idnits 2.17.1 draft-ietf-netmod-interfaces-cfg-12.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 233 has weird spacing: '...ty-time yan...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 4, 2013) is 3942 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-07 -- 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 July 4, 2013 5 Expires: January 5, 2014 7 A YANG Data Model for Interface Management 8 draft-ietf-netmod-interfaces-cfg-12 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, state data and counters 16 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 January 5, 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 . . . . . . . . . . . . 34 72 Appendix E. Examples: Interface Naming Schemes . . . . . . . . . 37 73 E.1. Router with Restricted Interface Names . . . . . . . . . . 37 74 E.2. Router with Arbitrary Interface Names . . . . . . . . . . 38 75 E.3. Ethernet Switch with Restricted Interface Names . . . . . 39 76 E.4. Generic Host with Restricted Interface Names . . . . . . . 39 77 E.5. Generic Host with Arbitrary Interface Names . . . . . . . 40 78 Appendix F. ChangeLog . . . . . . . . . . . . . . . . . . . . . . 42 79 F.1. Version -11 . . . . . . . . . . . . . . . . . . . . . . . 42 80 F.2. Version -08 . . . . . . . . . . . . . . . . . . . . . . . 42 81 F.3. Version -07 . . . . . . . . . . . . . . . . . . . . . . . 42 82 F.4. Version -06 . . . . . . . . . . . . . . . . . . . . . . . 42 83 F.5. Version -05 . . . . . . . . . . . . . . . . . . . . . . . 42 84 F.6. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 43 85 F.7. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 43 86 F.8. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 43 87 F.9. Version -01 . . . . . . . . . . . . . . . . . . . . . . . 43 88 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 44 90 1. Introduction 92 This document defines a YANG [RFC6020] data model for the management 93 of network interfaces. It is expected that interface type specific 94 data models augment the generic interfaces data model defined in this 95 document. 97 Network interfaces are central to the management of many Internet 98 protocols. Thus, it is important to establish a common data model 99 for how interfaces are identified, configured, and monitored. 101 The data model includes configuration data, state data and counters 102 for the collection of statistics. 104 1.1. Terminology 106 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 108 "OPTIONAL" in this document are to be interpreted as described in BCP 109 14, [RFC2119]. 111 The following terms are used within this document: 113 o system-controlled interface: An interface is said to be system- 114 controlled if the system creates and deletes the interface 115 independently of what has been explicitly configured. Examples 116 are interfaces representing physical hardware that appear and 117 disappear when hardware (e.g., a line card) is added or removed. 118 System-controlled interfaces may also appear if a certain 119 functionality is enabled (e.g., a loopback interface might appear 120 if the IP protocol stack is enabled). 122 o user-controlled interface: An interface is said to be user- 123 controlled if the creation of the interface is controlled by 124 adding explicit interface configuration to the running 125 configuration datastore and the removal of the interface is 126 controlled by removing explicit interface configuration from the 127 running configuration datastore. Examples are VLAN interfaces 128 configured on a system-controlled Ethernet interface. 130 The following terms are defined in [RFC6241] and are not redefined 131 here: 133 o client 135 o configuration data 136 o server 138 o state data 140 The following terms are defined in [RFC6020] and are not redefined 141 here: 143 o augment 145 o data model 147 o data node 149 1.2. Tree Diagrams 151 A simplified graphical representation of the data model is used in 152 this document. The meaning of the symbols in these diagrams is as 153 follows: 155 o Brackets "[" and "]" enclose list keys. 157 o Abbreviations before data node names: "rw" means configuration 158 (read-write) and "ro" state data (read-only). 160 o Symbols after data node names: "?" means an optional node and "*" 161 denotes a "list" and "leaf-list". 163 o Parentheses enclose choice and case nodes, and case nodes are also 164 marked with a colon (":"). 166 o Ellipsis ("...") stands for contents of subtrees that are not 167 shown. 169 2. Objectives 171 This section describes some of the design objectives for the model 172 presented in Section 5. 174 o It is recognized that existing implementations will have to map 175 the interface data model defined in this memo to their proprietary 176 native data model. The data model should be simple to facilitate 177 such mappings. 179 o The data model should be suitable for new implementations to use 180 as-is, without requiring a mapping to a different native model. 182 o References to interfaces should be as simple as possible, 183 preferably by using a single leafref. 185 o The mapping to ifIndex [RFC2863] used by SNMP to identify 186 interfaces must be clear. 188 o The model must support interface layering, both simple layering 189 where one interface is layered on top of exactly one other 190 interface, and more complex scenarios where one interface results 191 from the aggregation of N other interfaces, or when N interfaces 192 are multiplexed over one other interface. 194 o The data model should support the pre-provisioning of interface 195 configuration, i.e., it should be possible to configure an 196 interface whose physical interface hardware is not present on the 197 device. It is recommended that devices that support dynamic 198 addition and removal of physical interfaces also support pre- 199 provisioning. 201 o The data model should support both physical interfaces as well as 202 logical interfaces. 204 o The data model should include read-only counters in order to 205 gather statistics for octets, packets and errors, sent and 206 received. 208 3. Interfaces Data Model 210 This document defines the YANG module "ietf-interfaces", which has 211 the following structure: 213 +--rw interfaces 214 | +--rw interface* [name] 215 | +--rw name string 216 | +--rw description? string 217 | +--rw type ianaift:iana-if-type 218 | +--rw enabled? boolean 219 | +--rw link-up-down-trap-enable? enumeration 220 +--ro interfaces-state 221 +--ro interface* [name] 222 +--ro name string 223 +--ro type ianaift:iana-if-type 224 +--ro admin-status enumeration 225 +--ro oper-status enumeration 226 +--ro last-change? yang:date-and-time 227 +--ro if-index int32 228 +--ro phys-address? yang:phys-address 229 +--ro higher-layer-if* interface-state-ref 230 +--ro lower-layer-if* interface-state-ref 231 +--ro speed? yang:gauge64 232 +--ro statistics 233 +--ro discontinuity-time yang:date-and-time 234 +--ro in-octets? yang:counter64 235 +--ro in-unicast-pkts? yang:counter64 236 +--ro in-broadcast-pkts? yang:counter64 237 +--ro in-multicast-pkts? yang:counter64 238 +--ro in-discards? yang:counter32 239 +--ro in-errors? yang:counter32 240 +--ro in-unknown-protos? yang:counter32 241 +--ro out-octets? yang:counter64 242 +--ro out-unicast-pkts? yang:counter64 243 +--ro out-broadcast-pkts? yang:counter64 244 +--ro out-multicast-pkts? yang:counter64 245 +--ro out-discards? yang:counter32 246 +--ro out-errors? yang:counter32 248 3.1. The interface Lists 250 The data model for interfaces presented in this document uses a flat 251 list of interfaces. Each interface in the list is identified by its 252 name. Furthermore, each interface has a mandatory "type" leaf. 254 There is one list of configured interfaces ("/interfaces/interface"), 255 and a separate list for the operational state of all interfaces 256 ("/interfaces-state/interface"). 258 It is expected that interface type specific data models augment the 259 interface lists, and possibly use the "type" leaf to make the 260 augmentation conditional. 262 As an example of such an interface type specific augmentation, 263 consider this YANG snippet. For a more complete example, see 264 Appendix A. 266 import interfaces { 267 prefix "if"; 268 } 270 augment "/if:interfaces/if:interface" { 271 when "if:type = 'ethernetCsmacd'"; 273 container ethernet { 274 leaf duplex { 275 ... 276 } 277 } 278 } 280 For system-controlled interfaces, the "name" is the device-specific 281 name of the interface. The 'config false' list "/interfaces-state/ 282 interface" contains all existing interfaces on the device. 284 If the device supports arbitrarily named user-controlled interfaces, 285 the NETCONF server advertises the feature "arbitrary-names". If the 286 device does not advertise this feature, the names of user-controlled 287 interfaces MUST match the device's naming scheme. How a client can 288 learn the naming scheme of such devices is outside the scope of this 289 document. 291 When a system-controlled interface is created by the system, the 292 system tries to apply the interface configuration in /interfaces/ 293 interface with the same name as the new interface. If no such 294 interface configuration is found, or if the configured type does not 295 match the real interface type, the system creates the interface 296 without applying explicit configuration. 298 When a user-controlled interface is created, the configuration 299 determines the name of the interface. 301 3.2. Interface References 303 An interface is identified by its name, which is unique within the 304 server. This property is captured in the "interface-ref" and 305 "interface-state-ref" typedefs, which other YANG modules SHOULD use 306 when they need to reference a configured interface or operationally 307 used interface, respectively. 309 3.3. Interface Layering 311 There is no generic mechanism for how an interface is configured to 312 be layered on top of some other interface. It is expected that 313 interface type specific models define their own data nodes for 314 interface layering, by using "interface-ref" types to reference lower 315 layers. 317 Below is an example of a model with such nodes. For a more complete 318 example, see Appendix B. 320 import interfaces { 321 prefix "if"; 322 } 324 augment "/if:interfaces/if:interface" { 325 when "if:type = 'ieee8023adLag'"; 327 leaf-list slave-if { 328 type if:interface-ref; 329 must "/if:interfaces/if:interface[if:name = current()]" 330 + "/if:type = 'ethernetCsmacd'" { 331 description 332 "The type of a slave interface must be ethernet"; 333 } 334 } 335 // other bonding config params, failover times etc. 336 } 338 Two state data leaf-lists, "higher-layer-if" and "lower-layer-if", 339 represent a read-only view of the interface layering hierarchy. 341 4. Relationship to the IF-MIB 343 If the device implements IF-MIB [RFC2863], each entry in the 344 "/interfaces-state/interface" list is typically mapped to one 345 ifEntry. The "if-index" leaf MUST contain the value of the 346 corresponding ifEntry's ifIndex. 348 In most cases, the "name" of an "interface" entry is mapped to 349 ifName. ifName is defined as an DisplayString [RFC2579] which uses a 350 7-bit ASCII character set. An implementation MUST restrict the 351 allowed values for "name" to match the restrictions of ifName. 353 The IF-MIB allows two different ifEntries to have the same ifName. 354 Devices that support this feature, and also support the data model 355 defined in this document, cannot have a 1-1 mapping between the 356 "name" leaf and ifName. 358 The configured "description" of an "interface" has traditionally been 359 mapped to ifAlias in some implementations. This document allows this 360 mapping, but implementers should be aware of the differences in the 361 value space and persistence for these objects. See the YANG module 362 definition of the leaf "description" in Section 5 for details. 364 The IF-MIB also defines the writable object ifPromiscuousMode. Since 365 this object typically is not a configuration object, it is not mapped 366 to the "ietf-interfaces" module. 368 There are a number of counters in the IF-MIB that exist in two 369 versions; one with 32 bits and one with 64 bits. The YANG module 370 contains the 64 bits counters only. Note that NETCONF and SNMP may 371 differ in the time granularity in which they provide access to the 372 counters. For example, it is common that SNMP implementations cache 373 counter values for some time. 375 The following table lists the YANG data nodes with corresponding 376 objects in the IF-MIB. 378 +----------------------------------+------------------------+ 379 | YANG data node | IF-MIB object | 380 +----------------------------------+------------------------+ 381 | /interfaces-state/interface | ifEntry | 382 | /interfaces-state/name | ifName | 383 | description | ifAlias | 384 | type | ifType | 385 | enabled / admin-status | ifAdminStatus | 386 | oper-status | ifOperStatus | 387 | last-change | ifLastChange | 388 | if-index | ifIndex | 389 | link-up-down-trap-enable | ifLinkUpDownTrapEnable | 390 | phys-address | ifPhysAddress | 391 | higher-layer-if / lower-layer-if | ifStackTable | 392 | speed | ifSpeed | 393 | in-octets | ifHCInOctets | 394 | in-unicast-pkts | ifHCInUcastPkts | 395 | in-broadcast-pkts | ifHCInBroadcastPkts | 396 | in-multicast-pkts | ifHCInMulticastPkts | 397 | in-discards | ifInDiscards | 398 | in-errors | ifInErrors | 399 | in-unknown-protos | ifInUnknownProtos | 400 | out-octets | ifHCOutOctets | 401 | out-unicast-pkts | ifHCOutUcastPkts | 402 | out-broadcast-pkts | ifHCOutBroadcastPkts | 403 | out-multicast-pkts | ifHCOutMulticastPkts | 404 | out-discards | ifOutDiscards | 405 | out-errors | ifOutErrors | 406 +----------------------------------+------------------------+ 408 YANG data nodes and related IF-MIB objects 410 5. Interfaces YANG Module 412 This YANG module imports typedefs from [I-D.ietf-netmod-rfc6021-bis] 413 and [I-D.ietf-netmod-iana-if-type]. 415 RFC Ed.: update the date below with the date of RFC publication and 416 remove this note. 418 file "ietf-interfaces@2013-07-04.yang" 420 module ietf-interfaces { 422 namespace "urn:ietf:params:xml:ns:yang:ietf-interfaces"; 423 prefix if; 425 import ietf-yang-types { 426 prefix yang; 427 } 428 import iana-if-type { 429 prefix ianaift; 430 } 432 organization 433 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 435 contact 436 "WG Web: 437 WG List: 439 WG Chair: David Kessens 440 442 WG Chair: Juergen Schoenwaelder 443 445 Editor: Martin Bjorklund 446 "; 448 description 449 "This module contains a collection of YANG definitions for 450 managing network interfaces. 452 Copyright (c) 2013 IETF Trust and the persons identified as 453 authors of the code. All rights reserved. 455 Redistribution and use in source and binary forms, with or 456 without modification, is permitted pursuant to, and subject 457 to the license terms contained in, the Simplified BSD License 458 set forth in Section 4.c of the IETF Trust's Legal Provisions 459 Relating to IETF Documents 460 (http://trustee.ietf.org/license-info). 462 This version of this YANG module is part of RFC XXXX; see 463 the RFC itself for full legal notices."; 465 // RFC Ed.: replace XXXX with actual RFC number and remove this 466 // note. 468 // RFC Ed.: update the date below with the date of RFC publication 469 // and remove this note. 470 revision 2013-07-04 { 471 description 472 "Initial revision."; 473 reference 474 "RFC XXXX: A YANG Data Model for Interface Management"; 475 } 477 /* Typedefs */ 479 typedef interface-ref { 480 type leafref { 481 path "/if:interfaces/if:interface/if:name"; 482 } 483 description 484 "This type is used by data models that need to reference 485 configured interfaces."; 486 } 488 typedef interface-state-ref { 489 type leafref { 490 path "/if:interfaces-state/if:interface/if:name"; 491 } 492 description 493 "This type is used by data models that need to reference 494 the operationally present interfaces."; 495 } 497 /* Features */ 499 feature arbitrary-names { 500 description 501 "This feature indicates that the device allows user-controlled 502 interfaces to be named arbitrarily."; 503 } 505 feature pre-provisioning { 506 description 507 "This feature indicates that the device supports 508 pre-provisioning of interface configuration, i.e., it is 509 possible to configure an interface whose physical interface 510 hardware is not present on the device."; 511 } 513 feature if-mib { 514 description 515 "This feature indicates that the device implements IF-MIB."; 516 reference 517 "RFC 2863: The Interfaces Group MIB"; 518 } 520 /* Data nodes */ 522 container interfaces { 523 description 524 "Interface configuration parameters."; 526 list interface { 527 key "name"; 529 description 530 "The list of configured interfaces on the device. 532 The operational state of an interface is available in the 533 /interfaces-state/interface list. If the configuration of a 534 system-controlled interface cannot be used by the system 535 (e.g., the interface hardware present does not match the 536 interface type), then the configuration is not applied to 537 the system-controlled interface shown in the 538 /interfaces-state/interface list. If the the configuration 539 of a user-controlled interface cannot be used by the system, 540 the configured interface is not instantiated in the 541 /interfaces-state/interface list."; 543 leaf name { 544 type string; 545 description 546 "The name of the interface. 548 A device MAY restrict the allowed values for this leaf, 549 possibly depending on the type of the interface. 551 For system-controlled interfaces, this leaf is the 552 device-specific name of the interface. The 'config false' 553 list /interfaces-state/interface contains the currently 554 existing interfaces on the device. 556 If a client tries to create configuration for a 557 system-controlled interface that is not present in the 558 /interfaces-state/interface list, the server MAY reject 559 the request, if the implementation does not support 560 pre-provisioning of interfaces, or if the name refers to 561 an interface that can never exist in the system. A 562 NETCONF server MUST reply with an rpc-error with the 563 error-tag 'invalid-value' in this case. 565 If the device supports pre-provisioning of interface 566 configuration, the feature 'pre-provisioning' is 567 advertised. 569 If the device allows arbitrarily named user-controlled 570 interfaces, the feature 'arbitrary-names' is advertised. 572 When a configured user-controlled interface is created by 573 the system, it is instantiated with the same name in the 574 /interface-state/interface list. Since the name in that 575 list MAY be mapped to ifName by an implementation, such an 576 implementation MUST restrict the allowed values for this 577 leaf so that it matches the restrictions of ifName. 579 If a NETCONF server that implements this restriction is 580 sent a value that doesn't match the restriction, it MUST 581 reply with an rpc-error with the error-tag 582 'invalid-value'."; 583 } 585 leaf description { 586 type string; 587 description 588 "A textual description of the interface. 590 This leaf MAY be mapped to ifAlias by an implementation. 591 Such an implementation MUST restrict the allowed values 592 for this leaf so that it matches the restrictions of 593 ifAlias. 595 If a NETCONF server that implements this restriction is 596 sent a value that doesn't match the restriction, it MUST 597 reply with an rpc-error with the error-tag 598 'invalid-value'. 600 Since ifAlias is defined to be stored in non-volatile 601 storage, the MIB implementation MUST map ifAlias to the 602 value of 'description' in the persistently stored 603 datastore. 605 Specifically, if the device supports ':startup', when 606 ifAlias is read the device MUST return the value of 607 'description' in the 'startup' datastore, and when it is 608 written, it MUST be written to the 'running' and 'startup' 609 datastores. Note that it is up to the implementation if 610 it modifies this single leaf in 'startup', or if it 611 performs an implicit copy-config from 'running' to 612 'startup'. 614 If the device does not support ':startup', ifAlias MUST 615 be mapped to the 'description' leaf in the 'running' 616 datastore."; 617 reference 618 "RFC 2863: The Interfaces Group MIB - ifAlias"; 619 } 621 leaf type { 622 type ianaift:iana-if-type; 623 mandatory true; 624 description 625 "The type of the interface. 627 When an interface entry is created, a server MAY 628 initialize the type leaf with a valid value, e.g., if it 629 is possible to derive the type from the name of the 630 interface. 632 If a client tries to set the type of an interface to a 633 value that can never be used by the system, e.g., if the 634 type is not supported or if the type does not match the 635 name of the interface, the server MUST reject the request. 636 A NETCONF server MUST reply with an rpc-error with the 637 error-tag 'invalid-value' in this case."; 638 reference 639 "RFC 2863: The Interfaces Group MIB - ifType"; 640 } 642 leaf enabled { 643 type boolean; 644 default "true"; 645 description 646 "This leaf contains the configured, desired state of the 647 interface. 649 Systems that implement the IF-MIB use the value of this 650 leaf in the 'running' datastore to set 651 IF-MIB.ifAdminStatus to 'up' or 'down' after an ifEntry 652 has been initialized, as described in RFC 2863. 654 Changes in this leaf in the 'running' datastore are 655 reflected in ifAdminStatus, but if ifAdminStatus is 656 changed over SNMP, this leaf is not affected."; 657 reference 658 "RFC 2863: The Interfaces Group MIB - ifAdminStatus"; 659 } 661 leaf link-up-down-trap-enable { 662 if-feature if-mib; 663 type enumeration { 664 enum enabled { 665 value 1; 666 } 667 enum disabled { 668 value 2; 669 } 670 } 671 description 672 "Controls whether linkUp/linkDown SNMP notifications 673 should be generated for this interface. 675 If this node is not configured, the value 'enabled' is 676 operationally used by the server for interfaces which do 677 not operate on top of any other interface (i.e., there are 678 no 'lower-layer-if' entries), and 'disabled' otherwise."; 679 reference 680 "RFC 2863: The Interfaces Group MIB - 681 ifLinkUpDownTrapEnable"; 682 } 683 } 684 } 686 container interfaces-state { 687 config false; 688 description 689 "Data nodes for the operational state of interfaces."; 691 list interface { 692 key "name"; 694 description 695 "The list of interfaces on the device. 697 System-controlled interfaces created by the system are 698 always present in this list, whether they are configured or 699 not."; 701 leaf name { 702 type string; 703 description 704 "The name of the interface. 706 This leaf MAY be mapped to ifName by an implementation."; 707 reference 708 "RFC 2863: The Interfaces Group MIB - ifName"; 709 } 711 leaf type { 712 type ianaift:iana-if-type; 713 mandatory true; 714 description 715 "The type of the interface."; 716 reference 717 "RFC 2863: The Interfaces Group MIB - ifType"; 718 } 720 leaf admin-status { 721 if-feature if-mib; 722 type enumeration { 723 enum up { 724 value 1; 725 description 726 "Ready to pass packets."; 727 } 728 enum down { 729 value 2; 730 description 731 "Not ready to pass packets and not in some test mode."; 732 } 733 enum testing { 734 value 3; 735 description 736 "In some test mode."; 737 } 738 } 739 mandatory true; 740 description 741 "The desired state of the interface. 743 This leaf has the same read semantics as ifAdminStatus."; 744 reference 745 "RFC 2863: The Interfaces Group MIB - ifAdminStatus"; 747 } 749 leaf oper-status { 750 type enumeration { 751 enum up { 752 value 1; 753 description 754 "Ready to pass packets."; 755 } 756 enum down { 757 value 2; 758 description 759 "The interface does not pass any packets."; 760 } 761 enum testing { 762 value 3; 763 description 764 "In some test mode. No operational packets can 765 be passed."; 766 } 767 enum unknown { 768 value 4; 769 description 770 "Status cannot be determined for some reason."; 771 } 772 enum dormant { 773 value 5; 774 description 775 "Waiting for some external event."; 776 } 777 enum not-present { 778 value 6; 779 description 780 "Some component (typically hardware) is missing."; 781 } 782 enum lower-layer-down { 783 value 7; 784 description 785 "Down due to state of lower-layer interface(s)."; 786 } 787 } 788 mandatory true; 789 description 790 "The current operational state of the interface. 792 This leaf has the same semantics as ifOperStatus."; 793 reference 794 "RFC 2863: The Interfaces Group MIB - ifOperStatus"; 796 } 798 leaf last-change { 799 type yang:date-and-time; 800 description 801 "The time the interface entered its current operational 802 state. If the current state was entered prior to the 803 last re-initialization of the local network management 804 subsystem, then this node is not present."; 805 reference 806 "RFC 2863: The Interfaces Group MIB - ifLastChange"; 807 } 809 leaf if-index { 810 if-feature if-mib; 811 type int32 { 812 range "1..2147483647"; 813 } 814 mandatory true; 815 description 816 "The ifIndex value for the ifEntry represented by this 817 interface."; 818 reference 819 "RFC 2863: The Interfaces Group MIB - ifIndex"; 820 } 822 leaf phys-address { 823 type yang:phys-address; 824 description 825 "The interface's address at its protocol sub-layer. For 826 example, for an 802.x interface, this object normally 827 contains a MAC address. The interface's media-specific 828 modules must define the bit and byte ordering and the 829 format of the value of this object. For interfaces that do 830 not have such an address (e.g., a serial line), this node 831 is not present."; 832 reference 833 "RFC 2863: The Interfaces Group MIB - ifPhysAddress"; 834 } 836 leaf-list higher-layer-if { 837 type interface-state-ref; 838 description 839 "A list of references to interfaces layered on top of this 840 interface."; 841 reference 842 "RFC 2863: The Interfaces Group MIB - ifStackTable"; 843 } 844 leaf-list lower-layer-if { 845 type interface-state-ref; 846 description 847 "A list of references to interfaces layered underneath this 848 interface."; 849 reference 850 "RFC 2863: The Interfaces Group MIB - ifStackTable"; 851 } 853 leaf speed { 854 type yang:gauge64; 855 units "bits / second"; 856 description 857 "An estimate of the interface's current bandwidth in bits 858 per second. For interfaces that do not vary in 859 bandwidth or for those where no accurate estimation can 860 be made, this node should contain the nominal bandwidth. 861 For interfaces that have no concept of bandwidth, this 862 node is not present."; 863 reference 864 "RFC 2863: The Interfaces Group MIB - 865 ifSpeed, ifHighSpeed"; 866 } 868 container statistics { 869 description 870 "A collection of interface-related statistics objects."; 872 leaf discontinuity-time { 873 type yang:date-and-time; 874 mandatory true; 875 description 876 "The time on the most recent occasion at which any one or 877 more of this interface's counters suffered a 878 discontinuity. If no such discontinuities have occurred 879 since the last re-initialization of the local management 880 subsystem, then this node contains the time the local 881 management subsystem re-initialized itself."; 882 } 884 leaf in-octets { 885 type yang:counter64; 886 description 887 "The total number of octets received on the interface, 888 including framing characters. 890 Discontinuities in the value of this counter can occur 891 at re-initialization of the management system, and at 892 other times as indicated by the value of 893 'discontinuity-time'."; 894 reference 895 "RFC 2863: The Interfaces Group MIB - ifHCInOctets"; 896 } 897 leaf in-unicast-pkts { 898 type yang:counter64; 899 description 900 "The number of packets, delivered by this sub-layer to a 901 higher (sub-)layer, which were not addressed to a 902 multicast or broadcast address at this sub-layer. 904 Discontinuities in the value of this counter can occur 905 at re-initialization of the management system, and at 906 other times as indicated by the value of 907 'discontinuity-time'."; 908 reference 909 "RFC 2863: The Interfaces Group MIB - ifHCInUcastPkts"; 910 } 911 leaf in-broadcast-pkts { 912 type yang:counter64; 913 description 914 "The number of packets, delivered by this sub-layer to a 915 higher (sub-)layer, which were addressed to a broadcast 916 address at this sub-layer. 918 Discontinuities in the value of this counter can occur 919 at re-initialization of the management system, and at 920 other times as indicated by the value of 921 'discontinuity-time'."; 922 reference 923 "RFC 2863: The Interfaces Group MIB - 924 ifHCInBroadcastPkts"; 925 } 926 leaf in-multicast-pkts { 927 type yang:counter64; 928 description 929 "The number of packets, delivered by this sub-layer to a 930 higher (sub-)layer, which were addressed to a multicast 931 address at this sub-layer. For a MAC layer protocol, 932 this includes both Group and Functional addresses. 934 Discontinuities in the value of this counter can occur 935 at re-initialization of the management system, and at 936 other times as indicated by the value of 937 'discontinuity-time'."; 938 reference 939 "RFC 2863: The Interfaces Group MIB - 940 ifHCInMulticastPkts"; 941 } 942 leaf in-discards { 943 type yang:counter32; 944 description 945 "The number of inbound packets which were chosen to be 946 discarded even though no errors had been detected to 947 prevent their being deliverable to a higher-layer 948 protocol. One possible reason for discarding such a 949 packet could be to free up buffer space. 951 Discontinuities in the value of this counter can occur 952 at re-initialization of the management system, and at 953 other times as indicated by the value of 954 'discontinuity-time'."; 955 reference 956 "RFC 2863: The Interfaces Group MIB - ifInDiscards"; 957 } 958 leaf in-errors { 959 type yang:counter32; 960 description 961 "For packet-oriented interfaces, the number of inbound 962 packets that contained errors preventing them from being 963 deliverable to a higher-layer protocol. For character- 964 oriented or fixed-length interfaces, the number of 965 inbound transmission units that contained errors 966 preventing them from being deliverable to a higher-layer 967 protocol. 969 Discontinuities in the value of this counter can occur 970 at re-initialization of the management system, and at 971 other times as indicated by the value of 972 'discontinuity-time'."; 973 reference 974 "RFC 2863: The Interfaces Group MIB - ifInErrors"; 975 } 976 leaf in-unknown-protos { 977 type yang:counter32; 978 description 979 "For packet-oriented interfaces, the number of packets 980 received via the interface which were discarded because 981 of an unknown or unsupported protocol. For 982 character-oriented or fixed-length interfaces that 983 support protocol multiplexing the number of transmission 984 units received via the interface which were discarded 985 because of an unknown or unsupported protocol. For any 986 interface that does not support protocol multiplexing, 987 this counter is not present. 989 Discontinuities in the value of this counter can occur 990 at re-initialization of the management system, and at 991 other times as indicated by the value of 992 'discontinuity-time'."; 993 reference 994 "RFC 2863: The Interfaces Group MIB - ifInUnknownProtos"; 995 } 997 leaf out-octets { 998 type yang:counter64; 999 description 1000 "The total number of octets transmitted out of the 1001 interface, including framing characters. 1003 Discontinuities in the value of this counter can occur 1004 at re-initialization of the management system, and at 1005 other times as indicated by the value of 1006 'discontinuity-time'."; 1007 reference 1008 "RFC 2863: The Interfaces Group MIB - ifHCOutOctets"; 1009 } 1010 leaf out-unicast-pkts { 1011 type yang:counter64; 1012 description 1013 "The total number of packets that higher-level protocols 1014 requested be transmitted, and which were not addressed 1015 to a multicast or broadcast address at this sub-layer, 1016 including those that were discarded or not sent. 1018 Discontinuities in the value of this counter can occur 1019 at re-initialization of the management system, and at 1020 other times as indicated by the value of 1021 'discontinuity-time'."; 1022 reference 1023 "RFC 2863: The Interfaces Group MIB - ifHCOutUcastPkts"; 1024 } 1025 leaf out-broadcast-pkts { 1026 type yang:counter64; 1027 description 1028 "The total number of packets that higher-level protocols 1029 requested be transmitted, and which were addressed to a 1030 broadcast address at this sub-layer, including those 1031 that were discarded or not sent. 1033 Discontinuities in the value of this counter can occur 1034 at re-initialization of the management system, and at 1035 other times as indicated by the value of 1036 'discontinuity-time'."; 1038 reference 1039 "RFC 2863: The Interfaces Group MIB - 1040 ifHCOutBroadcastPkts"; 1041 } 1042 leaf out-multicast-pkts { 1043 type yang:counter64; 1044 description 1045 "The total number of packets that higher-level protocols 1046 requested be transmitted, and which were addressed to a 1047 multicast address at this sub-layer, including those 1048 that were discarded or not sent. For a MAC layer 1049 protocol, this includes both Group and Functional 1050 addresses. 1052 Discontinuities in the value of this counter can occur 1053 at re-initialization of the management system, and at 1054 other times as indicated by the value of 1055 'discontinuity-time'."; 1056 reference 1057 "RFC 2863: The Interfaces Group MIB - 1058 ifHCOutMulticastPkts"; 1059 } 1060 leaf out-discards { 1061 type yang:counter32; 1062 description 1063 "The number of outbound packets which were chosen to be 1064 discarded even though no errors had been detected to 1065 prevent their being transmitted. One possible reason 1066 for discarding such a packet could be to free up buffer 1067 space. 1069 Discontinuities in the value of this counter can occur 1070 at re-initialization of the management system, and at 1071 other times as indicated by the value of 1072 'discontinuity-time'."; 1073 reference 1074 "RFC 2863: The Interfaces Group MIB - ifOutDiscards"; 1075 } 1076 leaf out-errors { 1077 type yang:counter32; 1078 description 1079 "For packet-oriented interfaces, the number of outbound 1080 packets that could not be transmitted because of errors. 1081 For character-oriented or fixed-length interfaces, the 1082 number of outbound transmission units that could not be 1083 transmitted because of errors. 1085 Discontinuities in the value of this counter can occur 1086 at re-initialization of the management system, and at 1087 other times as indicated by the value of 1088 'discontinuity-time'."; 1089 reference 1090 "RFC 2863: The Interfaces Group MIB - ifOutErrors"; 1091 } 1092 } 1093 } 1094 } 1095 } 1097 1099 6. IANA Considerations 1101 This document registers a URI in the IETF XML registry [RFC3688]. 1102 Following the format in RFC 3688, the following registration is 1103 requested to be made. 1105 URI: urn:ietf:params:xml:ns:yang:ietf-interfaces 1107 Registrant Contact: The IESG. 1109 XML: N/A, the requested URI is an XML namespace. 1111 This document registers a YANG module in the YANG Module Names 1112 registry [RFC6020]. 1114 name: ietf-interfaces 1115 namespace: urn:ietf:params:xml:ns:yang:ietf-interfaces 1116 prefix: if 1117 reference: RFC XXXX 1119 7. Security Considerations 1121 The YANG module defined in this memo is designed to be accessed via 1122 the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the 1123 secure transport layer and the mandatory-to-implement secure 1124 transport is SSH [RFC6242]. The NETCONF access control model 1125 [RFC6536] provides the means to restrict access for particular 1126 NETCONF users to a pre-configured subset of all available NETCONF 1127 protocol operations and content. 1129 There are a number of data nodes defined in the YANG module which are 1130 writable/creatable/deletable (i.e., config true, which is the 1131 default). These data nodes may be considered sensitive or vulnerable 1132 in some network environments. Write operations (e.g., ) 1133 to these data nodes without proper protection can have a negative 1134 effect on network operations. These are the subtrees and data nodes 1135 and their sensitivity/vulnerability: 1137 /interfaces/interface: This list specifies the configured interfaces 1138 on a device. Unauthorized access to this list could cause the 1139 device to ignore packets it should receive and process. 1141 /interfaces/interface/enabled: This leaf controls if an interface is 1142 enabled or not. Unauthorized access to this leaf could cause the 1143 device to ignore packets it should receive and process. 1145 8. Acknowledgments 1147 The author wishes to thank Alexander Clemm, Per Hedeland, Ladislav 1148 Lhotka, and Juergen Schoenwaelder for their helpful comments. 1150 9. References 1152 9.1. Normative References 1154 [I-D.ietf-netmod-iana-if-type] 1155 Bjorklund, M., "IANA Interface Type YANG Module", 1156 draft-ietf-netmod-iana-if-type-07 (work in progress), 1157 July 2013. 1159 [I-D.ietf-netmod-rfc6021-bis] 1160 Schoenwaelder, J., "Common YANG Data Types", 1161 draft-ietf-netmod-rfc6021-bis-03 (work in progress), 1162 June 2013. 1164 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1165 Requirement Levels", BCP 14, RFC 2119, March 1997. 1167 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 1168 MIB", RFC 2863, June 2000. 1170 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1171 January 2004. 1173 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 1174 Network Configuration Protocol (NETCONF)", RFC 6020, 1175 October 2010. 1177 9.2. Informative References 1179 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1180 Schoenwaelder, Ed., "Textual Conventions for SMIv2", 1181 STD 58, RFC 2579, April 1999. 1183 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 1184 Bierman, "Network Configuration Protocol (NETCONF)", 1185 RFC 6241, June 2011. 1187 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1188 Shell (SSH)", RFC 6242, June 2011. 1190 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1191 Protocol (NETCONF) Access Control Model", RFC 6536, 1192 March 2012. 1194 Appendix A. Example: Ethernet Interface Module 1196 This section gives a simple example of how an Ethernet interface 1197 module could be defined. It demonstrates how media-specific 1198 configuration parameters can be conditionally augmented to the 1199 generic interface list. It also shows how operational state 1200 parameters can be conditionally augmented to the operational 1201 interface list. The example is not intended as a complete module for 1202 ethernet configuration. 1204 module ex-ethernet { 1205 namespace "http://example.com/ethernet"; 1206 prefix "eth"; 1208 import ietf-interfaces { 1209 prefix if; 1210 } 1212 // configuration parameters for ethernet interfaces 1213 augment "/if:interfaces/if:interface" { 1214 when "if:type = 'ethernetCsmacd'"; 1216 container ethernet { 1217 choice transmission-params { 1218 case auto { 1219 leaf auto-negotiate { 1220 type empty; 1221 } 1222 } 1223 case manual { 1224 leaf duplex { 1225 type enumeration { 1226 enum "half"; 1227 enum "full"; 1228 } 1229 } 1230 leaf speed { 1231 type enumeration { 1232 enum "10Mb"; 1233 enum "100Mb"; 1234 enum "1Gb"; 1235 enum "10Gb"; 1236 } 1237 } 1238 } 1239 } 1240 // other ethernet specific params... 1241 } 1243 } 1245 // operational state parameters for ethernet interfaces 1246 augment "/if:interfaces-state/if:interface" { 1247 when "if:type = 'ethernetCsmacd'"; 1249 container ethernet { 1250 leaf duplex { 1251 type enumeration { 1252 enum "half"; 1253 enum "full"; 1254 } 1255 } 1256 // other ethernet specific params... 1257 } 1258 } 1259 } 1261 Appendix B. Example: Ethernet Bonding Interface Module 1263 This section gives an example of how interface layering can be 1264 defined. An ethernet bonding interface is defined, which bonds 1265 several ethernet interfaces into one logical interface. 1267 module ex-ethernet-bonding { 1268 namespace "http://example.com/ethernet-bonding"; 1269 prefix "bond"; 1271 import ietf-interfaces { 1272 prefix if; 1273 } 1275 augment "/if:interfaces/if:interface" { 1276 when "if:type = 'ieee8023adLag'"; 1278 leaf-list slave-if { 1279 type if:interface-ref; 1280 must "/if:interfaces/if:interface[if:name = current()]" 1281 + "/if:type = 'ethernetCsmacd'" { 1282 description 1283 "The type of a slave interface must be ethernet."; 1284 } 1285 } 1286 leaf bonding-mode { 1287 type enumeration { 1288 enum round-robin; 1289 enum active-backup; 1290 enum broadcast; 1291 } 1292 } 1293 // other bonding config params, failover times etc. 1294 } 1295 } 1297 Appendix C. Example: VLAN Interface Module 1299 This section gives an example of how a vlan interface module can be 1300 defined. 1302 module ex-vlan { 1303 namespace "http://example.com/vlan"; 1304 prefix "vlan"; 1306 import ietf-interfaces { 1307 prefix if; 1308 } 1310 augment "/if:interfaces/if:interface" { 1311 when "if:type = 'ethernetCsmacd' or 1312 if:type = 'ieee8023adLag'"; 1313 leaf vlan-tagging { 1314 type boolean; 1315 default false; 1316 } 1317 } 1319 augment "/if:interfaces/if:interface" { 1320 when "if:type = 'l2vlan'"; 1322 leaf base-interface { 1323 type if:interface-ref; 1324 must "/if:interfaces/if:interface[if:name = current()]" 1325 + "/vlan:vlan-tagging = 'true'" { 1326 description 1327 "The base interface must have vlan tagging enabled."; 1328 } 1329 } 1330 leaf vlan-id { 1331 type uint16 { 1332 range "1..4094"; 1333 } 1334 must "../base-interface" { 1335 description 1336 "If a vlan-id is defined, a base-interface must 1337 be specified."; 1338 } 1339 } 1340 } 1341 } 1343 Appendix D. Example: NETCONF reply 1345 This section gives an example of a reply to the NETCONF request 1346 for a device that implements the example data models above. 1348 1351 1353 1357 1358 eth0 1359 ethernetCsmacd 1360 false 1361 1363 1364 eth1 1365 ethernetCsmacd 1366 true 1367 true 1368 1370 1371 eth1.10 1372 l2vlan 1373 true 1374 eth1 1375 10 1376 1378 1379 lo1 1380 softwareLoopback 1381 true 1382 1384 1386 1389 1390 eth0 1391 ethernetCsmacd 1392 down 1393 down 1394 2 1395 00:01:02:03:04:05 1396 1397 1398 2013-04-01T03:00:00+00:00 1399 1400 1401 1402 1404 1405 eth1 1406 ethernetCsmacd 1407 up 1408 up 1409 7 1410 00:01:02:03:04:06 1411 eth1.10 1412 1413 1414 2013-04-01T03:00:00+00:00 1415 1416 1417 1418 1420 1421 eth1.10 1422 l2vlan 1423 up 1424 up 1425 9 1426 eth1 1427 1428 1429 2013-04-01T03:00:00+00:00 1430 1431 1432 1433 1435 1436 1437 eth2 1438 ethernetCsmacd 1439 down 1440 down 1441 8 1442 00:01:02:03:04:07 1443 1444 1445 2013-04-01T03:00:00+00:00 1446 1447 1448 1449 1451 1452 lo1 1453 softwareLoopback 1454 up 1455 up 1456 1 1457 1458 1459 2013-04-01T03:00:00+00:00 1460 1461 1462 1463 1465 1466 1467 1469 Appendix E. Examples: Interface Naming Schemes 1471 This section gives examples of some implementation strategies. 1473 The examples make use of the example data model "ex-vlan" (see 1474 Appendix C) to show how user-controlled interfaces can be configured. 1476 E.1. Router with Restricted Interface Names 1478 In this example, a router has support for 4 line cards, each with 8 1479 ports. The slots for the cards are physically numbered from 0 to 3, 1480 and the ports on each card from 0 to 7. Each card has fast- or 1481 gigabit-ethernet ports. 1483 The device-specific names for these physical interfaces are 1484 "fastethernet-N/M" or "gigabitethernet-N/M". 1486 The name of a vlan interface is restricted to the form 1487 ".". 1489 It is assumed that the operator is aware of this naming scheme. The 1490 implementation auto-initializes the value for "type" based on the 1491 interface name. 1493 The NETCONF server does not advertise the 'arbitrary-names' feature 1494 in the message. 1496 An operator can configure a physical interface by sending an 1497 containing: 1499 1500 fastethernet-1/0 1501 1503 When the server processes this request, it will set the leaf "type" 1504 to "ethernetCsmacd". Thus, if the client performs a 1505 right after the above, it will get: 1507 1508 fastethernet-1/0 1509 ethernetCsmacd 1510 1512 The client can configure a vlan interface by sending an 1513 containing: 1515 1516 fastethernet-1/0.10005 1517 l2-vlan 1518 fastethernet-1/0 1519 5 1520 1522 If the client tries to change the type of the physical interface with 1523 an containing: 1525 1526 fastethernet-1/0 1527 tunnel 1528 1530 then the server will reply with an "invalid-value" error, since the 1531 new type does not match the name. 1533 E.2. Router with Arbitrary 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 implementation does not restrict the user-controlled interface 1544 names. This allows to more easily apply the interface configuration 1545 to a different interface. However, the additional level of 1546 indirection also makes it a bit more complex to map interface names 1547 found in other protocols to configuration entries. 1549 The NETCONF server advertises the 'arbitrary-names' feature in the 1550 message. 1552 Physical interfaces are configured as in Appendix E.1. 1554 An operator can configure a VLAN interface by sending an 1555 containing: 1557 1558 acme-interface 1559 l2-vlan 1560 fastethernet-1/0 1561 5 1562 1564 If necessary, the operator can move the configuration named 1565 "acme-interface" over to a different physical interface with an 1566 containing: 1568 1569 acme-interface 1570 fastethernet-1/1 1571 1573 E.3. Ethernet Switch with Restricted Interface Names 1575 In this example, an ethernet switch has a number of ports, each port 1576 identified by a simple port number. 1578 The device-specific names for the physical interfaces are numbers 1579 that match the physical port number. 1581 An operator can configure a physical interface by sending an 1582 containing: 1584 1585 6 1586 1588 When the server processes this request, it will set the leaf "type" 1589 to "ethernetCsmacd". Thus, if the client performs a 1590 right after the above, it will get: 1592 1593 6 1594 ethernetCsmacd 1595 1597 E.4. Generic Host with Restricted Interface Names 1599 In this example, a generic host has interfaces named by the kernel. 1600 The system identifies the physical interface by the name assigned by 1601 the operating system to the interface. 1603 The name of a vlan interface is restricted to the form 1604 ":". 1606 The NETCONF server does not advertise the 'arbitrary-names' feature 1607 in the message. 1609 An operator can configure an interface by sending an 1610 containing: 1612 1613 eth8 1614 1616 When the server processes this request, it will set the leaf "type" 1617 to "ethernetCsmacd". Thus, if the client performs a 1618 right after the above, it will get: 1620 1621 eth8 1622 ethernetCsmacd 1623 1625 The client can configure a vlan interface by sending an 1626 containing: 1628 1629 eth8:5 1630 l2-vlan 1631 eth8 1632 5 1633 1635 E.5. Generic Host with Arbitrary 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 implementation does not restrict the user-controlled interface 1642 names. This allows to more easily apply the interface configuration 1643 to a different interface. However, the additional level of 1644 indirection also makes it a bit more complex to map interface names 1645 found in other protocols to configuration entries. 1647 The NETCONF server advertises the 'arbitrary-names' feature in the 1648 message. 1650 Physical interfaces are configured as in Appendix E.4. 1652 An operator can configure a VLAN interface by sending an 1653 containing: 1655 1656 acme-interface 1657 l2-vlan 1658 eth8 1659 5 1661 1663 If necessary, the operator can move the configuration named 1664 "acme-interface" over to a different physical interface with an 1665 containing: 1667 1668 acme-interface 1669 eth3 1670 1672 Appendix F. ChangeLog 1674 RFC Editor: remove this section upon publication as an RFC. 1676 F.1. Version -11 1678 o Separated the operational state from the configuration. 1680 o Removed 'location', and instead use the name to identify physical 1681 interfaces. 1683 o Added the feature 'pre-provisioning'. 1685 o Made 'oper-status' and 'if-index' mandatory in the data model. 1687 o Added 'admin-status'. 1689 o Clarified why description can be mapped to ifAlias. 1691 o Clarified that 64-bit counters only are used, where there exist 1692 64-bit and 32-bit counters in IF-MIB. 1694 o Updated Security Considerations section with a reference to NACM. 1696 F.2. Version -08 1698 o Removed the mtu leaf. 1700 o Added examples of different interface naming schemes. 1702 F.3. Version -07 1704 o Made leaf speed config false. 1706 F.4. Version -06 1708 o Added oper-status leaf. 1710 o Added leaf-lists higher-layer-if and lower-layer-if, that show the 1711 interface layering. 1713 o Added container statistics with counters. 1715 F.5. Version -05 1717 o Added an Informative References section. 1719 o Updated the Security Considerations section. 1721 o Clarified the behavior of an NETCONF server when invalid values 1722 are received. 1724 F.6. Version -04 1726 o Clarified why ifPromiscuousMode is not part of this data model. 1728 o Added a table that shows the mapping between this YANG data model 1729 and IF-MIB. 1731 F.7. Version -03 1733 o Added the section Relationship to the IF-MIB. 1735 o Changed if-index to be a leaf instead of leaf-list. 1737 o Explained the notation used in the data model tree picture. 1739 F.8. Version -02 1741 o Editorial fixes 1743 F.9. Version -01 1745 o Changed leaf "if-admin-status" to leaf "enabled". 1747 o Added Security Considerations 1749 Author's Address 1751 Martin Bjorklund 1752 Tail-f Systems 1754 Email: mbj@tail-f.com