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

[Karsten Thomann <[e-mail]>]

Hi,

reply inline.

Am Donnerstag, 11. Juni 2015, 06:01:53 schrieb Liubing:
> Hi Karsten,
> 
> Thanks for your detailed explanation, please see replies inline.
> 
> > -----Original Message-----
> > From: Karsten Thomann [mailto:[e-mail]]
> > Sent: Tuesday, June 09, 2015 3:29 PM
> > To: Liubing (Leo)
> > Cc: [e-mail]
> > Subject: Re: [Isis-wg] ISIS-autoconf-04 submitted //FW: New Version
> > Notification for draft-liu-isis-auto-conf-04.txt
> > 
> > Hi Bing
> > 
> > Am Dienstag, 9. Juni 2015, 05:21:44 schrieb Liubing:
> > > Hi Karsten,
> > > 
> > > > > Regarding 3.3.2:
> > > > > 
> > > > > 
> > > > > 
> > > > > What is exactly the duplication resolution, if the NET is used by
> > > > > an ISIS
> > > > > 
> > > > > Router not capable of autoconfig?
> > > > > 
> > > > > 
> > > > > 
> > > > > In my opinion the device which is auto config capable MUST
> > > > > recalculate its
> > > > > 
> > > > > NET, if the other router does not advertise a Router-Fingerprint
> > > > > TLV.
> > > > > 
> > > > > 
> > > > > 
> > > > > [Bing] The autoconfig should be a dedicated ISIS process that it
> > > > > won't be
> > > > > 
> > > > > mixed with the non-autoconf routers. This is prevented by the
> > > > > 
> > > > > Authentication TLV as described in 3.4.1.
> > > > 
> > > > Yes and no, the draft uses a MUST for the ability to change the
> > > > password, and there are possible cases where it is indended by
> > > > design to use somewhere a link between a autoconf based network and
> > > > the not autoconf network...
> > > > 
> > > > 
> > > > 
> > > > I my opinion it's a bit weak argument to not specify that behavior
> > > > explicitly.
> > > > 
> > > > 
> > > > 
> > > > [Bing] I think it's good to explicitly specify the behavior.
> > > > 
> > > > But I'd prefer the behavior to be abandoning the LSP rather than
> > > > recalculating its NET. In this case, the router without a
> > > > Router-Fingerprin TLV just could not joint in the autoconf process,
> > > > even if the authentication TLV is correct.
> > > > 
> > > > How do you think about it?
> > > 
> > > In my opinion autoconf routers should be as "passive" to the network
> > > as possible, and how would the abandoning of the LSP solve the issue
> > > if the other router is not directly connected or multihomed to other
> > 
> > routers?
> > 
> > > [Bing] Sorry, I'm a bit confused. Let me explain what I understood to
> > > check whether I was sync with you. Say, RouterB is in an Autoconf
> > > area, and also connected to a Non-Auto area. By accident, the RouterC
> > > in the Non-auto area has a NET the same with RouterB, and for some
> > > reason RouterC send a LSP including the AuthTLV and set the autoconf
> > > password but without a Router-Fingerprint TLV. Then, my understanding
> > > is that it is not a bad LSP, which should be dropped by RouterB's
> > > autoconf process so that it won't influent the autoconf process. Did I
> > > miss
> > 
> > something?
> > 
> > Ok, that maybe explains our communication problem, my thinking requires
> > at least 3 routers to explain it.
> > 
> > Example topology is the following
> > 
> > |A| <-> |B| <-> |C|
> > 
> > A is the starting router and wants to join the ISIS network, B and C
> > already have built an adjacency.
> > C isn't autoconf capable with a configured NET and now A want's to join
> > the
> > network with the same NET as C.
> > My question is now, what is done to prevent the LSP war?
> > In my opinion C should detect the duplicate NET and as it recognizes that
> > C
> > isn't autoconf capable (as there is no Router-Fingerprint-TLV) it should
> > recalculate its NET.
> 
> [Bing] Ah, I think we had different assumption. I assumed the auto-conf
> routers and non-autoconf routers are basically separated; but I guess your
> case assuming they are mixed together. I think we need to think a bit more
> whether autoconf routers tolerance a non-autoconf router to join in the
> autoconf area when the non-auto router's AuthTLV is correct but without a
> Router-Fingerprint TLV. And vice versa, the autoconf router accidently
> plugged into a non-auto area and the AuthTLV is by accident be set the same
> as the non-auto area. If this is valid use case, then I think the autoconf
> router should re-caulculate the NET in both cases.
My preference would be to force the autoconf capable router to recalculate its NET, as preventing 
non autoconf capable routers to join the area could prevent some possible use cases in the 
future.

Kind regards
Karsten


> Best regards,
> Bing
> 
> > I hope this explains my "corner case" good enough.