1. 8/5/04L3VPN WG1 Multicast in BGP/MPLS IP VPNs Finally added to charter! Base specification: draft-rosen-vpn-mcast –Four years old, with few changes –Basis for all existing deployments and proposals –De facto standard, despite leaving some important problems unsolved –Should be WG document

2. 8/5/04L3VPN WG2 Formerly Unsolved Problems 1.General Inter-Provider Solution 2.Non-congruent multicast topology 3.Support for PIM-SSM 4.Sub-Optimality of Using One MDT per VPN 5.Which PIM variant to require (must require something to ensure inter- operability)

3. 8/5/04L3VPN WG3 Inter-Provider Problems One SP might not know address of other SP’s PE – for unicast, only needs to know BGP NH to it Even knowing the address, one SP’s core might not have route to other SP’s PE –BGP-free core This lack of knowledge interferes with PIM mechanisms for building the MDT –Don’t know where to forward the C-Joins.

4. 8/5/04L3VPN WG4 Proposed Solution From draft-nalawade-idr-mdt-safi: –MVPN PE distributes: route for itself in MDT-SAFI family connector attribute on unicast VPN-IPv4 routes, to associate its MDT-SAFI address with those routes (some controversy over coding of this attribute, but not significant to this WG) –Now any PE can determine the MDT-SAFI route towards a multicast transmitter at any VPN site. From draft-wijnands-pim-proxy: –In case transmitter address is not routable in SP network, specify its BGP NH in the Join message

5. 8/5/04L3VPN WG5 Support for PIM-SSM When PIM-SSM is used: –No RP, so need some other means of auto- discovering the roots of the MDTs Solution: –Advertise MDT-SAFI (PE’s IP address plus multicast group address for default MDT) –Constrain distribution of MDT-SAFI in same way as with VPN-IPv4 routes –Provides auto-discovery of PIM neighbors on the default MDT

6. 8/5/04L3VPN WG6 Support for Non-Congruent Multicast Topology Use MDT-SAFI to route towards MDT roots Can follow a different path than route towards IP address of MDT root Needs PIM extensions from draft-wijnands

7. 8/5/04L3VPN WG7 Sub-Optimality of Default MDT Don’t want one MDT per user multicast group, as that is unbounded. User multicast groups aggregated onto single MDT, so some traffic goes where it need not. Usual aggregation vs. optimization trade-off Data MDTs: proposed optional procedure for setting up additional MDTs to handle high-traffic multicasting

8. 8/5/04L3VPN WG8 Which PIM Variant to Require: I Shared trees require least state: –but don’t scale so well as traffic increases –even with source trees, state is bounded anyway by aggregation onto default MDTs –best method for producing shared trees is PIM-BIDIR –PIM-SM can be used to create shared trees: but not very good at it, due to need to unicast all packets to tree root

9. 8/5/04L3VPN WG9 Which PIM Variant to Require: II For source trees: –PIM-SM could be used, but has problems in inter- provider scenarios: Use of RP is major network engineering hassle Two SPs wouldn’t want to share RP, as no way to manage the intra-SP part of the service Assignment of multicast group address virtually impossible: n-party coordination problem Years of experience with PIM-SM shows these to be very real practical difficulties in multicast deployment –MSDP deals with some of these problems –PIM-SSM was created to avoid these problems, and is the preferred way to produce source trees

10. 8/5/04L3VPN WG10 Which PIM Variant to Require: III Given that: –Each variant scales well in some dimensions and poorly in others –Old fashioned PIM-SM does have wide deployment, support may be needed for legacy equipment –SSM provides for easiest management Choices: –Make SSM the “required to implement” variant, or –Require SSM, BIDIR, and SM –Require SSM only for inter-provider Of course, which to deploy is up to SP

11. 8/5/04L3VPN WG11 Wrap-Up Some controversies exist over new material: –Nothing fundamental –All issues are open to discussion –When two groups are largely in agreement, there is an unfortunate tendency to emphasize the small areas of disagreement. If we remain focused on the technical issues, it should be possible to adopt the mvpn draft as a WG draft, and evolve it into a doc with which everyone is happy.