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/