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

Benjamin Kaduk <kaduk@mit.edu> Tue, 08 October 2019 10:12 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCD681200C3; Tue, 8 Oct 2019 03:12:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xqe2VkP-VyG9; Tue, 8 Oct 2019 03:12:55 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5CA81200B8; Tue, 8 Oct 2019 03:12:55 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (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 <kaduk@mit.edu>
To: slitkows.ietf@gmail.com
Cc: "'The IESG'" <iesg@ietf.org>, draft-ietf-isis-yang-isis-cfg@ietf.org, "'Yingzhen Qu'" <yingzhen.ietf@gmail.com>, aretana.ietf@gmail.com, lsr-chairs@ietf.org, lsr@ietf.org
Message-ID: <20191008101249.GC76545@kduck.mit.edu>
References: <156997901245.26411.13754348016200348607.idtracker@ietfa.amsl.com> <00d501d57db3$1ca808d0$55f81a70$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <00d501d57db3$1ca808d0$55f81a70$@gmail.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/s9qpLtHqIy1PBgtczehxYu_bnIA>
Subject: Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-isis-yang-isis-cfg-40: (with DISCUSS and COMMENT)
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=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, slitkows.ietf@gmail.com 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 <noreply@ietf.org>; 
> Sent: mercredi 2 octobre 2019 03:17
> To: The IESG <iesg@ietf.org>;
> Cc: draft-ietf-isis-yang-isis-cfg@ietf.org; Yingzhen Qu <yingzhen.ietf@gmail.com>;; aretana.ietf@gmail.com; lsr-chairs@ietf.org; yingzhen.ietf@gmail.com; lsr@ietf.org
> 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.

https://tools.ietf.org/html/rfc8570#section-4.3 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?

Thanks!

-Ben