RE: VPLS model for L2VPN Framework document

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

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?

The only complication I can see here is that the service provider must
ensure trunk ports only connect to other trunk ports and access ports only
connect to other access ports. However, this is true in any Ethernet
switched network.

Richard