Subject: [PWE3] [Fwd: [rbridge] Brief summary of feedback from the IEEE meeting]

From: Stewart Bryant <[email-masked]>
Date: Fri, 12 Jan 2007 15:55:07 +0000

This is a report on the IETF-IEEE discussion on Rbridge.

It seems that IEEE is planning to do work on congestion
notification. We need be be aware of this for two reasons
firstly we may at some stage need a next generation
Ethernet PW as a result, and secondly anything the
IEEE does is usually low overheaded in the data plane,
and therefore may be applicable to our own work on
congestion.

- Stewart

-------- Original Message --------
Subject: [rbridge] Brief summary of feedback from the IEEE meeting
Date: Fri, 12 Jan 2007 09:19:28 -0600
From: Eric Gray (LO/EUS) <[email-masked]>
To: <[email-masked]>

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

_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3