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

From: Norman Finn <[email-masked]>
Date: Tue, 06 May 2003 17:13:41 -0700

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: Tue, 6 May 2003 21:15:54 -0700

In as much as I will ever wholly agree with Norm, I do so now.

Mick

-----Original Message-----
From: Norman Finn [mailto:[email-masked]]
Sent: Tuesday, May 06, 2003 5: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,

-- Norm

---

From: Eric Rosen <[email-masked]>
Date: Wed, 07 May 2003 11:25:52 -0400

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

Well, the  model in the FW  doc was developed as  the result of  a very long
and iterative conversation  in which I was desperately  trying to figure out
what the  IEEE guys were  talking about.  So  if it doesn't match  what IEEE
might expect, the  difference might be substantive, or it might  be due to a
misunderstanding; the first thing to do is to try to figure out which is the
case.  

Frankly, when I look at the diagram in  the FW doc and I look at Norm's doc,
I don't see what the substantive  difference is. Maybe the problem is that I
don't  understand  the difference  between  the  two  models Norm  describes
above. 

Can  anyone explain,  in  practical  terms, what  the  difference is?   Will
bridges built  to one  model do anything  differently than bridges  built to
another?  Or more  to the point, is there some  issue which prevents bridges
built to the IEEE model from  correctly implementing the VPLS model which is
in the framework document?

---

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

>misunderstanding; the first thing to do is to try to figure out which is the

With a slight modification of figure 3 in L2 FW, we can make it consistent 
with IEEE spec. Basically, we need to show multiple instances of VPLS 
forwarder along with its PWs - one such set for each VPLS instance and one 
such set corresponding to an Emulated VLAN wrt PE bridge module. All these 
emulated VLANs feed into a single bridge module and thus the text should be 
modified accordingly. If more details are needed, then one can expand the 
figure 3 to the one that Norm included in his earlier email.

-Ali

---

From: Muneyoshi Suzuki <[email-masked]>
Date: Tue, 13 May 2003 15:35:07 +0900 (JST)

Norm,

> and has received a lot of support.

I carefully red this thread in this week, but I'm increasingly confused.

I think intention of Eric's model shown in the below is that the 
Interface means a MSAP and the VPLS Forwarder provides an logical entity 
that is compatible with a MAC entity. This is very clear architecture 
for me, while it has loop/blackhole or flaky PEs problems.

>           |      |     |     |  
>           |      |     |     |       
>       |---|------|-----|-----|----|  
>       |  -|------|-----|-----|--- |  
>       |       VPLS Forwarder      |    == MAC entity
>       |  ----------|------------- |  
>     ..|..............................  MSAP
>       |            | Interface    | 
>       |  ----------|------------  |  
>       |  |       Bridge        |  |
>       |  -|--------|---------|--  | 
>       |---|--------|---------|----|
>           |        |         | 
>           |        | Access  | 
>           |        | Networks| 
   
Regarding your reply, I understand that the point "A" in the following 
model means a MSAP. However, I'm not sure what the right part is. 
Could you clarify the following points?

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

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

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

Thanks,

Muneyoshi Suzuki
Nippon Telegraph and Telephone Corp.