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

["Liubing (Leo)" <[e-mail]>]

Hi Les,

Sorry for replying your comments late, please see replies inline.

> -----Original Message-----
> From: Les Ginsberg (ginsberg) [mailto:[e-mail]]
> Sent: Friday, June 26, 2015 11:01 AM
> To: Liubing (Leo); [e-mail] list
> Subject: RE: ISIS-autoconf-04 submitted //FW: New Version Notification for
> draft-liu-isis-auto-conf-04.txt
> 
> Some (somewhat extensive) comments on the draft.
> 
> Overall Comments
> ------------------------------
> 
> 1)You have completely neglected the case where duplicate system-id occurs
> between two directly connected routers. In such a case no neighbor can be
> formed and therefore no LSPs can be exchanged - which means no
> Fingerprint TLV is available for conflict resolution. Please see RFC 7503
> Section 7.1.
> 
> There are a number of choices here:
> 
> a)You could use the MAC address as the tiebreaker (smaller MAC address
> changes its system-id). This of course only works on Ethernet and depends
> on the MAC address of the interface NOT being the source of the
> system-id. :-)
> 
> b)If you restrict yourself to IPv6 you could use the solution defined in RFC
> 7503 Section 7.1. But as you want to address IPv4 and IPv6 (no objection
> from me) that does not seem to be viable.
> 
> c)You could include the Fingerprint TLV in the hellos and be able to use that
> as a tiebreaker. This seems the most robust.

[Bing] Previously the draft limited the Sys-id to be MAC address, so when the MAC duplicated between neighbors, it is a very serious problem that not only regarding to ISIS routing.
But now the draft doesn't limit it anymore, so I agree the Sys-id duplication between neighbors is reasonable to be addressed.

And I prefer option C) as you listed above, thanks for your elaborate suggestion!


> 2)What you have written in the draft defines a way to make conflicts low
> probability and defines a means of resolving conflicts when they occur - but
> it does not attempt to minimize the occurrence of system-id changes for a
> router once it has become fully operational. This should also be a goal. To
> make this a reality I propose some additions:
> 
> Define a "startup mode" wherein a router does not start advertising
> neighbors/reachability and/or sets the OL bit until after an initial delay has
> expired. During this time it acquires the LSPDB and verifies that duplicate
> system-id is not detected. If duplicate system-id is detected we make the
> starting node the one which changes its system-id regardless of fingerprint
> content. This has minimal impact on a running network because the startup
> node is not yet being used for forwarding traffic. Once duplicate system-id
> has been resolved (if necessary) the router begins normal operation.
> 
> If two routers are both in startup mode (or both NOT in startup mode) and
> duplicate system-id is detected then we use the rules set forth in the draft to
> determine which one changes its system-id based on fingerprint.
> 
> Indication of being in startup mode can easily be included in the fingerprint
> TLV with a flag.

[Bing] I thinks it is a thoughtful complementary. Very good idea.
But I have a concern: anyway the duplication is a corner case, the initial delay might slow down the overall speed of auto-configuring the network? Is it worth to have the cost to fulfill the corner case?


> Specific Comments on Sections within the draft
> ----------------------------------------------------------------
> 
> Section 1.  Introduction
> 
> LES: Interesting that you don't mention ISO 10589 at all. That is the
> document that defines the base protocol - which RFC 1195,RFC 5308, and
> many others extend.
[Bing] Ok, will add the ref.


>   3.  NET duplication detection and resolution
> 
> LES: More correctly "NET" should be replaced by "system-id".
[Bing] It is indeed essentially the sys-id duplication problem. My previous concern is that NET is a complete entity and sys-id is only a key part of it.
But considering your comments regarding to Section 3.3 below, I think it's right to revise it as sys-id. Thanks.

> Section 3.1.  IS-IS Default Configuration
> 
> LES: You might want to consider an option that allows P2P mode on Ethernet
> interfaces as that is quite a pervasive deployment these days.
[Bing] Ok, will consider to do it. Thanks.

> Section 3.2.  IS-IS NET Generation
>   ...
> 
>    o  Area address
> 
>          This field is 1 to 13 octets in length.  In IS-IS auto-
>          configuration, this field MUST be 0 in 13 octets length.
> 
> LES: What does "0 in 13" mean? Do you mean that the area address MUST
> be 13 octets of all 0? Do you mean the area address can be 0 octets long
> (omitted) - which would be a violation of the protocol? Please clarify.
[Bing] It means all 0. Will clarify it in the next version.

>      o  NSEL
> 
>          This field is the N-selector, and is 1 octet in length.  In IS-
>          IS auto-configuration, it SHOULD be set to "00".
> 
> LES: The NSEL MUST be "00" as per ISO 10589. Anything else would be a
> protocol violation. Please revise the text accordingly - or eliminate it entirely
> as unnecessary.
[Bing] Reasonable suggestion. Will consider to directly delete it.


> Section 3.3.  IS-IS NET Duplication Detection and Resolution
> 
> LES: This entire section is a discussion of "duplicate system-id
> detection/resolution" - NOT duplicate NET. The area address portion of the
> NET is not subject to duplicate detection - and since all routers will be L1 any
> router with a different area address will be ignored i.e. we will not form
> adjacencies to it under base protocol rules. Please rename the section  and
> revise the text appropriately.
[Bing] Will do as said above.

> Section 3.3.2.  NET Duplication Detection and Resolution Procedures
> 
>    1) Flood the Router-Fingerprint TLVs
> 
>       When an IS-IS auto-configuration router gets online, it MUST
>       include the Router-Fingerprint TLV in the first originated level-1
>       LSP.  Then all the routers in the area could receive the
>       information in the TLV.
> 
> LES: You mean Fingerprint TLV MUST be in LSP #0?? That seems appropriate -
> but it needs to be stated that way.
[Bing] Ok, will do.

> Section 3.3.3.  SysID and Router-Fingerprint Generation Considerations
> 
> LES: It is also desirable that system-id - once chosen - should be retained
> across reboot.
[Bing] Agreed. There is some text, but maybe we need to make the text more emphasized.

> Section 3.3.4.  Double-Duplication of both NET and Router-Fingerprint
> 
> LES: I am not following this logic. You state at the beginning of the section
> that fingerprint generation might be constrained - presumably because an
> early implementation of this functionality might not be robust. You then go
> on to say that if this leads to "double duplication" that routers should ("on
> the fly"??) be able to enhance their fingerprint. This would seem to require
> an implementation upgrade. Otherwise why wouldn't the fingerprint be
> enhanced initially?
> 
> Or are you suggesting that - in order to save space - we send only a simple
> fingerprint - and if we hit double duplication we respond by sending a
> lengthier fingerprint? In which case you have a very imprecise definition of
> when "double duplication" can be declared.
[Bing] The logic is this:
1. At the initial stage, there is not much entropy for generating a high quality Fingerprint. (This is the feedback from the implementation team.)
2. Then, very unfortunately, the sys-id and Fingerprint both duplicated.
3. At the time the Double-Duplication is detected, there should be enough entropy (e.g. lots of random packets, LSP num etc.) to make tiebreaker of the duplication.
Does this sound reasonable for you?

> Section 3.4.1.  Authentication TLV
> 
> LES: If security is a real concern I think cleartext password has been proven
> to be of not much value. I would suggest that you provide the ability to
> specify a password which would be used in MD5 authentication (RFC 5304)
> or perhaps Generic Crypto (RFC 5310). If security is not a concern, then no
> password/authentication is fine. If you choose a unique area address then it
> is unlikely that a non-autoconf router would be configured w the same area
> address so you would never form an adjacency with it.
[Bing] The Auth TLV is not for security, but just for preventing non-autoconf routers joint in the autoconf area.
A unique area address is also an alternative, let us discuss it when do the next version. Thanks for your suggestion.

> Section 3.4.2.  Wide Metric TLV
> 
> LES: I think you have to use MUST here because routers using wide metric
> TLVs will not interoperate w routers using narrow metric TLVs - though they
> will form adjacencies. 
[Bing] Ok, I think it's reasonable. Thanks.

> Also, there is more to wide metrics than 1 TLV. For
> completeness you should specify the list of TLVs which can/cannot be used
> (TLV 22, 135, etc.). Also, are you forbidding the use of MT (e.g. TLV 222, 235,
> etc.)?
[Bing] Well, my thought was that except for the explicitly mentioned TLVs, the others are all NOT supposed to use. 

> Section 3.4.3.  Dynamic Host Name TLV
> 
> LES: "vendor" or "device type" won't provide uniqueness - not very helpful to
> have a bunch of devices all named "vendor-a". Serial #s - while likely unique -
> might be reasonable - assuming they are less cryptic than the chosen
> system-id - which is debatable. Unless there is a convenient way to get a
> name that the user can easily recognize I don't see much value here.
[Bing] My thought on this TLV is "Better Than Nothing". At least it is not harmful. Does this make sense for you?

> Section 3.4.4.  Purge Originator Identification TLV
> 
> LES: I don't object to this, but I don't see why it needs to be mentioned. It
> does not affect interoperability and it's use or non-use isn't specific to
> autoconfigured networks.
[Bing] In previous version, there was purge operation, but we revised it in the new version. So we might need to delete this section accordingly. Thanks.

> Section 3.5.1.  Adjacency Formation
> 
> LES: You could simply suggest using the defaults defined in ISO 10589 - which
> are the values you have mentioned.
[Bing] Sound good. Thanks!

> Section 3.5.2.  Co-existing with Other IGP Auto-configuration
> 
> LES: So what you stated in Section 2 about "Interworking with other routing
> protocols" being out of scope apparently isn't true?? Otherwise why did you
> write this section?
[Bing] This is some complementary explanation of the Section 2 relevant item. Although it is out of scope, it is a reasonable practical issue, and there had been some people raised this problem, so we thought it might be worth to specifically explain this.

Best regards,
Bing

>    Les
>