Re: [Isis-wg] ISIS-Autocon-06-//FW: New Version Notification for draft-liu-isis-auto-conf-06.txt

[Marc Binderberger <[e-mail]>]

Hello Bing,

thanks for the reply. I admit I did not read the "LSP war" as an active 
method to resolve the convergence for unique system IDs. Thanks for the 
clarification.

Reading your draft (again) how the router finger print should be generated, 
the problems you have faced etc. I have a few questions:

From your experience it may be difficult on smaller devices to have good 
random numbers (initially at least). Now RFC7503 also addresses Homenet. They 
have implementation on bird/quagga (probably others too but these are 
explicitly mentioned) and seem to master this problem with less 
rules/complexity. Thus my question if we can achieve the result with less 
rules?  Did you have a discussion with the authors of RFC7503 about this?  
What "trick" do they know? :-)

I do appreciate you cover the case of a double-duplication and agree this is 
comprehensive. If this would guarantee convergence towards uniqueness I would 
applaud. But it doesn't. It increases the chances of detection as having 
complete LSPs (size >> 32) being identical should be less likely than 
generating identical 32 byte fingerprints. But theoretically you could have 
identical LSPs.

There is a subtle difference between your draft and RFC7503: RFC7503 proposes 
to _concatenate_ multiple information, including MAC or EUI-64. Your section 
3.3.3 talks about "seed" and hashing or pseudo-random numbers based on it. 
Now, if you use e.g. the vendor name (or software name), software/OS version, 
detected hardware etc. and concatenate them to a router fingerprint then you 
turn the problem of unique router fingerprints into a per-vendor problem.


Long story short, my question (and motivation) is if we can achieve 
interoperability with a smaller algorithm by effectively forcing 
vendors/software to provide uniqueness for the router fingerprint. Your LSP 
war is clearly inventive :-) but it also causes churn. Maybe ok ... .


Regards, Marc





On Tue, 24 Nov 2015 10:28:48 +0000, Liubing (Leo) wrote:
> Hi Marc,
> 
>> -----Original Message-----
>> From: Marc Binderberger [mailto:[e-mail]]
>> Sent: Monday, November 23, 2015 7:02 PM
>> To: Liubing (Leo)
>> Cc: [e-mail] list
>> Subject: Re: [Isis-wg] ISIS-Autocon-06-//FW: New Version Notification for
>> draft-liu-isis-auto-conf-06.txt
>> 
>> Hello Bing and authors,
>> 
>> interesting topic, not just for homenet!
>> 
>> 
>> Reading the draft I had these thoughts:
>> 
>> * it looks "complicated" compared to RFC7503. This is likely due to the
>> duplication of some parts of the procedure for hellos, for startup mode, 
>> for
>> non-startup mode. Maybe the common parts could be extracted into
>> separate sub-sections?
> 
> [Bing] The common part is identifier generation and duplication 
> detection/resolution.
> The complexity you mentioned in my view is more comprehensive 
> considerations than RFC7503, and they're embed into the common part. I'm 
> not sure whether it's clearer to separate them, let me have a try in the 
> next version.
> 
>> * the document seems to be somewhat contradictory regarding the router
>> fingerprint. Section 3.3.1 refers to RFC7503. Which says in section 7.2.2:
>> "[...] It MUST be based on hardware attributes that will not change across
>> hard and soft restarts."
>> But your draft in section 3.3.3 mentions seeds based on System clock and
>> Arbitrary received packet.
> 
> [Bing] Section 3.3.3 is practical considerations according to the feedback 
> of the implementation team, who told us that in small home devices there is 
> actually NOT much hardware attributes to use other than MAC addresses. So, 
> if the Sys ID uses MAC, then basically there's no sufficient hardware 
> attributes for generating fingerprint. I think this consideration also 
> applies to RFC7503.
> 
>> * you actually try to solve somewhat the "unsolvable": duplication of the
>> router fingerprint. You describe how you can detect this and in section 
>> 3.3.3
>> / 3.3.4 what to do. But the point of the fingerprint is that it's 
>> uniqueness is
>> demanded to be of such high quality that you ignore the unlikely event of a
>> duplication. Who dares wins! :-) RFC7503 does not talk about fingerprint
>> duplication.
> 
> [Bing] In principle, I agree with you. This additional complexity was also 
> caused by the concern of not plenty hardware attributes and entropy (at the 
> start time). Although the probability is still very low, we'd feel safe to 
> have a mechanism against it. Is it a technical problem or psychological 
> problem? :)
> 
>> If you think this quality can not be achieved then it would require a
>> discussion why you think the detection you can do is sufficient. You can
>> detect duplicated fingerprints when exchanging hellos. Now with N nodes
>> the number of neighbors in your network is somewhere between N * O(1)
>> and N *
>> O(N) - it either a fixed, typically small number of cabled neighbors or a 
>> full
>> mesh. To detect a duplication you need to compare everyone with everyone,
>> which is O(N*N). For large N / large networks any duplicate detection from
>> the "few" neighbors (N * O (1)) is a lucky hit against the
>> O(N*N) and you better shut down than trying to fix it, IMHO. For small
>> networks though you may have a chance to detect duplications with a high
>> probability from the hellos.
> 
> [Bing] Sorry I don't quite get you. Did you mean the LSP war detecting in 
> the draft is NOT sufficient for detecting fingerprint duplication, or you 
> meant it was complex, and you proposed another approach based on hellos?
> For hellos, as you said, it doesn't work for large networks.
> 
>> Btw, there is an interesting document, RFC 4086 , about random generation.
> [Bing] Thanks for the info, I'll read it.
> 
>> * you write about the mix of autoconfig and non-autoconfig nodes:
>> 
>>           If there is no Router-Fingerprint TLV in the Hello message, it
>>           means a non-autoconfiguration router by accident connected to
>>           the auto-configuration domain or other unexpected bad
>>           behaviors.  In this case, the auto-configuration router MUST
>>           NOT form adjacency with the non-autoconfiguration router.
>> 
>> Sure we can make this restriction. This means we never expect a manually
>> configured IS-IS router to talk to autoconfig ones?
> [Bing] Basically yes, in my mind this is most for simplifying the problem 
> space. But I'd like to hear your opinions that do you think they mixed 
> together make sense in some specific scenarios?
> 
> Many thanks for your constructive comments.
> 
> Best regards,
> Bing
> 
> 
>> Regards, Marc
>> 
>> 
>> 
>> 
>> On Tue, 20 Oct 2015 08:27:58 +0000, Liubing (Leo) wrote:
>>> Hi Dear all,
>>> 
>>> Hi Dear all,
>>> 
>>> This version has some technical changes, according to discussion around
>>> last IETF (mostly from Les Ginsberg).
>>> 
>>> For your convenient, the main technical revisions are listed below:
>>> 1. Added a "Start-up Mode" when doing duplication detection/resolution.
>>> Accordingly, the Router-Fingerprint TLV added a flag to indicate the
>>> Start-up mode; and the duplication procedures are also revised
>> accordingly.
>>> 2. Added some description of duplication between neighbors.
>>> 3. Added a usage of authentication TLV to be the HMAC-MD5
>> authentication
>>> mode.
>>> And we have a new co-author Les Ginsberg who made great contribution
>> to
>>> improve the draft.
>>> 
>>> Your comments are welcome!
>>> 
>>> Best regards,
>>> Bing
>>> 
>>> -----Original Message-----
>>> From: [e-mail] [mailto:[e-mail]]
>>> Sent: Monday, October 19, 2015 4:27 PM
>>> To: Bruno Decraene; Les Ginsberg; Ian Farrer; Bruno Decraene; Liubing
>>> (Leo); Mikael Abrahamsson; Les Ginsberg; Mikael Abrahamsson; Ian Farrer;
>>> Liubing (Leo)
>>> Subject: New Version Notification for draft-liu-isis-auto-conf-06.txt
>>> 
>>> 
>>> A new version of I-D, draft-liu-isis-auto-conf-06.txt has been 
>>> successfully
>>> submitted by Bing Liu and posted to the IETF repository.
>>> 
>>> Name:		draft-liu-isis-auto-conf
>>> Revision:	06
>>> Title:		ISIS Auto-Configuration
>>> Document date:	2015-10-19
>>> Group:		Individual Submission
>>> Pages:		14
>>> URL:
>>> https://www.ietf.org/internet-drafts/draft-liu-isis-auto-conf-06.txt
>>> Status:         https://datatracker.ietf.org/doc/draft-liu-isis-auto-conf/
>>> Htmlized:       https://tools.ietf.org/html/draft-liu-isis-auto-conf-06
>>> Diff:
>>> https://www.ietf.org/rfcdiff?url2=draft-liu-isis-auto-conf-06
>>> 
>>> Abstract:
>>>    This document specifies an IS-IS auto-configuration technology.  The
>>>    key mechanisms of this technology are IS-IS System ID self-
>>>    generation, duplication detection and duplication resolution.  This
>>>    technology fits the environment where plug-and-play is expected.
>>> 
>>> 
>>> 
>>> 
>>> Please note that it may take a couple of minutes from the time of
>>> submission until the htmlized version and diff are available at
>>> tools.ietf.org.
>>> 
>>> The IETF Secretariat
>>> 
>>> _______________________________________________
>>> Isis-wg mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/isis-wg
>>> 
> 
> _______________________________________________
> Isis-wg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/isis-wg
>