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