Hi,
On 14/09/2015 09:31, Ladislav Lhotka wrote:
On 14 Sep 2015, at 10:21, Martin Bjorklund <[email protected]> wrote:
Juergen Schoenwaelder <[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
