idnits 2.17.1 draft-bjorklund-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 250 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 (August 21, 2017) is 2440 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) August 21, 2017 5 Intended status: Standards Track 6 Expires: February 22, 2018 8 A YANG Data Model for Interface Management 9 draft-bjorklund-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 February 22, 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 . . . . . . . . . . . . . . . . . . . 35 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 . . . . . . . . . . . 39 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 running 134 configuration datastore and the removal of the interface is 135 controlled by removing explicit interface configuration from the 136 running configuration datastore. Examples are VLAN interfaces 137 configured on a 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 datastore 151 o running configuration datastore 153 o startup configuration datastore 155 The following terms are defined in [RFC7950] and are not redefined 156 here: 158 o augment 160 o data model 162 o data node 164 o presence container 166 1.3. Tree Diagrams 168 A simplified graphical representation of the data model is used in 169 this document. The meaning of the symbols in these diagrams is as 170 follows: 172 o Brackets "[" and "]" enclose list keys. 174 o Abbreviations before data node names: "rw" means configuration 175 (read-write), and "ro" means state data (read-only). 177 o Symbols after data node names: "?" means an optional node, "!" 178 means a presence container, and "*" denotes either a list or a 179 leaf-list. 181 o Parentheses enclose choice and case nodes, and case nodes are also 182 marked with a colon (":"). 184 o Ellipsis ("...") stands for contents of subtrees that are not 185 shown. 187 2. Objectives 189 This section describes some of the design objectives for the model 190 presented in Section 5. 192 o It is recognized that existing implementations will have to map 193 the interface data model defined in this memo to their proprietary 194 native data model. To facilitate such mappings, the data model 195 should be simple. 197 o The data model should be suitable for new implementations to use 198 as is, without requiring a mapping to a different native model. 200 o References to interfaces should be as simple as possible, 201 preferably by using a single leafref. 203 o The mapping to ifIndex [RFC2863] used by the Simple Network 204 Management Protocol (SNMP) to identify interfaces must be clear. 206 o The model must support interface layering: both (1) simple 207 layering, where one interface is layered on top of exactly one 208 other interface, and (2) more complex scenarios, where one 209 interface results from the aggregation of N other interfaces or 210 when N interfaces are multiplexed over one other interface. 212 o The data model should support the pre-provisioning of interface 213 configuration, i.e., it should be possible to configure an 214 interface whose physical interface hardware is not present on the 215 device. It is recommended that devices that support dynamic 216 addition and removal of physical interfaces also support pre- 217 provisioning. 219 o The data model should support physical interfaces as well as 220 logical interfaces. 222 o The data model should include read-only counters in order to 223 gather statistics for sent and received octets and packets, 224 received packets with errors, and packets that could not be sent 225 due to errors. 227 3. Interfaces Data Model 229 This document defines the YANG module "ietf-interfaces", which has 230 the following structure, excluding the deprecated "/interfaces-state" 231 subtree: 233 module: ietf-interfaces 234 +--rw interfaces 235 +--rw interface* [name] 236 +--rw name string 237 +--rw description? string 238 +--rw type identityref 239 +--rw enabled? boolean 240 +--rw link-up-down-trap-enable? enumeration {if-mib}? 241 +--ro admin-status enumeration {if-mib}? 242 +--ro oper-status enumeration 243 +--ro last-change? yang:date-and-time 244 +--ro if-index int32 {if-mib}? 245 +--ro phys-address? yang:phys-address 246 +--ro higher-layer-if* interface-ref 247 +--ro lower-layer-if* interface-ref 248 +--ro speed? yang:gauge64 249 +--ro statistics 250 +--ro discontinuity-time yang:date-and-time 251 +--ro in-octets? yang:counter64 252 +--ro in-unicast-pkts? yang:counter64 253 +--ro in-broadcast-pkts? yang:counter64 254 +--ro in-multicast-pkts? yang:counter64 255 +--ro in-discards? yang:counter32 256 +--ro in-errors? yang:counter32 257 +--ro in-unknown-protos? yang:counter32 258 +--ro out-octets? yang:counter64 259 +--ro out-unicast-pkts? yang:counter64 260 +--ro out-broadcast-pkts? yang:counter64 261 +--ro out-multicast-pkts? yang:counter64 262 +--ro out-discards? yang:counter32 263 +--ro out-errors? yang:counter32 265 3.1. The Interface List 267 The data model for interfaces presented in this document uses a flat 268 list of interfaces ("/interfaces/interface"). Each interface in the 269 list is identified by its name. Furthermore, each interface has a 270 mandatory "type" leaf. 272 The "iana-if-type" module [RFC7224] defines YANG identities for the 273 interface types in the IANA-maintained "ifType definitions" registry. 275 It is expected that interface-type-specific data models augment the 276 interface list and possibly use the "type" leaf to make the 277 augmentation conditional. 279 As an example of such an interface-type-specific augmentation, 280 consider this YANG snippet. For a more complete example, see 281 Appendix A. 283 import interfaces { 284 prefix "if"; 285 } 286 import iana-if-type { 287 prefix ianaift; 288 } 290 augment "/if:interfaces/if:interface" { 291 when "if:type = 'ianaift:ethernetCsmacd'"; 293 container ethernet { 294 leaf duplex { 295 ... 296 } 297 } 298 } 300 For system-controlled interfaces, the "name" is the device-specific 301 name of the interface. 303 If the device supports arbitrarily named user-controlled interfaces, 304 then the server will advertise the "arbitrary-names" feature. If the 305 server does not advertise this feature, the names of user-controlled 306 interfaces MUST match the device's naming scheme. How a client can 307 learn the naming scheme of such devices is outside the scope of this 308 document. See Appendix F.1 and Appendix F.2 for examples. 310 When a system-controlled interface is created in the operational 311 state datastore by the system, the system tries to apply the 312 interface configuration in the intended configuration datastore with 313 the same name as the new interface. If no such interface 314 configuration is found, or if the configured type does not match the 315 real interface type, the system creates the interface without 316 applying explicit configuration. 318 When a user-controlled interface is created, the configuration 319 determines the name of the interface. 321 Depending on the operating system and the physical attachment point 322 to which a network interface may be attached or removed, it may be 323 impossible for an implementation to provide predictable and 324 consistent names for system-controlled interfaces across insertion/ 325 removal cycles as well as in anticipation of initial insertion. The 326 ability to provide configurations for such interfaces is therefore 327 dependent on the implementation and cannot be assumed in all cases. 329 3.2. Interface References 331 An interface is identified by its name, which is unique within the 332 server. This property is captured in the "interface-ref" and 333 typedef, which other YANG modules SHOULD use when they need to 334 reference an interface. 336 3.3. Interface Layering 338 There is no generic mechanism for how an interface is configured to 339 be layered on top of some other interface. It is expected that 340 interface-type-specific models define their own data nodes for 341 interface layering by using "interface-ref" types to reference lower 342 layers. 344 Below is an example of a model with such nodes. For a more complete 345 example, see Appendix B. 347 import interfaces { 348 prefix "if"; 349 } 350 import iana-if-type { 351 prefix ianaift; 352 } 354 augment "/if:interfaces/if:interface" { 355 when "if:type = 'ianaift:ieee8023adLag'"; 357 leaf-list slave-if { 358 type if:interface-ref; 359 must "/if:interfaces/if:interface[if:name = current()]" 360 + "/if:type = 'ianaift:ethernetCsmacd'" { 361 description 362 "The type of a slave interface must be 363 'ethernetCsmacd'."; 364 } 365 } 366 // other bonding config params, failover times, etc. 367 } 369 While the interface layering is configured in interface-type-specific 370 models, two generic state data leaf-lists, "higher-layer-if" and 371 "lower-layer-if", represent a read-only view of the interface 372 layering hierarchy. 374 4. Relationship to the IF-MIB 376 If the device implements the IF-MIB [RFC2863], each entry in the 377 "/interfaces/interface" list in the operational state datastore is 378 typically mapped to one ifEntry. The "if-index" leaf MUST contain 379 the value of the corresponding ifEntry's ifIndex. 381 In most cases, the "name" of an "/interfaces/interface" entry is 382 mapped to ifName. The IF-MIB allows two different ifEntries to have 383 the same ifName. Devices that support this feature and also support 384 the data model defined in this document cannot have a 1-1 mapping 385 between the "name" leaf and ifName. 387 The configured "description" of an "interface" has traditionally been 388 mapped to ifAlias in some implementations. This document allows this 389 mapping, but implementers should be aware of the differences in the 390 value space and persistence for these objects. See the YANG module 391 definition of the leaf "description" in Section 5 for details. 393 The IF-MIB also defines the writable object ifPromiscuousMode. Since 394 this object typically is not implemented as a configuration object by 395 SNMP agents, it is not mapped to the "ietf-interfaces" module. 397 The ifMtu object from the IF-MIB is not mapped to the 398 "ietf-interfaces" module. It is expected that interface-type- 399 specific YANG modules provide interface-type-specific MTU leafs by 400 augmenting the "ietf-interfaces" model. 402 There are a number of counters in the IF-MIB that exist in two 403 versions: one with 32 bits and one with 64 bits. The 64-bit versions 404 were added to support high-speed interfaces with a data rate greater 405 than 20,000,000 bits/second. Today's implementations generally 406 support such high-speed interfaces, and hence only 64-bit counters 407 are provided in this data model. Note that NETCONF and SNMP may 408 differ in the time granularity in which they provide access to the 409 counters. For example, it is common that SNMP implementations cache 410 counter values for some time. 412 The objects ifDescr and ifConnectorPresent from the IF-MIB are not 413 mapped to the "ietf-interfaces" module. 415 The following tables list the YANG data nodes with corresponding 416 objects in the IF-MIB. 418 +--------------------------------------+----------------------------+ 419 | YANG data node in | IF-MIB object | 420 | /interfaces/interface | | 421 +--------------------------------------+----------------------------+ 422 | name | ifName | 423 | type | ifType | 424 | description | ifAlias | 425 | admin-status | ifAdminStatus | 426 | oper-status | ifOperStatus | 427 | last-change | ifLastChange | 428 | if-index | ifIndex | 429 | link-up-down-trap-enable | ifLinkUpDownTrapEnable | 430 | phys-address | ifPhysAddress | 431 | higher-layer-if and lower-layer-if | ifStackTable | 432 | speed | ifSpeed and ifHighSpeed | 433 | discontinuity-time | ifCounterDiscontinuityTime | 434 | in-octets | ifHCInOctets | 435 | in-unicast-pkts | ifHCInUcastPkts | 436 | in-broadcast-pkts | ifHCInBroadcastPkts | 437 | in-multicast-pkts | ifHCInMulticastPkts | 438 | in-discards | ifInDiscards | 439 | in-errors | ifInErrors | 440 | in-unknown-protos | ifInUnknownProtos | 441 | out-octets | ifHCOutOctets | 442 | out-unicast-pkts | ifHCOutUcastPkts | 443 | out-broadcast-pkts | ifHCOutBroadcastPkts | 444 | out-multicast-pkts | ifHCOutMulticastPkts | 445 | out-discards | ifOutDiscards | 446 | out-errors | ifOutErrors | 447 +--------------------------------------+----------------------------+ 449 YANG Data Nodes and Related IF-MIB Objects 451 5. Interfaces YANG Module 453 This YANG module imports typedefs from [RFC6991]. 455 file "ietf-interfaces@2017-08-14.yang" 457 module ietf-interfaces { 458 yang-version 1.1; 459 namespace "urn:ietf:params:xml:ns:yang:ietf-interfaces"; 460 prefix if; 462 import ietf-yang-types { 463 prefix yang; 464 } 465 organization 466 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 468 contact 469 "WG Web: 470 WG List: 472 Editor: Martin Bjorklund 473 "; 475 description 476 "This module contains a collection of YANG definitions for 477 managing network interfaces. 479 Copyright (c) 2017 IETF Trust and the persons identified as 480 authors of the code. All rights reserved. 482 Redistribution and use in source and binary forms, with or 483 without modification, is permitted pursuant to, and subject 484 to the license terms contained in, the Simplified BSD License 485 set forth in Section 4.c of the IETF Trust's Legal Provisions 486 Relating to IETF Documents 487 (http://trustee.ietf.org/license-info). 489 This version of this YANG module is part of RFC XXXX; see 490 the RFC itself for full legal notices."; 492 revision 2017-08-17 { 493 description 494 "Updated to support NMDA."; 495 reference 496 "RFC XXXX: A YANG Data Model for Interface Management"; 497 } 499 revision 2014-05-08 { 500 description 501 "Initial revision."; 502 reference 503 "RFC 7223: A YANG Data Model for Interface Management"; 504 } 506 /* 507 * Typedefs 508 */ 510 typedef interface-ref { 511 type leafref { 512 path "/if:interfaces/if:interface/if:name"; 514 } 515 description 516 "This type is used by data models that need to reference 517 interfaces."; 518 } 520 /* 521 * Identities 522 */ 524 identity interface-type { 525 description 526 "Base identity from which specific interface types are 527 derived."; 528 } 530 /* 531 * Features 532 */ 534 feature arbitrary-names { 535 description 536 "This feature indicates that the device allows user-controlled 537 interfaces to be named arbitrarily."; 538 } 539 feature pre-provisioning { 540 description 541 "This feature indicates that the device supports 542 pre-provisioning of interface configuration, i.e., it is 543 possible to configure an interface whose physical interface 544 hardware is not present on the device."; 545 } 546 feature if-mib { 547 description 548 "This feature indicates that the device implements 549 the IF-MIB."; 550 reference 551 "RFC 2863: The Interfaces Group MIB"; 552 } 554 /* 555 * Data nodes 556 */ 558 container interfaces { 559 description 560 "Interface parameters."; 562 list interface { 563 key "name"; 565 description 566 "The list of interfaces on the device. 568 The operational state of an interface is available in this 569 list in the operational state datastore. If the 570 configuration of a system-controlled interface cannot be 571 used by the system (e.g., the interface hardware present 572 does not match the interface type), then the configuration 573 is not applied to the system-controlled interface shown in 574 the operational state datastore. If the configuration of a 575 user-controlled interface cannot be used by the system, the 576 configured interface is not instantiated in the operational 577 state datastore. 579 System-controlled interfaces created by the system are 580 always present in this list in the operational state 581 datastore, whether they are configured or not."; 583 leaf name { 584 type string; 585 description 586 "The name of the interface. 588 A device MAY restrict the allowed values for this leaf, 589 possibly depending on the type of the interface. 590 For system-controlled interfaces, this leaf is the 591 device-specific name of the interface. 593 If a client tries to create configuration for a 594 system-controlled interface that is not present in the 595 operational state datastore, the server MAY reject 596 the request if the implementation does not support 597 pre-provisioning of interfaces or if the name refers to 598 an interface that can never exist in the system. A 599 NETCONF server MUST reply with an rpc-error with the 600 error-tag 'invalid-value' in this case. 602 If the device supports pre-provisioning of interface 603 configuration, the 'pre-provisioning' feature is 604 advertised. 606 If the device allows arbitrarily named user-controlled 607 interfaces, the 'arbitrary-names' feature is advertised. 609 When a configured user-controlled interface is created by 610 the system, it is instantiated with the same name in the 611 operational state datastore. 613 A server implementation MAY map this leaf to the ifName 614 MIB object. Such an implementation needs to use some 615 mechanism to handle the differences in size and characters 616 allowed between this leaf and ifName. The definition of 617 such a mechanism is outside the scope of this document."; 618 reference 619 "RFC 2863: The Interfaces Group MIB - ifName"; 620 } 622 leaf description { 623 type string; 624 description 625 "A textual description of the interface. 627 A server implementation MAY map this leaf to the ifAlias 628 MIB object. Such an implementation needs to use some 629 mechanism to handle the differences in size and characters 630 allowed between this leaf and ifAlias. The definition of 631 such a mechanism is outside the scope of this document. 633 Since ifAlias is defined to be stored in non-volatile 634 storage, the MIB implementation MUST map ifAlias to the 635 value of 'description' in the persistently stored 636 datastore. 638 Specifically, if the device supports the startup 639 configuration datastore, when ifAlias is read the device 640 MUST return the value of 'description' in the startup 641 configuration datastore, and when it is written, it MUST 642 be written to the running and startup configuration 643 datastores. Note that it is up to the implementation to 644 decide whether to modify this single leaf in the startup 645 configuration datastore or perform an implicit copy from 646 the running configuration datastore to the startup 647 configuration datastore. 649 If the device does not support the startup configuration 650 datastore, ifAlias MUST be mapped to the 'description' 651 leaf in the running configuration datastore."; 652 reference 653 "RFC 2863: The Interfaces Group MIB - ifAlias"; 654 } 656 leaf type { 657 type identityref { 658 base interface-type; 659 } 660 mandatory true; 661 description 662 "The type of the interface. 664 When an interface entry is created, a server MAY 665 initialize the type leaf with a valid value, e.g., if it 666 is possible to derive the type from the name of the 667 interface. 669 If a client tries to set the type of an interface to a 670 value that can never be used by the system, e.g., if the 671 type is not supported or if the type does not match the 672 name of the interface, the server MUST reject the request. 673 A NETCONF server MUST reply with an rpc-error with the 674 error-tag 'invalid-value' in this case."; 675 reference 676 "RFC 2863: The Interfaces Group MIB - ifType"; 677 } 679 leaf enabled { 680 type boolean; 681 default "true"; 682 description 683 "This leaf contains the configured, desired state of the 684 interface. 686 Systems that implement the IF-MIB use the value of this 687 leaf in the running configuration datastore to set 688 IF-MIB.ifAdminStatus to 'up' or 'down' after an ifEntry 689 has been initialized, as described in RFC 2863. 691 Changes in this leaf in the running configuration 692 datastore are reflected in ifAdminStatus, but if 693 ifAdminStatus is changed over SNMP, this leaf is not 694 affected."; 695 reference 696 "RFC 2863: The Interfaces Group MIB - ifAdminStatus"; 697 } 699 leaf link-up-down-trap-enable { 700 if-feature if-mib; 701 type enumeration { 702 enum enabled { 703 value 1; 704 description 705 "The device will generate linkUp/linkDown SNMP 706 notifications for this interface."; 707 } 708 enum disabled { 709 value 2; 710 description 711 "The device will not generate linkUp/linkDown SNMP 712 notifications for this interface."; 713 } 714 } 715 description 716 "Controls whether linkUp/linkDown SNMP notifications 717 should be generated for this interface. 719 If this node is not configured, the value 'enabled' is 720 operationally used by the server for interfaces that do 721 not operate on top of any other interface (i.e., there are 722 no 'lower-layer-if' entries), and 'disabled' otherwise."; 723 reference 724 "RFC 2863: The Interfaces Group MIB - 725 ifLinkUpDownTrapEnable"; 726 } 728 leaf admin-status { 729 if-feature if-mib; 730 type enumeration { 731 enum up { 732 value 1; 733 description 734 "Ready to pass packets."; 735 } 736 enum down { 737 value 2; 738 description 739 "Not ready to pass packets and not in some test mode."; 740 } 741 enum testing { 742 value 3; 743 description 744 "In some test mode."; 745 } 746 } 747 config false; 748 mandatory true; 749 description 750 "The desired state of the interface. 752 This leaf has the same read semantics as ifAdminStatus."; 753 reference 754 "RFC 2863: The Interfaces Group MIB - ifAdminStatus"; 755 } 757 leaf oper-status { 758 type enumeration { 759 enum up { 760 value 1; 761 description 762 "Ready to pass packets."; 763 } 764 enum down { 765 value 2; 766 description 767 "The interface does not pass any packets."; 768 } 769 enum testing { 770 value 3; 771 description 772 "In some test mode. No operational packets can 773 be passed."; 774 } 775 enum unknown { 776 value 4; 777 description 778 "Status cannot be determined for some reason."; 779 } 780 enum dormant { 781 value 5; 782 description 783 "Waiting for some external event."; 784 } 785 enum not-present { 786 value 6; 787 description 788 "Some component (typically hardware) is missing."; 789 } 790 enum lower-layer-down { 791 value 7; 792 description 793 "Down due to state of lower-layer interface(s)."; 794 } 795 } 796 config false; 797 mandatory true; 798 description 799 "The current operational state of the interface. 801 This leaf has the same semantics as ifOperStatus."; 803 reference 804 "RFC 2863: The Interfaces Group MIB - ifOperStatus"; 805 } 807 leaf last-change { 808 type yang:date-and-time; 809 config false; 810 description 811 "The time the interface entered its current operational 812 state. If the current state was entered prior to the 813 last re-initialization of the local network management 814 subsystem, then this node is not present."; 815 reference 816 "RFC 2863: The Interfaces Group MIB - ifLastChange"; 817 } 819 leaf if-index { 820 if-feature if-mib; 821 type int32 { 822 range "1..2147483647"; 823 } 824 config false; 825 mandatory true; 826 description 827 "The ifIndex value for the ifEntry represented by this 828 interface."; 829 reference 830 "RFC 2863: The Interfaces Group MIB - ifIndex"; 831 } 833 leaf phys-address { 834 type yang:phys-address; 835 config false; 836 description 837 "The interface's address at its protocol sub-layer. For 838 example, for an 802.x interface, this object normally 839 contains a Media Access Control (MAC) address. The 840 interface's media-specific modules must define the bit 841 and byte ordering and the format of the value of this 842 object. For interfaces that do not have such an address 843 (e.g., a serial line), this node is not present."; 844 reference 845 "RFC 2863: The Interfaces Group MIB - ifPhysAddress"; 846 } 848 leaf-list higher-layer-if { 849 type interface-ref; 850 config false; 851 description 852 "A list of references to interfaces layered on top of this 853 interface."; 854 reference 855 "RFC 2863: The Interfaces Group MIB - ifStackTable"; 856 } 858 leaf-list lower-layer-if { 859 type interface-ref; 860 config false; 861 description 862 "A list of references to interfaces layered underneath this 863 interface."; 864 reference 865 "RFC 2863: The Interfaces Group MIB - ifStackTable"; 866 } 868 leaf speed { 869 type yang:gauge64; 870 units "bits/second"; 871 config false; 872 description 873 "An estimate of the interface's current bandwidth in bits 874 per second. For interfaces that do not vary in 875 bandwidth or for those where no accurate estimation can 876 be made, this node should contain the nominal bandwidth. 877 For interfaces that have no concept of bandwidth, this 878 node is not present."; 879 reference 880 "RFC 2863: The Interfaces Group MIB - 881 ifSpeed, ifHighSpeed"; 882 } 884 container statistics { 885 config false; 886 description 887 "A collection of interface-related statistics objects."; 889 leaf discontinuity-time { 890 type yang:date-and-time; 891 mandatory true; 892 description 893 "The time on the most recent occasion at which any one or 894 more of this interface's counters suffered a 895 discontinuity. If no such discontinuities have occurred 896 since the last re-initialization of the local management 897 subsystem, then this node contains the time the local 898 management subsystem re-initialized itself."; 900 } 902 leaf in-octets { 903 type yang:counter64; 904 description 905 "The total number of octets received on the interface, 906 including framing characters. 908 Discontinuities in the value of this counter can occur 909 at re-initialization of the management system, and at 910 other times as indicated by the value of 911 'discontinuity-time'."; 912 reference 913 "RFC 2863: The Interfaces Group MIB - ifHCInOctets"; 914 } 916 leaf in-unicast-pkts { 917 type yang:counter64; 918 description 919 "The number of packets, delivered by this sub-layer to a 920 higher (sub-)layer, that were not addressed to a 921 multicast or broadcast address at this sub-layer. 923 Discontinuities in the value of this counter can occur 924 at re-initialization of the management system, and at 925 other times as indicated by the value of 926 'discontinuity-time'."; 927 reference 928 "RFC 2863: The Interfaces Group MIB - ifHCInUcastPkts"; 929 } 931 leaf in-broadcast-pkts { 932 type yang:counter64; 933 description 934 "The number of packets, delivered by this sub-layer to a 935 higher (sub-)layer, that were addressed to a broadcast 936 address at this sub-layer. 938 Discontinuities in the value of this counter can occur 939 at re-initialization of the management system, and at 940 other times as indicated by the value of 941 'discontinuity-time'."; 942 reference 943 "RFC 2863: The Interfaces Group MIB - 944 ifHCInBroadcastPkts"; 945 } 947 leaf in-multicast-pkts { 948 type yang:counter64; 949 description 950 "The number of packets, delivered by this sub-layer to a 951 higher (sub-)layer, that were addressed to a multicast 952 address at this sub-layer. For a MAC-layer protocol, 953 this includes both Group and Functional addresses. 955 Discontinuities in the value of this counter can occur 956 at re-initialization of the management system, and at 957 other times as indicated by the value of 958 'discontinuity-time'."; 959 reference 960 "RFC 2863: The Interfaces Group MIB - 961 ifHCInMulticastPkts"; 962 } 964 leaf in-discards { 965 type yang:counter32; 966 description 967 "The number of inbound packets that were chosen to be 968 discarded even though no errors had been detected to 969 prevent their being deliverable to a higher-layer 970 protocol. One possible reason for discarding such a 971 packet could be to free up buffer space. 973 Discontinuities in the value of this counter can occur 974 at re-initialization of the management system, and at 975 other times as indicated by the value of 976 'discontinuity-time'."; 977 reference 978 "RFC 2863: The Interfaces Group MIB - ifInDiscards"; 979 } 981 leaf in-errors { 982 type yang:counter32; 983 description 984 "For packet-oriented interfaces, the number of inbound 985 packets that contained errors preventing them from being 986 deliverable to a higher-layer protocol. For character- 987 oriented or fixed-length interfaces, the number of 988 inbound transmission units that contained errors 989 preventing them from being deliverable to a higher-layer 990 protocol. 992 Discontinuities in the value of this counter can occur 993 at re-initialization of the management system, and at 994 other times as indicated by the value of 995 'discontinuity-time'."; 997 reference 998 "RFC 2863: The Interfaces Group MIB - ifInErrors"; 999 } 1001 leaf in-unknown-protos { 1002 type yang:counter32; 1003 description 1004 "For packet-oriented interfaces, the number of packets 1005 received via the interface that were discarded because 1006 of an unknown or unsupported protocol. For 1007 character-oriented or fixed-length interfaces that 1008 support protocol multiplexing, the number of 1009 transmission units received via the interface that were 1010 discarded because of an unknown or unsupported protocol. 1011 For any interface that does not support protocol 1012 multiplexing, this counter is not present. 1014 Discontinuities in the value of this counter can occur 1015 at re-initialization of the management system, and at 1016 other times as indicated by the value of 1017 'discontinuity-time'."; 1018 reference 1019 "RFC 2863: The Interfaces Group MIB - ifInUnknownProtos"; 1020 } 1022 leaf out-octets { 1023 type yang:counter64; 1024 description 1025 "The total number of octets transmitted out of the 1026 interface, including framing characters. 1028 Discontinuities in the value of this counter can occur 1029 at re-initialization of the management system, and at 1030 other times as indicated by the value of 1031 'discontinuity-time'."; 1032 reference 1033 "RFC 2863: The Interfaces Group MIB - ifHCOutOctets"; 1034 } 1036 leaf out-unicast-pkts { 1037 type yang:counter64; 1038 description 1039 "The total number of packets that higher-level protocols 1040 requested be transmitted, and that were not addressed 1041 to a multicast or broadcast address at this sub-layer, 1042 including those that were discarded or not sent. 1044 Discontinuities in the value of this counter can occur 1045 at re-initialization of the management system, and at 1046 other times as indicated by the value of 1047 'discontinuity-time'."; 1048 reference 1049 "RFC 2863: The Interfaces Group MIB - ifHCOutUcastPkts"; 1050 } 1052 leaf out-broadcast-pkts { 1053 type yang:counter64; 1054 description 1055 "The total number of packets that higher-level protocols 1056 requested be transmitted, and that were addressed to a 1057 broadcast address at this sub-layer, including those 1058 that were discarded or not sent. 1060 Discontinuities in the value of this counter can occur 1061 at re-initialization of the management system, and at 1062 other times as indicated by the value of 1063 'discontinuity-time'."; 1064 reference 1065 "RFC 2863: The Interfaces Group MIB - 1066 ifHCOutBroadcastPkts"; 1067 } 1069 leaf out-multicast-pkts { 1070 type yang:counter64; 1071 description 1072 "The total number of packets that higher-level protocols 1073 requested be transmitted, and that were addressed to a 1074 multicast address at this sub-layer, including those 1075 that were discarded or not sent. For a MAC-layer 1076 protocol, this includes both Group and Functional 1077 addresses. 1079 Discontinuities in the value of this counter can occur 1080 at re-initialization of the management system, and at 1081 other times as indicated by the value of 1082 'discontinuity-time'."; 1083 reference 1084 "RFC 2863: The Interfaces Group MIB - 1085 ifHCOutMulticastPkts"; 1086 } 1088 leaf out-discards { 1089 type yang:counter32; 1090 description 1091 "The number of outbound packets that were chosen to be 1092 discarded even though no errors had been detected to 1093 prevent their being transmitted. One possible reason 1094 for discarding such a packet could be to free up buffer 1095 space. 1097 Discontinuities in the value of this counter can occur 1098 at re-initialization of the management system, and at 1099 other times as indicated by the value of 1100 'discontinuity-time'."; 1101 reference 1102 "RFC 2863: The Interfaces Group MIB - ifOutDiscards"; 1103 } 1105 leaf out-errors { 1106 type yang:counter32; 1107 description 1108 "For packet-oriented interfaces, the number of outbound 1109 packets that could not be transmitted because of errors. 1110 For character-oriented or fixed-length interfaces, the 1111 number of outbound transmission units that could not be 1112 transmitted because of errors. 1114 Discontinuities in the value of this counter can occur 1115 at re-initialization of the management system, and at 1116 other times as indicated by the value of 1117 'discontinuity-time'."; 1118 reference 1119 "RFC 2863: The Interfaces Group MIB - ifOutErrors"; 1120 } 1121 } 1123 } 1124 } 1126 /* 1127 * Legacy typedefs 1128 */ 1130 typedef interface-state-ref { 1131 type leafref { 1132 path "/if:interfaces-state/if:interface/if:name"; 1133 } 1134 status deprecated; 1135 description 1136 "This type is used by data models that need to reference 1137 the operationally present interfaces."; 1138 } 1139 /* 1140 * Legacy operational state data nodes 1141 */ 1143 container interfaces-state { 1144 config false; 1145 status deprecated; 1146 description 1147 "Data nodes for the operational state of interfaces."; 1149 list interface { 1150 key "name"; 1151 status deprecated; 1153 description 1154 "The list of interfaces on the device. 1156 System-controlled interfaces created by the system are 1157 always present in this list, whether they are configured or 1158 not."; 1160 leaf name { 1161 type string; 1162 status deprecated; 1163 description 1164 "The name of the interface. 1166 A server implementation MAY map this leaf to the ifName 1167 MIB object. Such an implementation needs to use some 1168 mechanism to handle the differences in size and characters 1169 allowed between this leaf and ifName. The definition of 1170 such a mechanism is outside the scope of this document."; 1171 reference 1172 "RFC 2863: The Interfaces Group MIB - ifName"; 1173 } 1175 leaf type { 1176 type identityref { 1177 base interface-type; 1178 } 1179 mandatory true; 1180 status deprecated; 1181 description 1182 "The type of the interface."; 1183 reference 1184 "RFC 2863: The Interfaces Group MIB - ifType"; 1185 } 1186 leaf admin-status { 1187 if-feature if-mib; 1188 type enumeration { 1189 enum up { 1190 value 1; 1191 description 1192 "Ready to pass packets."; 1193 } 1194 enum down { 1195 value 2; 1196 description 1197 "Not ready to pass packets and not in some test mode."; 1198 } 1199 enum testing { 1200 value 3; 1201 description 1202 "In some test mode."; 1203 } 1204 } 1205 mandatory true; 1206 status deprecated; 1207 description 1208 "The desired state of the interface. 1210 This leaf has the same read semantics as ifAdminStatus."; 1211 reference 1212 "RFC 2863: The Interfaces Group MIB - ifAdminStatus"; 1213 } 1215 leaf oper-status { 1216 type enumeration { 1217 enum up { 1218 value 1; 1219 description 1220 "Ready to pass packets."; 1221 } 1222 enum down { 1223 value 2; 1224 description 1225 "The interface does not pass any packets."; 1226 } 1227 enum testing { 1228 value 3; 1229 description 1230 "In some test mode. No operational packets can 1231 be passed."; 1232 } 1233 enum unknown { 1234 value 4; 1235 description 1236 "Status cannot be determined for some reason."; 1237 } 1238 enum dormant { 1239 value 5; 1240 description 1241 "Waiting for some external event."; 1242 } 1243 enum not-present { 1244 value 6; 1245 description 1246 "Some component (typically hardware) is missing."; 1247 } 1248 enum lower-layer-down { 1249 value 7; 1250 description 1251 "Down due to state of lower-layer interface(s)."; 1252 } 1253 } 1254 mandatory true; 1255 status deprecated; 1256 description 1257 "The current operational state of the interface. 1259 This leaf has the same semantics as ifOperStatus."; 1260 reference 1261 "RFC 2863: The Interfaces Group MIB - ifOperStatus"; 1262 } 1264 leaf last-change { 1265 type yang:date-and-time; 1266 status deprecated; 1267 description 1268 "The time the interface entered its current operational 1269 state. If the current state was entered prior to the 1270 last re-initialization of the local network management 1271 subsystem, then this node is not present."; 1272 reference 1273 "RFC 2863: The Interfaces Group MIB - ifLastChange"; 1274 } 1276 leaf if-index { 1277 if-feature if-mib; 1278 type int32 { 1279 range "1..2147483647"; 1280 } 1281 mandatory true; 1282 status deprecated; 1283 description 1284 "The ifIndex value for the ifEntry represented by this 1285 interface."; 1286 reference 1287 "RFC 2863: The Interfaces Group MIB - ifIndex"; 1288 } 1290 leaf phys-address { 1291 type yang:phys-address; 1292 status deprecated; 1293 description 1294 "The interface's address at its protocol sub-layer. For 1295 example, for an 802.x interface, this object normally 1296 contains a Media Access Control (MAC) address. The 1297 interface's media-specific modules must define the bit 1298 and byte ordering and the format of the value of this 1299 object. For interfaces that do not have such an address 1300 (e.g., a serial line), this node is not present."; 1301 reference 1302 "RFC 2863: The Interfaces Group MIB - ifPhysAddress"; 1303 } 1305 leaf-list higher-layer-if { 1306 type interface-state-ref; 1307 status deprecated; 1308 description 1309 "A list of references to interfaces layered on top of this 1310 interface."; 1311 reference 1312 "RFC 2863: The Interfaces Group MIB - ifStackTable"; 1313 } 1315 leaf-list lower-layer-if { 1316 type interface-state-ref; 1317 status deprecated; 1318 description 1319 "A list of references to interfaces layered underneath this 1320 interface."; 1321 reference 1322 "RFC 2863: The Interfaces Group MIB - ifStackTable"; 1323 } 1325 leaf speed { 1326 type yang:gauge64; 1327 units "bits/second"; 1328 status deprecated; 1329 description 1330 "An estimate of the interface's current bandwidth in bits 1331 per second. For interfaces that do not vary in 1332 bandwidth or for those where no accurate estimation can 1333 be made, this node should contain the nominal bandwidth. 1334 For interfaces that have no concept of bandwidth, this 1335 node is not present."; 1336 reference 1337 "RFC 2863: The Interfaces Group MIB - 1338 ifSpeed, ifHighSpeed"; 1339 } 1341 container statistics { 1342 status deprecated; 1343 description 1344 "A collection of interface-related statistics objects."; 1346 leaf discontinuity-time { 1347 type yang:date-and-time; 1348 mandatory true; 1349 status deprecated; 1350 description 1351 "The time on the most recent occasion at which any one or 1352 more of this interface's counters suffered a 1353 discontinuity. If no such discontinuities have occurred 1354 since the last re-initialization of the local management 1355 subsystem, then this node contains the time the local 1356 management subsystem re-initialized itself."; 1357 } 1359 leaf in-octets { 1360 type yang:counter64; 1361 status deprecated; 1362 description 1363 "The total number of octets received on the interface, 1364 including framing characters. 1366 Discontinuities in the value of this counter can occur 1367 at re-initialization of the management system, and at 1368 other times as indicated by the value of 1369 'discontinuity-time'."; 1370 reference 1371 "RFC 2863: The Interfaces Group MIB - ifHCInOctets"; 1372 } 1374 leaf in-unicast-pkts { 1375 type yang:counter64; 1376 status deprecated; 1377 description 1378 "The number of packets, delivered by this sub-layer to a 1379 higher (sub-)layer, that were not addressed to a 1380 multicast or broadcast address at this sub-layer. 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 - ifHCInUcastPkts"; 1388 } 1390 leaf in-broadcast-pkts { 1391 type yang:counter64; 1392 status deprecated; 1393 description 1394 "The number of packets, delivered by this sub-layer to a 1395 higher (sub-)layer, that were addressed to a broadcast 1396 address at this sub-layer. 1398 Discontinuities in the value of this counter can occur 1399 at re-initialization of the management system, and at 1400 other times as indicated by the value of 1401 'discontinuity-time'."; 1402 reference 1403 "RFC 2863: The Interfaces Group MIB - 1404 ifHCInBroadcastPkts"; 1405 } 1407 leaf in-multicast-pkts { 1408 type yang:counter64; 1409 status deprecated; 1410 description 1411 "The number of packets, delivered by this sub-layer to a 1412 higher (sub-)layer, that were addressed to a multicast 1413 address at this sub-layer. For a MAC-layer protocol, 1414 this includes both Group and Functional addresses. 1416 Discontinuities in the value of this counter can occur 1417 at re-initialization of the management system, and at 1418 other times as indicated by the value of 1419 'discontinuity-time'."; 1420 reference 1421 "RFC 2863: The Interfaces Group MIB - 1422 ifHCInMulticastPkts"; 1423 } 1425 leaf in-discards { 1426 type yang:counter32; 1427 status deprecated; 1428 description 1429 "The number of inbound packets that were chosen to be 1430 discarded even though no errors had been detected to 1431 prevent their being deliverable to a higher-layer 1432 protocol. One possible reason for discarding such a 1433 packet could be to free up buffer space. 1435 Discontinuities in the value of this counter can occur 1436 at re-initialization of the management system, and at 1437 other times as indicated by the value of 1438 'discontinuity-time'."; 1439 reference 1440 "RFC 2863: The Interfaces Group MIB - ifInDiscards"; 1441 } 1443 leaf in-errors { 1444 type yang:counter32; 1445 status deprecated; 1446 description 1447 "For packet-oriented interfaces, the number of inbound 1448 packets that contained errors preventing them from being 1449 deliverable to a higher-layer protocol. For character- 1450 oriented or fixed-length interfaces, the number of 1451 inbound transmission units that contained errors 1452 preventing them from being deliverable to a higher-layer 1453 protocol. 1455 Discontinuities in the value of this counter can occur 1456 at re-initialization of the management system, and at 1457 other times as indicated by the value of 1458 'discontinuity-time'."; 1459 reference 1460 "RFC 2863: The Interfaces Group MIB - ifInErrors"; 1461 } 1463 leaf in-unknown-protos { 1464 type yang:counter32; 1465 status deprecated; 1466 description 1467 "For packet-oriented interfaces, the number of packets 1468 received via the interface that were discarded because 1469 of an unknown or unsupported protocol. For 1470 character-oriented or fixed-length interfaces that 1471 support protocol multiplexing, the number of 1472 transmission units received via the interface that were 1473 discarded because of an unknown or unsupported protocol. 1475 For any interface that does not support protocol 1476 multiplexing, this counter is not present. 1478 Discontinuities in the value of this counter can occur 1479 at re-initialization of the management system, and at 1480 other times as indicated by the value of 1481 'discontinuity-time'."; 1482 reference 1483 "RFC 2863: The Interfaces Group MIB - ifInUnknownProtos"; 1484 } 1486 leaf out-octets { 1487 type yang:counter64; 1488 status deprecated; 1489 description 1490 "The total number of octets transmitted out of the 1491 interface, including framing characters. 1493 Discontinuities in the value of this counter can occur 1494 at re-initialization of the management system, and at 1495 other times as indicated by the value of 1496 'discontinuity-time'."; 1497 reference 1498 "RFC 2863: The Interfaces Group MIB - ifHCOutOctets"; 1499 } 1501 leaf out-unicast-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 not addressed 1507 to a multicast or broadcast address at this sub-layer, 1508 including those that were discarded or not sent. 1510 Discontinuities in the value of this counter can occur 1511 at re-initialization of the management system, and at 1512 other times as indicated by the value of 1513 'discontinuity-time'."; 1514 reference 1515 "RFC 2863: The Interfaces Group MIB - ifHCOutUcastPkts"; 1516 } 1518 leaf out-broadcast-pkts { 1519 type yang:counter64; 1520 status deprecated; 1521 description 1522 "The total number of packets that higher-level protocols 1523 requested be transmitted, and that were addressed to a 1524 broadcast address at this sub-layer, including those 1525 that were discarded or not sent. 1527 Discontinuities in the value of this counter can occur 1528 at re-initialization of the management system, and at 1529 other times as indicated by the value of 1530 'discontinuity-time'."; 1531 reference 1532 "RFC 2863: The Interfaces Group MIB - 1533 ifHCOutBroadcastPkts"; 1534 } 1536 leaf out-multicast-pkts { 1537 type yang:counter64; 1538 status deprecated; 1539 description 1540 "The total number of packets that higher-level protocols 1541 requested be transmitted, and that were addressed to a 1542 multicast address at this sub-layer, including those 1543 that were discarded or not sent. For a MAC-layer 1544 protocol, this includes both Group and Functional 1545 addresses. 1547 Discontinuities in the value of this counter can occur 1548 at re-initialization of the management system, and at 1549 other times as indicated by the value of 1550 'discontinuity-time'."; 1551 reference 1552 "RFC 2863: The Interfaces Group MIB - 1553 ifHCOutMulticastPkts"; 1554 } 1556 leaf out-discards { 1557 type yang:counter32; 1558 status deprecated; 1559 description 1560 "The number of outbound packets that were chosen to be 1561 discarded even though no errors had been detected to 1562 prevent their being transmitted. One possible reason 1563 for discarding such a packet could be to free up buffer 1564 space. 1566 Discontinuities in the value of this counter can occur 1567 at re-initialization of the management system, and at 1568 other times as indicated by the value of 1569 'discontinuity-time'."; 1571 reference 1572 "RFC 2863: The Interfaces Group MIB - ifOutDiscards"; 1573 } 1575 leaf out-errors { 1576 type yang:counter32; 1577 status deprecated; 1578 description 1579 "For packet-oriented interfaces, the number of outbound 1580 packets that could not be transmitted because of errors. 1581 For character-oriented or fixed-length interfaces, the 1582 number of outbound transmission units that could not be 1583 transmitted because of errors. 1585 Discontinuities in the value of this counter can occur 1586 at re-initialization of the management system, and at 1587 other times as indicated by the value of 1588 'discontinuity-time'."; 1589 reference 1590 "RFC 2863: The Interfaces Group MIB - ifOutErrors"; 1591 } 1592 } 1593 } 1594 } 1595 } 1597 1599 6. IANA Considerations 1601 This document registers a URI in the "IETF XML Registry" [RFC3688]. 1602 Following the format in RFC 3688, the following registration has been 1603 made. 1605 URI: urn:ietf:params:xml:ns:yang:ietf-interfaces 1607 Registrant Contact: The IESG. 1609 XML: N/A, the requested URI is an XML namespace. 1611 This document registers a YANG module in the "YANG Module Names" 1612 registry [RFC6020]. 1614 name: ietf-interfaces 1615 namespace: urn:ietf:params:xml:ns:yang:ietf-interfaces 1616 prefix: if 1617 reference: RFC XXXX 1619 7. Security Considerations 1621 The YANG module defined in this memo is designed to be accessed via 1622 the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the 1623 secure transport layer and the mandatory-to-implement secure 1624 transport is SSH [RFC6242]. The NETCONF access control model 1625 [RFC6536] provides the means to restrict access for particular 1626 NETCONF users to a pre-configured subset of all available NETCONF 1627 protocol operations and content. 1629 There are a number of data nodes defined in the YANG module which are 1630 writable/creatable/deletable (i.e., config true, which is the 1631 default). These data nodes may be considered sensitive or vulnerable 1632 in some network environments. Write operations (e.g., ) 1633 to these data nodes without proper protection can have a negative 1634 effect on network operations. These are the subtrees and data nodes 1635 and their sensitivity/vulnerability: 1637 /interfaces/interface: This list specifies the configured interfaces 1638 on a device. Unauthorized access to this list could cause the 1639 device to ignore packets it should receive and process. 1641 /interfaces/interface/enabled: This leaf controls whether an 1642 interface is enabled or not. Unauthorized access to this leaf 1643 could cause the device to ignore packets it should receive and 1644 process. 1646 8. Acknowledgments 1648 The author wishes to thank Alexander Clemm, Per Hedeland, Ladislav 1649 Lhotka, and Juergen Schoenwaelder for their helpful comments. 1651 9. References 1653 9.1. Normative References 1655 [I-D.ietf-netmod-revised-datastores] 1656 Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1657 and R. Wilton, "Network Management Datastore 1658 Architecture", draft-ietf-netmod-revised-datastores-03 1659 (work in progress), July 2017. 1661 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1662 Requirement Levels", BCP 14, RFC 2119, 1663 DOI 10.17487/RFC2119, March 1997, . 1666 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 1667 MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, 1668 . 1670 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1671 DOI 10.17487/RFC3688, January 2004, . 1674 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1675 the Network Configuration Protocol (NETCONF)", RFC 6020, 1676 DOI 10.17487/RFC6020, October 2010, . 1679 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1680 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1681 . 1683 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1684 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1685 . 1687 9.2. Informative References 1689 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1690 and A. Bierman, Ed., "Network Configuration Protocol 1691 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1692 . 1694 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1695 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1696 . 1698 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1699 Protocol (NETCONF) Access Control Model", RFC 6536, 1700 DOI 10.17487/RFC6536, March 2012, . 1703 [RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", 1704 RFC 7224, DOI 10.17487/RFC7224, May 2014, 1705 . 1707 Appendix A. Example: Ethernet Interface Module 1709 This section gives a simple example of how an Ethernet interface 1710 module could be defined. It demonstrates how media-specific 1711 configuration parameters can be conditionally augmented to the 1712 generic interface list. It also shows how operational state 1713 parameters can be conditionally augmented to the operational 1714 interface list. The example is not intended as a complete module for 1715 Ethernet configuration. 1717 module ex-ethernet { 1718 namespace "http://example.com/ethernet"; 1719 prefix "eth"; 1721 import ietf-interfaces { 1722 prefix if; 1723 } 1724 import iana-if-type { 1725 prefix ianaift; 1726 } 1728 // configuration and state parameters for Ethernet interfaces 1729 augment "/if:interfaces/if:interface" { 1730 when "if:type = 'ianaift:ethernetCsmacd'"; 1732 container ethernet { 1733 choice transmission-params { 1734 case auto { 1735 leaf auto-negotiate { 1736 type empty; 1737 } 1738 } 1739 case manual { 1740 leaf duplex { 1741 type enumeration { 1742 enum "half"; 1743 enum "full"; 1744 } 1745 } 1747 leaf speed { 1748 type enumeration { 1749 enum "10Mb"; 1750 enum "100Mb"; 1751 enum "1Gb"; 1752 enum "10Gb"; 1753 } 1754 } 1755 } 1756 } 1757 leaf duplexx { 1758 type enumeration { 1759 enum "half"; 1760 enum "full"; 1761 } 1762 config false; 1763 } 1764 // other Ethernet-specific params... 1765 } 1766 } 1767 } 1769 Appendix B. Example: Ethernet Bonding Interface Module 1771 This section gives an example of how interface layering can be 1772 defined. An Ethernet bonding interface that bonds several Ethernet 1773 interfaces into one logical interface is defined. 1775 module ex-ethernet-bonding { 1776 namespace "http://example.com/ethernet-bonding"; 1777 prefix "bond"; 1779 import ietf-interfaces { 1780 prefix if; 1781 } 1782 import iana-if-type { 1783 prefix ianaift; 1784 } 1786 augment "/if:interfaces/if:interface" { 1787 when "if:type = 'ianaift:ieee8023adLag'"; 1789 leaf-list slave-if { 1790 type if:interface-ref; 1791 must "/if:interfaces/if:interface[if:name = current()]" 1792 + "/if:type = 'ianaift:ethernetCsmacd'" { 1793 description 1794 "The type of a slave interface must be 'ethernetCsmacd'."; 1795 } 1796 } 1797 leaf bonding-mode { 1798 type enumeration { 1799 enum round-robin; 1800 enum active-backup; 1801 enum broadcast; 1802 } 1803 } 1804 // other bonding config params, failover times, etc. 1805 } 1806 } 1808 Appendix C. Example: VLAN Interface Module 1810 This section gives an example of how a VLAN interface module can be 1811 defined. 1813 module ex-vlan { 1814 namespace "http://example.com/vlan"; 1815 prefix "vlan"; 1817 import ietf-interfaces { 1818 prefix if; 1819 } 1820 import iana-if-type { 1821 prefix ianaift; 1822 } 1824 augment "/if:interfaces/if:interface" { 1825 when "if:type = 'ianaift:ethernetCsmacd' or 1826 if:type = 'ianaift:ieee8023adLag'"; 1827 leaf vlan-tagging { 1828 type boolean; 1829 default false; 1830 } 1831 } 1833 augment "/if:interfaces/if:interface" { 1834 when "if:type = 'ianaift:l2vlan'"; 1836 leaf base-interface { 1837 type if:interface-ref; 1838 must "/if:interfaces/if:interface[if:name = current()]" 1839 + "/vlan:vlan-tagging = 'true'" { 1840 description 1841 "The base interface must have VLAN tagging enabled."; 1842 } 1843 } 1844 leaf vlan-id { 1845 type uint16 { 1846 range "1..4094"; 1847 } 1848 must "../base-interface" { 1849 description 1850 "If a vlan-id is defined, a base-interface must 1851 be specified."; 1852 } 1853 } 1854 } 1855 } 1857 Appendix D. Example: NETCONF Reply 1859 This section gives an example of a reply to the NETCONF 1860 request for for a device that implements the example data 1861 models above. 1863 1866 1867 1872 1873 eth0 1874 ianaift:ethernetCsmacd 1875 false 1876 1878 1879 eth1 1880 ianaift:ethernetCsmacd 1881 true 1882 true 1883 1885 1886 eth1.10 1887 ianaift:l2vlan 1888 true 1889 eth1 1890 10 1891 1893 1894 lo1 1895 ianaift:softwareLoopback 1896 true 1897 1899 1900 1901 1903 Appendix E. Example: NETCONF Reply 1905 This section gives an example of a reply to the NETCONF 1906 request for for a device that implements the example 1907 data models above. 1909 1912 1913 1919 1920 eth0 1921 ianaift:ethernetCsmacd 1922 false 1923 down 1924 down 1925 2 1926 00:01:02:03:04:05 1927 1928 1929 2013-04-01T03:00:00+00:00 1930 1931 1932 1933 1935 1936 eth1 1937 ianaift:ethernetCsmacd 1938 true 1939 up 1940 up 1941 7 1942 00:01:02:03:04:06 1943 eth1.10 1944 1945 1946 2013-04-01T03:00:00+00:00 1947 1948 1949 1950 true 1952 1954 1955 eth1.10 1956 ianaift:l2vlan 1957 true 1958 up 1959 up 1960 9 1961 eth1 1962 1963 1964 2013-04-01T03:00:00+00:00 1965 1966 1967 1968 eth1 1969 10 1970 1972 1973 1974 eth2 1975 ianaift:ethernetCsmacd 1976 down 1977 down 1978 8 1979 00:01:02:03:04:07 1980 1981 1982 2013-04-01T03:00:00+00:00 1983 1984 1985 1986 1988 1989 lo1 1990 ianaift:softwareLoopback 1991 true 1992 up 1993 up 1994 1 1995 1996 1997 2013-04-01T03:00:00+00:00 1998 1999 2001 2002 2004 2005 2006 2008 Appendix F. Examples: Interface Naming Schemes 2010 This section gives examples of some implementation strategies. 2012 The examples make use of the example data model "ex-vlan" (see 2013 Appendix C) to show how user-controlled interfaces can be configured. 2015 F.1. Router with Restricted Interface Names 2017 In this example, a router has support for 4 line cards, each with 8 2018 ports. The slots for the cards are physically numbered from 0 to 3, 2019 and the ports on each card from 0 to 7. Each card has Fast Ethernet 2020 or Gigabit Ethernet ports. 2022 The device-specific names for these physical interfaces are 2023 "fastethernet-N/M" or "gigabitethernet-N/M". 2025 The name of a VLAN interface is restricted to the form 2026 ".". 2028 It is assumed that the operator is aware of this naming scheme. The 2029 implementation auto-initializes the value for "type" based on the 2030 interface name. 2032 The NETCONF server does not advertise the "arbitrary-names" feature 2033 in the message. 2035 An operator can configure a physical interface by sending an 2036 containing: 2038 2039 fastethernet-1/0 2040 2042 When the server processes this request, it will set the leaf "type" 2043 to "ianaift:ethernetCsmacd". Thus, if the client performs a 2044 right after the above, it will get: 2046 2047 fastethernet-1/0 2048 ianaift:ethernetCsmacd 2049 2051 The client can configure a VLAN interface by sending an 2052 containing: 2054 2055 fastethernet-1/0.10005 2056 ianaift:l2vlan 2057 fastethernet-1/0 2058 5 2059 2061 If the client tries to change the type of the physical interface with 2062 an containing: 2064 2065 fastethernet-1/0 2066 ianaift:tunnel 2067 2069 then the server will reply with an "invalid-value" error, since the 2070 new type does not match the name. 2072 F.2. Router with Arbitrary Interface Names 2074 In this example, a router has support for 4 line cards, each with 8 2075 ports. The slots for the cards are physically numbered from 0 to 3, 2076 and the ports on each card from 0 to 7. Each card has Fast Ethernet 2077 or Gigabit Ethernet ports. 2079 The device-specific names for these physical interfaces are 2080 "fastethernet-N/M" or "gigabitethernet-N/M". 2082 The implementation does not restrict the user-controlled interface 2083 names. This allows an operator to more easily apply the interface 2084 configuration to a different interface. However, the additional 2085 level of indirection also makes it a bit more complex to map 2086 interface names found in other protocols to configuration entries. 2088 The NETCONF server advertises the "arbitrary-names" feature in the 2089 message. 2091 Physical interfaces are configured as in Appendix F.1. 2093 An operator can configure a VLAN interface by sending an 2094 containing: 2096 2097 acme-interface 2098 ianaift:l2vlan 2099 fastethernet-1/0 2100 5 2101 2103 If necessary, the operator can move the configuration named 2104 "acme-interface" over to a different physical interface with an 2105 containing: 2107 2108 acme-interface 2109 fastethernet-1/1 2110 2112 F.3. Ethernet Switch with Restricted Interface Names 2114 In this example, an Ethernet switch has a number of ports, each 2115 identified by a simple port number. 2117 The device-specific names for the physical interfaces are numbers 2118 that match the physical port number. 2120 An operator can configure a physical interface by sending an 2121 containing: 2123 2124 6 2125 2127 When the server processes this request, it will set the leaf "type" 2128 to "ianaift:ethernetCsmacd". Thus, if the client performs a 2129 right after the above, it will get: 2131 2132 6 2133 ianaift:ethernetCsmacd 2134 2136 F.4. Generic Host with Restricted Interface Names 2138 In this example, a generic host has interfaces named by the kernel. 2139 The system identifies the physical interface by the name assigned by 2140 the operating system to the interface. 2142 The name of a VLAN interface is restricted to the form 2143 ":". 2145 The NETCONF server does not advertise the "arbitrary-names" feature 2146 in the message. 2148 An operator can configure an interface by sending an 2149 containing: 2151 2152 eth8 2153 2155 When the server processes this request, it will set the leaf "type" 2156 to "ianaift:ethernetCsmacd". Thus, if the client performs a 2157 right after the above, it will get: 2159 2160 eth8 2161 ianaift:ethernetCsmacd 2162 2164 The client can configure a VLAN interface by sending an 2165 containing: 2167 2168 eth8:5 2169 ianaift:l2vlan 2170 eth8 2171 5 2172 2174 F.5. Generic Host with Arbitrary Interface Names 2176 In this example, a generic host has interfaces named by the kernel. 2177 The system identifies the physical interface by the name assigned by 2178 the operating system to the interface. 2180 The implementation does not restrict the user-controlled interface 2181 names. This allows an operator to more easily apply the interface 2182 configuration to a different interface. However, the additional 2183 level of indirection also makes it a bit more complex to map 2184 interface names found in other protocols to configuration entries. 2186 The NETCONF server advertises the "arbitrary-names" feature in the 2187 message. 2189 Physical interfaces are configured as in Appendix F.4. 2191 An operator can configure a VLAN interface by sending an 2192 containing: 2194 2195 acme-interface 2196 ianaift:l2vlan 2197 eth8 2198 5 2199 2201 If necessary, the operator can move the configuration named 2202 "acme-interface" over to a different physical interface with an 2203 containing: 2205 2206 acme-interface 2207 eth3 2208 2210 Author's Address 2212 Martin Bjorklund 2213 Tail-f Systems 2215 Email: mbj@tail-f.com