idnits 2.17.1 draft-ietf-rtgwg-ni-model-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 19, 2018) is 2229 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-12) exists of draft-ietf-netmod-schema-mount-08 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) == Outdated reference: A later version (-10) exists of draft-ietf-bess-l2vpn-yang-08 == Outdated reference: A later version (-05) exists of draft-ietf-bess-l3vpn-yang-02 == Outdated reference: A later version (-29) exists of draft-ietf-ospf-yang-10 == Outdated reference: A later version (-10) exists of draft-ietf-rtgwg-lne-model-09 -- Obsolete informational reference (is this intentional?): RFC 7223 (Obsoleted by RFC 8343) -- Obsolete informational reference (is this intentional?): RFC 7277 (Obsoleted by RFC 8344) -- Obsolete informational reference (is this intentional?): RFC 8022 (Obsoleted by RFC 8349) Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Berger 3 Internet-Draft LabN Consulting, L.L.C. 4 Intended status: Standards Track C. Hopps 5 Expires: September 20, 2018 Deutsche Telekom 6 A. Lindem 7 Cisco Systems 8 D. Bogdanovic 10 X. Liu 11 Jabil 12 March 19, 2018 14 YANG Model for Network Instances 15 draft-ietf-rtgwg-ni-model-12 17 Abstract 19 This document defines a network instance module. This module can be 20 used to manage the virtual resource partitioning that may be present 21 on a network device. Examples of common industry terms for virtual 22 resource partitioning are Virtual Routing and Forwarding (VRF) 23 instances and Virtual Switch Instances (VSIs). 25 The YANG model in this document conforms to the Network Management 26 Datastore Architecture defined in I-D.ietf-netmod-revised-datastores. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 20, 2018. 45 Copyright Notice 47 Copyright (c) 2018 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Network Instances . . . . . . . . . . . . . . . . . . . . . . 5 66 3.1. NI Types and Mount Points . . . . . . . . . . . . . . . . 6 67 3.1.1. Well Known Mount Points . . . . . . . . . . . . . . . 7 68 3.1.2. NI Type Example . . . . . . . . . . . . . . . . . . . 8 69 3.2. NIs and Interfaces . . . . . . . . . . . . . . . . . . . 9 70 3.3. Network Instance Management . . . . . . . . . . . . . . . 10 71 3.4. Network Instance Instantiation . . . . . . . . . . . . . 12 72 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 74 6. Network Instance Model . . . . . . . . . . . . . . . . . . . 14 75 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 76 7.1. Normative References . . . . . . . . . . . . . . . . . . 20 77 7.2. Informative References . . . . . . . . . . . . . . . . . 22 78 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 23 79 Appendix B. Example NI usage . . . . . . . . . . . . . . . . . . 23 80 B.1. Configuration Data . . . . . . . . . . . . . . . . . . . 23 81 B.2. State Data - Non-NMDA Version . . . . . . . . . . . . . . 27 82 B.3. State Data - NMDA Version . . . . . . . . . . . . . . . . 33 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 85 1. Introduction 87 This document defines the second of two new modules that are defined 88 to support the configuration and operation of network-devices that 89 allow for the partitioning of resources from both, or either, 90 management and networking perspectives. Both leverage the YANG 91 functionality enabled by YANG Schema Mount 92 [I-D.ietf-netmod-schema-mount]. 94 The YANG model in this document conforms to the Network Management 95 Datastore Architecture defined in the 96 [I-D.ietf-netmod-revised-datastores]. 98 The first form of resource partitioning provides a logical 99 partitioning of a network device where each partition is separately 100 managed as essentially an independent network element which is 101 'hosted' by the base network device. These hosted network elements 102 are referred to as logical network elements, or LNEs, and are 103 supported by the logical-network-element module defined in 104 [I-D.ietf-rtgwg-lne-model]. That module is used to identify LNEs and 105 associate resources from the network-device with each LNE. LNEs 106 themselves are represented in YANG as independent network devices; 107 each accessed independently. Examples of vendor terminology for an 108 LNE include logical system or logical router, and virtual switch, 109 chassis, or fabric. 111 The second form, which is defined in this document, provides support 112 for what is commonly referred to as Virtual Routing and Forwarding 113 (VRF) instances as well as Virtual Switch Instances (VSI), see 114 [RFC4026] and [RFC4664]. In this form of resource partitioning, 115 multiple control plane and forwarding/bridging instances are provided 116 by and managed via a single (physical or logical) network device. 117 This form of resource partitioning is referred to as a Network 118 Instance and is supported by the network-instance module defined 119 below. Configuration and operation of each network-instance is 120 always via the network device and the network-instance module. 122 One notable difference between the LNE model and the NI model is that 123 the NI model provides a framework for VRF and VSI management. This 124 document envisions the separate definition of VRF and VSI, i.e., L3 125 and L2 VPN, technology specific models. An example of such can be 126 found in the emerging L3VPN model defined in 127 [I-D.ietf-bess-l3vpn-yang] and the examples discussed below. 129 1.1. Terminology 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 133 "OPTIONAL" in this document are to be interpreted as described in BCP 134 14 [RFC2119] [RFC8174] when, and only when, they appear in all 135 capitals, as shown here. 137 Readers are expected to be familiar with terms and concepts of YANG 138 [RFC7950] and YANG Schema Mount [I-D.ietf-netmod-schema-mount]. 140 This document uses the graphical representation of data models 141 defined in [I-D.ietf-netmod-yang-tree-diagrams]. 143 2. Overview 145 In this document, we consider network devices that support protocols 146 and functions defined within the IETF, e.g, routers, firewalls, and 147 hosts. Such devices may be physical or virtual, e.g., a classic 148 router with custom hardware or one residing within a server-based 149 virtual machine implementing a virtual network function (VNF). Each 150 device may sub-divide their resources into logical network elements 151 (LNEs) each of which provides a managed logical device. Examples of 152 vendor terminology for an LNE include logical system or logical 153 router, and virtual switch, chassis, or fabric. Each LNE may also 154 support virtual routing and forwarding (VRF) and virtual switching 155 instance (VSI) functions, which are referred to below as a network 156 instances (NIs). This breakdown is represented in Figure 1. 158 ,''''''''''''''''''''''''''''''''''''''''''''''`. 159 | Network Device (Physical or Virtual) | 160 | ..................... ..................... | 161 | : Logical Network : : Logical Network : | 162 | : Element : : Element : | 163 | :+-----+-----+-----+: :+-----+-----+-----+: | 164 | :| Net | Net | Net |: :| Net | Net | Net |: | 165 | :|Inst.|Inst.|Inst.|: :|Inst.|Inst.|Inst.|: | 166 | :+-----+-----+-----+: :+-----+-----+-----+: | 167 | : | | | | | | : : | | | | | | : | 168 | :..|.|...|.|...|.|..: :..|.|...|.|...|.|..: | 169 | | | | | | | | | | | | | | 170 `'''|'|'''|'|'''|'|'''''''''|'|'''|'|'''|'|''''' 171 | | | | | | | | | | | | 172 Interfaces Interfaces 174 Figure 1: Module Element Relationships 176 A model for LNEs is described in [I-D.ietf-rtgwg-lne-model] and the 177 model for NIs is covered in this document in Section 3. 179 The current interface management model [I-D.ietf-netmod-rfc7223bis] 180 is impacted by the definition of LNEs and NIs. This document and 181 [I-D.ietf-rtgwg-lne-model] define augmentations to the interface 182 module to support LNEs and NIs. 184 The network instance model supports the configuration of VRFs and 185 VSIs. Each instance is supported by information that relates to the 186 device, for example the route target used when advertising VRF routes 187 via the mechanisms defined in [RFC4364], and information that relates 188 to the internal operation of the NI, for example for routing 189 protocols [I-D.ietf-netmod-rfc8022bis] and OSPF [I-D.ietf-ospf-yang]. 191 This document defines the network-instance module that provides a 192 basis for the management of both types of information. 194 NI information that relates to the device, including the assignment 195 of interfaces to NIs, is defined as part of this document. The 196 defined module also provides a placeholder for the definition of NI- 197 technology specific information both at the device level and for NI 198 internal operation. Information related to NI internal operation is 199 supported via schema mount [I-D.ietf-netmod-schema-mount] and 200 mounting appropriate modules under the mount point. Well known mount 201 points are defined for L3VPN, L2VPN, and L2+L3VPN NI types. 203 3. Network Instances 205 The network instance container is used to represent virtual routing 206 and forwarding instances (VRFs) and virtual switching instances 207 (VSIs). VRFs and VSIs are commonly used to isolate routing and 208 switching domains, for example to create virtual private networks, 209 each with their own active protocols and routing/switching policies. 210 The model supports both core/provider and virtual instances. Core/ 211 provider instance information is accessible at the top level of the 212 server, while virtual instance information is accessible under the 213 root schema mount points. 215 module: ietf-network-instance 216 +--rw network-instances 217 +--rw network-instance* [name] 218 +--rw name string 219 +--rw enabled? boolean 220 +--rw description? string 221 +--rw (ni-type)? 222 +--rw (root-type) 223 +--:(vrf-root) 224 | +--mp vrf-root 225 +--:(vsi-root) 226 | +--mp vsi-root 227 +--:(vv-root) 228 +--mp vv-root 229 augment /if:interfaces/if:interface: 230 +--rw bind-ni-name? -> /network-instances/network-instance/name 231 augment /if:interfaces/if:interface/ip:ipv4: 232 +--rw bind-ni-name? -> /network-instances/network-instance/name 233 augment /if:interfaces/if:interface/ip:ipv6: 234 +--rw bind-ni-name? -> /network-instances/network-instance/name 236 notifications: 237 +---n bind-ni-name-failed 238 +--ro name -> /if:interfaces/interface/name 239 +--ro interface 240 | +--ro bind-ni-name? 241 | -> /if:interfaces/interface/ni:bind-ni-name 242 +--ro ipv4 243 | +--ro bind-ni-name? 244 | -> /if:interfaces/interface/ip:ipv4/ni:bind-ni-name 245 +--ro ipv6 246 | +--ro bind-ni-name? 247 | -> /if:interfaces/interface/ip:ipv6/ni:bind-ni-name 248 +--ro error-info? string 250 A network instance is identified by a 'name' string. This string is 251 used both as an index within the network-instance module and to 252 associate resources with a network instance as shown above in the 253 interface augmentation. The ni-type and root-type choice statements 254 are used to support different types of L2 and L3 VPN technologies. 255 The bind-ni-name-failed notification is used in certain failure 256 cases. 258 3.1. NI Types and Mount Points 260 The network-instance module is structured to facilitate the 261 definition of information models for specific types of VRFs and VSIs 262 using augmentations. For example, the information needed to support 263 VPLS, VxLAN and EVPN based L2VPNs are likely to be quite different. 264 Example models under development that could be restructured to take 265 advantage on NIs include, for L3VPNs [I-D.ietf-bess-l3vpn-yang] and 266 for L2VPNs [I-D.ietf-bess-l2vpn-yang]. 268 Documents defining new YANG models for the support of specific types 269 of network instances should augment the network instance module. The 270 basic structure that should be used for such augmentations include a 271 case statement, with containers for configuration and state data and 272 finally, when needed, a type specific mount point. Generally ni 273 types, are expected to not need to define type specific mount points, 274 but rather reuse one of the well known mount point, as defined in the 275 next section. The following is an example type specific 276 augmentation: 278 augment "/ni:network-instances/ni:network-instance/ni:ni-type" { 279 case l3vpn { 280 container l3vpn { 281 ... 282 } 283 container l3vpn-state { 284 ... 285 } 286 } 287 } 289 3.1.1. Well Known Mount Points 291 YANG Schema Mount, [I-D.ietf-netmod-schema-mount], identifies mount 292 points by name within a module. This definition allows for the 293 definition of mount points whose schema can be shared across ni- 294 types. As discussed above, ni-types largely differ in the 295 configuration information needed in the core/top level instance to 296 support the NI, rather than in the information represented within an 297 NI. This allows the use of shared mount points across certain NI 298 types. 300 The expectation is that there are actually very few different schema 301 that need to be defined to support NIs on an implementation. In 302 particular, it is expected that the following three forms of NI 303 schema are needed, and each can be defined with a well known mount 304 point that can be reused by future modules defining ni-types. 306 The three well known mount points are: 308 vrf-root 309 vrf-root is intended for use with L3VPN type ni-types. 311 vsi-root 312 vsi-root is intended for use with L2VPN type ni-types. 314 vv-root 315 vv-root is intended for use with ni-types that simultaneously 316 support L2VPN bridging and L3VPN routing capabilities. 318 Future model definitions should use the above mount points whenever 319 possible. When a well known mount point isn't appropriate, a model 320 may define a type specific mount point via augmentation. 322 3.1.2. NI Type Example 324 The following is an example of an L3VPN VRF using a hypothetical 325 augmentation to the networking instance schema defined in 326 [I-D.ietf-bess-l3vpn-yang]. More detailed examples can be found in 327 Appendix B. 329 module: ietf-network-instance 330 +--rw network-instances 331 +--rw network-instance* [name] 332 +--rw name string 333 +--rw enabled? boolean 334 +--rw description? string 335 +--rw (ni-type)? 336 | +--:(l3vpn) 337 | +--rw l3vpn:l3vpn 338 | | ... // config data 339 | +--ro l3vpn:l3vpn-state 340 | | ... // state data 341 +--rw (root-type) 342 +--:(vrf-root) 343 +--mp vrf-root 344 +--rw rt:routing/ 345 | +--rw router-id? yang:dotted-quad 346 | +--rw control-plane-protocols 347 | +--rw control-plane-protocol* [type name] 348 | +--rw ospf:ospf/ 349 | +--rw area* [area-id] 350 | +--rw interfaces 351 | +--rw interface* [name] 352 | +--rw name if:interface-ref 353 | +--rw cost? uint16 354 +--ro if:interfaces@ 355 | ... 357 This shows YANG Routing Management [I-D.ietf-netmod-rfc8022bis] and 358 YANG OSPF [I-D.ietf-ospf-yang] as mounted modules. The mounted 359 modules can reference interface information via a parent-reference to 360 the containers defined in [I-D.ietf-netmod-rfc7223bis]. 362 3.2. NIs and Interfaces 364 Interfaces are a crucial part of any network device's configuration 365 and operational state. They generally include a combination of raw 366 physical interfaces, link-layer interfaces, addressing configuration, 367 and logical interfaces that may not be tied to any physical 368 interface. Several system services, and layer 2 and layer 3 369 protocols may also associate configuration or operational state data 370 with different types of interfaces (these relationships are not shown 371 for simplicity). The interface management model is defined by 372 [I-D.ietf-netmod-rfc7223bis]. 374 As shown below, the network-instance module augments the existing 375 interface management model by adding a name which is used on 376 interface or sub-interface types to identify an associated network 377 instance. Similarly, this name is also added for IPv4 and IPv6 378 types, as defined in [I-D.ietf-netmod-rfc7277bis]. 380 The following is an example of envisioned usage. The interfaces 381 container includes a number of commonly used components as examples: 383 module: ietf-interfaces 384 +--rw interfaces 385 | +--rw interface* [name] 386 | +--rw name string 387 | +--rw ip:ipv4! 388 | | +--rw ip:enabled? boolean 389 | | +--rw ip:forwarding? boolean 390 | | +--rw ip:mtu? uint16 391 | | +--rw ip:address* [ip] 392 | | | +--rw ip:ip inet:ipv4-address-no-zone 393 | | | +--rw (ip:subnet) 394 | | | +--:(ip:prefix-length) 395 | | | | +--rw ip:prefix-length? uint8 396 | | | +--:(ip:netmask) 397 | | | +--rw ip:netmask? yang:dotted-quad 398 | | +--rw ip:neighbor* [ip] 399 | | | +--rw ip:ip inet:ipv4-address-no-zone 400 | | | +--rw ip:link-layer-address yang:phys-address 401 | | +--rw ni:bind-network-instance-name? string 402 | +--rw ni:bind-network-instance-name? string 404 The [I-D.ietf-netmod-rfc7223bis] defined interface model is 405 structured to include all interfaces in a flat list, without regard 406 to virtual instances (e.g., VRFs) supported on the device. The bind- 407 network-instance-name leaf provides the association between an 408 interface and its associated NI (e.g., VRF or VSI). Note that as 409 currently defined, to assign an interface to both an LNE and NI, the 410 interface would first be assigned to the LNE using the mechanisms 411 defined in [I-D.ietf-rtgwg-lne-model] and then within that LNE's 412 interface module, the LNE's representation of that interface would be 413 assigned to an NI. 415 3.3. Network Instance Management 417 Modules that may be used to represent network instance information 418 will be available under the ni-type specific 'root' mount point. The 419 "shared-schema" method defined in the "ietf-yang-schema-mount" module 420 [I-D.ietf-netmod-schema-mount] MUST be used to identify accessible 421 modules. A future version of this document could relax this 422 requirement. Mounted modules SHOULD be defined with access, via the 423 appropriate schema mount parent-references 424 [I-D.ietf-netmod-schema-mount], to device resources such as 425 interfaces. An implementation MAY choose to restrict parent 426 referenced information to information related to a specific instance, 427 e.g., only allowing references to interfaces that have a "bind- 428 network-instance-name" which is identical to the instance's "name". 430 All modules that represent control-plane and data-plane information 431 may be present at the 'root' mount point, and be accessible via paths 432 modified per [I-D.ietf-netmod-schema-mount]. The list of available 433 modules is expected to be implementation dependent, as is the method 434 used by an implementation to support NIs. 436 For example, the following could be used to define the data 437 organization of the example NI shown in Section 3.1.2: 439 "ietf-yang-schema-mount:schema-mounts": { 440 "mount-point": [ 441 { 442 "module": "ietf-network-instance", 443 "label": "vrf-root", 444 "shared-schema": { 445 "parent-reference": [ 446 "/*[namespace-uri() = 'urn:ietf:...:ietf-interfaces']" 447 ] 448 } 449 } 450 ] 451 } 453 Module data identified according to the ietf-yang-schema-mount module 454 will be instantiated under the mount point identified under "mount- 455 point". These modules will be able to reference information for 456 nodes belonging to top-level modules that are identified under 457 "parent-reference". Parent referenced information is available to 458 clients via their top level paths only, and not under the associated 459 mount point. 461 To allow a client to understand the previously mentioned instance 462 restrictions on parent referenced information, an implementation MAY 463 represent such restrictions in the "parent-reference" leaf-list. For 464 example: 466 "namespace": [ 467 { 468 "prefix": "if", 469 "uri": "urn:ietf:params:xml:ns:yang:ietf-interfaces" 470 }, 471 { 472 "prefix": "ni", 473 "uri": "urn:ietf:params:xml:ns:yang:ietf-network-instance" 474 } 475 ], 476 "mount-point": [ 477 { 478 "module": "ietf-network-instance", 479 "label": "vrf-root", 480 "shared-schema": { 481 "parent-reference": [ 482 "/if:interfaces/if:interface 483 [ni:bind-network-instance-name = current()/../ni:name]", 484 "/if:interfaces/if:interface/ip:ipv4 485 [ni:bind-network-instance-name = current()/../ni:name]", 486 "/if:interfaces/if:interface/ip:ipv6 487 [ni:bind-network-instance-name = current()/../ni:name]" 488 ] 489 } 490 } 491 ], 493 The same such "parent-reference" restrictions for non-NMDA 494 implementations can be represented based on the [RFC7223] and 495 [RFC7277] as: 497 "namespace": [ 498 { 499 "prefix": "if", 500 "uri": "urn:ietf:params:xml:ns:yang:ietf-interfaces" 501 }, 502 { 503 "prefix": "ni", 504 "uri": "urn:ietf:params:xml:ns:yang:ietf-network-instance" 505 } 506 ], 507 "mount-point": [ 508 { 509 "module": "ietf-network-instance", 510 "label": "vrf-root", 511 "shared-schema": { 512 "parent-reference": [ 513 "/if:interfaces/if:interface 514 [ni:bind-network-instance-name = current()/../ni:name]", 515 "/if:interfaces-state/if:interface 516 [if:name = /if:interfaces/if:interface 517 [ni:bind-ni-name = current()/../ni:name]/if:name]", 518 "/if:interfaces/if:interface/ip:ipv4 519 [ni:bind-network-instance-name = current()/../ni:name]", 520 "/if:interfaces-state/if:interface/ip:ipv4 521 [if:name = /if:interfaces/if:interface/ip:ipv4 522 [ni:bind-ni-name = current()/../ni:name]/if:name]", 523 "/if:interfaces/if:interface/ip:ipv6 524 [ni:bind-network-instance-name = current()/../ni:name]", 525 "/if:interfaces-state/if:interface/ip:ipv6 526 [if:name = /if:interfaces/if:interface/ip:ipv4 527 [ni:bind-ni-name = current()/../ni:name]/if:name]" 528 ] 529 } 530 } 531 ], 533 3.4. Network Instance Instantiation 535 Network instances may be controlled by clients using existing list 536 operations. When a list entry is created, a new instance is 537 instantiated. The models mounted under an NI root are expected to be 538 dependent on the server implementation. When a list entry is 539 deleted, an existing network instance is destroyed. For more 540 information, see [RFC7950] Section 7.8.6. 542 Once instantiated, host network device resources can be associated 543 with the new NI. As previously mentioned, this document augments 544 ietf-interfaces with the bind-ni-name leaf to support such 545 associations for interfaces. When a bind-ni-name is set to a valid 546 NI name, an implementation MUST take whatever steps are internally 547 necessary to assign the interface to the NI or provide an error 548 message (defined below) with an indication of why the assignment 549 failed. It is possible for the assignment to fail while processing 550 the set operation, or after asynchronous processing. Error 551 notification in the latter case is supported via a notification. 553 4. Security Considerations 555 The YANG modules specified in this document define a schema for data 556 that is designed to be accessed via network management protocols such 557 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 558 is the secure transport layer, and the mandatory-to-implement secure 559 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 560 is HTTPS, and the mandatory-to-implement secure transport is TLS 561 [RFC5246]. 563 The NETCONF access control model [RFC6536] provides the means to 564 restrict access for particular NETCONF or RESTCONF users to a 565 preconfigured subset of all available NETCONF or RESTCONF protocol 566 operations and content. 568 There are two different sets of security considerations to consider 569 in the context of this document. One set is security related to 570 information contained within mounted modules. The security 571 considerations for mounted modules are not substantively changed 572 based on the information being accessible within the context of an 573 NI. For example, when considering the modules defined in 574 [I-D.ietf-netmod-rfc8022bis], the security considerations identified 575 in that document are equally applicable, whether those modules are 576 accessed at a server's root or under an NI instance's root node. 578 The second area for consideration is information contained in the NI 579 module itself. NI information represents network configuration and 580 route distribution policy information. As such, the security of this 581 information is important, but it is fundamentally no different than 582 any other interface or routing configuration information that has 583 already been covered in [I-D.ietf-netmod-rfc7223bis] and 584 [I-D.ietf-netmod-rfc8022bis]. 586 The vulnerable "config true" parameters and subtrees are the 587 following: 589 /network-instances/network-instance: This list specifies the network 590 instances and the related control plane protocols configured on a 591 device. 593 /if:interfaces/if:interface/*/bind-network-instance-name: This leaf 594 indicates the NI instance to which an interface is assigned. 596 Unauthorized access to any of these lists can adversely affect the 597 routing subsystem of both the local device and the network. This may 598 lead to network malfunctions, delivery of packets to inappropriate 599 destinations and other problems. 601 5. IANA Considerations 603 This document registers a URI in the IETF XML registry [RFC3688]. 604 Following the format in RFC 3688, the following registration is 605 requested to be made. 607 URI: urn:ietf:params:xml:ns:yang:ietf-network-instance 609 Registrant Contact: The IESG. 611 XML: N/A, the requested URI is an XML namespace. 613 This document registers a YANG module in the YANG Module Names 614 registry [RFC6020]. 616 name: ietf-network-instance 617 namespace: urn:ietf:params:xml:ns:yang:ietf-network-instance 618 prefix: ni 619 reference: RFC XXXX 621 6. Network Instance Model 623 The structure of the model defined in this document is described by 624 the YANG module below. 626 file "ietf-network-instance@2018-03-20.yang" 627 module ietf-network-instance { 628 yang-version 1.1; 629 namespace "urn:ietf:params:xml:ns:yang:ietf-network-instance"; 630 prefix ni; 632 // import some basic types 634 import ietf-interfaces { 635 prefix if; 636 reference "draft-ietf-netmod-rfc7223bis: A YANG Data Model 637 for Interface Management"; 638 } 639 import ietf-ip { 640 prefix ip; 641 reference "draft-ietf-netmod-rfc7277bis: A YANG Data Model 642 for IP Management"; 643 } 644 import ietf-yang-schema-mount { 645 prefix yangmnt; 646 reference "draft-ietf-netmod-schema-mount: YANG Schema Mount"; 647 // RFC Ed.: Please replace this draft name with the 648 // corresponding RFC number 649 } 651 organization 652 "IETF Routing Area (rtgwg) Working Group"; 653 contact 654 "WG Web: 655 WG List: 657 Author: Lou Berger 658 659 Author: Christan Hopps 660 661 Author: Acee Lindem 662 663 Author: Dean Bogdanovic 664 "; 665 description 666 "This module is used to support multiple network instances 667 within a single physical or virtual device. Network 668 instances are commonly known as VRFs (virtual routing 669 and forwarding) and VSIs (virtual switching instances). 671 Copyright (c) 2017 IETF Trust and the persons 672 identified as authors of the code. All rights reserved. 674 Redistribution and use in source and binary forms, with or 675 without modification, is permitted pursuant to, and subject 676 to the license terms contained in, the Simplified BSD License 677 set forth in Section 4.c of the IETF Trust's Legal Provisions 678 Relating to IETF Documents 679 (http://trustee.ietf.org/license-info). 681 This version of this YANG module is part of RFC XXXX; see 682 the RFC itself for full legal notices."; 684 // RFC Ed.: replace XXXX with actual RFC number and remove 685 // this note 686 // RFC Ed.: please update TBD 688 revision 2018-03-20 { 689 description 690 "Initial revision."; 691 reference "RFC TBD"; 692 } 694 // top level device definition statements 696 container network-instances { 697 description 698 "Network instances each of which consists of a 699 VRFs (virtual routing and forwarding) and/or 700 VSIs (virtual switching instances)."; 701 reference "draft-ietf-rtgwg-rfc8022bis - A YANG Data Model 702 for Routing Management"; 703 list network-instance { 704 key "name"; 705 description 706 "List of network-instances."; 707 leaf name { 708 type string; 709 mandatory true; 710 description 711 "device scoped identifier for the network 712 instance."; 713 } 714 leaf enabled { 715 type boolean; 716 default "true"; 717 description 718 "Flag indicating whether or not the network 719 instance is enabled."; 720 } 721 leaf description { 722 type string; 723 description 724 "Description of the network instance 725 and its intended purpose."; 726 } 727 choice ni-type { 728 description 729 "This node serves as an anchor point for different types 730 of network instances. Each 'case' is expected to 731 differ in terms of the information needed in the 732 parent/core to support the NI, and may differ in their 733 mounted schema definition. When the mounted schema is 734 not expected to be the same for a specific type of NI 735 a mount point should be defined."; 736 } 737 choice root-type { 738 mandatory true; 739 description 740 "Well known mount points."; 741 container vrf-root { 742 description 743 "Container for mount point."; 744 yangmnt:mount-point "vrf-root" { 745 description 746 "Root for L3VPN type models. This will typically 747 not be an inline type mount point."; 748 } 749 } 750 container vsi-root { 751 description 752 "Container for mount point."; 753 yangmnt:mount-point "vsi-root" { 754 description 755 "Root for L2VPN type models. This will typically 756 not be an inline type mount point."; 757 } 758 } 759 container vv-root { 760 description 761 "Container for mount point."; 762 yangmnt:mount-point "vv-root" { 763 description 764 "Root models that support both L2VPN type bridging 765 and L3VPN type routing. This will typically 766 not be an inline type mount point."; 767 } 768 } 769 } 770 } 771 } 773 // augment statements 775 augment "/if:interfaces/if:interface" { 776 description 777 "Add a node for the identification of the network 778 instance associated with the information configured 779 on a interface. 781 Note that a standard error will be returned if the 782 identified leafref isn't present. If an interfaces cannot 783 be assigned for any other reason, the operation SHALL fail 784 with an error-tag of 'operation-failed' and an 785 error-app-tag of 'ni-assignment-failed'. A meaningful 786 error-info that indicates the source of the assignment 787 failure SHOULD also be provided."; 788 leaf bind-ni-name { 789 type leafref { 790 path "/network-instances/network-instance/name"; 791 } 792 description 793 "Network Instance to which an interface is bound."; 794 } 795 } 796 augment "/if:interfaces/if:interface/ip:ipv4" { 797 description 798 "Add a node for the identification of the network 799 instance associated with the information configured 800 on an IPv4 interface. 802 Note that a standard error will be returned if the 803 identified leafref isn't present. If an interfaces cannot 804 be assigned for any other reason, the operation SHALL fail 805 with an error-tag of 'operation-failed' and an 806 error-app-tag of 'ni-assignment-failed'. A meaningful 807 error-info that indicates the source of the assignment 808 failure SHOULD also be provided."; 809 leaf bind-ni-name { 810 type leafref { 811 path "/network-instances/network-instance/name"; 812 } 813 description 814 "Network Instance to which IPv4 interface is bound."; 815 } 816 } 817 augment "/if:interfaces/if:interface/ip:ipv6" { 818 description 819 "Add a node for the identification of the network 820 instance associated with the information configured 821 on an IPv6 interface. 823 Note that a standard error will be returned if the 824 identified leafref isn't present. If an interfaces cannot 825 be assigned for any other reason, the operation SHALL fail 826 with an error-tag of 'operation-failed' and an 827 error-app-tag of 'ni-assignment-failed'. A meaningful 828 error-info that indicates the source of the assignment 829 failure SHOULD also be provided."; 830 leaf bind-ni-name { 831 type leafref { 832 path "/network-instances/network-instance/name"; 834 } 835 description 836 "Network Instance to which IPv6 interface is bound."; 837 } 838 } 840 // notification statements 842 notification bind-ni-name-failed { 843 description 844 "Indicates an error in the association of an interface to an 845 NI. Only generated after success is initially returned when 846 bind-ni-name is set. 848 Note: some errors may need to be reported for multiple 849 associations, e.g., a single error may need to be reported 850 for an IPv4 and an IPv6 bind-ni-name. 852 At least one container with a bind-ni-name leaf MUST be 853 included in this notification."; 854 leaf name { 855 type leafref { 856 path "/if:interfaces/if:interface/if:name"; 857 } 858 mandatory true; 859 description 860 "Contains the interface name associated with the 861 failure."; 862 } 863 container interface { 864 description 865 "Generic interface type."; 866 leaf bind-ni-name { 867 type leafref { 868 path "/if:interfaces/if:interface/ni:bind-ni-name"; 869 } 870 description 871 "Contains the bind-ni-name associated with the 872 failure."; 873 } 874 } 875 container ipv4 { 876 description 877 "IPv4 interface type."; 878 leaf bind-ni-name { 879 type leafref { 880 path "/if:interfaces/if:interface" 881 + "/ip:ipv4/ni:bind-ni-name"; 883 } 884 description 885 "Contains the bind-ni-name associated with the 886 failure."; 887 } 888 } 889 container ipv6 { 890 description 891 "IPv6 interface type."; 892 leaf bind-ni-name { 893 type leafref { 894 path "/if:interfaces/if:interface" 895 + "/ip:ipv6/ni:bind-ni-name"; 896 } 897 description 898 "Contains the bind-ni-name associated with the 899 failure."; 900 } 901 } 902 leaf error-info { 903 type string; 904 description 905 "Optionally, indicates the source of the assignment 906 failure."; 907 } 908 } 909 } 910 912 7. References 914 7.1. Normative References 916 [I-D.ietf-netmod-revised-datastores] 917 Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 918 and R. Wilton, "Network Management Datastore 919 Architecture", draft-ietf-netmod-revised-datastores-10 920 (work in progress), January 2018. 922 [I-D.ietf-netmod-rfc7223bis] 923 Bjorklund, M., "A YANG Data Model for Interface 924 Management", draft-ietf-netmod-rfc7223bis-03 (work in 925 progress), January 2018. 927 [I-D.ietf-netmod-rfc7277bis] 928 Bjorklund, M., "A YANG Data Model for IP Management", 929 draft-ietf-netmod-rfc7277bis-03 (work in progress), 930 January 2018. 932 [I-D.ietf-netmod-schema-mount] 933 Bjorklund, M. and L. Lhotka, "YANG Schema Mount", draft- 934 ietf-netmod-schema-mount-08 (work in progress), October 935 2017. 937 [I-D.ietf-netmod-yang-tree-diagrams] 938 Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft- 939 ietf-netmod-yang-tree-diagrams-06 (work in progress), 940 February 2018. 942 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 943 Requirement Levels", BCP 14, RFC 2119, 944 DOI 10.17487/RFC2119, March 1997, 945 . 947 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 948 DOI 10.17487/RFC3688, January 2004, 949 . 951 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 952 (TLS) Protocol Version 1.2", RFC 5246, 953 DOI 10.17487/RFC5246, August 2008, 954 . 956 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 957 the Network Configuration Protocol (NETCONF)", RFC 6020, 958 DOI 10.17487/RFC6020, October 2010, 959 . 961 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 962 and A. Bierman, Ed., "Network Configuration Protocol 963 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 964 . 966 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 967 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 968 . 970 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 971 Protocol (NETCONF) Access Control Model", RFC 6536, 972 DOI 10.17487/RFC6536, March 2012, 973 . 975 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 976 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 977 . 979 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 980 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 981 May 2017, . 983 7.2. Informative References 985 [I-D.ietf-bess-l2vpn-yang] 986 Shah, H., Brissette, P., Chen, I., Hussain, I., Wen, B., 987 and K. Tiruveedhula, "YANG Data Model for MPLS-based 988 L2VPN", draft-ietf-bess-l2vpn-yang-08 (work in progress), 989 February 2018. 991 [I-D.ietf-bess-l3vpn-yang] 992 Jain, D., Patel, K., Brissette, P., Li, Z., Zhuang, S., 993 Liu, X., Haas, J., Esale, S., and B. Wen, "Yang Data Model 994 for BGP/MPLS L3 VPNs", draft-ietf-bess-l3vpn-yang-02 (work 995 in progress), October 2017. 997 [I-D.ietf-netmod-rfc8022bis] 998 Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for 999 Routing Management (NMDA Version)", draft-ietf-netmod- 1000 rfc8022bis-11 (work in progress), January 2018. 1002 [I-D.ietf-ospf-yang] 1003 Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem, 1004 "Yang Data Model for OSPF Protocol", draft-ietf-ospf- 1005 yang-10 (work in progress), March 2018. 1007 [I-D.ietf-rtgwg-device-model] 1008 Lindem, A., Berger, L., Bogdanovic, D., and C. Hopps, 1009 "Network Device YANG Logical Organization", draft-ietf- 1010 rtgwg-device-model-02 (work in progress), March 2017. 1012 [I-D.ietf-rtgwg-lne-model] 1013 Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. 1014 Liu, "YANG Model for Logical Network Elements", draft- 1015 ietf-rtgwg-lne-model-09 (work in progress), March 2018. 1017 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 1018 Private Network (VPN) Terminology", RFC 4026, 1019 DOI 10.17487/RFC4026, March 2005, 1020 . 1022 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1023 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1024 2006, . 1026 [RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer 1027 2 Virtual Private Networks (L2VPNs)", RFC 4664, 1028 DOI 10.17487/RFC4664, September 2006, 1029 . 1031 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 1032 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 1033 . 1035 [RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", 1036 RFC 7277, DOI 10.17487/RFC7277, June 2014, 1037 . 1039 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1040 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1041 . 1043 [RFC8022] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing 1044 Management", RFC 8022, DOI 10.17487/RFC8022, November 1045 2016, . 1047 Appendix A. Acknowledgments 1049 The Routing Area Yang Architecture design team members included Acee 1050 Lindem, Anees Shaikh, Christian Hopps, Dean Bogdanovic, Lou Berger, 1051 Qin Wu, Rob Shakir, Stephane Litkowski, and Yan Gang. Useful review 1052 comments were also received by Martin Bjorklund and John Scudder. 1054 This document was motivated by, and derived from, 1055 [I-D.ietf-rtgwg-device-model]. 1057 Thanks for AD and IETF last call comments from Alia Atlas, Liang Xia, 1058 Benoit Claise, and Adam Roach. 1060 The RFC text was produced using Marshall Rose's xml2rfc tool. 1062 Appendix B. Example NI usage 1064 The following subsections provide example uses of NIs. 1066 B.1. Configuration Data 1068 The following shows an example where two customer specific network 1069 instances are configured: 1071 { 1072 "ietf-network-instance:network-instances": { 1073 "network-instance": [ 1074 { 1075 "name": "vrf-red", 1076 "vrf-root": { 1077 "ietf-routing:routing": { 1078 "router-id": "192.0.2.1", 1079 "control-plane-protocols": { 1080 "control-plane-protocol": [ 1081 { 1082 "type": "ietf-routing:ospf", 1083 "name": "1", 1084 "ietf-ospf:ospf": { 1085 "af": "ipv4", 1086 "areas": { 1087 "area": [ 1088 { 1089 "area-id": "203.0.113.1", 1090 "interfaces": { 1091 "interface": [ 1092 { 1093 "name": "eth1", 1094 "cost": 10 1095 } 1096 ] 1097 } 1098 } 1099 ] 1100 } 1101 } 1102 } 1103 ] 1104 } 1105 } 1106 } 1107 }, 1108 { 1109 "name": "vrf-blue", 1110 "vrf-root": { 1111 "ietf-routing:routing": { 1112 "router-id": "192.0.2.2", 1113 "control-plane-protocols": { 1114 "control-plane-protocol": [ 1115 { 1116 "type": "ietf-routing:ospf", 1117 "name": "1", 1118 "ietf-ospf:ospf": { 1119 "af": "ipv4", 1120 "areas": { 1121 "area": [ 1122 { 1123 "area-id": "203.0.113.1", 1124 "interfaces": { 1125 "interface": [ 1126 { 1127 "name": "eth2", 1128 "cost": 10 1129 } 1130 ] 1131 } 1132 } 1133 ] 1134 } 1135 } 1136 } 1137 ] 1138 } 1139 } 1140 } 1141 } 1142 ] 1143 }, 1145 "ietf-interfaces:interfaces": { 1146 "interfaces": { 1147 "interface": [ 1148 { 1149 "name": "eth0", 1150 "ip:ipv4": { 1151 "address": [ 1152 { 1153 "ip": "192.0.2.10", 1154 "prefix-length": 24, 1155 } 1156 ] 1157 }, 1158 "ip:ipv6": { 1159 "address": [ 1160 { 1161 "ip": "2001:db8:0:2::10", 1162 "prefix-length": 64, 1163 } 1164 ] 1165 } 1166 }, 1167 { 1168 "name": "eth1", 1169 "ip:ipv4": { 1170 "address": [ 1171 { 1172 "ip": "192.0.2.11", 1173 "prefix-length": 24, 1174 } 1175 ] 1176 }, 1177 "ip:ipv6": { 1178 "address": [ 1179 { 1180 "ip": "2001:db8:0:2::11", 1181 "prefix-length": 64, 1182 } 1183 ] 1184 }, 1185 "ni:bind-network-instance-name": "vrf-red" 1186 }, 1187 { 1188 "name": "eth2", 1189 "ip:ipv4": { 1190 "address": [ 1191 { 1192 "ip": "192.0.2.11", 1193 "prefix-length": 24, 1194 } 1195 ] 1196 }, 1197 "ip:ipv6": { 1198 "address": [ 1199 { 1200 "ip": "2001:db8:0:2::11", 1201 "prefix-length": 64, 1202 } 1203 ] 1204 }, 1205 "ni:bind-network-instance-name": "vrf-blue" 1206 } 1207 ] 1208 } 1209 }, 1211 "ietf-system:system": { 1212 "authentication": { 1213 "user": [ 1214 { 1215 "name": "john", 1216 "password": "$0$password" 1217 } 1219 ] 1220 } 1221 } 1222 } 1224 B.2. State Data - Non-NMDA Version 1226 The following shows state data for the configuration example above 1227 based on [RFC7223], [RFC7277], and [RFC8022]. 1229 { 1230 "ietf-network-instance:network-instances": { 1231 "network-instance": [ 1232 { 1233 "name": "vrf-red", 1234 "vrf-root": { 1235 "ietf-yang-library:modules-state": { 1236 "module-set-id": "123e4567-e89b-12d3-a456-426655440000", 1237 "module": [ 1238 { 1239 "name": "ietf-yang-library", 1240 "revision": "2016-06-21", 1241 "namespace": 1242 "urn:ietf:params:xml:ns:yang:ietf-yang-library", 1243 "conformance-type": "implement" 1244 }, 1245 { 1246 "name": "ietf-ospf", 1247 "revision": "2018-03-03", 1248 "namespace": 1249 "urn:ietf:params:xml:ns:yang:ietf-ospf", 1250 "conformance-type": "implement" 1251 }, 1252 { 1253 "name": "ietf-routing", 1254 "revision": "2018-03-13", 1255 "namespace": 1256 "urn:ietf:params:xml:ns:yang:ietf-routing", 1257 "conformance-type": "implement" 1258 } 1259 ] 1260 }, 1261 "ietf-routing:routing-state": { 1262 "router-id": "192.0.2.1", 1263 "control-plane-protocols": { 1264 "control-plane-protocol": [ 1265 { 1266 "type": "ietf-routing:ospf", 1267 "name": "1", 1268 "ietf-ospf:ospf": { 1269 "af": "ipv4", 1270 "areas": { 1271 "area": [ 1272 { 1273 "area-id": "203.0.113.1", 1274 "interfaces": { 1275 "interface": [ 1276 { 1277 "name": "eth1", 1278 "cost": 10 1279 } 1280 ] 1281 } 1282 } 1283 ] 1284 } 1285 } 1286 } 1287 ] 1288 } 1289 } 1290 } 1291 }, 1292 { 1293 "name": "vrf-blue", 1294 "vrf-root": { 1295 "ietf-yang-library:modules-state": { 1296 "module-set-id": "123e4567-e89b-12d3-a456-426655440000", 1297 "module": [ 1298 { 1299 "name": "ietf-yang-library", 1300 "revision": "2016-06-21", 1301 "namespace": 1302 "urn:ietf:params:xml:ns:yang:ietf-yang-library", 1303 "conformance-type": "implement" 1304 }, 1305 { 1306 "name": "ietf-ospf", 1307 "revision": "2018-03-03", 1308 "namespace": 1309 "urn:ietf:params:xml:ns:yang:ietf-ospf", 1310 "conformance-type": "implement" 1311 }, 1312 { 1313 "name": "ietf-routing", 1314 "revision": "2018-03-13", 1315 "namespace": 1316 "urn:ietf:params:xml:ns:yang:ietf-routing", 1317 "conformance-type": "implement" 1318 } 1319 ] 1320 }, 1321 "ietf-routing:routing-state": { 1322 "router-id": "192.0.2.2", 1323 "control-plane-protocols": { 1324 "control-plane-protocol": [ 1325 { 1326 "type": "ietf-routing:ospf", 1327 "name": "1", 1328 "ietf-ospf:ospf": { 1329 "af": "ipv4", 1330 "areas": { 1331 "area": [ 1332 { 1333 "area-id": "203.0.113.1", 1334 "interfaces": { 1335 "interface": [ 1336 { 1337 "name": "eth2", 1338 "cost": 10 1339 } 1340 ] 1341 } 1342 } 1343 ] 1344 } 1345 } 1346 } 1347 ] 1348 } 1349 } 1350 } 1351 } 1352 ] 1353 }, 1355 "ietf-interfaces:interfaces-state": { 1356 "interfaces": { 1357 "interface": [ 1358 { 1359 "name": "eth0", 1360 "type": "iana-if-type:ethernetCsmacd", 1361 "oper-status": "up", 1362 "phys-address": "00:01:02:A1:B1:C0", 1363 "statistics": { 1364 "discontinuity-time": "2017-06-26T12:34:56-05:00" 1365 }, 1366 "ip:ipv4": { 1367 "address": [ 1368 { 1369 "ip": "192.0.2.10", 1370 "prefix-length": 24, 1371 } 1372 ] 1373 } 1374 "ip:ipv6": { 1375 "address": [ 1376 { 1377 "ip": "2001:db8:0:2::10", 1378 "prefix-length": 64, 1379 } 1380 ] 1381 } 1382 }, 1383 { 1384 "name": "eth1", 1385 "type": "iana-if-type:ethernetCsmacd", 1386 "oper-status": "up", 1387 "phys-address": "00:01:02:A1:B1:C1", 1388 "statistics": { 1389 "discontinuity-time": "2017-06-26T12:34:56-05:00" 1390 }, 1391 "ip:ipv4": { 1392 "address": [ 1393 { 1394 "ip": "192.0.2.11", 1395 "prefix-length": 24, 1396 } 1397 ] 1398 } 1399 "ip:ipv6": { 1400 "address": [ 1401 { 1402 "ip": "2001:db8:0:2::11", 1403 "prefix-length": 64, 1404 } 1405 ] 1406 } 1407 }, 1408 { 1409 "name": "eth2", 1410 "type": "iana-if-type:ethernetCsmacd", 1411 "oper-status": "up", 1412 "phys-address": "00:01:02:A1:B1:C2", 1413 "statistics": { 1414 "discontinuity-time": "2017-06-26T12:34:56-05:00" 1415 }, 1416 "ip:ipv4": { 1417 "address": [ 1418 { 1419 "ip": "192.0.2.11", 1420 "prefix-length": 24, 1421 } 1422 ] 1423 } 1424 "ip:ipv6": { 1425 "address": [ 1426 { 1427 "ip": "2001:db8:0:2::11", 1428 "prefix-length": 64, 1429 } 1430 ] 1431 } 1432 } 1433 ] 1434 } 1435 }, 1437 "ietf-system:system-state": { 1438 "platform": { 1439 "os-name": "NetworkOS" 1440 } 1441 } 1443 "ietf-yang-library:modules-state": { 1444 "module-set-id": "123e4567-e89b-12d3-a456-426655440000", 1445 "module": [ 1446 { 1447 "name": "iana-if-type", 1448 "revision": "2014-05-08", 1449 "namespace": 1450 "urn:ietf:params:xml:ns:yang:iana-if-type", 1451 "conformance-type": "import" 1452 }, 1453 { 1454 "name": "ietf-inet-types", 1455 "revision": "2013-07-15", 1456 "namespace": 1457 "urn:ietf:params:xml:ns:yang:ietf-inet-types", 1458 "conformance-type": "import" 1460 }, 1461 { 1462 "name": "ietf-interfaces", 1463 "revision": "2014-05-08", 1464 "feature": [ 1465 "arbitrary-names", 1466 "pre-provisioning" 1467 ], 1468 "namespace": 1469 "urn:ietf:params:xml:ns:yang:ietf-interfaces", 1470 "conformance-type": "implement" 1471 }, 1472 { 1473 "name": "ietf-ip", 1474 "revision": "2014-06-16", 1475 "namespace": 1476 "urn:ietf:params:xml:ns:yang:ietf-ip", 1477 "conformance-type": "implement" 1478 }, 1479 { 1480 "name": "ietf-network-instance", 1481 "revision": "2018-02-03", 1482 "feature": [ 1483 "bind-network-instance-name" 1484 ], 1485 "namespace": 1486 "urn:ietf:params:xml:ns:yang:ietf-network-instance", 1487 "conformance-type": "implement" 1488 }, 1489 { 1490 "name": "ietf-ospf", 1491 "revision": "2018-03-03", 1492 "namespace": "urn:ietf:params:xml:ns:yang:ietf-ospf", 1493 "conformance-type": "implement" 1494 }, 1495 { 1496 "name": "ietf-routing", 1497 "revision": "2018-03-13", 1498 "namespace": 1499 "urn:ietf:params:xml:ns:yang:ietf-routing", 1500 "conformance-type": "implement" 1501 }, 1502 { 1503 "name": "ietf-system", 1504 "revision": "2014-08-06", 1505 "namespace": 1506 "urn:ietf:params:xml:ns:yang:ietf-system", 1507 "conformance-type": "implement" 1509 }, 1510 { 1511 "name": "ietf-yang-library", 1512 "revision": "2016-06-21", 1513 "namespace": 1514 "urn:ietf:params:xml:ns:yang:ietf-yang-library", 1515 "conformance-type": "implement" 1516 }, 1517 { 1518 "name": "ietf-yang-schema-mount", 1519 "revision": "2017-05-16", 1520 "namespace": 1521 "urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount", 1522 "conformance-type": "implement" 1523 }, 1524 { 1525 "name": "ietf-yang-types", 1526 "revision": "2013-07-15", 1527 "namespace": 1528 "urn:ietf:params:xml:ns:yang:ietf-yang-types", 1529 "conformance-type": "import" 1530 } 1531 ] 1532 }, 1534 "ietf-yang-schema-mount:schema-mounts": { 1535 "mount-point": [ 1536 { 1537 "module": "ietf-network-instance", 1538 "label": "vrf-root", 1539 "shared-schema": { 1540 "parent-reference": [ 1541 "/*[namespace-uri() = 'urn:ietf:...:ietf-interfaces']" 1542 ] 1543 } 1544 } 1545 ] 1546 } 1547 } 1549 B.3. State Data - NMDA Version 1551 The following shows state data for the configuration example above 1552 based on [I-D.ietf-netmod-rfc7223bis], [I-D.ietf-netmod-rfc7277bis], 1553 and [I-D.ietf-netmod-rfc8022bis]. 1555 { 1556 "ietf-network-instance:network-instances": { 1557 "network-instance": [ 1558 { 1559 "name": "vrf-red", 1560 "vrf-root": { 1561 "ietf-yang-library:yang-library": { 1562 "checksum": "41e2ab5dc325f6d86f743e8da3de323f1a61a801", 1563 "module-set": [ 1564 { 1565 "name": "ni-modules", 1566 "module": [ 1567 { 1568 "name": "ietf-yang-library", 1569 "revision": "2016-06-21", 1570 "namespace": 1571 "urn:ietf:params:xml:ns:yang:ietf-yang-library", 1572 "conformance-type": "implement" 1573 }, 1574 { 1575 "name": "ietf-ospf", 1576 "revision": "2018-03-03", 1577 "namespace": 1578 "urn:ietf:params:xml:ns:yang:ietf-ospf", 1579 "conformance-type": "implement" 1580 }, 1581 { 1582 "name": "ietf-routing", 1583 "revision": "2018-03-13", 1584 "namespace": 1585 "urn:ietf:params:xml:ns:yang:ietf-routing", 1586 "conformance-type": "implement" 1587 } 1588 ], 1589 "import-only-module": [ 1590 { 1591 "name": "ietf-inet-types", 1592 "revision": "2013-07-15", 1593 "namespace": "urn:ietf:params:xml:ns:yang:ietf-inet-types" 1594 }, 1595 { 1596 "name": "ietf-yang-types", 1597 "revision": "2013-07-15", 1598 "namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-types" 1599 }, 1600 { 1601 "name": "ietf-datastores", 1602 "revision": "2018-02-14", 1603 "namespace": "urn:ietf:params:xml:ns:yang:ietf-datastores" 1604 } 1606 ] 1607 } 1608 ], 1609 "schema": [ 1610 { 1611 "name": "ni-schema", 1612 "module-set": [ "ni-modules" ] 1613 } 1614 ], 1615 "datastore": [ 1616 { 1617 "name": "ietf-datastores:running", 1618 "schema": "ni-schema" 1619 }, 1620 { 1621 "name": "ietf-datastores:operational", 1622 "schema": "ni-schema" 1623 } 1624 ] 1625 }, 1626 "ietf-routing:routing": { 1627 "router-id": "192.0.2.1", 1628 "control-plane-protocols": { 1629 "control-plane-protocol": [ 1630 { 1631 "type": "ietf-routing:ospf", 1632 "name": "1", 1633 "ietf-ospf:ospf": { 1634 "af": "ipv4", 1635 "areas": { 1636 "area": [ 1637 { 1638 "area-id": "203.0.113.1", 1639 "interfaces": { 1640 "interface": [ 1641 { 1642 "name": "eth1", 1643 "cost": 10 1644 } 1645 ] 1646 } 1647 } 1648 ] 1649 } 1650 } 1651 } 1652 ] 1653 } 1655 } 1656 } 1657 }, 1658 { 1659 "name": "vrf-blue", 1660 "vrf-root": { 1661 "ietf-yang-library:yang-library": { 1662 "checksum": "41e2ab5dc325f6d86f743e8da3de323f1a61a801", 1663 "module-set": [ 1664 { 1665 "name": "ni-modules", 1666 "module": [ 1667 { 1668 "name": "ietf-yang-library", 1669 "revision": "2016-06-21", 1670 "namespace": 1671 "urn:ietf:params:xml:ns:yang:ietf-yang-library", 1672 "conformance-type": "implement" 1673 }, 1674 { 1675 "name": "ietf-ospf", 1676 "revision": "2018-03-03", 1677 "namespace": 1678 "urn:ietf:params:xml:ns:yang:ietf-ospf", 1679 "conformance-type": "implement" 1680 }, 1681 { 1682 "name": "ietf-routing", 1683 "revision": "2018-03-13", 1684 "namespace": 1685 "urn:ietf:params:xml:ns:yang:ietf-routing", 1686 "conformance-type": "implement" 1687 } 1688 ], 1689 "import-only-module": [ 1690 { 1691 "name": "ietf-inet-types", 1692 "revision": "2013-07-15", 1693 "namespace": "urn:ietf:params:xml:ns:yang:ietf-inet-types" 1694 }, 1695 { 1696 "name": "ietf-yang-types", 1697 "revision": "2013-07-15", 1698 "namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-types" 1699 }, 1700 { 1701 "name": "ietf-datastores", 1702 "revision": "2018-02-14", 1703 "namespace": "urn:ietf:params:xml:ns:yang:ietf-datastores" 1704 } 1705 ] 1706 } 1707 ], 1708 "schema": [ 1709 { 1710 "name": "ni-schema", 1711 "module-set": [ "ni-modules" ] 1712 } 1713 ], 1714 "datastore": [ 1715 { 1716 "name": "ietf-datastores:running", 1717 "schema": "ni-schema" 1718 }, 1719 { 1720 "name": "ietf-datastores:operational", 1721 "schema": "ni-schema" 1722 } 1723 ] 1724 }, 1725 "ietf-routing:routing": { 1726 "router-id": "192.0.2.2", 1727 "control-plane-protocols": { 1728 "control-plane-protocol": [ 1729 { 1730 "type": "ietf-routing:ospf", 1731 "name": "1", 1732 "ietf-ospf:ospf": { 1733 "af": "ipv4", 1734 "areas": { 1735 "area": [ 1736 { 1737 "area-id": "203.0.113.1", 1738 "interfaces": { 1739 "interface": [ 1740 { 1741 "name": "eth2", 1742 "cost": 10 1743 } 1744 ] 1745 } 1746 } 1747 ] 1748 } 1749 } 1750 } 1752 ] 1753 } 1754 } 1755 } 1756 } 1757 ] 1758 }, 1760 "ietf-interfaces:interfaces": { 1761 "interfaces": { 1762 "interface": [ 1763 { 1764 "name": "eth0", 1765 "type": "iana-if-type:ethernetCsmacd", 1766 "oper-status": "up", 1767 "phys-address": "00:01:02:A1:B1:C0", 1768 "statistics": { 1769 "discontinuity-time": "2017-06-26T12:34:56-05:00" 1770 }, 1771 "ip:ipv4": { 1772 "address": [ 1773 { 1774 "ip": "192.0.2.10", 1775 "prefix-length": 24, 1776 } 1777 ] 1778 } 1779 "ip:ipv6": { 1780 "address": [ 1781 { 1782 "ip": "2001:db8:0:2::10", 1783 "prefix-length": 64, 1784 } 1785 ] 1786 } 1787 }, 1788 { 1789 "name": "eth1", 1790 "type": "iana-if-type:ethernetCsmacd", 1791 "oper-status": "up", 1792 "phys-address": "00:01:02:A1:B1:C1", 1793 "statistics": { 1794 "discontinuity-time": "2017-06-26T12:34:56-05:00" 1795 }, 1796 "ip:ipv4": { 1797 "address": [ 1798 { 1799 "ip": "192.0.2.11", 1800 "prefix-length": 24, 1801 } 1802 ] 1803 } 1804 "ip:ipv6": { 1805 "address": [ 1806 { 1807 "ip": "2001:db8:0:2::11", 1808 "prefix-length": 64, 1809 } 1810 ] 1811 } 1812 }, 1813 { 1814 "name": "eth2", 1815 "type": "iana-if-type:ethernetCsmacd", 1816 "oper-status": "up", 1817 "phys-address": "00:01:02:A1:B1:C2", 1818 "statistics": { 1819 "discontinuity-time": "2017-06-26T12:34:56-05:00" 1820 }, 1821 "ip:ipv4": { 1822 "address": [ 1823 { 1824 "ip": "192.0.2.11", 1825 "prefix-length": 24, 1826 } 1827 ] 1828 } 1829 "ip:ipv6": { 1830 "address": [ 1831 { 1832 "ip": "2001:db8:0:2::11", 1833 "prefix-length": 64, 1834 } 1835 ] 1836 } 1837 } 1838 ] 1839 } 1840 }, 1842 "ietf-system:system-state": { 1843 "platform": { 1844 "os-name": "NetworkOS" 1845 } 1846 } 1847 "ietf-yang-library:modules-state": { 1848 "module-set-id": "123e4567-e89b-12d3-a456-426655440000", 1849 "module": [ 1850 { 1851 "name": "iana-if-type", 1852 "revision": "2014-05-08", 1853 "namespace": 1854 "urn:ietf:params:xml:ns:yang:iana-if-type", 1855 "conformance-type": "import" 1856 }, 1857 { 1858 "name": "ietf-inet-types", 1859 "revision": "2013-07-15", 1860 "namespace": 1861 "urn:ietf:params:xml:ns:yang:ietf-inet-types", 1862 "conformance-type": "import" 1863 }, 1864 { 1865 "name": "ietf-interfaces", 1866 "revision": "2018-01-09", 1867 "feature": [ 1868 "arbitrary-names", 1869 "pre-provisioning" 1870 ], 1871 "namespace": 1872 "urn:ietf:params:xml:ns:yang:ietf-interfaces", 1873 "conformance-type": "implement" 1874 }, 1875 { 1876 "name": "ietf-ip", 1877 "revision": "2018-01-09", 1878 "namespace": 1879 "urn:ietf:params:xml:ns:yang:ietf-ip", 1880 "conformance-type": "implement" 1881 }, 1882 { 1883 "name": "ietf-network-instance", 1884 "revision": "2018-02-03", 1885 "feature": [ 1886 "bind-network-instance-name" 1887 ], 1888 "namespace": 1889 "urn:ietf:params:xml:ns:yang:ietf-network-instance", 1890 "conformance-type": "implement" 1891 }, 1892 { 1893 "name": "ietf-ospf", 1894 "revision": "2017-10-30", 1895 "namespace": "urn:ietf:params:xml:ns:yang:ietf-ospf", 1896 "conformance-type": "implement" 1897 }, 1898 { 1899 "name": "ietf-routing", 1900 "revision": "2018-01-25", 1901 "namespace": 1902 "urn:ietf:params:xml:ns:yang:ietf-routing", 1903 "conformance-type": "implement" 1904 }, 1905 { 1906 "name": "ietf-system", 1907 "revision": "2014-08-06", 1908 "namespace": 1909 "urn:ietf:params:xml:ns:yang:ietf-system", 1910 "conformance-type": "implement" 1911 }, 1912 { 1913 "name": "ietf-yang-library", 1914 "revision": "2016-06-21", 1915 "namespace": 1916 "urn:ietf:params:xml:ns:yang:ietf-yang-library", 1917 "conformance-type": "implement" 1918 }, 1919 { 1920 "name": "ietf-yang-schema-mount", 1921 "revision": "2017-05-16", 1922 "namespace": 1923 "urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount", 1924 "conformance-type": "implement" 1925 }, 1926 { 1927 "name": "ietf-yang-types", 1928 "revision": "2013-07-15", 1929 "namespace": 1930 "urn:ietf:params:xml:ns:yang:ietf-yang-types", 1931 "conformance-type": "import" 1932 } 1933 ] 1934 }, 1936 "ietf-yang-schema-mount:schema-mounts": { 1937 "mount-point": [ 1938 { 1939 "module": "ietf-network-instance", 1940 "label": "vrf-root", 1941 "shared-schema": { 1942 "parent-reference": [ 1943 "/*[namespace-uri() = 'urn:ietf:...:ietf-interfaces']" 1944 ] 1945 } 1946 } 1947 ] 1948 } 1949 } 1951 Authors' Addresses 1953 Lou Berger 1954 LabN Consulting, L.L.C. 1956 Email: lberger@labn.net 1958 Christan Hopps 1959 Deutsche Telekom 1961 Email: chopps@chopps.org 1963 Acee Lindem 1964 Cisco Systems 1965 301 Midenhall Way 1966 Cary, NC 27513 1967 USA 1969 Email: acee@cisco.com 1971 Dean Bogdanovic 1973 Email: ivandean@gmail.com 1975 Xufeng Liu 1976 Jabil 1978 Email: Xufeng_Liu@jabil.com