Re: [Isis-wg] WG Last Call for draft-ietf-isis-auto-conf-04
"Liubing (Leo)" <leo.liubing@huawei.com> Sat, 04 February 2017 09:26 UTC
Return-Path: <leo.liubing@huawei.com>
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 DD1101295FD; Sat, 4 Feb 2017 01:26:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.42
X-Spam-Level:
X-Spam-Status: No, score=-7.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-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 f9ecF5_mMaMf; Sat, 4 Feb 2017 01:26:50 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B16A41293DF; Sat, 4 Feb 2017 01:26:49 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DFT90695; Sat, 04 Feb 2017 09:26:47 +0000 (GMT)
Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sat, 4 Feb 2017 09:26:46 +0000
Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Sat, 4 Feb 2017 17:26:43 +0800
From: "Liubing (Leo)" <leo.liubing@huawei.com>
To: Marc Binderberger <marc@sniff.de>, Les Ginsberg <ginsberg@cisco.com>
Thread-Topic: [Isis-wg] WG Last Call for draft-ietf-isis-auto-conf-04
Thread-Index: AQHScLlda0JYZz5r8UKulrfcz93dq6FQ1DiAgADPLwCAAmXZAIAEkycQ
Date: Sat, 04 Feb 2017 09:26:43 +0000
Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C2E9DB74@nkgeml514-mbx.china.huawei.com>
References: <87mvepkiag.fsf@chopps.org> <20170130092545041657.86168d8e@sniff.de> <0ae135606f3a4bc4b513707e3e540e27@XCH-ALN-001.cisco.com> <20170201102420181556.626b4ba8@sniff.de>
In-Reply-To: <20170201102420181556.626b4ba8@sniff.de>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.191.175]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.58959E57.009F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 118abe202d708be6759672ece87bc955
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/45J4p-Mg0Jz5_cQ4Nf10klrwBhU>
Cc: "draft-ietf-isis-auto-conf@ietf.org" <draft-ietf-isis-auto-conf@ietf.org>, "isis-wg@ietf.org" <isis-wg@ietf.org>, "isis-chairs@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: Sat, 04 Feb 2017 09:26:53 -0000
Hi Marc, Thanks for your thoughtful comments. Just a minor comment inline. > -----Original Message----- > From: Marc Binderberger [mailto:marc@sniff.de] > Sent: Thursday, February 02, 2017 2:24 AM > To: Les Ginsberg > Cc: Christian Hopps; draft-ietf-isis-auto-conf@ietf.org; 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 > > 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. [Bing] I think it is like a "natural flaw", if some low-end hardware really lack unique seeds. As you and Les discussed below, maybe implementers could figure out some clever methods; maybe it is just a problem hard to be solved by both this document and RFC7503. Best regards, Bing > 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 [mailto:marc@sniff.de] > >> Sent: Monday, January 30, 2017 9:26 AM > >> To: Christian Hopps; draft-ietf-isis-auto-conf@ietf.org > >> Cc: isis-wg@ietf.org; isis-chairs@ietf.org; isis-ads@ietf.org > >> 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" > >>> - https://datatracker.ietf.org/doc/draft-ietf-isis-auto-conf/ > >>> > >>> The WGLC will expire in 2 weeks on Jan 31, 2017. > > > > _______________________________________________ > > Isis-wg mailing list > > Isis-wg@ietf.org > > https://www.ietf.org/mailman/listinfo/isis-wg > >
- [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)