draft-ietf-rtgwg-ni-model-12.txt   rfc8529.txt 
Network Working Group L. Berger Internet Engineering Task Force (IETF) L. Berger
Internet-Draft LabN Consulting, L.L.C. Request for Comments: 8529 C. Hopps
Intended status: Standards Track C. Hopps Category: Standards Track LabN Consulting, L.L.C.
Expires: September 20, 2018 Deutsche Telekom ISSN: 2070-1721 A. Lindem
A. Lindem
Cisco Systems Cisco Systems
D. Bogdanovic D. Bogdanovic
X. Liu X. Liu
Jabil Volta Networks
March 19, 2018 March 2019
YANG Model for Network Instances YANG Data Model for Network Instances
draft-ietf-rtgwg-ni-model-12
Abstract Abstract
This document defines a network instance module. This module can be This document defines a network instance module. This module can be
used to manage the virtual resource partitioning that may be present used to manage the virtual resource partitioning that may be present
on a network device. Examples of common industry terms for virtual on a network device. Examples of common industry terms for virtual
resource partitioning are Virtual Routing and Forwarding (VRF) resource partitioning are VPN Routing and Forwarding (VRF) instances
instances and Virtual Switch Instances (VSIs). and Virtual Switch Instances (VSIs).
The YANG model in this document conforms to the Network Management The YANG data model in this document conforms to the Network
Datastore Architecture defined in I-D.ietf-netmod-revised-datastores. Management Datastore Architecture (NMDA) defined in RFC 8342.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on September 20, 2018. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8529.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Network Instances . . . . . . . . . . . . . . . . . . . . . . 5 3. Network Instances . . . . . . . . . . . . . . . . . . . . . . 6
3.1. NI Types and Mount Points . . . . . . . . . . . . . . . . 6 3.1. NI Types and Mount Points . . . . . . . . . . . . . . . . 7
3.1.1. Well Known Mount Points . . . . . . . . . . . . . . . 7 3.1.1. Well-Known Mount Points . . . . . . . . . . . . . . . 8
3.1.2. NI Type Example . . . . . . . . . . . . . . . . . . . 8 3.1.2. NI Type Example . . . . . . . . . . . . . . . . . . . 9
3.2. NIs and Interfaces . . . . . . . . . . . . . . . . . . . 9 3.2. NIs and Interfaces . . . . . . . . . . . . . . . . . . . 9
3.3. Network Instance Management . . . . . . . . . . . . . . . 10 3.3. Network Instance Management . . . . . . . . . . . . . . . 11
3.4. Network Instance Instantiation . . . . . . . . . . . . . 12 3.4. Network Instance Instantiation . . . . . . . . . . . . . 14
4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6. Network Instance Model . . . . . . . . . . . . . . . . . . . 14 6. Network Instance Model . . . . . . . . . . . . . . . . . . . 16
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
7.1. Normative References . . . . . . . . . . . . . . . . . . 20 7.1. Normative References . . . . . . . . . . . . . . . . . . 22
7.2. Informative References . . . . . . . . . . . . . . . . . 22 7.2. Informative References . . . . . . . . . . . . . . . . . 23
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 23 Appendix A. Example NI Usage . . . . . . . . . . . . . . . . . . 25
Appendix B. Example NI usage . . . . . . . . . . . . . . . . . . 23 A.1. Configuration Data . . . . . . . . . . . . . . . . . . . 25
B.1. Configuration Data . . . . . . . . . . . . . . . . . . . 23 A.2. State Data - Non-NMDA Version . . . . . . . . . . . . . . 28
B.2. State Data - Non-NMDA Version . . . . . . . . . . . . . . 27 A.3. State Data - NMDA Version . . . . . . . . . . . . . . . . 35
B.3. State Data - NMDA Version . . . . . . . . . . . . . . . . 33 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
1. Introduction 1. Introduction
This document defines the second of two new modules that are defined This document defines the second of two new modules that are defined
to support the configuration and operation of network-devices that to support the configuration and operation of network devices that
allow for the partitioning of resources from both, or either, allow for the partitioning of resources from both, or either,
management and networking perspectives. Both leverage the YANG management and networking perspectives. Both leverage the YANG
functionality enabled by YANG Schema Mount functionality enabled by YANG Schema Mount [RFC8528].
[I-D.ietf-netmod-schema-mount].
The YANG model in this document conforms to the Network Management The YANG data model in this document conforms to the Network
Datastore Architecture defined in the Management Datastore Architecture defined in [RFC8342].
[I-D.ietf-netmod-revised-datastores].
The first form of resource partitioning provides a logical The first form of resource partitioning provides a logical
partitioning of a network device where each partition is separately partitioning of a network device where each partition is separately
managed as essentially an independent network element which is managed as essentially an independent network element that is
'hosted' by the base network device. These hosted network elements "hosted" by the base network device. These hosted network elements
are referred to as logical network elements, or LNEs, and are are referred to as logical network elements, or LNEs, and are
supported by the logical-network-element module defined in supported by the logical-network-element module defined in [RFC8530].
[I-D.ietf-rtgwg-lne-model]. That module is used to identify LNEs and That module is used to identify LNEs and associate resources from the
associate resources from the network-device with each LNE. LNEs network device with each LNE. LNEs themselves are represented in
themselves are represented in YANG as independent network devices; YANG as independent network devices; each is accessed independently.
each accessed independently. Examples of vendor terminology for an Examples of vendor terminology for an LNE include logical system or
LNE include logical system or logical router, and virtual switch, logical router and virtual switch, chassis, or fabric.
chassis, or fabric.
The second form, which is defined in this document, provides support The second form, which is defined in this document, provides support
for what is commonly referred to as Virtual Routing and Forwarding for what are commonly referred to as VPN Routing and Forwarding (VRF)
(VRF) instances as well as Virtual Switch Instances (VSI), see instances as well as Virtual Switch Instances (VSI); see [RFC4026]
[RFC4026] and [RFC4664]. In this form of resource partitioning, and [RFC4664]. In this form of resource partitioning, multiple
multiple control plane and forwarding/bridging instances are provided control-plane and forwarding/bridging instances are provided by and
by and managed via a single (physical or logical) network device. managed through a single (physical or logical) network device. This
This form of resource partitioning is referred to as a Network form of resource partitioning is referred to as a Network Instance
Instance and is supported by the network-instance module defined (NI) and is supported by the network instance module defined below.
below. Configuration and operation of each network-instance is Configuration and operation of each network instance is always via
always via the network device and the network-instance module. the network device and the network instance module.
One notable difference between the LNE model and the NI model is that One notable difference between the LNE model and the NI model is that
the NI model provides a framework for VRF and VSI management. This the NI model provides a framework for VRF and VSI management. This
document envisions the separate definition of VRF and VSI, i.e., L3 document envisions the separate definition of models specific to VRF
and L2 VPN, technology specific models. An example of such can be and VSI -- i.e., L3 and L2 VPN -- technology. An example of such can
found in the emerging L3VPN model defined in be found in the emerging L3VPN model defined in [YANG-L3VPN] and the
[I-D.ietf-bess-l3vpn-yang] and the examples discussed below. examples discussed below.
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "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
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Readers are expected to be familiar with terms and concepts of YANG Readers are expected to be familiar with terms and concepts of YANG
[RFC7950] and YANG Schema Mount [I-D.ietf-netmod-schema-mount]. [RFC7950] and YANG Schema Mount [RFC8528].
This document uses the graphical representation of data models This document uses the graphical representation of data models
defined in [I-D.ietf-netmod-yang-tree-diagrams]. defined in [RFC8340].
2. Overview 2. Overview
In this document, we consider network devices that support protocols In this document, we consider network devices that support protocols
and functions defined within the IETF, e.g, routers, firewalls, and and functions defined within the IETF -- e.g., routers, firewalls,
hosts. Such devices may be physical or virtual, e.g., a classic and hosts. Such devices may be physical or virtual, e.g., a classic
router with custom hardware or one residing within a server-based router with custom hardware or one residing within a server-based
virtual machine implementing a virtual network function (VNF). Each virtual machine implementing a virtual network function (VNF). Each
device may sub-divide their resources into logical network elements device may subdivide their resources into logical network elements
(LNEs) each of which provides a managed logical device. Examples of (LNEs), each of which provides a managed logical device. Examples of
vendor terminology for an LNE include logical system or logical vendor terminology for an LNE include logical system or logical
router, and virtual switch, chassis, or fabric. Each LNE may also router and virtual switch, chassis, or fabric. Each LNE may also
support virtual routing and forwarding (VRF) and virtual switching support VRF and VSI functions, which are referred to below as network
instance (VSI) functions, which are referred to below as a network
instances (NIs). This breakdown is represented in Figure 1. instances (NIs). This breakdown is represented in Figure 1.
,''''''''''''''''''''''''''''''''''''''''''''''`. ,''''''''''''''''''''''''''''''''''''''''''''''`.
| Network Device (Physical or Virtual) | | Network Device (Physical or Virtual) |
| ..................... ..................... | | ..................... ..................... |
| : Logical Network : : Logical Network : | | : Logical Network : : Logical Network : |
| : Element : : Element : | | : Element : : Element : |
| :+-----+-----+-----+: :+-----+-----+-----+: | | :+-----+-----+-----+: :+-----+-----+-----+: |
| :| Net | Net | Net |: :| Net | Net | Net |: | | :| Net | Net | Net |: :| Net | Net | Net |: |
| :|Inst.|Inst.|Inst.|: :|Inst.|Inst.|Inst.|: | | :|Inst.|Inst.|Inst.|: :|Inst.|Inst.|Inst.|: |
| :+-----+-----+-----+: :+-----+-----+-----+: | | :+-----+-----+-----+: :+-----+-----+-----+: |
| : | | | | | | : : | | | | | | : | | : | | | | | | : : | | | | | | : |
| :..|.|...|.|...|.|..: :..|.|...|.|...|.|..: | | :..|.|...|.|...|.|..: :..|.|...|.|...|.|..: |
| | | | | | | | | | | | | | | | | | | | | | | | | | | |
`'''|'|'''|'|'''|'|'''''''''|'|'''|'|'''|'|''''' `'''|'|'''|'|'''|'|'''''''''|'|'''|'|'''|'|'''''
| | | | | | | | | | | | | | | | | | | | | | | |
Interfaces Interfaces Interfaces Interfaces
Figure 1: Module Element Relationships Figure 1: Module Element Relationships
A model for LNEs is described in [I-D.ietf-rtgwg-lne-model] and the A model for LNEs is described in [RFC8530], and the model for NIs is
model for NIs is covered in this document in Section 3. covered in Section 3 of this document.
The current interface management model [I-D.ietf-netmod-rfc7223bis] The current interface management model [RFC8343] is impacted by the
is impacted by the definition of LNEs and NIs. This document and definition of LNEs and NIs. This document and [RFC8530] define
[I-D.ietf-rtgwg-lne-model] define augmentations to the interface augmentations to the interface module to support LNEs and NIs.
module to support LNEs and NIs.
The network instance model supports the configuration of VRFs and The network instance model supports the configuration of VRFs and
VSIs. Each instance is supported by information that relates to the VSIs. Each instance is supported by information that relates to the
device, for example the route target used when advertising VRF routes device -- for example, the route target used when advertising VRF
via the mechanisms defined in [RFC4364], and information that relates routes via the mechanisms defined in [RFC4364], and information that
to the internal operation of the NI, for example for routing relates to the internal operation of the NI, such as for routing
protocols [I-D.ietf-netmod-rfc8022bis] and OSPF [I-D.ietf-ospf-yang]. protocols [RFC8349] and OSPF [YANG-OSPF]. This document defines the
network instance module that provides a basis for the management of
This document defines the network-instance module that provides a both types of information.
basis for the management of both types of information.
NI information that relates to the device, including the assignment NI information that relates to the device, including the assignment
of interfaces to NIs, is defined as part of this document. The of interfaces to NIs, is defined as part of this document. The
defined module also provides a placeholder for the definition of NI- defined module also provides a placeholder for the definition of
technology specific information both at the device level and for NI NI-technology-specific information both at the device level and for
internal operation. Information related to NI internal operation is NI internal operation. Information related to NI internal operation
supported via schema mount [I-D.ietf-netmod-schema-mount] and is supported via schema mount [RFC8528] and mounting appropriate
mounting appropriate modules under the mount point. Well known mount modules under the mount point. Well-known mount points are defined
points are defined for L3VPN, L2VPN, and L2+L3VPN NI types. for L3VPN, L2VPN, and L2+L3VPN NI types.
3. Network Instances 3. Network Instances
The network instance container is used to represent virtual routing The network instance container is used to represent VRFs and VSIs.
and forwarding instances (VRFs) and virtual switching instances VRFs and VSIs are commonly used to isolate routing and switching
(VSIs). VRFs and VSIs are commonly used to isolate routing and domains -- for example, to create virtual private networks, each with
switching domains, for example to create virtual private networks, their own active protocols and routing/switching policies. The model
each with their own active protocols and routing/switching policies. supports both core/provider and virtual instances. Core/provider
The model supports both core/provider and virtual instances. Core/ instance information is accessible at the top level of the server,
provider instance information is accessible at the top level of the while virtual instance information is accessible under the root
server, while virtual instance information is accessible under the schema mount points.
root schema mount points.
module: ietf-network-instance module: ietf-network-instance
+--rw network-instances +--rw network-instances
+--rw network-instance* [name] +--rw network-instance* [name]
+--rw name string +--rw name string
+--rw enabled? boolean +--rw enabled? boolean
+--rw description? string +--rw description? string
+--rw (ni-type)? +--rw (ni-type)?
+--rw (root-type) +--rw (root-type)
+--:(vrf-root) +--:(vrf-root)
skipping to change at page 6, line 40 skipping to change at page 7, line 5
| +--ro bind-ni-name? | +--ro bind-ni-name?
| -> /if:interfaces/interface/ni:bind-ni-name | -> /if:interfaces/interface/ni:bind-ni-name
+--ro ipv4 +--ro ipv4
| +--ro bind-ni-name? | +--ro bind-ni-name?
| -> /if:interfaces/interface/ip:ipv4/ni:bind-ni-name | -> /if:interfaces/interface/ip:ipv4/ni:bind-ni-name
+--ro ipv6 +--ro ipv6
| +--ro bind-ni-name? | +--ro bind-ni-name?
| -> /if:interfaces/interface/ip:ipv6/ni:bind-ni-name | -> /if:interfaces/interface/ip:ipv6/ni:bind-ni-name
+--ro error-info? string +--ro error-info? string
A network instance is identified by a 'name' string. This string is A network instance is identified by a "name" string. This string is
used both as an index within the network-instance module and to used both as an index within the network instance module and to
associate resources with a network instance as shown above in the associate resources with a network instance, as shown above in the
interface augmentation. The ni-type and root-type choice statements interface augmentation. The ni-type and root-type choice statements
are used to support different types of L2 and L3 VPN technologies. are used to support different types of L2 and L3 VPN technologies.
The bind-ni-name-failed notification is used in certain failure The bind-ni-name-failed notification is used in certain failure
cases. cases.
3.1. NI Types and Mount Points 3.1. NI Types and Mount Points
The network-instance module is structured to facilitate the The network instance module is structured to facilitate the
definition of information models for specific types of VRFs and VSIs definition of information models for specific types of VRFs and VSIs
using augmentations. For example, the information needed to support using augmentations. For example, the information needed to support
VPLS, VxLAN and EVPN based L2VPNs are likely to be quite different. L2VPN, such as VPLS and EVPN, are likely to be quite different.
Example models under development that could be restructured to take Example models under development that could be restructured to take
advantage on NIs include, for L3VPNs [I-D.ietf-bess-l3vpn-yang] and advantage on NIs include models for L3VPNs [YANG-L3VPN] and L2VPNs
for L2VPNs [I-D.ietf-bess-l2vpn-yang]. [YANG-L2VPN].
Documents defining new YANG models for the support of specific types Documents defining new YANG data models for the support of specific
of network instances should augment the network instance module. The types of network instances should augment the network instance
basic structure that should be used for such augmentations include a module. The basic structure that should be used for such
case statement, with containers for configuration and state data and augmentations includes a case statement with containers for
finally, when needed, a type specific mount point. Generally ni configuration and state data and, when needed, a type-specific mount
types, are expected to not need to define type specific mount points, point. Generally, NI types are expected to not need to define type-
but rather reuse one of the well known mount point, as defined in the specific mount points but rather reuse one of the well-known mount
next section. The following is an example type specific points, as defined in the next section. The following is an example
augmentation: type-specific augmentation:
augment "/ni:network-instances/ni:network-instance/ni:ni-type" { augment "/ni:network-instances/ni:network-instance/ni:ni-type" {
case l3vpn { case l3vpn {
container l3vpn { container l3vpn {
... ...
} }
container l3vpn-state { container l3vpn-state {
... ...
} }
} }
} }
3.1.1. Well Known Mount Points 3.1.1. Well-Known Mount Points
YANG Schema Mount, [I-D.ietf-netmod-schema-mount], identifies mount YANG Schema Mount [RFC8528] identifies mount points by name within a
points by name within a module. This definition allows for the module. This definition allows for the definition of mount points
definition of mount points whose schema can be shared across ni- whose schema can be shared across NI types. As discussed above,
types. As discussed above, ni-types largely differ in the ni-types largely differ in the configuration information needed in
configuration information needed in the core/top level instance to the core/top-level instance to support the NI, rather than in the
support the NI, rather than in the information represented within an information represented within an NI. This allows the use of shared
NI. This allows the use of shared mount points across certain NI mount points across certain NI types.
types.
The expectation is that there are actually very few different schema The expectation is that there are actually very few different schemas
that need to be defined to support NIs on an implementation. In that need to be defined to support NIs for an implementation. In
particular, it is expected that the following three forms of NI particular, it is expected that the following three forms of NI
schema are needed, and each can be defined with a well known mount schema are needed, and each can be defined with a well-known mount
point that can be reused by future modules defining ni-types. point that can be reused by future modules defining NI types.
The three well known mount points are: The three well-known mount points are:
vrf-root vrf-root
vrf-root is intended for use with L3VPN type ni-types. vrf-root is intended for use with L3VPN-type NI types.
vsi-root vsi-root
vsi-root is intended for use with L2VPN type ni-types. vsi-root is intended for use with L2VPN-type Ni types.
vv-root vv-root
vv-root is intended for use with ni-types that simultaneously vv-root is intended for use with NI types that simultaneously
support L2VPN bridging and L3VPN routing capabilities. support L2VPN bridging and L3VPN routing capabilities.
Future model definitions should use the above mount points whenever Future model definitions should use the above mount points whenever
possible. When a well known mount point isn't appropriate, a model possible. When a well-known mount point isn't appropriate, a model
may define a type specific mount point via augmentation. may define a type-specific mount point via augmentation.
3.1.2. NI Type Example 3.1.2. NI Type Example
The following is an example of an L3VPN VRF using a hypothetical The following is an example of an L3VPN VRF using a hypothetical
augmentation to the networking instance schema defined in augmentation to the network instance schema defined in [YANG-L3VPN].
[I-D.ietf-bess-l3vpn-yang]. More detailed examples can be found in More detailed examples can be found in Appendix A.
Appendix B.
module: ietf-network-instance module: ietf-network-instance
+--rw network-instances +--rw network-instances
+--rw network-instance* [name] +--rw network-instance* [name]
+--rw name string +--rw name string
+--rw enabled? boolean +--rw enabled? boolean
+--rw description? string +--rw description? string
+--rw (ni-type)? +--rw (ni-type)?
| +--:(l3vpn) | +--:(l3vpn)
| +--rw l3vpn:l3vpn | +--rw l3vpn:l3vpn
| | ... // config data | | ... // config data
| +--ro l3vpn:l3vpn-state | +--ro l3vpn:l3vpn-state
| | ... // state data | | ... // state data
+--rw (root-type) +--rw (root-type)
+--:(vrf-root) +--:(vrf-root)
+--mp vrf-root +--mp vrf-root
+--rw rt:routing/ +--rw rt:routing/
| +--rw router-id? yang:dotted-quad | +--rw router-id? yang:dotted-quad
| +--rw control-plane-protocols | +--rw control-plane-protocols
| +--rw control-plane-protocol* [type name] | +--rw control-plane-protocol* [type name]
| +--rw ospf:ospf/ | +--rw ospf:ospf
| +--rw area* [area-id] | +--rw area* [area-id]
| +--rw interfaces | +--rw interfaces
| +--rw interface* [name] | +--rw interface* [name]
| +--rw name if:interface-ref | +--rw name if:interface-ref
| +--rw cost? uint16 | +--rw cost? uint16
+--ro if:interfaces@ +--ro if:interfaces@
| ... | ...
This shows YANG Routing Management [I-D.ietf-netmod-rfc8022bis] and This shows YANG Routing Management [RFC8349] and YANG OSPF
YANG OSPF [I-D.ietf-ospf-yang] as mounted modules. The mounted [YANG-OSPF] as mounted modules. The mounted modules can reference
modules can reference interface information via a parent-reference to interface information via a parent-reference to the containers
the containers defined in [I-D.ietf-netmod-rfc7223bis]. defined in [RFC8343].
3.2. NIs and Interfaces 3.2. NIs and Interfaces
Interfaces are a crucial part of any network device's configuration Interfaces are a crucial part of any network device's configuration
and operational state. They generally include a combination of raw and operational state. They generally include a combination of raw
physical interfaces, link-layer interfaces, addressing configuration, physical interfaces, link-layer interfaces, addressing configuration,
and logical interfaces that may not be tied to any physical and logical interfaces that may not be tied to any physical
interface. Several system services, and layer 2 and layer 3 interface. Several system services and Layer 2 and Layer 3 protocols
protocols may also associate configuration or operational state data may also associate configuration or operational state data with
with different types of interfaces (these relationships are not shown different types of interfaces (these relationships are not shown for
for simplicity). The interface management model is defined by simplicity). The interface management model is defined by [RFC8343].
[I-D.ietf-netmod-rfc7223bis].
As shown below, the network-instance module augments the existing As shown below, the network instance module augments the existing
interface management model by adding a name which is used on interface management model by adding a name that is used on interface
interface or sub-interface types to identify an associated network or sub-interface types to identify an associated network instance.
instance. Similarly, this name is also added for IPv4 and IPv6 Similarly, this name is also added for IPv4 and IPv6 types, as
types, as defined in [I-D.ietf-netmod-rfc7277bis]. defined in [RFC8344].
The following is an example of envisioned usage. The interfaces The following is an example of envisioned usage. The interfaces
container includes a number of commonly used components as examples: container includes a number of commonly used components as examples:
module: ietf-interfaces module: ietf-interfaces
+--rw interfaces +--rw interfaces
| +--rw interface* [name] | +--rw interface* [name]
| +--rw name string | +--rw name string
| +--rw ip:ipv4! | +--rw ip:ipv4!
| | +--rw ip:enabled? boolean | | +--rw ip:enabled? boolean
skipping to change at page 9, line 49 skipping to change at page 10, line 38
| | | +--:(ip:prefix-length) | | | +--:(ip:prefix-length)
| | | | +--rw ip:prefix-length? uint8 | | | | +--rw ip:prefix-length? uint8
| | | +--:(ip:netmask) | | | +--:(ip:netmask)
| | | +--rw ip:netmask? yang:dotted-quad | | | +--rw ip:netmask? yang:dotted-quad
| | +--rw ip:neighbor* [ip] | | +--rw ip:neighbor* [ip]
| | | +--rw ip:ip inet:ipv4-address-no-zone | | | +--rw ip:ip inet:ipv4-address-no-zone
| | | +--rw ip:link-layer-address yang:phys-address | | | +--rw ip:link-layer-address yang:phys-address
| | +--rw ni:bind-network-instance-name? string | | +--rw ni:bind-network-instance-name? string
| +--rw ni:bind-network-instance-name? string | +--rw ni:bind-network-instance-name? string
The [I-D.ietf-netmod-rfc7223bis] defined interface model is The "ietf-interfaces" module [RFC8343] is structured to include all
structured to include all interfaces in a flat list, without regard interfaces in a flat list, without regard to virtual instances (e.g.,
to virtual instances (e.g., VRFs) supported on the device. The bind- VRFs) supported on the device. The bind-network-instance-name leaf
network-instance-name leaf provides the association between an provides the association between an interface and its associated NI
interface and its associated NI (e.g., VRF or VSI). Note that as (e.g., VRF or VSI). Note that as currently defined, to assign an
currently defined, to assign an interface to both an LNE and NI, the interface to both an LNE and an NI, the interface would first be
interface would first be assigned to the LNE using the mechanisms assigned to the LNE using the mechanisms defined in [RFC8530] and
defined in [I-D.ietf-rtgwg-lne-model] and then within that LNE's then, within that LNE's interface module, the LNE's representation of
interface module, the LNE's representation of that interface would be that interface would be assigned to an NI.
assigned to an NI.
3.3. Network Instance Management 3.3. Network Instance Management
Modules that may be used to represent network instance information Modules that may be used to represent network instance information
will be available under the ni-type specific 'root' mount point. The will be available under the "root" mount point specific to the
"shared-schema" method defined in the "ietf-yang-schema-mount" module ni-type. The "shared-schema" method defined in the "ietf-yang-
[I-D.ietf-netmod-schema-mount] MUST be used to identify accessible schema-mount" module [RFC8528] MUST be used to identify accessible
modules. A future version of this document could relax this modules. A future version of this document could relax this
requirement. Mounted modules SHOULD be defined with access, via the requirement. Mounted modules SHOULD be defined with access, via the
appropriate schema mount parent-references appropriate schema mount parent-references [RFC8528], to device
[I-D.ietf-netmod-schema-mount], to device resources such as resources such as interfaces. An implementation MAY choose to
interfaces. An implementation MAY choose to restrict parent restrict parent-referenced information to information related to a
referenced information to information related to a specific instance, specific instance. For example, it might only allow references to
e.g., only allowing references to interfaces that have a "bind- interfaces that have a "bind-network-instance-name" that is identical
network-instance-name" which is identical to the instance's "name". to the instance's "name".
All modules that represent control-plane and data-plane information All modules that represent control-plane and data-plane information
may be present at the 'root' mount point, and be accessible via paths may be present at the "root" mount point and accessible via paths
modified per [I-D.ietf-netmod-schema-mount]. The list of available modified per [RFC8528]. The list of available modules is expected to
modules is expected to be implementation dependent, as is the method be implementation dependent, as is the method used by an
used by an implementation to support NIs. implementation to support NIs.
For example, the following could be used to define the data For example, the following could be used to define the data
organization of the example NI shown in Section 3.1.2: organization of the example NI shown in Section 3.1.2:
"ietf-yang-schema-mount:schema-mounts": { "ietf-yang-schema-mount:schema-mounts": {
"mount-point": [ "mount-point": [
{ {
"module": "ietf-network-instance", "module": "ietf-network-instance",
"label": "vrf-root", "label": "vrf-root",
"shared-schema": { "shared-schema": {
"parent-reference": [ "parent-reference": [
"/*[namespace-uri() = 'urn:ietf:...:ietf-interfaces']" "/*[namespace-uri() = 'urn:ietf:...:ietf-interfaces']"
] ]
} }
} }
] ]
} }
Module data identified according to the ietf-yang-schema-mount module Module data identified according to the ietf-yang-schema-mount module
will be instantiated under the mount point identified under "mount- will be instantiated under the mount point identified under
point". These modules will be able to reference information for "mount-point". These modules will be able to reference information
nodes belonging to top-level modules that are identified under for nodes belonging to top-level modules that are identified under
"parent-reference". Parent referenced information is available to "parent-reference". Parent-referenced information is available to
clients via their top level paths only, and not under the associated clients via their top-level paths only and not under the associated
mount point. mount point.
To allow a client to understand the previously mentioned instance To allow a client to understand the previously mentioned instance
restrictions on parent referenced information, an implementation MAY restrictions on parent-referenced information, an implementation MAY
represent such restrictions in the "parent-reference" leaf-list. For represent such restrictions in the "parent-reference" leaf-list. For
example: example:
"namespace": [ "namespace": [
{ {
"prefix": "if", "prefix": "if",
"uri": "urn:ietf:params:xml:ns:yang:ietf-interfaces" "uri": "urn:ietf:params:xml:ns:yang:ietf-interfaces"
}, },
{ {
"prefix": "ni", "prefix": "ni",
skipping to change at page 11, line 43 skipping to change at page 13, line 6
"/if:interfaces/if:interface/ip:ipv4 "/if:interfaces/if:interface/ip:ipv4
[ni:bind-network-instance-name = current()/../ni:name]", [ni:bind-network-instance-name = current()/../ni:name]",
"/if:interfaces/if:interface/ip:ipv6 "/if:interfaces/if:interface/ip:ipv6
[ni:bind-network-instance-name = current()/../ni:name]" [ni:bind-network-instance-name = current()/../ni:name]"
] ]
} }
} }
], ],
The same such "parent-reference" restrictions for non-NMDA The same such "parent-reference" restrictions for non-NMDA
implementations can be represented based on the [RFC7223] and implementations can be represented based on [RFC8343] and [RFC8344]
[RFC7277] as: as:
"namespace": [ "namespace": [
{ {
"prefix": "if", "prefix": "if",
"uri": "urn:ietf:params:xml:ns:yang:ietf-interfaces" "uri": "urn:ietf:params:xml:ns:yang:ietf-interfaces"
}, },
{ {
"prefix": "ni", "prefix": "ni",
"uri": "urn:ietf:params:xml:ns:yang:ietf-network-instance" "uri": "urn:ietf:params:xml:ns:yang:ietf-network-instance"
} }
skipping to change at page 12, line 34 skipping to change at page 13, line 38
[if:name = /if:interfaces/if:interface [if:name = /if:interfaces/if:interface
[ni:bind-ni-name = current()/../ni:name]/if:name]", [ni:bind-ni-name = current()/../ni:name]/if:name]",
"/if:interfaces/if:interface/ip:ipv4 "/if:interfaces/if:interface/ip:ipv4
[ni:bind-network-instance-name = current()/../ni:name]", [ni:bind-network-instance-name = current()/../ni:name]",
"/if:interfaces-state/if:interface/ip:ipv4 "/if:interfaces-state/if:interface/ip:ipv4
[if:name = /if:interfaces/if:interface/ip:ipv4 [if:name = /if:interfaces/if:interface/ip:ipv4
[ni:bind-ni-name = current()/../ni:name]/if:name]", [ni:bind-ni-name = current()/../ni:name]/if:name]",
"/if:interfaces/if:interface/ip:ipv6 "/if:interfaces/if:interface/ip:ipv6
[ni:bind-network-instance-name = current()/../ni:name]", [ni:bind-network-instance-name = current()/../ni:name]",
"/if:interfaces-state/if:interface/ip:ipv6 "/if:interfaces-state/if:interface/ip:ipv6
[if:name = /if:interfaces/if:interface/ip:ipv4 [if:name = /if:interfaces/if:interface/ip:ipv6
[ni:bind-ni-name = current()/../ni:name]/if:name]" [ni:bind-ni-name = current()/../ni:name]/if:name]"
] ]
} }
} }
], ],
3.4. Network Instance Instantiation 3.4. Network Instance Instantiation
Network instances may be controlled by clients using existing list Network instances may be controlled by clients using existing list
operations. When a list entry is created, a new instance is operations. When a list entry is created, a new instance is
instantiated. The models mounted under an NI root are expected to be instantiated. The models mounted under an NI root are expected to be
dependent on the server implementation. When a list entry is dependent on the server implementation. When a list entry is
deleted, an existing network instance is destroyed. For more deleted, an existing network instance is destroyed. For more
information, see [RFC7950] Section 7.8.6. information, see Section 7.8.6 of [RFC7950].
Once instantiated, host network device resources can be associated Once instantiated, host network device resources can be associated
with the new NI. As previously mentioned, this document augments with the new NI. As previously mentioned, this document augments
ietf-interfaces with the bind-ni-name leaf to support such ietf-interfaces with the bind-ni-name leaf to support such
associations for interfaces. When a bind-ni-name is set to a valid associations for interfaces. When a bind-ni-name is set to a valid
NI name, an implementation MUST take whatever steps are internally NI name, an implementation MUST take whatever steps are internally
necessary to assign the interface to the NI or provide an error necessary to assign the interface to the NI or provide an error
message (defined below) with an indication of why the assignment message (defined below) with an indication of why the assignment
failed. It is possible for the assignment to fail while processing failed. It is possible for the assignment to fail while processing
the set operation, or after asynchronous processing. Error the set operation or after asynchronous processing. Error
notification in the latter case is supported via a notification. notification in the latter case is supported via a notification.
4. Security Considerations 4. Security Considerations
The YANG modules specified in this document define a schema for data The YANG modules specified in this document define a schema for data
that is designed to be accessed via network management protocols such that is designed to be accessed via network management protocols such
as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer
is the secure transport layer, and the mandatory-to-implement secure is the secure transport layer, and the mandatory-to-implement secure
transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer
is HTTPS, and the mandatory-to-implement secure transport is TLS is HTTPS, and the mandatory-to-implement secure transport is TLS
[RFC5246]. [RFC8446].
The NETCONF access control model [RFC6536] provides the means to The Network Configuration Access Control Model (NACM) [RFC8341]
restrict access for particular NETCONF or RESTCONF users to a provides the means to restrict access for particular NETCONF or
preconfigured subset of all available NETCONF or RESTCONF protocol RESTCONF users to a preconfigured subset of all available NETCONF or
operations and content. RESTCONF protocol operations and content.
There are two different sets of security considerations to consider There are two different sets of security considerations to consider
in the context of this document. One set is security related to in the context of this document. One set is security related to
information contained within mounted modules. The security information contained within mounted modules. The security
considerations for mounted modules are not substantively changed considerations for mounted modules are not substantively changed
based on the information being accessible within the context of an based on the information being accessible within the context of an
NI. For example, when considering the modules defined in NI. For example, when considering the modules defined in [RFC8349],
[I-D.ietf-netmod-rfc8022bis], the security considerations identified the security considerations identified in that document are equally
in that document are equally applicable, whether those modules are applicable, whether those modules are accessed at a server's root or
accessed at a server's root or under an NI instance's root node. under an NI instance's root node.
The second area for consideration is information contained in the NI The second area for consideration is information contained in the NI
module itself. NI information represents network configuration and module itself. NI information represents network configuration and
route distribution policy information. As such, the security of this route distribution policy information. As such, the security of this
information is important, but it is fundamentally no different than information is important, but it is fundamentally no different than
any other interface or routing configuration information that has any other interface or routing configuration information that has
already been covered in [I-D.ietf-netmod-rfc7223bis] and already been covered in [RFC8343] and [RFC8349].
[I-D.ietf-netmod-rfc8022bis].
The vulnerable "config true" parameters and subtrees are the The vulnerable "config true" parameters and subtrees are the
following: following:
/network-instances/network-instance: This list specifies the network /network-instances/network-instance: This list specifies the network
instances and the related control plane protocols configured on a instances and the related control plane protocols configured on a
device. device.
/if:interfaces/if:interface/*/bind-network-instance-name: This leaf /if:interfaces/if:interface/*/bind-network-instance-name: This leaf
indicates the NI instance to which an interface is assigned. indicates the NI instance to which an interface is assigned.
Unauthorized access to any of these lists can adversely affect the Unauthorized access to any of these lists can adversely affect the
routing subsystem of both the local device and the network. This may routing subsystem of both the local device and the network. This may
lead to network malfunctions, delivery of packets to inappropriate lead to network malfunctions, delivery of packets to inappropriate
destinations and other problems. destinations, and other problems.
5. IANA Considerations 5. 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
requested to be made.
URI: urn:ietf:params:xml:ns:yang:ietf-network-instance URI: urn:ietf:params:xml:ns:yang:ietf-network-instance
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-network-instance name: ietf-network-instance
namespace: urn:ietf:params:xml:ns:yang:ietf-network-instance namespace: urn:ietf:params:xml:ns:yang:ietf-network-instance
prefix: ni prefix: ni
reference: RFC XXXX reference: RFC 8529
6. Network Instance Model 6. Network Instance Model
The structure of the model defined in this document is described by The structure of the model defined in this document is described by
the YANG module below. the YANG module below.
<CODE BEGINS> file "ietf-network-instance@2018-03-20.yang" <CODE BEGINS> file "ietf-network-instance@2019-01-21.yang"
module ietf-network-instance { module ietf-network-instance {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-network-instance"; namespace "urn:ietf:params:xml:ns:yang:ietf-network-instance";
prefix ni; prefix ni;
// import some basic types // import some basic types
import ietf-interfaces { import ietf-interfaces {
prefix if; prefix if;
reference "draft-ietf-netmod-rfc7223bis: A YANG Data Model reference
for Interface Management"; "RFC 8343: A YANG Data Model for Interface Management";
} }
import ietf-ip { import ietf-ip {
prefix ip; prefix ip;
reference "draft-ietf-netmod-rfc7277bis: A YANG Data Model reference
for IP Management"; "RFC 8344: A YANG Data Model for IP Management";
} }
import ietf-yang-schema-mount { import ietf-yang-schema-mount {
prefix yangmnt; prefix yangmnt;
reference "draft-ietf-netmod-schema-mount: YANG Schema Mount"; reference
// RFC Ed.: Please replace this draft name with the "RFC 8528: YANG Schema Mount";
// corresponding RFC number
} }
organization organization
"IETF Routing Area (rtgwg) Working Group"; "IETF Routing Area (rtgwg) Working Group";
contact contact
"WG Web: <http://tools.ietf.org/wg/rtgwg/> "WG Web: <https://datatracker.ietf.org/wg/rtgwg>
WG List: <mailto:rtgwg@ietf.org> WG List: <mailto:rtgwg@ietf.org>
Author: Lou Berger Author: Lou Berger
<mailto:lberger@labn.net> <mailto:lberger@labn.net>
Author: Christan Hopps Author: Christian Hopps
<mailto:chopps@chopps.org> <mailto:chopps@chopps.org>
Author: Acee Lindem Author: Acee Lindem
<mailto:acee@cisco.com> <mailto:acee@cisco.com>
Author: Dean Bogdanovic Author: Dean Bogdanovic
<mailto:ivandean@gmail.com>"; <mailto:ivandean@gmail.com>";
description description
"This module is used to support multiple network instances "This module is used to support multiple network instances
within a single physical or virtual device. Network within a single physical or virtual device. Network
instances are commonly known as VRFs (virtual routing instances are commonly known as VRFs (VPN Routing and
and forwarding) and VSIs (virtual switching instances). Forwarding) and VSIs (Virtual Switching Instances).
Copyright (c) 2017 IETF Trust and the persons The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
identified as authors of the code. All rights reserved. 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
are to be interpreted as described in BCP 14 (RFC 2119)
(RFC 8174) when, and only when, they appear in all capitals,
as shown here.
Copyright (c) 2019 IETF Trust and the persons identified as
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 without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License to the license terms contained in, the Simplified BSD
set forth in Section 4.c of the IETF Trust's Legal Provisions License set forth in Section 4.c of the IETF Trust's Legal
Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see This version of this YANG module is part of RFC 8529; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
// RFC Ed.: replace XXXX with actual RFC number and remove revision 2019-01-21 {
// this note
// RFC Ed.: please update TBD
revision 2018-03-20 {
description description
"Initial revision."; "Initial revision.";
reference "RFC TBD"; reference
"RFC 8529";
} }
// top level device definition statements // top-level device definition statements
container network-instances { container network-instances {
description description
"Network instances each of which consists of a "Network instances, each of which consists of
VRFs (virtual routing and forwarding) and/or VRFs and/or VSIs.";
VSIs (virtual switching instances)."; reference
reference "draft-ietf-rtgwg-rfc8022bis - A YANG Data Model "RFC 8349: A YANG Data Model for Routing Management";
for Routing Management";
list network-instance { list network-instance {
key "name"; key "name";
description description
"List of network-instances."; "List of network instances.";
leaf name { leaf name {
type string; type string;
mandatory true; mandatory true;
description description
"device scoped identifier for the network "device-scoped identifier for the network
instance."; instance.";
} }
leaf enabled { leaf enabled {
type boolean; type boolean;
default "true"; default "true";
description description
"Flag indicating whether or not the network "Flag indicating whether or not the network
instance is enabled."; instance is enabled.";
} }
leaf description { leaf description {
type string; type string;
description description
"Description of the network instance "Description of the network instance
and its intended purpose."; and its intended purpose.";
} }
choice ni-type { choice ni-type {
description description
"This node serves as an anchor point for different types "This node serves as an anchor point for different types
of network instances. Each 'case' is expected to of network instances. Each 'case' is expected to
differ in terms of the information needed in the differ in terms of the information needed in the
parent/core to support the NI, and may differ in their parent/core to support the NI and may differ in their
mounted schema definition. When the mounted schema is mounted-schema definition. When the mounted schema is
not expected to be the same for a specific type of NI not expected to be the same for a specific type of NI,
a mount point should be defined."; a mount point should be defined.";
} }
choice root-type { choice root-type {
mandatory true; mandatory true;
description description
"Well known mount points."; "Well-known mount points.";
container vrf-root { container vrf-root {
description description
"Container for mount point."; "Container for mount point.";
yangmnt:mount-point "vrf-root" { yangmnt:mount-point "vrf-root" {
description description
"Root for L3VPN type models. This will typically "Root for L3VPN-type models. This will typically
not be an inline type mount point."; not be an inline-type mount point.";
} }
} }
container vsi-root { container vsi-root {
description description
"Container for mount point."; "Container for mount point.";
yangmnt:mount-point "vsi-root" { yangmnt:mount-point "vsi-root" {
description description
"Root for L2VPN type models. This will typically "Root for L2VPN-type models. This will typically
not be an inline type mount point."; not be an inline-type mount point.";
} }
} }
container vv-root { container vv-root {
description description
"Container for mount point."; "Container for mount point.";
yangmnt:mount-point "vv-root" { yangmnt:mount-point "vv-root" {
description description
"Root models that support both L2VPN type bridging "Root models that support both L2VPN-type bridging
and L3VPN type routing. This will typically and L3VPN-type routing. This will typically
not be an inline type mount point."; not be an inline-type mount point.";
} }
} }
} }
} }
} }
// augment statements // augment statements
augment "/if:interfaces/if:interface" { augment "/if:interfaces/if:interface" {
description description
"Add a node for the identification of the network "Add a node for the identification of the network
instance associated with the information configured instance associated with the information configured
on a interface. on a interface.
Note that a standard error will be returned if the Note that a standard error will be returned if the
identified leafref isn't present. If an interfaces cannot identified leafref isn't present. If an interface cannot
be assigned for any other reason, the operation SHALL fail be assigned for any other reason, the operation SHALL fail
with an error-tag of 'operation-failed' and an with an error-tag of 'operation-failed' and an
error-app-tag of 'ni-assignment-failed'. A meaningful error-app-tag of 'ni-assignment-failed'. A meaningful
error-info that indicates the source of the assignment error-info that indicates the source of the assignment
failure SHOULD also be provided."; failure SHOULD also be provided.";
leaf bind-ni-name { leaf bind-ni-name {
type leafref { type leafref {
path "/network-instances/network-instance/name"; path "/network-instances/network-instance/name";
} }
description description
"Network Instance to which an interface is bound."; "Network instance to which an interface is bound.";
} }
} }
augment "/if:interfaces/if:interface/ip:ipv4" { augment "/if:interfaces/if:interface/ip:ipv4" {
description description
"Add a node for the identification of the network "Add a node for the identification of the network
instance associated with the information configured instance associated with the information configured
on an IPv4 interface. on an IPv4 interface.
Note that a standard error will be returned if the Note that a standard error will be returned if the
identified leafref isn't present. If an interfaces cannot identified leafref isn't present. If an interface cannot
be assigned for any other reason, the operation SHALL fail be assigned for any other reason, the operation SHALL fail
with an error-tag of 'operation-failed' and an with an error-tag of 'operation-failed' and an
error-app-tag of 'ni-assignment-failed'. A meaningful error-app-tag of 'ni-assignment-failed'. A meaningful
error-info that indicates the source of the assignment error-info that indicates the source of the assignment
failure SHOULD also be provided."; failure SHOULD also be provided.";
leaf bind-ni-name { leaf bind-ni-name {
type leafref { type leafref {
path "/network-instances/network-instance/name"; path "/network-instances/network-instance/name";
} }
description description
"Network Instance to which IPv4 interface is bound."; "Network instance to which IPv4 interface is bound.";
} }
} }
augment "/if:interfaces/if:interface/ip:ipv6" { augment "/if:interfaces/if:interface/ip:ipv6" {
description description
"Add a node for the identification of the network "Add a node for the identification of the network
instance associated with the information configured instance associated with the information configured
on an IPv6 interface. on an IPv6 interface.
Note that a standard error will be returned if the Note that a standard error will be returned if the
identified leafref isn't present. If an interfaces cannot identified leafref isn't present. If an interface cannot
be assigned for any other reason, the operation SHALL fail be assigned for any other reason, the operation SHALL fail
with an error-tag of 'operation-failed' and an with an error-tag of 'operation-failed' and an
error-app-tag of 'ni-assignment-failed'. A meaningful error-app-tag of 'ni-assignment-failed'. A meaningful
error-info that indicates the source of the assignment error-info that indicates the source of the assignment
failure SHOULD also be provided."; failure SHOULD also be provided.";
leaf bind-ni-name { leaf bind-ni-name {
type leafref { type leafref {
path "/network-instances/network-instance/name"; path "/network-instances/network-instance/name";
} }
description description
"Network Instance to which IPv6 interface is bound."; "Network instance to which IPv6 interface is bound.";
} }
} }
// notification statements // notification statements
notification bind-ni-name-failed { notification bind-ni-name-failed {
description description
"Indicates an error in the association of an interface to an "Indicates an error in the association of an interface to an
NI. Only generated after success is initially returned when NI. Only generated after success is initially returned when
bind-ni-name is set. bind-ni-name is set.
Note: some errors may need to be reported for multiple Note: Some errors may need to be reported for multiple
associations, e.g., a single error may need to be reported associations, e.g., a single error may need to be reported
for an IPv4 and an IPv6 bind-ni-name. for an IPv4 and an IPv6 bind-ni-name.
At least one container with a bind-ni-name leaf MUST be At least one container with a bind-ni-name leaf MUST be
included in this notification."; included in this notification.";
leaf name { leaf name {
type leafref { type leafref {
path "/if:interfaces/if:interface/if:name"; path "/if:interfaces/if:interface/if:name";
} }
mandatory true; mandatory true;
description description
"Contains the interface name associated with the "Contains the interface name associated with the
failure."; failure.";
} }
container interface { container interface {
description description
"Generic interface type."; "Generic interface type.";
leaf bind-ni-name { leaf bind-ni-name {
type leafref { type leafref {
path "/if:interfaces/if:interface/ni:bind-ni-name"; path "/if:interfaces/if:interface"
+ "/ni:bind-ni-name";
} }
description description
"Contains the bind-ni-name associated with the "Contains the bind-ni-name associated with the
failure."; failure.";
} }
} }
container ipv4 { container ipv4 {
description description
"IPv4 interface type."; "IPv4 interface type.";
leaf bind-ni-name { leaf bind-ni-name {
type leafref { type leafref {
path "/if:interfaces/if:interface" path "/if:interfaces/if:interface/ip:ipv4/ni:bind-ni-name";
+ "/ip:ipv4/ni:bind-ni-name";
} }
description description
"Contains the bind-ni-name associated with the "Contains the bind-ni-name associated with the
failure."; failure.";
} }
} }
container ipv6 { container ipv6 {
description description
"IPv6 interface type."; "IPv6 interface type.";
leaf bind-ni-name { leaf bind-ni-name {
type leafref { type leafref {
path "/if:interfaces/if:interface" path "/if:interfaces/if:interface/ip:ipv6"
+ "/ip:ipv6/ni:bind-ni-name"; + "/ni:bind-ni-name";
} }
description description
"Contains the bind-ni-name associated with the "Contains the bind-ni-name associated with the
failure."; failure.";
} }
} }
leaf error-info { leaf error-info {
type string; type string;
description description
"Optionally, indicates the source of the assignment "Optionally, indicates the source of the assignment
failure."; failure.";
} }
} }
} }
<CODE ENDS> <CODE ENDS>
7. References 7. References
7.1. Normative References 7.1. Normative References
[I-D.ietf-netmod-revised-datastores]
Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "Network Management Datastore
Architecture", draft-ietf-netmod-revised-datastores-10
(work in progress), January 2018.
[I-D.ietf-netmod-rfc7223bis]
Bjorklund, M., "A YANG Data Model for Interface
Management", draft-ietf-netmod-rfc7223bis-03 (work in
progress), January 2018.
[I-D.ietf-netmod-rfc7277bis]
Bjorklund, M., "A YANG Data Model for IP Management",
draft-ietf-netmod-rfc7277bis-03 (work in progress),
January 2018.
[I-D.ietf-netmod-schema-mount]
Bjorklund, M. and L. Lhotka, "YANG Schema Mount", draft-
ietf-netmod-schema-mount-08 (work in progress), October
2017.
[I-D.ietf-netmod-yang-tree-diagrams]
Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft-
ietf-netmod-yang-tree-diagrams-06 (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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://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,
<https://www.rfc-editor.org/info/rfc3688>. <https://www.rfc-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-editor.org/info/rfc6020>. <https://www.rfc-editor.org/info/rfc6020>.
[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,
<https://www.rfc-editor.org/info/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc6242>. <https://www.rfc-editor.org/info/rfc6242>.
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
Protocol (NETCONF) Access Control Model", RFC 6536,
DOI 10.17487/RFC6536, March 2012,
<https://www.rfc-editor.org/info/rfc6536>.
[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,
<https://www.rfc-editor.org/info/rfc8040>. <https://www.rfc-editor.org/info/rfc8040>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
7.2. Informative References [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>.
[I-D.ietf-bess-l2vpn-yang] [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Shah, H., Brissette, P., Chen, I., Hussain, I., Wen, B., Access Control Model", STD 91, RFC 8341,
and K. Tiruveedhula, "YANG Data Model for MPLS-based DOI 10.17487/RFC8341, March 2018,
L2VPN", draft-ietf-bess-l2vpn-yang-08 (work in progress), <https://www.rfc-editor.org/info/rfc8341>.
February 2018.
[I-D.ietf-bess-l3vpn-yang] [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
Jain, D., Patel, K., Brissette, P., Li, Z., Zhuang, S., and R. Wilton, "Network Management Datastore Architecture
Liu, X., Haas, J., Esale, S., and B. Wen, "Yang Data Model (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
for BGP/MPLS L3 VPNs", draft-ietf-bess-l3vpn-yang-02 (work <https://www.rfc-editor.org/info/rfc8342>.
in progress), October 2017.
[I-D.ietf-netmod-rfc8022bis] [RFC8343] Bjorklund, M., "A YANG Data Model for Interface
Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for Management", RFC 8343, DOI 10.17487/RFC8343, March 2018,
Routing Management (NMDA Version)", draft-ietf-netmod- <https://www.rfc-editor.org/info/rfc8343>.
rfc8022bis-11 (work in progress), January 2018.
[I-D.ietf-ospf-yang] [RFC8344] Bjorklund, M., "A YANG Data Model for IP Management",
Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem, RFC 8344, DOI 10.17487/RFC8344, March 2018,
"Yang Data Model for OSPF Protocol", draft-ietf-ospf- <https://www.rfc-editor.org/info/rfc8344>.
yang-10 (work in progress), March 2018.
[I-D.ietf-rtgwg-device-model] [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Lindem, A., Berger, L., Bogdanovic, D., and C. Hopps, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
"Network Device YANG Logical Organization", draft-ietf- <https://www.rfc-editor.org/info/rfc8446>.
rtgwg-device-model-02 (work in progress), March 2017.
[I-D.ietf-rtgwg-lne-model] [RFC8528] Bjorklund, M. and L. Lhotka, "YANG Schema Mount",
Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. RFC 8528, DOI 10.17487/RFC8528, March 2019,
Liu, "YANG Model for Logical Network Elements", draft- <https://www.rfc-editor.org/info/rfc8528>.
ietf-rtgwg-lne-model-09 (work in progress), March 2018.
7.2. Informative References
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual
Private Network (VPN) Terminology", RFC 4026, Private Network (VPN) Terminology", RFC 4026,
DOI 10.17487/RFC4026, March 2005, DOI 10.17487/RFC4026, March 2005,
<https://www.rfc-editor.org/info/rfc4026>. <https://www.rfc-editor.org/info/rfc4026>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <https://www.rfc-editor.org/info/rfc4364>. 2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer [RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer
2 Virtual Private Networks (L2VPNs)", RFC 4664, 2 Virtual Private Networks (L2VPNs)", RFC 4664,
DOI 10.17487/RFC4664, September 2006, DOI 10.17487/RFC4664, September 2006,
<https://www.rfc-editor.org/info/rfc4664>. <https://www.rfc-editor.org/info/rfc4664>.
[RFC7223] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 7223, DOI 10.17487/RFC7223, May 2014,
<https://www.rfc-editor.org/info/rfc7223>.
[RFC7277] Bjorklund, M., "A YANG Data Model for IP Management",
RFC 7277, DOI 10.17487/RFC7277, June 2014,
<https://www.rfc-editor.org/info/rfc7277>.
[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,
<https://www.rfc-editor.org/info/rfc7950>. <https://www.rfc-editor.org/info/rfc7950>.
[RFC8022] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for
Management", RFC 8022, DOI 10.17487/RFC8022, November Routing Management (NMDA Version)", RFC 8349,
2016, <https://www.rfc-editor.org/info/rfc8022>. DOI 10.17487/RFC8349, March 2018,
<https://www.rfc-editor.org/info/rfc8349>.
Appendix A. Acknowledgments [RFC8530] Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X.
Liu, "YANG Model for Logical Network Elements", RFC 8530,
DOI 10.17487/RFC8530, March 2019.
The Routing Area Yang Architecture design team members included Acee [YANG-L2VPN]
Lindem, Anees Shaikh, Christian Hopps, Dean Bogdanovic, Lou Berger, Shah, H., Brissette, P., Chen, I., Hussain, I., Wen, B.,
Qin Wu, Rob Shakir, Stephane Litkowski, and Yan Gang. Useful review and K. Tiruveedhula, "YANG Data Model for MPLS-based
comments were also received by Martin Bjorklund and John Scudder. L2VPN", Work in Progress, draft-ietf-bess-l2vpn-yang-09,
October 2018.
This document was motivated by, and derived from, [YANG-L3VPN]
[I-D.ietf-rtgwg-device-model]. Jain, D., Patel, K., Brissette, P., Li, Z., Zhuang, S.,
Liu, X., Haas, J., Esale, S., and B. Wen, "Yang Data Model
for BGP/MPLS L3 VPNs", Work in Progress, draft-ietf-bess-
l3vpn-yang-04, October 2018.
Thanks for AD and IETF last call comments from Alia Atlas, Liang Xia, [YANG-NETWORK]
Benoit Claise, and Adam Roach. Lindem, A., Berger, L., Bogdanovic, D., and C. Hopps,
"Network Device YANG Logical Organization", Work in
Progress, draft-ietf-rtgwg-device-model-02, March 2017.
The RFC text was produced using Marshall Rose's xml2rfc tool. [YANG-OSPF]
Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem,
"YANG Data Model for OSPF Protocol", Work in Progress,
draft-ietf-ospf-yang-21, January 2019.
Appendix B. Example NI usage Appendix A. Example NI Usage
The following subsections provide example uses of NIs. The following subsections provide example uses of NIs.
B.1. Configuration Data A.1. Configuration Data
The following shows an example where two customer specific network The following shows an example where two customer-specific network
instances are configured: instances are configured:
{ {
"ietf-network-instance:network-instances": { "ietf-network-instance:network-instances": {
"network-instance": [ "network-instance": [
{ {
"name": "vrf-red", "name": "vrf-red",
"vrf-root": { "vrf-root": {
"ietf-routing:routing": { "ietf-routing:routing": {
"router-id": "192.0.2.1", "router-id": "192.0.2.1",
skipping to change at page 25, line 28 skipping to change at page 26, line 40
} }
] ]
} }
} }
} }
} }
] ]
}, },
"ietf-interfaces:interfaces": { "ietf-interfaces:interfaces": {
"interfaces": { "interface": [
"interface": [
{
"name": "eth0",
"ip:ipv4": {
"address": [
{
"ip": "192.0.2.10",
"prefix-length": 24,
}
]
},
"ip:ipv6": {
"address": [
{
"ip": "2001:db8:0:2::10",
"prefix-length": 64,
}
]
}
},
{
"name": "eth1",
"ip:ipv4": {
"address": [
{
"ip": "192.0.2.11",
"prefix-length": 24,
}
]
},
"ip:ipv6": {
"address": [
{
"ip": "2001:db8:0:2::11",
"prefix-length": 64,
}
]
},
"ni:bind-network-instance-name": "vrf-red"
},
{
"name": "eth2",
"ip:ipv4": {
"address": [
{
"ip": "192.0.2.11",
"prefix-length": 24,
}
]
},
"ip:ipv6": {
"address": [
{
"ip": "2001:db8:0:2::11",
"prefix-length": 64,
}
]
},
"ni:bind-network-instance-name": "vrf-blue"
}
]
}
},
"ietf-system:system": {
"authentication": {
"user": [
{
"name": "john",
"password": "$0$password"
}
]
}
}
}
B.2. State Data - Non-NMDA Version
The following shows state data for the configuration example above
based on [RFC7223], [RFC7277], and [RFC8022].
{
"ietf-network-instance:network-instances": {
"network-instance": [
{ {
"name": "vrf-red", "name": "eth0",
"vrf-root": { "type": "iana-if-type:ethernetCsmacd",
"ietf-yang-library:modules-state": { "ietf-ip:ipv4": {
"module-set-id": "123e4567-e89b-12d3-a456-426655440000", "address": [
"module": [ {
{ "ip": "192.0.2.10",
"name": "ietf-yang-library", "prefix-length": 24
"revision": "2016-06-21",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-yang-library",
"conformance-type": "implement"
},
{
"name": "ietf-ospf",
"revision": "2018-03-03",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-ospf",
"conformance-type": "implement"
},
{
"name": "ietf-routing",
"revision": "2018-03-13",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-routing",
"conformance-type": "implement"
}
]
},
"ietf-routing:routing-state": {
"router-id": "192.0.2.1",
"control-plane-protocols": {
"control-plane-protocol": [
{
"type": "ietf-routing:ospf",
"name": "1",
"ietf-ospf:ospf": {
"af": "ipv4",
"areas": {
"area": [
{
"area-id": "203.0.113.1",
"interfaces": {
"interface": [
{
"name": "eth1",
"cost": 10
}
]
}
}
]
}
}
}
]
} }
} ]
},
"ietf-ip:ipv6": {
"address": [
{
"ip": "2001:db8:0:2::10",
"prefix-length": 64
}
]
} }
}, },
{ {
"name": "vrf-blue", "name": "eth1",
"vrf-root": { "type": "iana-if-type:ethernetCsmacd",
"ietf-yang-library:modules-state": { "ietf-ip:ipv4": {
"module-set-id": "123e4567-e89b-12d3-a456-426655440000", "address": [
"module": [ {
{ "ip": "192.0.2.11",
"name": "ietf-yang-library", "prefix-length": 24
"revision": "2016-06-21",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-yang-library",
"conformance-type": "implement"
},
{
"name": "ietf-ospf",
"revision": "2018-03-03",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-ospf",
"conformance-type": "implement"
},
{
"name": "ietf-routing",
"revision": "2018-03-13",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-routing",
"conformance-type": "implement"
}
]
},
"ietf-routing:routing-state": {
"router-id": "192.0.2.2",
"control-plane-protocols": {
"control-plane-protocol": [
{
"type": "ietf-routing:ospf",
"name": "1",
"ietf-ospf:ospf": {
"af": "ipv4",
"areas": {
"area": [
{
"area-id": "203.0.113.1",
"interfaces": {
"interface": [
{
"name": "eth2",
"cost": 10
}
]
}
}
]
}
}
}
]
} }
} ]
}
}
]
},
"ietf-interfaces:interfaces-state": {
"interfaces": {
"interface": [
{
"name": "eth0",
"type": "iana-if-type:ethernetCsmacd",
"oper-status": "up",
"phys-address": "00:01:02:A1:B1:C0",
"statistics": {
"discontinuity-time": "2017-06-26T12:34:56-05:00"
},
"ip:ipv4": {
"address": [
{
"ip": "192.0.2.10",
"prefix-length": 24,
}
]
}
"ip:ipv6": {
"address": [
{
"ip": "2001:db8:0:2::10",
"prefix-length": 64,
}
]
}
}, },
{ "ietf-ip:ipv6": {
"name": "eth1", "address": [
"type": "iana-if-type:ethernetCsmacd", {
"oper-status": "up", "ip": "2001:db8:0:2::11",
"phys-address": "00:01:02:A1:B1:C1", "prefix-length": 64
"statistics": { }
"discontinuity-time": "2017-06-26T12:34:56-05:00" ]
},
"ip:ipv4": {
"address": [
{
"ip": "192.0.2.11",
"prefix-length": 24,
}
]
}
"ip:ipv6": {
"address": [
{
"ip": "2001:db8:0:2::11",
"prefix-length": 64,
}
]
}
}, },
{ "ietf-network-instance:bind-network-instance-name": "vrf-red"
"name": "eth2",
"type": "iana-if-type:ethernetCsmacd",
"oper-status": "up",
"phys-address": "00:01:02:A1:B1:C2",
"statistics": {
"discontinuity-time": "2017-06-26T12:34:56-05:00"
},
"ip:ipv4": {
"address": [
{
"ip": "192.0.2.11",
"prefix-length": 24,
}
]
}
"ip:ipv6": {
"address": [
{
"ip": "2001:db8:0:2::11",
"prefix-length": 64,
}
]
}
}
]
}
},
"ietf-system:system-state": {
"platform": {
"os-name": "NetworkOS"
}
}
"ietf-yang-library:modules-state": {
"module-set-id": "123e4567-e89b-12d3-a456-426655440000",
"module": [
{
"name": "iana-if-type",
"revision": "2014-05-08",
"namespace":
"urn:ietf:params:xml:ns:yang:iana-if-type",
"conformance-type": "import"
},
{
"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-network-instance",
"revision": "2018-02-03",
"feature": [
"bind-network-instance-name"
],
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-network-instance",
"conformance-type": "implement"
},
{
"name": "ietf-ospf",
"revision": "2018-03-03",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-ospf",
"conformance-type": "implement"
},
{
"name": "ietf-routing",
"revision": "2018-03-13",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-routing",
"conformance-type": "implement"
}, },
{ {
"name": "ietf-system", "name": "eth2",
"revision": "2014-08-06", "type": "iana-if-type:ethernetCsmacd",
"namespace": "ietf-ip:ipv4": {
"urn:ietf:params:xml:ns:yang:ietf-system", "address": [
"conformance-type": "implement" {
"ip": "192.0.2.11",
"prefix-length": 24
}
]
},
"ietf-ip:ipv6": {
"address": [
{
"ip": "2001:db8:0:2::11",
"prefix-length": 64
}
]
}, },
{ "ietf-network-instance:bind-network-instance-name":
"name": "ietf-yang-library", "vrf-blue"
"revision": "2016-06-21",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-yang-library",
"conformance-type": "implement"
},
{
"name": "ietf-yang-schema-mount",
"revision": "2017-05-16",
"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"
} }
] ]
}, },
"ietf-yang-schema-mount:schema-mounts": { "ietf-system:system": {
"mount-point": [ "authentication": {
{ "user": [
"module": "ietf-network-instance", {
"label": "vrf-root", "name": "john",
"shared-schema": { "password": "$0$password"
"parent-reference": [
"/*[namespace-uri() = 'urn:ietf:...:ietf-interfaces']"
]
} }
} ]
] }
} }
} }
B.3. State Data - NMDA Version A.2. State Data - Non-NMDA Version
The following shows state data for the configuration example above The following shows state data for the configuration example above
based on [I-D.ietf-netmod-rfc7223bis], [I-D.ietf-netmod-rfc7277bis], based on [RFC8343], [RFC8344], and [RFC8349].
and [I-D.ietf-netmod-rfc8022bis].
{ {
"ietf-network-instance:network-instances": { "ietf-network-instance:network-instances": {
"network-instance": [ "network-instance": [
{ {
"name": "vrf-red", "name": "vrf-red",
"vrf-root": { "vrf-root": {
"ietf-yang-library:yang-library": { "ietf-yang-library:modules-state": {
"checksum": "41e2ab5dc325f6d86f743e8da3de323f1a61a801", "module-set-id": "123e4567-e89b-12d3-a456-426655440000",
"module-set": [ "module": [
{
"name": "ni-modules",
"module": [
{
"name": "ietf-yang-library",
"revision": "2016-06-21",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-yang-library",
"conformance-type": "implement"
},
{
"name": "ietf-ospf",
"revision": "2018-03-03",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-ospf",
"conformance-type": "implement"
},
{
"name": "ietf-routing",
"revision": "2018-03-13",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-routing",
"conformance-type": "implement"
}
],
"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": "ni-schema", "name": "ietf-yang-library",
"module-set": [ "ni-modules" ] "revision": "2019-01-04",
} "namespace":
], "urn:ietf:params:xml:ns:yang:ietf-yang-library",
"datastore": [ "conformance-type": "implement"
},
{ {
"name": "ietf-datastores:running", "name": "ietf-ospf",
"schema": "ni-schema" "revision": "2019-01-24",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-ospf",
"conformance-type": "implement"
}, },
{ {
"name": "ietf-datastores:operational", "name": "ietf-routing",
"schema": "ni-schema" "revision": "2018-03-13",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-routing",
"conformance-type": "implement"
} }
] ]
}, },
"ietf-routing:routing": { "ietf-routing:routing-state": {
"router-id": "192.0.2.1", "router-id": "192.0.2.1",
"control-plane-protocols": { "control-plane-protocols": {
"control-plane-protocol": [ "control-plane-protocol": [
{ {
"type": "ietf-routing:ospf", "type": "ietf-routing:ospf",
"name": "1", "name": "1",
"ietf-ospf:ospf": { "ietf-ospf:ospf": {
"af": "ipv4", "af": "ipv4",
"areas": { "areas": {
"area": [ "area": [
skipping to change at page 36, line 4 skipping to change at page 29, line 38
} }
] ]
} }
} }
] ]
} }
} }
} }
] ]
} }
} }
} }
}, },
{ {
"name": "vrf-blue", "name": "vrf-blue",
"vrf-root": { "vrf-root": {
"ietf-yang-library:yang-library": { "ietf-yang-library:modules-state": {
"checksum": "41e2ab5dc325f6d86f743e8da3de323f1a61a801", "module-set-id": "123e4567-e89b-12d3-a456-426655440000",
"module-set": [ "module": [
{
"name": "ni-modules",
"module": [
{
"name": "ietf-yang-library",
"revision": "2016-06-21",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-yang-library",
"conformance-type": "implement"
},
{
"name": "ietf-ospf",
"revision": "2018-03-03",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-ospf",
"conformance-type": "implement"
},
{
"name": "ietf-routing",
"revision": "2018-03-13",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-routing",
"conformance-type": "implement"
}
],
"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": "ni-schema", "name": "ietf-yang-library",
"module-set": [ "ni-modules" ] "revision": "2019-01-04",
} "namespace":
], "urn:ietf:params:xml:ns:yang:ietf-yang-library",
"datastore": [
"conformance-type": "implement"
},
{ {
"name": "ietf-datastores:running", "name": "ietf-ospf",
"schema": "ni-schema" "revision": "2019-01-24",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-ospf",
"conformance-type": "implement"
}, },
{ {
"name": "ietf-datastores:operational", "name": "ietf-routing",
"schema": "ni-schema" "revision": "2018-03-13",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-routing",
"conformance-type": "implement"
} }
] ]
}, },
"ietf-routing:routing": { "ietf-routing:routing-state": {
"router-id": "192.0.2.2", "router-id": "192.0.2.2",
"control-plane-protocols": { "control-plane-protocols": {
"control-plane-protocol": [ "control-plane-protocol": [
{ {
"type": "ietf-routing:ospf", "type": "ietf-routing:ospf",
"name": "1", "name": "1",
"ietf-ospf:ospf": { "ietf-ospf:ospf": {
"af": "ipv4", "af": "ipv4",
"areas": { "areas": {
"area": [ "area": [
skipping to change at page 38, line 4 skipping to change at page 30, line 47
"name": "eth2", "name": "eth2",
"cost": 10 "cost": 10
} }
] ]
} }
} }
] ]
} }
} }
} }
] ]
} }
} }
} }
} }
] ]
}, },
"ietf-interfaces:interfaces": { "ietf-interfaces:interfaces-state": {
"interfaces": { "interface": [
"interface": [ {
{ "name": "eth0",
"name": "eth0", "type": "iana-if-type:ethernetCsmacd",
"type": "iana-if-type:ethernetCsmacd", "oper-status": "up",
"oper-status": "up", "phys-address": "00:01:02:A1:B1:C0",
"phys-address": "00:01:02:A1:B1:C0", "statistics": {
"statistics": { "discontinuity-time": "2017-06-26T12:34:56-05:00"
"discontinuity-time": "2017-06-26T12:34:56-05:00"
},
"ip:ipv4": {
"address": [
{
"ip": "192.0.2.10",
"prefix-length": 24,
}
]
}
"ip:ipv6": {
"address": [
{
"ip": "2001:db8:0:2::10",
"prefix-length": 64,
}
]
}
}, },
{ "ietf-ip:ipv4": {
"name": "eth1", "address": [
"type": "iana-if-type:ethernetCsmacd", {
"oper-status": "up", "ip": "192.0.2.10",
"phys-address": "00:01:02:A1:B1:C1", "prefix-length": 24
"statistics": { }
"discontinuity-time": "2017-06-26T12:34:56-05:00" ]
},
"ip:ipv4": {
"address": [
{
"ip": "192.0.2.11",
"prefix-length": 24,
}
]
}
"ip:ipv6": {
"address": [
{
"ip": "2001:db8:0:2::11",
"prefix-length": 64,
}
]
}
}, },
{ "ietf-ip:ipv6": {
"name": "eth2", "address": [
"type": "iana-if-type:ethernetCsmacd", {
"oper-status": "up", "ip": "2001:db8:0:2::10",
"phys-address": "00:01:02:A1:B1:C2", "prefix-length": 64
"statistics": { }
"discontinuity-time": "2017-06-26T12:34:56-05:00" ]
},
"ip:ipv4": {
"address": [
{
"ip": "192.0.2.11",
"prefix-length": 24,
}
]
}
"ip:ipv6": {
"address": [
{
"ip": "2001:db8:0:2::11",
"prefix-length": 64,
}
]
}
} }
] },
} {
"name": "eth1",
"type": "iana-if-type:ethernetCsmacd",
"oper-status": "up",
"phys-address": "00:01:02:A1:B1:C1",
"statistics": {
"discontinuity-time": "2017-06-26T12:34:56-05:00"
},
"ietf-ip:ipv4": {
"address": [
{
"ip": "192.0.2.11",
"prefix-length": 24
}
]
},
"ietf-ip:ipv6": {
"address": [
{
"ip": "2001:db8:0:2::11",
"prefix-length": 64
}
]
}
},
{
"name": "eth2",
"type": "iana-if-type:ethernetCsmacd",
"oper-status": "up",
"phys-address": "00:01:02:A1:B1:C2",
"statistics": {
"discontinuity-time": "2017-06-26T12:34:56-05:00"
},
"ietf-ip:ipv4": {
"address": [
{
"ip": "192.0.2.11",
"prefix-length": 24
}
]
},
"ietf-ip:ipv6": {
"address": [
{
"ip": "2001:db8:0:2::11",
"prefix-length": 64
}
]
}
}
]
}, },
"ietf-system:system-state": { "ietf-system:system-state": {
"platform": { "platform": {
"os-name": "NetworkOS" "os-name": "NetworkOS"
} }
} },
"ietf-yang-library:modules-state": { "ietf-yang-library:modules-state": {
"module-set-id": "123e4567-e89b-12d3-a456-426655440000", "module-set-id": "123e4567-e89b-12d3-a456-426655440000",
"module": [ "module": [
{ {
"name": "iana-if-type", "name": "iana-if-type",
"revision": "2014-05-08", "revision": "2018-07-03",
"namespace": "namespace": "urn:ietf:params:xml:ns:yang:iana-if-type",
"urn:ietf:params:xml:ns:yang:iana-if-type",
"conformance-type": "import" "conformance-type": "import"
}, },
{ {
"name": "ietf-inet-types", "name": "ietf-inet-types",
"revision": "2013-07-15", "revision": "2013-07-15",
"namespace": "namespace": "urn:ietf:params:xml:ns:yang:ietf-inet-types",
"urn:ietf:params:xml:ns:yang:ietf-inet-types",
"conformance-type": "import" "conformance-type": "import"
}, },
{ {
"name": "ietf-interfaces", "name": "ietf-interfaces",
"revision": "2018-01-09", "revision": "2018-02-20",
"feature": [ "feature": [
"arbitrary-names", "arbitrary-names",
"pre-provisioning" "pre-provisioning"
], ],
"namespace": "namespace": "urn:ietf:params:xml:ns:yang:ietf-interfaces",
"urn:ietf:params:xml:ns:yang:ietf-interfaces",
"conformance-type": "implement" "conformance-type": "implement"
}, },
{ {
"name": "ietf-ip", "name": "ietf-ip",
"revision": "2018-01-09", "revision": "2018-01-09",
"namespace": "namespace": "urn:ietf:params:xml:ns:yang:ietf-ip",
"urn:ietf:params:xml:ns:yang:ietf-ip",
"conformance-type": "implement" "conformance-type": "implement"
}, },
{ {
"name": "ietf-network-instance", "name": "ietf-network-instance",
"revision": "2018-02-03", "revision": "2018-02-03",
"feature": [ "feature": [
"bind-network-instance-name" "bind-network-instance-name"
], ],
"namespace": "namespace":
"urn:ietf:params:xml:ns:yang:ietf-network-instance", "urn:ietf:params:xml:ns:yang:ietf-network-instance",
"conformance-type": "implement" "conformance-type": "implement"
}, },
{ {
"name": "ietf-ospf", "name": "ietf-ospf",
"revision": "2017-10-30", "revision": "2019-01-24",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-ospf", "namespace": "urn:ietf:params:xml:ns:yang:ietf-ospf",
"conformance-type": "implement" "conformance-type": "implement"
}, },
{ {
"name": "ietf-routing", "name": "ietf-routing",
"revision": "2018-01-25", "revision": "2018-03-13",
"namespace": "namespace": "urn:ietf:params:xml:ns:yang:ietf-routing",
"urn:ietf:params:xml:ns:yang:ietf-routing",
"conformance-type": "implement" "conformance-type": "implement"
}, },
{ {
"name": "ietf-system", "name": "ietf-system",
"revision": "2014-08-06", "revision": "2014-08-06",
"namespace": "namespace": "urn:ietf:params:xml:ns:yang:ietf-system",
"urn:ietf:params:xml:ns:yang:ietf-system",
"conformance-type": "implement" "conformance-type": "implement"
}, },
{ {
"name": "ietf-yang-library", "name": "ietf-yang-library",
"revision": "2016-06-21", "revision": "2019-01-04",
"namespace": "namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-library",
"urn:ietf:params:xml:ns:yang:ietf-yang-library",
"conformance-type": "implement" "conformance-type": "implement"
}, },
{ {
"name": "ietf-yang-schema-mount", "name": "ietf-yang-schema-mount",
"revision": "2017-05-16", "revision": "2019-01-14",
"namespace": "namespace":
"urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount", "urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount",
"conformance-type": "implement" "conformance-type": "implement"
}, },
{ {
"name": "ietf-yang-types", "name": "ietf-yang-types",
"revision": "2013-07-15", "revision": "2013-07-15",
"namespace": "namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-types",
"urn:ietf:params:xml:ns:yang:ietf-yang-types",
"conformance-type": "import" "conformance-type": "import"
} }
] ]
}, },
"ietf-yang-schema-mount:schema-mounts": { "ietf-yang-schema-mount:schema-mounts": {
"mount-point": [ "mount-point": [
{ {
"module": "ietf-network-instance", "module": "ietf-network-instance",
"label": "vrf-root", "label": "vrf-root",
"shared-schema": { "shared-schema": {
"parent-reference": [ "parent-reference": [
"/*[namespace-uri() = 'urn:ietf:...:ietf-interfaces']" "/*[namespace-uri() = 'urn:ietf:...:ietf-interfaces']"
] ]
} }
} }
] ]
} }
} }
A.3. State Data - NMDA Version
The following shows state data for the configuration example above
based on [RFC8343], [RFC8344], and [RFC8349].
{
"ietf-network-instance:network-instances": {
"network-instance": [
{
"name": "vrf-red",
"vrf-root": {
"ietf-yang-library:yang-library": {
"content-id": "41e2ab5dc325f6d86f743e8da3de323f1a61a801",
"module-set": [
{
"name": "ni-modules",
"module": [
{
"name": "ietf-yang-library",
"revision": "2019-01-04",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-yang-library"
},
{
"name": "ietf-ospf",
"revision": "2019-01-24",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-ospf"
},
{
"name": "ietf-routing",
"revision": "2018-03-13",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-routing"
}
],
"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": "ni-schema",
"module-set": [ "ni-modules" ]
}
],
"datastore": [
{
"name": "ietf-datastores:running",
"schema": "ni-schema"
},
{
"name": "ietf-datastores:operational",
"schema": "ni-schema"
}
]
},
"ietf-routing:routing": {
"router-id": "192.0.2.1",
"control-plane-protocols": {
"control-plane-protocol": [
{
"type": "ietf-routing:ospf",
"name": "1",
"ietf-ospf:ospf": {
"af": "ipv4",
"areas": {
"area": [
{
"area-id": "203.0.113.1",
"interfaces": {
"interface": [
{
"name": "eth1",
"cost": 10
}
]
}
}
]
}
}
}
]
}
}
}
},
{
"name": "vrf-blue",
"vrf-root": {
"ietf-yang-library:yang-library": {
"checksum": "41e2ab5dc325f6d86f743e8da3de323f1a61a801",
"module-set": [
{
"name": "ni-modules",
"module": [
{
"name": "ietf-yang-library",
"revision": "2019-01-04",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-yang-library",
"conformance-type": "implement"
},
{
"name": "ietf-ospf",
"revision": "2019-01-24",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-ospf",
"conformance-type": "implement"
},
{
"name": "ietf-routing",
"revision": "2018-03-13",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-routing",
"conformance-type": "implement"
}
],
"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": "ni-schema",
"module-set": [ "ni-modules" ]
}
],
"datastore": [
{
"name": "ietf-datastores:running",
"schema": "ni-schema"
},
{
"name": "ietf-datastores:operational",
"schema": "ni-schema"
}
]
},
"ietf-routing:routing": {
"router-id": "192.0.2.2",
"control-plane-protocols": {
"control-plane-protocol": [
{
"type": "ietf-routing:ospf",
"name": "1",
"ietf-ospf:ospf": {
"af": "ipv4",
"areas": {
"area": [
{
"area-id": "203.0.113.1",
"interfaces": {
"interface": [
{
"name": "eth2",
"cost": 10
}
]
}
}
]
}
}
}
]
}
}
}
}
]
},
"ietf-interfaces:interfaces": {
"interface": [
{
"name": "eth0",
"type": "iana-if-type:ethernetCsmacd",
"oper-status": "up",
"phys-address": "00:01:02:A1:B1:C0",
"statistics": {
"discontinuity-time": "2017-06-26T12:34:56-05:00"
},
"ietf-ip:ipv4": {
"address": [
{
"ip": "192.0.2.10",
"prefix-length": 24
}
]
},
"ietf-ip:ipv6": {
"address": [
{
"ip": "2001:db8:0:2::10",
"prefix-length": 64
}
]
}
},
{
"name": "eth1",
"type": "iana-if-type:ethernetCsmacd",
"oper-status": "up",
"phys-address": "00:01:02:A1:B1:C1",
"statistics": {
"discontinuity-time": "2017-06-26T12:34:56-05:00"
},
"ietf-ip:ipv4": {
"address": [
{
"ip": "192.0.2.11",
"prefix-length": 24
}
]
},
"ietf-ip:ipv6": {
"address": [
{
"ip": "2001:db8:0:2::11",
"prefix-length": 64
}
]
}
},
{
"name": "eth2",
"type": "iana-if-type:ethernetCsmacd",
"oper-status": "up",
"phys-address": "00:01:02:A1:B1:C2",
"statistics": {
"discontinuity-time": "2017-06-26T12:34:56-05:00"
},
"ietf-ip:ipv4": {
"address": [
{
"ip": "192.0.2.11",
"prefix-length": 24
}
]
},
"ietf-ip:ipv6": {
"address": [
{
"ip": "2001:db8:0:2::11",
"prefix-length": 64
}
]
}
}
]
},
"ietf-system:system-state": {
"platform": {
"os-name": "NetworkOS"
}
},
"ietf-yang-library:yang-library": {
"content-id": "75a43df9bd56b92aacc156a2958fbe12312fb285",
"module-set": [
{
"name": "host-modules",
"module": [
{
"name": "ietf-interfaces",
"revision": "2018-02-20",
"feature": [
"arbitrary-names",
"pre-provisioning"
],
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-interfaces"
},
{
"name": "ietf-ip",
"revision": "2018-01-09",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-ip"
},
{
"name": "ietf-network-instance",
"revision": "2018-02-03",
"feature": [
"bind-network-instance-name"
],
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-network-instance"
},
{
"name": "ietf-ospf",
"revision": "2019-01-24",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-ospf"
},
{
"name": "ietf-routing",
"revision": "2018-03-13",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-routing"
},
{
"name": "ietf-system",
"revision": "2014-08-06",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-system"
},
{
"name": "ietf-yang-library",
"revision": "2019-01-04",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-yang-library"
},
{
"name": "ietf-yang-schema-mount",
"revision": "2019-01-14",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount"
}
],
"import-only-module": [
{
"name": "iana-if-type",
"revision": "2018-07-03",
"namespace": "urn:ietf:params:xml:ns:yang:iana-if-type"
},
{
"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": "host-schema",
"module-set": [ "host-modules" ]
}
],
"datastore": [
{
"name": "ietf-datastores:running",
"schema": "host-schema"
},
{
"name": "ietf-datastores:operational",
"schema": "host-schema"
}
]
},
"ietf-yang-schema-mount:schema-mounts": {
"mount-point": [
{
"module": "ietf-network-instance",
"label": "vrf-root",
"shared-schema": {
"parent-reference": [
"/*[namespace-uri() = 'urn:ietf:...:ietf-interfaces']"
]
}
}
]
}
}
Acknowledgments
The Routing Area Yang Architecture design team members included Acee
Lindem, Anees Shaikh, Christian Hopps, Dean Bogdanovic, Lou Berger,
Qin Wu, Rob Shakir, Stephane Litkowski, and Yan Gang. Martin
Bjorklund and John Scudder provided useful review comments.
This document was motivated by, and derived from, "Network Device
YANG Logical Organization" [YANG-NETWORK].
Thanks for Area Director and IETF last-call comments from Alia Atlas,
Liang Xia, Benoit Claise, and Adam Roach.
Authors' Addresses Authors' Addresses
Lou Berger Lou Berger
LabN Consulting, L.L.C. LabN Consulting, L.L.C.
Email: lberger@labn.net Email: lberger@labn.net
Christan Hopps Christian Hopps
Deutsche Telekom LabN Consulting, L.L.C.
Email: chopps@chopps.org Email: chopps@chopps.org
Acee Lindem Acee Lindem
Cisco Systems Cisco Systems
301 Midenhall Way 301 Midenhall Way
Cary, NC 27513 Cary, NC 27513
USA United States of America
Email: acee@cisco.com Email: acee@cisco.com
Dean Bogdanovic Dean Bogdanovic
Volta Networks
Email: ivandean@gmail.com Email: ivandean@gmail.com
Xufeng Liu Xufeng Liu
Jabil Volta Networks
Email: Xufeng_Liu@jabil.com Email: xufeng.liu.ietf@gmail.com
 End of changes. 175 change blocks. 
978 lines changed or deleted 945 lines changed or added

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