Subject: Re: [netmod] Last Call: iana-if-type-01 & interfaces-cfg-02 (20111121)

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 17 Dec 2011 11:38:49 +0100

On Fri, Nov 04, 2011 at 03:16:28AM -0700, David Kessens wrote:
> 
> Hi,
> 
> I would hereby like to start a Last Call for:
> 
> http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-02.txt
> http://tools.ietf.org/html/draft-ietf-netmod-iana-if-type-01.txt
> 
> The drafts seem to stabilized enough so it is time to determine whether
> they are ready to be send to the IESG for approval.
> 
> Please indicate your support by Nov 21 2011, but preferably before our
> working group session on Nov 15. I would like to see at least three reviews
> of the drafts to make sure that we have had sufficient review to move them
> to the next level so please indicate whether you have reviewed the current
> drafts when you state your support.

We only have received two supporting reviews and we (the chairs) feel
this is not enough to move this document forward. We need more reviews
and it would help a lot if there would even reports of people
implementing or planning to implement this.

More reviews please!

/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: Sat, 17 Dec 2011 10:02:05 -0800

>> I would hereby like to start a Last Call for:

I read both drafts and have a few comments.
I think they are ready to send to the IESG.
I have some concerns -- see below.

>> http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-02.txt

This draft is reasonable for a framework for interfaces.
It will have value if it gets filled in with augmenting definitions.
It is possible vendors will move their interface configuration
to the /interfaces/interface list, but not likely.  It is much more likely
this data structure will need to have a lot of standard modules defined
to make this more than an empty framework.

There are only 2 real 'knobs' defined -- 'mtu' and 'enabled' leafs.
The 'mtu' leaf is mandatory-to-implement and not always meaningful:

               This node might not be valid for all interface types.

               Media-specific modules must specify any restrictions on
               the mtu for their interface type.";

All the writable leafs seem to have a lot of vendor or context-specific 'wiggle-room'.
So much so, that I wonder how an application developer can really code anything
concrete based on this module.  The actual data node location (e.g., /interfaces/interface
vs. /acme:interface/acme:ethernet) is not a real factor in the implementation complexity.
Supporting 10 or 20 different data structure variants is the problem.

This module demonstrates the main challenge with standard configuration.
Integrating new config knobs into systems with existing proprietary solutions is hard.
A vendor cannot just remove the old knobs.  That is a non-starter.
Even brand new platforms usually need to support the legacy/proprietary solutions.

It is often expensive to re-design control code that assumes it is the only control path.
Allowing the device instrumentation to change underneath, and have both sets of
knobs instantly reflect the new config (in their own ways) is difficult.  It also assumes
that the data model mismatches are purely syntactic and not semantic.  This is usually wrong.

Perhaps some sort of instance-identifier 'pointers' would allow vendors to patch in
proprietary data models.

     leaf-list additional-object {
        type instance-identifier;
        description
          "List of pointers to other managed objects related to this interface.";
     }

The list of if-index values seems intended to provide the same sort of feature,
except it is SNMP-centric.

>> http://tools.ietf.org/html/draft-ietf-netmod-iana-if-type-01.txt

I assume this module will be updated at different times than the official IANA list
of interface enums.  There will be a window when some vendors may want to
use a newly assigned enum and it isn't published yet.  I guess this is a minor problem.

> implementing or planning to implement this.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 19 Dec 2011 09:04:14 +0100 (CET)

Hi Andy,

> It will have value if it gets filled in with augmenting definitions.

Agreed.

> implementation complexity.

Having one standard place for interfaces is also valuable for other
data models that need to reference an interface.  Without this, we end
up with solutions like the one in ietf-ipfix-psamp.

>          "List of pointers to other managed objects related to this

I am not sure exactly what problem this would solve and how it would
be used.  With the current model, vendors can always add such an
object if they need it.

> except it is SNMP-centric.

Not really; it is intended for co-existance with SNMP, so that you can
relate SNMP info with NETCONF/YANG.

> of interface enums.

No, the idea is to use the offical IANA list.  Originally we used an
identity for this instead, but the WG ruled that out in favor for the
current solution.

/martin