Hi Martin,
On 11/09/2015 08:38, Martin Bjorklund wrote:
Sam Aldrin <[email protected]> wrote:
On Sep 10, 2015, at 4:13 PM, Mahesh Jethanandani
<[email protected]> wrote:
On Sep 10, 2015, at 12:43 PM, Carl Moberg (camoberg)
<[email protected] <mailto:[email protected]>> 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.
- 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.
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
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
