idnits 2.17.1 draft-ietf-netmod-interfaces-cfg-15.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 236 has weird spacing: '...ty-time yan...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (December 23, 2013) is 3770 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 December 23, 2013 5 Expires: June 26, 2014 7 A YANG Data Model for Interface Management 8 draft-ietf-netmod-interfaces-cfg-15 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 June 26, 2014. 35 Copyright Notice 37 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . 9 61 5. Interfaces YANG Module . . . . . . . . . . . . . . . . . . . . 11 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 64 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 65 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 66 9.1. Normative References . . . . . . . . . . . . . . . . . . . 29 67 9.2. Informative References . . . . . . . . . . . . . . . . . . 29 68 Appendix A. Example: Ethernet Interface Module . . . . . . . . . 30 69 Appendix B. Example: Ethernet Bonding Interface Module . . . . . 32 70 Appendix C. Example: VLAN Interface Module . . . . . . . . . . . 33 71 Appendix D. Example: NETCONF reply . . . . . . . . . . . . 35 72 Appendix E. Examples: Interface Naming Schemes . . . . . . . . . 38 73 E.1. Router with Restricted Interface Names . . . . . . . . . . 38 74 E.2. Router with Arbitrary Interface Names . . . . . . . . . . 39 75 E.3. Ethernet Switch with Restricted Interface Names . . . . . 40 76 E.4. Generic Host with Restricted Interface Names . . . . . . . 40 77 E.5. Generic Host with Arbitrary Interface Names . . . . . . . 41 78 Appendix F. ChangeLog . . . . . . . . . . . . . . . . . . . . . . 43 79 F.1. Version -13 . . . . . . . . . . . . . . . . . . . . . . . 43 80 F.2. Version -11 . . . . . . . . . . . . . . . . . . . . . . . 43 81 F.3. Version -08 . . . . . . . . . . . . . . . . . . . . . . . 43 82 F.4. Version -07 . . . . . . . . . . . . . . . . . . . . . . . 43 83 F.5. Version -06 . . . . . . . . . . . . . . . . . . . . . . . 43 84 F.6. Version -05 . . . . . . . . . . . . . . . . . . . . . . . 44 85 F.7. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 44 86 F.8. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 44 87 F.9. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 44 88 F.10. Version -01 . . . . . . . . . . . . . . . . . . . . . . . 44 89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 45 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) is added or removed. 119 System-controlled interfaces may also appear if a certain 120 functionality is enabled (e.g., a loopback interface might appear 121 if the IP protocol stack is enabled). 123 o user-controlled interface: An interface is said to be user- 124 controlled if the creation of the interface is controlled by 125 adding explicit interface configuration to the running 126 configuration datastore and the removal of the interface is 127 controlled by removing explicit interface configuration from the 128 running configuration datastore. Examples are VLAN interfaces 129 configured on a system-controlled Ethernet interface. 131 The following terms are defined in [RFC6241] and are not redefined 132 here: 134 o client 136 o configuration data 137 o server 139 o state data 141 The following terms are defined in [RFC6020] and are not redefined 142 here: 144 o augment 146 o data model 148 o data node 150 o presence container 152 1.2. Tree Diagrams 154 A simplified graphical representation of the data model is used in 155 this document. The meaning of the symbols in these diagrams is as 156 follows: 158 o Brackets "[" and "]" enclose list keys. 160 o Abbreviations before data node names: "rw" means configuration 161 (read-write) and "ro" state data (read-only). 163 o Symbols after data node names: "?" means an optional node, "!" 164 means a presence container, and "*" denotes a list and leaf-list. 166 o Parentheses enclose choice and case nodes, and case nodes are also 167 marked with a colon (":"). 169 o Ellipsis ("...") stands for contents of subtrees that are not 170 shown. 172 2. Objectives 174 This section describes some of the design objectives for the model 175 presented in Section 5. 177 o It is recognized that existing implementations will have to map 178 the interface data model defined in this memo to their proprietary 179 native data model. The data model should be simple to facilitate 180 such mappings. 182 o The data model should be suitable for new implementations to use 183 as-is, without requiring a mapping to a different native model. 185 o References to interfaces should be as simple as possible, 186 preferably by using a single leafref. 188 o The mapping to ifIndex [RFC2863] used by SNMP to identify 189 interfaces must be clear. 191 o The model must support interface layering, both simple layering 192 where one interface is layered on top of exactly one other 193 interface, and more complex scenarios where one interface results 194 from the aggregation of N other interfaces, or when N interfaces 195 are multiplexed over one other interface. 197 o The data model should support the pre-provisioning of interface 198 configuration, i.e., it should be possible to configure an 199 interface whose physical interface hardware is not present on the 200 device. It is recommended that devices that support dynamic 201 addition and removal of physical interfaces also support pre- 202 provisioning. 204 o The data model should support both physical interfaces as well as 205 logical interfaces. 207 o The data model should include read-only counters in order to 208 gather statistics for octets, packets and errors, sent and 209 received. 211 3. Interfaces Data Model 213 This document defines the YANG module "ietf-interfaces", which has 214 the following structure: 216 +--rw interfaces 217 | +--rw interface* [name] 218 | +--rw name string 219 | +--rw description? string 220 | +--rw type identityref 221 | +--rw enabled? boolean 222 | +--rw link-up-down-trap-enable? enumeration 223 +--ro interfaces-state 224 +--ro interface* [name] 225 +--ro name string 226 +--ro type identityref 227 +--ro admin-status enumeration 228 +--ro oper-status enumeration 229 +--ro last-change? yang:date-and-time 230 +--ro if-index int32 231 +--ro phys-address? yang:phys-address 232 +--ro higher-layer-if* interface-state-ref 233 +--ro lower-layer-if* interface-state-ref 234 +--ro speed? yang:gauge64 235 +--ro statistics 236 +--ro discontinuity-time yang:date-and-time 237 +--ro in-octets? yang:counter64 238 +--ro in-unicast-pkts? yang:counter64 239 +--ro in-broadcast-pkts? yang:counter64 240 +--ro in-multicast-pkts? yang:counter64 241 +--ro in-discards? yang:counter32 242 +--ro in-errors? yang:counter32 243 +--ro in-unknown-protos? yang:counter32 244 +--ro out-octets? yang:counter64 245 +--ro out-unicast-pkts? yang:counter64 246 +--ro out-broadcast-pkts? yang:counter64 247 +--ro out-multicast-pkts? yang:counter64 248 +--ro out-discards? yang:counter32 249 +--ro out-errors? yang:counter32 251 3.1. The interface Lists 253 The data model for interfaces presented in this document uses a flat 254 list of interfaces. Each interface in the list is identified by its 255 name. Furthermore, each interface has a mandatory "type" leaf. 257 The "iana-if-type" module [I-D.ietf-netmod-iana-if-type] defines YANG 258 identities for the interface types in the IANA-maintained "ifType 259 registry". 261 There is one list of configured interfaces ("/interfaces/interface"), 262 and a separate list for the operational state of all interfaces 263 ("/interfaces-state/interface"). 265 It is expected that interface type specific data models augment the 266 interface lists, and possibly use the "type" leaf to make the 267 augmentation conditional. 269 As an example of such an interface type specific augmentation, 270 consider this YANG snippet. For a more complete example, see 271 Appendix A. 273 import interfaces { 274 prefix "if"; 275 } 276 import iana-if-type { 277 prefix ianaift; 278 } 280 augment "/if:interfaces/if:interface" { 281 when "if:type = 'ianaift:ethernetCsmacd'"; 283 container ethernet { 284 leaf duplex { 285 ... 286 } 287 } 288 } 290 For system-controlled interfaces, the "name" is the device-specific 291 name of the interface. The 'config false' list "/interfaces-state/ 292 interface" contains all existing interfaces on the device. 294 If the device supports arbitrarily named user-controlled interfaces, 295 the NETCONF server advertises the feature "arbitrary-names". If the 296 device does not advertise this feature, the names of user-controlled 297 interfaces MUST match the device's naming scheme. How a client can 298 learn the naming scheme of such devices is outside the scope of this 299 document. See Appendix E.1 and Appendix E.2 for examples. 301 When a system-controlled interface is created by the system, the 302 system tries to apply the interface configuration in "/interfaces/ 303 interface" with the same name as the new interface. If no such 304 interface configuration is found, or if the configured type does not 305 match the real interface type, the system creates the interface 306 without applying explicit configuration. 308 When a user-controlled interface is created, the configuration 309 determines the name of the interface. 311 3.2. Interface References 313 An interface is identified by its name, which is unique within the 314 server. This property is captured in the "interface-ref" and 315 "interface-state-ref" typedefs, which other YANG modules SHOULD use 316 when they need to reference a configured interface or operationally 317 used interface, respectively. 319 3.3. Interface Layering 321 There is no generic mechanism for how an interface is configured to 322 be layered on top of some other interface. It is expected that 323 interface type specific models define their own data nodes for 324 interface layering, by using "interface-ref" types to reference lower 325 layers. 327 Below is an example of a model with such nodes. For a more complete 328 example, see Appendix B. 330 import interfaces { 331 prefix "if"; 332 } 333 import iana-if-type { 334 prefix ianaift; 335 } 337 augment "/if:interfaces/if:interface" { 338 when "if:type = 'ianaift:ieee8023adLag'"; 340 leaf-list slave-if { 341 type if:interface-ref; 342 must "/if:interfaces/if:interface[if:name = current()]" 343 + "/if:type = 'ianaift:ethernetCsmacd'" { 344 description 345 "The type of a slave interface must be ethernet"; 346 } 347 } 348 // other bonding config params, failover times etc. 349 } 351 While the interface layering is configured in type specific models, 352 two generic state data leaf-lists, "higher-layer-if" and 353 "lower-layer-if", represent a read-only view of the interface 354 layering hierarchy. 356 4. Relationship to the IF-MIB 358 If the device implements IF-MIB [RFC2863], each entry in the 359 "/interfaces-state/interface" list is typically mapped to one 360 ifEntry. The "if-index" leaf MUST contain the value of the 361 corresponding ifEntry's ifIndex. 363 In most cases, the "name" of an "/interfaces-state/interface" entry 364 is mapped to ifName. The IF-MIB allows two different ifEntries to 365 have the same ifName. Devices that support this feature, and also 366 support the data model defined in this document, cannot have a 1-1 367 mapping between the "name" leaf and ifName. 369 The configured "description" of an "interface" has traditionally been 370 mapped to ifAlias in some implementations. This document allows this 371 mapping, but implementers should be aware of the differences in the 372 value space and persistence for these objects. See the YANG module 373 definition of the leaf "description" in Section 5 for details. 375 The IF-MIB also defines the writable object ifPromiscuousMode. Since 376 this object typically is not a configuration object, it is not mapped 377 to the "ietf-interfaces" module. 379 There are a number of counters in the IF-MIB that exist in two 380 versions; one with 32 bits and one with 64 bits. The 64-bit versions 381 were added to support high-speed interfaces with a data rate greater 382 than 20,000,000 bits/second. Today's implementations generally 383 support such high-speed interfaces and hence only 64-bit counters are 384 provided in this data model. Note that NETCONF and SNMP may differ 385 in the time granularity in which they provide access to the counters. 386 For example, it is common that SNMP implementations cache counter 387 values for some time. 389 The following tables list the YANG data nodes with corresponding 390 objects in the IF-MIB. 392 +------------------------------------------+------------------------+ 393 | YANG data node in | IF-MIB object | 394 | /interfaces-state/interface | | 395 +------------------------------------------+------------------------+ 396 | name | ifName | 397 | type | ifType | 398 | admin-status | ifAdminStatus | 399 | oper-status | ifOperStatus | 400 | last-change | ifLastChange | 401 | if-index | ifIndex | 402 | link-up-down-trap-enable | ifLinkUpDownTrapEnable | 403 | phys-address | ifPhysAddress | 404 | higher-layer-if / lower-layer-if | ifStackTable | 405 | speed | ifSpeed | 406 | in-octets | ifHCInOctets | 407 | in-unicast-pkts | ifHCInUcastPkts | 408 | in-broadcast-pkts | ifHCInBroadcastPkts | 409 | in-multicast-pkts | ifHCInMulticastPkts | 410 | in-discards | ifInDiscards | 411 | in-errors | ifInErrors | 412 | in-unknown-protos | ifInUnknownProtos | 413 | out-octets | ifHCOutOctets | 414 | out-unicast-pkts | ifHCOutUcastPkts | 415 | out-broadcast-pkts | ifHCOutBroadcastPkts | 416 | out-multicast-pkts | ifHCOutMulticastPkts | 417 | out-discards | ifOutDiscards | 418 | out-errors | ifOutErrors | 419 +------------------------------------------+------------------------+ 421 YANG state data nodes and related IF-MIB objects 423 +-----------------------------------------+---------------+ 424 | YANG data node in /interfaces/interface | IF-MIB object | 425 +-----------------------------------------+---------------+ 426 | description | ifAlias | 427 +-----------------------------------------+---------------+ 429 YANG config data nodes and related IF-MIB objects 431 5. Interfaces YANG Module 433 This YANG module imports typedefs from [RFC6991]. 435 RFC Ed.: update the date below with the date of RFC publication and 436 remove this note. 438 file "ietf-interfaces@2013-12-23.yang" 440 module ietf-interfaces { 442 namespace "urn:ietf:params:xml:ns:yang:ietf-interfaces"; 443 prefix if; 445 import ietf-yang-types { 446 prefix yang; 447 } 449 organization 450 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 452 contact 453 "WG Web: 454 WG List: 456 WG Chair: David Kessens 457 459 WG Chair: Juergen Schoenwaelder 460 462 Editor: Martin Bjorklund 463 "; 465 description 466 "This module contains a collection of YANG definitions for 467 managing network interfaces. 469 Copyright (c) 2013 IETF Trust and the persons identified as 470 authors of the code. All rights reserved. 472 Redistribution and use in source and binary forms, with or 473 without modification, is permitted pursuant to, and subject 474 to the license terms contained in, the Simplified BSD License 475 set forth in Section 4.c of the IETF Trust's Legal Provisions 476 Relating to IETF Documents 477 (http://trustee.ietf.org/license-info). 478 This version of this YANG module is part of RFC XXXX; see 479 the RFC itself for full legal notices."; 481 // RFC Ed.: replace XXXX with actual RFC number and remove this 482 // note. 484 // RFC Ed.: update the date below with the date of RFC publication 485 // and remove this note. 486 revision 2013-12-23 { 487 description 488 "Initial revision."; 489 reference 490 "RFC XXXX: A YANG Data Model for Interface Management"; 491 } 493 /* 494 * Typedefs 495 */ 497 typedef interface-ref { 498 type leafref { 499 path "/if:interfaces/if:interface/if:name"; 500 } 501 description 502 "This type is used by data models that need to reference 503 configured interfaces."; 504 } 506 typedef interface-state-ref { 507 type leafref { 508 path "/if:interfaces-state/if:interface/if:name"; 509 } 510 description 511 "This type is used by data models that need to reference 512 the operationally present interfaces."; 513 } 515 /* 516 * Identities 517 */ 519 identity interface-type { 520 description 521 "Base identity from which specific interface types are 522 derived."; 523 } 525 /* 526 * Features 527 */ 529 feature arbitrary-names { 530 description 531 "This feature indicates that the device allows user-controlled 532 interfaces to be named arbitrarily."; 533 } 535 feature pre-provisioning { 536 description 537 "This feature indicates that the device supports 538 pre-provisioning of interface configuration, i.e., it is 539 possible to configure an interface whose physical interface 540 hardware is not present on the device."; 541 } 543 feature if-mib { 544 description 545 "This feature indicates that the device implements IF-MIB."; 546 reference 547 "RFC 2863: The Interfaces Group MIB"; 548 } 550 /* 551 * Configuration data nodes 552 */ 554 container interfaces { 555 description 556 "Interface configuration parameters."; 558 list interface { 559 key "name"; 561 description 562 "The list of configured interfaces on the device. 564 The operational state of an interface is available in the 565 /interfaces-state/interface list. If the configuration of a 566 system-controlled interface cannot be used by the system 567 (e.g., the interface hardware present does not match the 568 interface type), then the configuration is not applied to 569 the system-controlled interface shown in the 570 /interfaces-state/interface list. If the configuration 571 of a user-controlled interface cannot be used by the system, 572 the configured interface is not instantiated in the 573 /interfaces-state/interface list."; 575 leaf name { 576 type string; 577 description 578 "The name of the interface. 580 A device MAY restrict the allowed values for this leaf, 581 possibly depending on the type of the interface. 583 For system-controlled interfaces, this leaf is the 584 device-specific name of the interface. The 'config false' 585 list /interfaces-state/interface contains the currently 586 existing interfaces on the device. 588 If a client tries to create configuration for a 589 system-controlled interface that is not present in the 590 /interfaces-state/interface list, the server MAY reject 591 the request, if the implementation does not support 592 pre-provisioning of interfaces, or if the name refers to 593 an interface that can never exist in the system. A 594 NETCONF server MUST reply with an rpc-error with the 595 error-tag 'invalid-value' in this case. 597 If the device supports pre-provisioning of interface 598 configuration, the feature 'pre-provisioning' is 599 advertised. 601 If the device allows arbitrarily named user-controlled 602 interfaces, the feature 'arbitrary-names' is advertised. 604 When a configured user-controlled interface is created by 605 the system, it is instantiated with the same name in the 606 /interface-state/interface list."; 607 } 609 leaf description { 610 type string; 611 description 612 "A textual description of the interface. 614 A server implementation MAY map this leaf to the ifAlias 615 MIB object. Such an implementation needs to use some 616 mechanism to handle the differences in size and characters 617 allowed between this leaf and ifAlias. The definition of 618 such a mechanism is outside the scope of this document. 620 Since ifAlias is defined to be stored in non-volatile 621 storage, the MIB implementation MUST map ifAlias to the 622 value of 'description' in the persistently stored 623 datastore. 625 Specifically, if the device supports ':startup', when 626 ifAlias is read the device MUST return the value of 627 'description' in the 'startup' datastore, and when it is 628 written, it MUST be written to the 'running' and 'startup' 629 datastores. Note that it is up to the implementation if 630 it modifies this single leaf in 'startup', or if it 631 performs an implicit copy-config from 'running' to 632 'startup'. 634 If the device does not support ':startup', ifAlias MUST 635 be mapped to the 'description' leaf in the 'running' 636 datastore."; 637 reference 638 "RFC 2863: The Interfaces Group MIB - ifAlias"; 639 } 641 leaf type { 642 type identityref { 643 base interface-type; 644 } 645 mandatory true; 646 description 647 "The type of the interface. 649 When an interface entry is created, a server MAY 650 initialize the type leaf with a valid value, e.g., if it 651 is possible to derive the type from the name of the 652 interface. 654 If a client tries to set the type of an interface to a 655 value that can never be used by the system, e.g., if the 656 type is not supported or if the type does not match the 657 name of the interface, the server MUST reject the request. 658 A NETCONF server MUST reply with an rpc-error with the 659 error-tag 'invalid-value' in this case."; 660 reference 661 "RFC 2863: The Interfaces Group MIB - ifType"; 662 } 664 leaf enabled { 665 type boolean; 666 default "true"; 667 description 668 "This leaf contains the configured, desired state of the 669 interface. 671 Systems that implement the IF-MIB use the value of this 672 leaf in the 'running' datastore to set 673 IF-MIB.ifAdminStatus to 'up' or 'down' after an ifEntry 674 has been initialized, as described in RFC 2863. 676 Changes in this leaf in the 'running' datastore are 677 reflected in ifAdminStatus, but if ifAdminStatus is 678 changed over SNMP, this leaf is not affected."; 679 reference 680 "RFC 2863: The Interfaces Group MIB - ifAdminStatus"; 681 } 683 leaf link-up-down-trap-enable { 684 if-feature if-mib; 685 type enumeration { 686 enum enabled { 687 value 1; 688 } 689 enum disabled { 690 value 2; 691 } 692 } 693 description 694 "Controls whether linkUp/linkDown SNMP notifications 695 should be generated for this interface. 697 If this node is not configured, the value 'enabled' is 698 operationally used by the server for interfaces which do 699 not operate on top of any other interface (i.e., there are 700 no 'lower-layer-if' entries), and 'disabled' otherwise."; 701 reference 702 "RFC 2863: The Interfaces Group MIB - 703 ifLinkUpDownTrapEnable"; 704 } 705 } 706 } 708 /* 709 * Operational state data nodes 710 */ 712 container interfaces-state { 713 config false; 714 description 715 "Data nodes for the operational state of interfaces."; 717 list interface { 718 key "name"; 719 description 720 "The list of interfaces on the device. 722 System-controlled interfaces created by the system are 723 always present in this list, whether they are configured or 724 not."; 726 leaf name { 727 type string; 728 description 729 "The name of the interface. 731 A server implementation MAY map this leaf to the ifName 732 MIB object. Such an implementation needs to use some 733 mechanism to handle the differences in size and characters 734 allowed between this leaf and ifName. The definition of 735 such a mechanism is outside the scope of this document."; 736 reference 737 "RFC 2863: The Interfaces Group MIB - ifName"; 738 } 740 leaf type { 741 type identityref { 742 base interface-type; 743 } 744 mandatory true; 745 description 746 "The type of the interface."; 747 reference 748 "RFC 2863: The Interfaces Group MIB - ifType"; 749 } 751 leaf admin-status { 752 if-feature if-mib; 753 type enumeration { 754 enum up { 755 value 1; 756 description 757 "Ready to pass packets."; 758 } 759 enum down { 760 value 2; 761 description 762 "Not ready to pass packets and not in some test mode."; 763 } 764 enum testing { 765 value 3; 766 description 767 "In some test mode."; 768 } 769 } 770 mandatory true; 771 description 772 "The desired state of the interface. 774 This leaf has the same read semantics as ifAdminStatus."; 775 reference 776 "RFC 2863: The Interfaces Group MIB - ifAdminStatus"; 777 } 779 leaf oper-status { 780 type enumeration { 781 enum up { 782 value 1; 783 description 784 "Ready to pass packets."; 785 } 786 enum down { 787 value 2; 788 description 789 "The interface does not pass any packets."; 790 } 791 enum testing { 792 value 3; 793 description 794 "In some test mode. No operational packets can 795 be passed."; 796 } 797 enum unknown { 798 value 4; 799 description 800 "Status cannot be determined for some reason."; 801 } 802 enum dormant { 803 value 5; 804 description 805 "Waiting for some external event."; 806 } 807 enum not-present { 808 value 6; 809 description 810 "Some component (typically hardware) is missing."; 811 } 812 enum lower-layer-down { 813 value 7; 814 description 815 "Down due to state of lower-layer interface(s)."; 816 } 817 } 818 mandatory true; 819 description 820 "The current operational state of the interface. 822 This leaf has the same semantics as ifOperStatus."; 823 reference 824 "RFC 2863: The Interfaces Group MIB - ifOperStatus"; 825 } 827 leaf last-change { 828 type yang:date-and-time; 829 description 830 "The time the interface entered its current operational 831 state. If the current state was entered prior to the 832 last re-initialization of the local network management 833 subsystem, then this node is not present."; 834 reference 835 "RFC 2863: The Interfaces Group MIB - ifLastChange"; 836 } 838 leaf if-index { 839 if-feature if-mib; 840 type int32 { 841 range "1..2147483647"; 842 } 843 mandatory true; 844 description 845 "The ifIndex value for the ifEntry represented by this 846 interface."; 847 reference 848 "RFC 2863: The Interfaces Group MIB - ifIndex"; 849 } 851 leaf phys-address { 852 type yang:phys-address; 853 description 854 "The interface's address at its protocol sub-layer. For 855 example, for an 802.x interface, this object normally 856 contains a MAC address. The interface's media-specific 857 modules must define the bit and byte ordering and the 858 format of the value of this object. For interfaces that do 859 not have such an address (e.g., a serial line), this node 860 is not present."; 861 reference 862 "RFC 2863: The Interfaces Group MIB - ifPhysAddress"; 864 } 866 leaf-list higher-layer-if { 867 type interface-state-ref; 868 description 869 "A list of references to interfaces layered on top of this 870 interface."; 871 reference 872 "RFC 2863: The Interfaces Group MIB - ifStackTable"; 873 } 875 leaf-list lower-layer-if { 876 type interface-state-ref; 877 description 878 "A list of references to interfaces layered underneath this 879 interface."; 880 reference 881 "RFC 2863: The Interfaces Group MIB - ifStackTable"; 882 } 884 leaf speed { 885 type yang:gauge64; 886 units "bits / second"; 887 description 888 "An estimate of the interface's current bandwidth in bits 889 per second. For interfaces that do not vary in 890 bandwidth or for those where no accurate estimation can 891 be made, this node should contain the nominal bandwidth. 892 For interfaces that have no concept of bandwidth, this 893 node is not present."; 894 reference 895 "RFC 2863: The Interfaces Group MIB - 896 ifSpeed, ifHighSpeed"; 897 } 899 container statistics { 900 description 901 "A collection of interface-related statistics objects."; 903 leaf discontinuity-time { 904 type yang:date-and-time; 905 mandatory true; 906 description 907 "The time on the most recent occasion at which any one or 908 more of this interface's counters suffered a 909 discontinuity. If no such discontinuities have occurred 910 since the last re-initialization of the local management 911 subsystem, then this node contains the time the local 912 management subsystem re-initialized itself."; 913 } 915 leaf in-octets { 916 type yang:counter64; 917 description 918 "The total number of octets received on the interface, 919 including framing characters. 921 Discontinuities in the value of this counter can occur 922 at re-initialization of the management system, and at 923 other times as indicated by the value of 924 'discontinuity-time'."; 925 reference 926 "RFC 2863: The Interfaces Group MIB - ifHCInOctets"; 927 } 928 leaf in-unicast-pkts { 929 type yang:counter64; 930 description 931 "The number of packets, delivered by this sub-layer to a 932 higher (sub-)layer, which were not addressed to a 933 multicast or broadcast address at this sub-layer. 935 Discontinuities in the value of this counter can occur 936 at re-initialization of the management system, and at 937 other times as indicated by the value of 938 'discontinuity-time'."; 939 reference 940 "RFC 2863: The Interfaces Group MIB - ifHCInUcastPkts"; 941 } 942 leaf in-broadcast-pkts { 943 type yang:counter64; 944 description 945 "The number of packets, delivered by this sub-layer to a 946 higher (sub-)layer, which were addressed to a broadcast 947 address at this sub-layer. 949 Discontinuities in the value of this counter can occur 950 at re-initialization of the management system, and at 951 other times as indicated by the value of 952 'discontinuity-time'."; 953 reference 954 "RFC 2863: The Interfaces Group MIB - 955 ifHCInBroadcastPkts"; 956 } 957 leaf in-multicast-pkts { 958 type yang:counter64; 959 description 960 "The number of packets, delivered by this sub-layer to a 961 higher (sub-)layer, which were addressed to a multicast 962 address at this sub-layer. For a MAC layer protocol, 963 this includes both Group and Functional addresses. 965 Discontinuities in the value of this counter can occur 966 at re-initialization of the management system, and at 967 other times as indicated by the value of 968 'discontinuity-time'."; 969 reference 970 "RFC 2863: The Interfaces Group MIB - 971 ifHCInMulticastPkts"; 972 } 973 leaf in-discards { 974 type yang:counter32; 975 description 976 "The number of inbound packets which were chosen to be 977 discarded even though no errors had been detected to 978 prevent their being deliverable to a higher-layer 979 protocol. One possible reason for discarding such a 980 packet could be to free up buffer space. 982 Discontinuities in the value of this counter can occur 983 at re-initialization of the management system, and at 984 other times as indicated by the value of 985 'discontinuity-time'."; 986 reference 987 "RFC 2863: The Interfaces Group MIB - ifInDiscards"; 988 } 989 leaf in-errors { 990 type yang:counter32; 991 description 992 "For packet-oriented interfaces, the number of inbound 993 packets that contained errors preventing them from being 994 deliverable to a higher-layer protocol. For character- 995 oriented or fixed-length interfaces, the number of 996 inbound transmission units that contained errors 997 preventing them from being deliverable to a higher-layer 998 protocol. 1000 Discontinuities in the value of this counter can occur 1001 at re-initialization of the management system, and at 1002 other times as indicated by the value of 1003 'discontinuity-time'."; 1004 reference 1005 "RFC 2863: The Interfaces Group MIB - ifInErrors"; 1006 } 1007 leaf in-unknown-protos { 1008 type yang:counter32; 1009 description 1010 "For packet-oriented interfaces, the number of packets 1011 received via the interface which were discarded because 1012 of an unknown or unsupported protocol. For 1013 character-oriented or fixed-length interfaces that 1014 support protocol multiplexing the number of transmission 1015 units received via the interface which were discarded 1016 because of an unknown or unsupported protocol. For any 1017 interface that does not support protocol multiplexing, 1018 this counter is not present. 1020 Discontinuities in the value of this counter can occur 1021 at re-initialization of the management system, and at 1022 other times as indicated by the value of 1023 'discontinuity-time'."; 1024 reference 1025 "RFC 2863: The Interfaces Group MIB - ifInUnknownProtos"; 1026 } 1028 leaf out-octets { 1029 type yang:counter64; 1030 description 1031 "The total number of octets transmitted out of the 1032 interface, including framing characters. 1034 Discontinuities in the value of this counter can occur 1035 at re-initialization of the management system, and at 1036 other times as indicated by the value of 1037 'discontinuity-time'."; 1038 reference 1039 "RFC 2863: The Interfaces Group MIB - ifHCOutOctets"; 1040 } 1041 leaf out-unicast-pkts { 1042 type yang:counter64; 1043 description 1044 "The total number of packets that higher-level protocols 1045 requested be transmitted, and which were not addressed 1046 to a multicast or broadcast address at this sub-layer, 1047 including those that were discarded or not sent. 1049 Discontinuities in the value of this counter can occur 1050 at re-initialization of the management system, and at 1051 other times as indicated by the value of 1052 'discontinuity-time'."; 1053 reference 1054 "RFC 2863: The Interfaces Group MIB - ifHCOutUcastPkts"; 1055 } 1056 leaf out-broadcast-pkts { 1057 type yang:counter64; 1058 description 1059 "The total number of packets that higher-level protocols 1060 requested be transmitted, and which were addressed to a 1061 broadcast address at this sub-layer, including those 1062 that were discarded or not sent. 1064 Discontinuities in the value of this counter can occur 1065 at re-initialization of the management system, and at 1066 other times as indicated by the value of 1067 'discontinuity-time'."; 1068 reference 1069 "RFC 2863: The Interfaces Group MIB - 1070 ifHCOutBroadcastPkts"; 1071 } 1072 leaf out-multicast-pkts { 1073 type yang:counter64; 1074 description 1075 "The total number of packets that higher-level protocols 1076 requested be transmitted, and which were addressed to a 1077 multicast address at this sub-layer, including those 1078 that were discarded or not sent. For a MAC layer 1079 protocol, this includes both Group and Functional 1080 addresses. 1082 Discontinuities in the value of this counter can occur 1083 at re-initialization of the management system, and at 1084 other times as indicated by the value of 1085 'discontinuity-time'."; 1086 reference 1087 "RFC 2863: The Interfaces Group MIB - 1088 ifHCOutMulticastPkts"; 1089 } 1090 leaf out-discards { 1091 type yang:counter32; 1092 description 1093 "The number of outbound packets which were chosen to be 1094 discarded even though no errors had been detected to 1095 prevent their being transmitted. One possible reason 1096 for discarding such a packet could be to free up buffer 1097 space. 1099 Discontinuities in the value of this counter can occur 1100 at re-initialization of the management system, and at 1101 other times as indicated by the value of 1102 'discontinuity-time'."; 1103 reference 1104 "RFC 2863: The Interfaces Group MIB - ifOutDiscards"; 1105 } 1106 leaf out-errors { 1107 type yang:counter32; 1108 description 1109 "For packet-oriented interfaces, the number of outbound 1110 packets that could not be transmitted because of errors. 1111 For character-oriented or fixed-length interfaces, the 1112 number of outbound transmission units that could not be 1113 transmitted because of errors. 1115 Discontinuities in the value of this counter can occur 1116 at re-initialization of the management system, and at 1117 other times as indicated by the value of 1118 'discontinuity-time'."; 1119 reference 1120 "RFC 2863: The Interfaces Group MIB - ifOutErrors"; 1121 } 1122 } 1123 } 1124 } 1125 } 1127 1129 6. IANA Considerations 1131 This document registers a URI in the IETF XML registry [RFC3688]. 1132 Following the format in RFC 3688, the following registration is 1133 requested to be made. 1135 URI: urn:ietf:params:xml:ns:yang:ietf-interfaces 1137 Registrant Contact: The IESG. 1139 XML: N/A, the requested URI is an XML namespace. 1141 This document registers a YANG module in the YANG Module Names 1142 registry [RFC6020]. 1144 name: ietf-interfaces 1145 namespace: urn:ietf:params:xml:ns:yang:ietf-interfaces 1146 prefix: if 1147 reference: RFC XXXX 1149 7. Security Considerations 1151 The YANG module defined in this memo is designed to be accessed via 1152 the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the 1153 secure transport layer and the mandatory-to-implement secure 1154 transport is SSH [RFC6242]. The NETCONF access control model 1155 [RFC6536] provides the means to restrict access for particular 1156 NETCONF users to a pre-configured subset of all available NETCONF 1157 protocol operations and content. 1159 There are a number of data nodes defined in the YANG module which are 1160 writable/creatable/deletable (i.e., config true, which is the 1161 default). These data nodes may be considered sensitive or vulnerable 1162 in some network environments. Write operations (e.g., ) 1163 to these data nodes without proper protection can have a negative 1164 effect on network operations. These are the subtrees and data nodes 1165 and their sensitivity/vulnerability: 1167 /interfaces/interface: This list specifies the configured interfaces 1168 on a device. Unauthorized access to this list could cause the 1169 device to ignore packets it should receive and process. 1171 /interfaces/interface/enabled: This leaf controls if an interface is 1172 enabled or not. Unauthorized access to this leaf could cause the 1173 device to ignore packets it should receive and process. 1175 8. Acknowledgments 1177 The author wishes to thank Alexander Clemm, Per Hedeland, Ladislav 1178 Lhotka, and Juergen Schoenwaelder for their helpful comments. 1180 9. References 1182 9.1. Normative References 1184 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1185 Requirement Levels", BCP 14, RFC 2119, March 1997. 1187 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 1188 MIB", RFC 2863, June 2000. 1190 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1191 January 2004. 1193 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 1194 Network Configuration Protocol (NETCONF)", RFC 6020, 1195 October 2010. 1197 [RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991, 1198 July 2013. 1200 9.2. Informative References 1202 [I-D.ietf-netmod-iana-if-type] 1203 Bjorklund, M., "IANA Interface Type YANG Module", 1204 draft-ietf-netmod-iana-if-type-08 (work in progress), 1205 November 2013. 1207 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 1208 Bierman, "Network Configuration Protocol (NETCONF)", 1209 RFC 6241, June 2011. 1211 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1212 Shell (SSH)", RFC 6242, June 2011. 1214 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1215 Protocol (NETCONF) Access Control Model", RFC 6536, 1216 March 2012. 1218 Appendix A. Example: Ethernet Interface Module 1220 This section gives a simple example of how an Ethernet interface 1221 module could be defined. It demonstrates how media-specific 1222 configuration parameters can be conditionally augmented to the 1223 generic interface list. It also shows how operational state 1224 parameters can be conditionally augmented to the operational 1225 interface list. The example is not intended as a complete module for 1226 ethernet configuration. 1228 module ex-ethernet { 1229 namespace "http://example.com/ethernet"; 1230 prefix "eth"; 1232 import ietf-interfaces { 1233 prefix if; 1234 } 1235 import iana-if-type { 1236 prefix ianaift; 1237 } 1239 // configuration parameters for ethernet interfaces 1240 augment "/if:interfaces/if:interface" { 1241 when "if:type = 'ianaift:ethernetCsmacd'"; 1243 container ethernet { 1244 choice transmission-params { 1245 case auto { 1246 leaf auto-negotiate { 1247 type empty; 1248 } 1249 } 1250 case manual { 1251 leaf duplex { 1252 type enumeration { 1253 enum "half"; 1254 enum "full"; 1255 } 1256 } 1257 leaf speed { 1258 type enumeration { 1259 enum "10Mb"; 1260 enum "100Mb"; 1261 enum "1Gb"; 1262 enum "10Gb"; 1263 } 1264 } 1265 } 1267 } 1268 // other ethernet specific params... 1269 } 1270 } 1272 // operational state parameters for ethernet interfaces 1273 augment "/if:interfaces-state/if:interface" { 1274 when "if:type = 'ianaift:ethernetCsmacd'"; 1276 container ethernet { 1277 leaf duplex { 1278 type enumeration { 1279 enum "half"; 1280 enum "full"; 1281 } 1282 } 1283 // other ethernet specific params... 1284 } 1285 } 1286 } 1288 Appendix B. Example: Ethernet Bonding Interface Module 1290 This section gives an example of how interface layering can be 1291 defined. An ethernet bonding interface is defined, which bonds 1292 several ethernet interfaces into one logical interface. 1294 module ex-ethernet-bonding { 1295 namespace "http://example.com/ethernet-bonding"; 1296 prefix "bond"; 1298 import ietf-interfaces { 1299 prefix if; 1300 } 1301 import iana-if-type { 1302 prefix ianaift; 1303 } 1305 augment "/if:interfaces/if:interface" { 1306 when "if:type = 'ianaift:ieee8023adLag'"; 1308 leaf-list slave-if { 1309 type if:interface-ref; 1310 must "/if:interfaces/if:interface[if:name = current()]" 1311 + "/if:type = 'ianaift:ethernetCsmacd'" { 1312 description 1313 "The type of a slave interface must be ethernet."; 1314 } 1315 } 1316 leaf bonding-mode { 1317 type enumeration { 1318 enum round-robin; 1319 enum active-backup; 1320 enum broadcast; 1321 } 1322 } 1323 // other bonding config params, failover times etc. 1324 } 1325 } 1327 Appendix C. Example: VLAN Interface Module 1329 This section gives an example of how a vlan interface module can be 1330 defined. 1332 module ex-vlan { 1333 namespace "http://example.com/vlan"; 1334 prefix "vlan"; 1336 import ietf-interfaces { 1337 prefix if; 1338 } 1339 import iana-if-type { 1340 prefix ianaift; 1341 } 1342 import ex-ethernet { 1343 prefix eth; 1344 } 1346 augment "/if:interfaces/if:interface" { 1347 when "if:type = 'ianaift:ethernetCsmacd' or 1348 if:type = 'ianaift:ieee8023adLag'"; 1349 leaf vlan-tagging { 1350 type boolean; 1351 default false; 1352 } 1353 } 1355 augment "/if:interfaces/if:interface" { 1356 when "if:type = 'ianaift:l2vlan'"; 1358 leaf base-interface { 1359 type if:interface-ref; 1360 must "/if:interfaces/if:interface[if:name = current()]" 1361 + "/vlan:vlan-tagging = 'true'" { 1362 description 1363 "The base interface must have vlan tagging enabled."; 1364 } 1365 } 1366 leaf vlan-id { 1367 type uint16 { 1368 range "1..4094"; 1369 } 1370 must "../base-interface" { 1371 description 1372 "If a vlan-id is defined, a base-interface must 1373 be specified."; 1374 } 1375 } 1376 } 1377 } 1379 Appendix D. Example: NETCONF reply 1381 This section gives an example of a reply to the NETCONF request 1382 for a device that implements the example data models above. 1384 1387 1389 1394 1395 eth0 1396 ianaift:ethernetCsmacd 1397 false 1398 1400 1401 eth1 1402 ianaift:ethernetCsmacd 1403 true 1404 true 1405 1407 1408 eth1.10 1409 ianaift:l2vlan 1410 true 1411 eth1 1412 10 1413 1415 1416 lo1 1417 ianaift:softwareLoopback 1418 true 1419 1421 1423 1427 1428 eth0 1429 ianaift:ethernetCsmacd 1430 down 1431 down 1432 2 1433 00:01:02:03:04:05 1434 1435 1436 2013-04-01T03:00:00+00:00 1437 1438 1439 1440 1442 1443 eth1 1444 ianaift:ethernetCsmacd 1445 up 1446 up 1447 7 1448 00:01:02:03:04:06 1449 eth1.10 1450 1451 1452 2013-04-01T03:00:00+00:00 1453 1454 1455 1456 1458 1459 eth1.10 1460 ianaift:l2vlan 1461 up 1462 up 1463 9 1464 eth1 1465 1466 1467 2013-04-01T03:00:00+00:00 1468 1469 1470 1471 1473 1474 1475 eth2 1476 ianaift:ethernetCsmacd 1477 down 1478 down 1479 8 1480 00:01:02:03:04:07 1481 1482 1483 2013-04-01T03:00:00+00:00 1484 1485 1486 1487 1489 1490 lo1 1491 ianaift:softwareLoopback 1492 up 1493 up 1494 1 1495 1496 1497 2013-04-01T03:00:00+00:00 1498 1499 1500 1501 1503 1504 1505 1507 Appendix E. Examples: Interface Naming Schemes 1509 This section gives examples of some implementation strategies. 1511 The examples make use of the example data model "ex-vlan" (see 1512 Appendix C) to show how user-controlled interfaces can be configured. 1514 E.1. Router with Restricted Interface Names 1516 In this example, a router has support for 4 line cards, each with 8 1517 ports. The slots for the cards are physically numbered from 0 to 3, 1518 and the ports on each card from 0 to 7. Each card has fast- or 1519 gigabit-ethernet ports. 1521 The device-specific names for these physical interfaces are 1522 "fastethernet-N/M" or "gigabitethernet-N/M". 1524 The name of a vlan interface is restricted to the form 1525 ".". 1527 It is assumed that the operator is aware of this naming scheme. The 1528 implementation auto-initializes the value for "type" based on the 1529 interface name. 1531 The NETCONF server does not advertise the 'arbitrary-names' feature 1532 in the message. 1534 An operator can configure a physical interface by sending an 1535 containing: 1537 1538 fastethernet-1/0 1539 1541 When the server processes this request, it will set the leaf "type" 1542 to "ianaift:ethernetCsmacd". Thus, if the client performs a 1543 right after the above, it will get: 1545 1546 fastethernet-1/0 1547 ianaift:ethernetCsmacd 1548 1550 The client can configure a vlan interface by sending an 1551 containing: 1553 1554 fastethernet-1/0.10005 1555 ianaift:l2vlan 1556 fastethernet-1/0 1557 5 1558 1560 If the client tries to change the type of the physical interface with 1561 an containing: 1563 1564 fastethernet-1/0 1565 ianaift:tunnel 1566 1568 then the server will reply with an "invalid-value" error, since the 1569 new type does not match the name. 1571 E.2. Router with Arbitrary Interface Names 1573 In this example, a router has support for 4 line cards, each with 8 1574 ports. The slots for the cards are physically numbered from 0 to 3, 1575 and the ports on each card from 0 to 7. Each card has fast- or 1576 gigabit-ethernet ports. 1578 The device-specific names for these physical interfaces are 1579 "fastethernet-N/M" or "gigabitethernet-N/M". 1581 The implementation does not restrict the user-controlled interface 1582 names. This allows to more easily apply the interface configuration 1583 to a different interface. However, the additional level of 1584 indirection also makes it a bit more complex to map interface names 1585 found in other protocols to configuration entries. 1587 The NETCONF server advertises the 'arbitrary-names' feature in the 1588 message. 1590 Physical interfaces are configured as in Appendix E.1. 1592 An operator can configure a VLAN interface by sending an 1593 containing: 1595 1596 acme-interface 1597 ianaift:l2vlan 1598 fastethernet-1/0 1599 5 1600 1602 If necessary, the operator can move the configuration named 1603 "acme-interface" over to a different physical interface with an 1604 containing: 1606 1607 acme-interface 1608 fastethernet-1/1 1609 1611 E.3. Ethernet Switch with Restricted Interface Names 1613 In this example, an ethernet switch has a number of ports, each port 1614 identified by a simple port number. 1616 The device-specific names for the physical interfaces are numbers 1617 that match the physical port number. 1619 An operator can configure a physical interface by sending an 1620 containing: 1622 1623 6 1624 1626 When the server processes this request, it will set the leaf "type" 1627 to "ianaift:ethernetCsmacd". Thus, if the client performs a 1628 right after the above, it will get: 1630 1631 6 1632 ianaift:ethernetCsmacd 1633 1635 E.4. Generic Host with Restricted Interface Names 1637 In this example, a generic host has interfaces named by the kernel. 1638 The system identifies the physical interface by the name assigned by 1639 the operating system to the interface. 1641 The name of a vlan interface is restricted to the form 1642 ":". 1644 The NETCONF server does not advertise the 'arbitrary-names' feature 1645 in the message. 1647 An operator can configure an interface by sending an 1648 containing: 1650 1651 eth8 1652 1654 When the server processes this request, it will set the leaf "type" 1655 to "ianaift:ethernetCsmacd". Thus, if the client performs a 1656 right after the above, it will get: 1658 1659 eth8 1660 ianaift:ethernetCsmacd 1661 1663 The client can configure a vlan interface by sending an 1664 containing: 1666 1667 eth8:5 1668 ianaift:l2vlan 1669 eth8 1670 5 1671 1673 E.5. Generic Host with Arbitrary Interface Names 1675 In this example, a generic host has interfaces named by the kernel. 1676 The system identifies the physical interface by the name assigned by 1677 the operating system to the interface. 1679 The implementation does not restrict the user-controlled interface 1680 names. This allows to more easily apply the interface configuration 1681 to a different interface. However, the additional level of 1682 indirection also makes it a bit more complex to map interface names 1683 found in other protocols to configuration entries. 1685 The NETCONF server advertises the 'arbitrary-names' feature in the 1686 message. 1688 Physical interfaces are configured as in Appendix E.4. 1690 An operator can configure a VLAN interface by sending an 1691 containing: 1693 1694 acme-interface 1695 ianaift:l2vlan 1696 eth8 1697 5 1699 1701 If necessary, the operator can move the configuration named 1702 "acme-interface" over to a different physical interface with an 1703 containing: 1705 1706 acme-interface 1707 eth3 1708 1710 Appendix F. ChangeLog 1712 RFC Editor: remove this section upon publication as an RFC. 1714 F.1. Version -13 1716 o Made the interface type an identity, instead of an enumseration. 1718 F.2. Version -11 1720 o Separated the operational state from the configuration. 1722 o Removed 'location', and instead use the name to identify physical 1723 interfaces. 1725 o Added the feature 'pre-provisioning'. 1727 o Made 'oper-status' and 'if-index' mandatory in the data model. 1729 o Added 'admin-status'. 1731 o Clarified why description can be mapped to ifAlias. 1733 o Clarified that 64-bit counters only are used, where there exist 1734 64-bit and 32-bit counters in IF-MIB. 1736 o Updated Security Considerations section with a reference to NACM. 1738 F.3. Version -08 1740 o Removed the mtu leaf. 1742 o Added examples of different interface naming schemes. 1744 F.4. Version -07 1746 o Made leaf speed config false. 1748 F.5. Version -06 1750 o Added oper-status leaf. 1752 o Added leaf-lists higher-layer-if and lower-layer-if, that show the 1753 interface layering. 1755 o Added container statistics with counters. 1757 F.6. Version -05 1759 o Added an Informative References section. 1761 o Updated the Security Considerations section. 1763 o Clarified the behavior of an NETCONF server when invalid values 1764 are received. 1766 F.7. Version -04 1768 o Clarified why ifPromiscuousMode is not part of this data model. 1770 o Added a table that shows the mapping between this YANG data model 1771 and IF-MIB. 1773 F.8. Version -03 1775 o Added the section Relationship to the IF-MIB. 1777 o Changed if-index to be a leaf instead of leaf-list. 1779 o Explained the notation used in the data model tree picture. 1781 F.9. Version -02 1783 o Editorial fixes 1785 F.10. Version -01 1787 o Changed leaf "if-admin-status" to leaf "enabled". 1789 o Added Security Considerations 1791 Author's Address 1793 Martin Bjorklund 1794 Tail-f Systems 1796 Email: mbj@tail-f.com