I2RS protocol strawman

This documents is a strawman for the I2RS Protocol from early I2RS design team discusses. It focuses on the protocol extensions for ephemeral data store. This draft provides suggests the following additions to support the I2RS ephemeral state: Yang ephemeral statement, NETCONF () protocol extensions for the ephemeral data store, RESTCONF () protocol extensions for the ephemeral data store draft-hares-i2rs-protocol-strawman-examples provides provides examples of this strawman protocol use for I2RS. This draft uses a simple thermostat model to illustrate commands. This draft is input to a NETCONF review and design team.

(dean)What edits are allowed in the ephemeral data store. Should those be syntactically correct or syntacticly and semantically? Validation slows things down a lot, so datastore validation needs to be considered carefully. This is where I think routing expertise will help decide how much validation can really be skipped for a particular use-case. (Anu)On priority: So the priority maximum will be same as the max-clients , if we are assigning unique priorities from 1 – max-clilents. (Eg , if max clients is 100 (leaf max clients , range 1 .. max ) then priority range is also from 1 – max ) So the leaf max-clients { .. range 1- 32 } represents priority information also , so it can be max-clients or max-priorities ?? (Andy)The term 'max' in YANG resolves to 4B-1 in this range, not 32. Actually, the text I sent allows for multiple clients to all have the default priority which is not good -- if client-id is needed to resolve collisions then there is no point to requiring a unique priority per client. (Andy)The priority is not required to be densely numbered. Whether there are 1 pane per client or 1 pane per priority or 1 giant blob full of everything, the code will be the same. The goal of "unique priority" is to require that only priority be saved in the meta-data for the ephemeral datastore. Without that, client-id and priority must be saved (per data node).

Currently the configuration systems managed by NETCONF () or RESTCONF () has three types of configuration: candidate, running, and startup running under the config=true flag. The candidate receives configuration changes from NETCONF/RESTCONF. The running configuration is the configuration currently operating on a devices The start-up configuration is the configuration that survives a reboot. The config=false flag has operational data which exists alongside the config=true data. However, at this point there is no datastored defined for configuration false.

........... ........... ........... :Candidate : --> : running : --> :start-up : ........... ........... ........... config true --------------------------------------------- config false =============== | operational | | data | ================ Figure 1 In reality, the running configuration becomes the intended configuration that is intended to be loaded into a device. The loading process of the intended configuation into a devices compares it against the actual devices and creates the actual configuration loaded into a box. Some people denote the actual configuration as applied configuration. The denotes the actual configuration as derived state. This document will use the term actual configuration.

........... ........... ........... :Candidate : --> : running : --> :start-up : ........... ........... ........... ============= | Intended | | config | ============= config true --------------------------------------------- config false ============= | Actual | | config | ============= ______________ | operational | | data | |______________| Figure 2 Recently the has proposed that intended configuration, actual configuration, and the traditional type of operational data included as operational state. Operational data may include: derived state (e.g. negotiated bgp hold timer) operational state for counters or statistics (interface counters) Again, this document will use the definitions above to discuss ephemeral state until the NETCONF WG agrees upon the changes to the state diagrams.

This section describes the properties of the ephemeral datastore. The ephemeral datastore is not unique to I2RS. This approach to the ephemeral datastore is a panes-of-glass model. This definition of I2RS does not support caching in the I2RS Agents. Future I2RS work may reconsidered supporting caching. The ephemeral data store has the following qualities: Ephemeral state is not unique to I2RS work. The ephemeral datastore is a datastore holds ephemeral configuration information that is intended to not survive a reboot. Configuration information is defined as "config=trude nodes". Ephemeral nodes will be denoted by an "ephemeral config statement in the yang protocol. The ephemeral datastore is never locked. The ephemeral datastore is one pane of glass that overrides the running data store. Each client has a unique priority client identities and priorities are assigned outside of I2RS. Examples of mechanisms are AAA or adminstrative. A valid I2RS client must have both an identity and a priority. A sample container for I2RS client information is shown below.

container i2rs-clients { leaf max-clients { config false; mandatory true; type uint32 { range "1 .. max"; } } list i2rs-client { key name; unique priority; leaf name { ... } leaf priority { ... } } } Figure 3

Error handling is an I2RS protocol features. Normal error handling of I2RS Agent for an I2RS client's information examines the following: syntax of I2RS commands, syntactic validation for nodes of data models, permission to write nodes of data model, grouping, priority to write nodes of data model being higher than existing priority Question of editor: Should grouping be tagged somehow? The specifies three types of error handling for a partial write operation: "all-or-nothing", "stop-on-error", or "continue-on-error". Partial write operations are allowed only for data writes which are not a part of a grouping within a data model. Groupings are defined by data models. The definition of these error conditions are: stop-on-error - means that the configuration process stops when a write to the configuration detects an error due to write conflict. continue-on-error - means the configuration process continues when a write to the configuration detects an error due to write process, and error reports are transmitted back to the client writing the error. all-or-nothing - means that all of the configuration process is correctly applied or no configuration process is applied. (Inherent in all-or-nothing is the concept of checking all changes before applying.) RESTCONF has a complete set of operations per message. The RESTCONF patch can support accesing multiple data messages. NETCONF stop-on-error and continue-on-error are not going to work. There is no mandated processing order for edits. For the stop-on-error and the continue-on-error process to work, the I2RS protocol extensions to NETCONF will have to force some processing order in order to support partial edits. NETCONF has no current mechanism for reporting which edits were accepted and which edits were reject for partial operations. The I2RS protocol extensions will have to provide new error handling to the response data. These features were removed from NETCONF (RFC 6241) because it was too complicated, and no company had implemented these features. Interoperability issues must be considered in all three cases: a) all-or-nothing, b) stop-on-error, and c) continue-on-error.

In this discussion of ephemeral configuration, this draft utilizes a simple thermostat model with the yang configuration found in figure 4.

module thermostat { .. leaf desired-temp { type int32; units "degrees Celsius"; description "The desired temperature"; } leaf actual-temp { type int32; config false; units "degrees Celsius"; description "The measured temperature (operational state)."; } } Figure 4 - Simple thermostat model yabng Figure 5 shows the diagram of the configuration state with the Simple thermostat model being attached to by an I2RS scheduler client receiving query information regarding intended configuration and actual configuration. Scheduler has a schedule set of temperatures to put in the thermostat. Actual temperature is operational state.

........... ............... ........... :Candidate : --> : Desired temp:-->:start-up : ........... ............... ........... | V ============ =========== | Intended |----| I2RS | | config | |scheduler| | | | client | ============ =========== config true ^ ------------------------------- | config false | ============= | | Actual |--------| | config | ============= ______________ | actual temp | | | --------------- Figure 5 - Scheduler client only Figure 6 shows two I2RS clients talking to this model: scheduler and hold-temp. Scheduler has a schedule set of temperatures to put in the thermostat. Hold-temp holds the temperature at the same value. The hold-temp I2RS client has a higher priority than the scheduler client.

........... ............... ........... :Candidate :---: Desired temp : -- :start-up : ........... ............... ........... | | ============= | |I2rs Client| | |scheduler | V / ============ ................../ ephemeral . '''''''''''''''/. ============== datastore . 'desired-temp'---- |I2RS Client | . '''''''''|'''' . | hold temp | . | . ============== . | . ============ . |---------| intended | . . | config | . . ======||==== config true . . || -------------------------------------- || config false || ============= || | Actual |============ | config | ============= ______________ | actual temp | | | ---------------- Figure 6 - Two I2RS clients

Yang needs to add a key word ephemeral that signal the ephemeral datatstore for items in the config true or the config false state.

module thermostat { .. leaf desired-temp { type int32; units "degrees Celsius"; ephemeral true; description "The desired temperature"; ephemeral true; } leaf actual-temp { type int32; config false; units "degrees Celsius"; description "The measured temperature"; } } Figure 8 - Simple Thermostat Yang with ephemeral Figure 6 shows the thermostat model has emphemeral variable desired-temp in the running configuration and the ephemeral data store. The RESTCONF way of addressings is below:

RESTCONF running data store PUT /resconf/data/thermostat:desired-temp {"desired-temp":18} RESTCONF ephemeral datastore PUT /restconf/data/thermostat:desired-temp?datastore=ephemeral {"desired-temp":19 }

capability-name: ephemeral-datastore

This capability defines the NETCONF protocol extensions for the ephemeral state. The ephemeral state has the following features: the ephemeral datastore is a datastore holds configuration that is intended to not survive a reboot. The ephemeral datastore is never locked. Each client has a unique priority. Each client writes into its own pane so there is no conflict within a pane. The implementation combines the panes into the appropriate image. A Partial operation is one where a subset of the written data is not applied because of better priority for that node. A partial operation is only allowed if the error-option is stop-on-error or continue-on-error. Caching is optional and and a server may retain the pain for each client.

The Yang data modules must be flag with the ephemeral data store. The Yang modules must support the notification of write-conflicts.

The ephemeral-datastore capability is identified by the following capability string: (capability uri)

The bulk-write goes here.

The bulk-read goes here.

The phrase "?datastore=ephemeral" following an element will specify the ephemeral data store.

TBD

capability-name: ephemeral-datastore

This capability defines the RESTCONF protocol extensions for the ephemeral state. The ephemeral state has the following features: The ephemeral datastore is a datastore holds ephemeral configuration information that is intended to not survive a reboot. Configuration information is defined as "config=trude nodes". Ephemeral nodes will be denoted by an "ephemeral config statement in the yang protocol. The ephemeral datastore is never locked. The ephemeral datastore is one pane of glass that overrides the running data store. Each I2RS client has a unique priority and a unique identity.

The Yang data modules must be flag with the ephemeral data store. The Yang modules must support the notification of write-conflicts. The Yang modules must support the yang-patch features as specified in .

The ephemeral-datastore capability is identified by the following capability string: (capability uri)

The bulk-write goes here.

The bulk-read goes here.

TBD

The phrase "?datastore=ephemeral" following an element will specify the ephemeral data store.

TBD

This document is an attempt to distill lengthy conversations on the I2RS proto design team from August Here's the list of the I2RS protocol design team members Alia Atlas Andy Bierman Alex Clemm Eric Voit Kent Watsen Jeff Haas Keyur Patel Hari Dean Bogdanavich Anu Nair Juergen Schoenwaelder Kent Watsen