Support confirmed commit in gNMI SetRequest

[kidiyoor]

A PR https://github.com/openconfig/reference/pull/196 was created with an initial proposal to initiate discussion to add confirmed commit support. From the feedbacks received we have drafted a new proposal, creating this issue to continue discussion on the new proposal.

The proposed proto has a subset of confirmed commit functionality as defined in NETCONF protocol(RFC6241). The proposal has a healthy disregard to few functionality defined in the RFC with the intention that most of the gRPC API clients are going to be automated systems and the proto should facilitate a simpler implementation of client workflows and server implementation.

The server can be viewed as a singleton resource, at any given point in time there can be only one commit active. This commit can be either confirmed or canceled before a new commit can begin. Client is expected to provide full configuration during the commit request, the commit cannot be amended once issued.

With these in mind, below are the two proposals-

Proposal-1

Proto update PR: https://github.com/openconfig/gnmi/pull/155 Reference/README update PR: https://github.com/openconfig/reference/pull/196

message Commit {
  oneof action {
    CommitRequest commit = 1;
    CommitConfirm confirm = 2;
    CommitCancel cancel = 3;
  }
}

Above spec limits the transactions to below three transactions-

1. Allow commit
2. Allow confirm
3. Allow cancel

Note: It doesn’t allow a new commit along with confirmation of previous commit.

Handing of Proposal-1 is explained here.

Alternate discussion options:

Proposal-2

message Commit {
  google.protobuf.Duration rollback_duration = 1;
  string commit_id = 2;
  string confirm_id = 3;
  string cancel_id = 4;
}

Handing of Proposal-2 is explained here.

Allows below transactions-

1. Allow commit
2. Allow confirm
3. Allow cancel
4. Allow confirm + new commit
5. Allow cancel + new commit

Open Questions

1. Is transaction 4. and 5. a valid use-case in current operations practices ?
2. Are there any anticipated use-case for 4. and 5. transactional model ?