Subject: SVLAN in the 2VLAN E-Tree solution

From: Jiangyuanlong <[email-masked]>
Date: Sun, 22 Apr 2012 09:25:24 +0000

Hi Josh and Shahram,

Please see my comments in line tagged with [JY].
I also changed the title to reflect the topic in discussion.

Regards
Yuanlong
----------------------------------------------------------------------

Date: Fri, 20 Apr 2012 14:40:09 -0400
From: "Rogers, Josh" <[email-masked]>
To: Shahram Davari <[email-masked]>, Lizhong Jin
	<[email-masked]>,	"[email-masked]" <[email-masked]>,
	"[email-masked]"	<[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: The status of the approaches to the E-Tree solution?
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="us-ascii"

This is a very good question.  A common (but not necessarily good) use case we run into is service multiplexing UNI's where multiple ELAN or ETREE services are handed off to the customer, and the S-VLAN is 'coordinated' with the customer.  Meaning we expect them to tag traffic for service X with S-tag X.
[JY] If ELAN or ETREE is the same service as defined in MEF, only C-VLANs may exist in the UNI as service de-multiplexer. S-VLAN may only appear in the E-NNI, if this is the case, the S-VLAN should be 'coordinated' with the external network (maybe Ethernet itself).

I suppose that we would ask the customer to use the 'root' S-Tag at the root site, and the 'leaf' at leaf sites, however this introduces a problem in my mind, because I believe the 2VLAN method has been working under the mindset of popping the s-tag off on UNI egress.  In this situation where we want to keep the s-tag in tact, we would require the s-tag to be kept on both ingress at one end and egress at the other.  (So things like PVST don't get upset about being sent with one vlan received w/out it)
[JY] If the customer is a network provider, I think it is a possible case. But the S-TAG need not be popped off in this case since it is not a E-Tree UNI with the end customer, but a NNI with another carrier (customer as a network provider).

This means that the customer would be expected to either, 1) send a frame with one VLAN id from one site type, and expect to receive it with another at the other site types, and the operator sort of 'maps' between root/leaf s-tags.  Or 2) transmit one vlan on a UNI, and expect return traffic to be tagged with the other vlan.

Neither of which is a good/reasonable option.  Is there some other way I haven't considered here?

-Josh

From: Shahram Davari <[email-masked]<mailto:[email-masked]>>
To: Lizhong Jin <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: The status of the approaches to the E-Tree solution?

Hi,

I also have a question regarding 2-VLAN. What if the customer traffic already has an S-VLAN? Do we need a 3rd VLAN to identify the L/R?

Thx
Shahram