Subject: [netmod] js review of interfaces-cfg-02

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 6 Feb 2012 14:56:06 +0100

Hi,

I have a closer look at the interfaces document (as technical
contributor) and here are my comments. None of my comments is really 
a big thing - they are more possible suggestions for little
improvements. Overall, the document seems to be in a good shape.

- Section 3 uses the pyang tree format (which I personally like very
  much) but it might not be immediately clear what all the notation
  means, e.g. enabled? or if-index*. I think I figured this out myself
  but perhaps we would benefit from having a writeup of the tree
  format that we could easily refer to.

- I am wondering whether there should be a more detailed discussion
  how the leaf name related to ifName. There are character set
  differences and it seems also some uniqueness differences. We might
  help implementors by spelling things out more clearly.

- The leaf name has a length restriction of 1..255. This might be
  coming from ifName. Anyway, draft-carpenter-6man-uri-zoneid-00
  suggests a zoneid is 1..15 characters and it seems Linux and Mac OS
  X use a 16 byte character array (holding a NUL terminated string).
  Should there be text saying that using names longer than 15
  characters (well thinking ASCII for the moment ;-) may be
  problematic?  Or is this a non-issue since these interface names are
  usually generated automatically? Well, on Linux this command

    ip link set eth0 name abcdefghij123456

  actually fails with a name too long error.

- Should this text be more explicit:

  OLD

     This leaf contains the configured, desired state of the
     interface.  Systems that implement the IF-MIB use the
     value of this leaf to set IF-MIB.ifAdminStatus after an
     ifEntry has been initialized, as described in RFC 2863.";

  NEW

     This leaf contains the configured, desired state of the
     interface.  Systems that implement the IF-MIB use the
     value of this leaf to set IF-MIB.ifAdminStatus to up 
     or down after an ifEntry has been initialized, as 
     described in RFC 2863.";

- Should there be an example motivating/explaining why an interface
  might have multiple associated if-index values? In which situations
  does the YANG model have a different number of interfaces than the
  SNMP model?

- I was wondering about trap vs. notification - we meanwhile prefer
  the term notification but on the other hand the leaf
  link-up-down-trap-enable models a well established MIB object.
  But at least in the description, I think we should write

  OLD
     "Indicates whether linkUp/linkDown SNMP traps should be
      generated for this interface.

  NEW
     "Indicates whether linkUp/linkDown SNMP notifications should be
      generated for this interface.

- While looking at appendix D, I first spotted 192.168.1.1 which
  should probably be changed to 198.51.0.1 (see RFC5737) but then I
  was wondering whether the example should not better line up with the
  other example augmentations shown in appendix A-C, that is focusing
  on ethernet/vlan examples rather than IP examples (that are covered
  meanwhile in a separate document).

/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: Mon, 06 Feb 2012 22:22:50 +0100 (CET)

Hi Juergen,

Thank you for your review.  Comments inline.

>   format that we could easily refer to.

I agree.  This was also discussed earlier, and I have this text now:

  The data model in the module "ietf-interfaces" has the following
  structure, where square brackets are used to enclose a list's keys,

>   help implementors by spelling things out more clearly.

Actually, ifName isn't mentioned at all in the draft.  The 'name' leaf
is not mapped to ifName.  See more below.

>   actually fails with a name too long error.

Maybe we should have a text similar to 'description' for ifAlias:

     This leaf MAY be mapped to ifName by an implementation.  Such an
     implementation MAY restrict the value space of this leaf so that
     it matches the restrictions of ifName.

Why does draft-carpenter-6man-uri-zoneid-00 limit the length to 15?

>      or down after an ifEntry has been initialized, as 

Fixed.

>   does the YANG model have a different number of interfaces than the

The idea was to capture the following example from rfc2863 (in the
discussion about ifName :)

   For example, consider a router having an interface composed of PPP
   running over an RS-232 port.  If the router uses the name "wan1"
   for the (combined) interface, then the ifName objects for the
   corresponding PPP and RS-232 entries in the ifTable would both have
   the value "wan1".

An interface "wan1" in this data model would have two entries in the
if-index leaf-list.

>       generated for this interface.

Fixed.

>   meanwhile in a separate document).

Yes, I now removed the ip example completely.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 7 Feb 2012 08:48:53 +0100

> Why does draft-carpenter-6man-uri-zoneid-00 limit the length to 15?

No idea, I did not follow the discussion that led to this I-D. But it
seems interface names are commonly limited in size - that does not
mean we should hard code the limit of the day but making people aware
that there are common limits might be useful.

> An interface "wan1" in this data model would have two entries in the

So we have something like

ifType.3 = rs232
ifType.4 = ppp
ifName.3 = "wan1"
ifName.4 = "wan1"

with interface 4 stacked on interface 3 in the SNMP world and you
would model this as

interface {
  name "wan1";
  if-index 3;
  if-index 4;
}

in the NETCONF world? What is the type of this interface then? Would
it note make more sense to expose the structure 1:1, that is

interface {
  name "wan1-1";
  type "rs232";
  if-index 3;  
}

interface {
  name "wan1-2";
  type "ppp";
  if-index 4;  
}

Yes, this requires to somehow create unique name leafs but that is
also why I think some additional text concerning the relationship to
ifName is probably a good thing.

If we want to preserve the ifName mechanics to compose multiple
interfaces into a single "unit", we probably need an additional leaf
or so. (I am not sure how useful this is - on the other hand, many
systems represent an ethernet interface and the IP interface on top of
it as a single unit, e.g. eth0.)

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 07 Feb 2012 09:12:02 +0100 (CET)

> that there are common limits might be useful.

I agree.  Currently the text says

           A device MAY restrict the allowed values for this leaf,
           possibly depending on the type and location.

Do you want to add explicit text about the length (and maybe character
set?)

> it note make more sense to expose the structure 1:1, that is

But you would still use ifName wan1 for both these interfaces?  I
think that is a bit odd.  If we keep if-index a leaf-list, we
obviously can model the simple case with a 1-1 mapping, but we are
also flexible enough for 1-N mappings.  

> it as a single unit, e.g. eth0.)

I also do not know how useful this is.  But since the flexibility is
there in IF-MIB, I think it makes sense to keep it here.

What additional leaf(s) would be needed?

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 7 Feb 2012 11:17:47 +0100

> Do you want to add explicit text about the length (and maybe character

Well, this likely depends on what happens to
draft-carpenter-6man-uri-zoneid-00. So for now this text seems to be
good enough.
 
> also flexible enough for 1-N mappings.  

I strongly prefer to have a 1:1 relationship between interfaces in the
YANG data model and the SNMP data model. And that means the name leaf
can't be the same value as ifName in this case. This is why I changed
it to "wan1-1" and "wan1-2" in the example.

> What additional leaf(s) would be needed?

Essentially, the IF-MIB allows to have a single ifName value for
several (stacked) interfaces. This can be used to "hide" or "collapse"
interface layers on a CLI.  Since I prefer to have a 1:1 mapping
between interfaces in the YANG data model and interfaces in the IF-MIB
data model and since the 'name' leaf is a key identifying an interface
in the YANG data model, I think we would need an additional object to
model an ifName value that is shared by multiple interfaces. I am
actually not sure why all this is needed since we have stacking
relationships. If I have a ppp interface named say ppp0 running over
rs232, then using ppp0 is just good enough. And if you would have
multiple different ppp sessions over a single rs232 layer, that is you
multiplex N interfaces over 1, then the ifName magic won't work
anyway.

/js

PS: If we do not have a 1:1 mapping, lots of questions will pop up
    (e.g. what is the interface type of a combined rs232 and ppp
    interface, or what is the effect of setting an MTU on say a
    combined ethernet / ip tunnel interface and so on.

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 07 Feb 2012 12:42:24 +0100 (CET)

> it to "wan1-1" and "wan1-2" in the example.

Ok, I am fine with making this change.  If one interface in the YANG
model results in more than one ifEntry, if-index can point to the
"best match" (probably the top-most interface).  In order to figure
out the sublayers, the ifStackTable can be used.

NEW:

      leaf if-index {
        if-feature snmp-if-mib;
        type int32 {
          range "1..2147483647";
        }
        config false;
        description
          "The ifIndex value for the ifEntry represented by this
           interface.

           Media-specific modules must specify how the type is
           mapped to entries in the ifTable.";
        reference
          "RFC 2863: The Interfaces Group MIB - ifIndex";
      }

Currently ifName is not mentioned at all.  Do you think we
should mention it?

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 7 Feb 2012 13:30:05 +0100

> Currently ifName is not mentioned at all.  Do you think we

I think it is in general helpful to be clear about such
relationships. On most systems, I think we want the 'name' leaf and
ifName to be the same value for the same interface. But it is good if
we give implementors guidance so that they more easily can figure out
whether their system deserves some special treatment (e.g. because
they have interfaces without an ifName or interfaces with the same
ifName value, which is what the IF-MIB allows while the 'name' leaf
requires to provide a unique name.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 07 Feb 2012 16:07:22 +0100 (CET)

Juergen Schoenwaelder <[email-masked]> wrote:
> relationships.

Ok.  I suggest this:

      leaf name {
        type string {
          length "1..255";
        }
        description
          "An arbitrary name for the interface.

           For example, if a device has a single array of 8 ethernet
           ports, the name might be restricted to be on the form
          'ethN', where N is an integer between '1' and '8'.

           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.";
        reference
          "RFC 2863: The Interfaces Group MIB - ifName";
      }
      
Hmm, maybe we should remove the length restriction altogether?

It is probably also a good idea to add a new subsection in the main
text describing the relationship to IF-MIB:

  * Relationship to the IF-MIB
  
  If the device implements IF-MIB ^RFC2863^, each entry in the
  "interface" list is typically mapped to one ifEntry.  The "if-index"
  leaf contains the value of the corresponding ifEntry's ifIndex.
  
  In most cases, the "name" of an "interface" entry is mapped to
  ifName.  ifName is defined as an DisplayString ^RFC2579^ which uses
  a 7-bit ASCII character set.  An implementation MAY restrict the
  allowed values for "name" to match the restrictions of ifName.
  
  The IF-MIB allows two different ifEntries to have the same ifName.
  Devices that support this feature, and also support the
  configuration of these interfaces using the "interface" list, cannot
  have a 1-1 mapping between the "name" leaf and ifName.

Should we be more strict regarding this mapping?  For example, should
we say that an interface MUST be mapped to an ifEntry?  Are there
situations where an entry might be configured, but no ifEntry exists?
I was thinking about pre-provisioning, but even this can be
represented by an ifEntry with ifOperStatus 'lowerLayerDown'.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 7 Feb 2012 16:22:58 +0100

> represented by an ifEntry with ifOperStatus 'lowerLayerDown'.

This looks good to me. Forcing a 1:1 mapping by using MUST language
may be wrong, e.g., some devices seem to have internal interfaces for
the communication between the various components of the device that
are sometimes visible in the IF-MIB but surely not a subject of a
configuration interface exposing the primary functions of a device.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 07 Feb 2012 17:59:38 +0100 (CET)

> configuration interface exposing the primary functions of a device.

Yes, it is certainly the case that interfaces show up in ifTable even
though they are not explicitly configured.  I was thinking of the
other direction - are there cases where an interafce is configured,
but it does not show up in ifTable?

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 7 Feb 2012 19:17:30 +0100

> but it does not show up in ifTable?

I can't think of an example easily (except in situations where the
SNMP agent screws up handling new interface types but this is a bug
not something to design a data model for).

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 07 Feb 2012 20:05:20 +0100 (CET)

> not something to design a data model for).

Ok.  In any case, I think the suggested text is probably sufficient
(i.e., no "MUST map").

If you think I have addressed your comments (I do), I'll post a
new version of the draft.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 7 Feb 2012 21:09:47 +0100

> new version of the draft.

Yes, my comments have been resolved. It would be nice to see even
more reviews.

/js

PS: I am following up on the carpenter I-D to see whether we can get a
    consistent idea about interface names.

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 08 Feb 2012 08:30:03 +0100 (CET)

> Yes, my comments have been resolved. It would be nice to see even

I have posted a new version of the draft, addressing all comments
raised during the WGLC.

/martin