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

From: "Himanshu Shah" <[email-masked]>
Date: Thu, 8 May 2003 17:46:55 -0400

I understand this approach. Its a simple approach.
And if you want to run M-STP (1 instance) across PWs
you may want to use this approach.

However, the VPLS drafts in IETF explicitly
talks about not having to run the P-STP across PWs.
Dual-homing/external loop in Provider's network
is handled without using P-STP.

There seems to be some disconnect in understanding 
between these two groups that needs to be worked
out.

/himanshu

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

Himanshu,

In (1) I think you have your layering a little mixed up. 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. STP is running across the service that runs on top of the mechanisms that make the service LAN like. If you wish to provide subset LANs to be configured then of course you can have subsets each of which has full connectivity in itself. Just never try to pretend to layer 2 that two non equal subsets are the same LAN.

In (2) I think you are further into the same pit.

It is trivial to get into BPDU scaleability issues along the path you suggest. A much more attractive alternative is to maintain a single full mesh for control connectivity which then prunes that mesh per VPLS (each VPLS doesn't have to touch certain mesh nodes) and then uses that pruning to delete VPLS specific pseudowires to the unwanted mesh nodes. Only one instance of the topology determining protocol and the pruning protocol are then required for all VPLSs. The trick here is to put provider provisioning in at the right level in the architecture (i.e. not at the pseudowire level,but higher up so that it can drive the pseudowire level in the context of the actually available resources).

Mick

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

This digresses from earlier thinking (at least mine) 
that P-STP would not span across pseudowires.

There are several implications to running STP
across PWs that may need to be clarified/worked out.

1) "fully-meshed" attribute of the PWs only applied
   within a context of a VPLS instance. That is, if
   PE1 and PE2 participated in VPLS instance 1 than
   there was no pseudowire to PE3 which did not
   participate in VPLS instance 1. However, with this
   scheme, each PE would have pseudowire to every
   other VPLS capable PE irrespective of its VPLS
   instance membership

2) Assuming that 1 MSTP instance covers entire provider's
   network, a backdoor link from ProvBridge1 to ProvBridge2
   of VPLS instance 1, may cause 802.1ad's emulated LAN ports
   to all VPLS instances (i.e. all PWs from that PE are
   in blocked state irrespective of its VPLS instance
   membership). Doesn't this block other VPLS instances's
   traffic across PWs?

   Perhaps my assumption is wrong and there is in fact
   P-STP instance for each VPLS instance. However, if that
   is true, PE would run into BPDU scalability issues.

/himanshu

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

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,

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: Thu, 8 May 2003 15:32:17 -0700

Himanshu,

If the VPLS drafts have not changed significantly in their intent (I don't
think they have) there is not a disconnect here. There is a difference
between running spanning tree to cut PWs and reduce their topology to that
of a spanning tree (which is what the VPLS folks were correctly rejecting)
and conveying spanning tree BPDUs across the emulated LAN formed by PWs so
that bridge ports attaching to that emulate LAN service can have the right
state, including the 'LAN' or not in the active topology/topologies for
VLANs. Again it is neccessary to get the layering straight, focusing on
which wire a BPDU goes down before the layering is straight really doesn't
help.

Mick

-----Original Message-----
From: Himanshu Shah [mailto:[email-masked]]
Sent: Thursday, May 08, 2003 2:47 PM
To: [email-masked]; Norman Finn; Muneyoshi Suzuki; Tony Jeffree;

/himanshu

-----Original Message-----
From: Mick Seaman [mailto:[email-masked]]
Sent: Wednesday, May 07, 2003 6:42 PM
To: Himanshu Shah; 'Norman Finn'; 'Muneyoshi Suzuki'; 'Tony Jeffree';

Himanshu,

In (1) I think you have your layering a little mixed up. 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.
STP is running across the service that runs on top of the mechanisms that
make the service LAN like. If you wish to provide subset LANs to be
configured then of course you can have subsets each of which has full
connectivity in itself. Just never try to pretend to layer 2 that two non
equal subsets are the same LAN.

It is trivial to get into BPDU scaleability issues along the path you
suggest. A much more attractive alternative is to maintain a single full
mesh for control connectivity which then prunes that mesh per VPLS (each
VPLS doesn't have to touch certain mesh nodes) and then uses that pruning to
delete VPLS specific pseudowires to the unwanted mesh nodes. Only one
instance of the topology determining protocol and the pruning protocol are
then required for all VPLSs. The trick here is to put provider provisioning
in at the right level in the architecture (i.e. not at the pseudowire
level,but higher up so that it can drive the pseudowire level in the context
of the actually available resources).

Mick

-----Original Message-----
From: Himanshu Shah [mailto:[email-masked]]
Sent: Wednesday, May 07, 2003 10:29 AM
To: [email-masked]; Norman Finn; Muneyoshi Suzuki; Tony Jeffree;

/himanshu

-----Original Message-----
From: Mick Seaman [mailto:[email-masked]]
Sent: Wednesday, May 07, 2003 10:42 AM
To: Himanshu Shah; 'Norman Finn'; 'Muneyoshi Suzuki'; 'Tony Jeffree';

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;

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