Eric Rosen (erosen@cisco) Rahul Aggarwal (rahul@juniper)

1. Multicast in BGP/MPLS VPNsdraft-ietf-l3vpn-2547bis-mcast-00.txtanddraft-raggarwa-l3vpn-2547bis-mcast-bgp-00.txt Eric Rosen (erosen@cisco.com) Rahul Aggarwal (rahul@juniper.net)

2. MVPN Improvements • Scalability: • Control plane: reduce overhead needed to maintain state • Data plane: • more aggregation • Tunnels on per-VPN or coarser basis • Control Integration: reuse general L3VPN mechanisms? • More optimality in data plane • Less aggregation, but less scalable. • Eliminate requirement for MI-PMSI-based control • More flexibility in choosing tunneling technologies • Inter-AS Architecture

3. Tensions • Scale vs. Optimality, duh! • More accepted in unicast rtg than in mcast rtg • “Known to Work” vs. “Being Invented Now” • Control: integration vs. optimization • Data vs. Control Plane • Which is bottleneck?? • Multicast has unpredictable demands • Dogma

4. Non-Goals • Generic Improvements to Multicast Technology • Welcome, but not our focus • Solutions for non-L3VPN environments

5. Data Plane MI-PMSI Elimination? • Data MI-PMSI makes it easier to handle: • Dense Mode • Flooding-based applications • Transparent when MI-PMSI is in place • Require special measures otherwise • E.g.:, BSR

6. S1, S2 S1, S2 PE1 PE2 PE3 PE4 PE3 PE4 Multi-Homed Sources and Duplicate Traffic • PE3 wants <S1,G> via PE1, <S2,G> via PE2 • PE4 wants <S1,G> via PE2, <S2,G> via PE1 • Data from both streams travels both trees: duplicates • With MI-PMSI in control plane, PIM Asserts can be used to prevent this by forcing a “designated forwarder” • Need alternative

7. Eliminating Duplicates • Option 1: PE discards streams on “wrong” tree • Possible, with MPLS even easy • Wastes core bandwidth (trade-off) • Option 2: All PEs must choose same ingress • How? no unique “best route” to S • Can waste core bandwidth, increase latency • Maybe: best of both • Policy to force same ingress per AS only • Not to force the same ingress across ASs (prefer intra-AS path) • Mandatory mechanism to force dups to be discarded

8. Theme for BGP Work • BGP: L3VPN PE-PE signaling mechanism • Prima facie advantages of using for PE-PE multicast signaling: • Uniform control plane • Leverage of capabilities: constrained distribution, security, summarization, inter-AS, etc. • Scaling needs to be carefully examined • Dynamics

9. Theme for BGP Work, 2 • Don’t get carried away • No need to suppress work on other options • Don’t throw away “known to work” schemes • Two different functions to handle: • Not new to BGP: auto-discovery for MVPNs, label distribution for m-tunnels, m-streams, binding streams to tunnels • New to BGP: carrying PE-PE multicast routing, interfacing to PIM

10. Basic BGP Interactions • R-state: Egress PE gets PIM J/P from CE, instantiates state: "(S,G)receivers" • Distribute R-state based on RTs for VPN. • Design issue: mapping PIM J/Ps to updates and withdraws, not always obvious • S-state: many-to-one binding of R-state to P-tunnel • When ingress PE receives R-state, it sends PIM J/P to CE, may or may not need to create and distribute new S-state • New S-state only needed for S-PMSI binding • S-state distribution based on RTs for VPN

11. S-State Scaling, 1 • How many S-states are needed? • Minimum: one per VPN • each VPN has a default tunnel (possibly shared with others), • MPLS label not used for per-stream demux, • Maximum: one per stream • each stream individually bound to a tunnel, or • MPLS label used for per-stream demux • What is the rate of change of S-state?

12. S-State Scaling, 2 • Distributing S-state (only for S-PMSI) • Needs to be known by ingress & each egress • Possible to restrict distribution: • only to egresses for stream, or • to all PEs in VPN. Trades off more information with latency and signaling overhead • S-states increased by multi-homing of sources, perhaps not significantly

13. R-State Scaling 1 • This is the stuff that PIM usually handles • pure PIM states rather than labels/bindings • Total # R-states: • At egress PE, # streams • At ingress PE, we have choices: • One per stream per egress PE (“explicit tracking”) • One per stream (receivers somewhere, don’t remember where) • Applies to any control protocol

14. R-State Scaling (Intra-AS) 2 • Is explicit tracking needed? • No in these cases: • Default tunnels (any tunnel setup protocol) • Selective tunnels set up via PIM or mLDP • Yes in these cases: • Selective tunnels set up via RSVP-TE • “Aggregation via congruence” S-PMSIs • Should be used only when needed, as determined by head-end

15. R-State Scaling (Intra-AS) 3 • Without explicit tracking: • R-states can be regarded by BGP as “comparable” routes (NLRI design) • Aggregate R-state at RR • RR gets one per stream per PE, forwards one per stream

16. BGP MVPN FunctionalityIntra-AS • MVPN Auto-Discovery/Inclusive Binding • Granularity of <PE, MVPN> • Binding one or more MVPNs to a P-tunnel (I-PMSI) • C-multicast routing information exchange among PEs • Granularity of <PE, C-S/C-RP, C-G> • Selective binding and switching from I-PMSI to S-PMSI • One or more specific C-multicast streams, from one or more MVPNs, to a P-Tunnel

17. BGP MVPN FunctionalityInter-AS • MVPN Auto-Discovery • Aggregation of Auto-discovery information • Granularity of <AS, MVPN> • Inter-AS tunnels constructed by stitching intra-AS tunnels • Independent P-Tunneling technology per provider • MVPN PE-PE Routing Exchange • Aggregation of R-state • Granularity of <AS, C-S/C-RP, C-G> • Routing peerings between ASs only at ASBRs or RRs • Use RT Constrain to limit distribution of auto-discovery routes and C-multicast routes • Support of all three options for inter-AS unicast

18. BGP MVPN Inter-AS • MVPN that is present in N ASs would result in N inter-AS P-tunnels (one per AS, not one per PE) • To improve scalability multiple intra-AS tunnel segments within an AS could be aggregated into a single intra-AS P-tunnel • Uses auto-discovery routes • Inter-AS R-state is propagated by egress PE towards the source AS • Propagates using the inter-AS auto-discovery routes i.e. <source AS, MVPN> route • No flooding of R-state • No R-state in the ASBR forwarding plane

19. BGP Extensions – MCAST VPN NLRI • Consists of • RD • Src PE Address • C-S length, C-S • C-G length, C-G • MPLS labels • Used for Auto-Discovery Routes • MVPN intra/inter-AS auto-discovery • Intra-AS I-PMSI and S-PMSI binding • Inter-AS tunnels “stitched” from intra-AS segments • Also used for C-multicast routes • Intra/Inter-AS C-multicast routing information exchange

20. Switching to S-PMSI • Driven by PE connected to C-S • Binds (C-S, C-G) to a particular P-tree • P-tree may be shared with other (C-S, C-G) • Sharing is not constrained by MVPN membership • Uses auto-discovery routes • Uses the same procedures as auto-discovery, except that MCAST VPN NLRI carries C-S, C-G • Both for intra-AS and inter-AS