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

Per Hedeland <per@hedeland.org> Sun, 09 June 2019 17:07 UTC

Return-Path: <per@hedeland.org>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19FD31200E3 for <netmod@ietfa.amsl.com>; Sun, 9 Jun 2019 10:07:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outbound.mailhop.org
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 sg2guGeqWFV6 for <netmod@ietfa.amsl.com>; Sun, 9 Jun 2019 10:07:55 -0700 (PDT)
Received: from outbound1p.ore.mailhop.org (outbound1p.ore.mailhop.org [54.149.210.130]) (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 CD84F12003F for <netmod@ietf.org>; Sun, 9 Jun 2019 10:07:55 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1560100074; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=FVZ+3+ZMLVsMvxT4zzKhB8xELGu3pwfgJmic8EDrr4fLz9mlwUU9lIq0JYA1kMWTIpIAyVqqAJmWN l9jnB65jCgzuN56lAGWeZ0cSTk9cjE6PgT4QzbNiGTPb8Mh/CQdw32zu5BbwhyFPqvGGNIkYYnba8h IhP6hd4/lr9IJpxUhsMXzV7BdJOwpmHwym6Q/CWJoY0YhwpTuQHacOT5eeLLtOacpzFAcSNK4jvLvD wWORmJe+9gpeHrTp5QDOW7BkCJR4D7N3WB+B7ZCLqYibJH+7zOQw5Fj9sI/hYZXn8zLnqwh5y/Tk4l 3Oplq7j6qJeOl26sE1z65Q5gz267kjA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:content-type:in-reply-to:mime-version:date: message-id:from:references:to:subject:dkim-signature:from; bh=csDvLDD21wnwN0sWSki41ipwCyofROZOzHOrn8IwN8c=; b=GaxBuyYgVSv25wLFjQ8GzfORms6aXAGSX3IEEPEVCpoequx31JPDOHi/dJmkfiUg7WcbSvvzxaKgQ 2SD81rvI1azNCwjGFj17r2XGFm5wnjvqeGgoy8WoNL8NShigex39D2W81rF1+VRENCZ5VV3Ccg2SXo a3LDc7pP91ZgqIOrso3LBd7uQYS/exR1kXFJS9Mf7DGjOJTfDRqDUdXeCbobo797ZH9yhW3vzKMv/W x+efC2lJm8VC85OCbCChukTEOi20qSqj1w0NM+AdbTFN1UiO040mM+vxR+TuT7oIfJc/pC4IRaSQR3 qSo0k9e5TjS58LfHtLgVFbchlbUXgSQ==
ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org; spf=none smtp.mailfrom=hedeland.org smtp.remote-ip=81.228.155.78; dmarc=none header.from=hedeland.org; arc=none header.oldest-pass=0;
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:content-type:in-reply-to:mime-version:date: message-id:from:references:to:subject:from; bh=csDvLDD21wnwN0sWSki41ipwCyofROZOzHOrn8IwN8c=; b=YU3OSL/6MKTwal7J0MIhu4+LOoiwpv9eZb/Ze6F59Z2ZsgYSiefqrpH72rwJ9nCx00g50//9IcnK0 MKCPgeaBNVM7XRbpygx+RsNt7BJ9+ZLijCv07jMKnYUAeba6liIb09obfVN4EBh2yvNwuviGORbImd owVrjsMtIqZoQoXwCPNVIVs8fO5DZgLHMGSQVyQZ3Dbv5r+L4nHtp8fEJTU63LelNVs/1qWddhPEln ko4hqYdFqTK9xGafMCQfgjvj16B40GaJckHAUeJmXDhSeXBH/ipO6d2ACHn3kx6fNVqqHwduQVMzF7 qL/EcFFJfumDUtU06JiaYCUXL26quZQ==
X-MHO-RoutePath: cGVyaGVkZWxhbmQ=
X-MHO-User: 1ccbdb15-8ad9-11e9-ba65-db796b3fb7af
X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information
X-Originating-IP: 81.228.155.78
X-Mail-Handler: DuoCircle Outbound SMTP
Received: from hedeland.org (unknown [81.228.155.78]) by outbound3.ore.mailhop.org (Halon) with ESMTPSA id 1ccbdb15-8ad9-11e9-ba65-db796b3fb7af; Sun, 09 Jun 2019 17:07:53 +0000 (UTC)
Received: from pluto.hedeland.org (pluto.hedeland.org [10.1.1.5]) by tellus.hedeland.org (8.15.2/8.15.2) with ESMTPS id x59H7n8c057329 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for <netmod@ietf.org>; Sun, 9 Jun 2019 19:07:50 +0200 (CEST) (envelope-from per@hedeland.org)
To: netmod@ietf.org
References: <CAEz6PPSQfshh0=itkUWmT1PMU3XVFNrjk5L49cbNKYr1m1BuWA@mail.gmail.com> <20190609152829.r25rkc4gevnzgcka@anna.jacobs.jacobs-university.de>
From: Per Hedeland <per@hedeland.org>
Message-ID: <cb575f7c-927a-631e-9eb2-12ccf066f53d@hedeland.org>
Date: Sun, 9 Jun 2019 19:07:49 +0200
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <20190609152829.r25rkc4gevnzgcka@anna.jacobs.jacobs-university.de>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/IAi82tf5gy-zf5WQ2Xo4shNCjP4>
Subject: Re: [netmod] A question on the parameter overriding in draft-ietf-isis-yang-isis-cfg
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 09 Jun 2019 17:07:58 -0000

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 CCing NETMOD WG too.
>>
>>
>> Thanks,
>>
>> - Xufeng