1. Task 62 Scope – Config / Operational State
Purpose – To agree upon our preferred representation of Config vs Operational Data
Specifically – To determine the UML constructs to be used
Includes –
Excludes – none
External Dependencies – none
Assumptions – none
Risks – none

2. Team Members
Leader - Members
???

3. IPR Declaration Is there any IPR associated with this presentation NO
NOTICE: This contribution has been prepared to assist the ONF. This document is offered to the ONF as a basis for discussion and is not a binding proposal on Cisco or any other company. The requirements are subject to change in form and numerical value after more study. Cisco specifically reserves the right to add to, amend, or withdraw statements contained herein.
THE INFORMATION HEREIN IS PROVIDED “AS IS,” WITHOUT ANY WARRANTIES OR REPRESENTATIONS, EXPRESS, IMPLIED OR STATUTORY, INCLUDING WITHOUT LIMITATION, WARRANTIES OF NONINFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

4. Admin & Operational State
Running Config Scratchpad value
The value used for all network operations. This is the latest of the startup value, the last configured value and any non-configured update {protocol or profile}. (in non-volatile storage)
Operational value
The last configured value (in volatile storage)
Running Config value
Startup Config value
The value that will be set on restart. (in non-volatile storage)

5. Admin & Operational State - Device Bootup
Running Config Scratchpad value
Operational value
Running Config value
Startup Config value 19

6. Admin & Operational State – Change config
Running Config Scratchpad value 22
Operational value 6
Running Config value 10
Copy running-config startup-config
Startup Config value 19

7. Admin & Operational State – operational value change
Running Config Scratchpad value 22
Operational value 6
Dynamic protocol or applying Profile
Running Config value 10
Admin value
Compare this to an ACID transactional database ! – commit (scratchpad + committed value)
Startup Config value 19

8. Admin & Operational State – Event Version
Running Config Scratchpad value
Operational value 2 3 5 3
Events 1 – startup config loaded
2 – config value changed
3 – scratchpad committed
4 – config saved
5 – operational value changed
Running Config value 1 1 4
Startup Config value
Note there is no way to copy operational value to the config values

9. Profiles
Need to determine how profiles interact with the previous diagrams

10. Operational and Config Data in Yang
Yang originally had top level separation of config and operational (twin trees) – a big issue was the key duplication – the primary key attributes need to be consistent in both trees
Yang then moved to separate datastores (NMDA)
Another option would have been separation of operational and config at the bottom of the tree (under the same key) similar to Openconfig YANG
Need to also consider applied profile value in a consistent way

11. Netconf datastores pre-NMDA (RFC 6421)
SPLIT TOP LEVEL TREES
IETF YANG in each module splits into 2 separate trees at the top – this limits where / how you can augment
Netconf datastores pre-NMDA (RFC 6421)
| <candidate> | | <startup> |
| (ct, rw) |< >| (ct, rw) |
| |
| | | |
| |
>| <running> |<
| (ct, rw) | | v
operational state <--- control plane
(cf, ro)
ct = config true; cf = config false
rw = read-write; ro = read-only
boxes denote datastores
Figure 1
3 config values

12. Netconf datastores pre-NMDA (RFC 6421)
Separate Config and State augmentation

13. Netconf NMDA (RFC 8342) The same YANG is used for all Datastores ?
SEPARATE DATASTORES
| <candidate> | | <startup> |
| (ct, rw) |< >| (ct, rw) |
| |
| | | |
| |
>| <running> |<
| (ct, rw) | |
| // configuration transformations,
| // e.g., removal of nodes marked as
| // "inactive", expansion of
| // templates v
| <intended> | // subject to validation
| (ct, ro) |
| // changes applied, subject to
| // local factors, e.g., missing
| // resources, delays
dynamic | learned configuration
configuration | system configuration
datastores | default configuration
| | |
v v v
| <operational> | <-- system state
| (ct + cf, ro) |
ct = config true; cf = config false
rw = read-write; ro = read-only
boxes denote named datastores
Netconf NMDA (RFC 8342)
The same YANG is used for all Datastores ?
Could we add applied profile values in another datastore ?
What about default values, why not a datastore for them ?

14. SPLIT LEAVES
Openconfig YANG
Config in red, State in Pink

15. Openconfig YANG Keys the key definition is a leafref down the tree
Note the duplication of attributes into both Config & State including the id

16. Wrappered Primitives COMBINED ATTRIBUTES
This is also where <<Generics>> could be useful
Rather than creating these datatypes per primitive type
Or do via <<Profilable>> <<Configurable>>
Or do via <<Configurable>>
Or do via <<Profilable>>
Note that <<Union>> is not useful here

17. Config vs Operational Options
Model Impact
Efficiency of aggregating
Comments
Separate Datastores
Simpler model
Easy to find the associated value (same path, match on key).
Could map to a single database by adding ‘datastore’ to every key. Not all values make sense for every datastore.
Separate Trees
Complex model
Could be hard to find the associated value
YANG trees can become inconsistent.
Separate Leaves
Easier to find the associated value
Less likely to become inconsistent.
Combined Attributes
Needs UML profile + generator support

18. Operational vs Config AttributesY
Oper
-----
Config Only
Oper only
Both

19. Shearing Layers http://www.laputan.org/mud/mud.html#ShearingLayers
“Different artifacts change at different rates. Therefore, factor your system so that artifacts that change at similar rates are together.” “This is "separate that which changes from that which doesn't" [Roberts & Johnson 1998] writ large.”
Counters and operational values tend to change more frequently than config values, so there should be an efficient way to retrieve counter and state values separately
Specification values will also rarely change

20. Event Driven / Telemetry Impact
Events shouldn’t mix slow and fast moving attributes
Similar to NMDA, a single event definition could be used for Config and State, with a flag indicating which it is