SVLAN in the 2VLAN E-Tree solution

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" <josh.rogers@...>
To: Shahram Davari <davari@...>, Lizhong Jin
        <lizho.jin@...>, "l2vpn@..." <l2vpn@...>,
        "Alexander.Vainshtein@..." <Alexander.Vainshtein@...>
Cc: "yuqun.cao@..." <yuqun.cao@...>
Subject: Re: The status of the approaches to the E-Tree solution?
Message-ID: <CBB7245E.AF1%josh.rogers@...>
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 <davari@...<mailto:davari@...>>
To: Lizhong Jin <lizho.jin@...<mailto:lizho.jin@...>>, "l2vpn@...<mailto:l2vpn@...>" <l2vpn@...<mailto:l2vpn@...>>, "Alexander.Vainshtein@...<mailto:Alexander.Vainshtein@...>" <Alexander.Vainshtein@...<mailto:Alexander.Vainshtein@...>>
Cc: "yuqun.cao@...<mailto:yuqun.cao@...>" <yuqun.cao@...<mailto:yuqun.cao@...>>
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