idnits 2.17.1 draft-ietf-netmod-interfaces-cfg-16.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 238 has weird spacing: '...ty-time yan...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (January 23, 2014) is 3708 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-iana-if-type-08 -- Obsolete informational reference (is this intentional?): RFC 6536 (Obsoleted by RFC 8341) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Bjorklund 3 Internet-Draft Tail-f Systems 4 Intended status: Standards Track January 23, 2014 5 Expires: July 27, 2014 7 A YANG Data Model for Interface Management 8 draft-ietf-netmod-interfaces-cfg-16 10 Abstract 12 This document defines a YANG data model for the management of network 13 interfaces. It is expected that interface type specific data models 14 augment the generic interfaces data model defined in this document. 15 The data model includes configuration data and state data (status 16 information and counters for the collection of statistics). 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on July 27, 2014. 35 Copyright Notice 37 Copyright (c) 2014 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 3. Interfaces Data Model . . . . . . . . . . . . . . . . . . . . 6 57 3.1. The interface Lists . . . . . . . . . . . . . . . . . . . 6 58 3.2. Interface References . . . . . . . . . . . . . . . . . . . 8 59 3.3. Interface Layering . . . . . . . . . . . . . . . . . . . . 8 60 4. Relationship to the IF-MIB . . . . . . . . . . . . . . . . . . 10 61 5. Interfaces YANG Module . . . . . . . . . . . . . . . . . . . . 12 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 64 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 65 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 66 9.1. Normative References . . . . . . . . . . . . . . . . . . . 30 67 9.2. Informative References . . . . . . . . . . . . . . . . . . 30 68 Appendix A. Example: Ethernet Interface Module . . . . . . . . . 31 69 Appendix B. Example: Ethernet Bonding Interface Module . . . . . 33 70 Appendix C. Example: VLAN Interface Module . . . . . . . . . . . 34 71 Appendix D. Example: NETCONF reply . . . . . . . . . . . . 36 72 Appendix E. Examples: Interface Naming Schemes . . . . . . . . . 39 73 E.1. Router with Restricted Interface Names . . . . . . . . . . 39 74 E.2. Router with Arbitrary Interface Names . . . . . . . . . . 40 75 E.3. Ethernet Switch with Restricted Interface Names . . . . . 41 76 E.4. Generic Host with Restricted Interface Names . . . . . . . 41 77 E.5. Generic Host with Arbitrary Interface Names . . . . . . . 42 78 Appendix F. ChangeLog . . . . . . . . . . . . . . . . . . . . . . 44 79 F.1. Version -13 . . . . . . . . . . . . . . . . . . . . . . . 44 80 F.2. Version -11 . . . . . . . . . . . . . . . . . . . . . . . 44 81 F.3. Version -08 . . . . . . . . . . . . . . . . . . . . . . . 44 82 F.4. Version -07 . . . . . . . . . . . . . . . . . . . . . . . 44 83 F.5. Version -06 . . . . . . . . . . . . . . . . . . . . . . . 44 84 F.6. Version -05 . . . . . . . . . . . . . . . . . . . . . . . 45 85 F.7. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 45 86 F.8. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 45 87 F.9. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 45 88 F.10. Version -01 . . . . . . . . . . . . . . . . . . . . . . . 45 89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 46 91 1. Introduction 93 This document defines a YANG [RFC6020] data model for the management 94 of network interfaces. It is expected that interface type specific 95 data models augment the generic interfaces data model defined in this 96 document. 98 Network interfaces are central to the management of many Internet 99 protocols. Thus, it is important to establish a common data model 100 for how interfaces are identified, configured, and monitored. 102 The data model includes configuration data and state data (status 103 information and counters for the collection of statistics). 105 1.1. Terminology 107 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 109 "OPTIONAL" in this document are to be interpreted as described in BCP 110 14, [RFC2119]. 112 The following terms are used within this document: 114 o system-controlled interface: An interface is said to be system- 115 controlled if the system creates and deletes the interface 116 independently of what has been explicitly configured. Examples 117 are interfaces representing physical hardware that appear and 118 disappear when hardware (e.g., a line card or hot pluggable 119 wireless interface) is added or removed. System-controlled 120 interfaces may also appear if a certain functionality is enabled 121 (e.g., a loopback interface might appear if the IP protocol stack 122 is enabled). 124 o user-controlled interface: An interface is said to be user- 125 controlled if the creation of the interface is controlled by 126 adding explicit interface configuration to the running 127 configuration datastore and the removal of the interface is 128 controlled by removing explicit interface configuration from the 129 running configuration datastore. Examples are VLAN interfaces 130 configured on a system-controlled Ethernet interface. 132 The following terms are defined in [RFC6241] and are not redefined 133 here: 135 o client 137 o configuration data 138 o server 140 o state data 142 The following terms are defined in [RFC6020] and are not redefined 143 here: 145 o augment 147 o data model 149 o data node 151 o presence container 153 1.2. Tree Diagrams 155 A simplified graphical representation of the data model is used in 156 this document. The meaning of the symbols in these diagrams is as 157 follows: 159 o Brackets "[" and "]" enclose list keys. 161 o Abbreviations before data node names: "rw" means configuration 162 (read-write) and "ro" state data (read-only). 164 o Symbols after data node names: "?" means an optional node, "!" 165 means a presence container, and "*" denotes a list and leaf-list. 167 o Parentheses enclose choice and case nodes, and case nodes are also 168 marked with a colon (":"). 170 o Ellipsis ("...") stands for contents of subtrees that are not 171 shown. 173 2. Objectives 175 This section describes some of the design objectives for the model 176 presented in Section 5. 178 o It is recognized that existing implementations will have to map 179 the interface data model defined in this memo to their proprietary 180 native data model. The data model should be simple to facilitate 181 such mappings. 183 o The data model should be suitable for new implementations to use 184 as-is, without requiring a mapping to a different native model. 186 o References to interfaces should be as simple as possible, 187 preferably by using a single leafref. 189 o The mapping to ifIndex [RFC2863] used by SNMP to identify 190 interfaces must be clear. 192 o The model must support interface layering, both simple layering 193 where one interface is layered on top of exactly one other 194 interface, and more complex scenarios where one interface results 195 from the aggregation of N other interfaces, or when N interfaces 196 are multiplexed over one other interface. 198 o The data model should support the pre-provisioning of interface 199 configuration, i.e., it should be possible to configure an 200 interface whose physical interface hardware is not present on the 201 device. It is recommended that devices that support dynamic 202 addition and removal of physical interfaces also support pre- 203 provisioning. 205 o The data model should support both physical interfaces as well as 206 logical interfaces. 208 o The data model should include read-only counters in order to 209 gather statistics for sent and received octets and packets, 210 received packets with errors, and packets that could not be sent 211 due to errors. 213 3. Interfaces Data Model 215 This document defines the YANG module "ietf-interfaces", which has 216 the following structure: 218 +--rw interfaces 219 | +--rw interface* [name] 220 | +--rw name string 221 | +--rw description? string 222 | +--rw type identityref 223 | +--rw enabled? boolean 224 | +--rw link-up-down-trap-enable? enumeration 225 +--ro interfaces-state 226 +--ro interface* [name] 227 +--ro name string 228 +--ro type identityref 229 +--ro admin-status enumeration 230 +--ro oper-status enumeration 231 +--ro last-change? yang:date-and-time 232 +--ro if-index int32 233 +--ro phys-address? yang:phys-address 234 +--ro higher-layer-if* interface-state-ref 235 +--ro lower-layer-if* interface-state-ref 236 +--ro speed? yang:gauge64 237 +--ro statistics 238 +--ro discontinuity-time yang:date-and-time 239 +--ro in-octets? yang:counter64 240 +--ro in-unicast-pkts? yang:counter64 241 +--ro in-broadcast-pkts? yang:counter64 242 +--ro in-multicast-pkts? yang:counter64 243 +--ro in-discards? yang:counter32 244 +--ro in-errors? yang:counter32 245 +--ro in-unknown-protos? yang:counter32 246 +--ro out-octets? yang:counter64 247 +--ro out-unicast-pkts? yang:counter64 248 +--ro out-broadcast-pkts? yang:counter64 249 +--ro out-multicast-pkts? yang:counter64 250 +--ro out-discards? yang:counter32 251 +--ro out-errors? yang:counter32 253 3.1. The interface Lists 255 The data model for interfaces presented in this document uses a flat 256 list of interfaces. Each interface in the list is identified by its 257 name. Furthermore, each interface has a mandatory "type" leaf. 259 The "iana-if-type" module [I-D.ietf-netmod-iana-if-type] defines YANG 260 identities for the interface types in the IANA-maintained "ifType 261 registry". 263 There is one list of configured interfaces ("/interfaces/interface"), 264 and a separate list for the operational state of all interfaces 265 ("/interfaces-state/interface"). 267 It is expected that interface type specific data models augment the 268 interface lists, and possibly use the "type" leaf to make the 269 augmentation conditional. 271 As an example of such an interface type specific augmentation, 272 consider this YANG snippet. For a more complete example, see 273 Appendix A. 275 import interfaces { 276 prefix "if"; 277 } 278 import iana-if-type { 279 prefix ianaift; 280 } 282 augment "/if:interfaces/if:interface" { 283 when "if:type = 'ianaift:ethernetCsmacd'"; 285 container ethernet { 286 leaf duplex { 287 ... 288 } 289 } 290 } 292 For system-controlled interfaces, the "name" is the device-specific 293 name of the interface. The 'config false' list "/interfaces-state/ 294 interface" contains all existing interfaces on the device. 296 If the device supports arbitrarily named user-controlled interfaces, 297 the NETCONF server advertises the feature "arbitrary-names". If the 298 device does not advertise this feature, the names of user-controlled 299 interfaces MUST match the device's naming scheme. How a client can 300 learn the naming scheme of such devices is outside the scope of this 301 document. See Appendix E.1 and Appendix E.2 for examples. 303 When a system-controlled interface is created by the system, the 304 system tries to apply the interface configuration in "/interfaces/ 305 interface" with the same name as the new interface. If no such 306 interface configuration is found, or if the configured type does not 307 match the real interface type, the system creates the interface 308 without applying explicit configuration. 310 When a user-controlled interface is created, the configuration 311 determines the name of the interface. 313 Depending on the operating system and the physical attachment point 314 to which a network interface may be attached or removed, it may be 315 impossible for an implementation to provide predictable and 316 consistent names for system-controlled interfaces across insertion/ 317 removal cycles as well as in anticipation of initial insertion. The 318 ability to provide configurations for such interfaces is therefore 319 dependent on the implementation, and cannot be assumed in all cases. 321 3.2. Interface References 323 An interface is identified by its name, which is unique within the 324 server. This property is captured in the "interface-ref" and 325 "interface-state-ref" typedefs, which other YANG modules SHOULD use 326 when they need to reference a configured interface or operationally 327 used interface, respectively. 329 3.3. Interface Layering 331 There is no generic mechanism for how an interface is configured to 332 be layered on top of some other interface. It is expected that 333 interface type specific models define their own data nodes for 334 interface layering, by using "interface-ref" types to reference lower 335 layers. 337 Below is an example of a model with such nodes. For a more complete 338 example, see Appendix B. 340 import interfaces { 341 prefix "if"; 342 } 343 import iana-if-type { 344 prefix ianaift; 345 } 347 augment "/if:interfaces/if:interface" { 348 when "if:type = 'ianaift:ieee8023adLag'"; 350 leaf-list slave-if { 351 type if:interface-ref; 352 must "/if:interfaces/if:interface[if:name = current()]" 353 + "/if:type = 'ianaift:ethernetCsmacd'" { 354 description 355 "The type of a slave interface must be ethernet"; 356 } 357 } 358 // other bonding config params, failover times etc. 359 } 361 While the interface layering is configured in type specific models, 362 two generic state data leaf-lists, "higher-layer-if" and 363 "lower-layer-if", represent a read-only view of the interface 364 layering hierarchy. 366 4. Relationship to the IF-MIB 368 If the device implements IF-MIB [RFC2863], each entry in the 369 "/interfaces-state/interface" list is typically mapped to one 370 ifEntry. The "if-index" leaf MUST contain the value of the 371 corresponding ifEntry's ifIndex. 373 In most cases, the "name" of an "/interfaces-state/interface" entry 374 is mapped to ifName. The IF-MIB allows two different ifEntries to 375 have the same ifName. Devices that support this feature, and also 376 support the data model defined in this document, cannot have a 1-1 377 mapping between the "name" leaf and ifName. 379 The configured "description" of an "interface" has traditionally been 380 mapped to ifAlias in some implementations. This document allows this 381 mapping, but implementers should be aware of the differences in the 382 value space and persistence for these objects. See the YANG module 383 definition of the leaf "description" in Section 5 for details. 385 The IF-MIB also defines the writable object ifPromiscuousMode. Since 386 this object typically is not implemented as a configuration object by 387 SNMP agents, it is not mapped to the "ietf-interfaces" module. 389 The ifMtu object from IF-MIB is not mapped to the "ietf-interfaces" 390 module. It is expected that interface type specific YANG modules 391 provide interface type specific MTU leafs by augmenting the 392 "ietf-interfaces" model. 394 There are a number of counters in the IF-MIB that exist in two 395 versions; one with 32 bits and one with 64 bits. The 64-bit versions 396 were added to support high-speed interfaces with a data rate greater 397 than 20,000,000 bits/second. Today's implementations generally 398 support such high-speed interfaces and hence only 64-bit counters are 399 provided in this data model. Note that NETCONF and SNMP may differ 400 in the time granularity in which they provide access to the counters. 401 For example, it is common that SNMP implementations cache counter 402 values for some time. 404 The objects ifDescr and ifConnectorPresent from IF-MIB are not mapped 405 to the "ietf-interfaces" module. 407 The following tables list the YANG data nodes with corresponding 408 objects in the IF-MIB. 410 +--------------------------------------+----------------------------+ 411 | YANG data node in | IF-MIB object | 412 | /interfaces-state/interface | | 413 +--------------------------------------+----------------------------+ 414 | name | ifName | 415 | type | ifType | 416 | admin-status | ifAdminStatus | 417 | oper-status | ifOperStatus | 418 | last-change | ifLastChange | 419 | if-index | ifIndex | 420 | link-up-down-trap-enable | ifLinkUpDownTrapEnable | 421 | phys-address | ifPhysAddress | 422 | higher-layer-if and lower-layer-if | ifStackTable | 423 | speed | ifSpeed and ifHSpeed | 424 | discontinuity-time | ifCounterDiscontinuityTime | 425 | in-octets | ifHCInOctets | 426 | in-unicast-pkts | ifHCInUcastPkts | 427 | in-broadcast-pkts | ifHCInBroadcastPkts | 428 | in-multicast-pkts | ifHCInMulticastPkts | 429 | in-discards | ifInDiscards | 430 | in-errors | ifInErrors | 431 | in-unknown-protos | ifInUnknownProtos | 432 | out-octets | ifHCOutOctets | 433 | out-unicast-pkts | ifHCOutUcastPkts | 434 | out-broadcast-pkts | ifHCOutBroadcastPkts | 435 | out-multicast-pkts | ifHCOutMulticastPkts | 436 | out-discards | ifOutDiscards | 437 | out-errors | ifOutErrors | 438 +--------------------------------------+----------------------------+ 440 YANG state data nodes and related IF-MIB objects 442 +-----------------------------------------+---------------+ 443 | YANG data node in /interfaces/interface | IF-MIB object | 444 +-----------------------------------------+---------------+ 445 | description | ifAlias | 446 +-----------------------------------------+---------------+ 448 YANG config data nodes and related IF-MIB objects 450 5. Interfaces YANG Module 452 This YANG module imports typedefs from [RFC6991]. 454 RFC Ed.: update the date below with the date of RFC publication and 455 remove this note. 457 file "ietf-interfaces@2013-12-23.yang" 459 module ietf-interfaces { 461 namespace "urn:ietf:params:xml:ns:yang:ietf-interfaces"; 462 prefix if; 464 import ietf-yang-types { 465 prefix yang; 466 } 468 organization 469 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 471 contact 472 "WG Web: 473 WG List: 475 WG Chair: David Kessens 476 478 WG Chair: Juergen Schoenwaelder 479 481 Editor: Martin Bjorklund 482 "; 484 description 485 "This module contains a collection of YANG definitions for 486 managing network interfaces. 488 Copyright (c) 2013 IETF Trust and the persons identified as 489 authors of the code. All rights reserved. 491 Redistribution and use in source and binary forms, with or 492 without modification, is permitted pursuant to, and subject 493 to the license terms contained in, the Simplified BSD License 494 set forth in Section 4.c of the IETF Trust's Legal Provisions 495 Relating to IETF Documents 496 (http://trustee.ietf.org/license-info). 497 This version of this YANG module is part of RFC XXXX; see 498 the RFC itself for full legal notices."; 500 // RFC Ed.: replace XXXX with actual RFC number and remove this 501 // note. 503 // RFC Ed.: update the date below with the date of RFC publication 504 // and remove this note. 505 revision 2013-12-23 { 506 description 507 "Initial revision."; 508 reference 509 "RFC XXXX: A YANG Data Model for Interface Management"; 510 } 512 /* 513 * Typedefs 514 */ 516 typedef interface-ref { 517 type leafref { 518 path "/if:interfaces/if:interface/if:name"; 519 } 520 description 521 "This type is used by data models that need to reference 522 configured interfaces."; 523 } 525 typedef interface-state-ref { 526 type leafref { 527 path "/if:interfaces-state/if:interface/if:name"; 528 } 529 description 530 "This type is used by data models that need to reference 531 the operationally present interfaces."; 532 } 534 /* 535 * Identities 536 */ 538 identity interface-type { 539 description 540 "Base identity from which specific interface types are 541 derived."; 542 } 544 /* 545 * Features 546 */ 548 feature arbitrary-names { 549 description 550 "This feature indicates that the device allows user-controlled 551 interfaces to be named arbitrarily."; 552 } 554 feature pre-provisioning { 555 description 556 "This feature indicates that the device supports 557 pre-provisioning of interface configuration, i.e., it is 558 possible to configure an interface whose physical interface 559 hardware is not present on the device."; 560 } 562 feature if-mib { 563 description 564 "This feature indicates that the device implements IF-MIB."; 565 reference 566 "RFC 2863: The Interfaces Group MIB"; 567 } 569 /* 570 * Configuration data nodes 571 */ 573 container interfaces { 574 description 575 "Interface configuration parameters."; 577 list interface { 578 key "name"; 580 description 581 "The list of configured interfaces on the device. 583 The operational state of an interface is available in the 584 /interfaces-state/interface list. If the configuration of a 585 system-controlled interface cannot be used by the system 586 (e.g., the interface hardware present does not match the 587 interface type), then the configuration is not applied to 588 the system-controlled interface shown in the 589 /interfaces-state/interface list. If the configuration 590 of a user-controlled interface cannot be used by the system, 591 the configured interface is not instantiated in the 592 /interfaces-state/interface list."; 594 leaf name { 595 type string; 596 description 597 "The name of the interface. 599 A device MAY restrict the allowed values for this leaf, 600 possibly depending on the type of the interface. 602 For system-controlled interfaces, this leaf is the 603 device-specific name of the interface. The 'config false' 604 list /interfaces-state/interface contains the currently 605 existing interfaces on the device. 607 If a client tries to create configuration for a 608 system-controlled interface that is not present in the 609 /interfaces-state/interface list, the server MAY reject 610 the request, if the implementation does not support 611 pre-provisioning of interfaces, or if the name refers to 612 an interface that can never exist in the system. A 613 NETCONF server MUST reply with an rpc-error with the 614 error-tag 'invalid-value' in this case. 616 If the device supports pre-provisioning of interface 617 configuration, the feature 'pre-provisioning' is 618 advertised. 620 If the device allows arbitrarily named user-controlled 621 interfaces, the feature 'arbitrary-names' is advertised. 623 When a configured user-controlled interface is created by 624 the system, it is instantiated with the same name in the 625 /interface-state/interface list."; 626 } 628 leaf description { 629 type string; 630 description 631 "A textual description of the interface. 633 A server implementation MAY map this leaf to the ifAlias 634 MIB object. Such an implementation needs to use some 635 mechanism to handle the differences in size and characters 636 allowed between this leaf and ifAlias. The definition of 637 such a mechanism is outside the scope of this document. 639 Since ifAlias is defined to be stored in non-volatile 640 storage, the MIB implementation MUST map ifAlias to the 641 value of 'description' in the persistently stored 642 datastore. 644 Specifically, if the device supports ':startup', when 645 ifAlias is read the device MUST return the value of 646 'description' in the 'startup' datastore, and when it is 647 written, it MUST be written to the 'running' and 'startup' 648 datastores. Note that it is up to the implementation if 649 it modifies this single leaf in 'startup', or if it 650 performs an implicit copy-config from 'running' to 651 'startup'. 653 If the device does not support ':startup', ifAlias MUST 654 be mapped to the 'description' leaf in the 'running' 655 datastore."; 656 reference 657 "RFC 2863: The Interfaces Group MIB - ifAlias"; 658 } 660 leaf type { 661 type identityref { 662 base interface-type; 663 } 664 mandatory true; 665 description 666 "The type of the interface. 668 When an interface entry is created, a server MAY 669 initialize the type leaf with a valid value, e.g., if it 670 is possible to derive the type from the name of the 671 interface. 673 If a client tries to set the type of an interface to a 674 value that can never be used by the system, e.g., if the 675 type is not supported or if the type does not match the 676 name of the interface, the server MUST reject the request. 677 A NETCONF server MUST reply with an rpc-error with the 678 error-tag 'invalid-value' in this case."; 679 reference 680 "RFC 2863: The Interfaces Group MIB - ifType"; 681 } 683 leaf enabled { 684 type boolean; 685 default "true"; 686 description 687 "This leaf contains the configured, desired state of the 688 interface. 690 Systems that implement the IF-MIB use the value of this 691 leaf in the 'running' datastore to set 692 IF-MIB.ifAdminStatus to 'up' or 'down' after an ifEntry 693 has been initialized, as described in RFC 2863. 695 Changes in this leaf in the 'running' datastore are 696 reflected in ifAdminStatus, but if ifAdminStatus is 697 changed over SNMP, this leaf is not affected."; 698 reference 699 "RFC 2863: The Interfaces Group MIB - ifAdminStatus"; 700 } 702 leaf link-up-down-trap-enable { 703 if-feature if-mib; 704 type enumeration { 705 enum enabled { 706 value 1; 707 } 708 enum disabled { 709 value 2; 710 } 711 } 712 description 713 "Controls whether linkUp/linkDown SNMP notifications 714 should be generated for this interface. 716 If this node is not configured, the value 'enabled' is 717 operationally used by the server for interfaces which do 718 not operate on top of any other interface (i.e., there are 719 no 'lower-layer-if' entries), and 'disabled' otherwise."; 720 reference 721 "RFC 2863: The Interfaces Group MIB - 722 ifLinkUpDownTrapEnable"; 723 } 724 } 725 } 727 /* 728 * Operational state data nodes 729 */ 731 container interfaces-state { 732 config false; 733 description 734 "Data nodes for the operational state of interfaces."; 736 list interface { 737 key "name"; 738 description 739 "The list of interfaces on the device. 741 System-controlled interfaces created by the system are 742 always present in this list, whether they are configured or 743 not."; 745 leaf name { 746 type string; 747 description 748 "The name of the interface. 750 A server implementation MAY map this leaf to the ifName 751 MIB object. Such an implementation needs to use some 752 mechanism to handle the differences in size and characters 753 allowed between this leaf and ifName. The definition of 754 such a mechanism is outside the scope of this document."; 755 reference 756 "RFC 2863: The Interfaces Group MIB - ifName"; 757 } 759 leaf type { 760 type identityref { 761 base interface-type; 762 } 763 mandatory true; 764 description 765 "The type of the interface."; 766 reference 767 "RFC 2863: The Interfaces Group MIB - ifType"; 768 } 770 leaf admin-status { 771 if-feature if-mib; 772 type enumeration { 773 enum up { 774 value 1; 775 description 776 "Ready to pass packets."; 777 } 778 enum down { 779 value 2; 780 description 781 "Not ready to pass packets and not in some test mode."; 782 } 783 enum testing { 784 value 3; 785 description 786 "In some test mode."; 787 } 788 } 789 mandatory true; 790 description 791 "The desired state of the interface. 793 This leaf has the same read semantics as ifAdminStatus."; 794 reference 795 "RFC 2863: The Interfaces Group MIB - ifAdminStatus"; 796 } 798 leaf oper-status { 799 type enumeration { 800 enum up { 801 value 1; 802 description 803 "Ready to pass packets."; 804 } 805 enum down { 806 value 2; 807 description 808 "The interface does not pass any packets."; 809 } 810 enum testing { 811 value 3; 812 description 813 "In some test mode. No operational packets can 814 be passed."; 815 } 816 enum unknown { 817 value 4; 818 description 819 "Status cannot be determined for some reason."; 820 } 821 enum dormant { 822 value 5; 823 description 824 "Waiting for some external event."; 825 } 826 enum not-present { 827 value 6; 828 description 829 "Some component (typically hardware) is missing."; 830 } 831 enum lower-layer-down { 832 value 7; 833 description 834 "Down due to state of lower-layer interface(s)."; 835 } 836 } 837 mandatory true; 838 description 839 "The current operational state of the interface. 841 This leaf has the same semantics as ifOperStatus."; 842 reference 843 "RFC 2863: The Interfaces Group MIB - ifOperStatus"; 844 } 846 leaf last-change { 847 type yang:date-and-time; 848 description 849 "The time the interface entered its current operational 850 state. If the current state was entered prior to the 851 last re-initialization of the local network management 852 subsystem, then this node is not present."; 853 reference 854 "RFC 2863: The Interfaces Group MIB - ifLastChange"; 855 } 857 leaf if-index { 858 if-feature if-mib; 859 type int32 { 860 range "1..2147483647"; 861 } 862 mandatory true; 863 description 864 "The ifIndex value for the ifEntry represented by this 865 interface."; 866 reference 867 "RFC 2863: The Interfaces Group MIB - ifIndex"; 868 } 870 leaf phys-address { 871 type yang:phys-address; 872 description 873 "The interface's address at its protocol sub-layer. For 874 example, for an 802.x interface, this object normally 875 contains a MAC address. The interface's media-specific 876 modules must define the bit and byte ordering and the 877 format of the value of this object. For interfaces that do 878 not have such an address (e.g., a serial line), this node 879 is not present."; 880 reference 881 "RFC 2863: The Interfaces Group MIB - ifPhysAddress"; 883 } 885 leaf-list higher-layer-if { 886 type interface-state-ref; 887 description 888 "A list of references to interfaces layered on top of this 889 interface."; 890 reference 891 "RFC 2863: The Interfaces Group MIB - ifStackTable"; 892 } 894 leaf-list lower-layer-if { 895 type interface-state-ref; 896 description 897 "A list of references to interfaces layered underneath this 898 interface."; 899 reference 900 "RFC 2863: The Interfaces Group MIB - ifStackTable"; 901 } 903 leaf speed { 904 type yang:gauge64; 905 units "bits / second"; 906 description 907 "An estimate of the interface's current bandwidth in bits 908 per second. For interfaces that do not vary in 909 bandwidth or for those where no accurate estimation can 910 be made, this node should contain the nominal bandwidth. 911 For interfaces that have no concept of bandwidth, this 912 node is not present."; 913 reference 914 "RFC 2863: The Interfaces Group MIB - 915 ifSpeed, ifHighSpeed"; 916 } 918 container statistics { 919 description 920 "A collection of interface-related statistics objects."; 922 leaf discontinuity-time { 923 type yang:date-and-time; 924 mandatory true; 925 description 926 "The time on the most recent occasion at which any one or 927 more of this interface's counters suffered a 928 discontinuity. If no such discontinuities have occurred 929 since the last re-initialization of the local management 930 subsystem, then this node contains the time the local 931 management subsystem re-initialized itself."; 932 } 934 leaf in-octets { 935 type yang:counter64; 936 description 937 "The total number of octets received on the interface, 938 including framing characters. 940 Discontinuities in the value of this counter can occur 941 at re-initialization of the management system, and at 942 other times as indicated by the value of 943 'discontinuity-time'."; 944 reference 945 "RFC 2863: The Interfaces Group MIB - ifHCInOctets"; 946 } 947 leaf in-unicast-pkts { 948 type yang:counter64; 949 description 950 "The number of packets, delivered by this sub-layer to a 951 higher (sub-)layer, which were not addressed to a 952 multicast or broadcast address at this sub-layer. 954 Discontinuities in the value of this counter can occur 955 at re-initialization of the management system, and at 956 other times as indicated by the value of 957 'discontinuity-time'."; 958 reference 959 "RFC 2863: The Interfaces Group MIB - ifHCInUcastPkts"; 960 } 961 leaf in-broadcast-pkts { 962 type yang:counter64; 963 description 964 "The number of packets, delivered by this sub-layer to a 965 higher (sub-)layer, which were addressed to a broadcast 966 address at this sub-layer. 968 Discontinuities in the value of this counter can occur 969 at re-initialization of the management system, and at 970 other times as indicated by the value of 971 'discontinuity-time'."; 972 reference 973 "RFC 2863: The Interfaces Group MIB - 974 ifHCInBroadcastPkts"; 975 } 976 leaf in-multicast-pkts { 977 type yang:counter64; 978 description 979 "The number of packets, delivered by this sub-layer to a 980 higher (sub-)layer, which were addressed to a multicast 981 address at this sub-layer. For a MAC layer protocol, 982 this includes both Group and Functional addresses. 984 Discontinuities in the value of this counter can occur 985 at re-initialization of the management system, and at 986 other times as indicated by the value of 987 'discontinuity-time'."; 988 reference 989 "RFC 2863: The Interfaces Group MIB - 990 ifHCInMulticastPkts"; 991 } 992 leaf in-discards { 993 type yang:counter32; 994 description 995 "The number of inbound packets which were chosen to be 996 discarded even though no errors had been detected to 997 prevent their being deliverable to a higher-layer 998 protocol. One possible reason for discarding such a 999 packet could be to free up buffer space. 1001 Discontinuities in the value of this counter can occur 1002 at re-initialization of the management system, and at 1003 other times as indicated by the value of 1004 'discontinuity-time'."; 1005 reference 1006 "RFC 2863: The Interfaces Group MIB - ifInDiscards"; 1007 } 1008 leaf in-errors { 1009 type yang:counter32; 1010 description 1011 "For packet-oriented interfaces, the number of inbound 1012 packets that contained errors preventing them from being 1013 deliverable to a higher-layer protocol. For character- 1014 oriented or fixed-length interfaces, the number of 1015 inbound transmission units that contained errors 1016 preventing them from being deliverable to a higher-layer 1017 protocol. 1019 Discontinuities in the value of this counter can occur 1020 at re-initialization of the management system, and at 1021 other times as indicated by the value of 1022 'discontinuity-time'."; 1023 reference 1024 "RFC 2863: The Interfaces Group MIB - ifInErrors"; 1025 } 1026 leaf in-unknown-protos { 1027 type yang:counter32; 1028 description 1029 "For packet-oriented interfaces, the number of packets 1030 received via the interface which were discarded because 1031 of an unknown or unsupported protocol. For 1032 character-oriented or fixed-length interfaces that 1033 support protocol multiplexing the number of transmission 1034 units received via the interface which were discarded 1035 because of an unknown or unsupported protocol. For any 1036 interface that does not support protocol multiplexing, 1037 this counter is not present. 1039 Discontinuities in the value of this counter can occur 1040 at re-initialization of the management system, and at 1041 other times as indicated by the value of 1042 'discontinuity-time'."; 1043 reference 1044 "RFC 2863: The Interfaces Group MIB - ifInUnknownProtos"; 1045 } 1047 leaf out-octets { 1048 type yang:counter64; 1049 description 1050 "The total number of octets transmitted out of the 1051 interface, including framing characters. 1053 Discontinuities in the value of this counter can occur 1054 at re-initialization of the management system, and at 1055 other times as indicated by the value of 1056 'discontinuity-time'."; 1057 reference 1058 "RFC 2863: The Interfaces Group MIB - ifHCOutOctets"; 1059 } 1060 leaf out-unicast-pkts { 1061 type yang:counter64; 1062 description 1063 "The total number of packets that higher-level protocols 1064 requested be transmitted, and which were not addressed 1065 to a multicast or broadcast address at this sub-layer, 1066 including those that were discarded or not sent. 1068 Discontinuities in the value of this counter can occur 1069 at re-initialization of the management system, and at 1070 other times as indicated by the value of 1071 'discontinuity-time'."; 1072 reference 1073 "RFC 2863: The Interfaces Group MIB - ifHCOutUcastPkts"; 1074 } 1075 leaf out-broadcast-pkts { 1076 type yang:counter64; 1077 description 1078 "The total number of packets that higher-level protocols 1079 requested be transmitted, and which were addressed to a 1080 broadcast address at this sub-layer, including those 1081 that were discarded or not sent. 1083 Discontinuities in the value of this counter can occur 1084 at re-initialization of the management system, and at 1085 other times as indicated by the value of 1086 'discontinuity-time'."; 1087 reference 1088 "RFC 2863: The Interfaces Group MIB - 1089 ifHCOutBroadcastPkts"; 1090 } 1091 leaf out-multicast-pkts { 1092 type yang:counter64; 1093 description 1094 "The total number of packets that higher-level protocols 1095 requested be transmitted, and which were addressed to a 1096 multicast address at this sub-layer, including those 1097 that were discarded or not sent. For a MAC layer 1098 protocol, this includes both Group and Functional 1099 addresses. 1101 Discontinuities in the value of this counter can occur 1102 at re-initialization of the management system, and at 1103 other times as indicated by the value of 1104 'discontinuity-time'."; 1105 reference 1106 "RFC 2863: The Interfaces Group MIB - 1107 ifHCOutMulticastPkts"; 1108 } 1109 leaf out-discards { 1110 type yang:counter32; 1111 description 1112 "The number of outbound packets which were chosen to be 1113 discarded even though no errors had been detected to 1114 prevent their being transmitted. One possible reason 1115 for discarding such a packet could be to free up buffer 1116 space. 1118 Discontinuities in the value of this counter can occur 1119 at re-initialization of the management system, and at 1120 other times as indicated by the value of 1121 'discontinuity-time'."; 1122 reference 1123 "RFC 2863: The Interfaces Group MIB - ifOutDiscards"; 1124 } 1125 leaf out-errors { 1126 type yang:counter32; 1127 description 1128 "For packet-oriented interfaces, the number of outbound 1129 packets that could not be transmitted because of errors. 1130 For character-oriented or fixed-length interfaces, the 1131 number of outbound transmission units that could not be 1132 transmitted because of errors. 1134 Discontinuities in the value of this counter can occur 1135 at re-initialization of the management system, and at 1136 other times as indicated by the value of 1137 'discontinuity-time'."; 1138 reference 1139 "RFC 2863: The Interfaces Group MIB - ifOutErrors"; 1140 } 1141 } 1142 } 1143 } 1144 } 1146 1148 6. IANA Considerations 1150 This document registers a URI in the IETF XML registry [RFC3688]. 1151 Following the format in RFC 3688, the following registration is 1152 requested to be made. 1154 URI: urn:ietf:params:xml:ns:yang:ietf-interfaces 1156 Registrant Contact: The IESG. 1158 XML: N/A, the requested URI is an XML namespace. 1160 This document registers a YANG module in the YANG Module Names 1161 registry [RFC6020]. 1163 name: ietf-interfaces 1164 namespace: urn:ietf:params:xml:ns:yang:ietf-interfaces 1165 prefix: if 1166 reference: RFC XXXX 1168 7. Security Considerations 1170 The YANG module defined in this memo is designed to be accessed via 1171 the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the 1172 secure transport layer and the mandatory-to-implement secure 1173 transport is SSH [RFC6242]. The NETCONF access control model 1174 [RFC6536] provides the means to restrict access for particular 1175 NETCONF users to a pre-configured subset of all available NETCONF 1176 protocol operations and content. 1178 There are a number of data nodes defined in the YANG module which are 1179 writable/creatable/deletable (i.e., config true, which is the 1180 default). These data nodes may be considered sensitive or vulnerable 1181 in some network environments. Write operations (e.g., ) 1182 to these data nodes without proper protection can have a negative 1183 effect on network operations. These are the subtrees and data nodes 1184 and their sensitivity/vulnerability: 1186 /interfaces/interface: This list specifies the configured interfaces 1187 on a device. Unauthorized access to this list could cause the 1188 device to ignore packets it should receive and process. 1190 /interfaces/interface/enabled: This leaf controls if an interface is 1191 enabled or not. Unauthorized access to this leaf could cause the 1192 device to ignore packets it should receive and process. 1194 8. Acknowledgments 1196 The author wishes to thank Alexander Clemm, Per Hedeland, Ladislav 1197 Lhotka, and Juergen Schoenwaelder for their helpful comments. 1199 9. References 1201 9.1. Normative References 1203 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1204 Requirement Levels", BCP 14, RFC 2119, March 1997. 1206 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 1207 MIB", RFC 2863, June 2000. 1209 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1210 January 2004. 1212 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 1213 Network Configuration Protocol (NETCONF)", RFC 6020, 1214 October 2010. 1216 [RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991, 1217 July 2013. 1219 9.2. Informative References 1221 [I-D.ietf-netmod-iana-if-type] 1222 Bjorklund, M., "IANA Interface Type YANG Module", 1223 draft-ietf-netmod-iana-if-type-08 (work in progress), 1224 November 2013. 1226 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 1227 Bierman, "Network Configuration Protocol (NETCONF)", 1228 RFC 6241, June 2011. 1230 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1231 Shell (SSH)", RFC 6242, June 2011. 1233 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1234 Protocol (NETCONF) Access Control Model", RFC 6536, 1235 March 2012. 1237 Appendix A. Example: Ethernet Interface Module 1239 This section gives a simple example of how an Ethernet interface 1240 module could be defined. It demonstrates how media-specific 1241 configuration parameters can be conditionally augmented to the 1242 generic interface list. It also shows how operational state 1243 parameters can be conditionally augmented to the operational 1244 interface list. The example is not intended as a complete module for 1245 ethernet configuration. 1247 module ex-ethernet { 1248 namespace "http://example.com/ethernet"; 1249 prefix "eth"; 1251 import ietf-interfaces { 1252 prefix if; 1253 } 1254 import iana-if-type { 1255 prefix ianaift; 1256 } 1258 // configuration parameters for ethernet interfaces 1259 augment "/if:interfaces/if:interface" { 1260 when "if:type = 'ianaift:ethernetCsmacd'"; 1262 container ethernet { 1263 choice transmission-params { 1264 case auto { 1265 leaf auto-negotiate { 1266 type empty; 1267 } 1268 } 1269 case manual { 1270 leaf duplex { 1271 type enumeration { 1272 enum "half"; 1273 enum "full"; 1274 } 1275 } 1276 leaf speed { 1277 type enumeration { 1278 enum "10Mb"; 1279 enum "100Mb"; 1280 enum "1Gb"; 1281 enum "10Gb"; 1282 } 1283 } 1284 } 1286 } 1287 // other ethernet specific params... 1288 } 1289 } 1291 // operational state parameters for ethernet interfaces 1292 augment "/if:interfaces-state/if:interface" { 1293 when "if:type = 'ianaift:ethernetCsmacd'"; 1295 container ethernet { 1296 leaf duplex { 1297 type enumeration { 1298 enum "half"; 1299 enum "full"; 1300 } 1301 } 1302 // other ethernet specific params... 1303 } 1304 } 1305 } 1307 Appendix B. Example: Ethernet Bonding Interface Module 1309 This section gives an example of how interface layering can be 1310 defined. An ethernet bonding interface is defined, which bonds 1311 several ethernet interfaces into one logical interface. 1313 module ex-ethernet-bonding { 1314 namespace "http://example.com/ethernet-bonding"; 1315 prefix "bond"; 1317 import ietf-interfaces { 1318 prefix if; 1319 } 1320 import iana-if-type { 1321 prefix ianaift; 1322 } 1324 augment "/if:interfaces/if:interface" { 1325 when "if:type = 'ianaift:ieee8023adLag'"; 1327 leaf-list slave-if { 1328 type if:interface-ref; 1329 must "/if:interfaces/if:interface[if:name = current()]" 1330 + "/if:type = 'ianaift:ethernetCsmacd'" { 1331 description 1332 "The type of a slave interface must be ethernet."; 1333 } 1334 } 1335 leaf bonding-mode { 1336 type enumeration { 1337 enum round-robin; 1338 enum active-backup; 1339 enum broadcast; 1340 } 1341 } 1342 // other bonding config params, failover times etc. 1343 } 1344 } 1346 Appendix C. Example: VLAN Interface Module 1348 This section gives an example of how a vlan interface module can be 1349 defined. 1351 module ex-vlan { 1352 namespace "http://example.com/vlan"; 1353 prefix "vlan"; 1355 import ietf-interfaces { 1356 prefix if; 1357 } 1358 import iana-if-type { 1359 prefix ianaift; 1360 } 1361 import ex-ethernet { 1362 prefix eth; 1363 } 1365 augment "/if:interfaces/if:interface" { 1366 when "if:type = 'ianaift:ethernetCsmacd' or 1367 if:type = 'ianaift:ieee8023adLag'"; 1368 leaf vlan-tagging { 1369 type boolean; 1370 default false; 1371 } 1372 } 1374 augment "/if:interfaces/if:interface" { 1375 when "if:type = 'ianaift:l2vlan'"; 1377 leaf base-interface { 1378 type if:interface-ref; 1379 must "/if:interfaces/if:interface[if:name = current()]" 1380 + "/vlan:vlan-tagging = 'true'" { 1381 description 1382 "The base interface must have vlan tagging enabled."; 1383 } 1384 } 1385 leaf vlan-id { 1386 type uint16 { 1387 range "1..4094"; 1388 } 1389 must "../base-interface" { 1390 description 1391 "If a vlan-id is defined, a base-interface must 1392 be specified."; 1393 } 1394 } 1395 } 1396 } 1398 Appendix D. Example: NETCONF reply 1400 This section gives an example of a reply to the NETCONF request 1401 for a device that implements the example data models above. 1403 1406 1408 1413 1414 eth0 1415 ianaift:ethernetCsmacd 1416 false 1417 1419 1420 eth1 1421 ianaift:ethernetCsmacd 1422 true 1423 true 1424 1426 1427 eth1.10 1428 ianaift:l2vlan 1429 true 1430 eth1 1431 10 1432 1434 1435 lo1 1436 ianaift:softwareLoopback 1437 true 1438 1440 1442 1446 1447 eth0 1448 ianaift:ethernetCsmacd 1449 down 1450 down 1451 2 1452 00:01:02:03:04:05 1453 1454 1455 2013-04-01T03:00:00+00:00 1456 1457 1458 1459 1461 1462 eth1 1463 ianaift:ethernetCsmacd 1464 up 1465 up 1466 7 1467 00:01:02:03:04:06 1468 eth1.10 1469 1470 1471 2013-04-01T03:00:00+00:00 1472 1473 1474 1475 1477 1478 eth1.10 1479 ianaift:l2vlan 1480 up 1481 up 1482 9 1483 eth1 1484 1485 1486 2013-04-01T03:00:00+00:00 1487 1488 1489 1490 1492 1493 1494 eth2 1495 ianaift:ethernetCsmacd 1496 down 1497 down 1498 8 1499 00:01:02:03:04:07 1500 1501 1502 2013-04-01T03:00:00+00:00 1503 1504 1505 1506 1508 1509 lo1 1510 ianaift:softwareLoopback 1511 up 1512 up 1513 1 1514 1515 1516 2013-04-01T03:00:00+00:00 1517 1518 1519 1520 1522 1523 1524 1526 Appendix E. Examples: Interface Naming Schemes 1528 This section gives examples of some implementation strategies. 1530 The examples make use of the example data model "ex-vlan" (see 1531 Appendix C) to show how user-controlled interfaces can be configured. 1533 E.1. Router with Restricted Interface Names 1535 In this example, a router has support for 4 line cards, each with 8 1536 ports. The slots for the cards are physically numbered from 0 to 3, 1537 and the ports on each card from 0 to 7. Each card has fast- or 1538 gigabit-ethernet ports. 1540 The device-specific names for these physical interfaces are 1541 "fastethernet-N/M" or "gigabitethernet-N/M". 1543 The name of a vlan interface is restricted to the form 1544 ".". 1546 It is assumed that the operator is aware of this naming scheme. The 1547 implementation auto-initializes the value for "type" based on the 1548 interface name. 1550 The NETCONF server does not advertise the 'arbitrary-names' feature 1551 in the message. 1553 An operator can configure a physical interface by sending an 1554 containing: 1556 1557 fastethernet-1/0 1558 1560 When the server processes this request, it will set the leaf "type" 1561 to "ianaift:ethernetCsmacd". Thus, if the client performs a 1562 right after the above, it will get: 1564 1565 fastethernet-1/0 1566 ianaift:ethernetCsmacd 1567 1569 The client can configure a vlan interface by sending an 1570 containing: 1572 1573 fastethernet-1/0.10005 1574 ianaift:l2vlan 1575 fastethernet-1/0 1576 5 1577 1579 If the client tries to change the type of the physical interface with 1580 an containing: 1582 1583 fastethernet-1/0 1584 ianaift:tunnel 1585 1587 then the server will reply with an "invalid-value" error, since the 1588 new type does not match the name. 1590 E.2. Router with Arbitrary Interface Names 1592 In this example, a router has support for 4 line cards, each with 8 1593 ports. The slots for the cards are physically numbered from 0 to 3, 1594 and the ports on each card from 0 to 7. Each card has fast- or 1595 gigabit-ethernet ports. 1597 The device-specific names for these physical interfaces are 1598 "fastethernet-N/M" or "gigabitethernet-N/M". 1600 The implementation does not restrict the user-controlled interface 1601 names. This allows to more easily apply the interface configuration 1602 to a different interface. However, the additional level of 1603 indirection also makes it a bit more complex to map interface names 1604 found in other protocols to configuration entries. 1606 The NETCONF server advertises the 'arbitrary-names' feature in the 1607 message. 1609 Physical interfaces are configured as in Appendix E.1. 1611 An operator can configure a VLAN interface by sending an 1612 containing: 1614 1615 acme-interface 1616 ianaift:l2vlan 1617 fastethernet-1/0 1618 5 1619 1621 If necessary, the operator can move the configuration named 1622 "acme-interface" over to a different physical interface with an 1623 containing: 1625 1626 acme-interface 1627 fastethernet-1/1 1628 1630 E.3. Ethernet Switch with Restricted Interface Names 1632 In this example, an ethernet switch has a number of ports, each port 1633 identified by a simple port number. 1635 The device-specific names for the physical interfaces are numbers 1636 that match the physical port number. 1638 An operator can configure a physical interface by sending an 1639 containing: 1641 1642 6 1643 1645 When the server processes this request, it will set the leaf "type" 1646 to "ianaift:ethernetCsmacd". Thus, if the client performs a 1647 right after the above, it will get: 1649 1650 6 1651 ianaift:ethernetCsmacd 1652 1654 E.4. Generic Host with Restricted Interface Names 1656 In this example, a generic host has interfaces named by the kernel. 1657 The system identifies the physical interface by the name assigned by 1658 the operating system to the interface. 1660 The name of a vlan interface is restricted to the form 1661 ":". 1663 The NETCONF server does not advertise the 'arbitrary-names' feature 1664 in the message. 1666 An operator can configure an interface by sending an 1667 containing: 1669 1670 eth8 1671 1673 When the server processes this request, it will set the leaf "type" 1674 to "ianaift:ethernetCsmacd". Thus, if the client performs a 1675 right after the above, it will get: 1677 1678 eth8 1679 ianaift:ethernetCsmacd 1680 1682 The client can configure a vlan interface by sending an 1683 containing: 1685 1686 eth8:5 1687 ianaift:l2vlan 1688 eth8 1689 5 1690 1692 E.5. Generic Host with Arbitrary Interface Names 1694 In this example, a generic host has interfaces named by the kernel. 1695 The system identifies the physical interface by the name assigned by 1696 the operating system to the interface. 1698 The implementation does not restrict the user-controlled interface 1699 names. This allows to more easily apply the interface configuration 1700 to a different interface. However, the additional level of 1701 indirection also makes it a bit more complex to map interface names 1702 found in other protocols to configuration entries. 1704 The NETCONF server advertises the 'arbitrary-names' feature in the 1705 message. 1707 Physical interfaces are configured as in Appendix E.4. 1709 An operator can configure a VLAN interface by sending an 1710 containing: 1712 1713 acme-interface 1714 ianaift:l2vlan 1715 eth8 1716 5 1718 1720 If necessary, the operator can move the configuration named 1721 "acme-interface" over to a different physical interface with an 1722 containing: 1724 1725 acme-interface 1726 eth3 1727 1729 Appendix F. ChangeLog 1731 RFC Editor: remove this section upon publication as an RFC. 1733 F.1. Version -13 1735 o Made the interface type an identity, instead of an enumseration. 1737 F.2. Version -11 1739 o Separated the operational state from the configuration. 1741 o Removed 'location', and instead use the name to identify physical 1742 interfaces. 1744 o Added the feature 'pre-provisioning'. 1746 o Made 'oper-status' and 'if-index' mandatory in the data model. 1748 o Added 'admin-status'. 1750 o Clarified why description can be mapped to ifAlias. 1752 o Clarified that 64-bit counters only are used, where there exist 1753 64-bit and 32-bit counters in IF-MIB. 1755 o Updated Security Considerations section with a reference to NACM. 1757 F.3. Version -08 1759 o Removed the mtu leaf. 1761 o Added examples of different interface naming schemes. 1763 F.4. Version -07 1765 o Made leaf speed config false. 1767 F.5. Version -06 1769 o Added oper-status leaf. 1771 o Added leaf-lists higher-layer-if and lower-layer-if, that show the 1772 interface layering. 1774 o Added container statistics with counters. 1776 F.6. Version -05 1778 o Added an Informative References section. 1780 o Updated the Security Considerations section. 1782 o Clarified the behavior of an NETCONF server when invalid values 1783 are received. 1785 F.7. Version -04 1787 o Clarified why ifPromiscuousMode is not part of this data model. 1789 o Added a table that shows the mapping between this YANG data model 1790 and IF-MIB. 1792 F.8. Version -03 1794 o Added the section Relationship to the IF-MIB. 1796 o Changed if-index to be a leaf instead of leaf-list. 1798 o Explained the notation used in the data model tree picture. 1800 F.9. Version -02 1802 o Editorial fixes 1804 F.10. Version -01 1806 o Changed leaf "if-admin-status" to leaf "enabled". 1808 o Added Security Considerations 1810 Author's Address 1812 Martin Bjorklund 1813 Tail-f Systems 1815 Email: mbj@tail-f.com