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

From: Muneyoshi Suzuki <[email-masked]>
Date: Thu, 01 May 2003 18:38:03 +0900 (JST)

Mark,

> For the purposes of what I was inquiry about I don't
> think it makes difference - more interesting in the
> spanning tree processing points you are interested in.
> But, for the sake of argument lets assume it is a
> VLAN-aware Bridge (I realize there are important
> differnces based on installed based interoperability)
> > Otherwise, is it 1982-style Bridge or VLAN-aware
> > Bridge without the Bridge Protocol Entity?
> > In these case, it is not
> > much meaningful to
> > distinguish 2) and 3).
> I was assuming with the Bridge Protocol Entity, in
> which case there would be a difference, I believe. In
> 3) Spanning tree may influence routing within the
> VPLS, whereas it would not in 2) and obviously not in
> 1)

Could you see the attached text that is the latter half of my reply
to Norm. I think there are two xSTP related issues; loop prevention
and cache clear due to customer topology change.

Thanks,

Muneyoshi Suzuki
Nippon Telegraph and Telephone Corp.

------
Anyway, in the following, how to process xSTP is discussed because
most interests relate on it.

(1) The SP must ensure a single tree topology in the SP network. Manual
configuration, provider-STP, and provider-RSTP can support it without
any difficulties. In this process, the SP don't care customer-xSTP, 
because it is the SP's responsibility to ensure a tree topology, thus it 
is determined under the SP's policy and control. It is a quite unrealistic 
scenario that the SP network topology is changed by the customer-xSTP.

(2) It is customer responsibility to ensure a single tree topology in the
customer network which consists of customer sites interconnected by the
SP network and backdoor links. This is because, the customer can cause 
a loop whether the SP forwards customer-xSTP transparently or the SP
provides per-customer xSTP instances. If the customer does no use
xSTP, there is a possibility to cause a loop.

(3) If the SP forwards customer-xSTP transparently, and if the customer 
use customer-xSTP, it can avoid a loop even if it pass through the SP 
network. This is because, the SP ensures a single tree topology and a 
single customer Bridge that supports customer-xSTP in a loop is sufficient 
to detect and cut the loop. 

(4) However, it is highly desired to detect a customer loop in the SP 
network. But, (a) detection is not limited xSTP, another technology
can also detect a loop, (b) provider core Bridges don't need to support 
per-customer xSTP instances, because Provider Edge Bridges that support 
pre-customer xSTP instances are sufficient to detect and cut the loop, 
and (c) the full-mesh scheme also has completely the same issues.

(5) And it is highly desired for the SP network to detect customer network 
topology change and clear the cache for the customer, if the customer use
xSTP and is multihomed. In this case, provider Bridges need to snoop 
customer-xSTP then forwards it transparently. However, both the xSTP based 
SP network and full-mesh scheme have completely the same issues.

---

From: "Mark Seery" <[email-masked]>
Date: Thu, 1 May 2003 11:09:52 -0700

Hi Muneyoshi,

to Norm. I think there are two xSTP related issues; loop prevention
and cache clear due to customer topology change. <<

I'm not sure anything short of a novel can do justice to the issues you
raise, so I am going to raise a few issues for consideration, with hopefully
an appropriate amount of brevity.

With respect to a mechanism to clear cache, this mechanism should probably
be a part of an Ethernet standard regardless of whether Ethernet is being
transported over MPLS or not. There are situations in pure Ethernet networks
where I could see this being useful, so I would suggest this is something
for the IEEE to pursue. I would also add that this raises the question of
whether a formal UNI interface between Ethernet client and server networks
would be useful (I can also see models where the server layer is completely
transparent as being useful too). Don't know to what extend this has been
discussed, in this forum, already.

With respect to loop prevention, VPLS needs to ensure correct routing for a
variety of security reasons. If it can not do this, then the concern you
raise is secondary to this issue. It has been suggested that routing
transients are unavoidable - seems to me all technologies face some outages,
we are just arguing expectations. Additionally, I am not convinced that
forcing the MPLS network to behave in accordance with a IEEE 802.1 spanning
tree, is the only way to solve this problem - perhaps I am misunderstanding
what you suggest? I think you have to examine why you want to use MPLS or IP
as a VPLS infrastructure and then ask yourslef are you getting that benefit
if you impose this kind of behavior on the underlying network.

Some other areas to consider below:

Network Architecture
====================

You have already observed yourself that there are a couple of models
floating around. Some clarity here is useful before getting in to the
details of a solution. As always, perhaps requirements clarification is the
place to start. Personally I am in favor of the model where the VPLS appears
and behaves as a LAN segment with no higher layer Bridge function, purely
MAC relay at best. I come to this conclusion for a variety of reasons, many
too long to discuss in one email, but as the result of concerns in the areas
of network architecture, system architecture, and standards (architecture).

Certainly my mind is oriented to appreciating the value of separate
transport and switching layers. And while I appreciate that taken to extreme
this leads to too many layers in a network, I would also argue you can have
to few layers from the perspectives of organizational efficiency, equipment
issues, and network extensibility.

Network architecture is too large of a subject to discuss in an email, but
would simply be curious to understand the overall goals and perceived
benefits of the network you are pursuing.

System Architecture
===================

While flatenning out networks can be a good thing, the attempt to mash all
layers of a network into one system can have dramatic impacts on the cost
and usefullness of a single system, and ultimatley network architecture
flexibility - a point which seems to recognized in varying degrees by HVPLS,
GVPLS, and DTLS. As you suggest that PEs have a fairly rich level of
Ethernet switching/bridging capability I would suggest that is something you
consider. There maybe otherways to skin the cat.

Standards (Architecture)
========================

IMO, pursuing solutions that requires the least amount of interaction
between two standards bodies is preferrable. Certainly to be avoided is the
situation where one standards body is perceived as making changes to
something that another standards body feels ownership for. There have been
some comments that suggest that IEEE and IETF are in sync, so I won't
challenge that assertion. I will simply observe that the road you are
heading down would seem to, IMO, provide a fertile ground for such issues to
germinate.

In closing I am not one to suggest what technology should or should not be
used as service and transport layers - I think that is completely dependent
on application and the value chain a service provider is pursuing - and the
market should support service providers pursuing different value chains. I
would only suggest that the issues above be examined.

Mark

---

From: Muneyoshi Suzuki <[email-masked]>
Date: Fri, 02 May 2003 17:18:54 +0900 (JST)

Mark,

> for the IEEE to pursue. 

Agreed.

Thanks,

Muneyoshi Suzuki

---

From: Norman Finn <[email-masked]>
Date: Tue, 06 May 2003 15:48:29 -0700

Muneyoshi,

At least on these issues, :) we are in perfect agreement.

-- Norm

---

From: Muneyoshi Suzuki <[email-masked]>
Date: Wed, 07 May 2003 13:51:34 +0900 (JST)

Norm,

> At least on these issues, :) we are in perfect agreement.

Good. :-)

BTW, it seems to me, we are leaved behind from the WG. There are 
little interest in the most important technical issues. ;-)

Thanks,

Muneyoshi Suzuki