[rbridge] Brief summary of feedback from the IEEE meeting

[Eric Gray (LO/EUS)]

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
 	bridging topology.
 	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
 		this issue.

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),
but
 		it will be important to have continuing dialogue (or
some
 		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
 		technologies.

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.

--
Eric Gray