Multicast in bgp mpls ip vpns
1 / 11

Multicast in BGP/MPLS IP VPNs - PowerPoint PPT Presentation

  • Uploaded on

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.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' Multicast in BGP/MPLS IP VPNs' - khoi

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
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


Formerly unsolved problems
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)


Inter provider problems
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.


Proposed solution
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


Support for pim ssm
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


Support for non congruent multicast topology
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


Sub optimality of default mdt
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


Which pim variant to require i
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


Which pim variant to require ii
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


Which pim variant to require iii
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


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.