idnits 2.17.00 (12 Aug 2021) /tmp/idnits64213/draft-ietf-rtgwg-lne-model-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 28, 2016) is 2030 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: draft-ietf-netmod-schema-mount has been published as RFC 8528 == Outdated reference: draft-ietf-rtgwg-ni-model has been published as RFC 8529 ** Obsolete normative reference: RFC 7223 (Obsoleted by RFC 8343) ** Obsolete normative reference: RFC 7277 (Obsoleted by RFC 8344) == Outdated reference: draft-ietf-netmod-routing-cfg has been published as RFC 8022 == Outdated reference: A later version (-02) exists of draft-ietf-rtgwg-device-model-00 -- Obsolete informational reference (is this intentional?): RFC 7895 (Obsoleted by RFC 8525) Summary: 2 errors (**), 0 flaws (~~), 5 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: May 1, 2017 Deutsche Telekom 6 A. Lindem 7 Cisco Systems 8 D. Bogdanovic 9 October 28, 2016 11 YANG Logical Network Elements 12 draft-ietf-rtgwg-lne-model-01 14 Abstract 16 This document defines a logical network element module. This module 17 along with the network instance module can be used to manage the 18 logical and virtual resource representations that may be present on a 19 network device. Examples of common industry terms for logical 20 resource representations are Logical Systems or Logical Routers. 21 Examples of of common industry terms for virtual resource 22 representations are Virtual Routing and Forwarding (VRF) instances 23 and Virtual Switch Instances (VSIs). 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on May 1, 2017. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Status of Work and Open Issues . . . . . . . . . . . . . 3 61 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Logical Network Elements . . . . . . . . . . . . . . . . . . 6 63 3.1. LNE Management - Host Network Device View . . . . . . . . 6 64 3.2. LNE Management - LNE View . . . . . . . . . . . . . . . . 8 65 3.3. LNE Instantiation . . . . . . . . . . . . . . . . . . . . 8 66 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 68 6. Logical Network Element Model . . . . . . . . . . . . . . . . 9 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 71 7.2. Informative References . . . . . . . . . . . . . . . . . 12 72 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 12 73 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 13 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 76 1. Introduction 78 This document defines a YANG [RFC6020] module to support the creation 79 of logical network elements on a network device. A logical network 80 element (LNE) is an independently managed virtual device made up of 81 resources allocated to it from the host, or parent, network device. 82 (An LNE running on a host network device conceptually parallels a 83 virtual machine running on a host system.) Using host-virtualization 84 terminology one could refer to an LNE as a "Guest", and the 85 containing network-device as the "Host". While LNEs may be 86 implemented via host-virtualization technologies this is not a 87 requirement. 89 This document also defines the necessary augmentations for allocating 90 host resources to a given LNE. As the interface management model 91 [RFC7223] is the only a module that currently defines host resources, 92 this document currently defines only a single augmentation to cover 93 the assignment of interfaces to an LNE. 95 As each LNE is an independently managed device, each will have its 96 own set of YANG modeled data that is independent of the host device 97 and other LNEs. For example, multiple LNEs may all have their own 98 "Tunnel0" interface defined which will not conflict with each other 99 and will not exist in the host's interface model. An LNE will have 100 it's own management interfaces possibly including independent 101 instances of netconf/restconf/etc servers to support configuration of 102 their YANG models. As an example of this independence, an 103 implementation may choose to completely rename assigned interfaces, 104 so on the host the assigned interface might be called "Ethernet0/1" 105 while within the LNE it might be called "eth1". 107 In addition to standard management interfaces, a host device 108 implementation may support accessing LNE configuration and 109 operational YANG models directly from the host system. When 110 supported, such access is accomplished through a yang-schema-mount 111 mount point [I-D.ietf-netmod-schema-mount] under which the root level 112 LNE YANG models may be accessed. 114 Examples of vendor terminology for an LNE include logical system or 115 logical router, and virtual switch, chassis, or fabric. 117 This document was motivated by, and derived from, 118 [I-D.ietf-rtgwg-device-model]. 120 1.1. Status of Work and Open Issues 122 The top open issues are: 124 1. This document will need to match the evolution and 125 standardization of [I-D.openconfig-netmod-opstate] or 126 [I-D.ietf-netmod-opstate-reqs] by the Netmod WG. 128 It will also make use of emerging YANG functionality supported by 129 YANG Schema Mount. 131 2. Overview 133 In this document, we consider network devices that support protocols 134 and functions defined within the IETF Routing Area, e.g, routers, 135 firewalls and hosts. Such devices may be physical or virtual, e.g., 136 a classic router with custom hardware or one residing within a 137 server-based virtual machine implementing a virtual network function 138 (VNF). Each device may sub-divide their resources into logical 139 network elements (LNEs) each of which provides a managed logical 140 device. Examples of vendor terminology for an LNE include logical 141 system or logical router, and virtual switch, chassis, or fabric. 142 Each LNE may also support virtual routing and forwarding (VRF) and 143 virtual switching instance (VSI) functions, which are referred to 144 below as a network instances (NIs). This breakdown is represented in 145 Figure 1. 147 ,''''''''''''''''''''''''''''''''''''''''''''''`. 148 | Network Device (Physical or Virtual) | 149 | ..................... ..................... | 150 | : Logical Network : : Logical Network : | 151 | : Element : : Element : | 152 | :+-----+-----+-----+: :+-----+-----+-----+: | 153 | :| Net | Net | Net |: :| Net | Net | Net |: | 154 | :|Inst.|Inst.|Inst.|: :|Inst.|Inst.|Inst.|: | 155 | :+-----+-----+-----+: :+-----+-----+-----+: | 156 | : | | | | | | : : | | | | | | : | 157 | :..|.|...|.|...|.|..: :..|.|...|.|...|.|..: | 158 | | | | | | | | | | | | | | 159 `'''|'|'''|'|'''|'|'''''''''|'|'''|'|'''|'|''''' 160 | | | | | | | | | | | | 161 Interfaces Interfaces 163 Figure 1: Module Element Relationships 165 A model for LNEs is described in Section 3 and the model for network 166 instances is covered in [I-D.ietf-rtgwg-ni-model]. For more 167 information on how these models may be used within an overall device 168 model structure, see [I-D.ietf-rtgwg-device-model]. 170 The interface management model [RFC7223] is and existing model that 171 is impacted by the definition of LNEs and network instances. This 172 document and [I-D.ietf-rtgwg-ni-model] define augmentations to the 173 interface module to support LNEs and NIs. Similar elements, although 174 perhaps only for LNEs, may also need to be included as part of the 175 definition of the future hardware and QoS modules. 177 Interfaces are a crucial part of any network device's configuration 178 and operational state. They generally include a combination of raw 179 physical interfaces, link-layer interfaces, addressing configuration, 180 and logical interfaces that may not be tied to any physical 181 interface. Several system services, and layer 2 and layer 3 182 protocols may also associate configuration or operational state data 183 with different types of interfaces (these relationships are not shown 184 for simplicity). The interface management model is defined by 185 [RFC7223]. 187 The logical-network-element and network-instance modules augment the 188 existing interface management model in two ways: The first, by the 189 logical-network-element module, adds an identifier which is used on 190 physical interface types to identify an associated LNE. The second, 191 by the network-instance module, adds a name which is used on 192 interface or sub-interface types to identify an associated network 193 instance. Similarly, this name is also added for IPv4 and IPv6 194 types, as defined in [RFC7277]. 196 The interface related augmentations are as follows: 198 module: ietf-logical-network-element 199 augment /if:interfaces/if:interface: 200 +--rw bind-lne-name? string 202 augment /if:interfaces/if:interface: 203 +--rw bind-network-instance-name? string 204 augment /if:interfaces/if:interface/ip:ipv4: 205 +--rw bind-network-instance-name? string 206 augment /if:interfaces/if:interface/ip:ipv6: 207 +--rw bind-network-instance-name? string 209 The following is an example of envisioned combined usage. The 210 interfaces container includes a number of commonly used components as 211 examples: 213 +--rw interfaces 214 | +--rw interface* [name] 215 | +--rw name string 216 | +--rw lne:bind-lne-name? string 217 | +--rw ethernet 218 | | +--rw ni:bind-network-instance-name? string 219 | | +--rw aggregates 220 | | +--rw rstp 221 | | +--rw lldp 222 | | +--rw ptp 223 | +--rw vlans 224 | +--rw tunnels 225 | +--rw ipv4 226 | | +--rw ni:bind-network-instance-name? string 227 | | +--rw arp 228 | | +--rw icmp 229 | | +--rw vrrp 230 | | +--rw dhcp-client 231 | +--rw ipv6 232 | +--rw ni:bind-network-instance-name? string 233 | +--rw vrrp 234 | +--rw icmpv6 235 | +--rw nd 236 | +--rw dhcpv6-client 238 The [RFC7223] defined interface model is structured to include all 239 interfaces in a flat list, without regard to logical or virtual 240 instances (e.g., VRFs) supported on the device. The bind-lne-name 241 and bind-network-instance-name leaves provide the association between 242 an interface and its associated LNE and NI (e.g., VRF or VSI). 244 3. Logical Network Elements 246 Logical network elements represent the capability of some devices to 247 partition resources into independent logical routers and/or switches. 248 Device support for multiple logical network elements is 249 implementation specific. Systems without such capabilities need not 250 include support for the logical-network-element module. In physical 251 devices, some hardware features are shared across partitions, but 252 control plane (e.g., routing) protocol instances, tables, and 253 configuration are managed separately. For example, in virtual 254 routers or VNFs, this may correspond to establishing multiple logical 255 instances using a single software installation. The model supports 256 configuration of multiple instances on a single device by creating a 257 list of logical network elements, each with their own configuration 258 and operational state related to routing and switching protocols, as 259 shown below: 261 module: ietf-logical-network-element 262 +--rw logical-network-inventory 263 +--rw logical-network-element* [name] 264 +--rw name? string 265 +--rw description? string 266 +--rw managed? boolean 267 +--rw root? yang-schema-mount 268 augment /if:interfaces/if:interface: 269 +--rw bind-lne-name? string 271 `name` identifies the logical network element. `managed` indicates 272 if the host network device is able to manage the LNE via the `root` 273 structure. 275 3.1. LNE Management - Host Network Device View 277 There are multiple implementation approaches possible to enable a 278 network device to support the logical-network-element module and 279 multiple LNEs. Some approaches will allow the management functions 280 operating at network device level to access LNE configuration and 281 operation information, while others will not. Similarly, even when 282 LNE management from the network device is supported by the 283 implementation, it may be prohibited by user policy. 285 The `managed` boolean mentioned above is used to indicate when LNE 286 management from the network device context is possible. When the 287 `managed` boolean is `false`, the LNE cannot be managed by the host 288 system and can only be managed from within the context of the LNE as 289 described in the next section, Section 3.2. 291 When the `managed` boolean is `true`, the LNE can be managed from 292 both the context of the LNE and the host network device. In this 293 case, the same information that is available from within the LNE 294 context is made available via the `root` element, with paths modified 295 as described in [I-D.ietf-netmod-schema-mount]. 297 As an example, consider the case where an LNE with a `name` of "one" 298 is defined on a network device. In this case the following structure 299 might be made available: 301 ....................................................................... 302 (network-device state) 304 +--rw yanglib:modules-state [RFC7895] 305 +--rw lne:logical-network-elements [This document] 306 +--rw logical-network-element* [name] 307 +--rw name="one" string 308 +--rw manged=true boolean 309 +--rw root yang-schema-mount 310 | 311 ....................................................................... 312 | (exposed LNE state if managed=true) 313 | 314 +--rw yanglib:modules-state [RFC7895] 315 +--rw if:intefaces [RFC7223] 316 +--rw hardware 317 +--rw qos 318 +--rw system-management 319 +--rw network-services 320 +--rw oam-protocols 321 +--rw rt:routing [I-D.ietf-netmod-routing-cfg] 322 +--rw mpls 323 +--rw ieee-dot1Q 324 +--rw ni:network-instances [I-D.ietf-rtgwg-ni-model] 326 As an LNE is a network device itself, all modules that may be present 327 at the top level network device may also be present for the LNE, be 328 made available under `root`, and be accessible via paths modified per 329 [I-D.ietf-netmod-schema-mount]. The list of available modules is 330 expected to be implementation dependent. As is the method used by an 331 implementation to support LNEs. 333 Resources assigned to the LNE will be represented in that LNE's 334 resource modules. e.g., an LNE's interfaces module will contain the 335 interfaces assigned to that LNE from the containing network-device. 337 3.2. LNE Management - LNE View 339 Management functions operating with the context of an LNE are 340 accessed through standard LNE's management interfaces, e.g., NETCONF 341 and SNMP. When accessing an LNE via an LNE's management interface, a 342 network-device representation will be presented, but its scope will 343 be limited to the specific LNE. Normal YANG/NETCONF mechanisms, 344 together with yang library [RFC7895], can be used to identify the 345 available modules. Each supported module will be presented as a top 346 level module. Only LNE associated resources will be reflected in 347 resource related modules, e.g., interfaces, hardware and perhaps QoS. 348 From the management perspective, there will be no difference between 349 the available LNE view (information) and an a physical network 350 device. 352 Multiple implementation approaches are possible to provide LNE views, 353 and these are outside the scope of this document. 355 3.3. LNE Instantiation 357 Logical network elements may be controlled by clients using existing 358 list operations. When list entries are created, a new LNE is 359 instantiated. The models mounted under an LNE root is expected to be 360 dependent on the server implementation. When a list entry is 361 deleted, an existing LNE is destroyed. For more information see 362 [RFC7950] Section 7.8.6. 364 4. Security Considerations 366 TBD 368 5. IANA Considerations 370 This document registers a URI in the IETF XML registry [RFC3688]. 371 Following the format in RFC 3688, the following registration is 372 requested to be made. 374 URI: urn:ietf:params:xml:ns:yang:ietf-logical-network-element 376 Registrant Contact: The IESG. 378 XML: N/A, the requested URI is an XML namespace. 380 This document registers a YANG module in the YANG Module Names 381 registry [RFC6020]. 383 name: ietf-logical-network-element 384 namespace: urn:ietf:params:xml:ns:yang:ietf-logical-network-element 385 prefix: lne 386 reference: RFC XXXX 388 6. Logical Network Element Model 390 The structure of the model defined in this document is described by 391 the YANG module below. 393 file "ietf-logical-network-element@2016-10-21.yang" 394 module ietf-logical-network-element { 396 yang-version 1.1; 398 // namespace 399 namespace "urn:ietf:params:xml:ns:yang:ietf-logical-network-element"; 401 prefix lne; 403 // import some basic types 404 import ietf-interfaces { 405 prefix if; 406 } 408 import ietf-yang-schema-mount { 409 prefix yangmnt; 410 } 412 // meta 413 organization "IETF Routing Area Working Group (rtgwg)"; 415 contact 416 "Routing Area Working Group - "; 418 description 419 "This module is used to support multiple logical network 420 elements on a single physical or virtual system."; 422 revision "2016-10-21" { 423 description 424 "Initial revision."; 425 reference "RFC TBD"; 426 } 427 // feature statements 428 feature bind-lne-name { 429 description 430 "Logical network element to which an interface is bound"; 431 } 433 // top level device definition statements 434 container logical-network-elements { 435 description "Allows a network device to support multiple logical 436 network element (device) instances"; 437 list logical-network-element { 438 key name; 439 description "List of logical network elements"; 440 leaf name { 441 type string; 442 description 443 "Device-wide unique identifier for the 444 logical network element"; 445 } 446 leaf managed { 447 type boolean; 448 description 449 "True if the host can manage the LNE using the root mount 450 point"; 451 } 452 leaf description { 453 type string; 454 description 455 "Description of the logical network element"; 456 } 457 anydata root { 458 yangmnt:mount-point "root"; 459 description 460 "Root for models supported per logical 461 network element"; 462 } 463 } 464 } 466 // augment statements 467 augment "/if:interfaces/if:interface" { 468 description 469 "Add a node for the identification of the logical network 470 element associated with an interface. Applies to interfaces 471 that can be assigned on a per logical network element basis. 472 A error is returned when the interface type cannot be 473 assigned."; 475 leaf bind-lne-name { 476 type string; 477 description 478 "Logical network element ID to which interface is bound"; 479 } 480 } 482 // rpc statements 484 // notification statements 486 } 487 489 7. References 491 7.1. Normative References 493 [I-D.ietf-netmod-schema-mount] 494 Bjorklund, M. and L. Lhotka, "YANG Schema Mount", draft- 495 ietf-netmod-schema-mount-02 (work in progress), July 2016. 497 [I-D.ietf-rtgwg-ni-model] 498 Berger, L., Hopps, C., Lindem, A., and D. Bogdanovic, 499 "Network Instance Model", draft-ietf-rtgwg-ni-model-00 500 (work in progress), June 2016. 502 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 503 DOI 10.17487/RFC3688, January 2004, 504 . 506 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 507 the Network Configuration Protocol (NETCONF)", RFC 6020, 508 DOI 10.17487/RFC6020, October 2010, 509 . 511 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 512 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 513 . 515 [RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", 516 RFC 7277, DOI 10.17487/RFC7277, June 2014, 517 . 519 7.2. Informative References 521 [I-D.ietf-netmod-opstate-reqs] 522 Watsen, K. and T. Nadeau, "Terminology and Requirements 523 for Enhanced Handling of Operational State", draft-ietf- 524 netmod-opstate-reqs-04 (work in progress), January 2016. 526 [I-D.ietf-netmod-routing-cfg] 527 Lhotka, L. and A. Lindem, "A YANG Data Model for Routing 528 Management", draft-ietf-netmod-routing-cfg-24 (work in 529 progress), October 2016. 531 [I-D.ietf-rtgwg-device-model] 532 Lindem, A., Berger, L., Bogdanovic, D., and C. Hopps, 533 "Network Device YANG Organizational Models", draft-ietf- 534 rtgwg-device-model-00 (work in progress), August 2016. 536 [I-D.openconfig-netmod-opstate] 537 Shakir, R., Shaikh, A., and M. Hines, "Consistent Modeling 538 of Operational State Data in YANG", draft-openconfig- 539 netmod-opstate-01 (work in progress), July 2015. 541 [RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module 542 Library", RFC 7895, DOI 10.17487/RFC7895, June 2016, 543 . 545 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 546 RFC 7950, DOI 10.17487/RFC7950, August 2016, 547 . 549 Appendix A. Acknowledgments 551 The Routing Area Yang Architecture design team members included Acee 552 Lindem, Anees Shaikh, Christian Hopps, Dean Bogdanovic, Lou Berger, 553 Qin Wu, Rob Shakir, Stephane Litkowski, and Yan Gang. 555 The RFC text was produced using Marshall Rose's xml2rfc tool. 557 Appendix B. Contributors 559 Contributors' Addresses 561 TBD 563 Authors' Addresses 565 Lou Berger 566 LabN Consulting, L.L.C. 568 Email: lberger@labn.net 570 Christan Hopps 571 Deutsche Telekom 573 Email: chopps@chopps.org 575 Acee Lindem 576 Cisco Systems 577 301 Midenhall Way 578 Cary, NC 27513 579 USA 581 Email: acee@cisco.com 583 Dean Bogdanovic 585 Email: ivandean@gmail.com