[rbridge] Consensus Check: Configure ports to disable end station traffic

[Anoop Ghanwani]

Well, this can be seen as more than an optimization.
It could be seen as a security feature.

For example, with 802.1Q bridges, we have configurations
for "Admit VLAN-tagged frames" or "Admit all" on each
port.  This does not affect interoperability in any
way.  However, it just says that the switch port is
not willing to admit untagged traffic.  They could
have just left this out of the spec and untagged
traffic would have gotten the PVID and the world
would have done just fine. 

Going back to the example that has been pointed
out by folks where ARP breaks.  In 802.1Q, if an 
end station moves from a port that admits untagged
traffic to a port that doesn't admit untagged traffic
then things would break there as well.

In any case, I don't know why folks are making 
such a big deal about this.  Since it doesn't affect
interoperability, it's not required in the spec.
But the spec already has TONS of informational
material, so I don't see why adding something 
like this is a problem - something which actually
helps the implementer.

Anoop

> -----Original Message-----
> From: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On Behalf Of Dinesh G Dutt
> Sent: Wednesday, January 09, 2008 8:05 AM
> To: James Carlson
> Cc: Rbridge at postel.org; Joe Touch
> Subject: Re: [rbridge] Consensus Check: Configure portsto 
> disable end stationtraffic
> 
> I agree with James' position. 802.1d bridges do such 
> optimizations without their being specified in the spec. This 
> seems like a box-specific optimization and I don't see a need 
> for something like this in the spec.
> 
> Dinesh
> James Carlson wrote:
> > 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.)
> >
> >   
> 
> --
> We make our world significant by the courage of our questions and by 
> the depth of our answers.                               - Carl Sagan
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>