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

Marc Binderberger <> Wed, 01 February 2017 18:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 17F9112969A; Wed, 1 Feb 2017 10:24:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.098
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JjS6MKkwWu9x; Wed, 1 Feb 2017 10:24:27 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 1C415128AC9; Wed, 1 Feb 2017 10:24:27 -0800 (PST)
Received: from [IPv6:::1] ( []) by (Postfix) with ESMTP id C2B9C4BD069; Wed, 1 Feb 2017 18:24:20 +0000 (UTC)
Date: Wed, 1 Feb 2017 10:24:20 -0800
From: Marc Binderberger <>
To: Les Ginsberg (ginsberg) <>
Message-ID: <>
In-Reply-To: <>
References: <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: GyazMail version 1.5.17
Archived-At: <>
Cc: "" <>, Christian Hopps <>, "" <>, "" <>, "" <>
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: Wed, 01 Feb 2017 18:24:30 -0000

Hello Les,

thanks for the reply. Based on our conversation yesterday: indeed, I 
misunderstood the "pathological case" paragraph I cited as a result, not as a 
mere description. Mea culpa!

For the rest: I still don't think the draft is particular suited for the use 
case of low-end hardware with no unique identifiers (e.g. serial number, MAC 
etc). This is where I remain sceptic that generating a fingerprint from 
random numbers is working well.

But as you said in our conversation: implementors are free to do something 
clever - and the draft leaves the room for it, e.g. to combine the random 
part with additional fixed  and reasonably unique information. Or to use 
NVRAM/flash to remember an entropy pool and this way break synchronization 
after a power outage.

So yes, fine with me to proceed with the draft to RFC status.

Regards, Marc

On Tue, 31 Jan 2017 05:47:18 +0000, Les Ginsberg (ginsberg) wrote:
> Marc -
> Thanx for the thoughtful review.
> Inline.
>> -----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-
>    Fingerprint..."
> " 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. :-)
>    Les
>> 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.
> _______________________________________________
> Isis-wg mailing list