Subject: [netmod] interface and ip

From: Martin Bjorklund <[email-masked]>
Date: Wed, 05 Sep 2012 09:55:34 +0200 (CEST)

Hi,

I have published new versions (-06) of these documents.  The biggest
change is that all IF-MIB counters are added to the interface
document.

Please review to make sure the wglc comments are properly addressed.

/martin

---

From: "Lisa Huang (yihuan)" <[email-masked]>
Date: Thu, 6 Sep 2012 05:03:54 +0000

Martin,

I have two comments for the choice of ipv4 subnet.

First comment: The ipv4 container has a choice of subnet which I believe
you mean choice of prefix-length or netmask. Adding a case statement will
make the choice more clear. Here is the choice snippet.

	choice subnet {
             default prefix-length;
             description
               "The subnet can be specified as a prefix-length, or,
                if the server supports non-contiguous netmasks, as
                a netmask.

                The default subnet is a prefix-length of 32.";
             leaf prefix-length {
               type uint8 {
                 range "0..32";
               }
               default 32;
               description
                 "The length of the subnet prefix.";
             }
             leaf netmask {
               if-feature non-contiguous-netmasks;
               type inet:ipv4-address;
               description
                 "The subnet specified as a netmask.";
             }
           }

>From the RFC, I could not derive the syntax means "prefix-length or net
mask" when case statement is omitted. Here are some statement I quote from
RFC6020 7.9.2:

"The "case" statement is used to define branches of the choice."

"As a shorthand, the "case" statement can be omitted if the branch
contains a single "anyxml", "container", "leaf", "list", or
"leaf-list" statement. In this case, the identifier of the case node
is the same as the identifier in the branch statement."

However, 0..n leaf can be the substatment of choice in section 7.9.1.

Second comment: This is more a question than a comment. Prefix-length has
type uint8, and netmask has type ipv4-address. Does ipv4-prefix in
ietf-inet-types has any relationship with these two leaves?

Thanks,

Lisa

On 9/5/12 12:55 AM, "Martin Bjorklund" <[email-masked]> wrote:

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

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 06 Sep 2012 13:05:48 +0200 (CEST)

Hi,

"Lisa Huang (yihuan)" <[email-masked]> wrote:
> make the choice more clear.

Ok.

> Here is the choice snippet.
> 
> 	choice subnet {
>              default prefix-length;
>              description

Right.  So, it says that if you have a branch with a single leaf, such
as:

   choice subnet {
     case prefix-length {
       leaf prefix-length {
         ...
       }
     }
     case ...
   }

you can omit the case statement:

   choice subnet {
     leaf prefix-length {
         ...
     }
     case ...
   }

> ietf-inet-types has any relationship with these two leaves?

The ipv4-prefix type could have been used to indicate the subnet in
the 'prefix-length' case, but then you'd have to enter duplicate info,
and it wouldn't work with the 'netmask' case.

With the ipv4-prefix type:

   <ip>10.0.0.1</ip>
   <subnet>10.0.0.0/24</subnet>

With the current model:

   <ip>10.0.0.1</ip>
   <prefix-length>24</prefix-length>

/martin

---

From: "Lisa Huang (yihuan)" <[email-masked]>
Date: Thu, 6 Sep 2012 15:34:43 +0000

Thanks, Martin. I think the example in the RFC need to be updated to make
it more clear. Not related to this I-D though.

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 07 Sep 2012 14:57:33 +0200

Hi,

I have some concerns regarding transferrability of interface configurations. For example, one may want to replace a router with a similar one from a different vendor, or simply replace an Ethernet card with another brand. In both cases, the names of physical interface(s) might change.

It would be nice to be able to take the old configuration and use it with the new hardware, perhaps after making a few trivial changes. With the current interfaces module it is not that easy because:

1. interface name is the list key, so it cannot be updated in place,

2. all references via "interface-ref" will have to be updated.

So my suggestion is to introduce an indirection by means of adding another leaf, e.g. "physical-name". "name" will remain the list key but it will be an arbitrary client-selected identifier. 

Another option is to have an extra list in the role of a translation table: The server could fill in the real physical interface names (= state data, and keys of this list), and the client would add an interface-ref to each entry defining the mapping.

Lada

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

---

From: "Patrick Gili (pgili)" <[email-masked]>
Date: Fri, 7 Sep 2012 13:14:25 +0000

Lada,

I think you are referring to the equivalent of the ifAlias defined by the IF-MIB. There is mention of it in the ietf-interfaces YANG module, but as part of the description element, which I thought was somewhat strange.

-Patrick

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ladislav Lhotka
Sent: Friday, September 07, 2012 8:58 AM
To: [email-masked]
Subject: Re: [netmod] interface and ip

Hi,

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 7 Sep 2012 15:31:40 +0200

> I think you are referring to the equivalent of the ifAlias defined by the IF-MIB. There is mention of it in the ietf-interfaces YANG module, but as part of the description element, which I thought…

Yes, but an important point is also what the list key is. My suggestion is to have a non-volatile client-selected name (which is indeed what ifAlias is) as the key for the interface list. 

Lada

---

From: "Patrick Gili (pgili)" <[email-masked]>
Date: Fri, 7 Sep 2012 13:33:01 +0000

Lada,

It is always possible to create another list that references interfaces but keys off something like description or alias or whatever.

-Patrick

-----Original Message-----
From: Ladislav Lhotka [mailto:[email-masked]] 
Sent: Friday, September 07, 2012 9:32 AM
To: Patrick Gili (pgili)
Cc: [email-masked]
Subject: Re: [netmod] interface and ip

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 07 Sep 2012 15:38:52 +0200 (CEST)

Ladislav Lhotka <[email-masked]> wrote:
> Hi,
> 
> I have some concerns regarding transferrability of interface
> configurations. For example, one may want to replace a router with a
> similar one from a different vendor, or simply replace an Ethernet
> card with another brand. In both cases, the names of physical
> interface(s) might change.
> 
> It would be nice to be able to take the old configuration and use it
> with the new hardware, perhaps after making a few trivial
> changes. With the current interfaces module it is not that easy
> because:
> 
> So my suggestion is to introduce an indirection by means of adding
> another leaf, e.g. "physical-name". "name" will remain the list key
> but it will be an arbitrary client-selected identifier.

If the key "name" is truly arbitrary and all implementations MUST
handle this, then a "physical-name" is not really needed.  Note that
we already have "type" and "location", so with an arbitrary name you
could create a new interface like this:

   <name>my-new-interface</name>
   <type>ethernet</type>
   <location>0/1</location>

If a vendor needs an indirection or not would be an implementation
detail.  A vendor could of course also add a "internal-name" config
false leaf through an augmentation, if it helps the operator.

The original reason for the text on "name" 

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

was to make it easier to implement.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 07 Sep 2012 15:43:02 +0200 (CEST)

Hi,

"Patrick Gili (pgili)" <[email-masked]> wrote:
> It is always possible to create another list that references
> interfaces but keys off something like description or alias or
> whatever.

The problem Lada is describing is that the key in the interface list
will be used by other data models referring to a specific interface.
So these interface names will be scattered all over, when you do <get>
or <get-config>.  This means that if vendor X enforces a different
naming scheme than vendor Y, it will be difficult to move
configuration snippets from one vendor to the other.  With arbitrary
names this would not be a problem.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 7 Sep 2012 15:45:37 +0200

> It is always possible to create another list that references interfaces but keys off something like description or alias or whatever.

Do you mean that I can use "description" for referring to an interface via a leafref node? This is true but the draft recommends to use the interface-ref type for such references.

Lada

---

From: Phil Shafer <[email-masked]>
Date: Fri, 7 Sep 2012 09:41:15 -0400

Ladislav Lhotka writes:
>Yes, but an important point is also what the list key is. My suggestion is to have a non
>-volatile client-selected name (which is indeed what ifAlias is) as the key for the inte
>rface list. 

Forcing use of ifAlias would be fairly shocking to your user
population and the benefits would only be when swapping devices
from distinct vendors, which turns out to be a fairly rare event.
And even when that event occurs, the real underlaying device name
would need to be fixed, limiting that benefit.

And forcing this would result in >99.999% of operators using an
alias identical to the underlaying interface name ;^)

What might be more apropros would be something like what we've just
added to junos: a wildcarded regex-based name replacement operation,
so I can say "turn all references to '10.1.2.3' to '10.4.5.6'".
It's more useful, generic, and allows one to make global change/replace
operations like interface name substitutions without requiring
non-specific user-defined interface names.

Thanks,
 Phil

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 7 Sep 2012 16:24:01 +0200

>   <name>my-new-interface</name>

This is fine for routers where interface names are formed directly from "type" and "location". But for a device based on Linux it would be useful to see (and be able to configure) that it is "eth0" rather than an Ethernet interface at a certain PCI address.

Also, "physical-name" (or "local-name") could be mapped to "ifName" and "name" to "ifAlias". The mapping proposed in the module (name->ifName, description->ifAlias) looks like an ugly hack. 

>         possibly depending on the type and location.

Yes, this and the following paragraphs in the description of "name" suggest pretty strongly that it is supposed to be the real interface name. IMO such a practice should be discouraged.

> was to make it easier to implement.

Well, implementing such an indirection is quite trivial.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 7 Sep 2012 16:39:44 +0200

> population and the benefits would only be when swapping devices

Do you mean my user population or your user population? :-)

> from distinct vendors, which turns out to be a fairly rare event.

Imagine a network port fails and you just want to reconnect the cable to the next free port.

On Linux it happens quite easily that a newly added card gets "eth0" and the old "eth0" becomes "eth1". Also, I believe, on BSD system the interface name encodes the device driver name.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 9 Sep 2012 17:46:52 +0200

> was to make it easier to implement.

So we have devices that can arbitrarily rename interfaces and we have
devices that cannot. Since we likely won't succeed in making all
devices support interface renaming, I think we should go for a data
model where devices that can rename interfaces can take advantage of
it but other devices are fine to implement our data model without
adding such a feature to their OS. Do we agree with that?

If so, what is missing or broken with the current I-D? On my linux
box, you really invoke an operation to rename an interface. But we do
not have operations that can be triggered when a configuration is
loaded. So we would have to have a mapping. Can we make it a separate
data model feature that only those who really care implement? Or even
better, we leave it out and if in say 2-3 years there are multiple
proprietary implementations of such a mechanism, someone can go an
standardize an extension of the data model?

/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: Ladislav Lhotka <[email-masked]>
Date: Mon, 10 Sep 2012 12:00:06 +0200

> adding such a feature to their OS. Do we agree with that?

I think that renaming an interface is more a user interface issue and could be implemented as an optional "alias" leaf. My comment was more about making the key of the "interface" list, which is also the link anchor for the "interface-ref" type, non-volatile. It could even be an opaque value.
As soon as the key is used in a configuration, it is difficult to change it.

> standardize an extension of the data model?

For all implementations, the interface key should either be the local name, which may change or disappear if the hardware changes, or something else. This should probably be decided now.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 10 Sep 2012 12:22:32 +0200

On Mon, Sep 10, 2012 at 12:00:06PM +0200, Ladislav Lhotka wrote:
> I think that renaming an interface is more a user interface issue
> and could be implemented as an optional "alias" leaf. My comment was
> more about making the key of the "interface" list, which is also the
> link anchor for the "interface-ref" type, non-volatile. It could
> even be an opaque value.  As soon as the key is used in a
> configuration, it is difficult to change it.

The leaf is config true and hence the volatility of this is determined
by the datastore. I am still not sure what your concern really
is. Here is the definition:

         leaf name {
           type string;
           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.
              If a NETCONF server that implements this restriction is
              sent a value that doesn't match the restriction, it MUST
              reply with an rpc-error with the error-tag
              'invalid-value'.";
         reference
	      "RFC 2863: The Interfaces Group MIB - ifName";
       }

Do you think this text prevents implementation on devices that have
the ability to rename interfaces? I think this definition allows to
have an interface configuration "foo" and when I rename 'eth5' to
"foo" it will apply just fine, no?

> For all implementations, the interface key should either be the local name, which may change or disappear if the hardware changes, or something else. This should probably be decided now.

So your issue really is that the current definition does not force one
or the other? I personally doubt we can do this if we want to achieve
wide implementation and deployment of this standard. What systems can
or can not do wrt. interface names is not likely to change just
because a new network management data model comes along.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 10 Sep 2012 14:36:11 +0200

> is. Here is the definition:

Assume a physical interface with name "X". You configure it with IP addresses, and then create some tunnels, VLANs, bonds, packet filters etc. - configuration of all these refer to "X". Now you want to transfer that configuration to another physical interface "Y". Currently the only option (and also the only option with most CLIs) is to copy-and-paste the configuration from entry "X" to entry "Y" and also change all references from "X" to "Y". If the interface key was an indirect identifier "Z", you could just say that it now represents physical interface "Y" instead of "X" and no other changes will be necessary.

> "foo" it will apply just fine, no?

The problem I am talking about is that you have an interface configuration for "eth0" and you want to make it into configuration of "eth1". You cannot rename the key of a list entry using <edit-config>, and even if you could, some "interface-ref" leafs could be left in the configuration pointing to the old name. Of course, it would work if the device allows for renaming "eth1" to "eth0", but I don't think this is generally possible - in JUNOS and IOS the interface names are formed from the type and location.

It would be possible to have an RPC method "rename-interface", which could also find all occurrences of the old name in a configuration and change them to the new one, as Phil suggested. However, I think it is cleaner to have the indirection explicitly in the data model because the semantics of RPC methods cannot be precisely defined.

> because a new network management data model comes along.

The NETCONF server could resolve indirect references to local interface names, so the indirection doesn't require the device to have the native ability to rename interfaces.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 10 Sep 2012 14:48:17 +0200

> Assume a physical interface with name "X". You configure it with IP addresses, and then create some tunnels, VLANs, bonds, packet filters etc. - configuration of all these refer to "X". Now you wan…

Whenever you choose a value for a key that is referenced in other
parts of the data model, you will have this same problem, no? Have we
operational experience tell us that is an important enough problem to
be solved? If so, would a generic mechanism to rename keys and
everything pointing to it not be the way to go?

> It would be possible to have an RPC method "rename-interface", which could also find all occurrences of the old name in a configuration and change them to the new one, as Phil suggested. However, I…

I am not sure what the issue with RPC semantics is. That said, I am
still not clear what exactly the change is that you propose.

> The NETCONF server could resolve indirect references to local interface names, so the indirection doesn't require the device to have the native ability to rename interfaces.

NETCONF will co-exist with other management interfaces for a long time
to come and even though the NETCONF might to magic translations, if at
the end your eth1 configuration does not relate to you eth1 data you
see on your CLI or the SNMP interface, we might have created a problem
rather than solved one. But then, I have not understood the details of
your proposal yet, so I do not know for sure.

/js

---

From: Andy Bierman <[email-masked]>
Date: Mon, 10 Sep 2012 08:09:46 -0700

I strongly object to the notion of replacing keys in YANG lists.
When you change keys, you delete the old entry and create a new one.
Period.  That is the only interpretation.

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

This is exactly the type of NMS data-silo design we are trying to
avoid in standards.
It is less objectionable to do this sort of vendor-specific variant
for config=false.
But for config=true, it means an application developer will have to
figure out from trial and error
or perhaps some ad-hoc vendor documentation what values are allowed on
each server.

This does not promote multi-vendor interoperability.
The YANG data type definition is normative.  The server must implement
the specified syntax (modulo too-big errors, etc.).  There cannot be some
secret patterns that the server accepts that are not documented
in the YANG type-stmt.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 10 Sep 2012 17:20:18 +0200

> parts of the data model, you will have this same problem, no? Have we

No. If the local (native) name of an interface changes, or the client wants to move the configuration between two interfaces, it is sufficient to issue an edit-config, where the interface entry is selected by the key ("Z" in my example) and the value of "local-name" is changed to "Y".

> everything pointing to it not be the way to go?

Yes, this would solve the problem, although it can be an expensive operation.

> still not clear what exactly the change is that you propose.

I propose to avoid using the local interface name as the key for "interface". One way to do it is to use a new key, say "id", containing an arbitrary string, so "name" would not be the key anymore, so it can be changed via <edit-config>.

The definition of the "interface-ref" would be

     typedef interface-ref {
       type leafref {
         path "/if:interfaces/if:interface/if:id";
       }
     } 

> your proposal yet, so I do not know for sure.

In get operations, the client can still select an interface using the "name" leaf, e.g. in a subtree filter. The "id" would have to be used in edit-config, but a client application could shield the user from this additional complexity.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Mon, 10 Sep 2012 08:22:34 -0700

...
> It would be possible to have an RPC method "rename-interface", which could also find all occurrences of the old name in a configuration and change them to the new one, as Phil suggested. However, I…

So what happens to any leafref objects in other data models that are pointing
at leafs within the 'eth0' entry?  Do they all get auto-magically changed too,
or do they all break?  Same question for any NACM rules configured for
that interface.

Consider the impact on the entire data model when you change the list keys.

Andy

---

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

> secret patterns that the server accepts that are not documented

I think it is a fact of life that several boxes do have restrictions
on interface names. Even if we claim there are not any restrictions,
they will be there. I doubt big vendors will change interface naming
schemes that have grown over years just because there is this shiny
new YANG data model.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 10 Sep 2012 17:28:29 +0200

> secret patterns that the server accepts that are not documented

I agree, and for all this I propose to avoid using vendor-specific name as the list key. It can be part of the data but as a non-key leaf.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Mon, 10 Sep 2012 08:42:27 -0700

> schemes that have grown over years just because there is this shiny

It means that some things are not appropriate for standards, or that we
have not written the standard correctly.  Servers cannot be allowed to return
an 'invalid-value' (or any non-resource related error-tag) for values that
are valid according to the YANG data-def-stmt.

What if there was an rpc like <name-my-interface> so the client could
pass in the type and location parameters, and the server will return
a name it will accept for the interface.

My objection is to making the client data-silo all the details to produce
a valid name, not to vendors using hard-wired naming schemes.
I agree that is not going to change.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 10 Sep 2012 09:05:31 -0700

> I agree, and for all this I propose to avoid using vendor-specific name as the list key. It can be part of the data but as a non-key leaf.

That would solve it, but so many other data models reference interface names.

Isn't the 'location' string also vendor-specific?
It does not contain any text about how the server MAY restrict values.
If the client provides an initial value, the server MUST use it, according
to the YANG that is there.

This whole thread really demonstrates that the REST-full way
of solving this problem is so much better than NETCONF.
Client POSTs new resource, server returns CREATED 201 and
a Location header identifying the new resource.  So much cleaner!
YANG-API has the 'optional-key' YANG extension to solve this problem.

Maybe a <create-interface> API is needed, since standard <edit-config>
is going to be vendor-specific.  That way, app developers can choose
the interoperable but very limited <create-interface> or they can create the
vendor-specific interface entry directly with <edit-config>.

If vendors can pick their own secret patterns for strings, then they can
also change them, right?  So a name that works today in the "standard"
is in no way guaranteed to work in the future?  I think the current key
for the interface list needs more work.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 10 Sep 2012 18:50:12 +0200

> or do they all break?  Same question for any NACM rules configured for

Yes, it would have to search the entire data tree. This is expensive because there are no backward refs leading to all leafrefs that point to a given node.

> Consider the impact on the entire data model when you change the list keys.

Yes, but it is not what I am proposing.

Lada

---

From: "Lange, Jeffrey K (GE Energy)" <[email-masked]>
Date: Mon, 10 Sep 2012 17:09:36 +0000

> Sent: Monday, September 10, 2012 11:28 AM
> To: Andy Bierman
> Cc: [email-masked]
> > I strongly object to undocumented vendor-specific value sets, as
> > identified in this text:
> >
> > figure out from trial and error or perhaps some ad-hoc vendor
> > documentation what values are allowed on each server.
> >

What if there was a config=false list of the physical interfaces on a machine, then new entries in the /interfaces table could point to the physical device that it is actually using?  This would solve the problem of vendors having name restriction on physical devices, and at the same time allow users to create interface entries with whatever names they wanted?

-Jeff

> > the specified syntax (modulo too-big errors, etc.).  There cannot be
> > some secret patterns that the server accepts that are not documented
> > in the YANG type-stmt.
> >
> 
> I agree, and for all this I propose to avoid using vendor-specific name as the
> list key. It can be part of the data but as a non-key leaf.
> 
> Lada
> 
> >
> > Andy
> >
> >
> >>>>> handle this, then a "physical-name" is not really needed.  Note
> >>>>> that we already have "type" and "location", so with an arbitrary
> >>>>> name you could create a new interface like this:
> >>>>>
> >>>>> detail.  A vendor could of course also add a "internal-name"
> >>>>> config false leaf through an augmentation, if it helps the operator.
> >>>>>
> >>>> So we have devices that can arbitrarily rename interfaces and we
> >>>> have devices that cannot. Since we likely won't succeed in making
> >>>> all devices support interface renaming, I think we should go for a
> >>>> data model where devices that can rename interfaces can take
> >>>> advantage of it but other devices are fine to implement our data
> >>>> model without adding such a feature to their OS. Do we agree with that?
> >>>
> >> The leaf is config true and hence the volatility of this is
> >> determined by the datastore. I am still not sure what your concern
> >> really is. Here is the definition:
> >>
> >>         leaf name {
> >>           type string;
> >>           description
> >>>> box, you really invoke an operation to rename an interface. But we
> >>>> do not have operations that can be triggered when a configuration
> >>>> is loaded. So we would have to have a mapping. Can we make it a
> >>>> separate data model feature that only those who really care
> >>>> implement? Or even better, we leave it out and if in say 2-3 years
> >>>> there are multiple proprietary implementations of such a mechanism,
> >>>> someone can go an standardize an extension of the data model?
> >>>
> >>> For all implementations, the interface key should either be the local
> name, which may change or disappear if the hardware changes, or something
> else. This should probably be decided now.
> >>>
> >>
> >> So your issue really is that the current definition does not force
> >> one or the other? I personally doubt we can do this if we want to
> >> achieve wide implementation and deployment of this standard. What
> >> systems can or can not do wrt. interface names is not likely to
> >> change just because a new network management data model comes along.
> >>
> >> /js
> >>
> >> --

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 10 Sep 2012 22:06:55 +0200 (CEST)

Andy Bierman <[email-masked]> wrote:
> > I agree, and for all this I propose to avoid using vendor-specific name as
> > the list key. It can be part of the data but as a non-key leaf.
> >
> 

Yes.

> It does not contain any text about how the server MAY restrict

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.

The text also says:

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

> to the YANG that is there.

I think it makes perfect sense for a device to reject a location
string with the value "hi mom".

> a Location header identifying the new resource.  So much cleaner!

Well, I agree that this feature is nice, but I fail to see how it
would help here.

> YANG-API has the 'optional-key' YANG extension to solve this

You still need the location, so it doesn't really solve the problem.

> for the interface list needs more work.

Even if the name is arbitrary, you will still have the problem that
different devices have different hardware, and thus different
"locations".  Again, making the name arbitrary doesn't solve *this*
problem.

/martin

---

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

"Lange, Jeffrey K (GE Energy)" <[email-masked]> wrote:
> What if there was a config=false list of the physical interfaces on a machine,
> then new entries in the /interfaces table could point to the physical device
> that it is actually using?  This would solve the problem of vendors having
> name restriction on physical devices, and at the same time allow users to
> create interface entries with whatever names they wanted?

It would be great with some mechanism a client can use to discover the
naming scheme / locations available on a device.  But a simple config
false list of physical interfaces won't solve this.  It might be
possible to hot-plug new interfaces for example, and you may want to
pre-provision those.  Also, even with such a list, an operator can
not just use these locations as opaque values - somehow you have to
know which physical interface a particular cable is connected to...

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 10 Sep 2012 22:25:31 +0200 (CEST)

Ladislav Lhotka <[email-masked]> wrote:
> I propose to avoid using the local interface name as the key for
> "interface". One way to do it is to use a new key, say "id", containing an
> arbitrary string, so "name" would not be the key anymore, so it can be changed
> via <edit-config>.

If this really is what we want to do, it is much simpler to remove the
text about restrictions on the name, and just say that the name is
arbitrary.

But it is not clear to me that this solves a real problem.

I agree with Juergen that devices will have their naming schemes
regardless of what we write in this document, and it seems to be error
prone to use a different name in the config and the rest of the system
(syslog, snmp, logs, cli messages etc).

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 10 Sep 2012 13:33:01 -0700

Hi,

It's OK to leave this out of scope I guess.
The text in the 'name' leaf should be consistent
with the 'location' leaf.  Maybe I missed the
out-of-scope text in the 'name' leaf?

It will take too long to come up with a solution
satisfactory to everybody, so better not to do anything
half-baked and delay this draft.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 10 Sep 2012 13:42:57 -0700

> (syslog, snmp, logs, cli messages etc).

+1

We don't want multiple naming schemes to map between.

Do devices really support renaming list entries?
We reject attempts to replace a list key.
You have to copy-and-create a new entry then delete the old one.

Does RFC 6241 or 6020 say what to do 1 way or the other?
I don't remember any edit-config text specific to list keys.
Maybe it should be supported.  This is a general N/Y issue
not specific to interfaces.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 11 Sep 2012 10:27:40 +0200

> "locations".  Again, making the name arbitrary doesn't solve *this*

So how about doing three simple things:

1. Add a new leaf "local-name", mandatory for physical interfaces.

   IMO "type" and "location" is not enough, in particular on systems that allow for changing the 
   internal interface name, such as Linux.

2. Make "type" and "location" optional even for physical interfaces.

3. Remove the following two paragraphs from the description of "name":

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

   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'.
   ----------------------------------------------------------

   A device imposing such restrictions should declare a deviation.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 11 Sep 2012 10:42:27 +0200

> know which physical interface a particular cable is connected to...

Pre-provisioning could be easy:

The client pre-configures the interface with "name" of his choice, and after the card is plugged in, the client just fills in the "local-name".

If the same card is removed, its configuration stay in the interface list, having the same client-selected name as before.

Later, if the card plugged in again, it may get another local name from the system. In this case it suffices to update the "local-name" and the configuration works again, including all logical interfaces built upon the hot-pluggable physical interface.

Of course, nothing prevents the client form using the tentative local name as the "name" key.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 11 Sep 2012 10:45:00 +0200 (CEST)

>    internal interface name, such as Linux.

Can you elaborate on why type + location is not sufficient?

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 11 Sep 2012 10:58:15 +0200

> Can you elaborate on why type + location is not sufficient?

What will the location leaf contain on Linux if the interface has the local name "foo"?

If you use the "nameif" command to change the interface name, the new name is really low-level, not just an alias for ethX, for example it appears in /proc/sys/net/ipv4/conf/.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 11 Sep 2012 11:00:19 +0200

> 3. Remove the following two paragraphs from the description of "name":

So what precisely is the definition of 'name' and 'local-name'? If I
do "ip link set eth0 name foo" on a Linux box, am I changing the
'name' or the 'local-name'? If I use interfaces(5) on a Debian-like
system, is the name of a stanza a 'name' or a 'local-name'? If I have
both, 'name' and 'local-name', how does that related to objects in say
the IF-MIB?

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 11 Sep 2012 11:26:35 +0200

> 'name' or the 'local-name'? If I use interfaces(5) on a Debian-like

In this case you are changing. I am not sure about kernel guts, but from the user's perspective "eth0" no more exists. 

> system, is the name of a stanza a 'name' or a 'local-name'? If I have

If you rename eth0 to foo before /etc/network/interfaces is read, you have to use "foo" in that file because it is now the local name of that interface.

The "name" key is applicable only in the context of a NETCONF configuration.

> both, 'name' and 'local-name', how does that related to objects in say

From RFC 2863 it seems clear that "local-name" corresponds to "ifName", and "name" corresponds to "ifAlias":

"[The ifName] object contains the device's local name (e.g., the name used at the device's local console) …"

"[ifAlias] provides a location in which a network management application can store a non-volatile interface-naming value of its own choice."

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 11 Sep 2012 11:32:29 +0200

> In this case you are changing. I am not sure about kernel guts, but from the user's perspective "eth0" no more exists.

I meant "In this case you are changing 'local-name'".

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 11 Sep 2012 11:42:33 +0200

> "[ifAlias] provides a location in which a network management application can store a non-volatile interface-naming value of its own choice."

This means the description leaf in -06 becomes obsolete? And now you
want essentially all references to the interface alias instead of the
interface name used natively by the operating system. Now, supposed I
do that and I call my interface 'customer-foo'. What happens if I have
to change 'customer-foo' to 'customer-bar'? Now you prefer that the
key would have been the interface name, not its alias. In other words,
you seem to assume that freely choosen names are more stable and the
names assigned by the underlying operating system, no?

/js

---

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

Ladislav Lhotka <[email-masked]> wrote:
> >>   IMO "type" and "location" is not enough, in particular on systems that
> >>   allow
> >>   for changing the

This would be a system that allows arbitrary names, and the arbitrary
name "foo" is not enough to identify the physical interface.  This is
why there is type and location.  So the location leaf in case might be
"1" (if this was 'eth1' originally).

> If you use the "nameif" command to change the interface name, the new name is
> really low-level, not just an alias for ethX, for example it appears in
> /proc/sys/net/ipv4/conf/.

nameif assigns a name based on the MAC address.  And it works only for
ethernet interfaces, so maybe it is not a good idea to use it for this
purpose.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 11 Sep 2012 11:59:24 +0200

> This means the description leaf in -06 becomes obsolete? And now you

No, this leaf may still contain any text describing the the interface in prose, or whatever. It corresponds to "ifDescr".

> to change 'customer-foo' to 'customer-bar'? Now you prefer that the

Do you mean you change it via "ip link"? In this case, you have to change "local-name" in the NETCONF configuration to "customer-bar". The "name" key needn't be changed.
 
> names assigned by the underlying operating system, no?

I guess the role and motivation for "name" are pretty much the same as for "ifAlias" in RFC 2863. The RFC continues:

   "The ifAlias object allows a network manager to give one or more
   interfaces their own unique names, irrespective of any interface-
   stack relationship."

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 11 Sep 2012 12:17:41 +0200

> name "foo" is not enough to identify the physical interface.  This is

Why? From the system point of view, "foo" uniquely identifies the interface.

> "1" (if this was 'eth1' originally).

The "1" has no meaning in the system anymore, and you have to assume that "name" contains "foo". This not only makes the "name" key vendor specific, but also makes it difficult to change the name via <edit-config>. For instance, if somebody changes the name from the console,

ip link set dev foo name bar

then you have to create a new interface entry with the "bar" key, copy and paste all configuration, and also find all references to "foo" in the entire configuration and change them to "bar". 

> ethernet interfaces, so maybe it is not a good idea to use it for this

You can also use the "ip link" command as above.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 11 Sep 2012 12:23:59 +0200

On Tue, Sep 11, 2012 at 11:59:24AM +0200, Ladislav Lhotka wrote:
 
[...]

> No, this leaf may still contain any text describing the the interface in prose, or whatever. It corresponds to "ifDescr".

Well, this is not what -06 says. But perhaps this is just a bug?

         leaf description {
           type string;
           description
             "A textual description of the interface.

              This leaf MAY be mapped to ifAlias by an implementation.
              Such an implementation MAY restrict the allowed values for
              this leaf so that it matches the restrictions of ifAlias.
              If a NETCONF server that implements this restriction is
              sent a value that doesn't match the restriction, it MUST
              reply with an rpc-error with the error-tag
              'invalid-value'.";
           reference
             "RFC 2863: The Interfaces Group MIB - ifAlias";
         }
 
> Do you mean you change it via "ip link"? In this case, you have to change "local-name" in the NETCONF configuration to "customer-bar". The "name" key needn't be changed.

No, I am talking about the key of my NETCONF interface configuration.

>    interfaces their own unique names, irrespective of any interface-

If I recall correctly, you started with these arguments:

a) If we use the OS local name for identifying interfaces, renaming
   becomes hard since NETCONF's edit-config() requires a delete/create
   cycle.

b) There likely will be many leafref references to the interface that
   also need to be updated to make the change complete.

Now, if instead we allow an arbitrary interface name, such as
"customer-foo" and map that to the OS local interface name (e.g.,
"en42"), once I start to dislike my arbitrary interface name, that is
I want to change "customer-foo" to "customer-bar", I think a) and b)
still apply. So does it then not boil down to how likely OS local
names change versus how likely administratively assigned names change?

And do we have reached agreement that OS local interface name changes,
e.g., 'ip link set eth42 name foo' are outside the scope of this data
model at this point in time?

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 11 Sep 2012 12:33:38 +0200 (CEST)

Juergen Schoenwaelder <[email-masked]> wrote:
> > No, this leaf may still contain any text describing the the interface in
> > prose, or whatever. It corresponds to "ifDescr".
> 

ifDescr is read-only in the MIB.  We had a discussion some IETFs back
about how ifAlias was really used by operators, and people said it is
used as a general description of the interface, not necessarily just
another name.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 11 Sep 2012 15:20:11 +0200

> ifDescr is read-only in the MIB.  We had a discussion some IETFs back

OK, so it's only manufacturer's info. 

> used as a general description of the interface, not necessarily just

This is not what RFC 2863 says about the intended use of ifAlias. It looks like a kludge due to the absence of an object corresponding to a read-write description as we know it from CLIs.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 11 Sep 2012 16:27:05 +0200

>              "RFC 2863: The Interfaces Group MIB - ifAlias";

See my previous response to Martin.

> No, I am talking about the key of my NETCONF interface configuration.

The "name" cannot be changed because it is a list key, at least not via <edit-config>.
 
>    becomes hard since NETCONF's edit-config() requires a delete/create

But I mean renaming that is forced by the change in the local name of the corresponding physical interface. For example, I reboot my Linux box and find out that my two Ethernet cards swapped their names "eth0" and "eth1" because the new kernel uses a different order of device driver initialization - I saw this several times. In the OS shell, I can simply edit /etc/network/interfaces, but in NETCONF it is not that easy if "eth0" and "eth1" are list keys.

>    also need to be updated to make the change complete.

Yes, because these references point to a wrong/nonexistent interface.
 
> names change versus how likely administratively assigned names change?

My use case is sort of opposite - easy changes of the "name" key are not supported because (i) it is a list key, and (ii) such a change may break references to that interface.

Instead, it is easy to handle changes in the underlying local name that is assigned by the system and follows the vendor's rules. In your example, if it is on Linux, you can do

ip link set dev customer-foo name customer-bar

and update the "local-name" in the NETCONF configuration to "customer-bar".

Of course, if the "name" key of this interface was originally "customer-foo", and it cannot be changed, then the new configuration of that interface may be a bit confusing, but at least nothing will break.

Detaching the "name" key from the local name also makes the configuration more vendor and system independent.

> model at this point in time?

Yes, except there must be a way for indicating the physical interface to which a given NETCONF interface entry belongs.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 11 Sep 2012 16:43:27 +0200 (CEST)

> a given NETCONF interface entry belongs.

Agreed.  The idea was that the combination 'type' and 'location' would
do this, where 'location' is defined as some string the device can use
to identify the physical hardware.

On linux, it doesn't seem that "eth0" and "eth1" are good names,
neither for 'name', 'location' or your proposed 'local-name', since
they may change with a new kernel.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 11 Sep 2012 17:13:29 +0200

> to identify the physical hardware.

So let's take the example in appendix D of the interfaces-cfg draft, and assume there is more configuration, IP addresses, VLANs etc. What is the NETCONF client supposed to do after finding out that the operating system swapped eth0 and eth1?

> they may change with a new kernel.

Well, "local-name" is a good name because it is the name under which the interface is known to the operating system. If the OS or its admin change their mind, then the local-name has to be updated in the NETCONF configuration(s). But the client can do this update using a simple <edit-config> because "local-name" is not the list key.

I agree that "0" or "1" has nothing to do with location of the interface as it just reflects the (arbitrary) order of initialisation. IMO it would be better to use the PCI address as the "location" value. But even then it is useful to know that a given interface is "eth0" from the OS perspective.

Lada

---

From: t.petch <[email-masked]>
Date: Tue, 11 Sep 2012 12:43:03 +0100

Lada

In principle, I agree with your suggestion but it is an argument I have
had many, many times over the years and have almost always lost, even if
people tell me years afterwards that I was right and that they wished
that they had listened to me:-(

I am against encoding information into names, seeing them as identifiers
that should be simple to use and not a source of something that instead
should be looked up in a database; but I usually lose out to those who
want to encode something useful, such as the type of the object, the
physical path to the network etc.  And when the useful information
changes, as it always does, then there is the choice of the useful
information now being misleading, or of telling everyone that the object
now has a new identifier, and yes, they will have to update all the
places where they have incorporated a reference to the printer name:-)

I am pleasantly surprised at how many operational, relational databases
actually do do this, with the primary key being system-chosen and a
seemingly arbitrary string that is hardly visible, with the keys that
the user uses being meaningful to users but always secondary.  Changing
the primary key is then straightforward.

But in the community of network and systems management, this almost
never happens.  So I think that you are right, but I do not expect it to
happen.

Tom Petch

----- Original Message -----
From: "Ladislav Lhotka" <[email-masked]>
To: "Martin Bjorklund" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, September 11, 2012 9:58 AM
Subject: Re: [netmod] interface and ip

> >>   IMO "type" and "location" is not enough, in particular on systems
that allow
> If you use the "nameif" command to change the interface name, the new
name is really low-level, not just an alias for ethX, for example it
appears in /proc/sys/net/ipv4/conf/.

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 11 Sep 2012 20:47:39 +0200

> that they had listened to me:-(

I understand that vendors (especially the big ones) consider their naming schemes a part of their trademark, so they are opposed to any vendor-independent scheme. However, for operators it would IMO be a real boon.

> places where they have incorporated a reference to the printer name:-)

Absolutely!

> the primary key is then straightforward.

Right, I like the way how this is done in mongodb: System-chosen object ids are attached to every new object by default, but the user can also set them explicitly if there is a more natural scheme of ids.

In NETCONF/YANG the primary key cannot be truly invisible because it must always be present when selecting a list entry in <edit-config>.

> never happens.  So I think that you are right, but I do not expect it to

I am a relatively unexperienced fellow, so I am still optimistic. :-)

Thank you, Lada

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 11 Sep 2012 12:19:32 -0700

Hi -

> From: "Juergen Schoenwaelder" <[email-masked]>
> To: "Ladislav Lhotka" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Tuesday, September 11, 2012 2:42 AM
...
> Now, supposed I

I think this use case illustrates how there are really THREE distinct
kinds of information involved:
   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"

Randy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 11 Sep 2012 22:19:07 +0200 (CEST)

Hi,

Ladislav Lhotka <[email-masked]> wrote:
> >> Yes, except there must be a way for indicating the physical interface to
> >> which
> >> a given NETCONF interface entry belongs.
> > 
> So let's take the example in appendix D of the interfaces-cfg draft, and
> assume there is more configuration, IP addresses, VLANs etc. What is the
> NETCONF client supposed to do after finding out that the operating system
> swapped eth0 and eth1?

I think a more stable identifier is needed for this to be useful.  The
client cannot be responsible for re-configuring the interfaces after a
reboot (it might not even be possible to communicate with the device
if interface identification changes...)  This is true both with
"location" or "local-name".

How this is solved on linux is up to the vendor.  If the device has 8
ethernet ports, the vendor can probably use a simple location 0 .. 7,
and make sure this works, regardless of the order the kernel uses.

I agree that arbitrary names are better - this is why the draft
RECOMMEND implementations to support it.  But at the same time, we
must be realistic and realize that this data model must be
implementable on popular platforms.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 12 Sep 2012 08:49:49 +0200

>    2) the administratively-assigned identifiers used to stitch stacks together

Right, that's the point. Our discussion is also complicated by the fact that some systems allow the local identifier to be arbitrary while others impose a precise format. 

So the draft/module should clarify whether the data model really treats 1 and 2 as independent identifiers, i.e. whether the "name" key has to be equal to the local name or not.

>    3) "Post-its" for things like "customer" or "cable-id"

Could the "description" leaf be used for this purpose?

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 12 Sep 2012 09:18:11 +0200

> "location" or "local-name".

Even if the local identifier is more stable: Let's say the name is "Ethernet0/1", type is the weird string representing Ethernet, and location is "0/1". Then the line card gets replaced (hot swap) and the same cable is now connected to "Ethernet0/0/1". My question is whether it is allowed to keep the old name "Ethernet0/1" as the key of that entry and only change location to "0/0/1".

> RECOMMEND implementations to support it.  But at the same time, we

This is not what I read in -06. It says:

> implementable on popular platforms.

But again: I propose the "name" key to be of the second type in Randy's classification, i.e.

So this key is used for internal purposes within the NETCONF system, and it is irrelevant whether the platform restricts the form of its local interface identifiers or not.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 12 Sep 2012 09:37:07 +0200 (CEST)

Hi,

Ladislav Lhotka <[email-masked]> wrote:
> Even if the local identifier is more stable: Let's say the name is
> "Ethernet0/1", type is the weird string representing Ethernet, and
> location is "0/1". Then the line card gets replaced (hot swap) and the
> same cable is now connected to "Ethernet0/0/1". My question is whether
> it is allowed to keep the old name "Ethernet0/1" as the key of that
> entry and only change location to "0/0/1".

With the current model, it depends on the implementation.

>     possibly depending on the type and location.

Ok, so this should be clarified.

/martin

---

From: Andrew McGregor <[email-masked]>
Date: Wed, 12 Sep 2012 19:40:43 +1200

> Even if the local identifier is more stable: Let's say the name is "Ethernet0/1", type is the weird string representing Ethernet, and location is "0/1". Then the line card gets replaced (hot swap)…

Most router and switch vendors seem to have solved this by always using a stable format on a given platform, in our case it's a triple of unit number, slot number, port number.  So if the port name changed, that's because the cable is in a different port by definition; if it's the same port in any useful sense, it has the same canonical name.

> So this key is used for internal purposes within the NETCONF system, and it is irrelevant whether the platform restricts the form of its local interface identifiers or not.

On linux, the stable identifiers are of one of the forms you can key off under the udev system, for example:

# PCI device 0x14e4:/sys/devices/pci0000:00/0000:00:01.1/0000:02:00.0 (tg3)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:15:77:df:e6:01", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

which is an extract from /etc/udev/rules.d/70-persistent-net.rules on my work machine.

In this case, it's configured to say that the device with MAC address 00:15:77:df:e6:01 is known as "eth1", but you could equally say the device in the slot at pci0000:00/0000:00:01.1/0000:02:00.0 could be "eth1".  Udev is unfortunate for this discussion, because it is extremely configurable in terms of name mapping.

In any case, netconf should be able to express something like the udev situation, but it might be necessary to identify the configuration entity by a UDID or something similar, that could be returned as a udev attribute along with the name.

Andrew

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 12 Sep 2012 10:17:57 +0200

> With the current model, it depends on the implementation.

Then people will start writing client applications that rely on "name" being the same as the local identifier and interoperability will be gone. I agree with Andy that the standard should be strict in this respect.

> Ok, so this should be clarified.

Maybe the MIB mapping should also be reconsidered, because according to RFC 2863 "ifName" is the local name that is used on the device console.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 14 Sep 2012 08:50:54 +0200

>    3) "Post-its" for things like "customer" or "cable-id"

There are also different aspects of change:

a) Lada's problem seems to be that on a certain platform, the system
   supplied "local" identifier can change with a kernel upgrade. It
   seems some network device vendors have solved that problem by using
   identifiers / kernels that do not have this "bug/feature", e.g. by
   making sure kernels follow the same device driver initialization
   order or by naming interfaces according to a location.

b) There is the old hotplug discussion of what it means to move one
   linecard from one slot to another. Depending on why you move the
   line card, you either want the configuration of that card to change
   or you want the config of the card to move with the card. 

c) There is the option to use purely administratively assigned keys
   for config snippets. Once we support this, I am sure we will see
   that people will encode semantics into these identifiers and hence
   there will be changes due to whatever encoded semantic got encoded.

Unless we make NETCONF generate purely semantic free keys (numbers,
uuids), we will end up with keys that once in a while require changes
and then the discussion boils down to how likely this is for the
various naming systems proposed. We will likely not find agreement on
an answer to this question.

Operationally, it seems that the system-level notion of interface
names is very widely used in management interfaces and beyond (e.g.
as part of zone indexes for link-local IPv6 addresses or to specify
scopes in IP multicast communication).

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 14 Sep 2012 11:27:52 +0200

>    order or by naming interfaces according to a location.

In my (not very recent) experience, the situation where one needs to migrate an entire stack to a different interface happens on all platforms - hardware upgrades, port failures etc.

>    there will be changes due to whatever encoded semantic got encoded.

On the other hand, such keys would enable publishing config snippets that can be used on various platforms, without the drudgery of changing interface names and all references to them.

> an answer to this question.

IMO, a user-friendly server could assign opaque keys automatically by default, but also allow the client to assign them manually.
 
> scopes in IP multicast communication).

In general, configurations are mostly dealt with in a very platform-specific context, even independent authors of technical books usually select one or at most two platforms for showing configuration examples.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 14 Sep 2012 12:17:44 +0200

> IMO, a user-friendly server could assign opaque keys automatically by default, but also allow the client to assign them manually.

NETCONF does not assign opaque keys automatically if you create new
list instances so for us this is completely out of scope.

> In general, configurations are mostly dealt with in a very platform-specific context, even independent authors of technical books usually select one or at most two platforms for showing configurati…

Operators need to be able to easily cross-correlate things. What is
"easy" is surely subjective. But we need to get back to concrete
proposals, otherwise this discussion becomes unproductive. I think we
have:

a) What is currently in draft-ietf-netmod-interfaces-cfg-06. Supports
   implementations using opaque interface names as well as
   implementations using system-level interface names.

b) The change you suggested in 

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

   essentially removing interface name restrictions (systems that
   choose to still have them 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.

Am I missing anything?

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 14 Sep 2012 12:32:01 +0200 (CEST)

Hi,

Juergen Schoenwaelder <[email-masked]> wrote:
> But we need to get back to concrete

Right.  These are exclusive; we have to pick one of them.

(In the cited msg Lada proposed 'local-name', but I don't think that
is necessary).

>    assume that at some point in time there will be a generic way of

Agreed.

>    c) which we could do now.

I think that if it is important to rename things, we should probably
look into a more generic mechanism.

So, I prefer (a) over (b); (c) is already out-of-scope, and I do not
think we should do (d).

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 14 Sep 2012 07:53:22 -0700

> list instances so for us this is completely out of scope.

Maybe <edit-config> cannot return the new resource ID,
but <create-interface> could easily do so.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 14 Sep 2012 17:03:29 +0200

> but <create-interface> could easily do so.

Yes, so we have another option, that is introducing a create-interface
RPC that returns suitable opaque keys.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 14 Sep 2012 17:11:59 +0200 (CEST)

Juergen Schoenwaelder <[email-masked]> wrote:
> > >> IMO, a user-friendly server could assign opaque keys automatically by
> > >> default, but also allow the client to assign them manually.
> > >>
> > >

This would be a really bad idea.  The fact that we have data models
and generic edit-config / get-config is what makes NETCONF so much
better for automation than rpc based solutions like soap or rest or
corba etc.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 17 Sep 2012 07:00:21 +0200

> (In the cited msg Lada proposed 'local-name', but I don't think that

I would still prefer to be able to see the the native interface name. Would it be a problem to have 'local-name' as an optional leaf?

Lada