Extension to LDP-VPLS for Ethernet Broadcast and Multicast draft-delord-l2vpn-ldp-vpls-broadcast-exten-03 Presenter: Zhihua Liu, China Telecom IETF79, Nov 2010 Beijing, China Authors: Simon Delord, Telstra Raymond Key, Telstra Frederic Jounay, France Telecom Yuji Kamite, NTT Communications Zhihua Liu, China Telecom Manuel Paul, Deutsche Telekom Ruediger Kunze, Deutsche Telekom Mach Chen, Huawei Lizhong Jin, ZTE Note: Simon Delord has changed affiliation to Alcatel-Lucent in Nov

Introduction This document proposes a simple extension to LDP-VPLS to improve bandwidth efficiency for Ethernet broadcast and multicast traffic within a carrier's network. It uses unidirectional point-to-multipoint PseudoWires (P2MP PWs) to minimise payload frame duplication on physical links. Authors believe this solution is complementary to the BGP based solution described in draft-ietf-l2vpn-vpls-mcast-08. 2

Problem Statement Two specific issues are highlighted in RFC5501: –Issue A: replication to non-member site. –Issue B: replication of PWs on shared physical path. Issue A requires Layer 3 information –for each AC on PE, to avoid sending traffic to unintended destination; –and also between PEs, to avoid flooding across the VPLS backbone. RFC5501 mentions in relation to Issue A: –“This will present scalability concerns about state resources (memory, CPU, etc.) and their maintenance complexity.” Issue B on the other hand can still be improved without making use of any Layer 3 information. 3

Motivation Some operators may want to keep VPLS agnostic to customer’s Layer 3 traffic –Operators may not be allowed to look above Layer 2, due to regulatory issues –Operators may not want to do Layer 3 snooping, due to complexity in operations Some operators may want a manual and granular optimisation process –Allow optimisation only to certain services without impact on others For example, only need it for video distribution. –Allow optimisation only to certain areas of their network without impact on the rest Only required in those areas with congestion Some network elements may not support the required features Some operators may prefer a deterministic process to an entirely automated path selection algorithm –Operations will become more complicated if topology change more frequently –Troubleshooting will be difficult if frequent multicast membership changes draft-ietf-l2vpn-vpls-mcast-08 is a solution that looks at solving both Issue A and Issue B. However it proposes that, even for LDP-VPLS, BGP be introduced. –This may require additional, undesired operational efforts for operators. 4

Scope of the Proposed Solution This draft explores if there is a simple way to improve Layer 2 Ethernet broadcast and multicast bandwidth with: –Minimal extension to RFC4762 and without the need to add BGP –Minimal impact to existing RFC4762 deployed networks –Operator driven optimisation to minimise the number of states and the potential operational complexities associated with dynamic changes within a carrier's network. 5

Proposed Solution Uses P2MP LSPs: –Minimise packet replication on physical infrastructure –Allow P routers to be transparent to services Uses unidirectional P2MP PWs: –Multiple P2MP PWs can be carried over a single P2MP LSP Defines enhancements to RFC4762 –1 st enhancement: Selection of PEs for P2MP PW deployment –2 nd enhancement: Flooding mechanism –3 rd enhancement: MAC Learning mechanism Simple fall-back using P2P PWs. 6

Proposed Solution – One Example 7 On the left, standard full mesh P2P PWs. On the right, add two P2MP PWs: P2MP PW1 - PE1 is Root PE, PE2 and PE4 are Leaf PEs P2MP PW2 - PE3 is Root PE, PE2 and PE4 are Leaf PEs No need for P2MP PWs to cover all PEs in a VPLS. For Broadcast from PE1, use P2MP PW to PE2 and PE4, use P2P PW to PE3. +

Choose PEs for a P2MP PW At the difference of P2P PWs, not all PEs in a VPLS instance need to be connected via P2MP PWs. For each P2MP PW on a VPLS instance: –The operator selects one PE as the Root of the P2MP PW. –The operator also selects two or more PEs belonging to the same VPLS instance to be Leafs of the P2MP PW. –The P2MP PW is unidirectional only, that is, from the Root PE to all the Leaf PEs of the P2MP PW. –The operator also needs to make sure that there is an active P2MP LSP setup between the Root PE and the Leaf PEs. 8

Map P2MP PW to VPLS Instance Once the endpoints of the P2MP PW are selected and there is an active P2MP LSP between them, the operator can then create and associate the P2MP PW to a specific VPLS instance. –This activity can be done statically or via LDP. The proposed solution allows for a Root PE to map more than one P2MP PW to a specific VPLS instance. However, the Root PE MUST NOT associate a Leaf PE to more than one P2MP PW for a specific VPLS instance: –This is to avoid Leaf PE receiving duplicate Ethernet frames via different P2MP PWs. 9

Flooding and Forwarding A Root PE MUST NOT flood frames simultaneously over P2MP PW and P2P PW toward the same Leaf PE. For the flooding of an Ethernet broadcast and multicast frame: –If there is P2MP PW towards a remote PE, use it. The P2P PW for this remote PE is not used. One copy of the frame is forwarded on the P2MP PW for all the remote PEs associated with it. –If there is no P2MP PW towards a remote PE, use the P2P PW. 10

Address Learning A Leaf PE MUST support the ability to perform MAC address learning for packets received on a P2MP PW. When a Leaf PE receives an Ethernet frame on a P2MP PW, –First determines the VSI associated to the P2MP PW –Then determines the Root PE of the P2MP PW –Then determines the P2P PW associated with that Root PE –Finally, creates a forwarding state in the VPLS instance for the P2P PW associated with the Root PE, for the source MAC address learned on the P2MP PW. 11

Optional PE Local Enhancement An egress PE receiving an IP multicast frame from the network, will forward it to all ACs, including those with no member of the specific IP multicast group attached. The use of some Layer 3 information in order to improve bandwidth consumption on the AC may be considered. –Static configuration of IP multicast membership or Layer 3 snooping may be enabled on an AC basis, and filtering on egress IP multicast frames accordingly. 12

Conclusion This draft takes a pragmatic approach to the problem and proposes a very simple solution for certain common deployment scenarios. This simple extension to VPLS will bring positive net value and incremental improvements in existing networks. Authors believe this solution is applicable to a majority of LDP-VPLS deployments and is complementary to the BGP based solution described in draft-ietf-l2vpn-vpls-mcast-08. Thank you very much. 13