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