Subject: [netmod] comments on interface-cfg-00 draft

From: Andy Bierman <[email-masked]>
Date: Mon, 11 Apr 2011 19:19:00 -0700

Hi,

just a couple comments, not a full review.

Consider the addition of 2 more nodes within /interfaces/interface (unique-id and see-also)

   leaf unique-id {
       description
           "Persistent operational data containing the vendor's unique (number-based) identifier.
            Similar to SNMP ifIndex except type uint64.";
      type uint64 { range "1..max"; }
      config false;
  }

  leaf-list see-also {
      description
          "List of pointers to other data structures related to the interface.
            For example, a vendor-specific interface entry corresponding to this entry.";
      type instance-identifier { require-instance false; }
      config false;
  }

admin-status:
           // FIXME: Can we say that changing ifAdminStatus does NOT
           //        change this object?  If not, is the opposite
           //        always true, i.e. that changing ifAdminStatus
           //        results in a change of this object (in running)?
           //        Or should we be silent?

Both ifAdminStatus and admin-status should reflect the instrumentation status.
This is an implementation detail.  The YANG module and SMIv2 module
define different access to the same conceptual data.  If the instrumentation
detects the interface status changes, each access method gets updated somehow
outside the scope of the standard.

How does this draft handle default physical interfaces that are created by the server
as config=true, but the client is not allowed to add or delete them?

Except for a couple administrative strings, there is not much to configure in this module.
Will there be any additional modules, such as configuring addresses?

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 12 Apr 2011 08:43:03 +0200

>       type uint64 { range "1..max"; }

Why is this needed? Are there really boxes with more than 2147483647
interfaces (the number range of ifIndex)? And what is "persistent
operational data" anyway?

/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: Andy Bierman <[email-masked]>
Date: Tue, 12 Apr 2011 00:24:50 -0700

> operational data" anyway?

There are boxes that use algorithms that assign unique interface IDs in a non-linear fashion
and 64 bits is needed.  Once assigned, one of these values do not change even if the box reboots.

This interface module does not configure anything worthwhile.
It relies completely on vendor extensions to be useful.
I do not see much standards value yet.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 12 Apr 2011 09:43:49 +0200

On Tue, Apr 12, 2011 at 12:24:50AM -0700, Andy Bierman wrote:
 
> There are boxes that use algorithms that assign unique interface IDs
> in a non-linear fashion and 64 bits is needed.  Once assigned, one
> of these values do not change even if the box reboots.

OK, I see. Could have been stated in the description. But, if I choose
to use UUIDs, then 64 bits may not be enough either...
 
> I do not see much standards value yet.

Yes, it relies on extensions to be useful. Such extensions do not have
to be proprietary and we even discussed creating an IP interface
configuration module that goes along with the core interface model at
the Prague IETF.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 12 Apr 2011 10:57:15 +0200 (CEST)

Hi,

>       type uint64 { range "1..max"; }

Is this common enough across vendors to standardize it?

The current approach in this module is to focus on configuration.  The
if-index is non-config, but only there to figure out the mapping to
ifIndex.  How would this new object be used?

>       type instance-identifier { require-instance false; }

The intended way to provide additional information is to augment the
interface list.  Since this is config false, I assume that the "other
datastructures related to the interface" are also non-config?

> outside the scope of the standard.

Note that admin-status is configuration.  Another thing is that
ifAdminStatus can have the value 'testing', which is not config, but
rather an "action" (or so it seems).  So the question is, if
ifAdminStatus is 'testing', how is that reflected in admin-status?  If
ifAdminStatus is set to 'up', does that mean that admin-status is also
up in the running configuration?

We discussed in Prague to change this leaf to a 'leaf enabled'.  I
think this would be a better approach.

> as config=true, but the client is not allowed to add or delete them?

I think the idea to let the server modify the configuration as
physical interfaces are added / deleted is very odd.  Suppose I have a
lock on the config when a physical interface is added.  Should the
server ignore this lock and create some config anyway?

I prefer the model where the configuration is separate from what is
really installed.  If there is an ethernet card in slot 4, but there
is no config for it, well then it is not configured.  It still shows
up in ifTable.  And the other way around, even if slot 4 is empty, I
should be able to configure "eth4" of type ethernet in location "slot
4".  This is pre-configuration.

This said, I think that this is a behavior of the device, and it is
orthogonal to the design of this data model.  If your device wants to
prepopulate some interface config and have logic that makes it
impossible to delete these interfaces, that is fine.

> Except for a couple administrative strings, there is not much to configure in

Right, this is of course a very conscious choice.  This module
provides a framework for interface config.  The main advantage is that
it defines how interfaces are referenced.  This is used e.g. in the
routing module.

> Will there be any additional modules, such as configuring addresses?

We discussed ip address configuration in Prague, and it seems likely
it is covered by our charter.  So I guess we just need someone to
write that module ;)

/martin