draft-ietf-netmod-interfaces-cfg-07.txt   draft-ietf-netmod-interfaces-cfg-08.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 October 22, 2012 Intended status: Standards Track November 15, 2012
Expires: April 25, 2013 Expires: May 19, 2013
A YANG Data Model for Interface Management A YANG Data Model for Interface Management
draft-ietf-netmod-interfaces-cfg-07 draft-ietf-netmod-interfaces-cfg-08
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.
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
skipping to change at page 1, line 32 skipping to change at page 1, line 32
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 April 25, 2013. This Internet-Draft will expire on May 19, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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
skipping to change at page 2, line 26 skipping to change at page 2, line 26
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
9.1. Normative References . . . . . . . . . . . . . . . . . . . 26 9.1. Normative References . . . . . . . . . . . . . . . . . . . 26
9.2. Informative References . . . . . . . . . . . . . . . . . . 26 9.2. Informative References . . . . . . . . . . . . . . . . . . 26
Appendix A. Example: Ethernet Interface Module . . . . . . . . . 27 Appendix A. Example: Ethernet Interface Module . . . . . . . . . 27
Appendix B. Example: Ethernet Bonding Interface Module . . . . . 29 Appendix B. Example: Ethernet Bonding Interface Module . . . . . 29
Appendix C. Example: VLAN Interface Module . . . . . . . . . . . 30 Appendix C. Example: VLAN Interface Module . . . . . . . . . . . 30
Appendix D. Example: NETCONF <get> reply . . . . . . . . . . . . 31 Appendix D. Example: NETCONF <get> reply . . . . . . . . . . . . 31
Appendix E. ChangeLog . . . . . . . . . . . . . . . . . . . . . . 32 Appendix E. Examples: Interface Naming Schemes . . . . . . . . . 32
E.1. Version -07 . . . . . . . . . . . . . . . . . . . . . . . 32 E.1. Router with Restricted Interface Names . . . . . . . . . . 32
E.2. Version -06 . . . . . . . . . . . . . . . . . . . . . . . 32 E.2. Router with Arbitrary Interface Names . . . . . . . . . . 33
E.3. Version -05 . . . . . . . . . . . . . . . . . . . . . . . 32 E.3. Ethernet Switch with Restricted Interface Names . . . . . 33
E.4. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 32 E.4. Generic Host with Restricted Interface Names . . . . . . . 34
E.5. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 32 E.5. Generic Host with Arbitrary Interface Names . . . . . . . 35
E.6. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 32 Appendix F. ChangeLog . . . . . . . . . . . . . . . . . . . . . . 36
E.7. Version -01 . . . . . . . . . . . . . . . . . . . . . . . 33 F.1. Version -08 . . . . . . . . . . . . . . . . . . . . . . . 36
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 34 F.2. Version -07 . . . . . . . . . . . . . . . . . . . . . . . 36
F.3. Version -06 . . . . . . . . . . . . . . . . . . . . . . . 36
F.4. Version -05 . . . . . . . . . . . . . . . . . . . . . . . 36
F.5. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 36
F.6. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 36
F.7. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 37
F.8. Version -01 . . . . . . . . . . . . . . . . . . . . . . . 37
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 38
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
skipping to change at page 5, line 21 skipping to change at page 5, line 21
+--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 location? string
+--rw enabled? boolean +--rw enabled? boolean
+--ro oper-status? enumeration +--ro oper-status? enumeration
+--ro last-change? yang:date-and-time +--ro last-change? yang:date-and-time
+--ro if-index? int32 +--ro if-index? int32
+--rw mtu? uint32
+--rw link-up-down-trap-enable? enumeration +--rw link-up-down-trap-enable? enumeration
+--ro phys-address? yang:phys-address +--ro phys-address? yang:phys-address
+--ro higher-layer-if* interface-ref +--ro higher-layer-if* interface-ref
+--ro lower-layer-if* interface-ref +--ro lower-layer-if* interface-ref
+--ro speed? yang:gauge64 +--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
skipping to change at page 5, line 43 skipping to change at page 5, line 42
+--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
This module defines one YANG feature:
if-mib: Indicates that the server implements IF-MIB [RFC2863].
3.1. The interface List 3.1. The interface List
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 a name. Furthermore, each interface has a mandatory "type" leaf, and a
"location" leaf. The combination of "type" and "location" is unique "location" leaf. The combination of "type" and "location" is unique
within the interface list. within the interface list.
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 list, and use the "type" leaf to make the augmentation
skipping to change at page 7, line 10 skipping to change at page 7, line 5
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
example, see Appendix B. example, see Appendix B.
import interfaces {
prefix "if";
}
augment "/if:interfaces/if:interface" { augment "/if:interfaces/if:interface" {
when "if:type = 'ieee8023adLag'"; when "if:type = 'ieee8023adLag'";
leaf-list slave-if { leaf-list slave-if {
type if:interface-ref; type if:interface-ref;
must "/if:interfaces/if:interface[if:name = current()]" must "/if:interfaces/if:interface[if:name = current()]"
+ "/if:type = 'ethernetCsmacd'" { + "/if:type = 'ethernetCsmacd'" {
description description
"The type of a slave interface must be ethernet"; "The type of a slave interface must be ethernet";
} }
skipping to change at page 9, line 16 skipping to change at page 9, line 16
| 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 | ifAdminStatus |
| oper-status | ifOperStatus | | oper-status | ifOperStatus |
| last-change | ifLastChange | | last-change | ifLastChange |
| if-index | ifIndex | | if-index | ifIndex |
| mtu | ifMtu |
| 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 |
| in-multicast-pkts | ifHCInMulticastPkts | | in-multicast-pkts | ifHCInMulticastPkts |
| in-discards | ifInDiscards | | in-discards | ifInDiscards |
| in-errors | ifInErrors | | in-errors | ifInErrors |
skipping to change at page 10, line 13 skipping to change at page 10, line 13
Mapping of YANG data nodes to IF-MIB objects Mapping of YANG data nodes to IF-MIB objects
5. Interfaces YANG Module 5. Interfaces YANG Module
This YANG module imports a typedef from This YANG module imports a typedef from
[I-D.ietf-netmod-iana-if-type]. [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@2012-10-22.yang" <CODE BEGINS> file "ietf-interfaces@2012-11-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 11, line 16 skipping to change at page 11, 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 2012-10-22 { revision 2012-11-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."; interfaces.";
} }
/* Features */ /* Features */
feature arbitrary-names {
description
"This feature indicates that the server allows interfaces to
be named arbitrarily.";
}
feature if-mib { feature if-mib {
description description
"This feature indicates that the server implements IF-MIB."; "This feature indicates that the server 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 {
skipping to change at page 12, line 4 skipping to change at page 12, line 10
/* Data nodes */ /* Data nodes */
container interfaces { container interfaces {
description description
"Interface parameters."; "Interface parameters.";
list interface { list interface {
key "name"; key "name";
unique "type location"; unique "type location";
description description
"The list of interfaces on the device."; "The list of interfaces on the device.";
leaf name { leaf name {
type string; type string;
description description
"An arbitrary name for 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 and location.
For example, if a device has a single array of 8 ethernet If the device allows arbitrarily named interfaces, the
ports, the name might be restricted to be on the form feature 'arbitrary-names' is advertised.
'ethN', where N is an integer between '1' and '8'.
This leaf MAY be mapped to ifName by an implementation. This leaf MAY be mapped to ifName by an implementation.
Such an implementation MAY restrict the allowed values for Such an implementation MAY restrict the allowed values for
this leaf so that it matches the restrictions of ifName. 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 reference
"RFC 2863: The Interfaces Group MIB - ifName"; "RFC 2863: The Interfaces Group MIB - ifName";
skipping to change at page 13, line 23 skipping to change at page 13, line 28
leaf location { leaf location {
type string; type string;
description description
"The device-specific location of the interface of a "The device-specific location of the interface of a
particular type. The format of the location string particular type. The format of the location string
depends on the interface type and the device. depends on the interface type and the device.
If the interface's type represents a physical interface, If the interface's type represents a physical interface,
this leaf MUST be set. this leaf MUST be set.
For example, if a device has a single array of 8 ethernet
ports, the location can be one of '1' to '8'. As another
example, if a device has N cards of M ports, the location
can be on the form 'n/m'.
When an interface entry is created, a server MAY When an interface entry is created, a server MAY
initialize the location leaf with a valid value, e.g., if initialize the location leaf with a valid value, e.g., if
it is possible to derive the location from the name of it is possible to derive the location from the name of
the interface."; the interface.";
} }
leaf enabled { leaf enabled {
type boolean; type boolean;
default "true"; default "true";
description description
skipping to change at page 14, line 9 skipping to change at page 14, line 10
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
"The interface does not pass any packets.";
} }
enum testing { enum testing {
value 3; value 3;
description description
"In some test mode. No operational packets can "In some test mode. No operational packets can
be passed."; be passed.";
} }
enum unknown { enum unknown {
value 4; value 4;
description description
"Status can not be determined "Status cannot be determined for some reason.";
for some reason.";
} }
enum dormant { enum dormant {
value 5; value 5;
description
"Waiting for some external event.";
} }
enum not-present { enum not-present {
value 6; value 6;
description description
"Some component is missing."; "Some component is missing.";
} }
enum lower-layer-down { enum lower-layer-down {
value 7; value 7;
description description
"Down due to state of lower-layer "Down due to state of lower-layer interface(s).";
interface(s).";
} }
} }
config false; config false;
description description
"The current operational state of the interface. "The current operational state of the interface.
If 'enabled' is 'false' then 'oper-status' If 'enabled' is 'false' then 'oper-status'
should be 'down'. If 'enabled' is changed to 'true' should be 'down'. If 'enabled' is changed to 'true'
then 'oper-status' should change to 'up' if the interface then 'oper-status' should change to 'up' if the interface
is ready to transmit and receive network traffic; it is ready to transmit and receive network traffic; it
skipping to change at page 15, line 37 skipping to change at page 15, line 39
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 Media-specific modules must specify how the type is
mapped to entries in the ifTable."; mapped to entries in the ifTable.";
reference reference
"RFC 2863: The Interfaces Group MIB - ifIndex"; "RFC 2863: The Interfaces Group MIB - ifIndex";
} }
leaf mtu {
type uint32;
description
"The size, in octets, of the largest packet that the
interface can send and receive. This node might not be
valid for all interface types.
Media-specific modules must specify any restrictions on
the mtu for their interface type.";
reference
"RFC 2863: The Interfaces Group MIB - ifMtu";
}
leaf link-up-down-trap-enable { leaf link-up-down-trap-enable {
if-feature if-mib; if-feature if-mib;
type enumeration { type enumeration {
enum enabled { enum enabled {
value 1; value 1;
} }
enum disabled { enum disabled {
value 2; value 2;
} }
} }
skipping to change at page 17, line 13 skipping to change at page 16, line 51
config false; 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;
config false;
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 which 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 has 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";
skipping to change at page 24, line 28 skipping to change at page 25, line 5
and their sensitivity/vulnerability: and their sensitivity/vulnerability:
/interfaces/interface: This list specifies the configured interfaces /interfaces/interface: This list specifies the configured interfaces
on a device. Unauthorized access to this list could cause the on a device. Unauthorized access to this list could cause the
device to ignore packets it should receive and process. device to ignore packets it should receive and process.
/interfaces/interface/enabled: This leaf controls if an interface is /interfaces/interface/enabled: This leaf controls if an interface is
enabled or not. Unauthorized access to this leaf could cause the enabled or not. Unauthorized access to this leaf could cause the
device to ignore packets it should receive and process. device to ignore packets it should receive and process.
/interfaces/interface/mtu: Setting this leaf to a very small value
can be used to slow down interfaces.
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]
skipping to change at page 32, line 5 skipping to change at page 32, line 5
<location>1</location> <location>1</location>
<enabled>true</enabled> <enabled>true</enabled>
<if-index>7</if-index> <if-index>7</if-index>
<vlan-tagging <vlan-tagging
xmlns="http://example.com/vlan">true</vlan-tagging> xmlns="http://example.com/vlan">true</vlan-tagging>
</interface> </interface>
</interfaces> </interfaces>
</data> </data>
</rpc-reply> </rpc-reply>
Appendix E. ChangeLog Appendix E. Examples: Interface Naming Schemes
This section gives examples of some implementation strategies.
E.1. Router with Restricted Interface Names
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,
and the ports on each card from 0 to 7. Each card has fast- or
gigabit-ethernet ports.
The implementation restricts the names of the interfaces to one of
"fastethernet-N/M" or "gigabitethernet-N/M". The "location" of an
interface is a string on the form "N/M". The implementation auto-
initializes the values for "type" and "location" based on the
interface name.
An operator can configure a new interface by sending an <edit-config>
containing:
<interface nc:operation="create">
<name>fastethernet-1/0</name>
</interface>
When the server processes this request, it will set the leaf "type"
to "ethernetCsmacd" and "location" to "1/0". Thus, if the client
performs a <get-config> right after the <edit-config> above, it will
get:
<interface>
<name>fastethernet-1/0</name>
<type>ethernetCsmacd</type>
<location>1/0</location>
</interface>
If the client tries to change the location of this interface with an
<edit-config> containing:
<interface nc:operation="merge">
<name>fastethernet-1/0</name>
<location>1/1</location>
</interface>
then the server will reply with an "invalid-value" error, since the
new location does not match the name.
E.2. Router with Arbitrary Interface Names
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,
and the ports on each card from 0 to 7. Each card has fast- or
gigabit-ethernet ports.
The implementation does not restrict the interface names. This
allows to more easily apply the interface configuration to a
different physical interface. However, the additional level of
indirection also makes it a bit more complex to map interface names
found in other protocols to configuration entries. The "location" of
an interface is a string on the form "N/M".
An operator can configure a new interface by sending an <edit-config>
containing:
<interface nc:operation="create">
<name>acme-interface</name>
<type>ethernetCsmacd</type>
<location>1/0</location>
</interface>
If necessary, the operator can move the configuration named
"acme-interface" over to a different physical interface with an
<edit-config> containing:
<interface nc:operation="merge">
<name>acme-interface</name>
<location>2/4</location>
</interface>
E.3. Ethernet Switch with Restricted Interface Names
In this example, an ethernet switch has a number of ports, each port
identified by a simple port number.
The implementation restricts the interface names to numbers that
match the physical port number.
An operator can configure a new interface by sending an <edit-config>
containing:
<interface nc:operation="create">
<name>6</name>
</interface>
When the server processes this request, it will set the leaf "type"
to "ethernetCsmacd" and "location" to "6". Thus, if the client
performs a <get-config> right after the <edit-config> above, it will
get:
<interface>
<name>6</name>
<type>ethernetCsmacd</type>
<location>6</location>
</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
In this example, a generic host has interfaces named by the kernel
and without easily usable location information. The system
identifies the physical interface by the name assigned by the
operating system to the interface.
The implementation restricts the interface name to the operating
system level name of the physical interface.
An operator can configure a new interface by sending an <edit-config>
containing:
<interface nc:operation="create">
<name>eth8</name>
</interface>
When the server processes this request, it will set the leaf "type"
to "ethernetCsmacd" and "location" to "eth8". Thus, if the client
performs a <get-config> right after the <edit-config> above, it will
get:
<interface>
<name>eth8</name>
<type>ethernetCsmacd</type>
<location>eth8</location>
</interface>
If the client tries to change the location of this interface with an
<edit-config> containing:
<interface nc:operation="merge">
<name>eth8</name>
<location>eth7</location>
</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
In this example, a generic host has interfaces named by the kernel
and without easily usable location information. The system
identifies the physical interface by the name assigned by the
operating system to the interface.
The implementation does not restrict the interface name to the
operating system level name of the physical interface. This allows
to more easily apply the interface configuration to a different
physical interface. However, the additional level of indirection
also makes it a bit more complex to map interface names found in
other protocols to configuration entries.
An operator can configure a new interface by sending an <edit-config>
containing:
<interface nc:operation="create">
<name>acme-interface</name>
<type>ethernetCsmacd</type>
<location>eth4</location>
</interface>
If necessary, the operator can move the configuration named
"acme-interface" over to a different physical interface with an
<edit-config> containing:
<interface nc:operation="merge">
<name>acme-interface</name>
<location>eth3</location>
</interface>
Appendix F. ChangeLog
RFC Editor: remove this section upon publication as an RFC. RFC Editor: remove this section upon publication as an RFC.
E.1. Version -07 F.1. Version -08
o Removed the mtu leaf.
o Added examples of different interface naming schemes.
F.2. Version -07
o Made leaf speed config false. o Made leaf speed config false.
E.2. Version -06 F.3. 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.
E.3. Version -05 F.4. 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.
E.4. Version -04 F.5. 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.
E.5. Version -03 F.6. 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.
E.6. Version -02 F.7. Version -02
o Editorial fixes o Editorial fixes
E.7. Version -01 F.8. 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. 31 change blocks. 
59 lines changed or deleted 243 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/