Re: [RTGWG] gRPC dial-out, oc-version, data types, draft-openconfig-rtgwg-gnmi-spec-01

[Rob Shakir <[e-mail]>]

Hi Thomas,

On Sun, Sep 23, 2018 at 2:50 AM <[e-mail]> wrote:

> To Rob and co-authors of the gNMI draft,
>
> First of all I want to congratulate on this draft. Speaking for Swisscom,
> from a service provider perspective, Streaming Telemetry is an important
> piece of the Network Telemetry framework. We see with gNMI a big potential
> in replacing SNMP in the long run.
>
> We are looking forward to the next draft and would like to give some input
> regarding gRPC dial-out, openconfig version support and data types.
>

Thanks for the comments. Please note that, as per the content in the draft,
we maintain the authoritative version of the gNMI specification in GitHub
at
https://github.com/openconfig/reference/blob/master/rpc/gnmi/gnmi-specification.md,
rather than as an IETF draft. Changes will initially be published there,
since this work is not being pursued through the IETF.

We are working since a few months with Huawei, Cisco, Juniper and pmacct
> (Paolo Lucente, open source collector daemon) together by using gNMI and
> openconfig YANG models to achieve the goal of an open and vendor
> independent Streaming Telemetry data collection, which integrates into a
> Big Data (message broker and schema registration) architecture.
>
> We understood that the draft-openconfig-rtgwg-gnmi-spec-01 scope is gRPC
> dial-in where in draft-openconfig-rtgwg-gnmi-spec-00 in Appendix B was
> stated that dial-out is on the road map for the next draft.
>
> For the reader it would be beneficial to describe the difference target
> data collection/transport use cases where dial-in vs. dial-out suits the
> best. In particular covering the high availability aspect which we think is
> key for autonomous (closed loop) operation.
>
Carl Lebsack ([e-mail], now CC'd) and I are working on extending gNMI
to meet dial-out use cases. We've talked to operators that are interested
in this in the context of CPE management, as well as within datacentre
environments. One of the things that we're trying to ensure is that we
understand the impact to implementations that need to support both dial-in
and dial-out modes of operation, and how we can make supporting and testing
both implementations as simple as possible. This has benefits to both
implementors (naturally), but also operators since it ensures that the gNMI
implementations that ship are well tested in both modes of operation. To
this end, we're working with the gRPC team to understand the different
options for implementing dial-out. I hope that we'll have an initial
proposal in the next few weeks.

The normal way that such changes get discussed is in a GitHub issue in the
github.com/openconfig/reference repo, prior to being fully merged back into
the specification. If you have interest, I'd encourage you to watch that
repo such that you get some notification of the issue being opened.


> Regarding gNMI data type support
>
>
> https://github.com/openconfig/reference/blob/master/rpc/gnmi/gnmi-specification.md#23-structured-data-types
>
>
> We believe that less would help in better adoption and interoperability.
> We favor JSON_IETF and Proto.
>

There are a couple of reasons that we support more than just these two
encodings today:

   - In gNMI we support the concept of a mixed schema device. This can be
   used to support different models (e.g., vendor native, and OpenConfig), or
   mixed modelled and unmodelled data within the same transaction. The ASCII
   encoding gives us a means to carry this unmodelled data in gNMI. A more
   detailed explanation is in the mixed schema
   <https://github.com/openconfig/reference/blob/master/rpc/gnmi/mixed-schema.md>
addendum
   to the gNMI spec.
   - We support carrying binary-marshalled protobufs directly on the wire
   in gNMI using the bytes type -- the reason not to use proto.Any here is
   that we end up with redundancy on the wire as to what message type is being
   used - since both the path and the type in the Any message give information
   as to how to unmarshal the protobuf contents. This is described in more
   detail in the protobuf value
   <https://github.com/openconfig/reference/blob/master/rpc/gnmi/protobuf-vals.md>
addendum
   to the spec.

So, there are implementation cases where we need to support these different
encodings. However, I do agree that fewer options are better for
interoperability. What we have done at Google is to define a minimum viable
feature specification that we've used with internal and external developers
to describe what must be supported for both configuration management and
streaming telemetry use cases. We've discussed making this a public
specification - if this is something that you'd be interested in commenting
on, that would be interesting. We can take it up off-list if so.

Regarding openconfig version support.
>
> We understood from
>
>
> https://github.com/openconfig/reference/blob/master/rpc/gnmi/gnmi-specification.md#322-the-capabilityresponse-message
>
> and
>
>
> https://github.com/openconfig/reference/blob/master/rpc/gnmi/gnmi-specification.md#261-the-modeldata-message
>
> that the supported data model version can be obtained before metrics are
> sent by a notification message.
>
> Within the notification message, the data model version is missing
> https://github.com/openconfig/reference/blob/master/rpc/gnmi/gnmi-specification.md#21-reusable-notification-message-format
>
>
> This means that the mapping between device and model version has to be
> stored and maintained on the data collection side. This could be simplified
> by sending the data model version also in the notification message.
>

Do you have a concrete example of where this is an issue? At the moment, if
the collector is schema-aware, then it seems like one would need to select
before unmarshalling what the version of the models that are to be used is,
and then this would not change during the lifetime of a Subscribe RPC (or
more likely, until the software version on the device changes). Is there a
case that you have whereby one needs to make a decision more often than
once per connection?

Alternatively, did I misunderstand and the issue here is maintaining state
w.r.t the connection at the collector side?


> The maintenance of the openconfig model version mapping has been
> challenging. Depending on router software upgrades and vendor this can
> change during operation. One of the three mentioned vendors which is
> exposed the longest to this environment, has a quiet big version mapping
> map which outlines where we are heading to. On top, the version information
> is difficult to obtain on
> https://github.com/openconfig/public/tree/master/release/models since it
> is embedded within the description of the openconfig YANG models.
> draft-openconfig-netmod-model-catalog-02.txt is addressing this with the
> right approach and we believe is an important piece of this puzzle.
>

Agreed -- Anees has been working on putting together catalogue entries for
the OpenConfig models. I'll let him comment on current progress and where
we intend to publish those entries. I agree that having this information
available as to what is supported where is an important part of the overall
solution.

Given your interest in both OpenConfig and gNMI, I'd encourage you to
engage directly on the GitHub for both, and consider joining OpenConfig as
an operator member. We're particularly interested in addressing the
implementation challenges for folks that are actually deploying these
technologies. Experience in production environments, inside and outside of
Google, has guided a significant proportion of the features and changes
we've made to both gNMI and OC.

Thanks again for the comments.

Cheers,
r.