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

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

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) PBB introduces a hierarchy where a Customer (CMAC) domain is separated from the Service Provider (BMAC) domain from both data plane (e.g. CMAC versus respectively BMAC switching) and control plane (e.g. xSTP, 802.1ak MRP) perspective. For example a CMAC should never be learned in the Backbone context/FIB. When porting the PBB hierarchy in PBB VPLS, the strict separation between the two domains must be maintained in both the VPLS data and control plane. In VPLS the control plane controls the setup of the data plane so it is possible to achieve this separation by proper separation of addressing and control plane procedures. Specifically in the example from Figure 1 the I-VPLS control plane must stay separate from the related B-VPLS control plane. This will ensure that control plane procedures (e.g. VPLS MAC Flush, OAM) destined for one domain will not leak into the other domain. Also PWs in one domain will not try to connect to the other domain: e.g. I-PW, destined for an I-VPLS will not try to connect to a B-VPLS instance. The simplest way to achieve this kind of separation is to assign for I-VPLS and B-VPLS separate addressing schemes. The following sections describe how this applies for BGP auto-discovery or for T-LDP signaling. Optionally usage of NSP capabilities sub-TLV [GE-PW] can guarantee additional protection against operational mistakes.

PBB-VPLS benefits — MAC scaling and customer-addressing awareness MTU-s PE-rs # MAC addresses/node 1,000s 100,000s VPLS + PBB PE-rs MPLS MPLS MTU-s MTU-s # MAC addresses/node Customer MACs 100,000s PE-rs Backbone MACs 1,000s MTU-s “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

PBB-VPLS benefits — Service/PW scaling and customer-service awareness MTU-s PE-rs VPLS + PBB # Services-PW/node 1,000s 100,000s 10,000s B Svc PW 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 1,000s Backbone services Svc PW Backbone PWs MTU-s MTU-s “Hub” PE-rs aggregates 1,000s services and PWs High customer-service awareness Services and PWs dramatically reduced No customer-service awareness

B-VPLS versus I-VPLS domains & PBB-VPLS reference model PBN (802.1ad) MPLS WAN Domain 2 MPLS Metro Domain 3 PW CE I I-VPLS B-VPLS PBBN (802.1ah) AC PBB-VPLS PE B-VPLS Domain 2 PE4 PE3 B B I2 I1 I-VPLS Domain 3 B-VPLS Domain 1 PE6 PE5 PE1 PE2 I1 I1 I2 B B I1 I2 I1 I2 CE CE CE CE 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 CE CE CE CE

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 B-VPLS Domain 2 PE4 PW2 PE3 C-DA C-SA Payload S-TAG Ethertype MPLS TL MPLS SL HVPLS PE-rs level B B MPLS TL MPLS SL Payload B-DA B-SA I-TAG Ethertype I1 I2 CMAC header/ Regular PW BMAC 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 I1 I2 PE1 PE2 I-TAG format – see 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

PBB-VPLS Addressing for Auto-discovery and Signaling Domain 2 PE4 PE3 B PW2 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 I1 I2 PE1 PE2 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

LDP MAC Flush for regular VPLS 4. Flush MAC -> PW FIB entries in I1..In Except MAC->PW31 B-VPLS Domain 2 5. Flush MAC -> PW FIB entries in I1..In Except MAC->PW43 PE3 PE4 5 LDP LDP I1 In LDP MAC Withdraws FEC I1 ……….. FEC In 4 X-> PWi 1 I1 In X-> PWj 1 B-VPLS Domain 1 I-VPLS Domain 3 PE1 PE2 PE5 LDP I1 In I1 In I1 In CE Failure of the Active link 2 3 “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 QinQ SW (resilient access to VPLS) Activation of the backup link CMAC X CE

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 B-VPLS Domain 2 PE3 PE4 5 LDP LDP MAC Withdraw w/ PBB TLV: 4 PBB TLV BMAC: BM2 ISIDs: I1-In LDP B B X-> BM1 1 I1 I2 B-VPLS Domain 1 I-VPLS Domain 3 PE1 PE2 PE5 LDP I1 I2 B B PE2 of BMAC=BM2 I1 I2 I1 I2 CE Failure of the Active link 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

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?