Subject: [rbridge] Consensus Check: MAC learning timers

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Tue, 4 Sep 2007 08:34:59 -0400

This is a check via the mailing list to confirm or refute an apparent
consensus at the Chicago meeting:

   MAC address remembering timers in TRILL should have the same
   configuration limits and default as in 802.1Q-2005.

If no particular controversy arises over this in the next two weeks, we
will declare it to be the working group consensus.

Thanks,
Donald & Erik

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu, 06 Sep 2007 06:54:15 -0700

>    configuration limits and default as in 802.1Q-2005.

Minor nits:

replace "remembering" with "cache persistence"

replace "default" with "defaults" (isn't there more than one timer?)

Minor question:

Do we want a stronger wording, e.g., MUST, SHOULD (vs should), etc?

Joe

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

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/rbridge/attachments/20070906/493afcc6/signature.bin

---

From: james.d.carlson at sun.com (James Carlson)
Date: Thu, 6 Sep 2007 10:54:04 -0400

> Do we want a stronger wording, e.g., MUST, SHOULD (vs should), etc?

What would be the basis of the MUST?  Is there something in TRILL that
falls apart if an implementation fails to heed this advice?  I don't
see what the exact interoperability issue would be.

Lacking a clear interoperability issue for TRILL itself, SHOULD seems
right to me.  It means that implementations are required to follow
that IEEE standard unless they've got a good reason to do otherwise.

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu, 06 Sep 2007 17:22:58 -0700

> that IEEE standard unless they've got a good reason to do otherwise.

I'd say MUST follow IEEE requirements.

I'm wondering how the IEEE spec's the defaults; if they're a MUST, then
why wouldn't we follow suit? How would we know what would break with
intermediate bridges? If, alternately, the defaults are SHOULDs, then
ours can be too.

I don't think it would be useful to diverge from those specs except
where we deliberately need to.

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/rbridge/attachments/20070906/4f77c7d1/signature.bin

---

From: john at jlc.net (John Leslie)
Date: Thu, 6 Sep 2007 21:45:47 -0400

> I'd say MUST follow IEEE requirements.

   I agree with James: absent something which falls apart, we should
avoid a MUST.

> why wouldn't we follow suit?

   IEEE specs can change; ours (effectively) can't.

> How would we know what would break with intermediate bridges?

   That's what we're paid the big bucks for... ;^)

> If, alternately, the defaults are SHOULDs, then ours can be too.

   If theirs are MUSTs, why doesn't simply referencing them suffice.
If we put a MUST in our document, it should be because we know that
failure to implement it would harm interoperability of _our_
protocol.

> where we deliberately need to.

   IMHO, we face scaling issues that IEEE does not. It may not be easy
to foresee those effects of scaling, but we should at least leave
ourselves wiggle room to deal with them.

--
John Leslie <john at jlc.net>

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu, 06 Sep 2007 19:56:20 -0700

John Leslie wrote:
...
> ourselves wiggle room to deal with them.

Scaling is outside this work. We're not intended to scale beyond what
IEEE works for.

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/rbridge/attachments/20070906/b23dbb0e/signature.bin

---

From: james.d.carlson at sun.com (James Carlson)
Date: Fri, 7 Sep 2007 06:41:50 -0400

> I'd say MUST follow IEEE requirements.

Where's the TRILL requirement for this?

I'm saying SHOULD because our role here isn't to design IEEE
protocols, nor is it to "enforce" any rules set down by IEEE.

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?

If there's no such issue, then we don't need a "MUST."  Following the
IEEE norms becomes just an issue of good practice, and not a
fundamental requirement of the protocol.

I'm not talking about people who wantonly ignore standards.  There's
nothing we can do about that situation -- they'll ignore MUST just as
easily as they'll ignore the implication of SHOULD.  I'm talking about
requirements for TRILL itself.

> where we deliberately need to.

I'm not suggesting creating a divergence in actual values.  I'm
suggesting that we don't need to copy the IEEE language into the TRILL
documents _unless_ there's a specific TRILL-related issue to solve.

Using SHOULD doesn't actually diverge us from IEEE, even if they use
MUST.  It provides leeway for a savvy implementor to spurn IEEE's
mandate for the good of TRILL, _if_ that's actually the right thing to
do.  It still requires others to follow IEEE if they don't have that
"good reason."

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri, 07 Sep 2007 07:15:29 -0700

> reason to use some other set of defaults for these parameters, doing

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.

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/rbridge/attachments/20070907/5a3d53f5/signature.bin

---

From: james.d.carlson at sun.com (James Carlson)
Date: Fri, 7 Sep 2007 13:58:31 -0400

> That's why we're recommending IEEE values and defaults; that didn't come

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

I think it's an important distinction, but I suppose it's not a hill
worth dying on.  If you feel that we simply cannot proceed without a
"MUST" here, or a copy of some IEEE text, then I'll relent.  It's not
as though I was going to ignore those defaults myself anyway.

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri, 07 Sep 2007 16:30:04 -0700

> least) to be key issues that will cause TRILL failure.  That means

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/rbridge/attachments/20070907/e03bd427/signature.bin

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Mon, 17 Sep 2007 01:36:55 -0400

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

Joe