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

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Fri, 18 Aug 2006 14:33:02 -0400

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

---

From: riw at cisco.com (Russ White)
Date: Tue, 29 Aug 2006 12:19:06 -0400

> state or distance vector)" to "apply modern network layer routing (e.g.,

Except there are modern distance vector protocols.... BGP falls loosely
within the designation of "distance vector," for instance. I think we
could just kill the "e.g." in the parenthesis altogether.

:-)

Russ

Date: Tue, 29 Aug 2006 12:19:06 -0400
From: Russ White <[email-masked]>
To: Eastlake III Donald-LDE008 <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] draft-ietf-trill-prob-00.txt
Status: RO
Content-Length: 891

> state or distance vector)" to "apply modern network layer routing (e.g.,

Except there are modern distance vector protocols.... BGP falls loosely
within the designation of "distance vector," for instance. I think we
could just kill the "e.g." in the parenthesis altogether.

:-)

Russ

Content-class: urn:content-classes:message
Date: Fri, 18 Aug 2006 14:33:02 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] draft-ietf-trill-prob-00.txt
Status: RO
Content-Length: 4392

Hi,

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

Thanks,
Donald

Content-class: urn:content-classes:message
Date: Fri, 11 Aug 2006 23:11:07 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] Draft-gray-trill-rbridge-arch-01.txt, draft-gray-trill-routing-reqs-01.txt
Status: RO
Content-Length: 304

Hi,

Based on the overall interest expressed, the next versions of these
drafts will be working group drafts. Please post additional comments on
these drafts and on our two existing working group drafts,
draft-ietf-trill-rbridge-protocol-00.txt and
draft-ietf-trill-prob-00.txt.

Thanks,
Donald and Erik

Content-class: urn:content-classes:message
Date: Thu, 10 Aug 2006 23:53:40 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] draft-gray-trill-routing-reqs-01.txt
Status: RO
Content-Length: 921

Just a few suggestions wearing my hat as a WG member:

Replace "R-Bridge" with "RBridge".

Page 7, 2nd paragraph before section 4, delete redundant "(the endnode
information)".

Page 7, section 4.1, 1st line, insert "parts of" between "within" and
"the".

Page 8, section 4.2, 2nd line, insert "known" between "each" and "L2".

Page 8, section 4.3, last line, replace "interactions with bridges" with
"interactions between routers and bridges".

As a general comment, it seems to me that this draft spends more time
than it needs to on co-located routers and RBridges. Its reasonable 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...

I may send some additional comments on the Security Considerations
section in a separate message.

Thanks,
Donald

From: "Gray, Eric" <[email-masked]>
To: Eastlake III Donald-LDE008 <[email-masked]>, [email-masked]
Date: Thu, 10 Aug 2006 11:50:47 -0400
Subject: Re: [rbridge] Draft-gray-trill-rbridge-arch-01.txt
Status: RO
Content-Length: 6423

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: [email-masked] 
--> [mailto:[email-masked]] On Behalf Of Eastlake 
--> III Donald-LDE008
--> Sent: Wednesday, August 09, 2006 11:56 PM
--> To: [email-masked]
--> 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
--> [email-masked]
--> http://mailman.postel.org/mailman/listinfo/rbridge
--> 

Date: Thu, 10 Aug 2006 07:26:43 -0700
From: Erik Nordmark <[email-masked]>
To: Shahram Davari <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Connection-Oriented Rbridge
Status: RO
Content-Length: 359

Shahram Davari wrote:
> Hi,
> 
> Is there any plan/thoughts to add GMPLS or other TE control-planes to Rbridge to make it connection-oriented?

Not that I know of.

I would assume one can do TE with Rbridges by tweaking the metrics that 
are used in the link-state routing protocol, but it would still be 
hop-by-hop forwarding between the Rbridges.

   Erik

Content-class: urn:content-classes:message
Date: Wed, 9 Aug 2006 23:56:21 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] Draft-gray-trill-rbridge-arch-01.txt
Status: RO
Content-Length: 5028

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