Subject: Re: [rbridge] Last Call: draft-ietf-trill-routing-reqs (TRILL Routing Requirements in Support of RBridges) to Informational RFC

From: Dinesh G Dutt <[email-masked]>
Date: Wed, 21 Mar 2007 12:15:07 -0700

Hi Eric,

Eric Gray (LO/EUS) wrote:
>>   - "Inefficient inter-bridge connection usage". What do you 
>>     mean by this phrase?
>>     
>
>   
I guess my issue is the choice of words "inter-bridge connection usage". 
"connection" is undefined and not sure if it is the right word.
> 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.
>   
If this what you want to say, something along the lines of "Non-optimal 
pair-wise forwarding of unicast frames using spanning tree also results 
in inefficient usage of links" will be sufficient. However, I think that 
merely stating the lack of non-optimal pair-wise forwarding is 
sufficient to imply this and many other issues around this style.
>> What is pFrom [email-masked] Thu Mar 22 07:43:53 2007
Date: Wed, 21 Mar 2007 12:15:07 -0700
From: Dinesh G Dutt <[email-masked]>
To: "Eric Gray (LO/EUS)" <[email-masked]>
Cc: [email-masked], [email-masked], IETF-Announce <[email-masked]>
Subject: Re: [rbridge] Last Call: draft-ietf-trill-routing-reqs (TRILL
 Routing Requirements in Support of RBridges) to Informational RFC

Hi Eric,

Eric Gray (LO/EUS) wrote:
>>   - "Inefficient inter-bridge connection usage". What do you 
>>     mean by this phrase?
>>     
>
>   
I guess my issue is the choice of words "inter-bridge connection usage". 
"connection" is undefined and not sure if it is the right word.
> 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.
>   
If this what you want to say, something along the lines of "Non-optimal 
pair-wise forwarding of unicast frames using spanning tree also results 
in inefficient usage of links" will be sufficient. However, I think that 
merely stating the lack of non-optimal pair-wise forwarding is 
sufficient to imply this and many other issues around this style.
>> 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?
>   
OK with me.

Dinesh

-- 
We make our world significant by the courage of our questions and by 
the depth of our answers.                               - Carl Sagan

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf-announce

---

From: caowayne <[email-masked]>
Date: Wed, 21 Mar 2007 19:23:31 +0800

----- Original Message ----- 
From: "Eric Gray (LO/EUS)" <[email-masked]>
To: "Dinesh G Dutt" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; "IETF-Announce" <[email-masked]>
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: [email-masked] 
>> [mailto:[email-masked]] On Behalf Of Dinesh G Dutt
>> Sent: Tuesday, Maroposed in the current solution is to run a spanning tree 
OK with me.

Dinesh

---

From: caowayne <[email-masked]>
Date: Wed, 21 Mar 2007 19:23:31 +0800

----- Original Message ----- 
From: "Eric Gray (LO/EUS)" <[email-masked]>
To: "Dinesh G Dutt" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; "IETF-Announce" <[email-masked]>
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

>> Sent: Tuesday, March 20, 2007 10:33 PM
>> To: [email-masked]
>> Cc: [email-masked]; 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.
> 
> 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.
> 
>> - 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 rch 20, 2007 10:33 PM
>> To: [email-masked]
>> Cc: [email-masked]; 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.
> 
> 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.
> 
>> - 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.
> 
>> - 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
>> > [email-masked] mailing lists by 2007-03-30. Exceptionally, 
>> > comments may be sent to [email-masked] 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
>> > [email-masked]
>> > http://mailman.postel.org/mailman/listinfo/rbridge
>> >
>> >   
>> 
>> -- 
>> rbridge mailing list
>> [email-masked]
>> http://mailman.postel.org/mailman/listinfo/rbridge
>> 
> 
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
>

group last call is needed, then I 
> would be happy to make this change as well.
> 
>> - 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
>> > [email-masked] mailing lists by 2007-03-30. Exceptionally, 
>> > comments may be sent to [email-masked] 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
>> > [email-masked]
>> > http://mailman.postel.org/mailman/listinfo/rbridge
>> >
>> >   
>> 
>> -- 
>> rbridge mailing list
>> [email-masked]
>> http://mailman.postel.org/mailman/listinfo/rbridge
>> 
> 
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
>