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

["Roger Lapuh" <[e-mail]>]

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 <[e-mail]>
Date: Thu, Sep 10, 2009 at 7:45 PM
Subject: Re: [rbridge] Review of
draft-ietf-trill-rbridge-protocol-13.txt
To: Donald Eastlake <[e-mail]>, "Romascanu, Dan (Dan)"
<[e-mail]>, [e-mail]
Cc: ext Bernard Aboba <[e-mail]>, Ralph Droms
<[e-mail]>


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)<[e-mail]> 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
[e-mail]
http://mailman.postel.org/mailman/listinfo/rbridge

_______________________________________________
rbridge mailing list
[e-mail]
http://mailman.postel.org/mailman/listinfo/rbridge