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

"Les Ginsberg (ginsberg)" <> Tue, 31 January 2017 05:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 811EF1296A7; Mon, 30 Jan 2017 21:47:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.721
X-Spam-Status: No, score=-17.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id M77PZB2SHOK4; Mon, 30 Jan 2017 21:47:21 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ACE7612940F; Mon, 30 Jan 2017 21:47:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=7686; q=dns/txt; s=iport; t=1485841640; x=1487051240; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=+mXQQ3iszB3LJ1id3IZ83/M88ZHqIjSdA58jqjUoMEk=; b=WS+EqruvaxqVBMai1esQ+AvGAWPQ/3/FxJPxe+4Nb4z7O+pYISy7L/X5 hmV6inq/lSwkC8mOyn+jAxR1JteA4l+nw1MQ8rp93TbfkuUYdrVZCtoWy pEReA5ZcH9BztMvVj1FnyolA3g0hKaY2eCufOzRqy6BBxmLyG9QDTgr4c 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DLAgDuI5BY/5ldJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgykrYYEJB59dlTKCDSqCQoM2AoIqQBcBAgEBAQEBAQFiKIRpAQE?= =?us-ascii?q?BAwEdHTQLBQcEAgEIEQQBAR8JBzIUCQgCBAENBQgTiUoIDq0sixwBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEYBYZLhG+KLgWIfBGHa4pdAYZmiwuCAoUViWqSfgEhAzN?= =?us-ascii?q?TeBU7hjl1hzaBDAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.33,313,1477958400"; d="scan'208";a="206104139"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Jan 2017 05:47:19 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id v0V5lJFP026840 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 31 Jan 2017 05:47:19 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 30 Jan 2017 23:47:18 -0600
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Mon, 30 Jan 2017 23:47:18 -0600
From: "Les Ginsberg (ginsberg)" <>
To: Marc Binderberger <>, Christian Hopps <>, "" <>
Thread-Topic: [Isis-wg] WG Last Call for draft-ietf-isis-auto-conf-04
Thread-Index: AQHScLlYCVfM58BMRE+A/OR/DV4RwqFRvumAgABekuA=
Date: Tue, 31 Jan 2017 05:47:18 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>, "" <>, "" <>
Subject: Re: [Isis-wg] WG Last Call for draft-ietf-isis-auto-conf-04
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF IS-IS working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 31 Jan 2017 05:47:23 -0000

Marc -

Thanx for the thoughtful review.

> -----Original Message-----
> From: Marc Binderberger []
> Sent: Monday, January 30, 2017 9:26 AM
> To: Christian Hopps;
> Cc:;;
> Subject: Re: [Isis-wg] WG Last Call for draft-ietf-isis-auto-conf-04
> 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.
[Les:] It seems you have misunderstood Section 3.4.6. This section is NOT pointing out a limitation of the solution proposed - it is pointing out the need to distinguish the "benign" case of "double duplication that will occur because a restarting router may receive stale copies of its own LSPs from its previous incarnation and the actual "pathological" case where two different routers actually do have the same system ID and fingerprint TLV. It then goes to specify logic on how to distinguish these cases.

If we failed to distinguish these cases every time a router restarted within LSP Maxage interval it would needlessly modify its systemID/fingerprint simply because it received a stale copy of one of its own LSPs. We want to avoid that and have defined a procedure to do so.

> 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.
[Les:]System ID uniqueness is a requirement of the base protocol specification The draft also specifies (Section 3.3) that the fingerprint MUST be unique. I do not see any circularity.

I am quite willing to admit that the authors of RFC 7503 may be smarter than me (though not necessarily smarter than my co-authors :-) ) - but I do not see that the substance of what is defined in the two documents differs. Both documents require detection of router/system ID duplication as well as fingerprint duplication. Both make recommendations as to how to resolve such duplication.

Here are some relevant excerpts from RFC 7503:

"[fingerprint]  SHOULD be constructed from the
   concatenation of a number of local values that themselves have a high
   likelihood of uniqueness,

" The OSPFv3 router
   SHOULD reduce the possibility of a subsequent Router ID collision by
   checking the Link State Database (LSDB) for an OSPFv3
   Autoconfiguration LSA with the newly selected Router ID and a
   different Router-Hardware-Fingerprint"

By comparison, the IS-IS autoconfig draft says:

" there are some resources which can
   provide an extremely high probability of uniqueness thus could be
   used as seeds to derive distinguisher..."

 " suggests using the MAC address as System ID and generating a
   pseudo-random number based on another seed (such as the memory
   address of a certain variable in the program) as the Router-

" to minimze the likelihood of double-duplication reoccuring,
   routers SHOULD have more entropies available.  One simple way to
   achieve this is to add the LSP sequence number..."

These seem to me to be qualitatively equivalent guidelines. And I do not see that RFC 7503 claims to have defined a guaranteed solution for fingerprint/router ID duplication. Just like the IS-IS draft it suggests procedures which have a high probability of success but which might have to be executed multiple times before successful resolution.

> 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 ?

[Les:] Duplicate MAC addresses are a different issue not directly related to systemID/fingerprint - nor autoconfig. They are only a problem when the two boxes are directly connected to the same media. Please see the recent discussion of this point between Acee and myself on the WG mailing list.

An implementation is free to implement duplicate MAC resolution procedures if it wishes - but doing so requires programmable MAC addresses which is NOT a requirement to support autoconfig.  Resolution of this issue is a base protocol issue and is out of scope for this draft.

> 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?
[Les:] It is a common - and useful - convention to use a MAC address as the system ID - which the draft recommends as the initial value, but if this results in systemID duplication then clearly something else must be used. This does NOT imply that MAC address should be changed. The procedures used to do that are purposely left undefined, but we have made some suggestions in Section 3.4.5.

I would argue that leaving the exact mechanisms undefined in and of itself adds to the entropy simply because implementers are free to choose different methods.

> 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.
[Les:] This is a misinterpretation. There is nothing in the draft which comments on utilizing the systemID to set MAC address for the device - only the reverse is suggested. :-)


> 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"
> >   -
> >
> > The WGLC will expire in 2 weeks on Jan 31, 2017.