[rbridge] Consensus Call: MAC learning timers

[Eastlake III Donald-LDE008]

The consensus at the Chicago meeting that the MAC address learning
timers in Rbridges should follow the IEEE 802.1-2005 (Section 8.8.3)
recommendations is confirmed.

Donald & Erik

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Eastlake III Donald-LDE008
Sent: Monday, September 17, 2007 1:37 AM
To: Joe Touch; James Carlson
Cc: Rbridge at postel.org
Subject: Re: [rbridge] Consensus Check: MAC learning timers

It's just a recommendation in the IEEE 802.1Q-2005 Standard as quoted
below.

Donald


>From IEEE 802.1Q-2005, Section 8.8.3, "Dynamic Filtering Entries", page
56:


The ageing out of Dynamic Filtering Entries ensures that end stations
that have been moved to a different part of the network will not be
permanently prevented from receiving frames. It also takes account of
changes in the active topology of the network that can cause end
stations to appear to move from the point of view of the bridge; i.e.,
the path to those end stations subsequently lies through a different
Bridge Port.

The Ageing Time may be set by management (Clause 12). A range of
applicable values and a recommended default is specified in Table 8-3;
this is suggested to remove the need for explicit configuration in most
cases. If the value of Ageing Time can be set by management, the Bridge
shall have the capability to use values in the range specified, with a
granularity of 1 s.

              Table 8-3-Ageing time parameter value

    Parameter        Recommended Default Value        Range
   Ageing Time         300.0 s.                     10.0 - 1,000,000.0s

NOTE 4-The granularity is specified in order to establish a common basis
for the granularity expressed in the management operations defined in
Clause 12, not to constrain the granularity of the actual timer
supported by a conformant implementation. If the implementation supports
a granularity other than 1 s, then it is possible that the value read
back by management following a Set operation will not match the actual
value expressed in the Set.

 

-----Original Message-----
From: Joe Touch [mailto:touch at ISI.EDU] 
Sent: Friday, September 07, 2007 7:30 PM
To: James Carlson
Cc: Eastlake III Donald-LDE008; Rbridge at postel.org
Subject: Re: [rbridge] Consensus Check: MAC learning timers



James Carlson wrote:
> Joe Touch writes:
>> James Carlson wrote:
>>> Instead, our role is to design TRILL, and specify what's _required_
to
>>> make that work.  Is there an issue here that, if someone had a good
>>> reason to use some other set of defaults for these parameters, doing
>>> so would break TRILL?
>> I'm concerned about breaking the non-TRILL devices by TRILL behavior.
If
>> our caches have timeouts different from theirs, then the overall
system
>> won't be as plug-and-play -- or, more specifically, more
'replug-and-play'.
>>
>> That's why we're recommending IEEE values and defaults; that didn't
come
>> out of the blue.
> 
> Yes, and that's precisely the reason to "recommend" those defaults --
> as in BCP 14 "SHOULD."  I never did suggest that they came out of the
> blue or that anyone ought to ignore them.
> 
> However, as a matter of operating TRILL, they don't appear (to me at
> least) to be key issues that will cause TRILL failure.  That means
> they're not a "MUST."

That's fine. Let's hear what others think. I just want to make sure
we're picking the right one and understanding what we're picking; I
really didn't have an a-priori decision.

Joe

-- 
----------------------------------------------------------------------
Joe Touch                Sr. Network Engineer, USAF TSAT Space Segment
               Postel Center Director & Research Assoc. Prof., USC/ISI


_______________________________________________
rbridge mailing list
rbridge at postel.org
http://mailman.postel.org/mailman/listinfo/rbridge