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. 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. We chose gRPC dial-out with anycast & BFD (https://tools.ietf.org/html/rfc5883) for load distribution and high availability. We have good experience from IPFIX (UDP) and BMP (TCP) with this setup and are happy with the simplicity in network integration and scalability. 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. 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. 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. Kind regards Thomas Graf ____________________________________________________________________________ Network Engineer Tribe IT Clouds Telefon +41-58-223 84 01 Mobile +41-79-728 80 12 [email protected]<mailto:[email protected]> ____________________________________________________________________________ Swisscom (Schweiz) AG IT, Network & Infrastructure Tribe IT Clouds Binzring 17 8045 Zürich www.swisscom.com Postadresse: Binzring 17 8045 Zürich
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
