Rob, thanks for clarifying the need for 6B. No new GitHub issues filed for this thread.
Kent On 9/14/15, 10:16 AM, "Rob Shakir" <[email protected]> wrote: > >On 14 September 2015 at 08:43:53, Benoit Claise ([email protected]) wrote: > >> Re-reading this section 4.5, I understand 6A and 6C, but is 6B also >> required? >> Do we need to make the link between a config node and all the derived >> counters/statistics it influences, which might be in different YANG >> models btw? > >Yes - we need to deterministically retrieve, for a particular >configuration object (e.g., interface, BGP peer) the set set of derived >state nodes associated with it, such that we do not need to maintain >complex mapping tables on the client side for this - and can efficiently >query the server for them. > >For instance, knowing that we configured a BGP peer at >$SOMEROOT/bgp/neighbors/neighbor[peer-address=Œ192.0.2.1¹]/config/{leaf-se >t} then we would find the counters at >$SOMEROOT/bgp/neighbors/neighbor[peer-address=Œ192.0.2.1¹]/state/ - >allows us to (based on the fact that we just configured a peer) retrieve >the state and counters that a client application will likely want to >check without having to map to some other (set of locations). > >Note that in previous discussions, it was expressed that this implied >that the model had knowledge of how the protocol operates such that it >was known that leaf A corresponding to some other derived-state leaf B. >However, this isn¹t true. As I expressed before, the intention is that it >is possible for a NMS layer to easily retrieve the set of state objects >that an interested client may require, without many disparate queries, >based on the configuration path. The actual meaning may be completely >unknown to this layer. > >The openconfig-opstate approach allows state and config to be defined in >separate modules - since the Œstate¹ module in this case can simply >augment the relevant Œstate¹ containers within the config model. > >Regards, >r. _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
