Re: VPLS model for L2VPN Framework document

Eric Rosen wrote:
> Matt> So this  is where I  may (or may  not) offer a different  opinion from
> Matt> Norm and/or Ali. 
> 
> Well, trying  to figure out  when the bridge  experts are agreeing  and when
> they are disagreeing is one of the challenges we face ;-) 

I can't always agree with Norm - he works with you!  And if you start 
making fun of me for disagreeing with people... well I'm just not sure 
if I'm the kettle or the pot.

> 
> Matt> Using a separate  VPLS instance for discovery and  setup (as discussed
> Matt> below) creates a likely opportunity of the 'discovery' VPLS being in a
> Matt> different  state than  the 'data'  VPLS, which  of course  would screw
> Matt> everything up. 
> 
> I think the  vision here is that a service  provider's network might consist
> of several Q-in-Q islands, where  some VPLS instances are intra-island, some
> are inter-island,  and some are  inter-provider.  However, an  MSTP instance
> would always  be intra-island, by definition.   I'm not sure  how your model
> handles this. 
> 

And thats fine for me as well.  xSTP is a protocol that may run over 
<real|emulated> LANs.  If you have a inter-provider VPLS and choose not 
to run xSTP over it, thats ok.  xSTP is enabled/disabled per VPLS port 
(e.g. PE) just as it would be for a real LAN.

> However, I  don't think  anything in my  proposed writeup prevents  you from
> setting  up a  single VPLS  instance which  contains multiple  VLANs, though
> there is the question of how the encapsulation would distinguish the VLANs. 
> 

Well, you said that the control traffic is separate from the data 
traffic, which is a huge difference than how LANs operate today.  I'll 
admit - I'm a coward.  Trying to coordinate multiple VPLS instances to 
create an "emulated LAN" is a scary proposition in light of the 
abundance of failure scenarios where not every VPLS is in that emulated 
LAN is working as well as every other.  Seems like a rathole to avoid.

- Matt