Re: VPLS model for L2VPN Framework document

Ali Sajassi <[email protected]> Fri, 30 May 2003 09:37:27 -0700
Newsgroups gmane.ietf.ppvpn
Message-ID <[email protected]>
At 11:38 PM 5/29/2003 -0400, Matt Squire wrote:
>Ali Sajassi 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
>>
>>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.
>
>This "emulated LAN == LAN" is the traditional model used by emulated LANs 
>over frame relay and emulated LANs over ATM.
>
>"Emulated LAN = VLAN" is a model supported by "emulated LAN = LAN" because 
>many LAN ports (access ports) have only a single VLAN.  But what it 
>doesn't do is introduce separate control and data planes.

The bridge module of the PE doesn't see separate control and data paths. It 
sees a single port over which both control and data traffic gets sent.


>Maybe its just me, but bridged networks have limits.  They always 
>have.  They weren't designed or intended to provide limitless worldwide 
>connectivity.  They're designed for simplicity, flexibility, and and 
>loop-free connectivity.  Global scaling was not one of the criteria.

What ! Have you talked to any SP regarding their VPLS requirements !! On 
the contrary global scaling is one of the major criteria for VPLS. The SPs 
are not only asking for the support of large number of customers within a 
metro region but also asking for much larger number across their metro 
regions.

>Thats why routers came along.  Geez, you work for Cisco, you have to 
>appreciate that.

Using VPLS as a low cost access into a L3VPN is certainly a viable model 
and option at SP's disposal. But that's not what SP have in mind when they 
talk about using VPLS end-to-end.


>>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.
>
>Well, no.  On a briding port, the control and data plane are tied 
>togehe.  A VLAN VPLS can fail without the control VPLS failing, or vice 
>versa.  Thats pretty inconsistent with existing models.

Bridge module sees them tied together even though at PW level they are not 
tied together. And the better the failure detection/recovery mechanism, the 
more negligible this difference looks to the bridge module.

-Ali