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. Why did you not earlier state specifically what part of the changes made were not satisfactory to you at that time? > > 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? > > 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. 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. 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, 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