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

Team Members Leader - Members ???

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.

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)

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

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

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

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

Profiles Need to determine how profiles interact with the previous diagrams

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

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

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

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 ?

SPLIT LEAVES Openconfig YANG Config in red, State in Pink

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

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

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

Operational vs Config Attributes Y Oper ----- Config Only Oper only Both

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

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