idnits 2.17.1 draft-ietf-netmod-rfc7223bis-03.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 : ---------------------------------------------------------------------------- == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. -- The abstract seems to indicate that this document obsoletes RFC7223, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 239 has weird spacing: '...ty-time yan...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (January 11, 2018) is 2290 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-10) exists of draft-ietf-netmod-revised-datastores-07 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) == Outdated reference: A later version (-06) exists of draft-ietf-netmod-yang-tree-diagrams-02 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Bjorklund 3 Internet-Draft Tail-f Systems 4 Obsoletes: rfc7223 (if approved) January 11, 2018 5 Intended status: Standards Track 6 Expires: July 15, 2018 8 A YANG Data Model for Interface Management 9 draft-ietf-netmod-rfc7223bis-03 11 Abstract 13 This document defines a YANG data model for the management of network 14 interfaces. It is expected that interface-type-specific data models 15 augment the generic interfaces data model defined in this document. 16 The data model includes definitions for configuration and system 17 state (status information and counters for the collection of 18 statistics). 20 The YANG model in this document conforms to the Network Management 21 Datastore Architecture defined in I-D.ietf-netmod-revised-datastores. 23 This document obsoletes RFC 7223. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on July 15, 2018. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Summary of Changes from RFC 7223 . . . . . . . . . . . . 3 61 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.3. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Interfaces Data Model . . . . . . . . . . . . . . . . . . . . 5 65 3.1. The Interface List . . . . . . . . . . . . . . . . . . . 6 66 3.2. Interface References . . . . . . . . . . . . . . . . . . 8 67 3.3. Interface Layering . . . . . . . . . . . . . . . . . . . 8 68 4. Relationship to the IF-MIB . . . . . . . . . . . . . . . . . 9 69 5. Interfaces YANG Module . . . . . . . . . . . . . . . . . . . 10 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 34 72 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 74 9.1. Normative References . . . . . . . . . . . . . . . . . . 35 75 9.2. Informative References . . . . . . . . . . . . . . . . . 36 76 Appendix A. Example: Ethernet Interface Module . . . . . . . . . 37 77 Appendix B. Example: Ethernet Bonding Interface Module . . . . . 38 78 Appendix C. Example: VLAN Interface Module . . . . . . . . . . . 39 79 Appendix D. Example: NETCONF Reply . . . . . . . . 41 80 Appendix E. Example: NETCONF Reply . . . . . . . . . 42 81 Appendix F. Examples: Interface Naming Schemes . . . . . . . . . 44 82 F.1. Router with Restricted Interface Names . . . . . . . . . 44 83 F.2. Router with Arbitrary Interface Names . . . . . . . . . . 45 84 F.3. Ethernet Switch with Restricted Interface Names . . . . . 46 85 F.4. Generic Host with Restricted Interface Names . . . . . . 46 86 F.5. Generic Host with Arbitrary Interface Names . . . . . . . 47 87 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 48 89 1. Introduction 91 This document defines a YANG [RFC7950] data model for the management 92 of network interfaces. It is expected that interface-type-specific 93 data models augment the generic interfaces data model defined in this 94 document. 96 Network interfaces are central to the management of many Internet 97 protocols. Thus, it is important to establish a common data model 98 for how interfaces are identified, configured, and monitored. 100 The data model includes configuration data and state data (status 101 information and counters for the collection of statistics). 103 This version of the interfaces data model supports the Network 104 Management Datastore Architecture (NMDA) 105 [I-D.ietf-netmod-revised-datastores]. 107 1.1. Summary of Changes from RFC 7223 109 The "/interfaces-state" subtree with "config false" data nodes is 110 deprecated. All "config false" data nodes are now present in the 111 "/interfaces" subtree. 113 Servers that do not implement NMDA, or that wish to support clients 114 that do not implement NMDA, MAY implement the deprecated 115 "/interfaces-state" tree. 117 1.2. Terminology 119 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 121 "OPTIONAL" in this document are to be interpreted as described in BCP 122 14, [RFC2119] [RFC8174] when, and only when, they appear in all 123 capitals, as shown here. 125 The following terms are used within this document: 127 o system-controlled interface: An interface is said to be system- 128 controlled if the system creates and deletes the interface 129 independently of what has been explicitly configured. Examples 130 are interfaces representing physical hardware that appear and 131 disappear when hardware (e.g., a line card or hot-pluggable 132 wireless interface) is added or removed. System-controlled 133 interfaces may also appear if a certain functionality is enabled 134 (e.g., a loopback interface might appear if the IP protocol stack 135 is enabled). 137 o user-controlled interface: An interface is said to be user- 138 controlled if the creation of the interface is controlled by 139 adding explicit interface configuration to the intended 140 configuration and the removal of the interface is controlled by 141 removing explicit interface configuration from the intended 142 configuration. Examples are VLAN interfaces configured on a 143 system-controlled Ethernet interface. 145 The following terms are defined in 146 [I-D.ietf-netmod-revised-datastores] and are not redefined here: 148 o client 150 o server 152 o configuration 154 o system state 156 o operational state 158 o intended configuration 160 The following terms are defined in [RFC7950] and are not redefined 161 here: 163 o augment 165 o data model 167 o data node 169 o presence container 171 1.3. Tree Diagrams 173 Tree diagrams used in this document follow the notation defined in 174 [I-D.ietf-netmod-yang-tree-diagrams]. 176 2. Objectives 178 This section describes some of the design objectives for the model 179 presented in Section 5. 181 o It is recognized that existing implementations will have to map 182 the interface data model defined in this memo to their proprietary 183 native data model. To facilitate such mappings, the data model 184 should be simple. 186 o The data model should be suitable for new implementations to use 187 as is, without requiring a mapping to a different native model. 189 o References to interfaces should be as simple as possible, 190 preferably by using a single leafref. 192 o The mapping to ifIndex [RFC2863] used by the Simple Network 193 Management Protocol (SNMP) to identify interfaces must be clear. 195 o The model must support interface layering: both (1) simple 196 layering, where one interface is layered on top of exactly one 197 other interface, and (2) more complex scenarios, where one 198 interface results from the aggregation of N other interfaces or 199 when N interfaces are multiplexed over one other interface. 201 o The data model should support the pre-provisioning of interface 202 configuration, i.e., it should be possible to configure an 203 interface whose physical interface hardware is not present on the 204 device. It is recommended that devices that support dynamic 205 addition and removal of physical interfaces also support pre- 206 provisioning. 208 o The data model should support physical interfaces as well as 209 logical interfaces. 211 o The data model should include read-only counters in order to 212 gather statistics for sent and received octets and packets, 213 received packets with errors, and packets that could not be sent 214 due to errors. 216 3. Interfaces Data Model 218 This document defines the YANG module "ietf-interfaces", which has 219 the following structure, excluding the deprecated "/interfaces-state" 220 subtree: 222 module: ietf-interfaces 223 +--rw interfaces 224 +--rw interface* [name] 225 +--rw name string 226 +--rw description? string 227 +--rw type identityref 228 +--rw enabled? boolean 229 +--rw link-up-down-trap-enable? enumeration {if-mib}? 230 +--ro admin-status enumeration {if-mib}? 231 +--ro oper-status enumeration 232 +--ro last-change? yang:date-and-time 233 +--ro if-index int32 {if-mib}? 234 +--ro phys-address? yang:phys-address 235 +--ro higher-layer-if* interface-ref 236 +--ro lower-layer-if* interface-ref 237 +--ro speed? yang:gauge64 238 +--ro statistics 239 +--ro discontinuity-time yang:date-and-time 240 +--ro in-octets? yang:counter64 241 +--ro in-unicast-pkts? yang:counter64 242 +--ro in-broadcast-pkts? yang:counter64 243 +--ro in-multicast-pkts? yang:counter64 244 +--ro in-discards? yang:counter32 245 +--ro in-errors? yang:counter32 246 +--ro in-unknown-protos? yang:counter32 247 +--ro out-octets? yang:counter64 248 +--ro out-unicast-pkts? yang:counter64 249 +--ro out-broadcast-pkts? yang:counter64 250 +--ro out-multicast-pkts? yang:counter64 251 +--ro out-discards? yang:counter32 252 +--ro out-errors? yang:counter32 254 3.1. The Interface List 256 The data model for interfaces presented in this document uses a flat 257 list of interfaces ("/interfaces/interface"). Each interface in the 258 list is identified by its name. Furthermore, each interface has a 259 mandatory "type" leaf. 261 The "iana-if-type" module [RFC7224] defines YANG identities for the 262 interface types in the IANA-maintained "ifType definitions" registry. 264 It is expected that interface-type-specific data models augment the 265 interface list and possibly use the "type" leaf to make the 266 augmentation conditional. 268 As an example of such an interface-type-specific augmentation, 269 consider this YANG snippet. For a more complete example, see 270 Appendix A. 272 import interfaces { 273 prefix "if"; 274 } 275 import iana-if-type { 276 prefix ianaift; 277 } 279 augment "/if:interfaces/if:interface" { 280 when "if:type = 'ianaift:ethernetCsmacd'"; 282 container ethernet { 283 leaf duplex { 284 ... 285 } 286 } 287 } 289 For system-controlled interfaces, the "name" is the device-specific 290 name of the interface. 292 If the device supports arbitrarily named user-controlled interfaces, 293 then the server will advertise the "arbitrary-names" feature. If the 294 server does not advertise this feature, the names of user-controlled 295 interfaces MUST match the device's naming scheme. How a client can 296 learn the naming scheme of such devices is outside the scope of this 297 document. See Appendix F.1 and Appendix F.2 for examples. 299 When a system-controlled interface is created in the operational 300 state by the system, the system tries to apply the interface 301 configuration in the intended configuration with the same name as the 302 new interface. If no such interface configuration is found, or if 303 the configured type does not match the real interface type, the 304 system creates the interface without applying explicit configuration. 306 When a user-controlled interface is created, the configuration 307 determines the name of the interface. 309 Depending on the operating system and the physical attachment point 310 to which a network interface may be attached or removed, it may be 311 impossible for an implementation to provide predictable and 312 consistent names for system-controlled interfaces across insertion/ 313 removal cycles as well as in anticipation of initial insertion. The 314 ability to provide configurations for such interfaces is therefore 315 dependent on the implementation and cannot be assumed in all cases. 317 3.2. Interface References 319 An interface is identified by its name, which is unique within the 320 server. This property is captured in the "interface-ref" typedef, 321 which other YANG modules SHOULD use when they need to reference an 322 interface. 324 3.3. Interface Layering 326 There is no generic mechanism for how an interface is configured to 327 be layered on top of some other interface. It is expected that 328 interface-type-specific models define their own data nodes for 329 interface layering by using "interface-ref" types to reference lower 330 layers. 332 Below is an example of a model with such nodes. For a more complete 333 example, see Appendix B. 335 import interfaces { 336 prefix "if"; 337 } 338 import iana-if-type { 339 prefix ianaift; 340 } 342 augment "/if:interfaces/if:interface" { 343 when "if:type = 'ianaift:ieee8023adLag'"; 345 leaf-list slave-if { 346 type if:interface-ref; 347 must "/if:interfaces/if:interface[if:name = current()]" 348 + "/if:type = 'ianaift:ethernetCsmacd'" { 349 description 350 "The type of a slave interface must be 351 'ethernetCsmacd'."; 352 } 353 } 354 // other bonding config params, failover times, etc. 355 } 357 While the interface layering is configured in interface-type-specific 358 models, two generic state data leaf-lists, "higher-layer-if" and 359 "lower-layer-if", represent a read-only view of the interface 360 layering hierarchy. 362 4. Relationship to the IF-MIB 364 If the device implements the IF-MIB [RFC2863], each entry in the 365 "/interfaces/interface" list in the operational state is typically 366 mapped to one ifEntry. The "if-index" leaf MUST contain the value of 367 the corresponding ifEntry's ifIndex. 369 In most cases, the "name" of an "/interfaces/interface" entry is 370 mapped to ifName. The IF-MIB allows two different ifEntries to have 371 the same ifName. Devices that support this feature and also support 372 the data model defined in this document cannot have a 1-1 mapping 373 between the "name" leaf and ifName. 375 The configured "description" of an "interface" has traditionally been 376 mapped to ifAlias in some implementations. This document allows this 377 mapping, but implementers should be aware of the differences in the 378 value space and persistence for these objects. See the YANG module 379 definition of the leaf "description" in Section 5 for details. 381 The IF-MIB also defines the writable object ifPromiscuousMode. Since 382 this object typically is not implemented as a configuration object by 383 SNMP agents, it is not mapped to the "ietf-interfaces" module. 385 The ifMtu object from the IF-MIB is not mapped to the 386 "ietf-interfaces" module. It is expected that interface-type- 387 specific YANG modules provide interface-type-specific MTU leafs by 388 augmenting the "ietf-interfaces" model. 390 There are a number of counters in the IF-MIB that exist in two 391 versions: one with 32 bits and one with 64 bits. The 64-bit versions 392 were added to support high-speed interfaces with a data rate greater 393 than 20,000,000 bits/second. Today's implementations generally 394 support such high-speed interfaces, and hence only 64-bit counters 395 are provided in this data model. Note that the server that 396 implements this module and an SNMP agent may differ in the time 397 granularity in which they provide access to the counters. For 398 example, it is common that SNMP implementations cache counter values 399 for some time. 401 The objects ifDescr and ifConnectorPresent from the IF-MIB are not 402 mapped to the "ietf-interfaces" module. 404 The following tables list the YANG data nodes with corresponding 405 objects in the IF-MIB. 407 +--------------------------------------+----------------------------+ 408 | YANG data node in | IF-MIB object | 409 | /interfaces/interface | | 410 +--------------------------------------+----------------------------+ 411 | name | ifName | 412 | type | ifType | 413 | description | ifAlias | 414 | admin-status | ifAdminStatus | 415 | oper-status | ifOperStatus | 416 | last-change | ifLastChange | 417 | if-index | ifIndex | 418 | link-up-down-trap-enable | ifLinkUpDownTrapEnable | 419 | phys-address | ifPhysAddress | 420 | higher-layer-if and lower-layer-if | ifStackTable | 421 | speed | ifSpeed and ifHighSpeed | 422 | discontinuity-time | ifCounterDiscontinuityTime | 423 | in-octets | ifHCInOctets | 424 | in-unicast-pkts | ifHCInUcastPkts | 425 | in-broadcast-pkts | ifHCInBroadcastPkts | 426 | in-multicast-pkts | ifHCInMulticastPkts | 427 | in-discards | ifInDiscards | 428 | in-errors | ifInErrors | 429 | in-unknown-protos | ifInUnknownProtos | 430 | out-octets | ifHCOutOctets | 431 | out-unicast-pkts | ifHCOutUcastPkts | 432 | out-broadcast-pkts | ifHCOutBroadcastPkts | 433 | out-multicast-pkts | ifHCOutMulticastPkts | 434 | out-discards | ifOutDiscards | 435 | out-errors | ifOutErrors | 436 +--------------------------------------+----------------------------+ 438 YANG Data Nodes and Related IF-MIB Objects 440 5. Interfaces YANG Module 442 This YANG module imports typedefs from [RFC6991]. 444 file "ietf-interfaces@2018-01-09.yang" 446 module ietf-interfaces { 447 yang-version 1.1; 448 namespace "urn:ietf:params:xml:ns:yang:ietf-interfaces"; 449 prefix if; 451 import ietf-yang-types { 452 prefix yang; 453 } 454 organization 455 "IETF NETMOD (Network Modeling) Working Group"; 457 contact 458 "WG Web: 459 WG List: 461 Editor: Martin Bjorklund 462 "; 464 description 465 "This module contains a collection of YANG definitions for 466 managing network interfaces. 468 Copyright (c) 2018 IETF Trust and the persons identified as 469 authors of the code. All rights reserved. 471 Redistribution and use in source and binary forms, with or 472 without modification, is permitted pursuant to, and subject 473 to the license terms contained in, the Simplified BSD License 474 set forth in Section 4.c of the IETF Trust's Legal Provisions 475 Relating to IETF Documents 476 (http://trustee.ietf.org/license-info). 478 This version of this YANG module is part of RFC XXXX; see 479 the RFC itself for full legal notices."; 481 revision 2018-01-09 { 482 description 483 "Updated to support NMDA."; 484 reference 485 "RFC XXXX: A YANG Data Model for Interface Management"; 486 } 488 revision 2014-05-08 { 489 description 490 "Initial revision."; 491 reference 492 "RFC 7223: A YANG Data Model for Interface Management"; 493 } 495 /* 496 * Typedefs 497 */ 499 typedef interface-ref { 500 type leafref { 501 path "/if:interfaces/if:interface/if:name"; 503 } 504 description 505 "This type is used by data models that need to reference 506 interfaces."; 507 } 509 /* 510 * Identities 511 */ 513 identity interface-type { 514 description 515 "Base identity from which specific interface types are 516 derived."; 517 } 519 /* 520 * Features 521 */ 523 feature arbitrary-names { 524 description 525 "This feature indicates that the device allows user-controlled 526 interfaces to be named arbitrarily."; 527 } 528 feature pre-provisioning { 529 description 530 "This feature indicates that the device supports 531 pre-provisioning of interface configuration, i.e., it is 532 possible to configure an interface whose physical interface 533 hardware is not present on the device."; 534 } 535 feature if-mib { 536 description 537 "This feature indicates that the device implements 538 the IF-MIB."; 539 reference 540 "RFC 2863: The Interfaces Group MIB"; 541 } 543 /* 544 * Data nodes 545 */ 547 container interfaces { 548 description 549 "Interface parameters."; 551 list interface { 552 key "name"; 554 description 555 "The list of interfaces on the device. 557 The status of an interface is available in this list in the 558 operational state. If the configuration of a 559 system-controlled interface cannot be used by the system 560 (e.g., the interface hardware present does not match the 561 interface type), then the configuration is not applied to 562 the system-controlled interface shown in the operational 563 state. If the configuration of a user-controlled interface 564 cannot be used by the system, the configured interface is 565 not instantiated in the operational state. 567 System-controlled interfaces created by the system are 568 always present in this list in the operational state, 569 whether they are configured or not."; 571 leaf name { 572 type string; 573 description 574 "The name of the interface. 576 A device MAY restrict the allowed values for this leaf, 577 possibly depending on the type of the interface. 578 For system-controlled interfaces, this leaf is the 579 device-specific name of the interface. 581 If a client tries to create configuration for a 582 system-controlled interface that is not present in the 583 operational state, the server MAY reject the request if 584 the implementation does not support pre-provisioning of 585 interfaces or if the name refers to an interface that can 586 never exist in the system. A NETCONF server MUST reply 587 with an rpc-error with the error-tag 'invalid-value' in 588 this case. 590 If the device supports pre-provisioning of interface 591 configuration, the 'pre-provisioning' feature is 592 advertised. 594 If the device allows arbitrarily named user-controlled 595 interfaces, the 'arbitrary-names' feature is advertised. 597 When a configured user-controlled interface is created by 598 the system, it is instantiated with the same name in the 599 operational state. 601 A server implementation MAY map this leaf to the ifName 602 MIB object. Such an implementation needs to use some 603 mechanism to handle the differences in size and characters 604 allowed between this leaf and ifName. The definition of 605 such a mechanism is outside the scope of this document."; 606 reference 607 "RFC 2863: The Interfaces Group MIB - ifName"; 608 } 610 leaf description { 611 type string; 612 description 613 "A textual description of the interface. 615 A server implementation MAY map this leaf to the ifAlias 616 MIB object. Such an implementation needs to use some 617 mechanism to handle the differences in size and characters 618 allowed between this leaf and ifAlias. The definition of 619 such a mechanism is outside the scope of this document. 621 Since ifAlias is defined to be stored in non-volatile 622 storage, the MIB implementation MUST map ifAlias to the 623 value of 'description' in the persistently stored 624 configuration."; 625 reference 626 "RFC 2863: The Interfaces Group MIB - ifAlias"; 627 } 629 leaf type { 630 type identityref { 631 base interface-type; 632 } 633 mandatory true; 634 description 635 "The type of the interface. 637 When an interface entry is created, a server MAY 638 initialize the type leaf with a valid value, e.g., if it 639 is possible to derive the type from the name of the 640 interface. 642 If a client tries to set the type of an interface to a 643 value that can never be used by the system, e.g., if the 644 type is not supported or if the type does not match the 645 name of the interface, the server MUST reject the request. 646 A NETCONF server MUST reply with an rpc-error with the 647 error-tag 'invalid-value' in this case."; 648 reference 649 "RFC 2863: The Interfaces Group MIB - ifType"; 650 } 652 leaf enabled { 653 type boolean; 654 default "true"; 655 description 656 "This leaf contains the configured, desired state of the 657 interface. 659 Systems that implement the IF-MIB use the value of this 660 leaf in the intended configuration to set 661 IF-MIB.ifAdminStatus to 'up' or 'down' after an ifEntry 662 has been initialized, as described in RFC 2863. 664 Changes in this leaf in the intended configuration are 665 reflected in ifAdminStatus."; 666 reference 667 "RFC 2863: The Interfaces Group MIB - ifAdminStatus"; 668 } 670 leaf link-up-down-trap-enable { 671 if-feature if-mib; 672 type enumeration { 673 enum enabled { 674 value 1; 675 description 676 "The device will generate linkUp/linkDown SNMP 677 notifications for this interface."; 678 } 679 enum disabled { 680 value 2; 681 description 682 "The device will not generate linkUp/linkDown SNMP 683 notifications for this interface."; 684 } 685 } 686 description 687 "Controls whether linkUp/linkDown SNMP notifications 688 should be generated for this interface. 690 If this node is not configured, the value 'enabled' is 691 operationally used by the server for interfaces that do 692 not operate on top of any other interface (i.e., there are 693 no 'lower-layer-if' entries), and 'disabled' otherwise."; 694 reference 695 "RFC 2863: The Interfaces Group MIB - 696 ifLinkUpDownTrapEnable"; 697 } 699 leaf admin-status { 700 if-feature if-mib; 701 type enumeration { 702 enum up { 703 value 1; 704 description 705 "Ready to pass packets."; 706 } 707 enum down { 708 value 2; 709 description 710 "Not ready to pass packets and not in some test mode."; 711 } 712 enum testing { 713 value 3; 714 description 715 "In some test mode."; 716 } 717 } 718 config false; 719 mandatory true; 720 description 721 "The desired state of the interface. 723 This leaf has the same read semantics as ifAdminStatus."; 724 reference 725 "RFC 2863: The Interfaces Group MIB - ifAdminStatus"; 726 } 728 leaf oper-status { 729 type enumeration { 730 enum up { 731 value 1; 732 description 733 "Ready to pass packets."; 734 } 735 enum down { 736 value 2; 737 description 738 "The interface does not pass any packets."; 739 } 740 enum testing { 741 value 3; 742 description 743 "In some test mode. No operational packets can 744 be passed."; 745 } 746 enum unknown { 747 value 4; 748 description 749 "Status cannot be determined for some reason."; 750 } 751 enum dormant { 752 value 5; 753 description 754 "Waiting for some external event."; 755 } 756 enum not-present { 757 value 6; 758 description 759 "Some component (typically hardware) is missing."; 760 } 761 enum lower-layer-down { 762 value 7; 763 description 764 "Down due to state of lower-layer interface(s)."; 765 } 766 } 767 config false; 768 mandatory true; 769 description 770 "The current operational state of the interface. 772 This leaf has the same semantics as ifOperStatus."; 773 reference 774 "RFC 2863: The Interfaces Group MIB - ifOperStatus"; 775 } 777 leaf last-change { 778 type yang:date-and-time; 779 config false; 780 description 781 "The time the interface entered its current operational 782 state. If the current state was entered prior to the 783 last re-initialization of the local network management 784 subsystem, then this node is not present."; 785 reference 786 "RFC 2863: The Interfaces Group MIB - ifLastChange"; 787 } 789 leaf if-index { 790 if-feature if-mib; 791 type int32 { 792 range "1..2147483647"; 793 } 794 config false; 795 mandatory true; 796 description 797 "The ifIndex value for the ifEntry represented by this 798 interface."; 799 reference 800 "RFC 2863: The Interfaces Group MIB - ifIndex"; 801 } 803 leaf phys-address { 804 type yang:phys-address; 805 config false; 806 description 807 "The interface's address at its protocol sub-layer. For 808 example, for an 802.x interface, this object normally 809 contains a Media Access Control (MAC) address. The 810 interface's media-specific modules must define the bit 811 and byte ordering and the format of the value of this 812 object. For interfaces that do not have such an address 813 (e.g., a serial line), this node is not present."; 814 reference 815 "RFC 2863: The Interfaces Group MIB - ifPhysAddress"; 816 } 818 leaf-list higher-layer-if { 819 type interface-ref; 820 config false; 821 description 822 "A list of references to interfaces layered on top of this 823 interface."; 824 reference 825 "RFC 2863: The Interfaces Group MIB - ifStackTable"; 826 } 828 leaf-list lower-layer-if { 829 type interface-ref; 830 config false; 831 description 832 "A list of references to interfaces layered underneath this 833 interface."; 834 reference 835 "RFC 2863: The Interfaces Group MIB - ifStackTable"; 836 } 838 leaf speed { 839 type yang:gauge64; 840 units "bits/second"; 841 config false; 842 description 843 "An estimate of the interface's current bandwidth in bits 844 per second. For interfaces that do not vary in 845 bandwidth or for those where no accurate estimation can 846 be made, this node should contain the nominal bandwidth. 847 For interfaces that have no concept of bandwidth, this 848 node is not present."; 849 reference 850 "RFC 2863: The Interfaces Group MIB - 851 ifSpeed, ifHighSpeed"; 852 } 854 container statistics { 855 config false; 856 description 857 "A collection of interface-related statistics objects."; 859 leaf discontinuity-time { 860 type yang:date-and-time; 861 mandatory true; 862 description 863 "The time on the most recent occasion at which any one or 864 more of this interface's counters suffered a 865 discontinuity. If no such discontinuities have occurred 866 since the last re-initialization of the local management 867 subsystem, then this node contains the time the local 868 management subsystem re-initialized itself."; 869 } 871 leaf in-octets { 872 type yang:counter64; 873 description 874 "The total number of octets received on the interface, 875 including framing characters. 877 Discontinuities in the value of this counter can occur 878 at re-initialization of the management system, and at 879 other times as indicated by the value of 880 'discontinuity-time'."; 881 reference 882 "RFC 2863: The Interfaces Group MIB - ifHCInOctets"; 883 } 885 leaf in-unicast-pkts { 886 type yang:counter64; 887 description 888 "The number of packets, delivered by this sub-layer to a 889 higher (sub-)layer, that were not addressed to a 890 multicast or broadcast address at this sub-layer. 892 Discontinuities in the value of this counter can occur 893 at re-initialization of the management system, and at 894 other times as indicated by the value of 895 'discontinuity-time'."; 896 reference 897 "RFC 2863: The Interfaces Group MIB - ifHCInUcastPkts"; 898 } 900 leaf in-broadcast-pkts { 901 type yang:counter64; 902 description 903 "The number of packets, delivered by this sub-layer to a 904 higher (sub-)layer, that were addressed to a broadcast 905 address at this sub-layer. 907 Discontinuities in the value of this counter can occur 908 at re-initialization of the management system, and at 909 other times as indicated by the value of 910 'discontinuity-time'."; 911 reference 912 "RFC 2863: The Interfaces Group MIB - 913 ifHCInBroadcastPkts"; 914 } 916 leaf in-multicast-pkts { 917 type yang:counter64; 918 description 919 "The number of packets, delivered by this sub-layer to a 920 higher (sub-)layer, that were addressed to a multicast 921 address at this sub-layer. For a MAC-layer protocol, 922 this includes both Group and Functional addresses. 924 Discontinuities in the value of this counter can occur 925 at re-initialization of the management system, and at 926 other times as indicated by the value of 927 'discontinuity-time'."; 928 reference 929 "RFC 2863: The Interfaces Group MIB - 930 ifHCInMulticastPkts"; 931 } 933 leaf in-discards { 934 type yang:counter32; 935 description 936 "The number of inbound packets that were chosen to be 937 discarded even though no errors had been detected to 938 prevent their being deliverable to a higher-layer 939 protocol. One possible reason for discarding such a 940 packet could be to free up buffer space. 942 Discontinuities in the value of this counter can occur 943 at re-initialization of the management system, and at 944 other times as indicated by the value of 945 'discontinuity-time'."; 946 reference 947 "RFC 2863: The Interfaces Group MIB - ifInDiscards"; 948 } 950 leaf in-errors { 951 type yang:counter32; 952 description 953 "For packet-oriented interfaces, the number of inbound 954 packets that contained errors preventing them from being 955 deliverable to a higher-layer protocol. For character- 956 oriented or fixed-length interfaces, the number of 957 inbound transmission units that contained errors 958 preventing them from being deliverable to a higher-layer 959 protocol. 961 Discontinuities in the value of this counter can occur 962 at re-initialization of the management system, and at 963 other times as indicated by the value of 964 'discontinuity-time'."; 965 reference 966 "RFC 2863: The Interfaces Group MIB - ifInErrors"; 967 } 969 leaf in-unknown-protos { 970 type yang:counter32; 971 description 972 "For packet-oriented interfaces, the number of packets 973 received via the interface that were discarded because 974 of an unknown or unsupported protocol. For 975 character-oriented or fixed-length interfaces that 976 support protocol multiplexing, the number of 977 transmission units received via the interface that were 978 discarded because of an unknown or unsupported protocol. 979 For any interface that does not support protocol 980 multiplexing, this counter is not present. 982 Discontinuities in the value of this counter can occur 983 at re-initialization of the management system, and at 984 other times as indicated by the value of 985 'discontinuity-time'."; 986 reference 987 "RFC 2863: The Interfaces Group MIB - ifInUnknownProtos"; 988 } 990 leaf out-octets { 991 type yang:counter64; 992 description 993 "The total number of octets transmitted out of the 994 interface, including framing characters. 996 Discontinuities in the value of this counter can occur 997 at re-initialization of the management system, and at 998 other times as indicated by the value of 999 'discontinuity-time'."; 1000 reference 1001 "RFC 2863: The Interfaces Group MIB - ifHCOutOctets"; 1002 } 1004 leaf out-unicast-pkts { 1005 type yang:counter64; 1006 description 1007 "The total number of packets that higher-level protocols 1008 requested be transmitted, and that were not addressed 1009 to a multicast or broadcast address at this sub-layer, 1010 including those that were discarded or not sent. 1012 Discontinuities in the value of this counter can occur 1013 at re-initialization of the management system, and at 1014 other times as indicated by the value of 1015 'discontinuity-time'."; 1016 reference 1017 "RFC 2863: The Interfaces Group MIB - ifHCOutUcastPkts"; 1018 } 1020 leaf out-broadcast-pkts { 1021 type yang:counter64; 1022 description 1023 "The total number of packets that higher-level protocols 1024 requested be transmitted, and that were addressed to a 1025 broadcast address at this sub-layer, including those 1026 that were discarded or not sent. 1028 Discontinuities in the value of this counter can occur 1029 at re-initialization of the management system, and at 1030 other times as indicated by the value of 1031 'discontinuity-time'."; 1032 reference 1033 "RFC 2863: The Interfaces Group MIB - 1034 ifHCOutBroadcastPkts"; 1035 } 1037 leaf out-multicast-pkts { 1038 type yang:counter64; 1039 description 1040 "The total number of packets that higher-level protocols 1041 requested be transmitted, and that were addressed to a 1042 multicast address at this sub-layer, including those 1043 that were discarded or not sent. For a MAC-layer 1044 protocol, this includes both Group and Functional 1045 addresses. 1047 Discontinuities in the value of this counter can occur 1048 at re-initialization of the management system, and at 1049 other times as indicated by the value of 1050 'discontinuity-time'."; 1051 reference 1052 "RFC 2863: The Interfaces Group MIB - 1053 ifHCOutMulticastPkts"; 1054 } 1056 leaf out-discards { 1057 type yang:counter32; 1058 description 1059 "The number of outbound packets that were chosen to be 1060 discarded even though no errors had been detected to 1061 prevent their being transmitted. One possible reason 1062 for discarding such a packet could be to free up buffer 1063 space. 1065 Discontinuities in the value of this counter can occur 1066 at re-initialization of the management system, and at 1067 other times as indicated by the value of 1068 'discontinuity-time'."; 1069 reference 1070 "RFC 2863: The Interfaces Group MIB - ifOutDiscards"; 1071 } 1073 leaf out-errors { 1074 type yang:counter32; 1075 description 1076 "For packet-oriented interfaces, the number of outbound 1077 packets that could not be transmitted because of errors. 1079 For character-oriented or fixed-length interfaces, the 1080 number of outbound transmission units that could not be 1081 transmitted because of errors. 1083 Discontinuities in the value of this counter can occur 1084 at re-initialization of the management system, and at 1085 other times as indicated by the value of 1086 'discontinuity-time'."; 1087 reference 1088 "RFC 2863: The Interfaces Group MIB - ifOutErrors"; 1089 } 1090 } 1092 } 1093 } 1095 /* 1096 * Legacy typedefs 1097 */ 1099 typedef interface-state-ref { 1100 type leafref { 1101 path "/if:interfaces-state/if:interface/if:name"; 1102 } 1103 status deprecated; 1104 description 1105 "This type is used by data models that need to reference 1106 the operationally present interfaces."; 1107 } 1109 /* 1110 * Legacy operational state data nodes 1111 */ 1113 container interfaces-state { 1114 config false; 1115 status deprecated; 1116 description 1117 "Data nodes for the operational state of interfaces."; 1119 list interface { 1120 key "name"; 1121 status deprecated; 1123 description 1124 "The list of interfaces on the device. 1126 System-controlled interfaces created by the system are 1127 always present in this list, whether they are configured or 1128 not."; 1130 leaf name { 1131 type string; 1132 status deprecated; 1133 description 1134 "The name of the interface. 1136 A server implementation MAY map this leaf to the ifName 1137 MIB object. Such an implementation needs to use some 1138 mechanism to handle the differences in size and characters 1139 allowed between this leaf and ifName. The definition of 1140 such a mechanism is outside the scope of this document."; 1141 reference 1142 "RFC 2863: The Interfaces Group MIB - ifName"; 1143 } 1145 leaf type { 1146 type identityref { 1147 base interface-type; 1148 } 1149 mandatory true; 1150 status deprecated; 1151 description 1152 "The type of the interface."; 1153 reference 1154 "RFC 2863: The Interfaces Group MIB - ifType"; 1155 } 1157 leaf admin-status { 1158 if-feature if-mib; 1159 type enumeration { 1160 enum up { 1161 value 1; 1162 description 1163 "Ready to pass packets."; 1164 } 1165 enum down { 1166 value 2; 1167 description 1168 "Not ready to pass packets and not in some test mode."; 1169 } 1170 enum testing { 1171 value 3; 1172 description 1173 "In some test mode."; 1174 } 1176 } 1177 mandatory true; 1178 status deprecated; 1179 description 1180 "The desired state of the interface. 1182 This leaf has the same read semantics as ifAdminStatus."; 1183 reference 1184 "RFC 2863: The Interfaces Group MIB - ifAdminStatus"; 1185 } 1187 leaf oper-status { 1188 type enumeration { 1189 enum up { 1190 value 1; 1191 description 1192 "Ready to pass packets."; 1193 } 1194 enum down { 1195 value 2; 1196 description 1197 "The interface does not pass any packets."; 1198 } 1199 enum testing { 1200 value 3; 1201 description 1202 "In some test mode. No operational packets can 1203 be passed."; 1204 } 1205 enum unknown { 1206 value 4; 1207 description 1208 "Status cannot be determined for some reason."; 1209 } 1210 enum dormant { 1211 value 5; 1212 description 1213 "Waiting for some external event."; 1214 } 1215 enum not-present { 1216 value 6; 1217 description 1218 "Some component (typically hardware) is missing."; 1219 } 1220 enum lower-layer-down { 1221 value 7; 1222 description 1223 "Down due to state of lower-layer interface(s)."; 1225 } 1226 } 1227 mandatory true; 1228 status deprecated; 1229 description 1230 "The current operational state of the interface. 1232 This leaf has the same semantics as ifOperStatus."; 1233 reference 1234 "RFC 2863: The Interfaces Group MIB - ifOperStatus"; 1235 } 1237 leaf last-change { 1238 type yang:date-and-time; 1239 status deprecated; 1240 description 1241 "The time the interface entered its current operational 1242 state. If the current state was entered prior to the 1243 last re-initialization of the local network management 1244 subsystem, then this node is not present."; 1245 reference 1246 "RFC 2863: The Interfaces Group MIB - ifLastChange"; 1247 } 1249 leaf if-index { 1250 if-feature if-mib; 1251 type int32 { 1252 range "1..2147483647"; 1253 } 1254 mandatory true; 1255 status deprecated; 1256 description 1257 "The ifIndex value for the ifEntry represented by this 1258 interface."; 1259 reference 1260 "RFC 2863: The Interfaces Group MIB - ifIndex"; 1261 } 1263 leaf phys-address { 1264 type yang:phys-address; 1265 status deprecated; 1266 description 1267 "The interface's address at its protocol sub-layer. For 1268 example, for an 802.x interface, this object normally 1269 contains a Media Access Control (MAC) address. The 1270 interface's media-specific modules must define the bit 1271 and byte ordering and the format of the value of this 1272 object. For interfaces that do not have such an address 1273 (e.g., a serial line), this node is not present."; 1274 reference 1275 "RFC 2863: The Interfaces Group MIB - ifPhysAddress"; 1276 } 1278 leaf-list higher-layer-if { 1279 type interface-state-ref; 1280 status deprecated; 1281 description 1282 "A list of references to interfaces layered on top of this 1283 interface."; 1284 reference 1285 "RFC 2863: The Interfaces Group MIB - ifStackTable"; 1286 } 1288 leaf-list lower-layer-if { 1289 type interface-state-ref; 1290 status deprecated; 1291 description 1292 "A list of references to interfaces layered underneath this 1293 interface."; 1294 reference 1295 "RFC 2863: The Interfaces Group MIB - ifStackTable"; 1296 } 1298 leaf speed { 1299 type yang:gauge64; 1300 units "bits/second"; 1301 status deprecated; 1302 description 1303 "An estimate of the interface's current bandwidth in bits 1304 per second. For interfaces that do not vary in 1305 bandwidth or for those where no accurate estimation can 1306 be made, this node should contain the nominal bandwidth. 1307 For interfaces that have no concept of bandwidth, this 1308 node is not present."; 1309 reference 1310 "RFC 2863: The Interfaces Group MIB - 1311 ifSpeed, ifHighSpeed"; 1312 } 1314 container statistics { 1315 status deprecated; 1316 description 1317 "A collection of interface-related statistics objects."; 1319 leaf discontinuity-time { 1320 type yang:date-and-time; 1321 mandatory true; 1322 status deprecated; 1323 description 1324 "The time on the most recent occasion at which any one or 1325 more of this interface's counters suffered a 1326 discontinuity. If no such discontinuities have occurred 1327 since the last re-initialization of the local management 1328 subsystem, then this node contains the time the local 1329 management subsystem re-initialized itself."; 1330 } 1332 leaf in-octets { 1333 type yang:counter64; 1334 status deprecated; 1335 description 1336 "The total number of octets received on the interface, 1337 including framing characters. 1339 Discontinuities in the value of this counter can occur 1340 at re-initialization of the management system, and at 1341 other times as indicated by the value of 1342 'discontinuity-time'."; 1343 reference 1344 "RFC 2863: The Interfaces Group MIB - ifHCInOctets"; 1345 } 1347 leaf in-unicast-pkts { 1348 type yang:counter64; 1349 status deprecated; 1350 description 1351 "The number of packets, delivered by this sub-layer to a 1352 higher (sub-)layer, that were not addressed to a 1353 multicast or broadcast address at this sub-layer. 1355 Discontinuities in the value of this counter can occur 1356 at re-initialization of the management system, and at 1357 other times as indicated by the value of 1358 'discontinuity-time'."; 1359 reference 1360 "RFC 2863: The Interfaces Group MIB - ifHCInUcastPkts"; 1361 } 1363 leaf in-broadcast-pkts { 1364 type yang:counter64; 1365 status deprecated; 1366 description 1367 "The number of packets, delivered by this sub-layer to a 1368 higher (sub-)layer, that were addressed to a broadcast 1369 address at this sub-layer. 1371 Discontinuities in the value of this counter can occur 1372 at re-initialization of the management system, and at 1373 other times as indicated by the value of 1374 'discontinuity-time'."; 1375 reference 1376 "RFC 2863: The Interfaces Group MIB - 1377 ifHCInBroadcastPkts"; 1378 } 1380 leaf in-multicast-pkts { 1381 type yang:counter64; 1382 status deprecated; 1383 description 1384 "The number of packets, delivered by this sub-layer to a 1385 higher (sub-)layer, that were addressed to a multicast 1386 address at this sub-layer. For a MAC-layer protocol, 1387 this includes both Group and Functional addresses. 1389 Discontinuities in the value of this counter can occur 1390 at re-initialization of the management system, and at 1391 other times as indicated by the value of 1392 'discontinuity-time'."; 1393 reference 1394 "RFC 2863: The Interfaces Group MIB - 1395 ifHCInMulticastPkts"; 1396 } 1398 leaf in-discards { 1399 type yang:counter32; 1400 status deprecated; 1401 description 1402 "The number of inbound packets that were chosen to be 1403 discarded even though no errors had been detected to 1404 prevent their being deliverable to a higher-layer 1405 protocol. One possible reason for discarding such a 1406 packet could be to free up buffer space. 1408 Discontinuities in the value of this counter can occur 1409 at re-initialization of the management system, and at 1410 other times as indicated by the value of 1411 'discontinuity-time'."; 1412 reference 1413 "RFC 2863: The Interfaces Group MIB - ifInDiscards"; 1414 } 1416 leaf in-errors { 1417 type yang:counter32; 1418 status deprecated; 1419 description 1420 "For packet-oriented interfaces, the number of inbound 1421 packets that contained errors preventing them from being 1422 deliverable to a higher-layer protocol. For character- 1423 oriented or fixed-length interfaces, the number of 1424 inbound transmission units that contained errors 1425 preventing them from being deliverable to a higher-layer 1426 protocol. 1428 Discontinuities in the value of this counter can occur 1429 at re-initialization of the management system, and at 1430 other times as indicated by the value of 1431 'discontinuity-time'."; 1432 reference 1433 "RFC 2863: The Interfaces Group MIB - ifInErrors"; 1434 } 1436 leaf in-unknown-protos { 1437 type yang:counter32; 1438 status deprecated; 1439 description 1440 "For packet-oriented interfaces, the number of packets 1441 received via the interface that were discarded because 1442 of an unknown or unsupported protocol. For 1443 character-oriented or fixed-length interfaces that 1444 support protocol multiplexing, the number of 1445 transmission units received via the interface that were 1446 discarded because of an unknown or unsupported protocol. 1447 For any interface that does not support protocol 1448 multiplexing, this counter is not present. 1450 Discontinuities in the value of this counter can occur 1451 at re-initialization of the management system, and at 1452 other times as indicated by the value of 1453 'discontinuity-time'."; 1454 reference 1455 "RFC 2863: The Interfaces Group MIB - ifInUnknownProtos"; 1456 } 1458 leaf out-octets { 1459 type yang:counter64; 1460 status deprecated; 1461 description 1462 "The total number of octets transmitted out of the 1463 interface, including framing characters. 1465 Discontinuities in the value of this counter can occur 1466 at re-initialization of the management system, and at 1467 other times as indicated by the value of 1468 'discontinuity-time'."; 1469 reference 1470 "RFC 2863: The Interfaces Group MIB - ifHCOutOctets"; 1471 } 1473 leaf out-unicast-pkts { 1474 type yang:counter64; 1475 status deprecated; 1476 description 1477 "The total number of packets that higher-level protocols 1478 requested be transmitted, and that were not addressed 1479 to a multicast or broadcast address at this sub-layer, 1480 including those that were discarded or not sent. 1482 Discontinuities in the value of this counter can occur 1483 at re-initialization of the management system, and at 1484 other times as indicated by the value of 1485 'discontinuity-time'."; 1486 reference 1487 "RFC 2863: The Interfaces Group MIB - ifHCOutUcastPkts"; 1488 } 1490 leaf out-broadcast-pkts { 1491 type yang:counter64; 1492 status deprecated; 1493 description 1494 "The total number of packets that higher-level protocols 1495 requested be transmitted, and that were addressed to a 1496 broadcast address at this sub-layer, including those 1497 that were discarded or not sent. 1499 Discontinuities in the value of this counter can occur 1500 at re-initialization of the management system, and at 1501 other times as indicated by the value of 1502 'discontinuity-time'."; 1503 reference 1504 "RFC 2863: The Interfaces Group MIB - 1505 ifHCOutBroadcastPkts"; 1506 } 1508 leaf out-multicast-pkts { 1509 type yang:counter64; 1510 status deprecated; 1511 description 1512 "The total number of packets that higher-level protocols 1513 requested be transmitted, and that were addressed to a 1514 multicast address at this sub-layer, including those 1515 that were discarded or not sent. For a MAC-layer 1516 protocol, this includes both Group and Functional 1517 addresses. 1519 Discontinuities in the value of this counter can occur 1520 at re-initialization of the management system, and at 1521 other times as indicated by the value of 1522 'discontinuity-time'."; 1523 reference 1524 "RFC 2863: The Interfaces Group MIB - 1525 ifHCOutMulticastPkts"; 1526 } 1528 leaf out-discards { 1529 type yang:counter32; 1530 status deprecated; 1531 description 1532 "The number of outbound packets that were chosen to be 1533 discarded even though no errors had been detected to 1534 prevent their being transmitted. One possible reason 1535 for discarding such a packet could be to free up buffer 1536 space. 1538 Discontinuities in the value of this counter can occur 1539 at re-initialization of the management system, and at 1540 other times as indicated by the value of 1541 'discontinuity-time'."; 1542 reference 1543 "RFC 2863: The Interfaces Group MIB - ifOutDiscards"; 1544 } 1546 leaf out-errors { 1547 type yang:counter32; 1548 status deprecated; 1549 description 1550 "For packet-oriented interfaces, the number of outbound 1551 packets that could not be transmitted because of errors. 1552 For character-oriented or fixed-length interfaces, the 1553 number of outbound transmission units that could not be 1554 transmitted because of errors. 1556 Discontinuities in the value of this counter can occur 1557 at re-initialization of the management system, and at 1558 other times as indicated by the value of 1559 'discontinuity-time'."; 1560 reference 1561 "RFC 2863: The Interfaces Group MIB - ifOutErrors"; 1562 } 1563 } 1564 } 1565 } 1566 } 1568 1570 6. IANA Considerations 1572 This document registers a URI in the "IETF XML Registry" [RFC3688]. 1573 Following the format in RFC 3688, the following registration has been 1574 made. 1576 URI: urn:ietf:params:xml:ns:yang:ietf-interfaces 1578 Registrant Contact: The IESG. 1580 XML: N/A, the requested URI is an XML namespace. 1582 This document registers a YANG module in the "YANG Module Names" 1583 registry [RFC6020]. 1585 name: ietf-interfaces 1586 namespace: urn:ietf:params:xml:ns:yang:ietf-interfaces 1587 prefix: if 1588 reference: RFC XXXX 1590 7. Security Considerations 1592 The YANG module specified in this document defines a schema for data 1593 that is designed to be accessed via network management protocols such 1594 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 1595 is the secure transport layer, and the mandatory-to-implement secure 1596 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 1597 is HTTPS, and the mandatory-to-implement secure transport is TLS 1598 [RFC5246]. 1600 The NETCONF access control model [RFC6536] provides the means to 1601 restrict access for particular NETCONF or RESTCONF users to a 1602 preconfigured subset of all available NETCONF or RESTCONF protocol 1603 operations and content. 1605 There are a number of data nodes defined in the YANG module which are 1606 writable/creatable/deletable (i.e., config true, which is the 1607 default). These data nodes may be considered sensitive or vulnerable 1608 in some network environments. Write operations (e.g., ) 1609 to these data nodes without proper protection can have a negative 1610 effect on network operations. These are the subtrees and data nodes 1611 and their sensitivity/vulnerability: 1613 /interfaces/interface: This list specifies the configured interfaces 1614 on a device. Unauthorized access to this list could cause the 1615 device to ignore packets it should receive and process. 1617 /interfaces/interface/enabled: This leaf controls whether an 1618 interface is enabled or not. Unauthorized access to this leaf 1619 could cause the device to ignore packets it should receive and 1620 process. 1622 8. Acknowledgments 1624 The author wishes to thank Alexander Clemm, Per Hedeland, Ladislav 1625 Lhotka, and Juergen Schoenwaelder for their helpful comments. 1627 9. References 1629 9.1. Normative References 1631 [I-D.ietf-netmod-revised-datastores] 1632 Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1633 and R. Wilton, "Network Management Datastore 1634 Architecture", draft-ietf-netmod-revised-datastores-07 1635 (work in progress), November 2017. 1637 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1638 Requirement Levels", BCP 14, RFC 2119, 1639 DOI 10.17487/RFC2119, March 1997, . 1642 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 1643 MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, 1644 . 1646 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1647 DOI 10.17487/RFC3688, January 2004, . 1650 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1651 (TLS) Protocol Version 1.2", RFC 5246, 1652 DOI 10.17487/RFC5246, August 2008, . 1655 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1656 the Network Configuration Protocol (NETCONF)", RFC 6020, 1657 DOI 10.17487/RFC6020, October 2010, . 1660 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1661 and A. Bierman, Ed., "Network Configuration Protocol 1662 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1663 . 1665 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1666 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1667 . 1669 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1670 Protocol (NETCONF) Access Control Model", RFC 6536, 1671 DOI 10.17487/RFC6536, March 2012, . 1674 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1675 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1676 . 1678 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1679 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1680 . 1682 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1683 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1684 . 1686 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1687 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1688 May 2017, . 1690 9.2. Informative References 1692 [I-D.ietf-netmod-yang-tree-diagrams] 1693 Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft- 1694 ietf-netmod-yang-tree-diagrams-02 (work in progress), 1695 October 2017. 1697 [RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", 1698 RFC 7224, DOI 10.17487/RFC7224, May 2014, 1699 . 1701 Appendix A. Example: Ethernet Interface Module 1703 This section gives a simple example of how an Ethernet interface 1704 module could be defined. It demonstrates how media-specific 1705 configuration parameters can be conditionally augmented to the 1706 generic interface list. It also shows how operational state 1707 parameters can be conditionally augmented to the operational 1708 interface list. The example is not intended as a complete module for 1709 Ethernet configuration. 1711 module example-ethernet { 1712 namespace "http://example.com/ethernet"; 1713 prefix "eth"; 1715 import ietf-interfaces { 1716 prefix if; 1717 } 1718 import iana-if-type { 1719 prefix ianaift; 1720 } 1722 // configuration and state parameters for Ethernet interfaces 1723 augment "/if:interfaces/if:interface" { 1724 when "if:type = 'ianaift:ethernetCsmacd'"; 1726 container ethernet { 1727 container transmission { 1728 choice transmission-params { 1729 case auto { 1730 leaf auto-negotiate { 1731 type empty; 1732 } 1733 } 1734 case manual { 1735 container manual { 1736 leaf duplex { 1737 type enumeration { 1738 enum "half"; 1739 enum "full"; 1740 } 1741 } 1742 leaf speed { 1743 type enumeration { 1744 enum "10Mb"; 1745 enum "100Mb"; 1746 enum "1Gb"; 1747 enum "10Gb"; 1748 } 1750 } 1751 } 1752 } 1753 } 1754 leaf duplex { 1755 type enumeration { 1756 enum "half"; 1757 enum "full"; 1758 } 1759 config false; 1760 } 1761 } 1762 // other Ethernet-specific params... 1763 } 1764 } 1765 } 1767 Appendix B. Example: Ethernet Bonding Interface Module 1769 This section gives an example of how interface layering can be 1770 defined. An Ethernet bonding interface that bonds several Ethernet 1771 interfaces into one logical interface is defined. 1773 module example-ethernet-bonding { 1774 namespace "http://example.com/ethernet-bonding"; 1775 prefix "bond"; 1777 import ietf-interfaces { 1778 prefix if; 1779 } 1780 import iana-if-type { 1781 prefix ianaift; 1782 } 1784 augment "/if:interfaces/if:interface" { 1785 when "if:type = 'ianaift:ieee8023adLag'"; 1787 leaf-list slave-if { 1788 type if:interface-ref; 1789 must "/if:interfaces/if:interface[if:name = current()]" 1790 + "/if:type = 'ianaift:ethernetCsmacd'" { 1791 description 1792 "The type of a slave interface must be 'ethernetCsmacd'."; 1793 } 1794 } 1795 leaf bonding-mode { 1796 type enumeration { 1797 enum round-robin; 1798 enum active-backup; 1799 enum broadcast; 1800 } 1801 } 1802 // other bonding config params, failover times, etc. 1803 } 1804 } 1806 Appendix C. Example: VLAN Interface Module 1808 This section gives an example of how a VLAN interface module can be 1809 defined. 1811 module example-vlan { 1812 namespace "http://example.com/vlan"; 1813 prefix "vlan"; 1815 import ietf-interfaces { 1816 prefix if; 1817 } 1818 import iana-if-type { 1819 prefix ianaift; 1820 } 1822 augment "/if:interfaces/if:interface" { 1823 when "if:type = 'ianaift:ethernetCsmacd' or 1824 if:type = 'ianaift:ieee8023adLag'"; 1825 leaf vlan-tagging { 1826 type boolean; 1827 default false; 1828 } 1829 } 1831 augment "/if:interfaces/if:interface" { 1832 when "if:type = 'ianaift:l2vlan'"; 1834 leaf base-interface { 1835 type if:interface-ref; 1836 must "/if:interfaces/if:interface[if:name = current()]" 1837 + "/vlan:vlan-tagging = 'true'" { 1838 description 1839 "The base interface must have VLAN tagging enabled."; 1840 } 1841 } 1842 leaf vlan-id { 1843 type uint16 { 1844 range "1..4094"; 1845 } 1846 must "../base-interface" { 1847 description 1848 "If a vlan-id is defined, a base-interface must 1849 be specified."; 1850 } 1851 } 1852 } 1853 } 1855 Appendix D. Example: NETCONF Reply 1857 This section gives an example of a reply to the NETCONF 1858 request for for a device that implements the example data 1859 models above. 1861 1864 1865 1870 1871 eth0 1872 ianaift:ethernetCsmacd 1873 false 1874 1876 1877 eth1 1878 ianaift:ethernetCsmacd 1879 true 1880 true 1881 1883 1884 eth1.10 1885 ianaift:l2vlan 1886 true 1887 eth1 1888 10 1889 1891 1892 lo1 1893 ianaift:softwareLoopback 1894 true 1895 1897 1898 1899 1901 Appendix E. Example: NETCONF Reply 1903 This section gives an example of a reply to the NETCONF 1904 request for for a device that implements the example 1905 data models above. 1907 This example uses the "origin" annotation, which is defined in the 1908 module "ietf-origin" [I-D.ietf-netmod-revised-datastores]. 1910 1913 1914 1920 1921 eth0 1922 ianaift:ethernetCsmacd 1923 false 1924 down 1925 down 1926 2 1927 00:01:02:03:04:05 1928 1929 1930 2013-04-01T03:00:00+00:00 1931 1932 1933 1934 1936 1937 eth1 1938 ianaift:ethernetCsmacd 1939 true 1940 up 1941 up 1942 7 1943 00:01:02:03:04:06 1944 eth1.10 1945 1946 1947 2013-04-01T03:00:00+00:00 1948 1949 1950 1951 true 1952 1954 1955 eth1.10 1956 ianaift:l2vlan 1957 true 1958 up 1959 up 1960 9 1961 eth1 1962 1963 1964 2013-04-01T03:00:00+00:00 1965 1966 1967 1968 eth1 1969 10 1970 1972 1973 1974 eth2 1975 ianaift:ethernetCsmacd 1976 down 1977 down 1978 8 1979 00:01:02:03:04:07 1980 1981 1982 2013-04-01T03:00:00+00:00 1983 1984 1985 1986 1988 1989 lo1 1990 ianaift:softwareLoopback 1991 true 1992 up 1993 up 1994 1 1995 1996 1997 2013-04-01T03:00:00+00:00 1998 1999 2000 2001 2003 2004 2005 2007 Appendix F. Examples: Interface Naming Schemes 2009 This section gives examples of some implementation strategies. 2011 The examples make use of the example data model "example-vlan" (see 2012 Appendix C) to show how user-controlled interfaces can be configured. 2014 F.1. Router with Restricted Interface Names 2016 In this example, a router has support for 4 line cards, each with 8 2017 ports. The slots for the cards are physically numbered from 0 to 3, 2018 and the ports on each card from 0 to 7. Each card has Fast Ethernet 2019 or Gigabit Ethernet ports. 2021 The device-specific names for these physical interfaces are 2022 "fastethernet-N/M" or "gigabitethernet-N/M". 2024 The name of a VLAN interface is restricted to the form 2025 ".". 2027 It is assumed that the operator is aware of this naming scheme. The 2028 implementation auto-initializes the value for "type" based on the 2029 interface name. 2031 The NETCONF server does not advertise the "arbitrary-names" feature 2032 in the message. 2034 An operator can configure a physical interface by sending an 2035 containing: 2037 2038 fastethernet-1/0 2039 2041 When the server processes this request, it will set the leaf "type" 2042 to "ianaift:ethernetCsmacd". Thus, if the client performs a 2043 right after the above, it will get: 2045 2046 fastethernet-1/0 2047 ianaift:ethernetCsmacd 2048 2050 The client can configure a VLAN interface by sending an 2051 containing: 2053 2054 fastethernet-1/0.10005 2055 ianaift:l2vlan 2056 fastethernet-1/0 2057 5 2058 2060 If the client tries to change the type of the physical interface with 2061 an containing: 2063 2064 fastethernet-1/0 2065 ianaift:tunnel 2066 2068 then the server will reply with an "invalid-value" error, since the 2069 new type does not match the name. 2071 F.2. Router with Arbitrary Interface Names 2073 In this example, a router has support for 4 line cards, each with 8 2074 ports. The slots for the cards are physically numbered from 0 to 3, 2075 and the ports on each card from 0 to 7. Each card has Fast Ethernet 2076 or Gigabit Ethernet ports. 2078 The device-specific names for these physical interfaces are 2079 "fastethernet-N/M" or "gigabitethernet-N/M". 2081 The implementation does not restrict the user-controlled interface 2082 names. This allows an operator to more easily apply the interface 2083 configuration to a different interface. However, the additional 2084 level of indirection also makes it a bit more complex to map 2085 interface names found in other protocols to configuration entries. 2087 The NETCONF server advertises the "arbitrary-names" feature in the 2088 message. 2090 Physical interfaces are configured as in Appendix F.1. 2092 An operator can configure a VLAN interface by sending an 2093 containing: 2095 2096 acme-interface 2097 ianaift:l2vlan 2098 fastethernet-1/0 2099 5 2100 2102 If necessary, the operator can move the configuration named 2103 "acme-interface" over to a different physical interface with an 2104 containing: 2106 2107 acme-interface 2108 fastethernet-1/1 2109 2111 F.3. Ethernet Switch with Restricted Interface Names 2113 In this example, an Ethernet switch has a number of ports, each 2114 identified by a simple port number. 2116 The device-specific names for the physical interfaces are numbers 2117 that match the physical port number. 2119 An operator can configure a physical interface by sending an 2120 containing: 2122 2123 6 2124 2126 When the server processes this request, it will set the leaf "type" 2127 to "ianaift:ethernetCsmacd". Thus, if the client performs a 2128 right after the above, it will get: 2130 2131 6 2132 ianaift:ethernetCsmacd 2133 2135 F.4. Generic Host with Restricted Interface Names 2137 In this example, a generic host has interfaces named by the kernel. 2138 The system identifies the physical interface by the name assigned by 2139 the operating system to the interface. 2141 The name of a VLAN interface is restricted to the form 2142 ":". 2144 The NETCONF server does not advertise the "arbitrary-names" feature 2145 in the message. 2147 An operator can configure an interface by sending an 2148 containing: 2150 2151 eth8 2152 2154 When the server processes this request, it will set the leaf "type" 2155 to "ianaift:ethernetCsmacd". Thus, if the client performs a 2156 right after the above, it will get: 2158 2159 eth8 2160 ianaift:ethernetCsmacd 2161 2163 The client can configure a VLAN interface by sending an 2164 containing: 2166 2167 eth8:5 2168 ianaift:l2vlan 2169 eth8 2170 5 2171 2173 F.5. Generic Host with Arbitrary Interface Names 2175 In this example, a generic host has interfaces named by the kernel. 2176 The system identifies the physical interface by the name assigned by 2177 the operating system to the interface. 2179 The implementation does not restrict the user-controlled interface 2180 names. This allows an operator to more easily apply the interface 2181 configuration to a different interface. However, the additional 2182 level of indirection also makes it a bit more complex to map 2183 interface names found in other protocols to configuration entries. 2185 The NETCONF server advertises the "arbitrary-names" feature in the 2186 message. 2188 Physical interfaces are configured as in Appendix F.4. 2190 An operator can configure a VLAN interface by sending an 2191 containing: 2193 2194 acme-interface 2195 ianaift:l2vlan 2196 eth8 2197 5 2198 2200 If necessary, the operator can move the configuration named 2201 "acme-interface" over to a different physical interface with an 2202 containing: 2204 2205 acme-interface 2206 eth3 2207 2209 Author's Address 2211 Martin Bjorklund 2212 Tail-f Systems 2214 Email: mbj@tail-f.com