VPLS Extensions for Provider Backbone Bridging - draft-balus-l2vpn-vpls-802.1ah-03.txt

1. VPLS Extensions for Provider Backbone Bridging - draft-balus-l2vpn-vpls-802.1ah-03.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 • Draft addressing the VPLS scalability (new item in the L2VPN charter) • MAC explosion, Service Aggregation • Versions 1 and 2 presented during IETF-69 and IETF-71 sessions • Extensions to existing VPLS Solution to accommodate IEEE 802.1ah • Re-using the existing VPLS Forwarder (PW termination) modules • Reflect the IEEE model in VPLS NSP – e.g. duality customer-backbone domains • Focus on VPLS Control Plane extensions • VPLS Addressing usage • Auto-discovery, Signaling – e.g. MAC Flush extensions, New NSP capabilities • Required additions to both Native Ethernet & VPLS to be handled in IEEE • i.e. whatever is transparent to VPLS

3. Updates, changes in draft-balus-l2vpn-vpls-802.1ah-03 • Addressed feedback, questions on the PBB-VPLS reference model • Why does inclusion of the PBB model require only NSP extensions?… • How to ensure separation of customer and backbone switching domains? • Separate VPLS addressing for each domain to allow flexible support of existing BGP-AD, LDP Signaling procedures in both domains. • No Addressing Extensions are required • New Section on NSP capabilities code points • Ensures the right type of NSPs are connected over existing Ethernet PWs • Details of the required extensions to VPLS MAC Flush • No Flushing of the Backbone FIBs, minimal processing in the Core PEs • Scalable M:1 packing of flush indications (M Customer VPNs into 1 LDP msg)

4. “Hub” PE-rs get visibility of 100,000s MACs High customer-addressing awareness MAC tables reduced: 1 B-MAC per node No customer-addressing awareness VPLS + PBB PE-rs MTU-s MTU-s # MAC addresses/node 100,000s 1,000s MTU-s PE-rs 0 PBB-VPLS benefits — MAC scaling and customer-addressing awareness VPLS PE-rs MPLS MPLS MTU-s MTU-s # MAC addresses/node Customer MACs PE-rs 100,000s Backbone MACs 1,000s MTU-s 0

5. “Hub” PE-rs aggregates 1,000s services and PWs High customer-service awareness VPLS + PBB B B PE-rs B B B B B B B B B MTU-s MTU-s # Services-PW/node 100,000s 10,000s 1,000s Svc PW Svc PW MTU-s PE-rs 0 MTU-s PE-rs PBB-VPLS benefits — Service/PW scaling and customer-service awareness VPLS PE-rs MPLS MPLS MTU-s MTU-s # Services-PW/node PW Customer services 100,000s PE-rs Svc Customer PWs 10,000s PE-rs Backbone services 1,000s Svc PW Backbone PWs MTU-s MTU-s 0 • Services and PWs dramatically reduced • No customer-service awareness

6. PBBN(802.1ah) MPLS WAN Domain 2 MPLS Metro Domain 3 PBN(802.1ad) B-VPLS versus I-VPLS domains & PBB-VPLS reference model B-VPLS = backbone / infrastructure VPLS, switching on Backbone MACs – e.g. 1 MAC per PE I-VPLS = customer VPLS, switching on Customer MACs – e.g. 1 MAC per customer station B-VPLS Domain 2 PE4 PW PW PE3 B B B-VPLS I1 I2 AC PBB-VPLS PE I-VPLS I-VPLS Domain 3 B-VPLS Domain 1 I PE6 PE5 AC PE1 PE2 PW AC I1 I1 I2 B B CE I1 I2 I2 I1 CE CE CE CE CE CE CE CE

7. MPLS TL MPLS SL B-DA B-SA Ethertype I-TAG Ethertype Payload MPLS TL MPLS SL C-DA C-SA Ethertype S-TAG Payload Ethertype PBB-VPLS & PW types • B-VPLS NSP on PE3 not aware of PBB encapsulation • Performs only IEEE 802.1ad switching using BMAC header • Same as PBB BCB in IEEE 802.1ah • PBB-VPLS addresses scalability concerns in a PE-rs – MTU-s environment • Existing PW types address the needs of PBB-VPLS, no need for a new one Ethernet type identifies the type of following tag for whichever NSP cares B-VPLS Domain 2 PE4 PE3 PW2 HVPLS PE-rs level B B I1 I2 BMAC Header/ Regular PW CMAC header/ Regular PW I-VPLS Domain 1 B-VPLS Domain 3 PW1 HVPLS MTU-s level I1 I1 I2 B B PE6 PE5 I1 I2 I2 I1 PE1 PE2 I-TAG format – see IEEE 802.1ah

8. PBB-VPLS Addressing for Auto-discovery and Signaling • Separate addressing allows seamless porting of existing Auto-discovery, Signaling • NSP capabilities sub-TLV may be used for additional protection – see Generic Eth PW draft B-VPLS Domain 2 PE4 PE3 PW2 B How to avoid miss-connections: e.g. PW3 connecting to B-domain? B B-VPLS – BMAC switching I1 I2 PW3 I-VPLS Domain 1 B-VPLS Domain 3 I-VPLS = Regular VPLS - CMAC switching I1 I1 I2 B B PE6 PE5 I1 I2 I2 I1 PE1 PE2

9. LDP MAC Flush for regular VPLS 4. Flush MAC -> PW FIB entries in I1..In Except MAC->PW31 Failure of the Active link B-VPLS Domain 2 5. Flush MAC -> PW FIB entries in I1..In Except MAC->PW43 PE3 PE4 LDP 5 LDP 4 I1 In LDP MAC Withdraws FEC I1 ……….. ……….. FEC In I1 In X-> PWi X-> PWj 1 1 B-VPLS Domain 1 I-VPLS Domain 3 PE1 PE2 LDP PE5 I1 In I1 In I1 In CE 2 3 QinQ SW (resilient access to VPLS) • “FLUSH ALL MACs but MINE” • where MINE = PW SOURCE • In PBB-VPLS the “SOURCE” is identified by the BMAC of the remote PBB-VPLS PE – see next slide Activation of the backup link CMAC X CE

10. LDP MAC Flush extensions for PBB-VPLS 4. No Flush or per service activity done in PE3; LDP forwarding for a few FECs (max 100s) • 5. “FLUSH ALL CMACs but MINE” • where MINE = BMAC SOURCE • i.e. Flush CMAC->BMAC • FIB entries in I1..In • Except CMAC->BM2 Failure of the Active link B-VPLS Domain 2 PE3 PE4 LDP 5 LDP B B LDP MAC Withdraw w/ PBB TLV: 4 I1 I2 X-> BM1 1 B-VPLS Domain 1 PBB TLV BMAC: BM2 ISIDs: I1-In I-VPLS Domain 3 PE1 PE2 LDP PE5 PE2 of BMAC=BM2 B B I1 I2 I1 I2 I2 I1 CE 2 3 QinQ SW (resilient access to VPLS) • VPLS E2E deployments keep using the existing tool • LDP MAC Flush for both VPLS types • Improved scalability from regular VPLS • 1 LDP message for n ISIDs • 1 Source BMAC – BM2 for PE2, No CMACs • B-PE3 not aware about PBB, just forwards LDP MAC Withdraw Activation of the backup link CMAC X CE

11. Next steps • Discuss the differences between the existing PBB-VPLS drafts • Use existing PW type(s) versus new PW type? • Consolidate the contents into one draft • Submit a consolidated version focused on the required changes to VPLS • What else do we need to address in IETF from a PBB-VPLS perspective? • … and what else should be addressed in other SDOs – i.e. IEEE?