YANG Data Model for Network Instances
Extracted elements (24)
Network Instances (NIs) differ from Logical Network Elements (LNEs) in that NIs are always configured and operated through a single network device via the NI module, whereas each LNE appears as an independent network element accessed separately; NIs model VRFs/VSIs, not fully independent routers.
NI types are expected to differ primarily in the configuration information needed at the device/core level (e.g., route targets for L3VPN) rather than in the schema mounted within an NI, which is why a small set of shared, well-known mount points suffices and proliferation of type-specific mount points is discouraged.
The NI module itself defines only the framework (name, mount points, interface binding) and delegates VRF/VSI technology-specific information (e.g., L3VPN route targets, L2VPN pseudowire config) to separate augmenting documents such as the emerging L3VPN and L2VPN YANG models.
YANG Schema Mount (RFC 8528) is used to support NI internal operation rather than embedding all possible protocol models inline, because the list of modules needed within an NI is implementation-dependent and the method used to support NIs varies across devices.
Implementations MAY restrict parent-referenced interface information visible within an NI mount point to only those interfaces whose 'bind-network-instance-name' matches the NI's 'name'; when such restrictions are applied, they SHOULD be expressed in the 'parent-reference' leaf-list so clients can discover them.
The YANG data model conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342. Appendix A shows both non-NMDA and NMDA variants of state data retrieval, highlighting differences in yang-library and routing-state paths between the two approaches.
To assign an interface to both an LNE and an NI, the interface must first be assigned to the LNE using RFC 8530 mechanisms; within that LNE's interface module, the LNE's representation of that interface is then assigned to an NI using bind-ni-name.
A meaningful 'error-info' indicating the source of the NI assignment failure SHOULD also be provided alongside the 'ni-assignment-failed' error-app-tag.
At least one container with a 'bind-ni-name' leaf MUST be included in the 'bind-ni-name-failed' notification, since a single failure may need to be reported across multiple interface/IPv4/IPv6 contexts.
Future model definitions SHOULD use the three well-known mount points (vrf-root, vsi-root, vv-root) whenever possible; a type-specific mount point defined via augmentation is only appropriate when none of the well-known points fit.
If an interface cannot be assigned to an NI for any reason other than a missing leafref, the operation SHALL fail with error-tag 'operation-failed' and error-app-tag 'ni-assignment-failed'.
Mounted modules SHOULD be defined with access, via appropriate schema mount parent-references (RFC 8528), to device resources such as interfaces.
The 'shared-schema' method defined in ietf-yang-schema-mount (RFC 8528) MUST be used to identify modules accessible under an NI root mount point.
When '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 indicating why the assignment failed; failure may occur synchronously or via the bind-ni-name-failed notification.
The 'bind-ni-name-failed' YANG notification reports asynchronous failures when an interface-to-NI assignment cannot be completed after an initially successful set operation. It carries the interface name, optional bind-ni-name leafrefs for interface/IPv4/IPv6 contexts, and an optional 'error-info' string.
The ietf-network-instance module defines a 'network-instances' container holding a keyed list 'network-instance', each with a 'name' string (mandatory), optional 'enabled' boolean (default true), optional 'description' string, a 'ni-type' choice for augmentation anchoring, and a mandatory 'root-type' choice selecting among the three well-known mount points.
The module augments '/if:interfaces/if:interface', '/if:interfaces/if:interface/ip:ipv4', and '/if:interfaces/if:interface/ip:ipv6' with a 'bind-ni-name' leafref that points to '/network-instances/network-instance/name', binding an interface or IP-layer to a specific network instance.
The 'ni-type' choice node serves as an anchor point for augmentations that define type-specific VRF/VSI information. Each augmenting case is expected to contain containers for configuration and state data and, when needed, a type-specific mount point distinct from the well-known ones.
Three well-known YANG Schema Mount mount points are defined: 'vrf-root' for L3VPN-type NIs, 'vsi-root' for L2VPN-type NIs, and 'vv-root' for NI types that simultaneously support L2VPN bridging and L3VPN routing. These are declared as alternatives under the mandatory 'root-type' choice.
This document registers the URI 'urn:ietf:params:xml:ns:yang:ietf-network-instance' in the IETF XML Registry (RFC 3688) as an XML namespace with the IESG as registrant contact.
This document registers the YANG module 'ietf-network-instance' (namespace 'urn:ietf:params:xml:ns:yang:ietf-network-instance', prefix 'ni') in the IANA YANG Module Names registry (RFC 6020), referencing RFC 8529.
NETCONF access to this module requires SSH as the mandatory-to-implement secure transport (RFC 6242); RESTCONF access requires HTTPS with TLS (RFC 8446). The Network Configuration Access Control Model (NACM, RFC 8341) provides per-user access control over protocol operations and content.
Security considerations for modules mounted under an NI root are not substantively changed by their NI context; the security considerations of those mounted modules (e.g., RFC 8349 for routing) apply equally whether accessed at the device root or under an NI instance root.
The two sensitive 'config true' subtrees are '/network-instances/network-instance' (specifying NIs and their control-plane protocols) and '/if:interfaces/if:interface/*/bind-network-instance-name' (interface-to-NI assignments). Unauthorized write access to either can adversely affect the routing subsystem, leading to packet misdelivery or network malfunctions.