Re: VPLS model for L2VPN Framework document

[email protected] wrote:
>  > So this is where I may (or may not) offer a different 
>  > opinion from Norm 
>  > and/or Ali.  I continue to be of the opinion that the "emulated LAN" 
>  > (e.g. VPLS) should look like a LAN to the bridge function, 
>  > which implies 
>  > (to me anyway) that
>  >   a) if that VPLS is provisioned as a trunk port to the bridge, then 
>  > there are multiple VLANs per VPLS (not one VPLS/vlan) - this 
>  > is after 
>  > all how a bridge views a non-emulated trunk port
>  >   b) if that VPLS is provisioned as an access port to the 
>  > bridge, then 
>  > there is only one VLAN per VPLS (though as with tag stacking, one 
>  > "carrier" VLAN may not equal one "customer" VLAN).
>  > To me, this keeps the terminology and model incredibly 
>  > consistent to the 
>  >   existing briding models.
> 
> [RS] This seems to me to be a more attractive option. However, if a single
> VPLS instance is allowed to carry multiple VLANs then customer frames must
> carry a VLAN ID so that the receiving PE can determine which VLAN a frame
> belongs to. 

Thats the whole idea (at least to me).  The VPLS is treated by the 
forwarding entities just like an Etherne segment, and can carry tagged 
or untagged traffic depending on how the ports are configured.

> 
> I seem to remember a debate about whether customer frames should have their
> VLAN information stripped of or not. Can anyone tell me if there was a
> conclusion to that debate and what the reason was for removing the VLAN tag
> was? Was it simply to save bandwidth?
> 

As I recall  it was so neither side had to care if they used the same 
tags for the same VLANs.  The BW difference is minimal.


- Matt