Re: VPLS model for L2VPN Framework document

Ali Sajassi <[email protected]> Thu, 29 May 2003 14:21:38 -0700
Newsgroups gmane.ietf.ppvpn
Message-ID <[email protected]>
>
>
>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

Considering a VPLS as an "emulated LAN" with respect to the bridge, is 
certainly another model. However, the issue of handling inter-island and 
inter-provider loop prevention as well as scalability of expanding # of 
VLANs across different islands and providers become much more challenging 
(e.g., running STP between different islands and different providers for 
tens of thousands of customers).
In the model that considers a VPLS as emulated VLANs, the L3 connection of 
the PE to the core is considered as a single trunk port and thus 
split-horizon mechanism serves as a loop prevention mechanism for the 
emulated VLANs.


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

A PW can certainly be considered as a trunk or access port

>To me, this keeps the terminology and model incredibly consistent to 
>the  existing briding models.

If you consider, the L3 connectivity of a PE to the core as a trunk port 
with each VPLS instance as a VLAN over this trunk port, then the operation 
of this model would be consistent as well with the existing bridging model.


>Using a separate VPLS instance for discovery and setup (as discussed 
>below) creates a likely opportunity of the 'discovery' VPLS being in a 
>different state than the 'data' VPLS, which of course would screw 
>everything up.  It also creates the necessity for some VPLS 
>coordination  so that the bridge sees multiple VPLSs as a single LAN 
>port.  E.g. if the "untagged" VPLS does not come up (not enough labels or 
>whatever), do the others go down?  What of some of the others don't come 
>up, should the untagged VPLS go down?  I get the willies thinking about 
>the possibilities.

Yes, we discussed these issues and some of the potential solutions sometime 
back.

-Ali