110 likes | 270 Vues
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.
E N D
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 L3VPN WG
Formerly Unsolved Problems • General Inter-Provider Solution • Non-congruent multicast topology • Support for PIM-SSM • Sub-Optimality of Using One MDT per VPN • Which PIM variant to require (must require something to ensure inter-operability) L3VPN WG
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. L3VPN WG
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 L3VPN WG
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 L3VPN WG
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 L3VPN WG
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 L3VPN WG
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 L3VPN WG
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 L3VPN WG
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 L3VPN WG
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. L3VPN WG