Subject: [rbridge] Review of draft-ietf-trill-rbridge-protocol-13.txt

From: "Roger Lapuh" <[email-masked]>
Date: Mon, 14 Sep 2009 22:04:45 +0100

Hi Don (Eastlake)

I know you were not trying to imply this, but I got the impression from
your comments that others might infer that the current link-state based
IEEE 802.1 project could take a long time and will not see any market
validation soon. Thus I wanted to point out that a pre-standard version
of 802.1aq (SPBm) has been shipping and is generally available since
2008 and is deployed in several carrier - as well as enterprise customer
(data center) networks. It has been proven to be a scalable and robust
solution with great potentials to extend beyond L2 virtualization. With
that in mind there are several vendors implementing it as well.

For broad market adoption, it makes sense for any new link-state
Ethernet approach to provide maximum interoperability with existing IEEE
standards.

Also, while going through the TRILL draft I was wondering how well you
perceive end-stations and applications will handle the out-of-ordered
(Unicast) packets that you point out within the TRILL design in section
4.5 page 48? 

regards,

Roger

Nortel

---------- Forwarded message ----------
From: FEDYK Don <[email-masked]>
Date: Thu, Sep 10, 2009 at 7:45 PM
Subject: Re: [rbridge] Review of
draft-ietf-trill-rbridge-protocol-13.txt
To: Donald Eastlake <[email-masked]>, "Romascanu, Dan (Dan)"
<[email-masked]>, [email-masked]
Cc: ext Bernard Aboba <[email-masked]>, Ralph Droms
<[email-masked]>

Hi Donald

I too would like to commend Dan for his careful and comprehensive
feedback.
But I have a few corrections to your comments. Inline:

> -----Original Message-----
>
> Hi Dan,
>
> Thanks for your efforts in providing these detailed comments.
>
> On Sun, Aug 30, 2009 at 8:41 AM, Romascanu, Dan
> (Dan)<[email-masked]> wrote:
> > I was asked by the TRILL WG chairs to perform a review of
> > draft-ietf-trill-rbridge-protocol-13.txt. Below please find
> my findings.
> >
> > I appreciate the work put by the editors and WG in designing this
> > solution and writing the document. The editors are to be
> saluted for
> > writing an I-D which is in most parts clear and well organized.
> >
> > I do believe that this work and the document as it stands
> still have a
> > number of problems that need to be solved.
> >
> > 1. I have serious reservations that this document can
> directly go to
> > Proposed Standard. For reasons detailed below there is a lot of
> > incertitude in what concerns the interoperability or
> coexistence with
> > the layer 2 protocols designed in the IEEE. Many of these are still
> > work in progress. For this good reason in many places the
> document is
> > forced to make assumptions and cannot make but statements like
> > 'Rbridges are generally compatible with IEEE ...' (section
> 2.4.2). Has
> > the WG discussed the option of issuing the first version of this
> > document as Experimental?
>
> It is true that many IEEE 802.1 standards efforts are "work
> in progress". But with the ever multiplying number of efforts
> in 802.1, this situation seems permanent. To wait for 802.1
> standards efforts to end would be to wait forever.

This is not an accurate representation of the work in 802.1.  Several
projects have completed this year. The 802.1 Working group has
considerable scope.

>
> There is no actual question concerning the interoperability
> of TRILL with current 802.1 protocols.
>

That is not the way I read the liaison referenced at the end of this
message.

> Section 2 of the draft is a broad overview. That is the
> reason it says "... RBridges are generally compatible with
> IEEE [802.1Q-2005] customer bridges ..." in Section 2.4.2. If
> all the details were given in Section 2, it wouldn't be a
> broad introductory overview. To avoid misleading readers,
> that phrase should probably be changed to "... RBridges are
> compatible with IEEE [802.1Q-2005] customer bridges except as
> discussed in this document ...".
>
> I cannot recall any status other than Proposed Standard ever
> being suggested in the TRILL working group for this document.
> The TRILL protocol has had more review by routing and
> bridging network experts than most IETF protocols at the
> Proposed Standard level.

How can you substantiate that comment?  Trill was one of the smaller
Groups that I have attended. It was not scheduled in the Routing area at
all.  Certainly some routing experts reviewed Trill.  But many I know
were reviewing the use of IS-IS by Trill and not evaluating Trill.

> TRILL has been implemented in
> software, tested, and the results of that testing included
> back in the protocol design. Multiple vendors are very
> interested in TRILL and I predict that RBridge products will
> ship in 2010.
>
> > 2. It looks to me like the motivation of the standard is frozen in
> > time into a period of evolution of the IEEE 802.1
> technology trying to
> > solve some problems that were in part dealt with by the
> IEEE in the meantime.
> > Out of the four spanning tree bullets listed in the introduction as
> > problems that TRILL solves the second and the fourth seem
> to have been
> > dealt with by the IEEE 802.1aq and the IEEE 802.1ak respectively.
>
> It appears to me that this comment does not suggest any
> changes in the draft. But, as a response, the TRILL WG was
> created by the IETF to produce a standard subsequent to
> substantial discussion of the fact that, after it rejected
> TRILL technology, IEEE 802.1 then started an effort with
> similar goals. (And after the IEEE 802 Executive Committee
> stated that it had no objection to the IETF pursuing
> development of a TRILL standard.)

Trill was created by individuals in the IETF that had goals that were
different than IEEE 802.1. IEEE is a an open standards body just like
the IETF.  We are open to good ideas on control planes and shortest path
tree computation. But we work on bridging data plane and the properties
and tools of that data plane.  The Trill data plan is not Ethernet and
it is not IP either.  So Trill is different.

>
> > 3. All the VLAN discussions in the specification mention only the
> > C-VLANs. What about provider bridges? Can these be migrated
> to Rbridges?
> > The explanation in Appendix E is not sufficient, the compatibility
> > with provider bridges needs to be dealt in the core part of the I-D.
>
> The TRILL protocol specified in this draft is, as stated in
> the draft, a customer bridge standard. The draft is careful
> to refer to
> 802.1Q-2005 all over the place. An IEEE 802.1Q-2005 bridge is
> a purely customer bridge.
>
> This TRILL protocol specification does not try to solve the
> provider bridge problem. (I believe it would be relatively
> easy to extend TRILL to do that but it should be done in a
> separate document.)  Provider bridges (and provider backbone
> bridges) cannot be replace by customer bridges, whether those
> customer bridges are 802.1 customer bridges or RBridges based
> on this spec. On the other hand, as stated in Appendix E,
> provider bridges (and/or provider backbone bridges) can be
> used to transparently interconnect parts of an RBridge campus.
>
> Since RBridges are compatible with provider bridges and
> provider backbone bridges, as I understand the word
> compatible, I don't understand what there is to "deal" with.
> However, an appropriately reworded version of the paragraph
> just above this paragraph can certainly be added to the main
> body of the draft.
>
> > 4. There needs to be more discussion about the IEEE
> protocols that do
> > not define forwarding or tagging. If TRILL makes a claim
> that the best
> > migration policy is to replace IEEE bridges by Rbridges it needs to
> > define behavior relative to protocols like IEEE 802.1AE
> Media Access
> > Control (MAC) Security, IEEE 802.1AB Station and Media
> Access Control
> > Connectivity Discovery, and IEEE 802.1aj Two Port Media Relay, as
> > bridges and end stations that are being replaced may
> support any or a
> > combination of these.
>
> This document does not claim that the best migration policy
> is incremental replacement, just that a network of
> 802.1Q-2005 customer bridges will, with the differences
> described in the document, operate correctly if some or all
> are replaced by RBridges.
>
> 802.1 protocols such as 802.1AE, 802.1AB, and 802.1X and
> 802.3 protocols such as Link Aggregation are logically
> implemented within ports. It makes no difference whether
> those ports are ports on 802.1D or 802.1Q or RBridge or IP
> router devices. (And, assuming they continue to develop in
> the direction it appears they are going, this will also be
> true of 802.1Qaz and 802.1Qbb.) This layering is covered in
> overview Section 2.4.1 and in more detail in Section 4.9.2 of
> the draft. As far as I can see, the draft makes RBridge
> "behavior relative to" this type of protocol, which is that
> they are orthogonal, clear.
>
> It would be true that if someone is incrementally replacing
> 802.1Q-2005 bridges that are using one or more of these, for
> want of a better term, "port level" protocols, such as
> 802.1AE, with RBridges, then obviously they need to use
> RBridges that also have the same port level protocols
> configured the same way. A statement to that effect could be
> added to the draft.
>
> 802.1aj is a work in progress.  Although referred to as a
> "type of bridge", as currently specified 802.1aj devices are,
> as far as I can tell, a fancy type of repeater. For example,
> to quote from 802.1aj Draft D4.0, "A MAC Relay is transparent
> to all frame-based media independent protocols except those
> explicitly addressed to this device." (Of course, 802.1aj
> repeaters have a management interface and any node, whether a
> bridge or end station, could have independent functionality
> added to it to interact with that management interface, but I
> don't think of that as a change in the bridge or end station
> functionality.) A statement could be added to the draft
> saying "RBridges are compatible with IEEE 802.1aj devices as
> currently specified, in the same sense that IEEE 802.1Q-2005
> bridges are compatible with such devices." or the like.
>
> > 5. For all the reasons above I think it is required that
> this document
> > is also reviewed in detail by IEEE 802.1. I suggest that a formal
> > review be required via a liaison letter before or during
> IETF Last Call.
>
> A review by IEEE 802.1 has been done. The TRILL draft has
> been modified based on that review (see item 2 of "Changes
> from -12 to -13"
> in Appendix Z).

As one who participated in the Review we only reviewed the documents
with respect to the IEEE 802.1 sections of the document. The IEEE did
not comment on Trill anymore than it would comment on say Fiber Channel
or IP.
The review is public for everyone to read right here.
http://www.ieee802.org/1/files/public/docs2009/liaison-to-trill-wg-0309.
pdf
<http://www.ieee802.org/1/files/public/docs2009/liaison-to-trill-wg-0309
.%0Apdf> 

Regards,
Don

<snip>

_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Caitlin Bestler <[email-masked]>
Date: Mon, 14 Sep 2009 21:23:14 -0700

Roger Lapuh wrote:
> your comments that others might infer that the current link-state 
> based  IEEE 802.1 project could take a long time and will not see any 
> market validation soon. Thus I wanted to point out that a pre-standard 
> version of 802.1aq (SPBm) has been shipping and is generally available 
> since 2008 and is deployed in several carrier - as well as enterprise 
> customer (data center) networks. It has been proven to be a scalable and 
> robust solution with great potentials to extend beyond L2 
> virtualization. With that in mind there are several vendors implementing 
> it as well.
> 

There are two major points that need to be made in regard to 802.1 
projects as they relate to Trill/RBridges.

First, 802.1 will always have work in progress. This is not some sort
of slam that implies 802.1 cannot finish things, but rather a
recognition that one of 802.1 strengths is that it continually evolves.
802.1 networking will not stabilize until it has been obsolete for
several years. Deployed RBRidges will of course have to track these
changes, but only because they almost certainly *include* an 802.1Q
Bridge. Layering is nice, but extra boxes take space and power.

But by positioning TRILL as an EISS client (with some minor ISS client
usage as noted) insulates TRILL from 802.1 protocol evolution, and
provides clear guidance on how to deal with each new evolution in
the protocol -- because new 802.1 protocols seldom disturb the EISS 
interface and would be very explicit about how to deal with 
compatability if a new extension to the EISS interface was
required.

Second, Shortest Path Briding may address some of the same problem-space
as TRILL, but it takes a distinctly different solution. SPB, like most
current work in 802.1, is based upon creating "clouds" with special
characteristics out of a set of 802.1 Bridges that are directly
connected with each other. Essentially any new feature grows out
from a core.

TRILL, by contrast can be deployed from the edges. It does not care
what type of 802.1 Bridges provide connectivity between RBridges, just
that the connectivity exists. A SPB-cloud, however, requires an unbroken
chain of SPB Bridges.

This distinction alone, in my opinion, justifies keeping TRILL as a
distinct solution whatever the state of deployment of SPB or SPBB is.
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Radia Perlman <[email-masked]>
Date: Tue, 15 Sep 2009 14:54:27 -0700

To reinforce what Caitlin said, TRILL is layered above 802, and as such 
it's similar to IP in both its
interaction with Ethernet and its independence from it. TRILL devices 
are, as Caitlin said,
like endnodes to layer 2.  There might be new features (such as congestion
feedback) that would be useful to exploit.  There are sometimes subtle 
issues in adjacent layers
that should be thought through (e.g., VRRP moving a MAC address around), 
so it's really good
to have experts checking out if there are any subtle issues. And TRILL 
has uncovered some (like
the need to consider what VLAN tag(s) to use in IS-IS Hellos, and to be 
defensive against
VLAN translation). But if there really were any work going on in IEEE 
that would break TRILL,
it would also likely break many other IETF protocols as well.

Radia

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 16 Sep 2009 22:44:52 -0400

On Mon, Sep 14, 2009 at 5:04 PM, Roger Lapuh <[email-masked]> wrote:
> Hi Don (Eastlake)
>
> I know you were not trying to imply this, but I got the impression from your
> comments that others might infer that the current link-state based  IEEE
> 802.1 project could take a long time ...

I'm sorry if my remarks were not clear. I did not mean to say anything
about the length of time it takes to complete standards efforts in
IEEE 802.1. In fact, as far as I can tell, there are roughly equal
complaints in the IETF and in IEEE 802 that standards efforts take too
long. My point was that, as Caitlin said, if you were to wait until
all current 802.1 efforts that might in some way bear on TRILL were
completed, you would find that additional 802.1 efforts of that type
had been started in the mean time. And if you were to then wait for
those to be completed, you would find that yet other new 802.1 efforts
of that type had been started. And so on. So, as I said, "to wait for
802.1 standards efforts to end", meaning to wait until there are no
802.1 standards activities in process, "would be to wait forever."

In any evert, given that TRILL is layered above 802.1, it is mostly
independent of IEEE. if there were problems with future IEEE work,
then it is likely that all the IP protocols would be impacted.

>...
> (Unicast) packets that you point out within the TRILL design in section 4.5
> page 48?

That seems like an odd question. If you have applications where such
occasional out-of-order unicast frames were a problem you would
configure your RBridge campus so as to make sure they were of
extremely low probability. For example by calculating a distribution
tree per RBridge or configuring addresses to eliminate unknown unicast
frames for connected end-stations or other techniques. In fact, a few
words should probably be added to the draft about this.

Thanks,
Donald