Eric, Inline > -----Original Message----- > From: Eric Gray (LO/EUS) [mailto:eric.gray@xxxxxxxxxxxx] > Sent: Tuesday, March 20, 2007 11:31 AM > To: Silvano Gai; ietf@xxxxxxxx > Cc: rbridge@xxxxxxxxxx > Subject: RE: [rbridge] Last Call: draft-ietf-trill-routing-reqs > (TRILLRoutingRequirements in Support of RBridges) to Informational RFC > > Silvano, > > Thanks for posting these comments. Please see below. > > -- > Eric Gray > Principal Engineer > Ericsson > > > -----Original Message----- > > From: rbridge-bounces@xxxxxxxxxx > > [mailto:rbridge-bounces@xxxxxxxxxx] On Behalf Of Silvano Gai > > Sent: Tuesday, March 20, 2007 12:35 PM > > To: ietf@xxxxxxxx > > Cc: rbridge@xxxxxxxxxx > > Subject: Re: [rbridge] Last Call: > > draft-ietf-trill-routing-reqs (TRILLRoutingRequirements in > > Support of RBridges) to Informational RFC > > > > > > This document has some issues that need to be corrected before it can > > pass an IESG last call. > > I think as a strict matter of process, we don't get to say what MUST be > corrected before a document can pass IESG last call (if there is such a > thing). > > Luckily, I believe this is an IETF Last Call, where the idea is that the > IESG is asking for our input before making _their_ decision as to what - > if anything - MUST be changed. > > > > > In order of importance: > > 1) The document equates Ethernet with IEEE 802 and this is clearly > > incorrect, since IEEE 802 includes also technologies like Token Ring, > > DQDB, Wireless that are clearly outside the scope of TRILL. Ethernet > > must be equated with IEEE 802.3 > > Which is historically at least as incorrect. > > This comment was made during the working group last call. Specific > changes were made that I hoped would address this comment. I made many comments to this document during working group last call, some were considered, some were ignored. There was not a second WG last call, the IESG last call was posted and I repeated the comments that were not addressed and that I think need to be addressed. I may have used slightly different words in the two postings. > > Why did you not earlier state specifically what part of the changes > made were not satisfactory to you at that time? > I stated very clear that IEEE 802 is a larger project that includes not only Ethernet, but Token Ring, Token Bus, DQDB, Wireless, etc. Ethernet is specified in IEEE 802.3. Since you and I continue to disagree and you don't accept to replace IEEE 802 with IEEE 802.3 I think this should be judged by an IEEE expert in the IESG. > > > > 2) The document discusses Spanning Tree compatibility in section 1.2 > > where it claims that BPDUs must be terminated and in Section 4.1 where > > the term "block" is used. This is clearly in contrast with what > > discussed in the WG and in the base protocol spec, where BPDUs are at > > least processed (in one proposal) or even sourced by RBridges (in an > > alternate proposal). > > This was the terminology decided on by the working group at the time. > > This comment was also made during the working group last call, and > explanations were provided and - I believe - some small explanatory > changes were made to the text. > > Again, why did you not earlier state specifically what part of the > changes made were not satisfactory to you at that time? > I stated at that time that this text was inappropriate and the base protocol draft contains text agreed in the WG that contradict your view. > > > > 3) Section 1.1 Terminology is formally incorrect since [TARCH] is not > an > > approved document. It is also substantially incorrect since many terms > > listed are not used in this document and some are not agreed in the > WG. > > I propose to eliminate this section. > > As a matter of process, again, this issue is addressed by listing the > Architecture as a Normative reference. > > Because the document is intended to be an informational RFC, the WG > chairs informed me that IESG members are comfortable with pushing this > to IETF last call ahead of its (one) normative reference. > > That, again, is their prerogative. > > > > > 4) The document uses the term "will" that is not compliant with > RFC2119. > > In general a better definition of what is mandatory and what is > optional > > is important in a requirement document. > > This is an informational document, proposed as an informational RFC. > > This is also a requirements document, stating what is needed from any > candidate routing protocol. It is not an options list, or a wish list. > People may decide to ignore requirements in this document, and that is > okay - because it is strictly informational. The requirements listed > in this document represent the things that the TRILL working group had > agreed were needed and should be documented at the time the document > was/is/will be published. > > The choice to avoid 2119 language was - for this reason - a deliberate > one, discussed on several occasions in the working group. There is no > inclusion of the "usage" of RFC 2119 terminology, nor any reference to > RFC 2119. Hence the word "will" can be, and is, used as it would be > interpreted in the English language. > > If you would care to provide a reasonably authoritative reference for > English usage of the word "will" that is in conflict with any specific > usage of the word in this document, I'd be happy to consider including > it as a reference in this document and changing the specific instances > you point out. > > > > > 5) Introduction - Bridging limitation. The first paragraph refers to > > Ethernet networks used without Spanning Tree. This is irrelevant, > > since Spanning Tree is always deployed in conjunction with Ethernet. > > This follows only because: > > o you disagree with the inclusive way this document uses the term > Ethernet. Let's not conflate issues here. > > The way the document uses the term Ethernet was explained to you > > - and to the working group - as a result of your earlier working > > group last call comments. > > o you exclude Ethernet deployments in small networks where small > Ethernet switches _clearly_ do not use spanning tree. > > o you exclude Ethernet, and Ethernet-like, encapsulation in new, > in progress, and yet to be developed technologies in making > this statement. > > In short, your statement that spanning tree is always used in Ethernet > networks is correct only if you define Ethernet networks as including > spanning tree. Interestingly enough, I do not recall that spanning > tree is actually defined by 802.3. > That is because the work that TRILL does is really an IEEE 802.1 replacement, but still DOES NOT cover IEEE 802 as a whole. > There was not at the time of the working group last call, nor have > I seen any indication that there is now, a consensus to change the > wording of this document with respect to this issue. > > My earlier justification that using a less inclusive interpretation > of "Ethernet" would mean replacing the term Ethernet with a more > explicitly inclusive (and complex) phrase in each place where it > occurs, still applies. > > > The correct contrast must be between Ethernet with Spanning Tree and > > Ethernet with TRILL. > > This only follows if you assume that the way that Ethernet is used > in this document is wrong. > > A point has been made - more than once - that there is no absolutely > cannonical definition of Ethernet. Not True. Ethernet is commonly defined as: Digital Equipment Corporation, Intel, Xerox, The Ethernet, Version 2.0, November 1982. This document and the term "Ethernet" are widely referenced in IEEE 802.3 (just do a search on the PDF file). In particular TRILL uses the Ethernet V2 encapsulation (the same used by IEEE 802.1Q) in which Length is replaced by Type. Please see IEEE 802.3 standard. You might choose to decide that > Ethernet is defined by 802.3 - in spite of the fact that Ethernet and > 802.3 have been considered by many to be distinct for many years. If > you do, then you would be limiting the definition to exclude how the > technology works with bridges, I never said that bridges are IEEE 802.3, Bridges are a combination of IEEE 802.1D and IEEE 802.1Q. -- Silvano and you would be forcing arbitrarily > complicated verbiage in what is essentially a relatively high-level > document that doesn't need that degree of technical precision. And > you would still be wrong by some (other) definitions of Ethernet. > > > The claim of a single broadcast/flooding domain is incorrect since > > VLANs have solved this issue many years ago. > > For the purposes of this document, it is not explicitly necessary - > nor necessarily even a good idea - to dwell in too great detail on > the ways that a domain that would be "a single broadcast/flooding > domain" in the absence of VLANs, becomes multiply sub-setted by the > inclusions of VLANs. > > I do not recall seeing this comment during the working group last > call. If I had, one of the things I would have pointed out is that > this is not explicitly an "issue" in forming requirements in this > document, and that your taking exception to the wording - in a more > representative context - is based on your interpretation of the > statement (possibly in a less representative context). Here is the > context: > > "... bridged networks consist of single broadcast/flooding domains." > > One - fairly simplistic - way to look at VLANs is that the use of a > VLAN ID allows VLAN bridges to treat the non-VLAN broadcast domain > as having been divided into multiple logical broadcast domains, with > each such logical broadcast domain being effectively - logically - > a bridged network consisting of a single broadcast/flooding domain. > > In this view, the statement is not incorrect - however you might not > like it. > > If you would like me to phrase this point some other way, propose an > alternative wording, don't just say "it's wrong." > > > > > -- Silvano Gai > > > > > > > > > -----Original Message----- > > > From: rbridge-bounces@xxxxxxxxxx [mailto:rbridge-bounces@xxxxxxxxxx] > > On > > > Behalf Of The IESG > > > Sent: Friday, March 16, 2007 2:53 PM > > > To: IETF-Announce > > > Cc: rbridge@xxxxxxxxxx > > > Subject: [rbridge] Last Call: draft-ietf-trill-routing-reqs (TRILL > > > RoutingRequirements in Support of RBridges) to Informational RFC > > > > > > The IESG has received a request from the Transparent Interconnection > > of > > > Lots of Links WG (trill) to consider the following document: > > > > > > - 'TRILL Routing Requirements in Support of RBridges ' > > > <draft-ietf-trill-routing-reqs-02.txt> as an Informational RFC > > > > > > The IESG plans to make a decision in the next few weeks, > > and solicits > > > final comments on this action. Please send substantive comments to > > the > > > ietf@xxxxxxxx mailing lists by 2007-03-30. Exceptionally, > > > comments may be sent to iesg@xxxxxxxx instead. In either > > case, please > > > retain the beginning of the Subject line to allow automated sorting. > > > > > > The file can be obtained via > > > > > http://www.ietf.org/internet-drafts/draft-ietf-trill-routing-r > > eqs-02.txt > > > > > > > > > IESG discussion can be tracked via > > > > > https://datatracker.ietf.org/public/pidtracker.cgi?command=vie > > w_id&dTag= > > 15 > > > 187&rfc_flag=0 > > > > > > _______________________________________________ > > > rbridge mailing list > > > rbridge@xxxxxxxxxx > > > http://mailman.postel.org/mailman/listinfo/rbridge > > > > _______________________________________________ > > rbridge mailing list > > rbridge@xxxxxxxxxx > > http://mailman.postel.org/mailman/listinfo/rbridge > > _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf