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" <r...@rob.sh> wrote:
>
>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-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
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
