idnits 2.17.1 draft-ietf-rtgwg-device-model-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 402 has weird spacing: '...rw type ide...' == Line 437 has weird spacing: '...rw type ide...' == Line 462 has weird spacing: '...rw type ide...' == Line 514 has weird spacing: '...rw type ide...' -- The document date (August 2, 2016) is 2814 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 261, but not defined == Missing Reference: 'I-D.ietf-rtgwg-yang-key-chain' is mentioned on line 262, but not defined == Missing Reference: 'I-D.rtgyangdt-rtgwg-lne-model' is mentioned on line 264, but not defined == Missing Reference: 'I-D.rtgyangdt-rtgwg-ni-model' is mentioned on line 265, 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: February 3, 2017 LabN Consulting, L.L.C. 6 D. Bogdanovic 8 C. Hopps 9 Deutsche Telekom 10 August 2, 2016 12 Network Device YANG Organizational Models 13 draft-ietf-rtgwg-device-model-00 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 February 3, 2017. 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 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 81 1. Introduction 83 "Operational Structure and Organization of YANG Models" 84 [I-D.openconfig-netmod-model-structure], highlights the value of 85 organizing individual, self-standing YANG [RFC6020] models into a 86 more comprehensive structure. This document builds on that work and 87 presents a derivative structure for use in representing the 88 networking infrastructure aspects of physical and virtual devices. 89 [I-D.openconfig-netmod-model-structure] and earlier versions of this 90 document presented a single device-centric model root, this document 91 no longer contains this element. Such an element would have 92 translated to a single device management model that would be the root 93 of all other models and was judged to be overly restrictive in terms 94 of definition, implementation, and operation. 96 The document presents a notional network device YANG organizational 97 structure that provides a conceptual framework for the models that 98 may be used to configure and operate network devices. The structure 99 is itself presented as a YANG module, with all of the related 100 component modules logically organized in a way that is operationally 101 intuitive. This network device model is not expected to be 102 implemented, but rather provide as context for the identified 103 representative component modules with are expected to be defined, and 104 supported on typical network devices. 106 This document refers to two new modules that are expected to be 107 implemented. These models are defined to support the configuration 108 and operation of network-devices that allow for the partitioning of 109 resources from both, or either, management and networking 110 perspectives. Two forms of resource partitioning are referenced: 112 The first form provides a logical partitioning of a network device 113 where each partition is separately managed as essentially an 114 independent network element which is 'hosted' by the base network 115 device. These hosted network elements are referred to as logical 116 network elements, or LNEs, and are supported by the logical-network- 117 element module defined in [LNE-MODEL]. The module is used to 118 identify LNEs and associate resources from the network-device with 119 each LNE. LNEs themselves are represented in YANG as independent 120 network devices; each accessed independently. Optionally, and when 121 supported by the implementation, they may also be accessed from the 122 host system. Examples of vendor terminology for an LNE include 123 logical system or logical router, and virtual switch, chassis, or 124 fabric. 126 The second form provides support what is commonly referred to as 127 Virtual Routing and Forwarding (VRF) instances as well as Virtual 128 Switch Instances (VSI), see [RFC4026]. In this form of resource 129 partitioning multiple control plane and forwarding/bridging instances 130 are provided by and managed via a single (physical or logical) 131 network device. This form of resource partitioning is referred to as 132 Network Instances and are supported by the network-instance module 133 defined in [NI-MODEL]. Configuration and operation of each network- 134 instance is always via the network device and the network-instance 135 module. 137 This document was motivated by, and derived from, 138 [I-D.openconfig-netmod-model-structure]. The requirements from that 139 document have been combined with the requirements from "Consistent 140 Modeling of Operational State Data in YANG", 142 [I-D.openconfig-netmod-opstate], into "NETMOD Operational State 143 Requirements", [I-D.ietf-netmod-opstate-reqs]. This document is 144 aimed at the requirement related to a common model-structure, 145 currently Requirement 7, and also aims to provide a modeling base for 146 Operational State representation. 148 The approach taken in this (and the original) document is to organize 149 the models describing various aspects of network infrastructure, 150 focusing on devices, their subsystems, and relevant protocols 151 operating at the link and network layers. The proposal does not 152 consider a common model for higher level network services. We focus 153 on the set of models that are commonly used by network operators, and 154 suggest a corresponding organization. 156 A significant portion of the text and model contained in this 157 document was taken from the -00 of 158 [I-D.openconfig-netmod-model-structure]. 160 1.1. Status of Work and Open Issues 162 This version of the document and structure are a product of the 163 Routing Area YANG Architecture design team and is very much a work in 164 progress rather than a final proposal. This version is a major 165 change from the prior version and this change was enabled by the work 166 on the previously mentioned Schema Mount. 168 Schema Mount enables a dramatic simplification of the presented 169 device model, particularly for "lower-end" devices which are unlikely 170 to support multiple network instances or logical network elements. 171 Should structural-mount/YSDL not be available, the more explicit tree 172 structure presented in earlier versions of this document will need to 173 be utilized. 175 The top open issues are: 177 1. This document will need to match the evolution and 178 standardization of [I-D.openconfig-netmod-opstate] or 179 [I-D.ietf-netmod-opstate-reqs] by the Netmod WG. 181 2. Interpretation of different policy containers requires 182 clarification. 184 3. It may make sense to use the identityref structuring with 185 hardware and QoS model. 187 4. Which document(s) define the base System management, network 188 services, and oam protocols modules is TBD. This includes the 189 possibility of simply using RFC7317 in place of the presented 190 System management module. 192 5. The model will be updated once the "opstate" requirements are 193 addressed. 195 2. Module Overview 197 In this document, we consider network devices that support protocols 198 and functions defined within the IETF Routing Area, e.g, routers, 199 firewalls and hosts. Such devices may be physical or virtual, e.g., 200 a classic router with custom hardware or one residing within a 201 server-based virtual machine implementing a virtual network function 202 (VNF). Each device may sub-divide their resources into logical 203 network elements (LNEs) each of which provides a managed logical 204 device. Examples of vendor terminology for an LNE include logical 205 system or logical router, and virtual switch, chassis, or fabric. 206 Each LNE may also support virtual routing and forwarding (VRF) and 207 virtual switching instance (VSI) functions, which are referred to 208 below as a network instances (NIs). This breakdown is represented in 209 Figure 1. 211 ,''''''''''''''''''''''''''''''''''''''''''''''`. 212 | Network Device (Physical or Virtual) | 213 | ..................... ..................... | 214 | : Logical Network : : Logical Network : | 215 | : Element : : Element : | 216 | :+-----+-----+-----+: :+-----+-----+-----+: | 217 | :| Net | Net | Net |: :| Net | Net | Net |: | 218 | :|Inst.|Inst.|Inst.|: :|Inst.|Inst.|Inst.|: | 219 | :+-----+-----+-----+: :+-----+-----+-----+: | 220 | : | | | | | | : : | | | | | | : | 221 | :..|.|...|.|...|.|..: :..|.|...|.|...|.|..: | 222 | | | | | | | | | | | | | | 223 `'''|'|'''|'|'''|'|'''''''''|'|'''|'|'''|'|''''' 224 | | | | | | | | | | | | 225 Interfaces Interfaces 227 Figure 1: Module Element Relationships 229 A model for LNEs is described in [LNE-MODEL] and the model for 230 network instances is covered in [NI-MODEL]. 232 The presented notional network device module can itself be thought of 233 as a "meta-model" as it describes the relationships between 234 individual models. We choose to represent it also as a simple YANG 235 module consisting of other models, which are in fact independent top 236 level individual models. Although it is never expected to be 237 implemented. 239 The presented modules do not follow the hierarchy of any Particular 240 implementation, and hence is vendor-neutral. Nevertheless, the 241 structure should be familiar to network operators and also readily 242 mapped to vendor implementations. 244 The overall structure is: 246 module: ietf-network-device 247 +--rw modules-state [I-D.ietf-netconf-yang-library] 248 | 249 +--rw interfaces [RFC7223] 250 +--rw hardware 251 +--rw qos 252 | 253 +--rw system-management [RFC7317 or derived] 254 +--rw network-services 255 +--rw oam-protocols 256 | 257 +--rw routing [I-D.ietf-netmod-routing-cfg] 258 +--rw mpls 259 +--rw ieee-dot1Q 260 | 261 +--rw acls [I-D.ietf-netmod-acl-model] 262 +--rw key-chains [I-D.ietf-rtgwg-yang-key-chain] 263 | 264 +--rw logical-network-elements [I-D.rtgyangdt-rtgwg-lne-model] 265 +--rw network-instances [I-D.rtgyangdt-rtgwg-ni-model] 267 The network device is composed of top level modules that can be used 268 to configure and operate a network device. (This is a significant 269 difference from earlier versions of this document where there was a 270 strict model hierarchy.) Importantly the network device structure is 271 the same for a physical network device or a logical network device, 272 such as those instantiated via the logical-network-element model. 273 Extra spacing is included to denote different types of modules 274 included. 276 YANG library [I-D.ietf-netconf-yang-library] is included as it used 277 to identify details of the top level modules supported by the 278 (physical or logical) network device. Th ability to identify 279 supported modules is particularly important for LNEs which may have a 280 set of supported modules which differs from the set supported by the 281 host network device. 283 The interface management model [RFC7223] is included at the top 284 level. The hardware module is a placeholder for a future device- 285 specific configuration and operational state data model. For 286 example, a common structure for the hardware model might include 287 chassis, line cards, and ports, but we leave this unspecified. The 288 quality of service (QoS) section is also a placeholder module for 289 device configuration and operational state data which relates to the 290 treatment of traffic across the device. This document references 291 augmentations to the interface module to support LNEs and NIs. 292 Similar elements, although perhaps only for LNEs, may also need to be 293 included as part of the definition of the future hardware and QoS 294 modules. 296 System management, network services, and oam protocols represent new 297 top level modules that are used to organize data models of similar 298 functions. Additional information on each is provided below. 300 The routing and MPLS modules provide core support for the 301 configuration and operation of a devices control plane and data plane 302 functions. IEEE dot1Q [IEEE-8021Q] is an example of another module 303 that provides similar functions for VLAN bridging, and other similar 304 modules are also possible. Each of these modules is expected to be 305 LNE and NI unaware, and to be instantiated as needed as part of the 306 LNE and NI configuration and operation supported by the logical- 307 network-element and network-instance modules. (Note that this is a 308 change from [I-D.ietf-netmod-routing-cfg] which is currently defined 309 with VRF/NI semantics.) 311 The access control list (ACL) and key chain modules are included as 312 examples of other top level modules that may be supported by a 313 network device. 315 The logical network element and network instance modules enable LNEs 316 and NIs respectively and are defined below. 318 2.1. Interface Model Components 320 Interfaces are a crucial part of any network device's configuration 321 and operational state. They generally include a combination of raw 322 physical interfaces, link-layer interfaces, addressing configuration, 323 and logical interfaces that may not be tied to any physical 324 interface. Several system services, and layer 2 and layer 3 325 protocols may also associate configuration or operational state data 326 with different types of interfaces (these relationships are not shown 327 for simplicity). The interface management model is defined by 328 [RFC7223]. 330 The logical-network-element and network-instance modules defined in 331 [LNE-MODEL] and [NI-MODEL] augment the existing interface management 332 model in two ways: The first, by the logical-network-element module, 333 adds an identifier which is used on physical interface types to 334 identify an associated LNE. The second, by the network-instance 335 module, adds a name which is used on interface or sub-interface types 336 to identify an associated network instance. Similarly, this name is 337 also added for IPv4 and IPv6 types, as defined in [RFC7277]. 339 The interface related augmentations are as follows: 341 module: ietf-logical-network-element 342 augment /if:interfaces/if:interface: 343 +--rw bind-lne-name? string 345 module: ietf-network-instance 346 augment /if:interfaces/if:interface: 347 +--rw bind-network-instance-name? string 348 augment /if:interfaces/if:interface/ip:ipv4: 349 +--rw bind-network-instance-name? string 350 augment /if:interfaces/if:interface/ip:ipv6: 351 +--rw bind-network-instance-name? string 353 The following is an example of envisioned combined usage. The 354 interfaces container includes a number of commonly used components as 355 examples: 357 +--rw if:interfaces 358 | +--rw interface* [name] 359 | +--rw name string 360 | +--rw lne:bind-lne-name? string 361 | +--rw ethernet 362 | | +--rw ni:bind-network-instance-name? string 363 | | +--rw aggregates 364 | | +--rw rstp 365 | | +--rw lldp 366 | | +--rw ptp 367 | +--rw vlans 368 | +--rw tunnels 369 | +--rw ipv4 370 | | +--rw ni:bind-network-instance-name? string 371 | | +--rw arp 372 | | +--rw icmp 373 | | +--rw vrrp 374 | | +--rw dhcp-client 375 | +--rw ipv6 376 | +--rw ni:bind-network-instance-name? string 377 | +--rw vrrp 378 | +--rw icmpv6 379 | +--rw nd 380 | +--rw dhcpv6-client 382 The [RFC7223] defined interface model is structured to include all 383 interfaces in a flat list, without regard to logical or virtual 384 instances (e.g., VRFs) supported on the device. The bind-lne-name 385 and bind-network-instance-name leaves provide the association between 386 an interface and its associated LNE and NI (e.g., VRF or VSI). 388 2.2. System Management 390 [Editor's note: need to discuss and resolve relationship between this 391 structure and RFC7317 and determine if 7317 is close enough to simply 392 use as is.] 394 System management is expected to reuse definitions contained in 395 [RFC7317]. It is expected to be instantiated per device and LNE. 396 Its structure is shown below: 398 module: ietf-network-device 399 +--rw system-management 400 | +--rw system-management-global 401 | +--rw system-management-protocol* [type] 402 | +--rw type identityref 404 System-management-global is used for configuration information and 405 state that is independent of a particular management protocol. 406 System-management-protocol is a list of management protocol specific 407 elements. The type-specific sub-modules are expected to be defined. 409 The following is an example of envisioned usage: 411 module: ietf-network-device 412 +--rw system-management 413 +--rw system-management-global 414 | +--rw statistics-collection 415 | ... 416 +--rw system-management-protocol* [type] 417 | +--rw type=syslog 418 | +--rw type=dns 419 | +--rw type=ntp 420 | +--rw type=ssh 421 | +--rw type=tacacs 422 | +--rw type=snmp 423 | +--rw type=netconf 425 2.3. Network Services 427 A device may provide different network services to other devices, for 428 example a device my act as a DHCP server. The model may be 429 instantiated per device, LNE, and NI. An identityref is used to 430 identify the type of specific service being provided and its 431 associated configuration and state information. The defined 432 structure is as follows: 434 module: ietf-network-device 435 +--rw network-services 436 | +--rw network-service* [type] 437 | +--rw type identityref 439 The following is an example of envisioned usage: Examples shown below 440 include a device-based Network Time Protocol (NTP) server, a Domain 441 Name System (DNS) server, and a Dynamic Host Configuration Protocol 442 (DHCP) server: 444 module: ietf-network-device 445 +--rw network-services 446 +--rw network-service* [type] 447 +--rw type=ntp-server 448 +--rw type=dns-server 449 +--rw type=dhcp-server 451 2.4. OAM Protocols 453 OAM protocols that may run within the context of a device are grouped 454 within the oam-protocols model. The model may be instantiated per 455 device, LNE, and NI. An identifyref is used to identify the 456 information and state that may relate to a specific OAM protocol. 457 The defined structure is as follows: 459 module: ietf-network-device 460 +--rw oam-protocols 461 +--rw oam-protocol* [type] 462 +--rw type identityref 464 The following is an example of envisioned usage. Examples shown 465 below include Bi-directional Forwarding Detection (BFD), Ethernet 466 Connectivity Fault Management (CFM), and Two-Way Active Measurement 467 Protocol (TWAMP): 469 module: ietf-network-device 470 +--rw oam-protocols 471 +--rw oam-protocol* [type] 472 +--rw type=bfd 473 +--rw type=cfm 474 +--rw type=twamp 476 2.5. Routing 478 Routing protocol and IP forwarding configuration and operation 479 information is modeled via a routing model, such as the one defined 480 in [I-D.ietf-netmod-routing-cfg]. 482 The routing module is expected to include all IETF defined control 483 plane protocols, such as BGP, OSPF, LDP and RSVP-TE. It is also 484 expected to support configuration and operation of or more routing 485 information bases (RIB). A RIB is a list of routes complemented with 486 administrative data. Finally, policy is expected to be represented 487 within each control plane protocol and RIB. 489 The anticipated structure is as follows: 491 module: ietf-network-device 492 +--rw rt:routing [I-D.ietf-netmod-routing-cfg] 493 +--rw control-plane-protocol* [type] 494 | +--rw type identityref 495 | +--rw policy 496 +--rw rib* [name] 497 +--rw name string 498 +--rw description? string 499 +--rw policy 501 2.6. MPLS 503 MPLS data plane related information is grouped together, as with the 504 previously discussed modules, is unaware of VRFs/NIs. The model may 505 be instantiated per device, LNE, and NI. MPLS control plane 506 protocols are expected to be included in Section 2.5. MPLS may reuse 507 and build on [I-D.openconfig-mpls-consolidated-model] or other 508 emerging models and has an anticipated structure as follows: 510 module: ietf-network-device 511 +--rw mpls 512 +--rw global 513 +--rw lsps* [type] 514 +--rw type identityref 516 Type refers to LSP type, such as static, traffic engineered or 517 routing congruent. The following is an example of such usage: 519 module: ietf-network-device 520 +--rw mpls 521 +--rw global 522 +--rw lsps* [type] 523 +--rw type=static 524 +--rw type=constrained-paths 525 +--rw type=igp-congruent 527 3. Security Considerations 529 The network-device model structure described in this document does 530 not define actual configuration and state data, hence it is not 531 directly responsible for security risks. 533 Each of the component models that provide the corresponding 534 configuration and state data should be considered sensitive from a 535 security standpoint since they generally manipulate aspects of 536 network configurations. Each component model should be carefully 537 evaluated to determine its security risks, along with mitigations to 538 reduce such risks. 540 LNE portion is TBD 542 NI portion is TBD 544 4. IANA Considerations 546 This YANG model currently uses a temporary ad-hoc namespace. If it 547 is placed or redirected for the standards track, an appropriate 548 namespace URI will be registered in the "IETF XML Registry" 549 [RFC3688]. The YANG structure modules will be registered in the 550 "YANG Module Names" registry [RFC6020]. 552 5. Network Device Model Structure 554 file "ietf-network-device@2016-05-01.yang" 555 module ietf-network-device { 557 yang-version "1"; 559 // namespace 560 namespace "urn:ietf:params:xml:ns:yang:ietf-network-device"; 562 prefix "nd"; 564 // import some basic types 566 // meta 567 organization "IETF RTG YANG Design Team Collaboration 568 with OpenConfig"; 570 contact 571 "Routing Area YANG Architecture Design Team - 572 "; 574 description 575 "This module describes a model structure for YANG 576 configuration and operational state data models. Its intent is 577 to describe how individual device protocol and feature models 578 fit together and interact."; 580 revision "2016-05-01" { 581 description 582 "IETF Routing YANG Design Team Meta-Model"; 583 reference "TBD"; 584 } 586 // extension statements 587 // identity statements 589 identity oam-protocol-type { 590 description 591 "Base identity for derivation of OAM protocols"; 592 } 594 identity network-service-type { 595 description 596 "Base identity for derivation of network services"; 597 } 599 identity system-management-protocol-type { 600 description 601 "Base identity for derivation of system management 602 protocols"; 603 } 605 identity oam-service-type { 606 description 607 "Base identity for derivation of Operations, 608 Administration, and Maintenance (OAM) services."; 609 } 611 identity control-plane-protocol-type { 612 description 613 "Base identity for derivation of control-plane protocols"; 614 } 616 identity mpls-lsp-type { 617 description 618 "Base identity for derivation of MPLS LSP typs"; 619 } 621 // typedef statements 623 // grouping statements 625 grouping ribs { 626 description 627 "Routing Information Bases (RIBs) supported by a 628 network-instance"; 629 container ribs { 630 description 631 "RIBs supported by a network-instance"; 632 list rib { 633 key "name"; 634 min-elements "1"; 635 description 636 "Each entry represents a RIB identified by the 637 'name' key. All routes in a RIB must belong to the 638 same address family. 640 For each routing instance, an implementation should 641 provide one system-controlled default RIB for each 642 supported address family."; 643 leaf name { 644 type string; 645 description 646 "The name of the RIB."; 647 } 648 reference "draft-ietf-netmod-routing-cfg"; 649 leaf description { 650 type string; 651 description 652 "Description of the RIB"; 653 } 654 // Note that there is no list of interfaces within 655 container policy { 656 description "Policy specific to RIB"; 657 } 658 } 659 } 660 } 662 // top level device definition statements 663 container ietf-yang-library { 664 description 665 "YANG Module Library as defined in 666 draft-ietf-netconf-yang-library"; 667 } 669 container interfaces { 670 description 671 "Interface list as defined by RFC7223/RFC7224"; 672 } 674 container hardware { 675 description 676 "Hardware / vendor-specific data relevant to the platform. 677 This container is an anchor point for platform-specific 678 configuration and operational state data. It may be further 679 organized into chassis, line cards, ports, etc. It is 680 expected that vendor or platform-specific augmentations 681 would be used to populate this part of the device model"; 682 } 683 container qos { 684 description "QoS features, for example policing, shaping, etc."; 685 } 687 container system-management { 688 description 689 "System management for physical or virtual device."; 690 container system-management-global { 691 description "System management - with reuse of RFC 7317"; 692 } 693 list system-management-protocol { 694 key "type"; 695 leaf type { 696 type identityref { 697 base system-management-protocol-type; 698 } 699 mandatory true; 700 description 701 "Syslog, ssh, TACAC+, SNMP, NETCONF, etc."; 702 } 703 description "List of system management protocol 704 configured for a logical network 705 element."; 706 } 707 } 709 container network-services { 710 description 711 "Container for list of configured network 712 services."; 713 list network-service { 714 key "type"; 715 description 716 "List of network services configured for a 717 network instance."; 718 leaf type { 719 type identityref { 720 base network-service-type; 721 } 722 mandatory true; 723 description 724 "The network service type supported within 725 a network instance, e.g., NTP server, DNS 726 server, DHCP server, etc."; 727 } 728 } 729 } 730 container oam-protocols { 731 description 732 "Container for configured OAM protocols."; 733 list oam-protocol { 734 key "type"; 735 leaf type { 736 type identityref { 737 base oam-protocol-type; 738 } 739 mandatory true; 740 description 741 "The Operations, Administration, and 742 Maintenance (OAM) protocol type, e.g., BFD, 743 TWAMP, CFM, etc."; 744 } 745 description 746 "List of configured OAM protocols."; 747 } 748 } 750 container routing { 751 description 752 "The YANG Data Model for Routing Management revised to be 753 Network Instance / VRF independent. "; 754 // Note that there is no routing or network instance 755 list control-plane-protocol { 756 key "type"; 757 description 758 "List of control plane protocols configured for 759 a network instance."; 760 leaf type { 761 type identityref { 762 base control-plane-protocol-type; 763 } 764 description 765 "The control plane protocol type, e.g., BGP, 766 OSPF IS-IS, etc"; 767 } 768 container policy { 769 description 770 "Protocol specific policy, 771 reusing [RTG-POLICY]"; 772 } 773 } 774 list rib { 775 key "name"; 776 min-elements "1"; 777 description 778 "Each entry represents a RIB identified by the 779 'name' key. All routes in a RIB must belong to the 780 same address family. 782 For each routing instance, an implementation should 783 provide one system-controlled default RIB for each 784 supported address family."; 785 leaf name { 786 type string; 787 description 788 "The name of the RIB."; 789 } 790 reference "draft-ietf-netmod-routing-cfg"; 791 leaf description { 792 type string; 793 description 794 "Description of the RIB"; 795 } 796 // Note that there is no list of interfaces within 797 container policy { 798 description "Policy specific to RIB"; 799 } 800 } 801 } 803 container mpls { 804 description "MPLS and TE configuration"; 805 container global { 806 description "Global MPLS configuration"; 807 } 808 list lsps { 809 key "type"; 810 description 811 "List of LSP types."; 812 leaf type { 813 type identityref { 814 base mpls-lsp-type; 815 } 816 mandatory true; 817 description 818 "MPLS and Traffic Engineering protocol LSP types, 819 static, LDP/SR (igp-congruent), 820 RSVP TE (constrained-paths) , etc."; 821 } 822 } 823 } 825 container ieee-dot1Q { 826 description 827 "The YANG Data Model for VLAN bridges as defined by the IEEE"; 828 } 830 container ietf-acl { 831 description "Packet Access Control Lists (ACLs) as specified 832 in draft-ietf-netmod-acl-model"; 833 } 835 container ietf-key-chain { 836 description "Key chains as specified in 837 draft-ietf-rtgwg-yang-key-chain;"; 838 } 840 container logical-network-element { 841 description 842 "This module is used to support multiple logical network 843 elements on a single physical or virtual system."; 844 } 846 container network-instance { 847 description 848 "This module is used to support multiple network instances 849 within a single physical or virtual device. Network 850 instances are commonly know as VRFs (virtual routing 851 and forwarding) and VSIs (virtual switching instances)."; 852 } 853 // rpc statements 855 // notification statements 857 } 858 860 6. References 862 6.1. Normative References 864 [LNE-MODEL] 865 Berger, L., Hopps, C., Lindem, A., and D. Bogdanovic, 866 "Logical Network Element Model", draft-rtgyangdt-rtgwg- 867 lne-model-00.txt (work in progress), May 2016. 869 [NI-MODEL] 870 Berger, L., Hopps, C., Lindem, A., and D. Bogdanovic, 871 "Network Instance Model", draft-rtgyangdt-rtgwg-ni-model- 872 00.txt (work in progress), May 2016. 874 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 875 DOI 10.17487/RFC3688, January 2004, 876 . 878 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 879 Private Network (VPN) Terminology", RFC 4026, 880 DOI 10.17487/RFC4026, March 2005, 881 . 883 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 884 the Network Configuration Protocol (NETCONF)", RFC 6020, 885 DOI 10.17487/RFC6020, October 2010, 886 . 888 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 889 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 890 . 892 [RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", 893 RFC 7277, DOI 10.17487/RFC7277, June 2014, 894 . 896 [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for 897 System Management", RFC 7317, DOI 10.17487/RFC7317, August 898 2014, . 900 6.2. Informative References 902 [I-D.ietf-netconf-yang-library] 903 Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module 904 Library", draft-ietf-netconf-yang-library-05 (work in 905 progress), April 2016. 907 [I-D.ietf-netmod-opstate-reqs] 908 Watsen, K. and T. Nadeau, "Terminology and Requirements 909 for Enhanced Handling of Operational State", draft-ietf- 910 netmod-opstate-reqs-03 (work in progress), January 2016. 912 [I-D.ietf-netmod-routing-cfg] 913 Lhotka, L. and A. Lindem, "A YANG Data Model for Routing 914 Management", draft-ietf-netmod-routing-cfg-20 (work in 915 progress), October 2015. 917 [I-D.openconfig-mpls-consolidated-model] 918 George, J., Fang, L., eric.osborne@level3.com, e., and R. 919 Shakir, "MPLS / TE Model for Service Provider Networks", 920 draft-openconfig-mpls-consolidated-model-02 (work in 921 progress), October 2015. 923 [I-D.openconfig-netmod-model-structure] 924 Shaikh, A., Shakir, R., D'Souza, K., and L. Fang, 925 "Operational Structure and Organization of YANG Models", 926 draft-openconfig-netmod-model-structure-00 (work in 927 progress), March 2015. 929 [I-D.openconfig-netmod-opstate] 930 Shakir, R., Shaikh, A., and M. Hines, "Consistent Modeling 931 of Operational State Data in YANG", draft-openconfig- 932 netmod-opstate-01 (work in progress), July 2015. 934 [IEEE-8021Q] 935 Holness, M., "IEEE 802.1Q YANG Module Specifications", 936 IEEE-Draft http://www.ieee802.org/1/files/public/docs2015/ 937 new-mholness-yang-8021Q-0515-v04.pdf, May 2015. 939 Appendix A. Acknowledgments 941 This document is derived from draft-openconfig-netmod-model- 942 structure-00. We thank the Authors of that document and acknowledge 943 their indirect contribution to this work. The authors include: Anees 944 Shaikh, Rob Shakir, Kevin D'Souza, Luyuan Fang, Qin Wu, Stephane 945 Litkowski and Gang Yan. 947 This work was discussed in and produced by the Routing Area Yang 948 Architecture design team. Members at the time of writing included 949 Acee Lindem, Anees Shaikh, Christian Hopps, Dean Bogdanovic, Lou 950 Berger, Qin Wu, Rob Shakir, Stephane Litkowski, and Gang Yan. 952 The identityref approach was proposed by Mahesh Jethanandani. 954 The RFC text was produced using Marshall Rose's xml2rfc tool. 956 Authors' Addresses 958 Acee Lindem (editor) 959 Cisco Systems 960 301 Midenhall Way 961 Cary, NC 27513 962 USA 964 Email: acee@cisco.com 966 Lou Berger (editor) 967 LabN Consulting, L.L.C. 969 Email: lberger@labn.net 971 Dean Bogdanovic 973 Email: ivandean@gmail.com 975 Christan Hopps 976 Deutsche Telekom 978 Email: chopps@chopps.org