Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Config Subscription gNMI Extension #169

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open

Config Subscription gNMI Extension #169

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
237bce1
config subscription extension init
hellt Jan 30, 2024
b3e3473
added oneof action
hellt Jan 30, 2024
b7c1194
Merge branch 'master' into config-sub
hellt Jul 1, 2024
43170f2
fix server->client for start action
hellt Jul 24, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
38 changes: 33 additions & 5 deletions proto/gnmi_ext/gnmi_ext.proto
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -28,12 +28,13 @@ option go_package = "github.com/openconfig/gnmi/proto/gnmi_ext";
// The Extension message contains a single gNMI extension.
message Extension {
oneof ext {
RegisteredExtension registered_ext = 1; // A registered extension.
RegisteredExtension registered_ext = 1; // A registered extension.
// Well known extensions.
MasterArbitration master_arbitration = 2; // Master arbitration extension.
History history = 3; // History extension.
Commit commit = 4; // Commit confirmed extension.
Depth depth = 5; // Depth extension.
MasterArbitration master_arbitration = 2; // Master arbitration extension.
History history = 3; // History extension.
Commit commit = 4; // Commit confirmed extension.
Depth depth = 5; // Depth extension.
ConfigSubscription config_subscription = 6; // Config Subscription extension.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @robshakir @dplore, all

We would like to resume the discussions around this extension proposal.

After extensive internal use of this extension we find it particularly fit for a common problem in the network management domain -- configuration deviation/drift detection and reconciliation. We believe it might be useful for operators and other gNMI users.

To summarize, ConfigSubscription extension provides the following capabilities that contribute to the config drift detection use case:

  1. An ability to subscribe to configuration only data
    Contrary to Get RPC, Subscribe RPC does not have a toggle to select which category of data nodes to subscribe to (state vs config vs both)
    This is important for gNMI applications that are based on yang models without strict state/config separation of data
  2. A way to identify commit boundaries when subscribed to configuration data.
    The sync_done message allows a client to identify when all changes for a particular commit have been fully sent by the gNMI server. This ensures it is safe to trigger deviation computation without needing to perform a full resync.

These two new capabilities added by this extension to gNMI could (among other use cases) enable a gNMI client to make use of a robust and reactive configuration drift detection/reconciliation mechanism.
When used together, the configuration mananagement system can make use of the streaming nature of gNMI Subscribe RPC to get a rapid deviation detection.

First, it benefits from a lightweight subscription mode when only changes to the configuration datastore elements are being sent as notifications.

And then, by making use of the sync_done message in this extension the system can quickly react to the changes made to the configuration data it is subscribed to.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the use case makes sense, we can probably stop selling it and work out the details :-)

The subscription to config only data is fine -- I would be OK with adding something here to SubscriptionList that says the the data type similarly to Get. We can just make the default state of this as BOTH, which would give a means to be able to be backwards compatible should this field not be specified.

}
}

Expand Down Expand Up @@ -159,3 +160,30 @@ message Depth {
// returned.
uint32 level = 1;
}

// ConfigSubscription extension allows clients to subscribe to configuration
// schema nodes only.
message ConfigSubscription {
oneof action {
// ConfigSubscriptionStart is sent by the client in the SubscribeRequest
ConfigSubscriptionStart start = 1;
// ConfigSubscriptionSyncDone is sent by the server in the SubscribeResponse
ConfigSubscriptionSyncDone sync_done = 2;
}
}

// ConfigSubscriptionStart is used to indicate to a target that for a given set
// of paths in the SubscribeRequest, the client wishes to receive updates
// for the configuration schema nodes only.
message ConfigSubscriptionStart {}

// ConfigSubscriptionSyncDone is sent by the server in the SubscribeResponse
// after all the updates for the configuration schema nodes have been sent.
message ConfigSubscriptionSyncDone {
// ID of a commit confirm operation as assigned by the client
// see Commit Confirm extension for more details.
string commit_confirm_id = 1;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be a oneof between the two values?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The two values can both be present in the same message. The commit_confirm_id is present if the commit is a commit confirmed one.
The server_commit_id is an internal ID to the target. Implementations can leave it empty if no ID is available or simply set it to the commit timestamp.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fwiw, here is a demo that shows how both commit_confirm_id and server_commit_id are both present when commit with confirm is executed

https://youtu.be/MO7_ZYbRT3k?si=ukWgC4H73D8_Nqgy&t=723

// ID of a commit as might be assigned by the server
// when registering a commit operation.
string server_commit_id = 2;
}