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

[Karsten Thomann <[e-mail]>]

Hi Bing,

please see reply inline.

Am Montag, 8. Juni 2015, 10:41:24 schrieb Liubing:
> Hi Karsten,
> 
> Please see replies inline.
> 
> From: Karsten Thomann [mailto:[e-mail]]
> Sent: Saturday, June 06, 2015 9:35 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
> 
<snip>
> > 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?

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.