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

Hi Andy,

On 11/09/2015 17:42, Andy Bierman wrote:
>
>
> On Fri, Sep 11, 2015 at 12:38 AM, Martin Bjorklund <mbj@tail-f.com 
> <mailto:mbj@tail-f.com>> wrote:
>
>     Sam Aldrin <aldrin.ietf@gmail.com <mailto:aldrin.ietf@gmail.com>>
>     wrote:
>     >
>     > > On Sep 10, 2015, at 4:13 PM, Mahesh Jethanandani
>     > > <mjethanandani@gmail.com <mailto:mjethanandani@gmail.com>> wrote:
>     > >
>     > >
>     > >> On Sep 10, 2015, at 12:43 PM, Carl Moberg (camoberg)
>     > >> <camoberg@cisco.com <mailto:camoberg@cisco.com>
>     <mailto:camoberg@cisco.com <mailto:camoberg@cisco.com>>> 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?

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

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

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

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

Thanks,
Rob

>
>
>     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 <mailto:netmod@ietf.org>
>     https://www.ietf.org/mailman/listinfo/netmod
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod