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 -

> -----Original Message-----
> From: Liubing (Leo) [mailto:[e-mail]]
> Sent: Thursday, July 16, 2015 11:41 PM
> 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,
> 
> 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?
> 
[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.

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

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

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