[rbridge] [Pppext] TRILL, IS-IS, and System ID

[Stewart Bryant]

Bill

The discussion of suitable methods of ISIS and hence TRILL
SystemID uniqueness needs to take place on the ISIS list
(copied) regardless of the data link technology under
consideration.

James I am fine with your proposed text.

Stewart

Sending again with the ISIS WG in the cc list not the BCC list.


On 01/06/2011 14:19, William Allen Simpson wrote:
> 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
>>   d3e3e3 at gmail.com
>>
>>
>> On Tue, May 31, 2011 at 1:05 PM, James
>> Carlson<carlsonj at workingcode.com>  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<carlsonj at workingcode.com>
>>> _______________________________________________
>>> Pppext mailing list
>>> Pppext at ietf.org
>>> https://www.ietf.org/mailman/listinfo/pppext
>>>
>> _______________________________________________
>> Pppext mailing list
>> Pppext at ietf.org
>> https://www.ietf.org/mailman/listinfo/pppext
>>
>
>


-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html