idnits 2.17.1 draft-ietf-rtgwg-lne-model-05.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 679 has weird spacing: '...-set-id str...' == Line 692 has weird spacing: '...gorithm str...' == Line 740 has weird spacing: '...-set-id str...' == Line 755 has weird spacing: '...gorithm str...' == Line 841 has weird spacing: '...-set-id str...' == (7 more instances...) -- The document date (December 4, 2017) is 2334 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-12) exists of draft-ietf-netmod-schema-mount-08 ** Obsolete normative reference: RFC 7223 (Obsoleted by RFC 8343) == Outdated reference: A later version (-06) exists of draft-ietf-netmod-yang-tree-diagrams-02 == Outdated reference: A later version (-12) exists of draft-ietf-rtgwg-ni-model-04 -- Obsolete informational reference (is this intentional?): RFC 7895 (Obsoleted by RFC 8525) -- Obsolete informational reference (is this intentional?): RFC 8022 (Obsoleted by RFC 8349) Summary: 1 error (**), 0 flaws (~~), 10 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: June 7, 2018 Deutsche Telekom 6 A. Lindem 7 Cisco Systems 8 D. Bogdanovic 10 X. Liu 11 Jabil 12 December 4, 2017 14 YANG Logical Network Elements 15 draft-ietf-rtgwg-lne-model-05 17 Abstract 19 This document defines a logical network element module. This module 20 can be used to manage the logical resource partitioning that may be 21 present on a network device. Examples of common industry terms for 22 logical resource partitioning are Logical Systems or Logical Routers. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on June 7, 2018. 41 Copyright Notice 43 Copyright (c) 2017 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Logical Network Elements . . . . . . . . . . . . . . . . . . 5 62 3.1. LNE Instantiation and Resource Assignment . . . . . . . . 6 63 3.2. LNE Management - LNE View . . . . . . . . . . . . . . . . 7 64 3.3. LNE Management - Host Network Device View . . . . . . . . 7 65 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 67 6. Logical Network Element Model . . . . . . . . . . . . . . . . 9 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 69 7.1. Normative References . . . . . . . . . . . . . . . . . . 13 70 7.2. Informative References . . . . . . . . . . . . . . . . . 14 71 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 14 72 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 15 73 B.1. Example: Host Device Managed LNE . . . . . . . . . . . . 15 74 B.1.1. Configuration Data . . . . . . . . . . . . . . . . . 19 75 B.1.2. State Data . . . . . . . . . . . . . . . . . . . . . 23 76 B.2. Example: Self Managed LNE . . . . . . . . . . . . . . . . 33 77 B.2.1. Configuration Data . . . . . . . . . . . . . . . . . 36 78 B.2.2. State Data . . . . . . . . . . . . . . . . . . . . . 39 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 81 1. Introduction 83 This document defines a YANG [RFC6020] module to support the creation 84 of logical network elements on a network device. A logical network 85 element (LNE) is an independently managed virtual device made up of 86 resources allocated to it from the host or parent network device. An 87 LNE running on a host network device conceptually parallels a virtual 88 machine running on a host system. Using host-virtualization 89 terminology one could refer to an LNE as a "Guest", and the 90 containing network-device as the "Host". While LNEs may be 91 implemented via host-virtualization technologies this is not a 92 requirement. 94 This document also defines the necessary augmentations for allocating 95 host resources to a given LNE. As the interface management model 96 [RFC7223] is the only a module that currently defines host resources, 97 this document currently defines only a single augmentation to cover 98 the assignment of interfaces to an LNE. Future modules that define 99 support for the control of host device resources are expected to, 100 where appropriate, provide parallel support for the assignment of 101 controlled resources to LNEs. 103 As each LNE is an independently managed device, each will have its 104 own set of YANG modeled data that is independent of the host device 105 and other LNEs. For example, multiple LNEs may all have their own 106 "Tunnel0" interface defined which will not conflict with each other 107 and will not exist in the host's interface model. An LNE will have 108 its own management interfaces possibly including independent 109 instances of netconf/restconf/etc servers to support configuration of 110 their YANG models. As an example of this independence, an 111 implementation may choose to completely rename assigned interfaces, 112 so on the host the assigned interface might be called "Ethernet0/1" 113 while within the LNE it might be called "eth1". 115 In addition to standard management interfaces, a host device 116 implementation may support accessing LNE configuration and 117 operational YANG models directly from the host system. When 118 supported, such access is accomplished through a yang-schema-mount 119 mount point [I-D.ietf-netmod-schema-mount] under which the root level 120 LNE YANG models may be accessed. 122 Examples of vendor terminology for an LNE include logical system or 123 logical router, and virtual switch, chassis, or fabric. 125 1.1. Terminology 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in [RFC2119]. 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 2. Overview 139 In this document, we consider network devices that support protocols 140 and functions defined within the IETF Routing Area, e.g, routers, 141 firewalls, and hosts. Such devices may be physical or virtual, e.g., 142 a classic router with custom hardware or one residing within a 143 server-based virtual machine implementing a virtual network function 144 (VNF). Each device may sub-divide their resources into logical 145 network elements (LNEs), each of which provides a managed logical 146 device. Examples of vendor terminology for an LNE include logical 147 system or logical router, and virtual switch, chassis, or fabric. 148 Each LNE may also support virtual routing and forwarding (VRF) and 149 virtual switching instance (VSI) functions, which are referred to 150 below as a network instances (NIs). This breakdown is represented in 151 Figure 1. 153 ,'''''''''''''''''''''''''''''''''''''''''''''''. 154 | Network Device (Physical or Virtual) | 155 | ..................... ..................... | 156 | : Logical Network : : Logical Network : | 157 | : Element : : Element : | 158 | :+-----+-----+-----+: :+-----+-----+-----+: | 159 | :| Net | Net | Net |: :| Net | Net | Net |: | 160 | :|Inst.|Inst.|Inst.|: :|Inst.|Inst.|Inst.|: | 161 | :+-----+-----+-----+: :+-----+-----+-----+: | 162 | : | | | | | | : : | | | | | | : | 163 | :..|.|...|.|...|.|..: :..|.|...|.|...|.|..: | 164 | | | | | | | | | | | | | | 165 ''''|'|'''|'|'''|'|'''''''''|'|'''|'|'''|'|''''' 166 | | | | | | | | | | | | 167 Interfaces Interfaces 169 Figure 1: Module Element Relationships 171 A model for LNEs is described in Section 3 and the model for NIs is 172 covered in [I-D.ietf-rtgwg-ni-model]. 174 The interface management model [RFC7223] is an existing model that is 175 impacted by the definition of LNEs and network instances. This 176 document and [I-D.ietf-rtgwg-ni-model] define augmentations to the 177 interface module to support LNEs and NIs. Similar elements, although 178 perhaps only for LNEs, may also need to be included as part of the 179 definition of the future hardware and QoS modules. 181 Interfaces are a crucial part of any network device's configuration 182 and operational state. They generally include a combination of raw 183 physical interfaces, link-layer interfaces, addressing configuration, 184 and logical interfaces that may not be tied to any physical 185 interface. Several system services, and layer 2 and layer 3 186 protocols may also associate configuration or operational state data 187 with different types of interfaces (these relationships are not shown 188 for simplicity). The interface management model is defined by 189 [RFC7223]. The logical-network-element module augments existing 190 interface management model by adding an identifier which is used on 191 physical interface types to identify an associated LNE. 193 The interface related augmentation is as follows: 195 module: ietf-logical-network-element 196 augment /if:interfaces/if:interface: 197 +--rw bind-lne-name? -> 198 /logical-network-elements/logical-network-element/name 200 The interface model defined in [RFC7223] is structured to include all 201 interfaces in a flat list, without regard to logical assignment of 202 resources supported on the device. The bind-lne-name and leaf 203 provides the association between an interface and its associated LNE. 204 Note that as currently defined, to assign an interface to both an LNE 205 and NI, the interface would first be assigned to the LNE and then 206 within that LNE's interface module, the LNE's representation of that 207 interface would be assigned to an NI using the mechanisms defined in 208 [I-D.ietf-rtgwg-ni-model]. 210 3. Logical Network Elements 212 Logical network elements support the ability of some devices to 213 partition resources into independent logical routers and/or switches. 214 Device support for multiple logical network elements is 215 implementation specific. Systems without such capabilities need not 216 include support for the logical-network-element module. In physical 217 devices, some hardware features are shared across partitions, but 218 control plane (e.g., routing) protocol instances, tables, and 219 configuration are managed separately. For example, in logical 220 routers or VNFs, this may correspond to establishing multiple logical 221 instances using a single software installation. The model supports 222 configuration of multiple instances on a single device by creating a 223 list of logical network elements, each with their own configuration 224 and operational state related to routing and switching protocols. 226 The LNE model can be represented using the tree format defined in 227 [I-D.ietf-netmod-yang-tree-diagrams] as: 229 module: ietf-logical-network-element 230 +--rw logical-network-elements 231 +--rw logical-network-element* [name] 232 +--rw name string 233 +--rw managed? boolean 234 +--rw description? string 235 +--mp root 236 augment /if:interfaces/if:interface: 237 +--rw bind-lne-name? 238 -> /logical-network-elements/logical-network-element/name 240 notifications: 241 +---n bind-lne-name-failed 242 +--ro name -> /if:interfaces/interface/name 243 +--ro bind-lne-name 244 | -> /if:interfaces/interface/lne:bind-lne-name 245 +--ro error-info? string 247 'name' identifies the logical network element. 'managed' indicates 248 if the server providing the host network device will provide the 249 client LNE information via the 'root' structure. The root of an 250 LNE's specific data is the schema mount point 'root'. bind-lne-name 251 is used to associated an interface with an LNE and bind-lne-name- 252 failed is used in certain failure cases. 254 An LNE root MUST contain at least the YANG library [RFC7895] and 255 Interfaces [RFC7223] modules. 257 3.1. LNE Instantiation and Resource Assignment 259 Logical network elements may be controlled by clients using existing 260 list operations. When list entries are created, a new LNE is 261 instantiated. The models mounted under an LNE root are expected to 262 be dependent on the server implementation. When a list entry is 263 deleted, an existing LNE is destroyed. For more information, see 264 [RFC7950] Section 7.8.6. 266 Once instantiated, host network device resources can be associated 267 with the new LNE. As previously mentioned, this document augments 268 ietf-interfaces with the bind-lne-name leaf to support such 269 associations for interfaces. When an bind-lne-name is set to a valid 270 LNE name, an implementation MUST take whatever steps are internally 271 necessary to assign the interface to the LNE or provide an error 272 message (defined below) with an indication of why the assignment 273 failed. It is possible for the assignment to fail while processing 274 the set, or after asynchronous processing. Error notification in the 275 latter case is supported via a notification. 277 On a successful interface assignment to an LNE, an implementation 278 MUST also make the resource available to the LNE by providing a 279 system created interface to the LNE. The name of the system created 280 interface is a local matter and may be identical or completely 281 different, and mapped from and to, the name used in the context of 282 the host device. The system created interface SHOULD be exposed via 283 the LNE-specific instance of the interfaces module [RFC7223]. 285 3.2. LNE Management - LNE View 287 Each LNE instance is expected to support management functions from 288 within the context of the LNE root, via a server that provides 289 information with the LNE's root exposed as device root. Management 290 functions operating within the context of an LNE are accessed through 291 the LNE's standard management interfaces, e.g., NETCONF and SNMP. 292 Initial configuration, much like the initial configuration of the 293 host device, is a local implementation matter. 295 When accessing an LNE via the LNE's management interface, a network- 296 device representation will be presented, but its scope will be 297 limited to the specific LNE. Normal YANG/NETCONF mechanisms, 298 together with the required YANG library [RFC7895] instance, can be 299 used to identify the available modules. Each supported module will 300 be presented as a top level module. Only LNE associated resources 301 will be reflected in resource related modules, e.g., interfaces, 302 hardware, and perhaps QoS. From the management perspective, there 303 will be no difference between the available LNE view (information) 304 and a physical network device. 306 3.3. LNE Management - Host Network Device View 308 There are multiple implementation approaches possible to enable a 309 network device to support the logical-network-element module and 310 multiple LNEs. Some approaches will allow the management functions 311 operating at network device level to access LNE configuration and 312 operational information, while others will not. Similarly, even when 313 LNE management from the network device is supported by the 314 implementation, it may be prohibited by user policy. 316 Independent of the method selected by an implementation, the 317 'managed' boolean mentioned above is used to indicate when LNE 318 management from the network device context is possible. When the 319 'managed' boolean is 'false', the LNE cannot be managed by the host 320 system and can only be managed from within the context of the LNE as 321 described in the previous section, Section 3.2. Attempts to access 322 information below a root node whose associated 'managed' boolean is 323 set to 'false' MUST result in the error message indicated below. In 324 some implementations, it may not be possible to change this value. 326 For example, when an LNE is implemented using virtual machine and 327 traditional hypervisor technologies, it is likely that this value 328 will be restricted to a 'false' value. 330 It is an implementation choice if the information can be accessed and 331 modified from within the context of the LNE, or even the context of 332 the host device. When the 'managed' boolean is 'true', LNE 333 information SHALL be accessible from the context of the host device. 334 When the associated schema-mount definition has the 'config' leaf set 335 to 'true', then LNE information SHALL also be modifiable from the 336 context of the host device. When LNE information is available from 337 both the host device and from within the context of the LNE, the same 338 information MUST be made available via the 'root' element, with paths 339 modified as described in [I-D.ietf-netmod-schema-mount]. 341 An implementation MAY represent an LNE's schema using either the 342 'inline' or 'use-schema' approaches defined in 343 [I-D.ietf-netmod-schema-mount]. The choice of which to use is 344 completely an implementation choice. The inline case is anticipated 345 to be generally used in the cases where the 'managed' will always be 346 'false'. The 'use-schema' approach is expected to be be most useful 347 in the case where all LNEs share the same schema. When 'use-schema' 348 is used with an LNE mount point, the YANG library rooted in the LNE's 349 mount point MUST match the associated schema defined within the ietf- 350 yang-schema-mount module. 352 Beyond the two modules that will always be present for an LNE, as an 353 LNE is a network device itself, all modules that may be present at 354 the top level network device MAY also be present for the LNE. The 355 list of available modules is expected to be implementation dependent. 356 As is the method used by an implementation to support LNEs. 357 Appendix B provide example uses of LNEs. 359 4. Security Considerations 361 LNE information represents device and network configuration 362 information. As such, the security of this information is important, 363 but it is fundamentally no different than any other interface or 364 device configuration information that has already been covered in 365 other documents such as [RFC7223], [RFC7317] and [RFC8022]. 367 The vulnerable "config true" parameters and subtrees are the 368 following: 370 /logical-network-elements/logical-network-element: This list 371 specifies the logical network element and the related logical 372 device configuration. 374 /logical-network-elements/logical-network-element/managed: While 375 this leaf is contained in the previous list, it is worth 376 particular attention as it controls whether information under the 377 LNE mount point is accessible by both the host device and within 378 the LNE context. There may be extra sensitivity to this leaf in 379 environments where an LNE is managed by a different party than the 380 host device, and that party does not wish to share LNE information 381 with the operator of the host device. 383 /if:interfaces/if:interface/bind-lne-name: This leaf indicates the 384 LNE instance to which an interface is assigned. 386 Unauthorized access to any of these lists can adversely affect the 387 security of both the local device and the network. This may lead to 388 network malfunctions, delivery of packets to inappropriate 389 destinations, and other problems. 391 5. IANA Considerations 393 This document registers a URI in the IETF XML registry [RFC3688]. 394 Following the format in RFC 3688, the following registration is 395 requested to be made. 397 URI: urn:ietf:params:xml:ns:yang:ietf-logical-network-element 399 Registrant Contact: The IESG. 401 XML: N/A, the requested URI is an XML namespace. 403 This document registers a YANG module in the YANG Module Names 404 registry [RFC6020]. 406 name: ietf-logical-network-element 407 namespace: urn:ietf:params:xml:ns:yang:ietf-logical-network-element 408 prefix: lne 409 reference: RFC XXXX 411 6. Logical Network Element Model 413 The structure of the model defined in this document is described by 414 the YANG module below. 416 file "ietf-logical-network-element@2017-12-04.yang" 417 module ietf-logical-network-element { 418 yang-version 1.1; 420 // namespace 421 namespace "urn:ietf:params:xml:ns:yang:ietf-logical-network-element"; 422 prefix lne; 424 // import some basic types 426 import ietf-interfaces { 427 prefix if; 428 reference "RFC 7223: A YANG Data Model for Interface Management"; 429 } 430 import ietf-yang-schema-mount { 431 prefix yangmnt; 432 reference "draft-ietf-netmod-schema-mount: YANG Schema Mount"; 433 // RFC Ed.: Please replace this draft name with the corresponding 434 // RFC number 435 } 437 organization 438 "IETF Routing Area (rtgwg) Working Group"; 439 contact 440 "WG Web: 441 WG List: 443 Author: Lou Berger 444 445 Author: Christan Hopps 446 447 Author: Acee Lindem 448 449 Author: Dean Bogdanovic 450 "; 451 description 452 "This module is used to support multiple logical network 453 elements on a single physical or virtual system. 455 Copyright (c) 2017 IETF Trust and the persons 456 identified as authors of the code. All rights reserved. 458 Redistribution and use in source and binary forms, with or 459 without modification, is permitted pursuant to, and subject 460 to the license terms contained in, the Simplified BSD License 461 set forth in Section 4.c of the IETF Trust's Legal Provisions 462 Relating to IETF Documents 463 (http://trustee.ietf.org/license-info). 465 This version of this YANG module is part of RFC XXXX; see 466 the RFC itself for full legal notices."; 468 // RFC Ed.: replace XXXX with actual RFC number and remove 469 // this note 470 // RFC Ed.: please update TBD 472 revision 2017-12-04 { 473 description 474 "Initial revision."; 475 reference "RFC TBD"; 476 } 478 // top level device definition statements 480 container logical-network-elements { 481 description 482 "Allows a network device to support multiple logical 483 network element (device) instances."; 484 list logical-network-element { 485 key "name"; 486 description 487 "List of logical network elements."; 488 leaf name { 489 type string; 490 description 491 "Device-wide unique identifier for the 492 logical network element."; 493 } 494 leaf managed { 495 type boolean; 496 default "true"; 497 description 498 "True if the host can access LNE information 499 using the root mount point. This value 500 my not be modifiable in all implementations."; 501 } 502 leaf description { 503 type string; 504 description 505 "Description of the logical network element."; 506 } 507 container "root" { 508 description 509 "Container for mount point."; 510 yangmnt:mount-point "root" { 511 description 512 "Root for models supported per logical 513 network element. This mount point may or may not 514 be inline based on the server implementation. It 515 SHALL always contain a YANG library and interfaces 516 instance. 518 When the associated 'managed' leaf is 'false' any 519 operation that attempts to access information below 520 the root SHALL fail with an error-tag of 521 'access-denied' and an error-app-tag of 522 'lne-not-managed'."; 523 } 524 } 525 } 526 } 528 // augment statements 530 augment "/if:interfaces/if:interface" { 531 description 532 "Add a node for the identification of the logical network 533 element associated with an interface. Applies to interfaces 534 that can be assigned on a per logical network element basis. 536 Note that a standard error will be returned if the 537 identified leafref isn't present. If an interfaces cannot 538 be assigned for any other reason, the operation SHALL fail 539 with an error-tag of 'operation-failed' and an error-app-tag 540 of 'lne-assignment-failed'. A meaningful error-info that 541 indicates the source of the assignment failure SHOULD also 542 be provided."; 543 leaf bind-lne-name { 544 type leafref { 545 path "/logical-network-elements/logical-network-element/name"; 546 } 547 description 548 "Logical network element ID to which interface is bound."; 549 } 550 } 552 // notification statements 554 notification bind-lne-name-failed { 555 description 556 "Indicates an error in the association of an interface to an 557 LNE. Only generated after success is initially returned when 558 bind-lne-name is set."; 559 leaf name { 560 type leafref { 561 path "/if:interfaces/if:interface/if:name"; 562 } 563 mandatory true; 564 description 565 "Contains the interface name associated with the 566 failure."; 567 } 568 leaf bind-lne-name { 569 type leafref { 570 path "/if:interfaces/if:interface/lne:bind-lne-name"; 571 } 572 mandatory true; 573 description 574 "Contains the bind-lne-name associated with the 575 failure."; 576 } 577 leaf error-info { 578 type string; 579 description 580 "Optionally, indicates the source of the assignment 581 failure."; 582 } 583 } 584 } 585 587 7. References 589 7.1. Normative References 591 [I-D.ietf-netmod-schema-mount] 592 Bjorklund, M. and L. Lhotka, "YANG Schema Mount", draft- 593 ietf-netmod-schema-mount-08 (work in progress), October 594 2017. 596 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 597 Requirement Levels", BCP 14, RFC 2119, 598 DOI 10.17487/RFC2119, March 1997, 599 . 601 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 602 DOI 10.17487/RFC3688, January 2004, 603 . 605 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 606 the Network Configuration Protocol (NETCONF)", RFC 6020, 607 DOI 10.17487/RFC6020, October 2010, 608 . 610 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 611 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 612 . 614 7.2. Informative References 616 [I-D.ietf-netmod-yang-tree-diagrams] 617 Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft- 618 ietf-netmod-yang-tree-diagrams-02 (work in progress), 619 October 2017. 621 [I-D.ietf-rtgwg-device-model] 622 Lindem, A., Berger, L., Bogdanovic, D., and C. Hopps, 623 "Network Device YANG Logical Organization", draft-ietf- 624 rtgwg-device-model-02 (work in progress), March 2017. 626 [I-D.ietf-rtgwg-ni-model] 627 Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. 628 Liu, "YANG Network Instances", draft-ietf-rtgwg-ni- 629 model-04 (work in progress), September 2017. 631 [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for 632 System Management", RFC 7317, DOI 10.17487/RFC7317, August 633 2014, . 635 [RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module 636 Library", RFC 7895, DOI 10.17487/RFC7895, June 2016, 637 . 639 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 640 RFC 7950, DOI 10.17487/RFC7950, August 2016, 641 . 643 [RFC8022] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing 644 Management", RFC 8022, DOI 10.17487/RFC8022, November 645 2016, . 647 Appendix A. Acknowledgments 649 The Routing Area Yang Architecture design team members included Acee 650 Lindem, Anees Shaikh, Christian Hopps, Dean Bogdanovic, Lou Berger, 651 Qin Wu, Rob Shakir, Stephane Litkowski, and Yan Gang. Useful review 652 comments were also received by Martin Bjorklund and John Scudder. 654 This document was motivated by, and derived from, 655 [I-D.ietf-rtgwg-device-model]. 657 The RFC text was produced using Marshall Rose's xml2rfc tool. 659 Appendix B. Examples 661 The following subsections provide example uses of LNEs. 663 B.1. Example: Host Device Managed LNE 665 This section describes an example of the LNE model using schema mount 666 to achieve the parent management. An example device supports 667 multiple instances of LNEs (logical routers), each of which supports 668 features of layer 2 and layer 3 interfaces [RFC7223], routing 669 information base [RFC8022], and OSPF protocol. Each of these 670 features is specified by a YANG model, and they are combined using 671 YANG Schema Mount as follows: 673 module: ietf-logical-network-element 674 +--rw logical-network-elements 675 +--rw logical-network-element* [name] 676 +--rw name string 677 +--mp root 678 +--ro yanglib:modules-state/ 679 | +--ro module-set-id string 680 | +--ro module* [name revision] 681 | +--ro name yang:yang-identifier 682 +--rw sys:system/ 683 | +--rw contact? string 684 | +--rw hostname? inet:domain-name 685 | +--rw authentication {authentication}? 686 | +--rw user-authentication-order* identityref 687 | +--rw user* [name] {local-users}? 688 | +--rw name string 689 | +--rw password? ianach:crypt-hash 690 | +--rw authorized-key* [name] 691 | +--rw name string 692 | +--rw algorithm string 693 | +--rw key-data binary 694 +--ro sys:system-state/ 695 | ... 696 +--ro rt:routing-state/ 697 | +--ro router-id? yang:dotted-quad 698 | +--ro control-plane-protocols 699 | +--ro control-plane-protocol* [type name] 700 | +--ro ospf:ospf/ 701 | +--ro instance* [af] 702 | ... 703 +--rw rt:routing/ 704 | +--rw router-id? yang:dotted-quad 705 | +--rw control-plane-protocols 706 | +--rw control-plane-protocol* [type name] 707 | +--rw ospf:ospf/ 708 | +--rw instance* [af] 709 | +--rw areas 710 | +--rw area* [area-id] 711 | +--rw interfaces 712 | +--rw interface* [name] 713 | +--rw name if:interface-ref 714 | +--rw cost? uint16 715 +--rw if:interfaces/ 716 | +--rw interface* [name] 717 | +--rw name string 718 | +--rw ip:ipv4!/ 719 | | +--rw address* [ip] 720 | | ... 721 +--ro if:interfaces-state/ 722 +--ro interface* [name] 723 +--ro name string 724 +--ro ip:ipv4!/ 725 | +--ro address* [ip] 726 | ... 728 module: ietf-interfaces 729 +--rw interfaces 730 | +--rw interface* [name] 731 | +--rw name string 732 | +--rw lne:bind-lne-name? string 733 +--ro interfaces-state 734 +--ro interface* [name] 735 +--ro name string 736 +--ro oper-status enumeration 738 module: ietf-yang-library 739 +--ro modules-state 740 +--ro module-set-id string 741 +--ro module* [name revision] 742 +--ro name yang:yang-identifier 744 module: ietf-system 745 +--rw system 746 | +--rw contact? string 747 | +--rw hostname? inet:domain-name 748 | +--rw authentication {authentication}? 749 | +--rw user-authentication-order* identityref 750 | +--rw user* [name] {local-users}? 751 | +--rw name string 752 | +--rw password? ianach:crypt-hash 753 | +--rw authorized-key* [name] 754 | +--rw name string 755 | +--rw algorithm string 756 | +--rw key-data binary 757 +--ro system-state 758 +--ro platform 759 | +--ro os-name? string 760 | +--ro os-release? string 762 To realize the above schema, the example device implements the 763 following schema mount instance: 765 "ietf-yang-schema-mount:schema-mounts": { 766 "mount-point": [ 767 { 768 "module": "ietf-logical-network-element", 769 "label": "root", 770 "use-schema": [ 771 { 772 "name": "lne-schema" 773 } 774 ] 775 } 776 ], 777 "schema": [ 778 { 779 "name": "lne-schema", 780 "module": [ 781 { 782 "name": "ietf-yang-library", 783 "revision": "2016-06-21", 784 "namespace": 785 "urn:ietf:params:xml:ns:yang:ietf-yang-library", 786 "conformance-type": "implement" 787 }, 788 { 789 "name": "ietf-system", 790 "revision": "2014-08-06", 791 "namespace": 792 "urn:ietf:params:xml:ns:yang:ietf-system", 793 "conformance-type": "implement" 794 }, 795 { 796 "name": "ietf-routing", 797 "revision": "2016-11-04", 798 "namespace": 799 "urn:ietf:params:xml:ns:yang:ietf-routing", 800 "conformance-type": "implement" 801 }, 802 { 803 "name": "ietf-ospf", 804 "revision": "2017-03-12", 805 "namespace": 806 "urn:ietf:params:xml:ns:yang:ietf-ospf", 807 "conformance-type": "implement" 808 }, 809 { 810 "name": "ietf-interfaces", 811 "revision": "2014-05-08", 812 "namespace": 813 "urn:ietf:params:xml:ns:yang:ietf-interfaces", 814 "conformance-type": "implement" 815 }, 816 { 817 "name": "ietf-ip", 818 "revision": "2014-06-16", 819 "namespace": 820 "urn:ietf:params:xml:ns:yang:ietf-ip", 821 "conformance-type": "implement" 822 } 823 ] 824 } 825 ] 826 } 828 By using the implementation of the YANG schema mount, an operator can 829 create instances of logical routers. An interface can be assigned to 830 a logical router, so that the logical router has the permission to 831 access this interface. The OSPF protocol can then be enabled on this 832 assigned interface. 834 For this implementation, a parent management session has access to 835 the schemas of both the parent hosting system and the child logical 836 routers. In addition, each child logical router can grant its own 837 management sessions, which have the following schema: 839 module: ietf-yang-library 840 +--ro modules-state 841 +--ro module-set-id string 842 +--ro module* [name revision] 843 +--ro name yang:yang-identifier 845 module: ietf-system 846 +--rw system 847 | +--rw contact? string 848 | +--rw hostname? inet:domain-name 849 | +--rw authentication {authentication}? 850 | +--rw user-authentication-order* identityref 851 | +--rw user* [name] {local-users}? 852 | +--rw name string 853 | +--rw password? ianach:crypt-hash 854 | +--rw authorized-key* [name] 855 | +--rw name string 856 | +--rw algorithm string 857 | +--rw key-data binary 858 +--ro system-state 859 +--ro platform 860 | +--ro os-name? string 861 | +--ro os-release? string 863 module: ietf-routing 864 +--ro routing-state 865 | +--ro router-id? yang:dotted-quad 866 | +--ro control-plane-protocols 867 | | +--ro control-plane-protocol* [type name] 868 | | +--ro ospf:ospf/ 869 | | +--ro instance* [af] 870 +--rw routing 871 +--rw router-id? yang:dotted-quad 872 +--rw control-plane-protocols 873 +--rw control-plane-protocol* [type name] 874 +--rw ospf:ospf/ 875 +--rw instance* [af] 876 +--rw areas 877 +--rw area* [area-id] 878 +--rw interfaces 879 +--rw interface* [name] 880 +--rw name if:interface-ref 881 +--rw cost? uint16 883 module: ietf-interfaces 884 +--rw interfaces 885 | +--rw interface* [name] 886 | +--rw name string 887 +--ro interfaces-state 888 +--ro interface* [name] 889 +--ro name string 890 +--ro oper-status enumeration 892 B.1.1. Configuration Data 894 The following shows an example where two customer specific LNEs are 895 configured: 897 { 898 "ietf-logical-network-element:logical-network-elements": { 899 "logical-network-element": [ 900 { 901 "name": "cust1", 902 "root": { 903 "ietf-system:system": { 904 "authentication": { 905 "user": [ 906 { 907 "name": "john", 908 "password": "$0$password" 909 } 910 ] 911 } 912 }, 913 "ietf-routing:routing": { 914 "router-id": "192.0.2.1", 915 "control-plane-protocols": { 916 "control-plane-protocol": [ 917 { 918 "type": "ietf-routing:ospf", 919 "name": "1", 920 "ietf-ospf:ospf": { 921 "instance": [ 922 { 923 "af": "ipv4", 924 "areas": { 925 "area": [ 926 { 927 "area-id": "203.0.113.1", 928 "interfaces": { 929 "interface": [ 930 { 931 "name": "eth1", 932 "cost": 10 933 } 934 ] 935 } 936 } 937 ] 938 } 939 } 940 ] 941 } 942 } 943 ] 944 } 945 }, 946 "ietf-interfaces:interfaces": { 947 "interfaces": { 948 "interface": [ 949 { 950 "name": "eth1", 951 "ip:ipv4": { 952 "address": [ 953 { 954 "ip": "192.0.2.11", 955 "prefix-length": 24, 956 } 957 ] 958 } 959 } 960 ] 961 } 962 } 963 } 964 }, 965 { 966 "name": "cust2", 967 "root": { 968 "ietf-system:system": { 969 "authentication": { 970 "user": [ 971 { 972 "name": "john", 973 "password": "$0$password" 974 } 975 ] 976 } 977 } 978 "ietf-routing:routing": { 979 "router-id": "192.0.2.2", 980 "control-plane-protocols": { 981 "control-plane-protocol": [ 982 { 983 "type": "ietf-routing:ospf", 984 "name": "1", 985 "ietf-ospf:ospf": { 986 "instance": [ 987 { 988 "af": "ipv4", 989 "areas": { 990 "area": [ 991 { 992 "area-id": "203.0.113.1", 993 "interfaces": { 994 "interface": [ 995 { 996 "name": "eth1", 997 "cost": 10 998 } 999 ] 1000 } 1001 } 1002 ] 1003 } 1004 } 1005 ] 1006 } 1007 } 1008 ] 1009 } 1010 } 1011 "ietf-interfaces:interfaces": { 1012 "interfaces": { 1013 { 1014 "name": "eth1", 1015 "ip:ipv4": { 1016 "address": [ 1017 { 1018 "ip": "192.0.2.11", 1019 "prefix-length": 24, 1020 } 1021 ] 1022 } 1023 } 1024 ] 1025 } 1026 } 1027 } 1028 ] 1029 }, 1031 "ietf-interfaces:interfaces": { 1032 "interfaces": { 1033 "interface": [ 1034 { 1035 "name": "eth0", 1036 "ip:ipv4": { 1037 "address": [ 1038 { 1039 "ip": "192.0.2.10", 1040 "prefix-length": 24, 1041 } 1042 ] 1044 } 1045 }, 1046 { 1047 "name": "cust1:eth1", 1048 "lne:bind-lne-name": "cust1" 1049 }, 1050 { 1051 "name": "cust2:eth1", 1052 "lne:bind-lne-name": "cust2" 1053 } 1054 ] 1055 } 1056 }, 1058 "ietf-system:system": { 1059 "authentication": { 1060 "user": [ 1061 { 1062 "name": "root", 1063 "password": "$0$password" 1064 } 1065 ] 1066 } 1067 } 1068 } 1070 B.1.2. State Data 1072 The following shows possible state data associated the above 1073 configuration data: 1075 { 1076 "ietf-logical-network-element:logical-network-elements": { 1077 "logical-network-element": [ 1078 { 1079 "name": "cust1", 1080 "root": { 1081 "ietf-yang-library:modules-state": { 1082 "module-set-id": "123e4567-e89b-12d3-a456-426655440000", 1083 "module": [ 1084 { 1085 "name": "iana-if-type", 1086 "revision": "2014-05-08", 1087 "namespace": 1088 "urn:ietf:params:xml:ns:yang:iana-if-type", 1089 "conformance-type": "import" 1090 }, 1091 { 1092 "name": "ietf-inet-types", 1093 "revision": "2013-07-15", 1094 "namespace": 1095 "urn:ietf:params:xml:ns:yang:ietf-inet-types", 1096 "conformance-type": "import" 1097 }, 1098 { 1099 "name": "ietf-interfaces", 1100 "revision": "2014-05-08", 1101 "feature": [ 1102 "arbitrary-names", 1103 "pre-provisioning" 1104 ], 1105 "namespace": 1106 "urn:ietf:params:xml:ns:yang:ietf-interfaces", 1107 "conformance-type": "implement" 1108 }, 1109 { 1110 "name": "ietf-ip", 1111 "revision": "2014-06-16", 1112 "namespace": 1113 "urn:ietf:params:xml:ns:yang:ietf-ip", 1114 "conformance-type": "implement" 1115 }, 1116 { 1117 "name": "ietf-ospf", 1118 "revision": "2017-03-12", 1119 "namespace": 1120 "urn:ietf:params:xml:ns:yang:ietf-ospf", 1121 "conformance-type": "implement" 1122 }, 1123 { 1124 "name": "ietf-routing", 1125 "revision": "2016-11-04", 1126 "namespace": 1127 "urn:ietf:params:xml:ns:yang:ietf-routing", 1128 "conformance-type": "implement" 1129 }, 1130 { 1131 "name": "ietf-system", 1132 "revision": "2014-08-06", 1133 "namespace": 1134 "urn:ietf:params:xml:ns:yang:ietf-system", 1135 "conformance-type": "implement" 1136 }, 1137 { 1138 "name": "ietf-yang-library", 1139 "revision": "2016-06-21", 1140 "namespace": 1141 "urn:ietf:params:xml:ns:yang:ietf-yang-library", 1142 "conformance-type": "implement" 1143 }, 1144 { 1145 "name": "ietf-yang-types", 1146 "revision": "2013-07-15", 1147 "namespace": 1148 "urn:ietf:params:xml:ns:yang:ietf-yang-types", 1149 "conformance-type": "import" 1150 } 1151 ] 1152 } 1153 "ietf-system:system-state": { 1154 "ietf-system:system-state": { 1155 "platform": { 1156 "os-name": "NetworkOS" 1157 } 1158 } 1159 }, 1160 "ietf-routing:routing-state": { 1161 "router-id": "192.0.2.1", 1162 "control-plane-protocols": { 1163 "control-plane-protocol": [ 1164 { 1165 "type": "ietf-routing:ospf", 1166 "name": "1", 1167 "ietf-ospf:ospf": { 1168 "instance": [ 1169 { 1170 "af": "ipv4", 1171 "areas": { 1172 "area": [ 1173 { 1174 "area-id": "203.0.113.1", 1175 "interfaces": { 1176 "interface": [ 1177 { 1178 "name": "eth1", 1179 "cost": 10 1180 } 1181 ] 1182 } 1183 } 1184 ] 1185 } 1186 } 1187 ] 1189 } 1190 } 1191 ] 1192 } 1193 }, 1194 "ietf-interfaces:interfaces-state": { 1195 "interfaces": { 1196 "interface": [ 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 } 1216 } 1217 } 1218 }, 1219 { 1220 "name": "cust2", 1221 "root": { 1222 "ietf-yang-library:modules-state": { 1223 "module-set-id": "123e4567-e89b-12d3-a456-426655440000", 1224 "module": [ 1225 { 1226 "name": "iana-if-type", 1227 "revision": "2014-05-08", 1228 "namespace": 1229 "urn:ietf:params:xml:ns:yang:iana-if-type", 1230 "conformance-type": "import" 1231 }, 1232 { 1233 "name": "ietf-inet-types", 1234 "revision": "2013-07-15", 1235 "namespace": 1236 "urn:ietf:params:xml:ns:yang:ietf-inet-types", 1237 "conformance-type": "import" 1238 }, 1239 { 1240 "name": "ietf-interfaces", 1241 "revision": "2014-05-08", 1242 "feature": [ 1243 "arbitrary-names", 1244 "pre-provisioning" 1245 ], 1246 "namespace": 1247 "urn:ietf:params:xml:ns:yang:ietf-interfaces", 1248 "conformance-type": "implement" 1249 }, 1250 { 1251 "name": "ietf-ip", 1252 "revision": "2014-06-16", 1253 "namespace": 1254 "urn:ietf:params:xml:ns:yang:ietf-ip", 1255 "conformance-type": "implement" 1256 }, 1257 { 1258 "name": "ietf-ospf", 1259 "revision": "2017-03-12", 1260 "namespace": 1261 "urn:ietf:params:xml:ns:yang:ietf-ospf", 1262 "conformance-type": "implement" 1263 }, 1264 { 1265 "name": "ietf-routing", 1266 "revision": "2016-11-04", 1267 "namespace": 1268 "urn:ietf:params:xml:ns:yang:ietf-routing", 1269 "conformance-type": "implement" 1270 }, 1271 { 1272 "name": "ietf-system", 1273 "revision": "2014-08-06", 1274 "namespace": 1275 "urn:ietf:params:xml:ns:yang:ietf-system", 1276 "conformance-type": "implement" 1277 }, 1278 { 1279 "name": "ietf-yang-library", 1280 "revision": "2016-06-21", 1281 "namespace": 1282 "urn:ietf:params:xml:ns:yang:ietf-yang-library", 1283 "conformance-type": "implement" 1284 }, 1285 { 1286 "name": "ietf-yang-types", 1287 "revision": "2013-07-15", 1288 "namespace": 1289 "urn:ietf:params:xml:ns:yang:ietf-yang-types", 1290 "conformance-type": "import" 1291 } 1292 ] 1293 } 1294 "ietf-system:system-state": { 1295 "ietf-system:system-state": { 1296 "platform": { 1297 "os-name": "NetworkOS" 1298 } 1299 } 1300 }, 1301 "ietf-routing:routing-state": { 1302 "router-id": "192.0.2.2", 1303 "control-plane-protocols": { 1304 "control-plane-protocol": [ 1305 { 1306 "type": "ietf-routing:ospf", 1307 "name": "1", 1308 "ietf-ospf:ospf": { 1309 "instance": [ 1310 { 1311 "af": "ipv4", 1312 "areas": { 1313 "area": [ 1314 { 1315 "area-id": "203.0.113.1", 1316 "interfaces": { 1317 "interface": [ 1318 { 1319 "name": "eth1", 1320 "cost": 10 1321 } 1322 ] 1323 } 1324 } 1325 ] 1326 } 1327 } 1328 ] 1329 } 1330 } 1331 ] 1332 } 1334 } 1335 "ietf-interfaces:interfaces-state": { 1336 "interfaces": { 1337 { 1338 "name": "eth1", 1339 "type": "iana-if-type:ethernetCsmacd", 1340 "oper-status": "up", 1341 "phys-address": "00:01:02:A1:B1:C2", 1342 "statistics": { 1343 "discontinuity-time": "2017-06-26T12:34:56-05:00" 1344 }, 1345 "ip:ipv4": { 1346 "address": [ 1347 { 1348 "ip": "192.0.2.11", 1349 "prefix-length": 24, 1350 } 1351 ] 1352 } 1353 } 1354 ] 1355 } 1356 } 1357 } 1358 ] 1359 }, 1361 "ietf-interfaces:interfaces-state": { 1362 "interfaces": { 1363 "interface": [ 1364 { 1365 "name": "eth0", 1366 "type": "iana-if-type:ethernetCsmacd", 1367 "oper-status": "up", 1368 "phys-address": "00:01:02:A1:B1:C0", 1369 "statistics": { 1370 "discontinuity-time": "2017-06-26T12:34:56-05:00" 1371 }, 1372 "ip:ipv4": { 1373 "address": [ 1374 { 1375 "ip": "192.0.2.10", 1376 "prefix-length": 24, 1377 } 1378 ] 1379 } 1380 }, 1381 { 1382 "name": "cust1:eth1", 1383 "type": "iana-if-type:ethernetCsmacd", 1384 "oper-status": "up", 1385 "phys-address": "00:01:02:A1:B1:C1", 1386 "statistics": { 1387 "discontinuity-time": "2017-06-26T12:34:56-05:00" 1388 } 1389 }, 1390 { 1391 "name": "cust2:eth1", 1392 "type": "iana-if-type:ethernetCsmacd", 1393 "oper-status": "up", 1394 "phys-address": "00:01:02:A1:B1:C2", 1395 "statistics": { 1396 "discontinuity-time": "2017-06-26T12:34:56-05:00" 1397 } 1398 } 1399 ] 1400 } 1401 }, 1403 "ietf-system:system-state": { 1404 "platform": { 1405 "os-name": "NetworkOS" 1406 } 1407 }, 1409 "ietf-yang-library:modules-state": { 1410 "module-set-id": "123e4567-e89b-12d3-a456-426655440000", 1411 "module": [ 1412 { 1413 "name": "iana-if-type", 1414 "revision": "2014-05-08", 1415 "namespace": 1416 "urn:ietf:params:xml:ns:yang:iana-if-type", 1417 "conformance-type": "import" 1418 }, 1419 { 1420 "name": "ietf-inet-types", 1421 "revision": "2013-07-15", 1422 "namespace": 1423 "urn:ietf:params:xml:ns:yang:ietf-inet-types", 1424 "conformance-type": "import" 1425 }, 1426 { 1427 "name": "ietf-interfaces", 1428 "revision": "2014-05-08", 1429 "feature": [ 1430 "arbitrary-names", 1431 "pre-provisioning" 1432 ], 1433 "namespace": 1434 "urn:ietf:params:xml:ns:yang:ietf-interfaces", 1435 "conformance-type": "implement" 1436 }, 1437 { 1438 "name": "ietf-ip", 1439 "revision": "2014-06-16", 1440 "namespace": 1441 "urn:ietf:params:xml:ns:yang:ietf-ip", 1442 "conformance-type": "implement" 1443 }, 1444 { 1445 "name": "ietf-logical-network-element", 1446 "revision": "2017-03-13", 1447 "feature": [ 1448 "bind-lne-name" 1449 ], 1450 "namespace": 1451 "urn:ietf:params:xml:ns:yang:ietf-logical-network-element", 1452 "conformance-type": "implement" 1453 }, 1454 { 1455 "name": "ietf-ospf", 1456 "revision": "2017-03-12", 1457 "namespace": 1458 "urn:ietf:params:xml:ns:yang:ietf-ospf", 1459 "conformance-type": "implement" 1460 }, 1461 { 1462 "name": "ietf-routing", 1463 "revision": "2016-11-04", 1464 "namespace": 1465 "urn:ietf:params:xml:ns:yang:ietf-routing", 1466 "conformance-type": "implement" 1467 }, 1468 { 1469 "name": "ietf-system", 1470 "revision": "2014-08-06", 1471 "namespace": 1472 "urn:ietf:params:xml:ns:yang:ietf-system", 1473 "conformance-type": "implement" 1474 }, 1475 { 1476 "name": "ietf-yang-library", 1477 "revision": "2016-06-21", 1478 "namespace": 1479 "urn:ietf:params:xml:ns:yang:ietf-yang-library", 1480 "conformance-type": "implement" 1481 }, 1482 { 1483 "name": "ietf-yang-schema-mount", 1484 "revision": "2017-05-16", 1485 "namespace": 1486 "urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount", 1487 "conformance-type": "implement" 1488 }, 1489 { 1490 "name": "ietf-yang-types", 1491 "revision": "2013-07-15", 1492 "namespace": 1493 "urn:ietf:params:xml:ns:yang:ietf-yang-types", 1494 "conformance-type": "import" 1495 } 1496 ] 1497 }, 1499 "ietf-yang-schema-mount:schema-mounts": { 1500 "mount-point": [ 1501 { 1502 "module": "ietf-logical-network-element", 1503 "label": "root", 1504 "use-schema": [ 1505 { 1506 "name": "lne-schema" 1507 } 1508 ] 1509 } 1510 ], 1511 "schema": [ 1512 { 1513 "name": "lne-schema", 1514 "module": [ 1515 { 1516 "name": "ietf-yang-library", 1517 "revision": "2016-06-21", 1518 "namespace": 1519 "urn:ietf:params:xml:ns:yang:ietf-yang-library", 1520 "conformance-type": "implement" 1521 }, 1522 { 1523 "name": "ietf-system", 1524 "revision": "2014-08-06", 1525 "namespace": 1527 "urn:ietf:params:xml:ns:yang:ietf-system", 1528 "conformance-type": "implement" 1529 }, 1530 { 1531 "name": "ietf-routing", 1532 "revision": "2016-11-04", 1533 "namespace": 1534 "urn:ietf:params:xml:ns:yang:ietf-routing", 1535 "conformance-type": "implement" 1536 }, 1537 { 1538 "name": "ietf-ospf", 1539 "revision": "2017-03-12", 1540 "namespace": 1541 "urn:ietf:params:xml:ns:yang:ietf-ospf", 1542 "conformance-type": "implement" 1543 }, 1544 { 1545 "name": "ietf-interfaces", 1546 "revision": "2014-05-08", 1547 "namespace": 1548 "urn:ietf:params:xml:ns:yang:ietf-interfaces", 1549 "conformance-type": "implement" 1550 }, 1551 { 1552 "name": "ietf-ip", 1553 "revision": "2014-06-16", 1554 "namespace": 1555 "urn:ietf:params:xml:ns:yang:ietf-ip", 1556 "conformance-type": "implement" 1557 } 1558 ] 1559 } 1560 ] 1561 } 1562 } 1564 B.2. Example: Self Managed LNE 1566 This section describes an example of the LNE model using schema mount 1567 to achieve child independent management. An example device supports 1568 multiple instances of LNEs (logical routers), each of them has the 1569 features of layer 2 and layer 3 interfaces [RFC7223], routing 1570 information base [RFC8022], and the OSPF protocol. Each of these 1571 features is specified by a YANG model, and they are put together by 1572 the YANG Schema Mount as following: 1574 module: ietf-logical-network-element 1575 +--rw logical-network-elements 1576 +--rw logical-network-element* [name] 1577 +--rw name string 1578 +--mp root 1579 // The internal modules of the LNE are not visible to 1580 // the parament management. 1581 // The child manages its modules, including ietf-routing 1582 // and ietf-interfaces 1584 module: ietf-interfaces 1585 +--rw interfaces 1586 | +--rw interface* [name] 1587 | +--rw name string 1588 | +--rw lne:bind-lne-name? string 1589 +--ro interfaces-state 1590 +--ro interface* [name] 1591 +--ro name string 1592 +--ro oper-status enumeration 1594 module: ietf-yang-library 1595 +--ro modules-state 1596 +--ro module-set-id string 1597 +--ro module* [name revision] 1598 +--ro name yang:yang-identifier 1600 module: ietf-system 1601 +--rw system 1602 | +--rw contact? string 1603 | +--rw hostname? inet:domain-name 1604 | +--rw authentication {authentication}? 1605 | +--rw user-authentication-order* identityref 1606 | +--rw user* [name] {local-users}? 1607 | +--rw name string 1608 | +--rw password? ianach:crypt-hash 1609 | +--rw authorized-key* [name] 1610 | +--rw name string 1611 | +--rw algorithm string 1612 | +--rw key-data binary 1613 +--ro system-state 1614 +--ro platform 1615 | +--ro os-name? string 1616 | +--ro os-release? string 1618 To realize the above schema, the device implements the following 1619 schema mount instance: 1621 "ietf-yang-schema-mount:schema-mounts": { 1622 "mount-point": [ 1623 { 1624 "module": "ietf-logical-network-element", 1625 "label": "root", 1626 "inline": [null] 1627 } 1628 ] 1629 } 1631 By using the implementation of the YANG schema mount, an operator can 1632 create instances of logical routers, each with their logical router 1633 specific in-line modules. An interface can be assigned to a logical 1634 router, so that the logical router has the permission to access this 1635 interface. The OSPF protocol can then be enabled on this assigned 1636 interface. Each logical router independently manages its own set of 1637 modules, which may or may not be the same as other logical routers. 1638 The following is an example of schema set implemented on one 1639 particular logical router: 1641 module: ietf-yang-library 1642 +--ro modules-state 1643 +--ro module-set-id string 1644 +--ro module* [name revision] 1645 +--ro name yang:yang-identifier 1647 module: ietf-system 1648 +--rw system 1649 | +--rw contact? string 1650 | +--rw hostname? inet:domain-name 1651 | +--rw authentication {authentication}? 1652 | +--rw user-authentication-order* identityref 1653 | +--rw user* [name] {local-users}? 1654 | +--rw name string 1655 | +--rw password? ianach:crypt-hash 1656 | +--rw authorized-key* [name] 1657 | +--rw name string 1658 | +--rw algorithm string 1659 | +--rw key-data binary 1660 +--ro system-state 1661 +--ro platform 1662 | +--ro os-name? string 1663 | +--ro os-release? string 1665 module: ietf-routing 1666 +--ro routing-state 1667 | +--ro router-id? yang:dotted-quad 1668 | +--ro control-plane-protocols 1669 | | +--ro control-plane-protocol* [type name] 1670 | | +--ro ospf:ospf/ 1671 | | +--ro instance* [af] 1672 +--rw routing 1673 +--rw router-id? yang:dotted-quad 1674 +--rw control-plane-protocols 1675 +--rw control-plane-protocol* [type name] 1676 +--rw ospf:ospf/ 1677 +--rw instance* [af] 1678 +--rw areas 1679 +--rw area* [area-id] 1680 +--rw interfaces 1681 +--rw interface* [name] 1682 +--rw name if:interface-ref 1683 +--rw cost? uint16 1685 module: ietf-interfaces 1686 +--rw interfaces 1687 | +--rw interface* [name] 1688 | +--rw name string 1689 +--ro interfaces-state 1690 +--ro interface* [name] 1691 +--ro name string 1692 +--ro oper-status enumeration 1694 B.2.1. Configuration Data 1696 Each of the child virtual routers is managed through its own sessions 1697 and configuration data. 1699 B.2.1.1. Logical Network Element 'vnf1' 1701 The following shows an example configuration data for the LNE name 1702 "vnf1": 1704 { 1705 "ietf-system:system": { 1706 "authentication": { 1707 "user": [ 1708 { 1709 "name": "john", 1710 "password": "$0$password" 1711 } 1712 ] 1713 } 1714 }, 1715 "ietf-routing:routing": { 1716 "router-id": "192.0.2.1", 1717 "control-plane-protocols": { 1718 "control-plane-protocol": [ 1719 { 1720 "type": "ietf-routing:ospf", 1721 "name": "1", 1722 "ietf-ospf:ospf": { 1723 "instance": [ 1724 { 1725 "af": "ipv4", 1726 "areas": { 1727 "area": [ 1728 { 1729 "area-id": "203.0.113.1", 1730 "interfaces": { 1731 "interface": [ 1732 { 1733 "name": "eth1", 1734 "cost": 10 1735 } 1736 ] 1737 } 1738 } 1739 ] 1740 } 1741 } 1742 ] 1743 } 1744 } 1745 ] 1746 } 1747 }, 1748 "ietf-interfaces:interfaces": { 1749 "interfaces": { 1750 "interface": [ 1751 { 1752 "name": "eth1", 1753 "ip:ipv4": { 1754 "address": [ 1755 { 1756 "ip": "192.0.2.11", 1757 "prefix-length": 24, 1758 } 1759 ] 1760 } 1761 } 1762 ] 1763 } 1764 } 1766 } 1768 B.2.1.2. Logical Network Element 'vnf2' 1770 The following shows an example configuration data for the LNE name 1771 "vnf2": 1773 { 1774 "ietf-system:system": { 1775 "authentication": { 1776 "user": [ 1777 { 1778 "name": "john", 1779 "password": "$0$password" 1780 } 1781 ] 1782 } 1783 }, 1784 "ietf-routing:routing": { 1785 "router-id": "192.0.2.2", 1786 "control-plane-protocols": { 1787 "control-plane-protocol": [ 1788 { 1789 "type": "ietf-routing:ospf", 1790 "name": "1", 1791 "ietf-ospf:ospf": { 1792 "instance": [ 1793 { 1794 "af": "ipv4", 1795 "areas": { 1796 "area": [ 1797 { 1798 "area-id": "203.0.113.1", 1799 "interfaces": { 1800 "interface": [ 1801 { 1802 "name": "eth1", 1803 "cost": 10 1804 } 1805 ] 1806 } 1807 } 1808 ] 1809 } 1810 } 1811 ] 1812 } 1813 } 1815 ] 1816 } 1817 }, 1818 "ietf-interfaces:interfaces": { 1819 "interfaces": { 1820 "interface": [ 1821 { 1822 "name": "eth1", 1823 "ip:ipv4": { 1824 "address": [ 1825 { 1826 "ip": "192.0.2.11", 1827 "prefix-length": 24, 1828 } 1829 ] 1830 } 1831 } 1832 ] 1833 } 1834 } 1835 } 1837 B.2.2. State Data 1839 The following sections shows possible state data associated the above 1840 configuration data. Note that there are three views: the host 1841 device's, and each LNE's. 1843 B.2.2.1. Host Device 1845 The following shows state data for the device hosting the example 1846 LNEs: 1848 { 1849 "ietf-logical-network-element:logical-network-elements": { 1850 "logical-network-element": [ 1851 { 1852 "name": "vnf1", 1853 "root": { 1854 } 1855 }, 1856 { 1857 "name": "vnf2", 1858 "root": { 1859 } 1860 } 1861 ] 1862 }, 1863 "ietf-interfaces:interfaces-state": { 1864 "interfaces": { 1865 "interface": [ 1866 { 1867 "name": "eth0", 1868 "type": "iana-if-type:ethernetCsmacd", 1869 "oper-status": "up", 1870 "phys-address": "00:01:02:A1:B1:C0", 1871 "statistics": { 1872 "discontinuity-time": "2017-06-26T12:34:56-05:00" 1873 }, 1874 "ip:ipv4": { 1875 "address": [ 1876 { 1877 "ip": "192.0.2.10", 1878 "prefix-length": 24, 1879 } 1880 ] 1881 } 1882 }, 1883 { 1884 "name": "vnf1:eth1", 1885 "type": "iana-if-type:ethernetCsmacd", 1886 "oper-status": "up", 1887 "phys-address": "00:01:02:A1:B1:C1", 1888 "statistics": { 1889 "discontinuity-time": "2017-06-26T12:34:56-05:00" 1890 } 1891 }, 1892 { 1893 "name": "vnf2:eth2", 1894 "type": "iana-if-type:ethernetCsmacd", 1895 "oper-status": "up", 1896 "phys-address": "00:01:02:A1:B1:C2", 1897 "statistics": { 1898 "discontinuity-time": "2017-06-26T12:34:56-05:00" 1899 } 1900 } 1901 ] 1902 } 1903 }, 1905 "ietf-system:system-state": { 1906 "platform": { 1907 "os-name": "NetworkOS" 1908 } 1909 }, 1910 "ietf-yang-library:modules-state": { 1911 "module-set-id": "123e4567-e89b-12d3-a456-426655440000", 1912 "module": [ 1913 { 1914 "name": "iana-if-type", 1915 "revision": "2014-05-08", 1916 "namespace": 1917 "urn:ietf:params:xml:ns:yang:iana-if-type", 1918 "conformance-type": "import" 1919 }, 1920 { 1921 "name": "ietf-inet-types", 1922 "revision": "2013-07-15", 1923 "namespace": 1924 "urn:ietf:params:xml:ns:yang:ietf-inet-types", 1925 "conformance-type": "import" 1926 }, 1927 { 1928 "name": "ietf-interfaces", 1929 "revision": "2014-05-08", 1930 "feature": [ 1931 "arbitrary-names", 1932 "pre-provisioning" 1933 ], 1934 "namespace": 1935 "urn:ietf:params:xml:ns:yang:ietf-interfaces", 1936 "conformance-type": "implement" 1937 }, 1938 { 1939 "name": "ietf-ip", 1940 "revision": "2014-06-16", 1941 "namespace": 1942 "urn:ietf:params:xml:ns:yang:ietf-ip", 1943 "conformance-type": "implement" 1944 }, 1945 { 1946 "name": "ietf-logical-network-element", 1947 "revision": "2017-03-13", 1948 "feature": [ 1949 "bind-lne-name" 1950 ], 1951 "namespace": 1952 "urn:ietf:params:xml:ns:yang:ietf-logical-network-element", 1953 "conformance-type": "implement" 1954 }, 1955 { 1956 "name": "ietf-system", 1957 "revision": "2014-08-06", 1958 "namespace": 1959 "urn:ietf:params:xml:ns:yang:ietf-system", 1960 "conformance-type": "implement" 1961 }, 1962 { 1963 "name": "ietf-yang-library", 1964 "revision": "2016-06-21", 1965 "namespace": 1966 "urn:ietf:params:xml:ns:yang:ietf-yang-library", 1967 "conformance-type": "implement" 1968 }, 1969 { 1970 "name": "ietf-yang-schema-mount", 1971 "revision": "2017-05-16", 1972 "namespace": 1973 "urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount", 1974 "conformance-type": "implement" 1975 }, 1976 { 1977 "name": "ietf-yang-types", 1978 "revision": "2013-07-15", 1979 "namespace": 1980 "urn:ietf:params:xml:ns:yang:ietf-yang-types", 1981 "conformance-type": "import" 1982 } 1983 ] 1984 }, 1986 "ietf-yang-schema-mount:schema-mounts": { 1987 "mount-point": [ 1988 { 1989 "module": "ietf-logical-network-element", 1990 "label": "root", 1991 "inline": [null] 1992 } 1993 ] 1994 } 1995 } 1997 B.2.2.2. Logical Network Element 'vnf1' 1999 The following shows state data for the example LNE with name "vnf1": 2001 { 2002 "ietf-yang-library:modules-state": { 2003 "module-set-id": "123e4567-e89b-12d3-a456-426655440000", 2004 "module": [ 2005 { 2006 "name": "iana-if-type", 2007 "revision": "2014-05-08", 2008 "namespace": 2009 "urn:ietf:params:xml:ns:yang:iana-if-type", 2010 "conformance-type": "import" 2011 }, 2012 { 2013 "name": "ietf-inet-types", 2014 "revision": "2013-07-15", 2015 "namespace": 2016 "urn:ietf:params:xml:ns:yang:ietf-inet-types", 2017 "conformance-type": "import" 2018 }, 2019 { 2020 "name": "ietf-interfaces", 2021 "revision": "2014-05-08", 2022 "feature": [ 2023 "arbitrary-names", 2024 "pre-provisioning" 2025 ], 2026 "namespace": 2027 "urn:ietf:params:xml:ns:yang:ietf-interfaces", 2028 "conformance-type": "implement" 2029 }, 2030 { 2031 "name": "ietf-ip", 2032 "revision": "2014-06-16", 2033 "namespace": 2034 "urn:ietf:params:xml:ns:yang:ietf-ip", 2035 "conformance-type": "implement" 2036 }, 2037 { 2038 "name": "ietf-ospf", 2039 "revision": "2017-03-12", 2040 "namespace": 2041 "urn:ietf:params:xml:ns:yang:ietf-ospf", 2042 "conformance-type": "implement" 2043 }, 2044 { 2045 "name": "ietf-routing", 2046 "revision": "2016-11-04", 2047 "namespace": 2048 "urn:ietf:params:xml:ns:yang:ietf-routing", 2049 "conformance-type": "implement" 2050 }, 2051 { 2052 "name": "ietf-system", 2053 "revision": "2014-08-06", 2054 "namespace": 2055 "urn:ietf:params:xml:ns:yang:ietf-system", 2056 "conformance-type": "implement" 2057 }, 2058 { 2059 "name": "ietf-yang-library", 2060 "revision": "2016-06-21", 2061 "namespace": 2062 "urn:ietf:params:xml:ns:yang:ietf-yang-library", 2063 "conformance-type": "implement" 2064 }, 2065 { 2066 "name": "ietf-yang-types", 2067 "revision": "2013-07-15", 2068 "namespace": 2069 "urn:ietf:params:xml:ns:yang:ietf-yang-types", 2070 "conformance-type": "import" 2071 } 2072 ] 2073 }, 2075 "ietf-system:system-state": { 2076 "platform": { 2077 "os-name": "NetworkOS" 2078 } 2079 }, 2081 "ietf-routing:routing-state": { 2082 "router-id": "192.0.2.1", 2083 "control-plane-protocols": { 2084 "control-plane-protocol": [ 2085 { 2086 "type": "ietf-routing:ospf", 2087 "name": "1", 2088 "ietf-ospf:ospf": { 2089 "instance": [ 2090 { 2091 "af": "ipv4", 2092 "areas": { 2093 "area": [ 2094 { 2095 "area-id": "203.0.113.1", 2096 "interfaces": { 2097 "interface": [ 2098 { 2099 "name": "eth1", 2100 "cost": 10 2101 } 2103 ] 2104 } 2105 } 2106 ] 2107 } 2108 } 2109 ] 2110 } 2111 } 2112 ] 2113 } 2114 }, 2116 "ietf-interfaces:interfaces-state": { 2117 "interfaces": { 2118 "interface": [ 2119 { 2120 "name": "eth1", 2121 "type": "iana-if-type:ethernetCsmacd", 2122 "oper-status": "up", 2123 "phys-address": "00:01:02:A1:B1:C1", 2124 "statistics": { 2125 "discontinuity-time": "2017-06-26T12:34:56-05:00" 2126 }, 2127 "ip:ipv4": { 2128 "address": [ 2129 { 2130 "ip": "192.0.2.11", 2131 "prefix-length": 24, 2132 } 2133 ] 2134 } 2135 } 2136 ] 2137 } 2138 } 2139 } 2141 B.2.2.3. Logical Network Element 'vnf2' 2143 The following shows state data for the example LNE with name "vnf2": 2145 { 2146 "ietf-yang-library:modules-state": { 2147 "module-set-id": "123e4567-e89b-12d3-a456-426655440000", 2148 "module": [ 2149 { 2150 "name": "iana-if-type", 2151 "revision": "2014-05-08", 2152 "namespace": 2153 "urn:ietf:params:xml:ns:yang:iana-if-type", 2154 "conformance-type": "import" 2155 }, 2156 { 2157 "name": "ietf-inet-types", 2158 "revision": "2013-07-15", 2159 "namespace": 2160 "urn:ietf:params:xml:ns:yang:ietf-inet-types", 2161 "conformance-type": "import" 2162 }, 2163 { 2164 "name": "ietf-interfaces", 2165 "revision": "2014-05-08", 2166 "feature": [ 2167 "arbitrary-names", 2168 "pre-provisioning" 2169 ], 2170 "namespace": 2171 "urn:ietf:params:xml:ns:yang:ietf-interfaces", 2172 "conformance-type": "implement" 2173 }, 2174 { 2175 "name": "ietf-ip", 2176 "revision": "2014-06-16", 2177 "namespace": 2178 "urn:ietf:params:xml:ns:yang:ietf-ip", 2179 "conformance-type": "implement" 2180 }, 2181 { 2182 "name": "ietf-ospf", 2183 "revision": "2017-03-12", 2184 "namespace": 2185 "urn:ietf:params:xml:ns:yang:ietf-ospf", 2186 "conformance-type": "implement" 2187 }, 2188 { 2189 "name": "ietf-routing", 2190 "revision": "2016-11-04", 2191 "namespace": 2192 "urn:ietf:params:xml:ns:yang:ietf-routing", 2193 "conformance-type": "implement" 2194 }, 2195 { 2196 "name": "ietf-system", 2197 "revision": "2014-08-06", 2198 "namespace": 2200 "urn:ietf:params:xml:ns:yang:ietf-system", 2201 "conformance-type": "implement" 2202 }, 2203 { 2204 "name": "ietf-yang-library", 2205 "revision": "2016-06-21", 2206 "namespace": 2207 "urn:ietf:params:xml:ns:yang:ietf-yang-library", 2208 "conformance-type": "implement" 2209 }, 2210 { 2211 "name": "ietf-yang-types", 2212 "revision": "2013-07-15", 2213 "namespace": 2214 "urn:ietf:params:xml:ns:yang:ietf-yang-types", 2215 "conformance-type": "import" 2216 } 2217 ] 2218 }, 2220 "ietf-system:system-state": { 2221 "platform": { 2222 "os-name": "NetworkOS" 2223 } 2224 }, 2226 "ietf-routing:routing-state": { 2227 "router-id": "192.0.2.2", 2228 "control-plane-protocols": { 2229 "control-plane-protocol": [ 2230 { 2231 "type": "ietf-routing:ospf", 2232 "name": "1", 2233 "ietf-ospf:ospf": { 2234 "instance": [ 2235 { 2236 "af": "ipv4", 2237 "areas": { 2238 "area": [ 2239 { 2240 "area-id": "203.0.113.1", 2241 "interfaces": { 2242 "interface": [ 2243 { 2244 "name": "eth1", 2245 "cost": 10 2246 } 2247 ] 2249 } 2250 } 2251 ] 2252 } 2253 } 2254 ] 2255 } 2256 } 2257 ] 2258 } 2259 }, 2261 "ietf-interfaces:interfaces-state": { 2262 "interfaces": { 2263 "interface": [ 2264 { 2265 "name": "eth1", 2266 "type": "iana-if-type:ethernetCsmacd", 2267 "oper-status": "up", 2268 "phys-address": "00:01:02:A1:B1:C2", 2269 "statistics": { 2270 "discontinuity-time": "2017-06-26T12:34:56-05:00" 2271 }, 2272 "ip:ipv4": { 2273 "address": [ 2274 { 2275 "ip": "192.0.2.11", 2276 "prefix-length": 24, 2277 } 2278 ] 2279 } 2280 } 2281 ] 2282 } 2283 } 2284 } 2286 Authors' Addresses 2288 Lou Berger 2289 LabN Consulting, L.L.C. 2291 Email: lberger@labn.net 2292 Christan Hopps 2293 Deutsche Telekom 2295 Email: chopps@chopps.org 2297 Acee Lindem 2298 Cisco Systems 2299 301 Midenhall Way 2300 Cary, NC 27513 2301 USA 2303 Email: acee@cisco.com 2305 Dean Bogdanovic 2307 Email: ivandean@gmail.com 2309 Xufeng Liu 2310 Jabil 2312 Email: Xufeng_Liu@jabil.com