[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [rbridge] Last Call: draft-ietf-trill-routing-reqs (TRILL Routing Requirements in Support of RBridges) to Informational RFC
----- 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
> Dinesh,
>
> Thank you for your comments. Please see below...
>
> Thanks!
>
> --
> Eric Gray
> Principal Engineer
> Ericsson
>
>> -----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 sufficFrom ietf-announce-bounces at ietf.org Thu Mar 22 07:43:53 2007
Return-path: <ietf-announce-bounces at ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1HULSZ-0007Ex-G8; Thu, 22 Mar 2007 07:27:59 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1HTz3u-0002Uo-A0; Wed, 21 Mar 2007 07:33:02 -0400
Received: from szxga03-in.huawei.com ([61.144.161.55])
by ietf-mx.ietf.org with esmtp (Exim 4.43)
id 1HTz3L-0000cj-Hq; Wed, 21 Mar 2007 07:33:02 -0400
Received: from huawei.com (szxga03-in [172.24.2.9])
by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
(built Mar
3 2004)) with ESMTP id <0JF900C7I3OCG1 at szxga03-in.huawei.com>; Wed,
21 Mar 2007 19:24:12 +0800 (CST)
Received: from jys6053946 (dhcp-4009.ietf68.org [130.129.64.9])
by szxga03-in.huawei.com
(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004))
with ESMTPA id <0JF900L4H3NHBG at szxga03-in.huawei.com>; Wed,
21 Mar 2007 19:24:12 +0800 (CST)
Date: Wed, 21 Mar 2007 19:23:31 +0800
From: caowayne <caowayne at huawei.com>
To: "Eric Gray (LO/EUS)" <eric.gray at ericsson.com>,
Dinesh G Dutt <ddutt at cisco.com>, ietf at ietf.org
Message-id: <009101c76bab$63717cb0$fa01000a at china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <E1HSKM4-0001KO-4Q at stiedprstage1.ietf.org>
<46009976.5030007 at cisco.com>
<941D5DCD8C42014FAF70FB7424686DCF9EAE91 at eusrcmw721.eamcs.ericsson.se>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7
X-Mailman-Approved-At: Thu, 22 Mar 2007 07:27:55 -0400
Cc: rbridge at postel.org, IETF-Announce <ietf-announce at ietf.org>
Subject: Re: [rbridge] Last Call: draft-ietf-trill-routing-reqs
(TRILL Routing
Requirements in Support of RBridges) to Informational RFC
X-BeenThere: ietf-announce at ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ietf-announce.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>,
<mailto:ietf-announce-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf-announce at ietf.org>
List-Help: <mailto:ietf-announce-request at ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>,
<mailto:ietf-announce-request at ietf.org?subject=subscribe>
Errors-To: ietf-announce-bounces at ietf.org
----- 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
> Dinesh,
>
> Thank you for your comments. Please see below...
>
> Thanks!
>
> --
> Eric Gray
> Principal Engineer
> Ericsson
>
>> -----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.
>
> 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
ient 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 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
>> >
>> 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 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
>> http://mailman.postel.org/mailman/listinfo/rbridge
>>
>
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>
_______________________________________________
IETF-Announce mailing list
IETF-Announce at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce