draft-ietf-netmod-schema-mount-03.txt   draft-ietf-netmod-schema-mount-04.txt 
Network Working Group M. Bjorklund Network Working Group M. Bjorklund
Internet-Draft Tail-f Systems Internet-Draft Tail-f Systems
Intended status: Standards Track L. Lhotka Intended status: Standards Track L. Lhotka
Expires: May 4, 2017 CZ.NIC Expires: September 7, 2017 CZ.NIC
October 31, 2016 March 6, 2017
YANG Schema Mount YANG Schema Mount
draft-ietf-netmod-schema-mount-03 draft-ietf-netmod-schema-mount-04
Abstract Abstract
This document defines a mechanism to combine YANG modules into the This document defines a mechanism to combine YANG modules into the
schema defined in other YANG modules. schema defined in other YANG modules.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 32 skipping to change at page 1, line 32
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 4, 2017. This Internet-Draft will expire on September 7, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 5
1.1.1. Tree Diagrams . . . . . . . . . . . . . . . . . . . . 2 2.1. Glossary of New Terms . . . . . . . . . . . . . . . . . . 6
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 6
3. Schema Mount . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Namespace Prefixes . . . . . . . . . . . . . . . . . . . 6
3.1. Augment and Validation in Mounted Data . . . . . . . . . 4 3. Schema Mount . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Top-level RPCs . . . . . . . . . . . . . . . . . . . . . 4 3.1. Mount Point Definition . . . . . . . . . . . . . . . . . 7
3.3. Top-level Notifications . . . . . . . . . . . . . . . . . 5 3.2. Specification of the Mounted Schema . . . . . . . . . . . 7
4. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Multiple Levels of Schema Mount . . . . . . . . . . . . . 11
5. Schema Mount YANG Module . . . . . . . . . . . . . . . . . . 6 4. Refering to Data Nodes in the Parent Schema . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 5. RPC operations and Notifications . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Implementation Notes . . . . . . . . . . . . . . . . . . . . 13
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12 7. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. Schema Mount YANG Module . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . 12 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
9.2. Informative References . . . . . . . . . . . . . . . . . 13 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21
Appendix A. Example: Logical Devices . . . . . . . . . . . . . . 14 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 21
Appendix B. Example: Network Manager with Fixed Device Models . 16 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
Appendix C. Example: Network Manager with Arbitrary Device 12.1. Normative References . . . . . . . . . . . . . . . . . . 21
Models . . . . . . . . . . . . . . . . . . . . . . . 19 12.2. Informative References . . . . . . . . . . . . . . . . . 22
C.1. Invoking an RPC . . . . . . . . . . . . . . . . . . . . . 23 Appendix A. Example: Device Model with LNEs and NIs . . . . . . 23
Appendix D. Open Issues . . . . . . . . . . . . . . . . . . . . 23 A.1. Physical Device . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 A.2. Logical Network Elements . . . . . . . . . . . . . . . . 24
A.3. Network Instances . . . . . . . . . . . . . . . . . . . . 27
A.4. Invoking an RPC Operation . . . . . . . . . . . . . . . . 29
Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 29
B.1. Referencing Mount Points Using Schema Node Identifiers . 29
B.2. Defining the "mount-point" Extension in a Separate Module 30
B.3. Parent References . . . . . . . . . . . . . . . . . . . . 31
B.4. RPC Operations and Notifications in Mounted Modules . . . 31
B.5. Tree Representation . . . . . . . . . . . . . . . . . . . 32
B.6. Design-Time Mounts . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
1.1. Terminology Modularity and extensibility were among the leading design principles
of the YANG data modeling language. As a result, the same YANG
module can be combined with various sets of other modules and thus
form a data model that is tailored to meet the requirements of a
specific use case. Server implementors are only required to specify
all YANG modules comprising the data model (together with their
revisions and other optional choices) in the YANG library data
([RFC7895], and Section 5.6.4 of [RFC7950]) implemented by the
server. Such YANG modules appear in the data model "side by side",
i.e., top-level data nodes of each module - if there are any - are
also top-level nodes of the overall data model.
Furthermore, YANG has two mechanisms for contributing a schema
hierarchy defined elsewhere to the contents of an internal node of
the schema tree; these mechanisms are realized through the following
YANG statements:
o The "uses" statement explicitly incorporates the contents of a
grouping defined in the same or another module. See Section 4.2.6
of [RFC7950] for more details.
o The "augment" statement explicitly adds contents to a target node
defined in the same or another module. See Section 4.2.8 of
[RFC7950] for more details.
With both mechanisms, the source or target YANG module explicitly
defines the exact location in the schema tree where the new nodes are
placed.
In some cases these mechanisms are not sufficient; it is often
necessary that an existing module (or a set of modules) is added to
the data model starting at a non-root location. For example, YANG
modules such as "ietf-interfaces" [RFC7223] are often defined so as
to be used in a data model of a physical device. Now suppose we want
to model a device that supports multiple logical devices
[I-D.ietf-rtgwg-lne-model], each of which has its own instantiation
of "ietf-interfaces", and possibly other modules, but, at the same
time, we want to be able to manage all these logical devices from the
master device. Hence, we would like to have a schema like this:
+--rw interfaces
| +--rw interface* [name]
| ...
+--rw logical-device* [name]
+--rw name
| ...
+--rw interfaces
+--rw interface* [name]
...
With the "uses" approach, the complete schema tree of
"ietf-interfaces" would have to be wrapped in a grouping, and then
this grouping would have to be used at the top level (for the master
device) and then also in the "logical-device" list (for the logical
devices). This approach has several disadvantages:
o It is not scalable because every time there is a new YANG module
that needs to be added to the logical device model, we have to
update the model for logical devices with another "uses" statement
pulling in contents of the new module.
o Absolute references to nodes defined inside a grouping may break
if the grouping is used in different locations.
o Nodes defined inside a grouping belong to the namespace of the
module where it is used, which makes references to such nodes from
other modules difficult or even impossible.
o It would be difficult for vendors to add proprietary modules when
the "uses" statements are defined in a standard module.
With the "augment" approach, "ietf-interfaces" would have to augment
the "logical-device" list with all its nodes, and at the same time
define all its nodes at the top level. The same hierarchy of nodes
would thus have to be defined twice, which is clearly not scalable
either.
This document introduces a new generic mechanism, denoted as schema
mount, that allows for mounting one data model consisting of any
number of YANG modules at a specified location of another (parent)
schema. Unlike the "uses" and "augment" approaches discussed above,
the mounted modules needn't be specially prepared for mounting and,
consequently, existing modules such as "ietf-interfaces" can be
mounted without any modifications.
The basic idea of schema mount is to label a data node in the parent
schema as the mount point, and then define a complete data model to
be attached to the mount point so that the labeled data node
effectively becomes the root node of the mounted data model.
In principle, the mounted schema can be specified at three different
phases of the data model life cycle:
1. Design-time: the mounted schema is defined along with the mount
point in the parent module. In this case, the mounted schema has
to be the same for every implementation of the parent module.
2. Implementation-time: the mounted schema is defined by a server
implementor and is as stable as YANG library information, i.e.,
it may change after an upgrade of server software but not after
rebooting the server. Also, a client can learn the entire schema
together with YANG library data.
3. Run-time: the mounted schema is defined by instance data that is
part of the mounted data model. If there are multiple instances
of the same mount point (e.g., in multiple entries of a list),
the mounted data model may be different for each instance.
The schema mount mechanism defined in this document provides support
only for the latter two cases because design-time definition of the
mounted schema doesn't play well with the existing YANG modularity
mechanisms. For example, it would be impossible to augment the
mounted data model.
Schema mount applies to the data model, and specifically does not
assume anything about the source of instance data for the mounted
schemas. It may be implemented using the same instrumentation as the
rest of the system, or it may be implemented by querying some other
system. Future specifications may define mechanisms to control or
monitor the implementation of specific mount points.
This document allows mounting of complete data models only. Other
specifications may extend this model by defining additional
mechanisms such as mounting sub-hierarchies of a module.
2. Terminology and Notation
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14, [RFC2119]. 14, [RFC2119].
1.1.1. Tree Diagrams The following terms are defined in [RFC6241] and are not redefined
here:
A simplified graphical representation of the data model is used in o client
this document. The meaning of the symbols in these diagrams is as
follows: o notification
o server
The following terms are defined in [RFC7950] and are not redefined
here:
o action
o configuration data
o container
o list
o operation
The following terms are defined in [RFC7223] and are not redefined
here:
o system-controlled interface
2.1. Glossary of New Terms
o inline schema: a mounted schema whose definition is provided as
part of the mounted data, using YANG library [RFC7895].
o mount point: container or list node whose definition contains the
"mount-point" extension statement. The argument of the
"mount-point" statement defines the name of the mount point.
o parent schema (of a particular mounted schema): the schema that
contains the mount point for the mounted schema.
o top-level schema: a schema according to [RFC7950] in which schema
trees of each module (except augments) start at the root node.
2.2. Tree Diagrams
A simplified graphical representation of the data model is used in
this document. The meaning of the symbols in these diagrams is as
follows:
o Brackets "[" and "]" enclose list keys. o Brackets "[" and "]" enclose list keys.
o Abbreviations before data node names: "rw" means configuration o Abbreviations before data node names: "rw" means configuration
data (read-write) and "ro" state data (read-only). data (read-write) and "ro" state data (read-only).
o Symbols after data node names: "?" means an optional node, "!" o Symbols after data node names: "?" means an optional node, "!"
means a presence container, and "*" denotes a list and leaf-list. means a presence container, and "*" denotes a list and leaf-list.
o Parentheses enclose choice and case nodes, and case nodes are also o Parentheses enclose choice and case nodes, and case nodes are also
marked with a colon (":"). marked with a colon (":").
o Ellipsis ("...") stands for contents of subtrees that are not o Ellipsis ("...") stands for contents of subtrees that are not
shown. shown.
2. Background 2.3. Namespace Prefixes
YANG has two mechanisms for extending a data model with additional In this document, names of data nodes, YANG extensions, actions and
nodes; "uses" and "augment". The "uses" statement explicitly other data model objects are often used without a prefix, as long as
incorporates the contents of a "grouping" defined in some other it is clear from the context in which YANG module each name is
module. The "augment" statement explicitly adds contents to a target defined. Otherwise, names are prefixed using the standard prefix
node defined in some other module. In both these cases, the source associated with the corresponding YANG module, as shown in Table 1.
and/or target model explicitly defines the relationship between the
models.
In some cases these mechanisms are not sufficient. For example, +---------+------------------------+-----------+
suppose we have a model like ietf-interfaces [RFC7223] that is | Prefix | YANG module | Reference |
defined to be implemented in a device. Now suppose we want to model +---------+------------------------+-----------+
a device that supports multiple logical devices | yangmnt | ietf-yang-schema-mount | Section 8 |
[I-D.rtgyangdt-rtgwg-device-model], where each such logical device | inet | ietf-inet-types | [RFC6991] |
has its own instantiation of ietf-interfaces (and other models), but | yang | ietf-yang-types | [RFC6991] |
at the same time, we'd like to be able to manage all these logical | yanglib | ietf-yang-library | [RFC7895] |
devices from the main device. We would like something like this: +---------+------------------------+-----------+
+--rw interfaces Table 1: Namespace Prefixes
| +--rw interface* [name]
| ... 3. Schema Mount
+--rw logical-device* [name]
+--rw name string The schema mount mechanism defined in this document provides a new
| ... extensibility mechanism for use with YANG 1.1. In contrast to the
+--rw interfaces existing mechanisms described in Section 1, schema mount defines the
+--rw interface* [name] relationship between the source and target YANG modules outside these
modules. The procedure consists of two separate steps that are
described in the following subsections.
3.1. Mount Point Definition
A "container" or "list" node becomes a mount point if the
"mount-point" extension (defined in the "ietf-yang-schema-mount"
module) is used in its definition. This extension can appear only as
a substatement of "container" and "list" statements.
The argument of the "mount-point" extension is a YANG identifier that
defines the name of the mount point. A module MAY contain multiple
"mount-point" statements having the same argument.
It is therefore up to the designer of the parent schema to decide
about the placement of mount points. A mount point can also be made
conditional by placing "if-feature" and/or "when" as substatements of
the "container" or "list" statement that represents the mount point.
The "mount-point" statement MUST NOT be used in a YANG version 1
module. Note, however, that modules written in any YANG version,
including version 1, can be mounted under a mount point.
3.2. Specification of the Mounted Schema
Mounted schemas for all mount points in the parent schema are defined
as state data in the "yangmnt:schema-mounts" container. Data in this
container is intended to be as stable as data in the top-level YANG
library [RFC7895]. In particular, it SHOULD NOT change during the
same management session.
The "schema-mount" container has the "mount-point" list as one of its
children. Every entry of this list refers through its key to a mount
point and specifies the mounted schema.
If a mount point is defined in the parent schema but does not have an
entry in the "mount-point" list, then the mounted schema is void,
i.e., instances of that mount point MUST NOT contain any data above
those that are defined in the parent schema.
If multiple mount points with the same name are defined in the same
module - either directly or because the mount point is defined in a
grouping and the grouping is used multiple times - then the
corresponding "mount-point" entry applies equally to all such mount
points.
The "config" property of mounted schema nodes is overriden and all
nodes in the mounted schema are read-only ("config false") if at
least one of the following conditions is satisfied for a mount point:
1. The mount point is itself defined as "config false".
2. The "config" leaf in the corresponding entry of the "mount-point"
list is set to "false".
An entry of the "mount-point" list can specify the mounted schema in
two different ways:
1. by stating that the schema is available inline, i.e., in run-time
instance data; or
2. by referring to one or more entries of the "schema" list in the
same instance of "schema-mounts".
In case 1, every instance of the mount point that exists in the
parent tree MUST contain a copy of YANG library data [RFC7895] that
defines the mounted schema exactly as for a top-level data model. A
client is expected to retrieve this data from the instance tree,
possibly after creating the mount point. Instances of the same mount
point MAY use different mounted schemas.
In case 2, the mounted schema is defined by the combination of all
"schema" entries referred to in the "use-schema" list. Optionally, a
reference to a "schema" entry can be made conditional by including
the "when" leaf. Its argument is an XPath expression that is
evaluated in the parent tree with the mount point instance as the
context node. The conditional "schema" entry is used only if the
XPath expression evaluates to true. XPath expressions in the
argument of "when" may use namespace prefixes that are declared in
the "namespace" list (child of "schema-mounts").
Conditional schemas may be used, for example, in a situation where
virtual devices are of several different types and the schema for
each type is fixed and known in advance. The list of virtual devices
in a parent schema module (say "example-virtual-host") might be
defined as follows:
list virtual-device {
key name;
leaf name {
type string;
}
leaf type {
type identityref {
base virtual-device-type;
}
}
container root {
yangmnt:mount-point virtual-device;
}
The "schema-mounts" specification in state data might contain, for
example,
"yangmnt:schema-mounts": {
"namespace": [
{
"prefix": "evh",
"ns-uri": "http://example.org/ns/example-virtual-host"
}
],
"mount-point": [
{
"module": "example-virtual-host",
"name": "root",
"use-schema": [
{
"name": "virtual-router-schema",
"when": "derived-from(../evh:type, 'evh:virtual-router')"
},
{
"name": "virtual-switch-schema",
"when": "derived-from(../evh:type, 'evh:virtual-switch')"
}
],
"schema": [
{
"name": "virtual-router-schema",
"module": [
... ...
]
},
{
"name": "virtual-switch-schema",
"module": [
...
]
}
]
}
With the "uses" approach, ietf-interfaces would have to define a The schema of virtual device instances can then be controlled by
grouping with all its nodes, and the new model for logical devices setting the "type" leaf to an appropriate identity derived from the
would have to use this grouping. This is a not a scalable solution, "virtual-device-type" base.
since every time there is a new model defined, we would have to
update our model for logical devices to use a grouping from the new
model. Another problem is that this approach cannot handle vendor-
specific modules.
With the "augment" approach, ietf-interfaces would have to augment In case 2, the mounted schema is specified as implementation-time
the logical-device list with all its nodes, and at the same time data that can be retrieved together with YANG library data for the
define all its nodes on the top-level. This approach is also not parent schema, i.e., even before any instances of the mount point
scalable, since there may be other models to which we would like to exist. However, the mounted schema has to be the same for all
add the interface list. instances of the mount point (except for parts that are conditional
due to "when" leaves).
3. Schema Mount Each entry of the "schema" list contains
The schema mount mechanism defined in this document takes a different o a list in the YANG library format specifying all YANG modules (and
approach to the extensibility problem described in the previous revisions etc.) that are implemented or imported in the mounted
section. It decouples the definition of the relation between the schema;
source and target models from the definitions of the models
themselves.
This is accomplished with a YANG extension statement that is used to o (optionally) a new "schema-mounts" specification that applies to
specify a mount point in a data model. The purpose of a mount point mount points defined within the mounted schema.
is to define a place in the node hierarchy where other YANG data
models may be attached, without any special notation in the other
YANG data models. Only "anydata" nodes can be used as mount points.
For each mount point supported by a server, the server populates an 3.3. Multiple Levels of Schema Mount
operational state node hierarchy with information about which models
it has mounted. This node hierarchy can be read by a client in order
to learn what is implemented on a server.
Schema mount applies to the data model, and specifically does not YANG modules in a mounted schema MAY again contain mount points under
assume anything about how the mounted data is implemented. It may be which subschemas can be mounted. Consequently, it is possible to
implemented using the same instrumentation as the rest of the system, construct data models with an arbitrary number of schema levels. A
or it may be implemented by querying some other system. Future subschema for a mount point contained in a mounted module can be
specifications may define mechanisms to control or monitor the specified in one of the following ways:
implementation of specific mount points.
This document allows mounting of complete data models only. Other o by implementing "ietf-yang-library" and "ietf-yang-schema-mount"
specifications may extend this model by defining additional modules in the mounted schema, and specifying the subschemas
mechanisms, for example mounting of sub-hierarchies of a module. exactly as it is done in the top-level schema
3.1. Augment and Validation in Mounted Data o by using the "mount-point" list inside the coresponding "schema"
entry.
All paths (in leafrefs, instance-identifiers, XPath expressions, and The former method is applicable to both "inline" and "use-schema"
target nodes of augments) in the data models mounted at a mount point cases whereas the latter requires the "use-schema" case. On the
are interpreted with the mount point as the root node, and the other hand, the latter method allows for a compact representation of
mounted data nodes as its children. This means that data within a a multi-level schema the does not rely on the presence of any
mounted subtree can never refer to data outside of this subtree. instance data.
3.2. Top-level RPCs 4. Refering to Data Nodes in the Parent Schema
If any mounted data model defines RPCs, these RPCs can be invoked by A fundamental design principle of schema mount is that the mounted
clients by treating them as actions defined where the mount point is data model works exactly as a top-level data model, i.e., it is
specified. An example of this is given in Appendix C.1. confined to the "mount jail". This means that all paths in the
mounted data model (in leafrefs, instance-identifiers, XPath
expressions, and target nodes of augments) are interpreted with the
mount point as the root node. YANG modules of the mounted schema as
well as corresponding instance data thus cannot refer to schema nodes
or instance data outside the mount jail.
3.3. Top-level Notifications However, this restriction is sometimes too severe. A typical example
are network instances (NI) [I-D.ietf-rtgwg-ni-model], where each NI
has its own routing engine but the list of interfaces is global and
shared by all NIs. If we want to model this organization with the NI
schema mounted using schema mount, the overall schema tree would look
schematically as follows:
If the server emits a notification defined at the top-level in any +--rw interfaces
mounted data model, it is treated as if the notification was attached | +--rw interface* [name]
to the data node where the mount point is specified. | ...
+--rw network-instances
+--rw network-instance* [name]
+--rw name
+--rw root
+--rw routing
...
4. Data Model Here, the "root" node is the mount point for the NI schema. Routing
configuration inside an NI often needs to refer to interfaces (at
least those that are assigned to the NI), which is impossible unless
such a reference can point to a node in the parent schema (interface
name).
Therefore, schema mount also allows for such references, albeit in a
limited and controlled way. The "schema-mounts" container has a
child leaf-list named "parent-reference" that contains zero or more
module names. All modules appearing in this leaf-list MUST be
implemented in the parent schema and MUST NOT be implemented in the
mounted schema. All absolute leafref paths and instance identifiers
within the mounted data model and corresponding instance data tree
are then evaluated as follows:
o If the leftmost node-identifier (right after the initial slash)
belongs to the namespace of a module that is listed in
"parent-reference", then the root of the accessible tree is not
the mount point but the root of the parent schema.
o Other rules for the "leafref" and "instance-identifier" types as
defined in Sections 9.9 and 9.13 of [RFC7950] remain in effect.
It is worth emphasizing that the mount jail can be escaped only via
absolute leafref paths and instance identifiers. Relative leafref
paths, "must"/"when" expressions and schema node identifiers are
still restricted to the mounted schema.
5. RPC operations and Notifications
If a mounted YANG module defines an RPC operation, clients can invoke
this operation by representing it as an action defined for the
corresponding mount point, see Section 7.15 of ^RFC7950. An example
of this is given in Appendix A.4.
Similarly, if the server emits a notification defined at the top
level of any mounted module, it MUST be represented as if the
notification was connected to the mount point, see Section 7.16 of
[RFC7950].
6. Implementation Notes
Network management of devices that use a data model with schema mount
can be implemented in different ways. However, the following
implementations options are envisioned as typical:
o shared management: instance data of both parent and mounted
schemas are accessible within the same management session.
o split management: one (master) management session has access to
instance data of both parent and mounted schemas but, in addition,
an extra session exists for every instance of the mount point,
having access only to the mounted data tree.
7. Data Model
This document defines the YANG 1.1 module [RFC7950] This document defines the YANG 1.1 module [RFC7950]
"ietf-yang-schema-mount", which has the following structure: "ietf-yang-schema-mount", which has the following structure:
module: ietf-yang-schema-mount module: ietf-yang-schema-mount
+--ro schema-mounts +--ro schema-mounts
+--ro namespace* [prefix] +--ro namespace* [prefix]
| +--ro prefix yang:yang-identifier | +--ro prefix yang:yang-identifier
| +--ro ns-uri? inet:uri | +--ro ns-uri? inet:uri
+--ro mount-point* [module name] +--ro mount-point* [module name]
| +--ro module yang:yang-identifier | +--ro module yang:yang-identifier
| +--ro name yang:yang-identifier | +--ro name yang:yang-identifier
| +--ro (subschema-ref)? | +--ro config? boolean
| +--ro (schema-ref)?
| +--:(inline) | +--:(inline)
| | +--ro inline? empty | | +--ro inline? empty
| +--:(use-schema) | +--:(use-schema)
| +--ro use-schema* [name] | +--ro use-schema* [name]
| +--ro name -> /schema-mounts/schema/name | +--ro name
| +--ro when? yang:xpath1.0 | | -> /schema-mounts/schema/name
| +--ro when? yang:xpath1.0
| +--ro parent-reference* yang:yang-identifier
+--ro schema* [name] +--ro schema* [name]
+--ro name string +--ro name string
+--ro module* [name revision] +--ro module* [name revision]
| +--ro name yang:yang-identifier | +--ro name yang:yang-identifier
| +--ro revision union | +--ro revision union
| +--ro schema? inet:uri | +--ro schema? inet:uri
| +--ro namespace inet:uri | +--ro namespace inet:uri
| +--ro feature* yang:yang-identifier | +--ro feature* yang:yang-identifier
| +--ro deviation* [name revision] | +--ro deviation* [name revision]
| | +--ro name yang:yang-identifier | | +--ro name yang:yang-identifier
| | +--ro revision union | | +--ro revision union
| +--ro conformance-type enumeration | +--ro conformance-type enumeration
| +--ro submodule* [name revision] | +--ro submodule* [name revision]
| +--ro name yang:yang-identifier | +--ro name yang:yang-identifier
| +--ro revision union | +--ro revision union
| +--ro schema? inet:uri | +--ro schema? inet:uri
+--ro mount-point* [module name] +--ro mount-point* [module name]
+--ro module yang:yang-identifier +--ro module yang:yang-identifier
+--ro name yang:yang-identifier +--ro name yang:yang-identifier
+--ro (subschema-ref)? +--ro config? boolean
+--ro (schema-ref)?
+--:(inline) +--:(inline)
| +--ro inline? empty | +--ro inline? empty
+--:(use-schema) +--:(use-schema)
+--ro use-schema* [name] +--ro use-schema* [name]
+--ro name -> /schema-mounts/schema/name +--ro name
+--ro when? yang:xpath1.0 | -> /schema-mounts/schema/name
+--ro when? yang:xpath1.0
+--ro parent-reference* yang:yang-identifier
5. Schema Mount YANG Module 8. Schema Mount YANG Module
This module references [RFC6991] and [RFC7895]. This module references [RFC6991] and [RFC7895].
<CODE BEGINS> file "ietf-yang-schema-mount@2016-04-05.yang" <CODE BEGINS> file "ietf-yang-schema-mount@2017-03-06.yang"
module ietf-yang-schema-mount {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount";
prefix yangmnt;
import ietf-inet-types {
prefix inet;
reference
"RFC 6991: Common YANG Data Types";
}
import ietf-yang-types { module ietf-yang-schema-mount {
prefix yang; yang-version 1.1;
reference namespace "urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount";
"RFC 6991: Common YANG Data Types"; prefix yangmnt;
}
import ietf-yang-library { import ietf-inet-types {
prefix yanglib; prefix inet;
reference reference
"RFC 7895: YANG Module Library"; "RFC 6991: Common YANG Data Types";
} }
organization import ietf-yang-types {
"IETF NETMOD (NETCONF Data Modeling Language) Working Group"; prefix yang;
reference
"RFC 6991: Common YANG Data Types";
}
contact import ietf-yang-library {
"WG Web: <https://tools.ietf.org/wg/netmod/> prefix yanglib;
WG List: <mailto:netmod@ietf.org> reference
"RFC 7895: YANG Module Library";
}
WG Chair: Lou Berger organization
<mailto:lberger@labn.net> "IETF NETMOD (NETCONF Data Modeling Language) Working Group";
WG Chair: Kent Watsen contact
<mailto:kwatsen@juniper.net> "WG Web: <https://tools.ietf.org/wg/netmod/>
WG List: <mailto:netmod@ietf.org>
Editor: Martin Bjorklund Editor: Martin Bjorklund
<mailto:mbj@tail-f.com> <mailto:mbj@tail-f.com>
Editor: Ladislav Lhotka Editor: Ladislav Lhotka
<mailto:lhotka@nic.cz>"; <mailto:lhotka@nic.cz>";
description description
"This module defines a YANG extension statement that can be used "This module defines a YANG extension statement that can be used
to incorporate data models defined in other YANG modules in a to incorporate data models defined in other YANG modules in a
module. It also defines operational state data that specify the module. It also defines operational state data that specify the
overall structure of the data model. overall structure of the data model.
Copyright (c) 2016 IETF Trust and the persons identified as Copyright (c) 2017 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to without modification, is permitted pursuant to, and subject to
the license terms contained in, the Simplified BSD License set the license terms contained in, the Simplified BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and
'OPTIONAL' in the module text are to be interpreted as described 'OPTIONAL' in the module text are to be interpreted as described
in RFC 2119 (https://tools.ietf.org/html/rfc2119). in RFC 2119 (https://tools.ietf.org/html/rfc2119).
This version of this YANG module is part of RFC XXXX This version of this YANG module is part of RFC XXXX
(https://tools.ietf.org/html/rfcXXXX); see the RFC itself for (https://tools.ietf.org/html/rfcXXXX); see the RFC itself for
full legal notices."; full legal notices.";
revision 2016-10-26 { revision 2017-03-06 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: YANG Schema Mount"; "RFC XXXX: YANG Schema Mount";
} }
/* /*
* Extensions * Extensions
*/ */
extension mount-point { extension mount-point {
argument name; argument name;
description description
"The argument 'name' is a yang-identifier. The name of the "The argument 'name' is a YANG identifier, i.e., it is of the
mount point MUST be unique within the module where it is type 'yang:yang-identifier'.
defined.
The 'mount-point' statement can only be present as a The 'mount-point' statement MUST NOT be used in a YANG
substatement of 'anydata'. version 1 module, neither explicitly nor via a 'uses'
statement.
If a mount point is defined in a grouping, its name is bound The 'mount-point' statement MAY be present as a substatement
to the module where the grouping is used. Note that this of 'container' and 'list', and MUST NOT be present elsewhere.
implies that such a grouping can be used at most once in a
module.
A mount point defines a place in the node hierarchy where If a mount point is defined in a grouping, its name is bound
other data models may be attached. A server that implements a to the module where the grouping is used.
module with a mount point, populates the
/schema-mounts/mount-point list with detailed information on
which data models are mounted at each mount point.";
}
/* A mount point defines a place in the node hierarchy where
* Groupings other data models may be attached. A server that implements a
*/ module with a mount point populates the
/schema-mounts/mount-point list with detailed information on
which data models are mounted at each mount point.";
}
grouping mount-point-list { /*
description * Groupings
"This grouping is used inside the 'schema-mounts' container and */
inside the 'schema' list.";
list mount-point {
key "module name";
description
"Each entry of this list specifies a subschema for a
particular mount point.
Each mount point MUST be defined using the 'mount-point' grouping mount-point-list {
extension in one of the modules listed in the corresponding description
YANG library instance with conformance type 'implement'. The "This grouping is used inside the 'schema-mounts' container and
corresponding YANG library instance is: inside the 'schema' list.";
list mount-point {
key "module name";
description
"Each entry of this list specifies a schema for a particular
mount point.
- standard YANG library state data as defined in RFC 7895, if Each mount point MUST be defined using the 'mount-point'
the 'mount-point' list is a child of 'schema-mounts', extension in one of the modules listed in the corresponding
YANG library instance with conformance type 'implement'. The
corresponding YANG library instance is:
- the contents of the sibling 'yanglib:modules-state' - standard YANG library state data as defined in RFC 7895,
container, if the 'mount-point' list is a child of if the 'mount-point' list is a child of 'schema-mounts',
'schema'.";
leaf module {
type yang:yang-identifier;
description
"Name of a module containing the mount point.";
}
leaf name {
type yang:yang-identifier;
description
"Name of the mount point defined using the 'mount-point'
extension.";
}
choice subschema-ref {
description
"Alternative way for specifying the subschema.";
leaf inline {
type empty;
description
"This leaf indicates that the server has mounted
'ietf-yang-library' and 'ietf-schema-mount' at the mount
point, and their instantiation (i.e., state data
containers 'yanglib:modules-state' and 'schema-mounts')
provides the information about the mounted schema.";
}
list use-schema {
key "name";
description
"Each entry of this list contains a reference to a
subschema defined in the /schema-mounts/schema list. The
entry can be made conditional by specifying an XPath
expression in the 'when' leaf.";
leaf name {
type leafref {
path "/schema-mounts/schema/name";
}
description
"Name of the referenced schema.";
}
leaf when {
type yang:xpath1.0;
description
"This leaf contains an XPath expression. If it is
present, then the current entry applies if and only if
the expression evaluates to true.
The XPath expression is evaluated once for each - the contents of the sibling 'yanglib:modules-state'
instance of the anydata node containing the mount container, if the 'mount-point' list is a child of
point for which the 'when' leaf is defined. 'schema'.";
leaf module {
type yang:yang-identifier;
description
"Name of a module containing the mount point.";
}
leaf name {
type yang:yang-identifier;
description
"Name of the mount point defined using the 'mount-point'
extension.";
}
leaf config {
type boolean;
default "true";
description
"If this leaf is set to 'false', then all data nodes in the
mounted schema are read-only (config false), regardless of
their 'config' property.";
The XPath expression is evaluated using the rules }
specified in sec. 6.4 of RFC 7950, with these choice schema-ref {
modifications: description
"Alternatives for specifying the schema.";
leaf inline {
type empty;
description
"This leaf indicates that the server has mounted
'ietf-yang-library' and 'ietf-schema-mount' at the mount
point, and their instantiation (i.e., state data
containers 'yanglib:modules-state' and 'schema-mounts')
provides the information about the mounted schema.";
}
list use-schema {
key "name";
description
"Each entry of this list contains a reference to a schema
defined in the /schema-mounts/schema list. The entry can
be made conditional by specifying an XPath expression in
the 'when' leaf.";
leaf name {
type leafref {
path "/schema-mounts/schema/name";
}
description
"Name of the referenced schema.";
}
leaf when {
type yang:xpath1.0;
description
"This leaf contains an XPath expression. If it is
present, then the current entry applies if and only if
the expression evaluates to true.
- The context node is the anydata instance containing The XPath expression is evaluated once for each
the corresponding 'mount-point' statement. instance of the data node containing the mount
point for which the 'when' leaf is defined.
- The accessible tree contains only data belonging to The XPath expression is evaluated using the rules
the parent schema, i.e., all instances of anydata specified in sec. 6.4 of RFC 7950, with these
nodes containing the mount points are considered modifications:
empty.
- The set of namespace declarations is the set of all - The context node is the data node instance
prefix/namespace pairs defined in the containing the corresponding 'mount-point'
/schema-mounts/namespace list. Names without a statement.
namespace prefix belong to the same namespace as the
context node.";
}
}
} - The accessible tree contains only data belonging to
} the parent schema, i.e., all instances of data
} nodes containing the mount points are considered
empty.
/* - The set of namespace declarations is the set of all
* State data nodes prefix/namespace pairs defined in the
*/ /schema-mounts/namespace list. Names without a
namespace prefix belong to the same namespace as the
context node.";
}
leaf-list parent-reference {
type yang:yang-identifier;
must "not(/schema-mounts/schema[name=current()/../name]/"
+ "module[name=current() and conformance-type="
+ "'implement'])" {
error-message "Parent references cannot be used for a "
+ "module implemented in the mounted schema.";
description
"Modules that are used for parent references MUST NOT
be implemented in the mounted schema.";
}
description
"Entries of this leaf-list are names of YANG modules.
All these modules MUST be implemented in the parent
schema.
container schema-mounts { Within the mounted schema and the corresponding data
config "false"; tree, conceptual evaluation of absolute leafref paths
description and instance identifiers is modified in the following
"Contains information about the structure of the overall data way:
model implemented in the server.";
list namespace {
key "prefix";
description
"This list provides a mapping of namespace prefixes that are
used in XPath expressions of 'when' leafs to the
corresponding namespace URI references.";
leaf prefix {
type yang:yang-identifier;
description
"Namespace prefix.";
}
leaf ns-uri {
type inet:uri;
description
"Namespace URI reference.";
}
}
uses mount-point-list;
list schema {
key "name";
description
"Each entry specifies a schema that can be mounted at a mount
point. The schema information consists of two parts:
- an instance of YANG library that defines YANG modules used If the leftmost node-identifier in an absolute leafref
in the schema, path or instance identifier belongs to a module whose
name is listed in 'parent-reference', then the root
of the accessible data tree coincides with the root of
the parent data tree.";
}
}
}
}
}
- mount-point list with content identical to the top-level /*
mount-point list (this makes the schema structure * State data nodes
recursive)."; */
leaf name {
type string; container schema-mounts {
description config false;
"Arbitrary name of the entry."; description
} "Contains information about the structure of the overall
uses yanglib:module-list; mounted data model implemented in the server.";
uses mount-point-list; list namespace {
} key "prefix";
} description
} "This list provides a mapping of namespace prefixes that are
used in XPath expressions of 'when' leafs to the
corresponding namespace URI references.";
leaf prefix {
type yang:yang-identifier;
description
"Namespace prefix.";
}
leaf ns-uri {
type inet:uri;
description
"Namespace URI reference.";
}
}
uses mount-point-list;
list schema {
key "name";
description
"Each entry specifies a schema that can be mounted at a mount
point. The schema information consists of two parts:
- an instance of YANG library that defines YANG modules used
in the schema,
- mount-point list with content identical to the top-level
mount-point list (this makes the schema structure
recursive).";
leaf name {
type string;
description
"Arbitrary name of the schema entry.";
}
uses yanglib:module-list;
uses mount-point-list;
}
}
}
<CODE ENDS> <CODE ENDS>
6. IANA Considerations 9. IANA Considerations
This document registers a URI in the IETF XML registry [RFC3688]. This document registers a URI in the IETF XML registry [RFC3688].
Following the format in RFC 3688, the following registration is Following the format in RFC 3688, the following registration is
requested to be made. requested to be made.
URI: urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount URI: urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount
Registrant Contact: The IESG. Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace. XML: N/A, the requested URI is an XML namespace.
This document registers a YANG module in the YANG Module Names This document registers a YANG module in the YANG Module Names
registry [RFC6020]. registry [RFC6020].
name: ietf-yang-schema-mount name: ietf-yang-schema-mount
namespace: urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount namespace: urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount
prefix: yangmnt prefix: yangmnt
reference: RFC XXXX reference: RFC XXXX
7. Security Considerations 10. Security Considerations
TBD TBD
8. Contributors 11. Contributors
The idea of having some way to combine schemas from different YANG The idea of having some way to combine schemas from different YANG
modules into one has been proposed independently by several groups of modules into one has been proposed independently by several groups of
people: Alexander Clemm, Jan Medved, and Eric Voit people: Alexander Clemm, Jan Medved, and Eric Voit
([I-D.clemm-netmod-mount]); Ladislav Lhotka ([I-D.clemm-netmod-mount]); and Lou Berger and Christian Hopps:
([I-D.lhotka-netmod-ysdl]); and Lou Berger and Christian Hopps.
9. References o Lou Berger, LabN Consulting, L.L.C., <lberger@labn.net>
9.1. Normative References o Alexander Clemm, Huawei, <alexander.clemm@huawei.com>
o Christian Hopps, Deutsche Telekom, <chopps@chopps.org>
o Jan Medved, Cisco, <jmedved@cisco.com>
o Eric Voit, Cisco, <evoit@cisco.com>
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<http://www.rfc-editor.org/info/rfc3688>. <http://www.rfc-editor.org/info/rfc3688>.
skipping to change at page 13, line 26 skipping to change at page 22, line 31
<http://www.rfc-editor.org/info/rfc6991>. <http://www.rfc-editor.org/info/rfc6991>.
[RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module [RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module
Library", RFC 7895, DOI 10.17487/RFC7895, June 2016, Library", RFC 7895, DOI 10.17487/RFC7895, June 2016,
<http://www.rfc-editor.org/info/rfc7895>. <http://www.rfc-editor.org/info/rfc7895>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<http://www.rfc-editor.org/info/rfc7950>. <http://www.rfc-editor.org/info/rfc7950>.
9.2. Informative References 12.2. Informative References
[I-D.clemm-netmod-mount] [I-D.clemm-netmod-mount]
Clemm, A., Medved, J., and E. Voit, "Mounting YANG-Defined Clemm, A., Medved, J., and E. Voit, "Mounting YANG-Defined
Information from Remote Datastores", draft-clemm-netmod- Information from Remote Datastores", draft-clemm-netmod-
mount-05 (work in progress), September 2016. mount-05 (work in progress), September 2016.
[I-D.lhotka-netmod-ysdl] [I-D.ietf-isis-yang-isis-cfg]
Lhotka, L., "YANG Schema Dispatching Language", draft- Litkowski, S., Yeung, D., Lindem, A., Zhang, Z., and L.
lhotka-netmod-ysdl-00 (work in progress), November 2015. Lhotka, "YANG Data Model for IS-IS protocol", draft-ietf-
isis-yang-isis-cfg-15 (work in progress), February 2017.
[I-D.rtgyangdt-rtgwg-device-model] [I-D.ietf-rtgwg-device-model]
Lindem, A., Berger, L., Bogdanovic, D., and C. Hopps, Lindem, A., Berger, L., Bogdanovic, D., and C. Hopps,
"Network Device YANG Organizational Models", draft- "Network Device YANG Organizational Models", draft-ietf-
rtgyangdt-rtgwg-device-model-05 (work in progress), August rtgwg-device-model-01 (work in progress), October 2016.
2016.
[I-D.ietf-rtgwg-lne-model]
Berger, L., Hopps, C., Lindem, A., and D. Bogdanovic,
"YANG Logical Network Elements", draft-ietf-rtgwg-lne-
model-01 (work in progress), October 2016.
[I-D.ietf-rtgwg-ni-model]
Berger, L., Hopps, C., Lindem, A., and D. Bogdanovic,
"YANG Network Instances", draft-ietf-rtgwg-ni-model-01
(work in progress), October 2016.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<http://www.rfc-editor.org/info/rfc6241>. <http://www.rfc-editor.org/info/rfc6241>.
[RFC7223] Bjorklund, M., "A YANG Data Model for Interface [RFC7223] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, Management", RFC 7223, DOI 10.17487/RFC7223, May 2014,
<http://www.rfc-editor.org/info/rfc7223>. <http://www.rfc-editor.org/info/rfc7223>.
[RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", Appendix A. Example: Device Model with LNEs and NIs
RFC 7277, DOI 10.17487/RFC7277, June 2014,
<http://www.rfc-editor.org/info/rfc7277>.
[RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for This non-normative example demonstrates an implementation of the
System Management", RFC 7317, DOI 10.17487/RFC7317, August device model as specified in Section 2 of
2014, <http://www.rfc-editor.org/info/rfc7317>. [I-D.ietf-rtgwg-device-model], using both logical network elements
(LNE) and network instances (NI).
Appendix A. Example: Logical Devices A.1. Physical Device
Logical devices within a device typically use the same set of data The data model for the physical device may be described by this YANG
models in each instance. This can be modelled with a mount point: library content:
module example-logical-devices { "ietf-yang-library:modules-state": {
yang-version 1.1; "module-set-id": "14e2ab5dc325f6d86f743e8d3ade233f1a61a899",
namespace "urn:example:logical-devices"; "module": [
prefix exld; {
"name": "iana-if-type",
"revision": "2014-05-08",
"namespace": "urn:ietf:params:xml:ns:yang:iana-if-type",
"conformance-type": "implement"
},
{
"name": "ietf-inet-types",
"revision": "2013-07-15",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-inet-types",
"conformance-type": "import"
},
{
"name": "ietf-interfaces",
"revision": "2014-05-08",
"feature": [
"arbitrary-names",
"pre-provisioning"
],
"namespace": "urn:ietf:params:xml:ns:yang:ietf-interfaces",
"conformance-type": "implement"
},
{
"name": "ietf-ip",
"revision": "2014-06-16",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-ip",
"conformance-type": "implement"
},
{
"name": "ietf-logical-network-element",
"revision": "2016-10-21",
"feature": [
"bind-lne-name"
],
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-logical-network-element",
"conformance-type": "implement"
},
{
"name": "ietf-yang-library",
"revision": "2016-06-21",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-library",
"conformance-type": "implement"
},
{
"name": "ietf-yang-schema-mount",
"revision": "2017-03-06",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount",
"conformance-type": "implement"
},
{
"name": "ietf-yang-types",
"revision": "2013-07-15",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-types",
"conformance-type": "import"
}
]
}
import ietf-yang-schema-mount { A.2. Logical Network Elements
prefix yangmnt;
}
container logical-devices { Each LNE can have a specific data model that is determined at run
list logical-device { time, so it is appropriate to mount it using the "inline" method,
key name; hence the following "schema-mounts" data:
leaf name {
type string;
}
anydata root { "ietf-yang-schema-mount:schema-mounts": {
yangmnt:mount-point logical-device; "mount-point": [
} {
"module": "ietf-logical-network-element",
"name": "root",
"inline": [null]
} }
]
}
An administrator of the host device has to configure an entry for
each LNE instance, for example,
{
"ietf-interfaces:interfaces": {
"interface": [
{
"name": "eth0",
"type": "iana-if-type:ethernetCsmacd",
"enabled": true,
"ietf-logical-network-element:bind-lne-name": "eth0"
}
]
},
"ietf-logical-network-element:logical-network-elements": {
"logical-network-element": [
{
"name": "lne-1",
"managed": true,
"description": "LNE with NIs",
"root": {
...
}
},
...
]
} }
} }
A server with two logical devices that both implement and then also place necessary state data as the contents of the
"ietf-interfaces" [RFC7223], "ietf-ip" [RFC7277], and "ietf-system" "root" instance, which should include at least
[RFC7317] YANG modules might populate the "schema-mounts" container
with:
<schema-mounts o YANG library data specifying the LNE's data model, for example:
xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount">
<mount-point>
<module>example-logical-devices</module>
<name>logical-device</name>
<use-schema>
<name>logical-device</name>
</use-schema>
</mount-point>
<schema>
<name>logical-device</name>
<module>
<name>ietf-interface</name>
<revision>2014-05-08</revision>
<namespace>
urn:ietf:params:xml:ns:yang:ietf-interfaces
</namespace>
<conformance-type>implement</conformance-type>
</module>
<module>
<name>ietf-ip</name>
<revision>2014-06-16</revision>
<namespace>
urn:ietf:params:xml:ns:yang:ietf-ip
</namespace>
<conformance-type>implement</conformance-type>
</module>
<module>
<name>ietf-system</name>
<revision>2014-08-06</revision>
<namespace>
urn:ietf:params:xml:ns:yang:ietf-system
</namespace>
<conformance-type>implement</conformance-type>
</module>
<module>
<name>ietf-yang-types</name>
<revision>2013-07-15</revision>
<namespace>
urn:ietf:params:xml:ns:yang:ietf-yang-types
</namespace>
<conformance-type>import</conformance-type>
</module>
</schema>
</schema-mounts>
and the "logical-devices" container might have: "ietf-yang-library:modules-state": {
"module-set-id": "9358e11874068c8be06562089e94a89e0a392019",
"module": [
{
"name": "iana-if-type",
"revision": "2014-05-08",
"namespace": "urn:ietf:params:xml:ns:yang:iana-if-type",
"conformance-type": "implement"
},
{
"name": "ietf-inet-types",
"revision": "2013-07-15",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-inet-types",
"conformance-type": "import"
},
{
"name": "ietf-interfaces",
"revision": "2014-05-08",
"feature": [
"arbitrary-names",
"pre-provisioning"
],
"namespace": "urn:ietf:params:xml:ns:yang:ietf-interfaces",
"conformance-type": "implement"
},
{
"name": "ietf-ip",
"revision": "2014-06-16",
"feature": [
"ipv6-privacy-autoconf"
],
"namespace": "urn:ietf:params:xml:ns:yang:ietf-ip",
"conformance-type": "implement"
},
{
"name": "ietf-network-instance",
"revision": "2016-10-27",
"feature": [
"bind-network-instance-name"
],
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-network-instance",
"conformance-type": "implement"
},
{
"name": "ietf-yang-library",
"revision": "2016-06-21",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-library",
"conformance-type": "implement"
},
{
"name": "ietf-yang-schema-mount",
"revision": "2017-03-06",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount",
"conformance-type": "implement"
},
{
"name": "ietf-yang-types",
"revision": "2013-07-15",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-types",
"conformance-type": "import"
}
]
}
<logical-devices xmlns="urn:example:logical-devices"> o state data for interfaces assigned to the LNE instance (that
<logical-device> effectively become system-controlled interfaces for the LNE), for
<name>vrtrA</name> example:
<root>
<interfaces
xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
<interface>
<name>eth0</name>
<ipv6 xmlns="urn:ietf:params:xml:ns:yang:ietf-ip">
<enabled>true</enabled>
...
</ipv6>
...
</interface>
</interfaces>
<system xmlns="urn:ietf:params:xml:ns:yang:ietf-system">
...
</system>
</root>
</logical-device>
<logical-device>
<name>vrtrB</name>
<root>
<interfaces
xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
<interface>
<name>eth0</name>
<ipv6 xmlns="urn:ietf:params:xml:ns:yang:ietf-ip">
<enabled>true</enabled>
...
</ipv6>
...
</interface>
</interfaces>
<system xmlns="urn:ietf:params:xml:ns:yang:ietf-system">
...
</system>
</root>
</logical-device>
</logical-devices>
Appendix B. Example: Network Manager with Fixed Device Models "ietf-interfaces:interfaces-state": {
"interface": [
{
"name": "eth0",
"type": "iana-if-type:ethernetCsmacd",
"oper-status": "up",
"statistics": {
"discontinuity-time": "2016-12-16T17:11:27+02:00"
},
"ietf-ip:ipv6": {
"address": [
{
"ip": "fe80::42a8:f0ff:fea8:24fe",
"origin": "link-layer",
"prefix-length": 64
}
]
}
},
...
]
}
This example shows how a Network Manager application can use schema A.3. Network Instances
mount to define a data model for a network consisting of devices
whose data models are known a priori and fixed.
Assume for simplicity that only two device types are used (switch and Assuming that network instances share the same data model, it can be
router), and they are identified by identities defined in the module mounted using the "use-schema" method as follows:
"example-device-types":
module example-device-types { "ietf-yang-schema-mount:schema-mounts": {
namespace "http://example.org/device-types"; "mount-point": [
prefix edt; {
identity device-type; "module": "ietf-network-instance",
identity switch-device { "name": "root",
base device-type; "parent-reference": ["ietf-interfaces"],
} "use-schema": [
identity router-device { {
base device-type; "name": "ni-schema"
}
]
}
],
"schema": [
{
"name": "ni-schema",
"module": [
{
"name": "ietf-ipv4-unicast-routing",
"revision": "2016-11-04",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing",
"conformance-type": "implement"
},
{
"name": "ietf-ipv6-unicast-routing",
"revision": "2016-11-04",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing",
"conformance-type": "implement"
},
{
"name": "ietf-routing",
"revision": "2016-11-04",
"feature": [
"multiple-ribs",
"router-id"
],
"namespace": "urn:ietf:params:xml:ns:yang:ietf-routing",
"conformance-type": "implement"
}
]
}
]
} }
}
Schema mount is used to mount the device data models conditionally, Note also that the "ietf-interfaces" module appears in the
depending on the "type" leaf that is a sibling of the mount point. "parent-reference" leaf-list for the mounted NI schema. This means
This approach is similar to "ietf-interfaces" [RFC7223] where the that references to LNE interfaces, such as "outgoing-interface" in
same effect is achieved via conditional augments. static routes, are valid despite the fact that "ietf-interfaces"
isn't part of the NI schema.
The top-level module may look as follows: A.4. Invoking an RPC Operation
module example-network-manager-fixed { Assume that the mounted NI data model also implements the "ietf-isis"
yang-version 1.1; module [I-D.ietf-isis-yang-isis-cfg]. An RPC operation defined in
namespace "urn:example:network-manager-fixed"; this module, such as "clear-adjacency", can be invoked by a client
prefix exf; session of a LNE's RESTCONF server as an action tied to a the mount
point of a particular network instance using a request URI like this
(all on one line):
import ietf-inet-types { POST /restconf/data/ietf-network-instance:network-instances/
prefix inet; network-instance=rtrA/root/ietf-isis:clear-adjacency HTTP/1.1
}
import ietf-yang-schema-mount {
prefix yangmnt;
}
import example-device-types {
prefix edt;
}
container managed-devices { Appendix B. Open Issues
description
"The managed devices and device communication settings.";
list device { B.1. Referencing Mount Points Using Schema Node Identifiers
key name;
leaf name { Each entry in the "mount-point" list is currently identified by two
type string; keys, namely YANG module name and mount point name. An alternative
} is to use a schema node identifier of the mount point as a single
leaf type { key.
type identityref {
base edt:device-type; For example, the "schema-mounts" data for NI (Appendix A.3) would be
} changed as follows (the "schema" list doesn't change):
}
container transport { "ietf-yang-schema-mount:schema-mounts": {
choice protocol { "namespace": [
mandatory true; {
container netconf { "prefix": "ni",
leaf address { "ns-uri": "urn:ietf:params:xml:ns:yang:ietf-network-instance"
type inet:ip-address; }
mandatory true; ]
} "mount-point": [
container authentication { {
// ... "target": "/ni:network-instances/ni:network-instance/ni:root",
} "parent-reference": ["ietf-interfaces"],
} "use-schema": [
container restconf { {
leaf address { "name": "ni-schema"
type inet:ip-address;
mandatory true;
}
// ...
}
} }
} ]
anydata root {
yangmnt:mount-point managed-device;
}
} }
} ],
"schema": [
...
]
} }
The "schema-mounts" container may have the following data: This change would have several advantages:
<data-model o the schema mount mechanism becomes even closer to augments, which
xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount"> may simplify implementation
<namespace>
<prefix>edt</prefix>
<ns-uri>http://example.org/device-types</ns-uri>
</namespace>
<mount-point>
<module>example-network-manager</module>
<name>managed-device</name>
<use-schema>
<name>switch</name>
<when>derived-from-or-self(../type, 'edt:switch-device')</when>
</use-schema>
<use-schema>
<name>router</name>
<when>derived-from-or-self(../type, 'edt:router-device')</when>
</use-schema>
</mount-point>
<schema>
<name>switch</name>
<module>
...
</module>
...
</schema>
<schema>
<name>router</name>
<module>
...
</module>
...
</schema>
</data-model>
The "devices" list may contain any number of instances of either o if a mount point appears inside a grouping, then a different
type. mounted schema can be used for each use of the grouping.
Appendix C. Example: Network Manager with Arbitrary Device Models o it optionally allows for use of mount without use of the mount-
point extension.
This example shows how a Network Manager application can use schema B.2. Defining the "mount-point" Extension in a Separate Module
mount to define a data model for a network consisting of devices
whose data models are not known in advance -- each device is expected
to provide its data model dynamically.
Schema mount is used to mount the data models that each device The "inline" method of schema mounting can be further simplified by
supports, and these data models can be discovered by inspecting state defining the "inline" case as the default. That is, if a mount point
data under the corresponding mount point. Every such device must is defined through the "mount-point" extension but is not present in
therefore implement "ietf-yang-library" and optionally the "mount-point" list, the "inline" schema mount is assumed.
"ietf-schema-mount".
module example-network-manager-arbitrary { Consequently, a data model that uses only the "inline" method could
yang-version 1.1; omit the "schema-mounts" data entirely, but it still needs to use the
namespace "urn:example:network-manager-arbitrary"; "mount-point" extension. In order to enable this, the definition of
prefix exa; the "mount-point" extension has to be moved to a YANG module of its
own.
import ietf-inet-types { A variant of this approach is to completely separate the "inline" and
prefix inet; "use-schema" cases by dedicating the "mount-point" extension for use
} with the "inline" method only (with no "schema-mounts" data), and
import ietf-yang-schema-mount { using schema node identifiers as described in Appendix B.1 for the
prefix yangmnt; "use-schema" case.
}
container managed-devices { B.3. Parent References
description
"The managed devices and device communication settings.";
list device { As explained in Section 4, references to the parent schema can only
key name; be used in absolute leafref paths and instance identifiers. However,
leaf name { it is conceivable that they may be useful in other XPath expressions,
type string; e.g. in "must" statements. The authors believe it is impossible to
} allow for parent references in general XPath expressions because, for
container transport { example, in a location path "//foo:bar" it would be unclear whether
choice protocol { the lookup has to be started in the mounted or parent schema.
mandatory true;
container netconf {
leaf address {
type inet:ip-address;
mandatory true;
}
container authentication {
// ...
}
}
container restconf {
leaf address {
type inet:ip-address;
mandatory true;
}
// ...
}
}
}
anydata root {
yangmnt:mount-point managed-device;
}
}
}
}
The "schema-mounts" container may have the following data:
<data-model Should parent references in general XPath be needed, it would be
xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount"> necessary to indicate it explicitly. One way to achieve this is to
<mount-point> defining a new XPath function, e.g., parent-root(), that returns the
<module>example-network-manager</module> root of the parent data tree.
<name>managed-device</name>
<inline/>
</mount-point>
</data-model>
The "devices" container might have: B.4. RPC Operations and Notifications in Mounted Modules
<devices xmlns="urn:example:network-manager"> Turning RPC operations defined in mounted modules into actions tied
<device> to the corresponding mount point (see Section 5, and similarly for
<name>rtrA</name> notifications) is not possible if the path to the mount point in the
<transport> parent schema contains a keyless list (Section 7.15 of [RFC7950]).
<netconf> The solutions for this corner case are possible:
<address>2001:db8::2</address>
<authentication>
...
</authentication>
...
</netconf>
</transport>
<root>
<modules-state
xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library">
<module>
<name>ietf-system</name>
...
</module>
</modules-state>
<system xmlns="urn:ietf:params:xml:ns:yang:ietf-system">
...
</system>
</root>
</device>
<device>
<name>rtrB</name>
<transport>
<restconf>
<address>2001:db8::3</address>
<authentication>
...
</authentication>
...
</restconf>
</transport> 1. any mount point MUST NOT have a keyless list among its ancestors
<root>
<modules-state
xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library">
<module>
<name>ietf-interfaces</name>
...
</module>
</modules-state>
<interfaces
xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
...
</interfaces>
</root>
</device>
</devices>
C.1. Invoking an RPC 2. any mounted module MUST NOT contain RPC operations and/or
notifications
A client that wants to invoke the "restart" operation [RFC7317] on 3. specifically for each mount point, at least one of the above
the managed device "rtrA" over NETCONF [RFC6241] can send: conditions MUST be satisfied.
<rpc message-id="101" 4. treat such actions and notifications as non-existing, i.e.,
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> ignore them.
<action xmlns="urn:ietf:params:xml:ns:yang:1">
<managed-devices xmlns="urn:example:network-manager">
<device>
<name>rtrA</name>
<root>
<system xmlns="urn:ietf:params:xml:ns:yang:ietf-system">
<restart/>
</system>
</root>
</device>
</managed-devices>
</action>
</rpc>
Appendix D. Open Issues The first two requirements seem rather restrictive. On the other
hand, the last one is difficult to guarantee - for example, things
can break after an augment within the mounted schema.
o Is the 'mount-point' extension really needed? Now that mount B.5. Tree Representation
points can only appear under anydata nodes, there seems to be
little need to otherwise restrict mount point locations. In the Need to decide how/if mount points are represented in trees.
'mount-point' list, schema node identifiers (as in 'augment'
statements) can be used instead of the (module, name) pair for B.6. Design-Time Mounts
identifying mount points. As a useful side effect, a grouping
containing mount points could be used any number of times in the The document currently doesn't provide explicit support for design-
same module. OTOH, by using this extension, the intention of the time mounts. Design-time mounts have been identified as possibly for
data modeller is clear, and it provides a formal machine readable multiple cases, and it may be worthwhile to identify a minimum or
instruction about where mounts are allowed to occur. complete set of modules that must be supported under a mount point.
This could be used in service modules that want to allow for
configuration of device-specific information. One option could be to
add an extension that specify that a certain module is required to be
mounted.
Also, if design-time mounts are supported, it could be possible to
represent both mounts points and their required modules in tree
representations and support for such would need to be defined.
Authors' Addresses Authors' Addresses
Martin Bjorklund Martin Bjorklund
Tail-f Systems Tail-f Systems
Email: mbj@tail-f.com Email: mbj@tail-f.com
Ladislav Lhotka Ladislav Lhotka
CZ.NIC CZ.NIC
Email: mbj@lhotka@nic.cz Email: lhotka@nic.cz
 End of changes. 124 change blocks. 
709 lines changed or deleted 1129 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/