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

["Les Ginsberg (ginsberg)" <[e-mail]>]

Bing -

Thanx for the reply.
I think we are in agreement on many things. A few comments inline.

> -----Original Message-----
> From: Liubing (Leo) [mailto:[e-mail]]
> Sent: Monday, July 13, 2015 1:37 AM
> To: Les Ginsberg (ginsberg); [e-mail] list
> Subject: RE: ISIS-autoconf-04 submitted //FW: New Version Notification for
> draft-liu-isis-auto-conf-04.txt
> 
> 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?
> 
[Les:] I don't believe there is a speed requirement as regards bringing up a new node. The network has been running fine w/o the new node - if after the new node comes up we delay using it  for forwarding for a period long enough to ensure that LSPDB sync has been achieved and possible disruption to forwarding caused by duplicate system-ids is guaranteed to be avoided this seems to me be a positive without any negatives.

Using such delays on startup is a well-established practice - see RFC 3277. In the case of auto-configured networks we are less concerned about BGP convergence and more concerned w avoiding unnecessary IGP disruption caused by duplicate system-id.

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

[Les:] This (mis)perception comes from the unfortunate (but widespread) practice of using a single configuration command "net" . Functionally what is required is:

1)Configure one or more area addresses
2)Configure a system-id
3)n-selector does not need to be configured since it MUST be "00"

Using a single "net" command introduces confusion and leads to silly requirements like "when multiple nets are configured the system-id MUST be the same in all of them".
I don't expect configuration commands to be changed, but we do need to understand what the actual protocol requirements are.

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

[Les:] I would prefer that we define a robust fingerprint. This is not that difficult.  If there are concerns about the difficulties please make them public.

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

[Les:] You already have chosen a unique area address. (If someone thinks "00.0000.0000.0000" is in use in networks today it would be good to know that.)
To me the point of adding authentication is either because we don't think unique area address is sufficient for a given deployment and/or we are worried about attackers. Supporting cryptographic authentication allows us to address both issues - plaintext password does not.

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

[Les:] Not sure what you mean here. But I think the draft should be clear on what TLVs are allowed and which are not. The text as written suggests (I am sure unintentionally) that you are only talking about TLV 22.

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

[Les:]  Having multiple ISs advertising the same hostname (which is likely what would happen if you used manufacturer name) is decidedly "worse than nothing".

> 
> > 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.
> 
[Les:] Problem is I cannot tell if you are saying:

1)This is unsupported
2)This is forbidden
3)This is allowed but not recommended

???

Note that you say (emphasis added):

 " decide  which IGP to be used, or EVEN BOTH."

   Les

> Best regards,
> Bing
> 
> >    Les
> >