idnits 2.17.1 draft-rtgyangdt-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 (May 17, 2016) is 2894 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.rtgyangdt-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.rtgyangdt-rtgwg-ni-model' is mentioned on line 325, but not defined == Outdated reference: A later version (-12) exists of draft-ietf-netmod-schema-mount-01 ** Obsolete normative reference: RFC 7223 (Obsoleted by RFC 8343) ** Obsolete normative reference: RFC 7277 (Obsoleted by RFC 8344) == Outdated reference: A later version (-05) exists of draft-rtgyangdt-rtgwg-device-model-04 ** Downref: Normative reference to an Informational draft: draft-rtgyangdt-rtgwg-device-model (ref. 'RTG-DEVICE-MODEL') == Outdated reference: A later version (-06) exists of draft-ietf-netconf-yang-library-05 == Outdated reference: A later version (-04) exists of draft-ietf-netmod-opstate-reqs-03 Summary: 3 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: November 18, 2016 Deutsche Telekom 6 A. Lindem 7 Cisco Systems 8 D. Bogdanovic 9 May 17, 2016 11 Logical Network Element Model 12 draft-rtgyangdt-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 November 18, 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 . . . . . . . . . . . . . . . . . . 11 71 7.2. Informative References . . . . . . . . . . . . . . . . . 11 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.) 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.rtgyangdt-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.rtgyangdt-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-05-01.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 RTG YANG Design Team Collaboration 396 with OpenConfig"; 398 contact 399 "Routing Area YANG Architecture Design Team - 400 "; 402 description 403 "This module is used to support multiple logical network 404 elements on a single physical or virtual system."; 406 revision "2016-05-01" { 407 description 408 "IETF Routing YANG Design Team Meta-Model"; 409 reference "TBD"; 410 } 412 // feature statements 413 feature bind-lne-name { 414 description 415 "Logical network element to which an interface is bound"; 416 } 418 // top level device definition statements 419 container logical-network-elements { 420 description "Allows a network device to support multiple logical 421 network element (device) instances"; 422 list logical-network-element { 423 key name; 424 description "List of logical network elements"; 425 leaf name { 426 type string; 427 description "Device-wide unique identifier for the 428 logical network element"; 429 } 430 leaf managed { 431 type boolean; 432 description 433 "True if the host can manage the LNE using the root mount 434 point"; 435 } 436 leaf description { 437 type string; 438 description 439 "Description of the logical network element"; 440 } 441 leaf root { 442 type schema-mount; 443 description "Root for models supported per logical 444 network element"; 445 } 446 } 447 } 449 // augment statements 450 augment "/if:interfaces/if:interface" { 451 description 452 "Add a node for the identification of the logical network 453 element associated with an interface. Applies to interfaces 454 that can be assigned on a per logical network element basis. 455 A error is returned when the interface type cannot be 456 assigned."; 458 leaf bind-lne-name { 459 type string; 460 description 461 "Logical network element ID to which interface is bound"; 462 } 463 } 465 // rpc statements 467 // notification statements 469 } 470 472 7. References 473 7.1. Normative References 475 [I-D.ietf-netmod-schema-mount] 476 Bjorklund, M. and L. Lhotka, "YANG Schema Mount", draft- 477 ietf-netmod-schema-mount-01 (work in progress), April 478 2016. 480 [NI-MODEL] 481 Berger, L., Hopps, C., Lindem, A., and D. Bogdanovic, 482 "Network Instance Model", draft-rtgyangdt-rtgwg-ni-model- 483 00.txt (work in progress), May 2016. 485 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 486 DOI 10.17487/RFC3688, January 2004, 487 . 489 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 490 the Network Configuration Protocol (NETCONF)", RFC 6020, 491 DOI 10.17487/RFC6020, October 2010, 492 . 494 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 495 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 496 . 498 [RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", 499 RFC 7277, DOI 10.17487/RFC7277, June 2014, 500 . 502 [RTG-DEVICE-MODEL] 503 Lindem, A., Ed., Berger, L., Ed., Bogdanovic, D., and C. 504 Hopps, "Network Device YANG Organizational Models", draft- 505 rtgyangdt-rtgwg-device-model-04.txt (work in progress), 506 May 2016. 508 7.2. Informative References 510 [I-D.ietf-netconf-yang-library] 511 Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module 512 Library", draft-ietf-netconf-yang-library-05 (work in 513 progress), April 2016. 515 [I-D.ietf-netmod-opstate-reqs] 516 Watsen, K. and T. Nadeau, "Terminology and Requirements 517 for Enhanced Handling of Operational State", draft-ietf- 518 netmod-opstate-reqs-03 (work in progress), January 2016. 520 [I-D.openconfig-netmod-opstate] 521 Shakir, R., Shaikh, A., and M. Hines, "Consistent Modeling 522 of Operational State Data in YANG", draft-openconfig- 523 netmod-opstate-01 (work in progress), July 2015. 525 Appendix A. Acknowledgments 527 The Routing Area Yang Architecture design team members included Acee 528 Lindem, Anees Shaikh, Christian Hopps, Dean Bogdanovic, Lou Berger, 529 Qin Wu, Rob Shakir, Stephane Litkowski, and Yan Gang. 531 The RFC text was produced using Marshall Rose's xml2rfc tool. 533 Appendix B. Contributors 535 Contributors' Addresses 537 TBD 539 Authors' Addresses 541 Lou Berger 542 LabN Consulting, L.L.C. 544 Email: lberger@labn.net 546 Christan Hopps 547 Deutsche Telekom 549 Email: chopps@chopps.org 551 Acee Lindem 552 Cisco Systems 553 301 Midenhall Way 554 Cary, NC 27513 555 USA 557 Email: acee@cisco.com 559 Dean Bogdanovic 561 Email: ivandean@gmail.com