80 likes | 217 Views
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
E N D
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
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
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
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?
Why PBB VPLS? • 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-VPLS Domain 2 PE4 PE3 B B I1 I2 B-VPLS Domain 1 VPLS Domain 3 PE1 PE2 PE6 PE5 B B I2 I2 I1 I1 CE CE CE CE CE CE CE CE
TL SL B-DA B-SA Ethertype I-TAG C-DA C-SA Ethertype VID Payload Ethertype B-DA B-SA Ethertype I-TAG C-DA C-SA Ethertype TL VID SL Payload Ethertype C-DA C-SA Ethertype VID Payload Ethertype PBB VPLS model B-PW B-PW ETH AC (BVID) • 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 B-module CBP PIP I-module I1 I2 I-PW I-PW ETH AC(CVID/SVID)
Extensions to VPLS MAC Flush • 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) PE4 BM1->NextHop B PE3 • 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) B VPLS I2 PE5 (BM5) B X-> BM1 I1 B B PE1 (BM1) PE2 (BM2) I1 I1 CE CE CMAC Y CMAC X