Re: [Isis-wg] Proposed drafts to become WG documents [draft-shen-isis-oper-enhance-00, draft-amante-isis-reverse-metric-02]

CAUCHIE Grégory <gregory.cauchie@orange-ftgroup.com> Thu, 19 May 2011 09:17 UTC

Return-Path: <gregory.cauchie@orange-ftgroup.com>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15C06E078A for <isis-wg@ietfa.amsl.com>; Thu, 19 May 2011 02:17:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.349
X-Spam-Level:
X-Spam-Status: No, score=-101.349 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_65=0.6, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JktopKs6ziR8 for <isis-wg@ietfa.amsl.com>; Thu, 19 May 2011 02:17:43 -0700 (PDT)
Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id 14CF8E0780 for <isis-wg@ietf.org>; Thu, 19 May 2011 02:17:42 -0700 (PDT)
Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 30D44738003 for <isis-wg@ietf.org>; Thu, 19 May 2011 11:18:57 +0200 (CEST)
Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 23CFA6F8002 for <isis-wg@ietf.org>; Thu, 19 May 2011 11:18:57 +0200 (CEST)
Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 May 2011 11:17:41 +0200
Received: from [10.193.167.144] ([10.193.167.144]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 May 2011 11:17:40 +0200
Message-ID: <4DD4E033.9030507@orange-ftgroup.com>
Date: Thu, 19 May 2011 11:17:39 +0200
From: CAUCHIE Grégory <gregory.cauchie@orange-ftgroup.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10
MIME-Version: 1.0
To: isis-wg@ietf.org
References: <EF848F0C-BA6E-4B5A-8178-162E4368F1B6@rawdofmt.org>
In-Reply-To: <EF848F0C-BA6E-4B5A-8178-162E4368F1B6@rawdofmt.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="------------ms060101020306000407020405"
X-OriginalArrivalTime: 19 May 2011 09:17:40.0549 (UTC) FILETIME=[9A40D750:01CC1605]
Subject: Re: [Isis-wg] Proposed drafts to become WG documents [draft-shen-isis-oper-enhance-00, draft-amante-isis-reverse-metric-02]
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: gregory.cauchie@orange-ftgroup.com
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: Thu, 19 May 2011 09:17:44 -0000

Hi everyone,

I don't have any opposition to these drafts becoming working group 
documents, I think even more that these are useful options for operations.

I just have one comment question about draft-shen-isis-oper-enhance. On 
one hand, I think having the possibility of pseudo-nodes sending metrics 
other than 0 is a useful idea. On the other hand, I am not sure to see 
the interest/benefit of the "Fast exit notification". IINM, the need is 
to take down one IS-IS adjacency without creating any traffic blackhole, 
and not to deal with taking down IS-IS as a whole on the node. If that's 
right, than I am not sure to see the value brought by "Fast exit 
notification".
As stated in the draft, when an adjacency is either unset or disabled on 
one end of a point-to-point link, several second elapse before the timer 
expire on the other end of the link to bring down the adjacency and then 
update+flood the LSP.
First I don't see why there would then be a blackhole of traffic as the 
node LSDB is not supposed to be flushed (remembering that the need is 
just to bring one adjacency down, not the entire IS-IS config/status), 
so the node should be able to forward the traffic it receives until the 
adjacent nodes react to the adjacency status change and update the rest 
of the network. Therefore no blackhole would be created. Am I missing 
something here?
Second, as IS-IS convergence is a great deal for us SPs, we usually 
enable BFD on IS-IS adjacency to detect adjacency status change under 
the order of the second. Even though this may still not be sufficient 
enough, I am  surprised not to see it mentionned in the draft and tend 
to think it could be of good for the draft to say something about it, 
whatever the answer to my previous point is.

Regards,

Greg

Le 27/04/2011 15:32, Christian Hopps a écrit :
> During IETF 79 the following drafts were presented to the WG and a request to make them WG documents was not met with objection. Are there objections on the list to the following drafts becoming isis-wg documents?
>
> http://tools.ietf.org/html/draft-shen-isis-oper-enhance-00
> http://tools.ietf.org/html/draft-amante-isis-reverse-metric-02
>
> Thanks,
> CHopps&  DWard.
> _______________________________________________
> Isis-wg mailing list
> Isis-wg@ietf.org
> https://www.ietf.org/mailman/listinfo/isis-wg
>