Subject: [netmod] Follow up on the openconfig oper status and the NETMOD interim

From: Benoit Claise <[email-masked]>
Date: Tue, 23 Jun 2015 17:44:21 +0200

Dear all,

In order to clarify the situation, I compiled some points from my notes 
and created a couple of diagrams. This was initially created for my 
personal use, but if it helps with the discussion, please use it.

The first open issue is terminology IMO.
     - intended, applied
     - synchronous/asynchronous
There are two synchronous levels: the protocol (NETCONF) and network 
element implementation. As Kent mentioned: "Kent NETCONF is a 
synchronous protocol but state may change asynchronously."
It would beneficial for the authors to explain what happens in the 
following NETCONF server two cases:
- an example of (non-NETCONF) asynchronous: RPC and leaf update (first 
intended, then applied)
     - example of full NETCONF synchronous: RPC and leaf update. In this 
case, duplicate leaf.

The second open issue is that it's not clear which exact features are 
requested: a breakdown per RFC6087bis, per YANG language, and per 
NETCONF would help. This is what I've been trying to do with the couple 
of attached pictures. I would like to get confirmation from the 
openconfig that the understanding is right.

Some additional questions:
- Don't we need an extra /startup for startup parameters? Or startup 
parameters will always be the intended configuration?
- "The way we represent op-state must be consistent across all models"
What if one of the models is not consistent? In that case, only the 
description will make the link between the config-false and config-true 
leaf, right? So don't we need that link anyway?
That makes the link to "Ability to relate configuration to operational 
state must be consistent".

---

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

Hi netmod,

Thanks very much to everyone that has considered the problem that we laid out on the last interim call. I think we’re starting to reach a common understanding.

If I can make some slight tweaks to the diagrams that have been distributed:  

And some further clarifying points/explanations:

We have not been considering ephemeral and startup as separate items. As far as we see these, the startup is simply a subset of the intended state that happens to persist after a system reboot, or seed the initial set of intended states when the system restarts. Ephemeral state is simply intended state that is not persistent.
Intended and applied/actualised state are views of the running configuration.
All intention is written to the intended configuration (whether it be by CLI, a human, an NMS via NETCONF, a system agent, etc.) – which then transitions to becoming the applied/actualised configuration. This is based on either an explicit request to do so (‘commit’) or may be implicit. The success of the intended configuration becoming the applied configuration may be due to time deltas or condition, as Kent drew.
In what we referred to as a ‘synchronous’ system – we expect the attempt to make the intended state transition to the actual state to be completed when the operation returns (e.g., after a <commit />) then the <ok /> should return only when this intention has been applied.
We require the ability for an NMS to be able to see both the intended and the actual configuration – such that it can check whether its intention is currently the applied configuration, or has not yet been applied due to some external dependency (e.g., line card not plugged in).
A portion of the operational state date (marked operational: true) is the set of variables that are not related to state that an external system can assert the value of — for example, a counter, or a negotiated protocol timer.
We believe that there is an important advantage in being able to syntactically / structurally retrieve the set of state that is associated with some set of intended state. This is not ‘easy’ today, as there is no common way to link the two – especially as models are composed. This does not imply that we understand the semantics of that set of state – but simply that we can retrieve all state data that relates to a particular entity that we expressed some intention about (e.g., all state data that corresponds to a particular interface or BGP peer). This division is very important, since there is separation between elements of the NMS that interact with the network, and those that do need to understand the semantics/contents of the data leaves.  For some OpenConfig operators, this separation of concerns is part of their current NMS software architecture.
In terms of accessing subsets of leaves, we need to be able to:
Retrieve the intended state – this is done with a method that does similar to get-config in NETCONF.
Retrieve the actual + operational state of the device – done with a method similar to get.
Retrieve only the operational state – done with a method such as get-operational.
This means that we need to be able to distinguish intended/actual/operational variables leaves through the data model.
We did not define a requirement for a get-actual type call in openconfig-opstate, but there may be solutions that do want something like this (as per Benoit’s mail to the netmod list yesterday, where it is referenced as get-config-false).
We do not require that the two trees for intended and actual have identical paths in the data model. They are the same set of leaves – but it MUST be possible to check both. In openconfig-opstate then we consistently achieve this by having the same set of leaves (typically grouping FOO-config) that is included under both container config (where they are intended) and container state (where they are applied)). Since there is a common way to be able to relate these through the structure, then this is OK for us.
Thanks again.

Kind regards,
Anees, Marcus & Rob.

On 23 June 2015 at 16:44:36, Benoit Claise ([email-masked]) wrote:

Dear all,

In order to clarify the situation, I compiled some points from my notes and created a couple of diagrams. This was initially created for my personal use, but if it helps with the discussion, please use it.

The first open issue is terminology IMO.
    - intended, applied
    - synchronous/asynchronous
There are two synchronous levels: the protocol (NETCONF) and network element implementation. As Kent mentioned: "Kent NETCONF is a synchronous protocol but state may change asynchronously."
It would beneficial for the authors to explain what happens in the following NETCONF server two cases:
    - an example of (non-NETCONF) asynchronous: RPC and leaf update (first intended, then applied)
    - example of full NETCONF synchronous: RPC and leaf update. In this case, duplicate leaf.

The second open issue is that it's not clear which exact features are requested: a breakdown per RFC6087bis, per YANG language, and per NETCONF would help. This is what I've been trying to do with the couple of attached pictures. I would like to get confirmation from the openconfig that the understanding is right.

[…snip images…]
Some additional questions:
- Don't we need an extra /startup for startup parameters? Or startup parameters will always be the intended configuration?
- "The way we represent op-state must be consistent across all models"
What if one of the models is not consistent? In that case, only the description will make the link between the config-false and config-true leaf, right? So don't we need that link anyway?
That makes the link to "Ability to relate configuration to operational state must be consistent".

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

---

From: Andy Bierman <[email-masked]>
Date: Wed, 24 Jun 2015 10:55:44 -0700

Hi,

Not sure you are aware which parts of your diagram are already
standardized in NETCONF.  The startup and candidate capabilities
as defined in RFC 6241 are not related to operational state.

Andy

On Wed, Jun 24, 2015 at 10:39 AM, Rob Shakir <[email-masked]> wrote:

> Hi netmod,
>
>
> Thanks very much to everyone that has considered the problem that we laid
> out on the last interim call. I think we’re starting to reach a common
> understanding.
>
>
>    -
>    We have not been considering ephemeral and startup as separate items.
>    As far as we see these, the startup is simply a subset of the intended
>    state that happens to persist after a system reboot, or seed the initial
>    set of intended states when the system restarts. Ephemeral state is simply
>    intended state that is not persistent.
>    -
>
>    -
>    All intention is written to the intended configuration (whether it be
>    by CLI, a human, an NMS via NETCONF, a system agent, etc.) – which then
>    transitions to becoming the applied/actualised configuration. This is based
>    on either an explicit request to do so (‘commit’) or may be implicit. The
>    success of the intended configuration becoming the applied configuration
>    may be due to time deltas or condition, as Kent drew.
>    -
>
>    In what we referred to as a ‘synchronous’ system – we expect the
>    attempt to make the intended state transition to the actual state to be
>    completed when the operation returns (e.g., after a <commit />) then the
>    <ok /> should return only when this intention has been applied.
>    -
>
>    We require the ability for an NMS to be able to see both the intended
>    and the actual configuration – such that it can check whether its intention
>    is currently the applied configuration, or has not yet been applied due to
>    some external dependency (e.g., line card not plugged in).
>    -
>
>    A portion of the operational state date (marked operational: true) is
>    the set of variables that are not related to state that an external system
>    can assert the value of — for example, a counter, or a negotiated protocol
>    timer.
>    -
>
>    We believe that there is an important advantage in being able to
>    syntactically / structurally retrieve the set of state that is associated
>    with some set of intended state. This is not ‘easy’ today, as there is no
>    common way to link the two – especially as models are composed. This does
>    not imply that we understand the semantics of that set of state – but
>    simply that we can retrieve all state data that relates to a particular
>    entity that we expressed some intention about (e.g., all state data that
>    corresponds to a particular interface or BGP peer). This division is very
>    important, since there is separation between elements of the NMS that
>    interact with the network, and those that do need to understand the
>    semantics/contents of the data leaves.  For some OpenConfig operators, this
>    separation of concerns is part of their current NMS software architecture.
>    -
>
>    -
>       -
>       -
>       -
>       This means that we need to be able to distinguish
>       intended/actual/operational variables leaves through the data model.
>       -
>
>       We did not define a requirement for a get-actual type call in
>       openconfig-opstate, but there may be solutions that do want something like
>       this (as per Benoit’s mail to the netmod list yesterday, where it is
>       referenced as get-config-false).
>       -
>
>    We do not require that the two trees for intended and actual have
>    identical paths in the data model. They are the same set of leaves – but it
>    MUST be possible to check both. In openconfig-opstate then we consistently
>    achieve this by having the same set of leaves (typically grouping
>    FOO-config) that is included under both container config (where they are
>    intended) and container state (where they are applied)). Since there is a
>    common way to be able to relate these through the structure, then this is
>    OK for us.
>
> Thanks again.
>
> Kind regards,
> Anees, Marcus & Rob.
>
> element implementation. As Kent mentioned: "Kent NETCONF is a synchronous
> protocol but state may change asynchronously."
> requested: a breakdown per RFC6087bis, per YANG language, and per NETCONF
> would help. This is what I've been trying to do with the couple of attached
> pictures. I would like to get confirmation from the openconfig that the
> understanding is right.
>
> […snip images…]
>

---

From: Rob Shakir <[email-masked]>
Date: Wed, 24 Jun 2015 19:11:02 +0100

Hi Andy,

Yes, I’m definitely aware of this. The intention is to present a holistic view, from which any deltas to the existing functionality can be identified.

Kind regards,
r.

On 24 June 2015 at 18:56:28, Andy Bierman ([email-masked]) wrote:

Hi,

Andy

Hi netmod,

Thanks very much to everyone that has considered the problem that
we laid out on the last interim call. I think we’re starting to
reach a common understanding.

If I can make some slight tweaks to the diagrams that have been
distributed:

We have not been
considering ephemeral and startup as separate items. As far as we
see these, the startup is simply a subset of the intended state
that happens to persist after a system reboot, or seed the initial
set of intended states when the system restarts. Ephemeral state is
simply intended state that is not persistent.
Intended and
applied/actualised state are views of the running
configuration.
All intention is
written to the intended configuration (whether it be by CLI, a
human, an NMS via NETCONF, a system agent, etc.) – which then
transitions to becoming the applied/actualised configuration. This
is based on either an explicit request to do so (‘commit’) or may
be implicit. The success of the intended configuration becoming the
applied configuration may be due to time deltas or condition, as
Kent drew.
In what we referred
to as a ‘synchronous’ system – we expect the attempt to make the
intended state transition to the actual state to be completed when
the operation returns (e.g., after a <commit />) then the
<ok /> should return only when this intention has been
applied.
We require the
ability for an NMS to be able to see both the intended and the
actual configuration – such that it can check whether its intention
is currently the applied configuration, or has not yet been applied
due to some external dependency (e.g., line card not plugged
in).
A portion of the
operational state date (marked operational: true) is the set of
variables that are not related to state that an external system can
assert the value of — for example, a counter, or a negotiated
protocol timer.
We believe that
there is an important advantage in being able to syntactically /
structurally retrieve the set of state that is associated with some
set of intended state. This is not ‘easy’ today, as there is no
common way to link the two – especially as models are composed.
This does not imply that we understand the semantics of that set of
state – but simply that we can retrieve all state data that relates
to a particular entity that we expressed some intention about
(e.g., all state data that corresponds to a particular interface or
BGP peer). This division is very important, since there is
separation between elements of the NMS that interact with the
network, and those that do need to understand the
semantics/contents of the data leaves.  For some OpenConfig
operators, this separation of concerns is part of their current NMS
software architecture.
In terms of
accessing subsets of leaves, we need to be able to:
Retrieve the
intended state – this is done with a method that does similar to
get-config in NETCONF.
Retrieve the actual
+ operational state of the device – done with a method similar to
get.
Retrieve only the
operational state – done with a method such as
get-operational.
This means that we
need to be able to distinguish intended/actual/operational
variables leaves through the data model.
We did not define a
requirement for a get-actual type call in openconfig-opstate, but
there may be solutions that do want something like this (as per
Benoit’s mail to the netmod list yesterday, where it is referenced
as get-config-false).
We do not require
that the two trees for intended and actual have identical paths in
the data model. They are the same set of leaves – but it MUST be
possible to check both. In openconfig-opstate then we consistently
achieve this by having the same set of leaves (typically grouping
FOO-config) that is included under both container config (where
they are intended) and container state (where they are applied)).
Since there is a common way to be able to relate these through the
structure, then this is OK for us.
Thanks again.

Kind regards,
Anees, Marcus & Rob.

Dear all,

[…snip images…]

---

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

[As an individual contributor]

Hi Rob and OC team,

> Thanks very much to everyone that has considered the problem
> that we laid out on the last interim call. I think we¹re
> starting to reach a common understanding.

Indeed!

> If I can make some slight tweaks to the diagrams that have

This looks like a variant of the picture I posted here:
http://www.ietf.org/mail-archive/web/netmod/current/msg12738.html.   On
one hand I'm happy to see this because no one had acknowledged the pic
previously, but on the other hand, I'm concerned that you felt the need to
draw another picture, implying there still being a gap...

Actually, when looking at your picture, substituting running for intended,
I think your picture is essentially the same as represented here:
http://www.ietf.org/mail-archive/web/netmod/current/msg12729.html.  Of
course, without ephemeral, running==intended, so your picture isn't wrong
either.  I think the only difference is that your picture shows slides 2-4
together, whereas mine had distinct slides.  Is there a more significant
difference in your mind?

> * We have not been considering ephemeral and startup as
> separate items. As far as we see these, the startup is
> simply a subset of the intended state that happens to
> persist after a system reboot, or seed the initial set
> of intended states when the system restarts. Ephemeral
> state is simply intended state that is not persistent.

Yup

> * Intended and applied/actualised state are views of
> the running configuration.

Yes, but more precisely, running==intended when there is no ephemeral
config, right?

> * All intention is written to the intended configuration
> (whether it be by CLI, a human, an NMS via NETCONF, a
> system agent, etc.)  which then transitions to becoming
> the applied/actualised configuration. This is based on
> either an explicit request to do so (Œcommit¹) or may be
> implicit. The success of the intended configuration
> becoming the applied configuration may be due to time
> deltas or condition, as Kent drew.

Yes but, again, the clients are interacting with the "running" and/or
"ephemeral" (not directly to "intended").  The important bit is that
"ephemeral" can override "running", so the "intended" is actually the
result of a merge operation of sorts...

> * In what we referred to as a Œsynchronous¹ system  we
> expect the attempt to make the intended state transition
> to the actual state to be completed when the operation
> returns (e.g., after a <commit />) then the <ok /> should
> return only when this intention has been applied.

I see.  As stated on the call last week, NETCONF/RESTCONF are currently
only "asynchronous" by this definition, as neither has any statement
regarding *when* intended becomes operational wrt <ok/> or 200 OK.
Dipping into design for a sec, it might be interesting to add an optional
commit flag indicating that the server should not respond until
actual==intended...

> * We require the ability for an NMS to be able to see both
> the intended and the actual configuration  such that it
> can check whether its intention is currently the applied
> configuration, or has not yet been applied due to some
> external dependency (e.g., line card not plugged in).

Understood, at least for leafs that get a protocol negotiated value, which
may account for just 1% of the configuration.   Dipping again into design,
I was hoping we might use [XML/JSON] attributes, for instance:

     leaf duplex {
       type enumeration {
         enum "half";
         enum "full";
         enum "auto";
       }
       config true;
     }

  get-config from running:
       <duplex>auto</duplex>

  get-operational:
       <duplex intended="auto">full</duplex>

Less understood is how to support the conditional enablement cases
(https://tools.ietf.org/html/draft-kwatsen-conditional-enablement-00) such
as plugging in a line card, or installing a license, or time-of-day.  For
these, it's not clear what <get-operational> would return...

> * A portion of the operational state date (marked
> operational: true) is the set of variables that
> are not related to state that an external system
> can assert the value of ‹ for example, a counter,
> or a negotiated protocol timer.

This is what I think config=false should be used for going forwards.  That
is, as the example above shows, config=true simultaneously defines some
nodes returned by <get-operational/>, thus we only need config=false to
define the non-config based nodes like counters.

> * We believe that there is an important advantage
> in being able to syntactically / structurally
> retrieve the set of state that is associated with
> some set of intended state. This is not Œeasy¹
> today, as there is no common way to link the two
>  especially as models are composed. This does
> not imply that we understand the semantics of that
> set of state  but simply that we can retrieve
> all state data that relates to a particular entity
> that we expressed some intention about (e.g., all
> state data that corresponds to a particular
> interface or BGP peer). This division is very
> important, since there is separation between
> elements of the NMS that interact with the network,
> and those that do need to understand the semantics/
> contents of the data leaves.  For some OpenConfig
> operators, this separation of concerns is part of
> their current NMS software architecture.

Thanks for clarifying the motivation.  Looking at
draft-openconfig-netmod-opstate, this requirement appears to be supported
through tree-structure alone.  Is this solution sufficient or is there
also a need to have something more explicit like XPath pointers in the
data-model?

Thanks again,
Kent

---

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

Hi,

Rob Shakir <[email-masked]> wrote:
> Thanks very much to everyone that has considered the problem that we laid out
> on the last interim call. I think we’re starting to reach a common
> understanding.

As Andy pointed out, there is some overlap in what you describe below
with how NETCONF already works.  This raises some concerns, see below.

>   * Intended and applied/actualised state are views of the running
>     configuration.

In NETCONF terms, I think intended config is the "running" data
store.  Do you agree?

In your picture, it is clear that the schema for "intended" and
"applied/actual" is the same.  Good.

>   * All intention is written to the intended configuration (whether it be by
>     CLI, a human, an NMS via NETCONF, a system agent, etc.) – which then
>     transitions to becoming the applied/actualised configuration. This is
>     based on either an explicit request to do so (‘commit’) or may be
>     implicit. The success of the intended configuration becoming the applied
>     configuration may be due to time deltas or condition, as Kent
>     drew.

This part is not clear to me.  Again in NETCONF terms, "commit" is an
operation to copy the contents of the candidate data store into the
running data store.  But if we agreed that running equals intended, I
don't see what the explicit request would be to transition intended /
running into applied/actual?

In NETCONF, as soon as something is written into running (via an
explicit edit-config towards running or via commit), that data is
starting to be used internally in the system.  NETCONF does not state
that the write request must not return until the data has been
"applied", so both asynchronous and synchronous implementations seems
to be ok.

It is not possible to write something into NETCONF's running data
store (intended config) and prevent it from being used internally.

>   * In what we referred to as a ‘synchronous’ system – we expect the attempt
>     to make the intended state transition to the actual state to be completed
>     when the operation returns (e.g., after a <commit />) then the <ok />
>     should return only when this intention has been applied.

Ok.  But see below.

>   * We require the ability for an NMS to be able to see both the intended and
>     the actual configuration – such that it can check whether its intention is
>     currently the applied configuration, or has not yet been applied due to

Are you saying that in a synchronous system, if I write the config of
a card that is not plugged in, my <commit/> will hang until the card
has been plugged in?

>   * A portion of the operational state date (marked operational: true) is the
>     set of variables that are not related to state that an external system can
>     assert the value of — for example, a counter, or a negotiated protocol
>     timer.

Ok, but there is a simpler solution to this ;-)

>   * We believe that there is an important advantage in being able to
>     corresponds to a particular interface or BGP peer).

Ok.

>     This division is very
>     semantics/contents of the data leaves.  For some OpenConfig operators,
>     this separation of concerns is part of their current NMS software
>     architecture.
> 
>   * In terms of accessing subsets of leaves, we need to be able to:
> 
>       + Retrieve the intended state – this is done with a method that does
>         similar to get-config in NETCONF.
> 
>       + Retrieve the actual + operational state of the device – done with a
>         method similar to get.

Actually, this is not what NETCONF's <get> gives you.  It will give
you intended + operational.  But we could define a new rpc that gives
you this in NETCONF.

>       + Retrieve only the operational state – done with a method such as
>         get-operational.
> 
>       + This means that we need to be able to distinguish intended/actual/
>         operational variables leaves through the data model.
> 
>       + We did not define a requirement for a get-actual type call in
>         openconfig-opstate, but there may be solutions that do want something
>         like this (as per Benoit’s mail to the netmod list yesterday, where it
>         is referenced as get-config-false).
> 
>   * We do not require that the two trees for intended and actual have
>     identical paths in the data model. They are the same set of leaves – but
>     it MUST be possible to check both. In openconfig-opstate then we
>     consistently achieve this by having the same set of leaves (typically
>     grouping FOO-config) that is included under both container config (where
>     they are intended) and container state (where they are applied)). Since
>     there is a common way to be able to relate these through the structure,
>     then this is OK for us.
> 
> Thanks again.
> 
> Kind regards,
> Anees, Marcus & Rob.

/martin

> > In order to clarify the situation, I compiled some points from my
> > notes and created a couple of diagrams. This was initially created
> > for my personal use, but if it helps with the discussion, please
> > use it.
> 
> > There are two synchronous levels: the protocol (NETCONF) and
> > network element implementation. As Kent mentioned: "Kent NETCONF is
> > a synchronous protocol but state may change asynchronously."
> 
> > 
> It would beneficial for
> > the authors to explain what happens in the following NETCONF server
> > two cases:
> >      - an
> > example of (non-NETCONF) asynchronous: RPC and leaf update (first
> > intended, then applied)
> 
> >     - example of full NETCONF synchronous: RPC and
> > leaf update. In this case, duplicate leaf.
> > 
> 
> > The second open issue is that it's not clear which exact features
> > are requested: a breakdown per RFC6087bis, per YANG language, and
> > per NETCONF would help. This is what I've been trying to do with
> > the couple of attached pictures. I would like to get confirmation
> > from the openconfig that the understanding is right.
> 
> > 
> 
> > 
> 
> […snip images…]
> 
> > 
> 
> > 
> 
> > - Don't we need an extra /startup for startup parameters? Or
> > startup parameters will always be the intended configuration?
> 
> > description will make the link between the config-false and
> > config-true leaf, right? So don't we need that link anyway?
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 25 Jun 2015 01:19:54 +0200

On Wed, Jun 24, 2015 at 06:39:44PM +0100, Rob Shakir wrote:

> A portion of the operational state date (marked operational: true)
> is the set of variables that are not related to state that an
> external system can assert the value of — for example, a counter, or
> a negotiated protocol timer.

Not sure I parse this correctly but it sounds a bit like you make
something a static data model property that in reality is a dynamic
property of state. Lets take as an example the IP address of an
interface.  It can be statically configured or it can bee optained
dynamically via DHCP. So would you mark this operational true (or
operational sometimes) in the data model?

/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: Anees Shaikh <[email-masked]>
Date: Wed, 24 Jun 2015 18:22:28 -0700

So the model probably would have this as a choice, right?  In one case I
set the mode as STATIC and specify the address (intended and actual config
leaves, marked config: true, and config: false, respectively), and in the
other case I set the interface to DHCP (again intended and actual config),
and the received IP address would be set in an operational state variable
(e.g., dhcp-assigned-address).  This last leaf would be marked as
operational:true in our proposal.

thanks.
-- Anees

---

From: Anees Shaikh <[email-masked]>
Date: Wed, 24 Jun 2015 19:57:14 -0700

Hi Kent,

<snip>

> together, whereas mine had distinct slides.  Is there a more significant

we actually took your followup picture as the basis for the one we drew,
i.e., the one with slides 3 and 4 combined (
http://www.ietf.org/mail-archive/web/netmod/current/msg12738.html).  You'll
see the main difference is that the applied config (what you call actual)
is part of the state (i.e., config: false
data).

> Yes, but more precisely, running==intended when there is no ephemeral

I guess that's right, but as Rob said, we have not really considered a
separate type of config called ephemeral.  I personally view what we are
calling ephemeral as just control coming through a config channel (e.g.,
the i2rs case)

> result of a merge operation of sorts...

here by intended config, we mean what the intended change to the running
config is.

> commit flag indicating that the server should not respond until

yes ... this is really down to implementations.  In some platforms, the
response comes back
once all involved downstream services have validated and applied the
requested config -- that would be considered synchronous in the way we have
been thinking about it.

>        <duplex intended="auto">full</duplex>

In the proposal laid out in the draft, you would be able see any
differences between intended, actual, and operational with <get> operation
since it would return config: true (intended) and config: false (actual +
negotiated) nodes.   I would view this a little differently as  (not really
netconf syntax):

get-config from running:
  <duplex>auto</duplex>

get:
  <duplex path=config/>auto</duplex>
  <duplex path=state/>auto</duplex>
  <negotiated-duplex path=state/>full</negotiated-duplex>

get-operational:
  <negotiated-duplex path=state/>full</negotiated-duplex>

In particular, notice that the actual config part of the state reflects the
intended value (either immediately or eventually), and if there is
additional state required to reflect a negotiated value, that is a separate
leaf marked operational: true in the model.

> define the non-config based nodes like counters.

Agree this label makes sense, but if we agree that the applied (actual)
config is part of the state, then we would still need a way to get the
different types of state separately, i.e., the applied config vs. the
counters, negotiated values, etc.

> also a need to have something more explicit like XPath pointers in the

We've been able to make a good deal of progress with the data model pattern
in the draft and, at least at here internally, our NMS exploits that
structure to set and retrieve the different types of data we want to
compare.  We're still gaining experience with it.

thanks!
-- Anees

---

From: Andy Bierman <[email-masked]>
Date: Wed, 24 Jun 2015 20:24:29 -0700

On Wed, Jun 24, 2015 at 7:57 PM, Anees Shaikh <[email-masked]> wrote:

> http://www.ietf.org/mail-archive/web/netmod/current/msg12738.html).
> You'll see the main difference is that the applied config (what you call
> actual) is part of the state (i.e., config: false
> data).
>
>
>

The NETCONF WG has been asked by the I2RS WG to work on ephemeral
data (or configuration or whatever), so it is also high priority.

I2RS is not really "just control coming through a config channel".
It allows a controller to override device config and state in a standard way
based on machine-readable data models.  Instead of hand-coding
control protocols completely from scratch, after writing long complicated
RFCs,
just write a YANG module, turn the crank, and integrate. (That's the plan,
anyway ;-)

Andy

> In particular, notice that the actual config part of the state reflects
> the intended value (either immediately or eventually), and if there is
> We've been able to make a good deal of progress with the data model
> pattern in the draft and, at least at here internally, our NMS exploits
> that structure to set and retrieve the different types of data we want to

---

From: Anees Shaikh <[email-masked]>
Date: Wed, 24 Jun 2015 20:34:30 -0700

Hi Martin,

> In NETCONF terms, I think intended config is the "running" data

yes

> running into applied/actual?

don't think of this as necessarily related to NETCONF terms (we didn't) --
the commit operation on a system might be explicit or implicit as Rob
mentioned.  Transition to applied/actualized here doesn't mean copying from
one datastore to another.  It simply means that the config that is written
to the running config may be applied at some later point.  On some systems
today, they translate a single configuration push to a series of CLI
equivalents followed by an explicit command (again, per the CLI) -- there
is no separate commit request required from the NMS; in this case the
'commit' is implicit from the perspective of the NMS.

> "applied", so both asynchronous and synchronous implementations seems

Yes, that is clear now.

> store (intended config) and prevent it from being used internally.

Understood, for NETCONF behavior.  But one could imagine a system that
requires an explicit commit command to apply (or start applying) the
configuration that was pushed to the running config.  You could argue that
the config has to be staged somewhere analogous to a candidate datastore,
but it could also just be a simple cache.  In short, whether the transition
from intended running to actual running is implicit or explicitly triggered
is independent of NETCONF.

> a card that is not plugged in, my <commit/> will hang until the card

No, if the system supports pre-configured interfaces (the favorite example
it seems), it should apply the configuration and return when it has been
applied.  It is a valid applied configuration because the system supports
pre-configured interfaces.  The NMS should know that the "ok" that was
returned doesn't necessarily mean that the interface is present and active
-- and it would learn that from the oper-state value for the interface
being set to not-present.

> protocol

We probably have a different view of what that is :-)

> you intended + operational.  But we could define a new rpc that gives

yes, a bit of confusion here.  The actual configuration state (what has
been applied) and the operational state are all part of the state, and
marked config: false (or operational: true when that support is
implemented).   So the <get> should return all of the config: false nodes
including applied config, counters, negotiated values, etc.   You're right
of course that is also returns the intended config (config: true nodes).

-- Anees

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 25 Jun 2015 07:38:43 +0200

Anees,

does it really make sense to have to track multiple different objects
in order to find out which IP address(es) are used by an interface?
Perhaps I am old school but I do like the existing design better - one
place to find the operationally used state. I rather have additional
_metadata_ about where the values are originating from instead of a
static marker in a data model that requires to report state in
multiple places that than needs to be integrated again to answer
simple questions like which IP addresses are used by an interface.

Knowing the origin of operational state data is highly useful. Trying
to encode that in the design and structure of the data model, however,
seems complex, costly, and inefficient.

/js

---

From: Anees Shaikh <[email-masked]>
Date: Thu, 25 Jun 2015 00:29:13 -0700

hi Juergen,

I don't believe it involves tracking anything beyond what you would need to
track however the model is structured.   You would want to know when your
static IP is applied and being used, or you would want to know what IP
address was assigned by the DHCP server.  Our approach collects this
information in one consistent place (in terms of paths) independent of how
one wants to compose the models.   I guess don't understand what you mean
by it requires reporting and integrating state data from multiple places.

I really don't see where the extra complexity and cost you mention is
coming from.  Is the addition of some nodes in the data model so costly?
For whom?  A model writer?  I think the design pattern for writing models
in this way actually is pretty straightforward (having written several
reasonably complex models now).   For a human model reader?   Perhaps the
disconnect is that our perspective is coming from trying to build
operational software systems that consume the models without having to
write unnecessary model-specific code that just propagates more complexity
into the NMS.

thanks.
-- Anees

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 25 Jun 2015 09:40:19 +0200

> write unnecessary model-specific code that just propagates more complexity

The problem with your approach is that you are assigning semantics to
where information is located in the data model. You can only do this
once. While have N different locations where IP addresses are listed
might answer one operationally relevant question, it makes other
opertionally relevant questions harder. If you continue with your
approach, you will start replicating data multiple times to address
different operationally relevant question. And this simply does not
scale, clearly not with standards in mind.

I like to understand:

- what are the additional semantics in the data model (e.g., machine
  readable information that helps to understand static model
  relationships)

- what is the meta data you like to have and that you might want to
  filter on in order to retrieve data in meaningful ways

I am having a hard time to believe that encoding semantics in the
naming structure is a proper and workable solution.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 25 Jun 2015 10:35:21 +0200 (CEST)

Anees Shaikh <[email-masked]> wrote:
> one datastore to another.

It wouldn't necessarily mean that in NETCONF either.  Even if we
represented actual as a data store in the protocol, it's a conceptual
entity.

> It simply means that the config that is written
> configuration that was pushed to the running config.

But why would you call the config that exists before this explicit
command "intended"?  If I copy all my config to a local file, with the
intention of applying it later, is that local file my "intended
config"?  Hopefully not.  My current "running" is still intended until
I replace it.

> You could argue that

Rob wrote:

    The success of the intended configuration becoming the applied
    configuration may be due to time deltas or condition

So can you give an example of when the "commit" would hang until a
dependency have been fulfilled?

/martin

---

From: Rob Shakir <[email-masked]>
Date: Thu, 25 Jun 2015 09:38:29 +0100

On 25 June 2015 at 09:35:19, Martin Bjorklund ([email-masked]) wrote:

So can you give an example of when the "commit" would hang until a 
dependency have been fulfilled? 
In cases where there is another “commit” ongoing from another user, and this must complete before it is possible to apply this set of intended state.

Thanks,
r.

---

From: Andy Bierman <[email-masked]>
Date: Thu, 25 Jun 2015 06:49:38 -0700

> scale, clearly not with standards in mind.

The data modeling language allows the designer to choose
an arbitrary identifier for node names.

Making clever little rules about what arbitrary names are allowed,
where they allowed, etc. just adds complexity to the language.
The only robust design is to assign semantics to statements
with reserved keywords.

It would be unwise to design code that ignores a deterministic first order
language statement and relies on ad-hoc naming conventions instead.

Naming conventions are fine -- we have interfaces, interface-state, etc.
This helps readability but it is not a substitute for deterministic and
fully machine-usable statements.

The addition of extra layers is a big issue to me.
It clutters the data model, the XPath expressions, and adds bytes
to every payload that references that data.

I understand that the use of NP containers is very subjective.
Not all people think data should be organized the same way.
The only purpose of an NP-container is to organize data.
Each WG should decide the best way to organize its data.
If "config" and "state" containers really make sense for the
data, then use them.

But we don't need a CLR forcing this on everybody.

Andy