On 2016-18-01 10:47, "netmod on behalf of Robert Wilton" <netmod-boun...@ietf.org on behalf of rwil...@cisco.com> wrote:
> > >On 16/01/2016 10:39, Juergen Schoenwaelder wrote: >> On Fri, Jan 15, 2016 at 11:15:47PM +0000, Kent Watsen wrote: >>>> 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? >>> >> It all boils down to the definition of 'associated derived state'... >> >>>> 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? >I think that it is meant to be state derived from particular >configuration nodes. To me the term Œderived state¹ looks good enough as it makes it clear that the state is captured (derived) from a set of sources where applied config is only one of them. If it comes to ¹associated derived state¹ the example above could provide clarity to the reader. Tagging from where state is derived appears a bit impractical to me, as there are often many sources and even sequences determining dynamic state. > > >> The way I personally think about the various things and terms right >> now is roughly as follows (warning ascii art): >> >> +-----------------+ >> | intended config | >> +--------v--------+ >> | >> +-----------|-----------------------------------------------+ >> | | (1) operational state | >> | v | >> | +-------------------------------------------+ | >> | | applied config (static operational state) | | >> | +---------------v---------------------------+ | >> | | | >> | +---------------|------------------------------------+ | >> | | | (2) dynamic operational state | | >> | | v | | >> | | - directly derived from applied config | | >> | | | | >> | | - provided by the system (system controlled) | | >> | | | | >> | | - obtained internally from system operation | | >> | | | | >> | | - obtained from interactions with other systems | | >> | | | | >> | +----------------------------------------------------+ | >> +-----------------------------------------------------------+ >> >> It is difficult to find good and crisp terms for all of these little >> different elements of dynamic operational state. >I broadly agree with your diagram. I don't think that applied config is >truly static through, it could still change if say a linecard was pulled >out (or failed). To me the diagram looks good. As discussed in other emails, an exchange of HW would have to be reflected in applied config, as it describes the static state of the server and HW is certainly Œapplied¹. > >> I think the scope of requirement 4.B should be limited to (2) in the >> figure above. For me, it does not make sense to tag stuff only >> indirectly related to a config object as derived from it since this >> would quickly get huge and then start to defeat its purpose. > >Yes, I think that this is probably right. +1 > > >> >> Conerning requirement 4, I would be very happy if I could get metadata >> telling me >> >> - this dynamic operational state has been directly derived from >> that part of applied config (e.g, this state interface exists >> because it was configured over there) >> >> - this dynamic operational state has been provided by the system and >> is system controlled (e.g., an interface not yet configured put >> part of the system's hardware) >> >> - this dynamic operational state has been obtained by system operation >> (e.g., interface counters, certain interface parameters discovered >> via auto-negotiation via cable or signal properties) >> >> - this dynamic operational state has been obtained from protocol >> interactions with other systems (e.g., IP addresses obtained via >> SLAAC or DHCP, interfaces created from a VPN service, ...), ideally >> with an indication which mechanism was used >> >> There are still borderline cases where the above classification may be >> debatable (and this is likely unavoidable). The guiding principle I >> would use to take a decision is the question: "What is directly >> responsible for the dynamic operational state to exist?" > >As I understand it, what you are proposing here is not what the section >4 requirements were intended to express. > >The section 4 requirements are meant to be at the YANG schema level, >i.e. illustrating possible relationships between YANG schema nodes. E.g. >for a particular interface IP address they wouldn't be able to indicate >whether it was actually configured by explicit IP address configuration >or due to DHCP. They would only be able to tell which configurations >nodes could influence a particular derived state node. > >I think that there are a couple of cases where this relationship is >useful: >(1) If you modify a config node, it allows the client to know (in >advance) which derived state nodes may be affected and hence should be >retrieved to confirm the change. >(2) Conversely, if a derived state note has an unexpected value, it >allows a client to know which configuration nodes it should retrieve to >try and infer what the cause of the value is. > > >If I understand your proposal, then what you are proposing is meta-data >annotations of the derived state nodes in the data tree. I.e. the >annotations would allow you to tell you whether a particular interface >IP address had that value due to explicit IP address configuration or >because it was allocated by DHCP. I agree that this is useful, but I >think that it is very hard to implement (on the systems that I'm >familiar with) and is also beyond the requirement as originally stated >by the opstate requirements draft. > >As such, I think that we should restrict the scope of the requirements >draft (and proposed solutions) to YANG schema level annotations that are >easier to solve. If you agree, then do we need to tweak the text of >requirement 4 to make this explicit? I have doubts on both options discussed. What Juergen proposes appears to be useful for debugging purposes. Today that state change information is usually found in log files. It¹s certainly not a perfect implementation given the zillion of entries and accelerated wrapping of ring buffers, but something is there. That said, it appears to me that pulling it into the YANG schema will burden the implementation, certainly the performance of operations quite a bit. I would be inclined to accept such a proposal as an optional extension, but not so much as a requirement. (and agree with Rob that it is not so easy to implement). On the other hand, trying to identify derived state that is *possibly* affected by a config appears to me a quite ambitious. 1) If for example a line card is supposed to be put into a state Œdown¹, there is probably a ton of derived state to be affected. What would a client do with all that data other than concluding it is traffic affecting? 2) The second issue is the completeness of that information. Depending on other state information, state change of e.g. a HW item on a server may either bring the whole server down, or just parts of it. Always indicating the worst case would probably render lots of actions "potentially catastrophic² and the amount of data to link to operational state will grow quite big. It doesn¹t appear to me that a client can do a lot to digest this data other than picking few parameters and trying to monitor them. Whether this is an adequate method to monitor the progress of a complex state change is anyones guess. 3) When limiting relationship information to what usually is affected, it would require some very educated guess, by whoever implements the schema over what a client may see as important. Over time, everyone wants to be on the safe side and we'll end up in 2) On that ground I would prefer stay with requirement 4 as it is now, without narrowing down a certain solution. > >Rob > > >> /js >> > >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
