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

["Acee Lindem (acee)" <[e-mail]>]

Hi Ben, 
Thanks for the excellent review - see one inline. 

On 10/8/19, 6:13 AM, "Benjamin Kaduk" <[e-mail]> wrote:

    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, [e-mail] 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 <[e-mail]> 
    > Sent: mercredi 2 octobre 2019 03:17
    > To: The IESG <[e-mail]>
    > Cc: [e-mail]; Yingzhen Qu <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]
    > 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?

I don't disagree that there is more configuration and state associated with these traffic metrics. However, these are not really under the purview of this model since IS-IS (and OSPF for that matter) are only serving as a mechanism to advertise these traffic metrics. 

Thanks,
Acee
    
    Thanks!
    
    -Ben