[rbridge] Your comments on (soon to be) draft-ietf-trill-rbridge-arch-00.tx t

[Gray, Eric]

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