From Eric.Gray at marconi.com Wed Sep 13 16:25:27 2006 From: Eric.Gray at marconi.com (Gray, Eric) Date: Wed, 13 Sep 2006 19:25:27 -0400 Subject: [rbridge] Your comments on (soon to be) draft-ietf-trill-rbridge-arch-00.tx t Message-ID: <0BF76B30C100624BA997C9CED19D81257D4015@uspitsmsgusr08.win.marconi.com> 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 paths. 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 "bridge learning"? How about "attached MAC address learning" or something? DONE 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" and "frame". 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" with "802.1D". DONE Page 9, last bullet, 1st line. Replace "the" with "an". DONE Page 10, 1st bullet, 2nd line. After "CRED" insert "(see section 2.2)". DONE 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"? ;-) 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 almost router. 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 the text. Page 13, section 3.1, 2nd paragraph, last line. Insert "active" between "all" and "ports". DONE 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 OBE. 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 additional peers. 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 - "Rbridges must..." and "Note that...": 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 "section 4.8". 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 we should. 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 protocol specification. 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 eliminate loops. Suggest "...is limited by loop protection mechanisms...". DONE - this change was a bit more complicated than suggested. 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...) DONE 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 ..." DONE Page 7, 1st bullet, add Informational reference for ARP [RFC 826]. DONE Page 7, "Broadcast Domain" bullet. Suggest deleting the word "any". DONE 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. DONE 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. DONE 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." DONE Page 24, section 4.6.1, 3rd paragraph, 3rd line, suggest inserting "entry" after "CFT". DONE 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. -- Eric From Eric.Gray at marconi.com Wed Sep 20 12:55:53 2006 From: Eric.Gray at marconi.com (Gray, Eric) Date: Wed, 20 Sep 2006 15:55:53 -0400 Subject: [rbridge] draft-gray-trill-routing-reqs-01.txt Message-ID: <0BF76B30C100624BA997C9CED19D81257D4519@uspitsmsgusr08.win.marconi.com> Donald, The following is the disposition with respect to your comments on the Routing Requirements draft. I have made other - relatively minor - changes to this draft and will be submitting it to the Internet Drafts site shortly. Replace "R-Bridge" with "RBridge". DONE Page 7, 2nd paragraph before section 4, delete redundant "(the endnode information)". DONE Page 7, section 4.1, 1st line, insert "parts of" between "within" and "the". DONE Page 8, section 4.2, 2nd line, insert "known" between "each" and "L2". DONE Page 8, section 4.3, last line, replace "interactions with bridges" with "interactions between routers and bridges". As a general comment, this draft spends more time than it needs to on co-located routers and RBridges. It's okay to mention that as it makes particularly clear the need to be able to distinguish routing protocol messages used for routing and for RBridge interaction but I'm not the sort of co-location needs to be mentioned so much. ? - there are a total of 4 instances of use of the word "co-located" (or "colocated" as it was before) and - of those - one could be removed without loss of information. However, that one instance serves as a parenthetical reminder in the sentence: "there may be specific requirements imposed on the interactions [...] between RBridge instances and (potentially co-located) IP routing instances." It's parenthetical, I think it adds value, and it is a single (extra) instance that could hardly be thought to wear out the expression. However, if other people feel that it doesn't add value, I will be happy to take it out. --- [SNIP] ---