SR OS supports the following basic response modes for YANG-modeled operations:
synchronous
This is the default response mode. This mode is supported on MD-CLI and NETCONF.
asynchronous
This mode is supported only on NETCONF.
In synchronous mode, the response to the operation request contains the complete result data and is held until the operation is complete. No additional operations can be initiated in the same management session (MD-CLI or NETCONF) until the previous operation completes. This behavior is evident in MD-CLI, for example, where the MD-CLI prompt does not return and no input is accepted until the currently running operation is completed.
In asynchronous mode, the response to the operation request does not contain the result data and is sent without waiting for the operation to complete. The request only starts the operation and the client (requester) obtains the result later. Users can perform other commands in the management session while the asynchronous operation runs in the background.
The response to an asynchronous operation request contains an operation ID. This ID is a handle for the operation and allows users to:
query the status of the operation
stop or delete the operation
Synchronous operations require a management session (NETCONF or MD-CLI) for each concurrent operation, whereas a single management session can manage hundreds of concurrent asynchronous operations.
Only a subset of SR OS operational commands are supported in the asynchronous response mode. See the SR OS nokia-oper-*.yang files for actions with the ‟asynchronous” leaf as part of the input to identify operations that support asynchronous mode.
The following figure shows a typical flow for an asynchronous operation.
A stopped asynchronous operation (for example, stopped using the stop-operation command) stays in the global operations table until it is explicitly deleted using a delete-operation command or the retention timeout expires. Synchronous operations are automatically removed from the global operations table when they are completed or stopped.
Because of the parallel processing nature of asynchronous operations, it is possible that an operation completes before the original requester of the operation receives a reply to the request. This means a client could receive a notification about an operation ID that the client does not yet know about.