Subject: [netmod] openconfig clarification on applied config

From: Martin Bjorklund <[email-masked]>
Date: Thu, 14 Jan 2016 10:19:06 +0100 (CET)

Anees,

I am trying to understand (again/still) exactly what your (openconfig)
intention is re applied config.

First, re. pre-configuration.

draft-openconfig-netmod-opstate-01.txt says:

   It is notable that the intended configuration and the applied
   configuration represent exactly the same set of variables (leaves).
   These may have different values based on the current point in time
   (e.g., if the change has not been communicated to an external
   software entity), or due to missing dependencies (e.g., a particular
   linecard not being installed).

So it seems that if hw is missing, the corresponding config is NOT
part of applied.

But in
https://mailarchive.ietf.org/arch/msg/netmod/h-SaTZnCc8deZk2yFDM9Q54OKfw
you wrote:

  Similarly, if an implementation supports pre-configuration of
  interfaces, for example, the intended configuration reflects that
  preconfiguration, while the corresponding state would show that it
  is applied but also that oper-status = 'NOT PRESENT'.

This seems to say that the pre-configured interface would show up both
in intended and applied.

I realize that the email was written some time after the draft was
published.

What is the correct answer?

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

Here's another situation.   Suppose I configure some daemon to listen
to a port that happens to be used on the system (let's say I picked
32768, and it was assigned by the kernel to some process listening to
0 just microseconds before my daemon tried to use it).  It is clear
that intended would contain port 32768, and it is clear that the
derived state would show that some other processes uses this port, but
what would end up in applied?  Specifically, if your answer is that
applied != intended in this case, what exactly would be different?
Just the port, or also the rest of the daemon's config?

/martin

---

From: Anees Shaikh <[email-masked]>
Date: Thu, 14 Jan 2016 22:48:35 -0800

Hi Martin, thanks for your note -- please see my comments inline.  I'm not
sure they will help given the recent netmod threads on this topic, however.
 :-)

> First, re. pre-configuration.

<snip>

> What is the correct answer?

The expectation here, as described in the last version of the draft, is
that the pre-configuration would only appear as intended configuration, not
applied, since the system cannot apply the configuration until the
corresponding linecard is plugged in, for example.   The NMS could
determine the state using oper-status as you referenced.

this is an interesting example ... what we have discussed is that if the
system sets some configuration, that should be reflected in the applied
config (i.e., as part of operational state).

In this case, it might be that the system rejects the configuration because
it can't honor it (as you said, derived state could be used to see that
another process is using that port).   If the system chooses another port
for the daemon, then the applied config could reflect that.

Regarding other parts of the daemon's config, I'd expect only the port to
be different between intended and applied, unless the system rejects the
entire configuration due to the port collision (seems unlikely).   This is
probably dependent on the implementation -- the NMS could at least learn
this by seeing that the applied config is not set for the other
configuration values.

thanks.
-- Anees

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 15 Jan 2016 09:59:21 +0100 (CET)

Hi Anees,

> sure they will help given the recent netmod threads on this topic, however.

Thank you for you reply, I think it helps to clarify some of the
confusion that I see when reading these threads on the ML.

> determine the state using oper-status as you referenced.

Ok, thanks.  This is a clear statement.

> another process is using that port).

Sure.  But the interesting scenario is that the config is accepted,
and then when the daemon tries to use it, it fails.  Another
situation where this can happen is after a restart.

> If the system chooses another port

Hmm.  If I configure a specific port, I wouldn't expect the system to
select another port.  However if I specified "0" (use any free port),
I would expect "0" to be reflected in applied, but the real port to be
reflected in derived state, similar to the example of duplex "auto".
Do you agree?

> this by seeing that the applied config is not set for the other

Ok, makes sense!

/martin