Subject: Re: Vlan-aware bundling over VPLS

From: Lizhong Jin<[email-masked]>
Date: Thu, 8 Nov 2012 19:25:56 +0800

It would be potentially useful for VLAN-aware bundling in datacenter 
(related with NVO3). If the virtualized L2 network could provide 
VLAN-aware bundling, the customer could manage its own VLAN domain, 
otherwise one virtual network could only provide one broadcast domain. And 
the VM moving would be easier in a VLAN-aware virtualized L2 network if 
the packet VLAN is added by VM.

Lizhong

> 
> ------------------------------
> 
> Message: 3
> Date: Wed, 07 Nov 2012 22:04:46 -0500
> From: Phil Bedard <[email-masked]>
> To: "Fedyk, Donald (Don)" <[email-masked]>,
>    "[email-masked]" <[email-masked]>
> Subject: Re: Vlan-aware bundling over VPLS
> Message-ID: <[email-masked]>
> Content-Type: text/plain;   charset="US-ASCII"
> 
> Part of the draft is the multiplexing, the other part is dynamically
> creating bridge domains for each bundled VLAN and pruning the 
unnecessary
> VLANs from remote PEs.
> 
> 
> I thought a bit more and here is a use case where this draft may have 
been
> useful.  We have a cell backhaul service delivered over VPLS for a 
mobile
> provider.  Each cell site (hundreds) are delivered to a single 
aggregation
> UNI, however there is a requirement for each cell site to belong to its
> own bridge domain.  This required creating a separate service for each
> cell site so the configuration on the aggregation node is substantial
> since each service requires its own PW configuration (no A-D in use.)
> With the mechanisms in this draft it would have required only creating a
> single service network-wide.  There may have been some OAM implications 
to
> this but I'd have to think that through.
> 
> In some other instances it would not have worked because we use H-VPLS
> w/an MPLS U-PE.  The upstream N-PE would need a mechanism to relay the
> U-PE VLANs to other N-PEs, and potentially aggregate those from multiple
> U-PEs belonging to the same service. The N-PE would also have to 
maintain
> separate bridge domains itself. There is nothing in the draft covering 
an
> H-VPLS scenario which is fairly common.
> 
> We also create VLAN-unaware VPLS quite often since we do not want to be
> involved with adding/deleting customer VLANs and most customers do not
> have an explicit requirement for their VLANs to be in separate bridge
> domains across the VPLS.  In reality most of them assume the VPLS works
> that way since most L2 switches do, but we haven't run into issues using 
a
> shared MAC table. 
> 
> Phil 
> 
> 
> 
> On 11/7/12 7:06 PM, "Fedyk, Donald (Don)"
> <[email-masked]> wrote:
> 
> >Hi
> >
> >I know Giles as for SP input and I'm not an SP but reading this thread
> >I'm also not sure I that people are on the same page.
> >
> >When we look at Ethernet IEEE 802.1Q there is a C-VLAN, S-VLAN, B-VLAN
> >where the S-VLAN can multiplex C-VLANs  and the B-LAN encapsulates and
> >multiplexes S-VLANs (or also allowed C-VLANs).
> >
> >When we look at VPLS the MPLS Label can carry any one of the above as a
> >single VLAN (unaware). This inherently includes the above multiplex. To
> >allow multiplexing at this layer we are saying we allow carrying 
multiple
> >VLANs (C-VLAN, S-VLAN, or B-VLAN) with a single label.
> >
> >While a label multiplex makes some sense for C-VLANs. (This is 
analogous
> >to the S-VLAN model).  I'm struggling with a label multiplex of VLAN
> >multiplexors or in other words beyond C-VLAN. (I don't think people are
> >suggesting we multiplex B-VLANs this way so I guess the questions is 
how
> >far should we take this and why is this needed given the service level
> >already supports multiplexers ?
> >
> >Regards,
> >Don 
> >
> >-----Original Message-----
> >From: [email-masked] [mailto:[email-masked]] On Behalf 
Of
> >David Allan I
> >Sent: Wednesday, November 07, 2012 4:40 PM
> >To: UTTARO, JAMES; 'Rogers, Josh'; Lucy yong; Giles Heron; 
[email-masked]
> >Subject: RE: Vlan-aware bundling over VPLS
> >
> >Given in 802.1 standards there is IVL (independent VLAN learning) and 
SVL
> >(shared VLAN learning), whether a MAC table exists per VID, per group 
of
> >VIDs, or for all VIDs in a bundle in theory is an
> >implementation/operational choice. Or should be.
> >
> >SVL does permit MAC information gleaned from one VID's traffic to be 
used
> >by another, which reduces the number of unknowns. OTOH if the VIDs
> >identify completely disjoint sets of endpoints there is no shared
> >information of consequence.
> >
> >Cheers
> >Dave
> >
> >-----Original Message-----
> >From: [email-masked] [mailto:[email-masked]] On Behalf 
Of
> >UTTARO, JAMES
> >Sent: Wednesday, November 07, 2012 1:23 PM
> >To: 'Rogers, Josh'; Lucy yong; Giles Heron; [email-masked]
> >Subject: RE: Vlan-aware bundling over VPLS
> >
> >+1.. 
> >
> >Jim Uttaro
> >
> >-----Original Message-----
> >From: [email-masked] [mailto:[email-masked]] On Behalf 
Of
> >Rogers, Josh
> >Sent: Wednesday, November 07, 2012 3:09 PM
> >To: Lucy yong; Giles Heron; [email-masked]
> >Subject: Re: Vlan-aware bundling over VPLS
> >
> >[Lucy] IMO: this is what all-to-one bundle offer. CPE performs the 
filter.
> >The critical question for this scenario is if each VLAN has its own MAC
> >space or not?
> >
> >Under the currently available VPLS method, the MAC table is shared for
> >the entire VPLS instance.  This method is no different than a native
> >ethernet network using 802.1ad, I'm not concerned with 'isolating' the
> >mac table between vlans, but if I was I'd be inclined to use something
> >available (ie, multiple VPLS instances/multiple PW's, or PBB/PBT)
> >
> >
> >-Josh
> >
> >
> >On 11/7/12 2:02 PM, "Lucy yong" <[email-masked]> wrote:
> >
> >>Hi Josh,
> >>
> >>Thank you for the reply first.
> >>
> >>> -----Original Message-----
> >>> From: Rogers, Josh [mailto:[email-masked]]
> >>> Sent: Wednesday, November 07, 2012 1:37 PM
> >>> To: Lucy yong; Giles Heron; [email-masked]
> >>> Subject: Re: Vlan-aware bundling over VPLS
> >>>
> >>> Regarding the trans-AS service scenario?
> >>[Lucy] I don't know, I post the question to know where it will be 
used.
> >> What we had previously
> >>> discussed/envisioned, and I've seen one other SP do, is buy a ELAN
> >>> type service from another operator (who delivered via VPLS).  This
> >>> allowed them to put any VLAN they like on the ENNI, and deliver it 
to
> >>> any endpoint on the VPLS instance.  Since they own the equipment
> >>> (CPE) at each end, they simply allowed the vlan(s) they wanted to
> >>> deliver to that end point.
> >>> Since the VPLS instance is mac-learning, the only traffic that is
> >>> delivered that may be dropped by the CPE is BUM traffic.
> >>[Lucy] IMO: this is what all-to-one bundle offer. CPE performs the
> >>filter. The critical question for this scenario is if each VLAN has 
its
> >>own MAC space or not?
> >>
> >>Lucy
> >>>
> >>> I'm not certain I understand the question well.  Does that answer 
it?
> >>>
> >>> -Josh
> >>>
> >>>
> >>>
> >>> On 11/7/12 1:32 PM, "Lucy yong" <[email-masked]> wrote:
> >>>
> >>> >I would like to add one more question to SP beside Giles's
> >>> >
> >>> >3) Does this service aspect mean whenever customer want to add a 
new
> >>> VLAN
> >>> >(a BD) into the VPLS service, it has to inform the SP and SP has to
> >>> >provision this on PE?
> >>> >
> >>> >Thanks,
> >>> >Lucy
> >>> >
> >>> >> -----Original Message-----
> >>> >> From: Giles Heron [mailto:[email-masked]]
> >>> >> Sent: Wednesday, November 07, 2012 8:55 AM
> >>> >> To: [email-masked]
> >>> >> Cc: Himanshu Shah; Lucy yong; Nabil Bitar
> >>> >> Subject: Re: Vlan-aware bundling over VPLS
> >>> >>
> >>> >> I'll leave the draft authors to comment on the points raised by
> >>> >> Himanshu and Lucy
> >>> >>
> >>> >> But I would like SPs to comment as to:
> >>> >> 1) whether VLAN-aware bundling is a requirement
> >>> >> 2) whether they require VLAN-aware bundling both for VPLS and
> >>> >> E-VPN
> >>> >>
> >>> >> Giles (chair hat firmly on).
> >>> >>
> >>> >> On 7 Nov 2012, at 14:13, Lucy yong <[email-masked]> wrote:
> >>> >>
> >>> >> > There is a trade-off on the solution. individual BD may have
> >>> >> different QoS requirement, multiplxing them together in a single
> >>> >> PW
> >>> may
> >>> >> lose some QoS and OAM capability. For example, when congestion
> >>> happens,
> >>> >> some BD may work and some may not, PW status is not able to 
reflex
> >>> that
> >>> >> properly.
> >>> >> >
> >>> >> > Lucy
> >>> >> >
> >>> >> >> -----Original Message-----
> >>> >> >> From: [email-masked] [mailto:[email-masked]] 
On
> >>> >> Behalf
> >>> >> >> Of Shah, Himanshu
> >>> >> >> Sent: Tuesday, November 06, 2012 2:04 PM
> >>> >> >> To: [email-masked]
> >>> >> >> Subject: Vlan-aware bundling over VPLS
> >>> >> >>
> >>> >> >> clarification question:   If vlan is the tag used for demux 
over
> >>> >> single
> >>> >> >> PW and if that vlan needs to be advertised then what is the
> >>> saving?
> >>> >> Is
> >>> >> >> this just saving of the PW label?
> >>> >> >> Himanshu
> >>> >> >>
> >>> >> >> Sent from my iPad
> >>> >
> >>>
> >>>

---

From: "Fedyk, Donald (Don)" <[email-masked]>
Date: Thu, 8 Nov 2012 15:07:19 +0000

Hi Lizhong

The way I see it:

In the case of non VLAN aware you need to add a C-VLAN service to a new node:

*         You create the service (local)

*         You add the access point (local)

*         You connect to the other service (PWs setup , Signaled,  may be automated)

In the case of VLAN aware you need to add a C-VLAN service to a new node:

*         You add the access point to a shared service (Local)

*         The service advertizes the VLAN Vector to all other points (Signaled, automatic)

However if the Service you implement is an S-VLAN and you are adding a C-VLAN on a VLAN unaware VPLS :

*         You add the access point to a shared service (Local)

We don't need VLAN aware to get bundling.

Don

From: Lizhong Jin [mailto:[email-masked]]
Sent: Thursday, November 08, 2012 6:26 AM
To: [email-masked]; [email-masked]; Fedyk, Donald (Don)
Subject: Re: Vlan-aware bundling over VPLS

It would be potentially useful for VLAN-aware bundling in datacenter (related with NVO3). If the virtualized L2 network could provide VLAN-aware bundling, the customer could manage its own VLAN domain, otherwise one virtual network could only provide one broadcast domain. And the VM moving would be easier in a VLAN-aware virtualized L2 network if the packet VLAN is added by VM.

Lizhong

> creating bridge domains for each bundled VLAN and pruning the unnecessary
> VLANs from remote PEs.
>
>
> I thought a bit more and here is a use case where this draft may have been
> useful.  We have a cell backhaul service delivered over VPLS for a mobile
> provider.  Each cell site (hundreds) are delivered to a single aggregation
> single service network-wide.  There may have been some OAM implications to
> U-PEs belonging to the same service. The N-PE would also have to maintain
> separate bridge domains itself. There is nothing in the draft covering an
> that way since most L2 switches do, but we haven't run into issues using a
> shared MAC table.
>
> Phil
>
>
>
> >allow multiplexing at this layer we are saying we allow carrying multiple
> >While a label multiplex makes some sense for C-VLANs. (This is analogous
> >suggesting we multiplex B-VLANs this way so I guess the questions is how
> >From: [email-masked] [mailto:[email-masked]] On Behalf Of
> >David Allan I
> >To: UTTARO, JAMES; 'Rogers, Josh'; Lucy yong; Giles Heron; [email-masked]
> >Given in 802.1 standards there is IVL (independent VLAN learning) and SVL
> >(shared VLAN learning), whether a MAC table exists per VID, per group of
> >SVL does permit MAC information gleaned from one VID's traffic to be used
> >From: [email-masked] [mailto:[email-masked]] On Behalf Of
> >UTTARO, JAMES
> >From: [email-masked] [mailto:[email-masked]] On Behalf Of
> >Rogers, Josh
> >[Lucy] IMO: this is what all-to-one bundle offer. CPE performs the filter.
> >>[Lucy] I don't know, I post the question to know where it will be used.
> >> What we had previously
> >>> allowed them to put any VLAN they like on the ENNI, and deliver it to
> >>filter. The critical question for this scenario is if each VLAN has its
> >>own MAC space or not?
> >>
> >>Lucy
> >>>
> >>> I'm not certain I understand the question well.  Does that answer it?
> >>>
> >>> -Josh
> >>>
> >>>
> >>>
> >>> >3) Does this service aspect mean whenever customer want to add a new
> >>> VLAN
> >>> >> some BD may work and some may not, PW status is not able to reflex
> >>> that
> >>> >> properly.
> >>> >> >
> >>> >> > Lucy
> >>> >> >
> >>> >> >> clarification question:   If vlan is the tag used for demux over
> >>> >> single

---

From: Lucy yong <[email-masked]>
Date: Thu, 8 Nov 2012 19:06:58 +0000

I concur what Doc states.

All-to-one  bundling  supports multiple bcast domains. The issue is if there is a need for each BD to have own MAC space. I don't see this is necessary for a tenant.

Lucy
From: [email-masked] [mailto:[email-masked]] On Behalf Of Fedyk, Donald (Don)
Sent: Thursday, November 08, 2012 9:07 AM
To: Lizhong Jin; [email-masked]; [email-masked]
Subject: RE: Vlan-aware bundling over VPLS

Hi Lizhong

The way I see it:

Don

Lizhong

---

From: Lizhong Jin<[email-masked]>
Date: Fri, 9 Nov 2012 17:26:22 +0800

Hi Don,
The potential case in my mind is in datacenter. In the provider L2VPN, the 
customer always has a CE switch which could do the VLAN filtering to 
ensure traffic separation between different customer VLANs. But in 
datacenter, if the network virtualization edge is in the hypervisor, there 
is no switch to do VLAN filtering between NVE and VM, then the VM should 
do the traffic filtering for different VLAN. In VLAN-aware switching, the 
traffic will be filtered at the ingress NVE, instead of VM.

For the VM moving case, it will be also useful if the VM's guest OS would 
add VLAN:
1. VM adds a VLAN to traffic and have an tagged interface with virtual 
switch.
2. the virtual switch will be the edge of virtual L2 network.
3. when VM moves to another place, the VLAN-ID should not be changed.
If VLAN-unaware is applied, the VLAN-ID maybe stripped by the edge, and 
VLAN translation is required to configure on the virtual switch when VM 
moving. While if VLAN-aware is applied, it ensures the same VLAN to be 
used at the domains traffic to/from VMs, and VM could move across the 
domains freely without bothering the virtual switch.
The virtual L2 network could be E-VPN, or VPLS? I am not sure. But for any 
virtual L2 network applied in NVO3, I think VLAN-aware has potential use 
case. draft-rekhter-nvo3-vm-mobility-issues-03 describes the moving issue 
in section 3.1.

Thanks
Lizhong

"Fedyk, Donald (Don)" <[email-masked]> wrote 2012/11/08 
23:07:19:

> ・         You create the service (local)
> ・         You add the access point (local) 
> ・         You connect to the other service (PWs setup , Signaled, 
> may be automated)
> 
> ・         You add the access point to a shared service (Local) 
> ・         The service advertizes the VLAN Vector to all other points
> (Signaled, automatic) 
> 
> ・         You add the access point to a shared service (Local) 
> 
> 
> We don’t need VLAN aware to get bundling. 
> 
> Don 
> 
> 
> 
> 
> otherwise one virtual network could only provide one broadcast 
> domain. And the VM moving would be easier in a VLAN-aware 
> virtualized L2 network if the packet VLAN is added by VM. 
> 
> Lizhong 
> 
> 
> > 
unnecessary
been
mobile
aggregation
maintain
an
multiple
analogous
how
[email-masked]
SVL
of
used
filter.
used.
to
its
it?
new
reflex
On
over

---

From: "Fedyk, Donald (Don)" <[email-masked]>
Date: Fri, 9 Nov 2012 15:59:34 +0000

Hi Lizhong

If you need VLAN filtering then the PBB-VPLS already offers this capability.  PBB-VPLS is I-SID aware and allows the flexibility.

My point is VLAN aware VPLS is recreating yet another version of VPLS with new forwarding with essentially the same features available today with standard tags. With the PBB-VPLS the limit on VLANs is 24 bit.

Cheers,
Don

From: Lizhong Jin [mailto:[email-masked]]
Sent: Friday, November 09, 2012 4:26 AM
To: Fedyk, Donald (Don)
Cc: [email-masked]; [email-masked]
Subject: RE: Vlan-aware bundling over VPLS

Hi Don,
The potential case in my mind is in datacenter. In the provider L2VPN, the customer always has a CE switch which could do the VLAN filtering to ensure traffic separation between different customer VLANs. But in datacenter, if the network virtualization edge is in the hypervisor, there is no switch to do VLAN filtering between NVE and VM, then the VM should do the traffic filtering for different VLAN. In VLAN-aware switching, the traffic will be filtered at the ingress NVE, instead of VM.

For the VM moving case, it will be also useful if the VM's guest OS would add VLAN:
1. VM adds a VLAN to traffic and have an tagged interface with virtual switch.
2. the virtual switch will be the edge of virtual L2 network.
3. when VM moves to another place, the VLAN-ID should not be changed.
If VLAN-unaware is applied, the VLAN-ID maybe stripped by the edge, and VLAN translation is required to configure on the virtual switch when VM moving. While if VLAN-aware is applied, it ensures the same VLAN to be used at the domains traffic to/from VMs, and VM could move across the domains freely without bothering the virtual switch.
The virtual L2 network could be E-VPN, or VPLS? I am not sure. But for any virtual L2 network applied in NVO3, I think VLAN-aware has potential use case. draft-rekhter-nvo3-vm-mobility-issues-03 describes the moving issue in section 3.1.

Thanks
Lizhong

---

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

IMO: when VM and NVE are on co-located, i.e. both are on a server, the filtering implementation is internal, no need to address in standard, and VM mobility will work just fun. When VM and NVE are remotely located, i.e. VM and NVE are connected through a local physical network, then the filtering function should not perform on the NVE, should be at the local network edge. Thus, neither case requires VLAN-aware bundling on NVE. Vm-mobility-issue draft is orthogonal to the VLAN-aware bundling request.

Lucy

From: [email-masked] [mailto:[email-masked]] On Behalf Of Lizhong Jin
Sent: Friday, November 09, 2012 3:26 AM
To: Fedyk, Donald (Don)
Cc: [email-masked]
Subject: RE: Vlan-aware bundling over VPLS

Hi Don,

Thanks
Lizhong