Multicast Pruning for PBB-VPLS Draft-sajassi-l2vpn-pbb-vpls-multicast-00.txt July 28, 2008

Authors Ali Sajassi Luyuan Pradosh Mohapatra Nabil Bitar Raymond Zhang

What is it ? PBB-VPLS provides much improved scalability for C-MAC addresses # of VPLS instances and its associated PWs C-MAC scaling is provided by encapsulating many C-MACs in a B-MAC address VPLS/PW scaling is provided by using a single VPLS for many I-SIDs However, when a VPLS is used for many I-SIDs, then we need to limit the scope of broadcast per I-SID (e.g., per customer) This draft describe the use of BGP for limiting the scope of broadcast per I-SID (e.g., multicast pruning per I-SID)

What is it ? – cont. MPLS Core PE PE Customer Network (802.1Q) Customer Equipment Access Network (802.1ah) Access Network (MPLS) IB- BEB BCB BCB u-PE w/ IB-BEB PB PB CE PE IB- BEB BCB PE u-PE w/ IB-BEB PB PB PE

Why is it needed ? If multicast pruning is not performed, then multicast/ broadcast traffic of a given customer can be replicated and sent to receivers that have no interest in the data resulting in Unnecessary processing & BW consumption at the ingress PE Unnecessary BW consumption in the network Unnecessary processing at the egress PE

How it works ? Since these multicast B-MAC addresses are administratively configured (directly or indirectly), use BGP to “auto-discover” them A given PE that is administratively configured for a multicast B-MAC address, discovers what other PE devices are interested in this multicast group It then creates an OIF list corresponding to these PEs The multicast frames (for a given I-SID) are replicated only over the PWs associated with these PE devices

How it works ? – Cont. Define a new BGP NLRI called PBB-VPLS NLRI as follow: RD (8 octets) VE-ID of VSI (4 octets) B-MAC address (6 octets) Use AFI of 25 (L2VPN AFI) and a new SAFI for PBB-VPLS Use a new BGP attribute called PMSI Tunnel Attribute as defined in [MVPN-BGP-Encode] and [L2VPN-Mcast] to indicate “ingress replication” is used for this NLRI.

Advantages Extending the existing auto-discovery for this propose which MPLS providers are already familiar with Avoiding using any IEEE protocols for the MPLS core !!

Next Step Solicit comments on the mailing list Ask for WG status by next IETF meeting