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, 4 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
> >