Subject: Re: [netmod] AD review of draft-ietf-netmod-interfaces-cfg-09

From: Martin Bjorklund <[email-masked]>
Date: Tue, 02 Apr 2013 23:01:49 +0200 (CEST)

Hi,

Benoit Claise <[email-masked]> wrote:
> Dear all,
> 
> Disclaimer:
> - If any of those points have been discussed on the mailing list, don't
> - hesitate to let me know.
> - I probably should have mentioned some of these documents during the last
> - call. Sorry. After a year in the new position, I'm still playing catch up
> - mode.
> 
> _CLARIFYING QUE__STION__S_
> 
> - Section 3.1 The interface List
> 
>    The data model for interfaces presented in this document uses a flat
>    list of interfaces.  Each interface in the list is identified by its
>    name.  Furthermore, each interface has a mandatory "type" leaf, and a
>    "location" leaf.  The combination of "type" and "location" is unique
>    within the interface list.
> 
> First time I read this, I thought the location was mandatory.
> However, it's not:
> 
>       +--rw interfaces
>          +--rw interface [name]
>             +--rw name                        string
>             +--rw description?                string
>             +--rw type                        ianaift:iana-if-type
>             +--rw location?                   string
> 
> Proposal:
> OLD:
> 	
>    Furthermore, each interface has a mandatory "type" leaf, and a
>    "location" leaf.
> 
> NEW:
>    Furthermore, each interface has a mandatory "type" leaf, and an optional
>    "location" leaf.

Ok, will fix.

> When I understood that the location is optional, I have some difficulties to
> understand the following sentence
> "The combination of "type" and "location" is unique within the interface list."
> when the location is an optional field.
> 
> - How does the mechanism above apply to subinterfaces? example: Interface
>   Ethernet 0.1?
>
> I believe it deserves some explanation. Now, it's true that the RFC 2863
> doesn't mention the notion of subinterface, and I believe that the notion of
> sub-layer (in RFC 2863) and interface layering (in
> draft-ietf-netmod-interfaces-cfg) notions don't apply to subinterfaces? I would
> be happy to stand corrected.

It all depends what you put in your definition of a subinterface.
This document does not mention subinterfaces at all.  It just talks
about how interfaces are layered.

> For example, how should I understand the following sentence, if we speak about
> an subinterface
> 
>    The "location" leaf is a string.  It is optional in the data model,
>    but if the type represents a physical interface, it is mandatory.
> 
> Does the subinterface really _represent _a physical interface?

If you have your subinterface represent a vlan, it would not.  In this
case, the subinterface would be layered on top of another (physical
maybe) interface.

> The "if-index" leaf contains the value of the corresponding ifEntry's ifIndex.
> 
> Shouldn't we stress this sentence with a MUST?

Ok, fixed.

> Let's face it, we still have many MIB modules for monitoring. We can use
> NETCONF/YANG for interface management, but we need the link to the ifIndex, to
> access the corresponding entries in the existing MIB modules

Agreed.  This is why this leaf is there :)

> - One of the real pain point of RFC 2863 is the ifIndex non persistence.
> 
>       "Its value ranges between 1 and the value of ifNumber.  The
>       value for each interface must remain constant at least from
>       one re-initialization of the entity's network management
>       system to the next re-initialization."
> 
> 
> Can we assume that the leaf name will remain constant after a
> "re-initialization of the entity's network management system", and that only
> the leaf if-index could change.

Yes!  With NETCONF/YANG, the config is persistently stored (which
config depends on the capabilities).

> Or we can't assume anything, and the NMS must rediscover everything. So same
> pain point as SNMP?
> Or should the NMS compare the config (which contains the ifName/leaf-name), and
> if they're unchanged after a reboot, the NMS just have query leaf if-index for
> the mapping to the MIB module?
> Could/should we say a few words about this in the draft?

I guess we could say that the if-index value may change, but in
general I am not too fond of redundant specifications in new
documents... I don't want to spell out all the semantics of ifIndex.
Maybe something like this:

  Note that the ifIndex value for a particular interface may change
  if the entity's network management system is re-initialized.

But I am not sure if this is what you meant?

> _EDITORIAL:_
> 
> - Section 2
> 
>    o  It is recognized that existing implementations will have to map
>       the interface data model defined in this memo to their proprietary
>       native data model.  The new data model should be simple to
>       facilitate such mappings.
> 
> What does new refer to? The YANG module in this document, or the extensions,
> referred by the text seen in the introduction
> 
>    It is expected that interface type specific
>    data models augment the generic interfaces data model defined in this
>    document.
> 
> I guess the YANG module in this document. So removing "new" would solve the
> confusion.

Ok, will fix.

> - You might to stress in the section 4 that the non HC counters are not
> - modeled.
> 
>        | in-octets                        | ifHCInOctets           |
>        | in-unicast-pkts                  | ifHCInUcastPkts        |
>        | in-broadcast-pkts                | ifHCInBroadcastPkts    |
>        | in-multicast-pkts                | ifHCInMulticastPkts    |
> 
> Btw, could this be a problem for sensors?

64 vs 32 bit counters were discussed in the thread starting at
http://www.ietf.org/mail-archive/web/netmod/current/msg06943.html.

>        leaf last-change {
>            type yang:date-and-time;
>            config false;
>            description
>              "The time the interface entered its current operational
>               state.  If the current state was entered prior to the
>               last re-initialization of the local network management
>               subsystem, then this node is not present.";
>            reference
>              "RFC 2863 <http://tools.ietf.org/html/rfc2863>: The Interfaces
>              Group MIB - ifLastChange";
>          }
> 
> From the date-and-time definition in RFC 6021, do I understand correctly that
> the date-and-time are absolute time (and not the equivalent of the sysUpTime,
> as mentioned in ifLastChange).
> What if the device doesn't have any absolute time, but simply the sysUpTime?
> Same question for leaf discontinuity-time

I think this was also discussed in the thread above.  It was suggested
that even smaller devices (that still implement NETCONF and these data
models) have support for absolute times these days.

> -  I discovered the following feature in the YANG module
> 
>      feature arbitrary-names {
>        description
>          "This feature indicates that the server allows interfaces to
>           be named arbitrarily.";
>      }
> 
> The only information I can find is
> 
>      If the device allows arbitrarily named interfaces, the
>      feature 'arbitrary-names' is advertised.
>         This leaf MAY be mapped to ifName by an implementation.
>      Such an implementation MAY restrict the allowed values for
>      this leaf so that it matches the restrictions of ifName.
> 
> As an implementor, I don't have much idea what is meant by this
> 'arbitrary-names' feature. Some explanatory text outside of the YANG module
> would be welcome.
> Note: it's only when I read the appendix E that I finally got the information I
> was after. Not sure why this is in the appendix... Up to you.
> At least, I would make it clear in which of the E.X examples, the "feature
> arbitrary-names" is advertised. I guess, from the title, E2 and E5

Ok, done.

/martin

---

From: Benoit Claise <[email-masked]>
Date: Mon, 08 Apr 2013 18:48:22 +0200

Hi Martin,

> about how interfaces are layered.
Having at least one example on how this module is supposed to work with 
sub-interfaces is required IMHO, specifically because of the location 
related sentences:

    The combination of "type" and "location" is unique within the interface list.

    ...

See below.

> case, the subinterface would be layered on top of another (physical
So should subinterface location be the location of the physical interface?
No, it can't because of

    The combination of "type" and "location" is unique within the interface list

You see, I'm slightly confused.
> config depends on the capabilities).
Actually, which RFC mentions that the config data is persistent?
> But I am not sure if this is what you meant?
Not really.
The interface "key" in SNMP is the ifIndex: the ifTable is rediscovered 
each time the device reboots.
The interface "key" in YANG is the interface name. How do I know, from 
the NETFCONF client point of view, if the interface name is persistent?
> http://www.ietf.org/mail-archive/web/netmod/current/msg06943.html.
Ok, if this is what the WG consensus...
> models) have support for absolute times these days.
Ok.

Regards, Benoit

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 08 Apr 2013 23:38:10 +0200 (CEST)

Benoit Claise <[email-masked]> wrote:
> sub-interfaces is required IMHO, specifically because of the location related
> sentences:
> 

No, you are right - the location would probably not be set for the
type of subinterface you have in mind.  There are examples of vlan
interfaces in the document.  You may call this a subinterface.  I
don't think there is any defintion of the term subinterface, but I may
be wrong.  So I don't really know what additional info you are looking
for.

> Actually, which RFC mentions that the config data is persistent?

6241 - but only implicitly.  For example:

   o  startup configuration datastore: The configuration datastore
      holding the configuration loaded by the device when it boots.

> The interface "key" in SNMP is the ifIndex: the ifTable is rediscovered each
> time the device reboots.
> The interface "key" in YANG is the interface name. How do I know, from the
> NETFCONF client point of view, if the interface name is persistent?

This is not different from any other configuration node - if a value
has been successfully written to a persistent datastore (startup or
running if startup is not supported), the value is there after a
reboot (unless it has been changed by some other client).  This should
be clear in 6241, but maybe it isn't...

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 17 Apr 2013 09:42:28 +0200 (CEST)

Hi Benoit,

Attached is the changes I propose as a result of your comments.  Do
you beleive that your comments are properly addressed by these
changes?

/martin
Index: .
===================================================================
--- . (revision 55158)
+++ . (working copy)

Property changes on: .
___________________________________________________________________
Modified: svn:mergeinfo
Merged /trunk:r55053,55061,55100
Index: lib
===================================================================
--- lib (revision 55158)
+++ lib (working copy)

Property changes on: lib
___________________________________________________________________
Modified: svn:mergeinfo
Merged /trunk/lib:r55053,55061,55100
Index: lib/cli/src/cli_cisco_show.erl
===================================================================
--- lib/cli/src/cli_cisco_show.erl (revision 55158)
+++ lib/cli/src/cli_cisco_show.erl (working copy)
@@ -38,6 +38,8 @@
-define(hide_in_submode(Cs), ?bit_is_set((Cs)#cs.cli_flags,
?F_CLI_HIDE_IN_SUBMODE)).

+-record('DOWN', {ref, type, object, info}).
+
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%
%%% Load configuration into transaction handler.
@@ -513,7 +515,9 @@
end,
Compact = use_compact_t(CiscoS, IKeypath, CsFlags),
if Compact, Written,
- ?deprecated_is_leaf(Cs) ->
+ ?deprecated_is_leaf(Cs) orelse
+ ?is_container(Cs) andalso
+ ?is_flattened(Cs) ->
?put_meta([sync]),
?put_chars(undefined, [$\n, sync]);
true ->
@@ -3704,14 +3708,22 @@
Visible = cs_trans:get_unhidden(Th1),
DiffStyle = false,
Self = self(),
- Pid = spawn_link(fun() -> get_diff_collect(Self, []) end),
- OutFun = fun(Chars) -> Pid ! {out, Chars} end,
- diff_configuration3(CliS, OutFun, Th1, Th2, NsList, IKeypath, Verbosity,
- _Astate=undefined, Visible, DiffStyle, Chroot,
- NoIndent),
- Pid ! done,
+ DiffPid =
+ spawn_link(
+ fun() ->
+ Pid = spawn_link(fun() -> get_diff_collect(Self, []) end),
+ OutFun = fun(Chars) -> Pid ! {out, Chars} end,
+ diff_configuration3(CliS, OutFun, Th1, Th2, NsList, IKeypath,
+ Verbosity, _Astate=undefined, Visible,
+ DiffStyle, Chroot, NoIndent),
+ Pid ! done
+ end),
+ MonRef = erlang:monitor(process, DiffPid),
receive
+ #'DOWN'{ref=MonRef, info=Info} when Info =/= normal ->
+ {error, crashec};
{accumulated, Chars} ->
+ erlang:demonitor(MonRef, [flush]),
{ok, Chars}
end.

@@ -3723,14 +3735,24 @@
Visible = cs_trans:get_unhidden(Th1),
DiffStyle = false,
Self = self(),
- Pid = spawn_link(fun() -> get_diff_collect(Self, []) end),
- OutFun = fun(Chars) -> Pid ! {out, Chars} end,
- diff_configuration1(CliS, OutFun, Th1, Th2, NsList, IKeypath, Verbosity,
- _Astate=undefined, Visible, DiffStyle, Chroot,
- NoIndent),
- Pid ! done,
+ %% We nned to do this since our caller may be trapping exits
+ DiffPid =
+ spawn_link(
+ fun() ->
+ Pid = spawn_link(fun() -> get_diff_collect(Self, []) end),
+ OutFun = fun(Chars) -> Pid ! {out, Chars} end,
+ diff_configuration1(CliS, OutFun, Th1, Th2, NsList, IKeypath,
+ Verbosity, _Astate=undefined, Visible,
+ DiffStyle, Chroot, NoIndent),
+ Pid ! done
+ end),
+ MonRef = erlang:monitor(process, DiffPid),
receive
+ #'DOWN'{ref=MonRef, info=Info} when Info =/= normal ->
+ {error, crashec};
{accumulated, Chars} ->
+ erlang:demonitor(MonRef, [flush]),
+ %% ?liof("Chars=~p\n", [Chars]),
{ok, Chars}
end.

Index: lib/java_conf_api
===================================================================
--- lib/java_conf_api (revision 55158)
+++ lib/java_conf_api (working copy)

Property changes on: lib/java_conf_api
___________________________________________________________________
Modified: svn:mergeinfo
Merged /trunk/lib/java_conf_api:r55053,55061

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 17 Apr 2013 09:52:30 +0200 (CEST)

Second try with proper diff!

/martin
< 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 17, 2013

Expires: August 10, 2013

Expires: October 19, 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 19, 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

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.

native data model. The data model should be simple to facilitate

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

name. Furthermore, each interface has a mandatory "type" leaf, and

an optional "location" leaf. The combination of "type" and

"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 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. 12 change blocks.

20 lines changed or deleted

35 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/

---

From: Benoit Claise <[email-masked]>
Date: Wed, 17 Apr 2013 16:52:30 +0200

Hi Martin,

In the new draft version you sent (actually the diff), there is just one 
issue that is not addressed.
> be wrong.  So I don't really know what additional info you are looking
What would be required is a new appendix with how the config at 
http://www.youtube.com/watch?v=KdQlwm6bIpM might be defined. 
Alternatively, the appendix C could be improved.
Specifically, the combination of type and location must be clearly 
labeled (or explained) for the primary interface and subinterfaces.

Regards, Benoit

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 17 Apr 2013 17:19:14 +0200

> labeled (or explained) for the primary interface and subinterfaces.

Is the problem in appendix C that the vlan-tagging is defined only for
interfaces with if:type = 'ethernetCsmacd' or if:type =
'ieee8023adLag' while the base-interface and vlan-id leafs only exist
for interfaces with if:type = 'l2vlan'? In other words, is your
question concerning which if:types a vlan interface would have to use?

Concerning the location, I would assume that it does not exist on the
vlan interface itself because the location is a property of the base
interface.

Perhaps all that is needed is to add another vlan example interface to
the config snipped shown in Appendix D.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 17 Apr 2013 22:49:30 +0200 (CEST)

> > labeled (or explained) for the primary interface and subinterfaces.

[...]

> the config snipped shown in Appendix D.

I think this makes sense.  I suggest we change the example in app. D
to:

<rpc-reply
    xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
    message-id="101">
  <data>
    <interfaces
        xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"
        xmlns:vlan="http://example.com/vlan">
      <interface>
        <name>eth0</name>
        <type>ethernetCsmacd</type>
        <location>0</location>
        <enabled>true</enabled>
        <if-index>2</if-index>
      </interface>
      <interface>
        <name>eth1</name>
        <type>ethernetCsmacd</type>
        <location>1</location>
        <enabled>true</enabled>
        <if-index>7</if-index>
        <vlan:vlan-tagging>true</vlan: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>
    </interfaces>
  </data>
</rpc-reply>

While doing this, I found and fixed a bug in a must expression in
Appendix C - quotes were missing around the literal 'true'.

Benoit, is this what you had in mind?

/martin

---

From: Benoit Claise <[email-masked]>
Date: Fri, 19 Apr 2013 10:55:16 +0200

> Benoit, is this what you had in mind?
Exactly. Thanks
Please publish a new version, and I'll progress the document.

Regards, Benoit