idnits 2.17.1 draft-ietf-netmod-rfc7223bis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == 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 248 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 16, 2017) is 2377 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-03 -- Obsolete informational reference (is this intentional?): RFC 6536 (Obsoleted by RFC 8341) Summary: 0 errors (**), 0 flaws (~~), 5 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) October 16, 2017 5 Intended status: Standards Track 6 Expires: April 19, 2018 8 A YANG Data Model for Interface Management 9 draft-ietf-netmod-rfc7223bis-00 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 April 19, 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 . . . . . 37 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 key words "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]. 119 The following terms are used within this document: 121 o system-controlled interface: An interface is said to be system- 122 controlled if the system creates and deletes the interface 123 independently of what has been explicitly configured. Examples 124 are interfaces representing physical hardware that appear and 125 disappear when hardware (e.g., a line card or hot-pluggable 126 wireless interface) is added or removed. System-controlled 127 interfaces may also appear if a certain functionality is enabled 128 (e.g., a loopback interface might appear if the IP protocol stack 129 is enabled). 131 o user-controlled interface: An interface is said to be user- 132 controlled if the creation of the interface is controlled by 133 adding explicit interface configuration to the intended 134 configuration and the removal of the interface is controlled by 135 removing explicit interface configuration from the intended 136 configuration. Examples are VLAN interfaces configured on a 137 system-controlled Ethernet interface. 139 The following terms are defined in 140 [I-D.ietf-netmod-revised-datastores] and are not redefined here: 142 o client 144 o server 145 o configuration 147 o system state 149 o operational state 151 o intended configuration 153 The following terms are defined in [RFC7950] and are not redefined 154 here: 156 o augment 158 o data model 160 o data node 162 o presence container 164 1.3. Tree Diagrams 166 A simplified graphical representation of the data model is used in 167 this document. The meaning of the symbols in these diagrams is as 168 follows: 170 o Brackets "[" and "]" enclose list keys. 172 o Abbreviations before data node names: "rw" means configuration 173 (read-write), and "ro" means state data (read-only). 175 o Symbols after data node names: "?" means an optional node, "!" 176 means a presence container, and "*" denotes either a list or a 177 leaf-list. 179 o Parentheses enclose choice and case nodes, and case nodes are also 180 marked with a colon (":"). 182 o Ellipsis ("...") stands for contents of subtrees that are not 183 shown. 185 2. Objectives 187 This section describes some of the design objectives for the model 188 presented in Section 5. 190 o It is recognized that existing implementations will have to map 191 the interface data model defined in this memo to their proprietary 192 native data model. To facilitate such mappings, the data model 193 should be simple. 195 o The data model should be suitable for new implementations to use 196 as is, without requiring a mapping to a different native model. 198 o References to interfaces should be as simple as possible, 199 preferably by using a single leafref. 201 o The mapping to ifIndex [RFC2863] used by the Simple Network 202 Management Protocol (SNMP) to identify interfaces must be clear. 204 o The model must support interface layering: both (1) simple 205 layering, where one interface is layered on top of exactly one 206 other interface, and (2) more complex scenarios, where one 207 interface results from the aggregation of N other interfaces or 208 when N interfaces are multiplexed over one other interface. 210 o The data model should support the pre-provisioning of interface 211 configuration, i.e., it should be possible to configure an 212 interface whose physical interface hardware is not present on the 213 device. It is recommended that devices that support dynamic 214 addition and removal of physical interfaces also support pre- 215 provisioning. 217 o The data model should support physical interfaces as well as 218 logical interfaces. 220 o The data model should include read-only counters in order to 221 gather statistics for sent and received octets and packets, 222 received packets with errors, and packets that could not be sent 223 due to errors. 225 3. Interfaces Data Model 227 This document defines the YANG module "ietf-interfaces", which has 228 the following structure, excluding the deprecated "/interfaces-state" 229 subtree: 231 module: ietf-interfaces 232 +--rw interfaces 233 +--rw interface* [name] 234 +--rw name string 235 +--rw description? string 236 +--rw type identityref 237 +--rw enabled? boolean 238 +--rw link-up-down-trap-enable? enumeration {if-mib}? 239 +--ro admin-status enumeration {if-mib}? 240 +--ro oper-status enumeration 241 +--ro last-change? yang:date-and-time 242 +--ro if-index int32 {if-mib}? 243 +--ro phys-address? yang:phys-address 244 +--ro higher-layer-if* interface-ref 245 +--ro lower-layer-if* interface-ref 246 +--ro speed? yang:gauge64 247 +--ro statistics 248 +--ro discontinuity-time yang:date-and-time 249 +--ro in-octets? yang:counter64 250 +--ro in-unicast-pkts? yang:counter64 251 +--ro in-broadcast-pkts? yang:counter64 252 +--ro in-multicast-pkts? yang:counter64 253 +--ro in-discards? yang:counter32 254 +--ro in-errors? yang:counter32 255 +--ro in-unknown-protos? yang:counter32 256 +--ro out-octets? yang:counter64 257 +--ro out-unicast-pkts? yang:counter64 258 +--ro out-broadcast-pkts? yang:counter64 259 +--ro out-multicast-pkts? yang:counter64 260 +--ro out-discards? yang:counter32 261 +--ro out-errors? yang:counter32 263 3.1. The Interface List 265 The data model for interfaces presented in this document uses a flat 266 list of interfaces ("/interfaces/interface"). Each interface in the 267 list is identified by its name. Furthermore, each interface has a 268 mandatory "type" leaf. 270 The "iana-if-type" module [RFC7224] defines YANG identities for the 271 interface types in the IANA-maintained "ifType definitions" registry. 273 It is expected that interface-type-specific data models augment the 274 interface list and possibly use the "type" leaf to make the 275 augmentation conditional. 277 As an example of such an interface-type-specific augmentation, 278 consider this YANG snippet. For a more complete example, see 279 Appendix A. 281 import interfaces { 282 prefix "if"; 283 } 284 import iana-if-type { 285 prefix ianaift; 286 } 288 augment "/if:interfaces/if:interface" { 289 when "if:type = 'ianaift:ethernetCsmacd'"; 291 container ethernet { 292 leaf duplex { 293 ... 294 } 295 } 296 } 298 For system-controlled interfaces, the "name" is the device-specific 299 name of the interface. 301 If the device supports arbitrarily named user-controlled interfaces, 302 then the server will advertise the "arbitrary-names" feature. If the 303 server does not advertise this feature, the names of user-controlled 304 interfaces MUST match the device's naming scheme. How a client can 305 learn the naming scheme of such devices is outside the scope of this 306 document. See Appendix F.1 and Appendix F.2 for examples. 308 When a system-controlled interface is created in the operational 309 state by the system, the system tries to apply the interface 310 configuration in the intended configuration with the same name as the 311 new interface. If no such interface configuration is found, or if 312 the configured type does not match the real interface type, the 313 system creates the interface without applying explicit configuration. 315 When a user-controlled interface is created, the configuration 316 determines the name of the interface. 318 Depending on the operating system and the physical attachment point 319 to which a network interface may be attached or removed, it may be 320 impossible for an implementation to provide predictable and 321 consistent names for system-controlled interfaces across insertion/ 322 removal cycles as well as in anticipation of initial insertion. The 323 ability to provide configurations for such interfaces is therefore 324 dependent on the implementation and cannot be assumed in all cases. 326 3.2. Interface References 328 An interface is identified by its name, which is unique within the 329 server. This property is captured in the "interface-ref" and 330 typedef, which other YANG modules SHOULD use when they need to 331 reference an interface. 333 3.3. Interface Layering 335 There is no generic mechanism for how an interface is configured to 336 be layered on top of some other interface. It is expected that 337 interface-type-specific models define their own data nodes for 338 interface layering by using "interface-ref" types to reference lower 339 layers. 341 Below is an example of a model with such nodes. For a more complete 342 example, see Appendix B. 344 import interfaces { 345 prefix "if"; 346 } 347 import iana-if-type { 348 prefix ianaift; 349 } 351 augment "/if:interfaces/if:interface" { 352 when "if:type = 'ianaift:ieee8023adLag'"; 354 leaf-list slave-if { 355 type if:interface-ref; 356 must "/if:interfaces/if:interface[if:name = current()]" 357 + "/if:type = 'ianaift:ethernetCsmacd'" { 358 description 359 "The type of a slave interface must be 360 'ethernetCsmacd'."; 361 } 362 } 363 // other bonding config params, failover times, etc. 364 } 366 While the interface layering is configured in interface-type-specific 367 models, two generic state data leaf-lists, "higher-layer-if" and 368 "lower-layer-if", represent a read-only view of the interface 369 layering hierarchy. 371 4. Relationship to the IF-MIB 373 If the device implements the IF-MIB [RFC2863], each entry in the 374 "/interfaces/interface" list in the operational state is typically 375 mapped to one ifEntry. The "if-index" leaf MUST contain the value of 376 the corresponding ifEntry's ifIndex. 378 In most cases, the "name" of an "/interfaces/interface" entry is 379 mapped to ifName. The IF-MIB allows two different ifEntries to have 380 the same ifName. Devices that support this feature and also support 381 the data model defined in this document cannot have a 1-1 mapping 382 between the "name" leaf and ifName. 384 The configured "description" of an "interface" has traditionally been 385 mapped to ifAlias in some implementations. This document allows this 386 mapping, but implementers should be aware of the differences in the 387 value space and persistence for these objects. See the YANG module 388 definition of the leaf "description" in Section 5 for details. 390 The IF-MIB also defines the writable object ifPromiscuousMode. Since 391 this object typically is not implemented as a configuration object by 392 SNMP agents, it is not mapped to the "ietf-interfaces" module. 394 The ifMtu object from the IF-MIB is not mapped to the 395 "ietf-interfaces" module. It is expected that interface-type- 396 specific YANG modules provide interface-type-specific MTU leafs by 397 augmenting the "ietf-interfaces" model. 399 There are a number of counters in the IF-MIB that exist in two 400 versions: one with 32 bits and one with 64 bits. The 64-bit versions 401 were added to support high-speed interfaces with a data rate greater 402 than 20,000,000 bits/second. Today's implementations generally 403 support such high-speed interfaces, and hence only 64-bit counters 404 are provided in this data model. Note that NETCONF and SNMP may 405 differ in the time granularity in which they provide access to the 406 counters. For example, it is common that SNMP implementations cache 407 counter values for some time. 409 The objects ifDescr and ifConnectorPresent from the IF-MIB are not 410 mapped to the "ietf-interfaces" module. 412 The following tables list the YANG data nodes with corresponding 413 objects in the IF-MIB. 415 +--------------------------------------+----------------------------+ 416 | YANG data node in | IF-MIB object | 417 | /interfaces/interface | | 418 +--------------------------------------+----------------------------+ 419 | name | ifName | 420 | type | ifType | 421 | description | ifAlias | 422 | admin-status | ifAdminStatus | 423 | oper-status | ifOperStatus | 424 | last-change | ifLastChange | 425 | if-index | ifIndex | 426 | link-up-down-trap-enable | ifLinkUpDownTrapEnable | 427 | phys-address | ifPhysAddress | 428 | higher-layer-if and lower-layer-if | ifStackTable | 429 | speed | ifSpeed and ifHighSpeed | 430 | discontinuity-time | ifCounterDiscontinuityTime | 431 | in-octets | ifHCInOctets | 432 | in-unicast-pkts | ifHCInUcastPkts | 433 | in-broadcast-pkts | ifHCInBroadcastPkts | 434 | in-multicast-pkts | ifHCInMulticastPkts | 435 | in-discards | ifInDiscards | 436 | in-errors | ifInErrors | 437 | in-unknown-protos | ifInUnknownProtos | 438 | out-octets | ifHCOutOctets | 439 | out-unicast-pkts | ifHCOutUcastPkts | 440 | out-broadcast-pkts | ifHCOutBroadcastPkts | 441 | out-multicast-pkts | ifHCOutMulticastPkts | 442 | out-discards | ifOutDiscards | 443 | out-errors | ifOutErrors | 444 +--------------------------------------+----------------------------+ 446 YANG Data Nodes and Related IF-MIB Objects 448 5. Interfaces YANG Module 450 This YANG module imports typedefs from [RFC6991]. 452 file "ietf-interfaces@2017-08-17.yang" 454 module ietf-interfaces { 455 yang-version 1.1; 456 namespace "urn:ietf:params:xml:ns:yang:ietf-interfaces"; 457 prefix if; 459 import ietf-yang-types { 460 prefix yang; 461 } 462 organization 463 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 465 contact 466 "WG Web: 467 WG List: 469 Editor: Martin Bjorklund 470 "; 472 description 473 "This module contains a collection of YANG definitions for 474 managing network interfaces. 476 Copyright (c) 2017 IETF Trust and the persons identified as 477 authors of the code. All rights reserved. 479 Redistribution and use in source and binary forms, with or 480 without modification, is permitted pursuant to, and subject 481 to the license terms contained in, the Simplified BSD License 482 set forth in Section 4.c of the IETF Trust's Legal Provisions 483 Relating to IETF Documents 484 (http://trustee.ietf.org/license-info). 486 This version of this YANG module is part of RFC XXXX; see 487 the RFC itself for full legal notices."; 489 revision 2017-08-17 { 490 description 491 "Updated to support NMDA."; 492 reference 493 "RFC XXXX: A YANG Data Model for Interface Management"; 494 } 496 revision 2014-05-08 { 497 description 498 "Initial revision."; 499 reference 500 "RFC 7223: A YANG Data Model for Interface Management"; 501 } 503 /* 504 * Typedefs 505 */ 507 typedef interface-ref { 508 type leafref { 509 path "/if:interfaces/if:interface/if:name"; 511 } 512 description 513 "This type is used by data models that need to reference 514 interfaces."; 515 } 517 /* 518 * Identities 519 */ 521 identity interface-type { 522 description 523 "Base identity from which specific interface types are 524 derived."; 525 } 527 /* 528 * Features 529 */ 531 feature arbitrary-names { 532 description 533 "This feature indicates that the device allows user-controlled 534 interfaces to be named arbitrarily."; 535 } 536 feature pre-provisioning { 537 description 538 "This feature indicates that the device supports 539 pre-provisioning of interface configuration, i.e., it is 540 possible to configure an interface whose physical interface 541 hardware is not present on the device."; 542 } 543 feature if-mib { 544 description 545 "This feature indicates that the device implements 546 the IF-MIB."; 547 reference 548 "RFC 2863: The Interfaces Group MIB"; 549 } 551 /* 552 * Data nodes 553 */ 555 container interfaces { 556 description 557 "Interface parameters."; 559 list interface { 560 key "name"; 562 description 563 "The list of interfaces on the device. 565 The status of an interface is available in this list in the 566 operational state. If the configuration of a 567 system-controlled interface cannot be used by the system 568 (e.g., the interface hardware present does not match the 569 interface type), then the configuration is not applied to 570 the system-controlled interface shown in the operational 571 state. If the configuration of a user-controlled interface 572 cannot be used by the system, the configured interface is 573 not instantiated in the operational state. 575 System-controlled interfaces created by the system are always 576 present in this list in the operational state, whether they 577 are configured or not."; 579 leaf name { 580 type string; 581 description 582 "The name of the interface. 584 A device MAY restrict the allowed values for this leaf, 585 possibly depending on the type of the interface. 586 For system-controlled interfaces, this leaf is the 587 device-specific name of the interface. 589 If a client tries to create configuration for a 590 system-controlled interface that is not present in the 591 operational state, the server MAY reject the request if 592 the implementation does not support pre-provisioning of 593 interfaces or if the name refers to an interface that can 594 never exist in the system. A NETCONF server MUST reply 595 with an rpc-error with the error-tag 'invalid-value' in 596 this case. 598 If the device supports pre-provisioning of interface 599 configuration, the 'pre-provisioning' feature is 600 advertised. 602 If the device allows arbitrarily named user-controlled 603 interfaces, the 'arbitrary-names' feature is advertised. 605 When a configured user-controlled interface is created by 606 the system, it is instantiated with the same name in the 607 operational state. 609 A server implementation MAY map this leaf to the ifName 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 ifName. The definition of 613 such a mechanism is outside the scope of this document."; 614 reference 615 "RFC 2863: The Interfaces Group MIB - ifName"; 616 } 618 leaf description { 619 type string; 620 description 621 "A textual description of the interface. 623 A server implementation MAY map this leaf to the ifAlias 624 MIB object. Such an implementation needs to use some 625 mechanism to handle the differences in size and characters 626 allowed between this leaf and ifAlias. The definition of 627 such a mechanism is outside the scope of this document. 629 Since ifAlias is defined to be stored in non-volatile 630 storage, the MIB implementation MUST map ifAlias to the 631 value of 'description' in the persistently stored 632 configuration."; 633 reference 634 "RFC 2863: The Interfaces Group MIB - ifAlias"; 635 } 637 leaf type { 638 type identityref { 639 base interface-type; 640 } 641 mandatory true; 642 description 643 "The type of the interface. 645 When an interface entry is created, a server MAY 646 initialize the type leaf with a valid value, e.g., if it 647 is possible to derive the type from the name of the 648 interface. 650 If a client tries to set the type of an interface to a 651 value that can never be used by the system, e.g., if the 652 type is not supported or if the type does not match the 653 name of the interface, the server MUST reject the request. 654 A NETCONF server MUST reply with an rpc-error with the 655 error-tag 'invalid-value' in this case."; 656 reference 657 "RFC 2863: The Interfaces Group MIB - ifType"; 658 } 660 leaf enabled { 661 type boolean; 662 default "true"; 663 description 664 "This leaf contains the configured, desired state of the 665 interface. 667 Systems that implement the IF-MIB use the value of this 668 leaf in the intended configuration to set 669 IF-MIB.ifAdminStatus to 'up' or 'down' after an ifEntry 670 has been initialized, as described in RFC 2863. 672 Changes in this leaf in the intended configuration are 673 reflected in ifAdminStatus, but if ifAdminStatus is 674 changed over SNMP, this leaf is not affected."; 675 reference 676 "RFC 2863: The Interfaces Group MIB - ifAdminStatus"; 677 } 679 leaf link-up-down-trap-enable { 680 if-feature if-mib; 681 type enumeration { 682 enum enabled { 683 value 1; 684 description 685 "The device will generate linkUp/linkDown SNMP 686 notifications for this interface."; 687 } 688 enum disabled { 689 value 2; 690 description 691 "The device will not generate linkUp/linkDown SNMP 692 notifications for this interface."; 693 } 694 } 695 description 696 "Controls whether linkUp/linkDown SNMP notifications 697 should be generated for this interface. 699 If this node is not configured, the value 'enabled' is 700 operationally used by the server for interfaces that do 701 not operate on top of any other interface (i.e., there are 702 no 'lower-layer-if' entries), and 'disabled' otherwise."; 704 reference 705 "RFC 2863: The Interfaces Group MIB - 706 ifLinkUpDownTrapEnable"; 707 } 709 leaf admin-status { 710 if-feature if-mib; 711 type enumeration { 712 enum up { 713 value 1; 714 description 715 "Ready to pass packets."; 716 } 717 enum down { 718 value 2; 719 description 720 "Not ready to pass packets and not in some test mode."; 721 } 722 enum testing { 723 value 3; 724 description 725 "In some test mode."; 726 } 727 } 728 config false; 729 mandatory true; 730 description 731 "The desired state of the interface. 733 This leaf has the same read semantics as ifAdminStatus."; 734 reference 735 "RFC 2863: The Interfaces Group MIB - ifAdminStatus"; 736 } 738 leaf oper-status { 739 type enumeration { 740 enum up { 741 value 1; 742 description 743 "Ready to pass packets."; 744 } 745 enum down { 746 value 2; 747 description 748 "The interface does not pass any packets."; 749 } 750 enum testing { 751 value 3; 752 description 753 "In some test mode. No operational packets can 754 be passed."; 755 } 756 enum unknown { 757 value 4; 758 description 759 "Status cannot be determined for some reason."; 760 } 761 enum dormant { 762 value 5; 763 description 764 "Waiting for some external event."; 765 } 766 enum not-present { 767 value 6; 768 description 769 "Some component (typically hardware) is missing."; 770 } 771 enum lower-layer-down { 772 value 7; 773 description 774 "Down due to state of lower-layer interface(s)."; 775 } 776 } 777 config false; 778 mandatory true; 779 description 780 "The current operational state of the interface. 782 This leaf has the same semantics as ifOperStatus."; 783 reference 784 "RFC 2863: The Interfaces Group MIB - ifOperStatus"; 785 } 787 leaf last-change { 788 type yang:date-and-time; 789 config false; 790 description 791 "The time the interface entered its current operational 792 state. If the current state was entered prior to the 793 last re-initialization of the local network management 794 subsystem, then this node is not present."; 795 reference 796 "RFC 2863: The Interfaces Group MIB - ifLastChange"; 797 } 799 leaf if-index { 800 if-feature if-mib; 801 type int32 { 802 range "1..2147483647"; 803 } 804 config false; 805 mandatory true; 806 description 807 "The ifIndex value for the ifEntry represented by this 808 interface."; 809 reference 810 "RFC 2863: The Interfaces Group MIB - ifIndex"; 811 } 813 leaf phys-address { 814 type yang:phys-address; 815 config false; 816 description 817 "The interface's address at its protocol sub-layer. For 818 example, for an 802.x interface, this object normally 819 contains a Media Access Control (MAC) address. The 820 interface's media-specific modules must define the bit 821 and byte ordering and the format of the value of this 822 object. For interfaces that do not have such an address 823 (e.g., a serial line), this node is not present."; 824 reference 825 "RFC 2863: The Interfaces Group MIB - ifPhysAddress"; 826 } 828 leaf-list higher-layer-if { 829 type interface-ref; 830 config false; 831 description 832 "A list of references to interfaces layered on top of this 833 interface."; 834 reference 835 "RFC 2863: The Interfaces Group MIB - ifStackTable"; 836 } 838 leaf-list lower-layer-if { 839 type interface-ref; 840 config false; 841 description 842 "A list of references to interfaces layered underneath this 843 interface."; 844 reference 845 "RFC 2863: The Interfaces Group MIB - ifStackTable"; 846 } 847 leaf speed { 848 type yang:gauge64; 849 units "bits/second"; 850 config false; 851 description 852 "An estimate of the interface's current bandwidth in bits 853 per second. For interfaces that do not vary in 854 bandwidth or for those where no accurate estimation can 855 be made, this node should contain the nominal bandwidth. 856 For interfaces that have no concept of bandwidth, this 857 node is not present."; 858 reference 859 "RFC 2863: The Interfaces Group MIB - 860 ifSpeed, ifHighSpeed"; 861 } 863 container statistics { 864 config false; 865 description 866 "A collection of interface-related statistics objects."; 868 leaf discontinuity-time { 869 type yang:date-and-time; 870 mandatory true; 871 description 872 "The time on the most recent occasion at which any one or 873 more of this interface's counters suffered a 874 discontinuity. If no such discontinuities have occurred 875 since the last re-initialization of the local management 876 subsystem, then this node contains the time the local 877 management subsystem re-initialized itself."; 878 } 880 leaf in-octets { 881 type yang:counter64; 882 description 883 "The total number of octets received on the interface, 884 including framing characters. 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 - ifHCInOctets"; 892 } 894 leaf in-unicast-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 not addressed to a 899 multicast or broadcast 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 - ifHCInUcastPkts"; 907 } 909 leaf in-broadcast-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 broadcast 914 address at this sub-layer. 916 Discontinuities in the value of this counter can occur 917 at re-initialization of the management system, and at 918 other times as indicated by the value of 919 'discontinuity-time'."; 920 reference 921 "RFC 2863: The Interfaces Group MIB - 922 ifHCInBroadcastPkts"; 923 } 925 leaf in-multicast-pkts { 926 type yang:counter64; 927 description 928 "The number of packets, delivered by this sub-layer to a 929 higher (sub-)layer, that were addressed to a multicast 930 address at this sub-layer. For a MAC-layer protocol, 931 this includes both Group and Functional addresses. 933 Discontinuities in the value of this counter can occur 934 at re-initialization of the management system, and at 935 other times as indicated by the value of 936 'discontinuity-time'."; 937 reference 938 "RFC 2863: The Interfaces Group MIB - 939 ifHCInMulticastPkts"; 940 } 942 leaf in-discards { 943 type yang:counter32; 944 description 945 "The number of inbound packets that were chosen to be 946 discarded even though no errors had been detected to 947 prevent their being deliverable to a higher-layer 948 protocol. One possible reason for discarding such a 949 packet could be to free up buffer space. 951 Discontinuities in the value of this counter can occur 952 at re-initialization of the management system, and at 953 other times as indicated by the value of 954 'discontinuity-time'."; 955 reference 956 "RFC 2863: The Interfaces Group MIB - ifInDiscards"; 957 } 959 leaf in-errors { 960 type yang:counter32; 961 description 962 "For packet-oriented interfaces, the number of inbound 963 packets that contained errors preventing them from being 964 deliverable to a higher-layer protocol. For character- 965 oriented or fixed-length interfaces, the number of 966 inbound transmission units that contained errors 967 preventing them from being deliverable to a higher-layer 968 protocol. 970 Discontinuities in the value of this counter can occur 971 at re-initialization of the management system, and at 972 other times as indicated by the value of 973 'discontinuity-time'."; 974 reference 975 "RFC 2863: The Interfaces Group MIB - ifInErrors"; 976 } 978 leaf in-unknown-protos { 979 type yang:counter32; 980 description 981 "For packet-oriented interfaces, the number of packets 982 received via the interface that were discarded because 983 of an unknown or unsupported protocol. For 984 character-oriented or fixed-length interfaces that 985 support protocol multiplexing, the number of 986 transmission units received via the interface that were 987 discarded because of an unknown or unsupported protocol. 988 For any interface that does not support protocol 989 multiplexing, this counter is not present. 991 Discontinuities in the value of this counter can occur 992 at re-initialization of the management system, and at 993 other times as indicated by the value of 994 'discontinuity-time'."; 995 reference 996 "RFC 2863: The Interfaces Group MIB - ifInUnknownProtos"; 997 } 999 leaf out-octets { 1000 type yang:counter64; 1001 description 1002 "The total number of octets transmitted out of the 1003 interface, including framing characters. 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 - ifHCOutOctets"; 1011 } 1013 leaf out-unicast-pkts { 1014 type yang:counter64; 1015 description 1016 "The total number of packets that higher-level protocols 1017 requested be transmitted, and that were not addressed 1018 to a multicast or broadcast address at this sub-layer, 1019 including those 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 - ifHCOutUcastPkts"; 1027 } 1029 leaf out-broadcast-pkts { 1030 type yang:counter64; 1031 description 1032 "The total number of packets that higher-level protocols 1033 requested be transmitted, and that were addressed to a 1034 broadcast address at this sub-layer, including those 1035 that were discarded or not sent. 1037 Discontinuities in the value of this counter can occur 1038 at re-initialization of the management system, and at 1039 other times as indicated by the value of 1040 'discontinuity-time'."; 1041 reference 1042 "RFC 2863: The Interfaces Group MIB - 1043 ifHCOutBroadcastPkts"; 1044 } 1046 leaf out-multicast-pkts { 1047 type yang:counter64; 1048 description 1049 "The total number of packets that higher-level protocols 1050 requested be transmitted, and that were addressed to a 1051 multicast address at this sub-layer, including those 1052 that were discarded or not sent. For a MAC-layer 1053 protocol, this includes both Group and Functional 1054 addresses. 1056 Discontinuities in the value of this counter can occur 1057 at re-initialization of the management system, and at 1058 other times as indicated by the value of 1059 'discontinuity-time'."; 1060 reference 1061 "RFC 2863: The Interfaces Group MIB - 1062 ifHCOutMulticastPkts"; 1063 } 1065 leaf out-discards { 1066 type yang:counter32; 1067 description 1068 "The number of outbound packets that were chosen to be 1069 discarded even though no errors had been detected to 1070 prevent their being transmitted. One possible reason 1071 for discarding such a packet could be to free up buffer 1072 space. 1074 Discontinuities in the value of this counter can occur 1075 at re-initialization of the management system, and at 1076 other times as indicated by the value of 1077 'discontinuity-time'."; 1078 reference 1079 "RFC 2863: The Interfaces Group MIB - ifOutDiscards"; 1080 } 1082 leaf out-errors { 1083 type yang:counter32; 1084 description 1085 "For packet-oriented interfaces, the number of outbound 1086 packets that could not be transmitted because of errors. 1087 For character-oriented or fixed-length interfaces, the 1088 number of outbound transmission units that could not be 1089 transmitted because of errors. 1091 Discontinuities in the value of this counter can occur 1092 at re-initialization of the management system, and at 1093 other times as indicated by the value of 1094 'discontinuity-time'."; 1095 reference 1096 "RFC 2863: The Interfaces Group MIB - ifOutErrors"; 1097 } 1098 } 1100 } 1101 } 1103 /* 1104 * Legacy typedefs 1105 */ 1107 typedef interface-state-ref { 1108 type leafref { 1109 path "/if:interfaces-state/if:interface/if:name"; 1110 } 1111 status deprecated; 1112 description 1113 "This type is used by data models that need to reference 1114 the operationally present interfaces."; 1115 } 1117 /* 1118 * Legacy operational state data nodes 1119 */ 1121 container interfaces-state { 1122 config false; 1123 status deprecated; 1124 description 1125 "Data nodes for the operational state of interfaces."; 1127 list interface { 1128 key "name"; 1129 status deprecated; 1131 description 1132 "The list of interfaces on the device. 1134 System-controlled interfaces created by the system are 1135 always present in this list, whether they are configured or 1136 not."; 1138 leaf name { 1139 type string; 1140 status deprecated; 1141 description 1142 "The name of the interface. 1144 A server implementation MAY map this leaf to the ifName 1145 MIB object. Such an implementation needs to use some 1146 mechanism to handle the differences in size and characters 1147 allowed between this leaf and ifName. The definition of 1148 such a mechanism is outside the scope of this document."; 1149 reference 1150 "RFC 2863: The Interfaces Group MIB - ifName"; 1151 } 1153 leaf type { 1154 type identityref { 1155 base interface-type; 1156 } 1157 mandatory true; 1158 status deprecated; 1159 description 1160 "The type of the interface."; 1161 reference 1162 "RFC 2863: The Interfaces Group MIB - ifType"; 1163 } 1165 leaf admin-status { 1166 if-feature if-mib; 1167 type enumeration { 1168 enum up { 1169 value 1; 1170 description 1171 "Ready to pass packets."; 1172 } 1173 enum down { 1174 value 2; 1175 description 1176 "Not ready to pass packets and not in some test mode."; 1177 } 1178 enum testing { 1179 value 3; 1180 description 1181 "In some test mode."; 1183 } 1184 } 1185 mandatory true; 1186 status deprecated; 1187 description 1188 "The desired state of the interface. 1190 This leaf has the same read semantics as ifAdminStatus."; 1191 reference 1192 "RFC 2863: The Interfaces Group MIB - ifAdminStatus"; 1193 } 1195 leaf oper-status { 1196 type enumeration { 1197 enum up { 1198 value 1; 1199 description 1200 "Ready to pass packets."; 1201 } 1202 enum down { 1203 value 2; 1204 description 1205 "The interface does not pass any packets."; 1206 } 1207 enum testing { 1208 value 3; 1209 description 1210 "In some test mode. No operational packets can 1211 be passed."; 1212 } 1213 enum unknown { 1214 value 4; 1215 description 1216 "Status cannot be determined for some reason."; 1217 } 1218 enum dormant { 1219 value 5; 1220 description 1221 "Waiting for some external event."; 1222 } 1223 enum not-present { 1224 value 6; 1225 description 1226 "Some component (typically hardware) is missing."; 1227 } 1228 enum lower-layer-down { 1229 value 7; 1230 description 1231 "Down due to state of lower-layer interface(s)."; 1232 } 1233 } 1234 mandatory true; 1235 status deprecated; 1236 description 1237 "The current operational state of the interface. 1239 This leaf has the same semantics as ifOperStatus."; 1240 reference 1241 "RFC 2863: The Interfaces Group MIB - ifOperStatus"; 1242 } 1244 leaf last-change { 1245 type yang:date-and-time; 1246 status deprecated; 1247 description 1248 "The time the interface entered its current operational 1249 state. If the current state was entered prior to the 1250 last re-initialization of the local network management 1251 subsystem, then this node is not present."; 1252 reference 1253 "RFC 2863: The Interfaces Group MIB - ifLastChange"; 1254 } 1256 leaf if-index { 1257 if-feature if-mib; 1258 type int32 { 1259 range "1..2147483647"; 1260 } 1261 mandatory true; 1262 status deprecated; 1263 description 1264 "The ifIndex value for the ifEntry represented by this 1265 interface."; 1266 reference 1267 "RFC 2863: The Interfaces Group MIB - ifIndex"; 1268 } 1270 leaf phys-address { 1271 type yang:phys-address; 1272 status deprecated; 1273 description 1274 "The interface's address at its protocol sub-layer. For 1275 example, for an 802.x interface, this object normally 1276 contains a Media Access Control (MAC) address. The 1277 interface's media-specific modules must define the bit 1278 and byte ordering and the format of the value of this 1279 object. For interfaces that do not have such an address 1280 (e.g., a serial line), this node is not present."; 1281 reference 1282 "RFC 2863: The Interfaces Group MIB - ifPhysAddress"; 1283 } 1285 leaf-list higher-layer-if { 1286 type interface-state-ref; 1287 status deprecated; 1288 description 1289 "A list of references to interfaces layered on top of this 1290 interface."; 1291 reference 1292 "RFC 2863: The Interfaces Group MIB - ifStackTable"; 1293 } 1295 leaf-list lower-layer-if { 1296 type interface-state-ref; 1297 status deprecated; 1298 description 1299 "A list of references to interfaces layered underneath this 1300 interface."; 1301 reference 1302 "RFC 2863: The Interfaces Group MIB - ifStackTable"; 1303 } 1305 leaf speed { 1306 type yang:gauge64; 1307 units "bits/second"; 1308 status deprecated; 1309 description 1310 "An estimate of the interface's current bandwidth in bits 1311 per second. For interfaces that do not vary in 1312 bandwidth or for those where no accurate estimation can 1313 be made, this node should contain the nominal bandwidth. 1314 For interfaces that have no concept of bandwidth, this 1315 node is not present."; 1316 reference 1317 "RFC 2863: The Interfaces Group MIB - 1318 ifSpeed, ifHighSpeed"; 1319 } 1321 container statistics { 1322 status deprecated; 1323 description 1324 "A collection of interface-related statistics objects."; 1326 leaf discontinuity-time { 1327 type yang:date-and-time; 1328 mandatory true; 1329 status deprecated; 1330 description 1331 "The time on the most recent occasion at which any one or 1332 more of this interface's counters suffered a 1333 discontinuity. If no such discontinuities have occurred 1334 since the last re-initialization of the local management 1335 subsystem, then this node contains the time the local 1336 management subsystem re-initialized itself."; 1337 } 1339 leaf in-octets { 1340 type yang:counter64; 1341 status deprecated; 1342 description 1343 "The total number of octets received on the interface, 1344 including framing characters. 1346 Discontinuities in the value of this counter can occur 1347 at re-initialization of the management system, and at 1348 other times as indicated by the value of 1349 'discontinuity-time'."; 1350 reference 1351 "RFC 2863: The Interfaces Group MIB - ifHCInOctets"; 1352 } 1354 leaf in-unicast-pkts { 1355 type yang:counter64; 1356 status deprecated; 1357 description 1358 "The number of packets, delivered by this sub-layer to a 1359 higher (sub-)layer, that were not addressed to a 1360 multicast or broadcast address at this sub-layer. 1362 Discontinuities in the value of this counter can occur 1363 at re-initialization of the management system, and at 1364 other times as indicated by the value of 1365 'discontinuity-time'."; 1366 reference 1367 "RFC 2863: The Interfaces Group MIB - ifHCInUcastPkts"; 1368 } 1370 leaf in-broadcast-pkts { 1371 type yang:counter64; 1372 status deprecated; 1373 description 1374 "The number of packets, delivered by this sub-layer to a 1375 higher (sub-)layer, that were addressed to a broadcast 1376 address at this sub-layer. 1378 Discontinuities in the value of this counter can occur 1379 at re-initialization of the management system, and at 1380 other times as indicated by the value of 1381 'discontinuity-time'."; 1382 reference 1383 "RFC 2863: The Interfaces Group MIB - 1384 ifHCInBroadcastPkts"; 1385 } 1387 leaf in-multicast-pkts { 1388 type yang:counter64; 1389 status deprecated; 1390 description 1391 "The number of packets, delivered by this sub-layer to a 1392 higher (sub-)layer, that were addressed to a multicast 1393 address at this sub-layer. For a MAC-layer protocol, 1394 this includes both Group and Functional addresses. 1396 Discontinuities in the value of this counter can occur 1397 at re-initialization of the management system, and at 1398 other times as indicated by the value of 1399 'discontinuity-time'."; 1400 reference 1401 "RFC 2863: The Interfaces Group MIB - 1402 ifHCInMulticastPkts"; 1403 } 1405 leaf in-discards { 1406 type yang:counter32; 1407 status deprecated; 1408 description 1409 "The number of inbound packets that were chosen to be 1410 discarded even though no errors had been detected to 1411 prevent their being deliverable to a higher-layer 1412 protocol. One possible reason for discarding such a 1413 packet could be to free up buffer space. 1415 Discontinuities in the value of this counter can occur 1416 at re-initialization of the management system, and at 1417 other times as indicated by the value of 1418 'discontinuity-time'."; 1419 reference 1420 "RFC 2863: The Interfaces Group MIB - ifInDiscards"; 1421 } 1422 leaf in-errors { 1423 type yang:counter32; 1424 status deprecated; 1425 description 1426 "For packet-oriented interfaces, the number of inbound 1427 packets that contained errors preventing them from being 1428 deliverable to a higher-layer protocol. For character- 1429 oriented or fixed-length interfaces, the number of 1430 inbound transmission units that contained errors 1431 preventing them from being deliverable to a higher-layer 1432 protocol. 1434 Discontinuities in the value of this counter can occur 1435 at re-initialization of the management system, and at 1436 other times as indicated by the value of 1437 'discontinuity-time'."; 1438 reference 1439 "RFC 2863: The Interfaces Group MIB - ifInErrors"; 1440 } 1442 leaf in-unknown-protos { 1443 type yang:counter32; 1444 status deprecated; 1445 description 1446 "For packet-oriented interfaces, the number of packets 1447 received via the interface that were discarded because 1448 of an unknown or unsupported protocol. For 1449 character-oriented or fixed-length interfaces that 1450 support protocol multiplexing, the number of 1451 transmission units received via the interface that were 1452 discarded because of an unknown or unsupported protocol. 1453 For any interface that does not support protocol 1454 multiplexing, this counter is not present. 1456 Discontinuities in the value of this counter can occur 1457 at re-initialization of the management system, and at 1458 other times as indicated by the value of 1459 'discontinuity-time'."; 1460 reference 1461 "RFC 2863: The Interfaces Group MIB - ifInUnknownProtos"; 1462 } 1464 leaf out-octets { 1465 type yang:counter64; 1466 status deprecated; 1467 description 1468 "The total number of octets transmitted out of the 1469 interface, including framing characters. 1471 Discontinuities in the value of this counter can occur 1472 at re-initialization of the management system, and at 1473 other times as indicated by the value of 1474 'discontinuity-time'."; 1475 reference 1476 "RFC 2863: The Interfaces Group MIB - ifHCOutOctets"; 1477 } 1479 leaf out-unicast-pkts { 1480 type yang:counter64; 1481 status deprecated; 1482 description 1483 "The total number of packets that higher-level protocols 1484 requested be transmitted, and that were not addressed 1485 to a multicast or broadcast address at this sub-layer, 1486 including those that were discarded or not sent. 1488 Discontinuities in the value of this counter can occur 1489 at re-initialization of the management system, and at 1490 other times as indicated by the value of 1491 'discontinuity-time'."; 1492 reference 1493 "RFC 2863: The Interfaces Group MIB - ifHCOutUcastPkts"; 1494 } 1496 leaf out-broadcast-pkts { 1497 type yang:counter64; 1498 status deprecated; 1499 description 1500 "The total number of packets that higher-level protocols 1501 requested be transmitted, and that were addressed to a 1502 broadcast address at this sub-layer, including those 1503 that were discarded or not sent. 1505 Discontinuities in the value of this counter can occur 1506 at re-initialization of the management system, and at 1507 other times as indicated by the value of 1508 'discontinuity-time'."; 1509 reference 1510 "RFC 2863: The Interfaces Group MIB - 1511 ifHCOutBroadcastPkts"; 1512 } 1514 leaf out-multicast-pkts { 1515 type yang:counter64; 1516 status deprecated; 1517 description 1518 "The total number of packets that higher-level protocols 1519 requested be transmitted, and that were addressed to a 1520 multicast address at this sub-layer, including those 1521 that were discarded or not sent. For a MAC-layer 1522 protocol, this includes both Group and Functional 1523 addresses. 1525 Discontinuities in the value of this counter can occur 1526 at re-initialization of the management system, and at 1527 other times as indicated by the value of 1528 'discontinuity-time'."; 1529 reference 1530 "RFC 2863: The Interfaces Group MIB - 1531 ifHCOutMulticastPkts"; 1532 } 1534 leaf out-discards { 1535 type yang:counter32; 1536 status deprecated; 1537 description 1538 "The number of outbound packets that were chosen to be 1539 discarded even though no errors had been detected to 1540 prevent their being transmitted. One possible reason 1541 for discarding such a packet could be to free up buffer 1542 space. 1544 Discontinuities in the value of this counter can occur 1545 at re-initialization of the management system, and at 1546 other times as indicated by the value of 1547 'discontinuity-time'."; 1548 reference 1549 "RFC 2863: The Interfaces Group MIB - ifOutDiscards"; 1550 } 1552 leaf out-errors { 1553 type yang:counter32; 1554 status deprecated; 1555 description 1556 "For packet-oriented interfaces, the number of outbound 1557 packets that could not be transmitted because of errors. 1558 For character-oriented or fixed-length interfaces, the 1559 number of outbound transmission units that could not be 1560 transmitted because of errors. 1562 Discontinuities in the value of this counter can occur 1563 at re-initialization of the management system, and at 1564 other times as indicated by the value of 1565 'discontinuity-time'."; 1566 reference 1567 "RFC 2863: The Interfaces Group MIB - ifOutErrors"; 1568 } 1569 } 1570 } 1571 } 1572 } 1574 1576 6. IANA Considerations 1578 This document registers a URI in the "IETF XML Registry" [RFC3688]. 1579 Following the format in RFC 3688, the following registration has been 1580 made. 1582 URI: urn:ietf:params:xml:ns:yang:ietf-interfaces 1584 Registrant Contact: The IESG. 1586 XML: N/A, the requested URI is an XML namespace. 1588 This document registers a YANG module in the "YANG Module Names" 1589 registry [RFC6020]. 1591 name: ietf-interfaces 1592 namespace: urn:ietf:params:xml:ns:yang:ietf-interfaces 1593 prefix: if 1594 reference: RFC XXXX 1596 7. Security Considerations 1598 The YANG module defined in this memo is designed to be accessed via 1599 the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the 1600 secure transport layer and the mandatory-to-implement secure 1601 transport is SSH [RFC6242]. The NETCONF access control model 1602 [RFC6536] provides the means to restrict access for particular 1603 NETCONF users to a pre-configured subset of all available NETCONF 1604 protocol operations and content. 1606 There are a number of data nodes defined in the YANG module which are 1607 writable/creatable/deletable (i.e., config true, which is the 1608 default). These data nodes may be considered sensitive or vulnerable 1609 in some network environments. Write operations (e.g., ) 1610 to these data nodes without proper protection can have a negative 1611 effect on network operations. These are the subtrees and data nodes 1612 and their sensitivity/vulnerability: 1614 /interfaces/interface: This list specifies the configured interfaces 1615 on a device. Unauthorized access to this list could cause the 1616 device to ignore packets it should receive and process. 1618 /interfaces/interface/enabled: This leaf controls whether an 1619 interface is enabled or not. Unauthorized access to this leaf 1620 could cause the device to ignore packets it should receive and 1621 process. 1623 8. Acknowledgments 1625 The author wishes to thank Alexander Clemm, Per Hedeland, Ladislav 1626 Lhotka, and Juergen Schoenwaelder for their helpful comments. 1628 9. References 1630 9.1. Normative References 1632 [I-D.ietf-netmod-revised-datastores] 1633 Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1634 and R. Wilton, "Network Management Datastore 1635 Architecture", draft-ietf-netmod-revised-datastores-03 1636 (work in progress), July 2017. 1638 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1639 Requirement Levels", BCP 14, RFC 2119, 1640 DOI 10.17487/RFC2119, March 1997, . 1643 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 1644 MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, 1645 . 1647 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1648 DOI 10.17487/RFC3688, January 2004, . 1651 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1652 the Network Configuration Protocol (NETCONF)", RFC 6020, 1653 DOI 10.17487/RFC6020, October 2010, . 1656 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1657 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1658 . 1660 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1661 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1662 . 1664 9.2. Informative References 1666 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1667 and A. Bierman, Ed., "Network Configuration Protocol 1668 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1669 . 1671 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1672 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1673 . 1675 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1676 Protocol (NETCONF) Access Control Model", RFC 6536, 1677 DOI 10.17487/RFC6536, March 2012, . 1680 [RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", 1681 RFC 7224, DOI 10.17487/RFC7224, May 2014, 1682 . 1684 Appendix A. Example: Ethernet Interface Module 1686 This section gives a simple example of how an Ethernet interface 1687 module could be defined. It demonstrates how media-specific 1688 configuration parameters can be conditionally augmented to the 1689 generic interface list. It also shows how operational state 1690 parameters can be conditionally augmented to the operational 1691 interface list. The example is not intended as a complete module for 1692 Ethernet configuration. 1694 module ex-ethernet { 1695 namespace "http://example.com/ethernet"; 1696 prefix "eth"; 1698 import ietf-interfaces { 1699 prefix if; 1700 } 1701 import iana-if-type { 1702 prefix ianaift; 1703 } 1705 // configuration and state parameters for Ethernet interfaces 1706 augment "/if:interfaces/if:interface" { 1707 when "if:type = 'ianaift:ethernetCsmacd'"; 1708 container ethernet { 1709 choice transmission-params { 1710 case auto { 1711 leaf auto-negotiate { 1712 type empty; 1713 } 1714 } 1715 case manual { 1716 leaf duplex { 1717 type enumeration { 1718 enum "half"; 1719 enum "full"; 1720 } 1721 } 1723 leaf speed { 1724 type enumeration { 1725 enum "10Mb"; 1726 enum "100Mb"; 1727 enum "1Gb"; 1728 enum "10Gb"; 1729 } 1730 } 1731 } 1732 } 1733 leaf duplexx { 1734 type enumeration { 1735 enum "half"; 1736 enum "full"; 1737 } 1738 config false; 1739 } 1740 // other Ethernet-specific params... 1741 } 1742 } 1743 } 1745 Appendix B. Example: Ethernet Bonding Interface Module 1747 This section gives an example of how interface layering can be 1748 defined. An Ethernet bonding interface that bonds several Ethernet 1749 interfaces into one logical interface is defined. 1751 module ex-ethernet-bonding { 1752 namespace "http://example.com/ethernet-bonding"; 1753 prefix "bond"; 1755 import ietf-interfaces { 1756 prefix if; 1757 } 1758 import iana-if-type { 1759 prefix ianaift; 1760 } 1762 augment "/if:interfaces/if:interface" { 1763 when "if:type = 'ianaift:ieee8023adLag'"; 1765 leaf-list slave-if { 1766 type if:interface-ref; 1767 must "/if:interfaces/if:interface[if:name = current()]" 1768 + "/if:type = 'ianaift:ethernetCsmacd'" { 1769 description 1770 "The type of a slave interface must be 'ethernetCsmacd'."; 1771 } 1772 } 1773 leaf bonding-mode { 1774 type enumeration { 1775 enum round-robin; 1776 enum active-backup; 1777 enum broadcast; 1778 } 1779 } 1780 // other bonding config params, failover times, etc. 1781 } 1782 } 1784 Appendix C. Example: VLAN Interface Module 1786 This section gives an example of how a VLAN interface module can be 1787 defined. 1789 module ex-vlan { 1790 namespace "http://example.com/vlan"; 1791 prefix "vlan"; 1793 import ietf-interfaces { 1794 prefix if; 1795 } 1796 import iana-if-type { 1797 prefix ianaift; 1798 } 1800 augment "/if:interfaces/if:interface" { 1801 when "if:type = 'ianaift:ethernetCsmacd' or 1802 if:type = 'ianaift:ieee8023adLag'"; 1803 leaf vlan-tagging { 1804 type boolean; 1805 default false; 1806 } 1807 } 1809 augment "/if:interfaces/if:interface" { 1810 when "if:type = 'ianaift:l2vlan'"; 1812 leaf base-interface { 1813 type if:interface-ref; 1814 must "/if:interfaces/if:interface[if:name = current()]" 1815 + "/vlan:vlan-tagging = 'true'" { 1816 description 1817 "The base interface must have VLAN tagging enabled."; 1818 } 1819 } 1820 leaf vlan-id { 1821 type uint16 { 1822 range "1..4094"; 1823 } 1824 must "../base-interface" { 1825 description 1826 "If a vlan-id is defined, a base-interface must 1827 be specified."; 1828 } 1829 } 1830 } 1831 } 1833 Appendix D. Example: NETCONF Reply 1835 This section gives an example of a reply to the NETCONF 1836 request for for a device that implements the example data 1837 models above. 1839 1842 1843 1848 1849 eth0 1850 ianaift:ethernetCsmacd 1851 false 1852 1854 1855 eth1 1856 ianaift:ethernetCsmacd 1857 true 1858 true 1859 1861 1862 eth1.10 1863 ianaift:l2vlan 1864 true 1865 eth1 1866 10 1867 1869 1870 lo1 1871 ianaift:softwareLoopback 1872 true 1873 1875 1876 1877 1879 Appendix E. Example: NETCONF Reply 1881 This section gives an example of a reply to the NETCONF 1882 request for for a device that implements the example 1883 data models above. 1885 1888 1889 1895 1896 eth0 1897 ianaift:ethernetCsmacd 1898 false 1899 down 1900 down 1901 2 1902 00:01:02:03:04:05 1903 1904 1905 2013-04-01T03:00:00+00:00 1906 1907 1908 1909 1911 1912 eth1 1913 ianaift:ethernetCsmacd 1914 true 1915 up 1916 up 1917 7 1918 00:01:02:03:04:06 1919 eth1.10 1920 1921 1922 2013-04-01T03:00:00+00:00 1923 1924 1925 1926 true 1928 1930 1931 eth1.10 1932 ianaift:l2vlan 1933 true 1934 up 1935 up 1936 9 1937 eth1 1938 1939 1940 2013-04-01T03:00:00+00:00 1941 1942 1943 1944 eth1 1945 10 1946 1948 1949 1950 eth2 1951 ianaift:ethernetCsmacd 1952 down 1953 down 1954 8 1955 00:01:02:03:04:07 1956 1957 1958 2013-04-01T03:00:00+00:00 1959 1960 1961 1962 1964 1965 lo1 1966 ianaift:softwareLoopback 1967 true 1968 up 1969 up 1970 1 1971 1972 1973 2013-04-01T03:00:00+00:00 1974 1975 1977 1978 1980 1981 1982 1984 Appendix F. Examples: Interface Naming Schemes 1986 This section gives examples of some implementation strategies. 1988 The examples make use of the example data model "ex-vlan" (see 1989 Appendix C) to show how user-controlled interfaces can be configured. 1991 F.1. Router with Restricted Interface Names 1993 In this example, a router has support for 4 line cards, each with 8 1994 ports. The slots for the cards are physically numbered from 0 to 3, 1995 and the ports on each card from 0 to 7. Each card has Fast Ethernet 1996 or Gigabit Ethernet ports. 1998 The device-specific names for these physical interfaces are 1999 "fastethernet-N/M" or "gigabitethernet-N/M". 2001 The name of a VLAN interface is restricted to the form 2002 ".". 2004 It is assumed that the operator is aware of this naming scheme. The 2005 implementation auto-initializes the value for "type" based on the 2006 interface name. 2008 The NETCONF server does not advertise the "arbitrary-names" feature 2009 in the message. 2011 An operator can configure a physical interface by sending an 2012 containing: 2014 2015 fastethernet-1/0 2016 2018 When the server processes this request, it will set the leaf "type" 2019 to "ianaift:ethernetCsmacd". Thus, if the client performs a 2020 right after the above, it will get: 2022 2023 fastethernet-1/0 2024 ianaift:ethernetCsmacd 2025 2027 The client can configure a VLAN interface by sending an 2028 containing: 2030 2031 fastethernet-1/0.10005 2032 ianaift:l2vlan 2033 fastethernet-1/0 2034 5 2035 2037 If the client tries to change the type of the physical interface with 2038 an containing: 2040 2041 fastethernet-1/0 2042 ianaift:tunnel 2043 2045 then the server will reply with an "invalid-value" error, since the 2046 new type does not match the name. 2048 F.2. Router with Arbitrary Interface Names 2050 In this example, a router has support for 4 line cards, each with 8 2051 ports. The slots for the cards are physically numbered from 0 to 3, 2052 and the ports on each card from 0 to 7. Each card has Fast Ethernet 2053 or Gigabit Ethernet ports. 2055 The device-specific names for these physical interfaces are 2056 "fastethernet-N/M" or "gigabitethernet-N/M". 2058 The implementation does not restrict the user-controlled interface 2059 names. This allows an operator to more easily apply the interface 2060 configuration to a different interface. However, the additional 2061 level of indirection also makes it a bit more complex to map 2062 interface names found in other protocols to configuration entries. 2064 The NETCONF server advertises the "arbitrary-names" feature in the 2065 message. 2067 Physical interfaces are configured as in Appendix F.1. 2069 An operator can configure a VLAN interface by sending an 2070 containing: 2072 2073 acme-interface 2074 ianaift:l2vlan 2075 fastethernet-1/0 2076 5 2077 2079 If necessary, the operator can move the configuration named 2080 "acme-interface" over to a different physical interface with an 2081 containing: 2083 2084 acme-interface 2085 fastethernet-1/1 2086 2088 F.3. Ethernet Switch with Restricted Interface Names 2090 In this example, an Ethernet switch has a number of ports, each 2091 identified by a simple port number. 2093 The device-specific names for the physical interfaces are numbers 2094 that match the physical port number. 2096 An operator can configure a physical interface by sending an 2097 containing: 2099 2100 6 2101 2103 When the server processes this request, it will set the leaf "type" 2104 to "ianaift:ethernetCsmacd". Thus, if the client performs a 2105 right after the above, it will get: 2107 2108 6 2109 ianaift:ethernetCsmacd 2110 2112 F.4. Generic Host with Restricted Interface Names 2114 In this example, a generic host has interfaces named by the kernel. 2115 The system identifies the physical interface by the name assigned by 2116 the operating system to the interface. 2118 The name of a VLAN interface is restricted to the form 2119 ":". 2121 The NETCONF server does not advertise the "arbitrary-names" feature 2122 in the message. 2124 An operator can configure an interface by sending an 2125 containing: 2127 2128 eth8 2129 2131 When the server processes this request, it will set the leaf "type" 2132 to "ianaift:ethernetCsmacd". Thus, if the client performs a 2133 right after the above, it will get: 2135 2136 eth8 2137 ianaift:ethernetCsmacd 2138 2140 The client can configure a VLAN interface by sending an 2141 containing: 2143 2144 eth8:5 2145 ianaift:l2vlan 2146 eth8 2147 5 2148 2150 F.5. Generic Host with Arbitrary Interface Names 2152 In this example, a generic host has interfaces named by the kernel. 2153 The system identifies the physical interface by the name assigned by 2154 the operating system to the interface. 2156 The implementation does not restrict the user-controlled interface 2157 names. This allows an operator to more easily apply the interface 2158 configuration to a different interface. However, the additional 2159 level of indirection also makes it a bit more complex to map 2160 interface names found in other protocols to configuration entries. 2162 The NETCONF server advertises the "arbitrary-names" feature in the 2163 message. 2165 Physical interfaces are configured as in Appendix F.4. 2167 An operator can configure a VLAN interface by sending an 2168 containing: 2170 2171 acme-interface 2172 ianaift:l2vlan 2173 eth8 2174 5 2175 2177 If necessary, the operator can move the configuration named 2178 "acme-interface" over to a different physical interface with an 2179 containing: 2181 2182 acme-interface 2183 eth3 2184 2186 Author's Address 2188 Martin Bjorklund 2189 Tail-f Systems 2191 Email: mbj@tail-f.com