Re: [Lsr] [netmod] A question on the parameter overriding in draft-ietf-isis-yang-isis-cfg

Xufeng Liu <xufeng.liu.ietf@gmail.com> Tue, 11 June 2019 13:44 UTC

Return-Path: <xufeng.liu.ietf@gmail.com>
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 44CBC12016A; Tue, 11 Jun 2019 06:44:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 vBBDIAt4m7Mr; Tue, 11 Jun 2019 06:43:57 -0700 (PDT)
Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 B669A120167; Tue, 11 Jun 2019 06:43:57 -0700 (PDT)
Received: by mail-io1-xd2f.google.com with SMTP id h6so9935492ioh.3; Tue, 11 Jun 2019 06:43:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xn13vOJqVILcaezLg3sF/J2pIWtxjq9sPfMLMXTtIVw=; b=EpFOThOO2vKAhGRlc+qUS7hlx8fjoek91JdxMne9TsNMkkdxSyfAoeFbLRG1SjQnux xQd9rWTx3c0Z8APXv7mKs7/DNM1A95kZ0waWy3MXrNhzznVqqK4Rro+gjHuqKiL06XTe y5QsajOnYQQMcHB1fAAhEMlfxkjCBkKUvXmuwYTP9S0xFwaUbZ4tEHuBO/tGxT5Q5ytV 2K8UozH0YpNpcvLUWJox61WfH5LGzKIyCXlx53JLhpU9yY7OFTmkhs8fBemI5e8cIej3 2ofqLulcJ+RZagab/4qd8NePz8PjfWU0YZrlSOPy9WgjHdHj+8iglR1QtAf77xv/1cgi /BmA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xn13vOJqVILcaezLg3sF/J2pIWtxjq9sPfMLMXTtIVw=; b=Pq0rtTPtWJccxzMDYnsax7xlBAMqEgezzsQm7SUqaf2MZBiQEwHKyIzREnhxjnx2NI C2vPBfW7B/3QGNhWcdqFB9xgQwY1M1Nd6bu9gIT2ITSV8nD5BMWjXpJh9QnbURwTWL0S 3C5t9RBaB58eaaXTzAkthkcdQo+drkuX8qnz0PXhrf0gatqzkn5rk9ajOlWclmw8+9gR wtgeno+yz8iNQXuPRP7kYWtZoOQE3h45RTpPy7241rWLRrmjlmha1sXG/mgjR8C/6mMf oVNnuh0GwCG65EsMTo4zOYfFCO1etvaGoeBwtS6mfgU6YwdjMQ4DUYx3MbevMO49HRY0 In1w==
X-Gm-Message-State: APjAAAXi7x6ebFIplp8QFJfZpAAeRXhFQY+H6CQhccWgnDMKrlV0NqKP 2R95mkfz5zK5PEz6GzLYV/koAdghdLTW5oIr03LjfQ==
X-Google-Smtp-Source: APXvYqwsNiEWZNRYMhk/iF0zDTNMbrzO9Az5StOcyXuxdljlqAoVUe3F8nP8TMzsZ6ybqHagsFUcYM+h+2088tid1/U=
X-Received: by 2002:a6b:bf01:: with SMTP id p1mr2918466iof.181.1560260636995; Tue, 11 Jun 2019 06:43:56 -0700 (PDT)
MIME-Version: 1.0
References: <CAEz6PPSQfshh0=itkUWmT1PMU3XVFNrjk5L49cbNKYr1m1BuWA@mail.gmail.com> <20190609152829.r25rkc4gevnzgcka@anna.jacobs.jacobs-university.de> <cb575f7c-927a-631e-9eb2-12ccf066f53d@hedeland.org>
In-Reply-To: <cb575f7c-927a-631e-9eb2-12ccf066f53d@hedeland.org>
From: Xufeng Liu <xufeng.liu.ietf@gmail.com>
Date: Tue, 11 Jun 2019 09:43:46 -0400
Message-ID: <CAEz6PPRSs5JWxcioo=tf_aHTbR2fNQROPN33-yp9RAoeJtC2BA@mail.gmail.com>
To: Per Hedeland <per@hedeland.org>
Cc: NETMOD WG <netmod@ietf.org>, lsr@ietf.org
Content-Type: multipart/alternative; boundary="0000000000000671ef058b0c7db2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/7lAWRxJXA-VUjCRXT82iEbyvNFw>
Subject: Re: [Lsr] [netmod] A question on the parameter overriding in draft-ietf-isis-yang-isis-cfg
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, 11 Jun 2019 13:44:00 -0000

Thank Per for the clear analysis.  Since the current YANG RFC7950 does not
have a formal way to specify the overriding rule, I agree that the best way
is to remove the default statements from "level-1" and "level-2", as Per,
Martin, and Rob suggested.

Regards,
- Xufeng

[Forwarding Per's reply to LSR mailing list]

On Sun, Jun 9, 2019 at 1:08 PM Per Hedeland <per@hedeland.org> wrote:

> On 2019-06-09 17:28, Juergen Schoenwaelder wrote:
> >
> > YANG does not have 'levels'. This seems to be an ISIS specific
> > question you should ask on the ISIS list.
>
> AFAIK, this list is not restricted to discussions of what YANG "is" or
> "has", but also covers (at least) how YANG can be used, and what the
> semantics of various YANG usage patterns are. I think there is a
> generic YANG question in the problem described, and possibly even an
> indication that the wording in the spec is overly restrictive.
>
> > On Sun, Jun 09, 2019 at 10:35:11AM -0400, Xufeng Liu wrote:
> >> In Section 2.3. and many other locations, the current IS-IS model
> applies
> >> the parameter overriding rule as below:
> >>
> >> [Quote]:
> >>
> >> 2.3 <
> https://tools.ietf.org/html/draft-ietf-isis-yang-isis-cfg-35#section-2..3
> >.
> >> Per-Level Parameters
> >>
> >>
> >>     Some parameters allow a per level configuration.  In this case, the
> >>     parameter is modeled as a container with three configuration
> >>     locations:
> >>
> >>     o  a top-level container: corresponds to level-1-2, so the
> >>        configuration applies to both levels.
> >>
> >>     o  a level-1 container: corresponds to level-1 specific parameters.
> >>
> >>     o  a level-2 container: corresponds to level-2 specific parameters.
> >>
> >>                 +--rw priority
> >>                 |  +--rw value?     uint8
> >>                 |  +--rw level-1
> >>                 |  |  +--rw value?   uint8
> >>                 |  +--rw level-2
> >>                 |     +--rw value?   uint8
> >>
> >>     Example:
> >>
> >>             <priority>
> >>                 <value>250</value>
> >>                 <level-1>
> >>                     <value>100</value>
> >>                 </level-1>
> >>                 <level-2>
> >>                     <value>200</value>
> >>                 </level-2>
> >>             </priority>
> >>
> >>     An implementation SHOULD prefer a level specific parameter over a
> >>     level-all parameter.  As example, if the priority is 100 for the
> >>     level-1, 200 for the level-2 and 250 for the top-level
> configuration,
> >>     the implementation should use 100 for the level-1 and 200 for the
> >>     level-2.
> >>
> >> [End of Quote]
> >>
> >>
> >> In the model, all three value leaves above have a default statement
> >>  default 64 , which brings up my question for the following example:
>
> So, to give an actual YANG snippet for this example, it would be
>
>    container priority {
>      leaf value {
>        type uint8;
>        default 64;
>      }
>      container level-1 {
>        leaf value {
>          type uint8;
>          default 64;
>        }
>      }
>      container level-2 {
>        leaf value {
>          type uint8;
>          default 64;
>        }
>      }
>    }
>
> >>             <priority>
> >>                 <value>250</value>
> >>                 <level-1>
> >>                     <value>100</value>
> >>                 </level-1>
> >>             </priority>
> >>
> >>
> >> The user does not provide a configured value for level-2. According to
> >> Section 7.6.1. of RFC7950, because the default value is in use, "the
> server
> >> MUST operationally behave as if the leaf was present in the data tree
> with
> >> the default value as its value". This means the priority value for
> level-2
> >> will be 64 (the default value), so the value 250 can never take effect
> as
> >> intended in the above quoted Section 2.3.
>
> Obviously there is at least a deficiency in the description, since it
> makes no sense with your (justifiable) interpretation. I think it is
> clear that the *intent* is that the value 250 should take effect for
> level-2 in this case (and I think that this is a very valid design).
> That intent could have been made clear by saying "if the priority is
> *configured* as 100" instead of just "if the priority is 100", since
> the "is" applies equally well to a "default value in effect" and a
> configured value.
>
> But this would seem to violate the statement in RFC 7950, since it
> actually does say that the value 64 MUST be used for level-2 in this
> case. Maybe it should have some conditional like "unless otherwise
> specified" or something - but IMHO it's entirely reasonable that the
> "overall system" behaves differently depending on whether the value
> for a specific leaf is actually configured or is just a
> "default-in-effect".
>
> Then again, in this case one could question what the point of the
> default values for the level-1 and level-2 leafs is. Removing them
> would mean that without values configured, they would use the
> "toplevel" value, whether default or configured - and since the
> defaults *in this case* are all the same, it would amount to the
> exactly the intent I assume above, but without any violation of the
> 7950 statement.
>
> However with different defaults, it is not as straightforward - say
> e.g.
>
>    container priority {
>      leaf value {
>        type uint8;
>      }
>      container level-1 {
>        leaf value {
>          type uint8;
>          default 32;
>        }
>      }
>      container level-2 {
>        leaf value {
>          type uint8;
>          default 64;
>        }
>      }
>    }
>
> IMHO, it would make perfect sense (assuming of course that it is
> documented) for the system to in this case behave like
>
>     configured "toplevel"   configured level-2   use for level-2
>
> 1)      nothing               nothing               64
> 2)        250                 nothing              250
> 3)     irrelevant               128                128
>
> And then the case 2) would again seem to violate the 7950 statement.
>
> --Per
>
> >> Is my understanding correct?
> >>
> >>
> >> Since this is a generic question, I am CC ing NETMOD WG too.
> >>
> >>
> >> Thanks,
> >>
> >> - Xufeng
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>