Re: [Isis-wg] WG Last Call for draft-ietf-isis-auto-conf-04

Marc Binderberger <marc@sniff.de> Mon, 30 January 2017 17:25 UTC

Return-Path: <marc@sniff.de>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDE57129531; Mon, 30 Jan 2017 09:25:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.098
X-Spam-Level:
X-Spam-Status: No, score=-5.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 1B4xRZ9MmfXY; Mon, 30 Jan 2017 09:25:48 -0800 (PST)
Received: from door.sniff.de (door.sniff.de [82.212.219.2]) by ietfa.amsl.com (Postfix) with ESMTP id E553D129474; Mon, 30 Jan 2017 09:25:47 -0800 (PST)
Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id A7E394BCFF8; Mon, 30 Jan 2017 17:25:45 +0000 (UTC)
Date: Mon, 30 Jan 2017 09:25:45 -0800
From: Marc Binderberger <marc@sniff.de>
To: Christian Hopps <chopps@chopps.org>, draft-ietf-isis-auto-conf@ietf.org
Message-ID: <20170130092545041657.86168d8e@sniff.de>
In-Reply-To: <87mvepkiag.fsf@chopps.org>
References: <87mvepkiag.fsf@chopps.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: GyazMail version 1.5.17
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/Xr0zxMpJFHHkbcb264ojo80MKLc>
Cc: isis-wg@ietf.org, isis-ads@ietf.org, isis-chairs@ietf.org
Subject: Re: [Isis-wg] WG Last Call for draft-ietf-isis-auto-conf-04
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.17
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, 30 Jan 2017 17:25:50 -0000

Hello draft authors, Christian and Hannes,

the authors have done a fine job with the document since 
"draft-liu-isis-auto-conf" and it contains (IMHO) enough material to create a 
standard document.


My problem with the draft (still) is: the auto-generation of the system ID 
has a flaw. The draft even admits this in section 3.4.6. "Double-Duplication 
of both System ID and Router-Fingerprint" when it states

   In the pathological case the generation of a new version of an LSP by
   one of the "twins" will cause the other twin to generate the same LSP
   with a higher sequence number - and oscillation will continue without
   achieving LSPDB synchronization.


The draft is inspired by RFC7503 but does not realize that RFC7503 de-facto 
says "you need to have a unique router fingerprint". Period. Instead the 
draft tries to solve the situation when system ID and fingerprint are not 
unique, which is going in a circle as the fingerprint's main purpose is to 
make LSPs distinguishable due to it's uniqueness.

I'm sure some implementations exists and tests have been done but the 
algorithm described in the draft has effectively a race condition. You don't 
see them in lab tests but once it has been deployed widely enough you will 
hit it (well, the customers will).


The main problem to me seems a lack of ideas how to generate a unique 
fingerprint. Hardware-based information are an obvious choice but not the 
only way to have unique information. Today we don't use classic ROM anymore, 
it's typically a flash memory, so even when the hardware has no serial 
number, no burned-in MAC etc. you can still store a unique serial number (per 
manufacturer) on the flash while the software is programmed into the flash.


One question to the authors: as we want to solve the situation where no 
burned-in MAC address exists, are you okay with the possibility that multiple 
IS-IS speakers using the same source MAC address at the same time ?  Assuming 
that the system ID and the MAC are kept in-sync this is likely covered by 
section 3.4.3 "IS-IS System ID Duplication Detection and Resolution" ?  
Should this be mentioned somewhere?


Another comment to the authors, chairs and WG: what the creation of unique 
6-byte system IDs is doing is creating unique MAC addresses for hardware with 
no burned-in address - another reason why the draft is relevant and 
standard-worthy in my opinion.


To summarize: I'm not happy standardizing the draft with the described 
algorithm. But I do support the draft's overall goal and think it's relevant 
and should be standardized.


Regards, Marc




> Hi Folks,
> 
> We are starting a WG Last Call for
> 
>   "ISIS Auto-Configuration"
>   - https://datatracker.ietf.org/doc/draft-ietf-isis-auto-conf/
> 
> The WGLC will expire in 2 weeks on Jan 31, 2017.