Subject: [netmod] follow-up from virtual interim and i2rs discussions

From: Kent Watsen <[email-masked]>
Date: Tue, 23 Jun 2015 00:17:15 +0000

[As an individual contributor]

Attached are some slides that I put together, with feedback from Andy and Martin, that attempt to capture a high-level model we can all agree on.  Comments, questions, concerns?

Kent

---

From: Phil Shafer <[email-masked]>
Date: Tue, 23 Jun 2015 01:14:40 -0400

Kent Watsen writes:
>Attached are some slides that I put together, with feedback from Andy and M=
>artin, that attempt to capture a high-level model we can all agree on.  Com=
>ments, questions, concerns?

Slide 3 calls negotiated values (e.g. duplex) "actualized config",
which is imho wrong.  Calling transient learned values "config"
makes the meaning of "config" useless.  Are bgp learned routes to
be considered config?

Perhaps that's the bit that's missing, a delineation between
learned values and config values.

Part of the question whether ephermal config is really config, or
just learned values trafficed in terms that mirror config.

But then slide 4 seems to distinquish between "protocol negotiated
values" and "protocol learned values".  What's the difference?

There are other state and state-like values, such as connection
tables, route tables, and MAC address tables, that aren't completely
config (but you can configure the port on which a listen is posted)
nor completely state (since you can have static mac entries and
static or interface-based routes).

And let's not miss the chance to discuss default values, a perennial
favorite ;^)

If I were picked terms, I think I'd go something like:

  base config + ephemeral data + defaults => intended state
  intended state + learned values => actual state
  actual state + counters => operational state

where:

base config == config suitable for startup (persistant, drives initial intended state)
defaults == both data model defined default values and system defaults
ephemeral data == learned values trafficed in terms that mirror config
learned values == data acquired by interaction with the real world
counters == well, you know.....

Thanks,
 Phil

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 23 Jun 2015 12:57:47 +0200

On Tue, Jun 23, 2015 at 12:17:15AM +0000, Kent Watsen wrote:
> Attached are some slides that I put together, with feedback from
> Andy and Martin, that attempt to capture a high-level model we can
> all agree on.  Comments, questions, concerns?

I am lost on slide #3. Operational state reflects what the device
actually does, I am not sure what 'actualized config' really is.

I am also lost on slide #3 and #4 concerning what protocol discovered
values (slide #4) are and when they differ from the middle box on
slide #3. The difference between counters and statistics is unclear as
well. RFC 3535 only distinguished config, operational state, statistics.

Why is it hard to provide generic access to counters? Processing the
data model easily gives you the query to retrieve all counters (but I
am not sure this is operationally a good thing to do anyway; is
blindly polling counters really how networks are managed?).

What is important I think is that data has different life times. You
can have config that is provisioned for interfaces not yet present,
you can have an interface operationally active that is not configured.
The model in RFC 7223 supports both. Can someone explain using
concrete examples what the RFC 7223 model is not supporting well or
are we searching for terms to describe what the RFC 7223 model all got
right?

/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: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 23 Jun 2015 13:06:06 +0200

On Tue, Jun 23, 2015 at 01:14:40AM -0400, Phil Shafer wrote:

[...]

>   base config + ephemeral data + defaults => intended state

I like intended state way more than intended config. I would change
the other two slightly:

  provisioned config + ephemeral config => intended state

>   intended state + learned values => actual state

In reality it is more like this:

  intended state + learned values + device properties => actual state

In other words, even if you know the intended state and the learned
values, you most likely won't be able to predict the actual state
precisely without knowing device specific properties. But we likely
ignore that nasty part of reality...

>   actual state + counters => operational state

This should be:

  actual state + statistics => operational state

Statistics is largely dominated by counters but not only counters.

/js

---

From: Phil Shafer <[email-masked]>
Date: Tue, 23 Jun 2015 09:37:26 -0400

>  provisioned config + ephemeral config => intended state

I dislike called using "ephemeral" with "config".  We did this in
JUNOS and it was confusing.  It's not really config.  If we used
BGP to tunnel stanzas of XML that looked followed the conventions
of bgp.yang, would it be config?  If so, what does "config" mean
as a term?

"ephemeral data" makes it plain that we don't consider this config.

>  intended state + learned values + device properties => actual state

Yup, completely agree.

>ignore that nasty part of reality...

Yup, and reality can change when you swap FRUs.

>Statistics is largely dominated by counters but not only counters.

Sound good.

Precise language is so important, so I think well-defined terms
matter.  Then again, one can be completely precise while being
completely useless, like my current favorite word, sphygmomanometer.

Thanks,
 Phil

---

From: heasley <[email-masked]>
Date: Tue, 23 Jun 2015 17:09:12 +0000

> Date: Tue, 23 Jun 2015 12:57:47 +0200
> From: Juergen Schoenwaelder <[email-masked]>
> 

FWIW, we do this often - collect every entry in a particular mib table,
and discard what is uninteresting to us, because it is usually much
faster than individual OIDs.  I expect the same to be true collecting
statistics via netconf/restconf.

> Date: Tue, 23 Jun 2015 09:37:26 -0400
> From: Phil Shafer <[email-masked]>
> 

yes, please.  Great to see this dialog.

> completely useless, like my current favorite word, sphygmomanometer.

or northbound/southbound.

---

From: Andy Bierman <[email-masked]>
Date: Tue, 23 Jun 2015 10:50:59 -0700

> "ephemeral data" makes it plain that we don't consider this config.
But it is config.

There is absolutely nothing "learned" about I2RS data.
The client connects to the server and the client is authenticated.
The authorized client requests to change ephemeral configuration
are attempted by the server. Just like configuration.

Negotiated data is something the server has a mechanism to alter the
outcome.

Discovered data is something the server has no mechanism to
alter the outcome.

Whether the non-configuration is learned from the local system
or learned from a protocol message from another system seems
rather unimportant.

> completely useless, like my current favorite word, sphygmomanometer.
IMO getting the concepts right needs to be done first.
Picking the right terms helps if the concepts are right in the first place.

The thermometer example I have given many times needs to be understood.

Let's say the same leaf "temperature" is used in all datastores.
The "running" temperature is the configured desired value.
The "operational" temperature is the current value read from a sensor.

So where does "ephemeral" temperature fit in?  Does this setting override
the desired temperature and have no affect on the operational sensor value?
Or does it over-write the sensor value to the device is now lying
when it reports the operational temperature?

IMO it is quite obvious that ephemeral data is configuration, not state.
Operational state is always read-only.

Thanks,
>  Phil

Andy

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

---

From: Kent Watsen <[email-masked]>
Date: Tue, 23 Jun 2015 19:57:18 +0000

Hi Phil,

>values" and "protocol learned values".  What's the difference?

Slides 3 & 4 were meant to be two parts of a single concept - the attached
picture better conveys what was intended.   Does it help?

> completely useless, like my current favorite word, sphygmomanometer.

Agreed - this exercise started because the OpenConfig presentation used
some terminology that caused some confusion.    We also needed a
conceptual model that incorporated the ephemeral concepts from the I2RS
discussions.

Kent  [as an individual contributor]

---

From: Dean Bogdanovic <[email-masked]>
Date: Tue, 23 Jun 2015 21:15:58 +0000

On Jun 23, 2015, at 1:50 PM, Andy Bierman <[email-masked]<mailto:[email-masked]>> wrote:

Sound good.

Andy,

ephemeral "temperature" would overwrite which ever data store was read to set "running" temperature. If the "temperature" was read from "startup" config, then ephemeral would mask the "temperature" leaf in the startup and running would read from ephemeral data store.
One of the issues I personally ran into while at Juniper was people perception that configuration is persistent. Ephemeral config was very confusing to Juniper customers, as I was trying to explain them, that if they change the ephemeral and device reboots, the configuration is gone. For many of them, it was running config, but it is not. Another issue was no rollback. Actually, there is only rollback 0, which is done automatically by the system, if the config commit is not successful.

I would not say that ephemeral data is config. It is temporary state developers want to change the device state too.

Thx

Dean

Thanks,
 Phil

Andy

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

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

---

From: Andy Bierman <[email-masked]>
Date: Tue, 23 Jun 2015 14:35:31 -0700

Hi,

I don't think the terminology is converging.

There is really only "intended state" and "operational state".
There is ephemeral intended state and persistent intended state.

The fact that a configured intended value came from the startup
or from I2RS or from CLI does not really matter.  The fact that
an I2RS value does not come back after a reboot does not
really matter.

Intended state means the server is asked to change the behavior
of the device, which needs to understand and activate the intentions of
the client.

Operational state means the actual state of the device.
It is the result of the device processing intended state and
participating in protocols that affect device behavior.

Andy

On Tue, Jun 23, 2015 at 2:15 PM, Dean Bogdanovic <[email-masked]> wrote:

>
>  On Jun 23, 2015, at 1:50 PM, Andy Bierman <[email-masked]> wrote:
>
>
>
>
>>
>  ephemeral "temperature" would overwrite which ever data store was read
> to set "running" temperature. If the "temperature" was read from "startup"
> config, then ephemeral would mask the "temperature" leaf in the startup and
> running would read from ephemeral data store.
> One of the issues I personally ran into while at Juniper was people
> perception that configuration is persistent. Ephemeral config was very
> confusing to Juniper customers, as I was trying to explain them, that if
> they change the ephemeral and device reboots, the configuration is gone.
> For many of them, it was running config, but it is not. Another issue was
> no rollback. Actually, there is only rollback 0, which is done
> automatically by the system, if the config commit is not successful.
>
>
>
>  I would not say that ephemeral data is config. It is temporary state
> developers want to change the device state too.
>
>  Thx
>
>  Dean
>

---

From: Andy Bierman <[email-masked]>
Date: Tue, 23 Jun 2015 14:57:28 -0700

> developers want to change the device state too.

Here is a simple example.
I hope it is not too abstract.

   leaf admin-temp {
      type uint32;
       units "degrees Celsius";
      description "The configured temperature.";
  }

   leaf oper-temp {
       type uint32;
       units "degrees Celsius";
       config false;
       description "The measured temperature.";
  }

Would your I2RS solution be able to over-ride the admin-temp
with a temporary ephemeral value?  Describe the solution
in detail.  Provide all YANG and all protocol operations that
would be used

Andy

---

From: Nadeau Thomas <[email-masked]>
Date: Tue, 23 Jun 2015 18:05:08 -0400

> On Jun 23, 2015:5:57 PM, at 5:57 PM, Andy Bierman <[email-masked]> wrote:
> 
> 
> 
> On Tue, Jun 23, 2015 at 2:15 PM, Dean Bogdanovic <[email-masked] <mailto:[email-masked]>> wrote:
> 
> On Jun 23, 2015, at 1:50 PM, Andy Bierman <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> 
>> 
>> 
>> 

	Keep in mind that that temporary state could easily be flipped to persistent simply by synching that temporal store “later".  This was one of the original concepts of i2rs.

	—Tom

>> [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>
> 
>

---

From: Dean Bogdanovic <[email-masked]>
Date: Tue, 23 Jun 2015 22:17:24 +0000

On Jun 23, 2015, at 5:57 PM, Andy Bierman <[email-masked]<mailto:[email-masked]>> wrote:

On Tue, Jun 23, 2015 at 2:15 PM, Dean Bogdanovic <[email-masked]<mailto:[email-masked]>> wrote:

Sound good.

Andy,

No, it is not

   leaf admin-temp {
      type uint32;
       units "degrees Celsius";

>From YANG perspective, it would be exactly the same, in persistent config and ephemeral data store

the only difference is in NETCONF RPC

for persistent config
<edit-configuration>

and for ephemeral
<edit-ephemeral-instance>

As there can be multiple ephemeral instances.

   leaf oper-temp {
       type uint32;
       units "degrees Celsius";
       config false;

Would your I2RS solution be able to over-ride the admin-temp
with a temporary ephemeral value?

 When commit is executed in ephemeral instance, merge between persistent and ephemeral is being executed, with priority for values coming from ephemeral data store.

Makes sense?

Describe the solution
in detail.  Provide all YANG and all protocol operations that would be used

Thx

Dean

Andy

Thanks,
 Phil

Andy

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 23 Jun 2015 18:23:52 -0400

Actually, the I2RS agreement was that "commit" can never be run on the 
I2RS data.  It is not to be persisted.

The reason this is important is that client 1 and client 2 may have made 
ephemeral changes to the device.  if client 1 did "commit", it would 
cause client 2's data to become permanent, when that was not his itnent.

Instead, if client 1 wants his changes to be persistend, he can make the 
directly to running, using NetConf (or, I suppose, RestConf) and then 
commit that.

Yours,
Joel

On 6/23/15 6:17 PM, Dean Bogdanovic wrote:
>>     ephemeral "temperature" would overwrite which ever data store was
>>     read to set "running" temperature. If the "temperature" was read
>>     from "startup" config, then ephemeral would mask the "temperature"
>>     leaf in the startup and running would read from ephemeral data store.
>>     One of the issues I personally ran into while at Juniper was
>>     people perception that configuration is persistent. Ephemeral
>>     config was very confusing to Juniper customers, as I was trying to
>>     explain them, that if they change the ephemeral and device
>>     reboots, the configuration is gone. For many of them, it was
>>     running config, but it is not. Another issue was no rollback.
>>     Actually, there is only rollback 0, which is done automatically by
>>     the system, if the config commit is not successful.
>>
>>
>>>
>>     I would not say that ephemeral data is config. It is temporary
>>     state developers want to change the device state too.
>>
>>
>>
>   When commit is executed in ephemeral instance, merge between
> persistent and ephemeral is being executed, with priority for values
> coming from ephemeral data store.
>
> Makes sense?
>
>> Describe the solution

---

From: Kent Watsen <[email-masked]>
Date: Tue, 23 Jun 2015 23:11:36 +0000

I think terminology is mostly converging, with the primary hangup being if ephemeral/intended are "configuration" or "state".    I'm personally in favor of calling both "configuration", as they would still contain values like "auto", that require actualization to obtain an operational state value...so I think, if it's not state, it must be config, right?  Adding to this, we have a general understanding that anything that can be configured persistently can also (in theory) be configured ephemerally – so it behaves like config in this way too...

More importantly though, I believe that we're converging on a conceptual model and have  general agreement that "running + ephemeral = intended" and "intended + <actualization> = operational state".  This seems obvious in hindsight, but it wasn't until the OpenConfig folks brought the "intended" term that we wrote it down.

I hope we can converge on the terminology and conceptual model in the near term, and then use this new foundation for articulating I2RS and OpenConfig solutions.

Kent

From: Andy Bierman <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, June 23, 2015 at 5:35 PM
To: Dean Bogdanovic <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netmod] follow-up from virtual interim and i2rs discussions

Hi,

Andy

Sound good.

Andy,

Thx

Dean

Thanks,
 Phil

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 23 Jun 2015 16:17:18 -0700

Hi,

You are not describing the procedure very precisely, even for Junos,
let alone a standard.  You are vaguely describing different
datastores, except the I2RS datastore does not support multiple
layers.  If client A data gets deleted because of higher priority
client B, then that client A data does not come back automatically
if client B data is deleted. (So there cannot be multiple ephemeral
instances in the I2RS standard).

If the 1 'admin-temp' config=true leaf is
used for both configuration and ephemeral,
and the only difference is what operation is used to edit the data,
then the server has to keep track of each.  The retrieval operations
have to keep each type of data separate.  Whether that
is a tag or a datastore, the implementation is basically the same.

The difference is that YANG has specific validation rules about
what is in the running datastore.  This cannot change in NETCONF.
Unless YANG validation is ignored by I2RS, new text will be needed
to say how this is handled.  Is there any concept of datastore validation
in I2RS?
Any YANG validation procedures specified at all?

Unless I2RS can explain why the NETCONF architecture and its
use of datastores is inappropriate, I see no reason to change it.

Andy

On Tue, Jun 23, 2015 at 3:17 PM, Dean Bogdanovic <[email-masked]> wrote:

>
>  On Jun 23, 2015, at 5:57 PM, Andy Bierman <[email-masked]> wrote:
>
>
>
>   When commit is executed in ephemeral instance, merge between persistent
> and ephemeral is being executed, with priority for values coming from
> ephemeral data store.
>
>  Makes sense?
>
>
>   Describe the solution

---

From: Kent Watsen <[email-masked]>
Date: Wed, 24 Jun 2015 00:50:14 +0000

>blindly polling counters really how networks are managed?).

Processing the data model syntactically is easy.  Processing it
semantically is when it becomes hard.  For instance, how does a client
know what "in-unicast-pkts" is suppose to mean?

> Can someone explain using

Based on what the openconfig folks called out:

1. Operational state is not a complete superset of the configured state.
Though I'm sympathetic to the idea that some config values would never be
represented in operational:
https://tools.ietf.org/html/draft-bjorklund-netmod-operational-00#section-4
.1.

2. Operational state is split out at the top-level, not sprinkled within
each interface.  

3. Data-model duplication.  The opstate nodes that are same as config
nodes are defined separately.

4. No protocol to just retrieve opstate without retrieving config.  OK,
this isn't true since subtree-filter could easily select the
"interfaces-state" subtree...

Kent

---

From: Phil Shafer <[email-masked]>
Date: Tue, 23 Jun 2015 21:09:16 -0400

>an I2RS value does not come back after a reboot does not

No, I think the nature of the data is more important than the source,
but if I have RIP handing me a default route every 30 seconds that
I will discard on reboot, and a custom app handing me a default
route every 30 seconds that I will discard on reboot, what makes
one "config" and the other not?  What makes "config" "config"?

Normally I'd say "persistence", but distinct-startup makes that,
well, odd.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Tue, 23 Jun 2015 18:50:39 -0700

> Normally I'd say "persistence", but distinct-startup makes that,

Persistence is an operator choice, according to the outcome
of the NETMOD interim meeting in NYC.

IMO config is the set of instructions from the administrator to
the device, describing the intended device behavior.
The administrator decision to enable RIP is config.

Ephemeral config could be no different than protocol-learned
values.  One could consider I2RS an unspecified, open-ended
routing protocol. Debugging broken I2RS deployments should
be great fun.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Tue, 23 Jun 2015 22:10:39 -0400

>the device, describing the intended device behavior.

That's a reasonable definition.  "config" involves an administrator,
whether automated or carbon-based.

>The administrator decision to enable RIP is config.

Ditto for i2rs.

>routing protocol.

Yup, exactly.  I2RS is just a way to learn data.

>Debugging broken I2RS deployments should
>be great fun.

Yup, and having sufficient logging will be critical to survival for
developers.

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 24 Jun 2015 11:39:47 +0200 (CEST)

Kent Watsen <[email-masked]> wrote:
> I think terminology is mostly converging, with the primary hangup
> being if ephemeral/intended are "configuration" or "state".  I'm
> personally in favor of calling both "configuration", as they would
> still contain values like "auto", that require actualization to obtain
> an operational state value...so I think, if it's not state, it must be
> config, right?  Adding to this, we have a general understanding that
> anything that can be configured persistently can also (in theory) be
> configured ephemerally – so it behaves like config in this way too...
> 
> More importantly though, I believe that we're converging on a
> conceptual model and have general agreement that "running + ephemeral
> = intended" and "intended + <actualization> = operational state".
> This seems obvious in hindsight, but it wasn't until the OpenConfig
> folks brought the "intended" term that we wrote it down.

I don't think this covers what the open config people call "actual
config".   Suppose we have (ignoring ephemeral for simplicitly):

       running        operational state
       -------        -----------------
  t0    half              half
  t1    auto              half
  t4    auto              full

I.e., at time t1, we set duplex to auto.  After some time (t4) this is
reflected in the operational state.

In the open config model we'd have:

       running      actual config    operational state
       -------      -------------    -----------------
  t0    half            half             half
  t1    auto            half             half
  t2    auto            half (*)         half
  t3    auto            auto             half
  t4    auto            auto             auto

This illustrates that at time t2, the actual config is still half (*)
in an asynchrounous implementation.  At time t3, the actual config is
in sync with the intended config, and at time t4 the operational state
has been affected.

> I hope we can converge on the terminology and conceptual model in the
> near term, and then use this new foundation for articulating I2RS and
> OpenConfig solutions.

+1  This should be our focus.

/martin

---

From: Robert Wilton <[email-masked]>
Date: Wed, 24 Jun 2015 14:40:41 +0100

Hi Martin,

One quick clarification:

In your open config model example, should the operational state of the 
last line read 'full'?
I.e

   t4    auto            auto            *full*

Thanks,
Rob

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 24 Jun 2015 16:10:41 +0200 (CEST)

> In your open config model example, should the operational state of the

yes!

>        running      actual config    operational state

Here's the updated table:

  t4    auto            auto             full

/martin

---

From: Rob Shakir <[email-masked]>
Date: Wed, 24 Jun 2015 18:30:58 +0100

Hi Martin,

The table you have is consistent with the proposal that we laid out in the last interim. Now that we understand the problem, it’d be great to move on to solutions :)

Cheers,
r.

On 24 June 2015 at 10:39:53, Martin Bjorklund ([email-masked]) wrote:

/martin

---

From: Kent Watsen <[email-masked]>
Date: Wed, 24 Jun 2015 19:37:53 +0000

Hi Martin,

>       running      actual config    operational state

I don't understand how actual is ever not the same as operational.  At
least in my view, actual is just a subset of operational (the subset
defined by config=true nodes).  What am I missing?  Also, what does (*)
represent?

Thanks,
Kent

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 24 Jun 2015 22:10:30 +0200 (CEST)

Kent Watsen <[email-masked]> wrote:
> I don't understand how actual is ever not the same as operational.

If it was always the same it would not be needed.

See Rob's picture.  In that picture, the schema for "actual" is the
same as for "intended".

> At
> defined by config=true nodes).  What am I missing?

Well, I am still trying to understand what (if any) meaning this
"actual config" has.  But Rob was pretty clear in his last email:

  * We require the ability for an NMS to be able to see both the intended and
    the actual configuration

If I understand this correctly, "actual config" is only interesting in
an asynchronous implementation; in a synchronous implementation actual
will always be equal to intended.

> Also, what does (*)

The (*) was just to relate the text to the table.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 24 Jun 2015 13:37:07 -0700

> See Rob's picture.  In that picture, the schema for "actual" is the

The concept of datastores fits "operational" well because it represents
the module set and potentially same set of data node instances,
where all data node instances are considered to be in the same
network management state.

It is also extensible because leafs like the <source> and <target>
parameters in NETCONF can identify any datastore (or non-datastore,
like 'url') and new datastores can be easily added in YANG
(conditionally based on YANG features).

> will always be equal to intended.

Our server supports edit callbacks that are synchronous or asynchronous,
on a per-object registration basis.

It would be better if <get-operational> worked on all objects.
It is trivial to return the intended value if the server is sure it is
also the actual value.

Andy

---

From: Anees Shaikh <[email-masked]>
Date: Wed, 24 Jun 2015 13:43:13 -0700

Our understanding of the table is that it assumes you have an additional
state leaf to reflect the negotiated mode (i.e., operational state
negotiated by protocol) that would be reflected as the "operational" value.

Actual config was primarily motivated by asynchronous systems (as we
defined it in the mail Rob sent out) though there are a number of use
cases.  I think the meaning was clear , and Martin's table essentially
captures it.

thanks.
-- Anees

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 24 Jun 2015 22:55:47 +0200 (CEST)

> negotiated by protocol) that would be reflected as the "operational" value.

Yes, in this example that is correct.  If we agree on the meaning of
these terms, we can discuss solutions.  I think two solutions have
been proposed:

  1. The data modeller defines three leafs, one for the intended config, one
     for the actual config (MUST be the same syntax as the intended), and
     one for the operational state.  

  2. The data modeller defines two leafs, one for the config, and one
     for the operational state.  The config leaf is instantiated in
     two different data stores; "running" and "operational",
     reflecting the intended and actual config, respectively.
     (It might be instantiated in other data stores as well, such as
     candidate and startup, and maybe ephemeral).

> cases.  I think the meaning was clear

It's not completely clear; see my reply to Rob's email.

/martin

> and Martin's table essentially
> captures it.
> 
> thanks.
> -- Anees
>

---

From: Kent Watsen <[email-masked]>
Date: Wed, 24 Jun 2015 22:14:49 +0000

>If it was always the same it would not be needed.

Not a helpful answer.  Please look at the right side of this picture:
http://www.ietf.org/mail-archive/web/netmod/current/jpgm4Rk4R9iBf.jpg.
Again, it seems that actual is just the part of operational that has
schema defined by the config=true nodes...

>See Rob's picture.  In that picture, the schema for "actual" is the

Right, same as what I've been saying - where's the disconnect?

>will always be equal to intended.

Yes, I get it, but in my view there are only two columns of interest:

       running/intended      actual/operational
       ----------------      ------------------
  t0        half                    half
  t1        auto                    half
  t2        auto                    half
  t3        auto                    full

Your table allowed "actual" to contain the value "auto", but how is that
possible when we defined actual as being after:

  data-plane groks intended
    - e.g., Δ time

  conditional enablement
    - e.g., line card plugged in

  protocol negotiated values
    - e.g., auto --> full / half

???

Kent