1 / 11

MVPN Profiles

MVPN Profiles. Why do we need “profiles”? By design, architecture provides many choices: PE-PE C-multicast routing info distribution: PIM or BGP Multicast data distribution infrastructure: GRE encaps with PIM trees, MPLS encaps with RSVP-TE P2MP LSPs mLDP P2MP LSPs mLDP MP2MP LSPs

gretchen-griffin
Télécharger la présentation

MVPN Profiles

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. IETF 70 L3VPN WG MVPN Profiles • Why do we need “profiles”? • By design, architecture provides many choices: • PE-PE C-multicast routing info distribution: PIM or BGP • Multicast data distribution infrastructure: • GRE encaps with PIM trees, • MPLS encaps with • RSVP-TE P2MP LSPs • mLDP P2MP LSPs • mLDP MP2MP LSPs • Ingress replication with IP-based encaps … • No consensus (and not desirable) to eliminate all but one choice • No vendor wants to implement all possible combinations of options

  2. IETF 70 L3VPN WG What’s Good About Specifying Profiles? • Profile: A set of options which are: • useful together, and • wanted by a customer • Customer can ask for the profile it wants: • conformance to a profile is well-defined • i.e., multi-vendor interoperability is possible.‏ • Decisions can be based on customer demand, rather than IETF debate.

  3. IETF 70 L3VPN WG FUD About Profiles • “Wouldn’t it be better to have fewer options, or even no options?” • Only if you believe that one size fits all • Only if there’s enough real world experience to show that only one set of options is needed • Only if there’s real consensus behind a single profile • “Unless one profile is mandatory, there’s no guaranteed interoperability” • In fact, it doesn’t matter if one profile is mandatory, unless that’s the one that everyone wants!

  4. IETF 70 L3VPN WG Profiles Using PIM Control Plane • “PIM? Oh, that’s so passe!”  • Some facts: • All existing deployments use PIM • Not going away tomorrow • One big advantage: known to work, many years experience behind it • Scalability issues do exist, but not even close to approaching them in practice

  5. IETF 70 L3VPN WG Isn’t BGP the “new generation?” • WG docs do not favor either PIM or BGP over the other • BGP for multicast: new, experimental, with certain risks: • Increased J/P latency • Impact on other uses of BGP • Sparse Mode: we think BGP handles sparse mode okay, but there are some differences from PIM, impact remains to be seen • Some customer deployments use PIM in odd ways (e.g., use more control than data) that may not fit well with BGP • BGP great at disseminating state, less great at handling transactions • many PIM operations are transactional • this caused the BGP solution to become more complicated than originally envisaged, at least by me

  6. IETF 70 L3VPN WG Profiles with PIM • Primary Focus is one two profiles: • PIM+GRE • Existing deployments • Really two “sub-profiles”: • Legacy sub-profile that corresponds exactly to existing deployments • Fully standard sub-profile that provides PIM+GRE in a way which is fully compatible with WG docs • PIM+MPLS • We think MPLS data transport can provide a number of advantages that make it useful with a PIM control plane.

  7. IETF 70 L3VPN WG PIM+GRE Profile • Legacy sub-profile contains non-standard items, specified in draft: • MDT/SAFI, connector • Replaced by Intra-AS AD Route and VRF Route Import Extended Community in standards • PIM RD+vector Join Attribute, for unsegmented inter-AS trees in “vanilla” option B nets • IMHO should be added to WG standard, but has gotten tangled up in the “loose threads” • Draft also specified fully standard PIM+GRE sub-profile

  8. IETF 70 L3VPN WG PIM+MP2MP-LSP Profile • PIM control plane is used • MP2MP LSPs used for data and control packet distribution • MI-PMSI required for PIM, but: • the P-tunnels instantiating the MI-PMSI are created only as needed, • a PE joins a particular P-tunnel only as needed. • No full mesh of P-tunnels • unless needed anyway for data

  9. IETF 70 L3VPN WG MP2MP LSPs as P-Tunnels • Each P-tunnel is MP2MP LSP rooted at a given PE • To send a JP to a PE, join its MP2MP LSP and send the JP on that LSP • Bidir: joining based on RPA discovery, choose DF based on upstream multicast hop selection for RPA • To send data to the other PEs: • Non-bidir: send on the MP2MP LSP that you are the root of • Bidir: send on the MP2MP LSP rooted at the selected DF‏ • N.B.: If no one wants data from a particular PE, the P-tunnel rooted at that PE is never created

  10. IETF 70 L3VPN WG Interesting Properties • Number of P-tunnels determined by number of PEs that have data to send • generally much smaller than total number of PEs • therefore addresses PIM/MI-PMSI scalability issues • When receiving data on MI-PMSI, can always tell which PE transmitted it • inferred from LSP label, since only root transmits data on LSP • data arriving from “wrong” upstream PE easily discarded • makes efficient support of C-bidir possible • eliminates need for single forwarder selection • asserts never occur • Does not require a second (upstream-assigned) MPLS label • Still allows use of S-PMSIs as necessary

  11. IETF 70 L3VPN WG Future of This Draft • Offered now as individual/informational • Hopefully would progress to RFC after WG docs • One might infer the interest of certain vendors and customers in these profiles  • WG might or might not decide to bless the notion of profiles and standardize a few • In that case, we might want to reconsider the role of this doc

More Related