[netmod] YANG library structure
Martin Bjorklund <mbj@tail-f.com> Fri, 08 December 2017 09:47 UTC
Return-Path: <mbj@tail-f.com>
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 312FF126CB6 for <netmod@ietfa.amsl.com>; Fri, 8 Dec 2017 01:47:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 iEjxZ200fIFq for <netmod@ietfa.amsl.com>; Fri, 8 Dec 2017 01:47:43 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 479791200CF for <netmod@ietf.org>; Fri, 8 Dec 2017 01:47:43 -0800 (PST)
Received: from localhost (h-85-209.A165.priv.bahnhof.se [94.254.85.209]) by mail.tail-f.com (Postfix) with ESMTPSA id 370181AE0398 for <netmod@ietf.org>; Fri, 8 Dec 2017 10:47:41 +0100 (CET)
Date: Fri, 08 Dec 2017 10:47:41 +0100
Message-Id: <20171208.104741.1957721911727198135.mbj@tail-f.com>
To: netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/gKFq3cu1MA8eJ_nd5PM36VEsde8>
Subject: [netmod] YANG library structure
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 08 Dec 2017 09:47:45 -0000
Hi, There has been quite a lot of discussion about the YANG library data model on the list. The authors of draft-ietf-netconf-rfc7895bis have tried to understand all arguments in the discussion, and provide a solution. Below are 3 solution proposals (we have discussed more, but they are basically just variations on the same themes). Absolute Requirements --------------------- o RFC 7950, Section 5.6.5 says: A server MUST NOT implement more than one revision of a module. o draft-ietf-netmod-revised-datastores says: The conventional configuration datastores [...] share exactly the same datastore schema o draft-ietf-netmod-revised-datastores says: The datastore schema for <operational> MUST be a superset of the combined datastore schema used in all configuration datastores except that YANG nodes supported in a configuration datastore MAY be omitted from <operational> if a server is not able to accurately report them. These requirements (of course) still hold, and we think that the YANG library document should explain what they imply for the data reported as part of the library. (For example, all conventional datastores MUST have a reference to the same "schema"). Objectives (in no particular order) ----------------------------------- 1. As efficient as possible for a client to consume. Since the size of the yang library can be quite large, it should be possible for clients to cache the yang library information. 2. A dynamic datastore must be able to implement a module or feature that is not implemented in the conventional datastores. 3. It must be possible to NOT implement a module or feature in operational, even if it is implemented in some other datastore. This is required for transition purposes; a server that wants to implement <operational> should not have to implement all modules at once. 4. A given module can only be implemented in one revision in all datastores. If a module is implemented in more than one datastores, the same revision is implemented in all these datastores. 5. Multiple revisions can be used for import, if import-by revision is used. 6. Nice to have: make it possible to be used by schema mount It should be noted that because of 2 and 3 (and 6), the original data model in RFC 7895 cannot be used. Use Cases --------- Here's a set of use cases that must be supported. C1. conventional + operational, all have the same schema C2. conventional + operational, ietf-hardware is not implemented in conventional C3. conventional + operational, some modules not yet implemented in operational, and some modules are partly implemented in operational. C4. conventional + operational + ephemeral, ephemeral has its own set of modules Alt. A. ------- Each datastore refers to a schema, and each schema contains a flat list of all modules, features, etc. +--ro yang-library +--ro schema* [name] | +--ro name string | +--ro checksum string | +--ro module* [name] | | +--ro name yang:yang-identifier | | +--ro revision? revision-identifier | | +--ro namespace inet:uri | | +--ro location* inet:uri | | +--ro submodule* [name] | | | +--ro name yang:yang-identifier | | | +--ro revision? revision-identifier | | | +--ro location* inet:uri | | +--ro feature* [name] | | | +--ro name yang:yang-identifier | | +--ro deviation* [module] | | +--ro module -> ../../name | +--ro import-only-module* [name revision] | +--ro name yang:yang-identifier | +--ro revision union | +--ro namespace inet:uri | +--ro location* inet:uri | +--ro submodule* [name] | +--ro name yang:yang-identifier | +--ro revision? revision-identifier | +--ro location* inet:uri +--ro datastore* [name] | +--ro name identityref | +--ro schema -> ../../schema/name +--ro checksum string How does this solution handle the use cases above? C1: One schema, all datastores refer to this schema. C2: Two schemas, "conventional" and "operational". They differ in just one element (ietf-hardware). All other module information is entirely duplicated in both. C3: Two schemas, "conventional" and "operational". They differ in the modules not implemented in operational, and operational also has some deviation modules with "not-implemented". C4: Three schemas, "conventional", "ephemeral", "operational". "operational" contains the union of all modules in the other two. Pro: simple on the client, simple on the server Con: verbose, since a single difference requires a complete, new, schema. Alt. B. ------- Each datastore refers to a schema, and each schema contains a list of references to module-sets, and each module-set contains a flat list of all modules, features, etc. When combining module-sets into a schema there MUST NOT be any duplicate module definitions in the module-sets. +--ro yang-library +--ro module-set* [name] | +--ro name string | +--ro checksum string | +--ro module* [name] | | +--ro name yang:yang-identifier | | +--ro revision? revision-identifier | | +--ro namespace inet:uri | | +--ro location* inet:uri | | +--ro submodule* [name] | | | +--ro name yang:yang-identifier | | | +--ro revision? revision-identifier | | | +--ro location* inet:uri | | +--ro feature* [name] | | | +--ro name yang:yang-identifier | | +--ro deviation* [module] | | +--ro module -> ../../name | +--ro import-only-module* [name revision] | +--ro name yang:yang-identifier | +--ro revision union | +--ro namespace inet:uri | +--ro location* inet:uri | +--ro submodule* [name] | +--ro name yang:yang-identifier | +--ro revision? revision-identifier | +--ro location* inet:uri +--ro schema* [name] | +--ro name string | +--ro checksum string | +--ro module-set* -> ../../module-set/name +--ro datastore* [name] | +--ro name identityref | +--ro schema -> ../../schema/name +--ro checksum string How does this solution handle the use cases above? C1: One module-set, one schema, all datastores refer to this schema, the schema refers to the single module-set. C2: Two schemas, "conventional" and "operational", and two module-sets. One module-set contains just "ietf-hardware" and the other everything else. The "operational" schema refers to both module-sets, and the "conventional" to just the one without "ietf-hardware". C3: Two schemas, "conventional" and "operational", and three module-sets. One module-set contains all modules fully implemented in both conventional and operational, one contains the modules implemented only in conventional, and one the modules and deviations for the partly implemented modules in operational. C4: Three schemas, "conventional", "ephemeral", "operational", but just two module-sets. "conventional" refers to one of the module-sets, and "ephemeral" to the other. "operational" refers to both. Pro: less verbose Con: the client has to follow extra references and must combine the result from the references into a single schema. Alt. C. ------- (This is the draft -02 version with just some name changes) Each datastore refers to a schema, and each schema contains a list of references to each module it includes. +--ro yang-library +--ro module* [id] | +--ro id string | +--ro name yang:yang-identifier | +--ro revision? revision-identifier | +--ro location* inet:uri | +--ro namespace inet:uri | +--ro feature* yang:yang-identifier | +--ro deviation* [module] | | +--ro module -> ../../id | +--ro conformance-type enumeration | +--ro submodule* [name] | +--ro name yang:yang-identifier | +--ro revision? revision-identifier | +--ro location* inet:uri +--ro schema* [name] | +--ro name string | +--ro module* -> ../../module/id +--ro datastore* [name] | +--ro name identityref | +--ro schema -> ../../schema/name +--ro checksum string How does this solution handle the use cases above? C1: One schema, all datastores refer to this schema, the schema refers to all modules. C2: Two schemas, "conventional" and "operational", and the module list contains all modules. The "operational" schema refers to all modules, and "conventional" to all modules except "ietf-hardware". C3: similar to C2, except there will be two entries in the module list for evenry module that is partly implemented in operational. C4: Three schemas, "conventional", "ephemeral", "operational", and the module list contains all modules. Each schema refers to the modules it supports. Pro: All modules available are listed in one place. Con: the client has to follow extra references and must combine the result from the references into a single schema. the least "direct" solution due to the module "id". probably a bit tricky to implement on the server. /martin
- [netmod] YANG library structure Martin Bjorklund
- Re: [netmod] YANG library structure Lou Berger
- Re: [netmod] YANG library structure Juergen Schoenwaelder
- Re: [netmod] YANG library structure Lou Berger
- Re: [netmod] YANG library structure Ladislav Lhotka
- Re: [netmod] YANG library structure Juergen Schoenwaelder
- Re: [netmod] YANG library structure Martin Bjorklund
- Re: [netmod] YANG library structure Vladimir Vassilev
- Re: [netmod] YANG library structure Kent Watsen
- Re: [netmod] YANG library structure Andy Bierman