idnits 2.17.00 (12 Aug 2021) /tmp/idnits62532/draft-ietf-rtgwg-lne-model-06.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 736 has weird spacing: '...-set-id str...' == Line 749 has weird spacing: '...gorithm str...' == Line 781 has weird spacing: '...-set-id str...' == Line 796 has weird spacing: '...gorithm str...' == Line 882 has weird spacing: '...-set-id str...' == (7 more instances...) -- The document date (February 6, 2018) is 1564 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-rfc7223bis has been published as RFC 8343 == Outdated reference: draft-ietf-netmod-schema-mount has been published as RFC 8528 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) == Outdated reference: draft-ietf-netmod-rfc8022bis has been published as RFC 8349 == Outdated reference: draft-ietf-netmod-yang-tree-diagrams has been published as RFC 8340 == Outdated reference: draft-ietf-rtgwg-ni-model has been published as RFC 8529 -- Obsolete informational reference (is this intentional?): RFC 7895 (Obsoleted by RFC 8525) Summary: 2 errors (**), 0 flaws (~~), 12 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: August 10, 2018 Deutsche Telekom 6 A. Lindem 7 Cisco Systems 8 D. Bogdanovic 10 X. Liu 11 Jabil 12 February 6, 2018 14 YANG Logical Network Elements 15 draft-ietf-rtgwg-lne-model-06 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. 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 August 10, 2018. 42 Copyright Notice 44 Copyright (c) 2018 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Logical Network Elements . . . . . . . . . . . . . . . . . . 5 63 3.1. LNE Instantiation and Resource Assignment . . . . . . . . 6 64 3.2. LNE Management - LNE View . . . . . . . . . . . . . . . . 7 65 3.3. LNE Management - Host Network Device View . . . . . . . . 7 66 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 68 6. Logical Network Element Model . . . . . . . . . . . . . . . . 10 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 70 7.1. Normative References . . . . . . . . . . . . . . . . . . 14 71 7.2. Informative References . . . . . . . . . . . . . . . . . 15 72 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 15 73 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 17 74 B.1. Example: Host Device Managed LNE . . . . . . . . . . . . 17 75 B.1.1. Configuration Data . . . . . . . . . . . . . . . . . 22 76 B.1.2. State Data . . . . . . . . . . . . . . . . . . . . . 25 77 B.2. Example: Self Managed LNE . . . . . . . . . . . . . . . . 36 78 B.2.1. Configuration Data . . . . . . . . . . . . . . . . . 40 79 B.2.2. State Data . . . . . . . . . . . . . . . . . . . . . 43 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 82 1. Introduction 84 This document defines a YANG [RFC6020] module to support the creation 85 of logical network elements on a network device. A logical network 86 element (LNE) is an independently managed virtual device made up of 87 resources allocated to it from the host or parent network device. An 88 LNE running on a host network device conceptually parallels a virtual 89 machine running on a host system. Using host-virtualization 90 terminology one could refer to an LNE as a "Guest", and the 91 containing network-device as the "Host". While LNEs may be 92 implemented via host-virtualization technologies this is not a 93 requirement. 95 This document also defines the necessary augmentations for allocating 96 host resources to a given LNE. As the interface management model 98 [I-D.ietf-netmod-rfc7223bis] is the only a module that currently 99 defines host resources, this document currently defines only a single 100 augmentation to cover the assignment of interfaces to an LNE. Future 101 modules that define support for the control of host device resources 102 are expected to, where appropriate, provide parallel support for the 103 assignment of controlled resources to LNEs. 105 As each LNE is an independently managed device, each will have its 106 own set of YANG modeled data that is independent of the host device 107 and other LNEs. For example, multiple LNEs may all have their own 108 "Tunnel0" interface defined which will not conflict with each other 109 and will not exist in the host's interface model. An LNE will have 110 its own management interfaces possibly including independent 111 instances of netconf/restconf/etc servers to support configuration of 112 their YANG models. As an example of this independence, an 113 implementation may choose to completely rename assigned interfaces, 114 so on the host the assigned interface might be called "Ethernet0/1" 115 while within the LNE it might be called "eth1". 117 In addition to standard management interfaces, a host device 118 implementation may support accessing LNE configuration and 119 operational YANG models directly from the host system. When 120 supported, such access is accomplished through a yang-schema-mount 121 mount point [I-D.ietf-netmod-schema-mount] under which the root level 122 LNE YANG models may be accessed. 124 Examples of vendor terminology for an LNE include logical system or 125 logical router, and virtual switch, chassis, or fabric. 127 1.1. Terminology 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 131 "OPTIONAL" in this document are to be interpreted as described in BCP 132 14 [RFC2119] [RFC8174] when, and only when, they appear in all 133 capitals, as shown here. 135 Readers are expected to be familiar with terms and concepts of YANG 136 [RFC7950] and YANG Schema Mount [I-D.ietf-netmod-schema-mount]. 138 This document uses the graphical representation of data models 139 defined in [I-D.ietf-netmod-yang-tree-diagrams]. 141 2. Overview 143 In this document, we consider network devices that support protocols 144 and functions defined within the IETF Routing Area, e.g, routers, 145 firewalls, and hosts. Such devices may be physical or virtual, e.g., 146 a classic router with custom hardware or one residing within a 147 server-based virtual machine implementing a virtual network function 148 (VNF). Each device may sub-divide their resources into logical 149 network elements (LNEs), each of which provides a managed logical 150 device. Examples of vendor terminology for an LNE include logical 151 system or logical router, and virtual switch, chassis, or fabric. 152 Each LNE may also support virtual routing and forwarding (VRF) and 153 virtual switching instance (VSI) functions, which are referred to 154 below as a network instances (NIs). This breakdown is represented in 155 Figure 1. 157 ,'''''''''''''''''''''''''''''''''''''''''''''''. 158 | Network Device (Physical or Virtual) | 159 | ..................... ..................... | 160 | : Logical Network : : Logical Network : | 161 | : Element : : Element : | 162 | :+-----+-----+-----+: :+-----+-----+-----+: | 163 | :| Net | Net | Net |: :| Net | Net | Net |: | 164 | :|Inst.|Inst.|Inst.|: :|Inst.|Inst.|Inst.|: | 165 | :+-----+-----+-----+: :+-----+-----+-----+: | 166 | : | | | | | | : : | | | | | | : | 167 | :..|.|...|.|...|.|..: :..|.|...|.|...|.|..: | 168 | | | | | | | | | | | | | | 169 ''''|'|'''|'|'''|'|'''''''''|'|'''|'|'''|'|''''' 170 | | | | | | | | | | | | 171 Interfaces Interfaces 173 Figure 1: Module Element Relationships 175 A model for LNEs is described in Section 3 and the model for NIs is 176 covered in [I-D.ietf-rtgwg-ni-model]. 178 The interface management model [I-D.ietf-netmod-rfc7223bis] is an 179 existing model that is impacted by the definition of LNEs and network 180 instances. This document and [I-D.ietf-rtgwg-ni-model] define 181 augmentations to the interface module to support LNEs and NIs. 182 Similar elements, although perhaps only for LNEs, may also need to be 183 included as part of the definition of the future hardware and QoS 184 modules. 186 Interfaces are a crucial part of any network device's configuration 187 and operational state. They generally include a combination of raw 188 physical interfaces, link-layer interfaces, addressing configuration, 189 and logical interfaces that may not be tied to any physical 190 interface. Several system services, and layer 2 and layer 3 191 protocols may also associate configuration or operational state data 192 with different types of interfaces (these relationships are not shown 193 for simplicity). The interface management model is defined by 194 [I-D.ietf-netmod-rfc7223bis]. The logical-network-element module 195 augments existing interface management model by adding an identifier 196 which is used on physical interface types to identify an associated 197 LNE. 199 The interface related augmentation is as follows: 201 module: ietf-logical-network-element 202 augment /if:interfaces/if:interface: 203 +--rw bind-lne-name? -> 204 /logical-network-elements/logical-network-element/name 206 The interface model defined in [I-D.ietf-netmod-rfc7223bis] is 207 structured to include all interfaces in a flat list, without regard 208 to logical assignment of resources supported on the device. The 209 bind-lne-name and leaf provides the association between an interface 210 and its associated LNE. Note that as currently defined, to assign an 211 interface to both an LNE and NI, the interface would first be 212 assigned to the LNE and then within that LNE's interface module, the 213 LNE's representation of that interface would be assigned to an NI 214 using the mechanisms defined in [I-D.ietf-rtgwg-ni-model]. 216 3. Logical Network Elements 218 Logical network elements support the ability of some devices to 219 partition resources into independent logical routers and/or switches. 220 Device support for multiple logical network elements is 221 implementation specific. Systems without such capabilities need not 222 include support for the logical-network-element module. In physical 223 devices, some hardware features are shared across partitions, but 224 control plane (e.g., routing) protocol instances, tables, and 225 configuration are managed separately. For example, in logical 226 routers or VNFs, this may correspond to establishing multiple logical 227 instances using a single software installation. The model supports 228 configuration of multiple instances on a single device by creating a 229 list of logical network elements, each with their own configuration 230 and operational state related to routing and switching protocols. 232 The LNE model can be represented using the tree format defined in 233 [I-D.ietf-netmod-yang-tree-diagrams] 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 'use-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 'use-schema' approach is expected to be be most useful 353 in the case where all LNEs share the same schema. When 'use-schema' 354 is used with an LNE mount point, the YANG library rooted in the LNE's 355 mount point MUST match the associated schema defined within the ietf- 356 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. 406 Unauthorized access to any of these lists can adversely affect the 407 security of both the local device and the network. This may lead to 408 network malfunctions, delivery of packets to inappropriate 409 destinations, and other problems. 411 5. IANA Considerations 413 This document registers a URI in the IETF XML registry [RFC3688]. 414 Following the format in RFC 3688, the following registration is 415 requested to be made. 417 URI: urn:ietf:params:xml:ns:yang:ietf-logical-network-element 419 Registrant Contact: The IESG. 421 XML: N/A, the requested URI is an XML namespace. 423 This document registers a YANG module in the YANG Module Names 424 registry [RFC6020]. 426 name: ietf-logical-network-element 427 namespace: urn:ietf:params:xml:ns:yang:ietf-logical-network-element 428 prefix: lne 429 reference: RFC XXXX 431 6. Logical Network Element Model 433 The structure of the model defined in this document is described by 434 the YANG module below. 436 file "ietf-logical-network-element@2018-02-06.yang" 437 module ietf-logical-network-element { 438 yang-version 1.1; 440 // namespace 442 namespace 443 "urn:ietf:params:xml:ns:yang:ietf-logical-network-element"; 444 prefix lne; 446 // import some basic types 448 import ietf-interfaces { 449 prefix if; 450 reference "draft-ietf-netmod-rfc7223bis: 451 A YANG Data Model for Interface Management"; 452 } 453 import ietf-yang-schema-mount { 454 prefix yangmnt; 455 reference "draft-ietf-netmod-schema-mount: YANG Schema Mount"; 456 // RFC Ed.: Please replace this draft name with the corresponding 457 // RFC number 458 } 460 organization 461 "IETF Routing Area (rtgwg) Working Group"; 462 contact 463 "WG Web: 464 WG List: 466 Author: Lou Berger 467 468 Author: Christan Hopps 469 470 Author: Acee Lindem 471 472 Author: Dean Bogdanovic 473 "; 475 description 476 "This module is used to support multiple logical network 477 elements on a single physical or virtual system. 479 Copyright (c) 2017 IETF Trust and the persons 480 identified as authors of the code. All rights reserved. 482 Redistribution and use in source and binary forms, with or 483 without modification, is permitted pursuant to, and subject 484 to the license terms contained in, the Simplified BSD 485 License set forth in Section 4.c of the IETF Trust's Legal 486 Provisions Relating to IETF Documents 487 (http://trustee.ietf.org/license-info). 489 This version of this YANG module is part of RFC XXXX; see 490 the RFC itself for full legal notices."; 492 // RFC Ed.: replace XXXX with actual RFC number and remove 493 // this note 494 // RFC Ed.: please update TBD 496 revision 2018-02-06 { 497 description 498 "Initial revision."; 499 reference "RFC XXXX"; 500 } 502 // top level device definition statements 504 container logical-network-elements { 505 description 506 "Allows a network device to support multiple logical 507 network element (device) instances."; 508 list logical-network-element { 509 key "name"; 510 description 511 "List of logical network elements."; 512 leaf name { 513 type string; 514 description 515 "Device-wide unique identifier for the 516 logical network element."; 517 } 518 leaf managed { 519 type boolean; 520 default "true"; 521 description 522 "True if the host can access LNE information 523 using the root mount point. This value 524 my not be modifiable in all implementations."; 525 } 526 leaf description { 527 type string; 528 description 529 "Description of the logical network element."; 530 } 531 container "root" { 532 description 533 "Container for mount point."; 534 yangmnt:mount-point "root" { 535 description 536 "Root for models supported per logical 537 network element. This mount point may or may not 538 be inline based on the server implementation. It 539 SHALL always contain a YANG library and interfaces 540 instance. 542 When the associated 'managed' leaf is 'false' any 543 operation that attempts to access information below 544 the root SHALL fail with an error-tag of 545 'access-denied' and an error-app-tag of 546 'lne-not-managed'."; 547 } 548 } 549 } 550 } 552 // augment statements 554 augment "/if:interfaces/if:interface" { 555 description 556 "Add a node for the identification of the logical network 557 element associated with an interface. Applies to 558 interfaces that can be assigned on a per logical network 559 element basis. 561 Note that a standard error will be returned if the 562 identified leafref isn't present. If an interfaces 563 cannot be assigned for any other reason, the operation 564 SHALL fail with an error-tag of 'operation-failed' and an 565 error-app-tag of 'lne-assignment-failed'. A meaningful 566 error-info that indicates the source of the assignment 567 failure SHOULD also be provided."; 568 leaf bind-lne-name { 569 type leafref { 570 path 571 "/logical-network-elements/logical-network-element/name"; 572 } 573 description 574 "Logical network element ID to which interface is bound."; 575 } 576 } 578 // notification statements 580 notification bind-lne-name-failed { 581 description 582 "Indicates an error in the association of an interface to an 583 LNE. Only generated after success is initially returned when 584 bind-lne-name is set."; 585 leaf name { 586 type leafref { 587 path "/if:interfaces/if:interface/if:name"; 588 } 589 mandatory true; 590 description 591 "Contains the interface name associated with the 592 failure."; 593 } 594 leaf bind-lne-name { 595 type leafref { 596 path "/if:interfaces/if:interface/lne:bind-lne-name"; 597 } 598 mandatory true; 599 description 600 "Contains the bind-lne-name associated with the 601 failure."; 602 } 603 leaf error-info { 604 type string; 605 description 606 "Optionally, indicates the source of the assignment 607 failure."; 608 } 609 } 610 } 611 613 7. References 614 7.1. Normative References 616 [I-D.ietf-netmod-rfc7223bis] 617 Bjorklund, M., "A YANG Data Model for Interface 618 Management", draft-ietf-netmod-rfc7223bis-03 (work in 619 progress), January 2018. 621 [I-D.ietf-netmod-schema-mount] 622 Bjorklund, M. and L. Lhotka, "YANG Schema Mount", draft- 623 ietf-netmod-schema-mount-08 (work in progress), October 624 2017. 626 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 627 Requirement Levels", BCP 14, RFC 2119, 628 DOI 10.17487/RFC2119, March 1997, . 631 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 632 DOI 10.17487/RFC3688, January 2004, . 635 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 636 (TLS) Protocol Version 1.2", RFC 5246, 637 DOI 10.17487/RFC5246, August 2008, . 640 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 641 the Network Configuration Protocol (NETCONF)", RFC 6020, 642 DOI 10.17487/RFC6020, October 2010, . 645 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 646 and A. Bierman, Ed., "Network Configuration Protocol 647 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 648 . 650 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 651 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 652 . 654 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 655 Protocol (NETCONF) Access Control Model", RFC 6536, 656 DOI 10.17487/RFC6536, March 2012, . 659 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 660 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 661 . 663 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 664 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 665 May 2017, . 667 7.2. Informative References 669 [I-D.ietf-netmod-rfc8022bis] 670 Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for 671 Routing Management (NMDA Version)", draft-ietf-netmod- 672 rfc8022bis-11 (work in progress), January 2018. 674 [I-D.ietf-netmod-yang-tree-diagrams] 675 Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft- 676 ietf-netmod-yang-tree-diagrams-05 (work in progress), 677 January 2018. 679 [I-D.ietf-rtgwg-device-model] 680 Lindem, A., Berger, L., Bogdanovic, D., and C. Hopps, 681 "Network Device YANG Logical Organization", draft-ietf- 682 rtgwg-device-model-02 (work in progress), March 2017. 684 [I-D.ietf-rtgwg-ni-model] 685 Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. 686 Liu, "YANG Network Instances", draft-ietf-rtgwg-ni- 687 model-09 (work in progress), February 2018. 689 [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for 690 System Management", RFC 7317, DOI 10.17487/RFC7317, August 691 2014, . 693 [RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module 694 Library", RFC 7895, DOI 10.17487/RFC7895, June 2016, 695 . 697 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 698 RFC 7950, DOI 10.17487/RFC7950, August 2016, 699 . 701 Appendix A. Acknowledgments 703 The Routing Area Yang Architecture design team members included Acee 704 Lindem, Anees Shaikh, Christian Hopps, Dean Bogdanovic, Lou Berger, 705 Qin Wu, Rob Shakir, Stephane Litkowski, and Yan Gang. Useful review 706 comments were also received by Martin Bjorklund and John Scudder. 708 This document was motivated by, and derived from, 709 [I-D.ietf-rtgwg-device-model]. 711 The RFC text was produced using Marshall Rose's xml2rfc tool. 713 Thanks to Alvaro Retana for IESG review. 715 Appendix B. Examples 717 The following subsections provide example uses of LNEs. 719 B.1. Example: Host Device Managed LNE 721 This section describes an example of the LNE model using schema mount 722 to achieve the parent management. An example device supports 723 multiple instances of LNEs (logical routers), each of which supports 724 features of layer 2 and layer 3 interfaces 725 [I-D.ietf-netmod-rfc7223bis], routing information base 726 [I-D.ietf-netmod-rfc8022bis], and OSPF protocol. Each of these 727 features is specified by a YANG model, and they are combined using 728 YANG Schema Mount as follows: 730 module: ietf-logical-network-element 731 +--rw logical-network-elements 732 +--rw logical-network-element* [name] 733 +--rw name string 734 +--mp root 735 +--ro yanglib:modules-state/ 736 | +--ro module-set-id string 737 | +--ro module* [name revision] 738 | +--ro name yang:yang-identifier 739 +--rw sys:system/ 740 | +--rw contact? string 741 | +--rw hostname? inet:domain-name 742 | +--rw authentication {authentication}? 743 | +--rw user-authentication-order* identityref 744 | +--rw user* [name] {local-users}? 745 | +--rw name string 746 | +--rw password? ianach:crypt-hash 747 | +--rw authorized-key* [name] 748 | +--rw name string 749 | +--rw algorithm string 750 | +--rw key-data binary 751 +--ro sys:system-state/ 752 | ... 753 +--rw rt:routing/ 754 | +--rw router-id? yang:dotted-quad 755 | +--rw control-plane-protocols 756 | +--rw control-plane-protocol* [type name] 757 | +--rw ospf:ospf/ 758 | +--rw instance* [af] 759 | +--rw areas 760 | +--rw area* [area-id] 761 | +--rw interfaces 762 | +--rw interface* [name] 763 | +--rw name if:interface-ref 764 | +--rw cost? uint16 765 +--rw if:interfaces/ 766 +--rw interface* [name] 767 +--rw name string 768 +--rw ip:ipv4!/ 769 | +--rw address* [ip] 770 | ... 772 module: ietf-interfaces 773 +--rw interfaces 774 +--rw interface* [name] 775 +--rw name string 776 +--rw lne:bind-lne-name? string 777 +--ro oper-status enumeration 779 module: ietf-yang-library 780 +--ro modules-state 781 +--ro module-set-id string 782 +--ro module* [name revision] 783 +--ro name yang:yang-identifier 785 module: ietf-system 786 +--rw system 787 | +--rw contact? string 788 | +--rw hostname? inet:domain-name 789 | +--rw authentication {authentication}? 790 | +--rw user-authentication-order* identityref 791 | +--rw user* [name] {local-users}? 792 | +--rw name string 793 | +--rw password? ianach:crypt-hash 794 | +--rw authorized-key* [name] 795 | +--rw name string 796 | +--rw algorithm string 797 | +--rw key-data binary 798 +--ro system-state 799 +--ro platform 800 | +--ro os-name? string 801 | +--ro os-release? string 803 To realize the above schema, the example device implements the 804 following schema mount instance: 806 "ietf-yang-schema-mount:schema-mounts": { 807 "mount-point": [ 808 { 809 "module": "ietf-logical-network-element", 810 "label": "root", 811 "use-schema": [ 812 { 813 "name": "lne-schema" 814 } 815 ] 816 } 817 ], 818 "schema": [ 819 { 820 "name": "lne-schema", 821 "module": [ 822 { 823 "name": "ietf-yang-library", 824 "revision": "2016-06-21", 825 "namespace": 826 "urn:ietf:params:xml:ns:yang:ietf-yang-library", 827 "conformance-type": "implement" 828 }, 829 { 830 "name": "ietf-system", 831 "revision": "2014-08-06", 832 "namespace": 833 "urn:ietf:params:xml:ns:yang:ietf-system", 834 "conformance-type": "implement" 835 }, 836 { 837 "name": "ietf-routing", 838 "revision": "2016-11-04", 839 "namespace": 840 "urn:ietf:params:xml:ns:yang:ietf-routing", 841 "conformance-type": "implement" 842 }, 843 { 844 "name": "ietf-ospf", 845 "revision": "2017-03-12", 846 "namespace": 847 "urn:ietf:params:xml:ns:yang:ietf-ospf", 848 "conformance-type": "implement" 849 }, 850 { 851 "name": "ietf-interfaces", 852 "revision": "2014-05-08", 853 "namespace": 854 "urn:ietf:params:xml:ns:yang:ietf-interfaces", 855 "conformance-type": "implement" 856 }, 857 { 858 "name": "ietf-ip", 859 "revision": "2014-06-16", 860 "namespace": 861 "urn:ietf:params:xml:ns:yang:ietf-ip", 862 "conformance-type": "implement" 863 } 864 ] 865 } 866 ] 867 } 869 By using the implementation of the YANG schema mount, an operator can 870 create instances of logical routers. An interface can be assigned to 871 a logical router, so that the logical router has the permission to 872 access this interface. The OSPF protocol can then be enabled on this 873 assigned interface. 875 For this implementation, a parent management session has access to 876 the schemas of both the parent hosting system and the child logical 877 routers. In addition, each child logical router can grant its own 878 management sessions, which have the following schema: 880 module: ietf-yang-library 881 +--ro modules-state 882 +--ro module-set-id string 883 +--ro module* [name revision] 884 +--ro name yang:yang-identifier 886 module: ietf-system 887 +--rw system 888 | +--rw contact? string 889 | +--rw hostname? inet:domain-name 890 | +--rw authentication {authentication}? 891 | +--rw user-authentication-order* identityref 892 | +--rw user* [name] {local-users}? 893 | +--rw name string 894 | +--rw password? ianach:crypt-hash 895 | +--rw authorized-key* [name] 896 | +--rw name string 897 | +--rw algorithm string 898 | +--rw key-data binary 899 +--ro system-state 900 +--ro platform 901 +--ro os-name? string 902 +--ro os-release? string 904 module: ietf-routing 905 rw-- routing 906 +--rw router-id? yang:dotted-quad 907 +--rw control-plane-protocols 908 +--rw control-plane-protocol* [type name] 909 +--rw ospf:ospf/ 910 +--rw instance* [af] 911 +--rw areas 912 +--rw area* [area-id] 913 +--rw interfaces 914 +--rw interface* [name] 915 +--rw name if:interface-ref 916 +--rw cost? uint16 918 module: ietf-interfaces 919 +--rw interfaces 920 +--rw interface* [name] 921 +--rw name string 922 +--ro oper-status enumeration 924 B.1.1. Configuration Data 926 The following shows an example where two customer specific LNEs are 927 configured: 929 { 930 "ietf-logical-network-element:logical-network-elements": { 931 "logical-network-element": [ 932 { 933 "name": "cust1", 934 "root": { 935 "ietf-system:system": { 936 "authentication": { 937 "user": [ 938 { 939 "name": "john", 940 "password": "$0$password" 941 } 942 ] 943 } 944 }, 945 "ietf-routing:routing": { 946 "router-id": "192.0.2.1", 947 "control-plane-protocols": { 948 "control-plane-protocol": [ 949 { 950 "type": "ietf-routing:ospf", 951 "name": "1", 952 "ietf-ospf:ospf": { 953 "instance": [ 954 { 955 "af": "ipv4", 956 "areas": { 957 "area": [ 958 { 959 "area-id": "203.0.113.1", 960 "interfaces": { 961 "interface": [ 962 { 963 "name": "eth1", 964 "cost": 10 965 } 966 ] 967 } 968 } 969 ] 970 } 971 } 973 ] 974 } 975 } 976 ] 977 } 978 }, 979 "ietf-interfaces:interfaces": { 980 "interfaces": { 981 "interface": [ 982 { 983 "name": "eth1", 984 "ip:ipv4": { 985 "address": [ 986 { 987 "ip": "192.0.2.11", 988 "prefix-length": 24, 989 } 990 ] 991 } 992 } 993 ] 994 } 995 } 996 } 997 }, 998 { 999 "name": "cust2", 1000 "root": { 1001 "ietf-system:system": { 1002 "authentication": { 1003 "user": [ 1004 { 1005 "name": "john", 1006 "password": "$0$password" 1007 } 1008 ] 1009 } 1010 } 1011 "ietf-routing:routing": { 1012 "router-id": "192.0.2.2", 1013 "control-plane-protocols": { 1014 "control-plane-protocol": [ 1015 { 1016 "type": "ietf-routing:ospf", 1017 "name": "1", 1018 "ietf-ospf:ospf": { 1019 "instance": [ 1020 { 1021 "af": "ipv4", 1022 "areas": { 1023 "area": [ 1024 { 1025 "area-id": "203.0.113.1", 1026 "interfaces": { 1027 "interface": [ 1028 { 1029 "name": "eth1", 1030 "cost": 10 1031 } 1032 ] 1033 } 1034 } 1035 ] 1036 } 1037 } 1038 ] 1039 } 1040 } 1041 ] 1042 } 1043 } 1044 "ietf-interfaces:interfaces": { 1045 "interfaces": { 1046 { 1047 "name": "eth1", 1048 "ip:ipv4": { 1049 "address": [ 1050 { 1051 "ip": "192.0.2.11", 1052 "prefix-length": 24, 1053 } 1054 ] 1055 } 1056 } 1057 ] 1058 } 1059 } 1060 } 1061 ] 1062 }, 1064 "ietf-interfaces:interfaces": { 1065 "interfaces": { 1066 "interface": [ 1067 { 1068 "name": "eth0", 1069 "ip:ipv4": { 1070 "address": [ 1071 { 1072 "ip": "192.0.2.10", 1073 "prefix-length": 24, 1074 } 1075 ] 1076 } 1077 }, 1078 { 1079 "name": "cust1:eth1", 1080 "lne:bind-lne-name": "cust1" 1081 }, 1082 { 1083 "name": "cust2:eth1", 1084 "lne:bind-lne-name": "cust2" 1085 } 1086 ] 1087 } 1088 }, 1090 "ietf-system:system": { 1091 "authentication": { 1092 "user": [ 1093 { 1094 "name": "root", 1095 "password": "$0$password" 1096 } 1097 ] 1098 } 1099 } 1100 } 1102 B.1.2. State Data 1104 The following shows possible state data associated the above 1105 configuration data: 1107 { 1108 "ietf-logical-network-element:logical-network-elements": { 1109 "logical-network-element": [ 1110 { 1111 "name": "cust1", 1112 "root": { 1113 "ietf-yang-library:modules-state": { 1114 "module-set-id": "123e4567-e89b-12d3-a456-426655440000", 1115 "module": [ 1116 { 1117 "name": "iana-if-type", 1118 "revision": "2014-05-08", 1119 "namespace": 1120 "urn:ietf:params:xml:ns:yang:iana-if-type", 1121 "conformance-type": "import" 1122 }, 1123 { 1124 "name": "ietf-inet-types", 1125 "revision": "2013-07-15", 1126 "namespace": 1127 "urn:ietf:params:xml:ns:yang:ietf-inet-types", 1128 "conformance-type": "import" 1129 }, 1130 { 1131 "name": "ietf-interfaces", 1132 "revision": "2014-05-08", 1133 "feature": [ 1134 "arbitrary-names", 1135 "pre-provisioning" 1136 ], 1137 "namespace": 1138 "urn:ietf:params:xml:ns:yang:ietf-interfaces", 1139 "conformance-type": "implement" 1140 }, 1141 { 1142 "name": "ietf-ip", 1143 "revision": "2014-06-16", 1144 "namespace": 1145 "urn:ietf:params:xml:ns:yang:ietf-ip", 1146 "conformance-type": "implement" 1147 }, 1148 { 1149 "name": "ietf-ospf", 1150 "revision": "2017-03-12", 1151 "namespace": 1152 "urn:ietf:params:xml:ns:yang:ietf-ospf", 1153 "conformance-type": "implement" 1154 }, 1155 { 1156 "name": "ietf-routing", 1157 "revision": "2016-11-04", 1158 "namespace": 1159 "urn:ietf:params:xml:ns:yang:ietf-routing", 1160 "conformance-type": "implement" 1161 }, 1162 { 1163 "name": "ietf-system", 1164 "revision": "2014-08-06", 1165 "namespace": 1166 "urn:ietf:params:xml:ns:yang:ietf-system", 1167 "conformance-type": "implement" 1168 }, 1169 { 1170 "name": "ietf-yang-library", 1171 "revision": "2016-06-21", 1172 "namespace": 1173 "urn:ietf:params:xml:ns:yang:ietf-yang-library", 1174 "conformance-type": "implement" 1175 }, 1176 { 1177 "name": "ietf-yang-types", 1178 "revision": "2013-07-15", 1179 "namespace": 1180 "urn:ietf:params:xml:ns:yang:ietf-yang-types", 1181 "conformance-type": "import" 1182 } 1183 ] 1184 } 1185 "ietf-system:system-state": { 1186 "ietf-system:system-state": { 1187 "platform": { 1188 "os-name": "NetworkOS" 1189 } 1190 } 1191 }, 1192 "ietf-routing:routing": { 1193 "router-id": "192.0.2.1", 1194 "control-plane-protocols": { 1195 "control-plane-protocol": [ 1196 { 1197 "type": "ietf-routing:ospf", 1198 "name": "1", 1199 "ietf-ospf:ospf": { 1200 "instance": [ 1201 { 1202 "af": "ipv4", 1203 "areas": { 1204 "area": [ 1205 { 1206 "area-id": "203.0.113.1", 1207 "interfaces": { 1208 "interface": [ 1209 { 1210 "name": "eth1", 1211 "cost": 10 1212 } 1214 ] 1215 } 1216 } 1217 ] 1218 } 1219 } 1220 ] 1221 } 1222 } 1223 ] 1224 } 1225 }, 1226 "ietf-interfaces:interfaces": { 1227 "interfaces": { 1228 "interface": [ 1229 { 1230 "name": "eth1", 1231 "type": "iana-if-type:ethernetCsmacd", 1232 "oper-status": "up", 1233 "phys-address": "00:01:02:A1:B1:C1", 1234 "statistics": { 1235 "discontinuity-time": "2017-06-26T12:34:56-05:00" 1236 }, 1237 "ip:ipv4": { 1238 "address": [ 1239 { 1240 "ip": "192.0.2.11", 1241 "prefix-length": 24, 1242 } 1243 ] 1244 } 1245 } 1246 ] 1247 } 1248 } 1249 } 1250 }, 1251 { 1252 "name": "cust2", 1253 "root": { 1254 "ietf-yang-library:modules-state": { 1255 "module-set-id": "123e4567-e89b-12d3-a456-426655440000", 1256 "module": [ 1257 { 1258 "name": "iana-if-type", 1259 "revision": "2014-05-08", 1260 "namespace": 1261 "urn:ietf:params:xml:ns:yang:iana-if-type", 1262 "conformance-type": "import" 1263 }, 1264 { 1265 "name": "ietf-inet-types", 1266 "revision": "2013-07-15", 1267 "namespace": 1268 "urn:ietf:params:xml:ns:yang:ietf-inet-types", 1269 "conformance-type": "import" 1270 }, 1271 { 1272 "name": "ietf-interfaces", 1273 "revision": "2014-05-08", 1274 "feature": [ 1275 "arbitrary-names", 1276 "pre-provisioning" 1277 ], 1278 "namespace": 1279 "urn:ietf:params:xml:ns:yang:ietf-interfaces", 1280 "conformance-type": "implement" 1281 }, 1282 { 1283 "name": "ietf-ip", 1284 "revision": "2014-06-16", 1285 "namespace": 1286 "urn:ietf:params:xml:ns:yang:ietf-ip", 1287 "conformance-type": "implement" 1288 }, 1289 { 1290 "name": "ietf-ospf", 1291 "revision": "2017-03-12", 1292 "namespace": 1293 "urn:ietf:params:xml:ns:yang:ietf-ospf", 1294 "conformance-type": "implement" 1295 }, 1296 { 1297 "name": "ietf-routing", 1298 "revision": "2016-11-04", 1299 "namespace": 1300 "urn:ietf:params:xml:ns:yang:ietf-routing", 1301 "conformance-type": "implement" 1302 }, 1303 { 1304 "name": "ietf-system", 1305 "revision": "2014-08-06", 1306 "namespace": 1307 "urn:ietf:params:xml:ns:yang:ietf-system", 1308 "conformance-type": "implement" 1309 }, 1310 { 1311 "name": "ietf-yang-library", 1312 "revision": "2016-06-21", 1313 "namespace": 1314 "urn:ietf:params:xml:ns:yang:ietf-yang-library", 1315 "conformance-type": "implement" 1316 }, 1317 { 1318 "name": "ietf-yang-types", 1319 "revision": "2013-07-15", 1320 "namespace": 1321 "urn:ietf:params:xml:ns:yang:ietf-yang-types", 1322 "conformance-type": "import" 1323 } 1324 ] 1325 } 1326 "ietf-system:system-state": { 1327 "ietf-system:system-state": { 1328 "platform": { 1329 "os-name": "NetworkOS" 1330 } 1331 } 1332 }, 1333 "ietf-routing:routing": { 1334 "router-id": "192.0.2.2", 1335 "control-plane-protocols": { 1336 "control-plane-protocol": [ 1337 { 1338 "type": "ietf-routing:ospf", 1339 "name": "1", 1340 "ietf-ospf:ospf": { 1341 "instance": [ 1342 { 1343 "af": "ipv4", 1344 "areas": { 1345 "area": [ 1346 { 1347 "area-id": "203.0.113.1", 1348 "interfaces": { 1349 "interface": [ 1350 { 1351 "name": "eth1", 1352 "cost": 10 1353 } 1354 ] 1355 } 1356 } 1357 ] 1359 } 1360 } 1361 ] 1362 } 1363 } 1364 ] 1365 } 1366 } 1367 "ietf-interfaces:interfaces": { 1368 "interfaces": { 1369 { 1370 "name": "eth1", 1371 "type": "iana-if-type:ethernetCsmacd", 1372 "oper-status": "up", 1373 "phys-address": "00:01:02:A1:B1:C2", 1374 "statistics": { 1375 "discontinuity-time": "2017-06-26T12:34:56-05:00" 1376 }, 1377 "ip:ipv4": { 1378 "address": [ 1379 { 1380 "ip": "192.0.2.11", 1381 "prefix-length": 24, 1382 } 1383 ] 1384 } 1385 } 1386 ] 1387 } 1388 } 1389 } 1390 ] 1391 }, 1393 "ietf-interfaces:interfaces": { 1394 "interfaces": { 1395 "interface": [ 1396 { 1397 "name": "eth0", 1398 "type": "iana-if-type:ethernetCsmacd", 1399 "oper-status": "up", 1400 "phys-address": "00:01:02:A1:B1:C0", 1401 "statistics": { 1402 "discontinuity-time": "2017-06-26T12:34:56-05:00" 1403 }, 1404 "ip:ipv4": { 1405 "address": [ 1406 { 1407 "ip": "192.0.2.10", 1408 "prefix-length": 24, 1409 } 1410 ] 1411 } 1412 }, 1413 { 1414 "name": "cust1:eth1", 1415 "type": "iana-if-type:ethernetCsmacd", 1416 "oper-status": "up", 1417 "phys-address": "00:01:02:A1:B1:C1", 1418 "statistics": { 1419 "discontinuity-time": "2017-06-26T12:34:56-05:00" 1420 } 1421 }, 1422 { 1423 "name": "cust2:eth1", 1424 "type": "iana-if-type:ethernetCsmacd", 1425 "oper-status": "up", 1426 "phys-address": "00:01:02:A1:B1:C2", 1427 "statistics": { 1428 "discontinuity-time": "2017-06-26T12:34:56-05:00" 1429 } 1430 } 1431 ] 1432 } 1433 }, 1435 "ietf-system:system-state": { 1436 "platform": { 1437 "os-name": "NetworkOS" 1438 } 1439 }, 1441 "ietf-yang-library:modules-state": { 1442 "module-set-id": "123e4567-e89b-12d3-a456-426655440000", 1443 "module": [ 1444 { 1445 "name": "iana-if-type", 1446 "revision": "2014-05-08", 1447 "namespace": 1448 "urn:ietf:params:xml:ns:yang:iana-if-type", 1449 "conformance-type": "import" 1450 }, 1451 { 1452 "name": "ietf-inet-types", 1453 "revision": "2013-07-15", 1454 "namespace": 1456 "urn:ietf:params:xml:ns:yang:ietf-inet-types", 1457 "conformance-type": "import" 1458 }, 1459 { 1460 "name": "ietf-interfaces", 1461 "revision": "2014-05-08", 1462 "feature": [ 1463 "arbitrary-names", 1464 "pre-provisioning" 1465 ], 1466 "namespace": 1467 "urn:ietf:params:xml:ns:yang:ietf-interfaces", 1468 "conformance-type": "implement" 1469 }, 1470 { 1471 "name": "ietf-ip", 1472 "revision": "2014-06-16", 1473 "namespace": 1474 "urn:ietf:params:xml:ns:yang:ietf-ip", 1475 "conformance-type": "implement" 1476 }, 1477 { 1478 "name": "ietf-logical-network-element", 1479 "revision": "2017-03-13", 1480 "feature": [ 1481 "bind-lne-name" 1482 ], 1483 "namespace": 1484 "urn:ietf:params:xml:ns:yang:ietf-logical-network-element", 1485 "conformance-type": "implement" 1486 }, 1487 { 1488 "name": "ietf-ospf", 1489 "revision": "2017-03-12", 1490 "namespace": 1491 "urn:ietf:params:xml:ns:yang:ietf-ospf", 1492 "conformance-type": "implement" 1493 }, 1494 { 1495 "name": "ietf-routing", 1496 "revision": "2016-11-04", 1497 "namespace": 1498 "urn:ietf:params:xml:ns:yang:ietf-routing", 1499 "conformance-type": "implement" 1500 }, 1501 { 1502 "name": "ietf-system", 1503 "revision": "2014-08-06", 1504 "namespace": 1505 "urn:ietf:params:xml:ns:yang:ietf-system", 1506 "conformance-type": "implement" 1507 }, 1508 { 1509 "name": "ietf-yang-library", 1510 "revision": "2016-06-21", 1511 "namespace": 1512 "urn:ietf:params:xml:ns:yang:ietf-yang-library", 1513 "conformance-type": "implement" 1514 }, 1515 { 1516 "name": "ietf-yang-schema-mount", 1517 "revision": "2017-05-16", 1518 "namespace": 1519 "urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount", 1520 "conformance-type": "implement" 1521 }, 1522 { 1523 "name": "ietf-yang-types", 1524 "revision": "2013-07-15", 1525 "namespace": 1526 "urn:ietf:params:xml:ns:yang:ietf-yang-types", 1527 "conformance-type": "import" 1528 } 1529 ] 1530 }, 1532 "ietf-yang-schema-mount:schema-mounts": { 1533 "mount-point": [ 1534 { 1535 "module": "ietf-logical-network-element", 1536 "label": "root", 1537 "use-schema": [ 1538 { 1539 "name": "lne-schema" 1540 } 1541 ] 1542 } 1543 ], 1544 "schema": [ 1545 { 1546 "name": "lne-schema", 1547 "module": [ 1548 { 1549 "name": "ietf-yang-library", 1550 "revision": "2016-06-21", 1551 "namespace": 1553 "urn:ietf:params:xml:ns:yang:ietf-yang-library", 1554 "conformance-type": "implement" 1555 }, 1556 { 1557 "name": "ietf-system", 1558 "revision": "2014-08-06", 1559 "namespace": 1560 "urn:ietf:params:xml:ns:yang:ietf-system", 1561 "conformance-type": "implement" 1562 }, 1563 { 1564 "name": "ietf-routing", 1565 "revision": "2016-11-04", 1566 "namespace": 1567 "urn:ietf:params:xml:ns:yang:ietf-routing", 1568 "conformance-type": "implement" 1569 }, 1570 { 1571 "name": "ietf-ospf", 1572 "revision": "2017-03-12", 1573 "namespace": 1574 "urn:ietf:params:xml:ns:yang:ietf-ospf", 1575 "conformance-type": "implement" 1576 }, 1577 { 1578 "name": "ietf-interfaces", 1579 "revision": "2014-05-08", 1580 "namespace": 1581 "urn:ietf:params:xml:ns:yang:ietf-interfaces", 1582 "conformance-type": "implement" 1583 }, 1584 { 1585 "name": "ietf-ip", 1586 "revision": "2014-06-16", 1587 "namespace": 1588 "urn:ietf:params:xml:ns:yang:ietf-ip", 1589 "conformance-type": "implement" 1590 } 1591 ] 1592 } 1593 ] 1594 } 1595 } 1597 B.2. Example: Self Managed LNE 1599 This section describes an example of the LNE model using schema mount 1600 to achieve child independent management. An example device supports 1601 multiple instances of LNEs (logical routers), each of them has the 1602 features of layer 2 and layer 3 interfaces 1603 [I-D.ietf-netmod-rfc7223bis], routing information base 1604 [I-D.ietf-netmod-rfc8022bis], and the OSPF protocol. Each of these 1605 features is specified by a YANG model, and they are put together by 1606 the YANG Schema Mount as following: 1608 module: ietf-logical-network-element 1609 +--rw logical-network-elements 1610 +--rw logical-network-element* [name] 1611 +--rw name string 1612 +--mp root 1613 // The internal modules of the LNE are not visible to 1614 // the parament management. 1615 // The child manages its modules, including ietf-routing 1616 // and ietf-interfaces 1618 module: ietf-interfaces 1619 +--rw interfaces 1620 +--rw interface* [name] 1621 +--rw name string 1622 +--rw lne:bind-lne-name? string 1623 +--ro oper-status enumeration 1625 module: ietf-yang-library 1626 +--ro modules-state 1627 +--ro module-set-id string 1628 +--ro module* [name revision] 1629 +--ro name yang:yang-identifier 1631 module: ietf-system 1632 +--rw system 1633 | +--rw contact? string 1634 | +--rw hostname? inet:domain-name 1635 | +--rw authentication {authentication}? 1636 | +--rw user-authentication-order* identityref 1637 | +--rw user* [name] {local-users}? 1638 | +--rw name string 1639 | +--rw password? ianach:crypt-hash 1640 | +--rw authorized-key* [name] 1641 | +--rw name string 1642 | +--rw algorithm string 1643 | +--rw key-data binary 1644 +--ro system-state 1645 +--ro platform 1646 | +--ro os-name? string 1647 | +--ro os-release? string 1649 To realize the above schema, the device implements the following 1650 schema mount instance: 1652 "ietf-yang-schema-mount:schema-mounts": { 1653 "mount-point": [ 1654 { 1655 "module": "ietf-logical-network-element", 1656 "label": "root", 1657 "inline": [null] 1658 } 1659 ] 1660 } 1662 By using the implementation of the YANG schema mount, an operator can 1663 create instances of logical routers, each with their logical router 1664 specific in-line modules. An interface can be assigned to a logical 1665 router, so that the logical router has the permission to access this 1666 interface. The OSPF protocol can then be enabled on this assigned 1667 interface. Each logical router independently manages its own set of 1668 modules, which may or may not be the same as other logical routers. 1669 The following is an example of schema set implemented on one 1670 particular logical router: 1672 module: ietf-yang-library 1673 +--ro modules-state 1674 +--ro module-set-id string 1675 +--ro module* [name revision] 1676 +--ro name yang:yang-identifier 1678 module: ietf-system 1679 +--rw system 1680 | +--rw contact? string 1681 | +--rw hostname? inet:domain-name 1682 | +--rw authentication {authentication}? 1683 | +--rw user-authentication-order* identityref 1684 | +--rw user* [name] {local-users}? 1685 | +--rw name string 1686 | +--rw password? ianach:crypt-hash 1687 | +--rw authorized-key* [name] 1688 | +--rw name string 1689 | +--rw algorithm string 1690 | +--rw key-data binary 1691 +--ro system-state 1692 +--ro platform 1693 | +--ro os-name? string 1694 | +--ro os-release? string 1696 module: ietf-routing 1697 +--rw routing 1698 +--rw router-id? yang:dotted-quad 1699 +--rw control-plane-protocols 1700 +--rw control-plane-protocol* [type name] 1701 +--rw ospf:ospf/ 1702 +--rw instance* [af] 1703 +--rw areas 1704 +--rw area* [area-id] 1705 +--rw interfaces 1706 +--rw interface* [name] 1707 +--rw name if:interface-ref 1708 +--rw cost? uint16 1710 module: ietf-interfaces 1711 +--rw interfaces 1712 +--rw interface* [name] 1713 +--rw name string 1714 +--ro oper-status enumeration 1716 B.2.1. Configuration Data 1718 Each of the child virtual routers is managed through its own sessions 1719 and configuration data. 1721 B.2.1.1. Logical Network Element 'vnf1' 1723 The following shows an example configuration data for the LNE name 1724 "vnf1": 1726 { 1727 "ietf-system:system": { 1728 "authentication": { 1729 "user": [ 1730 { 1731 "name": "john", 1732 "password": "$0$password" 1733 } 1734 ] 1735 } 1736 }, 1737 "ietf-routing:routing": { 1738 "router-id": "192.0.2.1", 1739 "control-plane-protocols": { 1740 "control-plane-protocol": [ 1741 { 1742 "type": "ietf-routing:ospf", 1743 "name": "1", 1744 "ietf-ospf:ospf": { 1745 "instance": [ 1746 { 1747 "af": "ipv4", 1748 "areas": { 1749 "area": [ 1750 { 1751 "area-id": "203.0.113.1", 1752 "interfaces": { 1753 "interface": [ 1754 { 1755 "name": "eth1", 1756 "cost": 10 1757 } 1758 ] 1759 } 1760 } 1761 ] 1762 } 1763 } 1765 ] 1766 } 1767 } 1768 ] 1769 } 1770 }, 1771 "ietf-interfaces:interfaces": { 1772 "interfaces": { 1773 "interface": [ 1774 { 1775 "name": "eth1", 1776 "ip:ipv4": { 1777 "address": [ 1778 { 1779 "ip": "192.0.2.11", 1780 "prefix-length": 24, 1781 } 1782 ] 1783 } 1784 } 1785 ] 1786 } 1787 } 1788 } 1790 B.2.1.2. Logical Network Element 'vnf2' 1792 The following shows an example configuration data for the LNE name 1793 "vnf2": 1795 { 1796 "ietf-system:system": { 1797 "authentication": { 1798 "user": [ 1799 { 1800 "name": "john", 1801 "password": "$0$password" 1802 } 1803 ] 1804 } 1805 }, 1806 "ietf-routing:routing": { 1807 "router-id": "192.0.2.2", 1808 "control-plane-protocols": { 1809 "control-plane-protocol": [ 1810 { 1811 "type": "ietf-routing:ospf", 1812 "name": "1", 1813 "ietf-ospf:ospf": { 1814 "instance": [ 1815 { 1816 "af": "ipv4", 1817 "areas": { 1818 "area": [ 1819 { 1820 "area-id": "203.0.113.1", 1821 "interfaces": { 1822 "interface": [ 1823 { 1824 "name": "eth1", 1825 "cost": 10 1826 } 1827 ] 1828 } 1829 } 1830 ] 1831 } 1832 } 1833 ] 1834 } 1835 } 1836 ] 1837 } 1838 }, 1839 "ietf-interfaces:interfaces": { 1840 "interfaces": { 1841 "interface": [ 1842 { 1843 "name": "eth1", 1844 "ip:ipv4": { 1845 "address": [ 1846 { 1847 "ip": "192.0.2.11", 1848 "prefix-length": 24, 1849 } 1850 ] 1851 } 1852 } 1853 ] 1854 } 1855 } 1856 } 1858 B.2.2. State Data 1860 The following sections shows possible state data associated the above 1861 configuration data. Note that there are three views: the host 1862 device's, and each LNE's. 1864 B.2.2.1. Host Device 1866 The following shows state data for the device hosting the example 1867 LNEs: 1869 { 1870 "ietf-logical-network-element:logical-network-elements": { 1871 "logical-network-element": [ 1872 { 1873 "name": "vnf1", 1874 "root": { 1875 } 1876 }, 1877 { 1878 "name": "vnf2", 1879 "root": { 1880 } 1881 } 1882 ] 1883 }, 1885 "ietf-interfaces:interfaces": { 1886 "interfaces": { 1887 "interface": [ 1888 { 1889 "name": "eth0", 1890 "type": "iana-if-type:ethernetCsmacd", 1891 "oper-status": "up", 1892 "phys-address": "00:01:02:A1:B1:C0", 1893 "statistics": { 1894 "discontinuity-time": "2017-06-26T12:34:56-05:00" 1895 }, 1896 "ip:ipv4": { 1897 "address": [ 1898 { 1899 "ip": "192.0.2.10", 1900 "prefix-length": 24, 1901 } 1902 ] 1903 } 1904 }, 1905 { 1906 "name": "vnf1:eth1", 1907 "type": "iana-if-type:ethernetCsmacd", 1908 "oper-status": "up", 1909 "phys-address": "00:01:02:A1:B1:C1", 1910 "statistics": { 1911 "discontinuity-time": "2017-06-26T12:34:56-05:00" 1912 } 1913 }, 1914 { 1915 "name": "vnf2:eth2", 1916 "type": "iana-if-type:ethernetCsmacd", 1917 "oper-status": "up", 1918 "phys-address": "00:01:02:A1:B1:C2", 1919 "statistics": { 1920 "discontinuity-time": "2017-06-26T12:34:56-05:00" 1921 } 1922 } 1923 ] 1924 } 1925 }, 1927 "ietf-system:system-state": { 1928 "platform": { 1929 "os-name": "NetworkOS" 1930 } 1931 }, 1933 "ietf-yang-library:modules-state": { 1934 "module-set-id": "123e4567-e89b-12d3-a456-426655440000", 1935 "module": [ 1936 { 1937 "name": "iana-if-type", 1938 "revision": "2014-05-08", 1939 "namespace": 1940 "urn:ietf:params:xml:ns:yang:iana-if-type", 1941 "conformance-type": "import" 1942 }, 1943 { 1944 "name": "ietf-inet-types", 1945 "revision": "2013-07-15", 1946 "namespace": 1947 "urn:ietf:params:xml:ns:yang:ietf-inet-types", 1948 "conformance-type": "import" 1949 }, 1950 { 1951 "name": "ietf-interfaces", 1952 "revision": "2014-05-08", 1953 "feature": [ 1954 "arbitrary-names", 1955 "pre-provisioning" 1956 ], 1957 "namespace": 1958 "urn:ietf:params:xml:ns:yang:ietf-interfaces", 1959 "conformance-type": "implement" 1960 }, 1961 { 1962 "name": "ietf-ip", 1963 "revision": "2014-06-16", 1964 "namespace": 1965 "urn:ietf:params:xml:ns:yang:ietf-ip", 1966 "conformance-type": "implement" 1967 }, 1968 { 1969 "name": "ietf-logical-network-element", 1970 "revision": "2017-03-13", 1971 "feature": [ 1972 "bind-lne-name" 1973 ], 1974 "namespace": 1975 "urn:ietf:params:xml:ns:yang:ietf-logical-network-element", 1976 "conformance-type": "implement" 1977 }, 1978 { 1979 "name": "ietf-system", 1980 "revision": "2014-08-06", 1981 "namespace": 1982 "urn:ietf:params:xml:ns:yang:ietf-system", 1983 "conformance-type": "implement" 1984 }, 1985 { 1986 "name": "ietf-yang-library", 1987 "revision": "2016-06-21", 1988 "namespace": 1989 "urn:ietf:params:xml:ns:yang:ietf-yang-library", 1990 "conformance-type": "implement" 1991 }, 1992 { 1993 "name": "ietf-yang-schema-mount", 1994 "revision": "2017-05-16", 1995 "namespace": 1996 "urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount", 1997 "conformance-type": "implement" 1998 }, 1999 { 2000 "name": "ietf-yang-types", 2001 "revision": "2013-07-15", 2002 "namespace": 2003 "urn:ietf:params:xml:ns:yang:ietf-yang-types", 2004 "conformance-type": "import" 2005 } 2006 ] 2007 }, 2009 "ietf-yang-schema-mount:schema-mounts": { 2010 "mount-point": [ 2011 { 2012 "module": "ietf-logical-network-element", 2013 "label": "root", 2014 "inline": [null] 2015 } 2016 ] 2017 } 2018 } 2020 B.2.2.2. Logical Network Element 'vnf1' 2022 The following shows state data for the example LNE with name "vnf1": 2024 { 2025 "ietf-yang-library:modules-state": { 2026 "module-set-id": "123e4567-e89b-12d3-a456-426655440000", 2027 "module": [ 2028 { 2029 "name": "iana-if-type", 2030 "revision": "2014-05-08", 2031 "namespace": 2032 "urn:ietf:params:xml:ns:yang:iana-if-type", 2033 "conformance-type": "import" 2034 }, 2035 { 2036 "name": "ietf-inet-types", 2037 "revision": "2013-07-15", 2038 "namespace": 2039 "urn:ietf:params:xml:ns:yang:ietf-inet-types", 2040 "conformance-type": "import" 2041 }, 2042 { 2043 "name": "ietf-interfaces", 2044 "revision": "2014-05-08", 2045 "feature": [ 2046 "arbitrary-names", 2047 "pre-provisioning" 2048 ], 2049 "namespace": 2051 "urn:ietf:params:xml:ns:yang:ietf-interfaces", 2052 "conformance-type": "implement" 2053 }, 2054 { 2055 "name": "ietf-ip", 2056 "revision": "2014-06-16", 2057 "namespace": 2058 "urn:ietf:params:xml:ns:yang:ietf-ip", 2059 "conformance-type": "implement" 2060 }, 2061 { 2062 "name": "ietf-ospf", 2063 "revision": "2017-03-12", 2064 "namespace": 2065 "urn:ietf:params:xml:ns:yang:ietf-ospf", 2066 "conformance-type": "implement" 2067 }, 2068 { 2069 "name": "ietf-routing", 2070 "revision": "2016-11-04", 2071 "namespace": 2072 "urn:ietf:params:xml:ns:yang:ietf-routing", 2073 "conformance-type": "implement" 2074 }, 2075 { 2076 "name": "ietf-system", 2077 "revision": "2014-08-06", 2078 "namespace": 2079 "urn:ietf:params:xml:ns:yang:ietf-system", 2080 "conformance-type": "implement" 2081 }, 2082 { 2083 "name": "ietf-yang-library", 2084 "revision": "2016-06-21", 2085 "namespace": 2086 "urn:ietf:params:xml:ns:yang:ietf-yang-library", 2087 "conformance-type": "implement" 2088 }, 2089 { 2090 "name": "ietf-yang-types", 2091 "revision": "2013-07-15", 2092 "namespace": 2093 "urn:ietf:params:xml:ns:yang:ietf-yang-types", 2094 "conformance-type": "import" 2095 } 2096 ] 2097 }, 2098 "ietf-system:system-state": { 2099 "platform": { 2100 "os-name": "NetworkOS" 2101 } 2102 }, 2104 "ietf-routing:routing": { 2105 "router-id": "192.0.2.1", 2106 "control-plane-protocols": { 2107 "control-plane-protocol": [ 2108 { 2109 "type": "ietf-routing:ospf", 2110 "name": "1", 2111 "ietf-ospf:ospf": { 2112 "instance": [ 2113 { 2114 "af": "ipv4", 2115 "areas": { 2116 "area": [ 2117 { 2118 "area-id": "203.0.113.1", 2119 "interfaces": { 2120 "interface": [ 2121 { 2122 "name": "eth1", 2123 "cost": 10 2124 } 2125 ] 2126 } 2127 } 2128 ] 2129 } 2130 } 2131 ] 2132 } 2133 } 2134 ] 2135 } 2136 }, 2138 "ietf-interfaces:interfaces": { 2139 "interfaces": { 2140 "interface": [ 2141 { 2142 "name": "eth1", 2143 "type": "iana-if-type:ethernetCsmacd", 2144 "oper-status": "up", 2145 "phys-address": "00:01:02:A1:B1:C1", 2146 "statistics": { 2147 "discontinuity-time": "2017-06-26T12:34:56-05:00" 2148 }, 2149 "ip:ipv4": { 2150 "address": [ 2151 { 2152 "ip": "192.0.2.11", 2153 "prefix-length": 24, 2154 } 2155 ] 2156 } 2157 } 2158 ] 2159 } 2160 } 2161 } 2163 B.2.2.3. Logical Network Element 'vnf2' 2165 The following shows state data for the example LNE with name "vnf2": 2167 { 2168 "ietf-yang-library:modules-state": { 2169 "module-set-id": "123e4567-e89b-12d3-a456-426655440000", 2170 "module": [ 2171 { 2172 "name": "iana-if-type", 2173 "revision": "2014-05-08", 2174 "namespace": 2175 "urn:ietf:params:xml:ns:yang:iana-if-type", 2176 "conformance-type": "import" 2177 }, 2178 { 2179 "name": "ietf-inet-types", 2180 "revision": "2013-07-15", 2181 "namespace": 2182 "urn:ietf:params:xml:ns:yang:ietf-inet-types", 2183 "conformance-type": "import" 2184 }, 2185 { 2186 "name": "ietf-interfaces", 2187 "revision": "2014-05-08", 2188 "feature": [ 2189 "arbitrary-names", 2190 "pre-provisioning" 2191 ], 2192 "namespace": 2193 "urn:ietf:params:xml:ns:yang:ietf-interfaces", 2194 "conformance-type": "implement" 2195 }, 2196 { 2197 "name": "ietf-ip", 2198 "revision": "2014-06-16", 2199 "namespace": 2200 "urn:ietf:params:xml:ns:yang:ietf-ip", 2201 "conformance-type": "implement" 2202 }, 2203 { 2204 "name": "ietf-ospf", 2205 "revision": "2017-03-12", 2206 "namespace": 2207 "urn:ietf:params:xml:ns:yang:ietf-ospf", 2208 "conformance-type": "implement" 2209 }, 2210 { 2211 "name": "ietf-routing", 2212 "revision": "2016-11-04", 2213 "namespace": 2214 "urn:ietf:params:xml:ns:yang:ietf-routing", 2215 "conformance-type": "implement" 2216 }, 2217 { 2218 "name": "ietf-system", 2219 "revision": "2014-08-06", 2220 "namespace": 2221 "urn:ietf:params:xml:ns:yang:ietf-system", 2222 "conformance-type": "implement" 2223 }, 2224 { 2225 "name": "ietf-yang-library", 2226 "revision": "2016-06-21", 2227 "namespace": 2228 "urn:ietf:params:xml:ns:yang:ietf-yang-library", 2229 "conformance-type": "implement" 2230 }, 2231 { 2232 "name": "ietf-yang-types", 2233 "revision": "2013-07-15", 2234 "namespace": 2235 "urn:ietf:params:xml:ns:yang:ietf-yang-types", 2236 "conformance-type": "import" 2237 } 2238 ] 2239 }, 2241 "ietf-system:system-state": { 2242 "platform": { 2243 "os-name": "NetworkOS" 2244 } 2245 }, 2247 "ietf-routing:routing": { 2248 "router-id": "192.0.2.2", 2249 "control-plane-protocols": { 2250 "control-plane-protocol": [ 2251 { 2252 "type": "ietf-routing:ospf", 2253 "name": "1", 2254 "ietf-ospf:ospf": { 2255 "instance": [ 2256 { 2257 "af": "ipv4", 2258 "areas": { 2259 "area": [ 2260 { 2261 "area-id": "203.0.113.1", 2262 "interfaces": { 2263 "interface": [ 2264 { 2265 "name": "eth1", 2266 "cost": 10 2267 } 2268 ] 2269 } 2270 } 2271 ] 2272 } 2273 } 2274 ] 2275 } 2276 } 2277 ] 2278 } 2279 }, 2281 "ietf-interfaces:interfaces": { 2282 "interfaces": { 2283 "interface": [ 2284 { 2285 "name": "eth1", 2286 "type": "iana-if-type:ethernetCsmacd", 2287 "oper-status": "up", 2288 "phys-address": "00:01:02:A1:B1:C2", 2289 "statistics": { 2290 "discontinuity-time": "2017-06-26T12:34:56-05:00" 2291 }, 2292 "ip:ipv4": { 2293 "address": [ 2294 { 2295 "ip": "192.0.2.11", 2296 "prefix-length": 24, 2297 } 2298 ] 2299 } 2300 } 2301 ] 2302 } 2303 } 2304 } 2306 Authors' Addresses 2308 Lou Berger 2309 LabN Consulting, L.L.C. 2311 Email: lberger@labn.net 2313 Christan Hopps 2314 Deutsche Telekom 2316 Email: chopps@chopps.org 2318 Acee Lindem 2319 Cisco Systems 2320 301 Midenhall Way 2321 Cary, NC 27513 2322 USA 2324 Email: acee@cisco.com 2326 Dean Bogdanovic 2328 Email: ivandean@gmail.com 2330 Xufeng Liu 2331 Jabil 2333 Email: Xufeng_Liu@jabil.com