[rbridge] Consensus Check: Configure ports todisable end stationtraffic

[Eric Gray]

James,

	I agree with you and Anoop on one point: if configuration
assumes the absence of end-stations on a local link and end 
stations are either already present, or are later are added on 
that local link, then this is a configuration/deployment error.

	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."

	Certainly ARP will not work, but neither will any other 
broadcast or (non-IP) multicast based application or protocol.
That is essentially a side effect, however, and not the intent
of the consensus originally proposed.  In the original proposed
consensus (which I notice has been removed from this thread),
the intention was to eliminate wasteful forwarding to a link 
that contains no end-stations.

	While I believe the consensus proposal has been misworded
in such a way that it implies configuration would be used to 
indicate that a link has no end-stations, merely disabling the
forwarding of ARP (and other similar traffic) will not prevent
end-stations from being added to a link - and working on that
link - nor will it necessarily prevent existing end-stations 
from continuing to work on such a link.

	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.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On Behalf Of James Carlson
> Sent: Monday, January 07, 2008 3:39 PM
> To: Joe Touch
> Cc: Rbridge at postel.org
> Subject: Re: [rbridge] Consensus Check: Configure ports 
> todisable end stationtraffic
> 
> Joe Touch writes:
> > I'm concerned about the case where an end station moves and doesn't 
> > announce itself. There's no requirement in ethernet to do 
> so, and such a 
> > station would never be discovered if we don't flood 
> broadcast to all links.
> > 
> > I.e., the optimization below is a recipe for ARP failure in 
> such cases. 
> > I disagree with it.
> 
> That "failure" is exactly the intent.
> 
> In other words, if you connect an end station to a special internal
> network that is intentionally designed by a network administrator
> _not_ to have end stations on it at all (which is what this
> configuration option specifies), then you've made a mistake, and you
> should _expect_ the node's attempts to communicate to fail miserably.
> 
> Obviously, the default should be to forward these messages (ports
> can't be "TRILL-only" type by default), but why try to prohibit
> implementations from offering an option if vendors so choose?  ARP
> failure modes for nodes that shouldn't be there at all shouldn't be a
> reason for a prohibition.
> 
> On the consensus proposal, I don't see a real reason why a description
> of such an option needs to be in the spec -- it seems to me that an
> implementation could provide such a feature under the guise of a
> "local optimization" without needing this group's permission to do so
> -- but if it is going to be there as an option, I'd weakly support it.
> (Really ... do we think we can outlaw vendor features or that we need
> to explicitly endorse each one?)
> 
> (I say "weakly" because _every_ option added increases complexity, and
> that's one of the important problems.  But if it's somehow crucial,
> then ok.)
> 
> -- 
> 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
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>