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

[Andy Bierman]

On Thu, Jun 25, 2015 at 12:40 AM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> On Thu, Jun 25, 2015 at 12:29:13AM -0700, Anees Shaikh wrote:
> > 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.
>
> 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.
>
>

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



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
>
> --
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Rob Shakir]

On 25 June 2015 at 09:35:19, Martin Bjorklund (m...@tail-f.com) 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.___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Martin Bjorklund]

Anees Shaikh  wrote:
> Hi Martin,
> 
> On Wed, Jun 24, 2015 at 1:03 PM, Martin Bjorklund  wrote:
> 
> >
> > 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?
> >
> 
> yes
> 
> 
> >
> > 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?
> >
> 
> 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 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
> 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.
> 
> 
> > 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.
> >
> 
> Yes, that is clear now.
> 
> 
> >
> > It is not possible to write something into NETCONF's running data
> > 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.

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
> 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.
> 
> 
> >   * 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).
> >
> > Are you saying that in a synchronous system, if I write the config of
> > a card that is not plugged in, my  will hang until the card
> > has been plugged in?
> >
> 
> 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.

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




> > >   * 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 t

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

[Juergen Schoenwaelder]

On Thu, Jun 25, 2015 at 12:29:13AM -0700, Anees Shaikh wrote:
> 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.

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

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Juergen Schoenwaelder]

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

On Wed, Jun 24, 2015 at 06:22:28PM -0700, Anees Shaikh wrote:
> 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
> 
> On Wed, Jun 24, 2015 at 4:19 PM, Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
> 
> > 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 
> >
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Andy Bierman]

On Wed, Jun 24, 2015 at 7:57 PM, Anees Shaikh  wrote:

> Hi Kent,
>
>
> 
>
>>
>>
>>
>> > If I can make some slight tweaks to the diagrams that have
>> > been distributed:
>>
>> 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 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).
>
>
>
>> > * Intended and applied/actualised state are views of
>> > the running configuration.
>>
>> Yes, but more precisely, running==intended when there is no ephemeral
>> config, right?
>>
>
> 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)
>
>

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



>
>>
>>
>> > * 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...
>>
>
> here by intended config, we mean what the intended change to the running
> config is.
>
>
>>
>> > * 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 ) then the  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  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...
>>
>
> 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.
>
>
>>
>> > * 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:
>>auto
>>
>>   get-operational:
>>full
>>
>
> In the proposal laid out in the draft, you would be able see any
> differences between intended, actual, and operational 

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

[Juergen Schoenwaelder]

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 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Martin Bjorklund]

Hi,

Rob Shakir  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 ) then the 
> 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
> some external dependency (e.g., line card not plugged in).

Are you saying that in a synchronous system, if I write the config of
a card that is not plugged in, my  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
> 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).

Ok.

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

Actually, this is not what NETCONF's  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 t

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

[Kent Watsen]

[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
> been distributed:

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 ) then the  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  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:
   auto

  get-operational:
   full


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  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 , 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
> interf

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

[Rob Shakir]

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 (a...@yumaworks.com) wrote:

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



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 ) then the
 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 (bcla...@cisco.com) 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 elemen

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

[Andy Bierman]

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  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.
>
>
> If I can make some slight tweaks to the diagrams that have been
> distributed:
>
> [image: img.png]
>
> 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 ) then the
> 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 (bcla...@cisco.com) wrote:
>
> Dear all,
>
> In order to clarify the situation, I compiled some points from my notes
> and created a couple of diagrams. T

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

[Rob Shakir]

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 ) then the  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 (bcla...@cisco.com) 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