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

"Liubing (Leo)" <leo.liubing@huawei.com> Tue, 09 June 2015 05:21 UTC

Return-Path: <leo.liubing@huawei.com>
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 522871AD055 for <isis-wg@ietfa.amsl.com>; Mon, 8 Jun 2015 22:21:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 0PaHD7RA4L5p for <isis-wg@ietfa.amsl.com>; Mon, 8 Jun 2015 22:21:54 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A118B1AD049 for <isis-wg@ietf.org>; Mon, 8 Jun 2015 22:21:53 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BXD64132; Tue, 09 Jun 2015 05:21:51 +0000 (GMT)
Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 9 Jun 2015 06:21:49 +0100
Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.186]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Tue, 9 Jun 2015 13:21:45 +0800
From: "Liubing (Leo)" <leo.liubing@huawei.com>
To: Karsten Thomann <karsten_thomann@linfre.de>
Thread-Topic: [Isis-wg] ISIS-autoconf-04 submitted //FW: New Version Notification for draft-liu-isis-auto-conf-04.txt
Thread-Index: AQHQmsUvhOb/9lHMUk2S32rA0gaCAZ2azvEAgAKhW7CAAY9YAIADd0+wgABDPICAALnZgA==
Date: Tue, 9 Jun 2015 05:21:44 +0000
Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45A6793EEE@nkgeml506-mbx.china.huawei.com>
References: <8AE0F17B87264D4CAC7DE0AA6C406F45A678E17E@nkgeml506-mbx.china.huawei.com> <2450780.fSPWS0PjFC@linne> <8AE0F17B87264D4CAC7DE0AA6C406F45A67929F3@nkgeml506-mbx.china.huawei.com> <2479054.jksjisMxEl@linne>
In-Reply-To: <2479054.jksjisMxEl@linne>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.98.117]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/isis-wg/ssgg06AlasrX7AnO0cXOUn0DHyo>
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: Tue, 09 Jun 2015 05:21:56 -0000

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.