Subject: [netmod] interface keying - call for preferences

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 19 Sep 2012 13:44:52 +0200

Hi,

I like to close the interface keying issue. There has been a long
thread "interface and ip" and I think we have seen the various
arguments. The options that were identified are listed below:

a) We use what is currently in draft-ietf-netmod-interfaces-cfg-06.
   This supports implementations using opaque interface names as well
   as implementations using system-level interface names.

b) We use the change suggested in:

   http://www.ietf.org/mail-archive/web/netmod/current/msg07207.html

   This essentially removes any interface name restrictions.
   Implementations that choose to still have some restrictions would
   either declare a deviation or cheat.

c) The option of having a generic 'rename' extension for NETCONF along
   the lines of Phil's email:

   http://www.ietf.org/mail-archive/web/netmod/current/msg07181.html

   This clearly is outside the scope of our charter, we would simply
   assume that at some point in time there will be a generic way of
   renaming things.

d) Not explicitely proposed but mentioned in some emails is the option
   to have a 'rename-interface' RPC that renames interface config plus
   all leafrefs pointing to the old name. A special purpose version of
   c) which we could do now.

e) Introduce a new RPC such as <create-interface> that returns a
   suitable key to the client when a new interface is created.

Can people please state their preferences? Please be concise, lets try
to not repeat the whole discussion. Here is what I have so far:

Martin Bjorklund:

  I prefer (a) over (b); (c) is already out-of-scope, and I do not
  think we should do (d). (e) would be a really bad idea.

/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: Phil Shafer <[email-masked]>
Date: Wed, 19 Sep 2012 10:01:12 -0400

>   as implementations using system-level interface names.

+1

>   suitable key to the client when a new interface is created.

I don't like (e) but there will (at some future point, in some
future (chassis?) module) need to be a <list-interfaces> RPC
that can take a set of criteria and return a set of suitable
interfaces, including names and other information.  Something
like "give me the set of unused ethernet ports on slot 1 of
this chassis".  But that's future work; for now, (a) is the
answer.

Thanks,
 Phil

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 19 Sep 2012 17:41:36 +0200

Hi,

I prefer (b) but I could easily live with (a) if "local-name" was added as an *optional* leaf.

Lada
 
Juergen Schoenwaelder <[email-masked]> writes:

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

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

---

From: "Lisa Huang (yihuan)" <[email-masked]>
Date: Thu, 20 Sep 2012 17:34:58 +0000

b +1.

---

From: "Patrick Gili (pgili)" <[email-masked]>
Date: Thu, 20 Sep 2012 17:37:56 +0000

Choice A

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Wednesday, September 19, 2012 7:45 AM
To: [email-masked]
Subject: [netmod] interface keying - call for preferences

Hi,

I like to close the interface keying issue. There has been a long thread "interface and ip" and I think we have seen the various arguments. The options that were identified are listed below:

Can people please state their preferences? Please be concise, lets try to not repeat the whole discussion. Here is what I have so far:

Martin Bjorklund:

/js

---

From: Andy Bierman <[email-masked]>
Date: Thu, 20 Sep 2012 10:55:08 -0700

I prefer (a).
I also prefer that some sort of <name-interface>
operation is available if (a) is used:

     rpc name-interface {
        description
           "return an acceptable interface name for a given
            interface type and location.";
        input {
           leaf type {
              type ianaift:iana-if-type;
              mandatory true;
           }
           leaf location {
              type string;
           }
       }
       output {
          leaf name {
             type string;
          }
       }
   }

Andy

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Thu, 20 Sep 2012 18:06:40 +0000

a+1 .  
b would still be preferrable over c,d,

not sure about the suggested operation - I agree with the spirit (of making it easier to avoid issues with picking the "right" name particular in the presence of device name constraints that MAY  apply) but I am wondering if the particular output would change over time - this addresses cases where the name is a function of type and location which may not be necessarily a given - anyway, maybe some further discussion needed.   

--- Alex

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: Thursday, September 20, 2012 10:55 AM
To: Juergen Schoenwaelder; [email-masked]
Subject: Re: [netmod] interface keying - call for preferences

I prefer (a).
I also prefer that some sort of <name-interface> operation is available if (a) is used:

     rpc name-interface {
        description

Andy

---

From: Xiang Li <[email-masked]>
Date: Fri, 21 Sep 2012 08:55:18 -0500

I prefer (a). I am also thinking if we could add a
mandatory-false and config-false leaf "xyz-pattern"
node that may serve as a hint to acceptable interface
name for a given interface type and location (if any).
For example:

leaf name-pattern {
        mandatory false; --not really needed here
        config false
        type string;
        description "acceptable interface name regular string pattern";
      }

Similarly we can add another mandatory-false leaf:
leaf description-pattern {
        mandatory false; --not really needed here
        config false	
        type string;
        description "acceptable description name regular string pattern";
      }

Then we can remove the description " This leaf MAY be mapped to ifAlias by
an implementation...." etc.

The idea is similar to Andy's proposed <name-interface> operation without
actually introducing an additional RPC. However I am not even sure this kind
of helper nodes are even recommended by YANG design principles.

--Xiang

-- 
--Xiang Li
Web: www.seguesoft.com
Voice: 1 (872) 216-2610
Mobile: 1 (217) 472-4108

---

From: Andy Bierman <[email-masked]>
Date: Fri, 21 Sep 2012 07:19:19 -0700

> of helper nodes are even recommended by YANG design principles.

IMO this will not work because there are no input parameters possible,
and a static pattern doesn't represent the acceptable choices.

The <name-interface> operation may even be too simplistic because
it assumes all interfaces can be named knowing the type and
location.  This probably covers most interface naming schemes though,
which is why I suggested it.

Andy

---

From: Xiang Li <[email-masked]>
Date: Fri, 21 Sep 2012 09:19:19 -0500

I realized this might not necessary if the <error-message> in the 
<invalid-value> error
can somehow be made to contain what is acceptable values.  Can we even 
enforce the
content of a  <error-message >?

<error-message >
            Name is not valid. Valid pattern are xxxx  <http://tools.ietf.org/html/rfc6241#page-9192>
</error-message>

--Xiang

-- 
--
Xiang Li
Web: www.seguesoft.com
Voice: 1 (872) 216-2610

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 21 Sep 2012 09:58:34 -0700

Hi -

I can't help but think that we're thinking about this in
if not the wrong way, at least in a way that makes things
harder than they need to be.

When one is stitching a stack together, there ends up being
a web of service users and service providers, connected
by references from one more-or-less arbitrarily named
interface to another.  Where this hits a rock in the current
discussion is when that reference is to the "bottom" of the
stack, which is really just the hardware - a particular connector
or cable.  Where I think our thinking has been subtly wrong is
in thinking that the set of possible values for that lowest-level
reference might somehow be *syntactically* more constrained
that the other references in the stack.

It is NOT more constrained syntactically.  The constraint
is an *existence* constraint, modulo what the system allows
for provisioning of non-existent interfaces.  The set of things
that might possibly exist in a given system might be describable
using a syntactic pattern, but there's really no reason to handle
this any differently from other references.

My point is that the ultimate lowest "level" - the set of possible
cable or connector identifiers, is *not* configuration data as
we've been using the term here, although an implementation would
hopefully make this information available.  Values from this set make up
the possible *references* from the lowest configurable layer in
the stack.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 21 Sep 2012 09:58:09 -0700

> the possible *references* from the lowest configurable layer in

Going back to your most relevant list:

   1) the system-supplied "local" identifier for an interface
   2) the administratively-assigned identifiers used to stitch stacks together
   3) "Post-its" for things like "customer" or "cable-id"

Are you saying we should not worry about (1)?
The system will pre-populate the factory-default config with
these interfaces, so an <edit-config> create operation
is not that common?

Andy

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 21 Sep 2012 11:23:07 -0700

Hi -

> From: "Andy Bierman" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Friday, September 21, 2012 9:58 AM

No.  Here's the subtle difference.  We've been talking as though
the system-supplied "local" identifier for an interface is something
that is a property of the object we've been calling an interface. 

<pre>
+-------------------------+
| Interface Object        |
|            "local id"   |
|            other stuff  |
+-------------------------+
</pre>

As we've already seen, this approach leads to multiple conundrums.
What I'm suggesting is that we look at it this way:

<pre>
+-----------------------------+
| Interface Object            |          +------------------------------+
|            service provider----------->|                              |
|            other stuff      |          | "hardware" interface, e.g.   |
+-----------------------------+          | physical socket, cable, etc. |
                                         +------------------------------+
</pre>

In other words, the position where we've been putting "local id" and its
ilk should really be just a reference.  I put "hardware" interface in
quotes, because with virtual machines, etc., etc. it's not really hardware,
but its provisioning, installation, etc. tends to take on a very different
character from just bringing up another stack.  This sort of approach
works really nicely with tunneling and other encapsulations, btw.

Of course, some will just say "it's turtles all the way down"; you can
view this as a bug or a feature, but the reality is that eventually that
reference will be to something physical and in a sense not configurable
at the level of virtualization in question.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 24 Sep 2012 11:06:55 +0200

> that is a property of the object we've been calling an interface. 

I think we already have your second model. The "hardware" interface is
identified by (type, location):

   The "location" leaf is a string.  It is optional in the data model,
   but if the type represents a physical interface, it is mandatory.
   The format of this string is device- and type-dependent.  The device
   uses the location string to identify the physical or logical entity
   that the configuration applies to.  For example, if a device has a
   single array of 8 ethernet ports, the location can be one of the
   strings "1" to "8".  As another example, if a device has N cards of M
   ports, the location can be on the form "n/m", such as "1/0".

   How a client can learn which types and locations are present on a
   certain device is outside the scope of this document.

The debate, as I understand it, started around the names of interface
objects. Operating systems usually assign names to hardware interfaces
and the question came up how the name of the interface object relates
to the system's notion of an interface name, i.e.:

- Is it allowed that implementations restrict the name of an interface
  object to the system's notion of an interface name?

The current I-D says yes, others argued for no. If the answer is yes,
how can a generic management applications learn about name
restrictions used by the underlying operating system? (Note that we
already have "how a client can learn which types and locations are
present on a certain device is outside the scope of this document",
making a truely generic client already impossible.)

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 24 Sep 2012 12:02:53 +0200

> making a truely generic client already impossible.)

I think the difference is this:

"type" and "location" (= the anchor to a hardware interface in Randy's picture) can be adjusted in one place whereas "name" may appear in multiple places and all occurrence have to be adjusted at the same time. Also, "name" is a list key so there are additional restrictions imposed by YANG.

My only problem with the (type, location) pair in the role of that anchor is that on some platforms it is not the natural way of identifying interfaces and it may require additional effort to figure out the hardware interface to which (type, location) refers.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 24 Sep 2012 12:20:24 +0200

On Mon, Sep 24, 2012 at 12:02:53PM +0200, Ladislav Lhotka wrote:

> My only problem with the (type, location) pair in the role of that
> anchor is that on some platforms it is not the natural way of
> identifying interfaces and it may require additional effort to
> figure out the hardware interface to which (type, location) refers.

So could the operating systems's notion of an interface name be a
valid 'location' value if there is no better one known? That is on
Linux, I would have

    <interface>
      <name>acme</name>
      <description>Interface for customer acme.</description>
      ...
      <type>ethernetCsmacd</type>
      <location>eth0</location>
    </interface>

but I could also choose to name the interface "eth0" if I really want
to.

    <interface>
      <name>eth0</name>
      <description>Interface for customer acme.</description>
      ...
      <type>ethernetCsmacd</type>
      <location>eth0</location>
    </interface>

Of course, the two 'eth0' strings here have rather different semantics
and persistence properties.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 24 Sep 2012 12:39:26 +0200 (CEST)

>       <location>eth0</location>

If I understand what Lada wrote correctly, this doesn't work.  Once
you have renamed 'eth0' to 'acme' in Linux, the 'eth0' name is gone.

On linux, it seems you must use PCI bus address for location, in order
to be truly generic.  Of course, a vendor that happens to use linux as
the OS for its device can choose a more user-friendly location string.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 24 Sep 2012 13:00:41 +0200

> the OS for its device can choose a more user-friendly location string.

Yes, but this is the core of the question for me. Where is the
system's notion of an interface name visible? On Linux, the OS refers
to an interface by a name, not by location. If we accept that OS level
name as a location, then after renaming 'eth0' to 'acme' all you have
to do is update the <location> element. Lada's original concern was
that eth0 might become eth1 and vice versa if you update the kernel
and reboot and he wanted to minimize the amount of config impacted by
such a change.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 24 Sep 2012 13:28:24 +0200 (CEST)

Juergen Schoenwaelder <[email-masked]> wrote:
> to do is update the <location> element.

What exactly does this mean, and who is "you" above?  Do you mean that
all the client has to do is set <location> to "acme"?   But that would
imply that the end config is:

     <interface>
       <name>acme</name>
       <description>Interface for customer acme.</description>
       ...
       <type>ethernetCsmacd</type>
       <location>acme</location>
     </interface>

This can't be used by the system after a reboot, since the interface
will be assigned the name 'eth0' (or whatever) by the kernel, before
it can be renamed.

> Lada's original concern was

Right.  It seems there are some ways to handle this in linux, all
based on some notion of a "location"; pci address or mac address,
using startup scripts or udev rules.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 24 Sep 2012 13:57:25 +0200

> will be assigned the name 'eth0' (or whatever) by the kernel, before

Sure, but if you mess with the system, you either need to do it
completely or accept the consequences. My point was that system level
interface renaming out of scope for us.

> using startup scripts or udev rules.

So anything against allowing the OS level interface name in the
location?

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 24 Sep 2012 13:58:53 +0200 (CEST)

> So anything against allowing the OS level interface name in the

People are free to use whatever works for them.  If OS level interface
name works - fine.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 24 Sep 2012 14:19:17 +0200

> you have renamed 'eth0' to 'acme' in Linux, the 'eth0' name is gone.

Yes, so in this case the location value also has to be changed from "eth0" to "acme".

> the OS for its device can choose a more user-friendly location string.

I think Juergen's proposal could work, too, although it is IMO better to avoid potential differences in location semantics. I assume that every device uses some kind of native interface identifiers and these should appear in a clearly named leaf like "local-name". Location can stay as an optional leaf, perhaps even state data - on Linux it could contain e.g. the PCI address.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 24 Sep 2012 14:40:39 +0200

> will be assigned the name 'eth0' (or whatever) by the kernel, before

If the system interface name is changed via init scripts, then "acme" is already the right (and only) name when the NETCONF server starts. Maybe you are assuming that the system name is to be changed via NETCONF, but that's IMO out of scope for this discussion - an RPC would probably be better for this. 

> using startup scripts or udev rules.

Even these addresses might change, e.g. when you replace the network card or motherboard.

Lada

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 24 Sep 2012 11:36:27 -0700

Hi -

> From: "Juergen Schoenwaelder" <[email-masked]>
> Sent: Monday, September 24, 2012 2:06 AM
...
> making a truely generic client already impossible.)

I think it's necessary to take it just a little bit farther.

The "types and locations" are really properties of the currently invisible
"hardware" interfaces.

An administrator *may* choose to propagate some of that information
one layer higher in the stack, but it's not logically necessary to do so.
That's one reason why opinions diverge.

This leads me to believe that it's unltimately simpler and cleaner to
make those currently invisible "hardware" interfaces (e.g. physical
connector) visible as "managed objects", even if not configurable ones.
Taking this extra tiny step eliminates the temptation to look at the constraints
on the reference (and it really is a reference, not a property) as syntactic ones,
as well as reducing the degree of layering violation.  (And it goes a long
way toward making generic clients more feasible.)

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 25 Sep 2012 09:22:08 +0200

On Mon, Sep 24, 2012 at 02:19:17PM +0200, Ladislav Lhotka wrote:
> 
> I think Juergen's proposal could work, too, although it is IMO
> better to avoid potential differences in location semantics. I
> assume that every device uses some kind of native interface
> identifiers and these should appear in a clearly named leaf like
> "local-name". Location can stay as an optional leaf, perhaps even
> state data - on Linux it could contain e.g. the PCI address.

I prefer to have one configurable reference to the 'hardware interface
identifier as know by the underlying operating system' instead of two.
Perhaps all we need to do is to rename the leaf location and revise
its description and make it clear that the name leaf really carries an
administratively assigned name. The concept of a location is not
really well developed anyway, we can punt that until we ever seriously
think about containment a la ENTITY-MIB.

Now we need a good name, "location" seems to restrictive and
"local-name" is somewhat unclear as well (what is local?). Any
ideas?

And I think we need to capture some of the outcomes of this
discussion. For example, that operating system level changes of
interface names affect the 'yet-to-be-named' leaf identifying a
hardware interface but not the 'name' of an interface. The definition
of an RPC to initiate operating system level changes of interface
names might be a future addition but has been left out for now.

And perhaps we should add examples showing in addition to flat hw
interface numbers and structured hw interface identifiers also the use
of os-level interface names. Perhaps also text discussing how
administratively assigned interface names can help moving configs
around easily if either the physical connection changes or the hw
interface identifier changes (e.g., due to firmware upgrades or
physical movement of line cards).

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 25 Sep 2012 10:43:21 +0200

> think about containment a la ENTITY-MIB.

Agreed.

> "local-name" is somewhat unclear as well (what is local?). Any

RFC 2863 uses the term "local name" in this sense. Another candidate could be "native-name".

+1

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 25 Sep 2012 17:11:48 +0200 (CEST)

> identifier as know by the underlying operating system' instead of

Me too.  And I do not think it would be a good idea to add another
indirection by using something like 'local-name'.

> Perhaps all we need to do is to rename the leaf location

If there is a better name, fine.  But I think this is probably more
important:

> and revise
> its description

But the question is what we need to add.

Note that there are really *two* leafs that together refer to the
correct hardware port - 'type' and 'location'.  'type' is needed as a
separate leaf since we base augmentation on the type.

> and make it clear that the name leaf really carries an
> administratively assigned name.

Hmm, does "administratively assigned name" imply "arbitrary"?  If not,
what exactly does "administratively assigned" mean?

> The concept of a location is not
> really well developed anyway

I still think that you always can pick something relevant to use as a
location.  It seems most router vendors have been able to do this for
some time now...

I don't think we can find something more precise, that will be useful
across vendors / OSes.

> hardware interface but not the 'name' of an interface.

I don't think this is true in general.  And implementing things this
way leads to a pretty bad user experience - for example, if you use
the kernel-assigned name as a 'location' on a linux system we have
seen that things might break down if you upgrade the kernel etc.  This
is a well-known problem.  So, the simple solution is to NOT use the
kernel-assigned name for hw-identiifcation purposes.

> The definition

I am actually still a bit confused.  It is not clear to me what the
real problem with the current 'location' leaf is.  This thread started
with a consensus call for some options that really boils down to
whether the name MUST be arbitrary or not.  It seems to me that most
people preferred (a) - i.e., allow implementations to restrict the
name of the interface.

Lada wanted an optional config false leaf 'local-name', which I guess
makes sense if the system implements a "mapping table" between the
configured name and the kernel-assigned name.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 26 Sep 2012 08:23:18 +0200

> what exactly does "administratively assigned" mean?

Yes, it means an administrator assigns a name that he/she finds
suitable, not necessarily a name the underlying system dictates.
 
> I don't think we can find something more precise, that will be useful

Some router vendors encode module/port numbers in interface names, but
the result is really an encoding of location information into a name
not just location information. The current text does not seem to imply
that en5 or eth5 would be suitable 'location' values. I believe what
we really store in the leaf is the system's local name of an
interface, which might or might not include location information.

> kernel-assigned name for hw-identiifcation purposes.

But as you mentioned before, system level software can make sure
interfaces are properly named. I think we need to tie into the local
system's interface name since this is visible on other interfaces,
e.g.  MIBs, CLIs, SYSLOG. A kernel randomly naming interfaces is bad
but the problem is bigger than just YANG data models.

> configured name and the kernel-assigned name.

You argue that location can't use the system's interface name as a
value since that value might change arbitrarily still you argue that
the system's interface name be used to name an interface even though
that can change arbitrarily.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 26 Sep 2012 08:56:43 +0200 (CEST)

> suitable, not necessarily a name the underlying system dictates.

So going back to your original poll in this thread, it seems you
prefer alternative (b), right?

> that en5 or eth5 would be suitable 'location' values.

I think the current text allows this.  It says:

           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.

Doesn't that imply that a device can pick any format it likes?

> I believe what

My concern with this approach is that you most probably get
information overlap.  In order to configure an interface, you'll
need to do:
 
   name: acme
   type: ethernetCsmacd
   local-name: eth1

With the current proposal, there is overlap only if the device imposes
the name restrictions:

   name: fastethernet-1/0
   type: ethernetCsmacd
   location: 1/0

If the device does not impose any restrictions, you can do:

   name: acme
   type: ethernetCsmacd
   location: 1/0

> e.g.  MIBs, CLIs, SYSLOG.

I think that a device that implements these arbitrary interface name,
will use the arbitrary name "locally", i.e., this arbitrary name will
show up in SNMP, CLI, SYSLOG.  This is how it works on Linux,
according to lada.

> A kernel randomly naming interfaces is bad

Agreed.

> value since that value might change arbitrarily

I argue that IF the kernel-assigned name can change "arbitrarily",
THEN it is a bad idead to use the kernel-assigned name for
identification purposes.

If the kernel-assigned name does not change "arbitrarily", then it can
be used.

> still you argue that

I hope I didn't say that :)

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 26 Sep 2012 13:56:28 +0200

> But the question is what we need to add.

Device-specific name of the interface which is used, e. g., at the device's local console.
 
> separate leaf since we base augmentation on the type.

I don't think so - local-name, or whatever it is called, should be sufficient. The 'type' can stay and may still be used in the same way for augments.

> what exactly does "administratively assigned" mean?

I think it should be arbitrary, and the name needn't exist outside NETCONF.

> I don't think we can find something more precise, that will be useful

Platform-specific data with more descriptive names can be augmented, for Linux it could be "pci-address". However, this information is no more crucial.

> kernel-assigned name for hw-identiifcation purposes.

What I think is important is not to use the native name as the key of the "interface" list. It that name is in another leaf, it is easy to update the configuration if the native name changes. 

> configured name and the kernel-assigned name.

I have never said that 'local-name' can be config false because it realizes the binding between the (arbitrary) name of an 'interface' entry and physical interface.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 27 Sep 2012 08:21:33 +0200

> information overlap.  In order to configure an interface, you'll

It is not always so. The Ethernet interface on my Mac carries the name "en0" and FreeBSD uses names like "em0" or "bge1". Even on Linux we can have this:

   name: acme
   type: ethernetCsmacd
   local-name: foo

> If the device does not impose any restrictions, you can do:

On devices that do not use the concept of location consistently this means that the configuration contains no reliable info about the local interface name.
 
> show up in SNMP, CLI, SYSLOG.  This is how it works on Linux,

We have to distinguish between two cases:

1. Local name of an interface can be changed to an arbitrary string at the system level.

2. The "name" key of the "interface" list is arbitrary.

My point is that 2 should hold for any implementation of the interfaces module, independently of 1.
The actual local name always has to be filled in the local-name leaf, no matter what the local name is - this realizes the link between NETCONF interface configuration and a physical interface. And the link can be easily updated in one place if the local name changes.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 27 Sep 2012 09:16:56 +0200 (CEST)

Ladislav Lhotka <[email-masked]> wrote:
> It is not always so. The Ethernet interface on my Mac carries the name
> "en0" and FreeBSD uses names like "em0" or "bge1".

But these are the names of the drivers, for the specific types.

> Even on Linux we
> can have this:

We *can*, but it depends on the implementation.

> On devices that do not use the concept of location consistently this
> means that the configuration contains no reliable info about the local
> interface name.

This is why a config false leaf 'local-name' would be useful.

> The actual local name always has to be filled in the local-name leaf,
> no matter what the local name is - this realizes the link between
> NETCONF interface configuration and a physical interface. And the link
> can be easily updated in one place if the local name changes.

This means that the user somehow must figure out the kernel-assigned
name for say the 4th ethernet port on the device.  With a location
leaf, you move this task to the implementation (*), and let the user
just specify the location "4".  This design at least makes it possible
to do a user-friendly product...

(*) it would still be up to each implementation.  An implementation
that wants to use the kernel-assigned name as hw-reference can still
do that.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 27 Sep 2012 17:41:37 +0200

> But these are the names of the drivers, for the specific types.

Right, so in this case type and location is not sufficient for determining the local name.

> This is why a config false leaf 'local-name' would be useful.

It depends. If we agree that the client should be able to assign an arbitrary key to an interface entry, then there has to be a way for linking the configuration that is in the "foobar" entry of the "interface" list to a particular physical interface. You propose to use "type" and "location" for this purpose, and then "local-name" can be config false. In contrast, I propose that "local-name" be used as the link, so it has to be config true, but type and location can now be config false.

> to do a user-friendly product...

OK, I see your point. It works fine on platforms with well-defined hardware organization but less so on messy platforms such as the generic PC.

The advantage of "local-name" is that it exists on all platforms, whilst "location" is not universal.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Thu, 27 Sep 2012 09:04:34 -0700

On Thu, Sep 27, 2012 at 12:16 AM, Martin Bjorklund <[email-masked]> wrote:
> name for say the 4th ethernet port on the device.

We could easily define a data-model specific operation
like <name-interface> so the client would not have to
guess this kernel-assigned name.

We do not need any new naming layers, and we cannot
change the vendor-specific nature of interface naming.
The current draft is good enough, and hopefully the
problem of standardized interface naming can be solved later.

I want the physical interfaces to have the system-assigned name
as the key.  I think kernel upgrade induced interface renumbering
is too rare to change the simple design we have now.

> With a location

Andy

---

From: "Lange, Jeffrey K (GE Energy)" <[email-masked]>
Date: Thu, 27 Sep 2012 16:29:26 +0000

> Sent: Thursday, September 27, 2012 12:05 PM
> To: Martin Bjorklund
> Cc: [email-masked]
> >> It is not always so. The Ethernet interface on my Mac carries the
> >> name "en0" and FreeBSD uses names like "em0" or "bge1".
> >
> >> > With the current proposal, there is overlap only if the device
> >> > imposes the name restrictions:
> >> >
> >> >    name: fastethernet-1/0
> >> >    type: ethernetCsmacd
> >> >    location: 1/0
> >> >
> >> means that the configuration contains no reliable info about the
> >> local interface name.
> >
> >> NETCONF interface configuration and a physical interface. And the
> >> link can be easily updated in one place if the local name changes.
> >
> We could easily define a data-model specific operation like <name-interface>
> so the client would not have to guess this kernel-assigned name.
> 
> We do not need any new naming layers, and we cannot change the vendor-
> specific nature of interface naming.
> The current draft is good enough, and hopefully the problem of standardized
> interface naming can be solved later.
> 
> I want the physical interfaces to have the system-assigned name as the key.  I
> think kernel upgrade induced interface renumbering is too rare to change the
> simple design we have now.
> 

This makes for a very un-user-friendly interface.  On our products, the external Ethernet ports are silk-screened as "LAN1" and "LAN2".  However, under the hood they are eth0 and eth1.  Requiring the user to configure /interfaces/interface{eth0} is not very obvious (or even worse /interfaces/interface{ppp0} for the case of a 3G cellular radio).  In my opinion, a much cleaner approach would be to have it as /interfaces/interface{lan1} or interface{cellular} and have the location / local-name (or whatever you want to call it) contain the value "eth0".  Whether this is config true or false doesn't matter much to us as these devices will be pre-populated at factory build time, and no user will be able to delete/change them (other than IP etc...).

We also need to support user-created virtual interfaces such as bridged devices in this case, the user would create a new interface{my_bridge}.  The user shouldn't care what the underlying device name for this is, which is where a config-false location/local-name would be useful.

I do agree that we shouldn't need to focus any attention on the kernel auto renaming devices on boot.. if you have a system that does this you have more general configuration issues you need to deal with at a system level!

-Jeff

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 28 Sep 2012 15:21:08 +0200

> prefer alternative (b), right?

I see value in enabling the separation. And I see value in figuring
out how to implement stuff on generic boxes where the notion of an
interface location does not exist (e.g., what would be the location of
a wireless stick plugged via a hub into a usb port?). The OSes I am
most familiar of assign names (more or less dynamically) and it might
be sensible to use that OS name of an interface as its 'location'
identifier. Sure, if you build a well controlled product, you can
rename stuff such that interfaces carry meaningful location
information.
 
> Doesn't that imply that a device can pick any format it likes?

Perhaps this was intended to be included, but in that case I would
prefer to make that explicit. What about being explicit and adding
something to the following paragraph? "Yes another example, if a
device natively identifies interfaces via devices names, the location
can be of the form 'en1' or 'eth2'.
 
> information overlap.  In order to configure an interface, you'll

No overlap I can spot here.

> If the device does not impose any restrictions, you can do:

What matters is that I can correlate information I receive from
different management interfaces. If syslog tells me "device eth1
entered promiscuous mode", I love to find eth1 somewhere in the
config. If I have to ping a link-local address from the router, I love
to be able to look into the config to lear that I can write ping6
fe80::2e0:fe47:81ff:c935%eth1. I think you assume the system level
name is the name stored in interface/name. But then that leaf's
description starts with "An arbitrary name for the interface."  This,
of course, makes moving the config from one system level interface to
another somewhat complicated. This is where Lada started. I am
meanwhile more concerned that we leave it open where the OS level
interface name shows up and I am worried that if implementations do
this very differently, management applications will have to maintain
several variations of code to configure interfaces and they will have
to dynamically discover what works. I think that is bad.

/js

---

From: Andy Bierman <[email-masked]>
Date: Fri, 28 Sep 2012 08:23:46 -0700

....

> This makes for a very un-user-friendly interface.  On our products, the
> external Ethernet ports are silk-screened as "LAN1" and "LAN2".  However,
> under the hood they are eth0 and eth1.  Requiring the user to configure
> /interfaces/interface{eth0} is not very obvious (or even worse
> /interfaces/interface{ppp0} for the case of a 3G cellular radio).  In my
> opinion, a much cleaner approach would be to have it as
> /interfaces/interface{lan1} or interface{cellular} and have the location /
> local-name (or whatever you want to call it) contain the value "eth0".
>  Whether this is config true or false doesn't matter much to us as these
> devices will be pre-populated at factory build time, and no user will be
> able to delete/change them (other than IP etc...).
>
>

It is your implementation choice to label something LAN1
and call it eth0 in CLI/NETCONF/SYSLOG output.

I guess I meant "system selected name", not literally
the "kernel selected name".  If the system will only accept
LAN1 or LAN2 as the name leaf values, then the system should
present all info using those names.

> We also need to support user-created virtual interfaces such as bridged
> devices in this case, the user would create a new interface{my_bridge}.
>  The user shouldn't care what the underlying device name for this is, which
> is where a config-false location/local-name would be useful.
>
>
So don't restrict the name values that are accepted.
That is the issue here.  BTW, I said PHY interfaces,
not virtual interfaces.

I don't have any objections to a config=false local-name.
I'm not sure each implementer would know what to put there.

I do agree that we shouldn't need to focus any attention on the kernel auto
> renaming devices on boot.. if you have a system that does this you have
> more general configuration issues you need to deal with at a system level!
>
> -Jeff
>
>

Andy