Subject: [netmod] I-D Action: draft-ietf-netmod-interfaces-cfg-11.txt

From: [email-masked]
Date: Wed, 15 May 2013 07:03:53 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF.

	Title           : A YANG Data Model for Interface Management
	Author(s)       : Martin Bjorklund
	Filename        : draft-ietf-netmod-interfaces-cfg-11.txt
	Pages           : 44
	Date            : 2013-05-15

Abstract:
   This document defines a YANG data model for the management of network
   interfaces.  It is expected that interface type specific data models
   augment the generic interfaces data model defined in this document.
   The data model includes configuration data, state data and counters
   for the collection of statistics.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-interfaces-cfg

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-11

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-interfaces-cfg-11

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 15 May 2013 16:05:12 +0200 (CEST)

Hi,

During the IETF LC, we got quite a few comments on document
draft-ietf-netmod-interfaces-cfg-10.

See for example the threads

http://www.ietf.org/mail-archive/web/ietf/current/msg78801.html
(my reply:
http://www.ietf.org/mail-archive/web/ietf/current/msg78945.html)

and

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

Benoit also has similar comments in his AD review (see
http://www.ietf.org/mail-archive/web/netmod/current/msg07863.html)

After discussing these issues with Benoit, David, Juergen and Lada, we
suggest a couple of changes to address the issues:

  o  Separate the operational state from the configuration.

  o  Remove 'location', and instead use the name to identify physical
     interfaces.

There were also some other clarifications and minor changes.

The new version (draft-ietf-netmod-interfaces-cfg-11) addresses these
issues.  Please review and comment!

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 15 May 2013 16:25:40 +0200

Hi,

let me add some further context to this in order to address any
procedural questions you might have. While discussing the comments
received during the IETF last call, it became clear that we need to
make changes to the document that go beyond what can reasonably be
done during the IESG processing phase. So we (the chairs) consulted
with Benoit and decided to move this document back into the working
group. Martin has (with the help of others) worked the last few days
on a proposal how we might be able to address the questions that were
raised and this is now in -11. The working group should review this
proposal and raise any questions or concerns. Procedurally, we will
run another WG last call on this document (or a subsequent revision of
it) and then this document goes again to Benoit and we will see
another IETF last call as well.

One of the key changes is that -11 makes a clear separation between
configuration data and operational state data. It does so by creating
two branches, namely /interfaces and /interfaces-state. By having a
clear separation (essentially two interface lists - one for
configuration data and one for operational data), we are able to more
clearly explain how things interact also with other management
interfaces such as SNMP MIBs.

We like to receive feedback about this approach since we have similar
issues with other data models, in particular the IP data model, which
essentially extends the interface list(s). With the two branches, we
can finally distinguish IP addresses configured on an interface from
IP addresses operationally used by an interface.

/js

On Wed, May 15, 2013 at 04:05:12PM +0200, Martin Bjorklund wrote:
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

-- 
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: t.petch <[email-masked]>
Date: Thu, 16 May 2013 12:10:21 +0100

Mmmm

Separate lists for configutation and state is a big change and I am not
sure whom it benefits.

Being able to set/get/view a table row with most if not all the relevant
information for an interface is so simple that it seems perverse to
split it into two with two separate keys with seemingly no required
relationship between them.

Likewise, having the information together in the YANG module makes it
easier to find, whatever tool is used to view the module.

This split seems more like a political statement, state and
configuration are different and the appearance of this must override
other considerations.

Tom Petch

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 16 May 2013 13:30:33 +0200

> configuration are different and the appearance of this must override

Tom,

I think you are drawing a picture that is overly simplified given
today's hardware. For example, routers and switches have often hot
swappable interface hardware and as such configuration state and
operational state can be quite different. We need to be able to
properly express that. Furthermore, some interfaces are related to
physical interfaces (that come and og when the physical hardware
changes) and logical interfaces (that come and go as part of
configuration changes). This all needs to be dealt with properly and
the -10 approach did not really allow to do this properly.

As another example, consider the IP configuration extension. There is
a clear difference between IP addresses configured on an interface and
the IP addresses operationally present on an interface. Having two
separate trees allows to deal with this properly.

Given this, as technical contributor, I completely disagree with your
statement that "this split seems more like a political statement".

/js

---

From: t.petch <[email-masked]>
Date: Thu, 16 May 2013 12:43:37 +0100

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, May 16, 2013 12:30 PM
Subject: Re: [netmod] I-D Action:
draft-ietf-netmod-interfaces-cfg-11.txt

> separate trees allows to deal with this properly.

I agree with your characterisation of the complexity but fail to see how
separate trees helps.  You seem to be changing the basic meaning of an
interface so that there will be configuration interfaces and state
interfaces with a loose (undefined?) coupling between them.  I think
that there is a lack of some analysis of the data, the like of third
normal form, which needs clarifying.

Tom Petch

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 16 May 2013 14:06:59 +0200

> normal form, which needs clarifying.

Please read the document and then we can discuss on the basis of what
is in the document.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 16 May 2013 14:51:41 +0200

> statement that "this split seems more like a political statement".

I agree with Juergen, it was not a political statement but a technical necessity, given the current state of affairs. It the state data and statistics for physical interfaces are under a config=true list entry then either

(i) they are not present until a client creates the config entry for the particular interface,

or

(ii) the server writes this entry on its own.

I don't think (ii) should be allowed, and even if it was, what happens if a client deletes the entry?

Lada

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

---

From: t.petch <[email-masked]>
Date: Thu, 16 May 2013 14:48:35 +0100

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, May 16, 2013 1:06 PM
> Please read the document and then we can discuss on the basis of what

I did, which means that I don't understand it.

One example.  If I may hark back to SNMP, then a reference to ifName is
unique whereas in YANG, a reference to 'name' is not.  Thus this I-D
defines two name objects, with no relationship defined in the model
between them, so when it says

       | name                             | ifName                 |

does it mean one, or the other or both or sometimes?  In YANG, you
really SHOULD say
/if:interfaces/if:interface/if:name
or some such, and not just name

Or,
  "An interface is identified by its name, which is unique within the
   server.  "
well there are two name objects, so this does not make sense to me.

Or
/if:interfaces/if:interface/if:name
is rw while
/if:interfaces-state/if:interface/if:name
is ro and there is a "separate list for the operational state of all
interfaces".  All interfaces, I note, so what happens when I make a typo
and write to
/if:interfaces/if:interface/if:name
a name that is not in
/if:interfaces-state/if:interface/if:name

'name' is key, literally and metaphorically, so not understanding that,
well, I don't understand:-(

Tom Petch

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 16 May 2013 16:44:50 +0200

> or some such, and not just name

That ambiguity was already mentioned and will be fixed.

In SNMP, an ifName may refer to multiple interfaces. See RFC 2863. Hence
I do not understand your uniqueness question.
 
> well there are two name objects, so this does not make sense to me.

I think the relationship is explained in the description statement of
/interfaces/name:

         For physical interfaces, this leaf is the device-specific
         name of the interface.  The 'config false' list
         /interfaces-state/interface contains the currently
         existing interfaces on the device.

         When a configured logical interface is created by the
         system, it is instantiated in the
         /interface-state/interface list.  Since the name in that
         list MAY be mapped to ifName by an implementation, such an
         implementation MUST restrict the allowed values for this
         leaf so that it matches the restrictions of ifName.

Perhaps the 1st sentence in the second paragraph can be made clearer
by saying:

         When a configured logical interface is created by the
         system, it is instantiated with the same name in the
         /interface-state/interface list.

> well, I don't understand:-(

Again, I think this situation is explained in the description
statement of /interfaces/name.

        If a client tries to create configuration for a physical
        interface that is not present, the server MAY reject the
        request, if the implementation does not support
        pre-provisioning of interfaces, or if the name refers to
        an interface that can never exist in the system.
        A NETCONF server MUST reply with an rpc-error with the
        error-tag 'invalid-value' in this case.

/js

---

From: Xiang Li <[email-masked]>
Date: Thu, 16 May 2013 20:19:40 -0500

>           /interface-state/interface list.

+1.

To make things clearer, I think it should worth pointing out  that for 
physical interfaces,
the /interfaces/interface/name has the same value as 
/interfaces-state/interface/name.
This should help clarify that there aren't two different keys for 
configured interfaces, be it
logical or physical.

>> /if:interfaces-state/if:interface/if:name

The description of /interfaces container also says something about this.

      container interfaces {
        description
          "Interface configuration parameters.";

        list interface {
          key "name";

          description
            "The list of configured interfaces on the device.

             The operational state of an interface is available in the
             /interfaces-state/interface list.  If the configuration of a
             physical interface cannot be used by the system (e.g., the
             physical interface present is not matching the interface
             type), then the configuration is not applied to the physical
             interface shown in the /interfaces-state/interface list. If
             the the configuration of a logical interface cannot be used
             by the system, the configured interface is not instantiated
             in the /interfaces-state/interface list.";

>          error-tag 'invalid-value' in this case.

The draft11  says:

  container interfaces-state {
        config false;
        description
          "Data nodes for the operational state of interfaces.";

        list interface {
          key "name";

          description
            "The list of interfaces on the device.

             Physical interfaces detected by the system are always
             present in this list, if they are configured or not.";

first, should the last sentence end with:

..., whether they are configured or not." ?

Another question:
Will /interfaces-state/interface possibly also contain entries that are neither physical interfaces nor
logical interfaces explicitly configured? Like some routing entries injected by system? If yes
pointing that out may also help.

--Xiang

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 17 May 2013 11:30:35 +0200

> pointing that out may also help.

Routing entries should go into routing tables. I plan to restructure the routing data model slightly along similar lines as ietf-interfaces, but IMO ietf-ip should go first.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 17 May 2013 12:16:56 +0200

On Thu, May 16, 2013 at 08:19:40PM -0500, Xiang Li wrote:
> To make things clearer, I think it should worth pointing out  that
> for physical interfaces,

Yep. We thought this is already clear but perhaps we can make it even
clearer.
 
> ..., whether they are configured or not." ?

yes 
 
> pointing that out may also help.

Not sure what you mean with 'routing entries'. But yes, I do assume
that /interface-state/interface contains all physical and logical
interfaces present on the box. And if interfaces appear as side
effects of say turning on other services, I would expect that they
also become visible in the /interface-state/interface list. If other
share this view, we may need to clarify this as well.

/js

---

From: t.petch <[email-masked]>
Date: Fri, 17 May 2013 14:31:31 +0100

----- Original Message -----
From: "Martin Bjorklund" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, May 15, 2013 3:05 PM
Subject: Re: [netmod] I-D Action:

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

Martin

One of the comments in this review was

'It is interesting that these design criteria do not call out the
applicability to "physical" and "virtual" interfaces. Moreover, the text
above seems to imply that the only "dynamic creation and deletion" of
interfaces happens with the "addition and removal of physical
interfaces" and does not call out tunnels, loopbacks, virtuals, and
other logical entities instantiated as "interfaces".'

which I do not think was addressed and which in turn left me uncertain
what you mean by physical and logical.

>From elsewhere, I have the sense that physical is there for interfaces
where the system has an idea of the relevant information, such as naming
it ser2, whether or not it is something physical or distinct, so that
the act of configuration is constrained by what the system has already
done - if a system with an X.25 card predefines 4000 VC, are they then
physical? - whereas if the agent can choose the details to suit itself
"If the device supports arbitrarily named logical interfaces,"
then does that make them logical?

Likewise, in
'   For physical interfaces, the "name" is the device-specific name of
   the interface.  It is used to identify the physical hardware
   interface.  The 'config false' list "/interfaces-state/interface"
   contains all currently existing interfaces on the device.'
the last sentence omits physical or logical so I read that as applying
to all interfaces, VPN, VC, ser3 and so on.

While
"When a configured logical interface is created by the  system, it is
instantiated in the interface-state/interface list"
puzzles me further.  Are logical interfaces always configured?  And what
does it mean for system to create an interface as opposed to the agent
configuring it?

I do not understand physical v logical v what goes in
interface-state/interface list
when:-(

I think it not enough just to use the terms without either defining
them, or else using them in such a way that the definition is implicit.
Like so much in this work, it seems obvious until you think about it:-(

Tom Petch

<snip>

---

From: Xiang Li <[email-masked]>
Date: Fri, 17 May 2013 08:52:04 -0500

> share this view, we may need to clarify this as well.

I just meant if /interfaces-state/interface will contain entries that 
are neither  physical interface nor 'logical interfaces' explicitly 
configured, but are somehow inserted by the 'netconf server' 
automatically, like the temporal/dynamic/ephemeral routing entries that 
have been discussed in the routing draft.

If there is no such thing, i.e.,  /interfaces-state/interface =
the physical interfaces on the device + the logical interface 
configured, then this should be
clarified.

--Xiang

---

From: Xiang Li <[email-masked]>
Date: Fri, 17 May 2013 08:56:36 -0500

> does it mean for system to create an interface as opposed to the agent

I had the same question so I think some clarification here should help...

> Like so much in this work, it seems obvious until you think about it:-(
+1

--Xiang

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 17 May 2013 16:19:43 +0200

> Like so much in this work, it seems obvious until you think about it:-(

I think I clarified when things get instantiated and removed before.
Concerning the term 'logical interface', this is borrowed from the
IF-MIB and its RFC, latest version being RFC 2863. Perhaps we need to
have a more explicit definitions these days.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 17 May 2013 16:20:27 +0200

> then does that make them logical?

My understanding is that physical interfaces are those that the device creates on its own, gives them a name and initialises them to some default state. These interfaces appear originally as entries under /interfaces-state. Now, if a client wants to reconfigure such an interface (which may include activating it), he has to create an entry with the same name under /interfaces (i.e., configuration) and specify the changes.

In contrast, the originator for a logical interface is a client who creates first a config entry for it under /interfaces. If the server accepts this configuration, it then creates the corresponding entry with the same name under /interfaces-state.

If the device supports arbitrarily named logical interfaces, then the client may configure the entry with any name as its key, otherwise the client has to pick a name according to the device's naming scheme.

Perhaps the adjectives "physical" and "logical" are somewhat misleading and something more neutral could be chosen instead.

Lada

---

From: t.petch <[email-masked]>
Date: Fri, 17 May 2013 18:20:15 +0100

----- Original Message -----
From: "Ladislav Lhotka" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: <[email-masked]>; "Martin Bjorklund" <[email-masked]>
Sent: Friday, May 17, 2013 3:20 PM

> then does that make them logical?

My understanding is that physical interfaces are those that the device
creates on its own, gives them a name and initialises them to some
default state. These interfaces appear originally as entries under
/interfaces-state. Now, if a client wants to reconfigure such an
interface (which may include activating it), he has to create an entry
with the same name under /interfaces (i.e., configuration) and specify
the changes.

In contrast, the originator for a logical interface is a client who
creates first a config entry for it under /interfaces. If the server
accepts this configuration, it then creates the corresponding entry with
the same name under /interfaces-state.

If the device supports arbitrarily named logical interfaces, then the
client may configure the entry with any name as its key, otherwise the
client has to pick a name according to the device's naming scheme.

Perhaps the adjectives "physical" and "logical" are somewhat misleading
and something more neutral could be chosen instead.

<tp>
Lada

As ever, thank you for a clear explanation.

Martin
I propose changing 3.1
OLD
" The data model for interfaces presented in this document uses a flat
   list of interfaces.  Each interface in the list is identified by its
   name.  Furthermore, each interface has a mandatory "type" leaf.

   There is one list of configured interfaces ("/interfaces/interface"),
   and a separate list for the operational state of all interfaces
   ("/interfaces-state/interface")."

NEW
" The data model for interfaces presented in this document uses two flat
   lists of interfaces.  An interface in a list is identified by its
   name; each entry has a mandatory "type" leaf.  One list consists of
   state, the other of configured information.

One list, /interfaces-state/interface, is initially populated by the
server, creating entries therein.  Subsequently, the client may create
an entry with the same name in the other list, /interfaces/interface,
and then edit that entry in order to amend the configuration of that
interface.

If the client creates an entry with a different name in
/interfaces/interface, and that entry is acceptable to the server, then
the server creates a corresponding entry in /interfaces-state/interface
Thus the entries in /interfaces/interface are a strict subset of
/interfaces-state/interface (apart from any transient conditions when an
entry is being created or deleted).
"

Not quite the right style but I am focussed on the semantics at present

Tom Petch

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 17 May 2013 22:09:39 +0200

> and then edit that entry in order to amend the configuration of that

I think the word 'amend' is wrong because the config data is not
amending the state data.

> entry is being created or deleted).

Strict subset is wrong because I can pre-provision config for physical
interfaces that are not there yet, for example.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 19 May 2013 22:15:34 +0200 (CEST)

Ladislav Lhotka <[email-masked]> wrote:
> My understanding is that physical interfaces are those that the device creates
> on its own, gives them a name and initialises them to some default state. These
> interfaces appear originally as entries under /interfaces-state. Now, if a
> client wants to reconfigure such an interface (which may include activating
> it), he has to create an entry with the same name under /interfaces (i.e.,
> configuration) and specify the changes.
> 
> In contrast, the originator for a logical interface is a client who creates
> first a config entry for it under /interfaces. If the server accepts this
> configuration, it then creates the corresponding entry with the same name under

Yes.  The property of being physical or logical is tied to the
interface type.  I agree that the term "physical" might be misleading,
esp. these days with virtualization.  A device might have a "virtual
physical" ethernet interface...  But it behaves as a proper physical
interface.

A logical interface is really not(physical).

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 20 May 2013 01:12:28 +0200

On Sun, May 19, 2013 at 10:15:34PM +0200, Martin Bjorklund wrote:
> interface type.

You mean type as /interfaces/interface/type? If so, are you sure this
statement would generally be true?

> I agree that the term "physical" might be misleading,

RFC 2863 actually has this piece of text:

   While some interfaces, for example, most physical interfaces, cannot
   be created via network management, other interfaces such as logical
   interfaces sometimes can be.

I think this is important: physical interface are simply there (or
appear/disappear by installing/removing pieces of hardware) while
logical interfaces are instantiated (created and deleted) via
configuration.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 20 May 2013 10:21:24 +0200

>   interfaces sometimes can be.

Even this formulation indicates that physical/logical interfaces are only typical examples of two distinct classes of interfaces (which are not given names).

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 20 May 2013 12:26:11 +0200 (CEST)

Ladislav Lhotka <[email-masked]> wrote:
> accepts this configuration, it then creates the corresponding entry
> with the same name under /interfaces-state.

I think that logical interfaces can appear in the
/interfaces-state/interface list also in other cases; i.e., in cases
where there is no explcit configuration for the logical interface in
/interfaces/interface.  This could be as a side-effect from some other
configuration, or from some dynamic event.  In any case, I think it
would be wrong to state that the /interfaces-state/interface list
contains the physical interfaces detected by the system, plus a strict
subset of the logical interfaces in /interfaces/interface.

> Perhaps the adjectives "physical" and "logical" are somewhat
> misleading and something more neutral could be chosen instead.

Do you have any suggestions?

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 20 May 2013 12:33:41 +0200

> Do you have any suggestions?

Most technical terms will probably have unwanted connotations, so I am thinking about something really simple, like "outer" for physical and "inner" for logical.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 20 May 2013 12:49:21 +0200

On Mon, May 20, 2013 at 12:33:41PM +0200, Ladislav Lhotka wrote:
> 
> Most technical terms will probably have unwanted connotations, so I
> am thinking about something really simple, like "outer" for physical
> and "inner" for logical.

Then I prefer foo and bar since people will speculate what is outer
and inner.

We used physical and logical because that is what IF-MIB is using.
Back in a day, this classification likely was easy to understand.

Physical interface: A network interface represented by a piece of
hardware (with a connector or an antenna) and forming the bottom
of an interface stack.

Logical interface: A network interface layered on top of a physical
interface or another logical interface typically created by network
management configuration.

Since the world have moved on, we have logical interfaces created by
other software services as side effects (that is not necessarily
explicitely configured as a network interface) and we have software
interfaces that are treated as physical interfaces say by a virtual
machine even though there is no physical hardware (e.g. a port of an
emulated Ethernet bridge). The question is how we factor these things
into the definitions. Lets start some wordsmithing:

Physical interface: A network interface represented by a piece of
hardware (with a connector or an antenna) and forming the bottom of an
interface stack. This may include virtual physical interfaces that
behave like physical interfaces even though they are provided by some
virtualization layer. Physical interfaces usually appear when
interface hardware is added/removed or when a virtualization system
is reconfigured.

Logical interface: A network interface layered on top of a physical
interface or another logical interface typically created by network
management configuration. Logical interfaces may also be introduced as
side effects of enabling certain services on a system. Logical
interfaces is that they usually appear and disappear related to their
configuration or a service enablement.

Now bash this quick proposal. ;-)

/js

---

From: Jonathan Hansford <[email-masked]>
Date: Mon, 20 May 2013 11:54:30 +0100

On 2013-05-20 11:49, Juergen Schoenwaelder wrote:

>> am
>> thinking about something really simple, like "outer" for physical 
>> and
>> "inner" for logical.
>

I struggle to make sense of this last sentence. Are there some words 
missing?

Jonathan

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 20 May 2013 12:58:56 +0200

> Then I prefer foo and bar since people will speculate what is outer

From the point of view of NETCONF, an outer interface comes from outside whereas an inner one has to be configured. But I think we have to provide definitions and not guarantee a truly intuitive meaning.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 20 May 2013 13:20:15 +0200

On Mon, May 20, 2013 at 11:54:30AM +0100, Jonathan Hansford wrote:
> >>Most technical terms will probably have unwanted connotations,
> >>so I am
> >>thinking about something really simple, like "outer" for
> >>physical and
> >>"inner" for logical.
> >
> >of an

s/is that they//

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 20 May 2013 13:30:03 +0200 (CEST)

> into the definitions. Lets start some wordsmithing:

I like this idea, and I perfer to use the terms "physical" and
"logical".

> virtualization layer. Physical interfaces usually appear when
                                                    ^^^^^^

What does this mean?  I think it means that it is detected by the
system and instantiated in /interfaces-state/interface.

> management configuration.

A loopback interface is not layered on top of another interface.

> Logical interfaces may also be introduced as

I think the last sentence is redundant and can be removed.

I think it would also be useful to allow logical interfaces to appear
not only as a result of some management action - I don't think we
should unnecessarily constrain the defintion.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 20 May 2013 15:12:12 +0200

yes
 
> > interface hardware is added/removed or when a virtualization system

Trying to improve the text below.

> should unnecessarily constrain the defintion.

This is why I include service enablement (which you suggested to
remove). Trying again:

  Physical interface: A network interface representing a piece of
  hardware and forming the bottom of an interface stack (e.g., an
  Ethernet interface). This may include virtual physical interfaces
  that behave like physical interfaces even though they are provided
  by some virtualization layer. Physical interfaces are usually
  detected by the system when they appear and removed by the system
  when they disappear. As such, the lifetime of the operational state
  of physical interfaces is typically determined by the system.

  Logical interface: A network interface which is either a pure
  software interface or an interface layered on top of a physical
  interface or another logical interface. Logical interfaces are
  either created and deleted by explicit configuration (e.g., VLAN
  interfaces on top of an Ethernet interface) or by enabling certain
  services (e.g., enabling an IP stack typically introduces a loopback
  interface). As such, the lifetime of the operational state of
  logical interfaces is typically determined by the configuration of
  the system. Of course, certain logical interfaces can only be
  instantiated successfully by the system if the underlying physical
  interfaces are present.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 20 May 2013 22:44:16 +0200 (CEST)

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

I just suggested to remove the last sentence; the sentence before also
mentioned "enabling certain services".  But anyway - I think your
proposal below is good, and I think it should be included in the
document.

/martin

---

From: t.petch <[email-masked]>
Date: Tue, 21 May 2013 08:49:14 +0100

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, May 16, 2013 3:44 PM
> I do not understand your uniqueness question.

Juergen

A reference to ifName is unique in the sense that that identifier is
unique in the namespace of objects in the mib.  By contrast, name in
'netconf' is something beyond ambiguous.  I think that users will have
to get used to using
 /interfaces/interface/name
or whatever the relevant path is, clumsy as I think that that is.

The other issue, from below, is that you are quoting from the
description clause whereas my expectation, set from reading many RFC
containing MIB modules, is that I will be able to get a good
understanding of  the module from sections 3 and 4.  Of course, the YANG
module will be extracted and needs to make sense by itself, so there
needs to be some duplication between the introductory sections and the
module itself (something that has long been the case with SNMP).  For
me,
it is not enough if you have to read the description clauses in order to
understand the broad thrust of the module.

Tom Petch

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 21 May 2013 10:36:52 +0200

On Tue, May 21, 2013 at 08:49:14AM +0100, t.petch wrote:

> me, it is not enough if you have to read the description clauses in 
> order to understand the broad thrust of the module.

Perhaps you can send concrete text you think is missing since this
will help us finishing the document.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 21 May 2013 11:06:04 +0200

>  of physical interfaces is typically determined by the system.

I am not sure that the line can be drawn based on any properties or type of an interface, it may also depend on the purpose or scope of the data model. Consider a device where NETCONF is used for configuring only a certain service, and is expected to *use* any interfaces that are provided by the operating system in the same way, be it a physical interface or VLAN or a tunnel. The client may be able to configure IP addresses on such interfaces etc., but neither create new (logical) interfaces nor delete existing ones. 

We are currently implementing NETCONF for a DNS server monitoring application and it is designed to work exactly like this. 

So what IMO really matters is whether an interface entry is present in /interfaces-state even before any configuration is written. The client then has to deal with such an interface as if it was provided by "vis maior", very much like a real physical interface.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 21 May 2013 11:50:34 +0200

> So what IMO really matters is whether an interface entry is present in /interfaces-state even before any configuration is written. The client then has to deal with such an interface as if it was pr…

I hear you saying that systems might have non-physical (that is
logical) interfaces that are kind of permanent or whose lifetime is
outside the control of NETCONF. Correct? Are you saying that the
distinction really is "system controlled interfaces" versus "config
controlled interfaces"? And where to interfaces belong that are
created as side effects, e.g. tun/tap interfaces created by an
application dynamically whenever that application is runing? Do we
have direct and indirect config controlled interfaces? Or is such a
tun/tap interface what you consider "system controlled" even though I
might be disable the function that creates such tun/tap interfaces?

/js

---

From: t.petch <[email-masked]>
Date: Tue, 21 May 2013 10:45:06 +0100

----- Original Message -----
From: "Martin Bjorklund" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, May 20, 2013 9:44 PM
of an

Martin

Something seems to happen when turning comments on the list into source
for the I-D:-(

Thus
"> > > What does this mean?  I think it means that it is detected by the
> > > system and instantiated in /interfaces-state/interface."

To me, that is a clear statement of what is fundamental to understanding
this I-D, what is 'physical' what is 'logical' - perhaps not ideal
terms, but no problem if well-defined.

"physical interfaces are those that the device creates on its own, gives
them a name and initialises them to some default state. These interfaces
appear originally as entries under /interfaces-state."

Again, clear and helpful.  Either statement would  much clarify the I-D.

By contrast,

"A network interface representing a piece of
 hardware and forming the bottom of an interface stack (e.g., an
 Ethernet interface."

"Physical interfaces are usually
 detected by the system when they appear and removed by the system
 when they disappear."

I find unhelpful.  The key, overwhelming, fundamental
point, in the context of netmod, is not that this is hardware, nor that
it is at the bottom of the stack.  It is that the system will
instantiate
it in
 /interfaces-state/interface/
I think that a user, to have any hope of understanding this module,
must grasp this and I do not think that they will with the sentences in
the order that they are and with the key point weakened by
'usually'.

If you know what definition means, then yes, you can read the meaning
into text; if you are unclear or uncertain, then I think you will
struggle.

Tom Petch

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 21 May 2013 12:33:19 +0200

> outside the control of NETCONF. Correct? Are you saying that the

Correct.

> controlled interfaces"? And where to interfaces belong that are

Yes, but only in the context of the interfaces module. That is:

- system-controlled interfaces are those that appear in /interfaces-state
  before the corresponding entry has been created in /interfaces.

- config-controlled interfaces are those that have to be configured as an entry under /interfaces, otherwise they don't exist.

This distinction is important because it affects the relationship between the "name" leaves, i. e. the keys of the lists /interfaces-state/interface and /interfaces/interface.

> might be disable the function that creates such tun/tap interfaces?

Yes, if a logical interface is created as a side effect of other configuration, then, from the point of view of the interfaces module, is a system-controlled interface. So perhaps a more appropriate name would be "elsewhere-controlled".

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 21 May 2013 12:57:33 +0200

>   before the corresponding entry has been created in /interfaces.

And here it is already getting wrong because we want to support
preprovisioning.
 
> This distinction is important because it affects the relationship between the "name" leaves, i. e. the keys of the lists /interfaces-state/interface and /interfaces/interface.

But then I think the text in the description clauses (with the minor
tweaks discussed here) is actually explaining this reasonably well,
no?

> Yes, if a logical interface is created as a side effect of other configuration, then, from the point of view of the interfaces module, is a system-controlled interface. So perhaps a more appropriat…

We can perhaps define system-controlled in such a way that these
elsewhere-controlled interfaces are included. So we have
system-controlled interfaces vs interface-config-controlled
interfaces?

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 21 May 2013 13:30:34 +0200

> And here it is already getting wrong because we want to support

I don't think so. The configuration can still be pre-provisioned, but the point is that the config entry has to have the same name as the future operational state entry will have after it is provided by the system, otherwise the configuration won't be applied. The sequence of events is:

1. The interface is independently created and named elsewhere and appears in /interfaces-state.

2. The NETCONF server then looks whether there is any configuration for this new interface.

> tweaks discussed here) is actually explaining this reasonably well,

Yes, what's missing is the definition of (the replacements of) the terms "physical" and "logical". 

> system-controlled interfaces vs interface-config-controlled

The latter seems pretty clumsy. How about system-originated and config-originated? Neither of these terms is completely precise, but they are going to be used only locally in this document, and their definition will be provided.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 21 May 2013 14:12:19 +0200

> The latter seems pretty clumsy. How about system-originated and config-originated? Neither of these terms is completely precise, but they are going to be used only locally in this document, and the…

To be honest, this distinction might show up in other contexts as
well. But that does not matter. So we have system-controlled vs.
system-originated and on the other side config-controlled vs.
interface-config-controlled vs. config-originated. Since it is not
just about when interfaces appear but also when they disappear, I do
not like '-originated' that much.

  system-controlled interface: An interface is said to be
  system-controlled if the system creates and deletes the interface.
  Examples are interfaces representing physical hardware that appear
  and disappear when hardware (e.g., a line card) is added or
  removed. System-controlled interfaces may also appear if a certain
  functionality is enabled (e.g, a loopback interface appears if the
  IP protocol stack is enabled).

  config-controlled interface: An interface is said to be
  config-controlled if the creation of the interface is controlled by
  adding interface configuration to the configuration datastore and
  the removal of the interface is controlled by removing interface
  configuration from the configuration datastore. Examples are VLAN
  interfaces configured on a system-controlled Ethernet interface.

Explanation to merge somewhere later into the document:

  When a system-controlled interface is created, the runtime system
  tries to apply the interface configuration matching the name of the
  new interfaces. When a config-controlled interface is created, then
  the configuration determines the name of the interface. Some systems
  may support arbitrary interface names while others require that the
  names of config-controlled interfaces matches certain naming
  conventions.

Would something like this work better than physical/logical?

/js

---

From: Jonathan Hansford <[email-masked]>
Date: Tue, 21 May 2013 13:19:41 +0100

On 2013-05-21 13:12, Juergen Schoenwaelder wrote:

>> The latter seems pretty clumsy. How about system-originated and
>> config-originated? Neither of these terms is completely precise, but
>> they are going to be used only locally in this document, and their
>> definition will be provided.
>

So, an interface that is config-controlled by another protocol but not 
config-controlled via this data model would, for this data model, be a 
system-controlled interface? If so, should that be more explicitly 
stated?

Jonathan

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 21 May 2013 14:27:25 +0200

On Tue, May 21, 2013 at 01:19:41PM +0100, Jonathan Hansford wrote:
> 
> So, an interface that is config-controlled by another protocol but
> not config-controlled via this data model would, for this data
> model, be a system-controlled interface? If so, should that be more
> explicitly stated?

Do you have an example? But I guess the answer is 'yes' so far.

/js

---

From: "Lange, Jeffrey K (GE Energy Management)" <[email-masked]>
Date: Tue, 21 May 2013 12:33:39 +0000

>   IP protocol stack is enabled).

The example given of a loopback interface seems to contradict the definition of system controlled. 
If the device is created via "configuring" the IP protocol stack, wouldn't it by definition be "config-controlled"?

-Jeff

---

From: Jonathan Hansford <[email-masked]>
Date: Tue, 21 May 2013 13:34:55 +0100

On 2013-05-21 13:27, Juergen Schoenwaelder wrote:

>> not

No, nor would I consider myself an expert on interfaces, so I'm happy 
for this to be ignored if others more in the know do not believe this is 
relevant. It just struck me as a corner case that could potentially lead 
to confusion.

Jonathan

---

From: t.petch <[email-masked]>
Date: Tue, 21 May 2013 13:57:34 +0100

----- Original Message -----
From: "Ladislav Lhotka" <[email-masked]>
To: "Juergen Schoenwaelder" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, May 21, 2013 12:30 P
<snip>

Lada

That I think is complicating the future:-(

You said you would hold off on routing since there were parallel issues
there, and thought that ip-cfg should come in-between.  I think that
there will be many more such, so calling them logical and physical in
one I-D, static and dynamic in another, etc. etc. can only confuse.

The concept is not local (which is why we have been discussing it for so
many years:-) and we could do worse than build on RFC6244, which is the
most recent description of this I have seen, and come up with global
terms that can then be used in all I-Ds; no problem with the definition
appearing here and being the normative reference for everyone else.

The best terms would be ones that are close to those then used in the
paths
/interfaces-system/interface/
/interfaces-config/interface/
for example

Tom Petch

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 21 May 2013 15:17:31 +0200

> /interfaces-config/interface/

The distinction between config state and operational state is well
understood and not the main subject of this discussion. We are talking
here about how config applies to operational state objects whose
lifetime is either controlled by the system or controlled by the
config itself. For me, these are two separate things and your
suggestion does not make much sense compared to what we have (since
config-controlled interfaces leads to operational state that is
similar to the operational state of system-controlled interfaces).

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 21 May 2013 17:07:01 +0200

On May 21, 2013, at 2:19 PM, Jonathan Hansford <[email-masked]> wrote:

> So, an interface that is config-controlled by another protocol but not config-controlled via this data model would, for this data model, be a system-controlled interface? If so, should that be more explicitly stated?

Yes, that's my view. It should be explicitly stated but we first have to agree on how it is supposed to work.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 21 May 2013 17:19:12 +0200

> If the device is created via "configuring" the IP protocol stack, wouldn't it by definition be "config-controlled"?

Not by this definition. The config entry for a loopback interface under /interfaces has to use the name that's already present under /interfaces-state (or, if it is pre-provisioned, will be present after the IP stack is enabled).

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 21 May 2013 17:46:02 +0200

> Not by this definition. The config entry for a loopback interface under /interfaces has to use the name that's already present under /interfaces-state (or, if it is pre-provisioned, will be present…

The loopback interface is probably not a good example since there is
typically not much to configure...

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 21 May 2013 17:46:42 +0200

> one I-D, static and dynamic in another, etc. etc. can only confuse.

You are right, it is not limited to this draft, so we should come up with terms suitable for describing the same situation in other contexts.

For example, in the routing draft, the main/default routing table for an address family, which is always present, will be system-controlled, and any additional routing tables will be config-controlled. 

> appearing here and being the normative reference for everyone else.

Hmm, I don't think it is a good time to open RFC 6244 now and make it a downref of all other I-Ds, if it is what you mean. After we agree on a definition, it will probably be better to have a copy of it in the terminology section of every I-D where this issue arises.

> /interfaces-config/interface/

So system-something and config-something seem to satisfy this. I am fine with "system-controlled" and "config-controlled", if we can agree on it.

Thanks, Lada

---

From: t.petch <[email-masked]>
Date: Tue, 21 May 2013 16:58:15 +0100

In line twice

----- Original Message -----
From: "Ladislav Lhotka" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, May 21, 2013 4:46 PM
> one I-D, static and dynamic in another, etc. etc. can only confuse.

You are right, it is not limited to this draft, so we should come up
with terms suitable for describing the same situation in other contexts.

For example, in the routing draft, the main/default routing table for an
address family, which is always present, will be system-controlled, and
any additional routing tables will be config-controlled.

> appearing here and being the normative reference for everyone else.

Hmm, I don't think it is a good time to open RFC 6244 now and make it a
downref of all other I-Ds, if it is what you mean. After we agree on a
definition, it will probably be better to have a copy of it in the
terminology section of every I-D where this issue arises.

<tp>
Whoops, no way did I mean open RFC6244; rather, in "definition appearing
here",
here = draft-ietf-netmod-interfaces-cfg
I have no problem with this particular I-D being the normative reference
for the terminology for all the other modules we create.

</tp>

> /interfaces-config/interface/

So system-something and config-something seem to satisfy this. I am fine
with "system-controlled" and "config-controlled", if we can agree on it.

<tp>
Works for me

Tom Petch
</tp>

Thanks, Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 21 May 2013 20:28:01 +0200 (CEST)

Hi,

> not like '-originated' that much.

I think system-controlled is fine.  In YANG we have ordered-by system
and ordered-by user so I wonder if we should use user-controlled
instead of config-controlled or interface-config-controlled?  It is
not perfect, but maybe consistent.

>   system-controlled if the system creates and deletes the interface.

Ok, but in my view the system creates all interfaces - who would
otherwise create them?

For example, when the system detects that a new user-controlled
interface is created in /interfaces/interface, the system creates (*)
the interface (in the kernel typically) and (conceptually)
instantiates an entry in /interface-state/interface.

(*) if it is not pre-configured...

The system creates/deletes an interface <=> an entry is conceptually
instantiated/removed from /interfaces-state/interface.

So maybe say:

   system-controlled interface: An interface is said to be
   system-controlled if the system creates and deletes the interface
   independently of what has been configured.

>   functionality is enabled (e.g, a loopback interface appears if the

s/appear/might appear/  ?

>   IP protocol stack is enabled).

[should this be added to the ip config document?]

>   adding interface configuration to the configuration datastore and

I think we must be even more explicit:

  ... to the /interfaces/interface list in the running configuration
  datastore ...

>   tries to apply the interface configuration matching the name of the

the interface configuration in /interfaces/interface ...

> Would something like this work better than physical/logical?

Yes.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 21 May 2013 20:58:23 +0200

On Tue, May 21, 2013 at 08:28:01PM +0200, Martin Bjorklund wrote:

[...]
 
>   ... to the /interfaces/interface list in the running configuration

I tried to define the concept without refering to the structure of the
data model where the general concept is defined. Perhaps that is too
difficult? My idea was to have a concise definition right up in the
terminology section and to have somewhere later text that explain how
the two lists interact for system-controlled and config-controlled
interfaces.

/js (once we can configure interfaces, the rest will be easy ;-)

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 21 May 2013 21:55:19 +0200

> not perfect, but maybe consistent.

Makes sense.

> Ok, but in my view the system creates all interfaces - who would

What about something like this: "User-controlled interface is created as a direct consequence of the creation of the corresponding configuration entry. In all other cases, the interface is called system-controlled." Some examples could then illustrate the other cases.

> (*) if it is not pre-configured…

What do you mean by pre-configured?
>   independently of what has been configured.

Or maybe better: "… creates and deletes the interface independently of the corresponding configuration entry (which also needn't be present at all)."

As we discussed earlier, it is possible that a system-controlled interface is created or deleted as a side effect of a change elsewhere in the configuration.

> [should this be added to the ip config document?]

How is the IP stack globally enabled - just by supporting the ietf-ip module?
The "enabled" flags are per interface.

>  datastore …

+1

+1

However, I agree with Tom that we should probably aim at a more general formulation. Which makes me wonder: Is it only about the relationship between identically keyed entries in a pair of "coupled" lists - one in operational state and the other in configuration? Or something else as well?

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 22 May 2013 06:19:52 +0200 (CEST)

Ladislav Lhotka <[email-masked]> wrote:
> What about something like this: "User-controlled interface is created as a
> direct consequence of the creation of the corresponding configuration
> entry. In all other cases, the interface is called system-controlled." Some
> examples could then illustrate the other cases.
> 
> > 

I meant that if you configure a vlan on a pre-provisioned ethernet
interface, the system will not create the vlan interface until the
hardare is present.

> Or maybe better: "… creates and deletes the interface independently of the
> corresponding configuration entry (which also needn't be present at all)."

Ok.

> As we discussed earlier, it is possible that a system-controlled interface is
> created or deleted as a side effect of a change elsewhere in the
> configuration.

Yes.

> However, I agree with Tom that we should probably aim at a more general
> formulation.

I would be very happy if we could solve this for the current
document(s).  I am not sure what a more general formulation would be?

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 22 May 2013 14:30:36 +0200

> interface, the system will not create the vlan interface until the

OK, right.

> document(s).  I am not sure what a more general formulation would be?

Maybe just "system/user-controlled list entry", because I will most likely have to deal with system/user-controlled routing tables in the routing draft.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 22 May 2013 07:50:21 -0700 (PDT)

Hi,

I tried to merge the various text snippets we discussed into full
paragraphs.  This is what I came up with:

In "Terminology":

- system-controlled interface: An interface is said to be
  system-controlled if the system creates and deletes the interface
  independently of what has been explicitly configured.  Examples are
  interfaces representing physical hardware that appear and disappear
  when hardware (e.g., a line card) is added or removed.
  System-controlled interfaces may also appear if a certain
  functionality is enabled (e.g., a loopback interface might appear if
  the IP protocol stack is enabled).

- user-controlled interface: An interface is said to be
  user-controlled if the creation of the interface is controlled by
  adding explicit interface configuration to the running configuration
  datastore and the removal of the interface is controlled by removing
  explicit interface configuration from the running configuration
  datastore.  Examples are VLAN interfaces configured on a
  system-controlled Ethernet interface.

In "The interface Lists":

For system-controlled interfaces, the "name" is the device-specific
name of the interface.  The 'config false' list
"/interfaces-state/interface" contains all existing interfaces on the
device.

If the device supports arbitrarily named user-controlled interfaces,
the NETCONF server advertises the feature "arbitrary-names".  If the
device does not advertise this feature, the names of user-controlled
interfaces MUST match the device's naming scheme.  How a client can
learn the naming scheme of such devices is outside the scope of this
document.

When a system-controlled interface is created by the system, the
system tries to apply the interface configuration in
/interfaces/interface with the same name as the new interface.  If no
such interface configuration is found, or if the configured type does
not match the real interface type, the system creates the interface
without applying explicit configuration.

When a user-controlled interface is created, the configuration
determines the name of the interface.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 22 May 2013 08:23:01 -0700

>   the IP protocol stack is enabled).

These system-created nodes are not limited to interfaces.
We use a YANG extension to control these objects automatically:
http://www.netconfcentral.org/modules/yuma-ncx/2012-11-10#user-write.652
(I need to upload the version w/ corrected description).

Do you think the ad-hoc approach of having each object
define this property independently is the best general solution,
or is some sort of generalized solution (such as a
YANG extension) needed to solve this problem?

> In "The interface Lists":
sorry I missed it, but what field indicates
whether the interface is system or user controlled?

> determines the name of the interface.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 22 May 2013 08:38:17 -0700 (PDT)

> YANG extension) needed to solve this problem?

Note that system-controlled vs. user-controlled refers to the
*operational state* interfaces.  (or actually, the underlying objects
in the system (typically in the kernel)).

The configuration is always created, modified and deleted by the
NETCONF client.

So I believe your extension does not apply to this case.

> whether the interface is system or user controlled?

There is no field for this.  Would it make sense to add one?

  // in /interfaces-state/interface:
  leaf controlled-by {
    type enumeration {
      enum system;
      enum user;
    }
  }

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 22 May 2013 09:00:41 -0700

> So I believe your extension does not apply to this case.
OK -- I guess 2 copies of everything works.
It supports pre-provisioning in a nice way.

>   // in /interfaces-state/interface:

not sure --  it may help but I haven't tried
to write an app using this module.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 22 May 2013 20:14:36 +0200

[...]

Looks OK to me (but then I am bad judge because I know what the text
is supposed to describe).

/js

---

From: t.petch <[email-masked]>
Date: Thu, 23 May 2013 16:29:11 +0100

----- Original Message -----
From: "Andy Bierman" <[email-masked]>
To: "Martin Bjorklund" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, May 22, 2013 5:00 PM

Andy

Could you be more specific about how you see it happening?

I had thought that pre-provisioning, say configuring eth0 to HDX
100Mbit/s where the card eth0 has yet to be plugged in, would create
entries in both /interfaces/ and /interface-state/ but the sense I now
have is the the latter entry must wait until the card appears.  Which
means that both /interfaces/ and /interface-state/ must be gotten in
order to understand where the box is at, that the absence of an entry in
/interface-state/ means that the card has yet to appear (which seems a
bit clumsy).  And it means that the server must not stop me from
configuring a name such as eth0 even though that has a specific meaning
to the server.

And if I create vlan0 to run over eth1 which does not yet exist but will
carry it when it does, then since vlan0 specifies eth1 as a carrier I
must configure eth1 even if there is nothing I wish to configure on it,
and even then, I cannot use an interface-state-ref until the card has
appeared which may mean going back and reconfiguring vlan0.

Do I understand this correctly?

Tom Petch

> to write an app using this module.

------------------------------------------------------------------------
--------

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 23 May 2013 09:31:09 -0700 (PDT)

Hi,

t.petch <[email-masked]> wrote:
> bit clumsy).

To some extent I agree with you.  My first thought was that the
pre-provisioned interface would show up in /interfaces-state/interface
with status 'not-present'.  But then Juergen pointed out that this is
not how devices work today.  If you configure a new interafce in
/etc/... on linux for non-existing hardware, it does not show in
ifconfig output.  Seems to be the same on popular routers as well.

It is also a bit unclear what exactly the problem is with the current
approach.  If you want to learn the status of an interface, you look
it up in /interfaces-state/interface.  If it is not there, it means
that there is no interface with this name created in the system.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 23 May 2013 20:25:54 +0200

> /interface-state/ means that the card has yet to appear (which seems a

The /interface-state tree reports operational state. If there is no
interface eth0, there hardly can be any operational state for it. It
simply does not exist. I do not see why this would be clumsy.

> And it means that the server must not stop me from configuring a
> name such as eth0 even though that has a specific meaning to the
> server.

Yes, if the system ever can have eth0, you can pre-configure it.

> must configure eth1 even if there is nothing I wish to configure on it,

Yes, you may want to enable that interface by configuring it. This is
a feature, not a bug.

> appeared which may mean going back and reconfiguring vlan0.

I am not sure I understand what the problem is. Yes, if you plug in a
card that pops up as eth4, then yes, your configuration needs to match
that. The same applies if you plug the cable into 4 instead of port 8,
you need to update the config. There is no AI here.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 23 May 2013 23:37:30 +0200

> simply does not exist. I do not see why this would be clumsy.

Yes, and moreover: we cannot be sure that the pre-provisioned config will be applied at all after the interface is installed (e.g., there may be mismatch in type).

>> appeared which may mean going back and reconfiguring vlan0.

Note that a leafref from config cannot refer to a leaf in operational state (YANG rule).
So interface-state-ref is confined to operational state data.

> you need to update the config. There is no AI here.

This goes back to the discussion of using opaque IDs as keys in the configuration list instead of the real interface names, and having the real name as another (non-key) leaf in the list entry. The VLAN entries would then refer to the opaque ID of the physical interface and this won't change. So, the only necessary change would be to update the name of the main interface (eth4) in *one* place. I still believe this would be a far better solution, because a very complex stack of interfaces could be preprovisioned without the risk of being forced to rewrite the name of the physical interface in many places.

Lada

---

From: t.petch <[email-masked]>
Date: Fri, 24 May 2013 17:49:42 +0100

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "Andy Bierman" <[email-masked]>; "Martin Bjorklund"
<[email-masked]>; <[email-masked]>
Sent: Thursday, May 23, 2013 7:25 PM

Juergen

I was using clumsy as the antithesis of elegant.

Elegant would be having an object that I could query to find out what is
currently going on, plus perhaps a notification of a significant change,
such as the card being plugged in, and so appearing in /interface-state.

Clumsy was querying /interface-state and having to use a failure,
because the object does not yet exist, to infer what is currently going
on - or not.

Perhaps it is no different to SNMP polling every 30 seconds in order to
find out.

Tom Petch

---

From: t.petch <[email-masked]>
Date: Tue, 28 May 2013 09:33:03 +0100

----- Original Message -----
From: "Ladislav Lhotka" <[email-masked]>
To: "Juergen Schoenwaelder" <[email-masked]>
Cc: "t.petch" <[email-masked]>; <[email-masked]>
Sent: Thursday, May 23, 2013 10:37 PM
On May 23, 2013, at 8:25 PM, Juergen Schoenwaelder

<snip>
>> appeared which may mean going back and reconfiguring vlan0.

Note that a leafref from config cannot refer to a leaf in operational
state (YANG rule).
So interface-state-ref is confined to operational state data.

<tp>

Lada, thanks for  putting me right - another of those ... Little Rules
that I forget.

Forgetting preconfiguration, looking at just configuration, this also
means

- I want to confgure vlan0 to run over something, say eth0
- I must link vlan0 to eth0
- I use a leafref to link the two
- since vlan0 is config, then I must also configure eth0, even though
everything the system has done for itself for eth0 is fine and I do not
need to change anything, yet I must create the entry in
/if:interfaces/if:interface else I cannot link to it.

Have I got it right?

> you need to update the config. There is no AI here.

This goes back to the discussion of using opaque IDs as keys in the
configuration list instead of the real interface names, and having the
real name as another (non-key) leaf in the list entry. The VLAN entries
would then refer to the opaque ID of the physical interface and this
won't change. So, the only necessary change would be to update the name
of the main interface (eth4) in *one* place. I still believe this would
be a far better solution, because a very complex stack of interfaces
could be preprovisioned without the risk of being forced to rewrite the
name of the physical interface in many places.

<tp>
Yes. Trouble is, the current SNMP key has been used outside SNMP and is
taken to be the best reference to use to refer to an interface so moving
to /if:interfaces/if:interface/if:name or
/if:interfaces-state/if:interface/if:name will be one hurdle and then
having an opaque ID might be too great a one.  I think that people will
use name (or ifIndex) in other protocols, and then have to jump through
a few hoops when that property is not as good as they would like it to
be, as happens at present with the inconstancy of ifIndex.

The best databases I know have opaque IDs as keys, which I am fine with,
but see my fellow users, who have not had to wrestle with issues such as
these, struggle with, thinking that what is intuitively obvious to them
as the unique identifier is not actually unique or an identifier.

Tom Petch

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 28 May 2013 18:56:31 +0200

> /if:interfaces/if:interface else I cannot link to it.

Yes, that's correct, though somewhat unfortunate. For every interface-ref, even from other modules, the corresponding entry in /if:interfaces/if:interface has to be present. If it isn't, it has to be created just for this purpose, provided that the client has write access to the interface list.

> as the unique identifier is not actually unique or an identifier.

Yes, I am afraid you are right. Interestingly, it is not a problem for software, such as MongoDB. It takes some time to get used to the proper ways of dealing with object IDs, but users have no choice, and then, after a period of huffing and puffing, one can eventually take advantage of their approach. On the other hand, for a standard, such a hurdle seems to be a non-starter.

Lada

---

From: "Lange, Jeffrey K (GE Energy Management)" <[email-masked]>
Date: Wed, 29 May 2013 17:53:19 +0000

Martin asked that I provide my $0.02 on this draft as we've created an implementation against the -08 version. So here we go...

In general I like having the interface-state separate from the interface configuration, it provides an easy way for a user to see what devices are currently in the system and are available for configuration.  In our -08 implementation we created a /interfaces/physical-interfaces table that would be pre-populated by the factory with the interfaces that are available for that particular product.  Note that our product is not customer expandable, so the interfaces that ship with the unit are the only ones that the customer can configure (ignoring logical interfaces).  By having this config false list of interfaces we could achieve the same thing in a more standard way.

However there is one sticking point that prevents us from using -11 (or -08) as is.. that is the mandatory requirement of "type"  We have many proprietary interface types (primarily different types of in-house radio interfaces) that do not fit into the categories defined by iana-if-type.  Sure you could use the argument "well then get them added via iana".  But that will never happen.  So that leaves us with a few choices.  What we did with our -08 implementation was to create our own interface type identity that we could extend with different types of interfaces (which by the inherent beauty of identities is also works well for splitting out our different interface types into separate yang files).  We then removed the existing type and replaced it with ours.  While I agree this is not in the spirit of using an open-standard, in my mind, end-user usability comes first.

So that being said here are my suggestions, which may be taken with a grain of salt, but I can guarantee that our products will not be able to 100% implement the proposed standard as-is without them.

1) change if-iana-type to an identity.  I know this was brought up in the past.. by me if I recall =) By making this an identity the ability to extend it with vendor specific types would make things far easier for vendors that create custom interface types.  If there is strong opposition to this, then I would propose a secondary leaf vendor-specific-type or something like that which is an identity, and _can_ be extended by vendors in a standard way.  Perhaps with a must statement that states that if "type" is "other"  Then the vendor specific type must be set.

2) If a user is creating a configuration entry in /interfaces/interface, and that name matches the name of one of the interfaces in /interfaces/interface-state the value of "type" should not be mandatory.  This is redundant configuration information which can be implied by the config-false type defined in the corresponding interface-state. By this node being mandatory you are introducing the possibility of a configuration mismatch.  What happens if /interfaces/interface-state{eth0}/type == Ethernet and /interfaces/interface{eth0} == wifi? I believe that if the names match, the value in interface-state should win.  This also eases the burden on user who is configuring the system, they don't care what the underlying type of cellular link on a radio is. They just know that the screen-print on the front box says "cell", and they want to configure the "cell" interface.

-Jeff

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 29 May 2013 22:16:10 +0200 (CEST)

Hi Jeff,

Thanks for your comments.  My responses inline.

"Lange, Jeffrey K (GE Energy Management)" <[email-masked]> wrote:
> 1) change if-iana-type to an identity.  I know this was brought up in the
> past.. by me if I recall =) By making this an identity the ability to extend it
> with vendor specific types would make things far easier for vendors that create
> custom interface types.

It was also my first idea to use an identity; it was later changed to
the current enumeration b/c of WG feedback.  I think the major
argument is that everyone benefits from having standard interface
types, instead of each vendor defining their own flavor of
ethernet etc.

> If there is strong opposition to this, then I would
> propose a secondary leaf vendor-specific-type or something like that which is
> an identity, and _can_ be extended by vendors in a standard way.  Perhaps with
> a must statement that states that if "type" is "other" Then the vendor specific
> type must be set.

This can already be done by a vendor.  Note that you could do this,
and since you are allowed to fill in the 'type' when the user creates
the interface, you could always fill in 'other' (and maybe your own
vendor-type).  However, this solution is not optimal.

> 2) If a user is creating a configuration entry in /interfaces/interface, and
> that name matches the name of one of the interfaces in
> /interfaces/interface-state the value of "type" should not be mandatory.  This
> is redundant configuration information which can be implied by the config-false
> type defined in the corresponding interface-state.

So an implementation can fill in the type in this case.

The reason for the type is that we want to achieve conditional
augment, based on the type.  In current YANG, this means the type must
be config.

> By this node being mandatory
> you are introducing the possibility of a configuration mismatch.  What happens
> if /interfaces/interface-state{eth0}/type == Ethernet and
> /interfaces/interface{eth0} == wifi?

In this case the configuration is not applied to the interface.  This
is the text (with the new terms system-controlled and user-controlled):

         If the configuration of a
         system-controlled interface cannot be used by the system
         (e.g., the interface hardware present does not match the
         interface type), then the configuration is not applied to
         the system-controlled interface shown in the
         /interfaces-state/interface list.

> I believe that if the names match, the
> value in interface-state should win.  This also eases the burden on user who is
> configuring the system, they don't care what the underlying type of cellular
> link on a radio is. They just know that the screen-print on the front box says
> "cell", and they want to configure the "cell" interface.

Note again that this can be done today - you can fill in the type for
the user (and in a human-oriented interface you may chose to not make
the type leaf available at all).

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 30 May 2013 01:52:04 +0200

On Wed, May 29, 2013 at 05:53:19PM +0000, Lange, Jeffrey K (GE Energy Management) wrote:
> Martin asked that I provide my $0.02 on this draft as we've created
> an implementation against the -08 version. So here we go...
> 
> In general I like having the interface-state separate from the
> interface configuration, it provides an easy way for a user to see
> what devices are currently in the system and are available for
> configuration.  In our -08 implementation we created a
> /interfaces/physical-interfaces table that would be pre-populated by
> the factory with the interfaces that are available for that
> particular product.  Note that our product is not customer
> expandable, so the interfaces that ship with the unit are the only
> ones that the customer can configure (ignoring logical interfaces).
> By having this config false list of interfaces we could achieve the
> same thing in a more standard way.

This is _very_ welcome feedback. Implementation experience is always
very welcome - if others implement things as well, please consider to
share your experiences. This helps a lot.

> We have many proprietary interface types (primarily different types
> of in-house radio interfaces) that do not fit into the categories
> defined by iana-if-type.  Sure you could use the argument "well then
> get them added via iana".  But that will never happen.

I have to ask this so I do better understand. Why will this never
happen?

- Is the procedure to register your interface type too complex?

- Is the interface type kind of secret and hence you do not want to
  have it registered somewhere?

- Is it that developers simply would not know how to register a new
  interface type and choose a random value anyway?

- Something else?

/js