idnits 2.17.1 draft-ietf-netmod-interfaces-cfg-13.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 234 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 (November 7, 2013) is 3816 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 November 7, 2013 5 Expires: May 11, 2014 7 A YANG Data Model for Interface Management 8 draft-ietf-netmod-interfaces-cfg-13 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 May 11, 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, state data and counters 103 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 1.2. Tree Diagrams 152 A simplified graphical representation of the data model is used in 153 this document. The meaning of the symbols in these diagrams is as 154 follows: 156 o Brackets "[" and "]" enclose list keys. 158 o Abbreviations before data node names: "rw" means configuration 159 (read-write) and "ro" state data (read-only). 161 o Symbols after data node names: "?" means an optional node, "!" 162 means a presence container, and "*" denotes a list and leaf-list. 164 o Parentheses enclose choice and case nodes, and case nodes are also 165 marked with a colon (":"). 167 o Ellipsis ("...") stands for contents of subtrees that are not 168 shown. 170 2. Objectives 172 This section describes some of the design objectives for the model 173 presented in Section 5. 175 o It is recognized that existing implementations will have to map 176 the interface data model defined in this memo to their proprietary 177 native data model. The data model should be simple to facilitate 178 such mappings. 180 o The data model should be suitable for new implementations to use 181 as-is, without requiring a mapping to a different native model. 183 o References to interfaces should be as simple as possible, 184 preferably by using a single leafref. 186 o The mapping to ifIndex [RFC2863] used by SNMP to identify 187 interfaces must be clear. 189 o The model must support interface layering, both simple layering 190 where one interface is layered on top of exactly one other 191 interface, and more complex scenarios where one interface results 192 from the aggregation of N other interfaces, or when N interfaces 193 are multiplexed over one other interface. 195 o The data model should support the pre-provisioning of interface 196 configuration, i.e., it should be possible to configure an 197 interface whose physical interface hardware is not present on the 198 device. It is recommended that devices that support dynamic 199 addition and removal of physical interfaces also support pre- 200 provisioning. 202 o The data model should support both physical interfaces as well as 203 logical interfaces. 205 o The data model should include read-only counters in order to 206 gather statistics for octets, packets and errors, sent and 207 received. 209 3. Interfaces Data Model 211 This document defines the YANG module "ietf-interfaces", which has 212 the following structure: 214 +--rw interfaces 215 | +--rw interface* [name] 216 | +--rw name string 217 | +--rw description? string 218 | +--rw type identityref 219 | +--rw enabled? boolean 220 | +--rw link-up-down-trap-enable? enumeration 221 +--ro interfaces-state 222 +--ro interface* [name] 223 +--ro name string 224 +--ro type identityref 225 +--ro admin-status enumeration 226 +--ro oper-status enumeration 227 +--ro last-change? yang:date-and-time 228 +--ro if-index int32 229 +--ro phys-address? yang:phys-address 230 +--ro higher-layer-if* interface-state-ref 231 +--ro lower-layer-if* interface-state-ref 232 +--ro speed? yang:gauge64 233 +--ro statistics 234 +--ro discontinuity-time yang:date-and-time 235 +--ro in-octets? yang:counter64 236 +--ro in-unicast-pkts? yang:counter64 237 +--ro in-broadcast-pkts? yang:counter64 238 +--ro in-multicast-pkts? yang:counter64 239 +--ro in-discards? yang:counter32 240 +--ro in-errors? yang:counter32 241 +--ro in-unknown-protos? yang:counter32 242 +--ro out-octets? yang:counter64 243 +--ro out-unicast-pkts? yang:counter64 244 +--ro out-broadcast-pkts? yang:counter64 245 +--ro out-multicast-pkts? yang:counter64 246 +--ro out-discards? yang:counter32 247 +--ro out-errors? yang:counter32 249 3.1. The interface Lists 251 The data model for interfaces presented in this document uses a flat 252 list of interfaces. Each interface in the list is identified by its 253 name. Furthermore, each interface has a mandatory "type" leaf. 255 The "iana-if-type" module [I-D.ietf-netmod-iana-if-type] defines YANG 256 identities for the interface types in the IANA-maintained "ifType 257 registry". 259 There is one list of configured interfaces ("/interfaces/interface"), 260 and a separate list for the operational state of all interfaces 261 ("/interfaces-state/interface"). 263 It is expected that interface type specific data models augment the 264 interface lists, and possibly use the "type" leaf to make the 265 augmentation conditional. 267 As an example of such an interface type specific augmentation, 268 consider this YANG snippet. For a more complete example, see 269 Appendix A. 271 import interfaces { 272 prefix "if"; 273 } 274 import iana-if-type { 275 prefix ianaift; 276 } 278 augment "/if:interfaces/if:interface" { 279 when "if:type = 'ianaift:ethernetCsmacd'"; 281 container ethernet { 282 leaf duplex { 283 ... 284 } 285 } 286 } 288 For system-controlled interfaces, the "name" is the device-specific 289 name of the interface. The 'config false' list "/interfaces-state/ 290 interface" contains all existing interfaces on the device. 292 If the device supports arbitrarily named user-controlled interfaces, 293 the NETCONF server advertises the feature "arbitrary-names". If the 294 device does not advertise this feature, the names of user-controlled 295 interfaces MUST match the device's naming scheme. How a client can 296 learn the naming scheme of such devices is outside the scope of this 297 document. 299 When a system-controlled interface is created by the system, the 300 system tries to apply the interface configuration in /interfaces/ 301 interface with the same name as the new interface. If no such 302 interface configuration is found, or if the configured type does not 303 match the real interface type, the system creates the interface 304 without applying explicit configuration. 306 When a user-controlled interface is created, the configuration 307 determines the name of the interface. 309 3.2. Interface References 311 An interface is identified by its name, which is unique within the 312 server. This property is captured in the "interface-ref" and 313 "interface-state-ref" typedefs, which other YANG modules SHOULD use 314 when they need to reference a configured interface or operationally 315 used interface, respectively. 317 3.3. Interface Layering 319 There is no generic mechanism for how an interface is configured to 320 be layered on top of some other interface. It is expected that 321 interface type specific models define their own data nodes for 322 interface layering, by using "interface-ref" types to reference lower 323 layers. 325 Below is an example of a model with such nodes. For a more complete 326 example, see Appendix B. 328 import interfaces { 329 prefix "if"; 330 } 331 import iana-if-type { 332 prefix ianaift; 333 } 335 augment "/if:interfaces/if:interface" { 336 when "if:type = 'ianaift:ieee8023adLag'"; 338 leaf-list slave-if { 339 type if:interface-ref; 340 must "/if:interfaces/if:interface[if:name = current()]" 341 + "/if:type = 'ianaift:ethernetCsmacd'" { 342 description 343 "The type of a slave interface must be ethernet"; 344 } 345 } 346 // other bonding config params, failover times etc. 347 } 349 Two state data leaf-lists, "higher-layer-if" and "lower-layer-if", 350 represent a read-only view of the interface layering hierarchy. 352 4. Relationship to the IF-MIB 354 If the device implements IF-MIB [RFC2863], each entry in the 355 "/interfaces-state/interface" list is typically mapped to one 356 ifEntry. The "if-index" leaf MUST contain the value of the 357 corresponding ifEntry's ifIndex. 359 In most cases, the "name" of an "interface" entry is mapped to 360 ifName. ifName is defined as an DisplayString [RFC2579] which uses a 361 7-bit ASCII character set. An implementation MUST restrict the 362 allowed values for "name" to match the restrictions of ifName. 364 The IF-MIB allows two different ifEntries to have the same ifName. 365 Devices that support this feature, and also support the data model 366 defined in this document, cannot have a 1-1 mapping between the 367 "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 YANG module 381 contains the 64 bits counters only. Note that NETCONF and SNMP may 382 differ in the time granularity in which they provide access to the 383 counters. For example, it is common that SNMP implementations cache 384 counter values for some time. 386 The following table lists the YANG data nodes with corresponding 387 objects in the IF-MIB. 389 +----------------------------------+------------------------+ 390 | YANG data node | IF-MIB object | 391 +----------------------------------+------------------------+ 392 | /interfaces-state/interface | ifEntry | 393 | /interfaces-state/name | ifName | 394 | description | ifAlias | 395 | type | ifType | 396 | enabled / admin-status | ifAdminStatus | 397 | oper-status | ifOperStatus | 398 | last-change | ifLastChange | 399 | if-index | ifIndex | 400 | link-up-down-trap-enable | ifLinkUpDownTrapEnable | 401 | phys-address | ifPhysAddress | 402 | higher-layer-if / lower-layer-if | ifStackTable | 403 | speed | ifSpeed | 404 | in-octets | ifHCInOctets | 405 | in-unicast-pkts | ifHCInUcastPkts | 406 | in-broadcast-pkts | ifHCInBroadcastPkts | 407 | in-multicast-pkts | ifHCInMulticastPkts | 408 | in-discards | ifInDiscards | 409 | in-errors | ifInErrors | 410 | in-unknown-protos | ifInUnknownProtos | 411 | out-octets | ifHCOutOctets | 412 | out-unicast-pkts | ifHCOutUcastPkts | 413 | out-broadcast-pkts | ifHCOutBroadcastPkts | 414 | out-multicast-pkts | ifHCOutMulticastPkts | 415 | out-discards | ifOutDiscards | 416 | out-errors | ifOutErrors | 417 +----------------------------------+------------------------+ 419 YANG data nodes and related IF-MIB objects 421 5. Interfaces YANG Module 423 This YANG module imports typedefs from [RFC6991]. 425 RFC Ed.: update the date below with the date of RFC publication and 426 remove this note. 428 file "ietf-interfaces@2013-11-07.yang" 430 module ietf-interfaces { 432 namespace "urn:ietf:params:xml:ns:yang:ietf-interfaces"; 433 prefix if; 435 import ietf-yang-types { 436 prefix yang; 437 } 439 organization 440 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 442 contact 443 "WG Web: 444 WG List: 446 WG Chair: David Kessens 447 449 WG Chair: Juergen Schoenwaelder 450 452 Editor: Martin Bjorklund 453 "; 455 description 456 "This module contains a collection of YANG definitions for 457 managing network interfaces. 459 Copyright (c) 2013 IETF Trust and the persons identified as 460 authors of the code. All rights reserved. 462 Redistribution and use in source and binary forms, with or 463 without modification, is permitted pursuant to, and subject 464 to the license terms contained in, the Simplified BSD License 465 set forth in Section 4.c of the IETF Trust's Legal Provisions 466 Relating to IETF Documents 467 (http://trustee.ietf.org/license-info). 468 This version of this YANG module is part of RFC XXXX; see 469 the RFC itself for full legal notices."; 471 // RFC Ed.: replace XXXX with actual RFC number and remove this 472 // note. 474 // RFC Ed.: update the date below with the date of RFC publication 475 // and remove this note. 476 revision 2013-07-04 { 477 description 478 "Initial revision."; 479 reference 480 "RFC XXXX: A YANG Data Model for Interface Management"; 481 } 483 /* 484 * Typedefs 485 */ 487 typedef interface-ref { 488 type leafref { 489 path "/if:interfaces/if:interface/if:name"; 490 } 491 description 492 "This type is used by data models that need to reference 493 configured interfaces."; 494 } 496 typedef interface-state-ref { 497 type leafref { 498 path "/if:interfaces-state/if:interface/if:name"; 499 } 500 description 501 "This type is used by data models that need to reference 502 the operationally present interfaces."; 503 } 505 /* 506 * Identities 507 */ 509 identity interface-type { 510 description 511 "Base identity from which specific interface types are 512 derived."; 513 } 515 /* 516 * Features 517 */ 519 feature arbitrary-names { 520 description 521 "This feature indicates that the device allows user-controlled 522 interfaces to be named arbitrarily."; 523 } 525 feature pre-provisioning { 526 description 527 "This feature indicates that the device supports 528 pre-provisioning of interface configuration, i.e., it is 529 possible to configure an interface whose physical interface 530 hardware is not present on the device."; 531 } 533 feature if-mib { 534 description 535 "This feature indicates that the device implements IF-MIB."; 536 reference 537 "RFC 2863: The Interfaces Group MIB"; 538 } 540 /* 541 * Configuration data nodes 542 */ 544 container interfaces { 545 description 546 "Interface configuration parameters."; 548 list interface { 549 key "name"; 551 description 552 "The list of configured interfaces on the device. 554 The operational state of an interface is available in the 555 /interfaces-state/interface list. If the configuration of a 556 system-controlled interface cannot be used by the system 557 (e.g., the interface hardware present does not match the 558 interface type), then the configuration is not applied to 559 the system-controlled interface shown in the 560 /interfaces-state/interface list. If the the configuration 561 of a user-controlled interface cannot be used by the system, 562 the configured interface is not instantiated in the 563 /interfaces-state/interface list."; 565 leaf name { 566 type string; 567 description 568 "The name of the interface. 570 A device MAY restrict the allowed values for this leaf, 571 possibly depending on the type of the interface. 573 For system-controlled interfaces, this leaf is the 574 device-specific name of the interface. The 'config false' 575 list /interfaces-state/interface contains the currently 576 existing interfaces on the device. 578 If a client tries to create configuration for a 579 system-controlled interface that is not present in the 580 /interfaces-state/interface list, the server MAY reject 581 the request, if the implementation does not support 582 pre-provisioning of interfaces, or if the name refers to 583 an interface that can never exist in the system. A 584 NETCONF server MUST reply with an rpc-error with the 585 error-tag 'invalid-value' in this case. 587 If the device supports pre-provisioning of interface 588 configuration, the feature 'pre-provisioning' is 589 advertised. 591 If the device allows arbitrarily named user-controlled 592 interfaces, the feature 'arbitrary-names' is advertised. 594 When a configured user-controlled interface is created by 595 the system, it is instantiated with the same name in the 596 /interface-state/interface list. Since the name in that 597 list MAY be mapped to ifName by an implementation, such an 598 implementation MUST restrict the allowed values for this 599 leaf so that it matches the restrictions of ifName. 601 If a NETCONF server that implements this restriction is 602 sent a value that doesn't match the restriction, it MUST 603 reply with an rpc-error with the error-tag 604 'invalid-value'."; 605 } 607 leaf description { 608 type string; 609 description 610 "A textual description of the interface. 612 This leaf MAY be mapped to ifAlias by an implementation. 614 Such an implementation MUST restrict the allowed values 615 for this leaf so that it matches the restrictions of 616 ifAlias. 618 If a NETCONF server that implements this restriction is 619 sent a value that doesn't match the restriction, it MUST 620 reply with an rpc-error with the error-tag 621 'invalid-value'. 623 Since ifAlias is defined to be stored in non-volatile 624 storage, the MIB implementation MUST map ifAlias to the 625 value of 'description' in the persistently stored 626 datastore. 628 Specifically, if the device supports ':startup', when 629 ifAlias is read the device MUST return the value of 630 'description' in the 'startup' datastore, and when it is 631 written, it MUST be written to the 'running' and 'startup' 632 datastores. Note that it is up to the implementation if 633 it modifies this single leaf in 'startup', or if it 634 performs an implicit copy-config from 'running' to 635 'startup'. 637 If the device does not support ':startup', ifAlias MUST 638 be mapped to the 'description' leaf in the 'running' 639 datastore."; 640 reference 641 "RFC 2863: The Interfaces Group MIB - ifAlias"; 642 } 644 leaf type { 645 type identityref { 646 base interface-type; 647 } 648 mandatory true; 649 description 650 "The type of the interface. 652 When an interface entry is created, a server MAY 653 initialize the type leaf with a valid value, e.g., if it 654 is possible to derive the type from the name of the 655 interface. 657 If a client tries to set the type of an interface to a 658 value that can never be used by the system, e.g., if the 659 type is not supported or if the type does not match the 660 name of the interface, the server MUST reject the request. 661 A NETCONF server MUST reply with an rpc-error with the 662 error-tag 'invalid-value' in this case."; 663 reference 664 "RFC 2863: The Interfaces Group MIB - ifType"; 665 } 667 leaf enabled { 668 type boolean; 669 default "true"; 670 description 671 "This leaf contains the configured, desired state of the 672 interface. 674 Systems that implement the IF-MIB use the value of this 675 leaf in the 'running' datastore to set 676 IF-MIB.ifAdminStatus to 'up' or 'down' after an ifEntry 677 has been initialized, as described in RFC 2863. 679 Changes in this leaf in the 'running' datastore are 680 reflected in ifAdminStatus, but if ifAdminStatus is 681 changed over SNMP, this leaf is not affected."; 682 reference 683 "RFC 2863: The Interfaces Group MIB - ifAdminStatus"; 684 } 686 leaf link-up-down-trap-enable { 687 if-feature if-mib; 688 type enumeration { 689 enum enabled { 690 value 1; 691 } 692 enum disabled { 693 value 2; 694 } 695 } 696 description 697 "Controls whether linkUp/linkDown SNMP notifications 698 should be generated for this interface. 700 If this node is not configured, the value 'enabled' is 701 operationally used by the server for interfaces which do 702 not operate on top of any other interface (i.e., there are 703 no 'lower-layer-if' entries), and 'disabled' otherwise."; 704 reference 705 "RFC 2863: The Interfaces Group MIB - 706 ifLinkUpDownTrapEnable"; 707 } 708 } 709 } 710 /* 711 * Operational state data nodes 712 */ 714 container interfaces-state { 715 config false; 716 description 717 "Data nodes for the operational state of interfaces."; 719 list interface { 720 key "name"; 722 description 723 "The list of interfaces on the device. 725 System-controlled interfaces created by the system are 726 always present in this list, whether they are configured or 727 not."; 729 leaf name { 730 type string; 731 description 732 "The name of the interface. 734 This leaf MAY be mapped to ifName by an implementation."; 735 reference 736 "RFC 2863: The Interfaces Group MIB - ifName"; 737 } 739 leaf type { 740 type identityref { 741 base interface-type; 742 } 743 mandatory true; 744 description 745 "The type of the interface."; 746 reference 747 "RFC 2863: The Interfaces Group MIB - ifType"; 748 } 750 leaf admin-status { 751 if-feature if-mib; 752 type enumeration { 753 enum up { 754 value 1; 755 description 756 "Ready to pass packets."; 757 } 758 enum down { 759 value 2; 760 description 761 "Not ready to pass packets and not in some test mode."; 762 } 763 enum testing { 764 value 3; 765 description 766 "In some test mode."; 767 } 768 } 769 mandatory true; 770 description 771 "The desired state of the interface. 773 This leaf has the same read semantics as ifAdminStatus."; 774 reference 775 "RFC 2863: The Interfaces Group MIB - ifAdminStatus"; 776 } 778 leaf oper-status { 779 type enumeration { 780 enum up { 781 value 1; 782 description 783 "Ready to pass packets."; 784 } 785 enum down { 786 value 2; 787 description 788 "The interface does not pass any packets."; 789 } 790 enum testing { 791 value 3; 792 description 793 "In some test mode. No operational packets can 794 be passed."; 795 } 796 enum unknown { 797 value 4; 798 description 799 "Status cannot be determined for some reason."; 800 } 801 enum dormant { 802 value 5; 803 description 804 "Waiting for some external event."; 805 } 806 enum not-present { 807 value 6; 808 description 809 "Some component (typically hardware) is missing."; 810 } 811 enum lower-layer-down { 812 value 7; 813 description 814 "Down due to state of lower-layer interface(s)."; 815 } 816 } 817 mandatory true; 818 description 819 "The current operational state of the interface. 821 This leaf has the same semantics as ifOperStatus."; 822 reference 823 "RFC 2863: The Interfaces Group MIB - ifOperStatus"; 824 } 826 leaf last-change { 827 type yang:date-and-time; 828 description 829 "The time the interface entered its current operational 830 state. If the current state was entered prior to the 831 last re-initialization of the local network management 832 subsystem, then this node is not present."; 833 reference 834 "RFC 2863: The Interfaces Group MIB - ifLastChange"; 835 } 837 leaf if-index { 838 if-feature if-mib; 839 type int32 { 840 range "1..2147483647"; 841 } 842 mandatory true; 843 description 844 "The ifIndex value for the ifEntry represented by this 845 interface."; 846 reference 847 "RFC 2863: The Interfaces Group MIB - ifIndex"; 848 } 850 leaf phys-address { 851 type yang:phys-address; 852 description 853 "The interface's address at its protocol sub-layer. For 854 example, for an 802.x interface, this object normally 855 contains a MAC address. The interface's media-specific 856 modules must define the bit and byte ordering and the 857 format of the value of this object. For interfaces that do 858 not have such an address (e.g., a serial line), this node 859 is not present."; 860 reference 861 "RFC 2863: The Interfaces Group MIB - ifPhysAddress"; 862 } 864 leaf-list higher-layer-if { 865 type interface-state-ref; 866 description 867 "A list of references to interfaces layered on top of this 868 interface."; 869 reference 870 "RFC 2863: The Interfaces Group MIB - ifStackTable"; 871 } 873 leaf-list lower-layer-if { 874 type interface-state-ref; 875 description 876 "A list of references to interfaces layered underneath this 877 interface."; 878 reference 879 "RFC 2863: The Interfaces Group MIB - ifStackTable"; 880 } 882 leaf speed { 883 type yang:gauge64; 884 units "bits / second"; 885 description 886 "An estimate of the interface's current bandwidth in bits 887 per second. For interfaces that do not vary in 888 bandwidth or for those where no accurate estimation can 889 be made, this node should contain the nominal bandwidth. 890 For interfaces that have no concept of bandwidth, this 891 node is not present."; 892 reference 893 "RFC 2863: The Interfaces Group MIB - 894 ifSpeed, ifHighSpeed"; 895 } 897 container statistics { 898 description 899 "A collection of interface-related statistics objects."; 901 leaf discontinuity-time { 902 type yang:date-and-time; 903 mandatory true; 904 description 905 "The time on the most recent occasion at which any one or 906 more of this interface's counters suffered a 907 discontinuity. If no such discontinuities have occurred 908 since the last re-initialization of the local management 909 subsystem, then this node contains the time the local 910 management subsystem re-initialized itself."; 911 } 913 leaf in-octets { 914 type yang:counter64; 915 description 916 "The total number of octets received on the interface, 917 including framing characters. 919 Discontinuities in the value of this counter can occur 920 at re-initialization of the management system, and at 921 other times as indicated by the value of 922 'discontinuity-time'."; 923 reference 924 "RFC 2863: The Interfaces Group MIB - ifHCInOctets"; 925 } 926 leaf in-unicast-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 not addressed to a 931 multicast or broadcast address at this sub-layer. 933 Discontinuities in the value of this counter can occur 934 at re-initialization of the management system, and at 935 other times as indicated by the value of 936 'discontinuity-time'."; 937 reference 938 "RFC 2863: The Interfaces Group MIB - ifHCInUcastPkts"; 939 } 940 leaf in-broadcast-pkts { 941 type yang:counter64; 942 description 943 "The number of packets, delivered by this sub-layer to a 944 higher (sub-)layer, which were addressed to a broadcast 945 address at this sub-layer. 947 Discontinuities in the value of this counter can occur 948 at re-initialization of the management system, and at 949 other times as indicated by the value of 950 'discontinuity-time'."; 951 reference 952 "RFC 2863: The Interfaces Group MIB - 953 ifHCInBroadcastPkts"; 954 } 955 leaf in-multicast-pkts { 956 type yang:counter64; 957 description 958 "The number of packets, delivered by this sub-layer to a 959 higher (sub-)layer, which were addressed to a multicast 960 address at this sub-layer. For a MAC layer protocol, 961 this includes both Group and Functional addresses. 963 Discontinuities in the value of this counter can occur 964 at re-initialization of the management system, and at 965 other times as indicated by the value of 966 'discontinuity-time'."; 967 reference 968 "RFC 2863: The Interfaces Group MIB - 969 ifHCInMulticastPkts"; 970 } 971 leaf in-discards { 972 type yang:counter32; 973 description 974 "The number of inbound packets which were chosen to be 975 discarded even though no errors had been detected to 976 prevent their being deliverable to a higher-layer 977 protocol. One possible reason for discarding such a 978 packet could be to free up buffer space. 980 Discontinuities in the value of this counter can occur 981 at re-initialization of the management system, and at 982 other times as indicated by the value of 983 'discontinuity-time'."; 984 reference 985 "RFC 2863: The Interfaces Group MIB - ifInDiscards"; 986 } 987 leaf in-errors { 988 type yang:counter32; 989 description 990 "For packet-oriented interfaces, the number of inbound 991 packets that contained errors preventing them from being 992 deliverable to a higher-layer protocol. For character- 993 oriented or fixed-length interfaces, the number of 994 inbound transmission units that contained errors 995 preventing them from being deliverable to a higher-layer 996 protocol. 998 Discontinuities in the value of this counter can occur 999 at re-initialization of the management system, and at 1000 other times as indicated by the value of 1001 'discontinuity-time'."; 1002 reference 1003 "RFC 2863: The Interfaces Group MIB - ifInErrors"; 1004 } 1005 leaf in-unknown-protos { 1006 type yang:counter32; 1007 description 1008 "For packet-oriented interfaces, the number of packets 1009 received via the interface which were discarded because 1010 of an unknown or unsupported protocol. For 1011 character-oriented or fixed-length interfaces that 1012 support protocol multiplexing the number of transmission 1013 units received via the interface which were discarded 1014 because of an unknown or unsupported protocol. For any 1015 interface that does not support protocol multiplexing, 1016 this counter is not present. 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 - ifInUnknownProtos"; 1024 } 1026 leaf out-octets { 1027 type yang:counter64; 1028 description 1029 "The total number of octets transmitted out of the 1030 interface, including framing characters. 1032 Discontinuities in the value of this counter can occur 1033 at re-initialization of the management system, and at 1034 other times as indicated by the value of 1035 'discontinuity-time'."; 1036 reference 1037 "RFC 2863: The Interfaces Group MIB - ifHCOutOctets"; 1038 } 1039 leaf out-unicast-pkts { 1040 type yang:counter64; 1041 description 1042 "The total number of packets that higher-level protocols 1043 requested be transmitted, and which were not addressed 1044 to a multicast or broadcast address at this sub-layer, 1045 including those that were discarded or not sent. 1047 Discontinuities in the value of this counter can occur 1048 at re-initialization of the management system, and at 1049 other times as indicated by the value of 1050 'discontinuity-time'."; 1051 reference 1052 "RFC 2863: The Interfaces Group MIB - ifHCOutUcastPkts"; 1053 } 1054 leaf out-broadcast-pkts { 1055 type yang:counter64; 1056 description 1057 "The total number of packets that higher-level protocols 1058 requested be transmitted, and which were addressed to a 1059 broadcast address at this sub-layer, including those 1060 that were discarded or not sent. 1062 Discontinuities in the value of this counter can occur 1063 at re-initialization of the management system, and at 1064 other times as indicated by the value of 1065 'discontinuity-time'."; 1066 reference 1067 "RFC 2863: The Interfaces Group MIB - 1068 ifHCOutBroadcastPkts"; 1069 } 1070 leaf out-multicast-pkts { 1071 type yang:counter64; 1072 description 1073 "The total number of packets that higher-level protocols 1074 requested be transmitted, and which were addressed to a 1075 multicast address at this sub-layer, including those 1076 that were discarded or not sent. For a MAC layer 1077 protocol, this includes both Group and Functional 1078 addresses. 1080 Discontinuities in the value of this counter can occur 1081 at re-initialization of the management system, and at 1082 other times as indicated by the value of 1083 'discontinuity-time'."; 1084 reference 1085 "RFC 2863: The Interfaces Group MIB - 1086 ifHCOutMulticastPkts"; 1087 } 1088 leaf out-discards { 1089 type yang:counter32; 1090 description 1091 "The number of outbound packets which were chosen to be 1092 discarded even though no errors had been detected to 1093 prevent their being transmitted. One possible reason 1094 for discarding such a packet could be to free up buffer 1095 space. 1097 Discontinuities in the value of this counter can occur 1098 at re-initialization of the management system, and at 1099 other times as indicated by the value of 1100 'discontinuity-time'."; 1101 reference 1102 "RFC 2863: The Interfaces Group MIB - ifOutDiscards"; 1103 } 1104 leaf out-errors { 1105 type yang:counter32; 1106 description 1107 "For packet-oriented interfaces, the number of outbound 1108 packets that could not be transmitted because of errors. 1109 For character-oriented or fixed-length interfaces, the 1110 number of outbound transmission units that could not be 1111 transmitted because of errors. 1113 Discontinuities in the value of this counter can occur 1114 at re-initialization of the management system, and at 1115 other times as indicated by the value of 1116 'discontinuity-time'."; 1117 reference 1118 "RFC 2863: The Interfaces Group MIB - ifOutErrors"; 1119 } 1120 } 1121 } 1122 } 1123 } 1125 1127 6. IANA Considerations 1129 This document registers a URI in the IETF XML registry [RFC3688]. 1130 Following the format in RFC 3688, the following registration is 1131 requested to be made. 1133 URI: urn:ietf:params:xml:ns:yang:ietf-interfaces 1135 Registrant Contact: The IESG. 1137 XML: N/A, the requested URI is an XML namespace. 1139 This document registers a YANG module in the YANG Module Names 1140 registry [RFC6020]. 1142 name: ietf-interfaces 1143 namespace: urn:ietf:params:xml:ns:yang:ietf-interfaces 1144 prefix: if 1145 reference: RFC XXXX 1147 7. Security Considerations 1149 The YANG module defined in this memo is designed to be accessed via 1150 the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the 1151 secure transport layer and the mandatory-to-implement secure 1152 transport is SSH [RFC6242]. The NETCONF access control model 1153 [RFC6536] provides the means to restrict access for particular 1154 NETCONF users to a pre-configured subset of all available NETCONF 1155 protocol operations and content. 1157 There are a number of data nodes defined in the YANG module which are 1158 writable/creatable/deletable (i.e., config true, which is the 1159 default). These data nodes may be considered sensitive or vulnerable 1160 in some network environments. Write operations (e.g., ) 1161 to these data nodes without proper protection can have a negative 1162 effect on network operations. These are the subtrees and data nodes 1163 and their sensitivity/vulnerability: 1165 /interfaces/interface: This list specifies the configured interfaces 1166 on a device. Unauthorized access to this list could cause the 1167 device to ignore packets it should receive and process. 1169 /interfaces/interface/enabled: This leaf controls if an interface is 1170 enabled or not. Unauthorized access to this leaf could cause the 1171 device to ignore packets it should receive and process. 1173 8. Acknowledgments 1175 The author wishes to thank Alexander Clemm, Per Hedeland, Ladislav 1176 Lhotka, and Juergen Schoenwaelder for their helpful comments. 1178 9. References 1180 9.1. Normative References 1182 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1183 Requirement Levels", BCP 14, RFC 2119, March 1997. 1185 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 1186 MIB", RFC 2863, June 2000. 1188 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1189 January 2004. 1191 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 1192 Network Configuration Protocol (NETCONF)", RFC 6020, 1193 October 2010. 1195 [RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991, 1196 July 2013. 1198 9.2. Informative References 1200 [I-D.ietf-netmod-iana-if-type] 1201 Bjorklund, M., "IANA Interface Type YANG Module", 1202 draft-ietf-netmod-iana-if-type-08 (work in progress), 1203 November 2013. 1205 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1206 Schoenwaelder, Ed., "Textual Conventions for SMIv2", 1207 STD 58, RFC 2579, April 1999. 1209 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 1210 Bierman, "Network Configuration Protocol (NETCONF)", 1211 RFC 6241, June 2011. 1213 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1214 Shell (SSH)", RFC 6242, June 2011. 1216 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1217 Protocol (NETCONF) Access Control Model", RFC 6536, 1218 March 2012. 1220 Appendix A. Example: Ethernet Interface Module 1222 This section gives a simple example of how an Ethernet interface 1223 module could be defined. It demonstrates how media-specific 1224 configuration parameters can be conditionally augmented to the 1225 generic interface list. It also shows how operational state 1226 parameters can be conditionally augmented to the operational 1227 interface list. The example is not intended as a complete module for 1228 ethernet configuration. 1230 module ex-ethernet { 1231 namespace "http://example.com/ethernet"; 1232 prefix "eth"; 1234 import ietf-interfaces { 1235 prefix if; 1236 } 1237 import iana-if-type { 1238 prefix ianaift; 1239 } 1241 // configuration parameters for ethernet interfaces 1242 augment "/if:interfaces/if:interface" { 1243 when "if:type = 'ianaift:ethernet'"; 1245 container ethernet { 1246 choice transmission-params { 1247 case auto { 1248 leaf auto-negotiate { 1249 type empty; 1250 } 1251 } 1252 case manual { 1253 leaf duplex { 1254 type enumeration { 1255 enum "half"; 1256 enum "full"; 1257 } 1258 } 1259 leaf speed { 1260 type enumeration { 1261 enum "10Mb"; 1262 enum "100Mb"; 1263 enum "1Gb"; 1264 enum "10Gb"; 1265 } 1266 } 1267 } 1269 } 1270 // other ethernet specific params... 1271 } 1272 } 1274 // operational state parameters for ethernet interfaces 1275 augment "/if:interfaces-state/if:interface" { 1276 when "if:type = 'ethernetCsmacd'"; 1278 container ethernet { 1279 leaf duplex { 1280 type enumeration { 1281 enum "half"; 1282 enum "full"; 1283 } 1284 } 1285 // other ethernet specific params... 1286 } 1287 } 1288 } 1290 Appendix B. Example: Ethernet Bonding Interface Module 1292 This section gives an example of how interface layering can be 1293 defined. An ethernet bonding interface is defined, which bonds 1294 several ethernet interfaces into one logical interface. 1296 module ex-ethernet-bonding { 1297 namespace "http://example.com/ethernet-bonding"; 1298 prefix "bond"; 1300 import ietf-interfaces { 1301 prefix if; 1302 } 1303 import iana-if-type { 1304 prefix ianaift; 1305 } 1307 augment "/if:interfaces/if:interface" { 1308 when "if:type = 'ianaift:ieee8023adLag'"; 1310 leaf-list slave-if { 1311 type if:interface-ref; 1312 must "/if:interfaces/if:interface[if:name = current()]" 1313 + "/if:type = 'ianaift:ethernetCsmacd'" { 1314 description 1315 "The type of a slave interface must be ethernet."; 1316 } 1317 } 1318 leaf bonding-mode { 1319 type enumeration { 1320 enum round-robin; 1321 enum active-backup; 1322 enum broadcast; 1323 } 1324 } 1325 // other bonding config params, failover times etc. 1326 } 1327 } 1329 Appendix C. Example: VLAN Interface Module 1331 This section gives an example of how a vlan interface module can be 1332 defined. 1334 module ex-vlan { 1335 namespace "http://example.com/vlan"; 1336 prefix "vlan"; 1338 import ietf-interfaces { 1339 prefix if; 1340 } 1341 import iana-if-type { 1342 prefix ianaift; 1343 } 1344 import ex-ethernet { 1345 prefix eth; 1346 } 1348 augment "/if:interfaces/if:interface" { 1349 when "if:type = 'ianaift:ethernetCsmacd' or 1350 if:type = 'ianaift:ieee8023adLag'"; 1351 leaf vlan-tagging { 1352 type boolean; 1353 default false; 1354 } 1355 } 1357 augment "/if:interfaces/if:interface" { 1358 when "if:type = 'ianaift:l2vlan'"; 1360 leaf base-interface { 1361 type if:interface-ref; 1362 must "/if:interfaces/if:interface[if:name = current()]" 1363 + "/vlan:vlan-tagging = 'true'" { 1364 description 1365 "The base interface must have vlan tagging enabled."; 1366 } 1367 } 1368 leaf vlan-id { 1369 type uint16 { 1370 range "1..4094"; 1371 } 1372 must "../base-interface" { 1373 description 1374 "If a vlan-id is defined, a base-interface must 1375 be specified."; 1376 } 1377 } 1378 } 1379 } 1381 Appendix D. Example: NETCONF reply 1383 This section gives an example of a reply to the NETCONF request 1384 for a device that implements the example data models above. 1386 1389 1391 1396 1397 eth0 1398 ianaift:ethernetCsmacd 1399 false 1400 1402 1403 eth1 1404 ianaift:ethernetCsmacd 1405 true 1406 true 1407 1409 1410 eth1.10 1411 ianaift:l2vlan 1412 true 1413 eth1 1414 10 1415 1417 1418 lo1 1419 ianaift:softwareLoopback 1420 true 1421 1423 1425 1429 1430 eth0 1431 ianaift:ethernetCsmacd 1432 down 1433 down 1434 2 1435 00:01:02:03:04:05 1436 1437 1438 2013-04-01T03:00:00+00:00 1439 1440 1441 1442 1444 1445 eth1 1446 ianaift:ethernetCsmacd 1447 up 1448 up 1449 7 1450 00:01:02:03:04:06 1451 eth1.10 1452 1453 1454 2013-04-01T03:00:00+00:00 1455 1456 1457 1458 1460 1461 eth1.10 1462 ianaift:l2vlan 1463 up 1464 up 1465 9 1466 eth1 1467 1468 1469 2013-04-01T03:00:00+00:00 1470 1471 1472 1473 1475 1476 1477 eth2 1478 ianaift:ethernetCsmacd 1479 down 1480 down 1481 8 1482 00:01:02:03:04:07 1483 1484 1485 2013-04-01T03:00:00+00:00 1486 1487 1488 1489 1491 1492 lo1 1493 ianaift:softwareLoopback 1494 up 1495 up 1496 1 1497 1498 1499 2013-04-01T03:00:00+00:00 1500 1501 1502 1503 1505 1506 1507 1509 Appendix E. Examples: Interface Naming Schemes 1511 This section gives examples of some implementation strategies. 1513 The examples make use of the example data model "ex-vlan" (see 1514 Appendix C) to show how user-controlled interfaces can be configured. 1516 E.1. Router with Restricted Interface Names 1518 In this example, a router has support for 4 line cards, each with 8 1519 ports. The slots for the cards are physically numbered from 0 to 3, 1520 and the ports on each card from 0 to 7. Each card has fast- or 1521 gigabit-ethernet ports. 1523 The device-specific names for these physical interfaces are 1524 "fastethernet-N/M" or "gigabitethernet-N/M". 1526 The name of a vlan interface is restricted to the form 1527 ".". 1529 It is assumed that the operator is aware of this naming scheme. The 1530 implementation auto-initializes the value for "type" based on the 1531 interface name. 1533 The NETCONF server does not advertise the 'arbitrary-names' feature 1534 in the message. 1536 An operator can configure a physical interface by sending an 1537 containing: 1539 1540 fastethernet-1/0 1541 1543 When the server processes this request, it will set the leaf "type" 1544 to "ianaift:ethernetCsmacd". Thus, if the client performs a 1545 right after the above, it will get: 1547 1548 fastethernet-1/0 1549 ianaift:ethernetCsmacd 1550 1552 The client can configure a vlan interface by sending an 1553 containing: 1555 1556 fastethernet-1/0.10005 1557 ianaift:l2vlan 1558 fastethernet-1/0 1559 5 1560 1562 If the client tries to change the type of the physical interface with 1563 an containing: 1565 1566 fastethernet-1/0 1567 ianaift:tunnel 1568 1570 then the server will reply with an "invalid-value" error, since the 1571 new type does not match the name. 1573 E.2. Router with Arbitrary Interface Names 1575 In this example, a router has support for 4 line cards, each with 8 1576 ports. The slots for the cards are physically numbered from 0 to 3, 1577 and the ports on each card from 0 to 7. Each card has fast- or 1578 gigabit-ethernet ports. 1580 The device-specific names for these physical interfaces are 1581 "fastethernet-N/M" or "gigabitethernet-N/M". 1583 The implementation does not restrict the user-controlled interface 1584 names. This allows to more easily apply the interface configuration 1585 to a different interface. However, the additional level of 1586 indirection also makes it a bit more complex to map interface names 1587 found in other protocols to configuration entries. 1589 The NETCONF server advertises the 'arbitrary-names' feature in the 1590 message. 1592 Physical interfaces are configured as in Appendix E.1. 1594 An operator can configure a VLAN interface by sending an 1595 containing: 1597 1598 acme-interface 1599 ianaift:l2vlan 1600 fastethernet-1/0 1601 5 1602 1604 If necessary, the operator can move the configuration named 1605 "acme-interface" over to a different physical interface with an 1606 containing: 1608 1609 acme-interface 1610 fastethernet-1/1 1611 1613 E.3. Ethernet Switch with Restricted Interface Names 1615 In this example, an ethernet switch has a number of ports, each port 1616 identified by a simple port number. 1618 The device-specific names for the physical interfaces are numbers 1619 that match the physical port number. 1621 An operator can configure a physical interface by sending an 1622 containing: 1624 1625 6 1626 1628 When the server processes this request, it will set the leaf "type" 1629 to "ianaift:ethernetCsmacd". Thus, if the client performs a 1630 right after the above, it will get: 1632 1633 6 1634 ianaift:ethernetCsmacd 1635 1637 E.4. Generic Host with Restricted Interface Names 1639 In this example, a generic host has interfaces named by the kernel. 1640 The system identifies the physical interface by the name assigned by 1641 the operating system to the interface. 1643 The name of a vlan interface is restricted to the form 1644 ":". 1646 The NETCONF server does not advertise the 'arbitrary-names' feature 1647 in the message. 1649 An operator can configure an interface by sending an 1650 containing: 1652 1653 eth8 1654 1656 When the server processes this request, it will set the leaf "type" 1657 to "ianaift:ethernetCsmacd". Thus, if the client performs a 1658 right after the above, it will get: 1660 1661 eth8 1662 ianaift:ethernetCsmacd 1663 1665 The client can configure a vlan interface by sending an 1666 containing: 1668 1669 eth8:5 1670 ianaift:l2vlan 1671 eth8 1672 5 1673 1675 E.5. Generic Host with Arbitrary Interface Names 1677 In this example, a generic host has interfaces named by the kernel. 1678 The system identifies the physical interface by the name assigned by 1679 the operating system to the interface. 1681 The implementation does not restrict the user-controlled interface 1682 names. This allows to more easily apply the interface configuration 1683 to a different interface. However, the additional level of 1684 indirection also makes it a bit more complex to map interface names 1685 found in other protocols to configuration entries. 1687 The NETCONF server advertises the 'arbitrary-names' feature in the 1688 message. 1690 Physical interfaces are configured as in Appendix E.4. 1692 An operator can configure a VLAN interface by sending an 1693 containing: 1695 1696 acme-interface 1697 ianaift:l2vlan 1698 eth8 1699 5 1701 1703 If necessary, the operator can move the configuration named 1704 "acme-interface" over to a different physical interface with an 1705 containing: 1707 1708 acme-interface 1709 eth3 1710 1712 Appendix F. ChangeLog 1714 RFC Editor: remove this section upon publication as an RFC. 1716 F.1. Version -13 1718 o Made the interface type an identity, instead of an enumseration. 1720 F.2. Version -11 1722 o Separated the operational state from the configuration. 1724 o Removed 'location', and instead use the name to identify physical 1725 interfaces. 1727 o Added the feature 'pre-provisioning'. 1729 o Made 'oper-status' and 'if-index' mandatory in the data model. 1731 o Added 'admin-status'. 1733 o Clarified why description can be mapped to ifAlias. 1735 o Clarified that 64-bit counters only are used, where there exist 1736 64-bit and 32-bit counters in IF-MIB. 1738 o Updated Security Considerations section with a reference to NACM. 1740 F.3. Version -08 1742 o Removed the mtu leaf. 1744 o Added examples of different interface naming schemes. 1746 F.4. Version -07 1748 o Made leaf speed config false. 1750 F.5. Version -06 1752 o Added oper-status leaf. 1754 o Added leaf-lists higher-layer-if and lower-layer-if, that show the 1755 interface layering. 1757 o Added container statistics with counters. 1759 F.6. Version -05 1761 o Added an Informative References section. 1763 o Updated the Security Considerations section. 1765 o Clarified the behavior of an NETCONF server when invalid values 1766 are received. 1768 F.7. Version -04 1770 o Clarified why ifPromiscuousMode is not part of this data model. 1772 o Added a table that shows the mapping between this YANG data model 1773 and IF-MIB. 1775 F.8. Version -03 1777 o Added the section Relationship to the IF-MIB. 1779 o Changed if-index to be a leaf instead of leaf-list. 1781 o Explained the notation used in the data model tree picture. 1783 F.9. Version -02 1785 o Editorial fixes 1787 F.10. Version -01 1789 o Changed leaf "if-admin-status" to leaf "enabled". 1791 o Added Security Considerations 1793 Author's Address 1795 Martin Bjorklund 1796 Tail-f Systems 1798 Email: mbj@tail-f.com