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

[Benoit Claise]

Rob,

Benoit,

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

On September 10, 2015 at 04:40:30, Benoit Claise (bcla...@cisco.com) wrote:

A common architecture includes a central configuration data

store that is being updated by the manageability framework and
updates read by the subsystems affected by the change (e.g. the
BGP service or the interface manager). In this case, there is
no other source of configuration except for the content of the
data store.

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

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

You're right. Good clarification.

Regards, Benoit


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

router bgp 65497
  neighbor 192.0.2.1 remote-as 65500

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


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

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

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

Regards,
r.



.



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

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

[Andy Bierman]

On Mon, Sep 14, 2015 at 12:12 PM, Kent Watsen  wrote:

> [As a contributor]
>
> > This raises the issue "how does the client know that a missing applied
> > value means there is no applied value vs. the server does not know
> >  and does not support reporting the applied value for a particular leaf?"
> >
> > None of the solutions allow a client to know that.
>
> draft-kwatsen-netmod-opstate-reqs Sections 5.2 and 6.1. define an
> Applied Configuration capability so the client to tell, doesn't this count?
>
>

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

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

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

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



> > Andy
>
> Kent
>
>
>
>

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

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

[Kent Watsen]

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

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

Thanks again Rob!

Kent

From: Kent Watsen <kwat...@juniper.net<mailto:kwat...@juniper.net>>
Date: Monday, September 14, 2015 at 3:12 PM
To: Andy Bierman <a...@yumaworks.com<mailto:a...@yumaworks.com>>, Juergen 
Schoenwaelder 
<j.schoenwael...@jacobs-university.de<mailto:j.schoenwael...@jacobs-university.de>>,
 Mahesh Jethanandani <mjethanand...@gmail.com<mailto:mjethanand...@gmail.com>>, 
"netmod@ietf.org<mailto:netmod@ietf.org>" 
<netmod@ietf.org<mailto:netmod@ietf.org>>
Subject: Re: [netmod] YANG coordination feedback on 
draft-openconfig-netmod-opstate-01

[As a contributor]

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

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

> Andy

Kent



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

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

[Kent Watsen]

[As a contributor]

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

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

> Andy

Kent



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

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

[Martin Bjorklund]

Juergen Schoenwaelder  wrote:
> On Fri, Sep 11, 2015 at 10:54:22AM +0100, Robert Wilton wrote:
> > >
> > >Then Lada brought up the example of ip addresses.  It was mentioned
> > >on the call that for ip addresses there would be three lists; one for
> > >intended, one for applied, and one in derived state, where the one in
> > >derived state is what the box *really* uses.  So for example if it
> > >gets an ip from dhcp, it will be in the derived state list, but not in
> > >applied config.
> > >
> > >Why is this ip-address list different from the interface list?  Why
> > >was it enough with two lists for interfaces, but we need three for ip
> > >addresses?
> > I don't see that they are different.  I think that you have 3 
> > lists/leaves in both cases:
> > 
> > I.e. I would say that 3 IP addr leaves are required in an async system, 
> > at a given time t:
> >  - only the intended leaf can indicate what IP addr config the operator 
> > wants on the interface (if any).
> >  - only the applied leaf can indicate what IP addr is actually being 
> > used as the configured value on the interface.
> >  - only the derived leaf can indicate what IP addr is actually 
> > operationally being used for the interface (which might be due to IP 
> > addr config, DHCP, or perhaps some other mechanism).
> > 
> > I think that in the both kwatsen-netmod-opstate and 
> > wilton-netmod-opstate there are logically 3 interface lists as well:
> >  - /if:interfaces is logically split into 2, either through being 
> > present in separate running and applied datastores, or through having 
> > separate cfg-intended/cfg-applied leaves.
> >  - /if:interfaces-state, which I perceive as logically the derived 
> > state for an interface.
> >
> 
> My personal requirement would be to be able to find all IP addresses
> of an interface that are operationally used in one place.

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


/martin

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

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

[Ladislav Lhotka]

> On 14 Sep 2015, at 10:21, Martin Bjorklund  wrote:
> 
> Juergen Schoenwaelder  wrote:
>> On Fri, Sep 11, 2015 at 10:54:22AM +0100, Robert Wilton wrote:
 
 Then Lada brought up the example of ip addresses.  It was mentioned
 on the call that for ip addresses there would be three lists; one for
 intended, one for applied, and one in derived state, where the one in
 derived state is what the box *really* uses.  So for example if it
 gets an ip from dhcp, it will be in the derived state list, but not in
 applied config.
 
 Why is this ip-address list different from the interface list?  Why
 was it enough with two lists for interfaces, but we need three for ip
 addresses?
>>> I don't see that they are different.  I think that you have 3 
>>> lists/leaves in both cases:
>>> 
>>> I.e. I would say that 3 IP addr leaves are required in an async system, 
>>> at a given time t:
>>> - only the intended leaf can indicate what IP addr config the operator 
>>> wants on the interface (if any).
>>> - only the applied leaf can indicate what IP addr is actually being 
>>> used as the configured value on the interface.
>>> - only the derived leaf can indicate what IP addr is actually 
>>> operationally being used for the interface (which might be due to IP 
>>> addr config, DHCP, or perhaps some other mechanism).
>>> 
>>> I think that in the both kwatsen-netmod-opstate and 
>>> wilton-netmod-opstate there are logically 3 interface lists as well:
>>> - /if:interfaces is logically split into 2, either through being 
>>> present in separate running and applied datastores, or through having 
>>> separate cfg-intended/cfg-applied leaves.
>>> - /if:interfaces-state, which I perceive as logically the derived 
>>> state for an interface.
>>> 
>> 
>> My personal requirement would be to be able to find all IP addresses
>> of an interface that are operationally used in one place.
> 
> Yes.  I am trying to understand if a separate list of operationally
> used addresses is needed even if we have the "applied config".  I
> think the answer is yes.  Then the question is if we don't need a
> separate list of operationally used interfaces as well.  If we do,
> what value does the "applied config" idea bring us?

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

Lada

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

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




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

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

[Juergen Schoenwaelder]

On Fri, Sep 11, 2015 at 10:54:22AM +0100, Robert Wilton wrote:
> >
> >Then Lada brought up the example of ip addresses.  It was mentioned
> >on the call that for ip addresses there would be three lists; one for
> >intended, one for applied, and one in derived state, where the one in
> >derived state is what the box *really* uses.  So for example if it
> >gets an ip from dhcp, it will be in the derived state list, but not in
> >applied config.
> >
> >Why is this ip-address list different from the interface list?  Why
> >was it enough with two lists for interfaces, but we need three for ip
> >addresses?
> I don't see that they are different.  I think that you have 3 
> lists/leaves in both cases:
> 
> I.e. I would say that 3 IP addr leaves are required in an async system, 
> at a given time t:
>  - only the intended leaf can indicate what IP addr config the operator 
> wants on the interface (if any).
>  - only the applied leaf can indicate what IP addr is actually being 
> used as the configured value on the interface.
>  - only the derived leaf can indicate what IP addr is actually 
> operationally being used for the interface (which might be due to IP 
> addr config, DHCP, or perhaps some other mechanism).
> 
> I think that in the both kwatsen-netmod-opstate and 
> wilton-netmod-opstate there are logically 3 interface lists as well:
>  - /if:interfaces is logically split into 2, either through being 
> present in separate running and applied datastores, or through having 
> separate cfg-intended/cfg-applied leaves.
>  - /if:interfaces-state, which I perceive as logically the derived 
> state for an interface.
>

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

/js

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

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

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

[Juergen Schoenwaelder]

On Fri, Sep 11, 2015 at 08:48:55PM -0700, Andy Bierman wrote:
> 
> All solutions expect the server to be able to determine applied status for
> every leaf
> in the intended config. All solutions require basically the same internal
> API support
> to check the relevant applied config or operational state.
> 
> In every solution, the server will magically know how to check that the IP
> address is active.
> That's the point. It is better than forcing the client to know how to do
> this for every type of server.
> 
> IMO, this requirement is clear, and each draft has a solution approach for
> this new API.
>

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

/js

-- 
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] YANG coordination feedback on draft-openconfig-netmod-opstate-01

[Robert Wilton]

Hi,

On 14/09/2015 09:31, Ladislav Lhotka wrote:

On 14 Sep 2015, at 10:21, Martin Bjorklund  wrote:

Juergen Schoenwaelder  wrote:

On Fri, Sep 11, 2015 at 10:54:22AM +0100, Robert Wilton wrote:

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

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

I don't see that they are different.  I think that you have 3
lists/leaves in both cases:

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

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


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

Yes.  I am trying to understand if a separate list of operationally
used addresses is needed even if we have the "applied config".  I
think the answer is yes.  Then the question is if we don't need a
separate list of operationally used interfaces as well.
I may be off the mark, but I don't think that the Open Config 
requirements are saying that they don't want/need a separate list of 
operationally used interfaces, but more that they want the config and 
operational data for an interface to be under the same per interface 
container, so (i) that you can easily get all the data for an interface 
in a single request, or (ii) easily get the config and operational data 
for a particular feature on a interface without having to request the 
interface data from two separate lists.


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



   If we do,
what value does the "applied config" idea bring us?

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


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


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



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


Thanks,
Rob




Lada



/martin

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

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




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


___
netmod 

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

[Andy Bierman]

On Fri, Sep 11, 2015 at 12:38 AM, Martin Bjorklund  wrote:

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

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

There are at least 2 outcomes I can think of:

  Outcome 1) Convergence:
  Intended config eventually matches Applied

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

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

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

  1.  Time (in async systems).
>

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

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




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

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



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


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



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



>
> Then Lada brought up the example of ip addresses.  It was mentioned
> on the call that for ip addresses there would be three lists; one for
> intended, one for applied, and one in derived state, where the one in
> derived state is what the box *really* uses.  So for example if it
> gets an ip from dhcp, it will be in the derived state list, but not in
> applied config.
>
> Why is this ip-address list different from the interface list?  Why
> was it enough with two lists for interfaces, but we need three for ip
> addresses?
>
>
> /martin
>


Andy


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

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

[Robert Wilton]

Hi Martin,

On 11/09/2015 08:38, Martin Bjorklund wrote:

Sam Aldrin  wrote:

On Sep 10, 2015, at 4:13 PM, Mahesh Jethanandani
 wrote:



On Sep 10, 2015, at 12:43 PM, Carl Moberg (camoberg)
> wrote:

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

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

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

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

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

Section 7 of draft-openconfig-netmod-opstate talks about
that. Specifically, #3 talks about the interface question you raise..

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

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

   1.  Time (in async systems).

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

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


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


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




   4.  "Template substitution"; the draft uses the example of an 'all'
   interface that exists in intended config but not in applied.
I don't agree with this one either.  I don't think that cfg intended vs 
applied can or should be used as templating mechanism.


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


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





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

Why is this ip-address list different from the interface list?  Why
was it enough with two lists for interfaces, but we need three for ip
addresses?
I don't see that they are different.  I think that you have 3 
lists/leaves in both cases:


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


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

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

[Ladislav Lhotka]

Martin Bjorklund  writes:

> Sam Aldrin  wrote:
>> 
>> > On Sep 10, 2015, at 4:13 PM, Mahesh Jethanandani
>> >  wrote:
>> > 
>> > 
>> >> On Sep 10, 2015, at 12:43 PM, Carl Moberg (camoberg)
>> >> > wrote:
>> >> 
>> >> Now, think about configuration parameters that have applied
>> >> configuration located in more than one place. Let’s say you change the
>> >> IP address of an interface, it is likely that this configuration will
>> >> be passed around as input to a handful of subsystems (e.g. the DHCP
>> >> server, some routing daemons that may bind to specific IP
>> >> addresses). Is the intended and applied in sync when a specific subset
>> >> of those configurations are updated. What happens if there’s a partial
>> >> failure?
>> > 
>> > This is a good example. Another example, and somebody on the call
>> > today started to ask this but got cut off, relates to interfaces on
>> > the device.
>> > 
>> > Interfaces already exist on a system. As such they have a
>> > configuration (default values) that exists on them. They are enabled
>> > when configuration gets applied on them. They will have applied
>> > configuration but no intended configuration. Should this be reported?
>> > 
>> > Yet another example is of a BFD session that gets bootstrapped because
>> > of a ping. There is no intended configuration, but the session exists
>> > and a query of configuration in this case would return a valid BFD
>> > session.
>> > 
>> > Could we get some clarification (with examples, preferably) on what
>> > the expectation is from a openconfig opstate perspective?
>> 
>> Section 7 of draft-openconfig-netmod-opstate talks about
>> that. Specifically, #3 talks about the interface question you raise..
>
> I think it is important that we understand how this 'applied config'
> is supposed to be populated on a device.
>
> First it was said that it there is just one way they can be different;
> time (on async systems).  After some discussion I think there are now
> four ways:
>
>   1.  Time (in async systems).
>
>   2.  Hardware.  If something is in intended config but there is no hw
>   present, it is not in applied.
>
>   3.  System-controlled stuff.  If the system auto-creates an
>   interface (for example), it will be in the applied config but
>   not in intended.
>
>   4.  "Template substitution"; the draft uses the example of an 'all'
>   interface that exists in intended config but not in applied.
>
>
> Then Lada brought up the example of ip addresses.  It was mentioned
> on the call that for ip addresses there would be three lists; one for
> intended, one for applied, and one in derived state, where the one in
> derived state is what the box *really* uses.  So for example if it
> gets an ip from dhcp, it will be in the derived state list, but not in
> applied config.

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

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

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

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

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

Lada

>
> Why is this ip-address list different from the interface list?  Why
> was it enough with two lists for interfaces, but we need three for ip
> addresses?
>
>
> /martin
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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

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

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

[Dean Bogdanovic]

> On Sep 11, 2015, at 12:07 PM, Ladislav Lhotka  wrote:
> 
> Martin Bjorklund  writes:
> 
>> Sam Aldrin  wrote:
>>> 
 On Sep 10, 2015, at 4:13 PM, Mahesh Jethanandani
  wrote:
 
 
> On Sep 10, 2015, at 12:43 PM, Carl Moberg (camoberg)
> > wrote:
> 
> Now, think about configuration parameters that have applied
> configuration located in more than one place. Let’s say you change the
> IP address of an interface, it is likely that this configuration will
> be passed around as input to a handful of subsystems (e.g. the DHCP
> server, some routing daemons that may bind to specific IP
> addresses). Is the intended and applied in sync when a specific subset
> of those configurations are updated. What happens if there’s a partial
> failure?
 
 This is a good example. Another example, and somebody on the call
 today started to ask this but got cut off, relates to interfaces on
 the device.
 
 Interfaces already exist on a system. As such they have a
 configuration (default values) that exists on them. They are enabled
 when configuration gets applied on them. They will have applied
 configuration but no intended configuration. Should this be reported?
 
 Yet another example is of a BFD session that gets bootstrapped because
 of a ping. There is no intended configuration, but the session exists
 and a query of configuration in this case would return a valid BFD
 session.
 
 Could we get some clarification (with examples, preferably) on what
 the expectation is from a openconfig opstate perspective?
>>> 
>>> Section 7 of draft-openconfig-netmod-opstate talks about
>>> that. Specifically, #3 talks about the interface question you raise..
>> 
>> I think it is important that we understand how this 'applied config'
>> is supposed to be populated on a device.
>> 
>> First it was said that it there is just one way they can be different;
>> time (on async systems).  After some discussion I think there are now
>> four ways:
>> 
>>  1.  Time (in async systems).
>> 
>>  2.  Hardware.  If something is in intended config but there is no hw
>>  present, it is not in applied.
>> 
>>  3.  System-controlled stuff.  If the system auto-creates an
>>  interface (for example), it will be in the applied config but
>>  not in intended.
>> 
>>  4.  "Template substitution"; the draft uses the example of an 'all'
>>  interface that exists in intended config but not in applied.
>> 
>> 
>> Then Lada brought up the example of ip addresses.  It was mentioned
>> on the call that for ip addresses there would be three lists; one for
>> intended, one for applied, and one in derived state, where the one in
>> derived state is what the box *really* uses.  So for example if it
>> gets an ip from dhcp, it will be in the derived state list, but not in
>> applied config.
> 
> Right. After yesterday's interim I am much less in favour of this
> intended/applied proposal because
> 
> - as you say, applied configuration falls short of representing "the
>  state that the network element is actually in",
> 
> - states in which intended and applied configuration can be out of sync
>  are only transient. In the use cases I am interested in, such states
>  could be relatively normal and last long.
> 
> Another example that comes to my mind are static routes: an operator
> needs to know that a configured static route got installed, and this can
> be verified only by inspecting a corresponding RIB (operational
> state). I don't see how a copy of static routes in applied configuration
> could help.
> 
> I agree with Juergen that what we need is a clever representation of
> operational state and this is hard work that needs to be done by experts
> on an ad hoc basis. That's why I am also sceptical about the possibility
> of having fixed and universally applicable relationships between
> configuration and operational state.

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

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

Dean

> 
> Lada
> 
>> 
>> Why is this ip-address list different from the interface list?  Why
>> was it enough with two lists for interfaces, but we need three for ip
>> addresses?
>> 
>> 
>> /martin
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> 

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

[Andy Bierman]

Hi Mahesh,

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

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

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

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

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

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


Andy

On Fri, Sep 11, 2015 at 2:52 PM, Mahesh Jethanandani <
mjethanand...@gmail.com> wrote:

> And while we mull over the questions Andy has raised, I want to go back
> and dwell on what Rob said about why he wanted a way to determine when the
> configuration has taken effect. I might be simplifying the problem a little
> too much, but I am sure Rob will correct me. The ask as I understand
> is, give me a way to deterministically know when a given piece of
> configuration has taken effect.
>
> As an exercise I wanted to mentally go through trying to configure an
> interface to determine if the configuration has taken effect. Very simply,
> I want to assign an IP address to an interface. If I now want to know if
> this configuration has taken effect, I can check for the IP address of the
> interface. Querying the IP address on an interface does not tell me if it
> has taken effect. Yes, it has been written to a register, but what does
> that tell me? Nothing. My only deterministic way of knowing that the IP
> address has taken effect is if I can see traffic transmitted/received with
> that IP address on that interface.
>
> To me that is the crux of the problem with simply reflecting operational
> status with a flag that gets updated when the configuration gets written.
> In most cases, the configuration will just work and the flag will tell me
> nothing new. But when it does not, having written to a flag will also tell
> me nothing, other than the fact that the configuration was written.
>
> I contend that the real ask with this example is to determine if I can
> pass IP traffic, and to determine that, we need more than a “intended vs
> actual” flag.
>
> On Sep 11, 2015, at 9:42 AM, Andy Bierman  wrote:
>
>
>
> On Fri, Sep 11, 2015 at 12:38 AM, Martin Bjorklund  wrote:
>
>> Sam Aldrin  wrote:
>> >
>> > > On Sep 10, 2015, at 4:13 PM, Mahesh Jethanandani
>> > >  wrote:
>> > >
>> > >
>> > >> On Sep 10, 2015, at 12:43 PM, Carl Moberg (camoberg)
>> > >> > wrote:
>> > >>
>> > >> Now, think about configuration parameters that have applied
>> > >> configuration located in more than one place. Let’s say you change
>> the
>> > >> IP address of an interface, it is likely that this configuration will
>> > >> be passed around as input to a handful of subsystems (e.g. the DHCP
>> > >> server, some routing daemons that may bind to specific IP
>> > >> addresses). Is the intended and applied in sync when a specific
>> subset
>> > >> of those configurations are updated. What happens if there’s a
>> partial
>> > >> failure?
>> > >
>> > > This is a good example. Another example, and somebody on the call
>> > > today started to ask this but got cut off, relates to interfaces on
>> > > the device.
>> > >
>> > > Interfaces already exist on a system. As such they have a
>> > > configuration (default values) that exists on them. They are enabled
>> > > when configuration gets applied on them. They will have applied
>> > > configuration but no intended configuration. Should this be reported?
>> > >
>> > > Yet another example is of a BFD session that gets bootstrapped because
>> > > of a ping. There is no intended configuration, but the session exists
>> > > and a query of configuration in this case would return a valid BFD
>> > > session.
>> > >
>> > > Could we get some clarification (with examples, preferably) on what
>> > > the expectation is from a openconfig opstate perspective?
>> >
>> > Section 7 of draft-openconfig-netmod-opstate talks about
>> > that. Specifically, #3 talks about the interface question you raise..
>>
>> I think it is important that we understand how this 'applied config'
>> is supposed to be populated on a device.
>>
>> First it was said that it there is just one way they can be different;
>> time (on async systems).  After some discussion I think there are now
>> four ways:
>>
>>
>
> IMO it would 

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

[Ladislav Lhotka]

Hi,

comments inline.

Benoit Claise  writes:

> Dear all,
>
> The YANG coordination team 
>  has 
> spent some time reading and gathering input on the requirements and 
> proposed solutions in draft-openconfig-netmod-opstate. This note is to 
> collect some observations that will hopefully contribute to progress in 
> the working group.
>
> We believe it is useful to consider that YANG was initially designed to 
> be a data modeling language for the NETCONF protocol. IETF is also 
> working on RESTCONF which is an HTTP-based protocol to access data 
> defined in YANG, using the datastores defined in NETCONF.
>
> YANG is fulfilling its intended role with NETCONF and RESTCONF and has 
> gained some significant traction in this capacity. There are some 
> changes worked on in YANG 1.1, but they are mostly incremental.
>
> There is interest in using other protocols outside of NETCONF and 
> RESTCONF to manipulate data described by YANG. The proposals in the 
> draft is based on the assertion that YANG models should be usable for 
> protocols beyond RESTCONF and NETCONF. So these are new requirements on 
> YANG from, or in preparation for, new protocol bindings.
>
> We have focused on two main aspects of the draft.
>
> FIRSTLY: The proposed split between intended and applied configuration 
> as described in sections 4.1 (requirements) and 5.1 (implications)
>
> There are two observations here:
> 1. The implication is that all configurable data nodes ("intended 
> configuration") shall be repeated in an operational version ("applied 
> configuration") in all models for all applications going forward. This 
> would apply independent of if the system is synchronous or asynchronous 
> in nature. Synchronous systems would simply hard-wire the applied 
> configuration to be the same as intended configuration at all times.
> 2. An informal round of conversations with some vendors as well as some 
> tooling vendors show that there are currently no widely known platforms 
> that allow for observing the intended and applied state separately. A 
> common architecture includes a central configuration data store that is 
> being updated by the manageability framework and updates read by the 
> subsystems affected by the change (e.g. the BGP service or the interface 
> manager). In this case, there is no other source of configuration except 
> for the content of the data store.

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

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

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

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

>
> Please note that this was not an exhaustive collection of data, but 
> should give some directional information.
>
> The *implication* we would like to make here is that by making this 
> feature mandatory part of the YANG language itself (as opposed to an 
> optional capability) we risk introducing a fake perception that the 
> current NETCONF server supports a capability it can't support. Indeed, 
> polling the applied configuration would always return the intended 
> configuration.
>
> A *question* would be if it would be useful to consider a direction 
> where we make an attempt to separate out requirements that are tied to 
> specific protocols and solve them in the protocol semantics rather than 
> in the language to the extent we can. Without knowing more about the 
> intended protocol in the case of this draft, it is hard to make more 
> progress.
>
> A *suggestion* is to ask the draft authors to document the protocol 
> bindings in order to qualify the requirements going forward.
>
> SECONDLY: The proposed schema locations for configuration and 
> corresponding operational state in sections 4.5 (requirements) and 5.4 
> (implications)
>
> The observation to be made here is well captured in the draft itself as 
> bullet 3 under section 7:
>
>  "The proposal does not allow items that are not configured, 
> configured but not present, or system 

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

[Lou Berger]

Benoit,

A nit on your mail:


On September 10, 2015 4:40:39 AM Benoit Claise  wrote:


Dear all,

The YANG coordination team
 has
spent some time reading and gathering input on the requirements and
proposed solutions in draft-openconfig-netmod-opstate. This note is to
collect some observations that will hopefully contribute to progress in
the working group.

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

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

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

We have focused on two main aspects of the draft.

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

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


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


Lou



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

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

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

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

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

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

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

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

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

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

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

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

[Einar Nilsen-Nygaard (einarnn)]

Lou,

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

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

Cheers,

Einar

On 10 Sep 2015, at 13:25, Lou Berger 
> wrote:


> 2. An informal round of conversations with some vendors as well as some
> tooling vendors show that there are currently no widely known platforms
> that allow for observing the intended and applied state separately. A
> common architecture includes a central configuration data store that is
> being updated by the manageability framework and updates read by the
> subsystems affected by the change (e.g. the BGP service or the interface
> manager). In this case, there is no other source of configuration except
> for the content of the data store.

While this narrow statement is true, every system I know about can provide the 
equivalent of applied config state via show commands.
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Rob Shakir]

Benoit,

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

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

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

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

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

router bgp 65497
 neighbor 192.0.2.1 remote-as 65500

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

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

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

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

Regards,
r.



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

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

[Lou Berger]

Einar,

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

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

Lou

> Cheers,
>
> Einar
>
> On 10 Sep 2015, at 13:25, Lou Berger  > wrote:
>
>> > 2. An informal round of conversations with some vendors as well as
>> some
>> > tooling vendors show that there are currently no widely known
>> platforms
>> > that allow for observing the intended and applied state separately. A
>> > common architecture includes a central configuration data store
>> that is
>> > being updated by the manageability framework and updates read by the
>> > subsystems affected by the change (e.g. the BGP service or the
>> interface
>> > manager). In this case, there is no other source of configuration
>> except
>> > for the content of the data store.
>>
>> While this narrow statement is true, every system I know about can
>> provide the equivalent of applied config state via show commands.
>>


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

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

[Mahesh Jethanandani]

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

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

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

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

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

Mahesh Jethanandani
mjethanand...@gmail.com



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

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

[Sam Aldrin]

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

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

-sam
> 
> Mahesh Jethanandani
> mjethanand...@gmail.com 
> 
> 
> 
> ___
> 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] YANG coordination feedback on draft-openconfig-netmod-opstate-01

[Anees Shaikh]

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

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

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

While the draft does say this, you've unfortunately misunderstood the point
being made in that section (I'll have to accept some responsibility for
writing it this way).  The preface to Section 7 says, "A number of issues
have been raised with the proposed solution ..." and point #3 is just
stating the issue that was raised with regard to our proposal -- if you
read the rest of the explanation in #3, it describes an example of how the
solution can address these situations, using a specific example of
configuring 'all' interfaces , some of which may not be present.
Similarly, if an implementation supports pre-configuration of interfaces,
for example, the intended configuration reflects that preconfiguration,
while the corresponding state would show that it is applied but also that
oper-status = 'NOT PRESENT'

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

thanks.
-- Anees


On Thu, Sep 10, 2015 at 1:40 AM, Benoit Claise  wrote:

> Dear all,
>
> The YANG coordination team
> 
> has spent some time reading and gathering input on the requirements and
> proposed solutions in draft-openconfig-netmod-opstate. This note is to
> collect some observations that will hopefully contribute to progress in the
> working group.
>
> We believe it is useful to consider that YANG was initially designed to be
> a data modeling language for the NETCONF protocol. IETF is also working on
> RESTCONF which is an HTTP-based protocol to access data defined in YANG,
> using the datastores defined in NETCONF.
>
> YANG is fulfilling its intended role with NETCONF and RESTCONF and has
> gained some significant traction in this capacity. There are some changes
> worked on in YANG 1.1, but they are mostly incremental.
>
> There is interest in using other protocols outside of NETCONF and RESTCONF
> to manipulate data described by YANG. The proposals in the draft is based
> on the assertion that YANG models should be usable for protocols beyond
> RESTCONF and NETCONF. So these are new requirements on YANG from, or in
> preparation for, new protocol bindings.
>
> We have focused on two main aspects of the draft.
>
> FIRSTLY: The proposed split between intended and applied configuration as
> described in sections 4.1 (requirements) and 5.1 (implications)
>
> There are two observations here:
> 1. The implication is that all configurable data nodes ("intended
> configuration") shall be repeated in an operational version ("applied
> configuration") in all models for all applications going forward. This
> would apply independent of if the system is synchronous or asynchronous in
> nature. Synchronous systems would simply hard-wire the applied
> configuration to be the same as intended configuration at all times.
> 2. An informal round of conversations with some vendors as well as some
> tooling vendors show that there are currently no widely known platforms
> that allow for observing the intended and applied state separately. A
> common architecture includes a central configuration data store that is
> being updated by the manageability framework and updates read by the
> subsystems affected by the change (e.g. the BGP service or the interface
> manager). In this case, there is no other source of configuration except
> for the content of the data store.
>
> Please note that this was not an exhaustive collection of data, but should
> give some directional information.
>
> The *implication* we would like to make here is that by making this
> feature mandatory part of the YANG language itself (as opposed to an
> optional capability) we risk introducing a fake perception that the current
> NETCONF server supports a capability it can't support. Indeed, polling the
> applied configuration would always return the intended configuration.
>
> A *question* would be if it would be useful to consider a direction where
> we make an attempt to separate out requirements that are tied to specific
> protocols and solve them in the protocol semantics rather than in the
> language to the extent we can. Without knowing more about the intended
> protocol in the case of this draft, it is hard to make more progress.
>
> A *suggestion* is to ask the 

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

[Carl Moberg (camoberg)]

 Inline:

> On Sep 10, 2015, at 11:46 AM, Ladislav Lhotka  wrote:
> 
> Hi,
> 
> comments inline.
> 
> Benoit Claise  writes:
> 
>> Dear all,
>> 
>> The YANG coordination team 
>>  
>> has 
>> spent some time reading and gathering input on the requirements and 
>> proposed solutions in draft-openconfig-netmod-opstate. This note is to 
>> collect some observations that will hopefully contribute to progress in 
>> the working group.
>> 
>> We believe it is useful to consider that YANG was initially designed to 
>> be a data modeling language for the NETCONF protocol. IETF is also 
>> working on RESTCONF which is an HTTP-based protocol to access data 
>> defined in YANG, using the datastores defined in NETCONF.
>> 
>> YANG is fulfilling its intended role with NETCONF and RESTCONF and has 
>> gained some significant traction in this capacity. There are some 
>> changes worked on in YANG 1.1, but they are mostly incremental.
>> 
>> There is interest in using other protocols outside of NETCONF and 
>> RESTCONF to manipulate data described by YANG. The proposals in the 
>> draft is based on the assertion that YANG models should be usable for 
>> protocols beyond RESTCONF and NETCONF. So these are new requirements on 
>> YANG from, or in preparation for, new protocol bindings.
>> 
>> We have focused on two main aspects of the draft.
>> 
>> FIRSTLY: The proposed split between intended and applied configuration 
>> as described in sections 4.1 (requirements) and 5.1 (implications)
>> 
>> There are two observations here:
>> 1. The implication is that all configurable data nodes ("intended 
>> configuration") shall be repeated in an operational version ("applied 
>> configuration") in all models for all applications going forward. This 
>> would apply independent of if the system is synchronous or asynchronous 
>> in nature. Synchronous systems would simply hard-wire the applied 
>> configuration to be the same as intended configuration at all times.
>> 2. An informal round of conversations with some vendors as well as some 
>> tooling vendors show that there are currently no widely known platforms 
>> that allow for observing the intended and applied state separately. A 
>> common architecture includes a central configuration data store that is 
>> being updated by the manageability framework and updates read by the 
>> subsystems affected by the change (e.g. the BGP service or the interface 
>> manager). In this case, there is no other source of configuration except 
>> for the content of the data store.
> 
> It may be because vendors tend to limit user access to the device
> configuration to a few official interfaces.

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

> In contrast, consider for example a typical Linux system. No matter what
> "official" configuration system is used (init scripts, NetworkManager,
> UCI in OpenWRT, even NETCONF), there is always a way to change the
> run-time configuration without the official configuration system being
> notified. For instance, one can go to the /proc filesystem and change
> many kernel parameters on the fly, such as IP addresses assigned to
> interfaces.
> 
> Since I am mainly interested in such open systems, I do see a use case
> for making the distinction between intended and applied
> configuration. And by the way, it might help solve the NETCONF/I2RS
> dilemma: NETCONF/RESTCONF would only be allowed to modify intended
> configuration whereas I2RS would operate exclusively on applied
> configuration.

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

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

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

> Finally, most existing NETMOD models in fact already