Re: TRILL, IS-IS, and System ID

Obviously, Stewart is wrong.  We've gone to great lengths to ensure PPP is
zero configuration.  We never need to buy and burn IEEE MAC identifiers.

TRILL seems to have zero configuration design goals, too.

Therefore, James is also wrong.  This is not an operator issue.  You
should *NOT* put this burden on operators.  It would really help for
anybody with aspirations of designing protocols to have actually been an
operator, and pay attention to discussions on the NANOG list!

As a personal example, just last summer I spent *many* hours trying to
figure our what was happening as a political campaign couldn't get their
wireless access point to work.  It was very flaky.  At long last, traces
discovered that the AP had a conflicting MAC with another device at
another office somewhere else in the Comcast region.  You cannot expect
political operatives (and quite frankly any other business) to fix this.

Therefore, this is a protocol design issue.  I've been trying to live with
the various compromises on language, but this goes too far!

Technically, that MUST is certainly wrong.  There's no guarantee of
uniqueness, and uniqueness is required by both ISIS and TRILL.

Moreover, there's no guarantee that a hot swappable or card or board based
device will not become (even temporarily) a PPP-only device.  To meet that
MUST, every vendor of PPP devices will have to burn an IEEE number for
every device.  Yet, it still might not work!

That's simply wrong!  There's a lot of nonsense in IETF protocols, but we
don't have to add more here and now.


On 5/31/11 2:20 PM, Donald Eastlake wrote:
> James,
>
> I'm fine with your suggested tweak of Stewart Bryant's wording.
>
> Thanks,
> Donald
> =============================
>   Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>   155 Beaver Street
>   Milford, MA 01757 USA
>   [email protected]
>
>
> On Tue, May 31, 2011 at 1:05 PM, James Carlson<[email protected]>  wrote:
>> As part of IETF review, the Routing ADs are looking over
>> draft-ietf-pppext-trill-protocol-06.  Not too surprising to me -- given
>> that I still think it's far out of scope -- the text concerning IS-IS
>> System IDs is causing trouble in that review.  See this thread:
>>
>> http://www.ietf.org/mail-archive/web/rtg-dir/current/threads.html#01533
>>
>> I wish I could leave the worms safely in the can, but it's looking like
>> that might not be one of the options.
>>
>> Instead of the reference to Bill Simpson's draft, Stewart Bryant
>> suggested replacement text like this:
>>
>>   ISO/IEC 10589 states that it is the responsibility of the routeing
>>   domain administrative authority to enforce the uniqueness of the
>>   system ID. In cases where a zero configuration system is
>>   supplied the system manufacturer MUST install a suitable
>>   unique identifier at manufacturing time. One way to achieve
>>   this is for the manufacturer to use a unique IEEE MAC address
>>   following the allocation procedures normally used in the
>>   manufacture of an Ethernet interface.
>>
>> This tosses the issue back into the implementor's lap (which,
>> incidentally, is exactly where I think the problem belongs), and
>> suggests an existing and known solution where a MAC identifier may be
>> allocated for the system itself and used as a global ID to construct the
>> necessary IS-IS System ID.
>>
>> For use in this draft, I would alter the wording slightly to indicate
>> that zero-configuration is strongly preferred for TRILL (as guidance),
>> and that obtaining a suitable identifier is the implementor's
>> responsibility, rather than just saying "in cases where."
>>
>> Would this change fly without breaking consensus?  Or do we have to
>> start over?
>>
>> --
>> James Carlson         42.703N 71.076W<[email protected]>
>> _______________________________________________
>> Pppext mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/pppext
>>
> _______________________________________________
> Pppext mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/pppext
>

_______________________________________________
Pppext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pppext