Re: [mpls] Ben Campbell's No Objection on draft-ietf-mpls-mldp-node-protection-05: (with COMMENT)

IJsbrand Wijnands <ice@cisco.com> Tue, 29 September 2015 08:39 UTC

Return-Path: <ice@cisco.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5671D1A6F42; Tue, 29 Sep 2015 01:39:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 bCDHchUQCqJh; Tue, 29 Sep 2015 01:39:15 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BC381A6F03; Tue, 29 Sep 2015 01:29:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1413; q=dns/txt; s=iport; t=1443515398; x=1444724998; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Ao7MOynEPeEE1KeNC8wEWtKEJd4xR+R0vCTWIoLoXLA=; b=HIJBTlRuOIYEYPnucd1H25vurifUrWZOmD4/Yl5e4OyRJd2DEjnulXUO 0ebezbPy33XNTfBVa87LVm8cIV4g/ERApRAjoHNM3TfpDHho0RizWyYd6 dMNxqLl3mf5ZH2apjEbOJ1to+KfOY3rE+VerR+3DABAV4X/4TUlKrAa/s I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AIBQACSwpW/xbLJq1ehGGpEAEBAQEBAQUBgQ2PAowjAoIWAQEBAQEBgQuEJAEBAQMBI1YFCwsYAgImAgJXBhMbiAsItwSUVQEBAQEBAQEBAQEBAQEBAQEBAQEZgSKFCoJWgm6EWjMHgmkvgRQBBJVyjRGbQWOCQ4FAPDOJHwEBAQ
X-IronPort-AV: E=Sophos;i="5.17,607,1437436800"; d="scan'208";a="605427457"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Sep 2015 08:29:55 +0000
Received: from ams-iwijnand-88111.cisco.com (ams-iwijnand-88111.cisco.com [10.60.202.92]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t8T8TsGV012539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Sep 2015 08:29:55 GMT
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: IJsbrand Wijnands <ice@cisco.com>
In-Reply-To: <24CFBE30-9AD0-4CFA-9353-3E0C43A474F7@nostrum.com>
Date: Tue, 29 Sep 2015 10:29:52 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <BB797CE4-1BB2-4B63-AEA7-96F83AB43183@cisco.com>
References: <20150914220331.5981.89192.idtracker@ietfa.amsl.com> <7DD892A2-37EF-435E-A8F5-9167436DA808@cisco.com> <64A18C22-B877-40A1-9C08-FFA3291658B1@nostrum.com> <702FC7E4-4AEB-48EE-8053-066506130C7C@cisco.com> <24CFBE30-9AD0-4CFA-9353-3E0C43A474F7@nostrum.com>
To: Ben Campbell <ben@nostrum.com>
X-Mailer: Apple Mail (2.1993)
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/9pcqK5XbgguPDXxDeJP11SdMNSU>
Cc: mpls@ietf.org, mpls-chairs@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-mpls-mldp-node-protection.shepherd@ietf.org, draft-ietf-mpls-mldp-node-protection@ietf.org, draft-ietf-mpls-mldp-node-protection.ad@ietf.org
Subject: Re: [mpls] Ben Campbell's No Objection on draft-ietf-mpls-mldp-node-protection-05: (with COMMENT)
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Sep 2015 08:39:19 -0000

Hi Ben,

How about this:

"If the operator is not concerned with the tLDP session flapping and/or other procedures are in place to avoid this altogether, there is no need to apply the delay."

Thx,

Ice.

> On 28 Sep 2015, at 21:47, Ben Campbell <ben@nostrum.com> wrote:
> 
> On 28 Sep 2015, at 14:40, IJsbrand Wijnands wrote:
> 
>> -- 4.1.3, last paragraph:
>>>>> Just “recommended”? Is link flapping a minor enough that it doesn't
>>>>> justify a MUST?
>> 
>>>> 
>>>> Well, its really an implementation choice to save resources being using in deleting and re-creating the tLDP session. If the implementation has means to deal with this or has other mechanism to solve this problem, that is fine too.
>> 
>>> 
>>> Okay, A few words to that effect might be helpful.
>> 
>> 
>> Well, in that section I’m already making the reader aware of the fact that a tLDP session may be flapping due to link flapping, and what solution can be applied to mitigate it. I don’t think more words are necessary here. Are you ok if we keep it like it is?
> 
> I meant a few words to explain why this is not a MUST, not the fact that the sessions may flap. For example something to the effect of "However, an implementation might have other mechanisms to prevent flapping, in which case the delay might not be needed."