idnits 2.17.1 draft-rtgyangdt-rtgwg-device-model-02.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 429 has weird spacing: '...rw type ide...' == Line 464 has weird spacing: '...rw type ide...' == Line 489 has weird spacing: '...rw type ide...' == Line 546 has weird spacing: '...rw type ide...' -- The document date (January 22, 2016) is 3015 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 7223 (Obsoleted by RFC 8343) ** Obsolete normative reference: RFC 7277 (Obsoleted by RFC 8344) == Outdated reference: A later version (-02) exists of draft-bjorklund-netmod-structural-mount-00 == Outdated reference: A later version (-04) exists of draft-ietf-netmod-opstate-reqs-03 == Outdated reference: A later version (-25) exists of draft-ietf-netmod-routing-cfg-20 == Outdated reference: A later version (-06) exists of draft-ietf-netconf-yang-library-03 Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Lindem, Ed. 3 Internet-Draft Cisco Systems 4 Intended status: Informational L. Berger, Ed. 5 Expires: July 25, 2016 LabN Consulting, L.L.C. 6 D. Bogdanovic 8 C. Hopps 9 Deutsche Telekom 10 January 22, 2016 12 Network Device YANG Organizational Models 13 draft-rtgyangdt-rtgwg-device-model-02 15 Abstract 17 This document presents an approach for organizing YANG models in a 18 comprehensive structure that may be used to configure and operate 19 network devices. The structure is itself represented as a YANG 20 model, with all of the related component models logically organized 21 in a way that is operationally intuitive, but this model is not 22 expected to be implemented. The identified component modules are 23 expected to be defined and implemented on common network devices. 25 This document also defines two modules that can be used to model the 26 logical and virtual resource representations that may be present on a 27 network device. Examples of common industry terms for logical 28 resource representations are Logical Systems or Routers. Examples of 29 of common industry terms for virtual resource representations are 30 Virtual Routing and Forwarding (VRF) instances and Virtual Switch 31 Instances (VSIs). 33 This document is derived from work submitted to the IETF by members 34 of the informal OpenConfig working group of network operators and is 35 a product of the Routing Area YANG Architecture design team. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on July 25, 2016. 54 Copyright Notice 56 Copyright (c) 2016 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 1.1. Status of Work and Open Issues . . . . . . . . . . . . . 4 73 2. Module Overview . . . . . . . . . . . . . . . . . . . . . . . 5 74 2.1. Interface Model Components . . . . . . . . . . . . . . . 8 75 2.2. System Management . . . . . . . . . . . . . . . . . . . . 10 76 2.3. Networking Services . . . . . . . . . . . . . . . . . . . 10 77 2.4. OAM Protocols . . . . . . . . . . . . . . . . . . . . . . 11 78 2.5. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 2.6. MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 3. Logical Network Elements . . . . . . . . . . . . . . . . . . 13 81 3.1. LNE Management - Host Network Device View . . . . . . . . 14 82 3.2. LNE Management - LNE View . . . . . . . . . . . . . . . . 15 83 3.3. LNE Instantiation . . . . . . . . . . . . . . . . . . . . 16 84 4. Network Instances . . . . . . . . . . . . . . . . . . . . . . 16 85 4.1. Network Instance Policy . . . . . . . . . . . . . . . . . 17 86 4.2. Network Instance Management . . . . . . . . . . . . . . . 17 87 4.3. Network Instance Instantiation . . . . . . . . . . . . . 18 88 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 89 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 90 7. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 18 91 7.1. Network Device Model Structure . . . . . . . . . . . . . 18 92 7.2. Logical Network Element Model . . . . . . . . . . . . . . 25 93 7.3. Networking Instance Model . . . . . . . . . . . . . . . . 27 94 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 95 8.1. Normative References . . . . . . . . . . . . . . . . . . 32 96 8.2. Informative References . . . . . . . . . . . . . . . . . 33 98 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 34 99 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 35 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 102 1. Introduction 104 "Operational Structure and Organization of YANG Models" [OC-STRUCT], 105 highlights the value of organizing individual, self-standing YANG 106 [RFC6020] models into a more comprehensive structure. This document 107 builds on that work and presents a derivative structure for use in 108 representing the networking infrastructure aspects of physical and 109 virtual devices. [OC-STRUCT] and earlier versions of this document 110 presented a single device-centric model root, this document no longer 111 contains this element. Such an element would have translated to a 112 single device management model that would be the root of all other 113 models and was judged to be overly restrictive in terms of 114 definition, implementation, and operation. 116 The document first presents a notional network device YANG 117 organizational structure that provides a conceptual framework for the 118 models that may be used to configure and operate network devices. 119 The structure is itself presented as a YANG module, with all of the 120 related component modules logically organized in a way that is 121 operationally intuitive. This network device model is not expected 122 to be implemented, but rather provide as context for the identified 123 representative component modules with are expected to be defined, and 124 supported on typical network devices. 126 This document also defines two new modules that are expected to be 127 implemented. These models are defined to support the configuration 128 and operation of network-devices that allow for the partitioning of 129 resources from both, or either, management and networking 130 perspectives. Both make use of emerging YANG functionality supported 131 by either structural mount [STRUCTURAL-MOUNT] or YANG Schema 132 Dispatching Language (YSDL) [YANG-YSDL]. The module definitions in 133 this version of the document match [STRUCTURAL-MOUNT] but the 134 solution adopted by the Netmod Working Group will be used. 136 Two forms of resource partitioning are supported: 138 The first form provides a logical partitioning of a network device 139 where each partition is separately managed as essentially an 140 independent network element which is 'hosted' by the base network 141 device. These hosted network elements are referred to as logical 142 network elements, or LNEs, and are supported by the logical-network- 143 element module defined below. The module is used to identify LNEs 144 and associate resources from the network-device with each LNE. LNEs 145 themselves are represented in YANG as independent network devices; 146 each accessed independently. Optionally, and when supported by the 147 implementation, they may also be accessed from the host system. 148 Examples of vendor terminology for an LNE include logical system or 149 router, and virtual switch, chassis, or fabric. 151 The second form provides support what is commonly referred to as 152 Virtual Routing and Forwarding (VRF) instances as well as Virtual 153 Switch Instances (VSI), see [RFC4026]. In this form of resource 154 partitioning multiple control plane and forwarding/bridging instances 155 are provided by and managed via a single (physical or logical) 156 network device. This form of resource partitioning is referred to as 157 Network Instances and are supported by the networking-instance module 158 defined below. Configuration and operation of each network-instance 159 is always via the network device and the networking-instance module. 161 This document was motivated by, and derived from, [OC-STRUCT]. The 162 requirements from that document have been combined with the 163 requirements from "Consistent Modeling of Operational State Data in 164 YANG", [OC-OPSTATE], into "NETMOD Operational State Requirements", 165 [NETMOD-OPSTATE]. This document is aimed at the requirement related 166 to a common model-structure, currently Requirement 7, and also aims 167 to provide a modeling base for Operational State representation. 169 The approach taken in this (and the original) document is to organize 170 the models describing various aspects of network infrastructure, 171 focusing on devices, their subsystems, and relevant protocols 172 operating at the link and network layers. The proposal does not 173 consider a common model for higher level network services. We focus 174 on the set of models that are commonly used by network operators, and 175 suggest a corresponding organization. 177 A significant portion of the text and model contained in this 178 document was taken from the -00 of [OC-STRUCT]. 180 1.1. Status of Work and Open Issues 182 This version of the document and structure are a product of the 183 Routing Area YANG Architecture design team and is very much a work in 184 progress rather than a final proposal. This version is a major 185 change from the prior version and this change was enabled by the work 186 on the previously mentioned Structural Mount/YSDL. 188 Structural Mount/YSDL enables a dramatic simplification of the 189 presented device model, particularly for "lower-end" devices which 190 are unlikely to support multiple network instances or logical network 191 elements. Should structural-mount/YSDL not be available, the more 192 explicit tree structure presented in earlier versions of this 193 document will need to be utilized. 195 The top open issues are: 197 1. The use of YSDL vs Structural Mount needs to be resolved as does 198 ensuring that the selected approach has the needed capabilities. 200 2. This document will need to match the evolution and 201 standardization of [OC-OPSTATE] or [NETMOD-OPSTATE] by the Netmod 202 WG. 204 3. Interpretation of different policy containers requires 205 clarification. 207 4. It may make sense to use the identityref structuring with 208 hardware and QoS model. 210 5. Which document(s) define the base System management, networking 211 services, and oam protocols modules is TBD. This includes the 212 possibility of simply using RFC7317 in place of the presented 213 System management module. 215 6. The model will be updated once the "opstate" requirements are 216 addressed. 218 7. It may make sense to publish the networking-instance and logical- 219 network-element modules separately, as different devices may not 220 implement both, and network providers may only require one or the 221 other. 223 2. Module Overview 225 In this document, we consider network devices that support protocols 226 and functions defined within the IETF Routing Area, e.g, routers, 227 firewalls and hosts. Such devices may be physical or virtual, e.g., 228 a classic router with custom hardware or one residing within a 229 server-based virtual machine implementing a virtual network function 230 (VNF). Each device may sub-divide their resources into logical 231 network elements (LNEs) each of which provides a managed logical 232 device. Examples of vendor terminology for an LNE include logical 233 system or router, and virtual switch, chassis, or fabric. Each LNE 234 may also support virtual routing and forwarding (VRF) and virtual 235 switching instance (VSI) functions, which are referred to below as a 236 networking instances (NIs). This breakdown is represented in 237 Figure 1. 239 ,''''''''''''''''''''''''''''''''''''''''''''''`. 240 | Network Device (Physical or Virtual) | 241 | ..................... ..................... | 242 | : Logical Network : : Logical Network : | 243 | : Element : : Element : | 244 | :+-----+-----+-----+: :+-----+-----+-----+: | 245 | :| Net | Net | Net |: :| Net | Net | Net |: | 246 | :|Inst.|Inst.|Inst.|: :|Inst.|Inst.|Inst.|: | 247 | :+-----+-----+-----+: :+-----+-----+-----+: | 248 | : | | | | | | : : | | | | | | : | 249 | :..|.|...|.|...|.|..: :..|.|...|.|...|.|..: | 250 | | | | | | | | | | | | | | 251 `'''|'|'''|'|'''|'|'''''''''|'|'''|'|'''|'|''''' 252 | | | | | | | | | | | | 253 Interfaces Interfaces 255 Figure 1: Module Element Relationships 257 A model for LNEs is described in Section 3 and the model for 258 networking instances is covered in Section 4. 260 The presented notional network device module can itself be thought of 261 as a "meta-model" as it describes the relationships between 262 individual models. We choose to represent it also as a simple YANG 263 module consisting of other models, which are in fact independent top 264 level individual models. Although it is never expected to be 265 implemented. 267 The presented modules do not follow the hierarchy of any particular 268 implementation, and hence is vendor-neutral. Nevertheless, the 269 structure should be familiar to network operators and also readily 270 mapped to vendor implementations. 272 The overall structure is: 274 module: network-device 275 +--rw ietf-yang-library 276 | 277 +--rw interfaces 278 +--rw hardware 279 +--rw qos 280 | 281 +--rw system-management 282 +--rw networking-services 283 +--rw oam-protocols 284 | 285 +--rw routing 286 +--rw mpls 287 +--rw ieee-dot1Q 288 | 289 +--rw ietf-acl 290 +--rw ietf-key-chain 291 | 292 +--rw logical-network-element 293 +--rw networking-instance 295 The network device is composed of top level modules that can be used 296 to configure and operate a network device. (This is a significant 297 difference from earlier versions of this document where there was a 298 strict model hierarchy.) Importantly the network device structure is 299 the same for a physical network device or a logical network device, 300 such as those instantiated via the logical-network-element model. 301 Extra spacing is included to denote different types of modules 302 included. 304 YANG library [YANG-LIBRARY] is included as it used to identify 305 details of the top level modules supported by the (physical or 306 logical) network device. Th ability to identify supported modules is 307 particularly important for LNEs which may have a set of supported 308 modules which differs from the set supported by the host network 309 device. 311 The interface management model [RFC7223] is included at the top 312 level. The hardware module is a placeholder for a future device- 313 specific configuration and operational state data model. For 314 example, a common structure for the hardware model might include 315 chassis, line cards, and ports, but we leave this unspecified. The 316 quality of service (QoS) section is also a placeholder module for 317 device configuration and operational state data which relates to the 318 treatment of traffic across the device. This document defines 319 augmentations to the interface module to support LNEs and NIs. 320 Similar elements, although perhaps only for LNEs, may also need to be 321 included as part of the definition of the future hardware and QoS 322 modules. 324 System management, networking services, and oam protocols represent 325 new top level modules that are used to organize data models of 326 similar functions. Additional information on each is provided below. 328 The routing and MPLS modules provide core support for the 329 configuration and operation of a devices control plane and data plane 330 functions. IEEE dot1Q [IEEE-8021Q] is an example of another module 331 that provides similar functions for VLAN bridging, and other similar 332 modules are also possible. Each of these modules is expected to be 333 LNE and NI unaware, and to be instantiated as needed as part of the 334 LNE and NI configuration and operation supported by the logical- 335 network-element and networking-instance modules. (Note that this is 336 a change from [RTG-CFG] which is currently defined with VRF/NI 337 semantics.) 339 The access control list (ACL) and key chain modules are included as 340 examples of other top level modules that may be supported by a 341 network device. 343 The logical network element and networking instance modules enable 344 LNEs and NIs respectively and are defined below. 346 2.1. Interface Model Components 348 Interfaces are a crucial part of any network device's configuration 349 and operational state. They generally include a combination of raw 350 physical interfaces, link-layer interfaces, addressing configuration, 351 and logical interfaces that may not be tied to any physical 352 interface. Several system services, and layer 2 and layer 3 353 protocols may also associate configuration or operational state data 354 with different types of interfaces (these relationships are not shown 355 for simplicity). The interface management model is defined by 356 [RFC7223]. 358 The logical-network-element and networking-instance modules defined 359 in this document augment the existing interface management model in 360 two ways: The first, by the logical-network-element module, adds an 361 identifier which is used on physical interface types to identify an 362 associated LNE. The second, by the networking-instance module, adds 363 a name which is used on sub-interface types to identify an associated 364 networking instance. Similarly, this name is also added for IPv4 and 365 IPv6 types, as defined in [RFC7277]. 367 The interface related augmentations are as follows: 369 augment /if:interfaces/if:interface: 370 +--rw bind-lne-name? string 372 augment /if:interfaces/if:interface: 373 +--rw bind-networking-instance-name? string 374 augment /if:interfaces/if:interface/ip:ipv4: 375 +--rw bind-networking-instance-name? string 376 augment /if:interfaces/if:interface/ip:ipv6: 377 +--rw bind-networking-instance-name? string 379 The following is an example of envisioned combined usage. The 380 interfaces container includes a number of commonly used components as 381 examples: 383 +--rw interfaces 384 | +--rw interface* [name] 385 | +--rw name string 386 | +--rw bind-lne-name? string 387 | +--rw ethernet 388 | | +--rw bind-networking-instance-name? string 389 | | +--rw aggregates 390 | | +--rw rstp 391 | | +--rw lldp 392 | | +--rw ptp 393 | +--rw vlans 394 | +--rw tunnels 395 | +--rw ipv4 396 | | +--rw bind-networking-instance-name? string 397 | | +--rw arp 398 | | +--rw icmp 399 | | +--rw vrrp 400 | | +--rw dhcp-client 401 | +--rw ipv6 402 | +--rw bind-networking-instance-name? string 403 | +--rw vrrp 404 | +--rw icmpv6 405 | +--rw nd 406 | +--rw dhcpv6-client 408 The [RFC7223] defined interface model is structured to include all 409 interfaces in a flat list, without regard to logical or virtual 410 instances (e.g., VRFs) supported on the device. The bind-lne-name 411 and bind-networking-instance-name leaves provide the association 412 between an interface and its associated LNE and NI (e.g., VRF or 413 VSI). 415 2.2. System Management 417 [Editor's note: need to discuss and resolve relationship between this 418 structure and RFC7317 and determine if 7317 is close enough to simply 419 use as is.] 421 System management is expected to reuse definitions contained in 422 [RFC7317]. It is expected to be instantiated per device and LNE. 423 Its structure is shown below: 425 module: network-device 426 +--rw system-management 427 | +--rw system-management-global 428 | +--rw system-management-protocol* [type] 429 | +--rw type identityref 431 System-management-global is used for configuration information and 432 state that is independent of a particular management protocol. 433 System-management-protocol is a list of management protocol specific 434 elements. The type-specific sub-modules are expected to be defined. 436 The following is an example of envisioned usage: 438 module: network-device 439 +--rw system-management 440 +--rw system-management-global 441 | +--rw statistics-collection 442 | ... 443 +--rw system-management-protocol* [type] 444 | +--rw type=syslog 445 | +--rw type=dns 446 | +--rw type=ntp 447 | +--rw type=ssh 448 | +--rw type=tacacs 449 | +--rw type=snmp 450 | +--rw type=netconf 452 2.3. Networking Services 454 A device may provide different network services to other devices, for 455 example a device my act as a DHCP server. The model may be 456 instantiated per device, LNE, and NI. An identityref is used to 457 identify the type of specific service being provided and its 458 associated configuration and state information. The defined 459 structure is as follows: 461 module: network-device 462 +--rw networking-services 463 | +--rw networking-service* [type] 464 | +--rw type identityref 466 The following is an example of envisioned usage: Examples shown below 467 include a device-based Network Time Protocol (NTP) server, a Domain 468 Name System (DNS) server, and a Dynamic Host Configuration Protocol 469 (DHCP) server: 471 module: network-device 472 +--rw networking-services 473 +--rw networking-service* [type] 474 +--rw type=ntp-server 475 +--rw type=dns-server 476 +--rw type=dhcp-server 478 2.4. OAM Protocols 480 OAM protocols that may run within the context of a device are grouped 481 within the oam-protocols model. The model may be instantiated per 482 device, LNE, and NI. An identifyref is used to identify the 483 information and state that may relate to a specific OAM protocol. 484 The defined structure is as follows: 486 module: network-device 487 +--rw oam-protocols 488 +--rw oam-protocol* [type] 489 +--rw type identityref 491 The following is an example of envisioned usage. Examples shown 492 below include Bi-directional Forwarding Detection (BFD), Ethernet 493 Connectivity Fault Management (CFM), and Two-Way Active Measurement 494 Protocol (TWAMP): 496 module: network-device 497 +--rw oam-protocols 498 +--rw oam-protocol* [type] 499 +--rw type=bfd 500 +--rw type=cfm 501 +--rw type=twamp 503 2.5. Routing 505 Routing protocol and IP forwarding configuration and operation 506 information is modeled via a routing model, such as the one defined 507 in [RTG-CFG]. Although, the defined routing module includes support 508 for NIs, which it refers to as Routing Instances, while the approach 509 presented in this document presumes that the routing module is 510 unaware of LNEs and NIs. 512 The routing module is expected to include all IETF defined control 513 plane protocols, such as BGP, OSPF, LDP and RSVP-TE. It is also 514 expected to support configuration and operation of or more routing 515 information bases (RIB). A RIB is a list of routes complemented with 516 administrative data. Finally, policy is expected to be represented 517 within each control plane protocol and RIB. 519 The anticipated structure is as follows: 521 module: network-device 522 +--rw routing 523 +--rw control-plane-protocols 524 | +--rw control-plane-protocol* [type] 525 | +--rw type identityref 526 | +--rw policy 527 +--rw ribs 528 +--rw rib* [name] 529 +--rw name string 530 +--rw description? string 531 +--rw policy 533 2.6. MPLS 535 MPLS data plane related information is grouped together, as with the 536 previously discussed modules, is unaware of VRFs/NIs. The model may 537 be instantiated per device, LNE, and NI. MPLS control plane 538 protocols are expected to be included in Section 2.5. MPLS may reuse 539 and build on [OC-MPLS] or other emerging models and has an 540 anticipated structure as follows: 542 module: network-device 543 +--rw mpls 544 +--rw global 545 +--rw lsps* [type] 546 +--rw type identityref 548 Type refers to LSP type, such as static, traffic engineered or 549 routing congruent. The following is an example of such usage: 551 module: network-device 552 +--rw mpls 553 +--rw global 554 +--rw lsps* [type] 555 +--rw type=static 556 +--rw type=constrained-paths 557 +--rw type=igp-congruent 559 3. Logical Network Elements 561 A logical network element is a network-device which is contained 562 within another network-device. Using host-virtualization terminology 563 one could refer to an LNE as a "Guest", and the containing network- 564 device as the "Host". While LNEs may be implemented via host- 565 virtualization technologies this is not a requirement. 567 Logical network elements represent the capability of some devices to 568 partition resources into independent logical routers and/or switches. 569 Device support for multiple logical network elements is 570 implementation specific. Systems without such capabilities need not 571 include support for the logical-network-element module. In physical 572 devices, some hardware features are shared across partitions, but 573 control plane (e.g., routing) protocol instances, tables, and 574 configuration are managed separately. For example, in virtual 575 routers or VNFs, this may correspond to establishing multiple logical 576 instances using a single software installation. The model supports 577 configuration of multiple instances on a single device by creating a 578 list of logical network elements, each with their own configuration 579 and operational state related to routing and switching protocols, as 580 shown below: 582 module: logical-network-element 583 +--rw logical-network-inventory 584 +--rw logical-network-element* [name] 585 +--rw name? string 586 +--rw description? string 587 +--rw managed? boolean 588 +--rw root? structural-mount 589 augment /if:interfaces/if:interface: 590 +--rw bind-lne-name? string 592 `name` identifies the logical network element. `managed` indicates 593 if the host network device is able to manage the LNE via the `root` 594 structure. 596 3.1. LNE Management - Host Network Device View 598 There are multiple implementation approaches possible to enable a 599 network device to support the logical-network-element module and 600 multiple LNEs. Some approaches will allow the management functions 601 operating at network device level to access LNE configuration and 602 operation information, while others will not. Similarly, even when 603 LNE management from the network device is supported by the 604 implementation, it may be prohibited by user policy. 606 The `managed` boolean mentioned above is used to indicate when LNE 607 management from the network device context is possible. When the 608 `managed` is `false`, the LNE cannot be managed by the host system 609 and can only be managed from within the context of the LNE as 610 described in the next section, Section 3.2. 612 When `managed` is `true`, the LNE can be managed from both the 613 context of the LNE and the host network device. In this case, the 614 same information that is available from within the LNE context is 615 made available via the `root` element, with paths modified as 616 described in [STRUCTURAL-MOUNT]. 618 As an example, consider the case where an LNE with a `name` of "one" 619 is defined on a network device. In this case the following structure 620 might be made available: 622 ....................................................................... 623 [ network-device state ] 624 module: logical-network-element 625 +--rw logical-network-inventory 626 +--rw logical-network-element* [name] 627 +--rw name="one" string 628 +--rw manged=true boolean 629 +--rw root structural-mount 631 ....................................................................... 632 [ LNE state exposed to network-device] 634 +--rw ietf-yang-library 635 +--rw interfaces 636 +--rw hardware 637 +--rw qos 638 +--rw system-management 639 +--rw networking-services 640 +--rw oam-protocols 641 +--rw routing 642 +--rw mpls 643 +--rw ieee-dot1Q 644 +--rw networking-instance 645 ....................................................................... 647 As an LNE is a network device itself, all modules that may be present 648 at the top level network device may also be present for the LNE, be 649 made available under `root`, and be accessible via paths modified per 650 [STRUCTURAL-MOUNT]. The list of available modules is expected to be 651 implementation dependent. As is the method used by an implementation 652 to support LNEs. 654 Resources assigned to the LNE will be represented in that LNE's 655 resource modules. e.g., an LNE's interfaces module will contain the 656 interfaces assigned to that LNE from the containing network-device. 658 3.2. LNE Management - LNE View 660 Management functions operating with the context of an LNE are 661 accessed through standard LNE's management interfaces, e.g., NETCONF 662 and SNMP. When accessing an LNE via an LNE's management interface, a 663 network-device representation will be presented, but its scope will 664 be limited to the specific LNE. Normal YANG/NETCONF mechanisms, 665 together with ietf-yang-library, can be used to identify the 666 available modules. Each supported module will be presented as a top 667 level module. Only LNE associated resources will be reflected in 668 resource related modules, e.g., interfaces, hardware and perhaps QoS. 669 From the management perspective, there will be no difference between 670 the available LNE view (information) and an a physical network 671 device. 673 Multiple implementation approaches are possible to provide LNE views, 674 and these are outside the scope of this document. 676 3.3. LNE Instantiation 678 TBD -- need to resolve if instantiation is based on (a) new list 679 entry creation, (2) YSDL, or (3) Structural Mount. 681 4. Network Instances 683 The network instance container is used to represent virtual routing 684 and forwarding instances (VRFs) and virtual switching instances 685 (VSIs), [RFC4026]. VRFs and VSIs are commonly used to isolate 686 routing and switching domains, for example to create virtual private 687 networks, each with their own active protocols and routing/switching 688 policies. The model represents both core/provider and virtual 689 instances. Networking instances reuse and build on [RTG-CFG] and are 690 shown below: 692 module: networking-instance 693 +--rw networking-instances 694 +--rw networking-instance* [name] 695 +--rw name string 696 +--rw type? identityref 697 +--rw enabled? boolean 698 +--rw description? string 699 +--rw networking-instance-policy 700 | ... 701 +--rw root? structural-mount 702 | ... 703 augment /if:interfaces/if:interface: 704 +--rw bind-networking-instance-name? string 705 augment /if:interfaces/if:interface/ip:ipv4: 706 +--rw bind-networking-instance-name? string 707 augment /if:interfaces/if:interface/ip:ipv6: 708 +--rw bind-networking-instance-name? string 710 A networking instance is identified by a `name` string. This string 711 is used both as an index within the networking-instance module and to 712 associate resources with a networking instance is shown above in the 713 interface augmentation. Type is used to indicate the type NI, such 714 as L3-VRF, VPLS, L2-VSI, etc. Networking instance policy and root 715 are discussed in greater detail below. 717 4.1. Network Instance Policy 719 Networking instance policies are used to control how NI information 720 is represented at the device level, VRF routing policies, and VRF/VSI 721 identifiers. Examples include BGP route targets (RTs) and route 722 distinguishers (RDs), virtual network identifiers (VN-IDs), VPLS 723 neighbors, etc. The structure is expected to be: 725 module: networking-instance 726 +--rw networking-instances 727 +--rw networking-instance* [name] 728 +--rw networking-instance-policy 729 (TBD) 731 4.2. Network Instance Management 733 Modules that may be used to represent networking instance specific 734 information will be available under `root`. As with LNEs, actual 735 module availability is expected to be implementation dependent. The 736 ietf-yang-library module is expected to be the primary method used to 737 identify supported modules. Resource related control and assignment 738 is expected to be managed at the network-device level, not the 739 networking instance level, based on the `bind-networking-instance- 740 name` augmentation mentioned above. 742 As an example, consider the case where a networking instance with a 743 `name` of "green" is defined on a network device. In this case the 744 following structure might be made available: 746 module: networking-instance 747 +--rw ietf-yang-library 748 +--rw interfaces 749 | +--rw bind-networking-instance-name="green" string 750 +--rw system-management 751 +--rw networking-instances 752 +--rw networking-instance* [name] 753 +--rw name="green" string 754 +--rw type? identityref 755 +--rw enabled=true boolean 756 +--rw description="The Green VRF" string 757 +--rw networking-instance-policy 758 | ... (RT=1000:1, RD=1.2.3.4) 759 +--rw root? structural-mount 760 +--rw ietf-yang-library 761 +--rw networking-services 762 +--rw oam-protocols 763 +--rw routing 764 +--rw mpls 766 All modules that represent control-plane and data-plane information 767 may be present at the `root`, and be accessible via paths modified 768 per [STRUCTURAL-MOUNT]. The list of available modules is expected to 769 be implementation dependent. As is the method used by an 770 implementation to support NIs. 772 4.3. Network Instance Instantiation 774 TBD -- need to resolve if instantiation is based on (a) new list 775 entry creation, (2) YSDL, or (3) Structural Mount. 777 5. Security Considerations 779 The network-device model structure described in this document does 780 not define actual configuration and state data, hence it is not 781 directly responsible for security risks. 783 Each of the component models that provide the corresponding 784 configuration and state data should be considered sensitive from a 785 security standpoint since they generally manipulate aspects of 786 network configurations. Each component model should be carefully 787 evaluated to determine its security risks, along with mitigations to 788 reduce such risks. 790 LNE portion is TBD 792 NI portion is TBD 794 6. IANA Considerations 796 This YANG model currently uses a temporary ad-hoc namespace. If it 797 is placed or redirected for the standards track, an appropriate 798 namespace URI will be registered in the "IETF XML Registry" 799 [RFC3688]. The YANG structure modules will be registered in the 800 "YANG Module Names" registry [RFC6020]. 802 7. YANG Modules 804 The structure of the models defined in this document are described by 805 the YANG module below. 807 7.1. Network Device Model Structure 809 file "network-device@2016-01-19.yang" 810 module network-device { 812 yang-version "1"; 813 // namespace 814 namespace "urn:ietf:params:xml:ns:yang:network-device"; 816 prefix "struct"; 818 // import some basic types 820 // meta 821 organization "IETF RTG YANG Design Team Collaboration 822 with OpenConfig"; 824 contact 825 "Routing Area YANG Architecture Design Team - 826 "; 828 description 829 "This module describes a model structure for YANG 830 configuration and operational state data models. Its intent is 831 to describe how individual device protocol and feature models 832 fit together and interact."; 834 revision "2016-01-19" { 835 description 836 "IETF Routing YANG Design Team Meta-Model"; 837 reference "TBD"; 838 } 840 // extension statements 842 // identity statements 844 identity oam-protocol-type { 845 description 846 "Base identity for derivation of OAM protocols"; 847 } 849 identity networking-service-type { 850 description 851 "Base identity for derivation of networking services"; 852 } 854 identity system-management-protocol-type { 855 description 856 "Base identity for derivation of system management 857 protocols"; 858 } 860 identity oam-service-type { 861 description 862 "Base identity for derivation of Operations, 863 Administration, and Maintenance (OAM) services."; 864 } 866 identity control-plane-protocol-type { 867 description 868 "Base identity for derivation of control-plane protocols"; 869 } 871 identity mpls-lsp-type { 872 description 873 "Base identity for derivation of MPLS LSP typs"; 874 } 876 // typedef statements 878 // grouping statements 880 grouping control-plane-protocols { 881 description 882 "Grouping for control plane protocols configured for 883 a networking-instance"; 884 container control-plane-protocols { 885 description 886 "Container for control plane protocols configured for 887 a networking instance."; 888 list control-plane-protocol { 889 key "type"; 890 description 891 "List of control plane protocols configured for 892 a networking instance."; 893 leaf type { 894 type identityref { 895 base control-plane-protocol-type; 896 } 897 mandatory true; 898 description 899 "The control plane protocol type, e.g., BGP, 900 OSPF IS-IS, etc"; 901 } 902 container policy { 903 description 904 "Protocol specific policy, 905 reusing [RTG-POLICY]"; 906 } 907 } 908 } 910 } 912 grouping ribs { 913 description 914 "Routing Information Bases (RIBs) supported by a 915 networking-instance"; 916 container ribs { 917 description 918 "RIBs supported by a networking-instance"; 919 list rib { 920 key "name"; 921 min-elements "1"; 922 description 923 "Each entry represents a RIB identified by the 924 'name' key. All routes in a RIB must belong to the 925 same address family. 927 For each routing instance, an implementation should 928 provide one system-controlled default RIB for each 929 supported address family."; 930 leaf name { 931 type string; 932 description 933 "The name of the RIB."; 934 } 935 reference "draft-ietf-netmod-routing-cfg"; 936 leaf description { 937 type string; 938 description 939 "Description of the RIB"; 940 } 941 // Note that there is no list of interfaces within 942 container policy { 943 description "Policy specific to RIB"; 944 } 945 } 946 } 947 } 949 // top level device definition statements 950 container ietf-yang-library { 951 description 952 "YANG Module Library as defined in 953 draft-ietf-netconf-yang-library"; 954 } 956 container interfaces { 957 description 958 "Interface list as defined by RFC7223/RFC7224"; 959 } 961 container hardware { 962 description 963 "Hardware / vendor-specific data relevant to the platform. 964 This container is an anchor point for platform-specific 965 configuration and operational state data. It may be further 966 organized into chassis, line cards, ports, etc. It is 967 expected that vendor or platform-specific augmentations 968 would be used to populate this part of the device model"; 969 } 971 container qos { 972 description "QoS features, for example policing, shaping, etc."; 973 } 975 container system-management { 976 description 977 "System management for physical or virtual device."; 978 container system-management-global { 979 description "System management - with reuse of RFC 7317"; 980 } 981 list system-management-protocol { 982 key "type"; 983 leaf type { 984 type identityref { 985 base system-management-protocol-type; 986 } 987 mandatory true; 988 description 989 "Syslog, ssh, TACAC+, SNMP, NETCONF, etc."; 990 } 991 description "List of system management protocol 992 configured for a logical networking 993 element."; 994 } 995 } 997 container networking-services { 998 description 999 "Container for list of configured networking 1000 services."; 1001 list networking-service { 1002 key "type"; 1003 description 1004 "List of networking services configured for a 1005 networking instance."; 1007 leaf type { 1008 type identityref { 1009 base networking-service-type; 1010 } 1011 mandatory true; 1012 description 1013 "The networking services type supported within 1014 a networking instance, e.g., NTP server, DNS 1015 server, DHCP server, etc."; 1016 } 1017 } 1018 } 1020 container oam-protocols { 1021 description 1022 "Container for configured OAM protocols."; 1023 list oam-protocol { 1024 key "type"; 1025 leaf type { 1026 type identityref { 1027 base oam-protocol-type; 1028 } 1029 mandatory true; 1030 description 1031 "The Operations, Administration, and 1032 Maintenance (OAM) protocol type, e.g., BFD, 1033 TWAMP, CFM, etc."; 1034 } 1035 description 1036 "List of configured OAM protocols."; 1037 } 1038 } 1040 container routing { 1041 description 1042 "The YANG Data Model for Routing Management revised to be 1043 Network Instance / VRF independent. "; 1044 // Note that there is no routing or network instance 1045 uses control-plane-protocols; 1046 uses ribs; 1047 } 1049 container mpls { 1050 description "MPLS and TE configuration"; 1051 container global { 1052 description "Global MPLS configuration"; 1053 } 1054 list lsps { 1055 key "type"; 1056 description 1057 "List of LSP types."; 1058 leaf type { 1059 type identityref { 1060 base mpls-lsp-type; 1061 } 1062 mandatory true; 1063 description 1064 "MPLS and Traffic Engineering protocol LSP types, 1065 static, LDP/SR (igp-congruent), 1066 RSVP TE (constrained-paths) , etc."; 1067 } 1068 } 1069 } 1071 container ieee-dot1Q { 1072 description 1073 "The YANG Data Model for VLAN bridges as defined by the IEEE"; 1074 } 1076 container ietf-acl { 1077 description "Packet Access Control Lists (ACLs) as specified 1078 in draft-ietf-netmod-acl-model"; 1079 } 1081 container ietf-key-chain { 1082 description "Key chains as specified in 1083 draft-ietf-rtgwg-yang-key-chain;"; 1084 } 1086 container logical-network-element { 1087 description 1088 "This module is used to support multiple logical network 1089 elements on a single physical or virtual system."; 1090 } 1092 container networking-instance { 1093 description 1094 "This module is used to support multiple network instances 1095 within a single physical or virtual device. Network 1096 instances are commonly know as VRFs (virtual routing 1097 and forwarding) and VSIs (virtual switching instances)."; 1098 } 1099 // rpc statements 1101 // notification statements 1103 } 1104 1106 7.2. Logical Network Element Model 1108 file "logical-network-element@2016-01-19.yang" 1109 module logical-network-element { 1111 yang-version "1"; 1113 // namespace 1114 namespace "urn:ietf:params:xml:ns:yang:logical-network-element"; 1116 prefix "struct"; 1118 // import some basic types 1119 import ietf-interfaces { 1120 prefix if; 1121 } 1123 // meta 1124 organization "IETF RTG YANG Design Team Collaboration 1125 with OpenConfig"; 1127 contact 1128 "Routing Area YANG Architecture Design Team - 1129 "; 1131 description 1132 "This module is used to support multiple logical network 1133 elements on a single physical or virtual system."; 1135 revision "2016-01-19" { 1136 description 1137 "IETF Routing YANG Design Team Meta-Model"; 1138 reference "TBD"; 1139 } 1141 // extension statements 1143 // feature statements 1144 feature bind-network-element-id { 1145 description 1146 "Logical network element ID to which an interface is bound"; 1147 } 1149 // identity statements 1150 identity logical-network-element-type { 1151 description 1152 "Identify type of logical-network-element"; 1153 } 1155 identity lne-managed { 1156 base logical-network-element-type; 1157 description 1158 "A Logical Network Element that can 1159 be managed by the host system"; 1160 } 1162 identity lne-unmanaged { 1163 base logical-network-element-type; 1164 description 1165 "A Logical Network Element that cannot 1166 be managed by the host system"; 1167 } 1169 // typedef statements 1171 // grouping statements 1173 // top level device definition statements 1174 container logical-network-inventory { 1175 description "Allows a network device to support multiple logical 1176 network element (device) instances"; 1177 list logical-network-element { 1178 key lne-id; 1179 description "List of logical network elements"; 1180 leaf lne-id { 1181 type uint16; // expect a small number of logical routers 1182 description "Device-wide unique identifier for the 1183 logical network element"; 1184 } 1185 leaf lne-name { 1186 type string; 1187 description "Descriptive name for the logical network 1188 element"; 1189 } 1190 leaf lne-type { 1191 type identityref { 1192 base logical-network-element-type; 1193 } 1194 description "Type of logical-network-element"; 1195 } 1196 leaf lne-root { 1197 type structural-mount; 1198 description "Root for models supported per logical 1199 network element"; 1200 } 1201 } 1202 } 1204 // augment statements 1205 augment "/if:interfaces/if:interface" { 1206 description 1207 "Add a node for the identification of the logical network 1208 element associated with an interface. Applies to interfaces 1209 that can be assigned on a per logical network element basis. 1210 A error is returned when the interface type cannot be 1211 assigned."; 1213 leaf bind-lne-id { 1214 type uint16; 1215 description 1216 "Logical network element ID to which interface is bound"; 1217 } 1218 } 1220 // rpc statements 1222 // notification statements 1224 } 1225 1227 7.3. Networking Instance Model 1229 file "networking-instance@2016-01-20.yang" 1230 module networking-instance { 1232 yang-version "1"; 1234 // namespace 1235 namespace "urn:ietf:params:xml:ns:yang:networking-instance"; 1237 prefix "struct"; 1239 // import some basic types 1240 import ietf-interfaces { 1241 prefix if; 1242 } 1244 import ietf-ip { 1245 prefix ip; 1247 } 1249 // meta 1250 organization "IETF RTG YANG Design Team Collaboration 1251 with OpenConfig"; 1253 contact 1254 "Routing Area YANG Architecture Design Team - 1255 "; 1257 description 1258 "This module is used to support multiple network instances 1259 within a single physical or virtual device. Network 1260 instances are commonly know as VRFs (virtual routing 1261 and forwarding) and VSIs (virtual switching instances)."; 1263 revision "2016-01-20" { 1264 description 1265 "IETF Routing YANG Design Team Meta-Model"; 1266 reference "TBD"; 1267 } 1269 // extension statements 1271 feature bind-networking-instance-name { 1272 description 1273 "Networking Instance to which an interface instance is bound"; 1274 } 1276 // identity statements 1278 identity networking-instance-type { 1279 description 1280 "Base identity from which identities describing 1281 networking instance types are derived."; 1282 } 1284 identity ipv4-interface-protocol-type { 1285 description 1286 "Base identity for derivation of IPv4 interface 1287 protocols"; 1288 } 1290 identity ipv6-interface-protocol-type { 1291 description 1292 "Base identity for derivation of IPv6 interface 1293 protocols"; 1294 } 1296 // typedef statements 1298 // grouping statements 1300 grouping interface-ip-common { 1301 description 1302 "interface-specific configuration for IP interfaces, IPv4 and 1303 IPv6"; 1305 } 1307 grouping ipv4-interface-protocols { 1308 container ipv4-interface-protocols { 1309 list ipv4-interface-protocol { 1310 key "type"; 1311 leaf type { 1312 type identityref { 1313 base ipv4-interface-protocol-type; 1314 } 1315 mandatory true; 1316 description 1317 "ARP, ICMP, VRRP, DHCP Client, etc."; 1318 } 1319 description 1320 "List of IPv4 protocols configured 1321 on an interface"; 1322 } 1323 description 1324 "Container for list of IPv4 protocols configured 1325 on an interface"; 1326 } 1327 description 1328 "Grouping for IPv4 protocols configured on an interface"; 1329 } 1331 grouping ipv6-interface-protocols { 1332 description 1333 "Grouping for IPv6 protocols configured on 1334 an interface."; 1335 container ipv6-interface-protocols { 1336 description 1337 "Container for list of IPv6 protocols configured 1338 on an interface."; 1339 list ipv6-interface-protocol { 1340 key "type"; 1341 description 1342 "List of IPv6 protocols configured 1343 on an interface"; 1345 leaf type { 1346 type identityref { 1347 base ipv6-interface-protocol-type; 1348 } 1349 mandatory true; 1350 description 1351 "ND, ICMPv6, VRRP, DHCPv6 Client, etc."; 1352 } 1353 } 1354 } 1355 } 1357 grouping networking-instance-policy { 1358 description 1359 "Networking instance policies such as route 1360 distinguisher, route targets, VPLS ID and neighbor, 1361 Ethernet ID, etc. "; 1362 reference 1363 "RFC 4364 - BGP/MPLS Virtual Private Networks (VPNs) 1364 RFC 6074 - Provisioning, Auto-Discovery, and Signaling 1365 in Layer 2 Virtual Private Networks (L2VPNs) 1366 RFC 7432 - BGP MPLS-Based Ethernet VPN"; 1367 container networking-instance-policy { 1368 description "Networking Instance Policy -- details TBD"; 1369 } 1370 } 1372 // top level device definition statements 1373 container networking-instances { 1374 description "Networking instances each of which have 1375 an independent IP/IPv6 addressing space 1376 and protocol instantiations. For layer 3, 1377 this consistent with the routing-instance 1378 definition in ietf-routing"; 1379 reference "draft-ietf-netmod-routing-cfg"; 1380 list networking-instance { 1381 key name; 1382 description "List of networking-instances"; 1383 leaf name { 1384 type string; 1385 description "device scoped 1386 identifier for the networking 1387 instance"; 1388 } 1389 leaf type { 1390 type identityref { 1391 base networking-instance-type; 1392 } 1393 description 1394 "The networking instance type -- details TBD 1395 Likely types include core, L3-VRF, VPLS, 1396 L2-cross-connect, L2-VSI, etc."; 1397 } 1398 leaf enabled { 1399 type boolean; 1400 default "true"; 1401 description 1402 "Flag indicating whether or not the networking 1403 instance is enabled."; 1404 } 1405 leaf description { 1406 type string; 1407 description 1408 "Description of the networking instance 1409 and its intended purpose"; 1410 } 1411 uses networking-instance-policy; 1412 leaf root { 1413 type structural-mount; 1414 description "Root for models supported per 1415 networking instance"; 1416 } 1417 } 1418 } 1420 // augment statements 1422 augment "/if:interfaces/if:interface" { 1423 description 1424 "Add a node for the identification of the logical networking 1425 instance (which is within the interface's identified logical 1426 network element) associated with the IP information 1427 configured on an interface"; 1429 leaf bind-networking-instance-name { 1430 type string; 1431 description 1432 "Networking Instance to which an interface is bound"; 1433 } 1434 } 1436 augment "/if:interfaces/if:interface/ip:ipv4" { 1437 description 1438 "Add a node for the identification of the logical 1439 networking instance (which is within the interface's 1440 identified physical or virtual device) associated with 1441 the IP information configured on an interface"; 1443 leaf bind-networking-instance-name { 1444 type string; 1445 description 1446 "Networking Instance to which IPv4 interface is bound"; 1448 } 1449 } 1451 augment "/if:interfaces/if:interface/ip:ipv6" { 1452 description 1453 "Add a node for the identification of the logical 1454 networking instance (which is within the interface's 1455 identified physical or virtual device) associated with 1456 the IP information configured on an interface"; 1458 leaf bind-networking-instance-name { 1459 type string; 1460 description 1461 "Networking Instance to which IPv6 interface is bound"; 1463 } 1464 } 1466 // rpc statements 1468 // notification statements 1470 } 1471 1473 8. References 1475 8.1. Normative References 1477 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1478 January 2004. 1480 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 1481 Private Network (VPN) Terminology", RFC 4026, March 2005. 1483 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 1484 Network Configuration Protocol (NETCONF)", RFC 6020, 1485 October 2010. 1487 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 1488 Management", RFC 7223, May 2014. 1490 [RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", 1491 RFC 7277, June 2014. 1493 [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for 1494 System Management", RFC 7317, August 2014. 1496 [STRUCTURAL-MOUNT] 1497 Bjorklund, M., "YANG Structural Mount", draft-bjorklund- 1498 netmod-structural-mount-00.txt (work in progress), 1499 December 2015. 1501 [YANG-YSDL] 1502 Lhotha, L., "YANG Schema Dispatching Language", draft- 1503 lhotka-netmod-ysdl-00.txt (work in progress), November 1504 2015. 1506 8.2. Informative References 1508 [IEEE-8021Q] 1509 Holness, M., "IEEE 802.1Q YANG Module Specifications", 1510 IEEE-Draft http://www.ieee802.org/1/files/public/docs2015/ 1511 new-mholness-yang-8021Q-0515-v04.pdf, May 2015. 1513 [NETMOD-OPSTATE] 1514 Watsen, K. and T. Nadeau, "NETMOD Operational State 1515 Requirements", draft-ietf-netmod-opstate-reqs-03.txt (work 1516 in progress), January 2016. 1518 [OC-MPLS] George, J., Fang, L., Osborne, E., and R. Shakir, "MPLS / 1519 TE Model for Service Provider Networks", draft-openconfig- 1520 mpls-consolidated-model-02.txt (work in progress), October 1521 2015. 1523 [OC-OPSTATE] 1524 Shakir, R., Shaikh, A., and M. Hines, "Consistent Modeling 1525 of Operational State Data in YANG", draft-openconfig- 1526 netmod-opstate-01.txt (work in progress), July 2015. 1528 [OC-STRUCT] 1529 Shaikh, A., Shakir, R., D'Souza, K., and L. Fang, 1530 "Consistent Modeling of Operational State Data in YANG", 1531 draft-openconfig-netmod-model-structure-00.txt (work in 1532 progress), March 2015. 1534 [RTG-CFG] Lhotha, L. and A. Lindem, "A YANG Data Model for Routing 1535 Management", draft-ietf-netmod-routing-cfg-20.txt (work in 1536 progress), October 2015. 1538 [YANG-LIBRARY] 1539 Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module 1540 Library", draft-ietf-netconf-yang-library-03.txt (work in 1541 progress), December 2015. 1543 Appendix A. Acknowledgments 1545 This document is derived from draft-openconfig-netmod-model- 1546 structure-00. The Authors of that document who are not also authors 1547 of this document are listed as Contributors to this work. 1549 The original stated: The authors are grateful for valuable 1550 contributions to this document and the associated models from: Deepak 1551 Bansal, Paul Borman, Chris Chase, Josh George, Marcus Hines, and Jim 1552 Uttaro. 1554 The Routing Area Yang Architecture design team members included Acee 1555 Lindem, Anees Shaikh, Christian Hopps, Dean Bogdanovic, Lou Berger, 1556 Qin Wu, Rob Shakir, Stephane Litkowski, and Yan Gang. 1558 The identityref approach was proposed by Mahesh Jethanandani. 1560 The RFC text was produced using Marshall Rose's xml2rfc tool. 1562 Appendix B. Contributors 1564 Contributors' Addresses 1566 Anees Shaikh 1567 Google 1568 1600 Amphitheatre Pkwy 1569 Mountain View, CA 94043 1570 United States 1571 Email: aashaikh@google.com 1573 Rob Shakir 1574 Jive Communications, Inc. 1575 1275 W 1600 N, Suite 100 1576 Orem, UT 84057 1577 United States 1578 Email: rjs@rob.sh 1580 Kevin D'Souza 1581 AT&T 1582 200 S. Laurel Ave 1583 Middletown, NJ 1584 United States 1585 Email: kd6913@att.com 1587 Luyuan Fang 1588 Microsoft 1589 205 108th Ave. NE, Suite 400 1590 Bellevue, WA 1591 United States 1592 Email: lufang@microsoft.com 1594 Qin Wu 1595 Huawei Technologies 1596 101 Software Avenue, Yuhua District 1597 Nanjing, Jiangsu 210012 1598 China 1600 Email: bill.wu@huawei.com 1601 Stephane Litkowski 1602 Orange 1603 9 rue du chene germain 1604 Cesson Sevigne 35512 1605 France 1607 Email: stephane.litkowski@orange.com 1609 Gang Yan 1610 Huawei Technologies 1611 Huawei Bld., No.156 Beiqing Rd. 1612 Beijing 100095 1613 China 1615 Email: yangang@huawei.com 1617 Authors' Addresses 1619 Acee Lindem (editor) 1620 Cisco Systems 1621 301 Midenhall Way 1622 Cary, NC 27513 1623 USA 1625 Email: acee@cisco.com 1627 Lou Berger (editor) 1628 LabN Consulting, L.L.C. 1630 Email: lberger@labn.net 1632 Dean Bogdanovic 1634 Email: ivandean@gmail.com 1636 Christan Hopps 1637 Deutsche Telekom 1639 Email: chopps@chopps.org