draft-ietf-netmod-interfaces-cfg-09.txt   draft-ietf-netmod-interfaces-cfg-10.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 February 6, 2013 Intended status: Standards Track April 19, 2013
Expires: August 10, 2013 Expires: October 21, 2013
A YANG Data Model for Interface Management A YANG Data Model for Interface Management
draft-ietf-netmod-interfaces-cfg-09 draft-ietf-netmod-interfaces-cfg-10
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 August 10, 2013. This Internet-Draft will expire on October 21, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 32 skipping to change at page 2, line 32
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. Examples: Interface Naming Schemes . . . . . . . . . 32 Appendix E. Examples: Interface Naming Schemes . . . . . . . . . 32
E.1. Router with Restricted Interface Names . . . . . . . . . . 32 E.1. Router with Restricted Interface Names . . . . . . . . . . 32
E.2. Router with Arbitrary Interface Names . . . . . . . . . . 33 E.2. Router with Arbitrary Interface Names . . . . . . . . . . 33
E.3. Ethernet Switch with Restricted Interface Names . . . . . 33 E.3. Ethernet Switch with Restricted Interface Names . . . . . 33
E.4. Generic Host with Restricted Interface Names . . . . . . . 34 E.4. Generic Host with Restricted Interface Names . . . . . . . 34
E.5. Generic Host with Arbitrary Interface Names . . . . . . . 35 E.5. Generic Host with Arbitrary Interface Names . . . . . . . 35
Appendix F. ChangeLog . . . . . . . . . . . . . . . . . . . . . . 36 Appendix F. ChangeLog . . . . . . . . . . . . . . . . . . . . . . 37
F.1. Version -08 . . . . . . . . . . . . . . . . . . . . . . . 36 F.1. Version -08 . . . . . . . . . . . . . . . . . . . . . . . 37
F.2. Version -07 . . . . . . . . . . . . . . . . . . . . . . . 36 F.2. Version -07 . . . . . . . . . . . . . . . . . . . . . . . 37
F.3. Version -06 . . . . . . . . . . . . . . . . . . . . . . . 36 F.3. Version -06 . . . . . . . . . . . . . . . . . . . . . . . 37
F.4. Version -05 . . . . . . . . . . . . . . . . . . . . . . . 36 F.4. Version -05 . . . . . . . . . . . . . . . . . . . . . . . 37
F.5. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 36 F.5. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 37
F.6. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 36 F.6. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 37
F.7. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 37 F.7. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 38
F.8. Version -01 . . . . . . . . . . . . . . . . . . . . . . . 37 F.8. Version -01 . . . . . . . . . . . . . . . . . . . . . . . 38
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 38 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 39
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 4, line 12 skipping to change at page 4, line 12
o data node o data node
2. Objectives 2. Objectives
This section describes some of the design objectives for the model This section describes some of the design objectives for the model
presented in Section 5. presented in Section 5.
o It is recognized that existing implementations will have to map o It is recognized that existing implementations will have to map
the interface data model defined in this memo to their proprietary the interface data model defined in this memo to their proprietary
native data model. The new data model should be simple to native data model. The data model should be simple to facilitate
facilitate such mappings. such mappings.
o The data model should be suitable for new implementations to use o The data model should be suitable for new implementations to use
as-is, without requiring a mapping to a different native model. as-is, without requiring a mapping to a different native model.
o References to interfaces should be as simple as possible, o References to interfaces should be as simple as possible,
preferably by using a single leafref. preferably by using a single leafref.
o The mapping to ifIndex [RFC2863] used by SNMP to identify o The mapping to ifIndex [RFC2863] used by SNMP to identify
interfaces must be clear. interfaces must be clear.
skipping to change at page 5, line 46 skipping to change at page 5, line 46
+--ro out-unicast-pkts? yang:counter64 +--ro out-unicast-pkts? yang:counter64
+--ro out-broadcast-pkts? yang:counter64 +--ro out-broadcast-pkts? yang:counter64
+--ro out-multicast-pkts? yang:counter64 +--ro out-multicast-pkts? yang:counter64
+--ro out-discards? yang:counter32 +--ro out-discards? yang:counter32
+--ro out-errors? yang:counter32 +--ro out-errors? yang:counter32
3.1. The interface List 3.1. The interface 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
"location" leaf. The combination of "type" and "location" is unique an optional "location" leaf. The combination of "type" and
within the interface list. "location" is unique 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
conditional. conditional.
As an example of such an interface type specific augmentation, As an example of such an interface type specific augmentation,
consider this YANG snippet. For a more complete example, see consider this YANG snippet. For a more complete example, see
Appendix A. Appendix A.
import interfaces { import interfaces {
skipping to change at page 8, line 9 skipping to change at page 8, line 9
// other bonding config params, failover times etc. // other bonding config params, failover times etc.
} }
Two state data leaf-lists, "higher-layer-if" and "lower-layer-if", Two state data leaf-lists, "higher-layer-if" and "lower-layer-if",
represent a read-only view of the interface layering hierarchy. represent a read-only view of the interface layering hierarchy.
4. Relationship to the IF-MIB 4. Relationship to the IF-MIB
If the device implements IF-MIB [RFC2863], each entry in the If the device implements IF-MIB [RFC2863], each entry in the
"interface" list is typically mapped to one ifEntry. The "if-index" "interface" list is typically mapped to one ifEntry. The "if-index"
leaf contains the value of the corresponding ifEntry's ifIndex. leaf MUST contain the value of the corresponding ifEntry's ifIndex.
In most cases, the "name" of an "interface" entry is mapped to In most cases, the "name" of an "interface" entry is mapped to
ifName. ifName is defined as an DisplayString [RFC2579] which uses a ifName. ifName is defined as an DisplayString [RFC2579] which uses a
7-bit ASCII character set. An implementation MAY restrict the 7-bit ASCII character set. An implementation MAY restrict the
allowed values for "name" to match the restrictions of ifName. allowed values for "name" to match the restrictions of ifName.
The IF-MIB allows two different ifEntries to have the same ifName. The IF-MIB allows two different ifEntries to have the same ifName.
Devices that support this feature, and also support the configuration Devices that support this feature, and also support the configuration
of these interfaces using the "interface" list, cannot have a 1-1 of these interfaces using the "interface" list, cannot have a 1-1
mapping between the "name" leaf and ifName. mapping between the "name" leaf and ifName.
skipping to change at page 30, line 33 skipping to change at page 30, line 33
default false; default false;
} }
} }
augment "/if:interfaces/if:interface" { augment "/if:interfaces/if:interface" {
when "if:type = 'l2vlan'"; when "if:type = 'l2vlan'";
leaf base-interface { leaf base-interface {
type if:interface-ref; type if:interface-ref;
must "/if:interfaces/if:interface[if:name = current()]" must "/if:interfaces/if:interface[if:name = current()]"
+ "/vlan:vlan-tagging = true" { + "/vlan:vlan-tagging = 'true'" {
description description
"The base interface must have vlan tagging enabled."; "The base interface must have vlan tagging enabled.";
} }
} }
leaf vlan-id { leaf vlan-id {
type uint16 { type uint16 {
range "1..4094"; range "1..4094";
} }
must "../base-interface" { must "../base-interface" {
description description
skipping to change at page 31, line 15 skipping to change at page 31, line 15
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">
<interface> <interface>
<name>eth0</name> <name>eth0</name>
<type>ethernetCsmacd</type> <type>ethernetCsmacd</type>
<location>0</location> <location>0</location>
<enabled>true</enabled> <enabled>true</enabled>
<if-index>2</if-index> <if-index>2</if-index>
</interface> </interface>
<interface> <interface>
<name>eth1</name> <name>eth1</name>
<type>ethernetCsmacd</type> <type>ethernetCsmacd</type>
<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:vlan-tagging>true</vlan:vlan-tagging>
xmlns="http://example.com/vlan">true</vlan-tagging> </interface>
<interface>
<name>eth1.10</name>
<type>l2vlan</type>
<enabled>true</enabled>
<if-index>9</if-index>
<vlan:base-interface>eth1</vlan:base-interface>
<vlan:vlan-id>10</vlan:vlan-id>
</interface> </interface>
</interfaces> </interfaces>
</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.
E.1. Router with Restricted Interface Names E.1. Router with Restricted Interface Names
skipping to change at page 32, line 22 skipping to change at page 32, line 22
ports. The slots for the cards are physically numbered from 0 to 3, ports. The slots for the cards are physically numbered from 0 to 3,
and the ports on each card from 0 to 7. Each card has fast- or and the ports on each card from 0 to 7. Each card has fast- or
gigabit-ethernet ports. gigabit-ethernet ports.
The implementation restricts the names of the interfaces to one of The implementation restricts the names of the interfaces to one of
"fastethernet-N/M" or "gigabitethernet-N/M". The "location" of an "fastethernet-N/M" or "gigabitethernet-N/M". The "location" of an
interface is a string on the form "N/M". The implementation auto- interface is a string on the form "N/M". The implementation auto-
initializes the values for "type" and "location" based on the initializes the values for "type" and "location" based on the
interface name. interface name.
The NETCONF server does not advertise the 'arbitrary-names' feature
in the <hello> message.
An operator can configure a new interface by sending an <edit-config> An operator can configure a new interface by sending an <edit-config>
containing: containing:
<interface nc:operation="create"> <interface nc:operation="create">
<name>fastethernet-1/0</name> <name>fastethernet-1/0</name>
</interface> </interface>
When the server processes this request, it will set the leaf "type" When the server processes this request, it will set the leaf "type"
to "ethernetCsmacd" and "location" to "1/0". Thus, if the client to "ethernetCsmacd" and "location" to "1/0". Thus, if the client
performs a <get-config> right after the <edit-config> above, it will performs a <get-config> right after the <edit-config> above, it will
skipping to change at page 33, line 19 skipping to change at page 33, line 19
and the ports on each card from 0 to 7. Each card has fast- or and the ports on each card from 0 to 7. Each card has fast- or
gigabit-ethernet ports. gigabit-ethernet ports.
The implementation does not restrict the interface names. This The implementation does not restrict the interface names. This
allows to more easily apply the interface configuration to a allows to more easily apply the interface configuration to a
different physical interface. However, the additional level of different physical interface. However, the additional level of
indirection also makes it a bit more complex to map interface names indirection also makes it a bit more complex to map interface names
found in other protocols to configuration entries. The "location" of found in other protocols to configuration entries. The "location" of
an interface is a string on the form "N/M". an interface is a string on the form "N/M".
The NETCONF server advertises the 'arbitrary-names' feature in the
<hello> message.
An operator can configure a new interface by sending an <edit-config> An operator can configure a new interface by sending an <edit-config>
containing: containing:
<interface nc:operation="create"> <interface nc:operation="create">
<name>acme-interface</name> <name>acme-interface</name>
<type>ethernetCsmacd</type> <type>ethernetCsmacd</type>
<location>1/0</location> <location>1/0</location>
</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 33, line 45 skipping to change at page 33, line 48
</interface> </interface>
E.3. Ethernet Switch with Restricted Interface Names E.3. Ethernet Switch with Restricted Interface Names
In this example, an ethernet switch has a number of ports, each port In this example, an ethernet switch has a number of ports, each port
identified by a simple port number. identified by a simple port number.
The implementation restricts the interface names to numbers that The implementation restricts the interface names to numbers that
match the physical port number. match the physical port number.
The NETCONF server does not advertise the 'arbitrary-names' feature
in the <hello> message.
An operator can configure a new interface by sending an <edit-config> An operator can configure a new interface by sending an <edit-config>
containing: containing:
<interface nc:operation="create"> <interface nc:operation="create">
<name>6</name> <name>6</name>
</interface> </interface>
When the server processes this request, it will set the leaf "type" When the server processes this request, it will set the leaf "type"
to "ethernetCsmacd" and "location" to "6". Thus, if the client to "ethernetCsmacd" and "location" to "6". Thus, if the client
performs a <get-config> right after the <edit-config> above, it will performs a <get-config> right after the <edit-config> above, it will
skipping to change at page 34, line 35 skipping to change at page 34, line 41
E.4. Generic Host with Restricted Interface Names E.4. Generic Host with Restricted Interface Names
In this example, a generic host has interfaces named by the kernel In this example, a generic host has interfaces named by the kernel
and without easily usable location information. The system and without easily usable location information. The system
identifies the physical interface by the name assigned by the identifies the physical interface by the name assigned by the
operating system to the interface. operating system to the interface.
The implementation restricts the interface name to the operating The implementation restricts the interface name to the operating
system level name of the physical interface. system level name of the physical interface.
The NETCONF server does not advertise the 'arbitrary-names' feature
in the <hello> message.
An operator can configure a new interface by sending an <edit-config> An operator can configure a new interface by sending an <edit-config>
containing: containing:
<interface nc:operation="create"> <interface nc:operation="create">
<name>eth8</name> <name>eth8</name>
</interface> </interface>
When the server processes this request, it will set the leaf "type" When the server processes this request, it will set the leaf "type"
to "ethernetCsmacd" and "location" to "eth8". Thus, if the client to "ethernetCsmacd" and "location" to "eth8". Thus, if the client
performs a <get-config> right after the <edit-config> above, it will performs a <get-config> right after the <edit-config> above, it will
skipping to change at page 35, line 30 skipping to change at page 35, line 38
identifies the physical interface by the name assigned by the identifies the physical interface by the name assigned by the
operating system to the interface. operating system to the interface.
The implementation does not restrict the interface name to the The implementation does not restrict the interface name to the
operating system level name of the physical interface. This allows operating system level name of the physical interface. This allows
to more easily apply the interface configuration to a different to more easily apply the interface configuration to a different
physical interface. However, the additional level of indirection physical interface. However, the additional level of indirection
also makes it a bit more complex to map interface names found in also makes it a bit more complex to map interface names found in
other protocols to configuration entries. other protocols to configuration entries.
The NETCONF server advertises the 'arbitrary-names' feature in the
<hello> message.
An operator can configure a new interface by sending an <edit-config> An operator can configure a new interface by sending an <edit-config>
containing: containing:
<interface nc:operation="create"> <interface nc:operation="create">
<name>acme-interface</name> <name>acme-interface</name>
<type>ethernetCsmacd</type> <type>ethernetCsmacd</type>
<location>eth4</location> <location>eth4</location>
</interface> </interface>
If necessary, the operator can move the configuration named If necessary, the operator can move the configuration named
 End of changes. 15 change blocks. 
24 lines changed or deleted 47 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/