----- Original Message ----- From: "Eric Gray (LO/EUS)" <eric.gray@ericsson.com> To: "Dinesh G Dutt" <ddutt@cisco.com>; <ietf@ietf.org> Cc: <rbridge@postel.org>; "IETF-Announce" <ietf-announce@ietf.org> Sent: Wednesday, March 21, 2007 6:48 PM Subject: Re: [rbridge] Last Call: draft-ietf-trill-routing-reqs (TRILL Routing Requirements in Support of RBridges) to Informational RFC > Dinesh, > > Thank you for your comments. Please see below... > > Thanks! > > -- > Eric Gray > Principal Engineer > Ericsson > >> -----Original Message----- >> From: rbridge-bounces@postel.org >> [mailto:rbridge-bounces@postel.org] On Behalf Of Dinesh G Dutt >> Sent: Tuesday, March 20, 2007 10:33 PM >> To: ietf@ietf.org >> Cc: rbridge@postel.org; IETF-Announce >> Subject: Re: [rbridge] Last Call: >> draft-ietf-trill-routing-reqs (TRILL Routing Requirements in >> Support of RBridges) to Informational RFC >> >> I have a few comments on the document. >> >> - Section 1, Bridging Limitations: The first two paragraphs are >> structured around the logic: because ethernet header doesn't have >> a TTL or a hop count, the only choice was to use spanning tree. >> IEEE 802.1 has defined several headers such as 802.1Q header that >> carries the VLAN. If they wanted to add a TTL, they could have. >> They picked spanning tree and said that therefore they didn't need >> a TTL. To the extent this represents history, I think it is >> inaccurate. To the extent it attempts to explain the rationale for >> RBridges, it seems unnecessary. A sufficient replacement maybe >> along the lines of: >> >> "Spanning Tree Protocol and its variants are the control protocol >> deployed in current 802.1D Ethernet bridges. This protocol >> constructs a single tree out of a mesh of network connections. >> This tree eliminates usage of equal cost multipaths and results in >> non-optimal pair-wise forwarding." >> > > This is a reasonable proposal for replacement text. If there > are no objections from the working group, or the IESG, I would > be happy to make this change. > > Thanks! > >> - Section 1, Bridging Limitations: More specific comments: >> - "Because of the potential for severe impact from looping traffic, >> many (if not most) current bridge implementations stop forwarding >> of traffic frames following a topology change event and restart >> only after STP/RSTP is complete" is incorrect. All 802.1D bridges >> allow (R/M)STP to complete before moving a port to forwarding >> state. I'd remove the phrase in parentheses. > > Good suggestion. Assuming the same acceptance, I can make this > change as well. > >> - "Inefficient inter-bridge connection usage". What do you >> mean by this phrase? > > I assume this is a reasonably well understood aspect of using > a spanning tree as opposed to using shortest path routing. > > It is not difficult to come up with a reasonable scenario in > which shortest path forwarding results in 80% of the total > link-by-link forwarding load that is generated by the same > amount of traffic in a corresponding spanning tree scenario. > > The reason why this happens is that a spanning tree may be > constructed in which the path for some destinations will > traverse at least one additional link, when arriving from > some sources. Practically speaking, unless a spanning tree > is constructed per-source bridge, it's easy to show that > this will be true for at least some source and destination > pairs. > > Assuming the simplistic (VLAN-free) scenario that is basic > to the "configuration-free" capability that is part of the > chartered goals of TRILL, there would only be one spanning > tree in a bridged network. Hence, in this scenario, there > would be many cases in which traffic traverses at least one > additional link. > > If traffic is demonstrably required to traverse more links > than some theoretical minimum, than link utilization is - > by definition - less efficient than it theoretically can > be. > >> >> - Section 1.2, Backward Compatibility and section 4.1: "...they >> terminate a bridged spanning tree, (i.e. - they do not forward >> BPDUs)". >> >> I thought that we have not concluded the discussion on preventing >> loops for interconnected Bridges and RBridges based on the email >> thread that started a while back. Putting a decision in this >> section on the solution seems a little unnecessary. > > I am not sure that this text - or something like it - is unnecessary > from a compatibility perspective, and it may be the case that this > change would require a new working group last call. However, if it > is acceptable to the IESG either that the change does not require a > new last call, or a second working group last call is needed, then I > would be happy to make this change as well. > >> What is proposed in the current solution is to run a spanning tree >> protocol instance per port which maybe not scalable. >> >> I think something like "It's strongly desirable to minimize the >> interaction between the bridges and Rbridges and constrain a >> spanning tree" is more appropriate. > > Yet it is difficult to imagine how this would translate to a > requirement that would make sense to someone evaluating the > acceptability of a routing protocol for the TRILL problem-space. > Perhaps it would be simpler to omit the offending text? > >> >> - Ethernet and 802 is used interchangeably. Isn't Ethernet >> 802.3 only ? >> Look at: http://en.wikipedia.org/wiki/IEEE_802.3 or >> http://www.ieee802.org/3/. >> >> I don't see anything on what I consider to be another >> important goal: to >> have a single protocol to compute unicast, multicast and broadcast >> routes. This reduces operational overhead by having to understand and >> debug a single protocol. >> >> The IESG wrote: >> > The IESG has received a request from the Transparent >> Interconnection of >> > Lots of Links WG (trill) to consider the following document: >> > >> > - 'TRILL Routing Requirements in Support of RBridges ' >> > <draft-ietf-trill-routing-reqs-02.txt> as an Informational RFC >> > >> > The IESG plans to make a decision in the next few weeks, >> and solicits >> > final comments on this action. Please send substantive >> comments to the >> > ietf@ietf.org mailing lists by 2007-03-30. Exceptionally, >> > comments may be sent to iesg@ietf.org instead. In either >> case, please >> > retain the beginning of the Subject line to allow automated sorting. >> > >> > The file can be obtained via >> > >> http://www.ietf.org/internet-drafts/draft-ietf-trill-routing-r >> eqs-02.txt >> > >> > >> > IESG discussion can be tracked via >> > >> https://datatracker.ietf.org/public/pidtracker.cgi?command=vie >> w_id&dTag=15187&rfc_flag=0 >> > >> > _______________________________________________ >> > rbridge mailing list >> > rbridge@postel.org >> > http://mailman.postel.org/mailman/listinfo/rbridge >> > >> > >> >> -- >> We make our world significant by the courage of our questions and by >> the depth of our answers. - Carl Sagan >> _______________________________________________ >> rbridge mailing list >> rbridge@postel.org >> http://mailman.postel.org/mailman/listinfo/rbridge >> > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > _______________________________________________ IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
