Thanks Rob, that clarifies the situation for me.
Regards, Benoit
On 14 September 2015 at 08:43:53, Benoit Claise (bcla...@cisco.com) 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-set}
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
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
