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

tom petch <ietfc@btconnect.com> Tue, 11 June 2019 16:35 UTC

Return-Path: <ietfc@btconnect.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 1866812036B; Tue, 11 Jun 2019 09:35:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.247
X-Spam-Level:
X-Spam-Status: No, score=0.247 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.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 6IkIfySDB-ZL; Tue, 11 Jun 2019 09:35:54 -0700 (PDT)
Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20133.outbound.protection.outlook.com [40.107.2.133]) (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 DB10E120366; Tue, 11 Jun 2019 09:35:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RAhqyTSW2nof7J+wMzob6MHryejV/9G8L/GauQP3BfA=; b=i6LnAj7zd9520nFUIPC9YHsbetSBjeXXSOAZw/O+MLurpaYCJQ/AMce7bc/YXB44ywNHAhMxX4Ddifc7HO7YPj52IvZmQT4o0n7UTHQn7tpJGu0CQpDhFMwiI8i4PzySGL6dLkCZiitAKY/yVOp0h8GTf6ZIoxbi+uvBMo9vGmI=
Received: from VI1PR07MB3118.eurprd07.prod.outlook.com (10.175.242.156) by VI1PR07MB3151.eurprd07.prod.outlook.com (10.175.243.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1987.10; Tue, 11 Jun 2019 16:35:31 +0000
Received: from VI1PR07MB3118.eurprd07.prod.outlook.com ([fe80::7537:44ee:88c1:dd6d]) by VI1PR07MB3118.eurprd07.prod.outlook.com ([fe80::7537:44ee:88c1:dd6d%7]) with mapi id 15.20.1987.010; Tue, 11 Jun 2019 16:35:31 +0000
From: tom petch <ietfc@btconnect.com>
To: "bill.wu@huawei.com" <bill.wu@huawei.com>, Martin Bjorklund <mbj@tail-f.com>
CC: "lsr@ietf.org" <lsr@ietf.org>, "j.schoenwaelder@jacobs-university.de" <j.schoenwaelder@jacobs-university.de>, "xufeng.liu.ietf@gmail.com" <xufeng.liu.ietf@gmail.com>, "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [Lsr] [netmod] A question on the parameter overriding in draft-ietf-isis-yang-isis-cfg
Thread-Index: AQHVIHOvJEZJIZgDJUanW1T7XQrMsg==
Date: Tue, 11 Jun 2019 16:35:31 +0000
Message-ID: <034401d52073$13ab02c0$4001a8c0@gateway.2wire.net>
References: <B8F9A780D330094D99AF023C5877DABAA496568F@nkgeml513-mbx.china.huawei.com> <20190610.100456.969581487209060819.mbj@tail-f.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: LNXP123CA0021.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:d2::33) To VI1PR07MB3118.eurprd07.prod.outlook.com (2603:10a6:802:20::28)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-mailer: Microsoft Outlook Express 6.00.2800.1106
x-originating-ip: [86.139.215.234]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 85839792-1461-4899-cabd-08d6ee8ad1a4
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:VI1PR07MB3151;
x-ms-traffictypediagnostic: VI1PR07MB3151:
x-ms-exchange-purlcount: 4
x-microsoft-antispam-prvs: <VI1PR07MB3151DC4A6F21CDC5918FC9FBA0ED0@VI1PR07MB3151.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 006546F32A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(376002)(136003)(366004)(346002)(396003)(39860400002)(199004)(189003)(13464003)(66946007)(26005)(4720700003)(2501003)(66446008)(446003)(14454004)(966005)(8936002)(73956011)(66476007)(478600001)(305945005)(6246003)(64756008)(186003)(68736007)(66556008)(50226002)(81166006)(316002)(5660300002)(4326008)(71200400001)(53936002)(8676002)(81156014)(25786009)(71190400001)(7736002)(486006)(476003)(2906002)(6306002)(14444005)(9686003)(44736005)(6116002)(3846002)(229853002)(256004)(84392002)(6436002)(6486002)(61296003)(386003)(102836004)(1556002)(66066001)(62236002)(99286004)(81686011)(14496001)(110136005)(54906003)(81816011)(6506007)(52116002)(76176011)(44716002)(86362001)(6512007)(74416001)(7726001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB3151; H:VI1PR07MB3118.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1;
received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: DfHBqxrC6mPPL4HxgJm+OGtonOhj+O+Ds6xX/MoXIaNkZC/+SYtZFJYiaisqdS86eUhq8QYTCzx3CKzISFBP0WsOL2TdnYy/3pOXlhD97GfMZNTla5OmtHj6HyOT98lCTlc7VSuKUsBQHF6sF10x6asCY4wEt6oYX54TRY+5kb3GPCwTPgn4WqIQ5nmwQcycYLRBc/LiWQB0hrGwCo8nHD8Vx+nUrVla4vuglRFXAmJXfTCI5WnJfolvkk8s+FuMBAfyrTPbaDfMq/5ZjgCgBERSSY9+jE/OsuCEf4AW/zQk+i3Tq6dX1zxWSha7UWteQo9sh/MZjXX13kR4la4eyyd3RX2JC82lugEcbYhZy9tf37XxhFICarKOeYQpl+XGFGxtyuSfkW64LaSSA2GzIRW8sz5gCou/khRju9aMYbk=
Content-Type: text/plain; charset="utf-8"
Content-ID: <3B323A393D30DE4CA860C698DE722A1D@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 85839792-1461-4899-cabd-08d6ee8ad1a4
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jun 2019 16:35:31.2667 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ietfc@btconnect.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3151
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/AW9izmJx9N2LHmBvlyAoBIG4NZ8>
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 16:35:57 -0000

A somewhat arbitrary choice of message to reply to, in order to say that
other protocols do have layers, e.g. igmp in
draft-ietf-pim-igmp-mld-yang
but they have taken a different approach.  They have such as
     grouping interface-global-config-attributes {
     grouping interface-common-config-attributes {
     grouping interface-level-config-attributes {
which, as this shows, are groupings, which are then in parallel, rather
than in a hierarchy.  The relationship is specified in text as
"                                     For a
   configuration node at the interface level, there may exist a
   corresponding configuration node with the same name at the
   interface-global level. The value configured on a node at the
   interface level overrides the value configured on the corresponding
   node at the interface-global level "

Clearly you could have some fairly sophisticated YANG to suppress the
interface-global value when that at the interface-level is configured,
but they don't, they rely on correct implementation!  Also, this
structure is not, IMHO, readily apparent in the tree diagram unless you
know what to look for.

Tom Petch

----- Original Message -----
From: "Martin Bjorklund" <mbj@tail-f.com>;
To: <bill.wu@huawei.com>;
Cc: <lsr@ietf.org>;; <j.schoenwaelder@jacobs-university.de>;;
<xufeng.liu.ietf@gmail.com>;; <netmod@ietf.org>;
Sent: Monday, June 10, 2019 9:04 AM

> Hi,
>
> Qin Wu <bill.wu@huawei.com>; wrote:
> > I think what they are looking for in RFC7950 is generic overridden
> > rule, i.e., a parent node statement can be overridden by its child
> > node substatement.
>
> See Per's reply to the netmod list.  In summary, in this case you
> should do:
>
>   container priority {
>     leaf value {
>       type uint8;
>       default 64;
>     }
>     container level-1 {
>       leaf value {
>         type uint8;
>         description
>           "If not configured, use the value of ../../value.";
>       }
>     }
>     container level-2 {
>       leaf value {
>         type uint8;
>         description
>           "If not configured, use the value of ../../level-1/value.";
>       }
>     }
>   }
>
>
>
> /martin
>
>
>
>
> >
> > -Qin
> > -----邮件原件-----
> > 发件人: netmod [mailto:netmod-bounces@ietf.org] 代表 Juergen
> > Schoenwaelder
> > 发送时间: 2019年6月9日 23:28
> > 收件人: Xufeng Liu <xufeng.liu.ietf@gmail.com>;
> > 抄送: lsr@ietf.org; NETMOD WG <netmod@ietf.org>;
> > 主题: Re: [netmod] A question on the parameter overriding in
> > draft-ietf-isis-yang-isis-cfg
> >
> > Hi,
> >
> > YANG does not have 'levels'. This seems to be an ISIS specific
> > question you should ask on the ISIS list.
> >
> > /js
> >
> > 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:
> > >
> > >
> > >            <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.
> > >
> > >
> > > 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
> >
> >
> > --
> > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen |
Germany
> > Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>