[Top] [All Lists]

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

2007-03-21 04:31:06
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."

- 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.
- "Inefficient inter-bridge connection usage". What do you mean by this phrase ?

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

- Ethernet and 802 is used interchangeably. Isn't Ethernet 802.3 only ? Look at: 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(_dot_)org mailing lists by 2007-03-30. Exceptionally, comments may be sent to iesg(_at_)ietf(_dot_)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

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

Ietf mailing list