[rbridge] Your comments on (soon to be) draft-ietf-trill-rbridge-arch-00.tx t
Eric.Gray at marconi.com
Wed Sep 13 16:25:27 PDT 2006
Donald (et al),
Here is my response on your (Donald's) comments:
Abstract: I'm not familiar with the term "cross-section
bandwidth". Suggest "... to provide higher aggregate
throughput & more robust behavior under link interruption
or rapidly varying topologoy than an ..."
Replaced with "higher aggregate throughput".
It's possible that "cross-section badwidth" is
more accurate, but - even if it is - what's the
point in being more accurate but not understood?
Page 4, 3rd paragraph, next to last line, replace "all
available" with "optimized".
Replaced "all available" with "an optimized subset
of all available" - using "optimized" to replace
"all available" implies that STP results in sub-
optimal paths. That is not necessarily true (and
is likely to offend some people); what is true is
that STP results in sub-optimal use of available
Even that statement makes assumptions about loop
prevention/avoidance/mitigation behaviors. It is
not "optimal use of available bandwidth" if I am
able to use twice as many links, but use 60% of
of the combined link capacity in "clocking down"
TTL on looping traffic.
Page 6, 2nd paragraph, 1st & 2nd line: do we want to say
How about "attached MAC address learning" or something?
Page 7, 2nd bullet, 3rd line. Is "some or all" correct?
What if it is an frame addressed to a MAC address in the
Bridging PDU range of addresses (BPDU, PAUSE, ...)? What
if it is a unicast frame received on the port learning
bridges think it needs to send it back out on, would all
bridges send it back out in such a "misconfigured" case?
How about just replacing "some or all" with "a subset"?
Similarly, at the end of this bullet, should it say "...
being forwarded except certain bridge control frames."?
DONE - replaced "some or all" with "zero or more".
Page 7, 3rd bullet, 2nd & 3rd line: replace "determines"
with "learns" and inserting "unicast" between "incoming"
DONE - actually, I must have fixed this already
as I couldn't find "determines" and "unicast"
was in there already.
Page 8, 2nd bullet, 3rd line. Suggest replacing "layer 2"
Page 9, last bullet, 1st line. Replace "the" with "an".
Page 10, 1st bullet, 2nd line. After "CRED" insert "(see
Page 10, 2nd bullet. Actually, I think it would be nice
if we could drop all occurrences of "Switch" since it
seems to randomly be used for bridges and routers and
who knows what. I think of it as more a marketing than a
technical term. At the end of this item, did you actually
mean "exclude"? Or "execute"? Or how about "exclude or
Deleted the bullet and all instances of use of the
word "switch." Actually, the definition did have
a purpose at one time - specifically relating to
the fact that switches can be anything from a weak
bridge (that doesn't do STP, for instance) to an
The discussion came up on the list (and carried on
off the list) when Harald Alvestrand observed that
he found some "work group switches" apparently do
not do STP at all.
It was a consideration at the time that we may
have to deal with potential loops inserted by a
lame bridge. However, I believe we eventually
concluded that this is not an RBridge-specific
problem - hence not one we have to solve.
Page 11, 1st bullet. I found this paragraph hard to parse.
Perhaps replace the text on the 4th, 5th and 6th lines
with "...encapsulated within the outer received L2 header.
The outer L2 header in this case ..."
DONE - deleted ", rather than that encapsulating
L2 header" as it obviously doesn't help clarify
Page 13, section 3.1, 2nd paragraph, last line. Insert
"active" between "all" and "ports".
Page 14, section 3.2.2, 1st line. Does "special-case"
really add anything? How about dropping it?
Reworded this. "Special- case" is not the right
word. CFT-IRT entries are distinct from the CFT
entries. It's hard to go very far into how they
differ, however, without making assumptions about
protocol and implementation.
Hopefully it will be clearer now.
Page 16, section 3.2.3, 1st paragraph: looks like the
first "see Section" refers to Section 3.1. Not so sure
about the 2nd reference...
Removed both references. The ****** document
processing software substitutes "0" for any
cross-reference when the reference is deleted.
The referenced section was removed as a result
of moving some of the "options" completely out
of the last version. Since the referenced text
was deemed not required, the references were
I am not happy with the way that this section
is worded. I would be very happy to get some
sort of suggestions as to how to fix it.
What the section is describing is how a CTT
(CRED Transit Table) is used by an ingress
RBridge to inject frames on a "tunnel" toward
appropriate egress RBridge(s).
I think I can hijack some text from an RFC I am
familiar with, later, that has to describe the
same sort of problem.
Page 17, last paragraph. Although it is pretty obvious,
'r' isn't specified, so I suggest, in line 3, adding:
", shown as 'r'" after "...are replaced by Bridges".
DONE - added as a parenthetical addition.
Also, I suggest inserting somewhere, such as at the end
of this paragraph, a sentence something like:
"Note that the former b8-b9 path, which is b8-r9 in
Figure 2 and had been disable by the hypothetical
spanning tree in Figure 1, is now usable."
DONE - new paragraph inserted.
Page 19, section 4.2, 2nd paragraph: This can be read
to imply that the discovery protocol messages are
flooded. How about changing the first sentence to read
"The discovery mechanisms must use protocol messages
which propagate information through ..."
They should be flooded - at least until consumed
by a peer RBridge. Therefore I am happy to hear
that it sounds that way. See below. If RBridge
discovery protocol is distributed - on a LAN (or
perhaps I should say bridged segment) - by means
other than "blind flooding" (broadcast), the only
way we can make sure that every RBridge is found
is to have 'a priori' knowledge of topology and
what types of devices are included.
However, I take your point, and I believe I made
it clearer that the peer discovery is not flooded
throughout an entire broadcast domain. It should
be a one-hop protocol where messages are consumed
by a peer, chewed and (possibly) emitted (in some
modified form) on links that might connect to
I replaced the second paragraph with:
"The discovery mechanisms must use protocol messages which will
be propagated throughout a LAN (or broadcast domain) until they
are consumed by another RBridge. This must happen in order to
ensure that RBridges in the same broadcast domain are discovered
by their peers as required to allow for accurate determination
of RBridge topology."
Page 20, 3rd & 4th paragraphs, beginning -
Both paragraphs include the phrase "same type" which
I don't understand in the context...
Modified - hopefully should be clearer. "Same
type" means RBridge control frames. The point
is that RBridges which cannot consume a frame
- even if it is an RBridge control frame - must
forward it according to existing L2 forwarding
rules. Otherwise, it is possible to black-hole
a co-existing discovery protocol and create an
undiscovered "loopy" configuration.
Page 20, 5th paragraph. Reference seems to be to
DONE - also added discussion of the "wiring
closet" problem to this section (4.8, that is).
On this subject, the squishy sense of the room
at the last meeting (very accurately captured
in the minutes) was that we need to figure out
if we can address it, how, and whether or not
I think the added text does this - at least to
the degree it is appropriate for this draft to
do so. I think the WG needs to make that call
and - when we do - the results should be in the
I got a good deal of help on this from Stewart
Bryant and Guillermo Ibáñez (though they have
not seen the current text - so, if you don't
like what I wrote, it isn't their fault).
Page 20, last paragraph, 4th & 5th lines: TTL's don't
Suggest "...is limited by loop protection mechanisms...".
DONE - this change was a bit more complicated
And here are some even less important quibbles:
Page 6, 1st paragraph, last line, suggest dropping
"exclusively". Maybe you can manually configure some if
you want in some implementations...
(In general, absolute terms like "exclusively", "any",
and "all" make me nervous in a relatively high level
architectural paper. There is commonly some niggly
exception in some rare or optional case...)
Page 6, section 2.1, first bullet. Actually, the official
name of the current 802 document (802-2001) is "IEEE
Standard for Local and Metropolitan Area Networks:
Overview and Architecture". I suggest at least inserting
"architecture" so it reads "802: IEEE specification for
the Ethernet architecture ..."
Page 7, 1st bullet, add Informational reference for ARP
Page 7, "Broadcast Domain" bullet. Suggest deleting the
Page 15, 3rd paragraph from the bottom starting "Each
entry..." and ending "... Egress Rbridge": I think this
should somehow be broken into two or more sentences.
Page 21, 1st bullet, and page 31 at top: do we want to
say "protocol" or "Ethertype"? I think Ethertype is
better. Also, I'm not sure IANA would be involved in
getting an Ethertype from IEEE.
Page 22, last paragraph before section 4.5, 1st line.
Suggest adding something to the end of the 1st sentence,
"...not complete as new information continues to be
learned and old information may be timed out and
Page 24, section 4.6.1, 3rd paragraph, 3rd line, suggest
inserting "entry" after "CFT".
As a by the way, the only other comments I saw on the list
since the last meeting (and maybe those were slightly before
or even during the meeting) that might apply to the arch doc
was one from Radia that we need to make it clearer in these
specifications we are not trying to prohibit configuration.
I looked at the text on configuration in the architecture
draft and cannot find any that is not reasonably clear on
this. However, my ideas on what is clear about text I've
bee working on should be suspect.
I would appreciate it if people could give me examples of
specific text where things like this are not clear.
Also, anybody, feel free to comment on the changes above.
More information about the rbridge