Subject: [netmod] YANG coordination feedback on draft-openconfig-netmod-opstate-01

From: Benoit Claise <[email-masked]>
Date: Thu, 10 Sep 2015 10:40:03 +0200

Dear all,

The YANG coordination team 
<http://www.ietf.org/iesg/directorate/yang-model-coordination-group.html> has 
spent some time reading and gathering input on the requirements and 
proposed solutions in draft-openconfig-netmod-opstate. This note is to 
collect some observations that will hopefully contribute to progress in 
the working group.

We believe it is useful to consider that YANG was initially designed to 
be a data modeling language for the NETCONF protocol. IETF is also 
working on RESTCONF which is an HTTP-based protocol to access data 
defined in YANG, using the datastores defined in NETCONF.

YANG is fulfilling its intended role with NETCONF and RESTCONF and has 
gained some significant traction in this capacity. There are some 
changes worked on in YANG 1.1, but they are mostly incremental.

There is interest in using other protocols outside of NETCONF and 
RESTCONF to manipulate data described by YANG. The proposals in the 
draft is based on the assertion that YANG models should be usable for 
protocols beyond RESTCONF and NETCONF. So these are new requirements on 
YANG from, or in preparation for, new protocol bindings.

We have focused on two main aspects of the draft.

FIRSTLY: The proposed split between intended and applied configuration 
as described in sections 4.1 (requirements) and 5.1 (implications)

There are two observations here:
1. The implication is that all configurable data nodes ("intended 
configuration") shall be repeated in an operational version ("applied 
configuration") in all models for all applications going forward. This 
would apply independent of if the system is synchronous or asynchronous 
in nature. Synchronous systems would simply hard-wire the applied 
configuration to be the same as intended configuration at all times.
2. An informal round of conversations with some vendors as well as some 
tooling vendors show that there are currently no widely known platforms 
that allow for observing the intended and applied state separately. A 
common architecture includes a central configuration data store that is 
being updated by the manageability framework and updates read by the 
subsystems affected by the change (e.g. the BGP service or the interface 
manager). In this case, there is no other source of configuration except 
for the content of the data store.

Please note that this was not an exhaustive collection of data, but 
should give some directional information.

The *implication* we would like to make here is that by making this 
feature mandatory part of the YANG language itself (as opposed to an 
optional capability) we risk introducing a fake perception that the 
current NETCONF server supports a capability it can't support. Indeed, 
polling the applied configuration would always return the intended 
configuration.

A *question* would be if it would be useful to consider a direction 
where we make an attempt to separate out requirements that are tied to 
specific protocols and solve them in the protocol semantics rather than 
in the language to the extent we can. Without knowing more about the 
intended protocol in the case of this draft, it is hard to make more 
progress.

A *suggestion* is to ask the draft authors to document the protocol 
bindings in order to qualify the requirements going forward.

SECONDLY: The proposed schema locations for configuration and 
corresponding operational state in sections 4.5 (requirements) and 5.4 
(implications)

The observation to be made here is well captured in the draft itself as 
bullet 3 under section 7:

     "The proposal does not allow items that are not configured, 
configured but not present, or system configured."

Please note that this is a general note that would apply to the language 
itself. Meaning that YANG will no longer be able to describe situations 
like the above for any type of application in any context.

Examples beyond what's already mentioned in the bullet of this could 
include:
- Removable physical assets (line cards, mezzanine cards) in systems 
that allow pre-provisioning of configuration
- Physical assets that arrive in the system with readable default state

Independent of the direction we will be taking going forward, the 
implication we make is that it is a pretty significant impact on the 
expressivity of the language itself and how useful it is in terms of 
modeling application data sets that may not align with the requirements.

The question we would ask is if it would be possible to rebalance the 
implication and make it a little more modular and optional in the 
language. We are aware of suggestions to use the extensibility of the 
language itself (e.g. in draft-kwatsen-netmod-opstate) to express 
relations across data sets. Understanding that this suggested approach 
does not normalize the paths according to the wish of the authors, but 
it can perhaps be a balanced approach that impacts the expressivity less.

                         Regards, the YANG coordination team

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 10 Sep 2015 11:46:30 +0200

Hi,

comments inline.

> for the content of the data store.

It may be because vendors tend to limit user access to the device
configuration to a few official interfaces.

In contrast, consider for example a typical Linux system. No matter what
"official" configuration system is used (init scripts, NetworkManager,
UCI in OpenWRT, even NETCONF), there is always a way to change the
run-time configuration without the official configuration system being
notified. For instance, one can go to the /proc filesystem and change
many kernel parameters on the fly, such as IP addresses assigned to
interfaces.

Since I am mainly interested in such open systems, I do see a use case
for making the distinction between intended and applied
configuration. And by the way, it might help solve the NETCONF/I2RS
dilemma: NETCONF/RESTCONF would only be allowed to modify intended
configuration whereas I2RS would operate exclusively on applied
configuration.

Finally, most existing NETMOD models in fact already have intended and
applied configuration even if they aren't called so: the applied one is
represented by nodes in *-state trees that are duplicates of
configuration entries.

> - Physical assets that arrive in the system with readable default

I agree, existing NETMOD modules already support pre-provisioning and
system-controlled components.

Lada

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

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

---

From: Lou Berger <[email-masked]>
Date: Thu, 10 Sep 2015 08:24:51 -0400

Benoit,

A nit on your mail:

> for the content of the data store.

While this narrow statement is true, every system I know about can provide 
the equivalent of applied config state via show commands.

Lou

> ----------

---

From: "Einar Nilsen-Nygaard (einarnn)" <[email-masked]>
Date: Thu, 10 Sep 2015 12:43:24 +0000

Lou,

Speaking as an embedded device developer, I think the point here is that up until today there are not very many systems that specifically show the applied config in exactly the same "syntax" as used for providing the intended config. Yes, the applied config can be implied from the output of show commands, but not in a way that is directly correlatable to the config the operator intended, by either operators themselves or by automation tools.

I completely agree that providing a mechanism whereby management systems and operators can easily see the correlation is important, but we do have to realize that this will likely be a non-trivial exercise for embedded systems to support this in the way the "opstate" draft or any other draft intends for the distributed or asynchronous use cases, and I speak from experience based on some work we are currently undertaking on similar ideas and applying them to existing embedded systems.

Cheers,

Einar

> for the content of the data store.

While this narrow statement is true, every system I know about can provide the equivalent of applied config state via show commands.

---

From: Lou Berger <[email-masked]>
Date: Thu, 10 Sep 2015 09:49:05 -0400

Einar,

On 9/10/2015 8:43 AM, Einar Nilsen-Nygaard (einarnn) wrote:
> Lou,
>
> Speaking as an embedded device developer, I think the point here is
> that up until today there are not very many systems that specifically
> show the applied config in exactly the same "syntax" as used for
> providing the intended config. Yes, the applied config can be implied
> from the output of show commands, but not in a way that is directly
> correlatable to the config the operator intended, by either operators
> themselves or by automation tools.
>
> I completely agree that providing a mechanism whereby management
> systems and operators can easily see the correlation is important, but
> we do have to realize that this will likely be a non-trivial exercise
> for embedded systems to support this in the way the "opstate" draft or
> any other draft intends for the distributed or asynchronous use cases,
> and I speak from experience based on some work we are currently
> undertaking on /similar/ ideas and applying them to existing embedded
> systems.
>

Agree 100%.  I responding to the point that no systems "allow for
observing the intended and applied state separately".  I think they do,
but you certainly are also correct that the format (and UI) is
completely different and there is a real cost in both development and
runtime for support this new capability .

Lou

>> While this narrow statement is true, every system I know about can
>> provide the equivalent of applied config state via show commands.
>>

---

From: Rob Shakir <[email-masked]>
Date: Thu, 10 Sep 2015 10:45:33 -0400

Benoit,

I want to pick up on this very specific point. I think Lou’s mails imply a similar position, but I want to be clear.

On September 10, 2015 at 04:40:30, Benoit Claise ([email-masked]) wrote:
> > A common architecture includes a central configuration data  
> store that is being updated by the manageability framework and  
> updates read by the subsystems affected by the change (e.g. the  
> BGP service or the interface manager). In this case, there is  
> no other source of configuration except for the content of the  
> data store.

The configuration file/‘store’ of a system shows the intent of how that system should be configured. We can agree that all implementations need to have this.

The applied configuration is the value of those configuration elements a daemon/software component/programmable memory is actually running, which can be compared to the intent. Essentially, this is *dynamic* information which is the *state* of the running system. Implementations *do* store this. I think the point that you are making here is not that it is not supported. The point is that it is dynamically built at query time, according to a different schema.

This different schema is bad news, programmatically. How did I know that the static (IOS-alike configuration):

router bgp 65497
 neighbor 192.0.2.1 remote-as 65500

Needs me to run:
 
show bgp ipv4 unicast neighbor 192.0.2.1 | i remote AS

and then run a regexp that extracts the following AS number after the words ‘remote AS’. Today - I probably need to write a mapping table that tells me that.

The requirement is that we can determine, for a particular leaf - what the intended value is, AND the value which is applied, PLUS be able to “easily” retrieve the state associated with that construct - in a way that is deterministic, and does not require per-leaf mapping tables to be maintained like we might have to today.

The point about identical values is that *in cases where no such retrieval of the actual applied config values is possible* a system can simply make all the applied leaves pointers to the intent. This would be akin to the ‘show’ command doing the equivalent of ‘show running-config | i 192.0.2.1.*remote-as’ and extracting the remote-as from there AFAICS.

Regards,
r.

---

From: "Carl Moberg (camoberg)" <[email-masked]>
Date: Thu, 10 Sep 2015 19:43:56 +0000

Inline:

> On Sep 10, 2015, at 11:46 AM, Ladislav Lhotka <[email-masked]> wrote:
> 
> Hi,
> 
> comments inline.
> 

 Agreed, a strong requirement for most of these systems is to provide coherent views of configuration and state through a set of protocols (normally CLI, SNMP and NETCONF). And since the application-level environment in theses systems are usually very heterogenous (various userland and kernel subsystems, some based on open source, some proprietary), it is hard to avoid a registry-style approach with integration interfaces for various types of applications.

> configuration whereas I2RS would operate exclusively on applied

 I think the issue at hand here is that the suggested changes require that all (intended) configuration parameters always have corresponding (applied) values.

 This will actually make a little interesting for open (or perhaps more loosely coupled) systems like the one you mention above. For every (intended) configuration parameter you model, you need to come up with a way to read back the applied configuration.

 Now, think about configuration parameters that have applied configuration located in more than one place. Let’s say you change the IP address of an interface, it is likely that this configuration will be passed around as input to a handful of subsystems (e.g. the DHCP server, some routing daemons that may bind to specific IP addresses). Is the intended and applied in sync when a specific subset of those configurations are updated. What happens if there’s a partial failure?

> represented by nodes in *-state trees that are duplicates of

 Yes, but do we want to enforce this for all models for all applications?

---

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 10 Sep 2015 14:05:41 -0700

> On Sep 10, 2015, at 7:45 AM, Rob Shakir <[email-masked]> wrote:
> 

This makes a whole lot more sense to me from a requirement perspective than what has been proposed in draft-openconfig-netmod-opstate.  I am not going to comment on what it will require to implement this. We agreed with no objections for requirement 2 as Kent put it out, but it would help to rephrase it. 

2. Ability to determine whether the configuration intended for the device has been applied.

To determine whether the configuration has been applied, the client should be able to query the construct and the values therein, including any state associated with the value, and get in return values that should allow the *client* to determine whether the configuration has been applied. 

Note, I emphasized client because if the returned value could be a state construct instead of a boolean value. In addition, one client’s interpretation of the values including state value might be different from another client.

Note also, I am trying (very hard) not to propose a solution :-), specially as to whether the data is operational data or config false. This will allow for the best solution to be proposed.

> The point about identical values is that *in cases where no such retrieval of the actual applied config values is possible* a system can simply make all the applied leaves pointers to the intent. T…

Mahesh Jethanandani
[email-masked]

---

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 10 Sep 2015 16:13:53 -0700

> On Sep 10, 2015, at 12:43 PM, Carl Moberg (camoberg) <[email-masked]> wrote:
> 

This is a good example. Another example, and somebody on the call today started to ask this but got cut off, relates to interfaces on the device.

Interfaces already exist on a system. As such they have a configuration (default values) that exists on them. They are enabled when configuration gets applied on them. They will have applied configuration but no intended configuration. Should this be reported?

Yet another example is of a BFD session that gets bootstrapped because of a ping. There is no intended configuration, but the session exists and a query of configuration in this case would return a valid BFD session.

Could we get some clarification (with examples, preferably) on what the expectation is from a openconfig opstate perspective?

Mahesh Jethanandani
[email-masked]

---

From: Sam Aldrin <[email-masked]>
Date: Thu, 10 Sep 2015 18:30:59 -0700

> On Sep 10, 2015, at 4:13 PM, Mahesh Jethanandani <[email-masked]> wrote:
> 
> 
>> On Sep 10, 2015, at 12:43 PM, Carl Moberg (camoberg) <[email-masked] <mailto:[email-masked]>> wrote:
>> 

Section 7 of draft-openconfig-netmod-opstate talks about that. Specifically, #3 talks about the interface question you raise..
Also, Rob mentioned on the call that, this is no different than BGP specific config/state (draft-ietf-idr-bgp-model).

-sam
> 
> Mahesh Jethanandani
> [email-masked] <mailto:[email-masked]>
> 
> 
>

---

From: Anees Shaikh <[email-masked]>
Date: Thu, 10 Sep 2015 22:05:11 -0700

Benoit, I think Rob and others have already addressed the first issue
raised in the comments from your group.  For the second point, your mail
says that the OpenConfig opstate draft says:

 *   "The proposal does not allow items that are not configured, configured
but not present, or system configured."*

*Please note that this is a general note that would apply to the language
itself. Meaning that YANG will no longer be able to describe situations
like the above for any type of application in any context.*

While the draft does say this, you've unfortunately misunderstood the point
being made in that section (I'll have to accept some responsibility for
writing it this way).  The preface to Section 7 says, "A number of issues
have been raised with the proposed solution ..." and point #3 is just
stating the issue that was raised with regard to our proposal -- if you
read the rest of the explanation in #3, it describes an example of how the
solution can address these situations, using a specific example of
configuring 'all' interfaces , some of which may not be present.
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'

So I would say that your point about the solution limiting expressivity
that is otherwise allowed by the language is based on a misreading of the
section.  Other points in Section 7 also first relate the issue raised,
followed by our response regarding how it can be addressed.

thanks.
-- Anees

On Thu, Sep 10, 2015 at 1:40 AM, Benoit Claise <[email-masked]> wrote:

> <http://www.ietf.org/iesg/directorate/yang-model-coordination-group.html>
> has spent some time reading and gathering input on the requirements and
> collect some observations that will hopefully contribute to progress in the
> working group.
>
> We believe it is useful to consider that YANG was initially designed to be
> a data modeling language for the NETCONF protocol. IETF is also working on
> RESTCONF which is an HTTP-based protocol to access data defined in YANG,
> using the datastores defined in NETCONF.
>
> gained some significant traction in this capacity. There are some changes
> worked on in YANG 1.1, but they are mostly incremental.
>
> There is interest in using other protocols outside of NETCONF and RESTCONF
> to manipulate data described by YANG. The proposals in the draft is based
> on the assertion that YANG models should be usable for protocols beyond
> RESTCONF and NETCONF. So these are new requirements on YANG from, or in
> preparation for, new protocol bindings.
>
> FIRSTLY: The proposed split between intended and applied configuration as
> described in sections 4.1 (requirements) and 5.1 (implications)
>
> would apply independent of if the system is synchronous or asynchronous in
> nature. Synchronous systems would simply hard-wire the applied
> Please note that this was not an exhaustive collection of data, but should
> give some directional information.
>
> optional capability) we risk introducing a fake perception that the current
> NETCONF server supports a capability it can't support. Indeed, polling the
> applied configuration would always return the intended configuration.
>
> A *question* would be if it would be useful to consider a direction where
> we make an attempt to separate out requirements that are tied to specific
> protocols and solve them in the protocol semantics rather than in the
> language to the extent we can. Without knowing more about the intended
> protocol in the case of this draft, it is hard to make more progress.
>
>     "The proposal does not allow items that are not configured, configured
> but not present, or system configured."
>
> - Removable physical assets (line cards, mezzanine cards) in systems that
> allow pre-provisioning of configuration
> implication and make it a little more modular and optional in the language.
> We are aware of suggestions to use the extensibility of the language itself
> (e.g. in draft-kwatsen-netmod-opstate) to express relations across data
> sets. Understanding that this suggested approach does not normalize the
> paths according to the wish of the authors, but it can perhaps be a
> balanced approach that impacts the expressivity less.
>

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 11 Sep 2015 09:38:46 +0200 (CEST)

Sam Aldrin <[email-masked]> wrote:
> >> On Sep 10, 2015, at 12:43 PM, Carl Moberg (camoberg)
> >> <[email-masked] <mailto:[email-masked]>> wrote:
> >> 
> >> Now, think about configuration parameters that have applied
> >> configuration located in more than one place. Let’s say you change the
> >> IP address of an interface, it is likely that this configuration will
> >> be passed around as input to a handful of subsystems (e.g. the DHCP
> >> server, some routing daemons that may bind to specific IP
> >> addresses). Is the intended and applied in sync when a specific subset
> >> of those configurations are updated. What happens if there’s a partial
> >> failure?
> > 
> > This is a good example. Another example, and somebody on the call
> > today started to ask this but got cut off, relates to interfaces on
> > the device.
> > 
> > Interfaces already exist on a system. As such they have a
> > configuration (default values) that exists on them. They are enabled
> > when configuration gets applied on them. They will have applied
> > configuration but no intended configuration. Should this be reported?
> > 
> > Yet another example is of a BFD session that gets bootstrapped because
> > of a ping. There is no intended configuration, but the session exists
> > and a query of configuration in this case would return a valid BFD
> > session.
> > 
> > Could we get some clarification (with examples, preferably) on what
> > the expectation is from a openconfig opstate perspective?
> 
> Section 7 of draft-openconfig-netmod-opstate talks about
> that. Specifically, #3 talks about the interface question you raise..

I think it is important that we understand how this 'applied config'
is supposed to be populated on a device.

First it was said that it there is just one way they can be different;
time (on async systems).  After some discussion I think there are now
four ways:

  1.  Time (in async systems).

  2.  Hardware.  If something is in intended config but there is no hw
      present, it is not in applied.

  3.  System-controlled stuff.  If the system auto-creates an
      interface (for example), it will be in the applied config but
      not in intended.

  4.  "Template substitution"; the draft uses the example of an 'all'
      interface that exists in intended config but not in applied.

Then Lada brought up the example of ip addresses.  It was mentioned
on the call that for ip addresses there would be three lists; one for
intended, one for applied, and one in derived state, where the one in
derived state is what the box *really* uses.  So for example if it
gets an ip from dhcp, it will be in the derived state list, but not in
applied config.

Why is this ip-address list different from the interface list?  Why
was it enough with two lists for interfaces, but we need three for ip
addresses?

/martin

---

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

Hi Martin,

>        interface (for example), it will be in the applied config but

I don't agree with this one.
  - if a system auto-creates an interface with no config then it is 
/interfaces-state, but not in /interfaces.
  - if a system auto-creates an interface and only then applies default 
config, the default config would go in intended and applied.
  - interfaces with pre-config that could be put into intended, but be 
left out of applied (because the hw isn't present).

So in summary, I would say that config is in applied and not intended 
only if the config is in the process of being deleted (or the delete 
operational failed for some reason).

>        interface that exists in intended config but not in applied.
I don't agree with this one either.  I don't think that cfg intended vs 
applied can or should be used as templating mechanism.

But I think that there is another case, which is for config that was 
accepted into the system (i.e. semantically valid) and then failed when 
being applied.  E.g. due to a system, or internal error.  There is also 
a possible failure due to out of resource (which could be counted as the 
same as case 2).

For a sync system, config failures can be returned as part of the 
edit-config request.  What is the equivalent mechanism for an async system?

> was it enough with two lists for interfaces, but we need three for ip
I don't see that they are different.  I think that you have 3 
lists/leaves in both cases:

I.e. I would say that 3 IP addr leaves are required in an async system, 
at a given time t:
  - only the intended leaf can indicate what IP addr config the operator 
wants on the interface (if any).
  - only the applied leaf can indicate what IP addr is actually being 
used as the configured value on the interface.
  - only the derived leaf can indicate what IP addr is actually 
operationally being used for the interface (which might be due to IP 
addr config, DHCP, or perhaps some other mechanism).

I think that in the both kwatsen-netmod-opstate and 
wilton-netmod-opstate there are logically 3 interface lists as well:
  - /if:interfaces is logically split into 2, either through being 
present in separate running and applied datastores, or through having 
separate cfg-intended/cfg-applied leaves.
  - /if:interfaces-state, which I perceive as logically the derived 
state for an interface.

Cheers,
Rob

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 11 Sep 2015 12:07:40 +0200

> gets an ip from dhcp, it will be in the derived state list, but not in

Right. After yesterday's interim I am much less in favour of this
intended/applied proposal because

- as you say, applied configuration falls short of representing "the
  state that the network element is actually in",

- states in which intended and applied configuration can be out of sync
  are only transient. In the use cases I am interested in, such states
  could be relatively normal and last long.

Another example that comes to my mind are static routes: an operator
needs to know that a configured static route got installed, and this can
be verified only by inspecting a corresponding RIB (operational
state). I don't see how a copy of static routes in applied configuration
could help.

I agree with Juergen that what we need is a clever representation of
operational state and this is hard work that needs to be done by experts
on an ad hoc basis. That's why I am also sceptical about the possibility
of having fixed and universally applicable relationships between
configuration and operational state.

Lada

---

From: Dean Bogdanovic <[email-masked]>
Date: Fri, 11 Sep 2015 12:27:36 +0200

> On Sep 11, 2015, at 12:07 PM, Ladislav Lhotka <[email-masked]> wrote:
> 

This is very true! As the networking is done today by vendors, achieving universally applicable relation between config and operational state is very hard. Openconfig folks want to get a single tree with of variables and it is lot of work for existing vendors to translate between customer desires and current vendor implementations, having separate operational and config models.

We should ask ourselves are we ready to work on an object oriented networking model with getter and setter functions and if vendors are ready to support such model.

Dean

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 11 Sep 2015 12:35:12 +0200 (CEST)

Robert Wilton <[email-masked]> wrote:
>  - /interfaces-state, but not in /interfaces.

Yes this is how ietf-interfaces work.  But the openconfig people want
to change this, and introduce 'applied config' as a simplicifation. I
am / we are trying to understand how they intend this 'applied config'
to work.

>  - config, the default config would go in intended and applied.
>  - left out of applied (because the hw isn't present).
> 
> I don't agree with this one either.  I don't think that cfg intended
> vs applied can or should be used as templating mechanism.

See above; the four bullets are (my understanding of) what the
openconfig people have said.  I hope they clarify if this is not what
they meant.

/martin

> accepted into the system (i.e. semantically valid) and then failed
> when being applied.  E.g. due to a system, or internal error.  There
> is also a possible failure due to out of resource (which could be
> counted as the same as case 2).
> 
> I.e. I would say that 3 IP addr leaves are required in an async
> system, at a given time t:
>  - wants on the interface (if any).
>  - only the applied leaf can indicate what IP addr is actually being used
>  - as the configured value on the interface.
>  - operationally being used for the interface (which might be due to IP
>  - addr config, DHCP, or perhaps some other mechanism).
> 
>  - /if:interfaces is logically split into 2, either through being present
>  - in separate running and applied datastores, or through having separate
>  - cfg-intended/cfg-applied leaves.
>  - /if:interfaces-state, which I perceive as logically the derived state
>  - for an interface.
> 
> Cheers,
> Rob
> 
> 
> >
> >
> > /martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 11 Sep 2015 09:42:34 -0700

> time (on async systems).  After some discussion I think there are now

IMO it would help to think just a bit about the operational aspects
of these issues.

There are at least 2 outcomes I can think of:

  Outcome 1) Convergence:
  Intended config eventually matches Applied

  Outcome 2) Non-convergence:
  Intended config is not going to become Applied

A system needs to decide if/when outcome 2 has occurred.
When is a fault raised because convergence is not happening?
There are probably other uses for all this extra meta-data.

So how do these 4 types of differences relate to these outcomes?

Obviously the main use-case.
Nothing in any solution proposal helps the client  decide Outcome 2 has
occurred.
That is out of scope I guess.

For most systems, this time delta will be too short to worry about ( < 5
sec.)
A good solution would not impact this vast majority of servers.

>       present, it is not in applied.

This is usually handled with a notification that the line-card was plugged
in, which
causes the NMS to re-check the config.  The solution proposal assumes the
server
can identify all the resources or other reasons that some specific leaf is
not applied yet.
This seems very complicated to implement in the server.

>       interface (for example), it will be in the applied config but

There is no convergence here because this is a case where applied has more
than intended,
not the other way around.

>       interface that exists in intended config but not in applied.
There is no convergence here because the template is not supposed to show
up in Applied.
However it is worth noting than none of the proposals solve this problem.
The Intended and Applied will never match.  The NMS must understand
how the specific template works to know what actual instances are expected
in Applied.

> was it enough with two lists for interfaces, but we need three for ip

Andy

---

From: Mahesh Jethanandani <[email-masked]>
Date: Fri, 11 Sep 2015 14:52:11 -0700

And while we mull over the questions Andy has raised, I want to go back and dwell on what Rob said about why he wanted a way to determine when the configuration has taken effect. I might be simplifying the problem a little too much, but I am sure Rob will correct me. The ask as I understand is, give me a way to deterministically know when a given piece of configuration has taken effect.

As an exercise I wanted to mentally go through trying to configure an interface to determine if the configuration has taken effect. Very simply, I want to assign an IP address to an interface. If I now want to know if this configuration has taken effect, I can check for the IP address of the interface. Querying the IP address on an interface does not tell me if it has taken effect. Yes, it has been written to a register, but what does that tell me? Nothing. My only deterministic way of knowing that the IP address has taken effect is if I can see traffic transmitted/received with that IP address on that interface.

To me that is the crux of the problem with simply reflecting operational status with a flag that gets updated when the configuration gets written. In most cases, the configuration will just work and the flag will tell me nothing new. But when it does not, having written to a flag will also tell me nothing, other than the fact that the configuration was written.

I contend that the real ask with this example is to determine if I can pass IP traffic, and to determine that, we need more than a “intended vs actual” flag.

> On Sep 11, 2015, at 9:42 AM, Andy Bierman <[email-masked]> wrote:
> 
> 
> 
> On Fri, Sep 11, 2015 at 12:38 AM, Martin Bjorklund <[email-masked] <mailto:[email-masked]>> wrote:
> Sam Aldrin <[email-masked] <mailto:[email-masked]>> wrote:
> >
> > > On Sep 10, 2015, at 4:13 PM, Mahesh Jethanandani
> > > <[email-masked] <mailto:[email-masked]>> wrote:
> > >
> > >
> > >> <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
> > >>
> Nothing in any solution proposal helps the client  decide Outcome 2 has occurred.
> For most systems, this time delta will be too short to worry about ( < 5 sec.)
> This is usually handled with a notification that the line-card was plugged in, which
> causes the NMS to re-check the config.  The solution proposal assumes the server
> can identify all the resources or other reasons that some specific leaf is not applied yet.
> There is no convergence here because this is a case where applied has more than intended,
> There is no convergence here because the template is not supposed to show up in Applied.
> how the specific template works to know what actual instances are expected in Applied.
> 
>  
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>
Mahesh Jethanandani
[email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Fri, 11 Sep 2015 20:48:55 -0700

Hi Mahesh,

The answer (today) is that some operator knows the show commands
to type, and then knows from the screen full of data that certain config
commands
are active.

It's not hard to imagine that how an API to do this without any magic would
be useful.
(Hence the openconfig requirement...)

As Carl pointed out in the interim, current systems do not provide this
level of automation.
All this is new code, and perhaps there are complicated corner-cases to be
found.

All solutions expect the server to be able to determine applied status for
every leaf
in the intended config. All solutions require basically the same internal
API support
to check the relevant applied config or operational state.

In every solution, the server will magically know how to check that the IP
address is active.
That's the point. It is better than forcing the client to know how to do
this for every type of server.

IMO, this requirement is clear, and each draft has a solution approach for
this new API.

Andy

On Fri, Sep 11, 2015 at 2:52 PM, Mahesh Jethanandani <
[email-masked]> wrote:

> And while we mull over the questions Andy has raised, I want to go back
> and dwell on what Rob said about why he wanted a way to determine when the
> configuration has taken effect. I might be simplifying the problem a little
> too much, but I am sure Rob will correct me. The ask as I understand
> is, give me a way to deterministically know when a given piece of
> configuration has taken effect.
>
> As an exercise I wanted to mentally go through trying to configure an
> interface to determine if the configuration has taken effect. Very simply,
> I want to assign an IP address to an interface. If I now want to know if
> this configuration has taken effect, I can check for the IP address of the
> interface. Querying the IP address on an interface does not tell me if it
> has taken effect. Yes, it has been written to a register, but what does
> that tell me? Nothing. My only deterministic way of knowing that the IP
> address has taken effect is if I can see traffic transmitted/received with
> that IP address on that interface.
>
> To me that is the crux of the problem with simply reflecting operational
> status with a flag that gets updated when the configuration gets written.
> In most cases, the configuration will just work and the flag will tell me
> nothing new. But when it does not, having written to a flag will also tell
> me nothing, other than the fact that the configuration was written.
>
> I contend that the real ask with this example is to determine if I can
> pass IP traffic, and to determine that, we need more than a “intended vs
> actual” flag.
>
>> > > <[email-masked]> wrote:
>> > >
>> > >

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 14 Sep 2015 10:10:42 +0200

>  - /if:interfaces-state, which I perceive as logically the derived 

My personal requirement would be to be able to find all IP addresses
of an interface that are operationally used in one place.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 14 Sep 2015 10:21:55 +0200 (CEST)

> of an interface that are operationally used in one place.

Yes.  I am trying to understand if a separate list of operationally
used addresses is needed even if we have the "applied config".  I
think the answer is yes.  Then the question is if we don't need a
separate list of operationally used interfaces as well.  If we do,
what value does the "applied config" idea bring us?

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 14 Sep 2015 10:27:45 +0200

> IMO, this requirement is clear, and each draft has a solution approach for

For resources residing somewhere in an OS kernel (e.g. IP addresses of
an interface), a proper implementation would require that the kernel
knows why the resource is there and not just the fact that the
resource is there. If I take an average resource in the Linux kernel,
then this information is not kept in the kernel. Daemons and user
space application simply create and modify resources in the kernel and
then the kernel does what it does. So how would I implement an applied
datastore on such a kernel? One obvious option would be that I simply
grab the operational state and I match it against the intended config
and everything that matches I report as applied config. Of course,
this may go wrong in certain cases if there are clashes or the mapping
is not trivial 1:1. But unless the piece of code that manages the
underlying resource has a way to maintain and manage meta information,
this is probably the best an implementation will be able to do. Or am
I missing something?

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 14 Sep 2015 10:31:09 +0200

> On 14 Sep 2015, at 10:21, Martin Bjorklund <[email-masked]> wrote:
> 

In my view, it provides just information that intended configuration was taken into account in an asynchronous system but, despite the definition, it may not always provide the parameter values that are operationally used. If this is true, then IMO the use case for applied configuration is too narrow and doesn’t warrant making applied configuration a general requirement.

Lada

---

From: Robert Wilton <[email-masked]>
Date: Mon, 14 Sep 2015 11:24:52 +0100

Hi,

On 14/09/2015 09:31, Ladislav Lhotka wrote:
>> separate list of operationally used interfaces as well.
I may be off the mark, but I don't think that the Open Config 
requirements are saying that they don't want/need a separate list of 
operationally used interfaces, but more that they want the config and 
operational data for an interface to be under the same per interface 
container, so (i) that you can easily get all the data for an interface 
in a single request, or (ii) easily get the config and operational data 
for a particular feature on a interface without having to request the 
interface data from two separate lists.

So, one hypothetical solution (which YANG doesn't currently allow) might 
be to have a single list of all interfaces, each with two leaves to 
indicate whether those interfaces are configured and/or operational.

>>    If we do,
> In my view, it provides just information that intended configuration was taken into account in an asynchronous system but, despite the definition, it may not always provide the parameter values that are operationally used.
Yes, this is also my thinking for the applied config.  In fact I think 
that it is analogous to the config states in a synchronous NETCONF 
commit.  I.e. the cfg-applied status doesn't give you any more 
information than a <get-config> request would against a server after a 
sync config change had been committed.

Ignoring errors, all the intended cfg vs applied cfg really provides is 
the ability for a client to determine how far through an async config 
commit a server has reached.  It is instead of the server blocking the 
commit request until the request has completed.  This equivalence is 
also one of the reasons why I don't think that applied cfg should be 
used for templating.

Specifically, I don't think that the cfg-applied state has to guarantee 
that a particular config change has been programmed everywhere any more 
than a synchronous commit has to make that same guarantee.  I.e. at the 
point in time that a server is happy to reply indicating a sync config 
request has completed should be sufficient to update the cfg-applied 
leaf in an equivalent async commit.

>   If this is true, then IMO the use case for applied configuration is too narrow and doesn’t warrant making applied configuration a general requirement.
I just see it as a way to support clients that want to process 
configuration in an asynchronous fashion, or for servers that want to 
adopt an eventual consistency configuration model.

Thanks,
Rob

---

From: Robert Wilton <[email-masked]>
Date: Mon, 14 Sep 2015 12:03:39 +0100

Hi Andy,

On 11/09/2015 17:42, Andy Bierman wrote:
>     > >> <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     > >>

I think that this same issue exists for a servers handling a sync config 
commit as well.  Presumably these would also block forever or require 
some timeout to determine (2)?

> how the specific template works to know what actual instances are 

Yes, and this is why I am suggest that templating shouldn't be part of 
applied cfg.  It looks like templating only turns up in section 7 of 
openconfig-netmod-opstate-01 rather than being listed in section 4 on 
requirements.

If support for generic YANG templating is required, then I would suggest 
that should be considered separately from the current opstate draft.

Thanks,
Rob

---

From: Benoit Claise <[email-masked]>
Date: Mon, 14 Sep 2015 15:04:57 +0200

Rob,
> The applied configuration is the value of those configuration elements a daemon/software component/programmable memory is actually running, which can be compared to the intent. Essentially, this is…
You're right. Good clarification.

Regards, Benoit
> .

---

From: Andy Bierman <[email-masked]>
Date: Mon, 14 Sep 2015 07:18:05 -0700

Hi,

This raises the issue "how does the client know that a missing applied
value means
there is no applied value vs. the server does not know and does not support
reporting
the applied value for a particular leaf?"

None of the solutions allow a client to know that. The RPC-based solutions
can be fixed, but not the replicated config retrieved with <get>.

Andy

---

From: Kent Watsen <[email-masked]>
Date: Mon, 14 Sep 2015 19:12:59 +0000

[As a contributor]

> value means there is no applied value vs. the server does not know
>  and does not support reporting the applied value for a particular leaf?"
>
> None of the solutions allow a client to know that.

draft-kwatsen-netmod-opstate-reqs Sections 5.2 and 6.1. define an
Applied Configuration capability so the client to tell, doesn't this count?

> Andy

Kent

---

From: Kent Watsen <[email-masked]>
Date: Mon, 14 Sep 2015 19:18:00 +0000

GitHub issue #4 has been raised to track the predominant concern raised in this thread:

https://github.com/netmod-wg/opstate-reqs/issues/4

Thanks again Rob!

Kent

From: Kent Watsen <[email-masked]<mailto:[email-masked]>>
Date: Monday, September 14, 2015 at 3:12 PM
To: Andy Bierman <[email-masked]<mailto:[email-masked]>>, Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>>, Mahesh Jethanandani <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netmod] YANG coordination feedback on draft-openconfig-netmod-opstate-01

[As a contributor]

Kent

---

From: Andy Bierman <[email-masked]>
Date: Mon, 14 Sep 2015 12:39:19 -0700

> Applied Configuration capability so the client to tell, doesn't this count?

This is a global flag.
All solutions ignore the possibility that the server is capable of
detecting the
current corresponding active value for a subset of all data nodes.

I think the wilton draft is easiest to fix.
It avoids the problem of "what does a missing applied node mean?"
For each indented config node, attributes can be returned to indicate:

    - status known? yes/no
    - unknown status temporary?  yes/no

The attribute return values can be quite deterministic with this extra info.

Andy