Subject: [rbridge] Draft-gray-trill-rbridge-arch-01.txt

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Thu, 10 Aug 2006 11:50:47 -0400

Donald,

	Thank you for your comments.  I am traveling right now so I will
need to get back to you on these comments next week.  Based on my quick
look at these comments, however, I do not anticipate any issues with 
going ahead with your recommended changes.

--
Eric 

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake 
--> III Donald-LDE008
--> Sent: Wednesday, August 09, 2006 11:56 PM
--> To: rbridge at postel.org
--> Subject: [rbridge] Draft-gray-trill-rbridge-arch-01.txt
--> 
--> Hi,
--> 
--> I think this should be a working group draft. Below are 
--> some thoughts;
--> 
--> 
--> Here are some comments on 
--> draft-gray-trill-rbridge-arch-01.txt from me
--> in my capacity as a working group member:
--> 
--> Abstract: I'm not familiar with the term "cross-section bandwidth".
--> Suggest "... to provide higher aggregate throughput and more robust
--> behavior under link interruption or rapidly varying 
--> topologoy than an
--> ..."
--> 
--> Page 4, 3rd paragraph, next to last line, suggest replacing "all
--> available" with "optimized".
--> 
--> Page 6, 2nd paragraph, 1st & 2nd line: do we want to say "bridge
--> learning"? 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
--> that the learning bridge thinks 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."?
--> 
--> Page 7, 3rd bullet, 2nd & 3rd line: suggest replacing 
--> "determines" with
--> "learns" and inserting "unicast" between "incoming" and "frame".
--> 
--> Page 8, 2nd bullet, 3rd line. Suggest replacing "layer 2" 
--> with "802.1D".
--> 
--> Page 9, last bullet, 1st line. Replace "the" with "an".
--> 
--> Page 10, 1st bullet, 2nd line. After "CRED" insert "(see 
--> section 2.2)".
--> 
--> 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
--> execute"? ;-)
--> 
--> 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
--> ..."
--> 
--> 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?
--> 
--> 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...
--> 
--> 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". 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."
--> 
--> 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 ..."
--> 
--> Page 20, 3rd & 4th paragraphs, beginning "Rbridges must..." 
--> and "Note
--> that...": Both paragraphs include the phrase "same type" 
--> which I don't
--> understand in the context...
--> 
--> Page 20, 5th paragraph. Reference seems to be to "section 4.8".
--> 
--> Page 20, last paragraph, 4th & 5th lines: TTL's don't 
--> eliminate loops.
--> Suggest "...is limited by loop protection mechanisms...".
--> 
--> 
--> 
--> 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 [RFC 826].
--> 
--> Page 7, "Broadcast Domain" bullet. Suggest deleting the word "any".
--> 
--> 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, like "...not 
--> complete as new
--> information continues to be learned and old information may 
--> be timed out
--> and discarded."
--> 
--> Page 24, section 4.6.1, 3rd paragraph, 3rd line, suggest inserting
--> "entry" after "CFT".
--> 
--> 
--> 
--> I'll probably send some comments on sections 4.8 and 5 in a separate
--> message...
--> 
--> 
--> Thanks,
--> Donald
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://mailman.postel.org/mailman/listinfo/rbridge
-->