1. VPLS Extensions for Provider Backbone Bridging - draft-balus-l2vpn-vpls-802.1ah-02.txt John Hoffmans – john.hoffmans@kpn.com Geraldine Calvignac - geraldine.calvignac@orange-ftgroup.com Raymond Zhang - raymond.zhang@bt.com Nabil Bitar - nabil.bitar@verizon.com Olen Stokes - ostokes@extremenetworks.com Florin Balus, Mustapha Aissaoui, Matthew Bocci – matthew.bocci@alcatel-lucent.com

2. Background and Objective Version 1 presented during IETF-69 session Extensions to existing VPLS Solution to accommodate IEEE 802.1ah  Reflect the PBB model in VPLS – i.e. the duality customer-backbone domains  Builds on the VPLS Model from L2VPN Framework (RFC 4664)  VPLS Forwarding – changes to NSP/Bridge/Forwarder modules  VPLS Addressing, Auto-discovery, Signaling including MAC Flush

3. Updates, changes in draft-balus-l2vpn-vpls-802.1ah-02 Included new feedback, new co-author Initial discussions with Ali, Dinesh  Removed overlap, added references to use cases in PBB-VPLS interop draft Expanded description of existing chapters  IEEE 802.1ah I-B duality represented in the VPLS components  Added details on functionality split between PBB-VPLS components  More text on VPLS Addressing for Auto-discovery and Signaling  Detailed description of the PBB MAC Flush

4. Next steps Continue to sort out the content of the two existing PBB-VPLS drafts  Will keep one draft with PBB-VPLS interop discussion and framework, another draft with the basic solution components  Must figure out what we do with other items - OAM, Multicast etc… Existing items that require more discussion, WG feedback  More input on requirements?  How do we split the solution components?  Feedback on the MAC Flush section  do we need to specify the CMAC list or is the ISID enough?  do we need to address the negative MAC Flush case?

5. BACKUP SLIDES

6. Why PBB VPLS? B-VPLS Domain 2 B-VPLS Domain 1 VPLS Domain 3 PE1PE2 PE3 PE4 PE6 CE Add useful PBB capabilities to VPLS  MAC hiding, VPN Aggregation Maintain MPLS Benefits  Avoid running STP in the Core  Traffic Engineered, Resilient Backbone Selective introduction of PBB  Large VPNs, lots of CE switches Maintain Interoperability  Native Ethernet Access  Coexist w/ Regular VPLS/PWE3 Support both 1:1 and M:1 models  Customer VPN to B-tunnels B BB B I1 I2 I1 I2 PE5 CE

7. PBB VPLS model B1 – BMAC, Multipoint tunnel  VPLS Addressing, Control Plane  Forwarder + Bridge Modules I1 and I2 – CMAC, customer VPNs  VPLS Addressing, Control Plane  Forwarder + Bridge Modules B1 I1 I2 B-module I-module C-DA C-SA Payload B-DA B-SA I-TAG VID Ethertype I-PW ETH AC (CVID/SVID) I-PW B-PW ETH AC (BVID) C-DA C-SA Payload VID Ethertype TL SL TL SL C-DA C-SA Payload B-DA B-SA I-TAG VID Ethertype PIP CBP

8. Extensions to VPLS MAC Flush VPLS PE1 (BM1) PE2 (BM2) PE4 PE5 (BM5) PE3 CE B B BB B I1 X-> BM1 I2 CMAC X CMAC Y BM1->NextHop Potential Blackholing issue in PBB  Dual-Homing of CE to PE1, PE2  Access Topology Change – i.e. failure of the active link to PE1  I1 Traffic Blackholed to BM1 (PE1) Existing MAC Withdraw should not be used in the “Backbone VPLS”  BM1 is still reachable, no need to flush  Flush only CMAC -> BMAC entries Proposed Solution  “Flush all CMACs in I1 except the ones owned by PE2 (BM2)”  New LDP TLV in Address Withdraw message indicates the impacted ISID domain(s) (I1) and the source BMAC (BM2)