idnits 2.17.00 (12 Aug 2021) /tmp/idnits63786/draft-ietf-rtgwg-lne-model-00.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 (June 23, 2016) is 2157 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) == Missing Reference: 'I-D.ietf-rtgwg-lne-model' is mentioned on line 306, but not defined == Missing Reference: 'I-D.ietf-netmod-routing-cfg' is mentioned on line 322, but not defined == Missing Reference: 'I-D.ietf-rtgwg-ni-model' is mentioned on line 325, but not defined == 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-netconf-yang-library has been published as RFC 7895 == Outdated reference: A later version (-05) exists of draft-rtgyangdt-rtgwg-device-model-04 Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). 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: December 25, 2016 Deutsche Telekom 6 A. Lindem 7 Cisco Systems 8 D. Bogdanovic 9 June 23, 2016 11 Logical Network Element Model 12 draft-ietf-rtgwg-lne-model-00 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 December 25, 2016. 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 . . . . . . . . . . . . . . . . 8 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 71 7.2. Informative References . . . . . . . . . . . . . . . . . 11 72 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 11 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.) This document also 84 defines the necessary augmentations for allocating host resources to 85 a given LNE. As the interface management model [RFC7223] is the only 86 a module that currently defines host resources, this document 87 currently defines only a single augmentation to cover the assignment 88 of interfaces to an LNE. 90 As each LNE is an independently managed device, each will have its 91 own set of YANG modeled data that is independent of the host device 92 and other LNEs. For example, multiple LNEs may all have their own 93 "Tunnel0" interface defined which will not conflict with each other 94 and will not exist in the host's interface model. An LNE will have 95 it's own management interfaces possibly including independent 96 instances of netconf/restconf/etc servers to support configuration of 97 their YANG models. As an example of this independence, an 98 implementation may choose to completely rename assigned interfaces, 99 so on the host the assigned interface might be called "Ethernet0/1" 100 while within the LNE it might be called "eth1". 102 In addition to standard management interfaces, a host device 103 implementation may support accessing LNE configuration and 104 operational YANG models directly from the host system. When 105 supported, such access is accomplished through a schema-mount mount 106 point [I-D.ietf-netmod-schema-mount] under which the root level LNE 107 YANG models may be accessed. 109 Examples of vendor terminology for an LNE include logical system or 110 logical router, and virtual switch, chassis, or fabric. 112 This document was motivated by, and derived from, [RTG-DEVICE-MODEL]. 114 1.1. Status of Work and Open Issues 116 The top open issues are: 118 1. This document will need to match the evolution and 119 standardization of [I-D.openconfig-netmod-opstate] or 120 [I-D.ietf-netmod-opstate-reqs] by the Netmod WG. 122 It will also make use of emerging YANG functionality supported by 123 YANG Schema Mount This document is expected to use whatever Schema 124 Mount solution is agreed upon by the Netmod Working Group. 126 2. Overview 128 In this document, we consider network devices that support protocols 129 and functions defined within the IETF Routing Area, e.g, routers, 130 firewalls and hosts. Such devices may be physical or virtual, e.g., 131 a classic router with custom hardware or one residing within a 132 server-based virtual machine implementing a virtual network function 133 (VNF). Each device may sub-divide their resources into logical 134 network elements (LNEs) each of which provides a managed logical 135 device. Examples of vendor terminology for an LNE include logical 136 system or logical router, and virtual switch, chassis, or fabric. 137 Each LNE may also support virtual routing and forwarding (VRF) and 138 virtual switching instance (VSI) functions, which are referred to 139 below as a network instances (NIs). This breakdown is represented in 140 Figure 1. 142 ,''''''''''''''''''''''''''''''''''''''''''''''`. 143 | Network Device (Physical or Virtual) | 144 | ..................... ..................... | 145 | : Logical Network : : Logical Network : | 146 | : Element : : Element : | 147 | :+-----+-----+-----+: :+-----+-----+-----+: | 148 | :| Net | Net | Net |: :| Net | Net | Net |: | 149 | :|Inst.|Inst.|Inst.|: :|Inst.|Inst.|Inst.|: | 150 | :+-----+-----+-----+: :+-----+-----+-----+: | 151 | : | | | | | | : : | | | | | | : | 152 | :..|.|...|.|...|.|..: :..|.|...|.|...|.|..: | 153 | | | | | | | | | | | | | | 154 `'''|'|'''|'|'''|'|'''''''''|'|'''|'|'''|'|''''' 155 | | | | | | | | | | | | 156 Interfaces Interfaces 158 Figure 1: Module Element Relationships 160 A model for LNEs is described in Section 3 and the model for network 161 instances is covered in [NI-MODEL]. For more information on how 162 these models may be used within an overall device model structure, 163 see [RTG-DEVICE-MODEL]. 165 The interface management model [RFC7223] is and existing model that 166 is impacted by the definition of LNEs and network instances. This 167 document and [NI-MODEL] define augmentations to the interface module 168 to support LNEs and NIs. Similar elements, although perhaps only for 169 LNEs, may also need to be included as part of the definition of the 170 future hardware and QoS modules. 172 Interfaces are a crucial part of any network device's configuration 173 and operational state. They generally include a combination of raw 174 physical interfaces, link-layer interfaces, addressing configuration, 175 and logical interfaces that may not be tied to any physical 176 interface. Several system services, and layer 2 and layer 3 177 protocols may also associate configuration or operational state data 178 with different types of interfaces (these relationships are not shown 179 for simplicity). The interface management model is defined by 180 [RFC7223]. 182 The logical-network-element and network-instance modules augment the 183 existing interface management model in two ways: The first, by the 184 logical-network-element module, adds an identifier which is used on 185 physical interface types to identify an associated LNE. The second, 186 by the network-instance module, adds a name which is used on 187 interface or sub-interface types to identify an associated network 188 instance. Similarly, this name is also added for IPv4 and IPv6 189 types, as defined in [RFC7277]. 191 The interface related augmentations are as follows: 193 module: ietf-logical-network-element 194 augment /if:interfaces/if:interface: 195 +--rw bind-lne-name? string 197 augment /if:interfaces/if:interface: 198 +--rw bind-network-instance-name? string 199 augment /if:interfaces/if:interface/ip:ipv4: 200 +--rw bind-network-instance-name? string 201 augment /if:interfaces/if:interface/ip:ipv6: 202 +--rw bind-network-instance-name? string 204 The following is an example of envisioned combined usage. The 205 interfaces container includes a number of commonly used components as 206 examples: 208 +--rw interfaces 209 | +--rw interface* [name] 210 | +--rw name string 211 | +--rw lne:bind-lne-name? string 212 | +--rw ethernet 213 | | +--rw ni:bind-network-instance-name? string 214 | | +--rw aggregates 215 | | +--rw rstp 216 | | +--rw lldp 217 | | +--rw ptp 218 | +--rw vlans 219 | +--rw tunnels 220 | +--rw ipv4 221 | | +--rw ni:bind-network-instance-name? string 222 | | +--rw arp 223 | | +--rw icmp 224 | | +--rw vrrp 225 | | +--rw dhcp-client 226 | +--rw ipv6 227 | +--rw ni:bind-network-instance-name? string 228 | +--rw vrrp 229 | +--rw icmpv6 230 | +--rw nd 231 | +--rw dhcpv6-client 233 The [RFC7223] defined interface model is structured to include all 234 interfaces in a flat list, without regard to logical or virtual 235 instances (e.g., VRFs) supported on the device. The bind-lne-name 236 and bind-network-instance-name leaves provide the association between 237 an interface and its associated LNE and NI (e.g., VRF or VSI). 239 3. Logical Network Elements 241 A logical network element is a network-device which is contained 242 within another network-device. Using host-virtualization terminology 243 one could refer to an LNE as a "Guest", and the containing network- 244 device as the "Host". While LNEs may be implemented via host- 245 virtualization technologies this is not a requirement. 247 Logical network elements represent the capability of some devices to 248 partition resources into independent logical routers and/or switches. 249 Device support for multiple logical network elements is 250 implementation specific. Systems without such capabilities need not 251 include support for the logical-network-element module. In physical 252 devices, some hardware features are shared across partitions, but 253 control plane (e.g., routing) protocol instances, tables, and 254 configuration are managed separately. For example, in virtual 255 routers or VNFs, this may correspond to establishing multiple logical 256 instances using a single software installation. The model supports 257 configuration of multiple instances on a single device by creating a 258 list of logical network elements, each with their own configuration 259 and operational state related to routing and switching protocols, as 260 shown below: 262 module: ietf-logical-network-element 263 +--rw logical-network-inventory 264 +--rw logical-network-element* [name] 265 +--rw name? string 266 +--rw description? string 267 +--rw managed? boolean 268 +--rw root? schema-mount 269 augment /if:interfaces/if:interface: 270 +--rw bind-lne-name? string 272 `name` identifies the logical network element. `managed` indicates 273 if the host network device is able to manage the LNE via the `root` 274 structure. 276 3.1. LNE Management - Host Network Device View 278 There are multiple implementation approaches possible to enable a 279 network device to support the logical-network-element module and 280 multiple LNEs. Some approaches will allow the management functions 281 operating at network device level to access LNE configuration and 282 operation information, while others will not. Similarly, even when 283 LNE management from the network device is supported by the 284 implementation, it may be prohibited by user policy. 286 The `managed` boolean mentioned above is used to indicate when LNE 287 management from the network device context is possible. When the 288 `managed` boolean is `false`, the LNE cannot be managed by the host 289 system and can only be managed from within the context of the LNE as 290 described in the next section, Section 3.2. 292 When the `managed` boolean is `true`, the LNE can be managed from 293 both the context of the LNE and the host network device. In this 294 case, the same information that is available from within the LNE 295 context is made available via the `root` element, with paths modified 296 as described in [I-D.ietf-netmod-schema-mount]. 298 As an example, consider the case where an LNE with a `name` of "one" 299 is defined on a network device. In this case the following structure 300 might be made available: 302 ....................................................................... 303 (network-device state) 305 +--rw yanglib:modules-state [I-D.ietf-netconf-yang-library] 306 +--rw lne:logical-network-elements [I-D.ietf-rtgwg-lne-model] 307 +--rw logical-network-element* [name] 308 +--rw name="one" string 309 +--rw manged=true boolean 310 +--rw root schema-mount 311 | 312 ....................................................................... 313 | (exposed LNE state if managed=true) 314 | 315 +--rw yanglib:modules-state [I-D.ietf-netconf-yang-library] 316 +--rw if:intefaces [RFC7223] 317 +--rw hardware 318 +--rw qos 319 +--rw system-management 320 +--rw network-services 321 +--rw oam-protocols 322 +--rw rt:routing [I-D.ietf-netmod-routing-cfg] 323 +--rw mpls 324 +--rw ieee-dot1Q 325 +--rw ni:network-instances [I-D.ietf-rtgwg-ni-model] 327 As an LNE is a network device itself, all modules that may be present 328 at the top level network device may also be present for the LNE, be 329 made available under `root`, and be accessible via paths modified per 330 [I-D.ietf-netmod-schema-mount]. The list of available modules is 331 expected to be implementation dependent. As is the method used by an 332 implementation to support LNEs. 334 Resources assigned to the LNE will be represented in that LNE's 335 resource modules. e.g., an LNE's interfaces module will contain the 336 interfaces assigned to that LNE from the containing network-device. 338 3.2. LNE Management - LNE View 340 Management functions operating with the context of an LNE are 341 accessed through standard LNE's management interfaces, e.g., NETCONF 342 and SNMP. When accessing an LNE via an LNE's management interface, a 343 network-device representation will be presented, but its scope will 344 be limited to the specific LNE. Normal YANG/NETCONF mechanisms, 345 together with yang library [I-D.ietf-netconf-yang-library], can be 346 used to identify the available modules. Each supported module will 347 be presented as a top level module. Only LNE associated resources 348 will be reflected in resource related modules, e.g., interfaces, 349 hardware and perhaps QoS. From the management perspective, there 350 will be no difference between the available LNE view (information) 351 and an a physical network device. 353 Multiple implementation approaches are possible to provide LNE views, 354 and these are outside the scope of this document. 356 3.3. LNE Instantiation 358 TBD -- need to resolve if instantiation is based on new list entry 359 creation per the pending Schema Mount solution definition. 361 4. Security Considerations 363 LNE portion is TBD 365 NI portion is TBD 367 5. IANA Considerations 369 This YANG model currently uses a temporary ad-hoc namespace. If it 370 is placed or redirected for the standards track, an appropriate 371 namespace URI will be registered in the "IETF XML Registry" 372 [RFC3688]. The YANG structure modules will be registered in the 373 "YANG Module Names" registry [RFC6020]. 375 6. Logical Network Element Model 377 The structure of the model defined in this document is described by 378 the YANG module below. 380 file "ietf-logical-network-element@2016-06-23.yang" 381 module ietf-logical-network-element { 382 yang-version "1"; 384 // namespace 385 namespace "urn:ietf:params:xml:ns:yang:ietf-logical-network-element"; 387 prefix "lne"; 389 // import some basic types 390 import ietf-interfaces { 391 prefix if; 392 } 394 // meta 395 organization "IETF Routing Area Working Group (rtgwg)"; 397 contact 398 "Routing Area Working Group - "; 400 description 401 "This module is used to support multiple logical network 402 elements on a single physical or virtual system."; 404 revision "2016-06-23" { 405 description 406 "Initial revision."; 407 reference "RFC TBD"; 408 } 410 // feature statements 411 feature bind-lne-name { 412 description 413 "Logical network element to which an interface is bound"; 414 } 416 // top level device definition statements 417 container logical-network-elements { 418 description "Allows a network device to support multiple logical 419 network element (device) instances"; 420 list logical-network-element { 421 key name; 422 description "List of logical network elements"; 423 leaf name { 424 type string; 425 description "Device-wide unique identifier for the 426 logical network element"; 427 } 428 leaf managed { 429 type boolean; 430 description 431 "True if the host can manage the LNE using the root mount 432 point"; 433 } 434 leaf description { 435 type string; 436 description 437 "Description of the logical network element"; 438 } 439 leaf root { 440 type schema-mount; 441 description "Root for models supported per logical 442 network element"; 443 } 444 } 445 } 447 // augment statements 448 augment "/if:interfaces/if:interface" { 449 description 450 "Add a node for the identification of the logical network 451 element associated with an interface. Applies to interfaces 452 that can be assigned on a per logical network element basis. 453 A error is returned when the interface type cannot be 454 assigned."; 456 leaf bind-lne-name { 457 type string; 458 description 459 "Logical network element ID to which interface is bound"; 460 } 461 } 463 // rpc statements 465 // notification statements 467 } 468 470 7. References 472 7.1. Normative References 474 [I-D.ietf-netmod-schema-mount] 475 Bjorklund, M. and L. Lhotka, "YANG Schema Mount", draft- 476 ietf-netmod-schema-mount-01 (work in progress), April 477 2016. 479 [NI-MODEL] 480 Berger, L., Hopps, C., Lindem, A., and D. Bogdanovic, 481 "Network Instance Model", draft-ietf-rtgwg-ni-model-00.txt 482 (work in progress), June 2016. 484 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 485 DOI 10.17487/RFC3688, January 2004, 486 . 488 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 489 the Network Configuration Protocol (NETCONF)", RFC 6020, 490 DOI 10.17487/RFC6020, October 2010, 491 . 493 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 494 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 495 . 497 [RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", 498 RFC 7277, DOI 10.17487/RFC7277, June 2014, 499 . 501 7.2. Informative References 503 [I-D.ietf-netconf-yang-library] 504 Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module 505 Library", draft-ietf-netconf-yang-library-06 (work in 506 progress), April 2016. 508 [I-D.ietf-netmod-opstate-reqs] 509 Watsen, K. and T. Nadeau, "Terminology and Requirements 510 for Enhanced Handling of Operational State", draft-ietf- 511 netmod-opstate-reqs-04 (work in progress), January 2016. 513 [I-D.openconfig-netmod-opstate] 514 Shakir, R., Shaikh, A., and M. Hines, "Consistent Modeling 515 of Operational State Data in YANG", draft-openconfig- 516 netmod-opstate-01 (work in progress), July 2015. 518 [RTG-DEVICE-MODEL] 519 Lindem, A., Ed., Berger, L., Ed., Bogdanovic, D., and C. 520 Hopps, "Network Device YANG Organizational Models", draft- 521 rtgyangdt-rtgwg-device-model-04.txt (work in progress), 522 May 2016. 524 Appendix A. Acknowledgments 525 The Routing Area Yang Architecture design team members included Acee 526 Lindem, Anees Shaikh, Christian Hopps, Dean Bogdanovic, Lou Berger, 527 Qin Wu, Rob Shakir, Stephane Litkowski, and Yan Gang. 529 The RFC text was produced using Marshall Rose's xml2rfc tool. 531 Appendix B. Contributors 533 Contributors' Addresses 535 TBD 537 Authors' Addresses 539 Lou Berger 540 LabN Consulting, L.L.C. 542 Email: lberger@labn.net 544 Christan Hopps 545 Deutsche Telekom 547 Email: chopps@chopps.org 549 Acee Lindem 550 Cisco Systems 551 301 Midenhall Way 552 Cary, NC 27513 553 USA 555 Email: acee@cisco.com 557 Dean Bogdanovic 559 Email: ivandean@gmail.com