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

[riw at cisco.com (Russ White)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> 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)".

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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFE9Gj6ER27sUhU9OQRArymAJsEjcDZh5zxd1Nbeqje35rChMIsawCg1zcD
70TUVNCfjUbFZQdOZ2jY/10=
=psXn
-----END PGP SIGNATURE-----


Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by boreas.isi.edu (8.13.8/8.13.6) with ESMTP id k7TGJAxm012020 for <[e-mail]>; Tue, 29 Aug 2006 09:19:11 -0700 (PDT)
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 29 Aug 2006 12:19:10 -0400
X-IronPort-AV: i="4.08,182,1154923200";  d="scan'208"; a="99505424:sNHT29392240"
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7TGJAIs007268; Tue, 29 Aug 2006 12:19:10 -0400
Received: from [64.101.196.76] (dhcp-chg-64-101-196-76.cisco.com [64.101.196.76]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k7TGJ9dM010757;  Tue, 29 Aug 2006 12:19:09 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Tue, 29 Aug 2006 12:19:06 -0400
From: Russ White <[e-mail]>
User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719)
MIME-Version: 1.0
To: Eastlake III Donald-LDE008 <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.94.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=888; t=1156868350; x=1157732350; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:Russ=20White=20<[e-mail]> |Subject:Re=3A=20[rbridge]=20draft-ietf-trill-prob-00.txt |To:Eastlake=20III=20Donald-LDE008=20<[e-mail]>; X=v=3Dcisco.com=3B=20h=3DBMPkjFNswtoeqzHiIgXRa4NQpAg=3D; b=luLDseSuUa1JNxflfqU/u9wSYixlqDpoDkBktspfuzeIEZ6W6in31St98PUA/XGeY3bEDSHK yi1kuHk+OoCxopqeK5SSDsg7Ax0n2dtZ/bXsNfC6Qzyiid0KGIM/RV46;
Authentication-Results: rtp-dkim-1.cisco.com; header.From=[e-mail]; dkim=pass ( 27 extraneous bytes; sig from cisco.com verified; ); 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] draft-ietf-trill-prob-00.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 29 Aug 2006 16:19:23 -0000
Status: RO
Content-Length: 891

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> 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)".

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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFE9Gj6ER27sUhU9OQRArymAJsEjcDZh5zxd1Nbeqje35rChMIsawCg1zcD
70TUVNCfjUbFZQdOZ2jY/10=
=psXn
-----END PGP SIGNATURE-----


Received: from motgate8.mot.com (motgate8.mot.com [129.188.136.8]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k7IIX7Y00894 for <[e-mail]>; Fri, 18 Aug 2006 11:33:07 -0700 (PDT)
Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id k7IIX6JC005196 for <[e-mail]>; Fri, 18 Aug 2006 11:33:06 -0700 (MST)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id k7IIX6cx025093 for <[e-mail]>; Fri, 18 Aug 2006 13:33:06 -0500 (CDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 18 Aug 2006 14:33:02 -0400
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-ietf-trill-prob-00.txt
Thread-Index: AcbC9Lyo4d3jWAVjQYCxagFLC44BLw==
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: <[e-mail]>
X-Brightmail-Tracker: AAAAAQAAAAQ=
X-White-List-Member: TRUE
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k7IIX7Y00894
Subject: [rbridge] draft-ietf-trill-prob-00.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 18 Aug 2006 18:33:28 -0000
Status: RO
Content-Length: 4392

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


Received: from motgate8.mot.com (motgate8.mot.com [129.188.136.8]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k7C3B9e26136 for <[e-mail]>; Fri, 11 Aug 2006 20:11:10 -0700 (PDT)
Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id k7C3B9bQ010104 for <[e-mail]>; Fri, 11 Aug 2006 20:11:09 -0700 (MST)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id k7C3B8QH019727 for <[e-mail]>; Fri, 11 Aug 2006 22:11:08 -0500 (CDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 11 Aug 2006 23:11:07 -0400
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Draft-gray-trill-rbridge-arch-01.txt, draft-gray-trill-routing-reqs-01.txt
Thread-Index: Aca9vPQlR8VdIkBkTs6piPIYQyHPjA==
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: <[e-mail]>
X-Brightmail-Tracker: AAAAAQAAAAQ=
X-White-List-Member: TRUE
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k7C3B9e26136
Subject: [rbridge] Draft-gray-trill-rbridge-arch-01.txt, draft-gray-trill-routing-reqs-01.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 12 Aug 2006 03:11:21 -0000
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


Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k7B3s3e06970 for <[e-mail]>; Thu, 10 Aug 2006 20:54:03 -0700 (PDT)
Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id k7B3rwBm009126 for <[e-mail]>; Thu, 10 Aug 2006 20:54:02 -0700 (MST)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id k7B3rv9I024198 for <[e-mail]>; Thu, 10 Aug 2006 22:53:57 -0500 (CDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 10 Aug 2006 23:53:40 -0400
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-gray-trill-routing-reqs-01.txt
Thread-Index: Aca8+bueRhVGCVGHSLiCEM4K9cgGUQ==
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: <[e-mail]>
X-Brightmail-Tracker: AAAAAQAAAAQ=
X-White-List-Member: TRUE
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k7B3s3e06970
Subject: [rbridge] draft-gray-trill-routing-reqs-01.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 11 Aug 2006 03:54:14 -0000
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


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k7AFove02486 for <[e-mail]>; Thu, 10 Aug 2006 08:50:58 -0700 (PDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k7AFonIX014148; Thu, 10 Aug 2006 11:50:49 -0400 (EDT)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA03622;  Thu, 10 Aug 2006 11:50:48 -0400 (EDT)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <308BLQYX>; Thu, 10 Aug 2006 11:50:48 -0400
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: Eastlake III Donald-LDE008 <[e-mail]>, [e-mail]
Date: Thu, 10 Aug 2006 11:50:47 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Draft-gray-trill-rbridge-arch-01.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 10 Aug 2006 15:52:47 -0000
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: [e-mail] 
--> [mailto:[e-mail]] On Behalf Of Eastlake 
--> III Donald-LDE008
--> Sent: Wednesday, August 09, 2006 11:56 PM
--> To: [e-mail]
--> 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
--> [e-mail]
--> http://mailman.postel.org/mailman/listinfo/rbridge
--> 


Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k7AEQwb08545 for <[e-mail]>; Thu, 10 Aug 2006 07:26:58 -0700 (PDT)
Received: from jurassic.eng.sun.com ([129.146.68.36]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7AEQl4R010526; Thu, 10 Aug 2006 08:26:49 -0600 (MDT)
Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id k7AEQijS208903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Aug 2006 07:26:46 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Thu, 10 Aug 2006 07:26:43 -0700
From: Erik Nordmark <[e-mail]>
User-Agent: Thunderbird 1.5.0.5 (X11/20060730)
MIME-Version: 1.0
To: Shahram Davari <[e-mail]>
References: <[e-mail]_nt.nt.pmc-sierra.bc.ca>
In-Reply-To: <[e-mail]_nt.nt.pmc-sierra.bc.ca>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Connection-Oriented Rbridge
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 10 Aug 2006 14:27:13 -0000
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


Received: from motgate8.mot.com (motgate8.mot.com [129.188.136.8]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k7A3uYb13957 for <[e-mail]>; Wed, 9 Aug 2006 20:56:34 -0700 (PDT)
Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id k7A3uXPo015219 for <[e-mail]>; Wed, 9 Aug 2006 20:56:33 -0700 (MST)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id k7A3uW76005886 for <[e-mail]>; Wed, 9 Aug 2006 22:56:32 -0500 (CDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 9 Aug 2006 23:56:21 -0400
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Draft-gray-trill-rbridge-arch-01.txt
Thread-Index: Aca8MPD+CTPYYAYPT5aGQuky6cu9VQ==
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: <[e-mail]>
X-Brightmail-Tracker: AAAAAQAAAAQ=
X-White-List-Member: TRUE
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k7A3uYb13957
Subject: [rbridge] Draft-gray-trill-rbridge-arch-01.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 10 Aug 2006 03:57:26 -0000
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