--- 1/draft-ietf-netmod-interfaces-cfg-09.txt 2013-05-02 08:42:19.983458013 +0100 +++ 2/draft-ietf-netmod-interfaces-cfg-10.txt 2013-05-02 08:42:20.971482618 +0100 @@ -1,18 +1,18 @@ Network Working Group M. Bjorklund Internet-Draft Tail-f Systems -Intended status: Standards Track February 6, 2013 -Expires: August 10, 2013 +Intended status: Standards Track April 19, 2013 +Expires: October 21, 2013 A YANG Data Model for Interface Management - draft-ietf-netmod-interfaces-cfg-09 + draft-ietf-netmod-interfaces-cfg-10 Abstract This document defines a YANG data model for the management of network interfaces. It is expected that interface type specific data models augment the generic interfaces data model defined in this document. Status of this Memo This Internet-Draft is submitted in full conformance with the @@ -21,21 +21,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on August 10, 2013. + This Internet-Draft will expire on October 21, 2013. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -65,30 +65,30 @@ Appendix A. Example: Ethernet Interface Module . . . . . . . . . 27 Appendix B. Example: Ethernet Bonding Interface Module . . . . . 29 Appendix C. Example: VLAN Interface Module . . . . . . . . . . . 30 Appendix D. Example: NETCONF reply . . . . . . . . . . . . 31 Appendix E. Examples: Interface Naming Schemes . . . . . . . . . 32 E.1. Router with Restricted Interface Names . . . . . . . . . . 32 E.2. Router with Arbitrary Interface Names . . . . . . . . . . 33 E.3. Ethernet Switch with Restricted Interface Names . . . . . 33 E.4. Generic Host with Restricted Interface Names . . . . . . . 34 E.5. Generic Host with Arbitrary Interface Names . . . . . . . 35 - Appendix F. ChangeLog . . . . . . . . . . . . . . . . . . . . . . 36 - F.1. Version -08 . . . . . . . . . . . . . . . . . . . . . . . 36 - F.2. Version -07 . . . . . . . . . . . . . . . . . . . . . . . 36 - F.3. Version -06 . . . . . . . . . . . . . . . . . . . . . . . 36 - F.4. Version -05 . . . . . . . . . . . . . . . . . . . . . . . 36 - F.5. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 36 - F.6. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 36 - F.7. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 37 - F.8. Version -01 . . . . . . . . . . . . . . . . . . . . . . . 37 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 38 + Appendix F. ChangeLog . . . . . . . . . . . . . . . . . . . . . . 37 + F.1. Version -08 . . . . . . . . . . . . . . . . . . . . . . . 37 + F.2. Version -07 . . . . . . . . . . . . . . . . . . . . . . . 37 + F.3. Version -06 . . . . . . . . . . . . . . . . . . . . . . . 37 + F.4. Version -05 . . . . . . . . . . . . . . . . . . . . . . . 37 + F.5. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 37 + F.6. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 37 + F.7. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 38 + F.8. Version -01 . . . . . . . . . . . . . . . . . . . . . . . 38 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 39 1. Introduction This document defines a YANG [RFC6020] data model for the management of network interfaces. It is expected that interface type specific data models augment the generic interfaces data model defined in this document. Network interfaces are central to the management of many Internet protocols. Thus, it is important to establish a common data model @@ -117,22 +117,22 @@ o data node 2. Objectives This section describes some of the design objectives for the model presented in Section 5. o It is recognized that existing implementations will have to map the interface data model defined in this memo to their proprietary - native data model. The new data model should be simple to - facilitate such mappings. + native data model. The data model should be simple to facilitate + such mappings. o The data model should be suitable for new implementations to use as-is, without requiring a mapping to a different native model. o References to interfaces should be as simple as possible, preferably by using a single leafref. o The mapping to ifIndex [RFC2863] used by SNMP to identify interfaces must be clear. @@ -183,23 +183,23 @@ +--ro out-unicast-pkts? yang:counter64 +--ro out-broadcast-pkts? yang:counter64 +--ro out-multicast-pkts? yang:counter64 +--ro out-discards? yang:counter32 +--ro out-errors? yang:counter32 3.1. The interface List The data model for interfaces presented in this document uses a flat list of interfaces. Each interface in the list is identified by its - name. Furthermore, each interface has a mandatory "type" leaf, and a - "location" leaf. The combination of "type" and "location" is unique - within the interface list. + name. Furthermore, each interface has a mandatory "type" leaf, and + an optional "location" leaf. The combination of "type" and + "location" is unique within the interface list. It is expected that interface type specific data models augment the interface list, and use the "type" leaf to make the augmentation conditional. As an example of such an interface type specific augmentation, consider this YANG snippet. For a more complete example, see Appendix A. import interfaces { @@ -264,21 +264,21 @@ // other bonding config params, failover times etc. } Two state data leaf-lists, "higher-layer-if" and "lower-layer-if", represent a read-only view of the interface layering hierarchy. 4. Relationship to the IF-MIB If the device implements IF-MIB [RFC2863], each entry in the "interface" list is typically mapped to one ifEntry. The "if-index" - leaf contains the value of the corresponding ifEntry's ifIndex. + leaf MUST contain the value of the corresponding ifEntry's ifIndex. In most cases, the "name" of an "interface" entry is mapped to ifName. ifName is defined as an DisplayString [RFC2579] which uses a 7-bit ASCII character set. An implementation MAY restrict the allowed values for "name" to match the restrictions of ifName. The IF-MIB allows two different ifEntries to have the same ifName. Devices that support this feature, and also support the configuration of these interfaces using the "interface" list, cannot have a 1-1 mapping between the "name" leaf and ifName. @@ -1094,21 +1094,21 @@ default false; } } augment "/if:interfaces/if:interface" { when "if:type = 'l2vlan'"; leaf base-interface { type if:interface-ref; must "/if:interfaces/if:interface[if:name = current()]" - + "/vlan:vlan-tagging = true" { + + "/vlan:vlan-tagging = 'true'" { description "The base interface must have vlan tagging enabled."; } } leaf vlan-id { type uint16 { range "1..4094"; } must "../base-interface" { description @@ -1122,36 +1122,44 @@ Appendix D. Example: NETCONF reply This section gives an example of a reply to the NETCONF request for a device that implements the example data models above. + xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces" + xmlns:vlan="http://example.com/vlan"> eth0 ethernetCsmacd 0 true 2 eth1 ethernetCsmacd 1 true 7 - true + true + + + eth1.10 + l2vlan + true + 9 + eth1 + 10 Appendix E. Examples: Interface Naming Schemes This section gives examples of some implementation strategies. E.1. Router with Restricted Interface Names @@ -1160,20 +1168,23 @@ ports. The slots for the cards are physically numbered from 0 to 3, and the ports on each card from 0 to 7. Each card has fast- or gigabit-ethernet ports. The implementation restricts the names of the interfaces to one of "fastethernet-N/M" or "gigabitethernet-N/M". The "location" of an interface is a string on the form "N/M". The implementation auto- initializes the values for "type" and "location" based on the interface name. + The NETCONF server does not advertise the 'arbitrary-names' feature + in the message. + An operator can configure a new interface by sending an containing: fastethernet-1/0 When the server processes this request, it will set the leaf "type" to "ethernetCsmacd" and "location" to "1/0". Thus, if the client performs a right after the above, it will @@ -1203,20 +1214,23 @@ and the ports on each card from 0 to 7. Each card has fast- or gigabit-ethernet ports. The implementation does not restrict the interface names. This allows to more easily apply the interface configuration to a different physical interface. However, the additional level of indirection also makes it a bit more complex to map interface names found in other protocols to configuration entries. The "location" of an interface is a string on the form "N/M". + The NETCONF server advertises the 'arbitrary-names' feature in the + message. + An operator can configure a new interface by sending an containing: acme-interface ethernetCsmacd 1/0 If necessary, the operator can move the configuration named @@ -1229,20 +1243,23 @@ E.3. Ethernet Switch with Restricted Interface Names In this example, an ethernet switch has a number of ports, each port identified by a simple port number. The implementation restricts the interface names to numbers that match the physical port number. + The NETCONF server does not advertise the 'arbitrary-names' feature + in the message. + An operator can configure a new interface by sending an containing: 6 When the server processes this request, it will set the leaf "type" to "ethernetCsmacd" and "location" to "6". Thus, if the client performs a right after the above, it will @@ -1268,20 +1285,23 @@ E.4. Generic Host with Restricted Interface Names In this example, a generic host has interfaces named by the kernel and without easily usable location information. The system identifies the physical interface by the name assigned by the operating system to the interface. The implementation restricts the interface name to the operating system level name of the physical interface. + The NETCONF server does not advertise the 'arbitrary-names' feature + in the message. + An operator can configure a new interface by sending an containing: eth8 When the server processes this request, it will set the leaf "type" to "ethernetCsmacd" and "location" to "eth8". Thus, if the client performs a right after the above, it will @@ -1311,20 +1331,23 @@ identifies the physical interface by the name assigned by the operating system to the interface. The implementation does not restrict the interface name to the operating system level name of the physical interface. This allows to more easily apply the interface configuration to a different physical interface. However, the additional level of indirection also makes it a bit more complex to map interface names found in other protocols to configuration entries. + The NETCONF server advertises the 'arbitrary-names' feature in the + message. + An operator can configure a new interface by sending an containing: acme-interface ethernetCsmacd eth4 If necessary, the operator can move the configuration named