Network Working GroupInternet Engineering Task Force (IETF) L. BergerInternet-DraftRequest for Comments: 8529 C. Hopps Category: Standards Track LabN Consulting, L.L.C.Intended status: Standards Track C. Hopps Expires: September 20, 2018 Deutsche TelekomISSN: 2070-1721 A. Lindem Cisco Systems D. Bogdanovic X. LiuJabil March 19, 2018Volta Networks February 2019 YANG Data Model for Network Instancesdraft-ietf-rtgwg-ni-model-12Abstract 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 areVirtualVPN 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 inI-D.ietf-netmod-revised-datastores.RFC 8342. Status of This Memo ThisInternet-Draftissubmitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documentsan Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF).Note that other groups may also distribute working documents as Internet-Drafts. The listIt represents the consensus ofcurrent Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents validthe IETF community. It has received public review and has been approved fora maximumpublication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 ofsix monthsRFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may beupdated, replaced, or obsoleted by other documentsobtained atany time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 20, 2018.https://www.rfc-editor.org/info/rfc8529. Copyright Notice Copyright (c)20182019 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . .43 3. Network Instances . . . . . . . . . . . . . . . . . . . . . . 5 3.1. NI Types and Mount Points . . . . . . . . . . . . . . . . 6 3.1.1.Well KnownWell-Known Mount Points . . . . . . . . . . . . . . .76 3.1.2. NI Type Example . . . . . . . . . . . . . . . . . . .87 3.2. NIs and Interfaces . . . . . . . . . . . . . . . . . . .98 3.3. Network Instance Management . . . . . . . . . . . . . . .109 3.4. Network Instance Instantiation . . . . . . . . . . . . . 12 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6. Network Instance Model . . . . . . . . . . . . . . . . . . . 14 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 7.1. Normative References . . . . . . . . . . . . . . . . . . 20 7.2. Informative References . . . . . . . . . . . . . . . . . 22 Appendix A.AcknowledgmentsExample NI Usage . . . . . . . . . . . . . . . . . . 23Appendix B. Example NI usageA.1. Configuration Data . . . . . . . . . . . . . . . . . . . 23B.1. ConfigurationA.2. State Data - Non-NMDA Version . . . . . . . . . . . . . . 26 A.3. State Data - NMDA Version . . . . . . .23 B.2. State Data - Non-NMDA Version. . . . . . . . . 33 Acknowledgments . . . . .27 B.3. State Data - NMDA Version. . . . . . . . . . . . . . . .33. . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 1. Introduction This document defines the second of two new modules that are defined to support the configuration and operation ofnetwork-devicesnetwork 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[I-D.ietf-netmod-schema-mount].[RFC8528]. The YANG data model in this document conforms to the Network Management Datastore Architecture defined inthe [I-D.ietf-netmod-revised-datastores].[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 elementwhichthat is'hosted'"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[I-D.ietf-rtgwg-lne-model].[RFC8530]. That module is used to identify LNEs and associate resources from thenetwork-devicenetwork 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 logicalrouter,router and virtual switch, chassis, or fabric. The second form, which is defined in this document, provides support for whatisare commonly referred to asVirtualVPN Routing and Forwarding (VRF) instances as well as Virtual Switch Instances(VSI),(VSI); see [RFC4026] and [RFC4664]. In this form of resource partitioning, multiplecontrol planecontrol-plane and forwarding/bridging instances are provided by and managedviathrough a single (physical or logical) network device. This form of resource partitioning is referred to as a Network Instance (NI) and is supported by thenetwork-instancenetwork instance module defined below. Configuration and operation of eachnetwork-instancenetwork instance is always via the network device and thenetwork-instancenetwork 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 andVSI,VSI -- i.e., L3 and L2VPN, technology specific models.VPN -- technology. An example of such can be found in the emerging L3VPN model defined in[I-D.ietf-bess-l3vpn-yang][YANG-L3VPN] and the examples discussed below. 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[I-D.ietf-netmod-schema-mount].[RFC8528]. This document uses the graphical representation of data models defined in[I-D.ietf-netmod-yang-tree-diagrams].[RFC8340]. 2. Overview In this document, we consider network devices that support protocols and functions defined within theIETF, e.g,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 maysub-dividesubdivide their resources into logical network elements(LNEs)(LNEs), each of which provides a managed logical device. Examples of vendor terminology for an LNE include logical system or logicalrouter,router and virtual switch, chassis, or fabric. Each LNE may also supportvirtual routing and forwarding (VRF)VRF andvirtual switching instance (VSI)VSI functions, which are referred to below asanetwork 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 A model for LNEs is described in[I-D.ietf-rtgwg-lne-model][RFC8530], and the model for NIs is covered inthis document inSection3.3 of this document. The current interface management model[I-D.ietf-netmod-rfc7223bis][RFC8343] is impacted by the definition of LNEs and NIs. This document and[I-D.ietf-rtgwg-lne-model][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 thedevice,device -- forexampleexample, 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,for examplesuch as for routing protocols[I-D.ietf-netmod-rfc8022bis][RFC8349] and OSPF[I-D.ietf-ospf-yang].[YANG-OSPF]. This document defines thenetwork-instancenetwork 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 specifictechnology-specific information both at the device level and for NI internal operation. Information related to NI internal operation is supported via schema mount[I-D.ietf-netmod-schema-mount][RFC8528] and mounting appropriate modules under the mount point.Well knownWell-known mount points are defined for L3VPN, L2VPN, and L2+L3VPN NI types. 3. Network Instances The network instance container is used to representvirtual routing and forwarding instances (VRFs)VRFs andvirtual switching instances (VSIs).VSIs. VRFs and VSIs are commonly used to isolate routing and switchingdomains,domains -- forexampleexample, 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/ providerCore/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 A network instance is identified by a'name'"name" string. This string is used both as an index within thenetwork-instancenetwork instance module and to associate resources with a networkinstanceinstance, 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 Thenetwork-instancenetwork 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 supportVPLS, VxLANL2VPN, such as VPLS andEVPN based L2VPNsEVPN, are likely to be quite different. Example models under development that could be restructured to take advantage on NIsinclude,include models for L3VPNs[I-D.ietf-bess-l3vpn-yang][YANG-L3VPN] andforL2VPNs[I-D.ietf-bess-l2vpn-yang].[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 augmentationsincludeincludes a casestatement,statement with containers for configuration and state dataand finally,and, when needed, atype specifictype-specific mount point.Generally ni types,Generally, NI types are expected to not need to definetypetype- specific mountpoints,points but rather reuse one of thewell knownwell-known mountpoint,points, as defined in the next section. The following is an exampletype specifictype-specific augmentation: augment "/ni:network-instances/ni:network-instance/ni:ni-type" { case l3vpn { container l3vpn { ... } container l3vpn-state { ... } } } 3.1.1.Well KnownWell-Known Mount Points YANG SchemaMount, [I-D.ietf-netmod-schema-mount],Mount [RFC8528] identifies mount points by name within a module. This definition allows for the definition of mount points whose schema can be shared acrossni-NI types. As discussed above, ni-types largely differ in the configuration information needed in thecore/top levelcore/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 differentschemaschemas that need to be defined to support NIsonfor an implementation. In particular, it is expected that the following three forms of NI schema are needed, and each can be defined with awell knownwell-known mount point that can be reused by future modules definingni-types.NI types. The threewell knownwell-known mount points are: vrf-root vrf-root is intended for use withL3VPN type ni-types.L3VPN-type NI types. vsi-root vsi-root is intended for use withL2VPN type ni-types.L2VPN-type Ni types. vv-root vv-root is intended for use withni-typesNI types that simultaneously support L2VPN bridging and L3VPN routing capabilities. Future model definitions should use the above mount points whenever possible. When awell knownwell-known mount point isn't appropriate, a model may define atype specifictype-specific mount point via augmentation. 3.1.2. NI Type Example The following is an example of an L3VPN VRF using a hypothetical augmentation to thenetworkingnetwork instance schema defined in[I-D.ietf-bess-l3vpn-yang].[YANG-L3VPN]. More detailed examples can be found in AppendixB.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] | +--rwospf:ospf/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[I-D.ietf-netmod-rfc8022bis][RFC8349] and YANG OSPF[I-D.ietf-ospf-yang][YANG-OSPF] as mounted modules. The mounted modules can reference interface information via a parent-reference to the containers defined in[I-D.ietf-netmod-rfc7223bis].[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 systemservices,services andlayerLayer 2 andlayerLayer 3 protocols 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[I-D.ietf-netmod-rfc7223bis].[RFC8343]. As shown below, thenetwork-instancenetwork instance module augments the existing interface management model by adding a namewhichthat 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[I-D.ietf-netmod-rfc7277bis].[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[I-D.ietf-netmod-rfc7223bis] defined interface model"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. Thebind- network-instance-namebind-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[I-D.ietf-rtgwg-lne-model][RFC8530] andthenthen, within that LNE's interface module, the LNE's representation of that interface would be assigned to an NI. 3.3. Network Instance Management Modules that may be used to represent network instance information will be available under theni-type specific 'root'"root" mountpoint.point specific to the ni-type. The "shared-schema" method defined in the"ietf-yang-schema-mount""ietf-yang- schema-mount" module[I-D.ietf-netmod-schema-mount][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[I-D.ietf-netmod-schema-mount],[RFC8528], to device resources such as interfaces. An implementation MAY choose to restrictparent referencedparent-referenced information to information related to a specificinstance, e.g.,instance. For example, it might onlyallowingallow references to interfaces that have a"bind- network-instance-name" which"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'"root" mountpoint,point andbeaccessible via paths modified per[I-D.ietf-netmod-schema-mount].[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"."mount-point". These modules will be able to reference information for nodes belonging to top-level modules that are identified under "parent-reference".Parent referencedParent-referenced information is available to clients via theirtop leveltop-level pathsonly,only and not under the associated mount point. To allow a client to understand the previously mentioned instance restrictions onparent referencedparent-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]" ] } } ], The same such "parent-reference" restrictions for non-NMDA implementations can be represented based onthe [RFC7223][RFC8343] and[RFC7277][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:ipv4/if:interfaces/if:interface/ip:ipv6 [ni:bind-ni-name = current()/../ni:name]/if:name]" ] } } ], 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[RFC7950]Section7.8.6.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 setoperation,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[RFC5246].[RFC8446]. TheNETCONF access control model [RFC6536]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[I-D.ietf-netmod-rfc8022bis],[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. 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[I-D.ietf-netmod-rfc7223bis][RFC8343] and[I-D.ietf-netmod-rfc8022bis].[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 inappropriatedestinationsdestinations, and other problems. 5. IANA Considerations This document registers a URI in theIETF"IETF XMLregistryRegistry" [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 Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. This document registers a YANG module in theYANG"YANG ModuleNamesNames" registry [RFC6020]. name: ietf-network-instance namespace: urn:ietf:params:xml:ns:yang:ietf-network-instance prefix: ni reference: RFCXXXX8529 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@2018-03-20.yang""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"draft-ietf-netmod-rfc7223bis:"RFC 8343: A YANG Data Model for Interface Management"; } import ietf-ip { prefix ip; reference"draft-ietf-netmod-rfc7277bis:"RFC 8344: A YANG Data Model for IP Management"; } import ietf-yang-schema-mount { prefix yangmnt; reference"draft-ietf-netmod-schema-mount:"RFC 8528: YANG Schema Mount";// RFC Ed.: Please replace this draft name with the // corresponding RFC number} organization "IETF Routing Area (rtgwg) Working Group"; contact "WG Web: <http://tools.ietf.org/wg/rtgwg/> WG List: <mailto:rtgwg@ietf.org> Author: Lou Berger <mailto:lberger@labn.net> Author:ChristanChristian 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(virtual routing(VPN Routing andforwarding)Forwarding) and VSIs(virtual switching instances).(Virtual Switching Instances). 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)20172019 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(http://trustee.ietf.org/license-info).(https://trustee.ietf.org/license-info). This version of this YANG module is part of RFCXXXX;8529; see the RFC itself for full legal notices.";// RFC Ed.: replace XXXX with actual RFC number and remove // this note // RFC Ed.: please update TBDrevision2018-03-202019-01-21 { description "Initial revision."; reference "RFCTBD";8529"; } //top leveltop-level device definition statements container network-instances { description "Networkinstancesinstances, each of which consists ofaVRFs(virtual routing and forwarding)and/orVSIs (virtual switching instances).";VSIs."; reference"draft-ietf-rtgwg-rfc8022bis -"RFC 8349: A YANG Data Model for Routing Management"; list network-instance { key "name"; description "List ofnetwork-instances.";network instances."; leaf name { type string; mandatory true; description"device scoped"device-scoped identifier for the network instance."; } leaf enabled { type boolean; 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 theNI,NI and may differ in theirmounted schemamounted-schema definition. When the mounted schema is not expected to be the same for a specific type ofNINI, a mount point should be defined."; } choice root-type { mandatory true; description"Well known"Well-known mount points."; container vrf-root { description "Container for mount point."; yangmnt:mount-point "vrf-root" { description "Root forL3VPN typeL3VPN-type models. This will typically not be aninline typeinline-type mount point."; } } container vsi-root { description "Container for mount point."; yangmnt:mount-point "vsi-root" { description "Root forL2VPN typeL2VPN-type models. This will typically not be aninline typeinline-type mount point."; } } container vv-root { description "Container for mount point."; yangmnt:mount-point "vv-root" { description "Root models that support bothL2VPN typeL2VPN-type bridging andL3VPN typeL3VPN-type routing. This will typically not be aninline typeinline-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 aninterfacesinterface 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 "NetworkInstanceinstance 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 aninterfacesinterface 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 "NetworkInstanceinstance 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 aninterfacesinterface 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 "NetworkInstanceinstance 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:someSome 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 failure."; } container interface { description "Generic interface type."; leaf bind-ni-name { type leafref { path"/if:interfaces/if:interface/ni:bind-ni-name";"/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";"/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""/if:interfaces/if:interface/ip:ipv6" +"/ip:ipv6/ni:bind-ni-name";"/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."; } } } <CODE ENDS> 7. 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[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>.[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 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>.[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 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>.7.2. Informative References [I-D.ietf-bess-l2vpn-yang] Shah, H., Brissette, P., Chen, I., Hussain, I., Wen, B.,[RFC8340] Bjorklund, M. andK. Tiruveedhula,L. Berger, Ed., "YANGData Model for MPLS-based L2VPN", draft-ietf-bess-l2vpn-yang-08 (work in progress), February 2018. [I-D.ietf-bess-l3vpn-yang] Jain, D., Patel, K., Brissette, P., Li, Z., Zhuang, S., Liu, X., Haas, J., Esale, S.,Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, <https://www.rfc-editor.org/info/rfc8340>. [RFC8341] Bierman, A. andB. Wen, "Yang Data Model for BGP/MPLS L3 VPNs", draft-ietf-bess-l3vpn-yang-02 (work in progress), October 2017. [I-D.ietf-netmod-rfc8022bis] Lhotka, L., Lindem, A.,M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, <https://www.rfc-editor.org/info/rfc8341>. [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., andY. Qu,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 forRouting Management (NMDA Version)", draft-ietf-netmod- rfc8022bis-11 (work in progress), January 2018. [I-D.ietf-ospf-yang] Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem, "YangInterface Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, <https://www.rfc-editor.org/info/rfc8343>. [RFC8344] Bjorklund, M., "A YANG Data Model forOSPF Protocol", draft-ietf-ospf- yang-10 (work in progress), March 2018. [I-D.ietf-rtgwg-device-model] Lindem, A., Berger, L., Bogdanovic, D., and C. Hopps, "Network Device YANG Logical Organization", draft-ietf- rtgwg-device-model-02 (work in progress),IP Management", RFC 8344, DOI 10.17487/RFC8344, March2017. [I-D.ietf-rtgwg-lne-model] Berger, L., Hopps, C., Lindem, A., Bogdanovic, D.,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. andX. Liu,L. Lhotka, "YANGModel for Logical Network Elements", draft- ietf-rtgwg-lne-model-09 (work in progress), March 2018.Schema Mount", RFC 8528, DOI 10.17487/RFC8528, February 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>.[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", RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.[RFC8022][RFC8349] Lhotka,L. and A.L., Lindem, A., and Y. Qu, "A YANG Data Model for RoutingManagement",Management (NMDA Version)", RFC8022,8349, DOI10.17487/RFC8022, November 2016, <https://www.rfc-editor.org/info/rfc8022>. Appendix A. Acknowledgments The Routing Area Yang Architecture design team members included Acee Lindem, Anees Shaikh, Christian10.17487/RFC8349, March 2018, <https://www.rfc-editor.org/info/rfc8349>. [RFC8530] Berger, L., Hopps,DeanC., Lindem, A., Bogdanovic,Lou Berger, Qin Wu, Rob Shakir, Stephane Litkowski,D., andYan Gang. Useful review comments were also received by Martin BjorklundX. Liu, "YANG Model for Logical Network Elements", RFC 8530, DOI 10.17487/RFC8530, February 2019. [YANG-L2VPN] Shah, H., Brissette, P., Chen, I., Hussain, I., Wen, B., andJohn Scudder. This document was motivated by,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., andderived from, [I-D.ietf-rtgwg-device-model]. ThanksA. Lindem, "YANG Data Model forAD and IETF last call comments from Alia Atlas, Liang Xia, Benoit Claise, and Adam Roach. The RFC text was produced using Marshall Rose's xml2rfc tool.OSPF Protocol", Work in Progress, draft-ietf-ospf-yang-21, January 2019. AppendixB.A. Example NIusageUsage The following subsections provide example uses of NIs.B.1.A.1. Configuration Data The following shows an example where twocustomer specificcustomer-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", "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": {"interfaces": {"interface": [ { "name": "eth0","ip:ipv4":"type": "iana-if-type:ethernetCsmacd", "ietf-ip:ipv4": { "address": [ { "ip": "192.0.2.10", "prefix-length":24,24 } ] },"ip:ipv6":"ietf-ip:ipv6": { "address": [ { "ip": "2001:db8:0:2::10", "prefix-length":64,64 } ] } }, { "name": "eth1","ip:ipv4":"type": "iana-if-type:ethernetCsmacd", "ietf-ip:ipv4": { "address": [ { "ip": "192.0.2.11", "prefix-length":24,24 } ] },"ip:ipv6":"ietf-ip:ipv6": { "address": [ { "ip": "2001:db8:0:2::11", "prefix-length":64,64 } ] },"ni:bind-network-instance-name":"ietf-network-instance:bind-network-instance-name": "vrf-red" }, { "name": "eth2","ip:ipv4":"type": "iana-if-type:ethernetCsmacd", "ietf-ip:ipv4": { "address": [ { "ip": "192.0.2.11", "prefix-length":24,24 } ] },"ip:ipv6":"ietf-ip:ipv6": { "address": [ { "ip": "2001:db8:0:2::11", "prefix-length":64,64 } ] },"ni:bind-network-instance-name":"ietf-network-instance:bind-network-instance-name": "vrf-blue" } ]}}, "ietf-system:system": { "authentication": { "user": [ { "name": "john", "password": "$0$password" } ] } } }B.2.A.2. State Data - Non-NMDA Version The following shows state data for the configuration example above based on[RFC7223], [RFC7277],[RFC8343], [RFC8344], and[RFC8022].[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":"2016-06-21","2019-01-04", "namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-library", "conformance-type": "implement" }, { "name": "ietf-ospf", "revision":"2018-03-03","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.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":"2016-06-21","2019-01-04", "namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-library", "conformance-type": "implement" }, { "name": "ietf-ospf", "revision":"2018-03-03","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 } ] } } ] } } } ] } } } } ] }, "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":"ietf-ip:ipv4": { "address": [ { "ip": "192.0.2.10", "prefix-length":24,24 } ]} "ip:ipv6":}, "ietf-ip:ipv6": { "address": [ { "ip": "2001:db8:0:2::10", "prefix-length":64,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" },"ip:ipv4":"ietf-ip:ipv4": { "address": [ { "ip": "192.0.2.11", "prefix-length":24,24 } ]} "ip:ipv6":}, "ietf-ip:ipv6": { "address": [ { "ip": "2001:db8:0:2::11", "prefix-length":64,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" },"ip:ipv4":"ietf-ip:ipv4": { "address": [ { "ip": "192.0.2.11", "prefix-length":24,24 } ]} "ip:ipv6":}, "ietf-ip:ipv6": { "address": [ { "ip": "2001:db8:0:2::11", "prefix-length":64,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","2018-07-03", "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","2018-02-20", "feature": [ "arbitrary-names", "pre-provisioning" ], "namespace": "urn:ietf:params:xml:ns:yang:ietf-interfaces", "conformance-type": "implement" }, { "name": "ietf-ip", "revision":"2014-06-16","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":"2018-03-03","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", "namespace": "urn:ietf:params:xml:ns:yang:ietf-system", "conformance-type": "implement" }, { "name": "ietf-yang-library", "revision":"2016-06-21","2019-01-04", "namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-library", "conformance-type": "implement" }, { "name": "ietf-yang-schema-mount", "revision":"2017-05-16","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']" ] } } ] } }B.3.A.3. State Data - NMDA Version The following shows state data for the configuration example above based on[I-D.ietf-netmod-rfc7223bis], [I-D.ietf-netmod-rfc7277bis],[RFC8343], [RFC8344], and[I-D.ietf-netmod-rfc8022bis].[RFC8349]. { "ietf-network-instance:network-instances": { "network-instance": [ { "name": "vrf-red", "vrf-root": { "ietf-yang-library:yang-library": {"checksum":"content-id": "41e2ab5dc325f6d86f743e8da3de323f1a61a801", "module-set": [ { "name": "ni-modules", "module": [ { "name": "ietf-yang-library", "revision":"2016-06-21","2019-01-04", "namespace":"urn:ietf:params:xml:ns:yang:ietf-yang-library", "conformance-type": "implement""urn:ietf:params:xml:ns:yang:ietf-yang-library" }, { "name": "ietf-ospf", "revision":"2018-03-03","2019-01-24", "namespace":"urn:ietf:params:xml:ns:yang:ietf-ospf", "conformance-type": "implement""urn:ietf:params:xml:ns:yang:ietf-ospf" }, { "name": "ietf-routing", "revision": "2018-03-13", "namespace":"urn:ietf:params:xml:ns:yang:ietf-routing", "conformance-type": "implement""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":"2016-06-21","2019-01-04", "namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-library", "conformance-type": "implement" }, { "name": "ietf-ospf", "revision":"2018-03-03","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": {"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":"ietf-ip:ipv4": { "address": [ { "ip": "192.0.2.10", "prefix-length":24,24 } ]} "ip:ipv6":}, "ietf-ip:ipv6": { "address": [ { "ip": "2001:db8:0:2::10", "prefix-length":64,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" },"ip:ipv4":"ietf-ip:ipv4": { "address": [ { "ip": "192.0.2.11", "prefix-length":24,24 } ]} "ip:ipv6":}, "ietf-ip:ipv6": { "address": [ { "ip": "2001:db8:0:2::11", "prefix-length":64,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" },"ip:ipv4":"ietf-ip:ipv4": { "address": [ { "ip": "192.0.2.11", "prefix-length":24,24 } ]} "ip:ipv6":}, "ietf-ip:ipv6": { "address": [ { "ip": "2001:db8:0:2::11", "prefix-length":64,64 } ] } } ]}}, "ietf-system:system-state": { "platform": { "os-name": "NetworkOS" }} "ietf-yang-library:modules-state":}, "ietf-yang-library:yang-library": {"module-set-id": "123e4567-e89b-12d3-a456-426655440000", "module":"content-id": "75a43df9bd56b92aacc156a2958fbe12312fb285", "module-set": [ { "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" },"host-modules", "module": [ { "name": "ietf-interfaces", "revision":"2018-01-09","2018-02-20", "feature": [ "arbitrary-names", "pre-provisioning" ], "namespace":"urn:ietf:params:xml:ns:yang:ietf-interfaces", "conformance-type": "implement""urn:ietf:params:xml:ns:yang:ietf-interfaces" }, { "name": "ietf-ip", "revision": "2018-01-09", "namespace":"urn:ietf:params:xml:ns:yang:ietf-ip", "conformance-type": "implement""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", "conformance-type": "implement""urn:ietf:params:xml:ns:yang:ietf-network-instance" }, { "name": "ietf-ospf", "revision":"2017-10-30","2019-01-24", "namespace":"urn:ietf:params:xml:ns:yang:ietf-ospf", "conformance-type": "implement""urn:ietf:params:xml:ns:yang:ietf-ospf" }, { "name": "ietf-routing", "revision":"2018-01-25","2018-03-13", "namespace":"urn:ietf:params:xml:ns:yang:ietf-routing", "conformance-type": "implement""urn:ietf:params:xml:ns:yang:ietf-routing" }, { "name": "ietf-system", "revision": "2014-08-06", "namespace":"urn:ietf:params:xml:ns:yang:ietf-system", "conformance-type": "implement""urn:ietf:params:xml:ns:yang:ietf-system" }, { "name": "ietf-yang-library", "revision":"2016-06-21","2019-01-04", "namespace":"urn:ietf:params:xml:ns:yang:ietf-yang-library", "conformance-type": "implement""urn:ietf:params:xml:ns:yang:ietf-yang-library" }, { "name": "ietf-yang-schema-mount", "revision":"2017-05-16","2019-01-14", "namespace":"urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount", "conformance-type": "implement""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", "conformance-type": "import""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 Lou Berger LabN Consulting, L.L.C. Email: lberger@labn.netChristanChristian HoppsDeutsche TelekomLabN Consulting, L.L.C. Email: chopps@chopps.org Acee Lindem Cisco Systems 301 Midenhall Way Cary, NC 27513USAUnited States of America Email: acee@cisco.com Dean Bogdanovic Volta Networks Email: ivandean@gmail.com Xufeng LiuJabilVolta Networks Email:Xufeng_Liu@jabil.comxufeng.liu.ietf@gmail.com