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

Hi,

On 14/09/2015 09:31, Ladislav Lhotka wrote:
>> On 14 Sep 2015, at 10:21, Martin Bjorklund <mbj@tail-f.com> wrote:
>>
>> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> 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 <get-config> 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