idnits 2.17.1 draft-openconfig-netmod-model-structure-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: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. 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 -- The document date (March 9, 2015) is 3335 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 (-25) exists of draft-ietf-netmod-routing-cfg-16 == Outdated reference: A later version (-01) exists of draft-shaikh-rtgwg-policy-model-00 == Outdated reference: A later version (-42) exists of draft-ietf-isis-yang-isis-cfg-01 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Shaikh 3 Internet-Draft Google 4 Intended status: Informational R. Shakir 5 Expires: September 10, 2015 BT 6 K. D'Souza 7 AT&T 8 L. Fang 9 Microsoft 10 March 9, 2015 12 Operational Structure and Organization of YANG Models 13 draft-openconfig-netmod-model-structure-00 15 Abstract 17 This document presents an approach for organizing YANG models in a 18 comprehensive structure that defines how individual models may be 19 composed to configure and operate network infrastructure and 20 services. The structure is itself represented as a YANG model rooted 21 at a device, with all of the related component models logically 22 organized in a way that is operationally intuitive. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 10, 2015. 41 Copyright Notice 43 Copyright (c) 2015 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 1. Introduction 58 The large number of configuration models recently published cover 59 much of networking protocols and technology and, in theory, enable a 60 programmatic, model-driven approach for configuring network devices. 61 These models have been largely developed individually and in 62 isolation, however, making it challenging to use them together to 63 fully configure a device, or manage a set of devices comprising a 64 service. For example, standard models for interface management 65 [RFC7223] and system management [RFC7317] are available but there is 66 no guidance for how they should be used together, or combined with 67 other models for routing protocols, ACLs, etc. to form a complete 68 model. Recently, some frameworks (e.g., [RTG-CFG] and [RTG-POLICY]) 69 that tie models together have been developed, but they are 70 incomplete, covering only a subset of related models. 72 1.1. Goals and approach 74 In this document, we describe a structure for organizing YANG 75 [RFC6020] models that is broadly applicable to physical and virtual 76 devices. Individual models are composed such that the data they 77 define can be accessed in a predictable and operationally intuitive 78 way that is common across implementations. This organization enables 79 several important capabilities: 81 o a common schema to access data related to all aspects of a device 83 o an extensible structure that makes it clear where additional 84 models or data should be fit (e.g., using YANG augmentation or 85 imports) 87 o a place for including metadata that provides useful information 88 about the corresponding individual models, such as which 89 organization provides them, which vendors support them, or which 90 version of the model is deployed 92 o a common infrastructure model layer on which higher layer service 93 models can be built, for example by specifying which models are 94 needed to provide the service 96 o an ability to express an instance of the structure consisting of 97 models that have been validated to work together (i.e., with 98 information about sources of the models, their versions, etc.), so 99 that operators can easily identify a set of models that is known 100 to be mutually consistent 102 Our approach is to organize the models describing various aspects of 103 network infrastructure, including devices and their subsystems, and 104 relevant protocols operating at the link and network layers. The 105 proposal does not consider a common model for higher level network 106 services, nor does it specify details of how hardware-related data 107 should be organized. Both of these are challenging to standardize -- 108 services are subject to operational and business considerations that 109 vary across network operators, and hardware models are necessarily 110 dependent on specific platform features and architecture -- and are 111 thus out of scope of this document. We instead consider the set of 112 models that are commonly used by network operators, and suggest a 113 corresponding organization. 115 As with other models developed from an operator perspective, the 116 intent is not to be exhaustive by including all possible models in 117 the overall structure, whether currently available or not. We focus 118 on components that are deemed most useful for network operators 119 across a variety of use cases. We recognize, however, that 120 additional models will be needed in some cases, and this structure is 121 useful for describing how new models can be fit into the overall 122 structure. 124 2. Model overview 126 The model organization can itself be thought of as a "meta- model", 127 in that it describes the relationships between individual models. We 128 choose to represent it also as simple YANG model consisting of lists 129 and containers to serve as anchor points for the corresponding 130 individual models. 132 As shown below, our model is rooted at a "device", which represents a 133 network router, switch, or similar device. The model is applicable 134 to both physical, hardware-based devices, as well as software-based 135 devices such as virtual network functions (VNFs). It does not follow 136 the hierarchy of any particular implementation, and hence is vendor- 137 neutral. Nevertheless, the structure should be familiar to network 138 operators and also readily mapped to vendor implementations. 140 +--rw device 141 +--rw info 142 | +--rw device-type? 143 | ... 144 +--rw hardware 145 +--rw system 146 | ... 147 +--rw interfaces 148 | ... 149 +--rw acl 150 +--rw qos 151 +--rw logical-routers 152 ... 154 The key subsystems are represented at the top level of the device, 155 including, system-wide configuration, interfaces, and routing 156 instances. The info section can be used for basic device information 157 such as its type (e.g., physical or virtual), vendor, and model. For 158 physical devices, the hardware container is intended to be a 159 placeholder for platform-specific configuration and operational state 160 data. For example, a common structure for the hardware model might 161 include chassis, linecards, and ports, but we leave this unspecified. 163 2.1. System model components 165 The system container includes a number of subsystems that are 166 typically configured globally for the device. Some of these, such as 167 DHCP, Ethernet CFM, or sampling configuration also may have data that 168 is associated with an interface. For simplicity, these relationships 169 are not represented in this structural model. The currently defined 170 subsystems are shown below: 172 +--rw device 173 +--rw system 174 +--rw dns 175 +--rw ntp 176 +--rw dhcp 177 +--rw syslog 178 +--rw ssh 179 +--rw stat-coll 180 +--rw oam 181 | +--rw snmp 182 | +--rw cfm 183 | +--rw twamp 184 +--rw aaa 185 | +--rw tacacs 186 | +--rw radius 187 +--rw users 189 2.2. Interface model components 191 Interfaces are a crucial part of any network device's configuration 192 and operational state. They generally include a combination of raw 193 physical interfaces, link-layer interfaces, addressing configuration, 194 and logical interfaces that may not be tied to any physical 195 interface. Several system services, and layer 2 and layer 3 196 protocols may also associate configuration or operational state data 197 with different types of interfaces (these relationships are not shown 198 for simplicity). The interfaces container includes a number of 199 commonly used components as examples: 201 +--rw device 202 +--rw interfaces 203 +--rw ethernet 204 | +--rw aggregates 205 | +--rw vlans 206 | +--rw lfm 207 +--rw sonet-sdh 208 +--rw addressing 209 | +--rw ipv4 210 | | +--rw vrrp 211 | +--rw ipv6 212 | +--rw vrrp 213 +--rw tunnels 215 2.3. Logical routing instances 217 Logical routers represent the capability on some devices to partition 218 resources into independent logical routers. In physical devices, 219 some hardware features are shared across partitions, but routing 220 protocol instances, routing tables, and configuration are managed 221 separately. In virtual routers or VNFs, this may correspond to 222 establishing multiple logical instances using a single software 223 installation. The model supports configuration of multiple routing 224 instances on a single device by creating a list of logical routers, 225 each with their own configuration and operational state related to 226 routing and switching protocols, as shown below: 228 +--rw device 229 +--rw logical-routers 230 +--rw logical-router* [router-id] 231 +--rw router-id uint8 232 +--rw router-name? string 233 +--rw layer-2-protocols 234 | ... 235 +--rw layer-3-protocols 236 ... 238 2.4. VRFs and global routing configuration 240 Virtual routing and forwarding instances (VRFs) are commonly used to 241 isolate routing domains, for example to create virtual private 242 networks, each with their own active protocols and routing policies. 243 Devices also have a global instance of each routing protocol that may 244 also exchange routes with VRFs through routing policies. The model 245 describes protocols and policies for both VRF routing instances and 246 the global instance. The routing policy framework is expected to 247 follow [RTG-POLICY], which enables import / export policies to be 248 expressed with respect to a VRF, or the global routing instance. 250 +--rw device 251 +--rw logical-routers 252 +--rw logical-router* [router-id] 253 +--rw router-id 254 +--rw router-name? 255 +--rw layer-3-protocols 256 +--rw global 257 | ... 258 +--rw vrf* [vrf-name] 259 | ... 260 +--rw routing-policy 261 ... 263 3. Populating the structural model 265 The structural model in this document describes how individual YANG 266 models may be used together to represent the configuration and 267 operational state for all parts of a physical or virtual device. It 268 does not, however, document the actual model in its entirety. In 269 this section, we outline an option for creating the full model and 270 also describe how it may be used. 272 3.1. Constructing the device model 274 One of the challenges in assembling existing YANG models is that they 275 are generally written with the assumption that each model is at the 276 root of the configuration or state tree. Combining models then 277 results in a multi-rooted tree that does not follow any logical 278 construction and makes it difficult to work with operationally. In 279 some cases, models explicitly reference other models (e.g., via 280 augmentation) to define a relationship, but this is the case for only 281 a few existing models. 283 Some examples include the interfaces [RFC7223] and IP management 284 [RFC7277] models, and proposed IS-IS [RTG-ISIS], OSPF [RTG-OSPF] and 285 routing configuration [RTG-CFG] models. 287 3.2. Pull approach for model composition 289 To enable model composition, one possible approach is to avoid using 290 root-level containers in individual component models. Instead, the 291 top level container (and all other data definitions) can be enclosed 292 in a YANG 'grouping' statement so that when the model is imported by 293 another model, its location in the configuration tree can be 294 controlled by the importing YANG module with the 'uses' statement. 295 One advantage of this approach is that the importing module has the 296 flexibility to readily use the data definitions where the author 297 deems appropriate. 299 One obvious drawback is that individual models no longer contain any 300 of their own data definitions and must be used by a higher-level 301 model for their data nodes to become active. Some judgment as to 302 which models are more suited for inclusion in higher level models is 303 also necessary to decide when the corresponding YANG module should 304 contain only groupings. Another potential drawback is that this 305 approach does not define a common structure for models to fit 306 together, limiting interoperability due to implementations using 307 different structures. To address this, a top-level standard model 308 structure could be defined and updated to import new models into the 309 hierarchy as they are defined. 311 3.3. "Push" approach for model composition 313 An alternative approach is to develop a top level model which defines 314 the overall structure of the models, similar to the structure 315 described in Section 2. Individual models may augment the top level 316 model with their data nodes in the appropriate locations. The 317 drawback is the need for a pre-defined top level model structure. On 318 the other hand, when this top level model is standardized, it can 319 become the basis for a vendor-neutral way to manage devices, assuming 320 that the component models are supported by a given implementation. 322 One question in both approaches is what the root of the top- level 323 model should be. In this document we selected to base the mode at a 324 device because this layer should be common across many use cases and 325 implementations. Starting at a higher layer (e.g., services) makes 326 defining and agreeing on a common organization more challenging as 327 discussed in Section 1.1. 329 Ideally, one could consider a hybrid construction mechanism that 330 supports both styles of model composition. For example, a YANG 331 compiler directive could be used to indicate whether an individual 332 model should assume it is at the root, or whether it is meant for 333 inclusion in other higher-level models. 335 4. Additional use cases 337 The goal of this document is to motivate the need for an overall 338 structure for YANG data models that allows all of the data to be 339 accessed in a common, logical way. With such a structure defined 340 itself as a simple YANG model, it is possible to consider additional 341 use cases. 343 4.1. Model catalog 345 YANG data models are being developed in a number of organizations, 346 including standards bodies such as IETF, ONF, and IEEE, as well as 347 open source projects and ad-hoc working groups. In addition to 348 understanding how these models can work together, another challenge 349 for users is the complexity of tracking which organization created a 350 given model, and the capabilities and coverage each model provides. 351 This becomes even more difficult when multiple overlapping models are 352 available for a particular component. 354 Such a catalog could also be locally defined by an operator to 355 describe the models needed to instantiate and manage different 356 services. 358 The idea of a model catalog is similar to service catalogs in 359 traditional IT environments. Service catalogs serve as a software- 360 based registries of available services with information needed to 361 discover and invoke available services. 363 The current model structure described in Section 2 focuses on 364 describing relationships between the models, however there are 365 several examples of additional metadata that could be captured for 366 each component model in the overall structural model: 368 o origin and responsible party for maintenance of the model with 369 contact information. In IETF standard models, the YANG 370 'organization' and 'contact' statement contents are a good 371 example, but this is not necessarily the case for models from 372 other sources. 374 o license under which the model is distributed, e.g., open source or 375 as part of a commercial license 377 o classification of the model, including its category / subcategory, 378 whether the model is intended to be used standalone, etc. 380 o model dependencies, e.g., a list of other modules that are 381 required 383 o namespace information, including base namespace, prefixes, etc. to 384 enable importing the model 386 o pointer to the YANG code, if it is freely downloadable 388 o implementation information, for example, a list of available 389 implementations that support the model from vendors, open source 390 projects, etc. 392 o authentication information to allow users to verify that the model 393 they download does in fact originate from the stated organization 395 For such an approach to be useful, we also require a registration 396 system where model developers can register information about their 397 models, and update it as needed. The IANA XML Registry" [RFC3688] 398 provides a basic registry for YANG models, but the information is 399 somewhat limited and is currently targeted at IETF-standardized 400 models only. Further details on the proposal for such a registry may 401 be forthcoming in further revisions to this document. 403 4.2. Service-layer composition 405 The proposed structural model covers a wide variety of components and 406 protocols, and clearly not all of them are needed for all services. 407 Another envisioned use case for the structural model is the ability 408 to reference the set of models that are needed for specific use cases 409 or services. The intent is that the set would be based on best 410 operational practices as defined by users or operators who run such 411 services. 413 One approach for this would be to define a 'service overlay' model, 414 for example for Layer 3 VPN services, that defines the set of 415 required configuration and state models, such as VRFs, interfaces, 416 BGP, policy, ACLs, and QoS. Similar overlay models can be defined 417 for other services or use cases, for example, basic Internet 418 operations such as adding new peers or customers, or setting up Layer 419 2 VPNs. Note these overlay models may be complementary to actual 420 configuration models for such services, which may focus on providing 421 an abstracted set of configuration or operational state variables, 422 which would then be mapped onto device level variables. We leave 423 discussion of such mapping mechanisms to future revisions. 425 5. Security Considerations 427 The model structure described in this document does not define actual 428 configuration and state data, hence it is not directly responsible 429 for security risks. 431 However, each of the component models that provide the corresponding 432 configuration and state data should be considered sensitive from a 433 security standpoint since they generally manipulate aspects of 434 network configurations. Each component model should be carefully 435 evaluated to determine its security risks, along with mitigations to 436 reduce such risks. 438 6. IANA Considerations 440 This YANG model currently uses a temporary ad-hoc namespace. If it 441 is placed or redirected for the standards track, an appropriate 442 namespace URI will be registered in the IETF XML Registry" [RFC3688]. 443 The YANG structure modules will be registered in the "YANG Module 444 Names" registry [RFC6020]. 446 7. YANG module 448 The model structure is described by the YANG module below. 450 7.1. Model structure 452 file model-structure.yang 453 module model-structure { 455 yang-version "1"; 457 // namespace 458 namespace "http://openconfig.net/yang/structure"; 460 prefix "struct"; 462 // import some basic types 464 // meta 465 organization "OpenConfig working group"; 467 contact 468 "OpenConfig working group 469 netopenconfig@googlegroups.com"; 471 description 472 "This module describes a model structure for YANG 473 configuration and operational state data models. Its intent is to 474 describe how individual device protocol and feature models fit 475 together and interact."; 477 revision "2015-03-06" { 478 description 479 "Initial revision"; 480 reference "TBD"; 481 } 483 // extension statements 485 // feature statements 487 // identity statements 489 // typedef statements 491 // grouping statements 493 grouping info { 494 description 495 "base system information"; 497 container info { 498 description 499 "This container is for base system information, including 500 device type (e.g., physcal or virtual), model, serial no., 501 location, etc."; 503 leaf device-type { 504 //TODO: consider changing to an identity if finer grained 505 // device type classification is envisioned 506 type enumeration { 507 enum PHYSICAL { 508 description "physical or hardware device"; 509 } 510 enum VIRTUAL { 511 description "virtual or software device"; 512 } 513 } 514 description 515 "Type of the device, e.g., physical or virtual. This node 516 may be used to activate other containers in the model"; 517 } 519 } 520 } 522 grouping hardware { 523 description 524 "hardware / vendor -specific data relevant to the platform"; 526 container hardware { 527 description 528 "This container is an anchor point for platform-specific 529 configuration and operational state data. It may be further 530 organized into chassis, linecards, ports, etc. It is 531 expected that vendor or platform-specific augmentations 532 would be used to populate this part of the device model"; 533 } 534 } 536 grouping l2-protocol-members { 537 description "containers for each layer 2 protocol model"; 539 container vsi { 540 description "virtual switch instance (or virtual forwarding 541 instance) for use in PWE3 / VPLS services"; 543 } 545 container ipv6-ndp { 546 description "IPv6 neighbor discovery"; 547 reference "RFC 4861 - Neighbor Discovery for IP version 6 548 (IPv6)"; 549 } 551 container arp { 552 description "Address resolution protocol"; 553 reference "STD 37 - An Ethernet Address Resolution Protocol"; 554 } 556 container rstp { 557 description "rapid spanning tree protocol"; 558 reference "IEEE 802.1D-2004"; 559 } 561 container lldp { 562 description "link layer discovery protocol"; 563 reference "IEEE 802.1AB"; 564 } 566 container ptp { 567 description 568 "precision time protocol for time synchronization services. 569 PTP also typically requires per-interface configuration"; 570 reference "IEEE 1588-2008"; 571 } 572 } 573 grouping l2-protocols { 574 description "Layer 2 protocol models"; 576 container layer-2-protocols { 577 description "layer 2 protocols and features"; 579 uses l2-protocol-members; 581 } 583 } 585 grouping igp-protocol-members { 586 description "containers for IGPs"; 588 container is-is { 589 description "IS-IS IGP routing protocol"; 590 reference "RFC 1195 - Use of OSI IS-IS for Routing in TCP/IP 591 and Dual Environments"; 592 } 594 container ospf { 595 description "OSPF IGP routing protocols"; 597 container ospf2 { 598 description "OSPF v2"; 599 reference "RFC 2328 - OSPF Version 2"; 600 } 602 container ospf3 { 603 description "OSPF v3"; 604 reference "RFC 5340 - OSPF for IPv6"; 605 } 606 } 608 container igp-common { 609 description "Common parameters for IGP protocols"; 610 } 611 } 613 grouping l3-protocol-members-vrf { 614 description "containers for layer 3 protocol that are supported 615 in a VRF instance"; 617 container bgp { 618 description "BGP 4"; 619 reference "RFC 4271 - A Border Gateway Protocol 4 (BGP-4)"; 620 } 621 container igp { 622 description "interior gateway protocols"; 624 uses igp-protocol-members; 625 } 627 container bfd { 628 description "bidirectional forwarding detection"; 629 reference "RFC 5880 - Bidirectional Forwarding Detection 630 (BFD)"; 631 } 633 container pim { 634 description "protocol independent multicast"; 635 reference "RFC 4601 - Protocol Independent Multicast - 636 Sparse Mode (PIM-SM): Protocol Specification (Revised)"; 637 } 639 container igmp { 640 description "Internet group management protocol"; 641 reference "RFC 3376 - Internet Group Management Protocol, 642 Version 3"; 643 } 645 container static-routes { 646 description "static route that are manually created"; 647 } 649 } 651 grouping l3-protocols-misc { 652 description "containers for other features operating at the 653 network layer"; 655 } 657 grouping l3-protocols-mpls { 658 description "models related to MPLS and TE"; 660 container mpls-te { 661 description "MPLS and traffic engineering"; 663 container global { 664 description "global MPLS configuration"; 665 } 667 container signaling { 668 description "MPLS signaling protocols"; 669 container rsvp { 670 description "RSVP signaling"; 671 reference "RFC 3209 - RSVP-TE: Extensions to RSVP for LSP 672 Tunnels"; 673 } 675 container segment-routing { 676 description "SR signaling"; 677 reference "Segment Routing Architecture - 678 draft-filsfils-spring-segment-routing-04"; 679 } 681 container ldp { 682 description "label distribution protocol"; 683 reference "RFC 5036 - LDP Specification"; 684 } 685 } 687 container label-switched-paths { 688 description "models for different types of LSPs"; 690 container constrained-path { 691 description "traffic-engineered, or constrained path LSPs"; 692 } 694 container igp-congruent { 695 description "LSPs that follow the IGP-computed path"; 696 } 698 container static { 699 description "statically configured LSPs"; 700 } 701 } 702 } 703 } 705 grouping l3-protocol-members { 706 description "containers for all layer 3 protocols"; 708 uses l3-protocol-members-vrf; 709 uses l3-protocols-misc; 710 uses l3-protocols-mpls; 712 } 714 grouping l3-routing-policy { 715 description "containers for routing policy models"; 716 container common { 717 description "generic routing policy framework and 718 configuration parameters"; 719 } 721 container bgp-policy { 722 description "BGP-specific routing policy parameters"; 723 } 725 container igp-policy { 726 description "IGP routing policy knobs -- may include 727 policy parameters for specific IGPs"; 728 } 730 container vrf-policy { 731 description "import/export policies for VRFs"; 732 } 733 } 735 grouping l3-protocols { 736 description "Layer 3 protocol models"; 738 container layer-3-protocols { 739 description "layer 3 protocols and features"; 741 container global { 742 description "router-wide instance of each routing protocol"; 744 uses l3-protocol-members; 746 } 748 list vrf { 749 key vrf-name; 750 description "list of VRF instances"; 752 leaf vrf-name { 753 type string; 754 description "name or id of the routing instance / VRF"; 755 } 757 uses l3-protocol-members-vrf; 758 } 760 container routing-policy { 761 description "models related to routing policy across 762 protocols and VRFs"; 763 uses l3-routing-policy; 765 } 766 } 767 } 769 grouping interface-ip-common { 770 description 771 "interface-specific configuration for IP interfaces, IPv4 and 772 IPv6"; 774 container vrrp { 775 description "virtual router redundancy protocol"; 776 reference "RFC 5798 - Virtual Router Redundancy Protocol 777 (VRRP) Version 3 for IPv4 and IPv6"; 778 } 779 } 781 grouping interface-addr-families { 782 description 783 "containers for addr family-specific data attached 784 to interfaces"; 786 container ipv4 { 787 description "IPv4 interfaces"; 789 uses interface-ip-common; 790 } 792 container ipv6 { 793 description "IPv6 interfaces"; 795 uses interface-ip-common; 796 } 797 } 799 grouping interfaces { 800 description "interface-related models"; 802 container interfaces { 803 description "various interface models"; 805 container ethernet { 806 description "Ethernet interface config, e.g., 10, 40, 807 100GBE"; 809 container aggregates { 810 description "LAGs, LACP, etc. for Ethernet interfaces"; 811 reference "IEEE 802.1ad, 802.1AX"; 812 } 814 container vlans { 815 description "VLANs, 802.1q, q-in-q, etc."; 816 reference "IEEE 802.1Q"; 817 } 819 container lfm { 820 description 821 "Link-layer fault management for Ethernet interfaces"; 822 reference "IEEE 802.3ah"; 823 } 824 } 826 container sonet-sdh { 827 description "SONET/SDH interfaces"; 828 reference 829 "SDH: ITU standards G.707, G.783, G.784, and G.803 830 SONET: ANSI standard T1.105"; 832 } 834 container addressing { 835 description "addressing and other interface-specific data, 836 e.g., data plane protocols"; 838 uses interface-addr-families; 839 } 841 container tunnels { 842 description 843 "logical tunnel interfaces incl. GRE, VxLAN, L2TP etc."; 844 } 846 } 847 } 849 grouping oam { 850 description "containers for features related to operations, 851 administration, and management"; 853 container oam { 854 description "commonly use OAM functions on devices"; 856 container snmp { 857 description "SNMP server information, e.g., allowed clients"; 858 } 859 container cfm { 860 description 861 "Ethernet connectivity fault management. Also includes 862 options that are associated with specific interfaces, such 863 as maintenance endpoint domains."; 864 reference "IEEE 802.1ag"; 865 } 867 container twamp { 868 description 869 "Two-way active measurement protocol for measuring 870 round-trip IP layer performance."; 871 reference "RFC 5357 A Two-Way Active Measurement Protocol 872 (TWAMP)"; 873 } 874 } 875 } 877 grouping system-services { 878 description "containers for system service models"; 880 container dns { 881 description "domain name service and resolver configurration"; 882 } 884 container ntp { 885 description "network time protocol configuration"; 886 } 888 container dhcp { 889 description "dhcp and relay services"; 890 } 892 container syslog { 893 description "syslog configuration"; 894 } 896 container ssh { 897 description "ssh server configuration"; 898 } 900 container stat-coll { 901 description 902 "mechanisms for data collection from devices, including 903 packet and flow-level sampling"; 904 } 906 uses oam; 908 } 910 grouping system-aaa { 911 description "AAA-related services"; 913 container aaa { 914 description "authentication, authorization, and accounting"; 916 container tacacs { 917 description "TACACS+ configuration"; 918 } 920 container radius { 921 description "RADIUS"; 922 reference "RFC 2865 - Remote Authentication Dial In User 923 Service (RADIUS)"; 924 } 925 } 926 } 928 grouping system { 929 description "system-wide services"; 931 container system { 932 description "system services"; 934 uses system-services; 935 uses system-aaa; 937 container users { 938 description "local user configuration"; 939 } 940 } 941 } 943 grouping acl { 944 description "forwarding rules"; 946 container acl { 947 description "ACLs and packet forwarding rules"; 948 } 949 } 951 grouping qos { 952 description "QoS features"; 954 container qos { 955 description "QoS, including policing, shaping, etc."; 957 } 958 } 960 // data definition statements 962 container device { 963 description "top-level anchor point for models. Device is a 964 generic L2/L3 network element"; 966 uses info; 967 uses hardware; 968 uses system; 969 uses interfaces; 970 uses acl; 971 uses qos; 973 container logical-routers { 974 description "devices may support multiple logical router 975 instances"; 977 list logical-router { 979 key router-id; 980 description "list of logical router instances"; 982 leaf router-id { 983 type uint8; // expect a small number of logical routers 984 description "identifier of the logical router instance"; 985 } 987 leaf router-name { 988 type string; // expect a small number of logical routers 989 description "identifier of the logical router instance"; 990 } 992 uses l2-protocols; 993 uses l3-protocols; 995 } 996 } 998 } 1000 // augment statements 1002 // rpc statements 1004 // notification statements 1006 } 1007 1009 8. References 1011 8.1. Normative references 1013 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 1014 Network Configuration Protocol (NETCONF)", RFC 6020, 1015 October 2014. 1017 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 1018 Management", RFC 7223, May 2014. 1020 [RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", RFC 1021 7277, June 2014. 1023 [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for 1024 System Management", RFC 7317, August 2014. 1026 [RFC3688] Mealling, M., "The IETF XML Registry", RFC 3688, January 1027 2004. 1029 8.2. Informative references 1031 [RTG-CFG] Lhotka, L., "A YANG Data Model for Routing Management", 1032 draft-ietf-netmod-routing-cfg-16 (work in progress), 1033 October 2014. 1035 [RTG-POLICY] 1036 Shaikh, A., Shakir, R., D'Souza, K., and C. Chase, 1037 "Routing Policy Configuration Model for Service Provider 1038 Networks", draft-shaikh-rtgwg-policy-model-00 (work in 1039 progress), January 2015. 1041 [RTG-OSPF] 1042 Yeung, D., Qu, Y., Zhang, J., and D. Bogdanovic, "Yang 1043 Data Model for OSPF Protocol", draft-yeung-netmod-ospf-02 1044 (work in progress), October 2014. 1046 [RTG-ISIS] 1047 Litkowski, S., Yeung, D., Lindem, A., Zhang, J., and L. 1048 Lhotka, "YANG Data Model for ISIS protocol", draft-ietf- 1049 isis-yang-isis-cfg-01 (work in progress), October 2014. 1051 Appendix A. Acknowledgements 1053 The authors are grateful for valuable contributions to this document 1054 and the associated models from: Deepak Bansal, Paul Borman, Chris 1055 Chase, Josh George, Marcus Hines, and Jim Uttaro. 1057 Authors' Addresses 1059 Anees Shaikh 1060 Google 1061 1600 Amphitheatre Pkwy 1062 Mountain View, CA 94043 1063 US 1065 Email: aashaikh@google.com 1067 Rob Shakir 1068 BT 1069 pp. C3L, BT Centre 1070 81, Newgate Street 1071 London EC1A 7AJ 1072 UK 1074 Email: rob.shakir@bt.com 1075 URI: http://www.bt.com/ 1077 Kevin D'Souza 1078 AT&T 1079 200 S. Laurel Ave 1080 Middletown, NJ 1081 US 1083 Email: kd6913@att.com 1085 Luyuan Fang 1086 Microsoft 1087 205 108th Ave. NE, Suite 400 1088 Bellevue, WA 1089 US 1091 Email: lufang@microsoft.com