Re: [Isis-wg] Ben Campbell's No Objection on draft-ietf-isis-remaining-lifetime-03: (with COMMENT)

"Ben Campbell" <ben@nostrum.com> Thu, 18 August 2016 02:27 UTC

Return-Path: <ben@nostrum.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 B867412D114; Wed, 17 Aug 2016 19:27:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.147
X-Spam-Level:
X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=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 k-K-xf92fQ6X; Wed, 17 Aug 2016 19:27:54 -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 3FB61128E18; Wed, 17 Aug 2016 19:27:54 -0700 (PDT)
Received: from [10.0.1.4] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u7I2RlxZ008459 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 17 Aug 2016 21:27:48 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.4]
From: Ben Campbell <ben@nostrum.com>
To: Les Ginsberg <ginsberg@cisco.com>
Date: Wed, 17 Aug 2016 21:27:47 -0500
Message-ID: <277AB751-3D06-44C6-A93D-901BAE111924@nostrum.com>
In-Reply-To: <af4363c1651b47c198d4b24cd823e102@XCH-ALN-001.cisco.com>
References: <147137910592.22871.16411946820142811060.idtracker@ietfa.amsl.com> <af4363c1651b47c198d4b24cd823e102@XCH-ALN-001.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.4r5234)
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/ObpDA57a9iPgS5n8n7yAXZFpRdc>
Cc: "isis-chairs@ietf.org" <isis-chairs@ietf.org>, "isis-wg@ietf.org" <isis-wg@ietf.org>, Christian Hopps <chopps@chopps.org>, The IESG <iesg@ietf.org>, "draft-ietf-isis-remaining-lifetime@ietf.org" <draft-ietf-isis-remaining-lifetime@ietf.org>
Subject: Re: [Isis-wg] Ben Campbell's No Objection on draft-ietf-isis-remaining-lifetime-03: (with COMMENT)
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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, 18 Aug 2016 02:27:56 -0000

On 16 Aug 2016, at 15:43, Les Ginsberg (ginsberg) wrote:

> Ben -
>

[...]

>>
>> I have just a few minor comments:
>>
>> - 1, 2nd paragraph: "... the checksum
>>    field MUST NOT be altered..."
>>
>> That sounds more like a statement of fact than a normative 
>> requirement.
>>
> [Les:] It is a normative requirement stated in the base protocol 
> specification ISO 10589. It is repeated here in order to make the 
> point that the reason RemainingLifetime is NOT included in the 
> checksum is that doing so would require each router flooding the LSP 
> to modify the checksum - which MUST NOT be done.

I don't dispute that it is effectively normative in ISO 10589. But it's 
not normative _here_. Normally 2119 keywords should be used to create 
materially new normative requirements, not to talk about existing ones. 
In my opinion, it's best to use descriptive language when talking about 
requirements established in other documents, with the exception of 
making direct quotes from the authoritative document.

But in any case, this is not a blocking comment; do with it what you 
will.


>
>> -1, paragraph 4:
>>
>> I’m no expert here, but are where the originator might want to let 
>> the LSP
>> expire before it becomes unreachable? (e.g. during a graceful
>> shutdown?)
>>
>
> [Les:] I am not quite sure what you are suggesting.
> If a router shuts down (gracefully or not) the adjacencies to it will 
> quickly go down on its neighbors. This will make the router 
> unreachable and any LSPs from that router will not be used by any 
> other routers in the system.
> If I wanted to be more proactive in case of a planned shutdown I could 
> purge LSP #0 before bringing adjacencies. Base specification requires 
> that LSP #0 from a given router be present in order to use any of the 
> LSPs from that router.
>
> But I don’t see the relevance of discussing any of this in the 
> context of this draft.

Okay.

>
>> -2, 4th paragraph from end: "An additional
>>    action is added:
>> "
>> This document adds the additional action, or ISO10589 adds it?
>>
>
> [Les:] This document adds the additional action. I am fine with 
> changing the text to say:
>
> "This document introduces one additional  action:"
>
> if you find that helpful.

I think it's helpful.

Thanks!

Ben.