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

Marc Binderberger <marc@sniff.de> Mon, 23 November 2015 11:02 UTC

Return-Path: <marc@sniff.de>
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 E754F1B2D17 for <isis-wg@ietfa.amsl.com>; Mon, 23 Nov 2015 03:02:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.135
X-Spam-Level:
X-Spam-Status: No, score=-2.135 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.585] 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 buXKN9LuBaa4 for <isis-wg@ietfa.amsl.com>; Mon, 23 Nov 2015 03:02:30 -0800 (PST)
Received: from door.sniff.de (door.sniff.de [82.212.219.2]) by ietfa.amsl.com (Postfix) with ESMTP id D16B01B2D18 for <isis-wg@ietf.org>; Mon, 23 Nov 2015 03:02:29 -0800 (PST)
Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id BC13D2AA0F; Mon, 23 Nov 2015 11:02:18 +0000 (GMT)
Date: Mon, 23 Nov 2015 03:02:17 -0800
From: Marc Binderberger <marc@sniff.de>
To: Liubing <leo.liubing@huawei.com>
Message-ID: <20151123030217881250.bcd126a7@sniff.de>
In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F45C23147E7@nkgeml506-mbx.china.huawei.com>
References: <8AE0F17B87264D4CAC7DE0AA6C406F45C23147E7@nkgeml506-mbx.china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: GyazMail version 1.5.16
Archived-At: <http://mailarchive.ietf.org/arch/msg/isis-wg/EPIXjKR--2seeEYT8128ELjJspA>
Cc: "isis-wg@ietf.org list" <isis-wg@ietf.org>
Subject: Re: [Isis-wg] ISIS-Autocon-06-//FW: New Version Notification for draft-liu-isis-auto-conf-06.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: Mon, 23 Nov 2015 11:02:32 -0000

Hello Bing and authors,

interesting topic, not just for homenet!


Reading the draft I had these thoughts:

* it looks "complicated" compared to RFC7503. This is likely due to the 
duplication of some parts of the procedure for hellos, for startup mode, for 
non-startup mode. Maybe the common parts could be extracted into separate 
sub-sections?

* the document seems to be somewhat contradictory regarding the router 
fingerprint. Section 3.3.1 refers to RFC7503. Which says in section 7.2.2: 
"[...] It MUST be based on hardware attributes that will not change across 
hard and soft restarts."
But your draft in section 3.3.3 mentions seeds based on System clock and 
Arbitrary received packet.

* you actually try to solve somewhat the "unsolvable": duplication of the 
router fingerprint. You describe how you can detect this and in section 3.3.3 
/ 3.3.4 what to do. But the point of the fingerprint is that it's uniqueness 
is demanded to be of such high quality that you ignore the unlikely event of 
a duplication. Who dares wins! :-) RFC7503 does not talk about fingerprint 
duplication.

If you think this quality can not be achieved then it would require a 
discussion why you think the detection you can do is sufficient. You can 
detect duplicated fingerprints when exchanging hellos. Now with N nodes the 
number of neighbors in your network is somewhere between N * O(1) and N * 
O(N) - it either a fixed, typically small number of cabled neighbors or a 
full mesh. To detect a duplication you need to compare everyone with 
everyone, which is O(N*N). For large N / large networks any duplicate 
detection from the "few" neighbors (N * O (1)) is a lucky hit against the 
O(N*N) and you better shut down than trying to fix it, IMHO. For small 
networks though you may have a chance to detect duplications with a high 
probability from the hellos.

Btw, there is an interesting document, RFC 4086 , about random generation.


* you write about the mix of autoconfig and non-autoconfig nodes:

          If there is no Router-Fingerprint TLV in the Hello message, it
          means a non-autoconfiguration router by accident connected to
          the auto-configuration domain or other unexpected bad
          behaviors.  In this case, the auto-configuration router MUST
          NOT form adjacency with the non-autoconfiguration router.

Sure we can make this restriction. This means we never expect a manually 
configured IS-IS router to talk to autoconfig ones? 


Regards, Marc




On Tue, 20 Oct 2015 08:27:58 +0000, Liubing (Leo) wrote:
> Hi Dear all,
> 
> Hi Dear all,
> 
> This version has some technical changes, according to discussion around 
> last IETF (mostly from Les Ginsberg).
> 
> For your convenient, the main technical revisions are listed below:
> 1. Added a "Start-up Mode" when doing duplication detection/resolution. 
> Accordingly, the Router-Fingerprint TLV added a flag to indicate the 
> Start-up mode; and the duplication procedures are also revised accordingly.
> 2. Added some description of duplication between neighbors. 
> 3. Added a usage of authentication TLV to be the HMAC-MD5 authentication 
> mode.
> And we have a new co-author Les Ginsberg who made great contribution to 
> improve the draft.
> 
> Your comments are welcome!
> 
> Best regards,
> Bing
> 
> -----Original Message-----
> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] 
> Sent: Monday, October 19, 2015 4:27 PM
> To: Bruno Decraene; Les Ginsberg; Ian Farrer; Bruno Decraene; Liubing 
> (Leo); Mikael Abrahamsson; Les Ginsberg; Mikael Abrahamsson; Ian Farrer; 
> Liubing (Leo)
> Subject: New Version Notification for draft-liu-isis-auto-conf-06.txt
> 
> 
> A new version of I-D, draft-liu-isis-auto-conf-06.txt has been successfully 
> submitted by Bing Liu and posted to the IETF repository.
> 
> Name:		draft-liu-isis-auto-conf
> Revision:	06
> Title:		ISIS Auto-Configuration
> Document date:	2015-10-19
> Group:		Individual Submission
> Pages:		14
> URL:            
> https://www.ietf.org/internet-drafts/draft-liu-isis-auto-conf-06.txt
> Status:         https://datatracker.ietf.org/doc/draft-liu-isis-auto-conf/
> Htmlized:       https://tools.ietf.org/html/draft-liu-isis-auto-conf-06
> Diff:           
> https://www.ietf.org/rfcdiff?url2=draft-liu-isis-auto-conf-06
> 
> Abstract:
>    This document specifies an IS-IS auto-configuration technology.  The
>    key mechanisms of this technology are IS-IS System ID self-
>    generation, duplication detection and duplication resolution.  This
>    technology fits the environment where plug-and-play is expected.
> 
>                                                                                   
> 
> 
> Please note that it may take a couple of minutes from the time of 
> submission until the htmlized version and diff are available at 
> tools.ietf.org.
> 
> The IETF Secretariat
> 
> _______________________________________________
> Isis-wg mailing list
> Isis-wg@ietf.org
> https://www.ietf.org/mailman/listinfo/isis-wg
>