Multicast in VPLS draft-raggarwa-l2vpn-vpls-mcast-00.txt

1. Multicast in VPLSdraft-raggarwa-l2vpn-vpls-mcast-00.txt Rahul Aggarwal (Juniper) Yuji Kamite (NTT) Luyuan Fang (AT&T)

2. Co-Authors • Yakov Rekhter (Juniper) • Chaitanya Kodeboniya (Juniper)

3. Agenda • Update since last IETF • Limitations of existing VPLS proposals for Multicast • VPLS Multicast Architecture – where do the various drafts fit • Avoiding PIM snooping on the PWs • Use of P-Multicast Trees • Conclusion

4. Update Since Last IETF • Part of the work was presented in this WG at the last IETF when it was part of draft-raggarwa-l3vpn-mvpn-vpls-mcast-01.txt • The VPLS mechanisms are now in a separate new draft as per WG feedback

5. Current VPLS proposals: • “Virtual Private LAN Service” (draft-ietf-l2vpn-vpls-bgp) • “Virtual Private LAN Services over MPLS” (draft-ietf-l2vpn-vpls-ldp) • Limitations of these proposals for VPLS multicast…

6. Limitations of current VPLS proposals for VPLS Multicast • Do not allow the use of P-Multicast Trees for VPLS multicast data traffic • Desirable for optimizing bandwidth efficiency • PEs with VPLS sites that do not have receivers in a given multicast customer (S, G) receive traffic for that multicast stream • Focus on optimizing state and not bandwidth.

7. A given customer (multicast) packet should traverse a given service provider link at most once Deliver customer multicast traffic to only PEs that have (customer) receivers for that traffic Deliver customer multicast traffic along the “optimal” paths within the service provider (from the ingress PE to the egress PEs) Design Objectives for multicast support in VPLS service (not a complete list) Optimize Bandwidth: Optimize State: • The amount of state within the service provider network required to support Multicast in VPLS service should be no greater than what is required to support unicast in VPLS service • The overhead of maintaining the state to support Multicast in VPLS service should be no greater than what is required to support unicast in VPLS service Optimizing Bandwidth and State are conflicting goals

8. VPLS Multicast ArchitectureControl Plane • VPLS Auto-Discovery • Use existing VPLS auto-discovery mechanisms • Allow elimination of flooding • PE-CE snooping – draft-serbest-l2vpn-vpls-mcast • In VPLS a PE does not maintain a layer 2 adjacency with a CE • PE-PE reliable exchange of multicast control messages • Allow avoiding PIM-IGMP snooping overhead on PWs • PIM with reliability extensions or • BGP • Draft-raggarwa-l2vpn-vpls-mcast-

9. VPLS Multicast ArchitectureData Plane Tree = PIM, RSVP-TE P2MP LSPs, Receiver Initiated P2MP LSPs Separate Tree per-set-of C-(S, G)s “Selective Mapping” Separate Tree per-set-of VPLSs “Inclusive Mapping” Ingress Replication Separate Tree for Every C-(S, G) Aggregate State State = Unicast VPLS Unbounded State Increasing P-router state and Bandwidth efficiency Decreasing P-router state and Bandwidth efficiency

10. PIM snooping – implications on the state maintenance on PE routers • PE router has to maintain (S, G) state at least for all the (S,G) received from all the local CEs • E.g., assume PE with 1,000 CEs/sites, each VPLS site has at any given point in time on average receivers for 3 groups, PE has to maintain at least 3,000 (S,G) entries • PE router maintains (S, G) state by processing PIM Join messages received from (a) all sites of VPLSs connected to that PE, AND (b) all the remote PEs that have members of these VPLSs • E.g., assume PE router with 1,000 CEs/sites, each VPLS site has at any given point in time on average receivers for 3 group, each group is present on average in 10 sites, PE router has to process ~300 PIM Joinper second, and ~900 (S, G) entries per second in a steady state • due to periodic PIM Join and PIM Join suppression

11. Avoiding PIM Snooping on PWs Reliable Exchange of Multicast Control Messages between PEs VPLS A Site 4 PE 4 CE-A4 VPLS A Site 1 CE -A1 PE 2 VSI-A VPLS B Site 3 CE-B3 PIM Join C-S, C-G – Snooped at PE1 VSI-A VSI-A VRF-B PE 1 C-S -> C-G VSI-A VSI-B RR CE-A3 VPLS B Site 1 CE-B1 VPLS A Site 3 VSI-B PE 3 CE-B2 PEs have I-BGP Peering Only With the RR CE-A2 VPLS B Site 2 VPLS A Site 2 BGP MVPN Routing Information Update: <RD, C-S, C-G, Originator PE – PE1 Upstream PE – PE2, RT>

12. VPLS MulticastData Plane Tunnels • SP Multicast Trees • Draft-raggarwa-l2vpn-vpls-mcast • Aggregate Trees (Inclusive Mapping) • Aggregate Data Trees (Selective Mapping) • Use PE-CE snooping and PE-PE Reliable multicast message exchange • Ingress Replication • Existing VPLS proposals AND • PE-CE snooping and PE-PE Reliable multicast message exchange

13. Aggregate P-Multicast Trees • Allow one P-multicast Tree to be shared across multiple VPLSs • Can be setup using PIM or P2MP MPLS TE • No architectural limitation on the P-multicast tree technology • Requires a MPLS label to demultiplex a particular VPN • ‘Upstream’ label allocation by the root of the tree • Egress PEs maintain a separate label space for each P-multicast tree root • State grows less than linearly with number of VPLSs • Some efficiency of multicast routing may be sacrificed

14. VPLS Multicast Data PlaneP-Multicast Trees (Inclusive Mapping) VPLS A Site 4 PE 4 CE-A4 VPLS A Site 1 CE -A1 PE 2 VSI-A VPLS B Site 3 CE-B3 VSI-A VSI-A VSI-B PE 1 C-S -> C-G VSI-A VSI-B RR CE-A3 VPLS B Site 1 CE-B1 VPLS A Site 3 VSI-B PE 3 CE-B2 VPLS Membership Discovery: <Aggregation Capability> eg PE1 CE-A2 VPLS B Site 2 VPLS A Site 2 Aggregate Tree – PE2 as Root BGP Signaled VPLS – Tree Binding: <RD, Root PE, Upstream Label, RT, Tree Identifier>

15. Conclusion • Comments ?