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

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