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

From: "Liubing (Leo)" <[email-masked]>
Date: Mon, 13 Jul 2015 08:37:29 +0000

Hi Les,

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

> -----Original Message-----
> From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
> Sent: Friday, June 26, 2015 11:01 AM
> To: Liubing (Leo); [email-masked] 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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 14 Jul 2015 19:46:57 +0000

Bing -

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

> From: Liubing (Leo) [mailto:[email-masked]]
> Sent: Monday, July 13, 2015 1:37 AM
> To: Les Ginsberg (ginsberg); [email-masked] list
> > Subject: RE: ISIS-autoconf-04 submitted //FW: New Version Notification
> > for draft-liu-isis-auto-conf-04.txt
> >
> > 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.
> >
> > 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. :-)
> >
> > 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.
> 
> > 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:
> >
> > 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.
> 
> 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.

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

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

> > LES: You might want to consider an option that allows P2P mode on
> > Ethernet interfaces as that is quite a pervasive deployment these days.
> > protocol violation. Please revise the text accordingly - or eliminate
> > it entirely as unnecessary.
> > 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.
> > 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.
> 
> > LES: It is also desirable that system-id - once chosen - should be
> > retained across reboot.
> > 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.
> 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.

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

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

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

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

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

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

> > 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.
> 
> > LES: You could simply suggest using the defaults defined in ISO 10589
> > - which are the values you have mentioned.
> > 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

---

From: "Liubing (Leo)" <[email-masked]>
Date: Fri, 17 Jul 2015 06:40:48 +0000

Hi Les,

Thanks for your quick response! Please see inline.

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

[Bing] For a new node that joining an existing autoconf network, I also agree the delay should be a positive without negatives.
But my concern was mostly for the scenario that several (or even more) routers initiate at the same timeslot, which means they will all delay, then the LSPDB won't be built for a while, then they can't do the duplicate detecting according to LSPDB... it seems a temporary break there and I'm a bit confused how long should they waiting for to stop the break?

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

[Bing] Thanks for your elaborate explanation. It's much clearer for me now.

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

[Bing] It's not difficult to "define" one, but for small devices, there is some practical difficulties.
I'll initiate another thread to discuss this issue.

> > > 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
> > > security is not a concern, then no password/authentication is fine.
> > > If you choose a unique area address then it is unlikely that a
> > [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.

[Bing] I'll consider to use cryptographic authentication carefully when do the next version.

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

[Bing] Ok, explicitly listing the supported/unsupported TLVs should be good.

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

[Bing] I agree that in theory the manufacturer name uniqueness are not guaranteed. But I believe most of the time the uniqueness should be sufficient in practice. Even if the uniqueness is broken, I also can't really see essential harm. Would you elaborating a bit more about what the worse thing you referred to?

> > [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.
> >
[Bing] For this document, it is clearly 1) This is unsupported. I'll make it more explicit.

Best regards,
Bing

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sun, 19 Jul 2015 20:19:08 +0000

Bing -

> Sent: Thursday, July 16, 2015 11:41 PM
> > > > 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.
> > > > 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
> > > > 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.
> > > >
> > [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.
> 
> [Bing] For a new node that joining an existing autoconf network, I also agree
> the delay should be a positive without negatives.
> But my concern was mostly for the scenario that several (or even more)
> routers initiate at the same timeslot, which means they will all delay, then
> the LSPDB won't be built for a while, then they can't do the duplicate
> detecting according to LSPDB... it seems a temporary break there and I'm a
> bit confused how long should they waiting for to stop the break?
> 
[Les:] New/restarting nodes still generate and flood LSP #0 as a minimum - which will have the fingerprint TLV - so duplicate system-id detection can still be done - which of course is essential. The delay proposal does not compromise duplicate detection in any way. What it does do is minimize disruption caused by a node assuming an identity before it has been able to perform duplicate detection - and it also prevents a node being used for forwarding before that node has had time to acquire the full LSPDB.

> > > 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
> > requirements like "when multiple nets are configured the system-id
> > MUST be the same in all of them".
> > [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.
> 
> > > > 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.
> > [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.
> 

[Les:] As discussed on a side thread, the problem w the current content is that you make cleartext password a MUST. Since the protocol does not support multiple authentication TLVs in a PDU this makes the use of cryptographic authentication not possible. I think you need to allow choices here:

  o Run w/o authentication
  o Run w authentication - the type and key subject to provisioning

> 
> > > > 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.)?
> > [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.
> 
> > > > 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".
> 
> [Bing] I agree that in theory the manufacturer name uniqueness are not
> guaranteed. But I believe most of the time the uniqueness should be
> sufficient in practice. Even if the uniqueness is broken, I also can't really see
> essential harm. Would you elaborating a bit more about what the worse
> thing you referred to?
> 
[Les:] It is quite likely that multiple devices from the same manufacturer will be in a network. This then leads to multiple devices with the same hostname but different system-ids. I think this is confusing - not clarifying.

   Les

> > > > LES: So what you stated in Section 2 about "Interworking with
> > > > other routing protocols" being out of scope apparently isn't true??