Subject: RE: Vlan-aware bundling over VPLS - add use case

From: "Dennis Cai (dcai)" <[email-masked]>
Date: Mon, 12 Nov 2012 01:00:54 +0000

Hi, all,

I'm the co-author for this draft. I saw lots of interesting discussion and points. I want to share some thoughts and use cases behind this draft

The original use case is enterprise Data Center interconnect using VPLS. The main motivation is for "user simplicity" which is very important in enterprise space. Although this concept could also be applied to SP DCI as well,  or other SP applications potentially

Think about enterprise customers who have multiple DC sites, and have hundreds of VLANs across DC sites, what will be the solution and configurations? The solution today is to use one VPLS instance per VLAN. This gives huge configuration, and introduce many PWs unnecessarily. QinQ is not an option here because it doesn't create separate broadcast domain per VLAN. It may run  into duplicated MAC issues

Yes, as some of you already pointed out, the function  in vlan-aware vpls has already been covered by PBB-VPLS. In fact, you can even treat this as a "simplified" pbb-vpls to help understand this draft. On the other hand, we didn't see much adoption of pbb-vpls in enterprise (but people in this alias can make comment). Pbb-vpls is considered complex (such as flooding packet pruning, MAC flushing, etc) and inefficient (big header) technology for enterprise DCI deployment.

With VLAN-aware VPLS, we just use VLAN for service multiplexer, which can be used for flooding packet pruning, and per-VLAN MAC flushing. This is much simple approach and doesn't introduce additional overhead. With platform implementation, the bridge-domain could be created implicitly, so user is even not aware of this. Per-bridge domain feature can still work as usual if it's required.

In short, it use same qinq over vpls configuration (simple and scalable) from end user point of view. However, it create separated bridge-domain per VLAN for true separation. Then it multiplex VLANs into same VPLS instance/PW to reduce the control planning overhead

Thanks
Dennis

---

From: Lucy yong <[email-masked]>
Date: Mon, 12 Nov 2012 01:54:29 +0000

Hi Dennis,

Please see inline.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Dennis Cai (dcai)
Sent: Sunday, November 11, 2012 7:01 PM
To: Fedyk, Donald (Don); Lizhong Jin; [email-masked]
Subject: RE: Vlan-aware bundling over VPLS - add use case

Hi, all,

Think about enterprise customers who have multiple DC sites, and have hundreds of VLANs across DC sites, what will be the solution and configurations? The solution today is to use one VPLS instance per VLAN. This gives huge configuration, and introduce many PWs unnecessarily. QinQ is not an option here because it doesn't create separate broadcast domain per VLAN. It may run  into duplicated MAC issues
[Lucy] I heard that SP and enterprise customer use QinQ approach to achieve "the simplify", and guess the enterprise DC has only one MAC address space to deal with. Is that right? Thus, "all to one bundle" meet the request and let enterprise DC sites create separate broadcast domain per VLAN. When using VLAN interconnect the sites together, VPLS merges the broadcast domain into one over WAN network only, but not at the enterprise site. If all VLANs use the same MAC space, I don't see much benefit for "user simplicity" by using VLAN-aware-bundling. It may save some bandwidth for SP WAN network but make PE less scale.

Yes, as some of you already pointed out, the function  in vlan-aware vpls has already been covered by PBB-VPLS. In fact, you can even treat this as a "simplified" pbb-vpls to help understand this draft. On the other hand, we didn't see much adoption of pbb-vpls in enterprise (but people in this alias can make comment). Pbb-vpls is considered complex (such as flooding packet pruning, MAC flushing, etc) and inefficient (big header) technology for enterprise DCI deployment.
[Lucy] PBB-VPLS is another option to achieve this.

In short, it use same qinq over vpls configuration (simple and scalable) from end user point of view. However, it create separated bridge-domain per VLAN for true separation. Then it multiplex VLANs into same VPLS instance/PW to reduce the control planning overhead
[Lucy] As I mentioned in previous e-mail, there are treat-offs in supporting this service interface in VPLS. I am not yet convinced if we should work on this service interface and hope see a concrete use case of it.

Regards,
Lucy

Thanks
Dennis

---

From: "Dennis Cai (dcai)" <[email-masked]>
Date: Mon, 12 Nov 2012 03:24:22 +0000

Hi, Lucy,

Comments inline

From: Lucy yong [mailto:[email-masked]]
Sent: Sunday, November 11, 2012 8:54 PM
To: Dennis Cai (dcai); Fedyk, Donald (Don); Lizhong Jin; [email-masked]
Subject: RE: Vlan-aware bundling over VPLS - add use case

Hi Dennis,

Please see inline.

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Dennis Cai (dcai)
Sent: Sunday, November 11, 2012 7:01 PM
To: Fedyk, Donald (Don); Lizhong Jin; [email-masked]<mailto:[email-masked]>
Subject: RE: Vlan-aware bundling over VPLS - add use case

Hi, all,

Think about enterprise customers who have multiple DC sites, and have hundreds of VLANs across DC sites, what will be the solution and configurations? The solution today is to use one VPLS instance per VLAN. This gives huge configuration, and introduce many PWs unnecessarily. QinQ is not an option here because it doesn't create separate broadcast domain per VLAN. It may run  into duplicated MAC issues
[Lucy] I heard that SP and enterprise customer use QinQ approach to achieve "the simplify", and guess the enterprise DC has only one MAC address space to deal with. Is that right? Thus, "all to one bundle" meet the request and let enterprise DC sites create separate broadcast domain per VLAN. When using VLAN interconnect the sites together, VPLS merges the broadcast domain into one over WAN network only, but not at the enterprise site. If all VLANs use the same MAC space, I don't see much benefit for "user simplicity" by using VLAN-aware-bundling. It may save some bandwidth for SP WAN network but make PE less scale.
[dennis] even for enterprise DC, it could have duplicated MAC address across different VLANs due to some virtual MAC address such as FW, load balancing, or even with VMs. The feedback of what we got is to prefer "separated" broadcast domain per VLAN to reduce the risk of the duplicated MAC address. So normal qinq may not meet the requirement here. However, enterprise customer does prefer the simplicity of the qinq over VPLS.

Yes, as some of you already pointed out, the function  in vlan-aware vpls has already been covered by PBB-VPLS. In fact, you can even treat this as a "simplified" pbb-vpls to help understand this draft. On the other hand, we didn't see much adoption of pbb-vpls in enterprise (but people in this alias can make comment). Pbb-vpls is considered complex (such as flooding packet pruning, MAC flushing, etc) and inefficient (big header) technology for enterprise DCI deployment.
[Lucy] PBB-VPLS is another option to achieve this.
[dcai] fully agree! Although PBB-VPLS can meet the full requirement, but it's considered as overkilled or too complex in enterprise space

In short, it use same qinq over vpls configuration (simple and scalable) from end user point of view. However, it create separated bridge-domain per VLAN for true separation. Then it multiplex VLANs into same VPLS instance/PW to reduce the control planning overhead
[Lucy] As I mentioned in previous e-mail, there are treat-offs in supporting this service interface in VPLS. I am not yet convinced if we should work on this service interface and hope see a concrete use case of it.
[dcai] as I mentioned, the original use case is for enterprise DCI. The main motivation is for user operational simplicity

Regards,
Lucy

Thanks
Dennis

---

From: Lucy yong <[email-masked]>
Date: Mon, 12 Nov 2012 15:02:03 +0000

Hi Dennis,

Snip..

[Lucy1]  If a customer knows these tread-offs on the VPLS service, they may think that PBB-VPLS is the right way to do in supporting different MAC spaces in each broadcast domain. IMO: supporting multiple mcast domain under one MAC address space or supporting separated MAC address space in each broadcast domain are two distinct requirements. NVO3 is about the latter.

Lucy