Subject: [netmod] Comments on draft-bjorklund-netmod-interfaces-cfg-00

From: Andy Bierman <[email-masked]>
Date: Fri, 10 Dec 2010 10:37:24 -0800

Hi,

   -  I like the augment-by-if:type design.

   -  This is a good enough starting point for the WG draft

   - an example of the interface list is needed;

   - the relationship between name and location is not clear
     to implementors; what info goes in what field?

   - An oper-status config=false leaf needs to be included.
     This should be an identityref, like if:type.
     Some basic oper-states should be defined here.
     A module augmenting the interface list should add
     its own oper-status identities as needed.

   - the SNMP coupling is not really explained anywhere;
     the specific conformance macro should be specified.
     e.g, is ifAdminStatus == admin-status; How can just 1 leaf out of the
     ifEntry be shared?  Clearly there is more overlap than 1 leaf.

   - I don't understand why if-index is a leaf-list.
     Why would a NETCONF interface show up as multiple SNMP interfaces?
     This raises IF-MIB divergence issues.

   - what about the ifStackTable? There is no example in the draft that shows
     the ifStackTable information for the interface list entries

   - what about ifUp and ifDown notifications?
     provisioning and other NETCONF app business logic may be interested
     in these events in order to adjust the config

   - what about a standard knob to request persistent if-index values?
     (uh-oh; that's not config true or false; doesn't fit the NETCONF model!
     Ignore it!)

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 10 Dec 2010 22:01:52 +0100

>     This raises IF-MIB divergence issues.

Some boxes have really interesting interface stacks (consider an ADSL
interface for example which on some boxes involves several ATM
sub-interfaces). While configuring an interface, you might actually
create multiple instances in the ifTable. The question then is whether
it is sufficient to refer to one of them or all of them.

/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: Fri, 10 Dec 2010 23:34:45 +0100 (CET)

Hi,

>   - an example of the interface list is needed;

Ok, I will add that.

>     to implementors; what info goes in what field?

The idea is that name is arbitrary, i.e. any name that the operator
chooses.  This could be a logical name like "acme-1" or reference to a
location like "fe-1/0/0".  But it is up to the operator.

The location, however, is not arbitrary; it is a string that refers to
a physical location.  The format of this string is device-specific.

>     its own oper-status identities as needed.

The current approach is that this module be confguration only, plus
the mapping to ifIndex.  The ifTable then contains all the operational
state and counters.  It can be accessed over SNMP, or, once we have
the std SMIv2 -> YANG mapping in place, over NETCONF.

>     e.g, is ifAdminStatus == admin-status;

The DESCRIPTION of ifAdminStatus says:

            "The desired state of the interface.  The testing(3) state
            indicates that no operational packets can be passed.  When a
            managed system initializes, all interfaces start with
            ifAdminStatus in the down(2) state.  As a result of either
            explicit management action or per configuration information
            retained by the managed system, ifAdminStatus is then
            changed to either the up(1) or testing(3) states (or remains
            in the down(2) state)."

The if-admin status object is the "configuration information".

I have a FIXME that needs to be resolved.  Can we say that if
ifAdminStatus is changed, that also means that if-admin-status is
changed, i.e. are these two objects really the same?   If so,
ifAdminStatus really modifies the configuration.  How does that
interact with the candidate?

OTOH, if ifAdminStatus is not config, but rather it changes the
(volatile) operational state, is that universally true?

>     How can just 1 leaf out of the

See above.  The idea was that just enough information is present to
map to ifTable.

There are some other read-write objects in IF-MIB that we can discuss;

  ifLinkUpDownTrapEnable: maybe we should include this one

  ifPromiscuousMode:  I don't think this object should be present in
              the config

  ifAlias: I'm not sure it is needed, since we have an arbitrary name.

>     This raises IF-MIB divergence issues.

The reason is that IF-MIB allows for this.  The ifName DESCRIPTION
says:

            The value of this
            object should be the name of the interface as assigned by
            the local device and should be suitable for use in commands
            entered at the device's `console'.

            [...]

            If
            several entries in the ifTable together represent a single
            interface as named by the device, then each will have the
            same value of ifName. 

So ifName allows the case that one named interface is mapped to
several entries in ifTable.

This said, maybe we could say that if-index is a single leaf, and that
it maps to the top-level ifTable entry for this configured interface.
But can we be sure that such a top-level entry always exists?  Can one
configured interface be represented as two ifTable entries on the same
level?

By using a leaf-list, this decision is up to the media-specific
modules.  Many will map 1-1 to ifTable, so in that case this leaf-list
will contain one single value.

>     the ifStackTable information for the interface list entries

See above.  Use ifStackTable for this.  I wanted to limit the scope to
configuration.

>     in these events in order to adjust the config

Philosophical question: Should we do NETCONF versions of all
interesting SNMP notifications?  In this particualr case we might do
"better" than the current SMIv2 versions, but maybe we should think
about a generic mechanism instead?

/martin