Re: VPLS model for L2VPN Framework document

> 
> If we want to  allow the PE bridges to be part  of a larger bridged network,
> it would be desirable for this  model to be supported by the VPLS framework.
> This would require:
> 
> - the PE contains a single bridge entity
> 
> - that bridge entity contains a single "port" to the emulated LAN
> 
> - each distinct  VLAN on  the emulated  LAN is replaced  by a  distinct VPLS
>   instance (an "emulated VLAN")
>
> - a further distinct  VPLS instance is used to  carry the "untagged packets"
>   of the emulated LAN. 
> 


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.

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.

Would you do this with real Ethernet segments?  E.g. use one LAN to 
control the status of all collection of other LANs connected to the same 
bridges?  I would guess not.  So I think its dangerous to try that 
approach here for those very same reasons.

> The  VPLS  instance used  to  carry the  untagged  packets  would, from  the
> perspective of discovery and setup,  be an independent VPLS instance.  It is
> only the  use of  this VPLS instance  that makes  it any different  than any
> other  VPLS  instance. Let's  call  this  VPLS  instance the  "control  VPLS
> instance".   Then we  need to  allow a  PE bridge  to attach,  via  a single
> emulated LAN port,  to one control VPLS instance and  to an arbitrary number
> of additional VPLS instances.
> 
> A set of PEs that attach to  a common VPLS control instance may be termed an
> "island".  Note that there is no requirement that two PE bridges in the same
> island support the same set of  VPLS instances, nor is there any requirement
> that  a VPLS  instance  (other than  the  control instance)  stay within  an
> island. 
> 
> The  framework model,  on the  other hand,  suggests that  a PE  may contain
> multiple bridges,  each with a port  to a single VPLS  instance.  This would
> seem  to rule  out  the possibility  of  using a  single  spanning tree  for
> multiple VLANs.
> 

Exactly, which is one of the critiques of the framework model.

- Matt