draft-ietf-netmod-interfaces-cfg-11.txt | draft-ietf-netmod-interfaces-cfg-12.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 May 15, 2013 | Intended status: Standards Track July 4, 2013 | |||
Expires: November 16, 2013 | Expires: January 5, 2014 | |||
A YANG Data Model for Interface Management | A YANG Data Model for Interface Management | |||
draft-ietf-netmod-interfaces-cfg-11 | draft-ietf-netmod-interfaces-cfg-12 | |||
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 | The data model includes configuration data, state data and counters | |||
for the collection of statistics. | for the collection of statistics. | |||
Status of this Memo | Status of this Memo | |||
skipping to change at page 1, line 34 | skipping to change at page 1, line 34 | |||
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 November 16, 2013. | This Internet-Draft will expire on January 5, 2014. | |||
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 | |||
1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3 | 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4 | |||
2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
3. Interfaces Data Model . . . . . . . . . . . . . . . . . . . . 6 | 3. Interfaces Data Model . . . . . . . . . . . . . . . . . . . . 6 | |||
3.1. The interface Lists . . . . . . . . . . . . . . . . . . . 6 | 3.1. The interface Lists . . . . . . . . . . . . . . . . . . . 6 | |||
3.2. Interface References . . . . . . . . . . . . . . . . . . . 7 | 3.2. Interface References . . . . . . . . . . . . . . . . . . . 8 | |||
3.3. Interface Layering . . . . . . . . . . . . . . . . . . . . 7 | 3.3. Interface Layering . . . . . . . . . . . . . . . . . . . . 8 | |||
4. Relationship to the IF-MIB . . . . . . . . . . . . . . . . . . 9 | 4. Relationship to the IF-MIB . . . . . . . . . . . . . . . . . . 9 | |||
5. Interfaces YANG Module . . . . . . . . . . . . . . . . . . . . 11 | 5. Interfaces YANG Module . . . . . . . . . . . . . . . . . . . . 11 | |||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 | |||
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 | 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 | |||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 | |||
9.1. Normative References . . . . . . . . . . . . . . . . . . . 29 | 9.1. Normative References . . . . . . . . . . . . . . . . . . . 29 | |||
9.2. Informative References . . . . . . . . . . . . . . . . . . 29 | 9.2. Informative References . . . . . . . . . . . . . . . . . . 29 | |||
Appendix A. Example: Ethernet Interface Module . . . . . . . . . 30 | Appendix A. Example: Ethernet Interface Module . . . . . . . . . 30 | |||
Appendix B. Example: Ethernet Bonding Interface Module . . . . . 32 | Appendix B. Example: Ethernet Bonding Interface Module . . . . . 32 | |||
skipping to change at page 3, line 26 | skipping to change at page 3, line 26 | |||
The data model includes configuration data, state data and counters | The data model includes configuration data, state data and counters | |||
for the collection of statistics. | 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 used within this document: | ||||
o system-controlled interface: An interface is said to be system- | ||||
controlled if the system creates and deletes the interface | ||||
independently of what has been explicitly configured. Examples | ||||
are interfaces representing physical hardware that appear and | ||||
disappear when hardware (e.g., a line card) is added or removed. | ||||
System-controlled interfaces may also appear if a certain | ||||
functionality is enabled (e.g., a loopback interface might appear | ||||
if the IP protocol stack is enabled). | ||||
o user-controlled interface: An interface is said to be user- | ||||
controlled if the creation of the interface is controlled by | ||||
adding explicit interface configuration to the running | ||||
configuration datastore and the removal of the interface is | ||||
controlled by removing explicit interface configuration from the | ||||
running configuration datastore. Examples are VLAN interfaces | ||||
configured on a system-controlled Ethernet interface. | ||||
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 configuration data | |||
o server | o server | |||
o state data | 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 | |||
skipping to change at page 7, line 7 | skipping to change at page 7, line 7 | |||
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. | name. Furthermore, each interface has a mandatory "type" leaf. | |||
There is one list of configured interfaces ("/interfaces/interface"), | There is one list of configured interfaces ("/interfaces/interface"), | |||
and a separate list for the operational state of all interfaces | and a separate list for the operational state of all interfaces | |||
("/interfaces-state/interface"). | ("/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 lists, and use the "type" leaf to make the augmentation | interface lists, and possibly use the "type" leaf to make the | |||
conditional. | augmentation 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 { | |||
... | ... | |||
} | } | |||
} | } | |||
} | } | |||
For physical interfaces, the "name" is the device-specific name of | For system-controlled interfaces, the "name" is the device-specific | |||
the interface. It is used to identify the physical hardware | name of the interface. The 'config false' list "/interfaces-state/ | |||
interface. The 'config false' list "/interfaces-state/interface" | interface" contains all existing interfaces on the device. | |||
contains all currently existing interfaces on the device. | ||||
If the device supports arbitrarily named logical interfaces, the | If the device supports arbitrarily named user-controlled interfaces, | |||
NETCONF server advertises the feature "arbitrary-names". If the | the NETCONF server advertises the feature "arbitrary-names". If the | |||
device does not advertise this feature, the names of logical | device does not advertise this feature, the names of user-controlled | |||
interfaces MUST match the device's naming scheme. How a client can | 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 | learn the naming scheme of such devices is outside the scope of this | |||
document. | document. | |||
When a system-controlled interface is created by the system, the | ||||
system tries to apply the interface configuration in /interfaces/ | ||||
interface with the same name as the new interface. If no such | ||||
interface configuration is found, or if the configured type does not | ||||
match the real interface type, the system creates the interface | ||||
without applying explicit configuration. | ||||
When a user-controlled interface is created, the configuration | ||||
determines the name of the interface. | ||||
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" and | server. This property is captured in the "interface-ref" and | |||
"interface-state-ref" typedefs, which other YANG modules SHOULD use | "interface-state-ref" typedefs, which other YANG modules SHOULD use | |||
when they need to reference a configured interface or operationally | when they need to reference a configured interface or operationally | |||
used interface, respectively. | used interface, respectively. | |||
3.3. Interface Layering | 3.3. Interface Layering | |||
skipping to change at page 10, line 8 | skipping to change at page 10, line 8 | |||
differ in the time granularity in which they provide access to the | differ in the time granularity in which they provide access to the | |||
counters. For example, it is common that SNMP implementations cache | counters. For example, it is common that SNMP implementations cache | |||
counter values for some time. | 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 | | | /interfaces-state/interface | ifEntry | | |||
| name | ifName | | | /interfaces-state/name | ifName | | |||
| description | ifAlias | | | description | ifAlias | | |||
| type | ifType | | | type | ifType | | |||
| enabled / admin-status | 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 | | |||
skipping to change at page 11, line 13 | skipping to change at page 11, line 13 | |||
YANG data nodes and related IF-MIB objects | YANG data nodes and related IF-MIB objects | |||
5. Interfaces YANG Module | 5. Interfaces YANG Module | |||
This YANG module imports typedefs from [I-D.ietf-netmod-rfc6021-bis] | This YANG module imports typedefs from [I-D.ietf-netmod-rfc6021-bis] | |||
and [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-05-15.yang" | <CODE BEGINS> file "ietf-interfaces@2013-07-04.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 12, line 16 | skipping to change at page 12, line 16 | |||
(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-05-15 { | revision 2013-07-04 { | |||
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 { | |||
skipping to change at page 12, line 47 | skipping to change at page 12, line 47 | |||
} | } | |||
description | description | |||
"This type is used by data models that need to reference | "This type is used by data models that need to reference | |||
the operationally present interfaces."; | the operationally present interfaces."; | |||
} | } | |||
/* Features */ | /* Features */ | |||
feature arbitrary-names { | feature arbitrary-names { | |||
description | description | |||
"This feature indicates that the device allows logical | "This feature indicates that the device allows user-controlled | |||
interfaces to be named arbitrarily."; | interfaces to be named arbitrarily."; | |||
} | } | |||
feature pre-provisioning { | feature pre-provisioning { | |||
description | description | |||
"This feature indicates that the device supports | "This feature indicates that the device supports | |||
pre-provisioning of interface configuration, i.e., it is | pre-provisioning of interface configuration, i.e., it is | |||
possible to configure an interface whose physical interface | possible to configure an interface whose physical interface | |||
hardware is not present on the device."; | hardware is not present on the device."; | |||
} | } | |||
skipping to change at page 13, line 32 | skipping to change at page 13, line 32 | |||
"Interface configuration parameters."; | "Interface configuration parameters."; | |||
list interface { | list interface { | |||
key "name"; | key "name"; | |||
description | description | |||
"The list of configured interfaces on the device. | "The list of configured interfaces on the device. | |||
The operational state of an interface is available in the | The operational state of an interface is available in the | |||
/interfaces-state/interface list. If the configuration of a | /interfaces-state/interface list. If the configuration of a | |||
physical interface cannot be used by the system (e.g., the | system-controlled interface cannot be used by the system | |||
physical interface present is not matching the interface | (e.g., the interface hardware present does not match the | |||
type), then the configuration is not applied to the physical | interface type), then the configuration is not applied to | |||
interface shown in the /interfaces-state/interface list. If | the system-controlled interface shown in the | |||
the the configuration of a logical interface cannot be used | /interfaces-state/interface list. If the the configuration | |||
by the system, the configured interface is not instantiated | of a user-controlled interface cannot be used by the system, | |||
in the /interfaces-state/interface list."; | the configured interface is not instantiated in the | |||
/interfaces-state/interface list."; | ||||
leaf name { | 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 of the interface. | possibly depending on the type of the interface. | |||
For physical interfaces, this leaf is the device-specific | For system-controlled interfaces, this leaf is the | |||
name of the interface. The 'config false' list | device-specific name of the interface. The 'config false' | |||
/interfaces-state/interface contains the currently | list /interfaces-state/interface contains the currently | |||
existing interfaces on the device. | existing interfaces on the device. | |||
If a client tries to create configuration for a physical | If a client tries to create configuration for a | |||
interface that is not present, the server MAY reject the | system-controlled interface that is not present in the | |||
request, if the implementation does not support | /interfaces-state/interface list, the server MAY reject | |||
the request, if the implementation does not support | ||||
pre-provisioning of interfaces, or if the name refers to | pre-provisioning of interfaces, or if the name refers to | |||
an interface that can never exist in the system. | an interface that can never exist in the system. A | |||
A NETCONF server MUST reply with an rpc-error with the | NETCONF server MUST reply with an rpc-error with the | |||
error-tag 'invalid-value' in this case. | error-tag 'invalid-value' in this case. | |||
If the device supports pre-provisioning of interface | If the device supports pre-provisioning of interface | |||
configuration, the feature 'pre-provisioning' is | configuration, the feature 'pre-provisioning' is | |||
advertised. | advertised. | |||
If the device allows arbitrarily named logical interfaces, | If the device allows arbitrarily named user-controlled | |||
the feature 'arbitrary-names' is advertised. | interfaces, the feature 'arbitrary-names' is advertised. | |||
When a configured logical interface is created by the | When a configured user-controlled interface is created by | |||
system, it is instantiated in the | the system, it is instantiated with the same name in the | |||
/interface-state/interface list. Since the name in that | /interface-state/interface list. Since the name in that | |||
list MAY be mapped to ifName by an implementation, such an | list MAY be mapped to ifName by an implementation, such an | |||
implementation MUST restrict the allowed values for this | implementation MUST restrict the allowed values for this | |||
leaf so that it matches the restrictions of ifName. | 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'."; | |||
} | } | |||
skipping to change at page 14, line 49 | skipping to change at page 14, line 51 | |||
Such an implementation MUST restrict the allowed values | Such an implementation MUST restrict the allowed values | |||
for this leaf so that it matches the restrictions of | for this leaf so that it matches the restrictions of | |||
ifAlias. | 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 | Since ifAlias is defined to be stored in non-volatile | |||
storage, the SNMP implementation MUST map ifAlias to the | storage, the MIB implementation MUST map ifAlias to the | |||
value of 'description' in the persistently stored | value of 'description' in the persistently stored | |||
datastore. | datastore. | |||
Specifically, if the device supports ':startup', when | Specifically, if the device supports ':startup', when | |||
ifAlias is read the device MUST return the value of | ifAlias is read the device MUST return the value of | |||
'description' in the 'startup' datastore, and when it is | 'description' in the 'startup' datastore, and when it is | |||
written, it MUST be written to the 'running' and 'startup' | written, it MUST be written to the 'running' and 'startup' | |||
datastores. Note that it is up to the implementation if | datastores. Note that it is up to the implementation if | |||
it modifies this single leaf in 'startup', or if it | it modifies this single leaf in 'startup', or if it | |||
performs an implicit copy-config from 'running' to | performs an implicit copy-config from 'running' to | |||
skipping to change at page 16, line 48 | skipping to change at page 16, line 51 | |||
config false; | config false; | |||
description | description | |||
"Data nodes for the operational state of interfaces."; | "Data nodes for the operational state of interfaces."; | |||
list interface { | list interface { | |||
key "name"; | key "name"; | |||
description | description | |||
"The list of interfaces on the device. | "The list of interfaces on the device. | |||
Physical interfaces detected by the system are always | System-controlled interfaces created by the system are | |||
present in this list, if they are configured or not."; | always present in this list, whether they are configured or | |||
not."; | ||||
leaf name { | leaf name { | |||
type string; | type string; | |||
description | description | |||
"The name of the interface. | "The name of the interface. | |||
This leaf MAY be mapped to ifName by an implementation. | This leaf MAY be mapped to ifName by an implementation."; | |||
Such an implementation MUST restrict the values | ||||
for this leaf so that it matches the restrictions of | ||||
ifName."; | ||||
reference | reference | |||
"RFC 2863: The Interfaces Group MIB - ifName"; | "RFC 2863: The Interfaces Group MIB - ifName"; | |||
} | } | |||
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."; | |||
reference | reference | |||
skipping to change at page 17, line 47 | skipping to change at page 17, line 49 | |||
enum testing { | enum testing { | |||
value 3; | value 3; | |||
description | description | |||
"In some test mode."; | "In some test mode."; | |||
} | } | |||
} | } | |||
mandatory true; | mandatory true; | |||
description | description | |||
"The desired state of the interface. | "The desired state of the interface. | |||
This leaf has the same semantics as ifAdminStatus."; | This leaf has the same read semantics as ifAdminStatus."; | |||
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."; | |||
} | } | |||
enum down { | enum down { | |||
value 2; | value 2; | |||
description | description | |||
skipping to change at page 29, line 10 | skipping to change at page 29, line 10 | |||
8. Acknowledgments | 8. Acknowledgments | |||
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 YANG Module", | |||
YANG Modules", draft-ietf-netmod-iana-if-type-06 (work in | draft-ietf-netmod-iana-if-type-07 (work in progress), | |||
progress), April 2013. | July 2013. | |||
[I-D.ietf-netmod-rfc6021-bis] | [I-D.ietf-netmod-rfc6021-bis] | |||
Schoenwaelder, J., "Common YANG Data Types", | Schoenwaelder, J., "Common YANG Data Types", | |||
draft-ietf-netmod-rfc6021-bis-02 (work in progress), | draft-ietf-netmod-rfc6021-bis-03 (work in progress), | |||
May 2013. | June 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 34, 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 | <interfaces | |||
xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces" | xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces" | |||
xmlns:vlan="http://example.com/vlan"> | xmlns:vlan="http://example.com/vlan"> | |||
<interface> | <interface> | |||
<name>eth0</name> | <name>eth0</name> | |||
<type>ethernetCsmacd</type> | <type>ethernetCsmacd</type> | |||
<enabled>false</enabled> | <enabled>false</enabled> | |||
</interface> | </interface> | |||
<interface> | <interface> | |||
<name>eth1</name> | <name>eth1</name> | |||
<type>ethernetCsmacd</type> | <type>ethernetCsmacd</type> | |||
<enabled>true</enabled> | <enabled>true</enabled> | |||
<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> | |||
<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> | |||
<interface> | <interface> | |||
<name>lo1</name> | <name>lo1</name> | |||
<type>softwareLoopback</type> | <type>softwareLoopback</type> | |||
<enabled>true</enabled> | <enabled>true</enabled> | |||
</interface> | </interface> | |||
</interfaces> | </interfaces> | |||
<interfaces-state | <interfaces-state | |||
xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"> | xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"> | |||
<interface> | <interface> | |||
<name>eth0</name> | <name>eth0</name> | |||
<type>ethernetCsmacd</type> | <type>ethernetCsmacd</type> | |||
<admin-status>down</admin-status> | <admin-status>down</admin-status> | |||
<oper-status>down</oper-status> | <oper-status>down</oper-status> | |||
<if-index>2</if-index> | <if-index>2</if-index> | |||
<phys-address>00:01:02:03:04:05</phys-address> | <phys-address>00:01:02:03:04:05</phys-address> | |||
<statistics> | <statistics> | |||
<discontinuity-time>2013-04-01T03:00:00Z</discontinuity-time> | <discontinuity-time> | |||
<!-- counters now shown here --> | 2013-04-01T03:00:00+00:00 | |||
</statistics> | </discontinuity-time> | |||
</interface> | <!-- counters now shown here --> | |||
</statistics> | ||||
</interface> | ||||
<interface> | <interface> | |||
<name>eth1</name> | <name>eth1</name> | |||
<type>ethernetCsmacd</type> | <type>ethernetCsmacd</type> | |||
<admin-status>up</admin-status> | <admin-status>up</admin-status> | |||
<oper-status>up</oper-status> | <oper-status>up</oper-status> | |||
<if-index>7</if-index> | <if-index>7</if-index> | |||
<phys-address>00:01:02:03:04:06</phys-address> | <phys-address>00:01:02:03:04:06</phys-address> | |||
<higher-layer-if>eth1.10</higher-layer-if> | <higher-layer-if>eth1.10</higher-layer-if> | |||
<statistics> | <statistics> | |||
<discontinuity-time>2013-04-01T03:00:00Z</discontinuity-time> | <discontinuity-time> | |||
<!-- counters now shown here --> | 2013-04-01T03:00:00+00:00 | |||
</statistics> | </discontinuity-time> | |||
</interface> | <!-- counters now shown here --> | |||
</statistics> | ||||
</interface> | ||||
<interface> | <interface> | |||
<name>eth1.10</name> | <name>eth1.10</name> | |||
<type>l2vlan</type> | <type>l2vlan</type> | |||
<admin-status>up</admin-status> | <admin-status>up</admin-status> | |||
<oper-status>up</oper-status> | <oper-status>up</oper-status> | |||
<if-index>9</if-index> | <if-index>9</if-index> | |||
<lower-layer-if>eth1</lower-layer-if> | <lower-layer-if>eth1</lower-layer-if> | |||
<statistics> | <statistics> | |||
<discontinuity-time>2013-04-01T03:00:00Z</discontinuity-time> | <discontinuity-time> | |||
<!-- counters now shown here --> | 2013-04-01T03:00:00+00:00 | |||
</statistics> | </discontinuity-time> | |||
</interface> | <!-- counters now shown here --> | |||
</statistics> | ||||
</interface> | ||||
<!-- This interface is not configured --> | <!-- This interface is not configured --> | |||
<interface> | <interface> | |||
<name>eth2</name> | <name>eth2</name> | |||
<type>ethernetCsmacd</type> | <type>ethernetCsmacd</type> | |||
<admin-status>down</admin-status> | <admin-status>down</admin-status> | |||
<oper-status>down</oper-status> | <oper-status>down</oper-status> | |||
<if-index>8</if-index> | <if-index>8</if-index> | |||
<phys-address>00:01:02:03:04:07</phys-address> | <phys-address>00:01:02:03:04:07</phys-address> | |||
<statistics> | <statistics> | |||
<discontinuity-time>2013-04-01T03:00:00Z</discontinuity-time> | <discontinuity-time> | |||
<!-- counters now shown here --> | 2013-04-01T03:00:00+00:00 | |||
</statistics> | </discontinuity-time> | |||
</interface> | <!-- counters now shown here --> | |||
</statistics> | ||||
</interface> | ||||
<interface> | <interface> | |||
<name>lo1</name> | <name>lo1</name> | |||
<type>softwareLoopback</type> | <type>softwareLoopback</type> | |||
<admin-status>up</admin-status> | <admin-status>up</admin-status> | |||
<oper-status>up</oper-status> | <oper-status>up</oper-status> | |||
<if-index>1</if-index> | <if-index>1</if-index> | |||
<statistics> | <statistics> | |||
<discontinuity-time>2013-04-01T03:00:00Z</discontinuity-time> | <discontinuity-time> | |||
<!-- counters now shown here --> | 2013-04-01T03:00:00+00:00 | |||
</statistics> | </discontinuity-time> | |||
</interface> | <!-- counters now shown here --> | |||
</statistics> | ||||
</interface> | ||||
</interfaces-state> | </interfaces-state> | |||
</data> | </data> | |||
</rpc-reply> | </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 | The examples make use of the example data model "ex-vlan" (see | |||
Appendix C) to show how logical interfaces can be configured. | Appendix C) to show how user-controlled 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 device-specific names for these physical interfaces are | The device-specific names for these physical interfaces are | |||
"fastethernet-N/M" or "gigabitethernet-N/M". | "fastethernet-N/M" or "gigabitethernet-N/M". | |||
skipping to change at page 38, line 33 | skipping to change at page 38, line 33 | |||
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 device-specific names for these physical interfaces are | The device-specific names for these physical interfaces are | |||
"fastethernet-N/M" or "gigabitethernet-N/M". | "fastethernet-N/M" or "gigabitethernet-N/M". | |||
The implementation does not restrict the logical interface names. | The implementation does not restrict the user-controlled interface | |||
This allows to more easily apply the interface configuration to a | names. This allows to more easily apply the interface configuration | |||
different interface. However, the additional level of indirection | to a different interface. However, the additional level of | |||
also makes it a bit more complex to map interface names found in | indirection also makes it a bit more complex to map interface names | |||
other protocols to configuration entries. | 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. | |||
Physical interfaces are configured as in Appendix E.1. | Physical interfaces are configured as in Appendix E.1. | |||
An operator can configure a logical interface by sending an | An operator can configure a VLAN interface by sending an | |||
<edit-config> containing: | <edit-config> containing: | |||
<interface nc:operation="create"> | <interface nc:operation="create"> | |||
<name>acme-interface</name> | <name>acme-interface</name> | |||
<type>l2-vlan</type> | <type>l2-vlan</type> | |||
<vlan:base-interface>fastethernet-1/0</vlan:base-interface> | <vlan:base-interface>fastethernet-1/0</vlan:base-interface> | |||
<vlan:vlan-id>5</vlan:vlan-id> | <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 | |||
skipping to change at page 40, line 34 | skipping to change at page 40, line 34 | |||
<vlan:base-interface>eth8</vlan:base-interface> | <vlan:base-interface>eth8</vlan:base-interface> | |||
<vlan:vlan-id>5</vlan:vlan-id> | <vlan:vlan-id>5</vlan:vlan-id> | |||
</interface> | </interface> | |||
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. | |||
The system identifies the physical interface by the name assigned by | The system identifies the physical interface by the name assigned by | |||
the operating system to the interface. | the operating system to the interface. | |||
The implementation does not restrict the logical interface names. | The implementation does not restrict the user-controlled interface | |||
This allows to more easily apply the interface configuration to a | names. This allows to more easily apply the interface configuration | |||
different interface. However, the additional level of indirection | to a different interface. However, the additional level of | |||
also makes it a bit more complex to map interface names found in | indirection also makes it a bit more complex to map interface names | |||
other protocols to configuration entries. | 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. | |||
Physical interfaces are configured as in Appendix E.4. | Physical interfaces are configured as in Appendix E.4. | |||
An operator can configure a logical interface by sending an | An operator can configure a VLAN interface by sending an | |||
<edit-config> containing: | <edit-config> containing: | |||
<interface nc:operation="create"> | <interface nc:operation="create"> | |||
<name>acme-interface</name> | <name>acme-interface</name> | |||
<type>l2-vlan</type> | <type>l2-vlan</type> | |||
<vlan:base-interface>eth8</vlan:base-interface> | <vlan:base-interface>eth8</vlan:base-interface> | |||
<vlan:vlan-id>5</vlan:vlan-id> | <vlan:vlan-id>5</vlan:vlan-id> | |||
</interface> | </interface> | |||
End of changes. 48 change blocks. | ||||
164 lines changed or deleted | 203 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/ |