idnits 2.17.1 draft-ietf-rtgwg-ni-model-09.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 5, 2018) is 2271 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 == Outdated reference: A later version (-06) exists of draft-ietf-netmod-yang-tree-diagrams-05 ** 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-07 == 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-09 == Outdated reference: A later version (-10) exists of draft-ietf-rtgwg-lne-model-05 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 2 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: August 9, 2018 Deutsche Telekom 6 A. Lindem 7 Cisco Systems 8 D. Bogdanovic 10 X. Liu 11 Jabil 12 February 5, 2018 14 YANG Network Instances 15 draft-ietf-rtgwg-ni-model-09 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 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on August 9, 2018. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Network Instances . . . . . . . . . . . . . . . . . . . . . . 5 63 3.1. NI Types and Mount Points . . . . . . . . . . . . . . . . 6 64 3.1.1. Well Known Mount Points . . . . . . . . . . . . . . . 7 65 3.1.2. NI Type Example . . . . . . . . . . . . . . . . . . . 8 66 3.2. NIs and Interfaces . . . . . . . . . . . . . . . . . . . 9 67 3.3. Network Instance Management . . . . . . . . . . . . . . . 10 68 3.4. Network Instance Instantiation . . . . . . . . . . . . . 12 69 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 70 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 71 6. Network Instance Model . . . . . . . . . . . . . . . . . . . 14 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 73 7.1. Normative References . . . . . . . . . . . . . . . . . . 20 74 7.2. Informative References . . . . . . . . . . . . . . . . . 22 75 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 23 76 Appendix B. Example NI usage . . . . . . . . . . . . . . . . . . 23 77 B.1. Configuration Data . . . . . . . . . . . . . . . . . . . 23 78 B.2. State Data . . . . . . . . . . . . . . . . . . . . . . . 26 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 81 1. Introduction 83 This document defines the second of two new modules that are defined 84 to support the configuration and operation of network-devices that 85 allow for the partitioning of resources from both, or either, 86 management and networking perspectives. Both leverage the YANG 87 functionality enabled by YANG Schema Mount 88 [I-D.ietf-netmod-schema-mount]. 90 The first form of resource partitioning provides a logical 91 partitioning of a network device where each partition is separately 92 managed as essentially an independent network element which is 93 'hosted' by the base network device. These hosted network elements 94 are referred to as logical network elements, or LNEs, and are 95 supported by the logical-network-element module defined in 96 [I-D.ietf-rtgwg-lne-model]. That module is used to identify LNEs and 97 associate resources from the network-device with each LNE. LNEs 98 themselves are represented in YANG as independent network devices; 99 each accessed independently. Examples of vendor terminology for an 100 LNE include logical system or logical router, and virtual switch, 101 chassis, or fabric. 103 The second form, which is defined in this document, provides support 104 for what is commonly referred to as Virtual Routing and Forwarding 105 (VRF) instances as well as Virtual Switch Instances (VSI), see 106 [RFC4026] and [RFC4664]. In this form of resource partitioning, 107 multiple control plane and forwarding/bridging instances are provided 108 by and managed via a single (physical or logical) network device. 109 This form of resource partitioning is referred to as a Network 110 Instance and is supported by the network-instance module defined 111 below. Configuration and operation of each network-instance is 112 always via the network device and the network-instance module. 114 One notable difference between the LNE model and the NI model is that 115 the NI model provides a framework for VRF and VSI management. This 116 document envisions the separate definition of VRF and VSI, i.e., L3 117 and L2 VPN, technology specific models. An example of such can be 118 found in the emerging L3VPN model defined in 119 [I-D.ietf-bess-l3vpn-yang] and the examples discussed below. 121 1.1. Terminology 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 125 "OPTIONAL" in this document are to be interpreted as described in BCP 126 14 [RFC2119] [RFC8174] when, and only when, they appear in all 127 capitals, as shown here. 129 Readers are expected to be familiar with terms and concepts of YANG 130 [RFC7950] and YANG Schema Mount [I-D.ietf-netmod-schema-mount]. 132 This document uses the graphical representation of data models 133 defined in [I-D.ietf-netmod-yang-tree-diagrams]. 135 2. Overview 137 In this document, we consider network devices that support protocols 138 and functions defined within the IETF, e.g, routers, firewalls, and 139 hosts. Such devices may be physical or virtual, e.g., a classic 140 router with custom hardware or one residing within a server-based 141 virtual machine implementing a virtual network function (VNF). Each 142 device may sub-divide their resources into logical network elements 143 (LNEs) each of which provides a managed logical device. Examples of 144 vendor terminology for an LNE include logical system or logical 145 router, and virtual switch, chassis, or fabric. Each LNE may also 146 support virtual routing and forwarding (VRF) and virtual switching 147 instance (VSI) functions, which are referred to below as a network 148 instances (NIs). This breakdown is represented in Figure 1. 150 ,''''''''''''''''''''''''''''''''''''''''''''''`. 151 | Network Device (Physical or Virtual) | 152 | ..................... ..................... | 153 | : Logical Network : : Logical Network : | 154 | : Element : : Element : | 155 | :+-----+-----+-----+: :+-----+-----+-----+: | 156 | :| Net | Net | Net |: :| Net | Net | Net |: | 157 | :|Inst.|Inst.|Inst.|: :|Inst.|Inst.|Inst.|: | 158 | :+-----+-----+-----+: :+-----+-----+-----+: | 159 | : | | | | | | : : | | | | | | : | 160 | :..|.|...|.|...|.|..: :..|.|...|.|...|.|..: | 161 | | | | | | | | | | | | | | 162 `'''|'|'''|'|'''|'|'''''''''|'|'''|'|'''|'|''''' 163 | | | | | | | | | | | | 164 Interfaces Interfaces 166 Figure 1: Module Element Relationships 168 A model for LNEs is described in [I-D.ietf-rtgwg-lne-model] and the 169 model for NIs is covered in this document in Section 3. 171 The current interface management model [I-D.ietf-netmod-rfc7223bis] 172 is impacted by the definition of LNEs and NIs. This document and 173 [I-D.ietf-rtgwg-lne-model] define augmentations to the interface 174 module to support LNEs and NIs. 176 The network instance model supports the configuration of VRFs and 177 VSIs. Each instance is supported by information that relates to the 178 device, for example the route target used when advertising VRF routes 179 via the mechanisms defined in [RFC4364], and information that relates 180 to the internal operation of the NI, for example for routing 181 protocols [I-D.ietf-netmod-rfc8022bis] and OSPF [I-D.ietf-ospf-yang]. 182 This document defines the network-instance module that provides a 183 basis for the management of both types of information. 185 NI information that relates to the device, including the assignment 186 of interfaces to NIs, is defined as part of this document. The 187 defined module also provides a placeholder for the definition of NI- 188 technology specific information both at the device level and for NI 189 internal operation. Information related to NI internal operation is 190 supported via schema mount [I-D.ietf-netmod-schema-mount] and 191 mounting appropriate modules under the mount point. Well known mount 192 points are defined for L3VPN, L2VPN, and L2+L3VPN NI types. 194 3. Network Instances 196 The network instance container is used to represent virtual routing 197 and forwarding instances (VRFs) and virtual switching instances 198 (VSIs). VRFs and VSIs are commonly used to isolate routing and 199 switching domains, for example to create virtual private networks, 200 each with their own active protocols and routing/switching policies. 201 The model supports both core/provider and virtual instances. Core/ 202 provider instance information is accessible at the top level of the 203 server, while virtual instance information is accessible under the 204 root schema mount points. 206 The NI model can be represented using the tree format defined in 207 [I-D.ietf-netmod-yang-tree-diagrams] as: 209 module: ietf-network-instance 210 +--rw network-instances 211 +--rw network-instance* [name] 212 +--rw name string 213 +--rw enabled? boolean 214 +--rw description? string 215 +--rw (ni-type)? 216 +--rw (root-type) 217 +--:(vrf-root) 218 | +--mp vrf-root 219 +--:(vsi-root) 220 | +--mp vsi-root 221 +--:(vv-root) 222 +--mp vv-root 223 augment /if:interfaces/if:interface: 224 +--rw bind-ni-name? -> /network-instances/network-instance/name 225 augment /if:interfaces/if:interface/ip:ipv4: 226 +--rw bind-ni-name? -> /network-instances/network-instance/name 227 augment /if:interfaces/if:interface/ip:ipv6: 228 +--rw bind-ni-name? -> /network-instances/network-instance/name 230 notifications: 231 +---n bind-ni-name-failed 232 +--ro name -> /if:interfaces/interface/name 233 +--ro interface 234 | +--ro bind-ni-name? 235 | -> /if:interfaces/interface/ni:bind-ni-name 236 +--ro ipv4 237 | +--ro bind-ni-name? 238 | -> /if:interfaces/interface/ip:ipv4/ni:bind-ni-name 239 +--ro ipv6 240 | +--ro bind-ni-name? 241 | -> /if:interfaces/interface/ip:ipv6/ni:bind-ni-name 242 +--ro error-info? string 244 A network instance is identified by a 'name' string. This string is 245 used both as an index within the network-instance module and to 246 associate resources with a network instance as shown above in the 247 interface augmentation. The ni-type and root-type choice statements 248 are used to support different types of L2 and L3 VPN technologies. 249 The bind-ni-name-failed notification is used in certain failure 250 cases. 252 3.1. NI Types and Mount Points 254 The network-instance module is structured to facilitate the 255 definition of information models for specific types of VRFs and VSIs 256 using augmentations. For example, the information needed to support 257 VPLS, VxLAN and EVPN based L2VPNs are likely to be quite different. 258 Example models under development that could be restructured to take 259 advantage on NIs include, for L3VPNs [I-D.ietf-bess-l3vpn-yang] and 260 for L2VPNs [I-D.ietf-bess-l2vpn-yang]. 262 Documents defining new YANG models for the support of specific types 263 of network instances should augment the network instance module. The 264 basic structure that should be used for such augmentations include a 265 case statement, with containers for configuration and state data and 266 finally, when needed, a type specific mount point. Generally ni 267 types, are expected to not need to define type specific mount points, 268 but rather reuse one of the well known mount point, as defined in the 269 next section. The following is an example type specific 270 augmentation: 272 augment "/ni:network-instances/ni:network-instance/ni:ni-type" { 273 case l3vpn { 274 container l3vpn { 275 ... 276 } 277 container l3vpn-state { 278 ... 279 } 280 } 281 } 283 3.1.1. Well Known Mount Points 285 YANG Schema Mount, [I-D.ietf-netmod-schema-mount], identifies mount 286 points by name within a module. This definition allows for the 287 definition of mount points whose schema can be shared across ni- 288 types. As discussed above, ni-types largely differ in the 289 configuration information needed in the core/top level instance to 290 support the NI, rather than in the information represented within an 291 NI. This allows the use of shared mount points across certain NI 292 types. 294 The expectation is that there are actually very few different schema 295 that need to be defined to support NIs on an implementation. In 296 particular, it is expected that the following three forms of NI 297 schema are needed, and each can be defined with a well known mount 298 point that can be reused by future modules defining ni-types. 300 The three well known mount points are: 302 vrf-root 303 vrf-root is intended for use with L3VPN type ni-types. 305 vsi-root 306 vsi-root is intended for use with L2VPN type ni-types. 308 vv-root 309 vv-root is intended for use with ni-types that simultaneously 310 support L2VPN bridging and L3VPN routing capabilities. 312 Future model definitions should use the above mount points whenever 313 possible. When a well known mount point isn't appropriate, a model 314 may define a type specific mount point via augmentation. 316 3.1.2. NI Type Example 318 The following is an example of an L3VPN VRF using a hypothetical 319 augmentation to the networking instance schema defined in 320 [I-D.ietf-bess-l3vpn-yang]. More detailed examples can be found in 321 Appendix B. 323 module: ietf-network-instance 324 +--rw network-instances 325 +--rw network-instance* [name] 326 +--rw name string 327 +--rw enabled? boolean 328 +--rw description? string 329 +--rw (ni-type)? 330 | +--:(l3vpn) 331 | +--rw l3vpn:l3vpn 332 | | ... // config data 333 | +--ro l3vpn:l3vpn-state 334 | | ... // state data 335 +--rw (root-type) 336 +--:(vrf-root) 337 +--mp vrf-root 338 +--rw rt:routing/ 339 | +--rw router-id? yang:dotted-quad 340 | +--rw control-plane-protocols 341 | +--rw control-plane-protocol* [type name] 342 | +--rw ospf:ospf/ 343 | +--rw instance* [af] 344 | +--rw areas 345 | +--rw area* [area-id] 346 | +--rw interfaces 347 | +--rw interface* [name] 348 | +--rw name if:interface-ref 349 | +--rw cost? uint16 350 +--ro if:interfaces@ 351 | ... 353 This shows YANG Routing Management [I-D.ietf-netmod-rfc8022bis] and 354 YANG OSPF [I-D.ietf-ospf-yang] as mounted modules. The mounted 355 modules can reference interface information via a parent-reference to 356 the containers defined in [I-D.ietf-netmod-rfc7223bis]. 358 3.2. NIs and Interfaces 360 Interfaces are a crucial part of any network device's configuration 361 and operational state. They generally include a combination of raw 362 physical interfaces, link-layer interfaces, addressing configuration, 363 and logical interfaces that may not be tied to any physical 364 interface. Several system services, and layer 2 and layer 3 365 protocols may also associate configuration or operational state data 366 with different types of interfaces (these relationships are not shown 367 for simplicity). The interface management model is defined by 368 [I-D.ietf-netmod-rfc7223bis]. 370 As shown below, the network-instance module augments the existing 371 interface management model by adding a name which is used on 372 interface or sub-interface types to identify an associated network 373 instance. Similarly, this name is also added for IPv4 and IPv6 374 types, as defined in [I-D.ietf-netmod-rfc7277bis]. 376 The following is an example of envisioned usage. The interfaces 377 container includes a number of commonly used components as examples: 379 module: ietf-interfaces 380 +--rw interfaces 381 | +--rw interface* [name] 382 | +--rw name string 383 | +--rw ip:ipv4! 384 | | +--rw ip:enabled? boolean 385 | | +--rw ip:forwarding? boolean 386 | | +--rw ip:mtu? uint16 387 | | +--rw ip:address* [ip] 388 | | | +--rw ip:ip inet:ipv4-address-no-zone 389 | | | +--rw (ip:subnet) 390 | | | +--:(ip:prefix-length) 391 | | | | +--rw ip:prefix-length? uint8 392 | | | +--:(ip:netmask) 393 | | | +--rw ip:netmask? yang:dotted-quad 394 | | +--rw ip:neighbor* [ip] 395 | | | +--rw ip:ip inet:ipv4-address-no-zone 396 | | | +--rw ip:link-layer-address yang:phys-address 397 | | +--rw ni:bind-network-instance-name? string 398 | +--rw ni:bind-network-instance-name? string 400 The [I-D.ietf-netmod-rfc7223bis] defined interface model is 401 structured to include all interfaces in a flat list, without regard 402 to virtual instances (e.g., VRFs) supported on the device. The bind- 403 network-instance-name leaf provides the association between an 404 interface and its associated NI (e.g., VRF or VSI). Note that as 405 currently defined, to assign an interface to both an LNE and NI, the 406 interface would first be assigned to the LNE using the mechanisms 407 defined in [I-D.ietf-rtgwg-lne-model] and then within that LNE's 408 interface module, the LNE's representation of that interface would be 409 assigned to an NI. 411 3.3. Network Instance Management 413 Modules that may be used to represent network instance information 414 will be available under the ni-type specific 'root' mount point. The 415 use-schema mechanism defined as part of the Schema Mount module 416 [I-D.ietf-netmod-schema-mount] MUST be used with the module defined 417 in this document to identify accessible modules. A future version of 418 this document could relax this requirement. Mounted modules in the 419 non-inline case SHOULD be defined with access, via the appropriate 420 schema mount parent-references [I-D.ietf-netmod-schema-mount], to 421 device resources such as interfaces. An implementation MAY choose to 422 restrict parent referenced information to information related to a 423 specific instance, e.g., only allowing references to interfaces that 424 have a "bind-network-instance-name" which is identical to the 425 instance's "name". 427 All modules that represent control-plane and data-plane information 428 may be present at the 'root' mount point, and be accessible via paths 429 modified per [I-D.ietf-netmod-schema-mount]. The list of available 430 modules is expected to be implementation dependent, as is the method 431 used by an implementation to support NIs. 433 For example, the following could be used to define the data 434 organization of the example NI shown in Section 3.1.2: 436 "ietf-yang-schema-mount:schema-mounts": { 437 "mount-point": [ 438 { 439 "module": "ietf-network-instance", 440 "label": "vrf-root", 441 "use-schema": [ 442 { 443 "name": "ni-schema", 444 "parent-reference": [ 445 "/*[namespace-uri() = 'urn:ietf:...:ietf-interfaces']" 446 ] 447 } 448 ] 449 } 450 ], 451 "schema": [ 452 { 453 "name": "ni-schema", 454 "module": [ 455 { 456 "name": "ietf-routing", 457 "revision": "2018-01-25", 458 "namespace": 459 "urn:ietf:params:xml:ns:yang:ietf-routing", 460 "conformance-type": "implement" 461 }, 462 { 463 "name": "ietf-ospf", 464 "revision": "2017-10-30", 465 "namespace": 466 "urn:ietf:params:xml:ns:yang:ietf-ospf", 467 "conformance-type": "implement" 468 } 469 ] 470 } 471 ] 472 } 474 Module data identified under "schema" will be instantiated under the 475 mount point identified under "mount-point". These modules will be 476 able to reference information for nodes belonging to top-level 477 modules that are identified under "parent-reference". Parent 478 referenced information is available to clients via their top level 479 paths only, and not under the associated mount point. 481 To allow a client to understand the previously mentioned instance 482 restrictions on parent referenced information, an implementation MAY 483 represent such restrictions in the "parent-reference" leaf-list. For 484 example: 486 "namespace": [ 487 { 488 "prefix": "if", 489 "uri": "urn:ietf:params:xml:ns:yang:ietf-interfaces" 490 }, 491 { 492 "prefix": "ni", 493 "uri": "urn:ietf:params:xml:ns:yang:ietf-network-instance" 494 } 495 ], 496 "mount-point": [ 497 { 498 "parent-reference": [ 499 "/if:interfaces/if:interface 500 [ni:bind-network-instance-name = current()/../ni:name]", 501 "/if:interfaces-state/if:interface 502 [if:name = /if:interfaces/if:interface 503 [ni:bind-ni-name = current()/../ni:name]/if:name]", 504 "/if:interfaces/if:interface/ip:ipv4 505 [ni:bind-network-instance-name = current()/../ni:name]", 506 "/if:interfaces-state/if:interface/ip:ipv4 507 [if:name = /if:interfaces/if:interface/ip:ipv4 508 [ni:bind-ni-name = current()/../ni:name]/if:name]", 509 "/if:interfaces/if:interface/ip:ipv6 510 [ni:bind-network-instance-name = current()/../ni:name]", 511 "/if:interfaces-state/if:interface/ip:ipv6 512 [if:name = /if:interfaces/if:interface/ip:ipv4 513 [ni:bind-ni-name = current()/../ni:name]/if:name]", 514 ] 515 } 516 ], 518 3.4. Network Instance Instantiation 520 Network instances may be controlled by clients using existing list 521 operations. When a list entry is created, a new instance is 522 instantiated. The models mounted under an NI root are expected to be 523 dependent on the server implementation. When a list entry is 524 deleted, an existing network instance is destroyed. For more 525 information, see [RFC7950] Section 7.8.6. 527 Once instantiated, host network device resources can be associated 528 with the new NI. As previously mentioned, this document augments 529 ietf-interfaces with the bind-ni-name leaf to support such 530 associations for interfaces. When a bind-ni-name is set to a valid 531 NI name, an implementation MUST take whatever steps are internally 532 necessary to assign the interface to the NI or provide an error 533 message (defined below) with an indication of why the assignment 534 failed. It is possible for the assignment to fail while processing 535 the set operation, or after asynchronous processing. Error 536 notification in the latter case is supported via a notification. 538 4. Security Considerations 540 The YANG modules specified in this document define a schema for data 541 that is designed to be accessed via network management protocols such 542 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 543 is the secure transport layer, and the mandatory-to-implement secure 544 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 545 is HTTPS, and the mandatory-to-implement secure transport is TLS 546 [RFC5246]. 548 The NETCONF access control model [RFC6536] provides the means to 549 restrict access for particular NETCONF or RESTCONF users to a 550 preconfigured subset of all available NETCONF or RESTCONF protocol 551 operations and content. 553 There are two different sets of security considerations to consider 554 in the context of this document. One set is security related to 555 information contained within mounted modules. The security 556 considerations for mounted modules are not substantively changed 557 based on the information being accessible within the context of an 558 NI. For example, when considering the modules defined in 559 [I-D.ietf-netmod-rfc8022bis], the security considerations identified 560 in that document are equally applicable, whether those modules are 561 accessed at a server's root or under an NI instance's root node. 563 The second area for consideration is information contained in the NI 564 module itself. NI information represents network configuration and 565 route distribution policy information. As such, the security of this 566 information is important, but it is fundamentally no different than 567 any other interface or routing configuration information that has 568 already been covered in [I-D.ietf-netmod-rfc7223bis] and 569 [I-D.ietf-netmod-rfc8022bis]. 571 The vulnerable "config true" parameters and subtrees are the 572 following: 574 /network-instances/network-instance: This list specifies the network 575 instances and the related control plane protocols configured on a 576 device. 578 /if:interfaces/if:interface/*/bind-network-instance-name: This leaf 579 indicates the NI instance to which an interface is assigned. 581 Unauthorized access to any of these lists can adversely affect the 582 routing subsystem of both the local device and the network. This may 583 lead to network malfunctions, delivery of packets to inappropriate 584 destinations and other problems. 586 5. IANA Considerations 588 This document registers a URI in the IETF XML registry [RFC3688]. 589 Following the format in RFC 3688, the following registration is 590 requested to be made. 592 URI: urn:ietf:params:xml:ns:yang:ietf-network-instance 594 Registrant Contact: The IESG. 596 XML: N/A, the requested URI is an XML namespace. 598 This document registers a YANG module in the YANG Module Names 599 registry [RFC6020]. 601 name: ietf-network-instance 602 namespace: urn:ietf:params:xml:ns:yang:ietf-network-instance 603 prefix: ni 604 reference: RFC XXXX 606 6. Network Instance Model 608 The structure of the model defined in this document is described by 609 the YANG module below. 611 file "ietf-network-instance@2018-02-03.yang" 612 module ietf-network-instance { 613 yang-version 1.1; 614 namespace "urn:ietf:params:xml:ns:yang:ietf-network-instance"; 615 prefix ni; 617 // import some basic types 619 import ietf-interfaces { 620 prefix if; 621 reference "draft-ietf-netmod-rfc7223bis: A YANG Data Model 622 for Interface Management"; 623 } 624 import ietf-ip { 625 prefix ip; 626 reference "draft-ietf-netmod-rfc7277bis: A YANG Data Model 627 for IP Management"; 628 } 629 import ietf-yang-schema-mount { 630 prefix yangmnt; 631 reference "draft-ietf-netmod-schema-mount: YANG Schema Mount"; 632 // RFC Ed.: Please replace this draft name with the 633 // corresponding RFC number 634 } 636 organization 637 "IETF Routing Area (rtgwg) Working Group"; 638 contact 639 "WG Web: 640 WG List: 642 Author: Lou Berger 643 644 Author: Christan Hopps 645 646 Author: Acee Lindem 647 648 Author: Dean Bogdanovic 649 "; 650 description 651 "This module is used to support multiple network instances 652 within a single physical or virtual device. Network 653 instances are commonly known as VRFs (virtual routing 654 and forwarding) and VSIs (virtual switching instances). 656 Copyright (c) 2017 IETF Trust and the persons 657 identified as authors of the code. All rights reserved. 659 Redistribution and use in source and binary forms, with or 660 without modification, is permitted pursuant to, and subject 661 to the license terms contained in, the Simplified BSD License 662 set forth in Section 4.c of the IETF Trust's Legal Provisions 663 Relating to IETF Documents 664 (http://trustee.ietf.org/license-info). 666 This version of this YANG module is part of RFC XXXX; see 667 the RFC itself for full legal notices."; 669 // RFC Ed.: replace XXXX with actual RFC number and remove 670 // this note 671 // RFC Ed.: please update TBD 673 revision 2018-02-03 { 674 description 675 "Initial revision."; 676 reference "RFC TBD"; 677 } 679 // top level device definition statements 681 container network-instances { 682 description 683 "Network instances each of which consists of a 684 VRFs (virtual routing and forwarding) and/or 685 VSIs (virtual switching instances)."; 686 reference "draft-ietf-rtgwg-rfc8022bis - A YANG Data Model 687 for Routing Management"; 688 list network-instance { 689 key "name"; 690 description 691 "List of network-instances."; 692 leaf name { 693 type string; 694 mandatory true; 695 description 696 "device scoped identifier for the network 697 instance."; 698 } 699 leaf enabled { 700 type boolean; 701 default "true"; 702 description 703 "Flag indicating whether or not the network 704 instance is enabled."; 705 } 706 leaf description { 707 type string; 708 description 709 "Description of the network instance 710 and its intended purpose."; 711 } 712 choice ni-type { 713 description 714 "This node serves as an anchor point for different types 715 of network instances. Each 'case' is expected to 716 differ in terms of the information needed in the 717 parent/core to support the NI, and may differ in their 718 mounted schema definition. When the mounted schema is 719 not expected to be the same for a specific type of NI 720 a mount point should be defined."; 721 } 722 choice root-type { 723 mandatory true; 724 description 725 "Well known mount points."; 726 container vrf-root { 727 description 728 "Container for mount point."; 729 yangmnt:mount-point "vrf-root" { 730 description 731 "Root for L3VPN type models. This will typically 732 not be an inline type mount point."; 733 } 734 } 735 container vsi-root { 736 description 737 "Container for mount point."; 738 yangmnt:mount-point "vsi-root" { 739 description 740 "Root for L2VPN type models. This will typically 741 not be an inline type mount point."; 742 } 743 } 744 container vv-root { 745 description 746 "Container for mount point."; 747 yangmnt:mount-point "vv-root" { 748 description 749 "Root models that support both L2VPN type bridging 750 and L3VPN type routing. This will typically 751 not be an inline type mount point."; 752 } 753 } 754 } 755 } 756 } 758 // augment statements 760 augment "/if:interfaces/if:interface" { 761 description 762 "Add a node for the identification of the network 763 instance associated with the information configured 764 on a interface. 766 Note that a standard error will be returned if the 767 identified leafref isn't present. If an interfaces cannot 768 be assigned for any other reason, the operation SHALL fail 769 with an error-tag of 'operation-failed' and an 770 error-app-tag of 'ni-assignment-failed'. A meaningful 771 error-info that indicates the source of the assignment 772 failure SHOULD also be provided."; 773 leaf bind-ni-name { 774 type leafref { 775 path "/network-instances/network-instance/name"; 776 } 777 description 778 "Network Instance to which an interface is bound."; 779 } 780 } 781 augment "/if:interfaces/if:interface/ip:ipv4" { 782 description 783 "Add a node for the identification of the network 784 instance associated with the information configured 785 on an IPv4 interface. 787 Note that a standard error will be returned if the 788 identified leafref isn't present. If an interfaces cannot 789 be assigned for any other reason, the operation SHALL fail 790 with an error-tag of 'operation-failed' and an 791 error-app-tag of 'ni-assignment-failed'. A meaningful 792 error-info that indicates the source of the assignment 793 failure SHOULD also be provided."; 794 leaf bind-ni-name { 795 type leafref { 796 path "/network-instances/network-instance/name"; 797 } 798 description 799 "Network Instance to which IPv4 interface is bound."; 800 } 801 } 802 augment "/if:interfaces/if:interface/ip:ipv6" { 803 description 804 "Add a node for the identification of the network 805 instance associated with the information configured 806 on an IPv6 interface. 808 Note that a standard error will be returned if the 809 identified leafref isn't present. If an interfaces cannot 810 be assigned for any other reason, the operation SHALL fail 811 with an error-tag of 'operation-failed' and an 812 error-app-tag of 'ni-assignment-failed'. A meaningful 813 error-info that indicates the source of the assignment 814 failure SHOULD also be provided."; 815 leaf bind-ni-name { 816 type leafref { 817 path "/network-instances/network-instance/name"; 819 } 820 description 821 "Network Instance to which IPv6 interface is bound."; 822 } 823 } 825 // notification statements 827 notification bind-ni-name-failed { 828 description 829 "Indicates an error in the association of an interface to an 830 NI. Only generated after success is initially returned when 831 bind-ni-name is set. 833 Note: some errors may need to be reported for multiple 834 associations, e.g., a single error may need to be reported 835 for an IPv4 and an IPv6 bind-ni-name. 837 At least one container with a bind-ni-name leaf MUST be 838 included in this notification."; 839 leaf name { 840 type leafref { 841 path "/if:interfaces/if:interface/if:name"; 842 } 843 mandatory true; 844 description 845 "Contains the interface name associated with the 846 failure."; 847 } 848 container interface { 849 description 850 "Generic interface type."; 851 leaf bind-ni-name { 852 type leafref { 853 path "/if:interfaces/if:interface/ni:bind-ni-name"; 854 } 855 description 856 "Contains the bind-ni-name associated with the 857 failure."; 858 } 859 } 860 container ipv4 { 861 description 862 "IPv4 interface type."; 863 leaf bind-ni-name { 864 type leafref { 865 path "/if:interfaces/if:interface" 866 + "/ip:ipv4/ni:bind-ni-name"; 868 } 869 description 870 "Contains the bind-ni-name associated with the 871 failure."; 872 } 873 } 874 container ipv6 { 875 description 876 "IPv6 interface type."; 877 leaf bind-ni-name { 878 type leafref { 879 path "/if:interfaces/if:interface" 880 + "/ip:ipv6/ni:bind-ni-name"; 881 } 882 description 883 "Contains the bind-ni-name associated with the 884 failure."; 885 } 886 } 887 leaf error-info { 888 type string; 889 description 890 "Optionally, indicates the source of the assignment 891 failure."; 892 } 893 } 894 } 895 897 7. References 899 7.1. Normative References 901 [I-D.ietf-netmod-rfc7223bis] 902 Bjorklund, M., "A YANG Data Model for Interface 903 Management", draft-ietf-netmod-rfc7223bis-03 (work in 904 progress), January 2018. 906 [I-D.ietf-netmod-rfc7277bis] 907 Bjorklund, M., "A YANG Data Model for IP Management", 908 draft-ietf-netmod-rfc7277bis-03 (work in progress), 909 January 2018. 911 [I-D.ietf-netmod-schema-mount] 912 Bjorklund, M. and L. Lhotka, "YANG Schema Mount", draft- 913 ietf-netmod-schema-mount-08 (work in progress), October 914 2017. 916 [I-D.ietf-netmod-yang-tree-diagrams] 917 Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft- 918 ietf-netmod-yang-tree-diagrams-05 (work in progress), 919 January 2018. 921 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 922 Requirement Levels", BCP 14, RFC 2119, 923 DOI 10.17487/RFC2119, March 1997, . 926 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 927 DOI 10.17487/RFC3688, January 2004, . 930 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 931 (TLS) Protocol Version 1.2", RFC 5246, 932 DOI 10.17487/RFC5246, August 2008, . 935 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 936 the Network Configuration Protocol (NETCONF)", RFC 6020, 937 DOI 10.17487/RFC6020, October 2010, . 940 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 941 and A. Bierman, Ed., "Network Configuration Protocol 942 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 943 . 945 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 946 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 947 . 949 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 950 Protocol (NETCONF) Access Control Model", RFC 6536, 951 DOI 10.17487/RFC6536, March 2012, . 954 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 955 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 956 . 958 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 959 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 960 May 2017, . 962 7.2. Informative References 964 [I-D.ietf-bess-l2vpn-yang] 965 Shah, H., Brissette, P., Chen, I., Hussain, I., Wen, B., 966 and K. Tiruveedhula, "YANG Data Model for MPLS-based 967 L2VPN", draft-ietf-bess-l2vpn-yang-07 (work in progress), 968 October 2017. 970 [I-D.ietf-bess-l3vpn-yang] 971 Jain, D., Patel, K., Brissette, P., Li, Z., Zhuang, S., 972 Liu, X., Haas, J., Esale, S., and B. Wen, "Yang Data Model 973 for BGP/MPLS L3 VPNs", draft-ietf-bess-l3vpn-yang-02 (work 974 in progress), October 2017. 976 [I-D.ietf-netmod-rfc8022bis] 977 Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for 978 Routing Management (NMDA Version)", draft-ietf-netmod- 979 rfc8022bis-11 (work in progress), January 2018. 981 [I-D.ietf-ospf-yang] 982 Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem, 983 "Yang Data Model for OSPF Protocol", draft-ietf-ospf- 984 yang-09 (work in progress), October 2017. 986 [I-D.ietf-rtgwg-device-model] 987 Lindem, A., Berger, L., Bogdanovic, D., and C. Hopps, 988 "Network Device YANG Logical Organization", draft-ietf- 989 rtgwg-device-model-02 (work in progress), March 2017. 991 [I-D.ietf-rtgwg-lne-model] 992 Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. 993 Liu, "YANG Logical Network Elements", draft-ietf-rtgwg- 994 lne-model-05 (work in progress), December 2017. 996 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 997 Private Network (VPN) Terminology", RFC 4026, 998 DOI 10.17487/RFC4026, March 2005, . 1001 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1002 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1003 2006, . 1005 [RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer 1006 2 Virtual Private Networks (L2VPNs)", RFC 4664, 1007 DOI 10.17487/RFC4664, September 2006, . 1010 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1011 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1012 . 1014 Appendix A. Acknowledgments 1016 The Routing Area Yang Architecture design team members included Acee 1017 Lindem, Anees Shaikh, Christian Hopps, Dean Bogdanovic, Lou Berger, 1018 Qin Wu, Rob Shakir, Stephane Litkowski, and Yan Gang. Useful review 1019 comments were also received by Martin Bjorklund and John Scudder. 1021 This document was motivated by, and derived from, 1022 [I-D.ietf-rtgwg-device-model]. 1024 Thanks for AD and IETF last call comments from Alia Atlas and Liang 1025 Xia. 1027 The RFC text was produced using Marshall Rose's xml2rfc tool. 1029 Appendix B. Example NI usage 1031 The following subsections provide example uses of NIs. 1033 B.1. Configuration Data 1035 The following shows an example where two customer specific network 1036 instances are configured: 1038 { 1039 "ietf-network-instance:network-instances": { 1040 "network-instance": [ 1041 { 1042 "name": "vrf-red", 1043 "vrf-root": { 1044 "ietf-routing:routing": { 1045 "router-id": "192.0.2.1", 1046 "control-plane-protocols": { 1047 "control-plane-protocol": [ 1048 { 1049 "type": "ietf-routing:ospf", 1050 "name": "1", 1051 "ietf-ospf:ospf": { 1052 "instance": [ 1053 { 1054 "af": "ipv4", 1055 "areas": { 1056 "area": [ 1057 { 1058 "area-id": "203.0.113.1", 1059 "interfaces": { 1060 "interface": [ 1061 { 1062 "name": "eth1", 1063 "cost": 10 1064 } 1065 ] 1066 } 1067 } 1068 ] 1069 } 1070 } 1071 ] 1072 } 1073 } 1074 ] 1075 } 1076 } 1077 } 1078 }, 1079 { 1080 "name": "vrf-blue", 1081 "vrf-root": { 1082 "ietf-routing:routing": { 1083 "router-id": "192.0.2.2", 1084 "control-plane-protocols": { 1085 "control-plane-protocol": [ 1086 { 1087 "type": "ietf-routing:ospf", 1088 "name": "1", 1089 "ietf-ospf:ospf": { 1090 "instance": [ 1091 { 1092 "af": "ipv4", 1093 "areas": { 1094 "area": [ 1095 { 1096 "area-id": "203.0.113.1", 1097 "interfaces": { 1098 "interface": [ 1099 { 1100 "name": "eth2", 1101 "cost": 10 1102 } 1103 ] 1104 } 1105 } 1107 ] 1108 } 1109 } 1110 ] 1111 } 1112 } 1113 ] 1114 } 1115 } 1116 } 1117 } 1118 ] 1119 }, 1121 "ietf-interfaces:interfaces": { 1122 "interfaces": { 1123 "interface": [ 1124 { 1125 "name": "eth0", 1126 "ip:ipv4": { 1127 "address": [ 1128 { 1129 "ip": "192.0.2.10", 1130 "prefix-length": 24, 1131 } 1132 ] 1133 } 1134 }, 1135 { 1136 "name": "eth1", 1137 "ip:ipv4": { 1138 "address": [ 1139 { 1140 "ip": "192.0.2.11", 1141 "prefix-length": 24, 1142 } 1143 ] 1144 }, 1145 "ni:bind-network-instance-name": "vrf-red" 1146 }, 1147 { 1148 "name": "eth2", 1149 "ip:ipv4": { 1150 "address": [ 1151 { 1152 "ip": "192.0.2.11", 1153 "prefix-length": 24, 1154 } 1156 ] 1157 }, 1158 "ni:bind-network-instance-name": "vrf-blue" 1159 } 1160 ] 1161 } 1162 }, 1164 "ietf-system:system": { 1165 "authentication": { 1166 "user": [ 1167 { 1168 "name": "john", 1169 "password": "$0$password" 1170 } 1171 ] 1172 } 1173 } 1174 } 1176 B.2. State Data 1178 The following shows state data for the example above. 1180 { 1181 "ietf-network-instance:network-instances": { 1182 "network-instance": [ 1183 { 1184 "name": "vrf-red", 1185 "vrf-root": { 1186 "ietf-routing:routing-state": { 1187 "router-id": "192.0.2.1", 1188 "control-plane-protocols": { 1189 "control-plane-protocol": [ 1190 { 1191 "type": "ietf-routing:ospf", 1192 "name": "1", 1193 "ietf-ospf:ospf": { 1194 "instance": [ 1195 { 1196 "af": "ipv4", 1197 "areas": { 1198 "area": [ 1199 { 1200 "area-id": "203.0.113.1", 1201 "interfaces": { 1202 "interface": [ 1203 { 1204 "name": "eth1", 1205 "cost": 10 1206 } 1207 ] 1208 } 1209 } 1210 ] 1211 } 1212 } 1213 ] 1214 } 1215 } 1216 ] 1217 } 1218 } 1219 } 1220 }, 1221 { 1222 "name": "vrf-blue", 1223 "vrf-root": { 1224 "ietf-routing:routing-state": { 1225 "router-id": "192.0.2.2", 1226 "control-plane-protocols": { 1227 "control-plane-protocol": [ 1228 { 1229 "type": "ietf-routing:ospf", 1230 "name": "1", 1231 "ietf-ospf:ospf": { 1232 "instance": [ 1233 { 1234 "af": "ipv4", 1235 "areas": { 1236 "area": [ 1237 { 1238 "area-id": "203.0.113.1", 1239 "interfaces": { 1240 "interface": [ 1241 { 1242 "name": "eth2", 1243 "cost": 10 1244 } 1245 ] 1246 } 1247 } 1248 ] 1249 } 1250 } 1251 ] 1253 } 1254 } 1255 ] 1256 } 1257 } 1258 } 1259 } 1260 ] 1261 }, 1263 "ietf-interfaces:interfaces-state": { 1264 "interfaces": { 1265 "interface": [ 1266 { 1267 "name": "eth0", 1268 "type": "iana-if-type:ethernetCsmacd", 1269 "oper-status": "up", 1270 "phys-address": "00:01:02:A1:B1:C0", 1271 "statistics": { 1272 "discontinuity-time": "2017-06-26T12:34:56-05:00" 1273 }, 1274 "ip:ipv4": { 1275 "address": [ 1276 { 1277 "ip": "192.0.2.10", 1278 "prefix-length": 24, 1279 } 1280 ] 1281 } 1282 }, 1283 { 1284 "name": "eth1", 1285 "type": "iana-if-type:ethernetCsmacd", 1286 "oper-status": "up", 1287 "phys-address": "00:01:02:A1:B1:C1", 1288 "statistics": { 1289 "discontinuity-time": "2017-06-26T12:34:56-05:00" 1290 }, 1291 "ip:ipv4": { 1292 "address": [ 1293 { 1294 "ip": "192.0.2.11", 1295 "prefix-length": 24, 1296 } 1297 ] 1298 } 1299 }, 1300 { 1301 "name": "eth2", 1302 "type": "iana-if-type:ethernetCsmacd", 1303 "oper-status": "up", 1304 "phys-address": "00:01:02:A1:B1:C2", 1305 "statistics": { 1306 "discontinuity-time": "2017-06-26T12:34:56-05:00" 1307 }, 1308 "ip:ipv4": { 1309 "address": [ 1310 { 1311 "ip": "192.0.2.11", 1312 "prefix-length": 24, 1313 } 1314 ] 1315 } 1316 } 1317 ] 1318 } 1319 }, 1321 "ietf-system:system-state": { 1322 "platform": { 1323 "os-name": "NetworkOS" 1324 } 1325 } 1327 "ietf-yang-library:modules-state": { 1328 "module-set-id": "123e4567-e89b-12d3-a456-426655440000", 1329 "module": [ 1330 { 1331 "name": "iana-if-type", 1332 "revision": "2014-05-08", 1333 "namespace": 1334 "urn:ietf:params:xml:ns:yang:iana-if-type", 1335 "conformance-type": "import" 1336 }, 1337 { 1338 "name": "ietf-inet-types", 1339 "revision": "2013-07-15", 1340 "namespace": 1341 "urn:ietf:params:xml:ns:yang:ietf-inet-types", 1342 "conformance-type": "import" 1343 }, 1344 { 1345 "name": "ietf-interfaces", 1346 "revision": "2014-05-08", 1347 "feature": [ 1348 "arbitrary-names", 1349 "pre-provisioning" 1350 ], 1351 "namespace": 1352 "urn:ietf:params:xml:ns:yang:ietf-interfaces", 1353 "conformance-type": "implement" 1354 }, 1355 { 1356 "name": "ietf-ip", 1357 "revision": "2014-06-16", 1358 "namespace": 1359 "urn:ietf:params:xml:ns:yang:ietf-ip", 1360 "conformance-type": "implement" 1361 }, 1362 { 1363 "name": "ietf-network-instance", 1364 "revision": "2017-03-13", 1365 "feature": [ 1366 "bind-network-instance-name" 1367 ], 1368 "namespace": 1369 "urn:ietf:params:xml:ns:yang:ietf-network-instance", 1370 "conformance-type": "implement" 1371 }, 1372 { 1373 "name": "ietf-ospf", 1374 "revision": "2017-03-12", 1375 "namespace": "urn:ietf:params:xml:ns:yang:ietf-ospf", 1376 "conformance-type": "implement" 1377 }, 1378 { 1379 "name": "ietf-routing", 1380 "revision": "2016-11-04", 1381 "namespace": 1382 "urn:ietf:params:xml:ns:yang:ietf-routing", 1383 "conformance-type": "implement" 1384 }, 1385 { 1386 "name": "ietf-system", 1387 "revision": "2014-08-06", 1388 "namespace": 1389 "urn:ietf:params:xml:ns:yang:ietf-system", 1390 "conformance-type": "implement" 1391 }, 1392 { 1393 "name": "ietf-yang-library", 1394 "revision": "2016-06-21", 1395 "namespace": 1396 "urn:ietf:params:xml:ns:yang:ietf-yang-library", 1397 "conformance-type": "implement" 1398 }, 1399 { 1400 "name": "ietf-yang-schema-mount", 1401 "revision": "2017-05-16", 1402 "namespace": 1403 "urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount", 1404 "conformance-type": "implement" 1405 }, 1406 { 1407 "name": "ietf-yang-types", 1408 "revision": "2013-07-15", 1409 "namespace": 1410 "urn:ietf:params:xml:ns:yang:ietf-yang-types", 1411 "conformance-type": "import" 1412 } 1413 ] 1414 }, 1416 "ietf-yang-schema-mount:schema-mounts": { 1417 "mount-point": [ 1418 { 1419 "module": "ietf-network-instance", 1420 "label": "vrf-root", 1421 "use-schema": [ 1422 { 1423 "name": "ni-schema", 1424 "parent-reference": [ 1425 "/*[namespace-uri() = 'urn:ietf:...:ietf-interfaces']" 1426 ] 1427 } 1428 ] 1429 } 1430 ], 1431 "schema": [ 1432 { 1433 "name": "ni-schema", 1434 "module": [ 1435 { 1436 "name": "ietf-routing", 1437 "revision": "2016-11-04", 1438 "namespace": 1439 "urn:ietf:params:xml:ns:yang:ietf-routing", 1440 "conformance-type": "implement" 1441 }, 1442 { 1443 "name": "ietf-ospf", 1444 "revision": "2017-03-12", 1445 "namespace": 1446 "urn:ietf:params:xml:ns:yang:ietf-ospf", 1447 "conformance-type": "implement" 1448 } 1449 ] 1450 } 1451 ] 1452 } 1453 } 1455 Authors' Addresses 1457 Lou Berger 1458 LabN Consulting, L.L.C. 1460 Email: lberger@labn.net 1462 Christan Hopps 1463 Deutsche Telekom 1465 Email: chopps@chopps.org 1467 Acee Lindem 1468 Cisco Systems 1469 301 Midenhall Way 1470 Cary, NC 27513 1471 USA 1473 Email: acee@cisco.com 1475 Dean Bogdanovic 1477 Email: ivandean@gmail.com 1479 Xufeng Liu 1480 Jabil 1482 Email: Xufeng_Liu@jabil.com