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