[rbridge] Consensus Check: MAC learning timers
John Leslie
john at jlc.net
Thu Sep 6 18:45:47 PDT 2007
Joe Touch <touch at ISI.EDU> wrote:
> James Carlson wrote:
>> Joe Touch writes:
>>> Eastlake III Donald-LDE008 wrote:
>>>
>>>> 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.
>>
>>> Minor question:
>>>
>>> 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.
>
> I'd say MUST follow IEEE requirements.
I agree with James: absent something which falls apart, we should
avoid a MUST.
> I'm wondering how the IEEE spec's the defaults; if they're a MUST, then
> 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.
> I don't think it would be useful to diverge from those specs except
> 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>
More information about the rbridge
mailing list