Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

Kent Watsen <kwatsen@juniper.net> Wed, 27 July 2016 20:09 UTC

Return-Path: <kwatsen@juniper.net>
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 4CD6A12D926 for <netmod@ietfa.amsl.com>; Wed, 27 Jul 2016 13:09:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level:
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 lkVvVki3NUnV for <netmod@ietfa.amsl.com>; Wed, 27 Jul 2016 13:09:27 -0700 (PDT)
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0124.outbound.protection.outlook.com [104.47.37.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C35F412D8E9 for <netmod@ietf.org>; Wed, 27 Jul 2016 13:09:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fqRJfJz6WJeoOl/GAfrRzm0lsbnV9YM8tFiXP2vE4hM=; b=EybtQkKQDzfK/Gcoa/0Yvt56gZtROImHKX++NPAIDS9jt/4tNMQlX67yY3ussM/sdBje7foGojtHjZGSspRyUcPWPt8AL0/L99Yp0VhEi2UZTP5U07WRkkwd3t3tKm4T1hkCgTIBx23HsNVLsaLcLYYefR/REYwP484JOepE9Gw=
Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CY1PR0501MB1451.namprd05.prod.outlook.com (10.160.149.12) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.557.8; Wed, 27 Jul 2016 20:09:24 +0000
Received: from CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) by CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) with mapi id 15.01.0557.009; Wed, 27 Jul 2016 20:09:25 +0000
From: Kent Watsen <kwatsen@juniper.net>
To: Robert Wilton <rwilton@cisco.com>, netmod WG <netmod@ietf.org>
Thread-Topic: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure
Thread-Index: AQHR426Bbp8QhQYR/0+rHOW0oBTwuqAjJxmAgADv8QCABT5TAIABj1SAgAAMLoCAAZpIAP//8HiA
Date: Wed, 27 Jul 2016 20:09:25 +0000
Message-ID: <5209ADAB-F74E-4F1A-9652-57F0BDD0E359@juniper.net>
References: <D3A935F0.6A4DC%acee@cisco.com> <eb15fd23-2c0a-50c4-1ebc-7c0e4867dfd8@cisco.com> <20160721174033.GB54646@elstar.local> <d18f5dd0-64d0-e223-88a9-faa4df4b7866@cisco.com> <DCB3EBBF-5EB1-4C8E-AA55-F59C4B5A8E4D@juniper.net> <bed9398c-0e6a-450e-d2ac-b381b6bebf87@cisco.com> <5296754B-8178-4B1B-B4A6-FE228ABB8E7F@juniper.net> <9367f4b1-7814-e175-32e8-d518438b841d@cisco.com>
In-Reply-To: <9367f4b1-7814-e175-32e8-d518438b841d@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.18.0.160709
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.241.11]
x-ms-office365-filtering-correlation-id: fc8c7a62-9ebb-479d-a5c8-08d3b659e81d
x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1451; 6:/fT2cXky7hfBiB/v+OGgoEbut1FRR55gwiIQ/afYIh8WPaTVpjM4WVvsPqCtX2PxUw6jLSf3DT6166xlwWiohfnhdKU7HXJdWPOp0LlMaJVd8FpXaK7kMNYgz7Rs9Vh+lXBUI0AwikjqA4GkE5cvdBmjmdo5onn8jWMBif/firJZG9cVCqLIS/Met4nXd18rOtQbyjZ9TvhQmZoF1S90RRt49L59p6BAZeKw2kaxq5MOJ0bmbxa/ZgPoqUquz/DX4qDmKFmqZDGaxILzp6PquWU6xfCqgpbTmmflVnvRuH9/m5MUgPa67GkZ3m1zDMb0h2SIN7TBkqO+rajpJChckw==; 5:7I4QXa/SW5eclFYxHtn5h6LQlN54XiX9NEKn5Z3IER11HZYKJgr8dtdpi0RmOd21H4GFWZ5eEelQ8HUvWz/aObTTLWTBquTbHRNDpGTJU1N+jtmrLIq0klqDNCaAm8gkt6E9LARr+TLwbZUMSPthRQ==; 24:JkAm29frfZYXlbAmKSYOzkRhhYgAeB32ymy5CzrKZgTn7t4Wf9ERjtYg5SzndDT/tKpmK9xhooWPScWsLI+Mt94P0zUs1bXKKXm4SJeIGYc=; 7:ufJsNnODbFHi9s3TUJ2Yzfkg/aCrxWKtyuZqPvW671On9oDKI/e3uZsV6gT0mT+lasUv3XytnQKazFIxe9IT7xPtccbsUYxE36K3S8fo1ZHD+F+vCoAOGd3ifWMcs7zcfvnYjl6/BZfMiEUcieJDeJW0cl+e//WOsc22nlkt1tRK+oQYKh59KUVpzRIYzYqFG6j6jHpE7w+O6dAGSLybvUMZOdqzOSszedWf2ErnQLxaLwIehQRN/YEtDiSyGViw
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1451;
x-microsoft-antispam-prvs: <CY1PR0501MB1451B33D24087C18AF15FA09A50F0@CY1PR0501MB1451.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:CY1PR0501MB1451; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1451;
x-forefront-prvs: 0016DEFF96
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(51444003)(189002)(199003)(189998001)(7736002)(54356999)(5001770100001)(16236675004)(7846002)(86362001)(106356001)(106116001)(2906002)(122556002)(19625215002)(101416001)(50986999)(99286002)(76176999)(87936001)(93886004)(105586002)(33656002)(2950100001)(3660700001)(4001350100001)(97736004)(4326007)(77096005)(3280700002)(5002640100001)(10400500002)(586003)(102836003)(68736007)(82746002)(3846002)(36756003)(92566002)(2900100001)(15975445007)(8676002)(8936002)(83506001)(81166006)(81156014)(66066001)(19300405004)(83716003)(6116002)(19580395003)(217873001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1451; H:CY1PR0501MB1450.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_5209ADABF74E4F1A965257F0BDD0E359junipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jul 2016 20:09:25.0542 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1451
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/4MIhappRT3lnb4lFPnhYI8GQQ5s>
Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
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: Wed, 27 Jul 2016 20:09:30 -0000

>> Firstly, I’m trying to get a sense of how big a problem this
>> foo/foo-state thing is.  [Note: by foo-state, I’m only referring
>> to counters, not opstate].

RW:
By counters, I think that we also mean any config false nodes that don't directly represent "applied configuration", right?  E.g. is an interface operationally up or down.

KW:  Yes, the term “counters” is a misnomer.  We are indeed talking about regular old config false nodes, whether they be used for counters, gauges, or whatever.   It is what the opstate-reqs draft refers to as derived state.



>> I know about RFC 7223, which was done out of consideration
>> for system-generated interfaces, but how many other such models
>> are there envisioned to be?

RW:
- Any models that augment RFC 7223 and have config false nodes will be impacted.
- I thought that quite a lot of other IETF models that are in the process of being standardized have a top level split between "foo" and "foo-state".  E.g the ISIS model (draft-ietf-isis-yang-isis-cfg-08) has this split.  I suspect that all the routing models will be structured similarly.

KW: I also notice that draft-ietf-netmod-routing-cfg does this and, to your point, you know the ietf-routing module is intended to be augmented by many other modules.  This issue is not easily isolated.

RW:
The current guidance for "intended vs applied" is clear.  I.e. there must not be "config false" leaves in the IETF YANG data models to represent "applied config".  But there is no clear guidance for the rest of operational state that isn't applied config.  The other WGs need clear guidance (effectively now) to ensure that they can start publishing models as RFCs.

KW: indeed.



RW:
Personally, I would like one common convention that applies to all IETF YANG models.

Idealistically I would like foo and foo-state to be merged because I think that will make the models easier to use and maintain in the long term, but I don't know if we are just too late to go in that direction.  It seems to me that the NETMOD WG really should try to come to a decision quite quickly on this, but I don't know how to encourage that.  A virtual interim on just this topic perhaps?

KW: I was going to suggest the same - will discuss with Lou.


>> Next, regarding paths forward (assuming 7223 is not an outlier), I’m
>> thinking the opposite.  I’m quite sure that we would never merge the
>> 600+ models with separate subtrees back together again.  So I’m
>> thinking we immediately merge foo and foo-state in all active YANG
>> models (so that the YANG “conceptual” models are stable and good)
>> *and* then we use your idea to programmatically generate the
>> “foo-state” tree, presumably only when needed.  This foo-state tree
>> could be generated offline by tools and provided as a second YANG
>> module in drafts.  In this way, servers (opstate aware or not) can
>> advertise if clients can access the foo-state tree (an opstate-aware
>> server may still advertise it for business reasons, and it can ‘deprecate’
>> the tree when no longer needed).   We could do the same without tools
>> today by just using a feature statement on, for instance, the interfaces-
>> state container, but I like pushing for tooling upfront so that we’re
>> guaranteed mergeability later.  Thoughts?


RW:
So the generated "foo-state" tree would contain a copy of all config false nodes in the YANG schema and a "config false copy" of any config true nodes in the YANG schema that are required to provide parental structure for the descendant config false nodes.
- The Xpath expressions would also need to be adjusted, and possibly some of those might break (or need to be fixed by hand).
- Groupings might be a problem, but potentially they could be expanded.

KW: all good points.

Technically this solution might work, but is it possible to get everyone to agree that this is the right direction to go in before we spend time on this?

KW: it was just an idea.   I’m trying to strike a balance between having the YANG models we want, and what is possible today (while waiting for the opstate solution to roll out).



To flesh this idea out just a bit more, let’s say we have module “ietf-foo” as follows:

module ietf-foo {
  namespace “foo-namespace”;
  container foo {
    list bar {
      key a;
      leaf a {
        type string;
      }
      leaf b {
         type int8;
         config false;
      }
   }
  }
}

whereby it’s possible that the system may generate some bars as well.  To address this, the module is run through a TBD-tool to generate second module foo-state as follows:

module ietf-foo-state {
  namespace “foo-state-namespace”;
  container foo-state {
    list bar {
      config false;    <-- everything below is config false
      key a;
      leaf a {    <-- this config true node kept only because it’s the key
        type string;
      }
      leaf b {
         type int8;
         config false;
      }
   }
  }
}

Now, here are the choices:

1) an opstate-unaware server might only support “ietf-foo”, as it is deemed unnecessary to provide the operational state for system-generated bars.

2) an opstate-unaware server might support both “ietf-foo” and “ietf-foo-state” as follows:

       <get-config>
         <source>
           <running/>
         </source>
         <filter type="subtree">
           <foo xmlns="foo-namespace"/>
         </filter>
       </get-config>

returns the derived state for just configured bars, while:

       <get-config>
         <source>
           <running/>
         </source>
         <filter type="subtree">
           <foo-state xmlns="foo-state-namespace"/>
         </filter>
       </get-config>

returns the derived state for both configured and system-generated bars.

3) an opstate-aware server only support “ietf-foo”, as it is expected that the derived state for system-generated bars can be obtained another way (e.g., via the “operational” datastore).

4) an opstate-aware server supports both “ietf-foo” and “ietf-foo-state”, most likely for backwards compatibility reasons.   The examples provided under (2) above continue to work and, later in time, the vendor can deprecate support for ietf-foo-state.


Kent  // as a contributor