draft-ietf-netmod-schema-mount-08.txt   draft-ietf-netmod-schema-mount-09.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: April 24, 2018 CZ.NIC Expires: September 21, 2018 CZ.NIC
October 21, 2017 March 20, 2018
YANG Schema Mount YANG Schema Mount
draft-ietf-netmod-schema-mount-08 draft-ietf-netmod-schema-mount-09
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 April 24, 2018. This Internet-Draft will expire on September 21, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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
2. Terminology and Notation . . . . . . . . . . . . . . . . . . 5 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 5
2.1. Glossary of New Terms . . . . . . . . . . . . . . . . . . 6 2.1. Glossary of New Terms . . . . . . . . . . . . . . . . . . 6
2.2. Namespace Prefixes . . . . . . . . . . . . . . . . . . . 6 2.2. Namespace Prefixes . . . . . . . . . . . . . . . . . . . 6
3. Schema Mount . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Schema Mount . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Mount Point Definition . . . . . . . . . . . . . . . . . 6 3.1. Mount Point Definition . . . . . . . . . . . . . . . . . 7
3.2. Specification of the Mounted Schema . . . . . . . . . . . 7 3.2. Specification of the Mounted Schema . . . . . . . . . . . 7
3.3. Multiple Levels of Schema Mount . . . . . . . . . . . . . 9 3.3. Multiple Levels of Schema Mount . . . . . . . . . . . . . 8
4. Referring to Data Nodes in the Parent Schema . . . . . . . . 9 4. Referring to Data Nodes in the Parent Schema . . . . . . . . 8
5. RPC operations and Notifications . . . . . . . . . . . . . . 10 5. RPC operations and Notifications . . . . . . . . . . . . . . 9
6. Implementation Notes . . . . . . . . . . . . . . . . . . . . 11 6. Network Management Datastore Architecture (NMDA)
7. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 11 Considerations . . . . . . . . . . . . . . . . . . . . . . . 10
8. Schema Mount YANG Module . . . . . . . . . . . . . . . . . . 13 7. Implementation Notes . . . . . . . . . . . . . . . . . . . . 10
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 8. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 10
10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 9. Schema Mount YANG Module . . . . . . . . . . . . . . . . . . 11
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 11. Security Considerations . . . . . . . . . . . . . . . . . . . 16
12.1. Normative References . . . . . . . . . . . . . . . . . . 19 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17
12.2. Informative References . . . . . . . . . . . . . . . . . 20 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
Appendix A. Example: Device Model with LNEs and NIs . . . . . . 21 13.1. Normative References . . . . . . . . . . . . . . . . . . 17
A.1. Physical Device . . . . . . . . . . . . . . . . . . . . . 21 13.2. Informative References . . . . . . . . . . . . . . . . . 18
A.2. Logical Network Elements . . . . . . . . . . . . . . . . 22 Appendix A. Example: Device Model with LNEs and NIs . . . . . . 19
A.1. Physical Device . . . . . . . . . . . . . . . . . . . . . 19
A.2. Logical Network Elements . . . . . . . . . . . . . . . . 21
A.3. Network Instances . . . . . . . . . . . . . . . . . . . . 25 A.3. Network Instances . . . . . . . . . . . . . . . . . . . . 25
A.4. Invoking an RPC Operation . . . . . . . . . . . . . . . . 27 A.4. Invoking an RPC Operation . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
Modularity and extensibility were among the leading design principles Modularity and extensibility were among the leading design principles
of the YANG data modeling language. As a result, the same YANG of the YANG data modeling language. As a result, the same YANG
module can be combined with various sets of other modules and thus 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 form a data model that is tailored to meet the requirements of a
specific use case. Server implementors are only required to specify specific use case. Server implementors are only required to specify
all YANG modules comprising the data model (together with their all YANG modules comprising the data model (together with their
revisions and other optional choices) in the YANG library data revisions and other optional choices) in the YANG library data
([RFC7895], and Section 5.6.4 of [RFC7950]) implemented by the ([RFC7895], [I-D.ietf-netconf-rfc7895bis] and Section 5.6.4 of
server. Such YANG modules appear in the data model "side by side", [RFC7950]) implemented by the server. Such YANG modules appear in
i.e., top-level data nodes of each module - if there are any - are the data model "side by side", i.e., top-level data nodes of each
also top-level nodes of the overall data model. module - if there are any - are also top-level nodes of the overall
data model.
Furthermore, YANG has two mechanisms for contributing a schema Furthermore, YANG has two mechanisms for contributing a schema
hierarchy defined elsewhere to the contents of an internal node of hierarchy defined elsewhere to the contents of an internal node of
the schema tree; these mechanisms are realized through the following the schema tree; these mechanisms are realized through the following
YANG statements: YANG statements:
o The "uses" statement explicitly incorporates the contents of a o The "uses" statement explicitly incorporates the contents of a
grouping defined in the same or another module. See Section 4.2.6 grouping defined in the same or another module. See Section 4.2.6
of [RFC7950] for more details. of [RFC7950] for more details.
skipping to change at page 3, line 20 skipping to change at page 3, line 22
defined in the same or another module. See Section 4.2.8 of defined in the same or another module. See Section 4.2.8 of
[RFC7950] for more details. [RFC7950] for more details.
With both mechanisms, the source or target YANG module explicitly With both mechanisms, the source or target YANG module explicitly
defines the exact location in the schema tree where the new nodes are defines the exact location in the schema tree where the new nodes are
placed. placed.
In some cases these mechanisms are not sufficient; it is often In some cases these mechanisms are not sufficient; it is often
necessary that an existing module (or a set of modules) is added to 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 the data model starting at a non-root location. For example, YANG
modules such as "ietf-interfaces" [RFC7223] are often defined so as modules such as "ietf-interfaces" [RFC8343] are often defined so as
to be used in a data model of a physical device. Now suppose we want to be used in a data model of a physical device. Now suppose we want
to model a device that supports multiple logical devices to model a device that supports multiple logical devices
[I-D.ietf-rtgwg-lne-model], each of which has its own instantiation [I-D.ietf-rtgwg-lne-model], each of which has its own instantiation
of "ietf-interfaces", and possibly other modules, but, at the same 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 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: master device. Hence, we would like to have a schema like this:
+--rw interfaces +--rw interfaces
| +--rw interface* [name] | +--rw interface* [name]
| ... | ...
skipping to change at page 4, line 40 skipping to change at page 4, line 43
In principle, the mounted schema can be specified at three different In principle, the mounted schema can be specified at three different
phases of the data model life cycle: phases of the data model life cycle:
1. Design-time: the mounted schema is defined along with the mount 1. Design-time: the mounted schema is defined along with the mount
point in the parent YANG module. In this case, the mounted point in the parent YANG module. In this case, the mounted
schema has to be the same for every implementation of the parent schema has to be the same for every implementation of the parent
module. module.
2. Implementation-time: the mounted schema is defined by a server 2. Implementation-time: the mounted schema is defined by a server
implementor and is as stable as YANG library information, i.e., implementor and is as stable as YANG library information of the
it may change after an upgrade of server software but not after server.
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 3. Run-time: the mounted schema is defined by instance data that is
part of the mounted data model. If there are multiple instances part of the mounted data model. If there are multiple instances
of the same mount point (e.g., in multiple entries of a list), of the same mount point (e.g., in multiple entries of a list),
the mounted data model may be different for each instance. the mounted data model may be different for each instance.
The schema mount mechanism defined in this document provides support The schema mount mechanism defined in this document provides support
only for the latter two cases. Design-time mounts are outside the only for the latter two cases. Design-time mounts are outside the
scope of this document, and could be possibly dealt with in a future scope of this document, and could be possibly dealt with in a future
revision of the YANG data modeling language. revision of the YANG data modeling language.
skipping to change at page 5, line 25 skipping to change at page 5, line 25
specifications may extend this model by defining additional specifications may extend this model by defining additional
mechanisms such as mounting sub-hierarchies of a module. mechanisms such as mounting sub-hierarchies of a module.
2. Terminology and Notation 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].
The following terms are defined in [RFC6241] and are not redefined The following terms are defined in [RFC7950] and are not redefined
here: here:
o client o action
o notification o container
o server o list
The following terms are defined in [RFC7950] and are not redefined o RPC operation
The following terms are defined in [RFC8342] and are not redefined
here: here:
o action o client
o container o notification
o list o operational state
o operation o server
The following terms are defined in [RFC7223] and are not redefined The following terms are defined in [RFC8343] and are not redefined
here: here:
o system-controlled interface o system-controlled interface
Tree diagrams used in this document follow the notation defined in Tree diagrams used in this document follow the notation defined in
[I-D.ietf-netmod-yang-tree-diagrams]. [RFC8340]
2.1. Glossary of New Terms 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 o mount point: container or list node whose definition contains the
"mount-point" extension statement. The argument of the "mount-point" extension statement. The argument of the
"mount-point" statement defines a label for the mount point. "mount-point" statement defines a label for the mount point.
o parent schema (of a particular mounted schema): the schema that o parent schema (of a particular mounted schema): the schema that
contains the mount point for the mounted schema. contains the mount point for the mounted schema.
o top-level schema: a schema according to [RFC7950] in which schema o top-level schema: a schema according to [RFC7950] in which schema
trees of each module (except augments) start at the root node. trees of each module (except augments) start at the root node.
2.2. Namespace Prefixes 2.2. Namespace Prefixes
In this document, names of data nodes, YANG extensions, actions and In this document, names of data nodes, YANG extensions, actions and
other data model objects are often used without a prefix, as long as other data model objects are often used without a prefix, as long as
it is clear from the context in which YANG module each name is it is clear from the context in which YANG module each name is
defined. Otherwise, names are prefixed using the standard prefix defined. Otherwise, names are prefixed using the standard prefix
associated with the corresponding YANG module, as shown in Table 1. associated with the corresponding YANG module, as shown in Table 1.
+---------+------------------------+-----------+ +---------+------------------------+--------------------------------+
| Prefix | YANG module | Reference | | Prefix | YANG module | Reference |
+---------+------------------------+-----------+ +---------+------------------------+--------------------------------+
| yangmnt | ietf-yang-schema-mount | Section 8 | | yangmnt | ietf-yang-schema-mount | Section 9 |
| inet | ietf-inet-types | [RFC6991] | | inet | ietf-inet-types | [RFC6991] |
| yang | ietf-yang-types | [RFC6991] | | yang | ietf-yang-types | [RFC6991] |
| yanglib | ietf-yang-library | [RFC7895] | | yanglib | ietf-yang-library | [RFC7895], |
+---------+------------------------+-----------+ | | | [I-D.ietf-netconf-rfc7895bis] |
+---------+------------------------+--------------------------------+
Table 1: Namespace Prefixes Table 1: Namespace Prefixes
3. Schema Mount 3. Schema Mount
The schema mount mechanism defined in this document provides a new The schema mount mechanism defined in this document provides a new
extensibility mechanism for use with YANG 1.1. In contrast to the extensibility mechanism for use with YANG 1.1. In contrast to the
existing mechanisms described in Section 1, schema mount defines the existing mechanisms described in Section 1, schema mount defines the
relationship between the source and target YANG modules outside these relationship between the source and target YANG modules outside these
modules. The procedure consists of two separate steps that are modules. The procedure consists of two separate steps that are
skipping to change at page 7, line 28 skipping to change at page 7, line 33
including version 1, can be mounted under a mount point. including version 1, can be mounted under a mount point.
Note that the "mount-point" statement does not define a new data Note that the "mount-point" statement does not define a new data
node. node.
3.2. Specification of the Mounted Schema 3.2. Specification of the Mounted Schema
Mounted schemas for all mount points in the parent schema are Mounted schemas for all mount points in the parent schema are
determined from state data in the "yangmnt:schema-mounts" container. determined from state data in the "yangmnt:schema-mounts" container.
Data in this container is intended to be as stable as data in the Data in this container is intended to be as stable as data in the
top-level YANG library [RFC7895]. In particular, it SHOULD NOT top-level YANG library.
change during the same management session.
Generally, the modules that are mounted under a mount point have no Generally, the modules that are mounted under a mount point have no
relation to the modules in the parent schema; specifically, if a relation to the modules in the parent schema; specifically, if a
module is mounted it may or may not be present in the parent schema module is mounted it may or may not be present in the parent schema
and, if present, its data will generally have no relationship to the and, if present, its data will generally have no relationship to the
data of the parent. Exceptions are possible and such needs to be data of the parent. Exceptions are possible and such needs to be
defined in the model defining the exception, e.g., the interface defined in the model defining the exception, e.g., the interface
module in [I-D.ietf-rtgwg-lne-model]. module in [I-D.ietf-rtgwg-lne-model].
The "schema-mounts" container has the "mount-point" list as one of The "schema-mounts" container has the "mount-point" list as one of
skipping to change at page 8, line 17 skipping to change at page 8, line 21
The "config" property of mounted schema nodes is overridden and all The "config" property of mounted schema nodes is overridden and all
nodes in the mounted schema are read-only ("config false") if at nodes in the mounted schema are read-only ("config false") if at
least one of the following conditions is satisfied for a mount point: least one of the following conditions is satisfied for a mount point:
o the mount point is itself defined as "config false" o the mount point is itself defined as "config false"
o the "config" leaf in the corresponding entry of the "mount-point" o the "config" leaf in the corresponding entry of the "mount-point"
list is set to "false". list is set to "false".
An entry of the "mount-point" list can specify the mounted schema in An entry of the "mount-point" list can specify the mounted schema in
two different ways: two different ways, "inline" or "shared-schema".
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, the mounted schema is determined at run time: 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. In this case,
the mounted schema is specified as implementation-time data that can
be retrieved together with YANG library data for the parent schema,
i.e., even before any instances of the mount point exist. However,
the mounted schema has to be the same for all instances of the mount
point. Note, that in this case a mount point may include a mounted
YANG library module and the data contained in the mounted module MUST
exactly match the data contained in the "schema" entries associated
with the mount point.
Each entry of the "schema" list contains:
o a list in the YANG library format specifying all YANG modules (and
revisions etc.) that are implemented or imported in the mounted
schema. Note that this includes modules that solely augment other
listed modules;
o (optionally) a new "mount-point" list that applies to mount points The mounted schema is determined at run time: every instance of the
defined within the mounted schema. mount point that exists in the operational state MUST contain a copy
of YANG library data 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. In
the "inline" case, instances of the same mount point MAY use
different mounted schemas, whereas in the "shared-schema" case, all
instances MUST use the same mounted schema.
3.3. Multiple Levels of Schema Mount 3.3. Multiple Levels of Schema Mount
YANG modules in a mounted schema MAY again contain mount points under YANG modules in a mounted schema MAY again contain mount points under
which subschemas can be mounted. Consequently, it is possible to which subschemas can be mounted. Consequently, it is possible to
construct data models with an arbitrary number of schema levels. A construct data models with an arbitrary number of schema levels. A
subschema for a mount point contained in a mounted module can be subschema for a mount point contained in a mounted module can be
specified in one of the following ways: specified by implementing "ietf-yang-library" and
"ietf-yang-schema-mount" modules in the mounted schema, and
o by implementing "ietf-yang-library" and "ietf-yang-schema-mount" specifying the subschemas exactly as it is done in the top-level
modules in the mounted schema, and specifying the subschemas schema.
exactly as it is done in the top-level schema
o by using the "mount-point" list inside the corresponding "schema"
entry.
The former method is applicable to both "inline" and "use-schema"
cases whereas the latter requires the "use-schema" case. On the
other hand, the latter method allows for a compact representation of
a multi-level schema the does not rely on the presence of any
instance data.
4. Referring to Data Nodes in the Parent Schema 4. Referring to Data Nodes in the Parent Schema
A fundamental design principle of schema mount is that the mounted A fundamental design principle of schema mount is that the mounted
data model works exactly as a top-level data model, i.e., it is data model works exactly as a top-level data model, i.e., it is
confined to the "mount jail". This means that all paths in the confined to the "mount jail". This means that all paths in the
mounted data model (in leafrefs, instance-identifiers, XPath mounted data model (in leafrefs, instance-identifiers, XPath
expressions, and target nodes of augments) are interpreted with the expressions, and target nodes of augments) are interpreted with the
mount point as the root node. YANG modules of the mounted schema as mount point as the root node. YANG modules of the mounted schema as
well as corresponding instance data thus cannot refer to schema nodes well as corresponding instance data thus cannot refer to schema nodes
skipping to change at page 10, line 22 skipping to change at page 9, line 29
+--rw routing +--rw routing
... ...
Here, the "root" node is the mount point for the NI schema. Routing Here, the "root" node is the mount point for the NI schema. Routing
configuration inside an NI often needs to refer to interfaces (at configuration inside an NI often needs to refer to interfaces (at
least those that are assigned to the NI), which is impossible unless 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 such a reference can point to a node in the parent schema (interface
name). name).
Therefore, schema mount also allows for such references. For every Therefore, schema mount also allows for such references. For every
schema mounted using the "use-schema" method, it is possible to mount point in the "shared-schema" case, it is possible to specify a
specify a leaf-list named "parent-reference" that contains zero or leaf-list named "parent-reference" that contains zero or more XPath
more XPath 1.0 expressions. Each expression is evaluated with the 1.0 expressions. Each expression is evaluated with the node in the
node in the parent data tree where the mount point is defined as the parent data tree where the mount point is defined as the context
context node. The result of this evaluation MUST be a nodeset (see node. The result of this evaluation MUST be a nodeset (see the
the description of the "parent-reference" node for a complete description of the "parent-reference" node for a complete definition
definition of the evaluation context). For the purposes of of the evaluation context). For the purposes of evaluating XPath
evaluating XPath expressions within the mounted data tree, the union expressions within the mounted data tree, the union of all such
of all such nodesets is added to the accessible data tree. nodesets is added to the accessible data tree.
It is worth emphasizing that
o The nodes specified in "parent-reference" leaf-list are available
in the mounted schema only for XPath evaluations. In particular,
they cannot be accessed there via network management protocols
such as NETCONF [RFC6241] or RESTCONF [RFC8040].
o The mechanism of referencing nodes in the parent schema is not It is worth emphasizing that the nodes specified in
available for schemas mounted using the "inline" method. "parent-reference" leaf-list are available in the mounted schema only
for XPath evaluations. In particular, they cannot be accessed there
via network management protocols such as NETCONF [RFC6241] or
RESTCONF [RFC8040].
5. RPC operations and Notifications 5. RPC operations and Notifications
If a mounted YANG module defines an RPC operation, clients can invoke If a mounted YANG module defines an RPC operation, clients can invoke
this operation by representing it as an action defined for the this operation as if it were defined as an action for the
corresponding mount point, see Section 7.15 of ^RFC7950. An example corresponding mount point, see Section 7.15 of [RFC7950]. An example
of this is given in Appendix A.4. of this is given in Appendix A.4.
Similarly, if the server emits a notification defined at the top Similarly, if the server emits a notification defined at the top
level of any mounted module, it MUST be represented as if the level of any mounted module, it MUST be represented as if the
notification was connected to the mount point, see Section 7.16 of notification was connected to the mount point, see Section 7.16 of
[RFC7950]. [RFC7950].
Note, inline actions and notifications will not work when they are Note, inline actions and notifications will not work when they are
contained within a list node without a "key" statement (see section contained within a list node without a "key" statement (see section
7.15 and 7.16 of [RFC7950]). Therefore, to be useful, mount points 7.15 and 7.16 of [RFC7950]). Therefore, to be useful, mount points
which contain modules with RPCs, actions, and notifications SHOULD which contain modules with RPCs, actions, and notifications SHOULD
NOT have any ancestor node that is a list node without a "key" NOT have any ancestor node that is a list node without a "key"
statement. This requirement applies to the definition of modules statement. This requirement applies to the definition of modules
using the "mount-point" extension statement. using the "mount-point" extension statement.
6. Implementation Notes 6. Network Management Datastore Architecture (NMDA) Considerations
The schema mount solution presented in this document is designed to
work both with servers that implement the NMDA [RFC8342], and old
servers that don't implement the NMDA.
Note to RFC Editor: please update the date YYYY-MM-DD below with the
revision of the ietf-yang-library in the published version of draft-
ietf-netconf-rfc7895bis, and remove this note.
Specifically, a server that doesn't support the NMDA, MAY implement
revision 2016-06-21 of "ietf-yang-library" [RFC7950] under a mount
point. A server that supports the NMDA, MUST implement at least
revision YYYY-MM-DD of "ietf-yang-library"
[I-D.ietf-netconf-rfc7895bis] under the mount points.
7. Implementation Notes
Network management of devices that use a data model with schema mount Network management of devices that use a data model with schema mount
can be implemented in different ways. However, the following can be implemented in different ways. However, the following
implementations options are envisioned as typical: implementations options are envisioned as typical:
o shared management: instance data of both parent and mounted o shared management: instance data of both parent and mounted
schemas are accessible within the same management session. schemas are accessible within the same management session.
o split management: one (master) management session has access to o split management: one (master) management session has access to
instance data of both parent and mounted schemas but, in addition, instance data of both parent and mounted schemas but, in addition,
an extra session exists for every instance of the mount point, an extra session exists for every instance of the mount point,
having access only to the mounted data tree. having access only to the mounted data tree.
7. Data Model 8. 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 uri? inet:uri | +--ro uri? inet:uri
+--ro mount-point* [module label] +--ro mount-point* [module label]
| +--ro module yang:yang-identifier +--ro module yang:yang-identifier
| +--ro label yang:yang-identifier +--ro label yang:yang-identifier
| +--ro config? boolean +--ro config? boolean
| +--ro (schema-ref) +--ro (schema-ref)
| +--:(inline) +--:(inline)
| | +--ro inline? empty | +--ro inline!
| +--:(use-schema) +--:(shared-schema)
| +--ro use-schema* [name] +--ro shared-schema!
| +--ro name +--ro parent-reference* yang:xpath1.0
| | -> /schema-mounts/schema/name
| +--ro parent-reference* yang:xpath1.0
+--ro schema* [name]
+--ro name string
+--ro module* [name revision]
| +--ro name yang:yang-identifier
| +--ro revision union
| +--ro schema? inet:uri
| +--ro namespace inet:uri
| +--ro feature* yang:yang-identifier
| +--ro deviation* [name revision]
| | +--ro name yang:yang-identifier
| | +--ro revision union
| +--ro conformance-type enumeration
| +--ro submodule* [name revision]
| +--ro name yang:yang-identifier
| +--ro revision union
| +--ro schema? inet:uri
+--ro mount-point* [module label]
+--ro module yang:yang-identifier
+--ro label yang:yang-identifier
+--ro config? boolean
+--ro (schema-ref)
+--:(inline)
| +--ro inline? empty
+--:(use-schema)
+--ro use-schema* [name]
+--ro name
| -> /schema-mounts/schema/name
+--ro parent-reference* yang:xpath1.0
8. Schema Mount YANG Module 9. Schema Mount YANG Module
This module references [RFC6991] and [RFC7895]. This module references [RFC6991].
<CODE BEGINS> file "ietf-yang-schema-mount@2017-10-09.yang" <CODE BEGINS> file "ietf-yang-schema-mount@2017-10-09.yang"
module ietf-yang-schema-mount { module ietf-yang-schema-mount {
yang-version 1.1; yang-version 1.1;
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;
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
reference reference
"RFC 6991: Common YANG Data Types"; "RFC 6991: Common YANG Data Types";
} }
import ietf-yang-types { import ietf-yang-types {
prefix yang; prefix yang;
reference reference
"RFC 6991: Common YANG Data Types"; "RFC 6991: Common YANG Data Types";
} }
import ietf-yang-library {
prefix yanglib;
reference
"RFC 7895: YANG Module Library";
}
organization organization
"IETF NETMOD (NETCONF Data Modeling Language) Working Group"; "IETF NETMOD (NETCONF Data Modeling Language) Working Group";
contact contact
"WG Web: <https://tools.ietf.org/wg/netmod/> "WG Web: <https://tools.ietf.org/wg/netmod/>
WG List: <mailto:netmod@ietf.org> 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) 2017 IETF Trust and the persons identified as Copyright (c) 2018 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 2017-10-09 { revision 2018-03-20 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: YANG Schema Mount"; "RFC XXXX: YANG Schema Mount";
} }
/* /*
* Extensions * Extensions
*/ */
skipping to change at page 15, line 16 skipping to change at page 13, line 24
other data models may be attached. A server that implements a other data models may be attached. A server that implements a
module with a mount point populates the module with a mount point populates the
/schema-mounts/mount-point list with detailed information on /schema-mounts/mount-point list with detailed information on
which data models are mounted at each mount point. which data models are mounted at each mount point.
Note that the 'mount-point' statement does not define a new Note that the 'mount-point' statement does not define a new
data node."; data node.";
} }
/* /*
* Groupings * State data nodes
*/ */
grouping mount-point-list { container schema-mounts {
config false;
description description
"This grouping is used inside the 'schema-mounts' container and "Contains information about the structure of the overall
inside the 'schema' list."; mounted data 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 'parent-reference' leafs to the
corresponding namespace URI references.";
leaf prefix {
type yang:yang-identifier;
description
"Namespace prefix.";
}
leaf uri {
type inet:uri;
description
"Namespace URI reference.";
}
}
list mount-point { list mount-point {
key "module label"; key "module label";
description description
"Each entry of this list specifies a schema for a particular "Each entry of this list specifies a schema for a particular
mount point. mount point.
Each mount point MUST be defined using the 'mount-point' Each mount point MUST be defined using the 'mount-point'
extension in one of the modules listed in the corresponding extension in one of the modules listed in the server's
YANG library instance with conformance type 'implement'. The YANG library instance with conformance type 'implement'.";
corresponding YANG library instance is:
- standard YANG library state data as defined in RFC 7895,
if the 'mount-point' list is a child of 'schema-mounts',
- the contents of the sibling 'yanglib:modules-state'
container, if the 'mount-point' list is a child of
'schema'.";
leaf module { leaf module {
type yang:yang-identifier; type yang:yang-identifier;
description description
"Name of a module containing the mount point."; "Name of a module containing the mount point.";
} }
leaf label { leaf label {
type yang:yang-identifier; type yang:yang-identifier;
description description
"Label of the mount point defined using the 'mount-point' "Label of the mount point defined using the 'mount-point'
extension."; extension.";
skipping to change at page 16, line 14 skipping to change at page 14, line 32
default "true"; default "true";
description description
"If this leaf is set to 'false', then all data nodes in the "If this leaf is set to 'false', then all data nodes in the
mounted schema are read-only (config false), regardless of mounted schema are read-only (config false), regardless of
their 'config' property."; their 'config' property.";
} }
choice schema-ref { choice schema-ref {
mandatory true; mandatory true;
description description
"Alternatives for specifying the schema."; "Alternatives for specifying the schema.";
leaf inline { container inline {
type empty; presence
"A complete self-contained schema is mounted at the
mount point.";
description description
"This leaf indicates that the server has mounted "This node indicates that the server has mounted
'ietf-yang-library' and 'ietf-schema-mount' at the mount 'ietf-yang-library' at the mount point, and its
point, and their instantiation (i.e., state data instantiation provides the information about the mounted
containers 'yanglib:modules-state' and 'schema-mounts') schema.
provides the information about the mounted schema.";
Different instances of the mount point may have
different schemas mounted.";
} }
list use-schema { container shared-schema {
key "name"; presence
min-elements 1; "The mounted schema together with the 'parent-reference'
make up the schema for this mount point.";
description description
"Each entry of this list contains a reference to a schema "This node indicates that the server has mounted
defined in the /schema-mounts/schema list."; 'ietf-yang-library' at the mount point, and its
leaf name { instantiation provides the information about the mounted
type leafref { schema. When XPath expressions in the mounted schema
path "/schema-mounts/schema/name"; are evaluated, the 'parent-reference' leaf-list is taken
} into account.
description
"Name of the referenced schema."; Different instances of the mount point MUST have the
} same schema mounted.";
leaf-list parent-reference { leaf-list parent-reference {
type yang:xpath1.0; type yang:xpath1.0;
description description
"Entries of this leaf-list are XPath 1.0 expressions "Entries of this leaf-list are XPath 1.0 expressions
that are evaluated in the following context: that are evaluated in the following context:
- The context node is the node in the parent data tree - The context node is the node in the parent data tree
where the mount-point is defined. where the mount-point is defined.
- The accessible tree is the parent data tree - The accessible tree is the parent data tree
skipping to change at page 17, line 25 skipping to change at page 15, line 47
(possibly empty). For the purposes of evaluating XPath (possibly empty). For the purposes of evaluating XPath
expressions whose context nodes are defined in the expressions whose context nodes are defined in the
mounted schema, the union of all these nodesets mounted schema, the union of all these nodesets
together with ancestor nodes are added to the together with ancestor nodes are added to the
accessible data tree."; accessible data tree.";
} }
} }
} }
} }
} }
/*
* State data nodes
*/
container schema-mounts {
config false;
description
"Contains information about the structure of the overall
mounted data 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 'parent-reference' leafs to the
corresponding namespace URI references.";
leaf prefix {
type yang:yang-identifier;
description
"Namespace prefix.";
}
leaf 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>
9. IANA Considerations 10. 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
10. Security Considerations 11. Security Considerations
This document defines a mechanism for combining schemas from YANG module "ietf-yang-schema-mount" specified in this document
different YANG modules into a single schema, and as such doesn't defines a schema for data that is designed to be accessed via network
introduce new security issues. management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040].
The lowest NETCONF layer is the secure transport layer, and the
mandatory-to-implement secure transport is Secure Shell (SSH)
[RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-
implement secure transport is TLS [RFC5246].
11. Contributors The network configuration access control model [RFC8341] provides the
means to restrict access for particular NETCONF or RESTCONF users to
a preconfigured subset of all available NETCONF or RESTCONF protocol
operations and content.
Some of the readable data nodes in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus
important to control read access (e.g., via get, get-config, or
notification) to these data nodes. These are the subtrees and data
nodes and their sensitivity/vulnerability:
o /schema-mounts: The schema defined by this state data provides
detailed information about a server implementation may help an
attacker identify the server capabilities and server
implementations with known bugs. Server vulnerabilities may be
specific to particular modules included in the schema, module
revisions, module features, or even module deviations. For
example, if a particular operation on a particular data node is
known to cause a server to crash or significantly degrade device
performance, then the schema information will help an attacker
identify server implementations with such a defect, in order to
launch a denial-of-service attack on the device.
12. 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]); and Lou Berger and Christian Hopps: ([I-D.clemm-netmod-mount]); and Lou Berger and Christian Hopps:
o Lou Berger, LabN Consulting, L.L.C., <lberger@labn.net> o Lou Berger, LabN Consulting, L.L.C., <lberger@labn.net>
o Alexander Clemm, Huawei, <alexander.clemm@huawei.com> o Alexander Clemm, Huawei, <alexander.clemm@huawei.com>
o Christian Hopps, Deutsche Telekom, <chopps@chopps.org> o Christian Hopps, Deutsche Telekom, <chopps@chopps.org>
o Jan Medved, Cisco, <jmedved@cisco.com> o Jan Medved, Cisco, <jmedved@cisco.com>
o Eric Voit, Cisco, <evoit@cisco.com> o Eric Voit, Cisco, <evoit@cisco.com>
12. References 13. References
12.1. Normative References 13.1. Normative References
[I-D.ietf-netconf-rfc7895bis]
Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K.,
and R. Wilton, "YANG Library", draft-ietf-netconf-
rfc7895bis-05 (work in progress), February 2018.
[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, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119,
RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc2119>. 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, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc3688>. editor.org/info/rfc3688>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, <https://www.rfc-
editor.org/info/rfc5246>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010, DOI 10.17487/RFC6020, October 2010, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc6020>. editor.org/info/rfc6020>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
6991, DOI 10.17487/RFC6991, July 2013, Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<http://www.rfc-editor.org/info/rfc6991>. <https://www.rfc-editor.org/info/rfc6242>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://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>. <https://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>. <https://www.rfc-editor.org/info/rfc7950>.
12.2. Informative References [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018, <https://www.rfc-
editor.org/info/rfc8341>.
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "Network Management Datastore Architecture
(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
<https://www.rfc-editor.org/info/rfc8342>.
13.2. Informative References
[I-D.clemm-netmod-mount] [I-D.clemm-netmod-mount]
Clemm, A., Voit, E., and J. Medved, "Mounting YANG-Defined Clemm, A., Voit, E., and J. Medved, "Mounting YANG-Defined
Information from Remote Datastores", draft-clemm-netmod- Information from Remote Datastores", draft-clemm-netmod-
mount-06 (work in progress), March 2017. mount-06 (work in progress), March 2017.
[I-D.ietf-isis-yang-isis-cfg] [I-D.ietf-isis-yang-isis-cfg]
Litkowski, S., Yeung, D., Lindem, A., Zhang, Z., and L. Litkowski, S., Yeung, D., Lindem, A., Zhang, Z., and L.
Lhotka, "YANG Data Model for IS-IS protocol", draft-ietf- Lhotka, "YANG Data Model for IS-IS protocol", draft-ietf-
isis-yang-isis-cfg-17 (work in progress), March 2017. isis-yang-isis-cfg-19 (work in progress), November 2017.
[I-D.ietf-netmod-yang-tree-diagrams]
Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft-
ietf-netmod-yang-tree-diagrams-01 (work in progress), June
2017.
[I-D.ietf-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 Logical Organization", draft-ietf- "Network Device YANG Logical Organization", draft-ietf-
rtgwg-device-model-02 (work in progress), March 2017. rtgwg-device-model-02 (work in progress), March 2017.
[I-D.ietf-rtgwg-lne-model] [I-D.ietf-rtgwg-lne-model]
Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X.
Liu, "YANG Logical Network Elements", draft-ietf-rtgwg- Liu, "YANG Model for Logical Network Elements", draft-
lne-model-03 (work in progress), July 2017. ietf-rtgwg-lne-model-09 (work in progress), March 2018.
[I-D.ietf-rtgwg-ni-model] [I-D.ietf-rtgwg-ni-model]
Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X.
Liu, "YANG Network Instances", draft-ietf-rtgwg-ni- Liu, "YANG Model for Network Instances", draft-ietf-rtgwg-
model-03 (work in progress), July 2017. ni-model-11 (work in progress), March 2018.
[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>. <https://www.rfc-editor.org/info/rfc6241>.
[RFC7223] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 7223, DOI 10.17487/RFC7223, May 2014,
<http://www.rfc-editor.org/info/rfc7223>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<http://www.rfc-editor.org/info/rfc8040>. <https://www.rfc-editor.org/info/rfc8040>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>.
[RFC8343] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 8343, DOI 10.17487/RFC8343, March 2018,
<https://www.rfc-editor.org/info/rfc8343>.
Appendix A. Example: Device Model with LNEs and NIs Appendix A. Example: Device Model with LNEs and NIs
This non-normative example demonstrates an implementation of the This non-normative example demonstrates an implementation of the
device model as specified in Section 2 of device model as specified in Section 2 of
[I-D.ietf-rtgwg-device-model], using both logical network elements [I-D.ietf-rtgwg-device-model], using both logical network elements
(LNE) and network instances (NI). (LNE) and network instances (NI).
In these examples, the character "\" is used where a line break has
been inserted for formatting reasons.
A.1. Physical Device A.1. Physical Device
The data model for the physical device may be described by this YANG The data model for the physical device may be described by this YANG
library content: library content, assuming the server supports the NMDA:
"ietf-yang-library:modules-state": {
"module-set-id": "14e2ab5dc325f6d86f743e8d3ade233f1a61a899",
"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",
"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": "ietf-yang-library:yang-library": {
"urn:ietf:params:xml:ns:yang:ietf-logical-network-element", "checksum": "14e2ab5dc325f6d86f743e8d3ade233f1a61a899",
"conformance-type": "implement" "module-set": [
}, {
{ "name": "physical-device-modules",
"name": "ietf-yang-library", "module": [
"revision": "2016-06-21", {
"namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-library", "name": "iana-if-type",
"conformance-type": "implement" "revision": "2015-06-12",
}, "namespace": "urn:ietf:params:xml:ns:yang:iana-if-type"
{ },
"name": "ietf-yang-schema-mount", {
"revision": "2017-05-16", "name": "ietf-interfaces",
"namespace": "revision": "2018-02-20",
"urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount", "feature": ["arbitrary-names", "pre-provisioning" ],
"conformance-type": "implement" "namespace":
}, "urn:ietf:params:xml:ns:yang:ietf-interfaces"
{ },
"name": "ietf-yang-types", {
"revision": "2013-07-15", "name": "ietf-ip",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-types", "revision": "2018-02-22",
"conformance-type": "import" "namespace": "urn:ietf:params:xml:ns:yang:ietf-ip"
} },
] {
"name": "ietf-logical-network-element",
"revision": "2016-10-21",
"feature": [ "bind-lne-name" ],
"namespace":
"urn:ietf:params:xml:ns:yang:\
ietf-logical-network-element"
},
{
"name": "ietf-yang-library",
"revision": "2018-02-21",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-yang-library"
},
{
"name": "ietf-yang-schema-mount",
"revision": "2018-03-20",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount"
}
],
"import-only-module": [
{
"name": "ietf-inet-types",
"revision": "2013-07-15",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-inet-types"
},
{
"name": "ietf-yang-types",
"revision": "2013-07-15",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-yang-types"
},
{
"name": "ietf-datastores",
"revision": "2018-02-14",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-datastores"
}
]
}
],
"schema": [
{
"name": "physical-device-schema",
"module-set": [ "physical-device-modules" ]
}
],
"datastore": [
{
"name": "ietf-datastores:running",
"schema": "physical-device-schema"
},
{
"name": "ietf-datastores:operational",
"schema": "physical-device-schema"
}
]
}
} }
A.2. Logical Network Elements A.2. Logical Network Elements
Each LNE can have a specific data model that is determined at run Each LNE can have a specific data model that is determined at run
time, so it is appropriate to mount it using the "inline" method, time, so it is appropriate to mount it using the "inline" method,
hence the following "schema-mounts" data: hence the following "schema-mounts" data:
"ietf-yang-schema-mount:schema-mounts": { {
"mount-point": [ "ietf-yang-schema-mount:schema-mounts": {
{ "mount-point": [
"module": "ietf-logical-network-element", {
"label": "root", "module": "ietf-logical-network-element",
"inline": [null] "label": "root",
} "inline": {}
] }
]
}
} }
An administrator of the host device has to configure an entry for An administrator of the host device has to configure an entry for
each LNE instance, for example, each LNE instance, for example,
{ {
"ietf-interfaces:interfaces": { "ietf-interfaces:interfaces": {
"interface": [ "interface": [
{ {
"name": "eth0", "name": "eth0",
"type": "iana-if-type:ethernetCsmacd", "type": "iana-if-type:ethernetCsmacd",
"enabled": true, "enabled": true,
"ietf-logical-network-element:bind-lne-name": "eth0" "ietf-logical-network-element:bind-lne-name": "eth0"
} }
] ]
skipping to change at page 23, line 24 skipping to change at page 22, line 40
}, },
"ietf-logical-network-element:logical-network-elements": { "ietf-logical-network-element:logical-network-elements": {
"logical-network-element": [ "logical-network-element": [
{ {
"name": "lne-1", "name": "lne-1",
"managed": true, "managed": true,
"description": "LNE with NIs", "description": "LNE with NIs",
"root": { "root": {
... ...
} }
}, }
... ...
] ]
} }
} }
and then also place necessary state data as the contents of the and then also place necessary state data as the contents of the
"root" instance, which should include at least "root" instance, which should include at least
o YANG library data specifying the LNE's data model, for example: o YANG library data specifying the LNE's data model, for example,
assuming the server does not implement the NMDA:
"ietf-yang-library:modules-state": { {
"module-set-id": "9358e11874068c8be06562089e94a89e0a392019", "ietf-yang-library:modules-state": {
"module": [ "module-set-id": "9358e11874068c8be06562089e94a89e0a392019",
{ "module": [
"name": "iana-if-type", {
"revision": "2014-05-08", "name": "iana-if-type",
"namespace": "urn:ietf:params:xml:ns:yang:iana-if-type", "revision": "2014-05-08",
"conformance-type": "implement" "namespace": "urn:ietf:params:xml:ns:yang:iana-if-type",
}, "conformance-type": "implement"
{ },
"name": "ietf-inet-types", {
"revision": "2013-07-15", "name": "ietf-inet-types",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-inet-types", "revision": "2013-07-15",
"conformance-type": "import" "namespace": "urn:ietf:params:xml:ns:yang:ietf-inet-types",
}, "conformance-type": "import"
{ },
"name": "ietf-interfaces", {
"revision": "2014-05-08", "name": "ietf-interfaces",
"feature": [ "revision": "2014-05-08",
"arbitrary-names", "feature": [
"pre-provisioning" "arbitrary-names",
], "pre-provisioning"
"namespace": "urn:ietf:params:xml:ns:yang:ietf-interfaces", ],
"conformance-type": "implement" "namespace": "urn:ietf:params:xml:ns:yang:ietf-interfaces",
}, "conformance-type": "implement"
{ },
"name": "ietf-ip", {
"revision": "2014-06-16", "name": "ietf-ip",
"feature": [ "revision": "2014-06-16",
"ipv6-privacy-autoconf" "feature": [
], "ipv6-privacy-autoconf"
"namespace": "urn:ietf:params:xml:ns:yang:ietf-ip", ],
"conformance-type": "implement" "namespace": "urn:ietf:params:xml:ns:yang:ietf-ip",
}, "conformance-type": "implement"
{ },
"name": "ietf-network-instance", {
"revision": "2016-10-27", "name": "ietf-network-instance",
"feature": [ "revision": "2016-10-27",
"bind-network-instance-name" "feature": [
], "bind-network-instance-name"
"namespace": ],
"urn:ietf:params:xml:ns:yang:ietf-network-instance", "namespace":
"conformance-type": "implement" "urn:ietf:params:xml:ns:yang:ietf-network-instance",
}, "conformance-type": "implement"
{ },
"name": "ietf-yang-library", {
"revision": "2016-06-21", "name": "ietf-yang-library",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-library", "revision": "2016-06-21",
"conformance-type": "implement" "namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-library",
}, "conformance-type": "implement"
{ },
"name": "ietf-yang-schema-mount", {
"revision": "2017-05-16", "name": "ietf-yang-schema-mount",
"namespace": "revision": "2017-05-16",
"urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount", "namespace":
"conformance-type": "implement" "urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount",
}, "conformance-type": "implement"
{ },
"name": "ietf-yang-types", {
"revision": "2013-07-15", "name": "ietf-yang-types",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-types", "revision": "2013-07-15",
"conformance-type": "import" "namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-types",
} "conformance-type": "import"
] }
]
}
} }
o state data for interfaces assigned to the LNE instance (that o state data for interfaces assigned to the LNE instance (that
effectively become system-controlled interfaces for the LNE), for effectively become system-controlled interfaces for the LNE), for
example: example:
"ietf-interfaces:interfaces-state": { {
"interface": [ "ietf-interfaces:interfaces": {
{ "interface": [
"name": "eth0", {
"type": "iana-if-type:ethernetCsmacd", "name": "eth0",
"oper-status": "up", "type": "iana-if-type:ethernetCsmacd",
"statistics": { "oper-status": "up",
"discontinuity-time": "2016-12-16T17:11:27+02:00" "statistics": {
}, "discontinuity-time": "2016-12-16T17:11:27+02:00"
"ietf-ip:ipv6": { },
"address": [ "ietf-ip:ipv6": {
{ "address": [
"ip": "fe80::42a8:f0ff:fea8:24fe", {
"origin": "link-layer", "ip": "fe80::42a8:f0ff:fea8:24fe",
"prefix-length": 64 "origin": "link-layer",
} "prefix-length": 64
] }
]
}
} }
}, ]
... }
]
} }
A.3. Network Instances A.3. Network Instances
Assuming that network instances share the same data model, it can be Assuming that network instances share the same data model, it can be
mounted using the "use-schema" method as follows: mounted using the "shared-schema" method as follows:
"ietf-yang-schema-mount:schema-mounts": { {
"namespace": [ "ietf-yang-schema-mount:schema-mounts": {
{ "namespace": [
"prefix": "if", {
"uri": "urn:ietf:params:xml:ns:yang:ietf-interfaces" "prefix": "if",
}, "uri": "urn:ietf:params:xml:ns:yang:ietf-interfaces"
{ },
"prefix": "ni", {
"uri": "urn:ietf:params:xml:ns:yang:ietf-network-instance" "prefix": "ni",
} "uri": "urn:ietf:params:xml:ns:yang:ietf-network-instance"
], }
"mount-point": [ ],
{ "mount-point": [
"module": "ietf-network-instance", {
"label": "root", "module": "ietf-network-instance",
"use-schema": [ "label": "root",
{ "shared-schema": {
"name": "ni-schema", "parent-reference": [
"parent-reference": [ "/if:interfaces/if:interface[\
"/if:interfaces/if:interface[ ni:bind-network-instance-name = current()/../ni:name]"
ni:bind-network-instance-name = current()/../ni:name]" ]
] }
} }
] ]
} }
],
"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"
}
]
}
]
} }
Note also that the "ietf-interfaces" module appears in the Note also that the "ietf-interfaces" module appears in the
"parent-reference" leaf-list for the mounted NI schema. This means "parent-reference" leaf-list for the mounted NI schema. This means
that references to LNE interfaces, such as "outgoing-interface" in that references to LNE interfaces, such as "outgoing-interface" in
static routes, are valid despite the fact that "ietf-interfaces" static routes, are valid despite the fact that "ietf-interfaces"
isn't part of the NI schema. isn't part of the NI schema.
A.4. Invoking an RPC Operation A.4. Invoking an RPC Operation
 End of changes. 79 change blocks. 
516 lines changed or deleted 472 lines changed or added

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