idnits 2.17.1 draft-ietf-rtgwg-ni-model-03.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 == Line 416 has weird spacing: '...address yang:...' -- The document date (July 3, 2017) is 2488 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-05 == Outdated reference: A later version (-06) exists of draft-ietf-netmod-yang-tree-diagrams-01 ** Obsolete normative reference: RFC 7223 (Obsoleted by RFC 8343) ** Obsolete normative reference: RFC 7277 (Obsoleted by RFC 8344) == Outdated reference: A later version (-10) exists of draft-ietf-bess-l2vpn-yang-05 == Outdated reference: A later version (-05) exists of draft-ietf-bess-l3vpn-yang-01 == Outdated reference: A later version (-29) exists of draft-ietf-ospf-yang-08 == Outdated reference: A later version (-10) exists of draft-ietf-rtgwg-lne-model-02 -- Obsolete informational reference (is this intentional?): RFC 8022 (Obsoleted by RFC 8349) Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 3 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: January 4, 2018 Deutsche Telekom 6 A. Lindem 7 Cisco Systems 8 D. Bogdanovic 10 X. Liu 11 Jabil 12 July 3, 2017 14 YANG Network Instances 15 draft-ietf-rtgwg-ni-model-03 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 January 4, 2018. 42 Copyright Notice 44 Copyright (c) 2017 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 . . . . . . . . . . . . . . . 11 69 3.4. Network Instance Instantiation . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . . . . . 22 77 Appendix B. Example NI usage . . . . . . . . . . . . . . . . . . 22 78 B.1. Configuration Data . . . . . . . . . . . . . . . . . . . 22 79 B.2. State Data . . . . . . . . . . . . . . . . . . . . . . . 25 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 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 [RFC7223] is impacted by the 184 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 [RFC8022] and OSPF [I-D.ietf-ospf-yang]. This document 194 defines the network-instance module that provides a basis for the 195 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 +--ro rt:routing-state/ 351 | +--ro router-id? yang:dotted-quad 352 | +--ro control-plane-protocols 353 | +--ro control-plane-protocol* [type name] 354 | +--ro ospf:ospf/ 355 | +--ro instance* [af] 356 +--rw rt:routing/ 357 | +--rw router-id? yang:dotted-quad 358 | +--rw control-plane-protocols 359 | +--rw control-plane-protocol* [type name] 360 | +--rw ospf:ospf/ 361 | +--rw instance* [af] 362 | +--rw areas 363 | +--rw area* [area-id] 364 | +--rw interfaces 365 | +--rw interface* [name] 366 | +--rw name if:interface-ref 367 | +--rw cost? uint16 368 +--ro if:interfaces@ 369 | ... 370 +--ro if:interfaces-state@ 371 | ... 373 This shows YANG Routing Management [RFC8022] and YANG OSPF 374 [I-D.ietf-ospf-yang] as mounted modules. The mounted modules can 375 reference interface information via a parent-reference to the 376 containers defined in [RFC7223]. 378 3.2. NIs and Interfaces 380 Interfaces are a crucial part of any network device's configuration 381 and operational state. They generally include a combination of raw 382 physical interfaces, link-layer interfaces, addressing configuration, 383 and logical interfaces that may not be tied to any physical 384 interface. Several system services, and layer 2 and layer 3 385 protocols may also associate configuration or operational state data 386 with different types of interfaces (these relationships are not shown 387 for simplicity). The interface management model is defined by 388 [RFC7223]. 390 As shown below, the network-instance module augments the existing 391 interface management model by adding a name which is used on 392 interface or sub-interface types to identify an associated network 393 instance. Similarly, this name is also added for IPv4 and IPv6 394 types, as defined in [RFC7277]. 396 The following is an example of envisioned usage. The interfaces 397 container includes a number of commonly used components as examples: 399 module: ietf-interfaces 400 +--rw interfaces 401 | +--rw interface* [name] 402 | +--rw name string 403 | +--rw ip:ipv4! 404 | | +--rw ip:enabled? boolean 405 | | +--rw ip:forwarding? boolean 406 | | +--rw ip:mtu? uint16 407 | | +--rw ip:address* [ip] 408 | | | +--rw ip:ip inet:ipv4-address-no-zone 409 | | | +--rw (ip:subnet) 410 | | | +--:(ip:prefix-length) 411 | | | | +--rw ip:prefix-length? uint8 412 | | | +--:(ip:netmask) 413 | | | +--rw ip:netmask? yang:dotted-quad 414 | | +--rw ip:neighbor* [ip] 415 | | | +--rw ip:ip inet:ipv4-address-no-zone 416 | | | +--rw ip:link-layer-address yang:phys-address 417 | | +--rw ni:bind-network-instance-name? string 418 | +--rw ni:bind-network-instance-name? string 420 The [RFC7223] defined interface model is structured to include all 421 interfaces in a flat list, without regard to virtual instances (e.g., 422 VRFs) supported on the device. The bind-network-instance-name leaf 423 provides the association between an interface and its associated NI 424 (e.g., VRF or VSI). Note that as currently defined, to assign an 425 interface to both an LNE and NI, the interface would first be 426 assigned to the LNE using the mechanisms defined in 427 [I-D.ietf-rtgwg-lne-model] and then within that LNE's interface 428 module, the LNE's representation of that interface would be assigned 429 to an NI. 431 3.3. Network Instance Management 433 Modules that may be used to represent network instance information 434 will be available under the ni-type specific 'root' mount point. The 435 use-schema mechanism defined as part of the Schema Mount module 436 [I-D.ietf-netmod-schema-mount] MUST be used with the module defined 437 in this document to identify accessible modules. A future version of 438 this document could relax this requirement. Mounted modules in the 439 non-inline case SHOULD be defined with access, via the appropriate 440 schema mount parent-references [I-D.ietf-netmod-schema-mount], to 441 device resources such as interfaces. 443 All modules that represent control-plane and data-plane information 444 may be present at the 'root' mount point, and be accessible via paths 445 modified per [I-D.ietf-netmod-schema-mount]. The list of available 446 modules is expected to be implementation dependent, as is the method 447 used by an implementation to support NIs. 449 For example, the following could be used to define the data 450 organization of the example NI shown in Section 3.1.2: 452 "ietf-yang-schema-mount:schema-mounts": { 453 "mount-point": [ 454 { 455 "module": "ietf-network-instance", 456 "name": "vrf-root", 457 "use-schema": [ 458 { 459 "name": "ni-schema", 460 "parent-reference": [ 461 "/*[namespace-uri() = 'urn:ietf:...:ietf-interfaces']" 462 ] 463 } 464 ] 465 } 466 ], 467 "schema": [ 468 { 469 "name": "ni-schema", 470 "module": [ 471 { 472 "name": "ietf-routing", 473 "revision": "2016-11-04", 474 "namespace": 475 "urn:ietf:params:xml:ns:yang:ietf-routing", 476 "conformance-type": "implement" 477 }, 478 { 479 "name": "ietf-ospf", 480 "revision": "2017-03-12", 481 "namespace": 482 "urn:ietf:params:xml:ns:yang:ietf-ospf", 483 "conformance-type": "implement" 484 } 485 ] 486 } 487 ] 488 } 490 Module data identified under "schema" will be instantiated under the 491 mount point identified under "mount-point". These modules will be 492 able to reference information for nodes belonging to top-level 493 modules that are identified under "parent-reference". Parent 494 referenced information is available to clients via their top level 495 paths only, and not under the associated mount point. 497 3.4. Network Instance Instantiation 499 Network instances may be controlled by clients using existing list 500 operations. When a list entry is created, a new instance is 501 instantiated. The models mounted under an NI root are expected to be 502 dependent on the server implementation. When a list entry is 503 deleted, an existing network instance is destroyed. For more 504 information, see [RFC7950] Section 7.8.6. 506 Once instantiated, host network device resources can be associated 507 with the new NI. As previously mentioned, this document augments 508 ietf-interfaces with the bind-ni-name leaf to support such 509 associations for interfaces. When a bind-ni-name is set to a valid 510 NI name, an implementation MUST take whatever steps are internally 511 necessary to assign the interface to the NI or provide an error 512 message (defined below) with an indication of why the assignment 513 failed. It is possible for the assignment to fail while processing 514 the set operation, or after asynchronous processing. Error 515 notification in the latter case is supported via a notification. 517 4. Security Considerations 519 There are two different sets of security considerations to consider 520 in the context of this document. One set is security related to 521 information contained within mounted modules. The security 522 considerations for mounted modules are not substantively changed 523 based on the information being accessible within the context of an 524 NI. For example, when considering the modules defined in [RFC8022], 525 the security considerations identified in that document are equally 526 applicable, whether those modules are accessed at a server's root or 527 under an NI instance's root node. 529 The second area for consideration is information contained in the NI 530 module itself. NI information represents network configuration and 531 route distribution policy information. As such, the security of this 532 information is important, but it is fundamentally no different than 533 any other interface or routing configuration information that has 534 already been covered in [RFC7223] and [RFC8022]. 536 The vulnerable "config true" parameters and subtrees are the 537 following: 539 /network-instances/network-instance: This list specifies the network 540 instances and the related control plane protocols configured on a 541 device. 543 /if:interfaces/if:interface/*/bind-network-instance-name: This leaf 544 indicates the NI instance to which an interface is assigned. 546 Unauthorized access to any of these lists can adversely affect the 547 routing subsystem of both the local device and the network. This may 548 lead to network malfunctions, delivery of packets to inappropriate 549 destinations and other problems. 551 5. IANA Considerations 553 This document registers a URI in the IETF XML registry [RFC3688]. 554 Following the format in RFC 3688, the following registration is 555 requested to be made. 557 URI: urn:ietf:params:xml:ns:yang:ietf-network-instance 559 Registrant Contact: The IESG. 561 XML: N/A, the requested URI is an XML namespace. 563 This document registers a YANG module in the YANG Module Names 564 registry [RFC6020]. 566 name: ietf-network-instance 567 namespace: urn:ietf:params:xml:ns:yang:ietf-network-instance 568 prefix: ni 569 reference: RFC XXXX 571 6. Network Instance Model 573 The structure of the model defined in this document is described by 574 the YANG module below. 576 file "ietf-network-instance@2017-07-03.yang" 577 module ietf-network-instance { 578 yang-version 1.1; 579 namespace "urn:ietf:params:xml:ns:yang:ietf-network-instance"; 580 prefix ni; 582 // import some basic types 584 import ietf-interfaces { 585 prefix if; 586 reference "RFC 7223: A YANG Data Model for Interface 587 Management"; 588 } 589 import ietf-ip { 590 prefix ip; 591 reference "RFC 7277: A YANG Data Model for IP Management"; 592 } 593 import ietf-yang-schema-mount { 594 prefix yangmnt; 595 reference "draft-ietf-netmod-schema-mount: YANG Schema Mount"; 596 // RFC Ed.: Please replace this draft name with the 597 // corresponding RFC number 598 } 600 organization 601 "IETF Routing Area (rtgwg) Working Group"; 602 contact 603 "WG Web: 604 WG List: 606 Author: Lou Berger 607 608 Author: Christan Hopps 609 610 Author: Acee Lindem 611 612 Author: Dean Bogdanovic 613 "; 614 description 615 "This module is used to support multiple network instances 616 within a single physical or virtual device. Network 617 instances are commonly known as VRFs (virtual routing 618 and forwarding) and VSIs (virtual switching instances). 620 Copyright (c) 2017 IETF Trust and the persons 621 identified as authors of the code. All rights reserved. 623 Redistribution and use in source and binary forms, with or 624 without modification, is permitted pursuant to, and subject 625 to the license terms contained in, the Simplified BSD License 626 set forth in Section 4.c of the IETF Trust's Legal Provisions 627 Relating to IETF Documents 628 (http://trustee.ietf.org/license-info). 630 This version of this YANG module is part of RFC XXXX; see 631 the RFC itself for full legal notices."; 633 // RFC Ed.: replace XXXX with actual RFC number and remove 634 // this note 635 // RFC Ed.: please update TBD 637 revision 2017-07-02 { 638 description 639 "Initial revision."; 640 reference "RFC TBD"; 641 } 642 // top level device definition statements 644 container network-instances { 645 description 646 "Network instances each of which consists of a 647 VRFs (virtual routing and forwarding) and/or 648 VSIs (virtual switching instances)."; 649 reference "RFC 8022 - A YANG Data Model for Routing 650 Management"; 651 list network-instance { 652 key "name"; 653 description 654 "List of network-instances."; 655 leaf name { 656 type string; 657 description 658 "device scoped identifier for the network 659 instance."; 660 } 661 leaf enabled { 662 type boolean; 663 default "true"; 664 description 665 "Flag indicating whether or not the network 666 instance is enabled."; 667 } 668 leaf description { 669 type string; 670 description 671 "Description of the network instance 672 and its intended purpose."; 673 } 674 choice ni-type { 675 description 676 "This node serves as an anchor point for different types 677 of network instances. Each 'case' is expected to 678 differ in terms of the information needed in the 679 parent/core to support the NI, and may differ in their 680 mounted schema definition. When the mounted schema is 681 not expected to be the same for a specific type of NI 682 a mount point should be defined."; 683 } 684 choice root-type { 685 description 686 "Well known mount points."; 687 yangmnt:mount-point "vrf-root" { 688 description 689 "Root for L3VPN type models. This will typically 690 not be an inline type mount point."; 691 } 692 yangmnt:mount-point "vsi-root" { 693 description 694 "Root for L2VPN type models. This will typically 695 not be an inline type mount point."; 696 } 697 yangmnt:mount-point "vv-root" { 698 description 699 "Root models that support both L2VPN type bridging 700 and L3VPN type routing. This will typically 701 not be an inline type mount point."; 702 } 703 } 704 } 705 } 707 // augment statements 709 augment "/if:interfaces/if:interface" { 710 description 711 "Add a node for the identification of the network 712 instance associated with the information configured 713 on a interface. 715 Note that a standard error will be returned if the 716 identified leafref isn't present. If an interfaces cannot 717 be assigned for any other reason, the operation SHALL fail 718 with an error-tag of 'operation-failed' and an 719 error-app-tag of 'ni-assignment-failed'. A meaningful 720 error-info that indicates the source of the assignment 721 failure SHOULD also be provided."; 722 leaf bind-ni-name { 723 type leafref { 724 path "/network-instances/network-instance/name"; 725 } 726 description 727 "Network Instance to which an interface is bound."; 728 } 729 } 730 augment "/if:interfaces/if:interface/ip:ipv4" { 731 description 732 "Add a node for the identification of the network 733 instance associated with the information configured 734 on an IPv4 interface. 736 Note that a standard error will be returned if the 737 identified leafref isn't present. If an interfaces cannot 738 be assigned for any other reason, the operation SHALL fail 739 with an error-tag of 'operation-failed' and an 740 error-app-tag of 'ni-assignment-failed'. A meaningful 741 error-info that indicates the source of the assignment 742 failure SHOULD also be provided."; 743 leaf bind-ni-name { 744 type leafref { 745 path "/network-instances/network-instance/name"; 746 } 747 description 748 "Network Instance to which IPv4 interface is bound."; 749 } 750 } 751 augment "/if:interfaces/if:interface/ip:ipv6" { 752 description 753 "Add a node for the identification of the network 754 instance associated with the information configured 755 on an IPv6 interface. 757 Note that a standard error will be returned if the 758 identified leafref isn't present. If an interfaces cannot 759 be assigned for any other reason, the operation SHALL fail 760 with an error-tag of 'operation-failed' and an 761 error-app-tag of 'ni-assignment-failed'. A meaningful 762 error-info that indicates the source of the assignment 763 failure SHOULD also be provided."; 764 leaf bind-ni-name { 765 type leafref { 766 path "/network-instances/network-instance/name"; 767 } 768 description 769 "Network Instance to which IPv6 interface is bound."; 770 } 771 } 773 // notification statements 775 notification bind-ni-name-failed { 776 description 777 "Indicates an error in the association of an interface to an 778 NI. Only generated after success is initially returned when 779 bind-ni-name is set. 781 Note: some errors may need to be reported for multiple 782 associations, e.g., a single error may need to be reported 783 for an IPv4 and an IPv6 bind-ni-name. 785 At least one container with a bind-ni-name leaf MUST be 786 included in this notification."; 787 leaf name { 788 type leafref { 789 path "/if:interfaces/if:interface/if:name"; 790 } 791 mandatory true; 792 description 793 "Contains the interface name associated with the 794 failure."; 795 } 796 container interface { 797 description 798 "Generic interface type."; 799 leaf bind-ni-name { 800 type leafref { 801 path "/if:interfaces/if:interface/ni:bind-ni-name"; 802 } 803 description 804 "Contains the bind-ni-name associated with the 805 failure."; 806 } 807 } 808 container ipv4 { 809 description 810 "IPv4 interface type."; 811 leaf bind-ni-name { 812 type leafref { 813 path "/if:interfaces/if:interface" 814 + "/ip:ipv4/ni:bind-ni-name"; 815 } 816 description 817 "Contains the bind-ni-name associated with the 818 failure."; 819 } 820 } 821 container ipv6 { 822 description 823 "IPv6 interface type."; 824 leaf bind-ni-name { 825 type leafref { 826 path "/if:interfaces/if:interface" 827 + "/ip:ipv6/ni:bind-ni-name"; 828 } 829 description 830 "Contains the bind-ni-name associated with the 831 failure."; 832 } 833 } 834 leaf error-info { 835 type string; 836 description 837 "Optionally, indicates the source of the assignment 838 failure."; 839 } 840 } 841 } 842 844 7. References 846 7.1. Normative References 848 [I-D.ietf-netmod-schema-mount] 849 Bjorklund, M. and L. Lhotka, "YANG Schema Mount", draft- 850 ietf-netmod-schema-mount-05 (work in progress), May 2017. 852 [I-D.ietf-netmod-yang-tree-diagrams] 853 Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft- 854 ietf-netmod-yang-tree-diagrams-01 (work in progress), June 855 2017. 857 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 858 Requirement Levels", BCP 14, RFC 2119, 859 DOI 10.17487/RFC2119, March 1997, 860 . 862 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 863 DOI 10.17487/RFC3688, January 2004, 864 . 866 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 867 the Network Configuration Protocol (NETCONF)", RFC 6020, 868 DOI 10.17487/RFC6020, October 2010, 869 . 871 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 872 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 873 . 875 [RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", 876 RFC 7277, DOI 10.17487/RFC7277, June 2014, 877 . 879 7.2. Informative References 881 [I-D.ietf-bess-l2vpn-yang] 882 Shah, H., Brissette, P., Chen, I., Hussain, I., Wen, B., 883 and K. Tiruveedhula, "YANG Data Model for MPLS-based 884 L2VPN", draft-ietf-bess-l2vpn-yang-05 (work in progress), 885 March 2017. 887 [I-D.ietf-bess-l3vpn-yang] 888 Jain, D., Patel, K., Brissette, P., Li, Z., Zhuang, S., 889 Liu, X., Haas, J., Esale, S., and B. Wen, "Yang Data Model 890 for BGP/MPLS L3 VPNs", draft-ietf-bess-l3vpn-yang-01 (work 891 in progress), April 2017. 893 [I-D.ietf-ospf-yang] 894 Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem, 895 "Yang Data Model for OSPF Protocol", draft-ietf-ospf- 896 yang-08 (work in progress), July 2017. 898 [I-D.ietf-rtgwg-device-model] 899 Lindem, A., Berger, L., Bogdanovic, D., and C. Hopps, 900 "Network Device YANG Logical Organization", draft-ietf- 901 rtgwg-device-model-02 (work in progress), March 2017. 903 [I-D.ietf-rtgwg-lne-model] 904 Berger, L., Hopps, C., Lindem, A., and D. Bogdanovic, 905 "YANG Logical Network Elements", draft-ietf-rtgwg-lne- 906 model-02 (work in progress), March 2017. 908 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 909 Private Network (VPN) Terminology", RFC 4026, 910 DOI 10.17487/RFC4026, March 2005, 911 . 913 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 914 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 915 2006, . 917 [RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer 918 2 Virtual Private Networks (L2VPNs)", RFC 4664, 919 DOI 10.17487/RFC4664, September 2006, 920 . 922 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 923 RFC 7950, DOI 10.17487/RFC7950, August 2016, 924 . 926 [RFC8022] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing 927 Management", RFC 8022, DOI 10.17487/RFC8022, November 928 2016, . 930 Appendix A. Acknowledgments 932 The Routing Area Yang Architecture design team members included Acee 933 Lindem, Anees Shaikh, Christian Hopps, Dean Bogdanovic, Lou Berger, 934 Qin Wu, Rob Shakir, Stephane Litkowski, and Yan Gang. Useful review 935 comments were also received by Martin Bjorklund and John Scudder. 937 This document was motivated by, and derived from, 938 [I-D.ietf-rtgwg-device-model]. 940 The RFC text was produced using Marshall Rose's xml2rfc tool. 942 Appendix B. Example NI usage 944 The following subsections provide example uses of NIs. 946 B.1. Configuration Data 948 The following shows an example where two customer specific network 949 instances are configured: 951 { 952 "ietf-network-instance:network-instances": { 953 "network-instance": [ 954 { 955 "name": "vrf-red", 956 "vrf-root": { 957 "ietf-routing:routing": { 958 "router-id": "192.0.2.1", 959 "control-plane-protocols": { 960 "control-plane-protocol": [ 961 { 962 "type": "ietf-routing:ospf", 963 "name": "1", 964 "ietf-ospf:ospf": { 965 "instance": [ 966 { 967 "af": "ipv4", 968 "areas": { 969 "area": [ 970 { 971 "area-id": "203.0.113.1", 972 "interfaces": { 973 "interface": [ 974 { 975 "name": "eth1", 976 "cost": 10 977 } 978 ] 979 } 980 } 981 ] 982 } 983 } 984 ] 985 } 986 } 987 ] 988 } 989 } 990 } 991 }, 992 { 993 "name": "vrf-blue", 994 "vrf-root": { 995 "ietf-routing:routing": { 996 "router-id": "192.0.2.2", 997 "control-plane-protocols": { 998 "control-plane-protocol": [ 999 { 1000 "type": "ietf-routing:ospf", 1001 "name": "1", 1002 "ietf-ospf:ospf": { 1003 "instance": [ 1004 { 1005 "af": "ipv4", 1006 "areas": { 1007 "area": [ 1008 { 1009 "area-id": "203.0.113.1", 1010 "interfaces": { 1011 "interface": [ 1012 { 1013 "name": "eth2", 1014 "cost": 10 1015 } 1016 ] 1017 } 1018 } 1019 ] 1020 } 1021 } 1023 ] 1024 } 1025 } 1026 ] 1027 } 1028 } 1029 } 1030 } 1031 ] 1032 }, 1034 "ietf-interfaces:interfaces": { 1035 "interfaces": { 1036 "interface": [ 1037 { 1038 "name": "eth0", 1039 "ip:ipv4": { 1040 "address": [ 1041 { 1042 "ip": "192.0.2.10", 1043 "prefix-length": 24, 1044 } 1045 ] 1046 } 1047 }, 1048 { 1049 "name": "eth1", 1050 "ip:ipv4": { 1051 "address": [ 1052 { 1053 "ip": "192.0.2.11", 1054 "prefix-length": 24, 1055 } 1056 ] 1057 }, 1058 "ni:bind-network-instance-name": "vrf-red" 1059 }, 1060 { 1061 "name": "eth2", 1062 "ip:ipv4": { 1063 "address": [ 1064 { 1065 "ip": "192.0.2.11", 1066 "prefix-length": 24, 1067 } 1068 ] 1069 }, 1070 "ni:bind-network-instance-name": "vrf-blue" 1072 } 1073 ] 1074 } 1075 }, 1077 "ietf-system:system": { 1078 "authentication": { 1079 "user": [ 1080 { 1081 "name": "john", 1082 "password": "$0$password" 1083 } 1084 ] 1085 } 1086 } 1087 } 1089 B.2. State Data 1091 The following shows state data for the example above. 1093 { 1094 "ietf-network-instance:network-instances": { 1095 "network-instance": [ 1096 { 1097 "name": "vrf-red", 1098 "vrf-root": { 1099 "ietf-routing:routing-state": { 1100 "router-id": "192.0.2.1", 1101 "control-plane-protocols": { 1102 "control-plane-protocol": [ 1103 { 1104 "type": "ietf-routing:ospf", 1105 "name": "1", 1106 "ietf-ospf:ospf": { 1107 "instance": [ 1108 { 1109 "af": "ipv4", 1110 "areas": { 1111 "area": [ 1112 { 1113 "area-id": "203.0.113.1", 1114 "interfaces": { 1115 "interface": [ 1116 { 1117 "name": "eth1", 1118 "cost": 10 1119 } 1121 ] 1122 } 1123 } 1124 ] 1125 } 1126 } 1127 ] 1128 } 1129 } 1130 ] 1131 } 1132 } 1133 } 1134 }, 1135 { 1136 "name": "vrf-blue", 1137 "vrf-root": { 1138 "ietf-routing:routing-state": { 1139 "router-id": "192.0.2.2", 1140 "control-plane-protocols": { 1141 "control-plane-protocol": [ 1142 { 1143 "type": "ietf-routing:ospf", 1144 "name": "1", 1145 "ietf-ospf:ospf": { 1146 "instance": [ 1147 { 1148 "af": "ipv4", 1149 "areas": { 1150 "area": [ 1151 { 1152 "area-id": "203.0.113.1", 1153 "interfaces": { 1154 "interface": [ 1155 { 1156 "name": "eth2", 1157 "cost": 10 1158 } 1159 ] 1160 } 1161 } 1162 ] 1163 } 1164 } 1165 ] 1166 } 1167 } 1168 ] 1170 } 1171 } 1172 } 1173 } 1174 ] 1175 }, 1177 "ietf-interfaces:interfaces-state": { 1178 "interfaces": { 1179 "interface": [ 1180 { 1181 "name": "eth0", 1182 "type": "iana-if-type:ethernetCsmacd", 1183 "oper-status": "up", 1184 "phys-address": "00:01:02:A1:B1:C0", 1185 "statistics": { 1186 "discontinuity-time": "2017-06-26T12:34:56-05:00" 1187 }, 1188 "ip:ipv4": { 1189 "address": [ 1190 { 1191 "ip": "192.0.2.10", 1192 "prefix-length": 24, 1193 } 1194 ] 1195 } 1196 }, 1197 { 1198 "name": "eth1", 1199 "type": "iana-if-type:ethernetCsmacd", 1200 "oper-status": "up", 1201 "phys-address": "00:01:02:A1:B1:C1", 1202 "statistics": { 1203 "discontinuity-time": "2017-06-26T12:34:56-05:00" 1204 }, 1205 "ip:ipv4": { 1206 "address": [ 1207 { 1208 "ip": "192.0.2.11", 1209 "prefix-length": 24, 1210 } 1211 ] 1212 } 1213 }, 1214 { 1215 "name": "eth2", 1216 "type": "iana-if-type:ethernetCsmacd", 1217 "oper-status": "up", 1218 "phys-address": "00:01:02:A1:B1:C2", 1219 "statistics": { 1220 "discontinuity-time": "2017-06-26T12:34:56-05:00" 1221 }, 1222 "ip:ipv4": { 1223 "address": [ 1224 { 1225 "ip": "192.0.2.11", 1226 "prefix-length": 24, 1227 } 1228 ] 1229 } 1230 } 1231 ] 1232 } 1233 }, 1235 "ietf-yang-library:modules-state": { 1236 "module-set-id": "123e4567-e89b-12d3-a456-426655440000", 1237 "module": [ 1238 { 1239 "name": "iana-if-type", 1240 "revision": "2014-05-08", 1241 "namespace": 1242 "urn:ietf:params:xml:ns:yang:iana-if-type", 1243 "conformance-type": "import" 1244 }, 1245 { 1246 "name": "ietf-inet-types", 1247 "revision": "2013-07-15", 1248 "namespace": 1249 "urn:ietf:params:xml:ns:yang:ietf-inet-types", 1250 "conformance-type": "import" 1251 }, 1252 { 1253 "name": "ietf-interfaces", 1254 "revision": "2014-05-08", 1255 "feature": [ 1256 "arbitrary-names", 1257 "pre-provisioning" 1258 ], 1259 "namespace": 1260 "urn:ietf:params:xml:ns:yang:ietf-interfaces", 1261 "conformance-type": "implement" 1262 }, 1263 { 1264 "name": "ietf-ip", 1265 "revision": "2014-06-16", 1266 "namespace": 1267 "urn:ietf:params:xml:ns:yang:ietf-ip", 1268 "conformance-type": "implement" 1269 }, 1270 { 1271 "name": "ietf-network-instance", 1272 "revision": "2017-03-13", 1273 "feature": [ 1274 "bind-network-instance-name" 1275 ], 1276 "namespace": 1277 "urn:ietf:params:xml:ns:yang:ietf-network-instance", 1278 "conformance-type": "implement" 1279 }, 1280 { 1281 "name": "ietf-ospf", 1282 "revision": "2017-03-12", 1283 "namespace": "urn:ietf:params:xml:ns:yang:ietf-ospf", 1284 "conformance-type": "implement" 1285 }, 1286 { 1287 "name": "ietf-routing", 1288 "revision": "2016-11-04", 1289 "namespace": 1290 "urn:ietf:params:xml:ns:yang:ietf-routing", 1291 "conformance-type": "implement" 1292 }, 1293 { 1294 "name": "ietf-system", 1295 "revision": "2014-08-06", 1296 "namespace": 1297 "urn:ietf:params:xml:ns:yang:ietf-system", 1298 "conformance-type": "implement" 1299 }, 1300 { 1301 "name": "ietf-yang-library", 1302 "revision": "2016-06-21", 1303 "namespace": 1304 "urn:ietf:params:xml:ns:yang:ietf-yang-library", 1305 "conformance-type": "implement" 1306 }, 1307 { 1308 "name": "ietf-yang-schema-mount", 1309 "revision": "2017-05-16", 1310 "namespace": 1311 "urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount", 1312 "conformance-type": "implement" 1313 }, 1314 { 1315 "name": "ietf-yang-types", 1316 "revision": "2013-07-15", 1317 "namespace": 1318 "urn:ietf:params:xml:ns:yang:ietf-yang-types", 1319 "conformance-type": "import" 1320 } 1321 ] 1322 }, 1324 "ietf-system:system-state": { 1325 "platform": { 1326 "os-name": "NetworkOS" 1327 } 1328 } 1329 } 1331 Authors' Addresses 1333 Lou Berger 1334 LabN Consulting, L.L.C. 1336 Email: lberger@labn.net 1338 Christan Hopps 1339 Deutsche Telekom 1341 Email: chopps@chopps.org 1343 Acee Lindem 1344 Cisco Systems 1345 301 Midenhall Way 1346 Cary, NC 27513 1347 USA 1349 Email: acee@cisco.com 1351 Dean Bogdanovic 1353 Email: ivandean@gmail.com 1354 Xufeng Liu 1355 Jabil 1357 Email: Xufeng_Liu@jabil.com