[rbridge] Last Call: draft-ietf-trill-routing-reqs (TRILL Routing Requirements in Support of RBridges) to Informational RFC
caowayne at huawei.com
Wed Mar 21 04:23:31 PDT 2007
----- Original Message -----
From: "Eric Gray (LO/EUS)" <eric.gray at ericsson.com>
To: "Dinesh G Dutt" <ddutt at cisco.com>; <ietf at ietf.org>
Cc: <rbridge at postel.org>; "IETF-Announce" <ietf-announce at 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
> Thank you for your comments. Please see below...
> Eric Gray
> Principal Engineer
>> -----Original Message-----
>> From: rbridge-bounces at postel.org
>> [mailto:rbridge-bounces at postel.org] On Behalf Of Dinesh G Dutt
>> Sent: Tuesday, March 20, 2007 10:33 PM
>> To: ietf at ietf.org
>> Cc: rbridge at 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.
>> - 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
> 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
>> - Section 1.2, Backward Compatibility and section 4.1: "...they
>> terminate a bridged spanning tree, (i.e. - they do not forward
>> 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
>> 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 at ietf.org mailing lists by 2007-03-30. Exceptionally,
>> > comments may be sent to iesg at ietf.org instead. In either
>> case, please
>> > retain the beginning of the Subject line to allow automated sorting.
>> > The file can be obtained via
>> > IESG discussion can be tracked via
>> > _______________________________________________
>> > rbridge mailing list
>> > rbridge at 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 at postel.org
> rbridge mailing list
> rbridge at postel.org
More information about the rbridge