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