All things related to multicast

[David Farmer <>]

Inline and below;

On Fri, Aug 11, 2017 at 3:20 PM, Mark Brochu <> wrote:

Hi David,

Again, thanks for providing this.

No problem.

 

Hi Michael,

From Internet2’s perspective, as long as multicast is supported within a VRF, which is the intended end state for the Research and Education routing table, the MCAST-VPN SAFI is still required for SSM functionality.  The alternative is sticking with the legacy draft-rosen specification which wasn’t our intent.

Connectors would use whatever their previous implementation would be, presumably without MSDP.

It’s probably worth noting that the draft for multicast VPNs (https://tools.ietf.org/html/draft-ietf-l3vpn-2547bis-mcast-08) specifies that ASM as well as SSM be supported.  In order for Internet2 to technically “deprecate” “inter-domain ASM” on the backbone, we simply would disable MSDP functionality.  Some of the ASM functionality is still available, but will go unused.

There are some textbook cases where ASM is supported across a provider VPN without MSDP where the rendezvous point role is outsourced to the provider edge node.  I don’t think this is something we need to worry about, those scenarios seem geared towards smaller orgs.  Frankly, I think from a layer3 perspective they’re better suited to smaller private MPLS VPNs.

While I think the R&E VRF won't generally do ASM, we could still do ASM for any meritorious applications on the R&E backbone VRF if there were any. The backbone could still do a special purpose or private VRFs supporting ASM, or more likely point-to-point VLANs between participants that want to do ASM multicast between them, they can do MSDP or use per group RPs as appropriate. 

 

Removing MSDP will allow Internet2 to support multicast while mitigating the threat that MSDP storms have on our BGP infrastructure.  Type-5 MVPN routes don’t get generated for sources in the default SSM range of 232/8.  Traffic outside of 232/8 will be effectively broken, even when the source is known by the connector.  Internet2 might be able to override this behavior by changing the SSM range.

I hope this helps..
Best,
-Mark

On 8/9/17, 7:40 PM, " on behalf of Michael H Lambert" < on behalf of > wrote:

    Thanks, David.

    > On 9 Aug 2017, at 16:59, David Farmer <> wrote:
    >
    > While this is does not formally deprecate ASM, it is clear that ASM is no longer the recommended approach for inter-domain multicast and SSM is the recommended approach for inter-domain multicast.

    One point that isn't quite clear to me is whether we need BGP routes with multicast SAFI for SSM.  Can we rely on the unicast table only?

    Michael

There were three answers to the survey that basically said they needed inter-domain ASM, would those three please elaborate on their applications for inter-domain ASM.  Do you have an identified set of inter-domain peers that you need to do ASM with?  What groups?  

 https://doodle.com/poll/zkuvs2vc6dh5dmvr

We will continue to do ASM multicast on campus for multicast IP TV but for licensing reasons that is localized to campus anyway.  Everything else that uses ASM is best  localized to campus as well.

What about SAP and SDP, has that been adapted to SSM?  I know SDP has, but I'm not sure there is a replacement for ASM SAP.

Thanks

--

===============================================
David Farmer              
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota  
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================