idnits 2.17.1 draft-ietf-netmod-rfc7223bis-01.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 (December 17, 2017) is 2320 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 == Outdated reference: A later version (-06) exists of draft-ietf-netmod-yang-tree-diagrams-02 -- Obsolete informational reference (is this intentional?): RFC 6536 (Obsoleted by RFC 8341) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 3 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) December 17, 2017 5 Intended status: Standards Track 6 Expires: June 20, 2018 8 A YANG Data Model for Interface Management 9 draft-ietf-netmod-rfc7223bis-01 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 June 20, 2018. 37 Copyright Notice 39 Copyright (c) 2017 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 . . . . . . . . . 36 72 Appendix B. Example: Ethernet Bonding Interface Module . . . . . 38 73 Appendix C. Example: VLAN Interface Module . . . . . . . . . . . 38 74 Appendix D. Example: NETCONF Reply . . . . . . . . 40 75 Appendix E. Example: NETCONF Reply . . . . . . . . . 41 76 Appendix F. Examples: Interface Naming Schemes . . . . . . . . . 43 77 F.1. Router with Restricted Interface Names . . . . . . . . . 43 78 F.2. Router with Arbitrary Interface Names . . . . . . . . . . 44 79 F.3. Ethernet Switch with Restricted Interface Names . . . . . 45 80 F.4. Generic Host with Restricted Interface Names . . . . . . 45 81 F.5. Generic Host with Arbitrary Interface Names . . . . . . . 46 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 47 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" and 315 typedef, which other YANG modules SHOULD use when they need to 316 reference an 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 NETCONF and SNMP may 390 differ in the time granularity in which they provide access to the 391 counters. For example, it is common that SNMP implementations cache 392 counter values for some time. 394 The objects ifDescr and ifConnectorPresent from the IF-MIB are not 395 mapped to the "ietf-interfaces" module. 397 The following tables list the YANG data nodes with corresponding 398 objects in the IF-MIB. 400 +--------------------------------------+----------------------------+ 401 | YANG data node in | IF-MIB object | 402 | /interfaces/interface | | 403 +--------------------------------------+----------------------------+ 404 | name | ifName | 405 | type | ifType | 406 | description | ifAlias | 407 | admin-status | ifAdminStatus | 408 | oper-status | ifOperStatus | 409 | last-change | ifLastChange | 410 | if-index | ifIndex | 411 | link-up-down-trap-enable | ifLinkUpDownTrapEnable | 412 | phys-address | ifPhysAddress | 413 | higher-layer-if and lower-layer-if | ifStackTable | 414 | speed | ifSpeed and ifHighSpeed | 415 | discontinuity-time | ifCounterDiscontinuityTime | 416 | in-octets | ifHCInOctets | 417 | in-unicast-pkts | ifHCInUcastPkts | 418 | in-broadcast-pkts | ifHCInBroadcastPkts | 419 | in-multicast-pkts | ifHCInMulticastPkts | 420 | in-discards | ifInDiscards | 421 | in-errors | ifInErrors | 422 | in-unknown-protos | ifInUnknownProtos | 423 | out-octets | ifHCOutOctets | 424 | out-unicast-pkts | ifHCOutUcastPkts | 425 | out-broadcast-pkts | ifHCOutBroadcastPkts | 426 | out-multicast-pkts | ifHCOutMulticastPkts | 427 | out-discards | ifOutDiscards | 428 | out-errors | ifOutErrors | 429 +--------------------------------------+----------------------------+ 431 YANG Data Nodes and Related IF-MIB Objects 433 5. Interfaces YANG Module 435 This YANG module imports typedefs from [RFC6991]. 437 file "ietf-interfaces@2017-12-16.yang" 439 module ietf-interfaces { 440 yang-version 1.1; 441 namespace "urn:ietf:params:xml:ns:yang:ietf-interfaces"; 442 prefix if; 444 import ietf-yang-types { 445 prefix yang; 446 } 447 organization 448 "IETF NETMOD (Network Modeling) Working Group"; 450 contact 451 "WG Web: 452 WG List: 454 Editor: Martin Bjorklund 455 "; 457 description 458 "This module contains a collection of YANG definitions for 459 managing network interfaces. 461 Copyright (c) 2017 IETF Trust and the persons identified as 462 authors of the code. All rights reserved. 464 Redistribution and use in source and binary forms, with or 465 without modification, is permitted pursuant to, and subject 466 to the license terms contained in, the Simplified BSD License 467 set forth in Section 4.c of the IETF Trust's Legal Provisions 468 Relating to IETF Documents 469 (http://trustee.ietf.org/license-info). 471 This version of this YANG module is part of RFC XXXX; see 472 the RFC itself for full legal notices."; 474 revision 2017-12-16 { 475 description 476 "Updated to support NMDA."; 477 reference 478 "RFC XXXX: A YANG Data Model for Interface Management"; 479 } 481 revision 2014-05-08 { 482 description 483 "Initial revision."; 484 reference 485 "RFC 7223: A YANG Data Model for Interface Management"; 486 } 488 /* 489 * Typedefs 490 */ 492 typedef interface-ref { 493 type leafref { 494 path "/if:interfaces/if:interface/if:name"; 496 } 497 description 498 "This type is used by data models that need to reference 499 interfaces."; 500 } 502 /* 503 * Identities 504 */ 506 identity interface-type { 507 description 508 "Base identity from which specific interface types are 509 derived."; 510 } 512 /* 513 * Features 514 */ 516 feature arbitrary-names { 517 description 518 "This feature indicates that the device allows user-controlled 519 interfaces to be named arbitrarily."; 520 } 521 feature pre-provisioning { 522 description 523 "This feature indicates that the device supports 524 pre-provisioning of interface configuration, i.e., it is 525 possible to configure an interface whose physical interface 526 hardware is not present on the device."; 527 } 528 feature if-mib { 529 description 530 "This feature indicates that the device implements 531 the IF-MIB."; 532 reference 533 "RFC 2863: The Interfaces Group MIB"; 534 } 536 /* 537 * Data nodes 538 */ 540 container interfaces { 541 description 542 "Interface parameters."; 544 list interface { 545 key "name"; 547 description 548 "The list of interfaces on the device. 550 The status of an interface is available in this list in the 551 operational state. If the configuration of a 552 system-controlled interface cannot be used by the system 553 (e.g., the interface hardware present does not match the 554 interface type), then the configuration is not applied to 555 the system-controlled interface shown in the operational 556 state. If the configuration of a user-controlled interface 557 cannot be used by the system, the configured interface is 558 not instantiated in the operational state. 560 System-controlled interfaces created by the system are 561 always present in this list in the operational state, 562 whether they are configured or not."; 564 leaf name { 565 type string; 566 description 567 "The name of the interface. 569 A device MAY restrict the allowed values for this leaf, 570 possibly depending on the type of the interface. 571 For system-controlled interfaces, this leaf is the 572 device-specific name of the interface. 574 If a client tries to create configuration for a 575 system-controlled interface that is not present in the 576 operational state, the server MAY reject the request if 577 the implementation does not support pre-provisioning of 578 interfaces or if the name refers to an interface that can 579 never exist in the system. A NETCONF server MUST reply 580 with an rpc-error with the error-tag 'invalid-value' in 581 this case. 583 If the device supports pre-provisioning of interface 584 configuration, the 'pre-provisioning' feature is 585 advertised. 587 If the device allows arbitrarily named user-controlled 588 interfaces, the 'arbitrary-names' feature is advertised. 590 When a configured user-controlled interface is created by 591 the system, it is instantiated with the same name in the 592 operational state. 594 A server implementation MAY map this leaf to the ifName 595 MIB object. Such an implementation needs to use some 596 mechanism to handle the differences in size and characters 597 allowed between this leaf and ifName. The definition of 598 such a mechanism is outside the scope of this document."; 599 reference 600 "RFC 2863: The Interfaces Group MIB - ifName"; 601 } 603 leaf description { 604 type string; 605 description 606 "A textual description of the interface. 608 A server implementation MAY map this leaf to the ifAlias 609 MIB object. Such an implementation needs to use some 610 mechanism to handle the differences in size and characters 611 allowed between this leaf and ifAlias. The definition of 612 such a mechanism is outside the scope of this document. 614 Since ifAlias is defined to be stored in non-volatile 615 storage, the MIB implementation MUST map ifAlias to the 616 value of 'description' in the persistently stored 617 configuration."; 618 reference 619 "RFC 2863: The Interfaces Group MIB - ifAlias"; 620 } 622 leaf type { 623 type identityref { 624 base interface-type; 625 } 626 mandatory true; 627 description 628 "The type of the interface. 630 When an interface entry is created, a server MAY 631 initialize the type leaf with a valid value, e.g., if it 632 is possible to derive the type from the name of the 633 interface. 635 If a client tries to set the type of an interface to a 636 value that can never be used by the system, e.g., if the 637 type is not supported or if the type does not match the 638 name of the interface, the server MUST reject the request. 639 A NETCONF server MUST reply with an rpc-error with the 640 error-tag 'invalid-value' in this case."; 641 reference 642 "RFC 2863: The Interfaces Group MIB - ifType"; 643 } 645 leaf enabled { 646 type boolean; 647 default "true"; 648 description 649 "This leaf contains the configured, desired state of the 650 interface. 652 Systems that implement the IF-MIB use the value of this 653 leaf in the intended configuration to set 654 IF-MIB.ifAdminStatus to 'up' or 'down' after an ifEntry 655 has been initialized, as described in RFC 2863. 657 Changes in this leaf in the intended configuration are 658 reflected in ifAdminStatus."; 659 reference 660 "RFC 2863: The Interfaces Group MIB - ifAdminStatus"; 661 } 663 leaf link-up-down-trap-enable { 664 if-feature if-mib; 665 type enumeration { 666 enum enabled { 667 value 1; 668 description 669 "The device will generate linkUp/linkDown SNMP 670 notifications for this interface."; 671 } 672 enum disabled { 673 value 2; 674 description 675 "The device will not generate linkUp/linkDown SNMP 676 notifications for this interface."; 677 } 678 } 679 description 680 "Controls whether linkUp/linkDown SNMP notifications 681 should be generated for this interface. 683 If this node is not configured, the value 'enabled' is 684 operationally used by the server for interfaces that do 685 not operate on top of any other interface (i.e., there are 686 no 'lower-layer-if' entries), and 'disabled' otherwise."; 687 reference 688 "RFC 2863: The Interfaces Group MIB - 689 ifLinkUpDownTrapEnable"; 690 } 692 leaf admin-status { 693 if-feature if-mib; 694 type enumeration { 695 enum up { 696 value 1; 697 description 698 "Ready to pass packets."; 699 } 700 enum down { 701 value 2; 702 description 703 "Not ready to pass packets and not in some test mode."; 704 } 705 enum testing { 706 value 3; 707 description 708 "In some test mode."; 709 } 710 } 711 config false; 712 mandatory true; 713 description 714 "The desired state of the interface. 716 This leaf has the same read semantics as ifAdminStatus."; 717 reference 718 "RFC 2863: The Interfaces Group MIB - ifAdminStatus"; 719 } 721 leaf oper-status { 722 type enumeration { 723 enum up { 724 value 1; 725 description 726 "Ready to pass packets."; 727 } 728 enum down { 729 value 2; 730 description 731 "The interface does not pass any packets."; 732 } 733 enum testing { 734 value 3; 735 description 736 "In some test mode. No operational packets can 737 be passed."; 738 } 739 enum unknown { 740 value 4; 741 description 742 "Status cannot be determined for some reason."; 743 } 744 enum dormant { 745 value 5; 746 description 747 "Waiting for some external event."; 748 } 749 enum not-present { 750 value 6; 751 description 752 "Some component (typically hardware) is missing."; 753 } 754 enum lower-layer-down { 755 value 7; 756 description 757 "Down due to state of lower-layer interface(s)."; 758 } 759 } 760 config false; 761 mandatory true; 762 description 763 "The current operational state of the interface. 765 This leaf has the same semantics as ifOperStatus."; 766 reference 767 "RFC 2863: The Interfaces Group MIB - ifOperStatus"; 768 } 770 leaf last-change { 771 type yang:date-and-time; 772 config false; 773 description 774 "The time the interface entered its current operational 775 state. If the current state was entered prior to the 776 last re-initialization of the local network management 777 subsystem, then this node is not present."; 778 reference 779 "RFC 2863: The Interfaces Group MIB - ifLastChange"; 780 } 782 leaf if-index { 783 if-feature if-mib; 784 type int32 { 785 range "1..2147483647"; 786 } 787 config false; 788 mandatory true; 789 description 790 "The ifIndex value for the ifEntry represented by this 791 interface."; 792 reference 793 "RFC 2863: The Interfaces Group MIB - ifIndex"; 794 } 796 leaf phys-address { 797 type yang:phys-address; 798 config false; 799 description 800 "The interface's address at its protocol sub-layer. For 801 example, for an 802.x interface, this object normally 802 contains a Media Access Control (MAC) address. The 803 interface's media-specific modules must define the bit 804 and byte ordering and the format of the value of this 805 object. For interfaces that do not have such an address 806 (e.g., a serial line), this node is not present."; 807 reference 808 "RFC 2863: The Interfaces Group MIB - ifPhysAddress"; 809 } 811 leaf-list higher-layer-if { 812 type interface-ref; 813 config false; 814 description 815 "A list of references to interfaces layered on top of this 816 interface."; 817 reference 818 "RFC 2863: The Interfaces Group MIB - ifStackTable"; 819 } 821 leaf-list lower-layer-if { 822 type interface-ref; 823 config false; 824 description 825 "A list of references to interfaces layered underneath this 826 interface."; 827 reference 828 "RFC 2863: The Interfaces Group MIB - ifStackTable"; 829 } 831 leaf speed { 832 type yang:gauge64; 833 units "bits/second"; 834 config false; 835 description 836 "An estimate of the interface's current bandwidth in bits 837 per second. For interfaces that do not vary in 838 bandwidth or for those where no accurate estimation can 839 be made, this node should contain the nominal bandwidth. 840 For interfaces that have no concept of bandwidth, this 841 node is not present."; 842 reference 843 "RFC 2863: The Interfaces Group MIB - 844 ifSpeed, ifHighSpeed"; 845 } 847 container statistics { 848 config false; 849 description 850 "A collection of interface-related statistics objects."; 852 leaf discontinuity-time { 853 type yang:date-and-time; 854 mandatory true; 855 description 856 "The time on the most recent occasion at which any one or 857 more of this interface's counters suffered a 858 discontinuity. If no such discontinuities have occurred 859 since the last re-initialization of the local management 860 subsystem, then this node contains the time the local 861 management subsystem re-initialized itself."; 862 } 864 leaf in-octets { 865 type yang:counter64; 866 description 867 "The total number of octets received on the interface, 868 including framing characters. 870 Discontinuities in the value of this counter can occur 871 at re-initialization of the management system, and at 872 other times as indicated by the value of 873 'discontinuity-time'."; 874 reference 875 "RFC 2863: The Interfaces Group MIB - ifHCInOctets"; 876 } 878 leaf in-unicast-pkts { 879 type yang:counter64; 880 description 881 "The number of packets, delivered by this sub-layer to a 882 higher (sub-)layer, that were not addressed to a 883 multicast or broadcast address at this sub-layer. 885 Discontinuities in the value of this counter can occur 886 at re-initialization of the management system, and at 887 other times as indicated by the value of 888 'discontinuity-time'."; 889 reference 890 "RFC 2863: The Interfaces Group MIB - ifHCInUcastPkts"; 891 } 893 leaf in-broadcast-pkts { 894 type yang:counter64; 895 description 896 "The number of packets, delivered by this sub-layer to a 897 higher (sub-)layer, that were addressed to a broadcast 898 address at this sub-layer. 900 Discontinuities in the value of this counter can occur 901 at re-initialization of the management system, and at 902 other times as indicated by the value of 903 'discontinuity-time'."; 904 reference 905 "RFC 2863: The Interfaces Group MIB - 906 ifHCInBroadcastPkts"; 907 } 909 leaf in-multicast-pkts { 910 type yang:counter64; 911 description 912 "The number of packets, delivered by this sub-layer to a 913 higher (sub-)layer, that were addressed to a multicast 914 address at this sub-layer. For a MAC-layer protocol, 915 this includes both Group and Functional addresses. 917 Discontinuities in the value of this counter can occur 918 at re-initialization of the management system, and at 919 other times as indicated by the value of 920 'discontinuity-time'."; 921 reference 922 "RFC 2863: The Interfaces Group MIB - 923 ifHCInMulticastPkts"; 924 } 926 leaf in-discards { 927 type yang:counter32; 928 description 929 "The number of inbound packets that were chosen to be 930 discarded even though no errors had been detected to 931 prevent their being deliverable to a higher-layer 932 protocol. One possible reason for discarding such a 933 packet could be to free up buffer space. 935 Discontinuities in the value of this counter can occur 936 at re-initialization of the management system, and at 937 other times as indicated by the value of 938 'discontinuity-time'."; 939 reference 940 "RFC 2863: The Interfaces Group MIB - ifInDiscards"; 941 } 943 leaf in-errors { 944 type yang:counter32; 945 description 946 "For packet-oriented interfaces, the number of inbound 947 packets that contained errors preventing them from being 948 deliverable to a higher-layer protocol. For character- 949 oriented or fixed-length interfaces, the number of 950 inbound transmission units that contained errors 951 preventing them from being deliverable to a higher-layer 952 protocol. 954 Discontinuities in the value of this counter can occur 955 at re-initialization of the management system, and at 956 other times as indicated by the value of 957 'discontinuity-time'."; 958 reference 959 "RFC 2863: The Interfaces Group MIB - ifInErrors"; 960 } 962 leaf in-unknown-protos { 963 type yang:counter32; 964 description 965 "For packet-oriented interfaces, the number of packets 966 received via the interface that were discarded because 967 of an unknown or unsupported protocol. For 968 character-oriented or fixed-length interfaces that 969 support protocol multiplexing, the number of 970 transmission units received via the interface that were 971 discarded because of an unknown or unsupported protocol. 972 For any interface that does not support protocol 973 multiplexing, this counter is not present. 975 Discontinuities in the value of this counter can occur 976 at re-initialization of the management system, and at 977 other times as indicated by the value of 978 'discontinuity-time'."; 979 reference 980 "RFC 2863: The Interfaces Group MIB - ifInUnknownProtos"; 981 } 983 leaf out-octets { 984 type yang:counter64; 985 description 986 "The total number of octets transmitted out of the 987 interface, including framing characters. 989 Discontinuities in the value of this counter can occur 990 at re-initialization of the management system, and at 991 other times as indicated by the value of 992 'discontinuity-time'."; 993 reference 994 "RFC 2863: The Interfaces Group MIB - ifHCOutOctets"; 995 } 997 leaf out-unicast-pkts { 998 type yang:counter64; 999 description 1000 "The total number of packets that higher-level protocols 1001 requested be transmitted, and that were not addressed 1002 to a multicast or broadcast address at this sub-layer, 1003 including those that were discarded or not sent. 1005 Discontinuities in the value of this counter can occur 1006 at re-initialization of the management system, and at 1007 other times as indicated by the value of 1008 'discontinuity-time'."; 1009 reference 1010 "RFC 2863: The Interfaces Group MIB - ifHCOutUcastPkts"; 1011 } 1013 leaf out-broadcast-pkts { 1014 type yang:counter64; 1015 description 1016 "The total number of packets that higher-level protocols 1017 requested be transmitted, and that were addressed to a 1018 broadcast address at this sub-layer, including those 1019 that were discarded or not sent. 1021 Discontinuities in the value of this counter can occur 1022 at re-initialization of the management system, and at 1023 other times as indicated by the value of 1024 'discontinuity-time'."; 1025 reference 1026 "RFC 2863: The Interfaces Group MIB - 1027 ifHCOutBroadcastPkts"; 1028 } 1030 leaf out-multicast-pkts { 1031 type yang:counter64; 1032 description 1033 "The total number of packets that higher-level protocols 1034 requested be transmitted, and that were addressed to a 1035 multicast address at this sub-layer, including those 1036 that were discarded or not sent. For a MAC-layer 1037 protocol, this includes both Group and Functional 1038 addresses. 1040 Discontinuities in the value of this counter can occur 1041 at re-initialization of the management system, and at 1042 other times as indicated by the value of 1043 'discontinuity-time'."; 1044 reference 1045 "RFC 2863: The Interfaces Group MIB - 1046 ifHCOutMulticastPkts"; 1047 } 1049 leaf out-discards { 1050 type yang:counter32; 1051 description 1052 "The number of outbound packets that were chosen to be 1053 discarded even though no errors had been detected to 1054 prevent their being transmitted. One possible reason 1055 for discarding such a packet could be to free up buffer 1056 space. 1058 Discontinuities in the value of this counter can occur 1059 at re-initialization of the management system, and at 1060 other times as indicated by the value of 1061 'discontinuity-time'."; 1062 reference 1063 "RFC 2863: The Interfaces Group MIB - ifOutDiscards"; 1064 } 1066 leaf out-errors { 1067 type yang:counter32; 1068 description 1069 "For packet-oriented interfaces, the number of outbound 1070 packets that could not be transmitted because of errors. 1072 For character-oriented or fixed-length interfaces, the 1073 number of outbound transmission units that could not be 1074 transmitted because of errors. 1076 Discontinuities in the value of this counter can occur 1077 at re-initialization of the management system, and at 1078 other times as indicated by the value of 1079 'discontinuity-time'."; 1080 reference 1081 "RFC 2863: The Interfaces Group MIB - ifOutErrors"; 1082 } 1083 } 1085 } 1086 } 1088 /* 1089 * Legacy typedefs 1090 */ 1092 typedef interface-state-ref { 1093 type leafref { 1094 path "/if:interfaces-state/if:interface/if:name"; 1095 } 1096 status deprecated; 1097 description 1098 "This type is used by data models that need to reference 1099 the operationally present interfaces."; 1100 } 1102 /* 1103 * Legacy operational state data nodes 1104 */ 1106 container interfaces-state { 1107 config false; 1108 status deprecated; 1109 description 1110 "Data nodes for the operational state of interfaces."; 1112 list interface { 1113 key "name"; 1114 status deprecated; 1116 description 1117 "The list of interfaces on the device. 1119 System-controlled interfaces created by the system are 1120 always present in this list, whether they are configured or 1121 not."; 1123 leaf name { 1124 type string; 1125 status deprecated; 1126 description 1127 "The name of the interface. 1129 A server implementation MAY map this leaf to the ifName 1130 MIB object. Such an implementation needs to use some 1131 mechanism to handle the differences in size and characters 1132 allowed between this leaf and ifName. The definition of 1133 such a mechanism is outside the scope of this document."; 1134 reference 1135 "RFC 2863: The Interfaces Group MIB - ifName"; 1136 } 1138 leaf type { 1139 type identityref { 1140 base interface-type; 1141 } 1142 mandatory true; 1143 status deprecated; 1144 description 1145 "The type of the interface."; 1146 reference 1147 "RFC 2863: The Interfaces Group MIB - ifType"; 1148 } 1150 leaf admin-status { 1151 if-feature if-mib; 1152 type enumeration { 1153 enum up { 1154 value 1; 1155 description 1156 "Ready to pass packets."; 1157 } 1158 enum down { 1159 value 2; 1160 description 1161 "Not ready to pass packets and not in some test mode."; 1162 } 1163 enum testing { 1164 value 3; 1165 description 1166 "In some test mode."; 1167 } 1169 } 1170 mandatory true; 1171 status deprecated; 1172 description 1173 "The desired state of the interface. 1175 This leaf has the same read semantics as ifAdminStatus."; 1176 reference 1177 "RFC 2863: The Interfaces Group MIB - ifAdminStatus"; 1178 } 1180 leaf oper-status { 1181 type enumeration { 1182 enum up { 1183 value 1; 1184 description 1185 "Ready to pass packets."; 1186 } 1187 enum down { 1188 value 2; 1189 description 1190 "The interface does not pass any packets."; 1191 } 1192 enum testing { 1193 value 3; 1194 description 1195 "In some test mode. No operational packets can 1196 be passed."; 1197 } 1198 enum unknown { 1199 value 4; 1200 description 1201 "Status cannot be determined for some reason."; 1202 } 1203 enum dormant { 1204 value 5; 1205 description 1206 "Waiting for some external event."; 1207 } 1208 enum not-present { 1209 value 6; 1210 description 1211 "Some component (typically hardware) is missing."; 1212 } 1213 enum lower-layer-down { 1214 value 7; 1215 description 1216 "Down due to state of lower-layer interface(s)."; 1218 } 1219 } 1220 mandatory true; 1221 status deprecated; 1222 description 1223 "The current operational state of the interface. 1225 This leaf has the same semantics as ifOperStatus."; 1226 reference 1227 "RFC 2863: The Interfaces Group MIB - ifOperStatus"; 1228 } 1230 leaf last-change { 1231 type yang:date-and-time; 1232 status deprecated; 1233 description 1234 "The time the interface entered its current operational 1235 state. If the current state was entered prior to the 1236 last re-initialization of the local network management 1237 subsystem, then this node is not present."; 1238 reference 1239 "RFC 2863: The Interfaces Group MIB - ifLastChange"; 1240 } 1242 leaf if-index { 1243 if-feature if-mib; 1244 type int32 { 1245 range "1..2147483647"; 1246 } 1247 mandatory true; 1248 status deprecated; 1249 description 1250 "The ifIndex value for the ifEntry represented by this 1251 interface."; 1252 reference 1253 "RFC 2863: The Interfaces Group MIB - ifIndex"; 1254 } 1256 leaf phys-address { 1257 type yang:phys-address; 1258 status deprecated; 1259 description 1260 "The interface's address at its protocol sub-layer. For 1261 example, for an 802.x interface, this object normally 1262 contains a Media Access Control (MAC) address. The 1263 interface's media-specific modules must define the bit 1264 and byte ordering and the format of the value of this 1265 object. For interfaces that do not have such an address 1266 (e.g., a serial line), this node is not present."; 1267 reference 1268 "RFC 2863: The Interfaces Group MIB - ifPhysAddress"; 1269 } 1271 leaf-list higher-layer-if { 1272 type interface-state-ref; 1273 status deprecated; 1274 description 1275 "A list of references to interfaces layered on top of this 1276 interface."; 1277 reference 1278 "RFC 2863: The Interfaces Group MIB - ifStackTable"; 1279 } 1281 leaf-list lower-layer-if { 1282 type interface-state-ref; 1283 status deprecated; 1284 description 1285 "A list of references to interfaces layered underneath this 1286 interface."; 1287 reference 1288 "RFC 2863: The Interfaces Group MIB - ifStackTable"; 1289 } 1291 leaf speed { 1292 type yang:gauge64; 1293 units "bits/second"; 1294 status deprecated; 1295 description 1296 "An estimate of the interface's current bandwidth in bits 1297 per second. For interfaces that do not vary in 1298 bandwidth or for those where no accurate estimation can 1299 be made, this node should contain the nominal bandwidth. 1300 For interfaces that have no concept of bandwidth, this 1301 node is not present."; 1302 reference 1303 "RFC 2863: The Interfaces Group MIB - 1304 ifSpeed, ifHighSpeed"; 1305 } 1307 container statistics { 1308 status deprecated; 1309 description 1310 "A collection of interface-related statistics objects."; 1312 leaf discontinuity-time { 1313 type yang:date-and-time; 1314 mandatory true; 1315 status deprecated; 1316 description 1317 "The time on the most recent occasion at which any one or 1318 more of this interface's counters suffered a 1319 discontinuity. If no such discontinuities have occurred 1320 since the last re-initialization of the local management 1321 subsystem, then this node contains the time the local 1322 management subsystem re-initialized itself."; 1323 } 1325 leaf in-octets { 1326 type yang:counter64; 1327 status deprecated; 1328 description 1329 "The total number of octets received on the interface, 1330 including framing characters. 1332 Discontinuities in the value of this counter can occur 1333 at re-initialization of the management system, and at 1334 other times as indicated by the value of 1335 'discontinuity-time'."; 1336 reference 1337 "RFC 2863: The Interfaces Group MIB - ifHCInOctets"; 1338 } 1340 leaf in-unicast-pkts { 1341 type yang:counter64; 1342 status deprecated; 1343 description 1344 "The number of packets, delivered by this sub-layer to a 1345 higher (sub-)layer, that were not addressed to a 1346 multicast or broadcast address at this sub-layer. 1348 Discontinuities in the value of this counter can occur 1349 at re-initialization of the management system, and at 1350 other times as indicated by the value of 1351 'discontinuity-time'."; 1352 reference 1353 "RFC 2863: The Interfaces Group MIB - ifHCInUcastPkts"; 1354 } 1356 leaf in-broadcast-pkts { 1357 type yang:counter64; 1358 status deprecated; 1359 description 1360 "The number of packets, delivered by this sub-layer to a 1361 higher (sub-)layer, that were addressed to a broadcast 1362 address at this sub-layer. 1364 Discontinuities in the value of this counter can occur 1365 at re-initialization of the management system, and at 1366 other times as indicated by the value of 1367 'discontinuity-time'."; 1368 reference 1369 "RFC 2863: The Interfaces Group MIB - 1370 ifHCInBroadcastPkts"; 1371 } 1373 leaf in-multicast-pkts { 1374 type yang:counter64; 1375 status deprecated; 1376 description 1377 "The number of packets, delivered by this sub-layer to a 1378 higher (sub-)layer, that were addressed to a multicast 1379 address at this sub-layer. For a MAC-layer protocol, 1380 this includes both Group and Functional addresses. 1382 Discontinuities in the value of this counter can occur 1383 at re-initialization of the management system, and at 1384 other times as indicated by the value of 1385 'discontinuity-time'."; 1386 reference 1387 "RFC 2863: The Interfaces Group MIB - 1388 ifHCInMulticastPkts"; 1389 } 1391 leaf in-discards { 1392 type yang:counter32; 1393 status deprecated; 1394 description 1395 "The number of inbound packets that were chosen to be 1396 discarded even though no errors had been detected to 1397 prevent their being deliverable to a higher-layer 1398 protocol. One possible reason for discarding such a 1399 packet could be to free up buffer space. 1401 Discontinuities in the value of this counter can occur 1402 at re-initialization of the management system, and at 1403 other times as indicated by the value of 1404 'discontinuity-time'."; 1405 reference 1406 "RFC 2863: The Interfaces Group MIB - ifInDiscards"; 1407 } 1409 leaf in-errors { 1410 type yang:counter32; 1411 status deprecated; 1412 description 1413 "For packet-oriented interfaces, the number of inbound 1414 packets that contained errors preventing them from being 1415 deliverable to a higher-layer protocol. For character- 1416 oriented or fixed-length interfaces, the number of 1417 inbound transmission units that contained errors 1418 preventing them from being deliverable to a higher-layer 1419 protocol. 1421 Discontinuities in the value of this counter can occur 1422 at re-initialization of the management system, and at 1423 other times as indicated by the value of 1424 'discontinuity-time'."; 1425 reference 1426 "RFC 2863: The Interfaces Group MIB - ifInErrors"; 1427 } 1429 leaf in-unknown-protos { 1430 type yang:counter32; 1431 status deprecated; 1432 description 1433 "For packet-oriented interfaces, the number of packets 1434 received via the interface that were discarded because 1435 of an unknown or unsupported protocol. For 1436 character-oriented or fixed-length interfaces that 1437 support protocol multiplexing, the number of 1438 transmission units received via the interface that were 1439 discarded because of an unknown or unsupported protocol. 1440 For any interface that does not support protocol 1441 multiplexing, this counter is not present. 1443 Discontinuities in the value of this counter can occur 1444 at re-initialization of the management system, and at 1445 other times as indicated by the value of 1446 'discontinuity-time'."; 1447 reference 1448 "RFC 2863: The Interfaces Group MIB - ifInUnknownProtos"; 1449 } 1451 leaf out-octets { 1452 type yang:counter64; 1453 status deprecated; 1454 description 1455 "The total number of octets transmitted out of the 1456 interface, including framing characters. 1458 Discontinuities in the value of this counter can occur 1459 at re-initialization of the management system, and at 1460 other times as indicated by the value of 1461 'discontinuity-time'."; 1462 reference 1463 "RFC 2863: The Interfaces Group MIB - ifHCOutOctets"; 1464 } 1466 leaf out-unicast-pkts { 1467 type yang:counter64; 1468 status deprecated; 1469 description 1470 "The total number of packets that higher-level protocols 1471 requested be transmitted, and that were not addressed 1472 to a multicast or broadcast address at this sub-layer, 1473 including those that were discarded or not sent. 1475 Discontinuities in the value of this counter can occur 1476 at re-initialization of the management system, and at 1477 other times as indicated by the value of 1478 'discontinuity-time'."; 1479 reference 1480 "RFC 2863: The Interfaces Group MIB - ifHCOutUcastPkts"; 1481 } 1483 leaf out-broadcast-pkts { 1484 type yang:counter64; 1485 status deprecated; 1486 description 1487 "The total number of packets that higher-level protocols 1488 requested be transmitted, and that were addressed to a 1489 broadcast address at this sub-layer, including those 1490 that were discarded or not sent. 1492 Discontinuities in the value of this counter can occur 1493 at re-initialization of the management system, and at 1494 other times as indicated by the value of 1495 'discontinuity-time'."; 1496 reference 1497 "RFC 2863: The Interfaces Group MIB - 1498 ifHCOutBroadcastPkts"; 1499 } 1501 leaf out-multicast-pkts { 1502 type yang:counter64; 1503 status deprecated; 1504 description 1505 "The total number of packets that higher-level protocols 1506 requested be transmitted, and that were addressed to a 1507 multicast address at this sub-layer, including those 1508 that were discarded or not sent. For a MAC-layer 1509 protocol, this includes both Group and Functional 1510 addresses. 1512 Discontinuities in the value of this counter can occur 1513 at re-initialization of the management system, and at 1514 other times as indicated by the value of 1515 'discontinuity-time'."; 1516 reference 1517 "RFC 2863: The Interfaces Group MIB - 1518 ifHCOutMulticastPkts"; 1519 } 1521 leaf out-discards { 1522 type yang:counter32; 1523 status deprecated; 1524 description 1525 "The number of outbound packets that were chosen to be 1526 discarded even though no errors had been detected to 1527 prevent their being transmitted. One possible reason 1528 for discarding such a packet could be to free up buffer 1529 space. 1531 Discontinuities in the value of this counter can occur 1532 at re-initialization of the management system, and at 1533 other times as indicated by the value of 1534 'discontinuity-time'."; 1535 reference 1536 "RFC 2863: The Interfaces Group MIB - ifOutDiscards"; 1537 } 1539 leaf out-errors { 1540 type yang:counter32; 1541 status deprecated; 1542 description 1543 "For packet-oriented interfaces, the number of outbound 1544 packets that could not be transmitted because of errors. 1545 For character-oriented or fixed-length interfaces, the 1546 number of outbound transmission units that could not be 1547 transmitted because of errors. 1549 Discontinuities in the value of this counter can occur 1550 at re-initialization of the management system, and at 1551 other times as indicated by the value of 1552 'discontinuity-time'."; 1553 reference 1554 "RFC 2863: The Interfaces Group MIB - ifOutErrors"; 1555 } 1556 } 1557 } 1558 } 1559 } 1561 1563 6. IANA Considerations 1565 This document registers a URI in the "IETF XML Registry" [RFC3688]. 1566 Following the format in RFC 3688, the following registration has been 1567 made. 1569 URI: urn:ietf:params:xml:ns:yang:ietf-interfaces 1571 Registrant Contact: The IESG. 1573 XML: N/A, the requested URI is an XML namespace. 1575 This document registers a YANG module in the "YANG Module Names" 1576 registry [RFC6020]. 1578 name: ietf-interfaces 1579 namespace: urn:ietf:params:xml:ns:yang:ietf-interfaces 1580 prefix: if 1581 reference: RFC XXXX 1583 7. Security Considerations 1585 The YANG module defined in this memo is designed to be accessed via 1586 the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the 1587 secure transport layer and the mandatory-to-implement secure 1588 transport is SSH [RFC6242]. The NETCONF access control model 1589 [RFC6536] provides the means to restrict access for particular 1590 NETCONF users to a pre-configured subset of all available NETCONF 1591 protocol operations and content. 1593 There are a number of data nodes defined in the YANG module which are 1594 writable/creatable/deletable (i.e., config true, which is the 1595 default). These data nodes may be considered sensitive or vulnerable 1596 in some network environments. Write operations (e.g., ) 1597 to these data nodes without proper protection can have a negative 1598 effect on network operations. These are the subtrees and data nodes 1599 and their sensitivity/vulnerability: 1601 /interfaces/interface: This list specifies the configured interfaces 1602 on a device. Unauthorized access to this list could cause the 1603 device to ignore packets it should receive and process. 1605 /interfaces/interface/enabled: This leaf controls whether an 1606 interface is enabled or not. Unauthorized access to this leaf 1607 could cause the device to ignore packets it should receive and 1608 process. 1610 8. Acknowledgments 1612 The author wishes to thank Alexander Clemm, Per Hedeland, Ladislav 1613 Lhotka, and Juergen Schoenwaelder for their helpful comments. 1615 9. References 1617 9.1. Normative References 1619 [I-D.ietf-netmod-revised-datastores] 1620 Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1621 and R. Wilton, "Network Management Datastore 1622 Architecture", draft-ietf-netmod-revised-datastores-07 1623 (work in progress), November 2017. 1625 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1626 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 1627 RFC2119, March 1997, . 1630 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 1631 MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, 1632 . 1634 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1635 DOI 10.17487/RFC3688, January 2004, . 1638 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1639 the Network Configuration Protocol (NETCONF)", RFC 6020, 1640 DOI 10.17487/RFC6020, October 2010, . 1643 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 1644 6991, DOI 10.17487/RFC6991, July 2013, . 1647 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1648 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1649 . 1651 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1652 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1653 May 2017, . 1655 9.2. Informative References 1657 [I-D.ietf-netmod-yang-tree-diagrams] 1658 Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft- 1659 ietf-netmod-yang-tree-diagrams-02 (work in progress), 1660 October 2017. 1662 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1663 and A. Bierman, Ed., "Network Configuration Protocol 1664 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1665 . 1667 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1668 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1669 . 1671 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1672 Protocol (NETCONF) Access Control Model", RFC 6536, DOI 1673 10.17487/RFC6536, March 2012, . 1676 [RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", RFC 1677 7224, DOI 10.17487/RFC7224, May 2014, . 1680 Appendix A. Example: Ethernet Interface Module 1682 This section gives a simple example of how an Ethernet interface 1683 module could be defined. It demonstrates how media-specific 1684 configuration parameters can be conditionally augmented to the 1685 generic interface list. It also shows how operational state 1686 parameters can be conditionally augmented to the operational 1687 interface list. The example is not intended as a complete module for 1688 Ethernet configuration. 1690 module ex-ethernet { 1691 namespace "http://example.com/ethernet"; 1692 prefix "eth"; 1694 import ietf-interfaces { 1695 prefix if; 1696 } 1697 import iana-if-type { 1698 prefix ianaift; 1699 } 1701 // configuration and state parameters for Ethernet interfaces 1702 augment "/if:interfaces/if:interface" { 1703 when "if:type = 'ianaift:ethernetCsmacd'"; 1705 container ethernet { 1706 container transmission { 1707 choice transmission-params { 1708 case auto { 1709 leaf auto-negotiate { 1710 type empty; 1711 } 1712 } 1713 case manual { 1714 container manual { 1715 leaf duplex { 1716 type enumeration { 1717 enum "half"; 1718 enum "full"; 1719 } 1720 } 1721 leaf speed { 1722 type enumeration { 1723 enum "10Mb"; 1724 enum "100Mb"; 1725 enum "1Gb"; 1726 enum "10Gb"; 1727 } 1728 } 1729 } 1730 } 1731 } 1732 leaf duplex { 1733 type enumeration { 1734 enum "half"; 1735 enum "full"; 1736 } 1737 config false; 1738 } 1739 } 1740 // other Ethernet-specific params... 1741 } 1742 } 1744 } 1746 Appendix B. Example: Ethernet Bonding Interface Module 1748 This section gives an example of how interface layering can be 1749 defined. An Ethernet bonding interface that bonds several Ethernet 1750 interfaces into one logical interface is defined. 1752 module ex-ethernet-bonding { 1753 namespace "http://example.com/ethernet-bonding"; 1754 prefix "bond"; 1756 import ietf-interfaces { 1757 prefix if; 1758 } 1759 import iana-if-type { 1760 prefix ianaift; 1761 } 1763 augment "/if:interfaces/if:interface" { 1764 when "if:type = 'ianaift:ieee8023adLag'"; 1766 leaf-list slave-if { 1767 type if:interface-ref; 1768 must "/if:interfaces/if:interface[if:name = current()]" 1769 + "/if:type = 'ianaift:ethernetCsmacd'" { 1770 description 1771 "The type of a slave interface must be 'ethernetCsmacd'."; 1772 } 1773 } 1774 leaf bonding-mode { 1775 type enumeration { 1776 enum round-robin; 1777 enum active-backup; 1778 enum broadcast; 1779 } 1780 } 1781 // other bonding config params, failover times, etc. 1782 } 1783 } 1785 Appendix C. Example: VLAN Interface Module 1787 This section gives an example of how a VLAN interface module can be 1788 defined. 1790 module ex-vlan { 1791 namespace "http://example.com/vlan"; 1792 prefix "vlan"; 1794 import ietf-interfaces { 1795 prefix if; 1796 } 1797 import iana-if-type { 1798 prefix ianaift; 1799 } 1801 augment "/if:interfaces/if:interface" { 1802 when "if:type = 'ianaift:ethernetCsmacd' or 1803 if:type = 'ianaift:ieee8023adLag'"; 1804 leaf vlan-tagging { 1805 type boolean; 1806 default false; 1807 } 1808 } 1810 augment "/if:interfaces/if:interface" { 1811 when "if:type = 'ianaift:l2vlan'"; 1813 leaf base-interface { 1814 type if:interface-ref; 1815 must "/if:interfaces/if:interface[if:name = current()]" 1816 + "/vlan:vlan-tagging = 'true'" { 1817 description 1818 "The base interface must have VLAN tagging enabled."; 1819 } 1820 } 1821 leaf vlan-id { 1822 type uint16 { 1823 range "1..4094"; 1824 } 1825 must "../base-interface" { 1826 description 1827 "If a vlan-id is defined, a base-interface must 1828 be specified."; 1829 } 1830 } 1831 } 1832 } 1834 Appendix D. Example: NETCONF Reply 1836 This section gives an example of a reply to the NETCONF 1837 request for for a device that implements the example data 1838 models above. 1840 1843 1844 1849 1850 eth0 1851 ianaift:ethernetCsmacd 1852 false 1853 1855 1856 eth1 1857 ianaift:ethernetCsmacd 1858 true 1859 true 1860 1862 1863 eth1.10 1864 ianaift:l2vlan 1865 true 1866 eth1 1867 10 1868 1870 1871 lo1 1872 ianaift:softwareLoopback 1873 true 1874 1876 1877 1878 1880 Appendix E. Example: NETCONF Reply 1882 This section gives an example of a reply to the NETCONF 1883 request for for a device that implements the example 1884 data models above. 1886 1889 1890 1896 1897 eth0 1898 ianaift:ethernetCsmacd 1899 false 1900 down 1901 down 1902 2 1903 00:01:02:03:04:05 1904 1905 1906 2013-04-01T03:00:00+00:00 1907 1908 1909 1910 1912 1913 eth1 1914 ianaift:ethernetCsmacd 1915 true 1916 up 1917 up 1918 7 1919 00:01:02:03:04:06 1920 eth1.10 1921 1922 1923 2013-04-01T03:00:00+00:00 1924 1925 1926 1927 true 1929 1931 1932 eth1.10 1933 ianaift:l2vlan 1934 true 1935 up 1936 up 1937 9 1938 eth1 1939 1940 1941 2013-04-01T03:00:00+00:00 1942 1943 1944 1945 eth1 1946 10 1947 1949 1950 1951 eth2 1952 ianaift:ethernetCsmacd 1953 down 1954 down 1955 8 1956 00:01:02:03:04:07 1957 1958 1959 2013-04-01T03:00:00+00:00 1960 1961 1962 1963 1965 1966 lo1 1967 ianaift:softwareLoopback 1968 true 1969 up 1970 up 1971 1 1972 1973 1974 2013-04-01T03:00:00+00:00 1975 1976 1978 1979 1981 1982 1983 1985 Appendix F. Examples: Interface Naming Schemes 1987 This section gives examples of some implementation strategies. 1989 The examples make use of the example data model "ex-vlan" (see 1990 Appendix C) to show how user-controlled interfaces can be configured. 1992 F.1. Router with Restricted Interface Names 1994 In this example, a router has support for 4 line cards, each with 8 1995 ports. The slots for the cards are physically numbered from 0 to 3, 1996 and the ports on each card from 0 to 7. Each card has Fast Ethernet 1997 or Gigabit Ethernet ports. 1999 The device-specific names for these physical interfaces are 2000 "fastethernet-N/M" or "gigabitethernet-N/M". 2002 The name of a VLAN interface is restricted to the form 2003 ".". 2005 It is assumed that the operator is aware of this naming scheme. The 2006 implementation auto-initializes the value for "type" based on the 2007 interface name. 2009 The NETCONF server does not advertise the "arbitrary-names" feature 2010 in the message. 2012 An operator can configure a physical interface by sending an 2013 containing: 2015 2016 fastethernet-1/0 2017 2019 When the server processes this request, it will set the leaf "type" 2020 to "ianaift:ethernetCsmacd". Thus, if the client performs a 2021 right after the above, it will get: 2023 2024 fastethernet-1/0 2025 ianaift:ethernetCsmacd 2026 2028 The client can configure a VLAN interface by sending an 2029 containing: 2031 2032 fastethernet-1/0.10005 2033 ianaift:l2vlan 2034 fastethernet-1/0 2035 5 2036 2038 If the client tries to change the type of the physical interface with 2039 an containing: 2041 2042 fastethernet-1/0 2043 ianaift:tunnel 2044 2046 then the server will reply with an "invalid-value" error, since the 2047 new type does not match the name. 2049 F.2. Router with Arbitrary Interface Names 2051 In this example, a router has support for 4 line cards, each with 8 2052 ports. The slots for the cards are physically numbered from 0 to 3, 2053 and the ports on each card from 0 to 7. Each card has Fast Ethernet 2054 or Gigabit Ethernet ports. 2056 The device-specific names for these physical interfaces are 2057 "fastethernet-N/M" or "gigabitethernet-N/M". 2059 The implementation does not restrict the user-controlled interface 2060 names. This allows an operator to more easily apply the interface 2061 configuration to a different interface. However, the additional 2062 level of indirection also makes it a bit more complex to map 2063 interface names found in other protocols to configuration entries. 2065 The NETCONF server advertises the "arbitrary-names" feature in the 2066 message. 2068 Physical interfaces are configured as in Appendix F.1. 2070 An operator can configure a VLAN interface by sending an 2071 containing: 2073 2074 acme-interface 2075 ianaift:l2vlan 2076 fastethernet-1/0 2077 5 2078 2080 If necessary, the operator can move the configuration named 2081 "acme-interface" over to a different physical interface with an 2082 containing: 2084 2085 acme-interface 2086 fastethernet-1/1 2087 2089 F.3. Ethernet Switch with Restricted Interface Names 2091 In this example, an Ethernet switch has a number of ports, each 2092 identified by a simple port number. 2094 The device-specific names for the physical interfaces are numbers 2095 that match the physical port number. 2097 An operator can configure a physical interface by sending an 2098 containing: 2100 2101 6 2102 2104 When the server processes this request, it will set the leaf "type" 2105 to "ianaift:ethernetCsmacd". Thus, if the client performs a 2106 right after the above, it will get: 2108 2109 6 2110 ianaift:ethernetCsmacd 2111 2113 F.4. Generic Host with Restricted Interface Names 2115 In this example, a generic host has interfaces named by the kernel. 2116 The system identifies the physical interface by the name assigned by 2117 the operating system to the interface. 2119 The name of a VLAN interface is restricted to the form 2120 ":". 2122 The NETCONF server does not advertise the "arbitrary-names" feature 2123 in the message. 2125 An operator can configure an interface by sending an 2126 containing: 2128 2129 eth8 2130 2132 When the server processes this request, it will set the leaf "type" 2133 to "ianaift:ethernetCsmacd". Thus, if the client performs a 2134 right after the above, it will get: 2136 2137 eth8 2138 ianaift:ethernetCsmacd 2139 2141 The client can configure a VLAN interface by sending an 2142 containing: 2144 2145 eth8:5 2146 ianaift:l2vlan 2147 eth8 2148 5 2149 2151 F.5. Generic Host with Arbitrary Interface Names 2153 In this example, a generic host has interfaces named by the kernel. 2154 The system identifies the physical interface by the name assigned by 2155 the operating system to the interface. 2157 The implementation does not restrict the user-controlled interface 2158 names. This allows an operator to more easily apply the interface 2159 configuration to a different interface. However, the additional 2160 level of indirection also makes it a bit more complex to map 2161 interface names found in other protocols to configuration entries. 2163 The NETCONF server advertises the "arbitrary-names" feature in the 2164 message. 2166 Physical interfaces are configured as in Appendix F.4. 2168 An operator can configure a VLAN interface by sending an 2169 containing: 2171 2172 acme-interface 2173 ianaift:l2vlan 2174 eth8 2175 5 2176 2178 If necessary, the operator can move the configuration named 2179 "acme-interface" over to a different physical interface with an 2180 containing: 2182 2183 acme-interface 2184 eth3 2185 2187 Author's Address 2189 Martin Bjorklund 2190 Tail-f Systems 2192 Email: mbj@tail-f.com