Re: [Pppext] TRILL, IS-IS, and System ID

[Stewart Bryant <[e-mail]>]

On 01/06/2011 17:37, William Allen Simpson wrote:
> On 6/1/11 12:10 PM, Stewart Bryant wrote:
>> On 01/06/2011 16:50, James Carlson wrote:
>>> Stewart Bryant wrote:
>>>>> All that said, I don't really care. This is a tempest in a teapot. I
>>>>> can mash together both texts if the Routing ADs are willing to 
>>>>> accept a
>>>>> passing reference here to a draft that, in their words, hasn't 
>>>>> even been
>>>>> considered by the IS-IS community.
>>>> James,
>>>>
>>>> I believe that any departure from the text in ISO10589 needs
>>>> to be discussed in the ISIS WG.
>
> Please point to the text in ISO10589 on configuring System Identifiers.
>
> Quote the section and page.

The following text:

ISO/IEC 10589:2002(E)
Page15
7.1.4    Administration and deployment of systems in a routeing domain
"It is the responsibility of the routeing domain administrative 
authority to enforce the requirements stated below in this clause"

ISO/IEC 10589:2002(E)
Page16 section (a) point 2
"Each system in an area must have an unambiguous ID; that is, no two 
systems (IS or ES) in an area may use the same ID value."

ISO/IEC 10589:2002(E)
Page16 section (b) point 1
"Each Level 2 Intermediate system within a routeing domain must have an 
unambiguous value for its ID field; that is,
no two level 2 ISs in a routeing domain can have the same value in their 
ID fields."

ISO/IEC 10589:2002(E)
Page148 Informational Annex B.1.1.3 The identifier (id) field
para 3
"Second, a considerable savings can be obtained in manual address 
administration for all systems in the routeing domain. If the ID is 
chosen from the ISO 8802 48-bit address space (represented as a sequence 
of 6 octets as specified in ISO/IEC 10039), the ID is known to be 
globally unique. Furthermore, since LAN systems conforming to ISO 8802 
often have their 48-bit MAC address stored in ROM locally, each system 
can be guaranteed to have a globally unambiguous NET and NSAP(s) without 
centralised address administration at the area level2). This not only 
eliminates administrative overhead, but also drastically reduces the 
possibility of duplicate NSAP addresses, which are illegal, difficult to 
diagnose, and often extremely difficult to isolate."

Seems to fully describe the intent of the authors.


> Please point to the text in ISO10589 on autonomously resolving 
> conflicting
> System Identifiers.
>
> Quote the section and page.
The text above seems to make it clear that the specifcation requires
resolution at either configuration or manufacturing time.

>
> Heck, I've not seen any reference to duplicate System Identifiers in
> ISO10589 anywhere.  Perhaps the standardese escaped my notice?

Please see Annex B.1.1.3

Stewart