idnits 2.17.1 draft-ietf-rtgwg-lne-model-09.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 748 has weird spacing: '...-set-id str...' == Line 761 has weird spacing: '...gorithm str...' == Line 792 has weird spacing: '...-set-id str...' == Line 807 has weird spacing: '...gorithm str...' == Line 894 has weird spacing: '...-set-id str...' == (7 more instances...) -- The document date (March 1, 2018) is 2246 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-12) exists of draft-ietf-netmod-schema-mount-08 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) == Outdated reference: A later version (-12) exists of draft-ietf-rtgwg-ni-model-10 -- Obsolete informational reference (is this intentional?): RFC 7895 (Obsoleted by RFC 8525) Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Berger 3 Internet-Draft LabN Consulting, L.L.C. 4 Intended status: Standards Track C. Hopps 5 Expires: September 2, 2018 Deutsche Telekom 6 A. Lindem 7 Cisco Systems 8 D. Bogdanovic 10 X. Liu 11 Jabil 12 March 1, 2018 14 YANG Model for Logical Network Elements 15 draft-ietf-rtgwg-lne-model-09 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 September 2, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . 21 76 B.1.2. State Data . . . . . . . . . . . . . . . . . . . . . 25 77 B.2. Example: Self Managed LNE . . . . . . . . . . . . . . . . 35 78 B.2.1. Configuration Data . . . . . . . . . . . . . . . . . 38 79 B.2.2. State Data . . . . . . . . . . . . . . . . . . . . . 41 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50 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 interfaces to identify an associated LNE. 198 The interface related augmentation is as follows: 200 module: ietf-logical-network-element 201 augment /if:interfaces/if:interface: 202 +--rw bind-lne-name? -> 203 /logical-network-elements/logical-network-element/name 205 The interface model defined in [I-D.ietf-netmod-rfc7223bis] is 206 structured to include all interfaces in a flat list, without regard 207 to logical assignment of resources supported on the device. The 208 bind-lne-name and leaf provides the association between an interface 209 and its associated LNE. Note that as currently defined, to assign an 210 interface to both an LNE and NI, the interface would first be 211 assigned to the LNE and then within that LNE's interface module, the 212 LNE's representation of that interface would be assigned to an NI 213 using the mechanisms defined in [I-D.ietf-rtgwg-ni-model]. 215 3. Logical Network Elements 217 Logical network elements support the ability of some devices to 218 partition resources into independent logical routers and/or switches. 219 Device support for multiple logical network elements is 220 implementation specific. Systems without such capabilities need not 221 include support for the logical-network-element module. In physical 222 devices, some hardware features are shared across partitions, but 223 control plane (e.g., routing) protocol instances, tables, and 224 configuration are managed separately. For example, in logical 225 routers or VNFs, this may correspond to establishing multiple logical 226 instances using a single software installation. The model supports 227 configuration of multiple instances on a single device by creating a 228 list of logical network elements, each with their own configuration 229 and operational state related to routing and switching protocols. 231 The LNE model can be represented as: 233 module: ietf-logical-network-element 234 +--rw logical-network-elements 235 +--rw logical-network-element* [name] 236 +--rw name string 237 +--rw managed? boolean 238 +--rw description? string 239 +--mp root 240 augment /if:interfaces/if:interface: 241 +--rw bind-lne-name? 242 -> /logical-network-elements/logical-network-element/name 244 notifications: 245 +---n bind-lne-name-failed 246 +--ro name -> /if:interfaces/interface/name 247 +--ro bind-lne-name 248 | -> /if:interfaces/interface/lne:bind-lne-name 249 +--ro error-info? string 251 'name' identifies the logical network element. 'managed' indicates 252 if the server providing the host network device will provide the 253 client LNE information via the 'root' structure. The root of an 254 LNE's specific data is the schema mount point 'root'. bind-lne-name 255 is used to associated an interface with an LNE and bind-lne-name- 256 failed is used in certain failure cases. 258 An LNE root MUST contain at least the YANG library [RFC7895] and 259 Interfaces [I-D.ietf-netmod-rfc7223bis] modules. 261 3.1. LNE Instantiation and Resource Assignment 263 Logical network elements may be controlled by clients using existing 264 list operations. When list entries are created, a new LNE is 265 instantiated. The models mounted under an LNE root are expected to 266 be dependent on the server implementation. When a list entry is 267 deleted, an existing LNE is destroyed. For more information, see 268 [RFC7950] Section 7.8.6. 270 Once instantiated, host network device resources can be associated 271 with the new LNE. As previously mentioned, this document augments 272 ietf-interfaces with the bind-lne-name leaf to support such 273 associations for interfaces. When an bind-lne-name is set to a valid 274 LNE name, an implementation MUST take whatever steps are internally 275 necessary to assign the interface to the LNE or provide an error 276 message (defined below) with an indication of why the assignment 277 failed. It is possible for the assignment to fail while processing 278 the set, or after asynchronous processing. Error notification in the 279 latter case is supported via a notification. 281 On a successful interface assignment to an LNE, an implementation 282 MUST also make the resource available to the LNE by providing a 283 system created interface to the LNE. The name of the system created 284 interface is a local matter and may be identical or completely 285 different, and mapped from and to, the name used in the context of 286 the host device. The system created interface SHOULD be exposed via 287 the LNE-specific instance of the interfaces module 288 [I-D.ietf-netmod-rfc7223bis]. 290 3.2. LNE Management - LNE View 292 Each LNE instance is expected to support management functions from 293 within the context of the LNE root, via a server that provides 294 information with the LNE's root exposed as device root. Management 295 functions operating within the context of an LNE are accessed through 296 the LNE's standard management interfaces, e.g., NETCONF and SNMP. 297 Initial configuration, much like the initial configuration of the 298 host device, is a local implementation matter. 300 When accessing an LNE via the LNE's management interface, a network- 301 device representation will be presented, but its scope will be 302 limited to the specific LNE. Normal YANG/NETCONF mechanisms, 303 together with the required YANG library [RFC7895] instance, can be 304 used to identify the available modules. Each supported module will 305 be presented as a top level module. Only LNE associated resources 306 will be reflected in resource related modules, e.g., interfaces, 307 hardware, and perhaps QoS. From the management perspective, there 308 will be no difference between the available LNE view (information) 309 and a physical network device. 311 3.3. LNE Management - Host Network Device View 313 There are multiple implementation approaches possible to enable a 314 network device to support the logical-network-element module and 315 multiple LNEs. Some approaches will allow the management functions 316 operating at network device level to access LNE configuration and 317 operational information, while others will not. Similarly, even when 318 LNE management from the network device is supported by the 319 implementation, it may be prohibited by user policy. 321 Independent of the method selected by an implementation, the 322 'managed' boolean mentioned above is used to indicate when LNE 323 management from the network device context is possible. When the 324 'managed' boolean is 'false', the LNE cannot be managed by the host 325 system and can only be managed from within the context of the LNE as 326 described in the previous section, Section 3.2. Attempts to access 327 information below a root node whose associated 'managed' boolean is 328 set to 'false' MUST result in the error message indicated below. In 329 some implementations, it may not be possible to change this value. 330 For example, when an LNE is implemented using virtual machine and 331 traditional hypervisor technologies, it is likely that this value 332 will be restricted to a 'false' value. 334 It is an implementation choice if the information can be accessed and 335 modified from within the context of the LNE, or even the context of 336 the host device. When the 'managed' boolean is 'true', LNE 337 information SHALL be accessible from the context of the host device. 338 When the associated schema-mount definition has the 'config' leaf set 339 to 'true', then LNE information SHALL also be modifiable from the 340 context of the host device. When LNE information is available from 341 both the host device and from within the context of the LNE, the same 342 information MUST be made available via the 'root' element, with paths 343 modified as described in [I-D.ietf-netmod-schema-mount]. 345 An implementation MAY represent an LNE's schema using either the 346 'inline' or 'use-schema' approaches defined in 347 [I-D.ietf-netmod-schema-mount]. The choice of which to use is 348 completely an implementation choice. The inline case is anticipated 349 to be generally used in the cases where the 'managed' will always be 350 'false'. The 'use-schema' approach is expected to be be most useful 351 in the case where all LNEs share the same schema. When 'use-schema' 352 is used with an LNE mount point, the YANG library rooted in the LNE's 353 mount point MUST match the associated schema defined within the ietf- 354 yang-schema-mount module. 356 Beyond the two modules that will always be present for an LNE, as an 357 LNE is a network device itself, all modules that may be present at 358 the top level network device MAY also be present for the LNE. The 359 list of available modules is expected to be implementation dependent. 360 As is the method used by an implementation to support LNEs. 361 Appendix B provide example uses of LNEs. 363 4. Security Considerations 365 The YANG modules specified in this document define a schema for data 366 that is designed to be accessed via network management protocols such 367 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 368 is the secure transport layer, and the mandatory-to-implement secure 369 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 370 is HTTPS, and the mandatory-to-implement secure transport is TLS 371 [RFC5246]. 373 The NETCONF access control model [RFC6536] provides the means to 374 restrict access for particular NETCONF or RESTCONF users to a 375 preconfigured subset of all available NETCONF or RESTCONF protocol 376 operations and content. 378 LNE information represents device and network configuration 379 information. As such, the security of this information is important, 380 but it is fundamentally no different than any other interface or 381 device configuration information that has already been covered in 382 other documents such as [I-D.ietf-netmod-rfc7223bis], [RFC7317] and 383 [I-D.ietf-netmod-rfc8022bis]. 385 The vulnerable "config true" parameters and subtrees are the 386 following: 388 /logical-network-elements/logical-network-element: This list 389 specifies the logical network element and the related logical 390 device configuration. 392 /logical-network-elements/logical-network-element/managed: While 393 this leaf is contained in the previous list, it is worth 394 particular attention as it controls whether information under the 395 LNE mount point is accessible by both the host device and within 396 the LNE context. There may be extra sensitivity to this leaf in 397 environments where an LNE is managed by a different party than the 398 host device, and that party does not wish to share LNE information 399 with the operator of the host device. 401 /if:interfaces/if:interface/bind-lne-name: This leaf indicates the 402 LNE instance to which an interface is assigned. Implementations 403 should pay particular attention to when changes to this leaf are 404 permitted as removal of an interface from an LNE can have major 405 impact on the LNEs operation as it is similar to physically 406 removing an interface from the device. Implementations can reject 407 an reassignment using the previously described error message 408 generation. 410 Unauthorized access to any of these lists can adversely affect the 411 security of both the local device and the network. This may lead to 412 network malfunctions, delivery of packets to inappropriate 413 destinations, and other problems. 415 5. IANA Considerations 417 This document registers a URI in the IETF XML registry [RFC3688]. 418 Following the format in RFC 3688, the following registration is 419 requested to be made. 421 URI: urn:ietf:params:xml:ns:yang:ietf-logical-network-element 423 Registrant Contact: The IESG. 425 XML: N/A, the requested URI is an XML namespace. 427 This document registers a YANG module in the YANG Module Names 428 registry [RFC6020]. 430 name: ietf-logical-network-element 431 namespace: urn:ietf:params:xml:ns:yang:ietf-logical-network-element 432 prefix: lne 433 reference: RFC XXXX 435 6. Logical Network Element Model 437 The structure of the model defined in this document is described by 438 the YANG module below. 440 file "ietf-logical-network-element@2018-02-14.yang" 441 module ietf-logical-network-element { 442 yang-version 1.1; 444 // namespace 446 namespace 447 "urn:ietf:params:xml:ns:yang:ietf-logical-network-element"; 448 prefix lne; 450 // import some basic types 452 import ietf-interfaces { 453 prefix if; 454 reference "draft-ietf-netmod-rfc7223bis: 455 A YANG Data Model for Interface Management"; 456 } 457 import ietf-yang-schema-mount { 458 prefix yangmnt; 459 reference "draft-ietf-netmod-schema-mount: YANG Schema Mount"; 460 // RFC Ed.: Please replace this draft name with the corresponding 461 // RFC number 462 } 464 organization 465 "IETF Routing Area (rtgwg) Working Group"; 466 contact 467 "WG Web: 468 WG List: 470 Author: Lou Berger 471 472 Author: Christan Hopps 473 474 Author: Acee Lindem 475 476 Author: Dean Bogdanovic 477 "; 478 description 479 "This module is used to support multiple logical network 480 elements on a single physical or virtual system. 482 Copyright (c) 2017 IETF Trust and the persons 483 identified as authors of the code. All rights reserved. 485 Redistribution and use in source and binary forms, with or 486 without modification, is permitted pursuant to, and subject 487 to the license terms contained in, the Simplified BSD 488 License set forth in Section 4.c of the IETF Trust's Legal 489 Provisions Relating to IETF Documents 490 (http://trustee.ietf.org/license-info). 492 This version of this YANG module is part of RFC XXXX; see 493 the RFC itself for full legal notices."; 495 // RFC Ed.: replace XXXX with actual RFC number and remove 496 // this note 497 // RFC Ed.: please update TBD 499 revision 2018-02-14 { 500 description 501 "Initial revision."; 502 reference "RFC XXXX"; 503 } 505 // top level device definition statements 507 container logical-network-elements { 508 description 509 "Allows a network device to support multiple logical 510 network element (device) instances."; 511 list logical-network-element { 512 key "name"; 513 description 514 "List of logical network elements."; 515 leaf name { 516 type string; 517 description 518 "Device-wide unique identifier for the 519 logical network element."; 520 } 521 leaf managed { 522 type boolean; 523 default "true"; 524 description 525 "True if the host can access LNE information 526 using the root mount point. This value 527 my not be modifiable in all implementations."; 528 } 529 leaf description { 530 type string; 531 description 532 "Description of the logical network element."; 533 } 534 container "root" { 535 description 536 "Container for mount point."; 537 yangmnt:mount-point "root" { 538 description 539 "Root for models supported per logical 540 network element. This mount point may or may not 541 be inline based on the server implementation. It 542 SHALL always contain a YANG library and interfaces 543 instance. 545 When the associated 'managed' leaf is 'false' any 546 operation that attempts to access information below 547 the root SHALL fail with an error-tag of 548 'access-denied' and an error-app-tag of 549 'lne-not-managed'."; 550 } 551 } 552 } 553 } 555 // augment statements 557 augment "/if:interfaces/if:interface" { 558 description 559 "Add a node for the identification of the logical network 560 element associated with an interface. Applies to 561 interfaces that can be assigned on a per logical network 562 element basis. 564 Note that a standard error will be returned if the 565 identified leafref isn't present. If an interfaces 566 cannot be assigned for any other reason, the operation 567 SHALL fail with an error-tag of 'operation-failed' and an 568 error-app-tag of 'lne-assignment-failed'. A meaningful 569 error-info that indicates the source of the assignment 570 failure SHOULD also be provided."; 572 leaf bind-lne-name { 573 type leafref { 574 path 575 "/logical-network-elements/logical-network-element/name"; 576 } 577 description 578 "Logical network element ID to which interface is bound."; 579 } 580 } 582 // notification statements 584 notification bind-lne-name-failed { 585 description 586 "Indicates an error in the association of an interface to an 587 LNE. Only generated after success is initially returned when 588 bind-lne-name is set."; 589 leaf name { 590 type leafref { 591 path "/if:interfaces/if:interface/if:name"; 592 } 593 mandatory true; 594 description 595 "Contains the interface name associated with the 596 failure."; 597 } 598 leaf bind-lne-name { 599 type leafref { 600 path "/if:interfaces/if:interface/lne:bind-lne-name"; 601 } 602 mandatory true; 603 description 604 "Contains the bind-lne-name associated with the 605 failure."; 606 } 607 leaf error-info { 608 type string; 609 description 610 "Optionally, indicates the source of the assignment 611 failure."; 612 } 613 } 614 } 615 617 7. References 619 7.1. Normative References 621 [I-D.ietf-netmod-rfc7223bis] 622 Bjorklund, M., "A YANG Data Model for Interface 623 Management", draft-ietf-netmod-rfc7223bis-03 (work in 624 progress), January 2018. 626 [I-D.ietf-netmod-schema-mount] 627 Bjorklund, M. and L. Lhotka, "YANG Schema Mount", draft- 628 ietf-netmod-schema-mount-08 (work in progress), October 629 2017. 631 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 632 Requirement Levels", BCP 14, RFC 2119, 633 DOI 10.17487/RFC2119, March 1997, . 636 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 637 DOI 10.17487/RFC3688, January 2004, . 640 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 641 (TLS) Protocol Version 1.2", RFC 5246, 642 DOI 10.17487/RFC5246, August 2008, . 645 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 646 the Network Configuration Protocol (NETCONF)", RFC 6020, 647 DOI 10.17487/RFC6020, October 2010, . 650 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 651 and A. Bierman, Ed., "Network Configuration Protocol 652 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 653 . 655 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 656 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 657 . 659 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 660 Protocol (NETCONF) Access Control Model", RFC 6536, 661 DOI 10.17487/RFC6536, March 2012, . 664 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 665 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 666 . 668 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 669 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 670 May 2017, . 672 7.2. Informative References 674 [I-D.ietf-netmod-entity] 675 Bierman, A., Bjorklund, M., Dong, J., and D. Romascanu, "A 676 YANG Data Model for Hardware Management", draft-ietf- 677 netmod-entity-08 (work in progress), January 2018. 679 [I-D.ietf-netmod-rfc8022bis] 680 Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for 681 Routing Management (NMDA Version)", draft-ietf-netmod- 682 rfc8022bis-11 (work in progress), January 2018. 684 [I-D.ietf-netmod-yang-tree-diagrams] 685 Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft- 686 ietf-netmod-yang-tree-diagrams-06 (work in progress), 687 February 2018. 689 [I-D.ietf-rtgwg-device-model] 690 Lindem, A., Berger, L., Bogdanovic, D., and C. Hopps, 691 "Network Device YANG Logical Organization", draft-ietf- 692 rtgwg-device-model-02 (work in progress), March 2017. 694 [I-D.ietf-rtgwg-ni-model] 695 Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. 696 Liu, "YANG Model for Network Instances", draft-ietf-rtgwg- 697 ni-model-10 (work in progress), February 2018. 699 [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for 700 System Management", RFC 7317, DOI 10.17487/RFC7317, August 701 2014, . 703 [RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module 704 Library", RFC 7895, DOI 10.17487/RFC7895, June 2016, 705 . 707 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 708 RFC 7950, DOI 10.17487/RFC7950, August 2016, 709 . 711 Appendix A. Acknowledgments 712 The Routing Area Yang Architecture design team members included Acee 713 Lindem, Anees Shaikh, Christian Hopps, Dean Bogdanovic, Lou Berger, 714 Qin Wu, Rob Shakir, Stephane Litkowski, and Yan Gang. Useful review 715 comments were also received by Martin Bjorklund, John Scudder, Dan 716 Romascanu and Taylor Yu. 718 This document was motivated by, and derived from, 719 [I-D.ietf-rtgwg-device-model]. 721 The RFC text was produced using Marshall Rose's xml2rfc tool. 723 Thanks to Alvaro Retana for IESG review. 725 Appendix B. Examples 727 The following subsections provide example uses of LNEs. 729 B.1. Example: Host Device Managed LNE 731 This section describes an example of the LNE model using schema mount 732 to achieve the parent management. An example device supports 733 multiple instances of LNEs (logical routers), each of which supports 734 features of layer 2 and layer 3 interfaces 735 [I-D.ietf-netmod-rfc7223bis], routing information base 736 [I-D.ietf-netmod-rfc8022bis], and OSPF protocol. Each of these 737 features is specified by a YANG model, and they are combined using 738 YANG Schema Mount as shown below. Not all possible mounted modules 739 are shown. For example implementations could also mount the model 740 defined in [I-D.ietf-netmod-entity]. 742 module: ietf-logical-network-element 743 +--rw logical-network-elements 744 +--rw logical-network-element* [name] 745 +--rw name string 746 +--mp root 747 +--ro yanglib:modules-state/ 748 | +--ro module-set-id string 749 | +--ro module* [name revision] 750 | +--ro name yang:yang-identifier 751 +--rw sys:system/ 752 | +--rw contact? string 753 | +--rw hostname? inet:domain-name 754 | +--rw authentication {authentication}? 755 | +--rw user-authentication-order* identityref 756 | +--rw user* [name] {local-users}? 757 | +--rw name string 758 | +--rw password? ianach:crypt-hash 759 | +--rw authorized-key* [name] 760 | +--rw name string 761 | +--rw algorithm string 762 | +--rw key-data binary 763 +--ro sys:system-state/ 764 | ... 765 +--rw rt:routing/ 766 | +--rw router-id? yang:dotted-quad 767 | +--rw control-plane-protocols 768 | +--rw control-plane-protocol* [type name] 769 | +--rw ospf:ospf/ 770 | +--rw areas 771 | +--rw area* [area-id] 772 | +--rw interfaces 773 | +--rw interface* [name] 774 | +--rw name if:interface-ref 775 | +--rw cost? uint16 776 +--rw if:interfaces/ 777 +--rw interface* [name] 778 +--rw name string 779 +--rw ip:ipv4!/ 780 | +--rw address* [ip] 781 | ... 783 module: ietf-interfaces 784 +--rw interfaces 785 +--rw interface* [name] 786 +--rw name string 787 +--rw lne:bind-lne-name? string 788 +--ro oper-status enumeration 790 module: ietf-yang-library 791 +--ro modules-state 792 +--ro module-set-id string 793 +--ro module* [name revision] 794 +--ro name yang:yang-identifier 796 module: ietf-system 797 +--rw system 798 | +--rw contact? string 799 | +--rw hostname? inet:domain-name 800 | +--rw authentication {authentication}? 801 | +--rw user-authentication-order* identityref 802 | +--rw user* [name] {local-users}? 803 | +--rw name string 804 | +--rw password? ianach:crypt-hash 805 | +--rw authorized-key* [name] 806 | +--rw name string 807 | +--rw algorithm string 808 | +--rw key-data binary 809 +--ro system-state 810 +--ro platform 811 | +--ro os-name? string 812 | +--ro os-release? string 814 To realize the above schema, the example device implements the 815 following schema mount instance: 817 "ietf-yang-schema-mount:schema-mounts": { 818 "mount-point": [ 819 { 820 "module": "ietf-logical-network-element", 821 "label": "root", 822 "use-schema": [ 823 { 824 "name": "lne-schema" 825 } 826 ] 827 } 828 ], 829 "schema": [ 830 { 831 "name": "lne-schema", 832 "module": [ 833 { 834 "name": "ietf-yang-library", 835 "revision": "2016-06-21", 836 "namespace": 837 "urn:ietf:params:xml:ns:yang:ietf-yang-library", 838 "conformance-type": "implement" 839 }, 840 { 841 "name": "ietf-system", 842 "revision": "2014-08-06", 843 "namespace": 844 "urn:ietf:params:xml:ns:yang:ietf-system", 845 "conformance-type": "implement" 846 }, 847 { 848 "name": "ietf-routing", 849 "revision": "2016-11-04", 850 "namespace": 851 "urn:ietf:params:xml:ns:yang:ietf-routing", 852 "conformance-type": "implement" 853 }, 854 { 855 "name": "ietf-ospf", 856 "revision": "2017-03-12", 857 "namespace": 858 "urn:ietf:params:xml:ns:yang:ietf-ospf", 859 "conformance-type": "implement" 860 }, 861 { 862 "name": "ietf-interfaces", 863 "revision": "2014-05-08", 864 "namespace": 865 "urn:ietf:params:xml:ns:yang:ietf-interfaces", 866 "conformance-type": "implement" 868 }, 869 { 870 "name": "ietf-ip", 871 "revision": "2014-06-16", 872 "namespace": 873 "urn:ietf:params:xml:ns:yang:ietf-ip", 874 "conformance-type": "implement" 875 } 876 ] 877 } 878 ] 879 } 881 By using the implementation of the YANG schema mount, an operator can 882 create instances of logical routers. An interface can be assigned to 883 a logical router, so that the logical router has the permission to 884 access this interface. The OSPF protocol can then be enabled on this 885 assigned interface. 887 For this implementation, a parent management session has access to 888 the schemas of both the parent hosting system and the child logical 889 routers. In addition, each child logical router can grant its own 890 management sessions, which have the following schema: 892 module: ietf-yang-library 893 +--ro modules-state 894 +--ro module-set-id string 895 +--ro module* [name revision] 896 +--ro name yang:yang-identifier 898 module: ietf-system 899 +--rw system 900 | +--rw contact? string 901 | +--rw hostname? inet:domain-name 902 | +--rw authentication {authentication}? 903 | +--rw user-authentication-order* identityref 904 | +--rw user* [name] {local-users}? 905 | +--rw name string 906 | +--rw password? ianach:crypt-hash 907 | +--rw authorized-key* [name] 908 | +--rw name string 909 | +--rw algorithm string 910 | +--rw key-data binary 911 +--ro system-state 912 +--ro platform 913 +--ro os-name? string 914 +--ro os-release? string 916 module: ietf-routing 917 rw-- routing 918 +--rw router-id? yang:dotted-quad 919 +--rw control-plane-protocols 920 +--rw control-plane-protocol* [type name] 921 +--rw ospf:ospf/ 922 +--rw areas 923 +--rw area* [area-id] 924 +--rw interfaces 925 +--rw interface* [name] 926 +--rw name if:interface-ref 927 +--rw cost? uint16 929 module: ietf-interfaces 930 +--rw interfaces 931 +--rw interface* [name] 932 +--rw name string 933 +--ro oper-status enumeration 935 B.1.1. Configuration Data 937 The following shows an example where two customer specific LNEs are 938 configured: 940 { 941 "ietf-logical-network-element:logical-network-elements": { 942 "logical-network-element": [ 943 { 944 "name": "cust1", 945 "root": { 946 "ietf-system:system": { 947 "authentication": { 948 "user": [ 949 { 950 "name": "john", 951 "password": "$0$password" 952 } 953 ] 954 } 955 }, 956 "ietf-routing:routing": { 957 "router-id": "192.0.2.1", 958 "control-plane-protocols": { 959 "control-plane-protocol": [ 960 { 961 "type": "ietf-routing:ospf", 962 "name": "1", 963 "ietf-ospf:ospf": { 964 "af": "ipv4", 965 "areas": { 966 "area": [ 967 { 968 "area-id": "203.0.113.1", 969 "interfaces": { 970 "interface": [ 971 { 972 "name": "eth1", 973 "cost": 10 974 } 975 ] 976 } 977 } 978 ] 979 } 980 } 981 } 982 ] 983 } 984 }, 985 "ietf-interfaces:interfaces": { 986 "interfaces": { 987 "interface": [ 988 { 989 "name": "eth1", 990 "ip:ipv4": { 991 "address": [ 992 { 993 "ip": "192.0.2.11", 994 "prefix-length": 24, 995 } 996 ] 997 }, 998 "ip:ipv6": { 999 "address": [ 1000 { 1001 "ip": "2001:db8:0:2::11", 1002 "prefix-length": 64, 1003 } 1004 ] 1005 } 1006 } 1007 ] 1008 } 1009 } 1010 } 1011 }, 1012 { 1013 "name": "cust2", 1014 "root": { 1015 "ietf-system:system": { 1016 "authentication": { 1017 "user": [ 1018 { 1019 "name": "john", 1020 "password": "$0$password" 1021 } 1022 ] 1023 } 1024 } 1025 "ietf-routing:routing": { 1026 "router-id": "192.0.2.2", 1027 "control-plane-protocols": { 1028 "control-plane-protocol": [ 1029 { 1030 "type": "ietf-routing:ospf", 1031 "name": "1", 1032 "ietf-ospf:ospf": { 1033 "af": "ipv4", 1034 "areas": { 1035 "area": [ 1036 { 1037 "area-id": "203.0.113.1", 1038 "interfaces": { 1039 "interface": [ 1040 { 1041 "name": "eth1", 1042 "cost": 10 1043 } 1044 ] 1045 } 1046 } 1047 ] 1048 } 1049 } 1050 } 1051 ] 1052 } 1053 }, 1054 "ietf-interfaces:interfaces": { 1055 "interfaces": { 1056 { 1057 "name": "eth1", 1058 "ip:ipv4": { 1059 "address": [ 1060 { 1061 "ip": "192.0.2.11", 1062 "prefix-length": 24, 1063 } 1064 ] 1065 } 1066 } 1067 ] 1068 } 1069 } 1070 } 1071 ] 1072 }, 1074 "ietf-interfaces:interfaces": { 1075 "interfaces": { 1076 "interface": [ 1077 { 1078 "name": "eth0", 1079 "ip:ipv4": { 1080 "address": [ 1081 { 1082 "ip": "192.0.2.10", 1083 "prefix-length": 24, 1085 } 1086 ] 1087 }, 1088 "ip:ipv6": { 1089 "address": [ 1090 { 1091 "ip": "2001:db8:0:2::10", 1092 "prefix-length": 64, 1093 } 1094 ] 1095 } 1096 }, 1097 { 1098 "name": "cust1:eth1", 1099 "lne:bind-lne-name": "cust1" 1100 }, 1101 { 1102 "name": "cust2:eth1", 1103 "lne:bind-lne-name": "cust2" 1104 } 1105 ] 1106 } 1107 }, 1109 "ietf-system:system": { 1110 "authentication": { 1111 "user": [ 1112 { 1113 "name": "root", 1114 "password": "$0$password" 1115 } 1116 ] 1117 } 1118 } 1119 } 1121 B.1.2. State Data 1123 The following shows possible state data associated the above 1124 configuration data: 1126 { 1127 "ietf-logical-network-element:logical-network-elements": { 1128 "logical-network-element": [ 1129 { 1130 "name": "cust1", 1131 "root": { 1132 "ietf-yang-library:modules-state": { 1133 "module-set-id": "123e4567-e89b-12d3-a456-426655440000", 1134 "module": [ 1135 { 1136 "name": "iana-if-type", 1137 "revision": "2014-05-08", 1138 "namespace": 1139 "urn:ietf:params:xml:ns:yang:iana-if-type", 1140 "conformance-type": "import" 1141 }, 1142 { 1143 "name": "ietf-inet-types", 1144 "revision": "2013-07-15", 1145 "namespace": 1146 "urn:ietf:params:xml:ns:yang:ietf-inet-types", 1147 "conformance-type": "import" 1148 }, 1149 { 1150 "name": "ietf-interfaces", 1151 "revision": "2014-05-08", 1152 "feature": [ 1153 "arbitrary-names", 1154 "pre-provisioning" 1155 ], 1156 "namespace": 1157 "urn:ietf:params:xml:ns:yang:ietf-interfaces", 1158 "conformance-type": "implement" 1159 }, 1160 { 1161 "name": "ietf-ip", 1162 "revision": "2014-06-16", 1163 "namespace": 1164 "urn:ietf:params:xml:ns:yang:ietf-ip", 1165 "conformance-type": "implement" 1166 }, 1167 { 1168 "name": "ietf-ospf", 1169 "revision": "2017-03-12", 1170 "namespace": 1171 "urn:ietf:params:xml:ns:yang:ietf-ospf", 1172 "conformance-type": "implement" 1173 }, 1174 { 1175 "name": "ietf-routing", 1176 "revision": "2016-11-04", 1177 "namespace": 1178 "urn:ietf:params:xml:ns:yang:ietf-routing", 1179 "conformance-type": "implement" 1180 }, 1181 { 1182 "name": "ietf-system", 1183 "revision": "2014-08-06", 1184 "namespace": 1185 "urn:ietf:params:xml:ns:yang:ietf-system", 1186 "conformance-type": "implement" 1187 }, 1188 { 1189 "name": "ietf-yang-library", 1190 "revision": "2016-06-21", 1191 "namespace": 1192 "urn:ietf:params:xml:ns:yang:ietf-yang-library", 1193 "conformance-type": "implement" 1194 }, 1195 { 1196 "name": "ietf-yang-types", 1197 "revision": "2013-07-15", 1198 "namespace": 1199 "urn:ietf:params:xml:ns:yang:ietf-yang-types", 1200 "conformance-type": "import" 1201 } 1202 ] 1203 } 1204 "ietf-system:system-state": { 1205 "ietf-system:system-state": { 1206 "platform": { 1207 "os-name": "NetworkOS" 1208 } 1209 } 1210 }, 1211 "ietf-routing:routing": { 1212 "router-id": "192.0.2.1", 1213 "control-plane-protocols": { 1214 "control-plane-protocol": [ 1215 { 1216 "type": "ietf-routing:ospf", 1217 "name": "1", 1218 "ietf-ospf:ospf": { 1219 "af": "ipv4", 1220 "areas": { 1221 "area": [ 1222 { 1223 "area-id": "203.0.113.1", 1224 "interfaces": { 1225 "interface": [ 1226 { 1227 "name": "eth1", 1228 "cost": 10 1230 } 1231 ] 1232 } 1233 } 1234 ] 1235 } 1236 } 1237 } 1238 ] 1239 } 1240 }, 1241 "ietf-interfaces:interfaces": { 1242 "interfaces": { 1243 "interface": [ 1244 { 1245 "name": "eth1", 1246 "type": "iana-if-type:ethernetCsmacd", 1247 "oper-status": "up", 1248 "phys-address": "00:01:02:A1:B1:C1", 1249 "statistics": { 1250 "discontinuity-time": "2017-06-26T12:34:56-05:00" 1251 }, 1252 "ip:ipv4": { 1253 "address": [ 1254 { 1255 "ip": "192.0.2.11", 1256 "prefix-length": 24, 1257 } 1258 ] 1259 } 1260 } 1261 ] 1262 } 1263 } 1264 } 1265 }, 1266 { 1267 "name": "cust2", 1268 "root": { 1269 "ietf-yang-library:modules-state": { 1270 "module-set-id": "123e4567-e89b-12d3-a456-426655440000", 1271 "module": [ 1272 { 1273 "name": "iana-if-type", 1274 "revision": "2014-05-08", 1275 "namespace": 1276 "urn:ietf:params:xml:ns:yang:iana-if-type", 1277 "conformance-type": "import" 1279 }, 1280 { 1281 "name": "ietf-inet-types", 1282 "revision": "2013-07-15", 1283 "namespace": 1284 "urn:ietf:params:xml:ns:yang:ietf-inet-types", 1285 "conformance-type": "import" 1286 }, 1287 { 1288 "name": "ietf-interfaces", 1289 "revision": "2014-05-08", 1290 "feature": [ 1291 "arbitrary-names", 1292 "pre-provisioning" 1293 ], 1294 "namespace": 1295 "urn:ietf:params:xml:ns:yang:ietf-interfaces", 1296 "conformance-type": "implement" 1297 }, 1298 { 1299 "name": "ietf-ip", 1300 "revision": "2014-06-16", 1301 "namespace": 1302 "urn:ietf:params:xml:ns:yang:ietf-ip", 1303 "conformance-type": "implement" 1304 }, 1305 { 1306 "name": "ietf-ospf", 1307 "revision": "2017-03-12", 1308 "namespace": 1309 "urn:ietf:params:xml:ns:yang:ietf-ospf", 1310 "conformance-type": "implement" 1311 }, 1312 { 1313 "name": "ietf-routing", 1314 "revision": "2016-11-04", 1315 "namespace": 1316 "urn:ietf:params:xml:ns:yang:ietf-routing", 1317 "conformance-type": "implement" 1318 }, 1319 { 1320 "name": "ietf-system", 1321 "revision": "2014-08-06", 1322 "namespace": 1323 "urn:ietf:params:xml:ns:yang:ietf-system", 1324 "conformance-type": "implement" 1325 }, 1326 { 1327 "name": "ietf-yang-library", 1328 "revision": "2016-06-21", 1329 "namespace": 1330 "urn:ietf:params:xml:ns:yang:ietf-yang-library", 1331 "conformance-type": "implement" 1332 }, 1333 { 1334 "name": "ietf-yang-types", 1335 "revision": "2013-07-15", 1336 "namespace": 1337 "urn:ietf:params:xml:ns:yang:ietf-yang-types", 1338 "conformance-type": "import" 1339 } 1340 ] 1341 } 1342 "ietf-system:system-state": { 1343 "ietf-system:system-state": { 1344 "platform": { 1345 "os-name": "NetworkOS" 1346 } 1347 } 1348 }, 1349 "ietf-routing:routing": { 1350 "router-id": "192.0.2.2", 1351 "control-plane-protocols": { 1352 "control-plane-protocol": [ 1353 { 1354 "type": "ietf-routing:ospf", 1355 "name": "1", 1356 "ietf-ospf:ospf": { 1357 "af": "ipv4", 1358 "areas": { 1359 "area": [ 1360 { 1361 "area-id": "203.0.113.1", 1362 "interfaces": { 1363 "interface": [ 1364 { 1365 "name": "eth1", 1366 "cost": 10 1367 } 1368 ] 1369 } 1370 } 1371 ] 1372 } 1373 } 1374 } 1376 ] 1377 } 1378 } 1379 "ietf-interfaces:interfaces": { 1380 "interfaces": { 1381 { 1382 "name": "eth1", 1383 "type": "iana-if-type:ethernetCsmacd", 1384 "oper-status": "up", 1385 "phys-address": "00:01:02:A1:B1:C2", 1386 "statistics": { 1387 "discontinuity-time": "2017-06-26T12:34:56-05:00" 1388 }, 1389 "ip:ipv4": { 1390 "address": [ 1391 { 1392 "ip": "192.0.2.11", 1393 "prefix-length": 24, 1394 } 1395 ] 1396 } 1397 } 1398 ] 1399 } 1400 } 1401 } 1402 ] 1403 }, 1405 "ietf-interfaces:interfaces": { 1406 "interfaces": { 1407 "interface": [ 1408 { 1409 "name": "eth0", 1410 "type": "iana-if-type:ethernetCsmacd", 1411 "oper-status": "up", 1412 "phys-address": "00:01:02:A1:B1:C0", 1413 "statistics": { 1414 "discontinuity-time": "2017-06-26T12:34:56-05:00" 1415 }, 1416 "ip:ipv4": { 1417 "address": [ 1418 { 1419 "ip": "192.0.2.10", 1420 "prefix-length": 24, 1421 } 1422 ] 1423 } 1425 }, 1426 { 1427 "name": "cust1:eth1", 1428 "type": "iana-if-type:ethernetCsmacd", 1429 "oper-status": "up", 1430 "phys-address": "00:01:02:A1:B1:C1", 1431 "statistics": { 1432 "discontinuity-time": "2017-06-26T12:34:56-05:00" 1433 } 1434 }, 1435 { 1436 "name": "cust2:eth1", 1437 "type": "iana-if-type:ethernetCsmacd", 1438 "oper-status": "up", 1439 "phys-address": "00:01:02:A1:B1:C2", 1440 "statistics": { 1441 "discontinuity-time": "2017-06-26T12:34:56-05:00" 1442 } 1443 } 1444 ] 1445 } 1446 }, 1448 "ietf-system:system-state": { 1449 "platform": { 1450 "os-name": "NetworkOS" 1451 } 1452 }, 1454 "ietf-yang-library:modules-state": { 1455 "module-set-id": "123e4567-e89b-12d3-a456-426655440000", 1456 "module": [ 1457 { 1458 "name": "iana-if-type", 1459 "revision": "2014-05-08", 1460 "namespace": 1461 "urn:ietf:params:xml:ns:yang:iana-if-type", 1462 "conformance-type": "import" 1463 }, 1464 { 1465 "name": "ietf-inet-types", 1466 "revision": "2013-07-15", 1467 "namespace": 1468 "urn:ietf:params:xml:ns:yang:ietf-inet-types", 1469 "conformance-type": "import" 1470 }, 1471 { 1472 "name": "ietf-interfaces", 1473 "revision": "2014-05-08", 1474 "feature": [ 1475 "arbitrary-names", 1476 "pre-provisioning" 1477 ], 1478 "namespace": 1479 "urn:ietf:params:xml:ns:yang:ietf-interfaces", 1480 "conformance-type": "implement" 1481 }, 1482 { 1483 "name": "ietf-ip", 1484 "revision": "2014-06-16", 1485 "namespace": 1486 "urn:ietf:params:xml:ns:yang:ietf-ip", 1487 "conformance-type": "implement" 1488 }, 1489 { 1490 "name": "ietf-logical-network-element", 1491 "revision": "2017-03-13", 1492 "feature": [ 1493 "bind-lne-name" 1494 ], 1495 "namespace": 1496 "urn:ietf:params:xml:ns:yang:ietf-logical-network-element", 1497 "conformance-type": "implement" 1498 }, 1499 { 1500 "name": "ietf-ospf", 1501 "revision": "2017-03-12", 1502 "namespace": 1503 "urn:ietf:params:xml:ns:yang:ietf-ospf", 1504 "conformance-type": "implement" 1505 }, 1506 { 1507 "name": "ietf-routing", 1508 "revision": "2016-11-04", 1509 "namespace": 1510 "urn:ietf:params:xml:ns:yang:ietf-routing", 1511 "conformance-type": "implement" 1512 }, 1513 { 1514 "name": "ietf-system", 1515 "revision": "2014-08-06", 1516 "namespace": 1517 "urn:ietf:params:xml:ns:yang:ietf-system", 1518 "conformance-type": "implement" 1519 }, 1520 { 1521 "name": "ietf-yang-library", 1522 "revision": "2016-06-21", 1523 "namespace": 1524 "urn:ietf:params:xml:ns:yang:ietf-yang-library", 1525 "conformance-type": "implement" 1526 }, 1527 { 1528 "name": "ietf-yang-schema-mount", 1529 "revision": "2017-05-16", 1530 "namespace": 1531 "urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount", 1532 "conformance-type": "implement" 1533 }, 1534 { 1535 "name": "ietf-yang-types", 1536 "revision": "2013-07-15", 1537 "namespace": 1538 "urn:ietf:params:xml:ns:yang:ietf-yang-types", 1539 "conformance-type": "import" 1540 } 1541 ] 1542 }, 1544 "ietf-yang-schema-mount:schema-mounts": { 1545 "mount-point": [ 1546 { 1547 "module": "ietf-logical-network-element", 1548 "label": "root", 1549 "use-schema": [ 1550 { 1551 "name": "lne-schema" 1552 } 1553 ] 1554 } 1555 ], 1556 "schema": [ 1557 { 1558 "name": "lne-schema", 1559 "module": [ 1560 { 1561 "name": "ietf-yang-library", 1562 "revision": "2016-06-21", 1563 "namespace": 1564 "urn:ietf:params:xml:ns:yang:ietf-yang-library", 1565 "conformance-type": "implement" 1566 }, 1567 { 1568 "name": "ietf-system", 1569 "revision": "2014-08-06", 1570 "namespace": 1571 "urn:ietf:params:xml:ns:yang:ietf-system", 1572 "conformance-type": "implement" 1573 }, 1574 { 1575 "name": "ietf-routing", 1576 "revision": "2016-11-04", 1577 "namespace": 1578 "urn:ietf:params:xml:ns:yang:ietf-routing", 1579 "conformance-type": "implement" 1580 }, 1581 { 1582 "name": "ietf-ospf", 1583 "revision": "2017-03-12", 1584 "namespace": 1585 "urn:ietf:params:xml:ns:yang:ietf-ospf", 1586 "conformance-type": "implement" 1587 }, 1588 { 1589 "name": "ietf-interfaces", 1590 "revision": "2014-05-08", 1591 "namespace": 1592 "urn:ietf:params:xml:ns:yang:ietf-interfaces", 1593 "conformance-type": "implement" 1594 }, 1595 { 1596 "name": "ietf-ip", 1597 "revision": "2014-06-16", 1598 "namespace": 1599 "urn:ietf:params:xml:ns:yang:ietf-ip", 1600 "conformance-type": "implement" 1601 } 1602 ] 1603 } 1604 ] 1605 } 1606 } 1608 B.2. Example: Self Managed LNE 1610 This section describes an example of the LNE model using schema mount 1611 to achieve child independent management. An example device supports 1612 multiple instances of LNEs (logical routers), each of them has the 1613 features of layer 2 and layer 3 interfaces 1614 [I-D.ietf-netmod-rfc7223bis], routing information base 1615 [I-D.ietf-netmod-rfc8022bis], and the OSPF protocol. Each of these 1616 features is specified by a YANG model, and they are put together by 1617 the YANG Schema Mount as following: 1619 module: ietf-logical-network-element 1620 +--rw logical-network-elements 1621 +--rw logical-network-element* [name] 1622 +--rw name string 1623 +--mp root 1624 // The internal modules of the LNE are not visible to 1625 // the parament management. 1626 // The child manages its modules, including ietf-routing 1627 // and ietf-interfaces 1629 module: ietf-interfaces 1630 +--rw interfaces 1631 +--rw interface* [name] 1632 +--rw name string 1633 +--rw lne:bind-lne-name? string 1634 +--ro oper-status enumeration 1636 module: ietf-yang-library 1637 +--ro modules-state 1638 +--ro module-set-id string 1639 +--ro module* [name revision] 1640 +--ro name yang:yang-identifier 1642 module: ietf-system 1643 +--rw system 1644 | +--rw contact? string 1645 | +--rw hostname? inet:domain-name 1646 | +--rw authentication {authentication}? 1647 | +--rw user-authentication-order* identityref 1648 | +--rw user* [name] {local-users}? 1649 | +--rw name string 1650 | +--rw password? ianach:crypt-hash 1651 | +--rw authorized-key* [name] 1652 | +--rw name string 1653 | +--rw algorithm string 1654 | +--rw key-data binary 1655 +--ro system-state 1656 +--ro platform 1657 | +--ro os-name? string 1658 | +--ro os-release? string 1660 To realize the above schema, the device implements the following 1661 schema mount instance: 1663 "ietf-yang-schema-mount:schema-mounts": { 1664 "mount-point": [ 1665 { 1666 "module": "ietf-logical-network-element", 1667 "label": "root", 1668 "inline": [null] 1669 } 1670 ] 1671 } 1673 By using the implementation of the YANG schema mount, an operator can 1674 create instances of logical routers, each with their logical router 1675 specific in-line modules. An interface can be assigned to a logical 1676 router, so that the logical router has the permission to access this 1677 interface. The OSPF protocol can then be enabled on this assigned 1678 interface. Each logical router independently manages its own set of 1679 modules, which may or may not be the same as other logical routers. 1680 The following is an example of schema set implemented on one 1681 particular logical router: 1683 module: ietf-yang-library 1684 +--ro modules-state 1685 +--ro module-set-id string 1686 +--ro module* [name revision] 1687 +--ro name yang:yang-identifier 1689 module: ietf-system 1690 +--rw system 1691 | +--rw contact? string 1692 | +--rw hostname? inet:domain-name 1693 | +--rw authentication {authentication}? 1694 | +--rw user-authentication-order* identityref 1695 | +--rw user* [name] {local-users}? 1696 | +--rw name string 1697 | +--rw password? ianach:crypt-hash 1698 | +--rw authorized-key* [name] 1699 | +--rw name string 1700 | +--rw algorithm string 1701 | +--rw key-data binary 1702 +--ro system-state 1703 +--ro platform 1704 | +--ro os-name? string 1705 | +--ro os-release? string 1707 module: ietf-routing 1708 +--rw routing 1709 +--rw router-id? yang:dotted-quad 1710 +--rw control-plane-protocols 1711 +--rw control-plane-protocol* [type name] 1712 +--rw ospf:ospf/ 1713 +--rw areas 1714 +--rw area* [area-id] 1715 +--rw interfaces 1716 +--rw interface* [name] 1717 +--rw name if:interface-ref 1718 +--rw cost? uint16 1720 module: ietf-interfaces 1721 +--rw interfaces 1722 +--rw interface* [name] 1723 +--rw name string 1724 +--ro oper-status enumeration 1726 B.2.1. Configuration Data 1728 Each of the child virtual routers is managed through its own sessions 1729 and configuration data. 1731 B.2.1.1. Logical Network Element 'vnf1' 1733 The following shows an example configuration data for the LNE name 1734 "vnf1": 1736 { 1737 "ietf-system:system": { 1738 "authentication": { 1739 "user": [ 1740 { 1741 "name": "john", 1742 "password": "$0$password" 1743 } 1744 ] 1745 } 1746 }, 1747 "ietf-routing:routing": { 1748 "router-id": "192.0.2.1", 1749 "control-plane-protocols": { 1750 "control-plane-protocol": [ 1751 { 1752 "type": "ietf-routing:ospf", 1753 "name": "1", 1754 "ietf-ospf:ospf": { 1755 "af": "ipv4", 1756 "areas": { 1757 "area": [ 1758 { 1759 "area-id": "203.0.113.1", 1760 "interfaces": { 1761 "interface": [ 1762 { 1763 "name": "eth1", 1764 "cost": 10 1765 } 1766 ] 1767 } 1768 } 1769 ] 1770 } 1771 } 1772 } 1773 ] 1774 } 1775 }, 1776 "ietf-interfaces:interfaces": { 1777 "interfaces": { 1778 "interface": [ 1779 { 1780 "name": "eth1", 1781 "ip:ipv4": { 1782 "address": [ 1783 { 1784 "ip": "192.0.2.11", 1785 "prefix-length": 24, 1786 } 1787 ] 1788 } 1789 } 1790 ] 1791 } 1792 } 1793 } 1795 B.2.1.2. Logical Network Element 'vnf2' 1797 The following shows an example configuration data for the LNE name 1798 "vnf2": 1800 { 1801 "ietf-system:system": { 1802 "authentication": { 1803 "user": [ 1804 { 1805 "name": "john", 1806 "password": "$0$password" 1807 } 1808 ] 1809 } 1810 }, 1811 "ietf-routing:routing": { 1812 "router-id": "192.0.2.2", 1813 "control-plane-protocols": { 1814 "control-plane-protocol": [ 1815 { 1816 "type": "ietf-routing:ospf", 1817 "name": "1", 1818 "ietf-ospf:ospf": { 1819 "af": "ipv4", 1820 "areas": { 1821 "area": [ 1822 { 1823 "area-id": "203.0.113.1", 1824 "interfaces": { 1825 "interface": [ 1826 { 1827 "name": "eth1", 1828 "cost": 10 1829 } 1830 ] 1831 } 1832 } 1833 ] 1834 } 1835 } 1836 } 1837 ] 1838 } 1839 }, 1840 "ietf-interfaces:interfaces": { 1841 "interfaces": { 1842 "interface": [ 1843 { 1844 "name": "eth1", 1845 "ip:ipv4": { 1846 "address": [ 1847 { 1848 "ip": "192.0.2.11", 1849 "prefix-length": 24, 1850 } 1851 ] 1852 } 1853 } 1854 ] 1855 } 1856 } 1857 } 1859 B.2.2. State Data 1861 The following sections shows possible state data associated the above 1862 configuration data. Note that there are three views: the host 1863 device's, and each LNE's. 1865 B.2.2.1. Host Device 1867 The following shows state data for the device hosting the example 1868 LNEs: 1870 { 1871 "ietf-logical-network-element:logical-network-elements": { 1872 "logical-network-element": [ 1873 { 1874 "name": "vnf1", 1875 "root": { 1876 } 1877 }, 1878 { 1879 "name": "vnf2", 1880 "root": { 1881 } 1882 } 1883 ] 1884 }, 1886 "ietf-interfaces:interfaces": { 1887 "interfaces": { 1888 "interface": [ 1889 { 1890 "name": "eth0", 1891 "type": "iana-if-type:ethernetCsmacd", 1892 "oper-status": "up", 1893 "phys-address": "00:01:02:A1:B1:C0", 1894 "statistics": { 1895 "discontinuity-time": "2017-06-26T12:34:56-05:00" 1896 }, 1897 "ip:ipv4": { 1898 "address": [ 1899 { 1900 "ip": "192.0.2.10", 1901 "prefix-length": 24, 1902 } 1903 ] 1904 } 1905 }, 1906 { 1907 "name": "vnf1:eth1", 1908 "type": "iana-if-type:ethernetCsmacd", 1909 "oper-status": "up", 1910 "phys-address": "00:01:02:A1:B1:C1", 1911 "statistics": { 1912 "discontinuity-time": "2017-06-26T12:34:56-05:00" 1913 } 1914 }, 1915 { 1916 "name": "vnf2:eth2", 1917 "type": "iana-if-type:ethernetCsmacd", 1918 "oper-status": "up", 1919 "phys-address": "00:01:02:A1:B1:C2", 1920 "statistics": { 1921 "discontinuity-time": "2017-06-26T12:34:56-05:00" 1922 } 1924 } 1925 ] 1926 } 1927 }, 1929 "ietf-system:system-state": { 1930 "platform": { 1931 "os-name": "NetworkOS" 1932 } 1933 }, 1935 "ietf-yang-library:modules-state": { 1936 "module-set-id": "123e4567-e89b-12d3-a456-426655440000", 1937 "module": [ 1938 { 1939 "name": "iana-if-type", 1940 "revision": "2014-05-08", 1941 "namespace": 1942 "urn:ietf:params:xml:ns:yang:iana-if-type", 1943 "conformance-type": "import" 1944 }, 1945 { 1946 "name": "ietf-inet-types", 1947 "revision": "2013-07-15", 1948 "namespace": 1949 "urn:ietf:params:xml:ns:yang:ietf-inet-types", 1950 "conformance-type": "import" 1951 }, 1952 { 1953 "name": "ietf-interfaces", 1954 "revision": "2014-05-08", 1955 "feature": [ 1956 "arbitrary-names", 1957 "pre-provisioning" 1958 ], 1959 "namespace": 1960 "urn:ietf:params:xml:ns:yang:ietf-interfaces", 1961 "conformance-type": "implement" 1962 }, 1963 { 1964 "name": "ietf-ip", 1965 "revision": "2014-06-16", 1966 "namespace": 1967 "urn:ietf:params:xml:ns:yang:ietf-ip", 1968 "conformance-type": "implement" 1969 }, 1970 { 1971 "name": "ietf-logical-network-element", 1972 "revision": "2017-03-13", 1973 "feature": [ 1974 "bind-lne-name" 1975 ], 1976 "namespace": 1977 "urn:ietf:params:xml:ns:yang:ietf-logical-network-element", 1978 "conformance-type": "implement" 1979 }, 1980 { 1981 "name": "ietf-system", 1982 "revision": "2014-08-06", 1983 "namespace": 1984 "urn:ietf:params:xml:ns:yang:ietf-system", 1985 "conformance-type": "implement" 1986 }, 1987 { 1988 "name": "ietf-yang-library", 1989 "revision": "2016-06-21", 1990 "namespace": 1991 "urn:ietf:params:xml:ns:yang:ietf-yang-library", 1992 "conformance-type": "implement" 1993 }, 1994 { 1995 "name": "ietf-yang-schema-mount", 1996 "revision": "2017-05-16", 1997 "namespace": 1998 "urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount", 1999 "conformance-type": "implement" 2000 }, 2001 { 2002 "name": "ietf-yang-types", 2003 "revision": "2013-07-15", 2004 "namespace": 2005 "urn:ietf:params:xml:ns:yang:ietf-yang-types", 2006 "conformance-type": "import" 2007 } 2008 ] 2009 }, 2011 "ietf-yang-schema-mount:schema-mounts": { 2012 "mount-point": [ 2013 { 2014 "module": "ietf-logical-network-element", 2015 "label": "root", 2016 "inline": [null] 2017 } 2018 ] 2019 } 2021 } 2023 B.2.2.2. Logical Network Element 'vnf1' 2025 The following shows state data for the example LNE with name "vnf1": 2027 { 2028 "ietf-yang-library:modules-state": { 2029 "module-set-id": "123e4567-e89b-12d3-a456-426655440000", 2030 "module": [ 2031 { 2032 "name": "iana-if-type", 2033 "revision": "2014-05-08", 2034 "namespace": 2035 "urn:ietf:params:xml:ns:yang:iana-if-type", 2036 "conformance-type": "import" 2037 }, 2038 { 2039 "name": "ietf-inet-types", 2040 "revision": "2013-07-15", 2041 "namespace": 2042 "urn:ietf:params:xml:ns:yang:ietf-inet-types", 2043 "conformance-type": "import" 2044 }, 2045 { 2046 "name": "ietf-interfaces", 2047 "revision": "2014-05-08", 2048 "feature": [ 2049 "arbitrary-names", 2050 "pre-provisioning" 2051 ], 2052 "namespace": 2053 "urn:ietf:params:xml:ns:yang:ietf-interfaces", 2054 "conformance-type": "implement" 2055 }, 2056 { 2057 "name": "ietf-ip", 2058 "revision": "2014-06-16", 2059 "namespace": 2060 "urn:ietf:params:xml:ns:yang:ietf-ip", 2061 "conformance-type": "implement" 2062 }, 2063 { 2064 "name": "ietf-ospf", 2065 "revision": "2017-03-12", 2066 "namespace": 2067 "urn:ietf:params:xml:ns:yang:ietf-ospf", 2068 "conformance-type": "implement" 2070 }, 2071 { 2072 "name": "ietf-routing", 2073 "revision": "2016-11-04", 2074 "namespace": 2075 "urn:ietf:params:xml:ns:yang:ietf-routing", 2076 "conformance-type": "implement" 2077 }, 2078 { 2079 "name": "ietf-system", 2080 "revision": "2014-08-06", 2081 "namespace": 2082 "urn:ietf:params:xml:ns:yang:ietf-system", 2083 "conformance-type": "implement" 2084 }, 2085 { 2086 "name": "ietf-yang-library", 2087 "revision": "2016-06-21", 2088 "namespace": 2089 "urn:ietf:params:xml:ns:yang:ietf-yang-library", 2090 "conformance-type": "implement" 2091 }, 2092 { 2093 "name": "ietf-yang-types", 2094 "revision": "2013-07-15", 2095 "namespace": 2096 "urn:ietf:params:xml:ns:yang:ietf-yang-types", 2097 "conformance-type": "import" 2098 } 2099 ] 2100 }, 2102 "ietf-system:system-state": { 2103 "platform": { 2104 "os-name": "NetworkOS" 2105 } 2106 }, 2108 "ietf-routing:routing": { 2109 "router-id": "192.0.2.1", 2110 "control-plane-protocols": { 2111 "control-plane-protocol": [ 2112 { 2113 "type": "ietf-routing:ospf", 2114 "name": "1", 2115 "ietf-ospf:ospf": { 2116 "af": "ipv4", 2117 "areas": { 2118 "area": [ 2119 { 2120 "area-id": "203.0.113.1", 2121 "interfaces": { 2122 "interface": [ 2123 { 2124 "name": "eth1", 2125 "cost": 10 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 "af": "ipv4", 2256 "areas": { 2257 "area": [ 2258 { 2259 "area-id": "203.0.113.1", 2260 "interfaces": { 2261 "interface": [ 2262 { 2263 "name": "eth1", 2264 "cost": 10 2265 } 2266 ] 2267 } 2268 } 2269 ] 2270 } 2271 } 2272 } 2273 ] 2274 } 2275 }, 2277 "ietf-interfaces:interfaces": { 2278 "interfaces": { 2279 "interface": [ 2280 { 2281 "name": "eth1", 2282 "type": "iana-if-type:ethernetCsmacd", 2283 "oper-status": "up", 2284 "phys-address": "00:01:02:A1:B1:C2", 2285 "statistics": { 2286 "discontinuity-time": "2017-06-26T12:34:56-05:00" 2287 }, 2288 "ip:ipv4": { 2289 "address": [ 2290 { 2291 "ip": "192.0.2.11", 2292 "prefix-length": 24, 2293 } 2294 ] 2295 } 2296 } 2297 ] 2298 } 2299 } 2300 } 2302 Authors' Addresses 2303 Lou Berger 2304 LabN Consulting, L.L.C. 2306 Email: lberger@labn.net 2308 Christan Hopps 2309 Deutsche Telekom 2311 Email: chopps@chopps.org 2313 Acee Lindem 2314 Cisco Systems 2315 301 Midenhall Way 2316 Cary, NC 27513 2317 USA 2319 Email: acee@cisco.com 2321 Dean Bogdanovic 2323 Email: ivandean@gmail.com 2325 Xufeng Liu 2326 Jabil 2328 Email: Xufeng_Liu@jabil.com