WARNING: This server is unstable and will be retired in the next days.
If you want to keep this forum available, please request immediately a migration
on the Nabble Support forum.
Forums that don't receive any migration request will be deleted forever.
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?