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,

Thanks for your quick response! Please see inline.

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

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


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

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

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

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

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

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

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

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

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

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

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


Best regards,
Bing

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