idnits 2.17.1 draft-ietf-rtgwg-lne-model-10.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 757 has weird spacing: '...-set-id str...' == Line 770 has weird spacing: '...gorithm str...' == Line 801 has weird spacing: '...-set-id str...' == Line 816 has weird spacing: '...gorithm str...' == Line 849 has weird spacing: '...-set-id str...' == (7 more instances...) -- The document date (March 19, 2018) is 2192 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 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) == Outdated reference: A later version (-12) exists of draft-ietf-rtgwg-ni-model-11 -- Obsolete informational reference (is this intentional?): RFC 7895 (Obsoleted by RFC 8525) Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Berger 3 Internet-Draft LabN Consulting, L.L.C. 4 Intended status: Standards Track C. Hopps 5 Expires: September 20, 2018 Deutsche Telekom 6 A. Lindem 7 Cisco Systems 8 D. Bogdanovic 10 X. Liu 11 Jabil 12 March 19, 2018 14 YANG Model for Logical Network Elements 15 draft-ietf-rtgwg-lne-model-10 17 Abstract 19 This document defines a logical network element YANG module. This 20 module can be used to manage the logical resource partitioning that 21 may be present on a network device. Examples of common industry 22 terms for logical resource partitioning are Logical Systems or 23 Logical Routers. The YANG model in this document conforms to the 24 Network Management Datastore Architecture as defined in RFCXXXX. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 20, 2018. 43 Copyright Notice 45 Copyright (c) 2018 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Logical Network Elements . . . . . . . . . . . . . . . . . . 5 64 3.1. LNE Instantiation and Resource Assignment . . . . . . . . 6 65 3.2. LNE Management - LNE View . . . . . . . . . . . . . . . . 7 66 3.3. LNE Management - Host Network Device View . . . . . . . . 7 67 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 69 6. Logical Network Element Model . . . . . . . . . . . . . . . . 10 70 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 71 7.1. Normative References . . . . . . . . . . . . . . . . . . 14 72 7.2. Informative References . . . . . . . . . . . . . . . . . 15 73 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 16 74 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 17 75 B.1. Example: Host Device Managed LNE . . . . . . . . . . . . 17 76 B.1.1. Configuration Data . . . . . . . . . . . . . . . . . 20 77 B.1.2. State Data . . . . . . . . . . . . . . . . . . . . . 24 78 B.2. Example: Self Managed LNE . . . . . . . . . . . . . . . . 33 79 B.2.1. Configuration Data . . . . . . . . . . . . . . . . . 36 80 B.2.2. State Data . . . . . . . . . . . . . . . . . . . . . 39 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 83 1. Introduction 85 This document defines a YANG [RFC6020] module to support the creation 86 of logical network elements on a network device. A logical network 87 element (LNE) is an independently managed virtual device made up of 88 resources allocated to it from the host or parent network device. An 89 LNE running on a host network device conceptually parallels a virtual 90 machine running on a host system. Using host-virtualization 91 terminology one could refer to an LNE as a "Guest", and the 92 containing network-device as the "Host". While LNEs may be 93 implemented via host-virtualization technologies this is not a 94 requirement. The YANG model in this document conforms to the Network 95 Management Datastore Architecture defined in the 96 [I-D.ietf-netmod-revised-datastores]. 98 This document also defines the necessary augmentations for allocating 99 host resources to a given LNE. As the interface management model 100 [I-D.ietf-netmod-rfc7223bis] is the only a module that currently 101 defines host resources, this document currently defines only a single 102 augmentation to cover the assignment of interfaces to an LNE. Future 103 modules that define support for the control of host device resources 104 are expected to, where appropriate, provide parallel support for the 105 assignment of controlled resources to LNEs. 107 As each LNE is an independently managed device, each will have its 108 own set of YANG modeled data that is independent of the host device 109 and other LNEs. For example, multiple LNEs may all have their own 110 "Tunnel0" interface defined which will not conflict with each other 111 and will not exist in the host's interface model. An LNE will have 112 its own management interfaces possibly including independent 113 instances of netconf/restconf/etc servers to support configuration of 114 their YANG models. As an example of this independence, an 115 implementation may choose to completely rename assigned interfaces, 116 so on the host the assigned interface might be called "Ethernet0/1" 117 while within the LNE it might be called "eth1". 119 In addition to standard management interfaces, a host device 120 implementation may support accessing LNE configuration and 121 operational YANG models directly from the host system. When 122 supported, such access is accomplished through a yang-schema-mount 123 mount point [I-D.ietf-netmod-schema-mount] under which the root level 124 LNE YANG models may be accessed. 126 Examples of vendor terminology for an LNE include logical system or 127 logical router, and virtual switch, chassis, or fabric. 129 1.1. Terminology 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 133 "OPTIONAL" in this document are to be interpreted as described in BCP 134 14 [RFC2119] [RFC8174] when, and only when, they appear in all 135 capitals, as shown here. 137 Readers are expected to be familiar with terms and concepts of YANG 138 [RFC7950] and YANG Schema Mount [I-D.ietf-netmod-schema-mount]. 140 This document uses the graphical representation of data models 141 defined in [I-D.ietf-netmod-yang-tree-diagrams]. 143 2. Overview 145 In this document, we consider network devices that support protocols 146 and functions defined within the IETF Routing Area, e.g, routers, 147 firewalls, and hosts. Such devices may be physical or virtual, e.g., 148 a classic router with custom hardware or one residing within a 149 server-based virtual machine implementing a virtual network function 150 (VNF). Each device may sub-divide their resources into logical 151 network elements (LNEs), each of which provides a managed logical 152 device. Examples of vendor terminology for an LNE include logical 153 system or logical router, and virtual switch, chassis, or fabric. 154 Each LNE may also support virtual routing and forwarding (VRF) and 155 virtual switching instance (VSI) functions, which are referred to 156 below as a network instances (NIs). This breakdown is represented in 157 Figure 1. 159 ,'''''''''''''''''''''''''''''''''''''''''''''''. 160 | Network Device (Physical or Virtual) | 161 | ..................... ..................... | 162 | : Logical Network : : Logical Network : | 163 | : Element : : Element : | 164 | :+-----+-----+-----+: :+-----+-----+-----+: | 165 | :| Net | Net | Net |: :| Net | Net | Net |: | 166 | :|Inst.|Inst.|Inst.|: :|Inst.|Inst.|Inst.|: | 167 | :+-----+-----+-----+: :+-----+-----+-----+: | 168 | : | | | | | | : : | | | | | | : | 169 | :..|.|...|.|...|.|..: :..|.|...|.|...|.|..: | 170 | | | | | | | | | | | | | | 171 ''''|'|'''|'|'''|'|'''''''''|'|'''|'|'''|'|''''' 172 | | | | | | | | | | | | 173 Interfaces Interfaces 175 Figure 1: Module Element Relationships 177 A model for LNEs is described in Section 3 and the model for NIs is 178 covered in [I-D.ietf-rtgwg-ni-model]. 180 The interface management model [I-D.ietf-netmod-rfc7223bis] is an 181 existing model that is impacted by the definition of LNEs and network 182 instances. This document and [I-D.ietf-rtgwg-ni-model] define 183 augmentations to the interface module to support LNEs and NIs. 184 Similar elements, although perhaps only for LNEs, may also need to be 185 included as part of the definition of the future hardware and QoS 186 modules. 188 Interfaces are a crucial part of any network device's configuration 189 and operational state. They generally include a combination of raw 190 physical interfaces, link-layer interfaces, addressing configuration, 191 and logical interfaces that may not be tied to any physical 192 interface. Several system services, and layer 2 and layer 3 193 protocols may also associate configuration or operational state data 194 with different types of interfaces (these relationships are not shown 195 for simplicity). The interface management model is defined by 196 [I-D.ietf-netmod-rfc7223bis]. The logical-network-element module 197 augments existing interface management model by adding an identifier 198 which is used on interfaces to identify an associated LNE. 200 The interface related augmentation is as follows: 202 module: ietf-logical-network-element 203 augment /if:interfaces/if:interface: 204 +--rw bind-lne-name? -> 205 /logical-network-elements/logical-network-element/name 207 The interface model defined in [I-D.ietf-netmod-rfc7223bis] is 208 structured to include all interfaces in a flat list, without regard 209 to logical assignment of resources supported on the device. The 210 bind-lne-name and leaf provides the association between an interface 211 and its associated LNE. Note that as currently defined, to assign an 212 interface to both an LNE and NI, the interface would first be 213 assigned to the LNE and then within that LNE's interface module, the 214 LNE's representation of that interface would be assigned to an NI 215 using the mechanisms defined in [I-D.ietf-rtgwg-ni-model]. 217 3. Logical Network Elements 219 Logical network elements support the ability of some devices to 220 partition resources into independent logical routers and/or switches. 221 Device support for multiple logical network elements is 222 implementation specific. Systems without such capabilities need not 223 include support for the logical-network-element module. In physical 224 devices, some hardware features are shared across partitions, but 225 control plane (e.g., routing) protocol instances, tables, and 226 configuration are managed separately. For example, in logical 227 routers or VNFs, this may correspond to establishing multiple logical 228 instances using a single software installation. The model supports 229 configuration of multiple instances on a single device by creating a 230 list of logical network elements, each with their own configuration 231 and operational state related to routing and switching protocols. 233 The LNE model can be represented as: 235 module: ietf-logical-network-element 236 +--rw logical-network-elements 237 +--rw logical-network-element* [name] 238 +--rw name string 239 +--rw managed? boolean 240 +--rw description? string 241 +--mp root 242 augment /if:interfaces/if:interface: 243 +--rw bind-lne-name? 244 -> /logical-network-elements/logical-network-element/name 246 notifications: 247 +---n bind-lne-name-failed 248 +--ro name -> /if:interfaces/interface/name 249 +--ro bind-lne-name 250 | -> /if:interfaces/interface/lne:bind-lne-name 251 +--ro error-info? string 253 'name' identifies the logical network element. 'managed' indicates 254 if the server providing the host network device will provide the 255 client LNE information via the 'root' structure. The root of an 256 LNE's specific data is the schema mount point 'root'. bind-lne-name 257 is used to associated an interface with an LNE and bind-lne-name- 258 failed is used in certain failure cases. 260 An LNE root MUST contain at least the YANG library [RFC7895] and 261 Interfaces [I-D.ietf-netmod-rfc7223bis] modules. 263 3.1. LNE Instantiation and Resource Assignment 265 Logical network elements may be controlled by clients using existing 266 list operations. When list entries are created, a new LNE is 267 instantiated. The models mounted under an LNE root are expected to 268 be dependent on the server implementation. When a list entry is 269 deleted, an existing LNE is destroyed. For more information, see 270 [RFC7950] Section 7.8.6. 272 Once instantiated, host network device resources can be associated 273 with the new LNE. As previously mentioned, this document augments 274 ietf-interfaces with the bind-lne-name leaf to support such 275 associations for interfaces. When an bind-lne-name is set to a valid 276 LNE name, an implementation MUST take whatever steps are internally 277 necessary to assign the interface to the LNE or provide an error 278 message (defined below) with an indication of why the assignment 279 failed. It is possible for the assignment to fail while processing 280 the set, or after asynchronous processing. Error notification in the 281 latter case is supported via a notification. 283 On a successful interface assignment to an LNE, an implementation 284 MUST also make the resource available to the LNE by providing a 285 system created interface to the LNE. The name of the system created 286 interface is a local matter and may be identical or completely 287 different, and mapped from and to, the name used in the context of 288 the host device. The system created interface SHOULD be exposed via 289 the LNE-specific instance of the interfaces module 290 [I-D.ietf-netmod-rfc7223bis]. 292 3.2. LNE Management - LNE View 294 Each LNE instance is expected to support management functions from 295 within the context of the LNE root, via a server that provides 296 information with the LNE's root exposed as device root. Management 297 functions operating within the context of an LNE are accessed through 298 the LNE's standard management interfaces, e.g., NETCONF and SNMP. 299 Initial configuration, much like the initial configuration of the 300 host device, is a local implementation matter. 302 When accessing an LNE via the LNE's management interface, a network- 303 device representation will be presented, but its scope will be 304 limited to the specific LNE. Normal YANG/NETCONF mechanisms, 305 together with the required YANG library [RFC7895] instance, can be 306 used to identify the available modules. Each supported module will 307 be presented as a top level module. Only LNE associated resources 308 will be reflected in resource related modules, e.g., interfaces, 309 hardware, and perhaps QoS. From the management perspective, there 310 will be no difference between the available LNE view (information) 311 and a physical network device. 313 3.3. LNE Management - Host Network Device View 315 There are multiple implementation approaches possible to enable a 316 network device to support the logical-network-element module and 317 multiple LNEs. Some approaches will allow the management functions 318 operating at network device level to access LNE configuration and 319 operational information, while others will not. Similarly, even when 320 LNE management from the network device is supported by the 321 implementation, it may be prohibited by user policy. 323 Independent of the method selected by an implementation, the 324 'managed' boolean mentioned above is used to indicate when LNE 325 management from the network device context is possible. When the 326 'managed' boolean is 'false', the LNE cannot be managed by the host 327 system and can only be managed from within the context of the LNE as 328 described in the previous section, Section 3.2. Attempts to access 329 information below a root node whose associated 'managed' boolean is 330 set to 'false' MUST result in the error message indicated below. In 331 some implementations, it may not be possible to change this value. 332 For example, when an LNE is implemented using virtual machine and 333 traditional hypervisor technologies, it is likely that this value 334 will be restricted to a 'false' value. 336 It is an implementation choice if the information can be accessed and 337 modified from within the context of the LNE, or even the context of 338 the host device. When the 'managed' boolean is 'true', LNE 339 information SHALL be accessible from the context of the host device. 340 When the associated schema-mount definition has the 'config' leaf set 341 to 'true', then LNE information SHALL also be modifiable from the 342 context of the host device. When LNE information is available from 343 both the host device and from within the context of the LNE, the same 344 information MUST be made available via the 'root' element, with paths 345 modified as described in [I-D.ietf-netmod-schema-mount]. 347 An implementation MAY represent an LNE's schema using either the 348 'inline' or 'shared-schema' approaches defined in 349 [I-D.ietf-netmod-schema-mount]. The choice of which to use is 350 completely an implementation choice. The inline case is anticipated 351 to be generally used in the cases where the 'managed' will always be 352 'false'. The 'shared-schema' approach is expected to be be most 353 useful in the case where all LNEs share the same schema. When 354 'shared-schema' is used with an LNE mount point, the YANG library 355 rooted in the LNE's mount point MUST match the associated schema 356 defined according to the ietf-yang-schema-mount module. 358 Beyond the two modules that will always be present for an LNE, as an 359 LNE is a network device itself, all modules that may be present at 360 the top level network device MAY also be present for the LNE. The 361 list of available modules is expected to be implementation dependent. 362 As is the method used by an implementation to support LNEs. 363 Appendix B provide example uses of LNEs. 365 4. Security Considerations 367 The YANG modules specified in this document define a schema for data 368 that is designed to be accessed via network management protocols such 369 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 370 is the secure transport layer, and the mandatory-to-implement secure 371 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 372 is HTTPS, and the mandatory-to-implement secure transport is TLS 373 [RFC5246]. 375 The NETCONF access control model [RFC6536] provides the means to 376 restrict access for particular NETCONF or RESTCONF users to a 377 preconfigured subset of all available NETCONF or RESTCONF protocol 378 operations and content. 380 LNE information represents device and network configuration 381 information. As such, the security of this information is important, 382 but it is fundamentally no different than any other interface or 383 device configuration information that has already been covered in 384 other documents such as [I-D.ietf-netmod-rfc7223bis], [RFC7317] and 385 [I-D.ietf-netmod-rfc8022bis]. 387 The vulnerable "config true" parameters and subtrees are the 388 following: 390 /logical-network-elements/logical-network-element: This list 391 specifies the logical network element and the related logical 392 device configuration. 394 /logical-network-elements/logical-network-element/managed: While 395 this leaf is contained in the previous list, it is worth 396 particular attention as it controls whether information under the 397 LNE mount point is accessible by both the host device and within 398 the LNE context. There may be extra sensitivity to this leaf in 399 environments where an LNE is managed by a different party than the 400 host device, and that party does not wish to share LNE information 401 with the operator of the host device. 403 /if:interfaces/if:interface/bind-lne-name: This leaf indicates the 404 LNE instance to which an interface is assigned. Implementations 405 should pay particular attention to when changes to this leaf are 406 permitted as removal of an interface from an LNE can have major 407 impact on the LNEs operation as it is similar to physically 408 removing an interface from the device. Implementations can reject 409 an reassignment using the previously described error message 410 generation. 412 Unauthorized access to any of these lists can adversely affect the 413 security of both the local device and the network. This may lead to 414 network malfunctions, delivery of packets to inappropriate 415 destinations, and other problems. 417 5. IANA Considerations 419 This document registers a URI in the IETF XML registry [RFC3688]. 420 Following the format in RFC 3688, the following registration is 421 requested to be made. 423 URI: urn:ietf:params:xml:ns:yang:ietf-logical-network-element 425 Registrant Contact: The IESG. 427 XML: N/A, the requested URI is an XML namespace. 429 This document registers a YANG module in the YANG Module Names 430 registry [RFC6020]. 432 name: ietf-logical-network-element 433 namespace: urn:ietf:params:xml:ns:yang:ietf-logical-network-element 434 prefix: lne 435 reference: RFC XXXX 437 6. Logical Network Element Model 439 The structure of the model defined in this document is described by 440 the YANG module below. 442 file "ietf-logical-network-element@2018-03-20.yang" 443 module ietf-logical-network-element { 444 yang-version 1.1; 446 // namespace 448 namespace 449 "urn:ietf:params:xml:ns:yang:ietf-logical-network-element"; 450 prefix lne; 452 // import some basic types 454 import ietf-interfaces { 455 prefix if; 456 reference "draft-ietf-netmod-rfc7223bis: 457 A YANG Data Model for Interface Management"; 458 } 459 import ietf-yang-schema-mount { 460 prefix yangmnt; 461 reference "draft-ietf-netmod-schema-mount: YANG Schema Mount"; 462 // RFC Ed.: Please replace this draft name with the corresponding 463 // RFC number 464 } 466 organization 467 "IETF Routing Area (rtgwg) Working Group"; 468 contact 469 "WG Web: 470 WG List: 472 Author: Lou Berger 473 474 Author: Christan Hopps 475 476 Author: Acee Lindem 477 478 Author: Dean Bogdanovic 479 "; 480 description 481 "This module is used to support multiple logical network 482 elements on a single physical or virtual system. 484 Copyright (c) 2017 IETF Trust and the persons 485 identified as authors of the code. All rights reserved. 487 Redistribution and use in source and binary forms, with or 488 without modification, is permitted pursuant to, and subject 489 to the license terms contained in, the Simplified BSD 490 License set forth in Section 4.c of the IETF Trust's Legal 491 Provisions Relating to IETF Documents 492 (http://trustee.ietf.org/license-info). 494 This version of this YANG module is part of RFC XXXX; see 495 the RFC itself for full legal notices."; 497 // RFC Ed.: replace XXXX with actual RFC number and remove 498 // this note 499 // RFC Ed.: please update TBD 501 revision 2018-03-20 { 502 description 503 "Initial revision."; 504 reference "RFC XXXX"; 505 } 507 // top level device definition statements 509 container logical-network-elements { 510 description 511 "Allows a network device to support multiple logical 512 network element (device) instances."; 513 list logical-network-element { 514 key "name"; 515 description 516 "List of logical network elements."; 517 leaf name { 518 type string; 519 description 520 "Device-wide unique identifier for the 521 logical network element."; 522 } 523 leaf managed { 524 type boolean; 525 default "true"; 526 description 527 "True if the host can access LNE information 528 using the root mount point. This value 529 my not be modifiable in all implementations."; 530 } 531 leaf description { 532 type string; 533 description 534 "Description of the logical network element."; 535 } 536 container "root" { 537 description 538 "Container for mount point."; 539 yangmnt:mount-point "root" { 540 description 541 "Root for models supported per logical 542 network element. This mount point may or may not 543 be inline based on the server implementation. It 544 SHALL always contain a YANG library and interfaces 545 instance. 547 When the associated 'managed' leaf is 'false' any 548 operation that attempts to access information below 549 the root SHALL fail with an error-tag of 550 'access-denied' and an error-app-tag of 551 'lne-not-managed'."; 552 } 553 } 554 } 555 } 557 // augment statements 559 augment "/if:interfaces/if:interface" { 560 description 561 "Add a node for the identification of the logical network 562 element associated with an interface. Applies to 563 interfaces that can be assigned on a per logical network 564 element basis. 566 Note that a standard error will be returned if the 567 identified leafref isn't present. If an interfaces 568 cannot be assigned for any other reason, the operation 569 SHALL fail with an error-tag of 'operation-failed' and an 570 error-app-tag of 'lne-assignment-failed'. A meaningful 571 error-info that indicates the source of the assignment 572 failure SHOULD also be provided."; 574 leaf bind-lne-name { 575 type leafref { 576 path 577 "/logical-network-elements/logical-network-element/name"; 578 } 579 description 580 "Logical network element ID to which interface is bound."; 581 } 582 } 584 // notification statements 586 notification bind-lne-name-failed { 587 description 588 "Indicates an error in the association of an interface to an 589 LNE. Only generated after success is initially returned when 590 bind-lne-name is set."; 591 leaf name { 592 type leafref { 593 path "/if:interfaces/if:interface/if:name"; 594 } 595 mandatory true; 596 description 597 "Contains the interface name associated with the 598 failure."; 599 } 600 leaf bind-lne-name { 601 type leafref { 602 path "/if:interfaces/if:interface/lne:bind-lne-name"; 603 } 604 mandatory true; 605 description 606 "Contains the bind-lne-name associated with the 607 failure."; 608 } 609 leaf error-info { 610 type string; 611 description 612 "Optionally, indicates the source of the assignment 613 failure."; 614 } 615 } 616 } 617 619 7. References 621 7.1. Normative References 623 [I-D.ietf-netmod-revised-datastores] 624 Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 625 and R. Wilton, "Network Management Datastore 626 Architecture", draft-ietf-netmod-revised-datastores-10 627 (work in progress), January 2018. 629 [I-D.ietf-netmod-rfc7223bis] 630 Bjorklund, M., "A YANG Data Model for Interface 631 Management", draft-ietf-netmod-rfc7223bis-03 (work in 632 progress), January 2018. 634 [I-D.ietf-netmod-schema-mount] 635 Bjorklund, M. and L. Lhotka, "YANG Schema Mount", draft- 636 ietf-netmod-schema-mount-08 (work in progress), October 637 2017. 639 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 640 Requirement Levels", BCP 14, RFC 2119, 641 DOI 10.17487/RFC2119, March 1997, 642 . 644 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 645 DOI 10.17487/RFC3688, January 2004, 646 . 648 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 649 (TLS) Protocol Version 1.2", RFC 5246, 650 DOI 10.17487/RFC5246, August 2008, 651 . 653 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 654 the Network Configuration Protocol (NETCONF)", RFC 6020, 655 DOI 10.17487/RFC6020, October 2010, 656 . 658 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 659 and A. Bierman, Ed., "Network Configuration Protocol 660 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 661 . 663 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 664 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 665 . 667 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 668 Protocol (NETCONF) Access Control Model", RFC 6536, 669 DOI 10.17487/RFC6536, March 2012, 670 . 672 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 673 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 674 . 676 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 677 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 678 May 2017, . 680 7.2. Informative References 682 [I-D.ietf-netmod-entity] 683 Bierman, A., Bjorklund, M., Dong, J., and D. Romascanu, "A 684 YANG Data Model for Hardware Management", draft-ietf- 685 netmod-entity-08 (work in progress), January 2018. 687 [I-D.ietf-netmod-rfc8022bis] 688 Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for 689 Routing Management (NMDA Version)", draft-ietf-netmod- 690 rfc8022bis-11 (work in progress), January 2018. 692 [I-D.ietf-netmod-yang-tree-diagrams] 693 Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft- 694 ietf-netmod-yang-tree-diagrams-06 (work in progress), 695 February 2018. 697 [I-D.ietf-rtgwg-device-model] 698 Lindem, A., Berger, L., Bogdanovic, D., and C. Hopps, 699 "Network Device YANG Logical Organization", draft-ietf- 700 rtgwg-device-model-02 (work in progress), March 2017. 702 [I-D.ietf-rtgwg-ni-model] 703 Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. 704 Liu, "YANG Model for Network Instances", draft-ietf-rtgwg- 705 ni-model-11 (work in progress), March 2018. 707 [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for 708 System Management", RFC 7317, DOI 10.17487/RFC7317, August 709 2014, . 711 [RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module 712 Library", RFC 7895, DOI 10.17487/RFC7895, June 2016, 713 . 715 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 716 RFC 7950, DOI 10.17487/RFC7950, August 2016, 717 . 719 Appendix A. Acknowledgments 721 The Routing Area Yang Architecture design team members included Acee 722 Lindem, Anees Shaikh, Christian Hopps, Dean Bogdanovic, Lou Berger, 723 Qin Wu, Rob Shakir, Stephane Litkowski, and Yan Gang. Useful review 724 comments were also received by Martin Bjorklund, John Scudder, Dan 725 Romascanu and Taylor Yu. 727 This document was motivated by, and derived from, 728 [I-D.ietf-rtgwg-device-model]. 730 The RFC text was produced using Marshall Rose's xml2rfc tool. 732 Thanks to Alvaro Retana for IESG review. 734 Appendix B. Examples 736 The following subsections provide example uses of LNEs. 738 B.1. Example: Host Device Managed LNE 740 This section describes an example of the LNE model using schema mount 741 to achieve the parent management. An example device supports 742 multiple instances of LNEs (logical routers), each of which supports 743 features of layer 2 and layer 3 interfaces 744 [I-D.ietf-netmod-rfc7223bis], routing information base 745 [I-D.ietf-netmod-rfc8022bis], and OSPF protocol. Each of these 746 features is specified by a YANG model, and they are combined using 747 YANG Schema Mount as shown below. Not all possible mounted modules 748 are shown. For example implementations could also mount the model 749 defined in [I-D.ietf-netmod-entity]. 751 module: ietf-logical-network-element 752 +--rw logical-network-elements 753 +--rw logical-network-element* [name] 754 +--rw name string 755 +--mp root 756 +--ro yanglib:modules-state/ 757 | +--ro module-set-id string 758 | +--ro module* [name revision] 759 | +--ro name yang:yang-identifier 760 +--rw sys:system/ 761 | +--rw contact? string 762 | +--rw hostname? inet:domain-name 763 | +--rw authentication {authentication}? 764 | +--rw user-authentication-order* identityref 765 | +--rw user* [name] {local-users}? 766 | +--rw name string 767 | +--rw password? ianach:crypt-hash 768 | +--rw authorized-key* [name] 769 | +--rw name string 770 | +--rw algorithm string 771 | +--rw key-data binary 772 +--ro sys:system-state/ 773 | ... 774 +--rw rt:routing/ 775 | +--rw router-id? yang:dotted-quad 776 | +--rw control-plane-protocols 777 | +--rw control-plane-protocol* [type name] 778 | +--rw ospf:ospf/ 779 | +--rw areas 780 | +--rw area* [area-id] 781 | +--rw interfaces 782 | +--rw interface* [name] 783 | +--rw name if:interface-ref 784 | +--rw cost? uint16 785 +--rw if:interfaces/ 786 +--rw interface* [name] 787 +--rw name string 788 +--rw ip:ipv4!/ 789 | +--rw address* [ip] 790 | ... 792 module: ietf-interfaces 793 +--rw interfaces 794 +--rw interface* [name] 795 +--rw name string 796 +--rw lne:bind-lne-name? string 797 +--ro oper-status enumeration 799 module: ietf-yang-library 800 +--ro modules-state 801 +--ro module-set-id string 802 +--ro module* [name revision] 803 +--ro name yang:yang-identifier 805 module: ietf-system 806 +--rw system 807 | +--rw contact? string 808 | +--rw hostname? inet:domain-name 809 | +--rw authentication {authentication}? 810 | +--rw user-authentication-order* identityref 811 | +--rw user* [name] {local-users}? 812 | +--rw name string 813 | +--rw password? ianach:crypt-hash 814 | +--rw authorized-key* [name] 815 | +--rw name string 816 | +--rw algorithm string 817 | +--rw key-data binary 818 +--ro system-state 819 +--ro platform 820 | +--ro os-name? string 821 | +--ro os-release? string 823 To realize the above schema, the example device implements the 824 following schema mount instance: 826 "ietf-yang-schema-mount:schema-mounts": { 827 "mount-point": [ 828 { 829 "module": "ietf-logical-network-element", 830 "label": "root", 831 "shared-schema": {} 832 } 833 ] 834 } 836 By using the implementation of the YANG schema mount, an operator can 837 create instances of logical routers. An interface can be assigned to 838 a logical router, so that the logical router has the permission to 839 access this interface. The OSPF protocol can then be enabled on this 840 assigned interface. 842 For this implementation, a parent management session has access to 843 the schemas of both the parent hosting system and the child logical 844 routers. In addition, each child logical router can grant its own 845 management sessions, which have the following schema: 847 module: ietf-yang-library 848 +--ro modules-state 849 +--ro module-set-id string 850 +--ro module* [name revision] 851 +--ro name yang:yang-identifier 853 module: ietf-system 854 +--rw system 855 | +--rw contact? string 856 | +--rw hostname? inet:domain-name 857 | +--rw authentication {authentication}? 858 | +--rw user-authentication-order* identityref 859 | +--rw user* [name] {local-users}? 860 | +--rw name string 861 | +--rw password? ianach:crypt-hash 862 | +--rw authorized-key* [name] 863 | +--rw name string 864 | +--rw algorithm string 865 | +--rw key-data binary 866 +--ro system-state 867 +--ro platform 868 +--ro os-name? string 869 +--ro os-release? string 871 module: ietf-routing 872 rw-- routing 873 +--rw router-id? yang:dotted-quad 874 +--rw control-plane-protocols 875 +--rw control-plane-protocol* [type name] 876 +--rw ospf:ospf/ 877 +--rw areas 878 +--rw area* [area-id] 879 +--rw interfaces 880 +--rw interface* [name] 881 +--rw name if:interface-ref 882 +--rw cost? uint16 884 module: ietf-interfaces 885 +--rw interfaces 886 +--rw interface* [name] 887 +--rw name string 888 +--ro oper-status enumeration 890 B.1.1. Configuration Data 892 The following shows an example where two customer specific LNEs are 893 configured: 895 { 896 "ietf-logical-network-element:logical-network-elements": { 897 "logical-network-element": [ 898 { 899 "name": "cust1", 900 "root": { 901 "ietf-system:system": { 902 "authentication": { 903 "user": [ 904 { 905 "name": "john", 906 "password": "$0$password" 907 } 908 ] 909 } 910 }, 911 "ietf-routing:routing": { 912 "router-id": "192.0.2.1", 913 "control-plane-protocols": { 914 "control-plane-protocol": [ 915 { 916 "type": "ietf-routing:ospf", 917 "name": "1", 918 "ietf-ospf:ospf": { 919 "af": "ipv4", 920 "areas": { 921 "area": [ 922 { 923 "area-id": "203.0.113.1", 924 "interfaces": { 925 "interface": [ 926 { 927 "name": "eth1", 928 "cost": 10 929 } 930 ] 931 } 932 } 933 ] 934 } 935 } 936 } 937 ] 938 } 939 }, 940 "ietf-interfaces:interfaces": { 941 "interfaces": { 942 "interface": [ 943 { 944 "name": "eth1", 945 "ip:ipv4": { 946 "address": [ 947 { 948 "ip": "192.0.2.11", 949 "prefix-length": 24, 950 } 951 ] 952 }, 953 "ip:ipv6": { 954 "address": [ 955 { 956 "ip": "2001:db8:0:2::11", 957 "prefix-length": 64, 958 } 959 ] 960 } 961 } 962 ] 963 } 964 } 965 } 966 }, 967 { 968 "name": "cust2", 969 "root": { 970 "ietf-system:system": { 971 "authentication": { 972 "user": [ 973 { 974 "name": "john", 975 "password": "$0$password" 976 } 977 ] 978 } 979 } 980 "ietf-routing:routing": { 981 "router-id": "192.0.2.2", 982 "control-plane-protocols": { 983 "control-plane-protocol": [ 984 { 985 "type": "ietf-routing:ospf", 986 "name": "1", 987 "ietf-ospf:ospf": { 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 "ietf-interfaces:interfaces": { 1010 "interfaces": { 1011 { 1012 "name": "eth1", 1013 "ip:ipv4": { 1014 "address": [ 1015 { 1016 "ip": "192.0.2.11", 1017 "prefix-length": 24, 1018 } 1019 ] 1020 } 1021 } 1022 ] 1023 } 1024 } 1025 } 1026 ] 1027 }, 1029 "ietf-interfaces:interfaces": { 1030 "interfaces": { 1031 "interface": [ 1032 { 1033 "name": "eth0", 1034 "ip:ipv4": { 1035 "address": [ 1036 { 1037 "ip": "192.0.2.10", 1038 "prefix-length": 24, 1040 } 1041 ] 1042 }, 1043 "ip:ipv6": { 1044 "address": [ 1045 { 1046 "ip": "2001:db8:0:2::10", 1047 "prefix-length": 64, 1048 } 1049 ] 1050 } 1051 }, 1052 { 1053 "name": "cust1:eth1", 1054 "lne:bind-lne-name": "cust1" 1055 }, 1056 { 1057 "name": "cust2:eth1", 1058 "lne:bind-lne-name": "cust2" 1059 } 1060 ] 1061 } 1062 }, 1064 "ietf-system:system": { 1065 "authentication": { 1066 "user": [ 1067 { 1068 "name": "root", 1069 "password": "$0$password" 1070 } 1071 ] 1072 } 1073 } 1074 } 1076 B.1.2. State Data 1078 The following shows possible state data associated the above 1079 configuration data: 1081 { 1082 "ietf-logical-network-element:logical-network-elements": { 1083 "logical-network-element": [ 1084 { 1085 "name": "cust1", 1086 "root": { 1087 "ietf-yang-library:modules-state": { 1088 "module-set-id": "123e4567-e89b-12d3-a456-426655440000", 1089 "module": [ 1090 { 1091 "name": "iana-if-type", 1092 "revision": "2014-05-08", 1093 "namespace": 1094 "urn:ietf:params:xml:ns:yang:iana-if-type", 1095 "conformance-type": "import" 1096 }, 1097 { 1098 "name": "ietf-inet-types", 1099 "revision": "2013-07-15", 1100 "namespace": 1101 "urn:ietf:params:xml:ns:yang:ietf-inet-types", 1102 "conformance-type": "import" 1103 }, 1104 { 1105 "name": "ietf-interfaces", 1106 "revision": "2014-05-08", 1107 "feature": [ 1108 "arbitrary-names", 1109 "pre-provisioning" 1110 ], 1111 "namespace": 1112 "urn:ietf:params:xml:ns:yang:ietf-interfaces", 1113 "conformance-type": "implement" 1114 }, 1115 { 1116 "name": "ietf-ip", 1117 "revision": "2014-06-16", 1118 "namespace": 1119 "urn:ietf:params:xml:ns:yang:ietf-ip", 1120 "conformance-type": "implement" 1121 }, 1122 { 1123 "name": "ietf-ospf", 1124 "revision": "2018-03-03", 1125 "namespace": 1126 "urn:ietf:params:xml:ns:yang:ietf-ospf", 1127 "conformance-type": "implement" 1128 }, 1129 { 1130 "name": "ietf-routing", 1131 "revision": "2018-03-13", 1132 "namespace": 1133 "urn:ietf:params:xml:ns:yang:ietf-routing", 1134 "conformance-type": "implement" 1135 }, 1136 { 1137 "name": "ietf-system", 1138 "revision": "2014-08-06", 1139 "namespace": 1140 "urn:ietf:params:xml:ns:yang:ietf-system", 1141 "conformance-type": "implement" 1142 }, 1143 { 1144 "name": "ietf-yang-library", 1145 "revision": "2016-06-21", 1146 "namespace": 1147 "urn:ietf:params:xml:ns:yang:ietf-yang-library", 1148 "conformance-type": "implement" 1149 }, 1150 { 1151 "name": "ietf-yang-types", 1152 "revision": "2013-07-15", 1153 "namespace": 1154 "urn:ietf:params:xml:ns:yang:ietf-yang-types", 1155 "conformance-type": "import" 1156 } 1157 ] 1158 }, 1159 "ietf-system:system-state": { 1160 "ietf-system:system-state": { 1161 "platform": { 1162 "os-name": "NetworkOS" 1163 } 1164 } 1165 }, 1166 "ietf-routing:routing": { 1167 "router-id": "192.0.2.1", 1168 "control-plane-protocols": { 1169 "control-plane-protocol": [ 1170 { 1171 "type": "ietf-routing:ospf", 1172 "name": "1", 1173 "ietf-ospf:ospf": { 1174 "af": "ipv4", 1175 "areas": { 1176 "area": [ 1177 { 1178 "area-id": "203.0.113.1", 1179 "interfaces": { 1180 "interface": [ 1181 { 1182 "name": "eth1", 1183 "cost": 10 1185 } 1186 ] 1187 } 1188 } 1189 ] 1190 } 1191 } 1192 } 1193 ] 1194 } 1195 }, 1196 "ietf-interfaces:interfaces": { 1197 "interfaces": { 1198 "interface": [ 1199 { 1200 "name": "eth1", 1201 "type": "iana-if-type:ethernetCsmacd", 1202 "oper-status": "up", 1203 "phys-address": "00:01:02:A1:B1:C1", 1204 "statistics": { 1205 "discontinuity-time": "2017-06-26T12:34:56-05:00" 1206 }, 1207 "ip:ipv4": { 1208 "address": [ 1209 { 1210 "ip": "192.0.2.11", 1211 "prefix-length": 24, 1212 } 1213 ] 1214 } 1215 } 1216 ] 1217 } 1218 } 1219 } 1220 }, 1221 { 1222 "name": "cust2", 1223 "root": { 1224 "ietf-yang-library:modules-state": { 1225 "module-set-id": "123e4567-e89b-12d3-a456-426655440000", 1226 "module": [ 1227 { 1228 "name": "iana-if-type", 1229 "revision": "2014-05-08", 1230 "namespace": 1231 "urn:ietf:params:xml:ns:yang:iana-if-type", 1232 "conformance-type": "import" 1234 }, 1235 { 1236 "name": "ietf-inet-types", 1237 "revision": "2013-07-15", 1238 "namespace": 1239 "urn:ietf:params:xml:ns:yang:ietf-inet-types", 1240 "conformance-type": "import" 1241 }, 1242 { 1243 "name": "ietf-interfaces", 1244 "revision": "2014-05-08", 1245 "feature": [ 1246 "arbitrary-names", 1247 "pre-provisioning" 1248 ], 1249 "namespace": 1250 "urn:ietf:params:xml:ns:yang:ietf-interfaces", 1251 "conformance-type": "implement" 1252 }, 1253 { 1254 "name": "ietf-ip", 1255 "revision": "2014-06-16", 1256 "namespace": 1257 "urn:ietf:params:xml:ns:yang:ietf-ip", 1258 "conformance-type": "implement" 1259 }, 1260 { 1261 "name": "ietf-ospf", 1262 "revision": "2018-03-03", 1263 "namespace": 1264 "urn:ietf:params:xml:ns:yang:ietf-ospf", 1265 "conformance-type": "implement" 1266 }, 1267 { 1268 "name": "ietf-routing", 1269 "revision": "2018-03-13", 1270 "namespace": 1271 "urn:ietf:params:xml:ns:yang:ietf-routing", 1272 "conformance-type": "implement" 1273 }, 1274 { 1275 "name": "ietf-system", 1276 "revision": "2014-08-06", 1277 "namespace": 1278 "urn:ietf:params:xml:ns:yang:ietf-system", 1279 "conformance-type": "implement" 1280 }, 1281 { 1282 "name": "ietf-yang-library", 1283 "revision": "2016-06-21", 1284 "namespace": 1285 "urn:ietf:params:xml:ns:yang:ietf-yang-library", 1286 "conformance-type": "implement" 1287 }, 1288 { 1289 "name": "ietf-yang-types", 1290 "revision": "2013-07-15", 1291 "namespace": 1292 "urn:ietf:params:xml:ns:yang:ietf-yang-types", 1293 "conformance-type": "import" 1294 } 1295 ] 1296 } 1297 "ietf-system:system-state": { 1298 "ietf-system:system-state": { 1299 "platform": { 1300 "os-name": "NetworkOS" 1301 } 1302 } 1303 }, 1304 "ietf-routing:routing": { 1305 "router-id": "192.0.2.2", 1306 "control-plane-protocols": { 1307 "control-plane-protocol": [ 1308 { 1309 "type": "ietf-routing:ospf", 1310 "name": "1", 1311 "ietf-ospf:ospf": { 1312 "af": "ipv4", 1313 "areas": { 1314 "area": [ 1315 { 1316 "area-id": "203.0.113.1", 1317 "interfaces": { 1318 "interface": [ 1319 { 1320 "name": "eth1", 1321 "cost": 10 1322 } 1323 ] 1324 } 1325 } 1326 ] 1327 } 1328 } 1329 } 1331 ] 1332 } 1333 } 1334 "ietf-interfaces:interfaces": { 1335 "interfaces": { 1336 { 1337 "name": "eth1", 1338 "type": "iana-if-type:ethernetCsmacd", 1339 "oper-status": "up", 1340 "phys-address": "00:01:02:A1:B1:C2", 1341 "statistics": { 1342 "discontinuity-time": "2017-06-26T12:34:56-05:00" 1343 }, 1344 "ip:ipv4": { 1345 "address": [ 1346 { 1347 "ip": "192.0.2.11", 1348 "prefix-length": 24, 1349 } 1350 ] 1351 } 1352 } 1353 ] 1354 } 1355 } 1356 } 1357 ] 1358 }, 1360 "ietf-interfaces:interfaces": { 1361 "interfaces": { 1362 "interface": [ 1363 { 1364 "name": "eth0", 1365 "type": "iana-if-type:ethernetCsmacd", 1366 "oper-status": "up", 1367 "phys-address": "00:01:02:A1:B1:C0", 1368 "statistics": { 1369 "discontinuity-time": "2017-06-26T12:34:56-05:00" 1370 }, 1371 "ip:ipv4": { 1372 "address": [ 1373 { 1374 "ip": "192.0.2.10", 1375 "prefix-length": 24, 1376 } 1377 ] 1378 } 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": "2018-03-03", 1457 "namespace": 1458 "urn:ietf:params:xml:ns:yang:ietf-ospf", 1459 "conformance-type": "implement" 1460 }, 1461 { 1462 "name": "ietf-routing", 1463 "revision": "2018-03-13", 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 "shared-schema": {} 1505 } 1506 ] 1507 } 1508 } 1510 B.2. Example: Self Managed LNE 1512 This section describes an example of the LNE model using schema mount 1513 to achieve child independent management. An example device supports 1514 multiple instances of LNEs (logical routers), each of them has the 1515 features of layer 2 and layer 3 interfaces 1516 [I-D.ietf-netmod-rfc7223bis], routing information base 1517 [I-D.ietf-netmod-rfc8022bis], and the OSPF protocol. Each of these 1518 features is specified by a YANG model, and they are put together by 1519 the YANG Schema Mount as following: 1521 module: ietf-logical-network-element 1522 +--rw logical-network-elements 1523 +--rw logical-network-element* [name] 1524 +--rw name string 1525 +--mp root 1526 // The internal modules of the LNE are not visible to 1527 // the parament management. 1528 // The child manages its modules, including ietf-routing 1529 // and ietf-interfaces 1531 module: ietf-interfaces 1532 +--rw interfaces 1533 +--rw interface* [name] 1534 +--rw name string 1535 +--rw lne:bind-lne-name? string 1536 +--ro oper-status enumeration 1538 module: ietf-yang-library 1539 +--ro modules-state 1540 +--ro module-set-id string 1541 +--ro module* [name revision] 1542 +--ro name yang:yang-identifier 1544 module: ietf-system 1545 +--rw system 1546 | +--rw contact? string 1547 | +--rw hostname? inet:domain-name 1548 | +--rw authentication {authentication}? 1549 | +--rw user-authentication-order* identityref 1550 | +--rw user* [name] {local-users}? 1551 | +--rw name string 1552 | +--rw password? ianach:crypt-hash 1553 | +--rw authorized-key* [name] 1554 | +--rw name string 1555 | +--rw algorithm string 1556 | +--rw key-data binary 1557 +--ro system-state 1558 +--ro platform 1559 | +--ro os-name? string 1560 | +--ro os-release? string 1562 To realize the above schema, the device implements the following 1563 schema mount instance: 1565 "ietf-yang-schema-mount:schema-mounts": { 1566 "mount-point": [ 1567 { 1568 "module": "ietf-logical-network-element", 1569 "label": "root", 1570 "inline": {} 1571 } 1572 ] 1573 } 1575 By using the implementation of the YANG schema mount, an operator can 1576 create instances of logical routers, each with their logical router 1577 specific in-line modules. An interface can be assigned to a logical 1578 router, so that the logical router has the permission to access this 1579 interface. The OSPF protocol can then be enabled on this assigned 1580 interface. Each logical router independently manages its own set of 1581 modules, which may or may not be the same as other logical routers. 1582 The following is an example of schema set implemented on one 1583 particular logical router: 1585 module: ietf-yang-library 1586 +--ro modules-state 1587 +--ro module-set-id string 1588 +--ro module* [name revision] 1589 +--ro name yang:yang-identifier 1591 module: ietf-system 1592 +--rw system 1593 | +--rw contact? string 1594 | +--rw hostname? inet:domain-name 1595 | +--rw authentication {authentication}? 1596 | +--rw user-authentication-order* identityref 1597 | +--rw user* [name] {local-users}? 1598 | +--rw name string 1599 | +--rw password? ianach:crypt-hash 1600 | +--rw authorized-key* [name] 1601 | +--rw name string 1602 | +--rw algorithm string 1603 | +--rw key-data binary 1604 +--ro system-state 1605 +--ro platform 1606 | +--ro os-name? string 1607 | +--ro os-release? string 1609 module: ietf-routing 1610 +--rw routing 1611 +--rw router-id? yang:dotted-quad 1612 +--rw control-plane-protocols 1613 +--rw control-plane-protocol* [type name] 1614 +--rw ospf:ospf/ 1615 +--rw areas 1616 +--rw area* [area-id] 1617 +--rw interfaces 1618 +--rw interface* [name] 1619 +--rw name if:interface-ref 1620 +--rw cost? uint16 1622 module: ietf-interfaces 1623 +--rw interfaces 1624 +--rw interface* [name] 1625 +--rw name string 1626 +--ro oper-status enumeration 1628 B.2.1. Configuration Data 1630 Each of the child virtual routers is managed through its own sessions 1631 and configuration data. 1633 B.2.1.1. Logical Network Element 'vnf1' 1635 The following shows an example configuration data for the LNE name 1636 "vnf1": 1638 { 1639 "ietf-system:system": { 1640 "authentication": { 1641 "user": [ 1642 { 1643 "name": "john", 1644 "password": "$0$password" 1645 } 1646 ] 1647 } 1648 }, 1649 "ietf-routing:routing": { 1650 "router-id": "192.0.2.1", 1651 "control-plane-protocols": { 1652 "control-plane-protocol": [ 1653 { 1654 "type": "ietf-routing:ospf", 1655 "name": "1", 1656 "ietf-ospf:ospf": { 1657 "af": "ipv4", 1658 "areas": { 1659 "area": [ 1660 { 1661 "area-id": "203.0.113.1", 1662 "interfaces": { 1663 "interface": [ 1664 { 1665 "name": "eth1", 1666 "cost": 10 1667 } 1668 ] 1669 } 1670 } 1671 ] 1672 } 1673 } 1674 } 1675 ] 1676 } 1677 }, 1678 "ietf-interfaces:interfaces": { 1679 "interfaces": { 1680 "interface": [ 1681 { 1682 "name": "eth1", 1683 "ip:ipv4": { 1684 "address": [ 1685 { 1686 "ip": "192.0.2.11", 1687 "prefix-length": 24, 1688 } 1689 ] 1690 } 1691 } 1692 ] 1693 } 1694 } 1695 } 1697 B.2.1.2. Logical Network Element 'vnf2' 1699 The following shows an example configuration data for the LNE name 1700 "vnf2": 1702 { 1703 "ietf-system:system": { 1704 "authentication": { 1705 "user": [ 1706 { 1707 "name": "john", 1708 "password": "$0$password" 1709 } 1710 ] 1711 } 1712 }, 1713 "ietf-routing:routing": { 1714 "router-id": "192.0.2.2", 1715 "control-plane-protocols": { 1716 "control-plane-protocol": [ 1717 { 1718 "type": "ietf-routing:ospf", 1719 "name": "1", 1720 "ietf-ospf:ospf": { 1721 "af": "ipv4", 1722 "areas": { 1723 "area": [ 1724 { 1725 "area-id": "203.0.113.1", 1726 "interfaces": { 1727 "interface": [ 1728 { 1729 "name": "eth1", 1730 "cost": 10 1731 } 1732 ] 1733 } 1734 } 1735 ] 1736 } 1737 } 1738 } 1739 ] 1740 } 1741 }, 1742 "ietf-interfaces:interfaces": { 1743 "interfaces": { 1744 "interface": [ 1745 { 1746 "name": "eth1", 1747 "ip:ipv4": { 1748 "address": [ 1749 { 1750 "ip": "192.0.2.11", 1751 "prefix-length": 24, 1752 } 1753 ] 1754 } 1755 } 1756 ] 1757 } 1758 } 1759 } 1761 B.2.2. State Data 1763 The following sections shows possible state data associated the above 1764 configuration data. Note that there are three views: the host 1765 device's, and each LNE's. 1767 B.2.2.1. Host Device 1769 The following shows state data for the device hosting the example 1770 LNEs: 1772 { 1773 "ietf-logical-network-element:logical-network-elements": { 1774 "logical-network-element": [ 1775 { 1776 "name": "vnf1", 1777 "root": { 1778 } 1779 }, 1780 { 1781 "name": "vnf2", 1782 "root": { 1783 } 1784 } 1785 ] 1786 }, 1788 "ietf-interfaces:interfaces": { 1789 "interfaces": { 1790 "interface": [ 1791 { 1792 "name": "eth0", 1793 "type": "iana-if-type:ethernetCsmacd", 1794 "oper-status": "up", 1795 "phys-address": "00:01:02:A1:B1:C0", 1796 "statistics": { 1797 "discontinuity-time": "2017-06-26T12:34:56-05:00" 1798 }, 1799 "ip:ipv4": { 1800 "address": [ 1801 { 1802 "ip": "192.0.2.10", 1803 "prefix-length": 24, 1804 } 1805 ] 1806 } 1807 }, 1808 { 1809 "name": "vnf1:eth1", 1810 "type": "iana-if-type:ethernetCsmacd", 1811 "oper-status": "up", 1812 "phys-address": "00:01:02:A1:B1:C1", 1813 "statistics": { 1814 "discontinuity-time": "2017-06-26T12:34:56-05:00" 1815 } 1816 }, 1817 { 1818 "name": "vnf2:eth2", 1819 "type": "iana-if-type:ethernetCsmacd", 1820 "oper-status": "up", 1821 "phys-address": "00:01:02:A1:B1:C2", 1822 "statistics": { 1823 "discontinuity-time": "2017-06-26T12:34:56-05:00" 1824 } 1826 } 1827 ] 1828 } 1829 }, 1831 "ietf-system:system-state": { 1832 "platform": { 1833 "os-name": "NetworkOS" 1834 } 1835 }, 1837 "ietf-yang-library:modules-state": { 1838 "module-set-id": "123e4567-e89b-12d3-a456-426655440000", 1839 "module": [ 1840 { 1841 "name": "iana-if-type", 1842 "revision": "2014-05-08", 1843 "namespace": 1844 "urn:ietf:params:xml:ns:yang:iana-if-type", 1845 "conformance-type": "import" 1846 }, 1847 { 1848 "name": "ietf-inet-types", 1849 "revision": "2013-07-15", 1850 "namespace": 1851 "urn:ietf:params:xml:ns:yang:ietf-inet-types", 1852 "conformance-type": "import" 1853 }, 1854 { 1855 "name": "ietf-interfaces", 1856 "revision": "2014-05-08", 1857 "feature": [ 1858 "arbitrary-names", 1859 "pre-provisioning" 1860 ], 1861 "namespace": 1862 "urn:ietf:params:xml:ns:yang:ietf-interfaces", 1863 "conformance-type": "implement" 1864 }, 1865 { 1866 "name": "ietf-ip", 1867 "revision": "2014-06-16", 1868 "namespace": 1869 "urn:ietf:params:xml:ns:yang:ietf-ip", 1870 "conformance-type": "implement" 1871 }, 1872 { 1873 "name": "ietf-logical-network-element", 1874 "revision": "2017-03-13", 1875 "feature": [ 1876 "bind-lne-name" 1877 ], 1878 "namespace": 1879 "urn:ietf:params:xml:ns:yang:ietf-logical-network-element", 1880 "conformance-type": "implement" 1881 }, 1882 { 1883 "name": "ietf-system", 1884 "revision": "2014-08-06", 1885 "namespace": 1886 "urn:ietf:params:xml:ns:yang:ietf-system", 1887 "conformance-type": "implement" 1888 }, 1889 { 1890 "name": "ietf-yang-library", 1891 "revision": "2016-06-21", 1892 "namespace": 1893 "urn:ietf:params:xml:ns:yang:ietf-yang-library", 1894 "conformance-type": "implement" 1895 }, 1896 { 1897 "name": "ietf-yang-schema-mount", 1898 "revision": "2017-05-16", 1899 "namespace": 1900 "urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount", 1901 "conformance-type": "implement" 1902 }, 1903 { 1904 "name": "ietf-yang-types", 1905 "revision": "2013-07-15", 1906 "namespace": 1907 "urn:ietf:params:xml:ns:yang:ietf-yang-types", 1908 "conformance-type": "import" 1909 } 1910 ] 1911 }, 1913 "ietf-yang-schema-mount:schema-mounts": { 1914 "mount-point": [ 1915 { 1916 "module": "ietf-logical-network-element", 1917 "label": "root", 1918 "inline": {} 1919 } 1920 ] 1921 } 1923 } 1925 B.2.2.2. Logical Network Element 'vnf1' 1927 The following shows state data for the example LNE with name "vnf1": 1929 { 1930 "ietf-yang-library:modules-state": { 1931 "module-set-id": "123e4567-e89b-12d3-a456-426655440000", 1932 "module": [ 1933 { 1934 "name": "iana-if-type", 1935 "revision": "2014-05-08", 1936 "namespace": 1937 "urn:ietf:params:xml:ns:yang:iana-if-type", 1938 "conformance-type": "import" 1939 }, 1940 { 1941 "name": "ietf-inet-types", 1942 "revision": "2013-07-15", 1943 "namespace": 1944 "urn:ietf:params:xml:ns:yang:ietf-inet-types", 1945 "conformance-type": "import" 1946 }, 1947 { 1948 "name": "ietf-interfaces", 1949 "revision": "2014-05-08", 1950 "feature": [ 1951 "arbitrary-names", 1952 "pre-provisioning" 1953 ], 1954 "namespace": 1955 "urn:ietf:params:xml:ns:yang:ietf-interfaces", 1956 "conformance-type": "implement" 1957 }, 1958 { 1959 "name": "ietf-ip", 1960 "revision": "2014-06-16", 1961 "namespace": 1962 "urn:ietf:params:xml:ns:yang:ietf-ip", 1963 "conformance-type": "implement" 1964 }, 1965 { 1966 "name": "ietf-ospf", 1967 "revision": "2018-03-03", 1968 "namespace": 1969 "urn:ietf:params:xml:ns:yang:ietf-ospf", 1970 "conformance-type": "implement" 1972 }, 1973 { 1974 "name": "ietf-routing", 1975 "revision": "2018-03-13", 1976 "namespace": 1977 "urn:ietf:params:xml:ns:yang:ietf-routing", 1978 "conformance-type": "implement" 1979 }, 1980 { 1981 "name": "ietf-system", 1982 "revision": "2014-08-06", 1983 "namespace": 1984 "urn:ietf:params:xml:ns:yang:ietf-system", 1985 "conformance-type": "implement" 1986 }, 1987 { 1988 "name": "ietf-yang-library", 1989 "revision": "2016-06-21", 1990 "namespace": 1991 "urn:ietf:params:xml:ns:yang:ietf-yang-library", 1992 "conformance-type": "implement" 1993 }, 1994 { 1995 "name": "ietf-yang-types", 1996 "revision": "2013-07-15", 1997 "namespace": 1998 "urn:ietf:params:xml:ns:yang:ietf-yang-types", 1999 "conformance-type": "import" 2000 } 2001 ] 2002 }, 2004 "ietf-system:system-state": { 2005 "platform": { 2006 "os-name": "NetworkOS" 2007 } 2008 }, 2010 "ietf-routing:routing": { 2011 "router-id": "192.0.2.1", 2012 "control-plane-protocols": { 2013 "control-plane-protocol": [ 2014 { 2015 "type": "ietf-routing:ospf", 2016 "name": "1", 2017 "ietf-ospf:ospf": { 2018 "af": "ipv4", 2019 "areas": { 2020 "area": [ 2021 { 2022 "area-id": "203.0.113.1", 2023 "interfaces": { 2024 "interface": [ 2025 { 2026 "name": "eth1", 2027 "cost": 10 2028 } 2029 ] 2030 } 2031 } 2032 ] 2033 } 2034 } 2035 } 2036 ] 2037 } 2038 }, 2040 "ietf-interfaces:interfaces": { 2041 "interfaces": { 2042 "interface": [ 2043 { 2044 "name": "eth1", 2045 "type": "iana-if-type:ethernetCsmacd", 2046 "oper-status": "up", 2047 "phys-address": "00:01:02:A1:B1:C1", 2048 "statistics": { 2049 "discontinuity-time": "2017-06-26T12:34:56-05:00" 2050 }, 2051 "ip:ipv4": { 2052 "address": [ 2053 { 2054 "ip": "192.0.2.11", 2055 "prefix-length": 24, 2056 } 2057 ] 2058 } 2059 } 2060 ] 2061 } 2062 } 2063 } 2065 B.2.2.3. Logical Network Element 'vnf2' 2067 The following shows state data for the example LNE with name "vnf2": 2069 { 2070 "ietf-yang-library:modules-state": { 2071 "module-set-id": "123e4567-e89b-12d3-a456-426655440000", 2072 "module": [ 2073 { 2074 "name": "iana-if-type", 2075 "revision": "2014-05-08", 2076 "namespace": 2077 "urn:ietf:params:xml:ns:yang:iana-if-type", 2078 "conformance-type": "import" 2079 }, 2080 { 2081 "name": "ietf-inet-types", 2082 "revision": "2013-07-15", 2083 "namespace": 2084 "urn:ietf:params:xml:ns:yang:ietf-inet-types", 2085 "conformance-type": "import" 2086 }, 2087 { 2088 "name": "ietf-interfaces", 2089 "revision": "2014-05-08", 2090 "feature": [ 2091 "arbitrary-names", 2092 "pre-provisioning" 2093 ], 2094 "namespace": 2095 "urn:ietf:params:xml:ns:yang:ietf-interfaces", 2096 "conformance-type": "implement" 2097 }, 2098 { 2099 "name": "ietf-ip", 2100 "revision": "2014-06-16", 2101 "namespace": 2102 "urn:ietf:params:xml:ns:yang:ietf-ip", 2103 "conformance-type": "implement" 2104 }, 2105 { 2106 "name": "ietf-ospf", 2107 "revision": "2018-03-03", 2108 "namespace": 2109 "urn:ietf:params:xml:ns:yang:ietf-ospf", 2110 "conformance-type": "implement" 2111 }, 2112 { 2113 "name": "ietf-routing", 2114 "revision": "2018-03-13", 2115 "namespace": 2116 "urn:ietf:params:xml:ns:yang:ietf-routing", 2117 "conformance-type": "implement" 2118 }, 2119 { 2120 "name": "ietf-system", 2121 "revision": "2014-08-06", 2122 "namespace": 2123 "urn:ietf:params:xml:ns:yang:ietf-system", 2124 "conformance-type": "implement" 2125 }, 2126 { 2127 "name": "ietf-yang-library", 2128 "revision": "2016-06-21", 2129 "namespace": 2130 "urn:ietf:params:xml:ns:yang:ietf-yang-library", 2131 "conformance-type": "implement" 2132 }, 2133 { 2134 "name": "ietf-yang-types", 2135 "revision": "2013-07-15", 2136 "namespace": 2137 "urn:ietf:params:xml:ns:yang:ietf-yang-types", 2138 "conformance-type": "import" 2139 } 2140 ] 2141 }, 2143 "ietf-system:system-state": { 2144 "platform": { 2145 "os-name": "NetworkOS" 2146 } 2147 }, 2149 "ietf-routing:routing": { 2150 "router-id": "192.0.2.2", 2151 "control-plane-protocols": { 2152 "control-plane-protocol": [ 2153 { 2154 "type": "ietf-routing:ospf", 2155 "name": "1", 2156 "ietf-ospf:ospf": { 2157 "af": "ipv4", 2158 "areas": { 2159 "area": [ 2160 { 2161 "area-id": "203.0.113.1", 2162 "interfaces": { 2163 "interface": [ 2164 { 2165 "name": "eth1", 2166 "cost": 10 2167 } 2168 ] 2169 } 2170 } 2171 ] 2172 } 2173 } 2174 } 2175 ] 2176 } 2177 }, 2179 "ietf-interfaces:interfaces": { 2180 "interfaces": { 2181 "interface": [ 2182 { 2183 "name": "eth1", 2184 "type": "iana-if-type:ethernetCsmacd", 2185 "oper-status": "up", 2186 "phys-address": "00:01:02:A1:B1:C2", 2187 "statistics": { 2188 "discontinuity-time": "2017-06-26T12:34:56-05:00" 2189 }, 2190 "ip:ipv4": { 2191 "address": [ 2192 { 2193 "ip": "192.0.2.11", 2194 "prefix-length": 24, 2195 } 2196 ] 2197 } 2198 } 2199 ] 2200 } 2201 } 2202 } 2204 Authors' Addresses 2205 Lou Berger 2206 LabN Consulting, L.L.C. 2208 Email: lberger@labn.net 2210 Christan Hopps 2211 Deutsche Telekom 2213 Email: chopps@chopps.org 2215 Acee Lindem 2216 Cisco Systems 2217 301 Midenhall Way 2218 Cary, NC 27513 2219 USA 2221 Email: acee@cisco.com 2223 Dean Bogdanovic 2225 Email: ivandean@gmail.com 2227 Xufeng Liu 2228 Jabil 2230 Email: Xufeng_Liu@jabil.com