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

Karsten Thomann <karsten_thomann@linfre.de> Sat, 13 June 2015 16:36 UTC

Return-Path: <karsten_thomann@linfre.de>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 943AB1A1B46 for <isis-wg@ietfa.amsl.com>; Sat, 13 Jun 2015 09:36:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.338
X-Spam-Level:
X-Spam-Status: No, score=0.338 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KxEa2pTOehxl for <isis-wg@ietfa.amsl.com>; Sat, 13 Jun 2015 09:36:28 -0700 (PDT)
Received: from linfre.de (linfre.de [83.151.26.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F4A81A1B0C for <isis-wg@ietf.org>; Sat, 13 Jun 2015 09:36:27 -0700 (PDT)
Received: from linne.localnet (178.142.119.145) by linfreserv (Axigen) with (ECDHE-RSA-AES256-SHA encrypted) ESMTPSA id 1BDBB3; Sat, 13 Jun 2015 18:36:13 +0200
From: Karsten Thomann <karsten_thomann@linfre.de>
To: "Liubing (Leo)" <leo.liubing@huawei.com>
Date: Sat, 13 Jun 2015 18:36:19 +0000
Message-ID: <2180607.8mq5FAOYMp@linne>
User-Agent: KMail/4.13.0.0 (Windows/6.1; KDE/4.13.3; i686; git-a6cb62d; 2014-12-22)
In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F45A6794A14@nkgeml506-mbx.china.huawei.com>
References: <8AE0F17B87264D4CAC7DE0AA6C406F45A678E17E@nkgeml506-mbx.china.huawei.com> <2303767.J4ItTAn8Zy@e7240.linfre> <8AE0F17B87264D4CAC7DE0AA6C406F45A6794A14@nkgeml506-mbx.china.huawei.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="nextPart4718759.bn9kT4lm4d"
Content-Transfer-Encoding: 7Bit
X-AXIGEN-DK-Result: No records
DomainKey-Status: no signature
X-AxigenSpam-Level: 7
Archived-At: <http://mailarchive.ietf.org/arch/msg/isis-wg/TMR3Fyinl_Dba-kqMJIB3TY-OPs>
Cc: "isis-wg@ietf.org" <isis-wg@ietf.org>
Subject: Re: [Isis-wg] ISIS-autoconf-04 submitted //FW: New Version Notification for draft-liu-isis-auto-conf-04.txt
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/isis-wg/>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 13 Jun 2015 16:36:30 -0000

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:karsten_thomann@linfre.de]
> > Sent: Tuesday, June 09, 2015 3:29 PM
> > To: Liubing (Leo)
> > Cc: isis-wg@ietf.org
> > 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.