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 >
- [Lsr] A question on the parameter overriding in d… Xufeng Liu
- Re: [Lsr] [netmod] A question on the parameter ov… Juergen Schoenwaelder
- Re: [Lsr] [netmod] A question on the parameter ov… Qin Wu
- Re: [Lsr] [netmod] A question on the parameter ov… Rob Wilton (rwilton)
- Re: [Lsr] [netmod] A question on the parameter ov… Martin Bjorklund
- Re: [Lsr] [netmod] A question on the parameter ov… Xufeng Liu
- Re: [Lsr] [netmod] A question on the parameter ov… Per Hedeland
- Re: [Lsr] [netmod] A question on the parameter ov… tom petch
- Re: [Lsr] A question on the parameter overriding … stephane.litkowski