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

Stewart Bryant <stbryant@cisco.com> Thu, 02 June 2011 10:44 UTC

Return-Path: <stbryant@cisco.com>
X-Original-To: pppext@ietfa.amsl.com
Delivered-To: pppext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CADB9E0736 for <pppext@ietfa.amsl.com>; Thu, 2 Jun 2011 03:44:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.427
X-Spam-Level:
X-Spam-Status: No, score=-110.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AiTd4XXRyDUK for <pppext@ietfa.amsl.com>; Thu, 2 Jun 2011 03:44:27 -0700 (PDT)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0956BE06EC for <pppext@ietf.org>; Thu, 2 Jun 2011 03:44:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=2782; q=dns/txt; s=iport; t=1307011467; x=1308221067; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=LR1Vlubf85nkyLKlpYcw79Fr6nkqnWV5FlNHFQ5pfRQ=; b=E60Aal+8cTIT2PyBQxSaCRyBA6iEbQpkTnhLX1SjkKzTnlbv8+aGMjf1 MiWSoiLT+7q0gSnFR6EabOE94hZ+etSEDjXitDFsqTcyICSBVaCJ9yM8+ CIK9UlN4Kdi7iAGAd6++7IpE6X8GklzwapSAEMg8/OQmOIWDH5L0aPVb1 w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAKpo502Q/khR/2dsb2JhbABTpjF3iHGhdoJ6DwGaZoYhBJBnjzE
X-IronPort-AV: E=Sophos;i="4.65,308,1304294400"; d="scan'208";a="33411713"
Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 02 Jun 2011 10:44:25 +0000
Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p52AiPNa022695; Thu, 2 Jun 2011 10:44:25 GMT
Received: from stbryant-mac2.local (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p52AiNW13740; Thu, 2 Jun 2011 11:44:23 +0100 (BST)
Message-ID: <4DE76994.3040807@cisco.com>
Date: Thu, 02 Jun 2011 11:44:36 +0100
From: Stewart Bryant <stbryant@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10
MIME-Version: 1.0
To: William Allen Simpson <william.allen.simpson@gmail.com>
References: <4DE51FC3.2070301@workingcode.com> <BANLkTikrJ217TLvKz61mCBcacgQUs317MA@mail.gmail.com> <4DE63C68.9070102@gmail.com> <4DE6528B.7070501@workingcode.com> <4DE659C1.2050306@cisco.com> <4DE65FD8.1090702@workingcode.com> <4DE6648E.7040605@cisco.com> <4DE66ADF.20002@gmail.com>
In-Reply-To: <4DE66ADF.20002@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: PPP Extensions <pppext@ietf.org>, rbridge@postel.org
Subject: Re: [Pppext] TRILL, IS-IS, and System ID
X-BeenThere: pppext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: stbryant@cisco.com
List-Id: PPP Extensions <pppext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pppext>, <mailto:pppext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pppext>
List-Post: <mailto:pppext@ietf.org>
List-Help: <mailto:pppext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pppext>, <mailto:pppext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Jun 2011 10:44:28 -0000

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