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

[Karsten Thomann <[e-mail]>]

Hi,

please see inline.

Am Freitag, 5. Juni 2015, 06:44:47 schrieb Liubing:
> Hi Karsten,
> 
> Thanks for your review and comments. Please see replies inline.
> 
> From: Karsten Thomann [mailto:[e-mail]]
> Sent: Thursday, June 04, 2015 5:36 AM
> To: [e-mail]
> Cc: Liubing (Leo)
> Subject: Re: [Isis-wg] ISIS-autoconf-04 submitted //FW: New Version
> Notification for draft-liu-isis-auto-conf-04.txt
> 
> 
> Hi,
> 
> 
> 
> some comments after reading the draft:
> 
> 
> 
> I'm not really convinced that this will really be implemented in a home
> network or small enterprise networks, as ISIS isn't a protocol widely
> supported on that platforms.
> 
> I was thinking more about shortest path bridging switch autodiscovery, but
> this is only my own opinion.
> 
> 
> 
> [Bing] I agree ISIS is not widely supported on small devices nowadays. But I
> think it might has the potential in the future.
> 
> Actually, In Homenet the ISIS is already in the short list for their routing
> protocol choice
> (http://datatracker.ietf.org/doc/draft-mrw-homenet-rtg-comparison/). And
> there is also some operator showed explicit requirement for ISIS in home
> routers.
> 
> 
> 
> Furthermore, the scope might not only limit to home/enterprise scenarios.
> Maybe the operators would find this auto-conf tool is also benefit for them
> one day:)
I didn't wanted to start a real discussion, only express my personal concern that it is unlikely to be 
supported in home networks, but likely in other areas where ISIS has advantages against OSPF.

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

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