idnits 2.17.1 draft-ietf-netmod-interfaces-cfg-11.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 215 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 (May 15, 2013) is 3993 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-06 == Outdated reference: A later version (-03) exists of draft-ietf-netmod-rfc6021-bis-02 -- Obsolete informational reference (is this intentional?): RFC 6536 (Obsoleted by RFC 8341) Summary: 0 errors (**), 0 flaws (~~), 5 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 May 15, 2013 5 Expires: November 16, 2013 7 A YANG Data Model for Interface Management 8 draft-ietf-netmod-interfaces-cfg-11 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 November 16, 2013. 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 . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 3. Interfaces Data Model . . . . . . . . . . . . . . . . . . . . 6 57 3.1. The interface Lists . . . . . . . . . . . . . . . . . . . 6 58 3.2. Interface References . . . . . . . . . . . . . . . . . . . 7 59 3.3. Interface Layering . . . . . . . . . . . . . . . . . . . . 7 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 defined in [RFC6241] and are not redefined 112 here: 114 o client 116 o configuration data 118 o server 120 o state data 122 The following terms are defined in [RFC6020] and are not redefined 123 here: 125 o augment 127 o data model 129 o data node 131 1.2. Tree Diagrams 133 A simplified graphical representation of the data model is used in 134 this document. The meaning of the symbols in these diagrams is as 135 follows: 137 o Brackets "[" and "]" enclose list keys. 139 o Abbreviations before data node names: "rw" means configuration 140 (read-write) and "ro" state data (read-only). 142 o Symbols after data node names: "?" means an optional node and "*" 143 denotes a "list" and "leaf-list". 145 o Parentheses enclose choice and case nodes, and case nodes are also 146 marked with a colon (":"). 148 o Ellipsis ("...") stands for contents of subtrees that are not 149 shown. 151 2. Objectives 153 This section describes some of the design objectives for the model 154 presented in Section 5. 156 o It is recognized that existing implementations will have to map 157 the interface data model defined in this memo to their proprietary 158 native data model. The data model should be simple to facilitate 159 such mappings. 161 o The data model should be suitable for new implementations to use 162 as-is, without requiring a mapping to a different native model. 164 o References to interfaces should be as simple as possible, 165 preferably by using a single leafref. 167 o The mapping to ifIndex [RFC2863] used by SNMP to identify 168 interfaces must be clear. 170 o The model must support interface layering, both simple layering 171 where one interface is layered on top of exactly one other 172 interface, and more complex scenarios where one interface results 173 from the aggregation of N other interfaces, or when N interfaces 174 are multiplexed over one other interface. 176 o The data model should support the pre-provisioning of interface 177 configuration, i.e., it should be possible to configure an 178 interface whose physical interface hardware is not present on the 179 device. It is recommended that devices that support dynamic 180 addition and removal of physical interfaces also support pre- 181 provisioning. 183 o The data model should support both physical interfaces as well as 184 logical interfaces. 186 o The data model should include read-only counters in order to 187 gather statistics for octets, packets and errors, sent and 188 received. 190 3. Interfaces Data Model 192 This document defines the YANG module "ietf-interfaces", which has 193 the following structure: 195 +--rw interfaces 196 | +--rw interface* [name] 197 | +--rw name string 198 | +--rw description? string 199 | +--rw type ianaift:iana-if-type 200 | +--rw enabled? boolean 201 | +--rw link-up-down-trap-enable? enumeration 202 +--ro interfaces-state 203 +--ro interface* [name] 204 +--ro name string 205 +--ro type ianaift:iana-if-type 206 +--ro admin-status enumeration 207 +--ro oper-status enumeration 208 +--ro last-change? yang:date-and-time 209 +--ro if-index int32 210 +--ro phys-address? yang:phys-address 211 +--ro higher-layer-if* interface-state-ref 212 +--ro lower-layer-if* interface-state-ref 213 +--ro speed? yang:gauge64 214 +--ro statistics 215 +--ro discontinuity-time yang:date-and-time 216 +--ro in-octets? yang:counter64 217 +--ro in-unicast-pkts? yang:counter64 218 +--ro in-broadcast-pkts? yang:counter64 219 +--ro in-multicast-pkts? yang:counter64 220 +--ro in-discards? yang:counter32 221 +--ro in-errors? yang:counter32 222 +--ro in-unknown-protos? yang:counter32 223 +--ro out-octets? yang:counter64 224 +--ro out-unicast-pkts? yang:counter64 225 +--ro out-broadcast-pkts? yang:counter64 226 +--ro out-multicast-pkts? yang:counter64 227 +--ro out-discards? yang:counter32 228 +--ro out-errors? yang:counter32 230 3.1. The interface Lists 232 The data model for interfaces presented in this document uses a flat 233 list of interfaces. Each interface in the list is identified by its 234 name. Furthermore, each interface has a mandatory "type" leaf. 236 There is one list of configured interfaces ("/interfaces/interface"), 237 and a separate list for the operational state of all interfaces 238 ("/interfaces-state/interface"). 240 It is expected that interface type specific data models augment the 241 interface lists, and use the "type" leaf to make the augmentation 242 conditional. 244 As an example of such an interface type specific augmentation, 245 consider this YANG snippet. For a more complete example, see 246 Appendix A. 248 import interfaces { 249 prefix "if"; 250 } 252 augment "/if:interfaces/if:interface" { 253 when "if:type = 'ethernetCsmacd'"; 255 container ethernet { 256 leaf duplex { 257 ... 258 } 259 } 260 } 262 For physical interfaces, the "name" is the device-specific name of 263 the interface. It is used to identify the physical hardware 264 interface. The 'config false' list "/interfaces-state/interface" 265 contains all currently existing interfaces on the device. 267 If the device supports arbitrarily named logical interfaces, the 268 NETCONF server advertises the feature "arbitrary-names". If the 269 device does not advertise this feature, the names of logical 270 interfaces MUST match the device's naming scheme. How a client can 271 learn the naming scheme of such devices is outside the scope of this 272 document. 274 3.2. Interface References 276 An interface is identified by its name, which is unique within the 277 server. This property is captured in the "interface-ref" and 278 "interface-state-ref" typedefs, which other YANG modules SHOULD use 279 when they need to reference a configured interface or operationally 280 used interface, respectively. 282 3.3. Interface Layering 284 There is no generic mechanism for how an interface is configured to 285 be layered on top of some other interface. It is expected that 286 interface type specific models define their own data nodes for 287 interface layering, by using "interface-ref" types to reference lower 288 layers. 290 Below is an example of a model with such nodes. For a more complete 291 example, see Appendix B. 293 import interfaces { 294 prefix "if"; 295 } 297 augment "/if:interfaces/if:interface" { 298 when "if:type = 'ieee8023adLag'"; 300 leaf-list slave-if { 301 type if:interface-ref; 302 must "/if:interfaces/if:interface[if:name = current()]" 303 + "/if:type = 'ethernetCsmacd'" { 304 description 305 "The type of a slave interface must be ethernet"; 306 } 307 } 308 // other bonding config params, failover times etc. 309 } 311 Two state data leaf-lists, "higher-layer-if" and "lower-layer-if", 312 represent a read-only view of the interface layering hierarchy. 314 4. Relationship to the IF-MIB 316 If the device implements IF-MIB [RFC2863], each entry in the 317 "/interfaces-state/interface" list is typically mapped to one 318 ifEntry. The "if-index" leaf MUST contain the value of the 319 corresponding ifEntry's ifIndex. 321 In most cases, the "name" of an "interface" entry is mapped to 322 ifName. ifName is defined as an DisplayString [RFC2579] which uses a 323 7-bit ASCII character set. An implementation MUST restrict the 324 allowed values for "name" to match the restrictions of ifName. 326 The IF-MIB allows two different ifEntries to have the same ifName. 327 Devices that support this feature, and also support the data model 328 defined in this document, cannot have a 1-1 mapping between the 329 "name" leaf and ifName. 331 The configured "description" of an "interface" has traditionally been 332 mapped to ifAlias in some implementations. This document allows this 333 mapping, but implementers should be aware of the differences in the 334 value space and persistence for these objects. See the YANG module 335 definition of the leaf "description" in Section 5 for details. 337 The IF-MIB also defines the writable object ifPromiscuousMode. Since 338 this object typically is not a configuration object, it is not mapped 339 to the "ietf-interfaces" module. 341 There are a number of counters in the IF-MIB that exist in two 342 versions; one with 32 bits and one with 64 bits. The YANG module 343 contains the 64 bits counters only. Note that NETCONF and SNMP may 344 differ in the time granularity in which they provide access to the 345 counters. For example, it is common that SNMP implementations cache 346 counter values for some time. 348 The following table lists the YANG data nodes with corresponding 349 objects in the IF-MIB. 351 +----------------------------------+------------------------+ 352 | YANG data node | IF-MIB object | 353 +----------------------------------+------------------------+ 354 | interface | ifEntry | 355 | name | ifName | 356 | description | ifAlias | 357 | type | ifType | 358 | enabled / admin-status | ifAdminStatus | 359 | oper-status | ifOperStatus | 360 | last-change | ifLastChange | 361 | if-index | ifIndex | 362 | link-up-down-trap-enable | ifLinkUpDownTrapEnable | 363 | phys-address | ifPhysAddress | 364 | higher-layer-if / lower-layer-if | ifStackTable | 365 | speed | ifSpeed | 366 | in-octets | ifHCInOctets | 367 | in-unicast-pkts | ifHCInUcastPkts | 368 | in-broadcast-pkts | ifHCInBroadcastPkts | 369 | in-multicast-pkts | ifHCInMulticastPkts | 370 | in-discards | ifInDiscards | 371 | in-errors | ifInErrors | 372 | in-unknown-protos | ifInUnknownProtos | 373 | out-octets | ifHCOutOctets | 374 | out-unicast-pkts | ifHCOutUcastPkts | 375 | out-broadcast-pkts | ifHCOutBroadcastPkts | 376 | out-multicast-pkts | ifHCOutMulticastPkts | 377 | out-discards | ifOutDiscards | 378 | out-errors | ifOutErrors | 379 +----------------------------------+------------------------+ 381 YANG data nodes and related IF-MIB objects 383 5. Interfaces YANG Module 385 This YANG module imports typedefs from [I-D.ietf-netmod-rfc6021-bis] 386 and [I-D.ietf-netmod-iana-if-type]. 388 RFC Ed.: update the date below with the date of RFC publication and 389 remove this note. 391 file "ietf-interfaces@2013-05-15.yang" 393 module ietf-interfaces { 395 namespace "urn:ietf:params:xml:ns:yang:ietf-interfaces"; 396 prefix if; 398 import ietf-yang-types { 399 prefix yang; 400 } 401 import iana-if-type { 402 prefix ianaift; 403 } 405 organization 406 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 408 contact 409 "WG Web: 410 WG List: 412 WG Chair: David Kessens 413 415 WG Chair: Juergen Schoenwaelder 416 418 Editor: Martin Bjorklund 419 "; 421 description 422 "This module contains a collection of YANG definitions for 423 managing network interfaces. 425 Copyright (c) 2013 IETF Trust and the persons identified as 426 authors of the code. All rights reserved. 428 Redistribution and use in source and binary forms, with or 429 without modification, is permitted pursuant to, and subject 430 to the license terms contained in, the Simplified BSD License 431 set forth in Section 4.c of the IETF Trust's Legal Provisions 432 Relating to IETF Documents 433 (http://trustee.ietf.org/license-info). 435 This version of this YANG module is part of RFC XXXX; see 436 the RFC itself for full legal notices."; 438 // RFC Ed.: replace XXXX with actual RFC number and remove this 439 // note. 441 // RFC Ed.: update the date below with the date of RFC publication 442 // and remove this note. 443 revision 2013-05-15 { 444 description 445 "Initial revision."; 446 reference 447 "RFC XXXX: A YANG Data Model for Interface Management"; 448 } 450 /* Typedefs */ 452 typedef interface-ref { 453 type leafref { 454 path "/if:interfaces/if:interface/if:name"; 455 } 456 description 457 "This type is used by data models that need to reference 458 configured interfaces."; 459 } 461 typedef interface-state-ref { 462 type leafref { 463 path "/if:interfaces-state/if:interface/if:name"; 464 } 465 description 466 "This type is used by data models that need to reference 467 the operationally present interfaces."; 468 } 470 /* Features */ 472 feature arbitrary-names { 473 description 474 "This feature indicates that the device allows logical 475 interfaces to be named arbitrarily."; 476 } 478 feature pre-provisioning { 479 description 480 "This feature indicates that the device supports 481 pre-provisioning of interface configuration, i.e., it is 482 possible to configure an interface whose physical interface 483 hardware is not present on the device."; 484 } 486 feature if-mib { 487 description 488 "This feature indicates that the device implements IF-MIB."; 489 reference 490 "RFC 2863: The Interfaces Group MIB"; 491 } 493 /* Data nodes */ 495 container interfaces { 496 description 497 "Interface configuration parameters."; 499 list interface { 500 key "name"; 502 description 503 "The list of configured interfaces on the device. 505 The operational state of an interface is available in the 506 /interfaces-state/interface list. If the configuration of a 507 physical interface cannot be used by the system (e.g., the 508 physical interface present is not matching the interface 509 type), then the configuration is not applied to the physical 510 interface shown in the /interfaces-state/interface list. If 511 the the configuration of a logical interface cannot be used 512 by the system, the configured interface is not instantiated 513 in the /interfaces-state/interface list."; 515 leaf name { 516 type string; 517 description 518 "The name of the interface. 520 A device MAY restrict the allowed values for this leaf, 521 possibly depending on the type of the interface. 523 For physical interfaces, this leaf is the device-specific 524 name of the interface. The 'config false' list 525 /interfaces-state/interface contains the currently 526 existing interfaces on the device. 528 If a client tries to create configuration for a physical 529 interface that is not present, the server MAY reject the 530 request, if the implementation does not support 531 pre-provisioning of interfaces, or if the name refers to 532 an interface that can never exist in the system. 533 A NETCONF server MUST reply with an rpc-error with the 534 error-tag 'invalid-value' in this case. 536 If the device supports pre-provisioning of interface 537 configuration, the feature 'pre-provisioning' is 538 advertised. 540 If the device allows arbitrarily named logical interfaces, 541 the feature 'arbitrary-names' is advertised. 543 When a configured logical interface is created by the 544 system, it is instantiated in the 545 /interface-state/interface list. Since the name in that 546 list MAY be mapped to ifName by an implementation, such an 547 implementation MUST restrict the allowed values for this 548 leaf so that it matches the restrictions of ifName. 550 If a NETCONF server that implements this restriction is 551 sent a value that doesn't match the restriction, it MUST 552 reply with an rpc-error with the error-tag 553 'invalid-value'."; 554 } 556 leaf description { 557 type string; 558 description 559 "A textual description of the interface. 561 This leaf MAY be mapped to ifAlias by an implementation. 562 Such an implementation MUST restrict the allowed values 563 for this leaf so that it matches the restrictions of 564 ifAlias. 566 If a NETCONF server that implements this restriction is 567 sent a value that doesn't match the restriction, it MUST 568 reply with an rpc-error with the error-tag 569 'invalid-value'. 571 Since ifAlias is defined to be stored in non-volatile 572 storage, the SNMP implementation MUST map ifAlias to the 573 value of 'description' in the persistently stored 574 datastore. 576 Specifically, if the device supports ':startup', when 577 ifAlias is read the device MUST return the value of 578 'description' in the 'startup' datastore, and when it is 579 written, it MUST be written to the 'running' and 'startup' 580 datastores. Note that it is up to the implementation if 581 it modifies this single leaf in 'startup', or if it 582 performs an implicit copy-config from 'running' to 583 'startup'. 585 If the device does not support ':startup', ifAlias MUST 586 be mapped to the 'description' leaf in the 'running' 587 datastore."; 588 reference 589 "RFC 2863: The Interfaces Group MIB - ifAlias"; 590 } 592 leaf type { 593 type ianaift:iana-if-type; 594 mandatory true; 595 description 596 "The type of the interface. 598 When an interface entry is created, a server MAY 599 initialize the type leaf with a valid value, e.g., if it 600 is possible to derive the type from the name of the 601 interface. 603 If a client tries to set the type of an interface to a 604 value that can never be used by the system, e.g., if the 605 type is not supported or if the type does not match the 606 name of the interface, the server MUST reject the request. 607 A NETCONF server MUST reply with an rpc-error with the 608 error-tag 'invalid-value' in this case."; 609 reference 610 "RFC 2863: The Interfaces Group MIB - ifType"; 611 } 613 leaf enabled { 614 type boolean; 615 default "true"; 616 description 617 "This leaf contains the configured, desired state of the 618 interface. 620 Systems that implement the IF-MIB use the value of this 621 leaf in the 'running' datastore to set 622 IF-MIB.ifAdminStatus to 'up' or 'down' after an ifEntry 623 has been initialized, as described in RFC 2863. 625 Changes in this leaf in the 'running' datastore are 626 reflected in ifAdminStatus, but if ifAdminStatus is 627 changed over SNMP, this leaf is not affected."; 628 reference 629 "RFC 2863: The Interfaces Group MIB - ifAdminStatus"; 630 } 632 leaf link-up-down-trap-enable { 633 if-feature if-mib; 634 type enumeration { 635 enum enabled { 636 value 1; 637 } 638 enum disabled { 639 value 2; 640 } 641 } 642 description 643 "Controls whether linkUp/linkDown SNMP notifications 644 should be generated for this interface. 646 If this node is not configured, the value 'enabled' is 647 operationally used by the server for interfaces which do 648 not operate on top of any other interface (i.e., there are 649 no 'lower-layer-if' entries), and 'disabled' otherwise."; 650 reference 651 "RFC 2863: The Interfaces Group MIB - 652 ifLinkUpDownTrapEnable"; 653 } 654 } 655 } 657 container interfaces-state { 658 config false; 659 description 660 "Data nodes for the operational state of interfaces."; 662 list interface { 663 key "name"; 665 description 666 "The list of interfaces on the device. 668 Physical interfaces detected by the system are always 669 present in this list, if they are configured or not."; 671 leaf name { 672 type string; 673 description 674 "The name of the interface. 676 This leaf MAY be mapped to ifName by an implementation. 677 Such an implementation MUST restrict the values 678 for this leaf so that it matches the restrictions of 679 ifName."; 680 reference 681 "RFC 2863: The Interfaces Group MIB - ifName"; 682 } 684 leaf type { 685 type ianaift:iana-if-type; 686 mandatory true; 687 description 688 "The type of the interface."; 689 reference 690 "RFC 2863: The Interfaces Group MIB - ifType"; 691 } 693 leaf admin-status { 694 if-feature if-mib; 695 type enumeration { 696 enum up { 697 value 1; 698 description 699 "Ready to pass packets."; 700 } 701 enum down { 702 value 2; 703 description 704 "Not ready to pass packets and not in some test mode."; 705 } 706 enum testing { 707 value 3; 708 description 709 "In some test mode."; 710 } 711 } 712 mandatory true; 713 description 714 "The desired state of the interface. 716 This leaf has the same semantics as ifAdminStatus."; 717 reference 718 "RFC 2863: The Interfaces Group MIB - ifAdminStatus"; 719 } 720 leaf oper-status { 721 type enumeration { 722 enum up { 723 value 1; 724 description 725 "Ready to pass packets."; 726 } 727 enum down { 728 value 2; 729 description 730 "The interface does not pass any packets."; 731 } 732 enum testing { 733 value 3; 734 description 735 "In some test mode. No operational packets can 736 be passed."; 737 } 738 enum unknown { 739 value 4; 740 description 741 "Status cannot be determined for some reason."; 742 } 743 enum dormant { 744 value 5; 745 description 746 "Waiting for some external event."; 747 } 748 enum not-present { 749 value 6; 750 description 751 "Some component (typically hardware) is missing."; 752 } 753 enum lower-layer-down { 754 value 7; 755 description 756 "Down due to state of lower-layer interface(s)."; 757 } 758 } 759 mandatory true; 760 description 761 "The current operational state of the interface. 763 This leaf has the same semantics as ifOperStatus."; 764 reference 765 "RFC 2863: The Interfaces Group MIB - ifOperStatus"; 766 } 767 leaf last-change { 768 type yang:date-and-time; 769 description 770 "The time the interface entered its current operational 771 state. If the current state was entered prior to the 772 last re-initialization of the local network management 773 subsystem, then this node is not present."; 774 reference 775 "RFC 2863: The Interfaces Group MIB - ifLastChange"; 776 } 778 leaf if-index { 779 if-feature if-mib; 780 type int32 { 781 range "1..2147483647"; 782 } 783 mandatory true; 784 description 785 "The ifIndex value for the ifEntry represented by this 786 interface."; 787 reference 788 "RFC 2863: The Interfaces Group MIB - ifIndex"; 789 } 791 leaf phys-address { 792 type yang:phys-address; 793 description 794 "The interface's address at its protocol sub-layer. For 795 example, for an 802.x interface, this object normally 796 contains a MAC address. The interface's media-specific 797 modules must define the bit and byte ordering and the 798 format of the value of this object. For interfaces that do 799 not have such an address (e.g., a serial line), this node 800 is not present."; 801 reference 802 "RFC 2863: The Interfaces Group MIB - ifPhysAddress"; 803 } 805 leaf-list higher-layer-if { 806 type interface-state-ref; 807 description 808 "A list of references to interfaces layered on top of this 809 interface."; 810 reference 811 "RFC 2863: The Interfaces Group MIB - ifStackTable"; 812 } 814 leaf-list lower-layer-if { 815 type interface-state-ref; 816 description 817 "A list of references to interfaces layered underneath this 818 interface."; 819 reference 820 "RFC 2863: The Interfaces Group MIB - ifStackTable"; 821 } 823 leaf speed { 824 type yang:gauge64; 825 units "bits / second"; 826 description 827 "An estimate of the interface's current bandwidth in bits 828 per second. For interfaces that do not vary in 829 bandwidth or for those where no accurate estimation can 830 be made, this node should contain the nominal bandwidth. 831 For interfaces that have no concept of bandwidth, this 832 node is not present."; 833 reference 834 "RFC 2863: The Interfaces Group MIB - 835 ifSpeed, ifHighSpeed"; 836 } 838 container statistics { 839 description 840 "A collection of interface-related statistics objects."; 842 leaf discontinuity-time { 843 type yang:date-and-time; 844 mandatory true; 845 description 846 "The time on the most recent occasion at which any one or 847 more of this interface's counters suffered a 848 discontinuity. If no such discontinuities have occurred 849 since the last re-initialization of the local management 850 subsystem, then this node contains the time the local 851 management subsystem re-initialized itself."; 852 } 854 leaf in-octets { 855 type yang:counter64; 856 description 857 "The total number of octets received on the interface, 858 including framing characters. 860 Discontinuities in the value of this counter can occur 861 at re-initialization of the management system, and at 862 other times as indicated by the value of 863 'discontinuity-time'."; 864 reference 865 "RFC 2863: The Interfaces Group MIB - ifHCInOctets"; 866 } 867 leaf in-unicast-pkts { 868 type yang:counter64; 869 description 870 "The number of packets, delivered by this sub-layer to a 871 higher (sub-)layer, which were not addressed to a 872 multicast or broadcast address at this sub-layer. 874 Discontinuities in the value of this counter can occur 875 at re-initialization of the management system, and at 876 other times as indicated by the value of 877 'discontinuity-time'."; 878 reference 879 "RFC 2863: The Interfaces Group MIB - ifHCInUcastPkts"; 880 } 881 leaf in-broadcast-pkts { 882 type yang:counter64; 883 description 884 "The number of packets, delivered by this sub-layer to a 885 higher (sub-)layer, which were addressed to a broadcast 886 address at this sub-layer. 888 Discontinuities in the value of this counter can occur 889 at re-initialization of the management system, and at 890 other times as indicated by the value of 891 'discontinuity-time'."; 892 reference 893 "RFC 2863: The Interfaces Group MIB - 894 ifHCInBroadcastPkts"; 895 } 896 leaf in-multicast-pkts { 897 type yang:counter64; 898 description 899 "The number of packets, delivered by this sub-layer to a 900 higher (sub-)layer, which were addressed to a multicast 901 address at this sub-layer. For a MAC layer protocol, 902 this includes both Group and Functional addresses. 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 - 910 ifHCInMulticastPkts"; 912 } 913 leaf in-discards { 914 type yang:counter32; 915 description 916 "The number of inbound packets which were chosen to be 917 discarded even though no errors had been detected to 918 prevent their being deliverable to a higher-layer 919 protocol. One possible reason for discarding such a 920 packet could be to free up buffer space. 922 Discontinuities in the value of this counter can occur 923 at re-initialization of the management system, and at 924 other times as indicated by the value of 925 'discontinuity-time'."; 926 reference 927 "RFC 2863: The Interfaces Group MIB - ifInDiscards"; 928 } 929 leaf in-errors { 930 type yang:counter32; 931 description 932 "For packet-oriented interfaces, the number of inbound 933 packets that contained errors preventing them from being 934 deliverable to a higher-layer protocol. For character- 935 oriented or fixed-length interfaces, the number of 936 inbound transmission units that contained errors 937 preventing them from being deliverable to a higher-layer 938 protocol. 940 Discontinuities in the value of this counter can occur 941 at re-initialization of the management system, and at 942 other times as indicated by the value of 943 'discontinuity-time'."; 944 reference 945 "RFC 2863: The Interfaces Group MIB - ifInErrors"; 946 } 947 leaf in-unknown-protos { 948 type yang:counter32; 949 description 950 "For packet-oriented interfaces, the number of packets 951 received via the interface which were discarded because 952 of an unknown or unsupported protocol. For 953 character-oriented or fixed-length interfaces that 954 support protocol multiplexing the number of transmission 955 units received via the interface which were discarded 956 because of an unknown or unsupported protocol. For any 957 interface that does not support protocol multiplexing, 958 this counter is not present. 960 Discontinuities in the value of this counter can occur 961 at re-initialization of the management system, and at 962 other times as indicated by the value of 963 'discontinuity-time'."; 964 reference 965 "RFC 2863: The Interfaces Group MIB - ifInUnknownProtos"; 966 } 968 leaf out-octets { 969 type yang:counter64; 970 description 971 "The total number of octets transmitted out of the 972 interface, including framing characters. 974 Discontinuities in the value of this counter can occur 975 at re-initialization of the management system, and at 976 other times as indicated by the value of 977 'discontinuity-time'."; 978 reference 979 "RFC 2863: The Interfaces Group MIB - ifHCOutOctets"; 980 } 981 leaf out-unicast-pkts { 982 type yang:counter64; 983 description 984 "The total number of packets that higher-level protocols 985 requested be transmitted, and which were not addressed 986 to a multicast or broadcast address at this sub-layer, 987 including those that were discarded or not sent. 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 - ifHCOutUcastPkts"; 995 } 996 leaf out-broadcast-pkts { 997 type yang:counter64; 998 description 999 "The total number of packets that higher-level protocols 1000 requested be transmitted, and which were addressed to a 1001 broadcast address at this sub-layer, including those 1002 that were discarded or not sent. 1004 Discontinuities in the value of this counter can occur 1005 at re-initialization of the management system, and at 1006 other times as indicated by the value of 1007 'discontinuity-time'."; 1009 reference 1010 "RFC 2863: The Interfaces Group MIB - 1011 ifHCOutBroadcastPkts"; 1012 } 1013 leaf out-multicast-pkts { 1014 type yang:counter64; 1015 description 1016 "The total number of packets that higher-level protocols 1017 requested be transmitted, and which were addressed to a 1018 multicast address at this sub-layer, including those 1019 that were discarded or not sent. For a MAC layer 1020 protocol, this includes both Group and Functional 1021 addresses. 1023 Discontinuities in the value of this counter can occur 1024 at re-initialization of the management system, and at 1025 other times as indicated by the value of 1026 'discontinuity-time'."; 1027 reference 1028 "RFC 2863: The Interfaces Group MIB - 1029 ifHCOutMulticastPkts"; 1030 } 1031 leaf out-discards { 1032 type yang:counter32; 1033 description 1034 "The number of outbound packets which were chosen to be 1035 discarded even though no errors had been detected to 1036 prevent their being transmitted. One possible reason 1037 for discarding such a packet could be to free up buffer 1038 space. 1040 Discontinuities in the value of this counter can occur 1041 at re-initialization of the management system, and at 1042 other times as indicated by the value of 1043 'discontinuity-time'."; 1044 reference 1045 "RFC 2863: The Interfaces Group MIB - ifOutDiscards"; 1046 } 1047 leaf out-errors { 1048 type yang:counter32; 1049 description 1050 "For packet-oriented interfaces, the number of outbound 1051 packets that could not be transmitted because of errors. 1052 For character-oriented or fixed-length interfaces, the 1053 number of outbound transmission units that could not be 1054 transmitted because of errors. 1056 Discontinuities in the value of this counter can occur 1057 at re-initialization of the management system, and at 1058 other times as indicated by the value of 1059 'discontinuity-time'."; 1060 reference 1061 "RFC 2863: The Interfaces Group MIB - ifOutErrors"; 1062 } 1063 } 1064 } 1065 } 1066 } 1068 1070 6. IANA Considerations 1072 This document registers a URI in the IETF XML registry [RFC3688]. 1073 Following the format in RFC 3688, the following registration is 1074 requested to be made. 1076 URI: urn:ietf:params:xml:ns:yang:ietf-interfaces 1078 Registrant Contact: The IESG. 1080 XML: N/A, the requested URI is an XML namespace. 1082 This document registers a YANG module in the YANG Module Names 1083 registry [RFC6020]. 1085 name: ietf-interfaces 1086 namespace: urn:ietf:params:xml:ns:yang:ietf-interfaces 1087 prefix: if 1088 reference: RFC XXXX 1090 7. Security Considerations 1092 The YANG module defined in this memo is designed to be accessed via 1093 the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the 1094 secure transport layer and the mandatory-to-implement secure 1095 transport is SSH [RFC6242]. The NETCONF access control model 1096 [RFC6536] provides the means to restrict access for particular 1097 NETCONF users to a pre-configured subset of all available NETCONF 1098 protocol operations and content. 1100 There are a number of data nodes defined in the YANG module which are 1101 writable/creatable/deletable (i.e., config true, which is the 1102 default). These data nodes may be considered sensitive or vulnerable 1103 in some network environments. Write operations (e.g., ) 1104 to these data nodes without proper protection can have a negative 1105 effect on network operations. These are the subtrees and data nodes 1106 and their sensitivity/vulnerability: 1108 /interfaces/interface: This list specifies the configured interfaces 1109 on a device. Unauthorized access to this list could cause the 1110 device to ignore packets it should receive and process. 1112 /interfaces/interface/enabled: This leaf controls if an interface is 1113 enabled or not. Unauthorized access to this leaf could cause the 1114 device to ignore packets it should receive and process. 1116 8. Acknowledgments 1118 The author wishes to thank Alexander Clemm, Per Hedeland, Ladislav 1119 Lhotka, and Juergen Schoenwaelder for their helpful comments. 1121 9. References 1123 9.1. Normative References 1125 [I-D.ietf-netmod-iana-if-type] 1126 Bjorklund, M., "IANA Interface Type and Address Family 1127 YANG Modules", draft-ietf-netmod-iana-if-type-06 (work in 1128 progress), April 2013. 1130 [I-D.ietf-netmod-rfc6021-bis] 1131 Schoenwaelder, J., "Common YANG Data Types", 1132 draft-ietf-netmod-rfc6021-bis-02 (work in progress), 1133 May 2013. 1135 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1136 Requirement Levels", BCP 14, RFC 2119, March 1997. 1138 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 1139 MIB", RFC 2863, June 2000. 1141 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1142 January 2004. 1144 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 1145 Network Configuration Protocol (NETCONF)", RFC 6020, 1146 October 2010. 1148 9.2. Informative References 1150 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1151 Schoenwaelder, Ed., "Textual Conventions for SMIv2", 1152 STD 58, RFC 2579, April 1999. 1154 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 1155 Bierman, "Network Configuration Protocol (NETCONF)", 1156 RFC 6241, June 2011. 1158 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1159 Shell (SSH)", RFC 6242, June 2011. 1161 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1162 Protocol (NETCONF) Access Control Model", RFC 6536, 1163 March 2012. 1165 Appendix A. Example: Ethernet Interface Module 1167 This section gives a simple example of how an Ethernet interface 1168 module could be defined. It demonstrates how media-specific 1169 configuration parameters can be conditionally augmented to the 1170 generic interface list. It also shows how operational state 1171 parameters can be conditionally augmented to the operational 1172 interface list. The example is not intended as a complete module for 1173 ethernet configuration. 1175 module ex-ethernet { 1176 namespace "http://example.com/ethernet"; 1177 prefix "eth"; 1179 import ietf-interfaces { 1180 prefix if; 1181 } 1183 // configuration parameters for ethernet interfaces 1184 augment "/if:interfaces/if:interface" { 1185 when "if:type = 'ethernetCsmacd'"; 1187 container ethernet { 1188 choice transmission-params { 1189 case auto { 1190 leaf auto-negotiate { 1191 type empty; 1192 } 1193 } 1194 case manual { 1195 leaf duplex { 1196 type enumeration { 1197 enum "half"; 1198 enum "full"; 1199 } 1200 } 1201 leaf speed { 1202 type enumeration { 1203 enum "10Mb"; 1204 enum "100Mb"; 1205 enum "1Gb"; 1206 enum "10Gb"; 1207 } 1208 } 1209 } 1210 } 1211 // other ethernet specific params... 1212 } 1214 } 1216 // operational state parameters for ethernet interfaces 1217 augment "/if:interfaces-state/if:interface" { 1218 when "if:type = 'ethernetCsmacd'"; 1220 container ethernet { 1221 leaf duplex { 1222 type enumeration { 1223 enum "half"; 1224 enum "full"; 1225 } 1226 } 1227 // other ethernet specific params... 1228 } 1229 } 1230 } 1232 Appendix B. Example: Ethernet Bonding Interface Module 1234 This section gives an example of how interface layering can be 1235 defined. An ethernet bonding interface is defined, which bonds 1236 several ethernet interfaces into one logical interface. 1238 module ex-ethernet-bonding { 1239 namespace "http://example.com/ethernet-bonding"; 1240 prefix "bond"; 1242 import ietf-interfaces { 1243 prefix if; 1244 } 1246 augment "/if:interfaces/if:interface" { 1247 when "if:type = 'ieee8023adLag'"; 1249 leaf-list slave-if { 1250 type if:interface-ref; 1251 must "/if:interfaces/if:interface[if:name = current()]" 1252 + "/if:type = 'ethernetCsmacd'" { 1253 description 1254 "The type of a slave interface must be ethernet."; 1255 } 1256 } 1257 leaf bonding-mode { 1258 type enumeration { 1259 enum round-robin; 1260 enum active-backup; 1261 enum broadcast; 1262 } 1263 } 1264 // other bonding config params, failover times etc. 1265 } 1266 } 1268 Appendix C. Example: VLAN Interface Module 1270 This section gives an example of how a vlan interface module can be 1271 defined. 1273 module ex-vlan { 1274 namespace "http://example.com/vlan"; 1275 prefix "vlan"; 1277 import ietf-interfaces { 1278 prefix if; 1279 } 1281 augment "/if:interfaces/if:interface" { 1282 when "if:type = 'ethernetCsmacd' or 1283 if:type = 'ieee8023adLag'"; 1284 leaf vlan-tagging { 1285 type boolean; 1286 default false; 1287 } 1288 } 1290 augment "/if:interfaces/if:interface" { 1291 when "if:type = 'l2vlan'"; 1293 leaf base-interface { 1294 type if:interface-ref; 1295 must "/if:interfaces/if:interface[if:name = current()]" 1296 + "/vlan:vlan-tagging = 'true'" { 1297 description 1298 "The base interface must have vlan tagging enabled."; 1299 } 1300 } 1301 leaf vlan-id { 1302 type uint16 { 1303 range "1..4094"; 1304 } 1305 must "../base-interface" { 1306 description 1307 "If a vlan-id is defined, a base-interface must 1308 be specified."; 1309 } 1310 } 1311 } 1312 } 1314 Appendix D. Example: NETCONF reply 1316 This section gives an example of a reply to the NETCONF request 1317 for a device that implements the example data models above. 1319 1322 1324 1328 1329 eth0 1330 ethernetCsmacd 1331 false 1332 1334 1335 eth1 1336 ethernetCsmacd 1337 true 1338 true 1339 1341 1342 eth1.10 1343 l2vlan 1344 true 1345 eth1 1346 10 1347 1349 1350 lo1 1351 softwareLoopback 1352 true 1353 1355 1357 1360 1361 eth0 1362 ethernetCsmacd 1363 down 1364 down 1365 2 1366 00:01:02:03:04:05 1367 1368 2013-04-01T03:00:00Z 1369 1370 1371 1373 1374 eth1 1375 ethernetCsmacd 1376 up 1377 up 1378 7 1379 00:01:02:03:04:06 1380 eth1.10 1381 1382 2013-04-01T03:00:00Z 1383 1384 1385 1387 1388 eth1.10 1389 l2vlan 1390 up 1391 up 1392 9 1393 eth1 1394 1395 2013-04-01T03:00:00Z 1396 1397 1398 1400 1401 1402 eth2 1403 ethernetCsmacd 1404 down 1405 down 1406 8 1407 00:01:02:03:04:07 1408 1409 2013-04-01T03:00:00Z 1410 1411 1412 1414 1415 lo1 1416 softwareLoopback 1417 up 1418 up 1419 1 1420 1421 2013-04-01T03:00:00Z 1422 1423 1424 1426 1427 1428 1430 Appendix E. Examples: Interface Naming Schemes 1432 This section gives examples of some implementation strategies. 1434 The examples make use of the example data model "ex-vlan" (see 1435 Appendix C) to show how logical interfaces can be configured. 1437 E.1. Router with Restricted Interface Names 1439 In this example, a router has support for 4 line cards, each with 8 1440 ports. The slots for the cards are physically numbered from 0 to 3, 1441 and the ports on each card from 0 to 7. Each card has fast- or 1442 gigabit-ethernet ports. 1444 The device-specific names for these physical interfaces are 1445 "fastethernet-N/M" or "gigabitethernet-N/M". 1447 The name of a vlan interface is restricted to the form 1448 ".". 1450 It is assumed that the operator is aware of this naming scheme. The 1451 implementation auto-initializes the value for "type" based on the 1452 interface name. 1454 The NETCONF server does not advertise the 'arbitrary-names' feature 1455 in the message. 1457 An operator can configure a physical interface by sending an 1458 containing: 1460 1461 fastethernet-1/0 1462 1464 When the server processes this request, it will set the leaf "type" 1465 to "ethernetCsmacd". Thus, if the client performs a 1466 right after the above, it will get: 1468 1469 fastethernet-1/0 1470 ethernetCsmacd 1471 1473 The client can configure a vlan interface by sending an 1474 containing: 1476 1477 fastethernet-1/0.10005 1478 l2-vlan 1479 fastethernet-1/0 1480 5 1481 1483 If the client tries to change the type of the physical interface with 1484 an containing: 1486 1487 fastethernet-1/0 1488 tunnel 1489 1491 then the server will reply with an "invalid-value" error, since the 1492 new type does not match the name. 1494 E.2. Router with Arbitrary Interface Names 1496 In this example, a router has support for 4 line cards, each with 8 1497 ports. The slots for the cards are physically numbered from 0 to 3, 1498 and the ports on each card from 0 to 7. Each card has fast- or 1499 gigabit-ethernet ports. 1501 The device-specific names for these physical interfaces are 1502 "fastethernet-N/M" or "gigabitethernet-N/M". 1504 The implementation does not restrict the logical interface names. 1505 This allows to more easily apply the interface configuration to a 1506 different interface. However, the additional level of indirection 1507 also makes it a bit more complex to map interface names found in 1508 other protocols to configuration entries. 1510 The NETCONF server advertises the 'arbitrary-names' feature in the 1511 message. 1513 Physical interfaces are configured as in Appendix E.1. 1515 An operator can configure a logical interface by sending an 1516 containing: 1518 1519 acme-interface 1520 l2-vlan 1521 fastethernet-1/0 1522 5 1523 1525 If necessary, the operator can move the configuration named 1526 "acme-interface" over to a different physical interface with an 1527 containing: 1529 1530 acme-interface 1531 fastethernet-1/1 1532 1534 E.3. Ethernet Switch with Restricted Interface Names 1536 In this example, an ethernet switch has a number of ports, each port 1537 identified by a simple port number. 1539 The device-specific names for the physical interfaces are numbers 1540 that match the physical port number. 1542 An operator can configure a physical interface by sending an 1543 containing: 1545 1546 6 1547 1549 When the server processes this request, it will set the leaf "type" 1550 to "ethernetCsmacd". Thus, if the client performs a 1551 right after the above, it will get: 1553 1554 6 1555 ethernetCsmacd 1556 1558 E.4. Generic Host with Restricted Interface Names 1560 In this example, a generic host has interfaces named by the kernel. 1561 The system identifies the physical interface by the name assigned by 1562 the operating system to the interface. 1564 The name of a vlan interface is restricted to the form 1565 ":". 1567 The NETCONF server does not advertise the 'arbitrary-names' feature 1568 in the message. 1570 An operator can configure an interface by sending an 1571 containing: 1573 1574 eth8 1575 1577 When the server processes this request, it will set the leaf "type" 1578 to "ethernetCsmacd". Thus, if the client performs a 1579 right after the above, it will get: 1581 1582 eth8 1583 ethernetCsmacd 1584 1586 The client can configure a vlan interface by sending an 1587 containing: 1589 1590 eth8:5 1591 l2-vlan 1592 eth8 1593 5 1594 1596 E.5. Generic Host with Arbitrary Interface Names 1598 In this example, a generic host has interfaces named by the kernel. 1599 The system identifies the physical interface by the name assigned by 1600 the operating system to the interface. 1602 The implementation does not restrict the logical interface names. 1603 This allows to more easily apply the interface configuration to a 1604 different interface. However, the additional level of indirection 1605 also makes it a bit more complex to map interface names found in 1606 other protocols to configuration entries. 1608 The NETCONF server advertises the 'arbitrary-names' feature in the 1609 message. 1611 Physical interfaces are configured as in Appendix E.4. 1613 An operator can configure a logical interface by sending an 1614 containing: 1616 1617 acme-interface 1618 l2-vlan 1619 eth8 1620 5 1622 1624 If necessary, the operator can move the configuration named 1625 "acme-interface" over to a different physical interface with an 1626 containing: 1628 1629 acme-interface 1630 eth3 1631 1633 Appendix F. ChangeLog 1635 RFC Editor: remove this section upon publication as an RFC. 1637 F.1. Version -11 1639 o Separated the operational state from the configuration. 1641 o Removed 'location', and instead use the name to identify physical 1642 interfaces. 1644 o Added the feature 'pre-provisioning'. 1646 o Made 'oper-status' and 'if-index' mandatory in the data model. 1648 o Added 'admin-status'. 1650 o Clarified why description can be mapped to ifAlias. 1652 o Clarified that 64-bit counters only are used, where there exist 1653 64-bit and 32-bit counters in IF-MIB. 1655 o Updated Security Considerations section with a reference to NACM. 1657 F.2. Version -08 1659 o Removed the mtu leaf. 1661 o Added examples of different interface naming schemes. 1663 F.3. Version -07 1665 o Made leaf speed config false. 1667 F.4. Version -06 1669 o Added oper-status leaf. 1671 o Added leaf-lists higher-layer-if and lower-layer-if, that show the 1672 interface layering. 1674 o Added container statistics with counters. 1676 F.5. Version -05 1678 o Added an Informative References section. 1680 o Updated the Security Considerations section. 1682 o Clarified the behavior of an NETCONF server when invalid values 1683 are received. 1685 F.6. Version -04 1687 o Clarified why ifPromiscuousMode is not part of this data model. 1689 o Added a table that shows the mapping between this YANG data model 1690 and IF-MIB. 1692 F.7. Version -03 1694 o Added the section Relationship to the IF-MIB. 1696 o Changed if-index to be a leaf instead of leaf-list. 1698 o Explained the notation used in the data model tree picture. 1700 F.8. Version -02 1702 o Editorial fixes 1704 F.9. Version -01 1706 o Changed leaf "if-admin-status" to leaf "enabled". 1708 o Added Security Considerations 1710 Author's Address 1712 Martin Bjorklund 1713 Tail-f Systems 1715 Email: mbj@tail-f.com