Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-isis-yang-isis-cfg-40: (with DISCUSS and COMMENT)

Benjamin Kaduk <> Tue, 08 October 2019 10:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DCD681200C3; Tue, 8 Oct 2019 03:12:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xqe2VkP-VyG9; Tue, 8 Oct 2019 03:12:55 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A5CA81200B8; Tue, 8 Oct 2019 03:12:55 -0700 (PDT)
Received: from ([]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.14.7/8.12.4) with ESMTP id x98ACnaP017810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 8 Oct 2019 06:12:52 -0400
Date: Tue, 8 Oct 2019 03:12:49 -0700
From: Benjamin Kaduk <>
Cc: "'The IESG'" <>,, "'Yingzhen Qu'" <>,,,
Message-ID: <>
References: <> <00d501d57db3$1ca808d0$55f81a70$>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <00d501d57db3$1ca808d0$55f81a70$>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <>
Subject: Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-isis-yang-isis-cfg-40: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 08 Oct 2019 10:12:58 -0000

Hi Stephane,

Thanks for pulling in the fixes; just a few notes inline (and trimming)...

On Tue, Oct 08, 2019 at 10:33:49AM +0200, wrote:
> Hi Benjamin,
> Thanks for your comment.
> Please find some inline answers.
> I'm doing the changes as part of the -41.
> Stephane
> -----Original Message-----
> From: Benjamin Kaduk via Datatracker <>; 
> Sent: mercredi 2 octobre 2019 03:17
> To: The IESG <>;
> Cc:; Yingzhen Qu <>;;;;;
> Subject: Benjamin Kaduk's Discuss on draft-ietf-isis-yang-isis-cfg-40: (with DISCUSS and COMMENT)
> In the "protection-available" container, is there some sort of constraint that two of the alternate-metrics add up to the third?
> [SLI] It is not really a constraint from a YANG point of view, these are operational counters.

Sorry, I shouldn't have used the word "constraint", since that's a YANG
verb.  I was just asking if the description should reiterate to the reader
that in normal circumstances the two will add up to the third (and "no" is
a fine answer).

>        container delay-metric {
>          leaf metric {
>            type std-metric;
>            description "IS-IS delay metric for IPv4 prefix";
>          }
>          leaf supported {
>            type boolean;
> Should the "metric" leaf be conditional on "supported" being true?
> (Same for the other flavors of metric, as well as when they appear later on in the "neighbor" grouping.)
> [SLI] This is not a configuration leaf, so I don't think that there is a need for enforcement at YANG level.

Oh, I had missed that it was config false; sorry about that.

>        container unidirectional-link-delay-variation {
>          description
>            "Container for the average delay variation
>            from the local neighbor to the remote one.";
>          leaf value {
>            type uint32;
>            units usec;
>            description
>              "Delay variation value expressed in microseconds.";
> Is this a standard deviation (variance), mean absolute error, ...?
> [SLI] We just mimic what is defined in RFC8570. As the reference is defined in the model. People should refer to it for more details.
> Moreover this is a pure operational state. still leaves me a little
unclear about what exactly is being reported (it sounds like it's just an
average link delay so the word "variation" confuses me), but I agree that
we should not say any more in this document.

>        container unidirectional-link-loss {
>          [...]
>          leaf value {
>            type uint32;
>            units percent;
>            description
>              "Link packet loss expressed as a percentage
>              of the total traffic sent over a configurable interval.";
> This document is all about specifying configuration.  How do I configure the interval in question?
> [SLI] This is an operational state.

The leaf value is operational state, yes, but it reports a valid computed
"over a configurable interval".  How do I configure that interval?