Thanks for posting these comments. Please see below.
[mailto:rbridge-bounces(_at_)postel(_dot_)org] On Behalf Of Silvano Gai
Sent: Tuesday, March 20, 2007 12:35 PM
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
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
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
approved document. It is also substantially incorrect since many terms
listed are not used in this document and some are not agreed in the
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
In general a better definition of what is mandatory and what is
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
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
"... 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
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
Behalf Of The IESG
Sent: Friday, March 16, 2007 2:53 PM
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
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,
final comments on this action. Please send substantive comments to
ietf(_at_)ietf(_dot_)org mailing lists by 2007-03-30. Exceptionally,
comments may be sent to iesg(_at_)ietf(_dot_)org instead. In either
retain the beginning of the Subject line to allow automated sorting.
The file can be obtained via
IESG discussion can be tracked via
rbridge mailing list
rbridge mailing list
Ietf mailing list