Hi Juergen,
On 11/01/2016 11:26, Juergen Schoenwaelder wrote:
On Mon, Jan 11, 2016 at 11:02:30AM +0000, Robert Wilton wrote:
On 10/01/2016 11:21, Juergen Schoenwaelder wrote:
On Fri, Jan 08, 2016 at 01:46:44PM +0000, Acee Lindem (acee) wrote:
The draft is quite succinct and I’m not sure how you and Juergen do not
agree that there are requirements beyond intended/applied state. Perhaps
you do not agree with them? Refer to requirements 3.(B & C) and 4.(B & C).
For your convenience, I’ve excerpted them below:
3. Separation of the applied configuration and derived state aspects
of operational state; ability to retrieve them independently and
together
A. Be able to retrieve only the applied configuration aspects of
operational state
B. Be able to retrieve only the derived state aspects of
operational state
This is nothing new. See for example section 4.3.3.2 of RFC 6244.
C. Be able to retrieve both the applied configuration and
derived state aspects of operational state together
Did you notice that 3.C talks about 'applied configuration'?
4. Ability to relate configuration with its corresponding
operational state
A. Ability to map intended config nodes to corresponding applied
config nodes
B. Ability to map intended config nodes to associated derived
state nodes
C. The mappings needs to be programmatically consumable
I do not agree that 4.B and 4.C require to broaden the title.
In fact, I wonder why 4.B is useful. If we agree that the applied
config (an extended subset of the intended config) is the configration
that determines what the device is doing, then we likely should have a
mapping of the applied config to associated derived state.
Yes, in essence the relationship is intended config => applied config =>
derived state. So I would say that derived state has a transitive
association with the intended config.
Yes. But applied config might include something that is not intended
config, which would be lost if we map intended config => derived state.
I basically agree. I also wonder whether it wouldn't be better to use
the term "relate/relationships" instead of map/mappings because the way
the text is written at the moment it implies that the binds only need to
go from config to state, but as I think the relationship is really
bijective.
This would be rewording this requirement text from:
4. Ability to relate configuration with its corresponding
operational state
A. Ability to map intended config nodes to corresponding applied
config nodes
B. Ability to map intended config nodes to associated derived
state nodes
C. The mappings needs to be programmatically consumable
to:
4. Ability to relate configuration with its corresponding
operational state
A. Ability to relate intended config nodes with corresponding applied
config nodes
B. Ability to relate applied config nodes with associated derived
state nodes
C. The relationships needs to be programmatically consumable
Are there any other views on whether this requirement text should be
updated?
Personally, I think that the relationship should be expressed in the
reverse direction. I.e. a particular node of derived state should be
allowed to refer back to the config (intended/applied) that is derived
from. This is presumably an implementation detail rather than a
requirement.
Yes, I wrote about this earlier - some several weeks ago. What is
really helpful for a managing system is to know the source of derived
state, be it applied config, be it a routing protocol daemon, be it a
dhcp server, be it a piece of tunneling software, be it an I2RS
agent. So yes, I agree with you that the reverse direction is
desirable (e.g., have meta data for derived state that explains where
the state if originating from). What I also explained back then is
that a standard Linux kernel does not track this context for many
resources, which makes this somewhat difficult (= expensive) to
implement. But yes, from a management point perspective, knowing the
source of derived state is truly helpful in my experience.
There seem to be two separate angles to this:
(1) Allowing the schema to express the relationship between derived
state and config nodes. This effectively allows the operator to know
that if they change a particular config item, which derived state fields
they may want to check to ensure that the config change has been enacted
correctly. My understanding is that this is what the requirements in
section 4 of the requirements draft are addressing.
(2) Optional meta-data annotations to the derived state that indicates
for a specific node in the data tree what is/are the sources for that
nodes existence/value. I agree that this does seem useful, but my hunch
is that very few systems would be able to track or provide this
information today. My naive impression is that this would be more
difficult for system vendors to implement than the applied configuration
nodes.
Thanks,
Rob
However, I'm not sure that we actually need to change the text, I think
that the requirement text is probably sufficiently clear to compare
solutions.
Perhaps. I just wanted to point out in my email that even 4.B involves
applied config if done right and hence the document really is grounded
on the distinction of applied config and intended config.
/js
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
