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: 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(_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
http://www.ietf.org/internet-drafts/draft-ietf-trill-routing-reqs-02.txt
IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15187&rfc_flag=0
_______________________________________________
rbridge mailing list
rbridge(_at_)postel(_dot_)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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf