idnits 2.17.1 draft-rtgyangdt-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 308 has weird spacing: '...ce-name str...' -- The document date (July 6, 2015) is 3218 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 7223 (Obsoleted by RFC 8343) ** Obsolete normative reference: RFC 7277 (Obsoleted by RFC 8344) == Outdated reference: A later version (-02) exists of draft-openconfig-mpls-consolidated-model-00 == Outdated reference: A later version (-25) exists of draft-ietf-netmod-routing-cfg-19 == Outdated reference: A later version (-42) exists of draft-ietf-isis-yang-isis-cfg-04 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group A. Lindem 2 Internet-Draft Cisco 3 Intended status: Informational L. Berger, Ed. 4 Expires: January 7, 2016 LabN 5 D. Bogdanovic 7 C. Hopps 8 Deustche Telekom 9 July 6, 2015 11 Network Device YANG Organizational Model 12 draft-rtgyangdt-rtgwg-device-model-00 14 Abstract 16 This document presents an approach for organizing YANG models in a 17 comprehensive structure that defines how individual models may be 18 composed to configure and operate network infrastructure and 19 services. The structure is itself represented as a YANG model rooted 20 at a device, with all of the related component models logically 21 organized in a way that is operationally intuitive. This document is 22 derived from work submitted to the IETF by members of the informal 23 OpenConfig working group of network operators and is a product of the 24 Routing Area YANG Architecture design team. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 10, 2015. 43 Copyright Notice 45 Copyright (c) 2015 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Contents 60 1. Introduction 61 1.1. Status of Work and Open Issues 62 2. Model Overview 63 2.1. Interface Model Components 64 2.2. Logical Network Elements 65 2.2.1. System Management 66 2.2.2. Network Instances 67 2.2.2.1. OAM Protocols 68 2.2.2.2. Network Instance Policy 69 2.2.2.3. Control Plane Protocols 70 2.2.2.4. RIBs 71 2.2.2.5. MPLS 72 2.2.2.6. Networking Services 73 2.3. Device View vs Logical Network Element (LNE) View Management 74 3. Populating the structural model 75 3.1. Constructing the device model 76 3.2. "Pull" approach for model composition 77 3.3. "Push" approach for model composition 78 4. Security Considerations 79 5. IANA Considerations 80 6. YANG module 81 6.1. Model structure 82 7. References 83 7.1. Normative references 84 7.2. Informative references 86 1. Introduction 88 "Operational Structure and Organization of YANG Models" [OC-STRUCT], 89 highlights the value of organizing individual, self-standing YANG 90 [RFC6020] models into a more comprehensive device-level model. This 91 document builds on that work and presents a derivative structure for 92 use in representing the networking infrastructure aspects of physical 93 and virtual devices. 95 This document aims to provide an extensible structure that can be 96 used to tie together other models. It allows for existing, emerging, 97 and future models. The overall structure can be constructed using 98 YANG augmentation and imports. 100 Additional motivation for this work can be found in [OC-STRUCT]. 102 The approach taken in this (and the original) document is to organize 103 the models describing various aspects of network infrastructure, 104 focusing on devices, their subsystems, and relevant protocols 105 operating at the link and network layers. The proposal does not 106 consider a common model for higher level network services, nor does 107 it specify details of how hardware-related data should be organized. 108 We focus on the set of models that are commonly used by network 109 operators, and suggest a corresponding organization. 111 A significant portion of the text and model contained in this 112 document was taken from the -00 of that document. 114 1.1. Status of Work and Open Issues 116 This version of the document and structure are a product of the 117 Routing Area YANG Architecture design team and is very much a work in 118 progress rather than a final proposal. Disagreement and open issues 119 remain, even within the design team. Major open issues are as 120 follows: 122 1. The structure related to L2VPNs, Ethernet services, and virtual 123 switching instances has not yet received sufficient discussion 124 and is likely to change. 126 2. Additional discussion and text is need to ensure that the 127 interpretation of different policy containers is clear. 129 3. Configuration information related to network-instance 130 interconnection (over a "core" network) is currently commingled 131 with configuration related to operation within the instance. 133 4. The representation of operational state is currently missing. The 134 model will be updated once the "opstate" requirements are 135 addressed. 137 2. Model Overview 139 The model organization can itself be thought of as a "meta-model", 140 in that it describes the relationships between individual models. We 141 choose to represent it also as simple YANG model consisting of lists 142 and containers to serve as anchor points for the corresponding 143 individual models. 145 As shown below, our model is rooted at a "device", which represents a 146 network router, switch, or similar network element. The model is 147 applicable to both physical, hardware-based devices, as well as 148 software-based devices such as virtual network functions (VNFs). It 149 does not follow the hierarchy of any particular implementation, and 150 hence is vendor-neutral. Nevertheless, the structure should be 151 familiar to network operators and also readily mapped to vendor 152 implementations. 154 +--rw device 155 +--rw info 156 | +--rw device-type? enumeration 157 +--rw hardware 158 +--rw interfaces 159 | +--rw interface* [name] 160 | ... 161 +--rw qos 162 +--rw logical-network-elements 163 | ... 165 The key subsystems are represented at the top level of the device, 166 including, system-wide configuration, interfaces, and routing 167 instances. The info section can be used for basic device information 168 such as its type (e.g., physical or virtual), vendor, and model. For 169 physical devices, the hardware container is intended to be a 170 placeholder for platform-specific configuration and operational state 171 data. For example, a common structure for the hardware model might 172 include chassis, line cards, and ports, but we leave this 173 unspecified. 175 2.1. Interface Model Components 177 Interfaces are a crucial part of any network device's configuration 178 and operational state. They generally include a combination of raw 179 physical interfaces, link-layer interfaces, addressing configuration, 180 and logical interfaces that may not be tied to any physical 181 interface. Several system services, and layer 2 and layer 3 182 protocols may also associate configuration or operational state data 183 with different types of interfaces (these relationships are not shown 184 for simplicity). 186 The interface model is taken from [RFC7223] and includes possible 187 technology-specific augmentations using example technologies defined 188 in [RFC7277]. Also included are examples of envisioned models 189 in order to provide future guidance. 191 The interfaces container includes a number of commonly used 192 components as examples: 194 +--rw interfaces 195 | +--rw interface* [name] 196 | +--rw name string 197 | +--rw bind-network-element-id? uint8 198 | +--rw ethernet 199 | | +--rw bind-networking-instance-name? string 200 | | +--rw aggregates 201 | | +--rw rstp 202 | | +--rw lldp 203 | | +--rw ptp 204 | +--rw vlans 205 | +--rw tunnels 206 | +--rw ipv4 207 | | +--rw bind-networking-instance-name? string 208 | | +--rw arp 209 | | +--rw icmp 210 | | +--rw vrrp 211 | | +--rw dhcp-client 212 | +--rw ipv6 213 | +--rw bind-networking-instance-name? string 214 | +--rw vrrp 215 | +--rw icmpv6 216 | +--rw nd 217 | +--rw dhcpv6-client 219 The bind-networking-instance-name leaf is an explicit and notable 220 addition. The [RFC7223] defined interface model is structured to 221 include all interfaces in a flat list, without regard to logical or 222 virtual instances (e.g., VRFs) supported on the device. The 223 bind-networking-instance-name leaf provides the association between 224 an interface and the networking instance (e.g., VRF or virtual switch 225 instance) that is configured to use it. 227 2.2. Logical Network Elements 228 Logical network elements represent the capability on some devices to 229 partition resources into independent logical routers and/or switches. 230 Device support for multiple logical network elements is 231 implementation specific. Systems without such capabilities will have 232 just a single container. In physical devices, some hardware features 233 are shared across partitions, but control plane (e.g., routing) 234 protocol instances, tables, and configuration are managed separately. 235 For example, in virtual routers or VNFs, this may correspond to 236 establishing multiple logical instances using a single software 237 installation. The model supports configuration of multiple instances 238 on a single device by creating a list of logical network elements, 239 each with their own configuration and operational state related to 240 routing and switching protocols, as shown below: 242 +--rw device 243 +--rw logical-network-elements 244 +--rw logical-network-element* [network-element-id] 245 +--rw network-element-id uint8 246 +--rw network-element-name? string 247 +--rw default-networking-instance-name? string 248 +--rw system-management 249 | ... 250 +--rw ietf-acl 251 +--rw ietf-key-chain 252 +--rw networking-instances 253 | ... 255 Network-element-id and network-element-name identify the logical 256 network element. 258 Default-networking-instance-name identifies the networking instance 259 to use for system management connectivity. Other instances may 260 access system management function through appropriate inter-instance 261 configuration. 263 2.2.1. System Management 265 The model supports the potentially independent system management 266 functions and configuration per logical network element. This 267 permits, for example, different users to manage either the whole 268 device or just the associated logical network element. System 269 management is supported by the system-management container which is 270 expected to reuse and augment [RFC7317] and is shown below: 272 +--rw device 273 +--rw logical-network-elements 274 +--rw system-management 275 | +--rw device-view? boolean 276 | +--rw syslog 277 | +--rw dns 278 | +--rw ntp 279 | +--rw statistics-collection 280 | +--rw ssh 281 | +--rw tacacs 282 | +--rw snmp 283 | +--rw netconf 285 The device-view leaf is used to indicate if the system management 286 functions associated with the logical network element are restricted 287 to the logical network element or can manage the whole device. The 288 leaf may have a fixed value. For example, some implementations may 289 only support management on a device-wide basis. Additional 290 information on the implications of this leaf can be found in Section 291 2.3. 293 2.2.2. Network Instances 295 The network instance container is used to represent virtual routing 296 and forwarding instances (VRFs) and virtual switching instances 297 (VSIs), [RFC4026]. VRFs and VSIs are commonly used to isolate 298 routing and switching domains, for example to create virtual private 299 networks, each with their own active protocols and routing/switching 300 policies. The model represents both core/provider and virtual 301 instances. Network instances reuse and build on [RTG-CFG] and are 302 shown below: 304 +--rw device 305 +--rw logical-network-elements 306 +--rw networking-instances 307 +--rw networking-instance* [networking-instance-name] 308 +--rw networking-instance-name string 309 +--rw type? identityref 310 +--rw enabled? boolean 311 +--rw router-id? uint32 312 +--rw description? string 313 +--rw oam-protocols 314 | ... 315 +--rw networking-instance-policy 316 | ... 317 +--rw control-plane-protocols 318 | ... 319 +--rw ribs 320 | ... 321 +--rw mpls 322 | ... 323 +--rw networking-services 324 ... 326 [Editor's note: L2/MAC forwarding table is TBD] 328 2.2.2.1. OAM Protocols 330 OAM protocols that may run within the context of a network instance 331 are grouped. Examples shown below include Bi-directional Forwarding 332 Detection (BFD), Ethernet Connectivity Fault Management (CFM), and 333 Two-Way Active Measurement Protocol (TWAMP): 335 +--rw device 336 +--rw logical-network-elements 337 +--rw networking-instances 338 +--rw networking-instance* [networking-instance-name] 339 +--rw oam-protocols 340 | +--rw bfd 341 | +--rw cfm 342 | +--rw twamp 344 2.2.2.2. Network Instance Policy 346 Network instance policies are used to control provider instances, VRF 347 routing policies, and VRF/VSI identifiers. Examples include BGP route 348 targets (RTs) and route distinguishers (RDs), if the instances is a 349 core/provider instance, virtual network identifiers(VN-IDs), VPLS 350 neighbors, etc. The structure is: 352 +--rw device 353 +--rw logical-network-elements 354 +--rw networking-instances 355 +--rw networking-instance* [networking-instance-name] 356 +--rw networking-instance-policy 357 (TBD) 359 2.2.2.3. Control Plane Protocols 361 Control plane protocols that may run within the context of a network 362 instance are grouped. Each protocol is expected to have its own 363 model. Note that protocol specific policy is included with the 364 protocol rather than being combined in a separate generic policy 365 grouping. The rationale behind this is that this ensures that only 366 protocol relevant policies may be configured. A reusable or common 367 approach may still be leveraged in creating these policy groupings, 368 perhaps based on [RTG-POLICY]. 370 +--rw device 371 +--rw logical-network-elements 372 +--rw networking-instances 373 +--rw networking-instance* [networking-instance-name] 374 +--rw control-plane-protocols 375 | +--rw bgp 376 | | +--rw policy 377 | +--rw is-is 378 | | +--rw policy 379 | +--rw ospf 380 | | +--rw policy 381 | +--rw rsvp 382 | +--rw segment-routing 383 | +--rw ldp 384 | +--rw pim 385 | +--rw igmp 386 | +--rw mld 387 | +--rw static-routes 389 2.2.2.4. RIBs 391 Every routing instance manages one or more routing information bases 392 (RIB). A RIB is a list of routes complemented with administrative 393 data. RIBs reuse and build on [RTG-CFG] and are shown below: 395 +--rw device 396 +--rw logical-network-elements 397 +--rw networking-instances 398 +--rw networking-instance* [networking-instance-name] 399 +--rw ribs 400 | +--rw rib* [name] 401 | +--rw name string 402 | +--rw description? string 403 | +--rw policy 405 2.2.2.5. MPLS 407 MPLS data plane related information is grouped together. MPLS 408 control plane protocols are included above. MPLS may reuse and 409 build on [OC-MPLS] or other emerging models and is shown below: 411 +--rw device 412 +--rw logical-network-elements 413 +--rw networking-instances 414 +--rw networking-instance* [networking-instance-name] 415 +--rw mpls 416 | +--rw global 417 | +--rw label-switched-paths 418 | +--rw constrained-path 419 | +--rw igp-congruent 420 | +--rw static 422 2.2.2.6. Networking Services 424 A device may provide services to other devices within the scope of a 425 networking instance. Examples shown below include a device-based 426 Network Time Protocol (NTP) server, a Domain Name System (DNS) server, 427 and a Dynamic Host Configuration Protocol (DHCP) server: 429 +--rw device 430 +--rw logical-network-elements 431 +--rw networking-instances 432 +--rw networking-instance* [networking-instance-name] 433 +--rw networking-services 434 +--rw ntp-server 435 +--rw dns-server 436 +--rw dhcp-server 438 2.3. Device View vs Logical Network Element (LNE) View Management 440 On some devices it is possible to limit control and management to a 441 scoped set of system resources. As stated above in Section 2.2., the 442 documented approach supports this capability using logical network 443 elements and the system management device-view leaf. 445 When the device-view leaf is set to true, information accessible via 446 a logical network element's system management functions represents 447 the complete device. This applies to all system management 448 functions, not just those represented in the YANG model. When 449 viewing information represented in a YANG model, the device model 450 will cover the full device and allow management across all logical 451 network elements. 453 The case when a logical network element's system management functions 454 do not have a device wide view is more complex. In this case, there 455 are two perspectives: one from functions that are operating within a 456 context of a logical network element that has a device wide view (or 457 more simply have a "device view"); and the other from functions that 458 are operating within a context of a logical network element that has 459 only a logical network element view (or more simply have an "LNE 460 view"). 462 From a management function operating with a device view, the 463 limited logical network element's system management device-view 464 leaf is simply set to false. 466 Management functions operating with an LNE view can only see 467 information (e.g., resources, interfaces, configuration, operational 468 state, etc.) associated with in the logical network element. When 469 viewing information represented in a YANG model, a full device model 470 (as defined in this document) is available from within the view, but 471 it includes only those elements associated with the LNE. For 472 information contained with the logical-network-element container 473 entry, this is the same information as available in a device wide 474 view. Information outside the logical-network-elements container is 475 made available within an LNE view as is appropriated based on device 476 wide configuration. For example, interfaces assigned to the logical 477 network element can be managed from within the LNE view. Note: some 478 information that can be modified from a device view may be read-only 479 from within the LNE view. 481 Multiple implementation approaches are possible to provide LNE views, 482 and these are outside the scope of this document. 484 3. Populating the structural model 486 The structural model in this document describes how individual YANG 487 models may be used together to represent the configuration and 488 operational state for all parts of a physical or virtual device. It 489 does not, however, document the actual model in its entirety. In 490 this section, we outline an option for creating the full model and 491 also describe how it may be used. 493 3.1. Constructing the device model 495 One of the challenges in assembling existing YANG models is that they 496 are generally written with the assumption that each model is at the 497 root of the configuration or state tree. Combining models then 498 results in a multi-rooted tree that does not follow any logical 499 construction and makes it difficult to work with operationally. In 500 some cases, models explicitly reference other models (e.g., via 501 augmentation) to define a relationship, but this is the case for only 502 a few existing models. 504 Some examples include the interfaces [RFC7223] and IP management 505 [RFC7277] models, and proposed IS-IS [RTG-ISIS], OSPF [RTG-OSPF] and 506 routing configuration [RTG-CFG] models. 508 3.2. "Pull" approach for model composition 510 To enable model composition, one possible approach is to avoid using 511 root-level containers in individual component models. Instead, the 512 top level container (and all other data definitions) can be enclosed 513 in a YANG 'grouping' statement so that when the model is imported by 514 another model, its location in the configuration tree can be 515 controlled by the importing YANG module with the 'uses' statement. 516 One advantage of this approach is that the importing module has the 517 flexibility to readily use the data definitions where the author 518 deems appropriate. 520 One obvious drawback is that individual models no longer contain any 521 of their own data definitions and must be used by a higher-level 522 model for their data nodes to become active. Some judgment as to 523 which models are more suited for inclusion in higher level models is 524 also necessary to decide when the corresponding YANG module should 525 contain only groupings. Another potential drawback is that this 526 approach does not define a common structure for models to fit 527 together, limiting interoperability due to implementations using 528 different structures. To address this, a top-level standard model 529 structure could be defined and updated to import new models into the 530 hierarchy as they are defined. 532 3.3. "Push" approach for model composition 534 An alternative approach is to develop a top level model which defines 535 the overall structure of the models, similar to the structure 536 described in Section 2. Individual models may augment the top level 537 model with their data nodes in the appropriate locations. The 538 drawback is the need for a pre-defined top level model structure. On 539 the other hand, when this top level model is standardized, it can 540 become the basis for a vendor-neutral way to manage devices, assuming 541 that the component models are supported by a given implementation. 543 One question in both approaches is what the root of the top-level 544 model should be. In this document we selected to base the model at a 545 device because this layer should be common across many use cases and 546 implementations. Starting at a higher layer (e.g., services) makes 547 defining and agreeing on a common organization more challenging as 548 discussed in Section 1.1. 550 Ideally, one could consider a hybrid construction mechanism that 551 supports both styles of model composition. For example, a YANG 552 compiler or preprocessing directive could be used to indicate whether 553 an individual model should assume it is at the root, or whether it is 554 meant for inclusion in other higher-level models. 556 4. Security Considerations 558 The model structure described in this document does not define actual 559 configuration and state data, hence it is not directly responsible 560 for security risks. 562 However, each of the component models that provide the corresponding 563 configuration and state data should be considered sensitive from a 564 security standpoint since they generally manipulate aspects of 565 network configurations. Each component model should be carefully 566 evaluated to determine its security risks, along with mitigations to 567 reduce such risks. 569 5. IANA Considerations 571 This YANG model currently uses a temporary ad-hoc namespace. If it 572 is placed or redirected for the standards track, an appropriate 573 namespace URI will be registered in the "IETF XML Registry" 574 [RFC3688]. The YANG structure modules will be registered in the 575 "YANG Module Names" registry [RFC6020]. 577 6. YANG module 579 The model structure is described by the YANG module below. 581 6.1. Model structure 583 file "model-structure.yang" 584 module model-structure { 586 yang-version "1"; 588 // namespace 589 namespace "urn:ietf:params:xml:ns:yang:model-structure"; 591 prefix "struct"; 593 // import some basic types 595 // meta 596 organization "OpenConfig working group/IETF RTG YANG Design Team"; 598 contact 599 "OpenConfig working group netopenconfig@googlegroups.com 600 Routing Area YANG Architecture DT rtg-dt-yang-arch@ietf.org"; 602 description "This module describes a model structure for YANG 603 configuration and operational state data models. Its intent is 604 to describe how individual device protocol and feature models 605 fit together and interact."; 607 revision "2015-07-09" { 608 description 609 "First Pass of IETF Routing YANG Design Team"; 610 reference "draft-rtgyangdt-rtgwg-device-model-00.txt"; 611 } 613 // extension statements 615 // feature statements 617 // identity statements 619 // typedef statements 621 // grouping statements 623 grouping info { 624 description 625 "Base system information"; 627 container info { 628 description 629 "This container is for base system information, including 630 device type (e.g., physical or virtual), model, serial no., 631 location, etc."; 633 leaf device-type { 634 //TODO: consider changing to an identity if finer grained 635 // device type classification is envisioned 636 type enumeration { 637 enum PHYSICAL { 638 description "physical or hardware device"; 639 } 640 enum VIRTUAL { 641 description "virtual or software device"; 642 } 643 } 644 description 645 "Type of the device, e.g., physical or virtual. This node 646 may be used to activate other containers in the model"; 647 } 649 } 650 } 652 grouping hardware { 653 description 654 "hardware / vendor -specific data relevant to the platform"; 656 container hardware { 657 description 658 "This container is an anchor point for platform-specific 659 configuration and operational state data. It may be further 660 organized into chassis, line cards, ports, etc. It is 661 expected that vendor or platform-specific augmentations 662 would be used to populate this part of the device model"; 663 } 664 } 666 grouping interface-ip-common { 667 description 668 "interface-specific configuration for IP interfaces, IPv4 and 669 IPv6"; 671 } 673 grouping interfaces { 674 description "interface-related models"; 675 container interfaces { 676 description "Various interface models"; 677 reference "RFC 7223 - A Yang Model for Interface Management"; 678 list interface { 679 key "name"; 680 description "List of interfaces keyed by name"; 681 leaf name { 682 type string; 683 description "Interface name"; 684 } 685 leaf bind-network-element-id { 686 type uint8; 687 description "Logical network element ID to which 688 interface is bound"; 689 } 690 container ethernet { 691 description "Ethernet interface config, e.g., 10, 40, 692 100GB Ethernet"; 693 leaf bind-networking-instance-name { 694 type string; 695 description "Networking Instance to which 696 the Ethernet instance is bound"; 697 } 698 container aggregates { 699 description 700 "LAGs, LACP, etc. for Ethernet interfaces"; 701 reference "IEEE 802.1ad, 802.1AX"; 702 } 703 container rstp { 704 description "Rapid Spanning Tree Protocol"; 705 reference "IEEE 802.1D-2004"; 706 } 707 container lldp { 708 description "link layer discovery protocol"; 709 reference "IEEE 802.1AB"; 710 } 711 container ptp { 712 description 713 "Precision Time Protocol (PTP) for time 714 synchronization services. PTP typically requires 715 per-interface configuration"; 716 reference "IEEE 1588-2008"; 717 } 718 } 719 container vlans { 720 description "VLANs, 802.1q, q-in-q, etc."; 721 reference "IEEE 802.1Q"; 722 } 723 container tunnels { 724 description 725 "Logical tunnel interfaces incl. GRE, VxLAN, 726 L2TP etc."; 727 } 729 container ipv4 { 730 description "IPv4 interface"; 731 reference "RFC 7277 - A Yang Model for IP Management"; 732 leaf bind-networking-instance-name { 733 type string; 734 description "Networking Instance to which 735 IPv4 interface is bound"; 736 } 737 container arp { 738 description "Address resolution protocol"; 739 reference "STD 37 - An Ethernet Address Resolution 740 Protocol"; 741 } 742 container icmp { 743 description "Internet Control Message Protocol"; 744 reference "RFC 792 - Internet Control Message Protocol"; 745 } 746 container vrrp { 747 description "virtual router redundancy protocol"; 748 reference 749 "RFC 5798 - Virtual Router Redundancy Protocol 750 (VRRP) Version 3 for IPv4 and IPv6"; 751 } 752 container dhcp-client { 753 description "Dynamic Host Configuration Protocol"; 754 reference 755 "RFC 2131 - Dynamic Host Configuration Protocol"; 756 } 757 } 758 container ipv6 { 759 description "IPv6 interface"; 760 reference "RFC 7277 - A Yang Model for IP Management"; 761 leaf bind-networking-instance-name { 762 type string; 763 description "Networking Instance to which 764 IPv4 interface is bound"; 765 } 766 container vrrp { 767 description "virtual router redundancy protocol"; 768 reference 769 "RFC 5798 - Virtual Router Redundancy Protocol 770 (VRRP) Version 3 for IPv4 and IPv6"; 771 } 772 container icmpv6 { 773 description "Internet Control Message Protocol"; 774 reference 775 "RFC 2463 - Internet Control Message Protocol 776 (ICMPv6) for Internet Protocol Version 6 (IPv6)"; 777 } 778 container nd { 779 description "IPv6 Neighbor Discovery"; 780 reference "RFC 4861 - Neighbor Discovery for IP 781 version 6 (IPv6)"; 782 } 783 container dhcpv6-client { 784 description 785 "Dynamic Host Configuration Protocol Version 6"; 786 reference 787 "RFC 3315 - Dynamic Host Configuration Protocol 788 for IPv6 (DHCPv6)"; 789 } 790 } 791 } 792 } 793 } 795 identity networking-instance { 796 description 797 "Base identity from which identities describing 798 networking instance types are derived."; 799 } 801 grouping router-id { 802 description 803 "This grouping provides router ID."; 804 leaf router-id { 805 type uint32; // yang:dotted-quad 806 description 807 "A 32-bit number in the form of a dotted quad that is 808 used by some routing protocols identifying a router."; 809 reference 810 "RFC 2328: OSPF Version 2."; 811 } 812 } 814 grouping oam-protocols { 815 description 816 "Definitions for OAM protocols within a networking-instance"; 817 container oam-protocols { 818 description 819 "OAM protocols"; 820 container bfd { 821 description "Bi-directional Forwarding Detection (BFD) 822 configuration"; 824 } 825 container cfm { 826 description 827 "Ethernet connectivity fault management. Also includes 828 options that are associated with specific interfaces, 829 such as maintenance endpoint domains."; 830 reference "IEEE 802.1ag"; 831 } 832 container twamp { 833 description 834 "Two-way active measurement protocol for measuring 835 round-trip IP layer performance."; 836 reference "RFC 5357 A Two-Way Active Measurement Protocol 837 (TWAMP)"; 838 } 839 } 840 } 842 grouping mpls { 843 description "MPLS and TE configuration"; 844 container mpls { 845 description "MPLS and TE configuration"; 846 container global { 847 description "global MPLS configuration"; 848 } 849 container label-switched-paths { 850 description "Models for different types of LSPs"; 851 } 852 container constrained-path { 853 description "traffic-engineered or constrained path LSPs"; 854 } 855 container igp-congruent { 856 description "LSPs that follow the IGP-computed path"; 857 } 858 container static { 859 description "Statically configured LSPs"; 860 } 861 } 862 } 864 grouping networking-instance-policy { 865 description 866 "Networking instance policies such as route 867 distinguisher, route targets, VPLS ID and neighbor, 868 Ethernet ID, etc. "; 869 reference 870 "RFC 4364 - BGP/MPLS Virtual Private Networks (VPNs) 871 RFC 6074 - Provisioning, Auto-Discovery, and Signaling 872 in Layer 2 Virtual Private Networks (L2VPNs) 873 RFC 7432 - BGP MPLS-Based Ethernet VPN"; 874 container networking-instance-policy { 875 description "Networking Instance Policy -- details TBD"; 876 } 877 } 879 grouping control-plane-protocols { 880 description "control protocol models"; 882 container control-plane-protocols { 883 description "Control plane protocols and features"; 885 container bgp { 886 description "BGP-4 protocol configuration"; 887 reference "RFC 4271 - Border Gateway Protocol 4 (BGP-4)"; 888 container policy { 889 description "Policy specific to BGP"; 890 } 891 } 892 container is-is { 893 description "ISO IS-IS protocol configuration"; 894 reference "RFC 1195 - Use of OSI IS-IS for Routing in 895 TCP/IP and Dual Environments"; 896 container policy { 897 description "Policy specific to IS-IS"; 898 } 899 } 900 container ospf { 901 description "Open Shortest Path First (OSPF) protocol 902 configuration"; 903 reference "RFC 2328 - OSPFv2 Protocol 904 RFC 5340 - OSPF for IPv6"; 905 container policy { 906 description "Policy specific to OSPF"; 907 } 908 } 909 container rsvp { 910 description "Resource Reservation Protocol (RSVP) 911 protocol configuration"; 912 reference "RFC 2205 - Resource ReSerVation Protocol (RSVP) 913 RFC 3209 - RSVP-TE: Extensions to RSVP for LSP 914 Tunnels"; 915 } 916 container segment-routing { 917 description "Segment Routing configuration for networking 918 instance"; 919 reference "draft-likowski-spring-sr-yang"; 920 } 921 container ldp { 922 description "Label Distribution Protocol (LDP) 923 configuration"; 924 reference "RFC 5036 - LDP Specification"; 925 } 926 container pim { 927 description "Protocol Independent Multicast (PIM) 928 configuration"; 929 reference "RFC 4601 - Protocol Independent Multicast - 930 Sparse Mode (PIM-SM) Protocol Specification"; 931 } 932 container igmp { 933 description "Internet Group Management Protocol 934 configuration"; 935 reference "RFC 3376 - Internet Group Management Protocol, 936 Version 3"; 937 } 938 container mld { 939 description "Multicast Listener Discovery Protocol 940 configuration"; 941 reference "RFC 3810 - Multicast Listener Discovery 942 Version 2 (MLDv2 for IPv6)"; 943 } 944 container static-routes { 945 description "Static route configuration"; 946 reference "draft-ietf-netmod-routing-cfg"; 947 } 948 } 950 } 952 grouping ribs { 953 description 954 "Routing Information Bases (RIBs) supported by a 955 networking-instance"; 956 container ribs { 957 description 958 "RIBs supported by a networking-instance"; 959 list rib { 960 key "name"; 961 min-elements "1"; 962 description 963 "Each entry represents a RIB identified by the 964 'name' key. All routes in a RIB must belong to the 965 same address family. 967 For each routing instance, an implementation should 968 provide one system-controlled default RIB for each 969 supported address family."; 970 leaf name { 971 type string; 972 description 973 "The name of the RIB."; 974 } 975 reference "draft-ietf-netmod-routing-cfg"; 976 leaf description { 977 type string; 978 description 979 "Description of the RIB"; 980 } 981 // Note that there is no list of interfaces within 982 container policy { 983 description "Policy specific to RIB"; 984 } 985 } 986 } 987 } 989 grouping networking-services { 990 description 991 "Networking services provided by the device in the scope of 992 the networking-instance"; 993 container networking-services { 994 description "Networking services"; 995 container ntp-server { 996 description "Network Time Protocol (NTP) Server"; 997 reference "RFC 5905 - Network Time Protocol Version 4: 998 Protocol and Algorithms Specification"; 1000 } 1001 container dns-server { 1002 description "Domain Name System (DNS) Server"; 1003 reference "RFC 1035 - DOMAIN NAMES - IMPLEMENTATION 1004 AND SPECIFICATION"; 1005 } 1006 container dhcp-server { 1007 description "Dynamic Host Configuration Protocol (DHCP) 1008 Server"; 1009 reference "RFC 2131 - Dynamic Host Configuration Protocol"; 1010 } 1011 } 1012 } 1014 grouping system-management { 1015 description "System management for device or logical network 1016 element"; 1017 container system-management { 1018 description "System management - logical device 1019 management with reuse of RFC 7317"; 1020 leaf device-view { 1021 type boolean; 1022 default "true"; 1023 description "Flag indicating whether or not the 1024 logical network element is able to view 1025 and manage the entire device"; 1026 } 1027 container syslog { 1028 description "Syslog configuration"; 1029 } 1030 container dns { 1031 description "Domain Name Service (DNS) and resolver 1032 configuration"; 1033 } 1034 container ntp { 1035 description "network time protocol configuration"; 1036 } 1037 container statistics-collection { 1038 description 1039 "Mechanisms for data collection from devices, 1040 including packet and flow-level sampling"; 1041 } 1042 container ssh { 1043 description "SSH server configuration"; 1044 } 1045 container tacacs { 1046 description "TACACS+ configuration"; 1047 } 1048 container snmp { 1049 description "System Network Management Protocol 1050 (SNMP) configuration"; 1051 } 1052 container netconf { 1053 description "Network Configuration Protocol(NETCONF)"; 1054 reference "RFC 6020 - YANG - A Data Modeling Language 1055 for the Network Configuration Protocol 1056 (NETCONF)"; 1057 } 1058 } 1059 } 1061 grouping ietf-acl { 1062 description "Packet Access Control Lists (ACLs) as specified 1063 in draft-ietf-netmod-acl-model"; 1064 container ietf-acl { 1065 description "ACLs and packet forwarding rules"; 1066 } 1067 } 1069 grouping ietf-key-chain { 1070 description "Key chains as specified in 1071 draft-acee-rtgwg-yang-key-chain;"; 1072 container ietf-key-chain { 1073 description "Key chains"; 1074 } 1075 } 1077 grouping qos { 1078 description "QoS features"; 1080 container qos { 1081 description "QoS, including policing, shaping, etc."; 1082 } 1083 } 1085 // data definition statements 1087 container device { 1088 description "Top-level anchor point for models. Device is a 1089 generic L2/L3 network element"; 1090 uses info; 1091 uses hardware; 1092 uses interfaces; 1093 uses qos; 1094 container logical-network-elements { 1095 description "Network devices may support multiple logical 1096 network instances"; 1097 list logical-network-element { 1098 key network-element-id; 1099 description "List of logical network elements"; 1100 leaf network-element-id { 1101 type uint8; // expect a small number of logical routers 1102 description "Device-wide unique identifier for the 1103 logical network element"; 1104 } 1105 leaf network-element-name { 1106 type string; 1107 description "Descriptive name for the logical network 1108 element"; 1109 } 1110 leaf default-networking-instance-name { 1111 type string; 1112 description "Specification of the networking instance to 1113 use for management connectivity"; 1114 } 1115 uses system-management; 1116 uses ietf-acl; 1117 uses ietf-key-chain; 1118 container networking-instances { 1119 description "Networking instances each of which have 1120 an independent IP/IPv6 addressing space 1121 and protocol instantiations. For layer 3, 1122 this consistent with the routing-instance 1123 definition in ietf-routing"; 1124 reference "draft-ietf-netmod-routing-cfg"; 1125 list networking-instance { 1126 key networking-instance-name; 1127 description "List of networking-instances"; 1128 leaf networking-instance-name { 1129 type string; 1130 description "logical network element scoped 1131 identifier for the networking 1132 instance"; 1133 } 1134 leaf type { 1135 type identityref { 1136 base networking-instance; 1137 } 1138 description 1139 "The networking instance type -- details TBD 1140 Likely types include core, L3-VRF, VPLS, 1141 L2-cross-connect, L2-VSI, etc."; 1142 } 1143 leaf enabled { 1144 type boolean; 1145 default "true"; 1146 description 1147 "Flag indicating whether or not the networking 1148 instance is enabled."; 1149 } 1150 uses router-id { 1151 description 1152 "Router ID for networking instances"; 1153 } 1154 leaf description { 1155 type string; 1156 description 1157 "Description of the networking instance 1158 and its intended purpose"; 1159 } 1160 // Note that there is no list of interfaces within 1161 // the networking-instance 1162 uses oam-protocols; 1163 uses networking-instance-policy; 1164 uses control-plane-protocols; 1165 uses ribs; 1166 uses mpls; 1167 uses networking-services; 1168 } 1169 } 1170 } 1171 } 1173 } 1175 // augment statements 1177 // rpc statements 1179 // notification statements 1181 } 1182 1184 7. References 1186 7.1. Normative references 1188 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 1189 Network Configuration Protocol (NETCONF)", RFC 6020, 1190 October 2014. 1192 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 1193 Management", RFC 7223, May 2014. 1195 [RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", RFC 1196 7277, June 2014. 1198 [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for 1199 System Management", RFC 7317, August 2014. 1201 [RFC3688] Mealling, M., "The IETF XML Registry", RFC 3688, January 1202 2004. 1204 7.2. Informative references 1206 [OC-MPLS] George, J., Fang, L., Osborne, E., Shakir, R., "MPLS TE 1207 Model for Service Provider Networks", 1208 draft-openconfig-mpls-consolidated-model-00 (work in 1209 progress). 1211 [OC-STRUCT] Shaikh, A., Shakir, R., D'Souza, K., Fang, L., 1212 "Operational Structure and Organization of YANG Models", 1213 draft-openconfig-netmod-model-structure-00 (work in 1214 progress). 1216 [RFC4026] Andersson, L., Madsen, T., "Provider Provisioned Virtual 1217 Private Network (VPN) Terminology", RFC 4026, March 2005. 1219 [RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", 1220 RFC 7277, June 2014. 1222 [RTG-CFG] Lhotka, L., "A YANG Data Model for Routing Management", 1223 draft-ietf-netmod-routing-cfg-19 (work in progress), 1224 October 2014. 1226 [RTG-POLICY] 1227 Shaikh, A., Shakir, R., D'Souza, K., and C. Chase, 1228 "Routing Policy Configuration Model for Service Provider 1229 Networks", draft-shaikh-rtgwg-policy-model-01 (work in 1230 progress), July 2015. 1232 [RTG-OSPF] Yeung, D., Qu, Y., Zhang, J., and D. Bogdanovic, "Yang 1233 Data Model for OSPF Protocol", draft-yeung-netmod-ospf-02 1234 (work in progress), October 2014. 1236 [RTG-ISIS] Litkowski, S., Yeung, D., Lindem, A., Zhang, J., and L. 1237 Lhotka, "YANG Data Model for ISIS protocol", draft-ietf- 1238 isis-yang-isis-cfg-04 (work in progress), October 2014. 1240 Appendix A. Acknowledgments 1242 This document is derived from 1243 draft-openconfig-netmod-model-structure-00. The Authors of that 1244 document who are not also authors of this document are listed as 1245 Contributors to this work. 1247 The original stated: The authors are grateful for valuable 1248 contributions to this document and the associated models from: Deepak 1249 Bansal, Paul Borman, Chris Chase, Josh George, Marcus Hines, and Jim 1250 Uttaro. 1252 The Routing Area Yang Architecture design team members included Acee 1253 Lindem, Anees Shaikh, Christian Hopps, Dean Bogdanovic, Lou Berger, 1254 Qin Wu, Rob Shakir, Stephane Litkowski, and Yan Gang. 1256 Contributors 1258 Anees Shaikh 1259 Google 1260 1600 Amphitheatre Pkwy 1261 Mountain View, CA 94043 1262 US 1263 Email: aashaikh@google.com 1265 Rob Shakir 1266 BT 1267 pp. C3L, BT Centre 1268 81, Newgate Street 1269 London EC1A 7AJ 1270 UK 1271 Email: rob.shakir@bt.com 1272 URI: http://www.bt.com/ 1274 Kevin D'Souza 1275 AT&T 1276 200 S. Laurel Ave 1277 Middletown, NJ 1278 US 1279 Email: kd6913@att.com 1281 Luyuan Fang 1282 Microsoft 1283 205 108th Ave. NE, Suite 400 1284 Bellevue, WA 1285 US 1286 Email: lufang@microsoft.com 1288 Qin Wu 1289 Email: bill.wu@huawei.com 1291 Stephane Litkowski 1292 Email: stephane.litkowski@orange.com 1294 Yan Gang 1295 Email: yangang@huawei.com 1297 Authors' Addresses 1299 Acee Lindem 1300 Cisco Systems 1301 301 Midenhall Way 1302 Cary, NC 27513 1303 USA 1304 Email: acee@cisco.com 1306 Lou Berger (editor) 1307 LabN Consulting, L.L.C. 1308 Email: lberger@labn.net 1310 Dean Bogdanovic 1311 Email: ivandean@gmail.com 1313 Christian Hopps 1314 Deustche Telekom 1315 Email: chopps@chopps.org