From: Eric Gray (LO/EUS) [mailto:eric(_dot_)gray(_at_)ericsson(_dot_)com]
Sent: Tuesday, March 20, 2007 11:31 AM
To: Silvano Gai; ietf(_at_)ietf(_dot_)org
Subject: RE: [rbridge] Last Call: draft-ietf-trill-routing-reqs
(TRILLRoutingRequirements in Support of RBridges) to Informational RFC
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
pass an IESG last call.
I think as a strict matter of process, we don't get to say what MUST
corrected before a document can pass IESG last call (if there is such
Luckily, I believe this is an IETF Last Call, where the idea is that
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
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
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
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?
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
approved document. It is also substantially incorrect since many
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
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.
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,
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.
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
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
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
The file can be obtained via
IESG discussion can be tracked via
rbridge mailing list
rbridge mailing list
Ietf mailing list