Subject: VPLS model for L2VPN Framework document

From: Eric Rosen <[email-masked]>
Date: Tue, 27 May 2003 13:32:28 -0400

Ali's been  trying to help me understand  just what Mick and  Norm have been
objecting to with respect to the  VPLS model in the framework.  Let's see if
I've improved my understanding of the issue.

In a  pure bridged  environment, a set  of bridges  is connected via  a LAN.
Each bridge has a  single port to a particular LAN.  Each  LAN can contain a
set of  VLANs, and  a packet  on that LAN  belongs to  a particular  VLAN by
virtue of  carrying a .1Q tag.   The LAN can also  contain untagged packets,
which do not belong to any of the VLANs. 

A  multi-VLAN spanning  tree protocol  can  be run  using untagged  packets.
This protocol  will determine, for each  VLAN, whether a  particular port is
blocked FOR THAT VLAN. 

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. 

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.

To eliminate this problem, we could state  that a PE may contain one or more
bridges,  each of  which  has a  single  emulated LAN  port.  Further,  each
emulated LAN port  may attach to one or more VPLS  instances.  When a single
emulated  LAN  port  attaches to  more  than  one  VPLS instance,  the  VPLS
instances may be thought of as "emulated VLANs", and no more than one of the
VPLS instances may be used to carry traffic that would be "untagged traffic"
if  the emulated  LAN port  were a  real LAN  port.  We  could also  add the
"island" stuff from two paragraphs back. 

Should we go further, and state that  a PE must contain a single bridge with
a single  emulated port that attaches  to all the VPLS  instances?  The "one
bridge" model seems to be required if and  only if the PEs are to be part of
a  larger  bridged  network.  Since  this  won't  always  be the  case,  I'm
reluctant  to make the  "multiple bridges"  model illegal  unless it  can be
shown that there are no conceivable advantages to it.

Comments?

---

From: Matt Squire <[email-masked]>
Date: Wed, 28 May 2003 22:13:03 -0400

> - a further distinct  VPLS instance is used to  carry the "untagged packets"

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.

> seem  to rule  out  the possibility  of  using a  single  spanning tree  for

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

- Matt

---

From: Muneyoshi Suzuki <[email-masked]>
Date: Thu, 29 May 2003 11:47:48 +0900 (JST)

> seem to rule out the possibility of using a single spanning tree for

I thought the framework model was that the PE contain a single Bridge.
Certainly, if it contains multiple Bridges, it is impossible to run
an MSTP instance among the Bridges. However, why multiple Bridges are 
needed in a single PE? If it is single, I think there is no problem. 

Thanks,

Muneyoshi Suzuki
Nippon Telegraph and Telephone Corp.

---

From: "Mark Seery" <[email-masked]>
Date: Thu, 29 May 2003 06:16:44 -0700

Some questions:

1) Is a VPLS subscriber not allowed to send frames that are already
formatted as a "stacked VLAN"?
2) In the model where the SP only has one VPLS, and each subscriber is a
VLAN, how many VLANs can be supported?
3) What are the scaling limitations/determinants of the model where the SP
has one VPLS for all subscribers?

Thanks,
Mark

---

From: Eric Rosen <[email-masked]>
Date: Thu, 29 May 2003 10:12:03 -0400

> needed in a single PE? If it is single, I think there is no problem. 

I didn't  have the MSTP stuff  clear in my mind  when I wrote  up the model,
which is why the text is subject to different interpretations.

The  way the  framework document  is written,  it seems  to suggest  that an
"emulated LAN"  is the as a "VPLS  instance", which in turn  suggests that a
single  MSTP instance  cannot govern  multiple  VPLS instances.   So I  just
wanted to  make it clearer that  an emulated LAN  could consist of a  set of
VPLS instances plus  an MSTP instance; I think this  would remove Mick's and
Norm's objection.  

But I  didn't want to  require that  if there is  an MSTP instance,  it must
govern all the VPLS instances; this  seems to me to be a deployment decision
which need not be mandated by the framework.

---

From: Eric Rosen <[email-masked]>
Date: Thu, 29 May 2003 10:26:45 -0400

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

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. 

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.

---

From: Ali Sajassi <[email-masked]>
Date: Thu, 29 May 2003 14:21:38 -0700

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

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

>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

---

From: Ali Sajassi <[email-masked]>
Date: Thu, 29 May 2003 14:29:33 -0700

>needed in a single PE? If it is single, I think there is no problem.

With respect to IEEE, the proper model is single bridge in a PE; however, 
if Ethernet access network is not used or IEEE control protocols is not 
used in the MPLS/IP access network, then one can use multiple bridges model 
where each bridge is simple 1980-style bridge (e.g., VSI). Although the 
later model is not recommended because of its restrictions.

-Ali

---

From: Ali Sajassi <[email-masked]>
Date: Thu, 29 May 2003 14:34:21 -0700

>formatted as a "stacked VLAN"?

No, it is allowed.

>VLAN, how many VLANs can be supported?

I don't know if anyone is suggesting such model; however, one model is one 
VPLS instance per subscriber and in a given island Ethernet island a 
subscriber maps into a VLAN. So the number of subscribers in a given island 
is limited to 4K but not in the network since the network can consist of 
many islands join together with a set of PWs.

-Ali

---

From: Matt Squire <[email-masked]>
Date: Thu, 29 May 2003 23:17:45 -0400

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

> would always  be intra-island, by definition.   I'm not sure  how your model

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.

> 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

---

From: Matt Squire <[email-masked]>
Date: Thu, 29 May 2003 23:38:20 -0400

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

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.

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. 
Thats why routers came along.  Geez, you work for Cisco, you have to 
appreciate that.

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

Assuming that PW is used as an P2P emulated LAN, sure.

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

---

From: Muneyoshi Suzuki <[email-masked]>
Date: Fri, 30 May 2003 13:27:37 +0900 (JST)

> VPLS instances plus  an MSTP instance; I think this  would remove Mick's and

It seems to me, something is still confusing. What is different between
emulated LAN and VPLS instance? Could you clarify this?

Regarding the framework model, if a single PE contains multiple logical
Bridges, a single VPLS Forwarder cannot be shared by Bridges. In this
case, a PE must contain multiple logical Bridges and VPLS Forwarders. Each
Bridge may have a single MSTP instance, and the instances interwork through
VPLS Forwarders. I can't see any problem in this model. (Needless to say,
if the VPLS Forwarders is supported by full mesh, there is a big issue ;-)

Thanks,

Muneyoshi Suzuki

---

From: Muneyoshi Suzuki <[email-masked]>
Date: Fri, 30 May 2003 13:39:24 +0900 (JST)

Ali,

> later model is not recommended because of its restrictions.

I'm not sure relation ship between the above and MSTP issue in the 
framework model.

If a Bridged LAN consists of 1980-style bridges that don't support xSTP,
it is logically equivalent a LAN segment from a viewpoint of Bridges that
support xSTP, so I think there is no xSTP related issue.

I still don't understand the issue in the framework model. I'm still 
waiting answers to the following questions as I posted over two weeks ago.

----
(1) Could you clarify what the mistake is in the Eric's model, and
and how your model resolved it? 

(2) Could you clarify what the right part from "A" means? I my understanding
it must be a MAC entity or a part of a MAC relay entity that distributed PEs.

(3) Could you clarify why the above model is consistent with the following 
Mick's interpretation of the Bridge protocol architecture.
---

Thanks,

Muneyoshi Suzuki

---

From: Eric Rosen <[email-masked]>
Date: Fri, 30 May 2003 10:41:04 -0400

Matt> if you start making fun of me for disagreeing with people... 

The problem  is not that the  L2 guys may  disagree, it's that it's  so hard
(for me) to tell whether they disagree or not ;-)

Eric> I think  the vision  here is that  a service provider's  network might
Eric> consist  of several  Q-in-Q  islands, where  some  VPLS instances  are
Eric> intra-island,  some  are inter-island,  and  some are  inter-provider.
Eric> However, an MSTP instance would always be intra-island, by definition.
Eric> I'm not sure how your model handles this.

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

So, if  a PE  has to  support an inter-provider  VPLS and  an intra-provider
VPLS, it would then need to  contain two virtual bridges, one for each VPLS?
That seems  more like my  original model, which  I thought you  didn't agree
with either ;-)

---

From: Ali Sajassi <[email-masked]>
Date: Fri, 30 May 2003 09:37:27 -0700

At 11:38 PM 5/29/2003 -0400, Matt Squire wrote:
>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 

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 

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.

>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

---

From: Ali Sajassi <[email-masked]>
Date: Fri, 30 May 2003 09:54:26 -0700

>emulated LAN and VPLS instance? Could you clarify this?

This is the way I look at it:
A VPLS instance corresponds to an end-to-end service instance that can 
spans across different access networks (e.g., one side to be QinQ and the 
other side to be MPLS).

An emulated LAN correspond to a set of PWs and their associated forwarding 
functions.

An emulated LAN looks like an emulated VLAN with respect to the bridge module.

>if the VPLS Forwarders is supported by full mesh, there is a big issue ;-)

Yes, in that model there is a one to one correspondence between logical 
bridge and forwarder and sometimes the combination of the two is referred 
to as VSI.

-Ali

---

From: Ali Sajassi <[email-masked]>
Date: Fri, 30 May 2003 10:06:07 -0700

>I'm not sure relation ship between the above and MSTP issue in the

MSTP would apply to the first model - a single bridge within the PE.

>support xSTP, so I think there is no xSTP related issue.

correct.

>and how your model resolved it?

Frankly I think it was a nit because Eric's wording is general and abstract 
enough that applies to both models. However, in the paragraph after the 
figure, there is a sentence that says:"Within the VPLS-PE, the bridge 
module attaches, through an "Emulated LAN Interface" to an Emulated LAN".
If one considers an emulated LAN as an emulated VLAN, then he can interpret 
this sentence as there is a bridge module for every emulated VLAN (e.g., 
for every VPLS instance) which in turn becomes the multi-bridge model 
within a PE.

>it must be a MAC entity or a part of a MAC relay entity that distributed PEs.

I cannot put this question in the proper context.

>Mick's interpretation of the Bridge protocol architecture.

Hope it is clear now from the above description.

-Ali