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

["Liubing (Leo)" <[e-mail]>]

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.

Best regards,
Bing 
 


> I hope this explains my "corner case" good enough.