Presentation is loading. Please wait.

Presentation is loading. Please wait.

VPLS Extensions for Provider Backbone Bridging - draft-balus-l2vpn-vpls-802.1ah-03.txt John Hoffmans – Geraldine Calvignac -

Similar presentations


Presentation on theme: "VPLS Extensions for Provider Backbone Bridging - draft-balus-l2vpn-vpls-802.1ah-03.txt John Hoffmans – Geraldine Calvignac -"— Presentation transcript:

1 VPLS Extensions for Provider Backbone Bridging - draft-balus-l2vpn-vpls-802.1ah-03.txt John Hoffmans – Geraldine Calvignac - Raymond Zhang - Nabil Bitar - Olen Stokes - Florin Balus, Mustapha Aissaoui, Matthew Bocci –

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

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

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

7 PBB-VPLS & PW types  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 I-VPLS Domain 1 PE4 CMAC header/ Regular PW B I2 PE5 I1I2 I1 B-VPLS Domain 3 PE1 PE2 PE3 BB B I1 I2 PE6 PW1 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 I1 PW2 HVPLS MTU-s level HVPLS PE-rs level BMAC Header/ Regular PW C-DA C-SA Payload S-TAG Ethertype MPLS TL MPLS SL MPLS TL MPLS SL Payload B-DA B-SA I-TAG Ethertype 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 I-VPLS Domain 1 PE4 I-VPLS = Regular VPLS - CMAC switching B I2 PE5 I1I2 I1 B-VPLS Domain 3 PE1 PE2 PE3 BB B I1 I2 PE6 PW3 B-VPLS – BMAC switching How to avoid miss-connections: e.g. PW3 connecting to B-domain? I1 PW2

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

10 LDP MAC Flush extensions for PBB-VPLS Failure of the Active link B-VPLS Domain 2 I-VPLS Domain 3 PE4 B-VPLS Domain 1 PE1PE2 PE3 B B I1 I2 PE5 CMAC X LDP B I1 I2 LDP CE X-> BM1 1 2 QinQ SW (resilient access to VPLS) 3 5 I1I2 B I1 I2 CE LDP MAC Withdraw w/ PBB TLV: 4 PBB TLV BMAC: BM2 ISIDs: I1-In 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 5. “FLUSH ALL CMACs but MINE” where MINE = BMAC SOURCE i.e. Flush CMAC->BMAC FIB entries in I1..In Except CMAC->BM2 PE2 of BMAC=BM2 4. No Flush or per service activity done in PE3; LDP forwarding for a few FECs (max 100s)

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?


Download ppt "VPLS Extensions for Provider Backbone Bridging - draft-balus-l2vpn-vpls-802.1ah-03.txt John Hoffmans – Geraldine Calvignac -"

Similar presentations


Ads by Google