Subject: Vlan-aware bundling over VPLS

From: "Shah, Himanshu" <[email-masked]>
Date: Tue, 6 Nov 2012 15:04:03 -0500

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: Lucy yong <[email-masked]>
Date: Wed, 7 Nov 2012 14:13:52 +0000

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: Giles Heron <[email-masked]>
Date: Wed, 7 Nov 2012 14:55:05 +0000

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

---

From: Lucy yong <[email-masked]>
Date: Wed, 7 Nov 2012 14:59:15 +0000

Hi Giles,

Thank you to raise this question. 

In fact, I raised this question in the E-VPN req. last call. I like see some answer from SPs and a use case.

Lucy 

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

---

From: "Rogers, Josh" <[email-masked]>
Date: Wed, 7 Nov 2012 10:06:35 -0500

1) for us, not currently.  However, I understand the proposed benefit and
how it could be leveraged, and believe it _may_ become a needed feature in
the future.  We don't see use cases that would benefit from this approach
_today_ though.
2) I would be inclined to say that if it is available in VPLS, I'd like to
see it in E-VPN (although the converse is not necessarily true)

-Josh

On 11/7/12 8:55 AM, "Giles Heron" <[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
>>

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Wed, 7 Nov 2012 16:11:57 +0000

I am not a co-author of this draft but let me give you my 2 cents Š

Currently VPLS supports only VLAN-based and VLAN bundle service per RFC
4762 sec. 7.2 (that I helped with its writeup). In E-VPN, we introduce a
new service called VLAN-aware bundle service which allows to have multiple
bridge domains within the same VPN instance (e.g., EVI in EVPN).

I think the primary purpose of this draft is to allow for such service
which I believe many of the existing switches (from different vendors)
support already. This helps with PW scale and avoids having a full-mesh of
PWs per VLAN. The secondary purpose of it (I believe) is to provide VLAN
pruning using LDP signaling and that's why during the meeting I made the
comment that this needs to be a "SHOULD" or "MAY" as opposed to a "MUST".

Cheers,
Ali   

On 11/7/12 10:06 AM, "Rogers, Josh" <[email-masked]> wrote:

>This E-mail and any of its attachments may contain Time Warner Cable
>proprietary information, which is privileged, confidential, or subject to
>copyright belonging to Time Warner Cable. This E-mail is intended solely
>for the use of the individual or entity to which it is addressed. If you
>are not the intended recipient of this E-mail, you are hereby notified
>that any dissemination, distribution, copying, or action taken in
>relation to the contents of and attachments to this E-mail is strictly
>prohibited and may be unlawful. If you have received this E-mail in
>error, please notify the sender immediately and permanently delete the
>original and any copy of this E-mail and any printout.

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 7 Nov 2012 16:29:46 +0000

When multiple customer VLANs are boundled to a single VPLS instance or EVPN instance, it'd better to keep the broadcast domain associated with each customer VLAN separated from each other. The obvious benefits of such choice include: 1) support overlapping MAC address spaces across different customer VLANs and avoid unneccessary MAC withdrawal in such case; 2) avoid the unneccessary flood of BUM traffic of a given customer VLAN to those PEs which are not attached with that customer VLAN yet.

One possible use case is the CSC scenario.

Xiaohu

________________________________________
发件人: [email-masked] [[email-masked]] 代表 Rogers, Josh [[email-masked]]
发送时间: 2012年11月7日 23:06
到: Giles Heron; [email-masked]
主题: Re: Vlan-aware bundling over VPLS

-Josh

---

From: Giles Heron <[email-masked]>
Date: Wed, 7 Nov 2012 17:45:16 +0000

Hi Xiaohu,

I think we all understand the potential benefits of VLAN-aware bundling.  But of course nothing comes for free ;)

And it still remains for SPs to give more feedback on my questions...

What's your thinking on CSC?

Giles

---

From: "Sami Boutros (sboutros)" <[email-masked]>
Date: Wed, 7 Nov 2012 18:21:21 +0000

As discussed Himanshu

We have only one binding that we advertise regardless of the # of Vlans, the Vlans are signaled using the vector TLV, in which each Vlan is presented by a bit. 

So the saving is not only a label, but as well in control plane we have one message binding.

Thanks,

Sami

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 7 Nov 2012 18:21:28 +0000

In the CSC case, the tier-1 carrier (VPLS SP) assigns a single VPLS instance to a given tier-2 carrier (e.g., cloud data center SP which uses TRILL within its data centers) which in turn use VLANs to identify its different customers, for the purpose of data center interconnect. In this case, it may be hard for the tier-2 carrier to ensure there is no MAC address overlapping across multiple customer VLANs of its different customers/tenants. In addition, the virtual network topologies (i.e., PE routers to which a given customer/tenant VLAN is attached) of different customers/tenants of the given tier-2 carrier are usually different.

Best regards,
Xiaohu

________________________________________
发件人: Giles Heron [[email-masked]]
发送时间: 2012年11月8日 1:45
到: Xuxiaohu
Cc: Rogers, Josh; [email-masked]
主题: Re: Vlan-aware bundling over VPLS

Hi Xiaohu,

Giles

---

From: Giles Heron <[email-masked]>
Date: Wed, 7 Nov 2012 18:25:22 +0000

I can't really see the "tier-1" carrier being happy to be exposed to the C-MACs of the "tier-2" carrier.  But I'll leave SPs to comment on that.

---

From: "Sami Boutros (sboutros)" <[email-masked]>
Date: Wed, 7 Nov 2012 18:25:46 +0000

Which Qos aspect would we loose here?

Actually in the core you have only MPLS Qos, which is in the MPLS label, mapping some service Qos to the MPLS label doesn't change with this at all.

As for OAM capability, why is that lost? in the next rev we would describe how LSP Ping will be extended to do per service on the PW connectivity check.

If we need to communicate per service status via the PW status message, the same TLV can be used.

Thanks,

Sami

---

From: Lucy yong <[email-masked]>
Date: Wed, 7 Nov 2012 18:38:49 +0000

Hi Sami,

> Actually in the core you have only MPLS Qos, which is in the MPLS label,
> mapping some service Qos to the MPLS label doesn't change with this at
> all.
[Lucy] But SPs have a choice to construct multiple LSP TE tunnels where each support a particular CoS, Current mechanism allow the PW to carry customer CoS to be mapped into a proper LSP with the same CoS. When you multiplex them together, you loose such nature, right?
> 
> As for OAM capability, why is that lost? in the next rev we would
> describe how LSP Ping will be extended to do per service on the PW
> connectivity check.
[Lucy] You typically have SOAM map to a PW status in one-to-one for VPLS service. You lost that nature here, which require some new way to correlate if you get a customer complain on the service. Current draft does not address these. 

Regards,
Lucy

---

From: "Sami Boutros (sboutros)" <[email-masked]>
Date: Wed, 7 Nov 2012 18:50:50 +0000

Hi Lucy,

> [Lucy] But SPs have a choice to construct multiple LSP TE tunnels where each support a particular CoS,Current mechanism allow the PW to carry customer CoS to be mapped into a proper LSP with the same CoS. When you multiplex them together, you loose such nature, right?

Sami: Mapping a per service traffic on the PW to a given TE tunnel, this is a local implementation matter.

> [Lucy] You typically have SOAM map to a PW status in one-to-one for VPLS service. You lost that nature here, which require some new way to correlate if you get a customer complain on the service. C…

Sami: This is not true because the TLV we are proposing that encodes the VLans impacted can be used with the PW status, MAC WD, etc..

Thanks,

Sami

---

From: "Rogers, Josh" <[email-masked]>
Date: Wed, 7 Nov 2012 14:00:21 -0500

This sort of use case has come up before (where a operator A purchases a
'any to any' type II service from operator B) where the buyer wants to use
the service to deliver multiple services for multiple end users on the
second operator's network.  If VPLS is used, the C-Mac's on operator A's
network will be seen on operator B's network.

I see the value of the case that Xiaohu outlined, however its relatively
uncommon for us (never done it actually, only discussed it a couple
times), and we would be happy to wait and implement the same sort of thing
using E-VPN at a much later date.

-Josh

On 11/7/12 12:25 PM, "Giles Heron" <[email-masked]> wrote:

>I can't really see the "tier-1" carrier being happy to be exposed to the
>C-MACs of the "tier-2" carrier.  But I'll leave SPs to comment on that.
>
>> In the CSC case, the tier-1 carrier (VPLS SP) assigns a single VPLS
>>instance to a given tier-2 carrier (e.g., cloud data center SP which
>>uses TRILL within its data centers) which in turn use VLANs to identify
>>its different customers, for the purpose of data center interconnect. In
>>this case, it may be hard for the tier-2 carrier to ensure there is no
>>MAC address overlapping across multiple customer VLANs of its different
>>customers/tenants. In addition, the virtual network topologies (i.e., PE
>>routers to which a given customer/tenant VLAN is attached) of different
>>customers/tenants of the given tier-2 carrier are usually different.
>>
>> Best regards,
>> Xiaohu
>>
>> I think we all understand the potential benefits of VLAN-aware
>>bundling.  But of course nothing comes for free ;)
>>
>>> When multiple customer VLANs are boundled to a single VPLS instance or
>>>EVPN instance, it'd better to keep the broadcast domain associated with
>>>each customer VLAN separated from each other. The obvious benefits of
>>>such choice include: 1) support overlapping MAC address spaces across
>>>different customer VLANs and avoid unneccessary MAC withdrawal in such
>>>case; 2) avoid the unneccessary flood of BUM traffic of a given
>>>customer VLAN to those PEs which are not attached with that customer
>>>VLAN yet.
>>>
>>>> I'll leave the draft authors to comment on the points raised by
>>>>Himanshu
>>>> and Lucy
>>>>
>>>>>different
>>>proprietary information, which is privileged, confidential, or subject
>>>to copyright belonging to Time Warner Cable. This E-mail is intended
>>>solely for the use of the individual or entity to which it is
>>>addressed. If you are not the intended recipient of this E-mail, you
>>>are hereby notified that any dissemination, distribution, copying, or
>>>action taken in relation to the contents of and attachments to this
>>>E-mail is strictly prohibited and may be unlawful. If you have received
>>>this E-mail in error, please notify the sender immediately and
>>>permanently delete the original and any copy of this E-mail and any
>>>printout.
>

---

From: Lucy yong <[email-masked]>
Date: Wed, 7 Nov 2012 19:02:09 +0000

See below.

> Of Sami Boutros (sboutros)
> Sent: Wednesday, November 07, 2012 12:51 PM
> To: Lucy yong
> Cc: [email-masked]
> > [Lucy] But SPs have a choice to construct multiple LSP TE tunnels
> where each support a particular CoS,Current mechanism allow the PW to
> carry customer CoS to be mapped into a proper LSP with the same CoS.
> When you multiplex them together, you loose such nature, right?
> 
> 
[Lucy] Yes, it is local implementation. But, this approach may impact a lot of existing devices to do it. This pushes the mapping a per service traffic from a PW to a LSP to a VLAN to a LSP directly.
> > [Lucy] You typically have SOAM map to a PW status in one-to-one for
> VPLS service. You lost that nature here, which require some new way to
> correlate if you get a customer complain on the service. Current draft
> does not address these.
> 
> Sami: This is not true because the TLV we are proposing that encodes
> the VLans impacted can be used with the PW status, MAC WD, etc..
[Lucy] I do not catch this. Could you elaborate how it works if SOAM indicates a PM problem on a particular VLAN in the VLAN aware bundle, how does SP figure out where the problem is.

Lucy
> 
> Thanks,
> 
> Sami
> 
> >
> > Regards,
> > Lucy
> >>
> >> If we need to communicate per service status via the PW status
> message,
> >> the same TLV can be used.
> >>
> >> Thanks,
> >>
> >> Sami

---

From: "Sami Boutros (sboutros)" <[email-masked]>
Date: Wed, 7 Nov 2012 19:20:34 +0000

> [Lucy] Yes, it is local implementation. But, this approach may impact a lot of existing devices to do it. This pushes the mapping a per service traffic from a PW to a LSP to a VLAN to a LSP directl…

Sami:  I really don't get your comment, Vlan aware support is going to impact devices operation anyway. The PW here is servicing multiple services so the PW MUST be aware of the services, we din't claim anything different here.

> [Lucy] I do not catch this. Could you elaborate how it works if SOAM indicates a PM problem on a particular VLAN in the VLAN aware bundle, how does SP figure out where the problem is.

Sami: In the OAM/ PW message or whatever you call it, we include the service one/many VLans (in the new TLV we are proposing), this is what the draft is about.

Thanks,

Sami

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 7 Nov 2012 19:22:44 +0000

Fully agree with Gile's and Rogers's point that it woud be better to avoid deploy heterogenous network technologies on different sites of a tier-2 carrier at the beginning. In this way, there is no need to explore the C-MAC of tier-2 carrier to tier-1' carrier's VPLS PE devices. However, there may be some uncommon cases where hetergenous site networks are already there. For example, tier-2 carriers may want to interconnect their existing spanning-tree based data center network sites to some new data center network sites where TRILL or some other overlay network technologies are used.

Of course, operators' views are more desirable.

Best regards,
Xiaohu

________________________________________
发件人: Rogers, Josh [[email-masked]]
发送时间: 2012年11月8日 3:00
到: Giles Heron; Xuxiaohu
Cc: [email-masked]
主题: Re: Vlan-aware bundling over VPLS

-Josh

---

From: Lucy yong <[email-masked]>
Date: Wed, 7 Nov 2012 19:32:22 +0000

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

> Himanshu and Lucy

---

From: "Rogers, Josh" <[email-masked]>
Date: Wed, 7 Nov 2012 14:36:45 -0500

Regarding the trans-AS service scenario?  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.

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:

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

---

From: Lucy yong <[email-masked]>
Date: Wed, 7 Nov 2012 20:02:59 +0000

Hi Josh,

Thank you for the reply first.

> From: Rogers, Josh [mailto:[email-masked]]
> Sent: Wednesday, November 07, 2012 1:37 PM
> To: Lucy yong; Giles Heron; [email-masked]
> 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
> 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
> >> >> PW and if that vlan needs to be advertised then what is the
> saving?
> >> Is
> solely for the use of the individual or entity to which it is addressed.
> If you are not the intended recipient of this E-mail, you are hereby
> notified that any dissemination, distribution, copying, or action taken
> in relation to the contents of and attachments to this E-mail is
> strictly prohibited and may be unlawful. If you have received this E-
> mail in error, please notify the sender immediately and permanently
> delete the original and any copy of this E-mail and any printout.

---

From: "Rogers, Josh" <[email-masked]>
Date: Wed, 7 Nov 2012 15:08:58 -0500

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

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

---

From: Lucy yong <[email-masked]>
Date: Wed, 7 Nov 2012 20:13:16 +0000

Hi Josh,

Thank you for the clarification. This means that all-to-one bundles service interface can do this scenarios.

Highly appreciate in sharing your insight as a Service Provider.

Lucy

> Sent: Wednesday, November 07, 2012 2:09 PM
> filter.
> >> 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
> >> >3) Does this service aspect mean whenever customer want to add a
> new
> >> VLAN
> >> >> different QoS requirement, multiplxing them together in a single
> PW
> >> may
> >> >> some BD may work and some may not, PW status is not able to
> reflex
> >> that
> >> >> properly.
> >> >> >
> >> >> > Lucy
> >> >> >
> >> >> >> From: [email-masked] [mailto:[email-masked]]
> On
> >> >> Behalf
> >> >> >> Of Shah, Himanshu
> >> >> >> clarification question:   If vlan is the tag used for demux
> over
> >> >> single
> addressed.

---

From: Phil Bedard <[email-masked]>
Date: Wed, 7 Nov 2012 15:27:28 -0500

1) I have not seen this specific use case come up but I can understand the benefits and can't say it wouldn't be useful in some service scenarios but see my additional comments.  We've been deploying VPLS for years now without it so I wouldn't state it as a "requirement" but would certainly ease configuration in specific use cases.  

2) No, I see EVPN as a step forward from the current LDP VPLS, I don't think we need to back port every new feature in EVPN into VPLS. 

I have some additional comments.

  Some vendors do bundling already where multiple VLANs can be used within the same service as delimiters, the new part is maintaining a separate bridge domain.  I'm not sure why the VLANs need to be communicated, maintaining a separate BD per VLAN seems like a local decision, if the VLAN is always present either from the AC or via PW the device should be able to learn and store the VLAN/MAC combo as a separate entity like any other modern switch.   If the far end receives a frame for a VLAN not defined in the egress AC it should discard it.  

The draft says port or raw mode must be used, maybe a reference to RFC 4448 should be included.  Also the VLANs bing bundled would be locally defined and constitute a service delimiter.   According to that specific RFC raw mode is supposed to strip the VLAN in a service delimiting mode. 

I do not see any QoS concerns, traffic will be classified on ingress and use the same MPLS mechanisms whether it was one service or 10 services.    

Phil

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Wed, 7 Nov 2012 21:22:32 +0000

+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

-Josh

---

From: David Allan I <[email-masked]>
Date: Wed, 7 Nov 2012 21:39:43 +0000

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:

>> 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.
>> proprietary information, which is privileged, confidential, or 
>> subject to copyright belonging to Time Warner Cable. This E-mail is 
>> intended solely for the use of the individual or entity to which it is addressed.
>> notified that any dissemination, distribution, copying, or action 
>> taken in relation to the contents of and attachments to this E-mail 
>> is strictly prohibited and may be unlawful. If you have received this 
>> E- mail in error, please notify the sender immediately and 
>> permanently delete the original and any copy of this E-mail and any printout.

---

From: "Fedyk, Donald (Don)" <[email-masked]>
Date: Thu, 8 Nov 2012 00:06:21 +0000

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

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

-Josh

---

From: Phil Bedard <[email-masked]>
Date: Wed, 07 Nov 2012 22:04:46 -0500

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

---

From: "Fedyk, Donald (Don)" <[email-masked]>
Date: Thu, 8 Nov 2012 13:21:35 +0000

Hi Phil

Inline Don>

-----Original Message-----
From: Phil Bedard [mailto:[email-masked]] 
Sent: Wednesday, November 07, 2012 10:05 PM
To: Fedyk, Donald (Don); [email-masked]
Subject: Re: Vlan-aware bundling over VPLS

Don> Agree but you get that explicitly with a separate Label. The pruning is an extra function you must perform with VLAN aware. Sharing is controlled in the pure Ethernet cases as well, S-VLAN multiplex is a shared FDB. 

Don> The tradeoff is Single service large FDB, many shared Access points, single label VLAN aware with VLAN pruning, versus 
Multiple separate FDBs, separate access points, Multiple Labels VLAN unaware no pruning,
But the Customer experience is shared both in QoS and Ethernet operations in the VLAN Aware case. 
Flooding scope is increased per site and optionally pruned between sites.  

Don> Good Point. 

Don> Understood and you also get that with S-VLANs/B-VLANs. 

Phil