December 5, 2007IETF 70 L3VPN WG1 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

December 5, 2007IETF 70 L3VPN WG2 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.

December 5, 2007IETF 70 L3VPN WG3 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!

December 5, 2007IETF 70 L3VPN WG4 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

December 5, 2007IETF 70 L3VPN WG5 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

December 5, 2007IETF 70 L3VPN WG6 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.

December 5, 2007IETF 70 L3VPN WG7 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

December 5, 2007IETF 70 L3VPN WG8 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

December 5, 2007IETF 70 L3VPN WG9 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

December 5, 2007IETF 70 L3VPN WG10 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

December 5, 2007IETF 70 L3VPN WG11 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