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