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.
- [Isis-wg] WG Last Call for draft-ietf-isis-auto-c… Christian Hopps
- Re: [Isis-wg] WG Last Call for draft-ietf-isis-au… Acee Lindem (acee)
- Re: [Isis-wg] WG Last Call for draft-ietf-isis-au… Les Ginsberg (ginsberg)
- Re: [Isis-wg] WG Last Call for draft-ietf-isis-au… Acee Lindem (acee)
- Re: [Isis-wg] WG Last Call for draft-ietf-isis-au… Les Ginsberg (ginsberg)
- Re: [Isis-wg] WG Last Call for draft-ietf-isis-au… Acee Lindem (acee)
- Re: [Isis-wg] WG Last Call for draft-ietf-isis-au… Acee Lindem (acee)
- Re: [Isis-wg] WG Last Call for draft-ietf-isis-au… Marc Binderberger
- Re: [Isis-wg] WG Last Call for draft-ietf-isis-au… Les Ginsberg (ginsberg)
- Re: [Isis-wg] WG Last Call for draft-ietf-isis-au… Marc Binderberger
- Re: [Isis-wg] WG Last Call for draft-ietf-isis-au… Liubing (Leo)