[rbridge] Brief summary of feedback from the IEEE meeting
Eric Gray (LO/EUS)
eric.gray at ericsson.com
Fri Jan 12 07:19:28 PST 2007
SUMMARY of IEEE Feedback on TRILL Architecture
This is a brief summary of the verbal feedback we received from
members of the IEEE 802.1 at the November meeting in Dallas. I
am merely passing these on. They are not representative of any
formal feedback, there was no vote taken or call for objections
made, and they do not necessarily reflect my own opinion on any
particular aspect of the work in IEEE, or in the TRILL WG.
o One point was to address all of the documents: the statement
that spanning tree protocol converges slowly, is inefficient
or otherwise defective requires more clarification.
o 802.1s (MSTP) has been around since 2000 - and is now
part of 802.1Q.
o RSTP has a convergence time much quicker than appears
to have been considered in the problem statement draft.
RSTP is now part of 802.1D (2004).
o The TRILL document set should be specific as to which
aspects of spanning tree "deficiencies" it will address
and how it will address them.
o Current bridging deployments take advantage of the STP root
election process to optimize the use of certain links in the
o The specific scenario described is the "wiring closet"
problem outlined in the Architecture draft.
o The 802.1 group would like to point out that they feel
the TRILL solution will be dead on arrival if it does
not address this issue.
o The group does not consider replacing all wiring closet
equipment with RBridges as a valid approach to address
o Several members of the group said that currently developing
802.1 protocols and enhancements must be considered in working
through the process of TRILL protocol definition.
o For example, there are issues with supporting BCN in the
use of tunneling technologies (specifically, how will an
ingress RBridge ensure that a congestion notification is
delivered to the actual source).
o There was some discussion of BCN details (see below),
it will be important to have continuing dialogue (or
other form of interaction) going forward.
o There are several other issues with 802.1 enhancements
and/or extensions and issues with address transparency
that should be considered as well.
o Members of the group considers the intention of developing an
SPF-based approach (using a link-state routing protocol) -
particularly with intended plug-and-play capabilities -
commendable, but would prefer:
o the IETF consider sending routing experts to help the
IEEE with shortest path bridging using a link-state
routing protocol (replacing the current DVRP), or
o focus strictly on defining control plane mechanisms to
establish forwarding information for already existing -
and yet to be defined 802 encapsulation and data-plane
In the brief discussion on the topic of BCN, one thing that came out
was that there is a need - and considerations in progress - to include
some part of an original data-frame as part of congestion notification
messages. This could potentially address issues with "tunneled" MAC
frames - provided that the portion included is of sufficient length to
include at least the MAC DA/SA of the triggering frame.
There are no guarantees that this will happen, and it would be a very
good idea to track the development of BCN in IEEE 802.1 - assuming we
might want to support data-center applications using RBridges.
More information about the rbridge