Re: [Isis-wg] ISIS-autoconf-04 submitted //FW: New Version Notification for draft-liu-isis-auto-conf-04.txt

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Fri, 26 June 2015 03:01 UTC

Return-Path: <ginsberg@cisco.com>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C78B1B31AA for <isis-wg@ietfa.amsl.com>; Thu, 25 Jun 2015 20:01:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iGmptxfzM-AY for <isis-wg@ietfa.amsl.com>; Thu, 25 Jun 2015 20:01:25 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8C7F1B319E for <isis-wg@ietf.org>; Thu, 25 Jun 2015 20:01:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7757; q=dns/txt; s=iport; t=1435287685; x=1436497285; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=qClC7NEtplK/5wMBbUSESE3O636A2nweb8IzjLuIHC4=; b=FfdCJ/cNZBwWYjaq1awTZJJL1obYnClx6KOHc5dOjELZ85OXdBKBc56O Uj7wfWeediu4BVwbpemidnFCHpViHChX0xTy2IbKiSlQeLW1INv9ictBJ dZ58U4btD0kd2TPoD8QmGtDg3oGC8HyEDoguQ0qidV+JKSmMDaRg1zuyz Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AWBQAXv4xV/4wNJK1YA4MRgTm4Y4wSAoE7PBABAQEBAQEBgQqEIgEBAQQ6PRICAQgiDgYQMhwJAgQBGhOIFM5vAQEBAQEBAQEBAQEBAQEBAQEBGotKhFU4DAUHgn+BFAEEhwOFEYRxgwEBhy+FXIQQkm8mY4EpARsVgT2CNYECAQEB
X-IronPort-AV: E=Sophos;i="5.13,681,1427760000"; d="scan'208";a="162986779"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-8.cisco.com with ESMTP; 26 Jun 2015 03:01:24 +0000
Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t5Q31NGs022254 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Jun 2015 03:01:23 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.112]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Thu, 25 Jun 2015 22:01:23 -0500
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: "Liubing (Leo)" <leo.liubing@huawei.com>, "isis-wg@ietf.org list" <isis-wg@ietf.org>
Thread-Topic: ISIS-autoconf-04 submitted //FW: New Version Notification for draft-liu-isis-auto-conf-04.txt
Thread-Index: AQHQmsUvhOb/9lHMUk2S32rA0gaCAZ2+NYzw
Date: Fri, 26 Jun 2015 03:01:22 +0000
Message-ID: <F3ADE4747C9E124B89F0ED2180CC814F5947F857@xmb-aln-x02.cisco.com>
References: <8AE0F17B87264D4CAC7DE0AA6C406F45A678E17E@nkgeml506-mbx.china.huawei.com>
In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F45A678E17E@nkgeml506-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [128.107.163.34]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/isis-wg/yE473Gd6UTFVi-Xg__ArDaE2ce0>
Subject: Re: [Isis-wg] ISIS-autoconf-04 submitted //FW: New Version Notification for draft-liu-isis-auto-conf-04.txt
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/isis-wg/>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jun 2015 03:01:27 -0000

Some (somewhat extensive) comments on the draft.

Overall Comments
------------------------------

1)You have completely neglected the case where duplicate system-id occurs between two directly connected routers. In such a case no neighbor can be formed and therefore no LSPs can be exchanged - which means no Fingerprint TLV is available for conflict resolution. Please see RFC 7503 Section 7.1.

There are a number of choices here:

a)You could use the MAC address as the tiebreaker (smaller MAC address changes its system-id). This of course only works on Ethernet and depends on the MAC address of the interface NOT being the source of the system-id. :-)

b)If you restrict yourself to IPv6 you could use the solution defined in RFC 7503 Section 7.1. But as you want to address IPv4 and IPv6 (no objection from me) that does not seem to be viable.

c)You could include the Fingerprint TLV in the hellos and be able to use that as a tiebreaker. This seems the most robust.

2)What you have written in the draft defines a way to make conflicts low probability and defines a means of resolving conflicts when they occur - but it does not attempt to minimize the occurrence of system-id changes for a router once it has become fully operational. This should also be a goal. To make this a reality I propose some additions:

Define a "startup mode" wherein a router does not start advertising neighbors/reachability and/or sets the OL bit until after an initial delay has expired. During this time it acquires the LSPDB and verifies that duplicate system-id is not detected. If duplicate system-id is detected we make the starting node the one which changes its system-id regardless of fingerprint content. This has minimal impact on a running network because the startup node is not yet being used for forwarding traffic. Once duplicate system-id has been resolved (if necessary) the router begins normal operation.

If two routers are both in startup mode (or both NOT in startup mode) and duplicate system-id is detected then we use the rules set forth in the draft to determine which one changes its system-id based on fingerprint.

Indication of being in startup mode can easily be included in the fingerprint TLV with a flag.

Specific Comments on Sections within the draft
----------------------------------------------------------------

Section 1.  Introduction

LES: Interesting that you don't mention ISO 10589 at all. That is the document that defines the base protocol - which RFC 1195,RFC 5308, and many others extend.


  3.  NET duplication detection and resolution

LES: More correctly "NET" should be replaced by "system-id".


Section 3.1.  IS-IS Default Configuration

LES: You might want to consider an option that allows P2P mode on Ethernet interfaces as that is quite a pervasive deployment these days.

Section 3.2.  IS-IS NET Generation
  ...

   o  Area address

         This field is 1 to 13 octets in length.  In IS-IS auto-
         configuration, this field MUST be 0 in 13 octets length.

LES: What does "0 in 13" mean? Do you mean that the area address MUST be 13 octets of all 0? Do you mean the area address can be 0 octets long (omitted) - which would be a violation of the protocol? Please clarify. 

     o  NSEL

         This field is the N-selector, and is 1 octet in length.  In IS-
         IS auto-configuration, it SHOULD be set to "00".

LES: The NSEL MUST be "00" as per ISO 10589. Anything else would be a protocol violation. Please revise the text accordingly - or eliminate it entirely as unnecessary. 

Section 3.3.  IS-IS NET Duplication Detection and Resolution

LES: This entire section is a discussion of "duplicate system-id detection/resolution" - NOT duplicate NET. The area address portion of the NET is not subject to duplicate detection - and since all routers will be L1 any router with a different area address will be ignored i.e. we will not form adjacencies to it under base protocol rules. Please rename the section  and revise the text appropriately.

Section 3.3.2.  NET Duplication Detection and Resolution Procedures

   1) Flood the Router-Fingerprint TLVs

      When an IS-IS auto-configuration router gets online, it MUST
      include the Router-Fingerprint TLV in the first originated level-1
      LSP.  Then all the routers in the area could receive the
      information in the TLV.

LES: You mean Fingerprint TLV MUST be in LSP #0?? That seems appropriate - but it needs to be stated that way.

Section 3.3.3.  SysID and Router-Fingerprint Generation Considerations

LES: It is also desirable that system-id - once chosen - should be retained across reboot.

Section 3.3.4.  Double-Duplication of both NET and Router-Fingerprint

LES: I am not following this logic. You state at the beginning of the section that fingerprint generation might be constrained - presumably because an early implementation of this functionality might not be robust. You then go on to say that if this leads to "double duplication" that routers should ("on the fly"??) be able to enhance their fingerprint. This would seem to require an implementation upgrade. Otherwise why wouldn't the fingerprint be enhanced initially? 

Or are you suggesting that - in order to save space - we send only a simple fingerprint - and if we hit double duplication we respond by sending a lengthier fingerprint? In which case you have a very imprecise definition of when "double duplication" can be declared.

Section 3.4.1.  Authentication TLV

LES: If security is a real concern I think cleartext password has been proven to be of not much value. I would suggest that you provide the ability to specify a password which would be used in MD5 authentication (RFC 5304) or perhaps Generic Crypto (RFC 5310). If security is not a concern, then no password/authentication is fine. If you choose a unique area address then it is unlikely that a non-autoconf router would be configured w the same area address so you would never form an adjacency with it.

Section 3.4.2.  Wide Metric TLV

LES: I think you have to use MUST here because routers using wide metric TLVs will not interoperate w routers using narrow metric TLVs - though they will form adjacencies. Also, there is more to wide metrics than 1 TLV. For completeness you should specify the list of TLVs which can/cannot be used (TLV 22, 135, etc.). Also, are you forbidding the use of MT (e.g. TLV 222, 235, etc.)?

Section 3.4.3.  Dynamic Host Name TLV

LES: "vendor" or "device type" won't provide uniqueness - not very helpful to have a bunch of devices all named "vendor-a". Serial #s - while likely unique - might be reasonable - assuming they are less cryptic than the chosen system-id - which is debatable. Unless there is a convenient way to get a name that the user can easily recognize I don't see much value here.

Section 3.4.4.  Purge Originator Identification TLV

LES: I don't object to this, but I don't see why it needs to be mentioned. It does not affect interoperability and it's use or non-use isn't specific to autoconfigured networks.

Section 3.5.1.  Adjacency Formation

LES: You could simply suggest using the defaults defined in ISO 10589 - which are the values you have mentioned.

Section 3.5.2.  Co-existing with Other IGP Auto-configuration

LES: So what you stated in Section 2 about "Interworking with other routing protocols" being out of scope apparently isn't true?? Otherwise why did you write this section?

   Les