p4lang / p4runtime

Specification documents for the P4Runtime control-plane API
Apache License 2.0
147 stars 88 forks source link

Consider adding Capabilities RPC for P4Runtime v1.1.0 #249

Closed antoninbas closed 5 years ago

antoninbas commented 5 years ago

Similar to the one in gNMI: https://github.com/openconfig/gnmi/blob/master/proto/gnmi/gnmi.proto#L49

This would enable a P4Runtime client to determine which version is currently supported by the server for a given major version number.

service P4Runtime {
  // ...
  rpc Capabilities(CapabilitiesRequest) returns CapabilitiesResponse;
}

message CapabilityRequest { }

message CapabilitiesResponse {
  string semver = 1;
  // potentially other fields in the future
}

Moving forward this would enable the client to determine whether some features introduced by minor version releases are actually supported by the server.

In the future the Capabilities RPC could be useful to provide additional information to the client. See https://github.com/p4lang/p4runtime/issues/213.

The earlier this RPC is added (even in a very simple form as proposed above), the better. Otherwise it doesn't provide a reliable mechanism for the client to determine the P4Runtime version supported by the server, since the RPC itself may not be supported by the service (in which case the client would get an UNIMPLEMENTED error). This is why I would be in favor of adding this RPC in the upcoming 1.1.0 release.

Thoughts?

chrispsommers commented 5 years ago

I'm in favor and agree that the sooner we do this the better. I think the most general-purpose way to enhance this further is to include a map <string, string> properties = 2; whose usage can be defined over time by simple convention, i.e. defining "standard" properties. There I go with the kv-pairs again. :)