Subject: RE: Comments on the L2 VPN framework and solutions documents

From: "Himanshu Shah" <[email-masked]>
Date: Wed, 7 May 2003 09:01:13 -0400

Norm,

You have to excuse me for jumping in at the
tail end and not following the thread.

I would like a clarification. 

Are you implying that 802.1ad is contemplating on
running one or more (Provider's) instances of R/M/STP 
on fully-meshed pseudowires?

/himanshu
Wavesmith Networks

-----Original Message-----
From: Norman Finn [mailto:[email-masked]]
Sent: Tuesday, May 06, 2003 8:14 PM
To: Muneyoshi Suzuki; Mick Seaman; Tony Jeffree; Les Bell; Paul Congdon;
Neil Jarvis
Cc: [email-masked]; [email-masked]
Subject: Re: Comments on the L2 VPN framework and solutions documents

Muneyoshi,

Muneyoshi Suzuki wrote:
> 
> > I don't think we're referring to the same model.  The correct model
> > for how a bridge interacts with full-meshes, one full-mesh per VPLS
> > instance, is:
> 
> The discussion is in the context of WG last call of the L2 FW doc and
> how to progress related solution drafts. So, I'm referring Eric's model
> describe in the FW doc. The following model completely differ from Eric's,
> so the following is disagreement to the FW doc, isn't it?

My abrupt answer:  The FW doc is misleading, because it disagrees
with the way bridges are both defined and built.

Another way to put it:  My diagram is the only way that a standard
bridge CAN interface to the full meshes within the layering model
shared by IEEE 802 and IETF.  I should be more careful in my claims:
It's the only way that has been presented, to date, to IEEE 802.1,
and has received a lot of support.

The problem with the model in the L2 FW doc (rev 3) is that it
clings to the idea, discarded by IEEE 802 in 1996, that separate
VLANs are handled by separate, independent, virtual bridges.  IEEE
802.1Q chose a model in which one bridge handles all of the VLANs
using individual physical ports, through which each of the VLANs
pass.

There is little point in arguing over which model is better.  I
favored the IETF model when 802.1Q was making its decision, but I lost.
The models, diagrams, and protocols employed by 802.1Q, and hence the
actual bridges built today, conform to the IEEE model.  There is
every reason to argue over which model is more relevant; the one to
which bridges are actually built should be of considerably more
interest than it seems to be on this mailing list.

The diagram, below, brings the IEEE model, in which all VLANs pass
through a single port, in line with VPLS full meshes, which exist one
per (Provider VLAN | Customer Service Instance | Forwarding Function).

Rather than rail against the L2 FW doc rev 3, let me suggest this:
Provider Bridges exist, are making money for their (several) builders,
and hopefully, are making money for their purchasers.  IEEE 802.1AD
will standardize them.  IEEE 802.1AD will be based on the 802.1Q model.
Deployed pseudowire full meshes will, of market-driven necessity, be
compatible with this 802.1AD provider bridge model.  The only questions
are whether or not the 802.1AD-compatible implementations will conform
to the IETF documentation, and if not, whether their will exist naive
implementations of the incorrect IETF documents that confuse the market.
(Incorrect by definition, if they disagree with bridge implementations.)

> >             |===========================================--------+
> >             |                   |          | forwarding |       |
> >             |                   |          |  function  +---    |
> >    E  i   --+                   | untagged +  VPLS 100  |       |
> >    t  n     |      Provider     |          | for BPDUs  +---    |  P  r
> >    h  t     |       Bridge      |          |------------|       |  s  o
> >    e  e     |                   |          |            +---    |  e  u
> >    r  r   --+                   |          | forwarding |       |  u  t
> >    n  f     |     Each "+" in   |  VLAN 26 +  function  +---    |  d  i
> >    e  a     |    the border of  |          |  VPLS 200  |       |  o  n
> >    t  c     |     this block    |   mux-   |            +---    |  w  g
> >       e   --+   represents one  +  demux   |------------|       |  i
> >       s     |     bridge port   | function |            +---    |  r  f
> >             |                   |          |            |       |  e  u
> >             |                   |          |            +---    |  s  n
> >           --+                   |          | forwarding |       |     c
> >             |                   | VLAN 589 +  function  +---    |  i  t
> >             |                   |          |  VPLS 300  |       |  n  i
> >             |                   |          |            +---    |     o
> >           --+                   |          |            |       |     n
> >             |===========================================--------+
> >                                 A          B            C
> >
> > The single interface above the "A" label at the bottom is the Provider
> > Bridge's bridge port that opens to the L3 world.  The three interfaces
> > above the "B" label are the interfaces between the forwarding functions
> > and the mux-demux unit that translates between the Provider Bridge's
> > P-VLAN space and the VPLS VCID space.  The "C" ports are the mouths of
> > the pseudowires.  The physical ports on the routed side are of no
> > interest to the bridge.  :)
> >
> > In my last note, I was pointing out that the each forwarding function
> > MUST control its "B" interface so that it provides 1) full service, or
> > 2) no service.  (Let's be honest -- my last note was a little confused
> > between the "A" interface and the "B" interfaces.)
> >
> > Since VPLS meshes have one characteristic that physical LANs don't --
> > one VLAN can be disconnected, while another is working -- IEEE 802.1
> > needs to examine this situation, and figure out how to deal with it.
> >
> > Finally, let me note that only one VPLS -- the one used for BPDUs --
> > is absolutely required to prevent a meltdown of the Provider's network.
> > A failure of one of the other VPLSs affects only that customer's traffic.
> 
> (1) It seems to me, in the above model, PEs are interconnected with per
> customer meshes, where the PEs attached to the customer are interconnected
> with a full mesh. Therefore, in the worst case, there 2000 full meshes
> between PEs, if number of customers are 2000. Originally, full mesh has the
> O(N^2) problem, so the proposed scheme has O(#ofCustomers * N^2) problem.
> Furthermore, if fast protection is supported to avoid the protection
> racing problem and partial mesh, there are double meshes between the PEs.
> So, I don't feel any reality from the above model.

For N PEs, the number of LSPs is exactly N, because each LSP is a
multipiont-to-point tree terminating at the destination PE.  The number
of "branches" on all LSP trees is far less than O(N^2), because there is
(probably) no single VPLS that spans all of the PEs.  The VPLS that
touches the largest number of PEs determines the largest n^2 full mesh
of LSP "branches".  In a typical network with a very large number of
PEs, the actual number of LSP "branches" will be far less than N^2.

Within that partial mesh of LSPs, for each VPLS, there is a full mesh
of pseudowires.  The cost of setting up a pseudowire is trivial,
compared to the cost of an LSP, because it does not involve the
intervening routers.  The number of pseudowires required is O(m^2),
where m is not the total number of PEs, but some smaller number,
related to the typical number of PEs attached to each VPLS.

> (2) Frankly, I don't well understand the above model, because it
> illustrates some implementation, but is not a protocol architecture.

I disagree completely that it is not a protocol architecture.  I would
not implement the above diagram in one of my switches, because it would
be horribly inefficient, there.  This is precisely a protocol
architecture, because it illustrates exactly where the existing
standardized interfaces and standardized functions go, and exactly
where new protocol and/or functional elements are required.  Specifically,
the "mux/demux function", which is trivial, and the "Forwarding Function",
which L2VPN is defining.

> In the Bridge architecture defined in a series of the IEEE standards,
> a Bridge consists of MAC entities, a MAC relay entity, and a Higher
> layer entity. Could you clarify where these entities are located in
> the above figure? Where are MSAPs defined in ISO/IEC 15802-1 is located?
> If the provider Bridge is a VLAN aware Bridge, where are the E-ISSs located?
> What is VLAN mux-demux function? According to the standards, the VLAN ID
> value is effective only inside the MAC relay entity, so it does not
> identify MSAP. I'm not sure whether this conforms with the standards or not,
> but I think to realize this architecture big changes are needed to the
> current standards.

All of the standard IEEE bridge functions are contained in the "Provider
Bridge" block.  I did not break it out into its components, because there
is no need to do so; their existing functions are unchanged.  The VLAN
mux-demux function merely translates between the Provider's VLAN tags and
the Forwarding Function world.

The IEEE P802.1 Working Group writes the bridging standards.  All of the
members of IEEE 802.1, with whom I have discussed this diagram, and that is
most of them, believe the above diagram to be conformant to the IEEE 802
standards.  It's a shame I cannot explain it better, and I invite
those members of 802.1 who read this mailing list to respond, and either
argue with me, or hopefully, explain it better.  :)

-- Norm

---

From: "Mick Seaman" <[email-masked]>
Date: Wed, 7 May 2003 07:41:31 -0700

If the fully meshed pseudowires (and the attached equipment/functions at
their ends) provide a LAN Service (stictly the Internal Sublayer Service as
defined in 802.1D and 802.1Q Clause 6.5 (same number clause in both
documents) then RSTP/MSTP will work just fine.

To be more specific P802.1ad does specify the operation of a single instance
of MSTP within a Provider Network, how that travels over pseduowires is of
course how any LAN traffic travels over psedudowires (i.e. the pseudowire
protocol looks after making sure the configuration of the pseudo wires
correctly provides the fully connected LAN service, that not being either
MSTPs design goal or the desire of P802.1ad to specify the simulation of
LANs over non-LAN media, particularly where the non-LAN media have native
protocols that are to be used as part of the solution - MPLS for example).

Mick

-----Original Message-----
From: Himanshu Shah [mailto:[email-masked]]
Sent: Wednesday, May 07, 2003 6:01 AM
To: Norman Finn; Muneyoshi Suzuki; Mick Seaman; Tony Jeffree; Les Bell;
Paul Congdon; Neil Jarvis
Cc: [email-masked]; [email-masked]
Subject: RE: Comments on the L2 VPN framework and solutions documents

Norm,

/himanshu
Wavesmith Networks

-----Original Message-----
From: Norman Finn [mailto:[email-masked]]
Sent: Tuesday, May 06, 2003 8:14 PM
To: Muneyoshi Suzuki; Mick Seaman; Tony Jeffree; Les Bell; Paul Congdon;
Neil Jarvis

Muneyoshi,

-- Norm

---

From: Pedro Roque Marques <[email-masked]>
Date: Wed, 7 May 2003 11:07:09 -0700 (PDT)

Mick Seaman writes:

> If the fully meshed pseudowires (and the attached
> equipment/functions at their ends) provide a LAN Service (stictly
> the Internal Sublayer Service as defined in 802.1D and 802.1Q Clause
> 6.5 (same number clause in both documents) then RSTP/MSTP will work
> just fine.

> To be more specific P802.1ad does specify the operation of a single
> instance of MSTP within a Provider Network, how that travels over
> pseduowires is of course how any LAN traffic travels over
> psedudowires (i.e. the pseudowire protocol looks after making sure
> the configuration of the pseudo wires correctly provides the fully
> connected LAN service, that not being either MSTPs design goal or
> the desire of P802.1ad to specify the simulation of LANs over
> non-LAN media, particularly where the non-LAN media have native

Mick,
Running the risk of abusing your patience to explain basic things...

Assume i have provider bridges [A-Z].
Bridge A has two VPLSs:
 - VPLS 1 has attachement points in A B C.
 - VPLS 2 has attachement points in A C D.

I got the impression that the model that Norm Finn is attempting to
explain to the WG is one where xSTP actually involves A sending BPDUs
to all provider bridges in the domain [A-Z]. At least that was my
reading of the fact that in that model 'one VPLS instance exchanges
BPDUs for the entire provider bridge'.

If this is the case, in steady state and assuming that the root
bridges on the custumer domain is attached to A, would this result in
A flooding a single xSTP BPDU to [B-Z] w/ information about both VPLSs
or one BPDU per VPLS ?

thanks,
  Pedro.

P.S.: Any recomended literature on this topic ?

---

From: "Mick Seaman" <[email-masked]>
Date: Wed, 7 May 2003 15:59:25 -0700

Pedro,

For literature see Clause 7 in 802.1s (the MSTP amendment to 802.1Q which
will be rolled in to 802.1Q-2003).

You can find a copy at:

http://www.ieee802.org/1/files/private/s-drafts/d15/802-1s-d15.pdf

user: p8021 password: go_wildcats

I think this gives a better explanation of how all this layers out in .1Q
than the prior version of the document.

And I believe I agree with you on what Norm is trying to explain (but he
should confirm that himself, as there are many twists possible here).

The question about the number of BPDUs per VPLS depends on exactly how you
want to do this. I like the single MSTP BPDU answer best. The rest of this
answer has to wait until I complete the editing on the soon to be
distributed P802.1ad/D1, as I find that the answer is essentially the
content I am currently working on.

Mick

-----Original Message-----
From: Pedro Roque Marques [mailto:[email-masked]]
Sent: Wednesday, May 07, 2003 11:07 AM
To: [email-masked]
Cc: 'Himanshu Shah'; 'Norman Finn'; 'Muneyoshi Suzuki'; 'Tony Jeffree';
'Les Bell'; 'Paul Congdon'; 'Neil Jarvis'; [email-masked];
[email-masked]
Subject: RE: Comments on the L2 VPN framework and solutions documents

Mick,

thanks,
  Pedro.

---

From: "Mick Seaman" <[email-masked]>
Date: Wed, 7 May 2003 22:26:38 -0700

Pedro,
Let me try another shot at this, and at the same time possibly cast some
light on Eric's recent question (single bridge model versus multiple virtual
bridge model).

An IEEE Bridge connects to a LAN, or more properly an instance of the MAC
Service. The functionality of multiplexing and demultiplexing VLANs to and
from distinguishable packet formats on the LAN is an imbedded function of
the Bridge. Further the multiplexing/demultiplexing of certain control
protocols to and from the LAN is independent of the VLAN mux/demux. This can
be important from the protocol efficiency/scaleability point of view since
VLAN mux/demux is limited to associating each whole frames with a given
VLAN. Frames that are not VLAN associated can convey information that has
been aggregated for a number of VLANs (e.g. GVRP) or information that is the
same and applies to all VLANs (is this media working etc. etc.).

Since bridging is very susceptible to errors in perceived connectivity
[though I am amazed that people are generally so relaxed about burning
network bandwidth with routed packets counting out their hop counts during
reconfiguration] it is crucially important that (local) connectivity
information is bound closely to service support. Accordingly the IEEE Bridge
model does not include the possibility of any of the VLANs or the control
protocols accessed through a single M-SAP (point of attachment to the MAC
Service) being separately supported with methods that can lead to
independent/different connectivity/reachability/failure, i.e. data path ==
control path.

So while the decomposition of the services provided by a bridged network
into (one version of) a number of VPLS connections appears logically obvious
it misses a few things. (1) If the support of each VPLS is understood to be
accomplished by a number of 'virtual bridges' the very strong properties of
the mux/demux function that ties each of these together at each point of
underlying service use need to be explained and not trivialised (equal
potential reachability connectivity etc.) and if they cannot be guaranteed
overhauled and possibly replicated. (2) Removal of the non VLAN mux/demuxed
control traffic not only means that information that can no longer be shared
has to be replicated, but that certain items of information (what is the
maximum possible extent of this set of VLANs so that I can simply
autoconfigure each to the size demanded by external inputs) seems to have
disappeared entirely.

One excuse for the decomposition of the MAC service into the set of VLAN
specific MACs with no other non-VLAN component is that each VPLS will be a
'provisioned service'. At bottom this is simply a claim that the network
provider will never ever make a mistake and has a perfectly working service
at all times. [If you think that is good enough then you never have to ship
BPDUs except when the input conditions change, the far side of each VPLS
just manufactures repeat copies at regular intervals]. Being more serious
about this the question is what can break or change independently of what
else in the provider network. If VPLSes that split out customer data from
one site and recombine them at another can only work or break all together
then you don't need to track the connectivity of each with a separate BPDU,
you could just send one MSTP BPDU with information for all of them on any of
them (or on a separate control VPLS though that may be less attractive). If
they can all fail independently then you need per VLAN information be
carried on each (data path == control path).

I sort of anticipate that this discovery may lead to another outbreak of
'bridging doesn't scale' claims. I am afraid here that it is the
decomposition into multiple VPLSes and the pseudo-wire models that may be
failing the scaling test [good news is that it is entirely possible to get
both of these right]. In fact straight bridging with up to 4094 trees per
network (region) each supporting up to 4094 independent service instances
per link with learning on point to points relegated to the edge
ingress/egress ports seems to be doing just fine, so we'll just have to see
if we can agree on a VPLS/pseudo-wire model that does at least as well :-)

Mick

-----Original Message-----
From: Pedro Roque Marques [mailto:[email-masked]]
Sent: Wednesday, May 07, 2003 11:07 AM
To: [email-masked]
Cc: 'Himanshu Shah'; 'Norman Finn'; 'Muneyoshi Suzuki'; 'Tony Jeffree';

Mick,

thanks,
  Pedro.

---

From: Eric Rosen <[email-masked]>
Date: Thu, 08 May 2003 15:15:50 -0400

I think I see  what you're saying -- the FW model  provides one emulated LAN
per VPLS instance,  and only bridges which support  that VPLS instances need
attach to  that emulated LAN.  In  the IEEE model, all  the provider bridges
attach to a single emulated LAN,  and the VPLS instances would be treated as
VLANs of that emulated LAN.  

Since a VPLS would have sites  all around the world presumably, attaching to
multiple  provider networks,  why  doesn't this  imply  that every  provider
bridge in  the world needs to be  on the same emulated  LAN?  You're correct
that that does not seem scalable to me. 

Mick> (1) If the support of each  VPLS is understood to be accomplished by a
Mick> number  of  'virtual  bridges'  the  very  strong  properties  of  the
Mick> mux/demux function that  ties each of these together  at each point of
Mick> underlying service use need to be explained and not trivialised (equal
Mick> potential  reachability  connectivity  etc.)  and if  they  cannot  be
Mick> guaranteed overhauled and possibly replicated. 

That doesn't seem like a fatal objection, especially given the alternative. 

Mick> (2) Removal of the non VLAN mux/demuxed control traffic not only means
Mick> that information that can no longer be shared has to be replicated,

That certainly seems like the lesser of the evils.

Mick> but that  certain items of  information (what is the  maximum possible
Mick> extent of this set of VLANs so that I can simply autoconfigure each to
Mick> the  size  demanded by  external  inputs)  seems  to have  disappeared
Mick> entirely. 

Yes, that would need to be provisioned. 

Mick> One excuse  for the decomposition of  the MAC service into  the set of
Mick> VLAN specific MACs with no  other non-VLAN component is that each VPLS
Mick> will be a 'provisioned service'. 

Yes. 

Mick> At bottom this is simply a  claim that the network provider will never
Mick> ever make a mistake and has a perfectly working service at all times. 

No, but it  does mean that the  OAM model is different, from  layer 3 rather
than  from layer  2.  The  provider will  manage his  network as  a  layer 3
network, not as a layer 2 network.

Mick> If you  think that is  good enough then  you never have to  ship BPDUs
Mick> except when  the input  conditions change, the  far side of  each VPLS
Mick> just manufactures repeat copies at regular intervals 

Actually,  I like  the  idea of  having  the BPDUs  spoofed locally,  driven
perhaps by changes that are learned via network mechanisms.  This might help
with the "bridges are very  susceptible to errors in perceived connectivity"
issue. 

It seems to me  that you've pointed to some issues which  need to be worked,
but if there's a fatal flaw, I  don't see what it is.  But perhaps there are
still some layer 2 issues that I just don't appreciate.

---

From: "Mick Seaman" <[email-masked]>
Date: Thu, 8 May 2003 13:18:59 -0700

The first thing is to appreciate the difference in the models, the second is
to work out what information needs to go where and why. It seems that we
have spent too long in the 'VPLS works like this, so what do I have to send
on each VPLS' mode, and need to get up above that perspective.

Of course the IEEE model doesn't require all provider bridges to be on the
same emulated LAN, only all those that are optimising their control traffic
by sharing its results between them - i.e. just like ordinary LAN. So VPLS's
that are on the *same* underlying connectivity can share that knowledge and
don't have to suffer BPDU sending inefficiency. Having just written this I
now see that it is crucially important to distinguish between "an emulated
LAN" and "a subset of an emulated LAN such that control connectivity can be
shared amongst the VLANs using it", of course the subset is an emulated LAN
in its own right. We don't have this descriptive problem in the IEEE model
(yet) because the name for the subset with identical control connectivity is
"a LAN", a real one with a single MAC and no bridges inside it. This has
probably got to be developed along the lines of investigating how good an
emulation any given emulation is, the past descriptions of "looks like" i.e.
"looks like a LAN", "no, looks like a bridge", "no, looks like a bridge with
LANs around it", "no, looks like a LAN with bridges around it with LANs
around them" doesn't get us very far.

I had started some work on various good wasy to spoof and otherwise optimise
control flows over shaky media, hopefully some time I'll get back to it.

And no I don't think there is a fatal flaw either, just some problems to be
overscoem.

-----Original Message-----
From: Eric Rosen [mailto:[email-masked]]
Sent: Thursday, May 08, 2003 12:16 PM
To: [email-masked]
Cc: 'Pedro Roque Marques'; 'Himanshu Shah'; 'Norman Finn'; 'Muneyoshi
Suzuki'; 'Tony Jeffree'; 'Les Bell'; 'Paul Congdon'; 'Neil Jarvis';
[email-masked]; [email-masked]
Subject: Re: Comments on the L2 VPN framework and solutions documents

Yes.

---

From: Ali Sajassi <[email-masked]>
Date: Thu, 08 May 2003 15:51:46 -0700

>VLANs of that emulated LAN.

That's why we sometimes refer to it during our DT discussion as "emulated 
VLAN" since with respect to the bridge module, the full-mesh of PWs along 
with its VPLS forwarder looks like a VLAN to the bridge module.

>that that does not seem scalable to me.

I think "emulated LAN" is just a matter of perspective. If we look at the 
set of VPLS forwarder along with its associated PWs for a given VPLS 
instance, then that set by itself can be called an "emulated LAN". However, 
if you look at this set with respect to the bridge module, it is just an 
"emulated VLAN".

>still some layer 2 issues that I just don't appreciate.

I think as long as we update the figure 3 and its corresponding text to 
show that an emulated LAN (emulated VLAN) corresponds to a single VPLS 
instance and there can be many of them for the single bridge module of the 
PE, then we should hopefully be all set.

-Ali

---

From: Eric Rosen <[email-masked]>
Date: Fri, 09 May 2003 10:59:20 -0400

Mick> Of course the IEEE model doesn't require all provider bridges to be on
Mick> the  same emulated  LAN,  only  all those  that  are optimising  their
Mick> control traffic by  sharing its results between them  - i.e. just like
Mick> ordinary LAN. So VPLS's that are on the *same* underlying connectivity
Mick> can  share  that knowledge  and  don't  have  to suffer  BPDU  sending
Mick> inefficiency. 

So the difference between  the IEEE model and the FW model  is that the IEEE
model allows this optimization.  But I don't quite understand how to benefit
from this optimization in the  VPLS environment.  A particular set of VPLSes
could only be considered to have the same "underlying connectivity" if it is
known that they  are supported by the same  set of PEs, both now  and in the
future.  I'm not  sure whether this is a common enough  case to worry about,
and  I'm  also  not  sure  how  one would  get  this  information  from  the
auto-discovery provisioning model.

---

From: Matt Squire <[email-masked]>
Date: Tue, 13 May 2003 08:43:36 -0400

> auto-discovery provisioning model. 

The benefit, at least to me, is that everything else can treat the VPLS 
instance as a LAN and doesn't need to be aware.  So provisioning and 
forwarding behavior for bridges doesn't need VPLS awareness.  Otherwise, 
  certain higher level functions have to know that a port is a VPLS port 
or an Ethernet port.

Additionally, it allows arbitrary topologies to be built.  Right now, 
most people are on the direction that there's a single VPLS per customer 
and that it spans edge-to-edge.  And people are complaining about the 
scaleability of that solution.

Back in older days with previous incarnations of emulated LANs, many 
people designed their networks differently.  I recollect some carriers 
building mostly regional emulated LANs, putting multiple customers 
within a region on the same regional VPLS and putting bridges together 
between the regions.

The logic as I recall was that bandwidth within a region was pretty much 
free, but between regions it was real money.  Many customers stayed 
within a single region, which was even better, and multicast/broadcast 
traffic was policed properly.  The specific example I recall was a 
carrier that had 5-10 switches in NY and DC, and they created a single 
emulated LAN instance in NY and DC with VLANs across it, and they had a 
bridge between the two that switched a small number of VLANs between NY 
& DC.  Later, they replaced the emulated LAN with a big honking Ethernet 
switch and everything continued to operate.

Now I'm not promoting this topology over any other.  But ensuring the 
emulated and real technologies are transparent to the higher layer, one 
can build arbitrary networks based on traditional bridging models.  I 
hope thats a good thing.

- Matt

---

From: "Cheng-Yin Lee" <[email-masked]>
Date: Tue, 13 May 2003 15:42:29 -0400

Mick, Matt,

Mick Seaman wrote:
> From the point of
> view of control connectivity the pseudo-wires have to establish a full mesh
> that is never perceived by layer 2 protocols as being less than complete.
How can this "lower layer emulated LAN" (using full mesh split horizon)
be perceived by IEEE L2 as being _never_ less than complete? 

> STP is running across the service that runs on top of the mechanisms that
> make the service LAN like.

Matt Squire wrote:
> But ensuring the
From the architecture point of view, it looks clean to make the lower
layer transparent and to mandate the lower layer should do its job
properly (in this case IEEE 802.1ad assumes PPVPN VPLS always provide a
properly emulated LAN, no configuration loops, connectivity issues,
etc). However, I do not know how loops in the forwarding paths can be
prevented, if a tree is concatenated/spliced with the lower layer
forwarding path (or another tree), unless all common nodes in the
forwarding path (both higher and lower layer) participate in one common
spanning tree or a similar algorithm to prevent forwarding loops.

Thanks
Cheng-Yin

---

From: Matt Squire <[email-masked]>
Date: Wed, 14 May 2003 01:37:20 -0400

> be perceived by IEEE L2 as being _never_ less than complete? 

One has to take precautions/measure to ensure that the virtual port to 
the emulated LAN is operationally down if there is an incomplete mesh 
for that emulated LAN.  There are various ways this could be accomplished.

> spanning tree or a similar algorithm to prevent forwarding loops.

I'm having a hard time parsing that last sentence.  Loops in a VPLS are 
prevented with split horizon, and I'm not sure what tree is being 
spliced/concatenated with what.  But emulated LAN segments would be 
bridged to other emulated or real LAN segments, and if the bridged 
topology is not a tree, then STP has to be used to reduce it to a tree.

- Matt