Subject: [netmod] interfaces open issue

From: Martin Bjorklund <[email-masked]>
Date: Sun, 21 Oct 2012 15:59:46 +0200 (CEST)

Hi,

After the recent discussion about interface keying and what a location
is, Juergen suggested that we should try to examplify some common
implementation use cases, to see if people can agree that the model
covers these cases.

One concern was if the "location" leaf could be set to the
kernel-assigned name (e.g., "eth0").  I think the current text
allows this:

          "The device-specific location of the interface of a
           particular type.  The format of the location string
           depends on the interface type and the device.

but suggestions for improvements are welcome.

Below are two implementation examples:

* A well controlled router with interfaces named by a physical
  location.

Suppose a router has support for 4 cards, each with 8 ports.  The
cards are physically numbered from 0 to 3, and the ports on each card
from 0 to 7.  Each card has fast- or gigabit-ethernet ports.

The implementation restricts the names of the interfaces to one of
"fastethernet-N/M" or "gigabitethernet-N/M".  The "location" of an
interface is a string on the form "N/M".  The implementation
auto-initializes the values for "type" and "location" based on the
interface name.

An operator can configure a new interface by sending an <edit-config>
containing:

  <interface nc:operation="create">
    <name>fastethernet-1/0"</fastethernet>
    <mtu>1500</mtu>
  </interface>

When the server processes this request, it will set the leaf "type" to
"ethernetCsmacd" and "location" to "1/0".  Thus, if the client
performs a <get-config> right after the <edit-config> above, it will
get:

  <interface nc:operation="create">
    <name>fastethernet-1/0"</fastethernet>
    <type>ethernetCsmacd</type>
    <location>1/0</location>
    <mtu>1500</mtu>
  </interface>

If the client tries to change the location of this interface with an
<edit-config> containing:

  <interface nc:operation="merge">
    <name>fastethernet-1/0"</fastethernet>
    <location>1/1</location>
  </interface>

then the server will reply with an "invalid-value" error, since the
new location does not match the name.

*  A generic Linux host with (pluggable) interfaces named by the kernel
   and without easily usable location information.

In this case, the implementation allows arbitrary values for "name",
and the "location" is the kernel-assigned name for the interface.
Suppose the device has two ethernet interfaces, named "eth0" and
"eth1" by the kernel.  The configuration may look like this:

  <interface>
    <name>foo</name>
    <type>ethernetCsmacd</type>
    <location>eth1</location>
    ...
  </interface>

When the system boots, an implementation can for example early in the
boot procedure issue the command "ip link set eth1 name foo" in order
to set the name "foo" in the kernel.

If the kernel-assigned name changes from "eth1" to "eth2", e.g., due
to the installation of a third ethernet card, the operator can change
the "location" leaf of interface "foo", and the rest of the
configuration can be left intact, since all references to this
interface in the configuration is "foo".

/martin

---

From: Phil Shafer <[email-masked]>
Date: Sun, 21 Oct 2012 15:29:41 -0400

>interface in the configuration is "foo".

If your kernel is arbitrarily renaming your interfaces, you have a
much bigger issue.  I don't think this is a real world use case.
Modern systems are required to keep consistent SNMP index values,
so holding consistent interfaces names is relatively trivial.

I'm concerned we've moved from a "this is the way things work" POV
to one of "if we could rebuild the world from scratch, it should
have looked like this".  Operators are completely comfortable with
using existing device-assigned interface names.  I don't see a real
problem being solved by this "location" feature.

Thanks,
 Phil

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 22 Oct 2012 10:43:59 +0200

Speaking as technical contributor inline...

> new location does not match the name.

How would a generic configuration management application know that an
interface name like "fastethernet-1/0" should be used? (Note that
there is a " in the name value and that the get-config likely won't
return an nc:operation="create" attribute.)
 
> interface in the configuration is "foo".

I am not sure about this. You are saying the config above forces the
name foo by renaming the system's notion of an interface.  Is that
really what we want? Note that eth1 is gone from the system once you
do "ip link set eth1 name foo". I personally think that messing around
with system level interface names as side effects is ugly.

For me, the key question is whether we want an identity relationship
between the value of interface/name and the system's notion of an
interface. This is what you seem to have in mind. To allow for
interoperability, we should really answer this question in a very
clear way. Of course, saying 'yes' ties everything configured related
to an interface to the system's notion of an interface. 

A separate question for me is whether we support renaming of
interfaces. If we do, I think a separate mechanism should be
introduced or we should acknowledge this as a function to be
potentially added later.

The third question is how a generic configuration manager knows how to
properly configure new interfaces, that is how to learn about
interface names and how to generically extract the type and location
value out of the name or from some other resources. This likely ties
into the operational state discussion but I think we need to be
somewhat explicit about this if the goal is really to support generic
interoperable configuration management.

/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, 22 Oct 2012 11:01:55 +0200 (CEST)

Juergen Schoenwaelder <[email-masked]> wrote:
> interface name like "fastethernet-1/0" should be used?

out of scope for this document, just like the location values.  As
long as we are talking about physical interfaces, a generic
configuration management app really needs to get information about the
physical name/location from the operator that inserted the cable/card,
...

>  (Note that

Yes, copy&paste errors.

> with system level interface names as side effects is ugly.

This is just an example.  This is one way of doing it.  By setting the
configured name in the kernel, this name shows up in logs and other
interfaces.

> interface. This is what you seem to have in mind.

Personally, I think this is an implementation detail and that we
should stay out of it.

The idea was to provide an *example* so that people would easier
understand how it *could* be done.  I guess the risk with examples is
that people rather think it is the way it *should* be done...

> To allow for

One thing is renaming of interfaces in the configuration.  There is no
NETCONF support for this in general, and I don't think we should do
special rpc operations for some data models.

Another thing is renaming of interfaces on the system level.  I that
is out of scope.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 22 Oct 2012 12:14:00 +0200

> that people rather think it is the way it *should* be done...

I believe we need to decide this one way or the other if we want
interoperability. In your example, the interface/location value would
become meaningless. In another implementation, where interface/name
really just names the config not the interface, the interface/location
value would be the value that likely shows up in other management
interfaces. In the worst case, we will see something like

   <interface>
     <name>eth2</name>

where it becomes totally unclear how I relate this config snippet to
syslog messages etc. I believe we need to settle this if we want
interoperability.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 22 Oct 2012 13:39:38 +0200

Martin Bjorklund <[email-masked]> writes:

...

> physical name/location from the operator that inserted the cable/card,

I think this information should be available to the client through the NETCONF session, either as state data or via "show"-like RPC methods. That is, the "ietf-interfaces" module should address it.

> Personally, I think this is an implementation detail and that we

I think it is a fundamental question: Do we allow an indirection between the "name" key of an interface entry in the configuration and the system-assigned name? There are three possible answers to this:

1. The "name" key always has to be the same as the system-assigned name.

2. The "name" key as it is used in a NETCONF configuration is independent of the system-assigned name and the relationship is established by other data.

3. #2 on some systems and #1 on others.

I think we should decide between #1 or #2, and I personally prefer #2. The draft currently supports #3.

Note that #2 is completely unrelated to whether the system-assigned name can be changed or not - the indirection is always resolved within the NETCONF server implementation.

Lada

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 22 Oct 2012 14:09:05 +0200 (CEST)

> I believe we need to decide this one way or the other if we want

Can you elaborate on this?  How would the interoperability be hurt if
different implementations use different names in the kernel? 

> In your example, the interface/location value would
> become meaningless.

In common routers, the name carries both type and location
information, yes.

> In another implementation, where interface/name
> syslog messages etc.

 <interface>
   <name>00100101010100101010100101010100111</name>
   ....
 </interface>
 <interface>
      <name>00100101010100101110100101010100111</name>
   ....
 </interface>

So we need a rule that says "operators MUST choose meaningful names",
to complement your old rule "implementations MUST be bug-free" :)

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 22 Oct 2012 14:12:43 +0200 (CEST)

Ladislav Lhotka <[email-masked]> wrote:
> I think this information should be available to the client through the
> NETCONF session, either as state data or via "show"-like RPC
> methods. That is, the "ietf-interfaces" module should address it.

I prefer to do this later and leave it out of scope for now.  We need
to limit our work.

> I think it is a fundamental question: Do we allow an indirection
> between the "name" key of an interface entry in the configuration and
> the system-assigned name? There are three possible answers to this:
> 
> 2. The "name" key as it is used in a NETCONF configuration is
> independent of the system-assigned name and the relationship is
> established by other data.
> 
> I think we should decide between #1 or #2, and I personally prefer
> #2.

But in #2, what prevents one implementation to use the NETCONF name
also as the kernel-name?  I think #2 and #3 are the same.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 22 Oct 2012 14:36:12 +0200

> I prefer to do this later and leave it out of scope for now.  We need

OK - in fact, the solution may also depend on the outcome of the forthcoming general discussion on operational state data.
 
> also as the kernel-name?  I think #2 and #3 are the same.

It is the client who selects the name and #2 means the server has to accept it. With #3, a server working in the #1 mode would reject any "name" key that does not correspond to a system-assigned name of an existing interface.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 22 Oct 2012 14:51:01 +0200

> different implementations use different names in the kernel? 

I need to know whether interface/name is just a name for the
configuration (choosen by the operator or management application) or
whether it is the native system level name of the interface. These are
fundamentally different things. If I want to know the system level
interface name, I need to know where I get it from. Guessing one out
of two values is hampering interoperability.
 
> to complement your old rule "implementations MUST be bug-free" :)

You apparently did not get the point. So let me try to explain: If we
allow different semantics of interface/name and interface/location, I
have a hard time to correlate say syslog messages to configuration
snippets. Is the above interface what syslog reports as eth1 or eth2?
I think we need to settle this, one way or the other. For me, option
#3 is Lada's enumeration is a failure interoperability wise. It
actually forces to use #1 in practice since #2 can't be expected to be
supported generally.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 22 Oct 2012 14:54:49 +0200 (CEST)

> so holding consistent interfaces names is relatively trivial.

Agreed; but this is a real problem in linux.  I also don't think we
should worry about this; this is an implementation issue.

> have looked like this".

That's not the intention.  There are other devices that use
different names than what the kernel uses (see mail from Jeffrey
Lange
http://www.ietf.org/mail-archive/web/netmod/current/msg07322.html).

The are also devices that support arbitrary named interafces (I
believe Alcatel-Lucent routers do this for example).

The idea with this data model is to be flexible enough to allow such
implementations, while at the same time also allow implementations
such as junos that uses device-assigned names.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 22 Oct 2012 15:03:32 +0200 (CEST)

> of two values is hampering interoperability.

It seems there are two solutions to this problem:

1) Require the name in the config to be the same as the
   kernel-assigned name.

2) Allow an arbitrary name in the config, but add an additional config
   false leaf 'local-name' or 'system-name' or something.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 22 Oct 2012 15:32:42 +0200

> 1) Require the name in the config to be the same as the

I think this is potentially misleading. The kernel assigns a name,
which might be modified during system bootup. Hence, I prefer to talk
about system's name of the interface (once the system is out of the
boot sequence and running).
 
>    false leaf 'local-name' or 'system-name' or something.

Is it then required to support arbitrary names? Right now, the problem
for me is that I can not predict what the implementation will support.
If I use an arbitrary name, how do I link to the system's notion of
the interface name if the leaf is config false? I write it as a
location and read it back as local-name?

/js

---

From: Phil Shafer <[email-masked]>
Date: Mon, 22 Oct 2012 09:37:19 -0400

>   false leaf 'local-name' or 'system-name' or something.

Will systems be expected (required) to emit snmp/syslog/etc content
with the arbitrary-name or the system-name?

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 22 Oct 2012 15:39:06 +0200 (CEST)

> boot sequence and running).

Ok, rephrase this as:

  1) Require the name in the config to be the same as the
     system's name of the interface.

> Is it then required to support arbitrary names?

Just like before.  MAY restrict.

> Right now, the problem

You might write:

  name: foo
  type: ethernetCsmacd
  location 1/1

and read back

  system-name: fe-1/1

or on a linux-based system maybe you get back

  system-name: eth32

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 22 Oct 2012 15:48:58 +0200 (CEST)

> with the arbitrary-name or the system-name?

I think Juergen's idea was 'system-name'.  Of course, if an
implementation actually uses the arbitrary name as the system name
there is no difference.  My worry is that it will be difficult to wrte
the definition of 'system-name', since it applies to something we
don't standardize (syslog, log files, ...).  We'll probably not do it
correctly.

/martin

---

From: Phil Shafer <[email-masked]>
Date: Mon, 22 Oct 2012 09:48:19 -0400

>or on a linux-based system maybe you get back

It's not clear if you are talking about writing/reading config here.
If so, this seems like a poor API.  I shouldn't be making interface
instances to find the name of the thing I'm trying to make.

Instead, I should be invoking an RPC that returns names based on
criteria.  Like "what's the name of an unsed ethernet port at
location 1/1?" or "if I put an ATM FRU into location "2/2", what
would but the interface names?".

    rpc get-interface-names {
        input {
            leaf location { .... }
            leaf type { ... }
            leaf ephemeral { type boolean; }
            ...
        }
        output {
            list interface {
                key name;
                leaf name { ... }
                ...
            }
        }
    }

Or something like that....

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 22 Oct 2012 16:06:03 +0200 (CEST)

> It's not clear if you are talking about writing/reading config here.

To be clear:

  list interface {
    config true;
    key name;
    leaf name { ...}
    leaf type { ... }
    leaf location { ... }
    leaf system-name {
      config false;
      ...
    }
    ...
  }

So 'system-name' behaves like 'if-index' in the current draft - they
both map the configured interface to some other interface identifier.

> instances to find the name of the thing I'm trying to make.

You don't have to care about the system name until the interface has
been created.

> would but the interface names?".

This solves the problem that I wanted to punt for now...

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 22 Oct 2012 17:17:54 +0200

> Just like before.  MAY restrict.

Well, then it becomes my option #3, right? The same "name" key for an interface entry then would be accepted by some systems and rejected by others. This should IMO be avoided.

> or on a linux-based system maybe you get back

What's then the point of having the (mandatory) "location" leaf? The client could use "system-name" right away:

name: foo
type: ethernetCsmacd
system-name: fe-1/1 (or eth0)

The advantage is that semantics of "system-name" is natural and clear on all systems I know, while it is not always the case for "location".

BTW, note that even the "type" leaf is in fact unnecessary because the system knows very well what type its interface "fe-1/1" is.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 22 Oct 2012 17:27:00 +0200

> I think Juergen's idea was 'system-name'.  Of course, if an

Yes, it should be "system-name". The "name" key should be internal to the NETCONF configuration, pretty much as the "xml:id" attribute in XML documents.
 
> don't standardize (syslog, log files, ...).  We'll probably not do it

We could use the same definition as RFC 2863:

Device's local name for the interface (e.g., the name used at the device's local console).

Lada

---

From: Andy Bierman <[email-masked]>
Date: Mon, 22 Oct 2012 08:40:00 -0700

Hi,

So we are back to the 3 options?

2. The "name" key as it is used in a NETCONF configuration is independent
of the system-assigned name and the relationship is established by other
data.

We should not try to change the industry interface naming rules.
That is not the charter of this WG.  The WG was asked to
produce an interfaces model that real-world networking devices could use.

There have been several custom RPCs proposed that would allow
a client to get the system name for an interface, based on its type
and location.  That is an easily solved problem that the WG seems
to insist on ignoring.

For now, the current -06 text is close enough.
If the server does not like the name used in the create request,
then it returns an error. So what's the problem?

Andy

On Mon, Oct 22, 2012 at 4:39 AM, Ladislav Lhotka <[email-masked]> wrote:

> NETCONF session, either as state data or via "show"-like RPC methods. That
> is, the "ietf-interfaces" module should address it.
>
> >
> >
> >>  (Note that
> I think it is a fundamental question: Do we allow an indirection between
> the "name" key of an interface entry in the configuration and the
> system-assigned name? There are three possible answers to this:
>
> 2. The "name" key as it is used in a NETCONF configuration is independent
> of the system-assigned name and the relationship is established by other
> data.
>
> Note that #2 is completely unrelated to whether the system-assigned name
> can be changed or not - the indirection is always resolved within the
> NETCONF server implementation.
>
> Lada
>
> >

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 22 Oct 2012 17:47:39 +0200

> produce an interfaces model that real-world networking devices could use.

Nobody wants to change the industry interface naming rules, such a name would be present in "system-name".
The question only is whether it makes sense to allow for an indirection *internal to NETCONF*. This would enable re-assigning a configured stack of logical interfaces from one physical interface to another.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Mon, 22 Oct 2012 09:22:49 -0700

On Mon, Oct 22, 2012 at 8:47 AM, Ladislav Lhotka <[email-masked]> wrote:

> independent of the system-assigned name and the relationship is established
> by other data.
> >
> The question only is whether it makes sense to allow for an indirection
> *internal to NETCONF*. This would enable re-assigning a configured stack of
> logical interfaces from one physical interface to another.
>
>
I don't think we should continue tinkering on the interfaces model
to handle every possible corner-case.  If the server accepts
the name "fred" when creating an interface, then it is an
implementation detail what that means "internal to NETCONF".
If the syslog output says "eth0" then too bad.  Not in scope.

We should only deal with CRUD operations on interface entries
in this revision.

Lada

Andy

> independent of the system-assigned name and the relationship is established
> by other data.
> >

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 22 Oct 2012 20:37:05 +0200

> If the syslog output says "eth0" then too bad.  Not in scope.

So what do you suggest? Do nothing?

On 10 September you wrote [1]:

      I strongly object to undocumented vendor-specific value sets,
      as identified in this text:

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

      This is exactly the type of NMS data-silo design we are trying to
      avoid in standards.

This seems to contradict what you are saying now.

Lada

[1] http://www.ietf.org/mail-archive/web/netmod/current/msg07192.html

---

From: Andy Bierman <[email-masked]>
Date: Mon, 22 Oct 2012 11:50:20 -0700

> This seems to contradict what you are saying now.
Yes -- then I realized we could get around this restriction just
by adding a custom RPC that gives the client a mapping
between (type, location) and a name.  No data-silo.  Problem solved.

Lada

Andy

> between

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 22 Oct 2012 21:14:54 +0200 (CEST)

Ladislav Lhotka <[email-masked]> wrote:
> Well, then it becomes my option #3, right? The same "name" key for an interface
> entry then would be accepted by some systems and rejected by others. This
> should IMO be avoided.
> 
> > 
> >> Right now, the problem
> The advantage is that semantics of "system-name" is natural and clear on all
> systems I know, while it is not always the case for "location".

It is not trivial on linux, as we have seen earlier.  A location of
<rack>/<slot>/<port> is probably easier than eth32.  "mgmt" and "lan"
are probably easier that "eth1" and "eth0".

> BTW, note that even the "type" leaf is in fact unnecessary because the system
> knows very well what type its interface "fe-1/1" is.

Right, but we need something stable to base augmentation on.

/martin