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)
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.

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

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
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

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?