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

[Martin Bjorklund <[e-mail]>]

Robert Wilton <[e-mail]> wrote:
> Hi Martin,
> 
> On 11/09/2015 08:38, Martin Bjorklund wrote:
> > Sam Aldrin <[e-mail]> wrote:
> >>> On Sep 10, 2015, at 4:13 PM, Mahesh Jethanandani
> >>> <[e-mail]> wrote:
> >>>
> >>>
> >>>> On Sep 10, 2015, at 12:43 PM, Carl Moberg (camoberg)
> >>>> <[e-mail] <mailto:[e-mail]>> 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.

Yes this is how ietf-interfaces work.  But the openconfig people want
to change this, and introduce 'applied config' as a simplicifation. I
am / we are trying to understand how they intend this 'applied config'
to work.

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

See above; the four bullets are (my understanding of) what the
openconfig people have said.  I hope they clarify if this is not what
they meant.


/martin


> 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 the derived state
>  - for an interface.
> 
> Cheers,
> Rob
> 
> 
> >
> >
> > /martin
> > _______________________________________________
> > netmod mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netmod
>