[rbridge] draft-ietf-trill-prob-00.txt

[Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)]

Hi,

Here are a few comments from me as a WG member on the
draft-ietf-trill-prob-00.txt draft:

Page 2 in abstract at the top: I don't actually think of typical
distance vector routing as much, if any, better that spanning tree, both
being substantially inferior to link state protocols.  I would suggest,
in the 3rd & 4th line, changing "apply network layer routing (e.g., link
state or distance vector)" to "apply modern network layer routing (e.g.,
link state)".

Section 2.2, page 6, first question: Sure, just make a ring. STP will
turn off some arbitrary link in it (actually determined by MAC addresses
or something). Now imagine that a link approximately opposite the one
turned off by STP fails. The direction towards root will change for all
or almost all nodes, those that were few hops apart will be many hops
apart and vice versa...

Section 2.2, page 6, second question: I'm not an expert but I have heard
things said that imply that the worst case RSTP settling time is related
to 3 times the network diameter, where diameter is the maximum of the
minimum number of hops between all pairs of nodes.

Section 2.2, page 6, third question: I'm not sure if this is an answer
to your question but it seems to me that bridge port learning has
problems solvable by link state protocol distribution of the
information.

	   A---\
	        B---\
	C1--X--/     \
	              D---...Z
	C2--Y--\     /
	        E---/
	   F---/

Assuming node C moves from C1 to C2. There had been traffic from C1 to
Z. Traffic from C2 to Z would presumably cause D, E, and Y to learn of
its new attachment, changing information at D. But is there any
mechanism in spanning tree systems whereby B's opinion of how to forward
frames to C would be updated? What happened if there is a spurt of data
from A addressed to C? If B/D/E were Rbridges, presumably information
about C's new attachment would have gotten to B.

Section 2.3: given that this is about "Robustness to Link Interruption",
I suppose it is reasonable that it talks so much about alternative
paths.  But I think Section 2 is too heavy on alternative paths and very
odd that it does not mention loops. Perhaps 2.3 should be "Robustness to
Link Interruption and Appearance" and could mention loops due to a
repeater coming up or the like.

Section 2.4, page 7, last paragraph: I don't think multipath is "the
focus of TRILL". Maybe optimized paths is. Also, should this paragraph
mention loops?

Section 2.5: I found this section, or at least the first part of it, a
bit hard to understand. Are the first two bullet items actually related
to "deployment", mentioned before them, or to "larger scale", which is
not mentioned until after them?

Section 3.2, page 9: Suggest dropping "(inadvertent)". 

Section 3.3: Spanning tree tries to avoid loops but the appearance of a
link can create one.

Section 3.4: I'm not sure that the "TRILL solution" is necessarily more
"stable". It is supposed to provide more optimized paths and be more
robust...

Section 3.5: I believe this has to do with things like a cloud of TRILL
devices, bridge, and hubs having "multiple attachments" of various sorts
such as to the Internet and questions about which is chosen for various
traffic, how you can be sure that a broadcast coming in through one
attachment isn't sent back out on another so it doesn't loop, etc. I
believe this sort of concern is why the TRILL charter includes the
following:
	"The TRILL working will work with the L2VPN WG to develop
interworking between TRILL and 802.1D bridges at the edge, such that a
bridged sub-cloud could be attached to TRILL devices in more than one
place for redundancy."

Section 5, page 13, 4th paragraph: Suggest inserting "or adding" after
"interrupting".

References: "D" should be capitalized in 802.1D. Document title is "IEEE
Standard for
Local and metropolitan area networks: Media Access Control (MAC)
Bridges" dated 9 June 2004.

802.1Q, 7 May 2003, is "IEEE Standards for Local and metropolitan area
networks: Virtual Bridged Local Area Networks" and incorporates 802.1v
and 802.1s. In 802-land, the capitalization of the alphabetic suffix
makes a difference. If it is upper case, you are talking about a
free-standing document. If it is lower case, then you are talking about
an amendment to a base document which will get rolled into that base
document the next time it is updated.

Thanks,
Donald