Subject: [netmod] opstate-reqs: terminology

From: Phil Shafer <[email-masked]>
Date: Tue, 29 Sep 2015 14:37:39 -0400

Semi-in-reply-to: <[email-masked]>

I keep thinking the terms in the draft somewhat confusing.  Okay,
confusing isn't exactly right.  I find the terms have a lot of
background that needs to be explained that's not obvious from the
simple explanations in the draft.  The reader will see these terms
and think they know what they mean without that deeper understanding.

For example:

   o  applied configuration - this data represents the state that the
      network element is actually in, i.e., that which is currently
      being run by particular software modules (e.g., the BGP daemon),
      or other systems within the device (e.g., a secondary control-
      plane, or line card).

This says nothing about how the current state relates to the
configuration.  The term "applied configuration" would imply that
this state is driven by configuration, but there's really nothing
here addressing that.  Does config for interfaces that don't exist
appear in AC?  Do implicit peers appear along side explicitly
configured ones?

Likewise:

   o  derived state - this data represents information which is
      generated as part of the system's own interactions.  For example,
      derived state may consist of the results of protocol interactions
      (the negotiated duplex state of an Ethernet link), statistics
      (such as message queue depth), or counters (such as packet input
      or output bytes).

There's nothing that clearly delineates DS from AC.  The switch
from "state" to "information" doesn't really add anything concrete.
Why is AC state but DS information?

How does one decide which category any particular leaf belongs in?
Does "protocol interactions" include ospf peers, their status, and
learned routes?  Is this the same for both explicitly configured
peers and unconfigured peers (set protocols ospf interface ge-0/0/0)?

I wouldn't have thought duplex as derived state, given that I can
configure a value for it.

Would it be better to think of these values in three sets?

A) values given explicitly by the user (== IC == running config)
B) current values which use organization identical to (A)
C) current values which are not organized identical to (A)

I think the real key is that values which _can_ be organized by the
data models used in (A) _should_ use identifical organization in (B).
When I read openconfig, that seems to be their real requirement.

So if (A) has duplex or OSPF peers or interfaces, then (B) will
list duplex state, peer state, and interface state using an identical
organization (in terms of parentage or containers, lists, and keys).

Once the concepts are clear, selecting terminology should be easier.
I'd actually prefer terms like "primary state" and "secondary state"
which force the reader to look up their meaning to terms like
"derived state" which the reader will likely assume they know the
meaning of.  Clean terms really help with understanding and discussions
especially when the audience grows beyond the key players active
here.

Should a request for better terms be a new, distinct issue?

Andy B. writes:
>> I do not agree at all that the running datastore means anything other
>> than the intended confg.   A new operation is needed to retrieve
>> the active config vs. the intended config.

Do we have a definition for "active config"?  Is this running config
or the parts of AC that are fed by IC?

Robert Wilton writes:
>If the running datastore only ever means intended config, then I think 
>that would imply:
>
>  - existing NETCONF servers should reply immediately after the config 
>has been semantically verified + written to the config subsystem before 
>the configuration is applied.

The running datastore is definitely only intended config.

My question is what "the configuration change MUST also be applied
in the system" means in a world of a hundred FRUs with a zillion
chips.  Does an "applied" MTU mean it hits the kernel, the embedded
FRU, or the final chip with enforces the MTU?  Does an "applied"
BGP peer mean an open connection or full route exchange and FIB
update?  There's a lot of gray space here.

The original NETCONF view is that when the config is atomically
accepted as the new, valid config, it's done.  Are we really talking
about changing that?

You see the same issue with AC's used of "particular software
modules", where any piece of functionality might well be a distributed
set of software instances, often with differing code (kernel,
embedded, chip).

FWIW, in JUNOS we show configuration from the configuration database
and _most_ operational commands from the routing engine, either
from its kernel or the daemons running on it.  We expect the kernel
to propagate an MTU as needed without asking the embedded FRU or
chips for their view of the MTU.

>  - the existing NETCONF/RESTCONF protocols has no direct mechanism for 
>indicating a failure to apply any configuration leaf, the only way such 
>information could be deduced is through related operational state leaves 
>or notifications.

True, and this is one of the thing I think openconfig hopes to
address, by allowing apps that fetch IC, fetch AC, and diff them
(with suitable diff logic), which stresses the importance of
reusing organization.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Tue, 29 Sep 2015 12:30:09 -0700

Hi,

Perhaps the operational requirements are not that clear, so
the terminology is also not that clear?

Is there really a requirement to know detailed info about the
differences between intended and applied config?

It seems like the general requirement is that the client
needs to know when it can start using the network resource
that has been added or modified in the intended config.

There are 2 modes that fall out from this requirement:
  1) synchronous: do not return from this RPC until resources are ready
  2) asynchronous: return right away from this RPC, and inform the client
       when the resources are ready (could indicate ready in the RPC
response)

Andy

On Tue, Sep 29, 2015 at 11:37 AM, Phil Shafer <[email-masked]> wrote:

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

---

From: Phil Shafer <[email-masked]>
Date: Tue, 29 Sep 2015 15:51:10 -0400

>the terminology is also not that clear?

Are we trying to agree on the former without the later?

>differences between intended and applied config?

I'm assuming this will end up impacting either netconf operations
or yang data model construction.  At that point (if not before),
we'll need clear terms for app writers and data modelers.

>that has been added or modified in the intended config.

Consider that case where you add interface config for an interface
FRU that's not been inserted.  This config might not be used for
months, until the tech inserts the FRU.

>       when the resources are ready (could indicate ready in the RPC response)

Given the inherently squishy definition of "ready", I'd prefer to avoid #1.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Tue, 29 Sep 2015 13:22:59 -0700

> we'll need clear terms for app writers and data modelers.

I don't have any objection to "intended" and "applied" as terms.

> months, until the tech inserts the FRU.

Clearly a case where the client should pick (2)

> Given the inherently squishy definition of "ready", I'd prefer to avoid #1.

None of the protocols actually tell the client which one they did, for a
given edit.
I agree the best we could say is "I think it's ready right now".
However, I think even this much could require massive code changes in many
systems.

Andy

---

From: Robert Wilton <[email-masked]>
Date: Wed, 30 Sep 2015 11:10:22 +0100

On 29/09/2015 21:22, Andy Bierman wrote:
>
>
> On Tue, Sep 29, 2015 at 12:51 PM, Phil Shafer <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Andy Bierman writes:
+1.

I think that the terms will be fine once we agree on the definitions of 
them, and I think that we probably already agree on "intended".

>     >that has been added or modified in the intended config.
I agree.

Perhaps some wording based around the above might be a better way of 
defining "applied configuration"?

E.g. considering that case where an VPWS service is being provisioned.  
I would expect that a programmatic client might choose to wait until the 
configuration to instantiate the VPWS service has been applied before 
starting to verify the end-to-end connectivity as a pre-requisite to 
using the service.

>     >  1) synchronous: do not return from this RPC until resources are

For a synchronous request I would suggest that the server should wait 
until it has programmed all resources that are currently available (i.e. 
installed in the system) and to warn on any resources which can't be 
programmed because they are not present. Not returning from a request 
because an item of hardware is physically not present in the system 
doesn't sound like a usable design to me.

> None of the protocols actually tell the client which one they did, for 
> a given edit.

Ideally, I think that it would be good if a server could indicate 
whether it supports (1) or (2) or both, and to allow a client to choose 
which semantics are expected to be used when making the request.

Rob

> However, I think even this much could require massive code changes in 
> many systems.
>
>
>
>     Thanks,
>      Phil
>
>
>
> Andy
>
>
>