Subject: [netmod] review of draft-openconfig-netmod-opstate-00

From: Kent Watsen <[email-masked]>
Date: Tue, 16 Jun 2015 01:01:55 +0000

[As an individual contributor]

In preparation for our Virtual Interim meeting this Thursday, my primary goal was to understand the problems needing to be solved.   Hopefully this isn't too much of a simplification, but there seems to be just the single core issue:

  - no programatic mechanism to relate running state to intended
    state (configuration).  Currently, management systems must
    code to the text found YANG description statements.

The draft then puts forth a a number of recommendations to address the issue including:

  - recommendation to put state in leafs
  - recommendation to use a naming convention
  - recommendation to have statement like operational true/intent/false
  - recommendation to add to YANG a map statement  (since lists don't support deep keys)
  - recommendation to allow config=true inside config=false containers

Some parts of the draft did not make sense to me.   For instance, the synchronous vs asynchronous discussion didn't seem to be connected to the solution.  Same for the desire to have an asynchronous push notification mechanism.  Separately, I don't agree that receiving NETCONF RPC-reply <ok/> means that the intended configuration is operational, so much as "received by the server".  I also don't agree that every configured value has op-state - e.g., consider a server's hostname.

Overall I agree that it would be nice if there was a programmatic mechanism to relate intended and configured state, even if only for state nodes that are identical to configured nodes.  But I m struggling to understand the importance of supporting generic clients that do not understand the semantics of a model well enough to know where and how to consume its operational state.

Thanks,
Kent

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 16 Jun 2015 10:18:44 +0200 (CEST)

Hi,

Kent Watsen <[email-masked]> wrote:
> In preparation for our Virtual Interim meeting this Thursday, my
> primary goal was to understand the problems needing to be solved.
> Hopefully this isn't too much of a simplification, but there seems to
> be just the single core issue:
> 

I also re-read this document yesterday, and I agree with this
conclusion.

Note that section 5.19 of the recently published
draft-ietf-netmod-rfc6087bis-03 contains text that tries to illustrate
some of the issues around the problem of associating state with
config.

>   - recommendation to add to YANG a map statement (since lists don't
>   - support deep keys)
> Some parts of the draft did not make sense to me.  For instance, the
> synchronous vs asynchronous discussion didn't seem to be connected to
> the solution.

I am also confused by the terms "intended config" and "actual
config", and the lifecycle of these objects in an asynchronous
system.  Is the idea that every leaf that you can configure exists in
three different places:

  o  as "actual config" (under the "config" container)
  o  as "intended config" (under the "state" container)
  o  as "operationally used value" (also under the "state" container,
     but presumably with a different name?)

When a client tries to set this leaf in an asynchronous system, will
the "intended config" value be set first, then the "actual config",
and lastly the "operationally used value"?

The examples in the document don't reflect this, so maybe I didn't get
it right.

/martin

> Same for the desire to have an asynchronous push
> notification mechanism.  Separately, I don't agree that receiving
> NETCONF RPC-reply <ok/> means that the intended configuration is
> operational, so much as "received by the server".  I also don't agree
> that every configured value has op-state - e.g., consider a server's
> hostname.
> 
> Overall I agree that it would be nice if there was a programmatic
> mechanism to relate intended and configured state, even if only for
> state nodes that are identical to configured nodes.  But I m
> struggling to understand the importance of supporting generic clients
> that do not understand the semantics of a model well enough to know
> where and how to consume its operational state.
> 
> Thanks,
> Kent
> 
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 16 Jun 2015 14:13:32 +0200

Kent Watsen <[email-masked]> writes:

> the solution.  Same for the desire to have an asynchronous push

Well, in fact hostname does need an op-state copy, and it's IMO a gap in
ietf-system that it doesn't provide one. Even if there is a configured
value, the system may use something else, perhaps because somebody ran
"hostname" command in the mean time.

Lada

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

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 16 Jun 2015 14:21:41 +0200

> I also re-read this document yesterday, and I agree with this

+1

> The examples in the document don't reflect this, so maybe I didn't get

I agree it is confusing, and in particular I don't get the naming -
intended configuration should be an operator's intention,
i.e. config=true, no?

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 16 Jun 2015 14:24:08 +0200 (CEST)

> intended configuration should be an operator's intention,

That's what I thought, but not what the document says; hence the
confusion.  I am asking for clarification.

/martin

---

From: Benoit Claise <[email-masked]>
Date: Thu, 18 Jun 2015 10:56:49 +0200

Dear all,

While I believe that the interim today should primarily focus on getting 
agreement on the problem statements, I anyway looked at the solution.
In preparation, I created my own drawing of the proposed solution.

I hope it will help regarding terminology, as it might become confusing 
very quickly.
Indeed:
- NETCONF only mentions configuration and state data
- RFC 6244 mentions:

        oConfiguration data  is the set of writable data that is required to
           transform a system from its initial default state into its current
           state [RFC4741].

        oOperational state data  is a set of data that has been obtained by
           the system at runtime and influences the system's behavior similar
           to configuration data.  In contrast to configuration data,
           operational state is transient and modified by interactions with
           internal components or other systems via specialized protocols.

        oStatistical data  is the set of read-only data created by a system
           itself.  It describes the performance of the system and its
           components.

- And this draft mentions four different terms: See the drawing.

Regards, Benoit
> support deep keys)
> that every configured value has op-state – e.g., consider a server's 
> hostname.
>
> state nodes that are identical to configured nodes.  But I 
> m struggling to understand the importance of supporting generic 
> clients that do not understand the semantics of a model well enough to 
> know where and how to consume its operational state.
>
> Thanks,
> Kent
>
>
>
>