[rbridge] Learning endnode locations (was something like "encoding IS-IS encapsulation")

[Eric Gray (LO/EUS)]

Radia,

	See in-line below...

Thanks!

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Radia Perlman [mailto:Radia.Perlman at sun.com] 
> Sent: Tuesday, May 22, 2007 12:43 AM
> To: Eric Gray (LO/EUS)
> Cc: Silvano Gai; Rbridge at postel.org
> Subject: Re: [rbridge] Learning endnode locations (was 
> something like "encoding IS-IS encapsulation")
> Importance: High
> 
> A subtle difference:
> 
> Eric Gray (LO/EUS) wrote:
> > 	I would qualify this somewhat differently: I would say
> > "MUST be capable of MAC learning via data-frame examination
> > and MAY be configurable for learning from IS-IS advertisement
> > - either in addition to MAC learning, or in lieu of it.  The
> > default configuration is with MAC learning from data frames 
> > in operation (enabled)."
> >   
> The problem with being able to turn off learning from data 
> packets is if not all MAC addresses are advertised, then that
> RBridge will always flood those MAC addresses.

That would be why it would have to be a common configuration 
across devices deployed in a single campus.

Note that this would - in my suggested modification - have
required explicit configuration of devices to turn off the
capability.  That SHOULD only happen if a network operator
has reason to believe it will work.

> 
> How about that any MAC addresses learned through 
> advertisements always take precedence
> over any learned through data packets?

I really do have issues with trying to be clever like this.

If - as I suggested - it is desirable to not learn from the
data frames, why go through the motions?

My concern is that - the way Silvano and yourself have put
it prior to my suggestion - it would be arguable that an
implementation that is configurable not to learn from data
frames would be non-compliant.  And that is rediculous, of
course.

If you want the default behavior to be to learn from data
frames, then that is what you specify.  You don't say that
is what you MUST do, you simply say that that is the default
learning mode and it MUST be supported as such in compliant
implementations.

> 
> You said:
>  >>The reason I would characterize it this way is that it
>  >>MAY be the case that there are applications for which learning
>  >>from data frames MUST be disabled.
> 
> What kind of application would be really bad to learn from 
> data packets, or are you  talking about the security aspect
> of not letting a rogue endnode confuse RBridges about
> the location of a duly enrolled endnode, that authenticated 
> to an RBridge? 

You know, if I knew this I could probably retire.  But my
crystal ball is a little murky when it comes to trying to
figure out why people do the things they do.

The fact is that it is possible to turn off MAC learning in 
many 802.1D compliant bridges.  I see little point in being
more restrictive here than is the case generally with 802.1D
bridging.

> If the latter, then it seems like saying that if you learn
> the location of endnode E from IS-IS, you do not change your
> mind about where E is based on data packets should answer
> that concern, right?

Maybe.  But if you're planning to ignore what you might learn
from data frames, then why MUST you do that sort of learning?

You're right, this is a subtle difference, but you're in the
business of defining what makes a compliant implementation.  I
am merely stating that saying that implementations MUST do it
(as opposed to MUST support it as a default mode) is more than
you need to say in order to achieve interoperability - hence,
it is also more than you SHOULD specify for compliance.

> 
> 
> Radia
> 
> 
>