While working on MPLS LDP yang model
(https://tools.ietf.org/html/draft-raza-mpls-ldp-mldp-yang), we noticed the
possible confusion around structuring intended config, applied config and
derived state *.
On one hand, one may have 'intended-config’ (RW) and ‘applied-config’ (RO) in
the same construct (container), and ‘derived state’ (RO) in a separate
construct (container).
This keeps config together, but doesn’t help operational state, which
requires
Both Applied-config and derived-state.
On the other hand hand, one may have ‘intended-config’ in one construct
(container), and ‘applied-config’ and ‘derived state’ in a separate construct
(container).
This simplifies figuring operational-state, but divides the config
types.
There are pros & cons either way. It would be good to have some guidance/text
around guiding one over another, so that other models can leverage. Otherwise,
we are going to end up with yet one more discrepancy (among various protocols
YANG models), & confusing if not inefficient modeling.
Perhaps, we ditch both of the above approaches, and settle on keeping all three
of them in the same construct. It might simplify the organization a bit. Of
course, that also has 2 options - have all the data types in intended-config,
and then in applied-config and then in derived-state. Or have intended-config,
applied-config and derived-state for each data type. Latter might be slightly
better, given that not every data type will have all three.
Thoughts?
--
Cheers,
Rajiv Asati
Distinguished Engineer, Cisco
* https://tools.ietf.org/html/draft-ietf-netmod-opstate-reqs
<https://tools.ietf.org/html/draft-ietf-netmod-opstate-reqs-04>
https://tools.ietf.org/html/draft-openconfig-netmod-opstate
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
