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

From: Marc Binderberger <[email-masked]>
Date: Mon, 23 Nov 2015 03:02:17 -0800

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?

* 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.

* 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.

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.

Btw, there is an interesting document, RFC 4086 , about random generation.

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

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: [email-masked] [mailto:[email-masked]] 
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg
>

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 24 Nov 2015 10:28:48 +0000

Hi Marc,

> From: Marc Binderberger [mailto:[email-masked]]
> Sent: Monday, November 23, 2015 7:02 PM
> To: Liubing (Leo)
> Cc: [email-masked] list
> Subject: Re: [Isis-wg] ISIS-Autocon-06-//FW: New Version Notification for
> draft-liu-isis-auto-conf-06.txt
> 
> Hello Bing and authors,
> 
> 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.

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

> / 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? :)

> 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

[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.

> 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