[rbridge] Consensus Check: Configure ports todisable endstationtraffic

[Eric Gray]

James,

	Perhaps not quite orthogonal, but definitely not 
100 % correlated.

	I disagree that you would necessarily break the 
normal operation of end-stations running on the link.
I thought I had said that previosuly, so maybe I am
not getting your point.  However, I am pretty sure 
Joe was talking about "silent end stations" which is
pretty far from the "normal case" these days.

	Many of today's end stations would work, as long 
as you don't explicitly disable ARP (as in both sending
requests and receiving responses) because many of them 
do not rely on being discovered by flooding.

	Also, the notion of "known to be on the inside
of the network" is a trap people fall into if they were
not listening to the discussion in this working group 
from 18 to 24 months ago in which the point was made on
several occasions that the intended "topological" notion
of "inside the network" is not actually topological at
all.  Connect two links that appear to be "outside of the
network" and they are now "inside of the network."  The
apparent "connection" of two or more "outside links" is
a normal occurrence during network startup.  Connection
or disconnection of physical links is something that an
operator may not have direct control over.

	However, I agree that this is something that should 
be out of scope (avoiding these discussions entirely).
And for mostly the same reasons.  But I also thought I
said that already too...

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: James Carlson [mailto:james.d.carlson at sun.com] 
> Sent: Tuesday, January 08, 2008 2:51 PM
> To: Eric Gray
> Cc: Joe Touch; Rbridge at postel.org
> Subject: RE: [rbridge] Consensus Check: Configure ports 
> todisable endstationtraffic
> Importance: High
> 
> Eric Gray writes:
> > 	However I disagree that ARP failure is a specific intent
> > of the configuration option mentioned in Donald's "consensus
> > check" or that this is sufficient to somehow "enforce" a network
> > operator's intention that a link should remain "end-station free."
> [...]
> > 	Hence configuring an RBridge to disable certain types of
> > presumed wasteful traffic forwarding on a link is orthogonal to 
> > indentifying that link as end-station free.
> 
> I don't think it's quite orthogonal.  The two are related in that if
> you "optimize" away this "wasteful" traffic, you necessarily also
> break the operation of any ordinary end stations that may be present
> on that link, as Joe Touch was correctly pointing out.  Those nodes
> can't work normally, so you're already partway down the path to
> breaking those nodes intentionally.
> 
> But fair enough to observe that there are two different intents here.
> I think Anoop was arguing more forcefully in favor of having a more
> generic (and thus simpler) "no end-station on this link" option on the
> theory that some links may be "known" (by an administrator) to be on
> the inside of a network, and thus optimizing all of the end-station-
> related behavior away would be useful for some implementations.
> 
> It seems particularly attractive given that TRILL wants to encapsulate
> things.  If we were "only" bridging, this wouldn't be an issue.
> 
> I'd be ok with either intended option, but would slightly prefer not
> bothering to document this special link behavior, as it looks to me to
> be the sort of enhancement that vendors could cook up on their own
> without affecting either TRILL interoperability or ordinary RBridge
> operation.  It's not something I think is strictly _needed_ in the
> TRILL document in order to make it complete ... though it seems Anoop
> does.
> 
> -- 
> James Carlson, Solaris Networking              
> <james.d.carlson at sun.com>
> Sun Microsystems / 35 Network Drive        71.232W   Vox +1 
> 781 442 2084
> MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 
> 781 442 1677
>