On Fri, Jan 15, 2016 at 05:01:54PM +0000, Robert Wilton wrote: [...] > 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? >
I think the new wording is an improvement. > > > >>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. > (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'. 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.) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
