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

"Ben Campbell" <ben@nostrum.com> Mon, 28 September 2015 19:47 UTC

Return-Path: <ben@nostrum.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 F284F1B2C33; Mon, 28 Sep 2015 12:47:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 KEI1vpLMGJ0U; Mon, 28 Sep 2015 12:47:49 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 581271B2C32; Mon, 28 Sep 2015 12:47:49 -0700 (PDT)
Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t8SJlYWc014567 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 28 Sep 2015 14:47:44 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23]
From: Ben Campbell <ben@nostrum.com>
To: IJsbrand Wijnands <ice@cisco.com>
Date: Mon, 28 Sep 2015 14:47:34 -0500
Message-ID: <24CFBE30-9AD0-4CFA-9353-3E0C43A474F7@nostrum.com>
In-Reply-To: <702FC7E4-4AEB-48EE-8053-066506130C7C@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>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.2r5107)
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/8Fx32Ve6F8T8mQjbIUehnankqOc>
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: Mon, 28 Sep 2015 19:47:51 -0000

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