draft-ietf-netmod-interfaces-cfg-10.txt | draft-ietf-netmod-interfaces-cfg-11.txt | |||
---|---|---|---|---|
Network Working Group M. Bjorklund | Network Working Group M. Bjorklund | |||
Internet-Draft Tail-f Systems | Internet-Draft Tail-f Systems | |||
Intended status: Standards Track April 19, 2013 | Intended status: Standards Track May 15, 2013 | |||
Expires: October 21, 2013 | Expires: November 16, 2013 | |||
A YANG Data Model for Interface Management | A YANG Data Model for Interface Management | |||
draft-ietf-netmod-interfaces-cfg-10 | draft-ietf-netmod-interfaces-cfg-11 | |||
Abstract | Abstract | |||
This document defines a YANG data model for the management of network | This document defines a YANG data model for the management of network | |||
interfaces. It is expected that interface type specific data models | interfaces. It is expected that interface type specific data models | |||
augment the generic interfaces data model defined in this document. | augment the generic interfaces data model defined in this document. | |||
The data model includes configuration data, state data and counters | ||||
for the collection of statistics. | ||||
Status of this Memo | Status of this Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on October 21, 2013. | This Internet-Draft will expire on November 16, 2013. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2013 IETF Trust and the persons identified as the | Copyright (c) 2013 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 | 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3 | |||
3. Interfaces Data Model . . . . . . . . . . . . . . . . . . . . 5 | 2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
3.1. The interface List . . . . . . . . . . . . . . . . . . . . 5 | 3. Interfaces Data Model . . . . . . . . . . . . . . . . . . . . 6 | |||
3.2. Interface References . . . . . . . . . . . . . . . . . . . 6 | 3.1. The interface Lists . . . . . . . . . . . . . . . . . . . 6 | |||
3.3. Interface Layering . . . . . . . . . . . . . . . . . . . . 6 | 3.2. Interface References . . . . . . . . . . . . . . . . . . . 7 | |||
4. Relationship to the IF-MIB . . . . . . . . . . . . . . . . . . 8 | 3.3. Interface Layering . . . . . . . . . . . . . . . . . . . . 7 | |||
5. Interfaces YANG Module . . . . . . . . . . . . . . . . . . . . 10 | 4. Relationship to the IF-MIB . . . . . . . . . . . . . . . . . . 9 | |||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 | 5. Interfaces YANG Module . . . . . . . . . . . . . . . . . . . . 11 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 | |||
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 | |||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 | 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 | |||
9.1. Normative References . . . . . . . . . . . . . . . . . . . 26 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 | |||
9.2. Informative References . . . . . . . . . . . . . . . . . . 26 | 9.1. Normative References . . . . . . . . . . . . . . . . . . . 29 | |||
Appendix A. Example: Ethernet Interface Module . . . . . . . . . 27 | 9.2. Informative References . . . . . . . . . . . . . . . . . . 29 | |||
Appendix B. Example: Ethernet Bonding Interface Module . . . . . 29 | Appendix A. Example: Ethernet Interface Module . . . . . . . . . 30 | |||
Appendix C. Example: VLAN Interface Module . . . . . . . . . . . 30 | Appendix B. Example: Ethernet Bonding Interface Module . . . . . 32 | |||
Appendix D. Example: NETCONF <get> reply . . . . . . . . . . . . 31 | Appendix C. Example: VLAN Interface Module . . . . . . . . . . . 33 | |||
Appendix E. Examples: Interface Naming Schemes . . . . . . . . . 32 | Appendix D. Example: NETCONF <get> reply . . . . . . . . . . . . 34 | |||
E.1. Router with Restricted Interface Names . . . . . . . . . . 32 | Appendix E. Examples: Interface Naming Schemes . . . . . . . . . 37 | |||
E.2. Router with Arbitrary Interface Names . . . . . . . . . . 33 | E.1. Router with Restricted Interface Names . . . . . . . . . . 37 | |||
E.3. Ethernet Switch with Restricted Interface Names . . . . . 33 | E.2. Router with Arbitrary Interface Names . . . . . . . . . . 38 | |||
E.4. Generic Host with Restricted Interface Names . . . . . . . 34 | E.3. Ethernet Switch with Restricted Interface Names . . . . . 39 | |||
E.5. Generic Host with Arbitrary Interface Names . . . . . . . 35 | E.4. Generic Host with Restricted Interface Names . . . . . . . 39 | |||
Appendix F. ChangeLog . . . . . . . . . . . . . . . . . . . . . . 37 | E.5. Generic Host with Arbitrary Interface Names . . . . . . . 40 | |||
F.1. Version -08 . . . . . . . . . . . . . . . . . . . . . . . 37 | Appendix F. ChangeLog . . . . . . . . . . . . . . . . . . . . . . 42 | |||
F.2. Version -07 . . . . . . . . . . . . . . . . . . . . . . . 37 | F.1. Version -11 . . . . . . . . . . . . . . . . . . . . . . . 42 | |||
F.3. Version -06 . . . . . . . . . . . . . . . . . . . . . . . 37 | F.2. Version -08 . . . . . . . . . . . . . . . . . . . . . . . 42 | |||
F.4. Version -05 . . . . . . . . . . . . . . . . . . . . . . . 37 | F.3. Version -07 . . . . . . . . . . . . . . . . . . . . . . . 42 | |||
F.5. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 37 | F.4. Version -06 . . . . . . . . . . . . . . . . . . . . . . . 42 | |||
F.6. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 37 | F.5. Version -05 . . . . . . . . . . . . . . . . . . . . . . . 42 | |||
F.7. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 38 | F.6. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 43 | |||
F.8. Version -01 . . . . . . . . . . . . . . . . . . . . . . . 38 | F.7. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 43 | |||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 39 | F.8. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 43 | |||
F.9. Version -01 . . . . . . . . . . . . . . . . . . . . . . . 43 | ||||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 44 | ||||
1. Introduction | 1. Introduction | |||
This document defines a YANG [RFC6020] data model for the management | This document defines a YANG [RFC6020] data model for the management | |||
of network interfaces. It is expected that interface type specific | of network interfaces. It is expected that interface type specific | |||
data models augment the generic interfaces data model defined in this | data models augment the generic interfaces data model defined in this | |||
document. | document. | |||
Network interfaces are central to the management of many Internet | Network interfaces are central to the management of many Internet | |||
protocols. Thus, it is important to establish a common data model | protocols. Thus, it is important to establish a common data model | |||
for how interfaces are identified and configured. | for how interfaces are identified, configured, and monitored. | |||
The data model includes configuration data, state data and counters | ||||
for the collection of statistics. | ||||
1.1. Terminology | 1.1. Terminology | |||
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
"OPTIONAL" in this document are to be interpreted as described in BCP | "OPTIONAL" in this document are to be interpreted as described in BCP | |||
14, [RFC2119]. | 14, [RFC2119]. | |||
The following terms are defined in [RFC6241] and are not redefined | The following terms are defined in [RFC6241] and are not redefined | |||
here: | here: | |||
o client | o client | |||
o configuration data | ||||
o server | o server | |||
o state data | ||||
The following terms are defined in [RFC6020] and are not redefined | The following terms are defined in [RFC6020] and are not redefined | |||
here: | here: | |||
o augment | o augment | |||
o data model | o data model | |||
o data node | o data node | |||
1.2. Tree Diagrams | ||||
A simplified graphical representation of the data model is used in | ||||
this document. The meaning of the symbols in these diagrams is as | ||||
follows: | ||||
o Brackets "[" and "]" enclose list keys. | ||||
o Abbreviations before data node names: "rw" means configuration | ||||
(read-write) and "ro" state data (read-only). | ||||
o Symbols after data node names: "?" means an optional node and "*" | ||||
denotes a "list" and "leaf-list". | ||||
o Parentheses enclose choice and case nodes, and case nodes are also | ||||
marked with a colon (":"). | ||||
o Ellipsis ("...") stands for contents of subtrees that are not | ||||
shown. | ||||
2. Objectives | 2. Objectives | |||
This section describes some of the design objectives for the model | This section describes some of the design objectives for the model | |||
presented in Section 5. | presented in Section 5. | |||
o It is recognized that existing implementations will have to map | o It is recognized that existing implementations will have to map | |||
the interface data model defined in this memo to their proprietary | the interface data model defined in this memo to their proprietary | |||
native data model. The data model should be simple to facilitate | native data model. The data model should be simple to facilitate | |||
such mappings. | such mappings. | |||
skipping to change at page 4, line 26 | skipping to change at page 5, line 26 | |||
as-is, without requiring a mapping to a different native model. | as-is, without requiring a mapping to a different native model. | |||
o References to interfaces should be as simple as possible, | o References to interfaces should be as simple as possible, | |||
preferably by using a single leafref. | preferably by using a single leafref. | |||
o The mapping to ifIndex [RFC2863] used by SNMP to identify | o The mapping to ifIndex [RFC2863] used by SNMP to identify | |||
interfaces must be clear. | interfaces must be clear. | |||
o The model must support interface layering, both simple layering | o The model must support interface layering, both simple layering | |||
where one interface is layered on top of exactly one other | where one interface is layered on top of exactly one other | |||
interface, and more complex scenarios where one interface is | interface, and more complex scenarios where one interface results | |||
aggregated over N other interfaces, or when N interfaces are | from the aggregation of N other interfaces, or when N interfaces | |||
multiplexed over one other interface. | are multiplexed over one other interface. | |||
o The data model should support the pre-provisioning of interface | o The data model should support the pre-provisioning of interface | |||
configuration, i.e., it should be possible to configure an | configuration, i.e., it should be possible to configure an | |||
interface whose physical interface hardware is not present on the | interface whose physical interface hardware is not present on the | |||
device. It is recommended that devices that support dynamic | device. It is recommended that devices that support dynamic | |||
addition and removal of physical interfaces also support pre- | addition and removal of physical interfaces also support pre- | |||
provisioning. | provisioning. | |||
o The data model should support both physical interfaces as well as | ||||
logical interfaces. | ||||
o The data model should include read-only counters in order to | ||||
gather statistics for octets, packets and errors, sent and | ||||
received. | ||||
3. Interfaces Data Model | 3. Interfaces Data Model | |||
The data model in the module "ietf-interfaces" has the following | This document defines the YANG module "ietf-interfaces", which has | |||
structure, where square brackets are used to enclose a list's keys, | the following structure: | |||
"?" means that the leaf is optional, and "*" denotes a leaf-list: | ||||
+--rw interfaces | +--rw interfaces | |||
+--rw interface [name] | | +--rw interface* [name] | |||
+--rw name string | | +--rw name string | |||
+--rw description? string | | +--rw description? string | |||
+--rw type ianaift:iana-if-type | | +--rw type ianaift:iana-if-type | |||
+--rw location? string | | +--rw enabled? boolean | |||
+--rw enabled? boolean | | +--rw link-up-down-trap-enable? enumeration | |||
+--ro oper-status? enumeration | +--ro interfaces-state | |||
+--ro last-change? yang:date-and-time | +--ro interface* [name] | |||
+--ro if-index? int32 | +--ro name string | |||
+--rw link-up-down-trap-enable? enumeration | +--ro type ianaift:iana-if-type | |||
+--ro phys-address? yang:phys-address | +--ro admin-status enumeration | |||
+--ro higher-layer-if* interface-ref | +--ro oper-status enumeration | |||
+--ro lower-layer-if* interface-ref | +--ro last-change? yang:date-and-time | |||
+--ro speed? yang:gauge64 | +--ro if-index int32 | |||
+--ro phys-address? yang:phys-address | ||||
+--ro higher-layer-if* interface-state-ref | ||||
+--ro lower-layer-if* interface-state-ref | ||||
+--ro speed? yang:gauge64 | ||||
+--ro statistics | +--ro statistics | |||
+--ro discontinuity-time? yang:date-and-time | +--ro discontinuity-time yang:date-and-time | |||
+--ro in-octets? yang:counter64 | +--ro in-octets? yang:counter64 | |||
+--ro in-unicast-pkts? yang:counter64 | +--ro in-unicast-pkts? yang:counter64 | |||
+--ro in-broadcast-pkts? yang:counter64 | +--ro in-broadcast-pkts? yang:counter64 | |||
+--ro in-multicast-pkts? yang:counter64 | +--ro in-multicast-pkts? yang:counter64 | |||
+--ro in-discards? yang:counter32 | +--ro in-discards? yang:counter32 | |||
+--ro in-errors? yang:counter32 | +--ro in-errors? yang:counter32 | |||
+--ro in-unknown-protos? yang:counter32 | +--ro in-unknown-protos? yang:counter32 | |||
+--ro out-octets? yang:counter64 | +--ro out-octets? yang:counter64 | |||
+--ro out-unicast-pkts? yang:counter64 | +--ro out-unicast-pkts? yang:counter64 | |||
+--ro out-broadcast-pkts? yang:counter64 | +--ro out-broadcast-pkts? yang:counter64 | |||
+--ro out-multicast-pkts? yang:counter64 | +--ro out-multicast-pkts? yang:counter64 | |||
+--ro out-discards? yang:counter32 | +--ro out-discards? yang:counter32 | |||
+--ro out-errors? yang:counter32 | +--ro out-errors? yang:counter32 | |||
3.1. The interface List | 3.1. The interface Lists | |||
The data model for interfaces presented in this document uses a flat | The data model for interfaces presented in this document uses a flat | |||
list of interfaces. Each interface in the list is identified by its | list of interfaces. Each interface in the list is identified by its | |||
name. Furthermore, each interface has a mandatory "type" leaf, and | name. Furthermore, each interface has a mandatory "type" leaf. | |||
an optional "location" leaf. The combination of "type" and | ||||
"location" is unique within the interface list. | There is one list of configured interfaces ("/interfaces/interface"), | |||
and a separate list for the operational state of all interfaces | ||||
("/interfaces-state/interface"). | ||||
It is expected that interface type specific data models augment the | It is expected that interface type specific data models augment the | |||
interface list, and use the "type" leaf to make the augmentation | interface lists, and use the "type" leaf to make the augmentation | |||
conditional. | conditional. | |||
As an example of such an interface type specific augmentation, | As an example of such an interface type specific augmentation, | |||
consider this YANG snippet. For a more complete example, see | consider this YANG snippet. For a more complete example, see | |||
Appendix A. | Appendix A. | |||
import interfaces { | import interfaces { | |||
prefix "if"; | prefix "if"; | |||
} | } | |||
augment "/if:interfaces/if:interface" { | augment "/if:interfaces/if:interface" { | |||
when "if:type = 'ethernetCsmacd'"; | when "if:type = 'ethernetCsmacd'"; | |||
container ethernet { | container ethernet { | |||
leaf duplex { | leaf duplex { | |||
... | ... | |||
} | } | |||
} | } | |||
} | } | |||
The "location" leaf is a string. It is optional in the data model, | For physical interfaces, the "name" is the device-specific name of | |||
but if the type represents a physical interface, it is mandatory. | the interface. It is used to identify the physical hardware | |||
The format of this string is device- and type-dependent. The device | interface. The 'config false' list "/interfaces-state/interface" | |||
uses the location string to identify the physical or logical entity | contains all currently existing interfaces on the device. | |||
that the configuration applies to. For example, if a device has a | ||||
single array of 8 ethernet ports, the location can be one of the | ||||
strings "1" to "8". As another example, if a device has N cards of M | ||||
ports, the location can be on the form "n/m", such as "1/0". | ||||
How a client can learn which types and locations are present on a | If the device supports arbitrarily named logical interfaces, the | |||
certain device is outside the scope of this document. | NETCONF server advertises the feature "arbitrary-names". If the | |||
device does not advertise this feature, the names of logical | ||||
interfaces MUST match the device's naming scheme. How a client can | ||||
learn the naming scheme of such devices is outside the scope of this | ||||
document. | ||||
3.2. Interface References | 3.2. Interface References | |||
An interface is identified by its name, which is unique within the | An interface is identified by its name, which is unique within the | |||
server. This property is captured in the "interface-ref" typedef, | server. This property is captured in the "interface-ref" and | |||
which other YANG modules SHOULD use when they need to reference an | "interface-state-ref" typedefs, which other YANG modules SHOULD use | |||
existing interface. | when they need to reference a configured interface or operationally | |||
used interface, respectively. | ||||
3.3. Interface Layering | 3.3. Interface Layering | |||
There is no generic mechanism for how an interface is configured to | There is no generic mechanism for how an interface is configured to | |||
be layered on top of some other interface. It is expected that | be layered on top of some other interface. It is expected that | |||
interface type specific models define their own data nodes for | interface type specific models define their own data nodes for | |||
interface layering, by using "interface-ref" types to reference lower | interface layering, by using "interface-ref" types to reference lower | |||
layers. | layers. | |||
Below is an example of a model with such nodes. For a more complete | Below is an example of a model with such nodes. For a more complete | |||
skipping to change at page 8, line 8 | skipping to change at page 9, line 8 | |||
} | } | |||
// other bonding config params, failover times etc. | // other bonding config params, failover times etc. | |||
} | } | |||
Two state data leaf-lists, "higher-layer-if" and "lower-layer-if", | Two state data leaf-lists, "higher-layer-if" and "lower-layer-if", | |||
represent a read-only view of the interface layering hierarchy. | represent a read-only view of the interface layering hierarchy. | |||
4. Relationship to the IF-MIB | 4. Relationship to the IF-MIB | |||
If the device implements IF-MIB [RFC2863], each entry in the | If the device implements IF-MIB [RFC2863], each entry in the | |||
"interface" list is typically mapped to one ifEntry. The "if-index" | "/interfaces-state/interface" list is typically mapped to one | |||
leaf MUST contain the value of the corresponding ifEntry's ifIndex. | ifEntry. The "if-index" leaf MUST contain the value of the | |||
corresponding ifEntry's ifIndex. | ||||
In most cases, the "name" of an "interface" entry is mapped to | In most cases, the "name" of an "interface" entry is mapped to | |||
ifName. ifName is defined as an DisplayString [RFC2579] which uses a | ifName. ifName is defined as an DisplayString [RFC2579] which uses a | |||
7-bit ASCII character set. An implementation MAY restrict the | 7-bit ASCII character set. An implementation MUST restrict the | |||
allowed values for "name" to match the restrictions of ifName. | allowed values for "name" to match the restrictions of ifName. | |||
The IF-MIB allows two different ifEntries to have the same ifName. | The IF-MIB allows two different ifEntries to have the same ifName. | |||
Devices that support this feature, and also support the configuration | Devices that support this feature, and also support the data model | |||
of these interfaces using the "interface" list, cannot have a 1-1 | defined in this document, cannot have a 1-1 mapping between the | |||
mapping between the "name" leaf and ifName. | "name" leaf and ifName. | |||
The configured "description" of an "interface" has traditionally been | ||||
mapped to ifAlias in some implementations. This document allows this | ||||
mapping, but implementers should be aware of the differences in the | ||||
value space and persistence for these objects. See the YANG module | ||||
definition of the leaf "description" in Section 5 for details. | ||||
The IF-MIB also defines the writable object ifPromiscuousMode. Since | The IF-MIB also defines the writable object ifPromiscuousMode. Since | |||
this object typically is not a configuration object, it is not mapped | this object typically is not a configuration object, it is not mapped | |||
to the "ietf-interfaces" module. | to the "ietf-interfaces" module. | |||
There are a number of counters in the IF-MIB that exist in two | ||||
versions; one with 32 bits and one with 64 bits. The YANG module | ||||
contains the 64 bits counters only. Note that NETCONF and SNMP may | ||||
differ in the time granularity in which they provide access to the | ||||
counters. For example, it is common that SNMP implementations cache | ||||
counter values for some time. | ||||
The following table lists the YANG data nodes with corresponding | The following table lists the YANG data nodes with corresponding | |||
objects in the IF-MIB. | objects in the IF-MIB. | |||
+----------------------------------+------------------------+ | +----------------------------------+------------------------+ | |||
| YANG data node | IF-MIB object | | | YANG data node | IF-MIB object | | |||
+----------------------------------+------------------------+ | +----------------------------------+------------------------+ | |||
| interface | ifEntry | | | interface | ifEntry | | |||
| name | ifName | | | name | ifName | | |||
| description | ifAlias | | | description | ifAlias | | |||
| type | ifType | | | type | ifType | | |||
| enabled | ifAdminStatus | | | enabled / admin-status | ifAdminStatus | | |||
| oper-status | ifOperStatus | | | oper-status | ifOperStatus | | |||
| last-change | ifLastChange | | | last-change | ifLastChange | | |||
| if-index | ifIndex | | | if-index | ifIndex | | |||
| link-up-down-trap-enable | ifLinkUpDownTrapEnable | | | link-up-down-trap-enable | ifLinkUpDownTrapEnable | | |||
| phys-address | ifPhysAddress | | | phys-address | ifPhysAddress | | |||
| higher-layer-if / lower-layer-if | ifStackTable | | | higher-layer-if / lower-layer-if | ifStackTable | | |||
| speed | ifSpeed | | | speed | ifSpeed | | |||
| in-octets | ifHCInOctets | | | in-octets | ifHCInOctets | | |||
| in-unicast-pkts | ifHCInUcastPkts | | | in-unicast-pkts | ifHCInUcastPkts | | |||
| in-broadcast-pkts | ifHCInBroadcastPkts | | | in-broadcast-pkts | ifHCInBroadcastPkts | | |||
skipping to change at page 9, line 35 | skipping to change at page 10, line 35 | |||
| in-errors | ifInErrors | | | in-errors | ifInErrors | | |||
| in-unknown-protos | ifInUnknownProtos | | | in-unknown-protos | ifInUnknownProtos | | |||
| out-octets | ifHCOutOctets | | | out-octets | ifHCOutOctets | | |||
| out-unicast-pkts | ifHCOutUcastPkts | | | out-unicast-pkts | ifHCOutUcastPkts | | |||
| out-broadcast-pkts | ifHCOutBroadcastPkts | | | out-broadcast-pkts | ifHCOutBroadcastPkts | | |||
| out-multicast-pkts | ifHCOutMulticastPkts | | | out-multicast-pkts | ifHCOutMulticastPkts | | |||
| out-discards | ifOutDiscards | | | out-discards | ifOutDiscards | | |||
| out-errors | ifOutErrors | | | out-errors | ifOutErrors | | |||
+----------------------------------+------------------------+ | +----------------------------------+------------------------+ | |||
Mapping of YANG data nodes to IF-MIB objects | YANG data nodes and related IF-MIB objects | |||
5. Interfaces YANG Module | 5. Interfaces YANG Module | |||
This YANG module imports a typedef from | This YANG module imports typedefs from [I-D.ietf-netmod-rfc6021-bis] | |||
[I-D.ietf-netmod-iana-if-type]. | and [I-D.ietf-netmod-iana-if-type]. | |||
RFC Ed.: update the date below with the date of RFC publication and | RFC Ed.: update the date below with the date of RFC publication and | |||
remove this note. | remove this note. | |||
<CODE BEGINS> file "ietf-interfaces@2013-02-06.yang" | <CODE BEGINS> file "ietf-interfaces@2013-05-15.yang" | |||
module ietf-interfaces { | module ietf-interfaces { | |||
namespace "urn:ietf:params:xml:ns:yang:ietf-interfaces"; | namespace "urn:ietf:params:xml:ns:yang:ietf-interfaces"; | |||
prefix if; | prefix if; | |||
import ietf-yang-types { | import ietf-yang-types { | |||
prefix yang; | prefix yang; | |||
} | } | |||
import iana-if-type { | import iana-if-type { | |||
skipping to change at page 10, line 47 | skipping to change at page 11, line 47 | |||
WG Chair: Juergen Schoenwaelder | WG Chair: Juergen Schoenwaelder | |||
<mailto:j.schoenwaelder@jacobs-university.de> | <mailto:j.schoenwaelder@jacobs-university.de> | |||
Editor: Martin Bjorklund | Editor: Martin Bjorklund | |||
<mailto:mbj@tail-f.com>"; | <mailto:mbj@tail-f.com>"; | |||
description | description | |||
"This module contains a collection of YANG definitions for | "This module contains a collection of YANG definitions for | |||
managing network interfaces. | managing network interfaces. | |||
Copyright (c) 2012 IETF Trust and the persons identified as | Copyright (c) 2013 IETF Trust and the persons identified as | |||
authors of the code. All rights reserved. | authors of the code. All rights reserved. | |||
Redistribution and use in source and binary forms, with or | Redistribution and use in source and binary forms, with or | |||
without modification, is permitted pursuant to, and subject | without modification, is permitted pursuant to, and subject | |||
to the license terms contained in, the Simplified BSD License | to the license terms contained in, the Simplified BSD License | |||
set forth in Section 4.c of the IETF Trust's Legal Provisions | set forth in Section 4.c of the IETF Trust's Legal Provisions | |||
Relating to IETF Documents | Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info). | (http://trustee.ietf.org/license-info). | |||
This version of this YANG module is part of RFC XXXX; see | This version of this YANG module is part of RFC XXXX; see | |||
the RFC itself for full legal notices."; | the RFC itself for full legal notices."; | |||
// RFC Ed.: replace XXXX with actual RFC number and remove this | // RFC Ed.: replace XXXX with actual RFC number and remove this | |||
// note. | // note. | |||
// RFC Ed.: update the date below with the date of RFC publication | // RFC Ed.: update the date below with the date of RFC publication | |||
// and remove this note. | // and remove this note. | |||
revision 2013-02-06 { | revision 2013-05-15 { | |||
description | description | |||
"Initial revision."; | "Initial revision."; | |||
reference | reference | |||
"RFC XXXX: A YANG Data Model for Interface Management"; | "RFC XXXX: A YANG Data Model for Interface Management"; | |||
} | } | |||
/* Typedefs */ | /* Typedefs */ | |||
typedef interface-ref { | typedef interface-ref { | |||
type leafref { | type leafref { | |||
path "/if:interfaces/if:interface/if:name"; | path "/if:interfaces/if:interface/if:name"; | |||
} | } | |||
description | description | |||
"This type is used by data models that need to reference | "This type is used by data models that need to reference | |||
interfaces."; | configured interfaces."; | |||
} | ||||
typedef interface-state-ref { | ||||
type leafref { | ||||
path "/if:interfaces-state/if:interface/if:name"; | ||||
} | ||||
description | ||||
"This type is used by data models that need to reference | ||||
the operationally present interfaces."; | ||||
} | } | |||
/* Features */ | /* Features */ | |||
feature arbitrary-names { | feature arbitrary-names { | |||
description | description | |||
"This feature indicates that the server allows interfaces to | "This feature indicates that the device allows logical | |||
be named arbitrarily."; | interfaces to be named arbitrarily."; | |||
} | ||||
feature pre-provisioning { | ||||
description | ||||
"This feature indicates that the device supports | ||||
pre-provisioning of interface configuration, i.e., it is | ||||
possible to configure an interface whose physical interface | ||||
hardware is not present on the device."; | ||||
} | } | |||
feature if-mib { | feature if-mib { | |||
description | description | |||
"This feature indicates that the server implements IF-MIB."; | "This feature indicates that the device implements IF-MIB."; | |||
reference | reference | |||
"RFC 2863: The Interfaces Group MIB"; | "RFC 2863: The Interfaces Group MIB"; | |||
} | } | |||
/* Data nodes */ | /* Data nodes */ | |||
container interfaces { | container interfaces { | |||
description | description | |||
"Interface parameters."; | "Interface configuration parameters."; | |||
list interface { | list interface { | |||
key "name"; | key "name"; | |||
unique "type location"; | ||||
description | description | |||
"The list of interfaces on the device."; | "The list of configured interfaces on the device. | |||
leaf name { | The operational state of an interface is available in the | |||
/interfaces-state/interface list. If the configuration of a | ||||
physical interface cannot be used by the system (e.g., the | ||||
physical interface present is not matching the interface | ||||
type), then the configuration is not applied to the physical | ||||
interface shown in the /interfaces-state/interface list. If | ||||
the the configuration of a logical interface cannot be used | ||||
by the system, the configured interface is not instantiated | ||||
in the /interfaces-state/interface list."; | ||||
leaf name { | ||||
type string; | type string; | |||
description | description | |||
"The name of the interface. | "The name of the interface. | |||
A device MAY restrict the allowed values for this leaf, | A device MAY restrict the allowed values for this leaf, | |||
possibly depending on the type and location. | possibly depending on the type of the interface. | |||
If the device allows arbitrarily named interfaces, the | For physical interfaces, this leaf is the device-specific | |||
feature 'arbitrary-names' is advertised. | name of the interface. The 'config false' list | |||
/interfaces-state/interface contains the currently | ||||
existing interfaces on the device. | ||||
If a client tries to create configuration for a physical | ||||
interface that is not present, the server MAY reject the | ||||
request, if the implementation does not support | ||||
pre-provisioning of interfaces, or if the name refers to | ||||
an interface that can never exist in the system. | ||||
A NETCONF server MUST reply with an rpc-error with the | ||||
error-tag 'invalid-value' in this case. | ||||
If the device supports pre-provisioning of interface | ||||
configuration, the feature 'pre-provisioning' is | ||||
advertised. | ||||
If the device allows arbitrarily named logical interfaces, | ||||
the feature 'arbitrary-names' is advertised. | ||||
When a configured logical interface is created by the | ||||
system, it is instantiated in the | ||||
/interface-state/interface list. Since the name in that | ||||
list MAY be mapped to ifName by an implementation, such an | ||||
implementation MUST restrict the allowed values for this | ||||
leaf so that it matches the restrictions of ifName. | ||||
This leaf MAY be mapped to ifName by an implementation. | ||||
Such an implementation MAY restrict the allowed values for | ||||
this leaf so that it matches the restrictions of ifName. | ||||
If a NETCONF server that implements this restriction is | If a NETCONF server that implements this restriction is | |||
sent a value that doesn't match the restriction, it MUST | sent a value that doesn't match the restriction, it MUST | |||
reply with an rpc-error with the error-tag | reply with an rpc-error with the error-tag | |||
'invalid-value'."; | 'invalid-value'."; | |||
reference | ||||
"RFC 2863: The Interfaces Group MIB - ifName"; | ||||
} | } | |||
leaf description { | leaf description { | |||
type string; | type string; | |||
description | description | |||
"A textual description of the interface. | "A textual description of the interface. | |||
This leaf MAY be mapped to ifAlias by an implementation. | This leaf MAY be mapped to ifAlias by an implementation. | |||
Such an implementation MAY restrict the allowed values for | Such an implementation MUST restrict the allowed values | |||
this leaf so that it matches the restrictions of ifAlias. | for this leaf so that it matches the restrictions of | |||
ifAlias. | ||||
If a NETCONF server that implements this restriction is | If a NETCONF server that implements this restriction is | |||
sent a value that doesn't match the restriction, it MUST | sent a value that doesn't match the restriction, it MUST | |||
reply with an rpc-error with the error-tag | reply with an rpc-error with the error-tag | |||
'invalid-value'."; | 'invalid-value'. | |||
Since ifAlias is defined to be stored in non-volatile | ||||
storage, the SNMP implementation MUST map ifAlias to the | ||||
value of 'description' in the persistently stored | ||||
datastore. | ||||
Specifically, if the device supports ':startup', when | ||||
ifAlias is read the device MUST return the value of | ||||
'description' in the 'startup' datastore, and when it is | ||||
written, it MUST be written to the 'running' and 'startup' | ||||
datastores. Note that it is up to the implementation if | ||||
it modifies this single leaf in 'startup', or if it | ||||
performs an implicit copy-config from 'running' to | ||||
'startup'. | ||||
If the device does not support ':startup', ifAlias MUST | ||||
be mapped to the 'description' leaf in the 'running' | ||||
datastore."; | ||||
reference | reference | |||
"RFC 2863: The Interfaces Group MIB - ifAlias"; | "RFC 2863: The Interfaces Group MIB - ifAlias"; | |||
} | } | |||
leaf type { | leaf type { | |||
type ianaift:iana-if-type; | type ianaift:iana-if-type; | |||
mandatory true; | mandatory true; | |||
description | description | |||
"The type of the interface. | "The type of the interface. | |||
When an interface entry is created, a server MAY | When an interface entry is created, a server MAY | |||
initialize the type leaf with a valid value, e.g., if it | initialize the type leaf with a valid value, e.g., if it | |||
is possible to derive the type from the name of the | is possible to derive the type from the name of the | |||
interface."; | interface. | |||
If a client tries to set the type of an interface to a | ||||
value that can never be used by the system, e.g., if the | ||||
type is not supported or if the type does not match the | ||||
name of the interface, the server MUST reject the request. | ||||
A NETCONF server MUST reply with an rpc-error with the | ||||
error-tag 'invalid-value' in this case."; | ||||
reference | reference | |||
"RFC 2863: The Interfaces Group MIB - ifType"; | "RFC 2863: The Interfaces Group MIB - ifType"; | |||
} | } | |||
leaf location { | leaf enabled { | |||
type boolean; | ||||
default "true"; | ||||
description | ||||
"This leaf contains the configured, desired state of the | ||||
interface. | ||||
Systems that implement the IF-MIB use the value of this | ||||
leaf in the 'running' datastore to set | ||||
IF-MIB.ifAdminStatus to 'up' or 'down' after an ifEntry | ||||
has been initialized, as described in RFC 2863. | ||||
Changes in this leaf in the 'running' datastore are | ||||
reflected in ifAdminStatus, but if ifAdminStatus is | ||||
changed over SNMP, this leaf is not affected."; | ||||
reference | ||||
"RFC 2863: The Interfaces Group MIB - ifAdminStatus"; | ||||
} | ||||
leaf link-up-down-trap-enable { | ||||
if-feature if-mib; | ||||
type enumeration { | ||||
enum enabled { | ||||
value 1; | ||||
} | ||||
enum disabled { | ||||
value 2; | ||||
} | ||||
} | ||||
description | ||||
"Controls whether linkUp/linkDown SNMP notifications | ||||
should be generated for this interface. | ||||
If this node is not configured, the value 'enabled' is | ||||
operationally used by the server for interfaces which do | ||||
not operate on top of any other interface (i.e., there are | ||||
no 'lower-layer-if' entries), and 'disabled' otherwise."; | ||||
reference | ||||
"RFC 2863: The Interfaces Group MIB - | ||||
ifLinkUpDownTrapEnable"; | ||||
} | ||||
} | ||||
} | ||||
container interfaces-state { | ||||
config false; | ||||
description | ||||
"Data nodes for the operational state of interfaces."; | ||||
list interface { | ||||
key "name"; | ||||
description | ||||
"The list of interfaces on the device. | ||||
Physical interfaces detected by the system are always | ||||
present in this list, if they are configured or not."; | ||||
leaf name { | ||||
type string; | type string; | |||
description | description | |||
"The device-specific location of the interface of a | "The name of the interface. | |||
particular type. The format of the location string | ||||
depends on the interface type and the device. If a | ||||
NETCONF server is sent a value that doesn't match this | ||||
format, it MUST reply with an rpc-error with the error-tag | ||||
'invalid-value'. | ||||
If the interface's type represents a physical interface, | This leaf MAY be mapped to ifName by an implementation. | |||
this leaf MUST be set. | Such an implementation MUST restrict the values | |||
for this leaf so that it matches the restrictions of | ||||
ifName."; | ||||
reference | ||||
"RFC 2863: The Interfaces Group MIB - ifName"; | ||||
} | ||||
When an interface entry is created, a server MAY | leaf type { | |||
initialize the location leaf with a valid value, e.g., if | type ianaift:iana-if-type; | |||
it is possible to derive the location from the name of | mandatory true; | |||
the interface."; | description | |||
"The type of the interface."; | ||||
reference | ||||
"RFC 2863: The Interfaces Group MIB - ifType"; | ||||
} | } | |||
leaf enabled { | leaf admin-status { | |||
type boolean; | if-feature if-mib; | |||
default "true"; | type enumeration { | |||
enum up { | ||||
value 1; | ||||
description | ||||
"Ready to pass packets."; | ||||
} | ||||
enum down { | ||||
value 2; | ||||
description | ||||
"Not ready to pass packets and not in some test mode."; | ||||
} | ||||
enum testing { | ||||
value 3; | ||||
description | ||||
"In some test mode."; | ||||
} | ||||
} | ||||
mandatory true; | ||||
description | description | |||
"The desired state of the interface. | "The desired state of the interface. | |||
This leaf contains the configured, desired state of the | This leaf has the same semantics as ifAdminStatus."; | |||
interface. Systems that implement the IF-MIB use the | ||||
value of this leaf to set IF-MIB.ifAdminStatus to 'up' or | ||||
'down' after an ifEntry has been initialized, as described | ||||
in RFC 2863."; | ||||
reference | reference | |||
"RFC 2863: The Interfaces Group MIB - ifAdminStatus"; | "RFC 2863: The Interfaces Group MIB - ifAdminStatus"; | |||
} | } | |||
leaf oper-status { | leaf oper-status { | |||
type enumeration { | type enumeration { | |||
enum up { | enum up { | |||
value 1; | value 1; | |||
description | description | |||
"Ready to pass packets."; | "Ready to pass packets."; | |||
} | } | |||
skipping to change at page 14, line 43 | skipping to change at page 18, line 43 | |||
value 6; | value 6; | |||
description | description | |||
"Some component (typically hardware) is missing."; | "Some component (typically hardware) is missing."; | |||
} | } | |||
enum lower-layer-down { | enum lower-layer-down { | |||
value 7; | value 7; | |||
description | description | |||
"Down due to state of lower-layer interface(s)."; | "Down due to state of lower-layer interface(s)."; | |||
} | } | |||
} | } | |||
config false; | mandatory true; | |||
description | description | |||
"The current operational state of the interface. | "The current operational state of the interface. | |||
If 'enabled' is 'false' then 'oper-status' | This leaf has the same semantics as ifOperStatus."; | |||
should be 'down'. If 'enabled' is changed to 'true' | ||||
then 'oper-status' should change to 'up' if the interface | ||||
is ready to transmit and receive network traffic; it | ||||
should change to 'dormant' if the interface is waiting for | ||||
external actions (such as a serial line waiting for an | ||||
incoming connection); it should remain in the 'down' state | ||||
if and only if there is a fault that prevents it from | ||||
going to the 'up' state; it should remain in the | ||||
'not-present' state if the interface has missing | ||||
(typically, hardware) components."; | ||||
reference | reference | |||
"RFC 2863: The Interfaces Group MIB - ifOperStatus"; | "RFC 2863: The Interfaces Group MIB - ifOperStatus"; | |||
} | } | |||
leaf last-change { | leaf last-change { | |||
type yang:date-and-time; | type yang:date-and-time; | |||
config false; | ||||
description | description | |||
"The time the interface entered its current operational | "The time the interface entered its current operational | |||
state. If the current state was entered prior to the | state. If the current state was entered prior to the | |||
last re-initialization of the local network management | last re-initialization of the local network management | |||
subsystem, then this node is not present."; | subsystem, then this node is not present."; | |||
reference | reference | |||
"RFC 2863: The Interfaces Group MIB - ifLastChange"; | "RFC 2863: The Interfaces Group MIB - ifLastChange"; | |||
} | } | |||
leaf if-index { | leaf if-index { | |||
if-feature if-mib; | if-feature if-mib; | |||
type int32 { | type int32 { | |||
range "1..2147483647"; | range "1..2147483647"; | |||
} | } | |||
config false; | mandatory true; | |||
description | description | |||
"The ifIndex value for the ifEntry represented by this | "The ifIndex value for the ifEntry represented by this | |||
interface. | interface."; | |||
Media-specific modules must specify how the type is | ||||
mapped to entries in the ifTable."; | ||||
reference | reference | |||
"RFC 2863: The Interfaces Group MIB - ifIndex"; | "RFC 2863: The Interfaces Group MIB - ifIndex"; | |||
} | } | |||
leaf link-up-down-trap-enable { | ||||
if-feature if-mib; | ||||
type enumeration { | ||||
enum enabled { | ||||
value 1; | ||||
} | ||||
enum disabled { | ||||
value 2; | ||||
} | ||||
} | ||||
description | ||||
"Indicates whether linkUp/linkDown SNMP notifications | ||||
should be generated for this interface. | ||||
If this node is not configured, the value 'enabled' is | ||||
operationally used by the server for interfaces which do | ||||
not operate on top of any other interface (i.e., there are | ||||
no 'lower-layer-if' entries), and 'disabled' otherwise."; | ||||
reference | ||||
"RFC 2863: The Interfaces Group MIB - | ||||
ifLinkUpDownTrapEnable"; | ||||
} | ||||
leaf phys-address { | leaf phys-address { | |||
type yang:phys-address; | type yang:phys-address; | |||
config false; | ||||
description | description | |||
"The interface's address at its protocol sub-layer. For | "The interface's address at its protocol sub-layer. For | |||
example, for an 802.x interface, this object normally | example, for an 802.x interface, this object normally | |||
contains a MAC address. The interface's media-specific | contains a MAC address. The interface's media-specific | |||
modules must define the bit and byte ordering and the | modules must define the bit and byte ordering and the | |||
format of the value of this object. For interfaces that do | format of the value of this object. For interfaces that do | |||
not have such an address (e.g., a serial line), this node | not have such an address (e.g., a serial line), this node | |||
is not present."; | is not present."; | |||
reference | reference | |||
"RFC 2863: The Interfaces Group MIB - ifPhysAddress"; | "RFC 2863: The Interfaces Group MIB - ifPhysAddress"; | |||
} | } | |||
leaf-list higher-layer-if { | leaf-list higher-layer-if { | |||
type interface-ref; | type interface-state-ref; | |||
config false; | ||||
description | description | |||
"A list of references to interfaces layered on top of this | "A list of references to interfaces layered on top of this | |||
interface."; | interface."; | |||
reference | reference | |||
"RFC 2863: The Interfaces Group MIB - ifStackTable"; | "RFC 2863: The Interfaces Group MIB - ifStackTable"; | |||
} | } | |||
leaf-list lower-layer-if { | leaf-list lower-layer-if { | |||
type interface-ref; | type interface-state-ref; | |||
config false; | ||||
description | description | |||
"A list of references to interfaces layered underneath this | "A list of references to interfaces layered underneath this | |||
interface."; | interface."; | |||
reference | reference | |||
"RFC 2863: The Interfaces Group MIB - ifStackTable"; | "RFC 2863: The Interfaces Group MIB - ifStackTable"; | |||
} | } | |||
leaf speed { | leaf speed { | |||
type yang:gauge64; | type yang:gauge64; | |||
units "bits / second"; | units "bits / second"; | |||
config false; | ||||
description | description | |||
"An estimate of the interface's current bandwidth in bits | "An estimate of the interface's current bandwidth in bits | |||
per second. For interfaces which do not vary in | per second. For interfaces that do not vary in | |||
bandwidth or for those where no accurate estimation can | bandwidth or for those where no accurate estimation can | |||
be made, this node should contain the nominal bandwidth. | be made, this node should contain the nominal bandwidth. | |||
For interfaces that has no concept of bandwidth, this | For interfaces that have no concept of bandwidth, this | |||
node is not present."; | node is not present."; | |||
reference | reference | |||
"RFC 2863: The Interfaces Group MIB - | "RFC 2863: The Interfaces Group MIB - | |||
ifSpeed, ifHighSpeed"; | ifSpeed, ifHighSpeed"; | |||
} | } | |||
container statistics { | container statistics { | |||
config false; | ||||
description | description | |||
"A collection of interface-related statistics objects."; | "A collection of interface-related statistics objects."; | |||
leaf discontinuity-time { | leaf discontinuity-time { | |||
type yang:date-and-time; | type yang:date-and-time; | |||
mandatory true; | ||||
description | description | |||
"The time on the most recent occasion at which any one or | "The time on the most recent occasion at which any one or | |||
more of this interface's counters suffered a | more of this interface's counters suffered a | |||
discontinuity. If no such discontinuities have occurred | discontinuity. If no such discontinuities have occurred | |||
since the last re-initialization of the local management | since the last re-initialization of the local management | |||
subsystem, then this node contains the time the local | subsystem, then this node contains the time the local | |||
management subsystem re-initialized itself."; | management subsystem re-initialized itself."; | |||
} | } | |||
leaf in-octets { | leaf in-octets { | |||
skipping to change at page 24, line 10 | skipping to change at page 27, line 10 | |||
name: ietf-interfaces | name: ietf-interfaces | |||
namespace: urn:ietf:params:xml:ns:yang:ietf-interfaces | namespace: urn:ietf:params:xml:ns:yang:ietf-interfaces | |||
prefix: if | prefix: if | |||
reference: RFC XXXX | reference: RFC XXXX | |||
7. Security Considerations | 7. Security Considerations | |||
The YANG module defined in this memo is designed to be accessed via | The YANG module defined in this memo is designed to be accessed via | |||
the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the | the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the | |||
secure transport layer and the mandatory-to-implement secure | secure transport layer and the mandatory-to-implement secure | |||
transport is SSH [RFC6242]. | transport is SSH [RFC6242]. The NETCONF access control model | |||
[RFC6536] provides the means to restrict access for particular | ||||
NETCONF users to a pre-configured subset of all available NETCONF | ||||
protocol operations and content. | ||||
There are a number of data nodes defined in the YANG module which are | There are a number of data nodes defined in the YANG module which are | |||
writable/creatable/deletable (i.e., config true, which is the | writable/creatable/deletable (i.e., config true, which is the | |||
default). These data nodes may be considered sensitive or vulnerable | default). These data nodes may be considered sensitive or vulnerable | |||
in some network environments. Write operations (e.g., <edit-config>) | in some network environments. Write operations (e.g., <edit-config>) | |||
to these data nodes without proper protection can have a negative | to these data nodes without proper protection can have a negative | |||
effect on network operations. These are the subtrees and data nodes | effect on network operations. These are the subtrees and data nodes | |||
and their sensitivity/vulnerability: | and their sensitivity/vulnerability: | |||
/interfaces/interface: This list specifies the configured interfaces | /interfaces/interface: This list specifies the configured interfaces | |||
skipping to change at page 26, line 11 | skipping to change at page 29, line 11 | |||
The author wishes to thank Alexander Clemm, Per Hedeland, Ladislav | The author wishes to thank Alexander Clemm, Per Hedeland, Ladislav | |||
Lhotka, and Juergen Schoenwaelder for their helpful comments. | Lhotka, and Juergen Schoenwaelder for their helpful comments. | |||
9. References | 9. References | |||
9.1. Normative References | 9.1. Normative References | |||
[I-D.ietf-netmod-iana-if-type] | [I-D.ietf-netmod-iana-if-type] | |||
Bjorklund, M., "IANA Interface Type and Address Family | Bjorklund, M., "IANA Interface Type and Address Family | |||
YANG Modules", draft-ietf-netmod-iana-if-type-02 (work in | YANG Modules", draft-ietf-netmod-iana-if-type-06 (work in | |||
progress), April 2012. | progress), April 2013. | |||
[I-D.ietf-netmod-rfc6021-bis] | ||||
Schoenwaelder, J., "Common YANG Data Types", | ||||
draft-ietf-netmod-rfc6021-bis-02 (work in progress), | ||||
May 2013. | ||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group | [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group | |||
MIB", RFC 2863, June 2000. | MIB", RFC 2863, June 2000. | |||
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, | [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, | |||
January 2004. | January 2004. | |||
skipping to change at page 27, line 5 | skipping to change at page 29, line 45 | |||
Schoenwaelder, Ed., "Textual Conventions for SMIv2", | Schoenwaelder, Ed., "Textual Conventions for SMIv2", | |||
STD 58, RFC 2579, April 1999. | STD 58, RFC 2579, April 1999. | |||
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. | [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. | |||
Bierman, "Network Configuration Protocol (NETCONF)", | Bierman, "Network Configuration Protocol (NETCONF)", | |||
RFC 6241, June 2011. | RFC 6241, June 2011. | |||
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure | [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure | |||
Shell (SSH)", RFC 6242, June 2011. | Shell (SSH)", RFC 6242, June 2011. | |||
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration | ||||
Protocol (NETCONF) Access Control Model", RFC 6536, | ||||
March 2012. | ||||
Appendix A. Example: Ethernet Interface Module | Appendix A. Example: Ethernet Interface Module | |||
This section gives a simple example of how an Ethernet interface | This section gives a simple example of how an Ethernet interface | |||
module could be defined. It demonstrates how media-specific | module could be defined. It demonstrates how media-specific | |||
configuration parameters can be conditionally augmented to the | configuration parameters can be conditionally augmented to the | |||
generic interface list. It is not intended as a complete module for | generic interface list. It also shows how operational state | |||
parameters can be conditionally augmented to the operational | ||||
interface list. The example is not intended as a complete module for | ||||
ethernet configuration. | ethernet configuration. | |||
module ex-ethernet { | module ex-ethernet { | |||
namespace "http://example.com/ethernet"; | namespace "http://example.com/ethernet"; | |||
prefix "eth"; | prefix "eth"; | |||
import ietf-interfaces { | import ietf-interfaces { | |||
prefix if; | prefix if; | |||
} | } | |||
// configuration parameters for ethernet interfaces | ||||
augment "/if:interfaces/if:interface" { | augment "/if:interfaces/if:interface" { | |||
when "if:type = 'ethernetCsmacd'"; | when "if:type = 'ethernetCsmacd'"; | |||
container ethernet { | container ethernet { | |||
must "../if:location" { | ||||
description | ||||
"An ethernet interface must specify the physical location | ||||
of the ethernet hardware."; | ||||
} | ||||
choice transmission-params { | choice transmission-params { | |||
case auto { | case auto { | |||
leaf auto-negotiate { | leaf auto-negotiate { | |||
type empty; | type empty; | |||
} | } | |||
} | } | |||
case manual { | case manual { | |||
leaf duplex { | leaf duplex { | |||
type enumeration { | type enumeration { | |||
enum "half"; | enum "half"; | |||
skipping to change at page 28, line 47 | skipping to change at page 31, line 4 | |||
enum "10Mb"; | enum "10Mb"; | |||
enum "100Mb"; | enum "100Mb"; | |||
enum "1Gb"; | enum "1Gb"; | |||
enum "10Gb"; | enum "10Gb"; | |||
} | } | |||
} | } | |||
} | } | |||
} | } | |||
// other ethernet specific params... | // other ethernet specific params... | |||
} | } | |||
} | ||||
// operational state parameters for ethernet interfaces | ||||
augment "/if:interfaces-state/if:interface" { | ||||
when "if:type = 'ethernetCsmacd'"; | ||||
container ethernet { | ||||
leaf duplex { | ||||
type enumeration { | ||||
enum "half"; | ||||
enum "full"; | ||||
} | ||||
} | ||||
// other ethernet specific params... | ||||
} | ||||
} | } | |||
} | } | |||
Appendix B. Example: Ethernet Bonding Interface Module | Appendix B. Example: Ethernet Bonding Interface Module | |||
This section gives an example of how interface layering can be | This section gives an example of how interface layering can be | |||
defined. An ethernet bonding interface is defined, which bonds | defined. An ethernet bonding interface is defined, which bonds | |||
several ethernet interfaces into one logical interface. | several ethernet interfaces into one logical interface. | |||
module ex-ethernet-bonding { | module ex-ethernet-bonding { | |||
skipping to change at page 31, line 10 | skipping to change at page 34, line 10 | |||
} | } | |||
} | } | |||
} | } | |||
} | } | |||
Appendix D. Example: NETCONF <get> reply | Appendix D. Example: NETCONF <get> reply | |||
This section gives an example of a reply to the NETCONF <get> request | This section gives an example of a reply to the NETCONF <get> request | |||
for a device that implements the example data models above. | for a device that implements the example data models above. | |||
<rpc-reply | <rpc-reply | |||
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" | xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" | |||
message-id="101"> | message-id="101"> | |||
<data> | <data> | |||
<interfaces | ||||
xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces" | <interfaces | |||
xmlns:vlan="http://example.com/vlan"> | xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces" | |||
<interface> | xmlns:vlan="http://example.com/vlan"> | |||
<name>eth0</name> | ||||
<type>ethernetCsmacd</type> | <interface> | |||
<location>0</location> | <name>eth0</name> | |||
<enabled>true</enabled> | <type>ethernetCsmacd</type> | |||
<if-index>2</if-index> | <enabled>false</enabled> | |||
</interface> | </interface> | |||
<interface> | ||||
<name>eth1</name> | <interface> | |||
<type>ethernetCsmacd</type> | <name>eth1</name> | |||
<location>1</location> | <type>ethernetCsmacd</type> | |||
<enabled>true</enabled> | <enabled>true</enabled> | |||
<if-index>7</if-index> | <vlan:vlan-tagging>true</vlan:vlan-tagging> | |||
<vlan:vlan-tagging>true</vlan:vlan-tagging> | </interface> | |||
</interface> | ||||
<interface> | <interface> | |||
<name>eth1.10</name> | <name>eth1.10</name> | |||
<type>l2vlan</type> | <type>l2vlan</type> | |||
<enabled>true</enabled> | <enabled>true</enabled> | |||
<if-index>9</if-index> | <vlan:base-interface>eth1</vlan:base-interface> | |||
<vlan:base-interface>eth1</vlan:base-interface> | <vlan:vlan-id>10</vlan:vlan-id> | |||
<vlan:vlan-id>10</vlan:vlan-id> | </interface> | |||
</interface> | ||||
</interfaces> | <interface> | |||
</data> | <name>lo1</name> | |||
</rpc-reply> | <type>softwareLoopback</type> | |||
<enabled>true</enabled> | ||||
</interface> | ||||
</interfaces> | ||||
<interfaces-state | ||||
xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"> | ||||
<interface> | ||||
<name>eth0</name> | ||||
<type>ethernetCsmacd</type> | ||||
<admin-status>down</admin-status> | ||||
<oper-status>down</oper-status> | ||||
<if-index>2</if-index> | ||||
<phys-address>00:01:02:03:04:05</phys-address> | ||||
<statistics> | ||||
<discontinuity-time>2013-04-01T03:00:00Z</discontinuity-time> | ||||
<!-- counters now shown here --> | ||||
</statistics> | ||||
</interface> | ||||
<interface> | ||||
<name>eth1</name> | ||||
<type>ethernetCsmacd</type> | ||||
<admin-status>up</admin-status> | ||||
<oper-status>up</oper-status> | ||||
<if-index>7</if-index> | ||||
<phys-address>00:01:02:03:04:06</phys-address> | ||||
<higher-layer-if>eth1.10</higher-layer-if> | ||||
<statistics> | ||||
<discontinuity-time>2013-04-01T03:00:00Z</discontinuity-time> | ||||
<!-- counters now shown here --> | ||||
</statistics> | ||||
</interface> | ||||
<interface> | ||||
<name>eth1.10</name> | ||||
<type>l2vlan</type> | ||||
<admin-status>up</admin-status> | ||||
<oper-status>up</oper-status> | ||||
<if-index>9</if-index> | ||||
<lower-layer-if>eth1</lower-layer-if> | ||||
<statistics> | ||||
<discontinuity-time>2013-04-01T03:00:00Z</discontinuity-time> | ||||
<!-- counters now shown here --> | ||||
</statistics> | ||||
</interface> | ||||
<!-- This interface is not configured --> | ||||
<interface> | ||||
<name>eth2</name> | ||||
<type>ethernetCsmacd</type> | ||||
<admin-status>down</admin-status> | ||||
<oper-status>down</oper-status> | ||||
<if-index>8</if-index> | ||||
<phys-address>00:01:02:03:04:07</phys-address> | ||||
<statistics> | ||||
<discontinuity-time>2013-04-01T03:00:00Z</discontinuity-time> | ||||
<!-- counters now shown here --> | ||||
</statistics> | ||||
</interface> | ||||
<interface> | ||||
<name>lo1</name> | ||||
<type>softwareLoopback</type> | ||||
<admin-status>up</admin-status> | ||||
<oper-status>up</oper-status> | ||||
<if-index>1</if-index> | ||||
<statistics> | ||||
<discontinuity-time>2013-04-01T03:00:00Z</discontinuity-time> | ||||
<!-- counters now shown here --> | ||||
</statistics> | ||||
</interface> | ||||
</interfaces-state> | ||||
</data> | ||||
</rpc-reply> | ||||
Appendix E. Examples: Interface Naming Schemes | Appendix E. Examples: Interface Naming Schemes | |||
This section gives examples of some implementation strategies. | This section gives examples of some implementation strategies. | |||
The examples make use of the example data model "ex-vlan" (see | ||||
Appendix C) to show how logical interfaces can be configured. | ||||
E.1. Router with Restricted Interface Names | E.1. Router with Restricted Interface Names | |||
In this example, a router has support for 4 line cards, each with 8 | In this example, a router has support for 4 line cards, each with 8 | |||
ports. The slots for the cards are physically numbered from 0 to 3, | 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 | and the ports on each card from 0 to 7. Each card has fast- or | |||
gigabit-ethernet ports. | gigabit-ethernet ports. | |||
The implementation restricts the names of the interfaces to one of | The device-specific names for these physical interfaces are | |||
"fastethernet-N/M" or "gigabitethernet-N/M". The "location" of an | "fastethernet-N/M" or "gigabitethernet-N/M". | |||
interface is a string on the form "N/M". The implementation auto- | ||||
initializes the values for "type" and "location" based on the | The name of a vlan interface is restricted to the form | |||
"<physical-interface-name>.<subinterface-number>". | ||||
It is assumed that the operator is aware of this naming scheme. The | ||||
implementation auto-initializes the value for "type" based on the | ||||
interface name. | interface name. | |||
The NETCONF server does not advertise the 'arbitrary-names' feature | The NETCONF server does not advertise the 'arbitrary-names' feature | |||
in the <hello> message. | in the <hello> message. | |||
An operator can configure a new interface by sending an <edit-config> | An operator can configure a physical interface by sending an | |||
containing: | <edit-config> containing: | |||
<interface nc:operation="create"> | <interface nc:operation="create"> | |||
<name>fastethernet-1/0</name> | <name>fastethernet-1/0</name> | |||
</interface> | </interface> | |||
When the server processes this request, it will set the leaf "type" | When the server processes this request, it will set the leaf "type" | |||
to "ethernetCsmacd" and "location" to "1/0". Thus, if the client | to "ethernetCsmacd". Thus, if the client performs a <get-config> | |||
performs a <get-config> right after the <edit-config> above, it will | right after the <edit-config> above, it will get: | |||
get: | ||||
<interface> | <interface> | |||
<name>fastethernet-1/0</name> | <name>fastethernet-1/0</name> | |||
<type>ethernetCsmacd</type> | <type>ethernetCsmacd</type> | |||
<location>1/0</location> | ||||
</interface> | </interface> | |||
If the client tries to change the location of this interface with an | The client can configure a vlan interface by sending an <edit-config> | |||
<edit-config> containing: | containing: | |||
<interface nc:operation="create"> | ||||
<name>fastethernet-1/0.10005</name> | ||||
<type>l2-vlan</type> | ||||
<vlan:base-interface>fastethernet-1/0</vlan:base-interface> | ||||
<vlan:vlan-id>5</vlan:vlan-id> | ||||
</interface> | ||||
If the client tries to change the type of the physical interface with | ||||
an <edit-config> containing: | ||||
<interface nc:operation="merge"> | <interface nc:operation="merge"> | |||
<name>fastethernet-1/0</name> | <name>fastethernet-1/0</name> | |||
<location>1/1</location> | <type>tunnel</type> | |||
</interface> | </interface> | |||
then the server will reply with an "invalid-value" error, since the | then the server will reply with an "invalid-value" error, since the | |||
new location does not match the name. | new type does not match the name. | |||
E.2. Router with Arbitrary Interface Names | E.2. Router with Arbitrary Interface Names | |||
In this example, a router has support for 4 line cards, each with 8 | In this example, a router has support for 4 line cards, each with 8 | |||
ports. The slots for the cards are physically numbered from 0 to 3, | 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 | and the ports on each card from 0 to 7. Each card has fast- or | |||
gigabit-ethernet ports. | gigabit-ethernet ports. | |||
The implementation does not restrict the interface names. This | The device-specific names for these physical interfaces are | |||
allows to more easily apply the interface configuration to a | "fastethernet-N/M" or "gigabitethernet-N/M". | |||
different physical interface. However, the additional level of | ||||
indirection also makes it a bit more complex to map interface names | The implementation does not restrict the logical interface names. | |||
found in other protocols to configuration entries. The "location" of | This allows to more easily apply the interface configuration to a | |||
an interface is a string on the form "N/M". | different 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 | The NETCONF server advertises the 'arbitrary-names' feature in the | |||
<hello> message. | <hello> message. | |||
An operator can configure a new interface by sending an <edit-config> | Physical interfaces are configured as in Appendix E.1. | |||
containing: | ||||
An operator can configure a logical interface by sending an | ||||
<edit-config> containing: | ||||
<interface nc:operation="create"> | <interface nc:operation="create"> | |||
<name>acme-interface</name> | <name>acme-interface</name> | |||
<type>ethernetCsmacd</type> | <type>l2-vlan</type> | |||
<location>1/0</location> | <vlan:base-interface>fastethernet-1/0</vlan:base-interface> | |||
<vlan:vlan-id>5</vlan:vlan-id> | ||||
</interface> | </interface> | |||
If necessary, the operator can move the configuration named | If necessary, the operator can move the configuration named | |||
"acme-interface" over to a different physical interface with an | "acme-interface" over to a different physical interface with an | |||
<edit-config> containing: | <edit-config> containing: | |||
<interface nc:operation="merge"> | <interface nc:operation="merge"> | |||
<name>acme-interface</name> | <name>acme-interface</name> | |||
<location>2/4</location> | <vlan:base-interface>fastethernet-1/1</vlan:base-interface> | |||
</interface> | </interface> | |||
E.3. Ethernet Switch with Restricted Interface Names | E.3. Ethernet Switch with Restricted Interface Names | |||
In this example, an ethernet switch has a number of ports, each port | In this example, an ethernet switch has a number of ports, each port | |||
identified by a simple port number. | identified by a simple port number. | |||
The implementation restricts the interface names to numbers that | The device-specific names for the physical interfaces are numbers | |||
match the physical port number. | that match the physical port number. | |||
The NETCONF server does not advertise the 'arbitrary-names' feature | ||||
in the <hello> message. | ||||
An operator can configure a new interface by sending an <edit-config> | An operator can configure a physical interface by sending an | |||
containing: | <edit-config> containing: | |||
<interface nc:operation="create"> | <interface nc:operation="create"> | |||
<name>6</name> | <name>6</name> | |||
</interface> | </interface> | |||
When the server processes this request, it will set the leaf "type" | When the server processes this request, it will set the leaf "type" | |||
to "ethernetCsmacd" and "location" to "6". Thus, if the client | to "ethernetCsmacd". Thus, if the client performs a <get-config> | |||
performs a <get-config> right after the <edit-config> above, it will | right after the <edit-config> above, it will get: | |||
get: | ||||
<interface> | <interface> | |||
<name>6</name> | <name>6</name> | |||
<type>ethernetCsmacd</type> | <type>ethernetCsmacd</type> | |||
<location>6</location> | ||||
</interface> | </interface> | |||
If the client tries to change the location of this interface with an | ||||
<edit-config> containing: | ||||
<interface nc:operation="merge"> | ||||
<name>6</name> | ||||
<location>5</location> | ||||
</interface> | ||||
then the server will reply with an "invalid-value" error, since the | ||||
new location does not match the name. | ||||
E.4. Generic Host with Restricted Interface Names | E.4. Generic Host with Restricted Interface Names | |||
In this example, a generic host has interfaces named by the kernel | In this example, a generic host has interfaces named by the kernel. | |||
and without easily usable location information. The system | The system identifies the physical interface by the name assigned by | |||
identifies the physical interface by the name assigned by the | the operating system to the interface. | |||
operating system to the interface. | ||||
The implementation restricts the interface name to the operating | The name of a vlan interface is restricted to the form | |||
system level name of the physical interface. | "<physical-interface-name>:<vlan-number>". | |||
The NETCONF server does not advertise the 'arbitrary-names' feature | The NETCONF server does not advertise the 'arbitrary-names' feature | |||
in the <hello> message. | in the <hello> message. | |||
An operator can configure a new interface by sending an <edit-config> | An operator can configure an interface by sending an <edit-config> | |||
containing: | containing: | |||
<interface nc:operation="create"> | <interface nc:operation="create"> | |||
<name>eth8</name> | <name>eth8</name> | |||
</interface> | </interface> | |||
When the server processes this request, it will set the leaf "type" | When the server processes this request, it will set the leaf "type" | |||
to "ethernetCsmacd" and "location" to "eth8". Thus, if the client | to "ethernetCsmacd". Thus, if the client performs a <get-config> | |||
performs a <get-config> right after the <edit-config> above, it will | right after the <edit-config> above, it will get: | |||
get: | ||||
<interface> | <interface> | |||
<name>eth8</name> | <name>eth8</name> | |||
<type>ethernetCsmacd</type> | <type>ethernetCsmacd</type> | |||
<location>eth8</location> | ||||
</interface> | </interface> | |||
If the client tries to change the location of this interface with an | The client can configure a vlan interface by sending an <edit-config> | |||
<edit-config> containing: | containing: | |||
<interface nc:operation="merge"> | <interface nc:operation="create"> | |||
<name>eth8</name> | <name>eth8:5</name> | |||
<location>eth7</location> | <type>l2-vlan</type> | |||
<vlan:base-interface>eth8</vlan:base-interface> | ||||
<vlan:vlan-id>5</vlan:vlan-id> | ||||
</interface> | </interface> | |||
then the server will reply with an "invalid-value" error, since the | ||||
new location does not match the name. | ||||
E.5. Generic Host with Arbitrary Interface Names | E.5. Generic Host with Arbitrary Interface Names | |||
In this example, a generic host has interfaces named by the kernel | In this example, a generic host has interfaces named by the kernel. | |||
and without easily usable location information. The system | The system identifies the physical interface by the name assigned by | |||
identifies the physical interface by the name assigned by the | the operating system to the interface. | |||
operating system to the interface. | ||||
The implementation does not restrict the interface name to the | The implementation does not restrict the logical interface names. | |||
operating system level name of the physical interface. This allows | This allows to more easily apply the interface configuration to a | |||
to more easily apply the interface configuration to a different | different interface. However, the additional level of indirection | |||
physical interface. However, the additional level of indirection | ||||
also makes it a bit more complex to map interface names found in | also makes it a bit more complex to map interface names found in | |||
other protocols to configuration entries. | other protocols to configuration entries. | |||
The NETCONF server advertises the 'arbitrary-names' feature in the | The NETCONF server advertises the 'arbitrary-names' feature in the | |||
<hello> message. | <hello> message. | |||
An operator can configure a new interface by sending an <edit-config> | Physical interfaces are configured as in Appendix E.4. | |||
containing: | ||||
An operator can configure a logical interface by sending an | ||||
<edit-config> containing: | ||||
<interface nc:operation="create"> | <interface nc:operation="create"> | |||
<name>acme-interface</name> | <name>acme-interface</name> | |||
<type>ethernetCsmacd</type> | <type>l2-vlan</type> | |||
<location>eth4</location> | <vlan:base-interface>eth8</vlan:base-interface> | |||
<vlan:vlan-id>5</vlan:vlan-id> | ||||
</interface> | </interface> | |||
If necessary, the operator can move the configuration named | If necessary, the operator can move the configuration named | |||
"acme-interface" over to a different physical interface with an | "acme-interface" over to a different physical interface with an | |||
<edit-config> containing: | <edit-config> containing: | |||
<interface nc:operation="merge"> | <interface nc:operation="merge"> | |||
<name>acme-interface</name> | <name>acme-interface</name> | |||
<location>eth3</location> | <vlan:base-interface>eth3</vlan:base-interface> | |||
</interface> | </interface> | |||
Appendix F. ChangeLog | Appendix F. ChangeLog | |||
RFC Editor: remove this section upon publication as an RFC. | RFC Editor: remove this section upon publication as an RFC. | |||
F.1. Version -08 | F.1. Version -11 | |||
o Separated the operational state from the configuration. | ||||
o Removed 'location', and instead use the name to identify physical | ||||
interfaces. | ||||
o Added the feature 'pre-provisioning'. | ||||
o Made 'oper-status' and 'if-index' mandatory in the data model. | ||||
o Added 'admin-status'. | ||||
o Clarified why description can be mapped to ifAlias. | ||||
o Clarified that 64-bit counters only are used, where there exist | ||||
64-bit and 32-bit counters in IF-MIB. | ||||
o Updated Security Considerations section with a reference to NACM. | ||||
F.2. Version -08 | ||||
o Removed the mtu leaf. | o Removed the mtu leaf. | |||
o Added examples of different interface naming schemes. | o Added examples of different interface naming schemes. | |||
F.2. Version -07 | F.3. Version -07 | |||
o Made leaf speed config false. | o Made leaf speed config false. | |||
F.3. Version -06 | F.4. Version -06 | |||
o Added oper-status leaf. | o Added oper-status leaf. | |||
o Added leaf-lists higher-layer-if and lower-layer-if, that show the | o Added leaf-lists higher-layer-if and lower-layer-if, that show the | |||
interface layering. | interface layering. | |||
o Added container statistics with counters. | o Added container statistics with counters. | |||
F.4. Version -05 | F.5. Version -05 | |||
o Added an Informative References section. | o Added an Informative References section. | |||
o Updated the Security Considerations section. | o Updated the Security Considerations section. | |||
o Clarified the behavior of an NETCONF server when invalid values | o Clarified the behavior of an NETCONF server when invalid values | |||
are received. | are received. | |||
F.5. Version -04 | F.6. Version -04 | |||
o Clarified why ifPromiscuousMode is not part of this data model. | o Clarified why ifPromiscuousMode is not part of this data model. | |||
o Added a table that shows the mapping between this YANG data model | o Added a table that shows the mapping between this YANG data model | |||
and IF-MIB. | and IF-MIB. | |||
F.6. Version -03 | F.7. Version -03 | |||
o Added the section Relationship to the IF-MIB. | o Added the section Relationship to the IF-MIB. | |||
o Changed if-index to be a leaf instead of leaf-list. | o Changed if-index to be a leaf instead of leaf-list. | |||
o Explained the notation used in the data model tree picture. | o Explained the notation used in the data model tree picture. | |||
F.7. Version -02 | F.8. Version -02 | |||
o Editorial fixes | o Editorial fixes | |||
F.8. Version -01 | F.9. Version -01 | |||
o Changed leaf "if-admin-status" to leaf "enabled". | o Changed leaf "if-admin-status" to leaf "enabled". | |||
o Added Security Considerations | o Added Security Considerations | |||
Author's Address | Author's Address | |||
Martin Bjorklund | Martin Bjorklund | |||
Tail-f Systems | Tail-f Systems | |||
End of changes. 113 change blocks. | ||||
311 lines changed or deleted | 600 lines changed or added | |||
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |