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

From: Joris wils <[email-masked]>
Date: Tue, 22 Apr 2003 08:26:45 -0400

Muneyoshi,

Thank you for your response.  Answers below.

>Joris,

>> Please verify my understanding: are you proposing that vendors add
Bridging
>> to their MPLS devices; Bridging over MPLS as it were, MPLS is the
Transport.
>> correct?  

>Correct.

>> If so, I have noticed, that vendors are quietly adding Bridging to
>> their ATM, Frame and TDM devices as well.  802.1ad could interconnect
all.
>> these devices, regardless of which media they use as the Transport.  

>Exactly.

>> My question is: how do you deal with (portions of) the network, for which
a
>> spanning tree would be a very inefficient forwarding means, because the
>> physical topology does not approximate a tree?

>Could you clarify this? What is spanning tree in the above context?
>802.1D STP, or STP/RSTP/MSTP?

>If you are claiming STP topology change time is inefficient, the use of
>RSTP/MSTP should be considered.

>If you are claiming all STP/RSTP/MSTP are inefficient, could you clarify
>the issues?
Yes, at first approximation, they are efficient in the access & aggregation
portion of a WAN, but inefficient in the core of a WAN.

At first approximation: 
It is my understanding that a wide area network can be roughly divided into
an access & aggregation portion on the one hand and a core on the other,
each with a very different physical topology.  The aggregation portion looks
roughly like a tree with links or rings of increasing bandwidth heading
towards the core.  The core of the WAN, however, is an arbitrary
interconnect of links, which usually bears no resemblance to a tree at all.

So for any given vlan, it works well to rely on *STP in the aggregation
portion, because the spanning tree will closely match the aggregation tree,
so that no or few useful links have to go into blocking. In the core of the
network, however, the spanning tree does not match the physical topology, so
many possibly useful links to the vlan would have to be placed into
blocking.  So, you can say that *STP makes efficient use of the WAN
bandwidth and links in the aggregation portion, but inefficient use in the
core portion.

MSTP is only a partial solution, because it does not provide efficient use
of available bandwidth and links for any individual VLAN.  VPLS, on the
other hand, can provide efficient use of available bandwidth, as long as the
number of split-horizon bridges is kept low enough to constrain broadcast,
control plane and reliability inefficiences.

So I have been an proponent of Norm Finn's approach in which a handful of
Spanning Tree islands per vlan are interconnected by an Inter-Island Trunk
provided by Ethernet Emulation using VPLS.  I just think it is important to
realize that these Spanning Tree islands will exist in the Aggregation
portions of WAN and thus be largely constructed out of Provider Bridges,
which are doing Bridging over Point-to-point media, such as MPLS, ATM, TDM,
Frame or L2TP.

At second approximation:
Things may not be as bad as they seem above, if we consider the following:
a) Many existing applications, which provide MAN/WAN based multipoint
bridging (emulation) services are small and limited to the aggregation
portions of the WAN cloud anyway.  Thus, you could rely on *STP completely,
because you can usually construct a spanning tree, which makes efficient use
of the physical tree.

b) Some applications, which do cross the core of the WAN, do so in such
limited fashion, that a spanning tree can again be constructed, which makes
efficient use of available interconnect and puts no or few useful links into
blocking.

>Thanks,

>Muneyoshi Suzuki
>Nippon Telegraph and Telephone Corp.

Thanks,

Joris Wils 
Consulting SW Engineer
Coriolis Networks
[email-masked]/978-264-1904x667

---

From: Muneyoshi Suzuki <[email-masked]>
Date: Wed, 23 Apr 2003 14:12:32 +0900 (JST)

Joris,

Thanks for clarification.

First, needless to say, I aware link block problem of STP/RSTP. We 
definitely need a solution. However, the solution must be robust.
To enable large scale deployment, it must not force the operators 
and users to reboot boxes even if the worst case. The full mesh 
approach is a fragility solution that has loop, blackhole or unreliable 
flaky PEs problems, so we have no choice other than the conventional scheme.

Second, if we regard xSTP as routing protocols, obviously there are less 
efficient than OSPF/BGP. However, if we regard xSTP as protocols for 
protection, these are not bad. If we reserve paths for fast protection 
for the mesh, there are active and standby meshes. I think this problem
is not much different form xSTP link block problem.

Finally, as far as I know, currently providers don't use STP due to long 
recovery time; instead manually configure a single tree topology. However, 
a single tree topology is not bad. Please image conventional telephone 
network architecture; it is a tree. A tree is one of fundamental network 
architecture. However, needless to say, topology free is much better than
a tree. Therefore, I proposed OSPF or BGP-4 extension for MAC routing
in Atlanta meeting (please see my slides in the last November). I think
it is not easy to progress this work in the IETF, but I believe we need
this kind of work in the near future.

Thanks,

Muneyoshi Suzuki

---

From: Sukanta ganguly <[email-masked]>
Date: Wed, 23 Apr 2003 12:32:58 -0700 (PDT)

Hi,
  Just curious as to why you specified that "this kind
of work can't be progressed in the IETF" ?
  
Thanks
SG

--- Muneyoshi Suzuki <[email-masked]>
> Nippon Telegraph and Telephone Corp.

__________________________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo
http://search.yahoo.com

---

From: Muneyoshi Suzuki <[email-masked]>
Date: Thu, 24 Apr 2003 11:20:37 +0900 (JST)

Sukanta,

> of work can't be progressed in the IETF" ?

I did not say "can't" but think it is difficult, because, obviously it is
out scope of the PPVPN WG charter. In my understanding, we need BOF
to progress this kind of work. However, this proposal use IP routing 
protocol as technology but target is MAC frame routing. Is this in scope
of the IETF? I think it is gray.

 From a technical view point, it is clear from the standard, MAC frame
forwarding permits tentative out-sequence delivery, but loop is prohibited
even if it is tentative. However, it is too difficult for current IP 
routing protocols to ensure loop free operation. So, a TTL field is
indispensable in MAC frame, but it does not have the TTL. Therefore, 
this technology can't support current MAC frame; but it may be applicable
Q-in-Q or MAC-in-MAC that have the TTL field. I think this is an allowable
restriction, but this work can not be accomplished the IETF alone,
co-operation with IEEE 801 is indispensable.

If someone is interested in this work, please contact me. If there are
sufficient interests, I will ask BOF to the IESG.

Thanks,

Muneyoshi Suzuki

---

From: "Vach Kompella" <[email-masked]>
Date: Wed, 23 Apr 2003 21:09:53 -0700

Hi Muneyoshi,

> co-operation with IEEE 801 is indispensable.

Yes, defining a TTL in the MAC frame is out of scope for the IETF.  If the IEEE
is going to define something like this, and we want an L2 solution for the
provider network, then we will work with the IEEE.

Is something about the fact that we want to work with the IEEE 802.1ad wg
bothering you?  Is it insufficient?  Do we need to work with some other group?

> sufficient interests, I will ask BOF to the IESG.

Why do we need a new working group?  Why can't it be done here in the ppvpn WG?
Or perhaps in the PWE3 WG?

> Thanks,

Thanks.

---

From: Muneyoshi Suzuki <[email-masked]>
Date: Fri, 25 Apr 2003 16:48:31 +0900 (JST)

Vach,

> bothering you?  Is it insufficient?  Do we need to work with some other group?

No. I don't have any political obstacles, but I think significant interest
is needed to propose this kind of work.

However, I think it is a good idea to lobby 802.1WG to reserve one octet
for the TTL in 802.1AD frame format.

Thanks,

Muneyoshi Suzuki

---

From: Norman Finn <[email-masked]>
Date: Fri, 25 Apr 2003 09:30:58 -0700

Muneyoshi,

I think that adding a TTL field to the MAC frame is an attractive
idea.  I also think that it is an extraordinarily bad idea.  If I
may paraphrase your argument, it is:  (Forgive me, please, for putting
words in your mouth.)

 1. Routing is not reliable enough to establish the connections
    that we need.  Bridge A might be able to talk to Bridge B, but
    not to Bridge C.

 2. Spanning trees and full meshes, which don't require TTL, are
    not good enough, for the reasons thoroughly discussed.  (By
    the way, I very much agree with you that, for large N, a full
    mesh will not be reliable.  My solution is to keep N fairly
    small.)

 3. Therefore, we'll add TTL and use OSPF to route the MAC frames.

What I don't understand is how you have solved the problem that
Bridge A could not talk to Bridge C!  Why is your toy routing system
going to be any more robust than the existing routing system?

This approach is not flawed because it is reinventing bridging.  It
is flawed because it is reinventing routing.

-- Norm