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,

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

Kind regards
Karsten
> 
> 
> Best regards,
> 
> Bing
> 
> > I'm not able to find a similar approach for the OSPF RFC, as it seems to
> > 
> > have the same problem.