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

["Eric Gray \(LO/EUS\)" <eric.gray at ericsson.com>]

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 
> 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
> 

_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf