idnits 2.17.1 draft-rtgyangdt-rtgwg-device-model-04.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 403 has weird spacing: '...rw type ide...' == Line 438 has weird spacing: '...rw type ide...' == Line 463 has weird spacing: '...rw type ide...' == Line 515 has weird spacing: '...rw type ide...' -- The document date (May 17, 2016) is 2901 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I-D.ietf-netmod-acl-model' is mentioned on line 262, but not defined == Missing Reference: 'I-D.ietf-rtgwg-yang-key-chain' is mentioned on line 263, but not defined == Missing Reference: 'I-D.rtgyangdt-rtgwg-lne-model' is mentioned on line 265, but not defined == Missing Reference: 'I-D.rtgyangdt-rtgwg-ni-model' is mentioned on line 266, but not defined ** Obsolete normative reference: RFC 7223 (Obsoleted by RFC 8343) ** Obsolete normative reference: RFC 7277 (Obsoleted by RFC 8344) == Outdated reference: A later version (-06) exists of draft-ietf-netconf-yang-library-05 == Outdated reference: A later version (-04) exists of draft-ietf-netmod-opstate-reqs-03 == Outdated reference: A later version (-25) exists of draft-ietf-netmod-routing-cfg-20 Summary: 2 errors (**), 0 flaws (~~), 12 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: November 18, 2016 LabN Consulting, L.L.C. 6 D. Bogdanovic 8 C. Hopps 9 Deutsche Telekom 10 May 17, 2016 12 Network Device YANG Organizational Models 13 draft-rtgyangdt-rtgwg-device-model-04 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 is derived from work submitted to the IETF by members 26 of the informal OpenConfig working group of network operators and is 27 a product of the Routing Area YANG Architecture design team. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on November 18, 2016. 46 Copyright Notice 48 Copyright (c) 2016 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 1.1. Status of Work and Open Issues . . . . . . . . . . . . . 4 65 2. Module Overview . . . . . . . . . . . . . . . . . . . . . . . 5 66 2.1. Interface Model Components . . . . . . . . . . . . . . . 7 67 2.2. System Management . . . . . . . . . . . . . . . . . . . . 9 68 2.3. Network Services . . . . . . . . . . . . . . . . . . . . 10 69 2.4. OAM Protocols . . . . . . . . . . . . . . . . . . . . . . 11 70 2.5. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 2.6. MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 3. Security Considerations . . . . . . . . . . . . . . . . . . . 12 73 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 74 5. Network Device Model Structure . . . . . . . . . . . . . . . 13 75 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 76 6.1. Normative References . . . . . . . . . . . . . . . . . . 19 77 6.2. Informative References . . . . . . . . . . . . . . . . . 20 78 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 21 79 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 22 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 82 1. Introduction 84 "Operational Structure and Organization of YANG Models" 85 [I-D.openconfig-netmod-model-structure], highlights the value of 86 organizing individual, self-standing YANG [RFC6020] models into a 87 more comprehensive structure. This document builds on that work and 88 presents a derivative structure for use in representing the 89 networking infrastructure aspects of physical and virtual devices. 90 [I-D.openconfig-netmod-model-structure] and earlier versions of this 91 document presented a single device-centric model root, this document 92 no longer contains this element. Such an element would have 93 translated to a single device management model that would be the root 94 of all other models and was judged to be overly restrictive in terms 95 of definition, implementation, and operation. 97 The document presents a notional network device YANG organizational 98 structure that provides a conceptual framework for the models that 99 may be used to configure and operate network devices. The structure 100 is itself presented as a YANG module, with all of the related 101 component modules logically organized in a way that is operationally 102 intuitive. This network device model is not expected to be 103 implemented, but rather provide as context for the identified 104 representative component modules with are expected to be defined, and 105 supported on typical network devices. 107 This document refers to two new modules that are expected to be 108 implemented. These models are defined to support the configuration 109 and operation of network-devices that allow for the partitioning of 110 resources from both, or either, management and networking 111 perspectives. Two forms of resource partitioning are referenced: 113 The first form provides a logical partitioning of a network device 114 where each partition is separately managed as essentially an 115 independent network element which is 'hosted' by the base network 116 device. These hosted network elements are referred to as logical 117 network elements, or LNEs, and are supported by the logical-network- 118 element module defined in [LNE-MODEL]. The module is used to 119 identify LNEs and associate resources from the network-device with 120 each LNE. LNEs themselves are represented in YANG as independent 121 network devices; each accessed independently. Optionally, and when 122 supported by the implementation, they may also be accessed from the 123 host system. Examples of vendor terminology for an LNE include 124 logical system or logical router, and virtual switch, chassis, or 125 fabric. 127 The second form provides support what is commonly referred to as 128 Virtual Routing and Forwarding (VRF) instances as well as Virtual 129 Switch Instances (VSI), see [RFC4026]. In this form of resource 130 partitioning multiple control plane and forwarding/bridging instances 131 are provided by and managed via a single (physical or logical) 132 network device. This form of resource partitioning is referred to as 133 Network Instances and are supported by the network-instance module 134 defined in [NI-MODEL]. Configuration and operation of each network- 135 instance is always via the network device and the network-instance 136 module. 138 This document was motivated by, and derived from, 139 [I-D.openconfig-netmod-model-structure]. The requirements from that 140 document have been combined with the requirements from "Consistent 141 Modeling of Operational State Data in YANG", 143 [I-D.openconfig-netmod-opstate], into "NETMOD Operational State 144 Requirements", [I-D.ietf-netmod-opstate-reqs]. This document is 145 aimed at the requirement related to a common model-structure, 146 currently Requirement 7, and also aims to provide a modeling base for 147 Operational State representation. 149 The approach taken in this (and the original) document is to organize 150 the models describing various aspects of network infrastructure, 151 focusing on devices, their subsystems, and relevant protocols 152 operating at the link and network layers. The proposal does not 153 consider a common model for higher level network services. We focus 154 on the set of models that are commonly used by network operators, and 155 suggest a corresponding organization. 157 A significant portion of the text and model contained in this 158 document was taken from the -00 of 159 [I-D.openconfig-netmod-model-structure]. 161 1.1. Status of Work and Open Issues 163 This version of the document and structure are a product of the 164 Routing Area YANG Architecture design team and is very much a work in 165 progress rather than a final proposal. This version is a major 166 change from the prior version and this change was enabled by the work 167 on the previously mentioned Schema Mount. 169 Schema Mount enables a dramatic simplification of the presented 170 device model, particularly for "lower-end" devices which are unlikely 171 to support multiple network instances or logical network elements. 172 Should structural-mount/YSDL not be available, the more explicit tree 173 structure presented in earlier versions of this document will need to 174 be utilized. 176 The top open issues are: 178 1. This document will need to match the evolution and 179 standardization of [I-D.openconfig-netmod-opstate] or 180 [I-D.ietf-netmod-opstate-reqs] by the Netmod WG. 182 2. Interpretation of different policy containers requires 183 clarification. 185 3. It may make sense to use the identityref structuring with 186 hardware and QoS model. 188 4. Which document(s) define the base System management, network 189 services, and oam protocols modules is TBD. This includes the 190 possibility of simply using RFC7317 in place of the presented 191 System management module. 193 5. The model will be updated once the "opstate" requirements are 194 addressed. 196 2. Module Overview 198 In this document, we consider network devices that support protocols 199 and functions defined within the IETF Routing Area, e.g, routers, 200 firewalls and hosts. Such devices may be physical or virtual, e.g., 201 a classic router with custom hardware or one residing within a 202 server-based virtual machine implementing a virtual network function 203 (VNF). Each device may sub-divide their resources into logical 204 network elements (LNEs) each of which provides a managed logical 205 device. Examples of vendor terminology for an LNE include logical 206 system or logical router, and virtual switch, chassis, or fabric. 207 Each LNE may also support virtual routing and forwarding (VRF) and 208 virtual switching instance (VSI) functions, which are referred to 209 below as a network instances (NIs). This breakdown is represented in 210 Figure 1. 212 ,''''''''''''''''''''''''''''''''''''''''''''''`. 213 | Network Device (Physical or Virtual) | 214 | ..................... ..................... | 215 | : Logical Network : : Logical Network : | 216 | : Element : : Element : | 217 | :+-----+-----+-----+: :+-----+-----+-----+: | 218 | :| Net | Net | Net |: :| Net | Net | Net |: | 219 | :|Inst.|Inst.|Inst.|: :|Inst.|Inst.|Inst.|: | 220 | :+-----+-----+-----+: :+-----+-----+-----+: | 221 | : | | | | | | : : | | | | | | : | 222 | :..|.|...|.|...|.|..: :..|.|...|.|...|.|..: | 223 | | | | | | | | | | | | | | 224 `'''|'|'''|'|'''|'|'''''''''|'|'''|'|'''|'|''''' 225 | | | | | | | | | | | | 226 Interfaces Interfaces 228 Figure 1: Module Element Relationships 230 A model for LNEs is described in [LNE-MODEL] and the model for 231 network instances is covered in [NI-MODEL]. 233 The presented notional network device module can itself be thought of 234 as a "meta-model" as it describes the relationships between 235 individual models. We choose to represent it also as a simple YANG 236 module consisting of other models, which are in fact independent top 237 level individual models. Although it is never expected to be 238 implemented. 240 The presented modules do not follow the hierarchy of any Particular 241 implementation, and hence is vendor-neutral. Nevertheless, the 242 structure should be familiar to network operators and also readily 243 mapped to vendor implementations. 245 The overall structure is: 247 module: ietf-network-device 248 +--rw modules-state [I-D.ietf-netconf-yang-library] 249 | 250 +--rw interfaces [RFC7223] 251 +--rw hardware 252 +--rw qos 253 | 254 +--rw system-management [RFC7317 or derived] 255 +--rw network-services 256 +--rw oam-protocols 257 | 258 +--rw routing [I-D.ietf-netmod-routing-cfg] 259 +--rw mpls 260 +--rw ieee-dot1Q 261 | 262 +--rw acls [I-D.ietf-netmod-acl-model] 263 +--rw key-chains [I-D.ietf-rtgwg-yang-key-chain] 264 | 265 +--rw logical-network-elements [I-D.rtgyangdt-rtgwg-lne-model] 266 +--rw network-instances [I-D.rtgyangdt-rtgwg-ni-model] 268 The network device is composed of top level modules that can be used 269 to configure and operate a network device. (This is a significant 270 difference from earlier versions of this document where there was a 271 strict model hierarchy.) Importantly the network device structure is 272 the same for a physical network device or a logical network device, 273 such as those instantiated via the logical-network-element model. 274 Extra spacing is included to denote different types of modules 275 included. 277 YANG library [I-D.ietf-netconf-yang-library] is included as it used 278 to identify details of the top level modules supported by the 279 (physical or logical) network device. Th ability to identify 280 supported modules is particularly important for LNEs which may have a 281 set of supported modules which differs from the set supported by the 282 host network device. 284 The interface management model [RFC7223] is included at the top 285 level. The hardware module is a placeholder for a future device- 286 specific configuration and operational state data model. For 287 example, a common structure for the hardware model might include 288 chassis, line cards, and ports, but we leave this unspecified. The 289 quality of service (QoS) section is also a placeholder module for 290 device configuration and operational state data which relates to the 291 treatment of traffic across the device. This document references 292 augmentations to the interface module to support LNEs and NIs. 293 Similar elements, although perhaps only for LNEs, may also need to be 294 included as part of the definition of the future hardware and QoS 295 modules. 297 System management, network services, and oam protocols represent new 298 top level modules that are used to organize data models of similar 299 functions. Additional information on each is provided below. 301 The routing and MPLS modules provide core support for the 302 configuration and operation of a devices control plane and data plane 303 functions. IEEE dot1Q [IEEE-8021Q] is an example of another module 304 that provides similar functions for VLAN bridging, and other similar 305 modules are also possible. Each of these modules is expected to be 306 LNE and NI unaware, and to be instantiated as needed as part of the 307 LNE and NI configuration and operation supported by the logical- 308 network-element and network-instance modules. (Note that this is a 309 change from [I-D.ietf-netmod-routing-cfg] which is currently defined 310 with VRF/NI semantics.) 312 The access control list (ACL) and key chain modules are included as 313 examples of other top level modules that may be supported by a 314 network device. 316 The logical network element and network instance modules enable LNEs 317 and NIs respectively and are defined below. 319 2.1. Interface Model Components 321 Interfaces are a crucial part of any network device's configuration 322 and operational state. They generally include a combination of raw 323 physical interfaces, link-layer interfaces, addressing configuration, 324 and logical interfaces that may not be tied to any physical 325 interface. Several system services, and layer 2 and layer 3 326 protocols may also associate configuration or operational state data 327 with different types of interfaces (these relationships are not shown 328 for simplicity). The interface management model is defined by 329 [RFC7223]. 331 The logical-network-element and network-instance modules defined in 332 [LNE-MODEL] and [NI-MODEL] augment the existing interface management 333 model in two ways: The first, by the logical-network-element module, 334 adds an identifier which is used on physical interface types to 335 identify an associated LNE. The second, by the network-instance 336 module, adds a name which is used on interface or sub-interface types 337 to identify an associated network instance. Similarly, this name is 338 also added for IPv4 and IPv6 types, as defined in [RFC7277]. 340 The interface related augmentations are as follows: 342 module: ietf-logical-network-element 343 augment /if:interfaces/if:interface: 344 +--rw bind-lne-name? string 346 module: ietf-network-instance 347 augment /if:interfaces/if:interface: 348 +--rw bind-network-instance-name? string 349 augment /if:interfaces/if:interface/ip:ipv4: 350 +--rw bind-network-instance-name? string 351 augment /if:interfaces/if:interface/ip:ipv6: 352 +--rw bind-network-instance-name? string 354 The following is an example of envisioned combined usage. The 355 interfaces container includes a number of commonly used components as 356 examples: 358 +--rw if:interfaces 359 | +--rw interface* [name] 360 | +--rw name string 361 | +--rw lne:bind-lne-name? string 362 | +--rw ethernet 363 | | +--rw ni:bind-network-instance-name? string 364 | | +--rw aggregates 365 | | +--rw rstp 366 | | +--rw lldp 367 | | +--rw ptp 368 | +--rw vlans 369 | +--rw tunnels 370 | +--rw ipv4 371 | | +--rw ni:bind-network-instance-name? string 372 | | +--rw arp 373 | | +--rw icmp 374 | | +--rw vrrp 375 | | +--rw dhcp-client 376 | +--rw ipv6 377 | +--rw ni:bind-network-instance-name? string 378 | +--rw vrrp 379 | +--rw icmpv6 380 | +--rw nd 381 | +--rw dhcpv6-client 383 The [RFC7223] defined interface model is structured to include all 384 interfaces in a flat list, without regard to logical or virtual 385 instances (e.g., VRFs) supported on the device. The bind-lne-name 386 and bind-network-instance-name leaves provide the association between 387 an interface and its associated LNE and NI (e.g., VRF or VSI). 389 2.2. System Management 391 [Editor's note: need to discuss and resolve relationship between this 392 structure and RFC7317 and determine if 7317 is close enough to simply 393 use as is.] 395 System management is expected to reuse definitions contained in 396 [RFC7317]. It is expected to be instantiated per device and LNE. 397 Its structure is shown below: 399 module: ietf-network-device 400 +--rw system-management 401 | +--rw system-management-global 402 | +--rw system-management-protocol* [type] 403 | +--rw type identityref 405 System-management-global is used for configuration information and 406 state that is independent of a particular management protocol. 407 System-management-protocol is a list of management protocol specific 408 elements. The type-specific sub-modules are expected to be defined. 410 The following is an example of envisioned usage: 412 module: ietf-network-device 413 +--rw system-management 414 +--rw system-management-global 415 | +--rw statistics-collection 416 | ... 417 +--rw system-management-protocol* [type] 418 | +--rw type=syslog 419 | +--rw type=dns 420 | +--rw type=ntp 421 | +--rw type=ssh 422 | +--rw type=tacacs 423 | +--rw type=snmp 424 | +--rw type=netconf 426 2.3. Network Services 428 A device may provide different network services to other devices, for 429 example a device my act as a DHCP server. The model may be 430 instantiated per device, LNE, and NI. An identityref is used to 431 identify the type of specific service being provided and its 432 associated configuration and state information. The defined 433 structure is as follows: 435 module: ietf-network-device 436 +--rw network-services 437 | +--rw network-service* [type] 438 | +--rw type identityref 440 The following is an example of envisioned usage: Examples shown below 441 include a device-based Network Time Protocol (NTP) server, a Domain 442 Name System (DNS) server, and a Dynamic Host Configuration Protocol 443 (DHCP) server: 445 module: ietf-network-device 446 +--rw network-services 447 +--rw network-service* [type] 448 +--rw type=ntp-server 449 +--rw type=dns-server 450 +--rw type=dhcp-server 452 2.4. OAM Protocols 454 OAM protocols that may run within the context of a device are grouped 455 within the oam-protocols model. The model may be instantiated per 456 device, LNE, and NI. An identifyref is used to identify the 457 information and state that may relate to a specific OAM protocol. 458 The defined structure is as follows: 460 module: ietf-network-device 461 +--rw oam-protocols 462 +--rw oam-protocol* [type] 463 +--rw type identityref 465 The following is an example of envisioned usage. Examples shown 466 below include Bi-directional Forwarding Detection (BFD), Ethernet 467 Connectivity Fault Management (CFM), and Two-Way Active Measurement 468 Protocol (TWAMP): 470 module: ietf-network-device 471 +--rw oam-protocols 472 +--rw oam-protocol* [type] 473 +--rw type=bfd 474 +--rw type=cfm 475 +--rw type=twamp 477 2.5. Routing 479 Routing protocol and IP forwarding configuration and operation 480 information is modeled via a routing model, such as the one defined 481 in [I-D.ietf-netmod-routing-cfg]. 483 The routing module is expected to include all IETF defined control 484 plane protocols, such as BGP, OSPF, LDP and RSVP-TE. It is also 485 expected to support configuration and operation of or more routing 486 information bases (RIB). A RIB is a list of routes complemented with 487 administrative data. Finally, policy is expected to be represented 488 within each control plane protocol and RIB. 490 The anticipated structure is as follows: 492 module: ietf-network-device 493 +--rw rt:routing [I-D.ietf-netmod-routing-cfg] 494 +--rw control-plane-protocol* [type] 495 | +--rw type identityref 496 | +--rw policy 497 +--rw rib* [name] 498 +--rw name string 499 +--rw description? string 500 +--rw policy 502 2.6. MPLS 504 MPLS data plane related information is grouped together, as with the 505 previously discussed modules, is unaware of VRFs/NIs. The model may 506 be instantiated per device, LNE, and NI. MPLS control plane 507 protocols are expected to be included in Section 2.5. MPLS may reuse 508 and build on [I-D.openconfig-mpls-consolidated-model] or other 509 emerging models and has an anticipated structure as follows: 511 module: ietf-network-device 512 +--rw mpls 513 +--rw global 514 +--rw lsps* [type] 515 +--rw type identityref 517 Type refers to LSP type, such as static, traffic engineered or 518 routing congruent. The following is an example of such usage: 520 module: ietf-network-device 521 +--rw mpls 522 +--rw global 523 +--rw lsps* [type] 524 +--rw type=static 525 +--rw type=constrained-paths 526 +--rw type=igp-congruent 528 3. Security Considerations 530 The network-device model structure described in this document does 531 not define actual configuration and state data, hence it is not 532 directly responsible for security risks. 534 Each of the component models that provide the corresponding 535 configuration and state data should be considered sensitive from a 536 security standpoint since they generally manipulate aspects of 537 network configurations. Each component model should be carefully 538 evaluated to determine its security risks, along with mitigations to 539 reduce such risks. 541 LNE portion is TBD 543 NI portion is TBD 545 4. IANA Considerations 547 This YANG model currently uses a temporary ad-hoc namespace. If it 548 is placed or redirected for the standards track, an appropriate 549 namespace URI will be registered in the "IETF XML Registry" 550 [RFC3688]. The YANG structure modules will be registered in the 551 "YANG Module Names" registry [RFC6020]. 553 5. Network Device Model Structure 555 file "ietf-network-device@2016-05-01.yang" 556 module ietf-network-device { 558 yang-version "1"; 560 // namespace 561 namespace "urn:ietf:params:xml:ns:yang:ietf-network-device"; 563 prefix "nd"; 565 // import some basic types 567 // meta 568 organization "IETF RTG YANG Design Team Collaboration 569 with OpenConfig"; 571 contact 572 "Routing Area YANG Architecture Design Team - 573 "; 575 description 576 "This module describes a model structure for YANG 577 configuration and operational state data models. Its intent is 578 to describe how individual device protocol and feature models 579 fit together and interact."; 581 revision "2016-05-01" { 582 description 583 "IETF Routing YANG Design Team Meta-Model"; 584 reference "TBD"; 585 } 587 // extension statements 588 // identity statements 590 identity oam-protocol-type { 591 description 592 "Base identity for derivation of OAM protocols"; 593 } 595 identity network-service-type { 596 description 597 "Base identity for derivation of network services"; 598 } 600 identity system-management-protocol-type { 601 description 602 "Base identity for derivation of system management 603 protocols"; 604 } 606 identity oam-service-type { 607 description 608 "Base identity for derivation of Operations, 609 Administration, and Maintenance (OAM) services."; 610 } 612 identity control-plane-protocol-type { 613 description 614 "Base identity for derivation of control-plane protocols"; 615 } 617 identity mpls-lsp-type { 618 description 619 "Base identity for derivation of MPLS LSP typs"; 620 } 622 // typedef statements 624 // grouping statements 626 grouping ribs { 627 description 628 "Routing Information Bases (RIBs) supported by a 629 network-instance"; 630 container ribs { 631 description 632 "RIBs supported by a network-instance"; 633 list rib { 634 key "name"; 635 min-elements "1"; 636 description 637 "Each entry represents a RIB identified by the 638 'name' key. All routes in a RIB must belong to the 639 same address family. 641 For each routing instance, an implementation should 642 provide one system-controlled default RIB for each 643 supported address family."; 644 leaf name { 645 type string; 646 description 647 "The name of the RIB."; 648 } 649 reference "draft-ietf-netmod-routing-cfg"; 650 leaf description { 651 type string; 652 description 653 "Description of the RIB"; 654 } 655 // Note that there is no list of interfaces within 656 container policy { 657 description "Policy specific to RIB"; 658 } 659 } 660 } 661 } 663 // top level device definition statements 664 container ietf-yang-library { 665 description 666 "YANG Module Library as defined in 667 draft-ietf-netconf-yang-library"; 668 } 670 container interfaces { 671 description 672 "Interface list as defined by RFC7223/RFC7224"; 673 } 675 container hardware { 676 description 677 "Hardware / vendor-specific data relevant to the platform. 678 This container is an anchor point for platform-specific 679 configuration and operational state data. It may be further 680 organized into chassis, line cards, ports, etc. It is 681 expected that vendor or platform-specific augmentations 682 would be used to populate this part of the device model"; 683 } 684 container qos { 685 description "QoS features, for example policing, shaping, etc."; 686 } 688 container system-management { 689 description 690 "System management for physical or virtual device."; 691 container system-management-global { 692 description "System management - with reuse of RFC 7317"; 693 } 694 list system-management-protocol { 695 key "type"; 696 leaf type { 697 type identityref { 698 base system-management-protocol-type; 699 } 700 mandatory true; 701 description 702 "Syslog, ssh, TACAC+, SNMP, NETCONF, etc."; 703 } 704 description "List of system management protocol 705 configured for a logical network 706 element."; 707 } 708 } 710 container network-services { 711 description 712 "Container for list of configured network 713 services."; 714 list network-service { 715 key "type"; 716 description 717 "List of network services configured for a 718 network instance."; 719 leaf type { 720 type identityref { 721 base network-service-type; 722 } 723 mandatory true; 724 description 725 "The network service type supported within 726 a network instance, e.g., NTP server, DNS 727 server, DHCP server, etc."; 728 } 729 } 730 } 731 container oam-protocols { 732 description 733 "Container for configured OAM protocols."; 734 list oam-protocol { 735 key "type"; 736 leaf type { 737 type identityref { 738 base oam-protocol-type; 739 } 740 mandatory true; 741 description 742 "The Operations, Administration, and 743 Maintenance (OAM) protocol type, e.g., BFD, 744 TWAMP, CFM, etc."; 745 } 746 description 747 "List of configured OAM protocols."; 748 } 749 } 751 container routing { 752 description 753 "The YANG Data Model for Routing Management revised to be 754 Network Instance / VRF independent. "; 755 // Note that there is no routing or network instance 756 list control-plane-protocol { 757 key "type"; 758 description 759 "List of control plane protocols configured for 760 a network instance."; 761 leaf type { 762 type identityref { 763 base control-plane-protocol-type; 764 } 765 description 766 "The control plane protocol type, e.g., BGP, 767 OSPF IS-IS, etc"; 768 } 769 container policy { 770 description 771 "Protocol specific policy, 772 reusing [RTG-POLICY]"; 773 } 774 } 775 list rib { 776 key "name"; 777 min-elements "1"; 778 description 779 "Each entry represents a RIB identified by the 780 'name' key. All routes in a RIB must belong to the 781 same address family. 783 For each routing instance, an implementation should 784 provide one system-controlled default RIB for each 785 supported address family."; 786 leaf name { 787 type string; 788 description 789 "The name of the RIB."; 790 } 791 reference "draft-ietf-netmod-routing-cfg"; 792 leaf description { 793 type string; 794 description 795 "Description of the RIB"; 796 } 797 // Note that there is no list of interfaces within 798 container policy { 799 description "Policy specific to RIB"; 800 } 801 } 802 } 804 container mpls { 805 description "MPLS and TE configuration"; 806 container global { 807 description "Global MPLS configuration"; 808 } 809 list lsps { 810 key "type"; 811 description 812 "List of LSP types."; 813 leaf type { 814 type identityref { 815 base mpls-lsp-type; 816 } 817 mandatory true; 818 description 819 "MPLS and Traffic Engineering protocol LSP types, 820 static, LDP/SR (igp-congruent), 821 RSVP TE (constrained-paths) , etc."; 822 } 823 } 824 } 826 container ieee-dot1Q { 827 description 828 "The YANG Data Model for VLAN bridges as defined by the IEEE"; 829 } 831 container ietf-acl { 832 description "Packet Access Control Lists (ACLs) as specified 833 in draft-ietf-netmod-acl-model"; 834 } 836 container ietf-key-chain { 837 description "Key chains as specified in 838 draft-ietf-rtgwg-yang-key-chain;"; 839 } 841 container logical-network-element { 842 description 843 "This module is used to support multiple logical network 844 elements on a single physical or virtual system."; 845 } 847 container network-instance { 848 description 849 "This module is used to support multiple network instances 850 within a single physical or virtual device. Network 851 instances are commonly know as VRFs (virtual routing 852 and forwarding) and VSIs (virtual switching instances)."; 853 } 854 // rpc statements 856 // notification statements 858 } 859 861 6. References 863 6.1. Normative References 865 [LNE-MODEL] 866 Berger, L., Hopps, C., Lindem, A., and D. Bogdanovic, 867 "Logical Network Element Model", draft-rtgyangdt-rtgwg- 868 lne-model-00.txt (work in progress), May 2016. 870 [NI-MODEL] 871 Berger, L., Hopps, C., Lindem, A., and D. Bogdanovic, 872 "Network Instance Model", draft-rtgyangdt-rtgwg-ni-model- 873 00.txt (work in progress), May 2016. 875 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 876 DOI 10.17487/RFC3688, January 2004, 877 . 879 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 880 Private Network (VPN) Terminology", RFC 4026, 881 DOI 10.17487/RFC4026, March 2005, 882 . 884 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 885 the Network Configuration Protocol (NETCONF)", RFC 6020, 886 DOI 10.17487/RFC6020, October 2010, 887 . 889 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 890 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 891 . 893 [RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", 894 RFC 7277, DOI 10.17487/RFC7277, June 2014, 895 . 897 [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for 898 System Management", RFC 7317, DOI 10.17487/RFC7317, August 899 2014, . 901 6.2. Informative References 903 [I-D.ietf-netconf-yang-library] 904 Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module 905 Library", draft-ietf-netconf-yang-library-05 (work in 906 progress), April 2016. 908 [I-D.ietf-netmod-opstate-reqs] 909 Watsen, K. and T. Nadeau, "Terminology and Requirements 910 for Enhanced Handling of Operational State", draft-ietf- 911 netmod-opstate-reqs-03 (work in progress), January 2016. 913 [I-D.ietf-netmod-routing-cfg] 914 Lhotka, L. and A. Lindem, "A YANG Data Model for Routing 915 Management", draft-ietf-netmod-routing-cfg-20 (work in 916 progress), October 2015. 918 [I-D.openconfig-mpls-consolidated-model] 919 George, J., Fang, L., eric.osborne@level3.com, e., and R. 920 Shakir, "MPLS / TE Model for Service Provider Networks", 921 draft-openconfig-mpls-consolidated-model-02 (work in 922 progress), October 2015. 924 [I-D.openconfig-netmod-model-structure] 925 Shaikh, A., Shakir, R., D'Souza, K., and L. Fang, 926 "Operational Structure and Organization of YANG Models", 927 draft-openconfig-netmod-model-structure-00 (work in 928 progress), March 2015. 930 [I-D.openconfig-netmod-opstate] 931 Shakir, R., Shaikh, A., and M. Hines, "Consistent Modeling 932 of Operational State Data in YANG", draft-openconfig- 933 netmod-opstate-01 (work in progress), July 2015. 935 [IEEE-8021Q] 936 Holness, M., "IEEE 802.1Q YANG Module Specifications", 937 IEEE-Draft http://www.ieee802.org/1/files/public/docs2015/ 938 new-mholness-yang-8021Q-0515-v04.pdf, May 2015. 940 Appendix A. Acknowledgments 942 This document is derived from draft-openconfig-netmod-model- 943 structure-00. The Authors of that document who are not also authors 944 of this document are listed as Contributors to this work. 946 The original stated: The authors are grateful for valuable 947 contributions to this document and the associated models from: Deepak 948 Bansal, Paul Borman, Chris Chase, Josh George, Marcus Hines, and Jim 949 Uttaro. 951 The Routing Area Yang Architecture design team members included Acee 952 Lindem, Anees Shaikh, Christian Hopps, Dean Bogdanovic, Lou Berger, 953 Qin Wu, Rob Shakir, Stephane Litkowski, and Yan Gang. 955 The identityref approach was proposed by Mahesh Jethanandani. 957 The RFC text was produced using Marshall Rose's xml2rfc tool. 959 Appendix B. Contributors 961 Contributors' Addresses 963 Anees Shaikh 964 Google 965 1600 Amphitheatre Pkwy 966 Mountain View, CA 94043 967 United States 968 Email: aashaikh@google.com 970 Rob Shakir 971 Jive Communications, Inc. 972 1275 W 1600 N, Suite 100 973 Orem, UT 84057 974 United States 975 Email: rjs@rob.sh 977 Kevin D'Souza 978 AT&T 979 200 S. Laurel Ave 980 Middletown, NJ 981 United States 982 Email: kd6913@att.com 984 Luyuan Fang 985 Microsoft 986 205 108th Ave. NE, Suite 400 987 Bellevue, WA 988 United States 989 Email: lufang@microsoft.com 991 Qin Wu 992 Huawei Technologies 993 101 Software Avenue, Yuhua District 994 Nanjing, Jiangsu 210012 995 China 997 Email: bill.wu@huawei.com 998 Stephane Litkowski 999 Orange 1000 9 rue du chene germain 1001 Cesson Sevigne 35512 1002 France 1004 Email: stephane.litkowski@orange.com 1006 Gang Yan 1007 Huawei Technologies 1008 Huawei Bld., No.156 Beiqing Rd. 1009 Beijing 100095 1010 China 1012 Email: yangang@huawei.com 1014 Authors' Addresses 1016 Acee Lindem (editor) 1017 Cisco Systems 1018 301 Midenhall Way 1019 Cary, NC 27513 1020 USA 1022 Email: acee@cisco.com 1024 Lou Berger (editor) 1025 LabN Consulting, L.L.C. 1027 Email: lberger@labn.net 1029 Dean Bogdanovic 1031 Email: ivandean@gmail.com 1033 Christan Hopps 1034 Deutsche Telekom 1036 Email: chopps@chopps.org