>>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?
>>
>
>I think the new wording is an improvement.
I agree and view this as an editorial fix.
>> >>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.
>
>This direction of the relationship might in some cases be a relatively
>trivial and predictable 1:1 relationship, in other cases it may be
>more complex and in the worst case dynamically changing.
It YANG module could support 1:N by having a list of associated derived state
relationships. I don’t get the dynamically changing part, are you saying the
derived state can randomly appear anywhere?
>> (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.
>
>If you can do 'applied config' -> 'associated derived state' then you
>should be able to do 'derived state' -> 'applied config' for 'derived
>state' associated with 'applied config'.
I made this point before as well. Given the forward mapping, a system could
calculate the reverse mapping...
>But yes, I agree that 'derived state' -> 'arbitrary source of derived
>state' is unfortunately unrealistic (in the general case).
>
>BTW, do we have a definition of 'associated derived state'? What is
>the scope of the _associated_ derived state? My interpretation is that
>it is any derived state that is a _direct_ consequence of some applied
>config being active but it does not include any state indirectly
>associated with some applied config. (For example, if I turn on a VPN
>service, then the associated derived state are VPN service counters
>etc. but not lets say interfaces dynamically created via the VPN
>service operation.)
I think your interpretation is acceptable, but do we need to define a term
other than “derived state”?
Derived State: This data represents information which is generated
as part of the server's own interactions. For example, derived
state may consist of the results of protocol interactions (the
negotiated duplex state of an Ethernet link), statistics (such as
message queue depth), or counters (such as packet input or output
bytes).
Separately, the term “derived state” seems poorly named. I know that it is
what the OpenConfig draft called it, but it begs the question as to what the
state is derived from. Thoughts on a better name?
Thanks,
Kent
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
