Subject: [rbridge] Ingress Rbridge address and BCN - 2nd Issue

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Fri, 27 Oct 2006 18:39:26 -0400

Larry,

	I am no more likely to have the time to fix everything that is
broken than I am to have the time to create summaries for people who
apprently don't have time to read.  :-)

	I am not criticizing the group that came up with the protocol,
I am criticizing the protocol as you described it.  Generating a lot
of traffic during congested conditions is a pathological behavior, in
almost every case. 

	I assume that - if the BCN approach is supposed to work at all
- that it actually starts sending BCN messages well before the links
involved are experiencing true congestion.  I would imagine that this
might be based on some well-known or configurable threshold.

	The reason why I assume that, is based on a previously stated
goal for BCN - loss-less congestion notification.  If you wait until 
you are actually experiencing congestion to send BCNs, then you are
sending BCNs _instead_ of traffic.  That will quickly result in more
BCNs and you're already well on the way to a "melt-down."  That hardly 
seems like a sane "loss-less congestion notification" strategy

	I also assume that BCNs are not sent for every frame when the
links approach a congested state (by whatever definition the protocol
uses for "congested state") because that leads to another type of bad
behavior - i.e. that experienced using TCP combined with certain
undesirable forms to packet discard.

	Consequently, at the level of microseconds of turn-around time,
BCN _should_ not depend on "instantaneous frame turn around" nor is
it likely that flooding frames for a relatively scarce event will be
that much more of a burden than simply sending them to the ingress.

	Since you can have a choice - either build in slightly more
memory so that you can retain information you need, or operate at a
slightly lower threshold of "relative congestion" - it seems to me
that BCN implementers can knob this one out without help from TRILL.

--
Eric 

--> -----Original Message-----
--> From: Larry Kreeger (kreeger) [mailto:kreeger at cisco.com] 
--> Sent: Friday, October 27, 2006 5:43 PM
--> To: Gray, Eric
--> Cc: rbridge at postel.org
--> Subject: RE: [rbridge] Ingress Rbridge address and BCN - 2nd Issue
--> 
--> Gray, Eric wrote on Friday, October 27, 2006 11:46 AM:
--> 
--> > -- [SNIP] --
--> > 
--> > --> >
--> > --> > 2nd Issue - what is the importance of "optimizing" 
--> support for
--> > BCN? 
--> > --> >
--> > 
--> ================================================================== 
--> > --> >
--> > --> > 	BCN is likely to be important for a number of
--> applications that
--> > --> > we care about.  But is it important enough that we 
--> should design
--> > --> > an
--> > RBridge
--> > --> > solution that is optimized for it, or is it 
--> sufficient that our
--> > solution
--> > --> > is not significantly sub-optimal for these applications?
--> > --> >
--> > --> > 	As Radia has already pointed out, an RBridge that finds
--> itself
--> > --> > with a frame it must deliver, and no corresponding 
--> forwarding
--> > --> > entry, will forward that frame on the ingress RBridge tree
--> > --> > (corresponding to
--> > delivery
--> > --> > of unknown MAC destination "flooding").  This is 
--> sub-optimal,
--> > but 
--> > --> > the choice that leads to an RBridge finding it 
--> needs to do this
--> > in 
--> > --> > the BCN
--> > 
--> > --> > case is (as I've said before) entirely an 
--> implementation choice.
--> > --> > Presumably, the implementer may choose to discard even BCN
--> > related 
--> > --> > MAC
--> > 
--> > --> > reachability if - as a trade-off decision - they 
--> believe that
--> > conservative
--> > --> > retention of MAC reachability is desirable over 
--> optimal support
--> > of 
--> > BCN.
--> > --> >
--> > --> > 	I personally favor the idea of forwarding BCN
--> notifications on
--> > --> > the Ingress RBridge Tree - for those 
--> implementations that do not
--> > --> > keep the appropriate MAC reachability information.  I favor
--> > this because: 
--> > --> >
--> > --> > 	1) it is consistent with how bridges work now, therefore
--> it is
--> > --> > 	not a departure from "the devil we know,"
--> > -->
--> > --> Last time looked at the BCN proposal, there could be 
--> a significant
--> > amount
--> > --> of BCN traffic during congestion.  Flooding this 
--> traffic to ALL
--> > --> RBridges
--> > 
--> > --> seems like a bad idea if you are concerned with link 
--> utilization.
--> > 
--> > A couple of separable points -
--> > 
--> > 1) Flooding will only occur when a specific RBridge has 
--> removed (due
--> > to aging, for example), or failed to retain, an entry it 
--> subsequently
--> > needs.  
--> > This kind of flooding could occur in any case (although it might
--> > involve a smaller subset of the entire network). 
--> 
--> I understand that this will occur when an edge RBridge does 
--> not have an
--> entry, but I assume that this will be a fairly rare 
--> condition.  Also, I
--> am expecting the number of flows through an edge RBridge to 
--> be much less
--> than throught a core RBridge, such that the number of MAC addresses
--> entries needed would be much less at an edge RBridge.  If a 
--> core RBridge
--> did not have a larger table, then it could get easily 
--> filled which would
--> require flooding of the BCNs much more than would occur 
--> naturally at an
--> edge RBridge.
--> 
--> > 
--> > 2) If, as you say, "there could be a significant amount of BCN
--> > traffic during congestion", then BCN suffers from fatal 
--> design flaws.
--> > If the need to occasionally flood BCN notifications contributes to
--> > this flaw, that is an issue (certainly), but it is one 
--> that is likely
--> > to be fixed at the same time as the current fatal flaw in BCN is
--> > fixed.     
--> 
--> I don't think it is fair to criticize the 802.1au group 
--> unless you have
--> better suggestions.  I suggest you contribute to that group 
--> if you feel
--> it is fatally broken.  In the meantime, RBridges should not 
--> compound the
--> problem.
--> 
--> > 
--> > -->
--> > --> >
--> > --> > 	2) it affects only implementations that are designed to
--> discard
--> > --> > 	potentially useful information in favor of reduced
--> memory needs
--> > --> > 	and
--> > --> >
--> > --> > 	3) it is a generic solution related to Caitlin's earlier
--> > remarks 
--> > --> > 	with respect to the relative numbers of "core RBridges"
--> and the
--> > --> > 	likelihood that next-hop RBridges on the Ingress RBridge
--> Tree
--> > are 
--> > --> > 	actually going to have an entry for the "unknown MAC
--> > destination" 
--> > --> > 	in the frame being flooded on the IRT.
--> > --> >
--> > 
--> > -- [SNIP] --
-->