Iterate on the payload generation for gSII.

[robshakir]

This PR makes an initial proposal for how the payload of gSII RPCs should look.

There are two cases that I think we need to consider:

• state that is part of an existing OpenConfig model
• protos that are generated for a subset of some other schema

For the OpenConfig case, ideally we would not generate new schemas, and be able to re-use existing schema components (and thus want to be able to write these components in YANG). This requires minor extension of the ygot toolchain to generate protobufs (see openconfig/ygot@master...volatile where this change is made). The protos that are included herein use this approach.

The alternative is just to have hand-crafted protos as payload -- but this seems like it would be error prone in some cases.

The PR contains two generated protos:

• One that allows for interface admin status to be manipulated.
• A second that allows for QoS 1r2c policers to have their PIR manipulated.

[brianneville]

(prefacing this by saying i dont know much about yang-protobuf generation)

is it intended that some field numbers increase monotonically while others are generated as the FNV hash of the schemapath (via https://github.com/openconfig/ygot/blob/100bd44fc21215ffcc4862f37d90f7c257b5fa2b/protogen/protogen.go#L1058)?
This seems to affect the fields in messages which are declared inside other messages, and differs from the way that protobuf generation is done for something like hercules (https://github.com/openconfig/hercules/blob/ca3575e85500fa089dfe0b8cd3ea71943267102e/proto/openconfig/openconfig_interfaces/openconfig_interfaces.proto#L37)

[robshakir]

It is intended. YANG lists are generated as repeated <message> fields. Where <message> is a generated message of the form:

message FooKey {
  string key_one = 1;
  string key_two = 2;
  ...
  string key_fourty = 40;
  Foo foo = 41;
}

Where Foo is the actual "member" of the list, and each of the monotonically increasing fields are the keys in the YANG list's key statement. Since these are stably ordered by the YANG schema itself we can save ourselves a few bytes and just give them a number.

For all other fields within a list or container, we don't have a stable numbering -- so we calculate the field ID using a fnv hash. We published something as to why this was reasonable here.

[brianneville]

cool, sounds good!
thanks for linking that doc

[brianneville]

This change adds entries under volatile paths - can the motivation.md doc be updated to reflect this name if it has been finalized?
right now the motivation.md doc makes references to dynamic paths, see:
https://github.com/openconfig/gsii/blob/606a993/docs/motivation.md#data-modelling

[robshakir]

This change adds entries under volatile paths - can the motivation.md doc be updated to reflect this name if it has been finalized? right now the motivation.md doc makes references to dynamic paths, see: https://github.com/openconfig/gsii/blob/606a993/docs/motivation.md#data-modelling

Yes -- #1 covers this change within the motivation.md doc. I'll also put together a more succinct specification document once the design becomes more stable. I'm working on a reference implementation to make sure that we understand some of the nuances over at gSIIgo.

[brianneville]

Yes -- #1 covers this change within the motivation.md doc. I'll also put together a more succinct specification document once the design becomes more stable. I'm working on a reference implementation to make sure that we understand some of the nuances over at gSIIgo.

ack - thanks for including that in #1.
Is gSIIgo going to be made public when completed?