1 / 11

Multicast in BGP/MPLS IP VPNs

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.

ccarlos
Download Presentation

Multicast in BGP/MPLS IP VPNs

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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

  2. 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

  3. 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

  4. 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

  5. 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

  6. 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

  7. 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

  8. 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

  9. 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

  10. 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

  11. 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

More Related