idnits 2.17.1 draft-talwar-rtgwg-grpc-use-cases-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 17, 2017) is 2654 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group V. Talwar 3 Internet-Draft J. Kolhe 4 Intended status: Informational A. Shaikh 5 Expires: July 21, 2017 Google 6 J. George 7 Cisco 8 January 17, 2017 10 Use cases for gRPC in network management 11 draft-talwar-rtgwg-grpc-use-cases-01 13 Abstract 15 gRPC is an open, high-performance RPC framework designed for 16 efficient low-latency cross-service communications. This document 17 describes use cases for gRPC in network management and other 18 services, particularly streaming telemetry. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on July 21, 2017. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. gRPC use cases . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.1. Network management . . . . . . . . . . . . . . . . . . . 3 57 2.1.1. Streaming telemetry motivation and overview . . . . . 3 58 2.1.2. Streaming telemetry with gRPC . . . . . . . . . . . . 5 59 2.1.3. Network configuration management . . . . . . . . . . 5 60 2.2. Additional use cases . . . . . . . . . . . . . . . . . . 6 61 2.2.1. Client Libraries for connecting polyglot systems . . 6 62 2.2.2. MicroServices . . . . . . . . . . . . . . . . . . . . 6 63 2.2.3. Browser and mobile applications communicating to gRPC 64 Services . . . . . . . . . . . . . . . . . . . . . . 6 65 2.2.4. High performance access to Cloud Services . . . . . . 6 66 2.2.5. Secure and low overhead communications in embedded 67 systems . . . . . . . . . . . . . . . . . . . . . . . 6 68 2.2.6. Unified inter-process and remote communication . . . 7 69 3. Security Considerations . . . . . . . . . . . . . . . . . . . 7 70 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 71 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 5.1. Normative references . . . . . . . . . . . . . . . . . . 7 73 5.2. Informative references . . . . . . . . . . . . . . . . . 8 74 Appendix A. Change summary . . . . . . . . . . . . . . . . . . . 9 75 A.1. Changes between revisions -00 and -01 . . . . . . . . . . 9 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 78 1. Introduction 80 gRPC is a high performance universal RPC framework to connect 81 distributed systems [GRPC-WWW]. gRPC emerged from an internal Google 82 framework called Stubby which has been used to connect large numbers 83 microservices running within and across data centers for over a 84 decade. Having a uniform, cross-platform RPC infrastructure allowed 85 Google to deploy fleet-wide improvements in efficiency, security, 86 reliability and behavioral analysis critical to supporting the 87 incredible growth of these services. gRPC is the next generation of 88 Stubby, built in the open originally for services, as well as last 89 mile computing use cases like mobile, browser, IOT [GRPC-DESIGN]. It 90 is based on standards like HTTP/2 [RFC7540] and is extensible and 91 pluggable by design. 93 This document describes use cases for the gRPC protocol 94 [I-D.kumar-rtgwg-grpc-protocol] in network management, including 95 monitoring, configuration management and programmatic operations. We 96 also summarize a number of additional use cases where gRPC is 97 currently being applied. 99 2. gRPC use cases 101 2.1. Network management 103 Below we discuss several gRPC applications related to network 104 management with a focus on monitoring and telemetry. gRPC is already 105 implemented by several network device vendors as a primary transport 106 for monitoring data based on the streaming telemetry paradigm. 108 2.1.1. Streaming telemetry motivation and overview 110 Network operations depend fundamentally on the availability of 111 accurate, near real-time data to drive a variety of management 112 systems, including traffic control systems, fault recovery systems, 113 and demand and capacity forecasting systems. This data consists of 114 information about the control plane (e.g., protocol operations), 115 management plane (e.g., system availability, statistics, and 116 counters), and data plane (e.g., packet and flow statistics). 118 In addition to the variety of data, the volume of monitoring and 119 management data continues to increase significantly. Modern, high- 120 density platforms with thousands of interfaces and numerous hardware 121 and software modules means potentially collecting millions of objects 122 and running tens of thousands of CLI commands every few minutes in a 123 large-scale network. Network monitoring data is increasingly used to 124 manage mission-critical systems such as real-time monitoring, 125 centralized traffic engineering, server selection and load balancing. 126 Hence it requires efficient, secure, and scalable mechanisms for data 127 transport, encoding, and control. 129 Most networks rely on traditional management protocols such as SNMP 130 [RFC1157] [RFC3410] for collecting monitoring data about the control 131 and management planes, and SFLOW [RFC3176] or IPFIX [RFC7011] for the 132 data plane. For control and management data in particular, SNMP is 133 the primary tool, despite limitations which make it ill-suited for 134 modern, large-scale networks, especially Web- and Internet-scale 135 backbones, and large, high-capacity data center networks. 137 While SNMP is widely deployed and implemented in a variety of network 138 environment, it suffers from a number of drawbacks: 140 o legacy implementations -- designed for devices with limited memory 141 and little processing power; e.g., SNMPv2 supports multiple data 142 items in a message, but is not optimized for high-volume data 143 collection 145 o lack of discoverability -- discovering new elements requires 146 walking the SNMP MIB periodically; on high-density platforms this 147 is extremely computationally expensive 149 o lack of capability advertisements -- each object ID must be 150 checked to know whether it is supported by the target platform 152 o rigid data structures -- whether using standard or vendor 153 proprietary MIBs, the structure and format of the data cannot be 154 easily extended or augmented 156 To address these drawbacks, a number of network operators proposed a 157 new approach for network monitoring based on streaming telemetry (see 158 an early proposal in [I-D.swhyte-i2rs-data-collection-system]). 159 Streaming telemetry is based on a pub/sub push model in which target 160 devices send data of interest over a streaming channel to a data 161 collection system. 163 Some notable features of a streaming telemetry system include: 165 o targets stream data continuously based on a specified period (or 166 as frequently as the target supports), or on a state change 168 o data is sent as soon as it is available, reducing the need to 169 buffer, or to handle a single large for all data at once 171 o data may be sent incrementally, e.g., only for those data items 172 that have changed 174 o ability to distribute the telemetry sources (e.g., directly to 175 linecards) to avoid burdening the management CPU 177 o users issue subscription requests via RPC to the target to request 178 only the data of interest 180 o data is exported in a well-structured, common format, e.g., based 181 on YANG models of operational state data 182 [I-D.openconfig-netmod-opstate] 184 o the target and collector communicate over a secure, authenticated, 185 reliable channel that is long-lived and efficient 187 Streaming telemetry allows the network behavior to be observed 188 through a time-series data stream. This is in contrast to the 189 polling mechanism used in SNMP in which a monitoring client must 190 periodically request the set of desired data, and walk the MIB to 191 discover changes. The polling frequency is limited since the device 192 must be able to handle large requests for all interface or QoS 193 counters, for example. 195 Open source implementations of streaming telemetry are currently 196 being developed by several network vendors, including adapters to 197 deliver data into time-series databases, messaging systems, and data 198 visualization systems [ST-CISCO] [ST-JUNIPER] [ST-ARISTA]. 200 2.1.2. Streaming telemetry with gRPC 202 gRPC provides a number of capabilities that makes it well-suited for 203 network telemetry. Since its underlying transport is based on 204 HTTP/2, it can exploit several key features: 206 o binary framing and header compression -- highly efficient encoding 207 on the wire to enable bulk data transfer 209 o bidirectional streaming RPCs -- the target and collector can 210 stream their data independently, and leverage application-level 211 flow control 213 o flexible data encoding -- gRPC is payload agnostic, and can be 214 used to transfer data encoded as XML, JSON, protocol buffer, or 215 Thrift; as new data formats and encodings emerge for network data, 216 the RPC layer can be easily adapted 218 o multi-language support -- open source gRPC IDLs are available for 219 10 programming languages, and service endpoints can be created on 220 a number of operating systems, giving device vendors flexibility 221 in implementation 223 gRPC-based telemetry stacks are now being implemented with some 224 available as open source [ST-ARISTA]. A protocol specification for 225 streaming telemetry based on gRPC is also available [GNMI-SPEC]. 227 2.1.3. Network configuration management 229 gRPC offers a non-proprietary, modern alternative to vendor-specific 230 configuration protocols or standards such as NETCONF [RFC6241] or TL1 231 [TL1]. Some of the benefits of using gRPC for configuration 232 management include more flexible data encodings (e.g., no requirement 233 to use XML), easier integration based on the large number of language 234 implementations available, and more options for securing connections. 236 Several platforms now support gRPC configuration protocols using data 237 based on YANG models [GRPC-CISCO] [GRPC-JUNIPER]. 239 2.2. Additional use cases 241 2.2.1. Client Libraries for connecting polyglot systems 243 gRPC generates client libraries in 10 languages and thus allows 244 developers to operate in their language of choice and system to 245 communicate with any other system. These libraries offer idiomatic- 246 to-language API surface such that every developer feels they are in 247 their language native environment. 249 2.2.2. MicroServices 251 Designed as a general, high performance protocol to interconnect 252 polyglot systems, gRPC is ideal for microservices communication, 253 independent of where the services are deployed. A protocol that 254 offers flow control, bidirectional streaming and a very compact 255 serialization mechanism is ideally suited for connecting 256 microservices at scale. It is already being adopted by large 257 organizations like Square and Netflix for their microservices 258 communications. 260 2.2.3. Browser and mobile applications communicating to gRPC Services 262 Mobile and Browser applications are becoming feature rich and more 263 demanding by the day. User expectation is that apps are performant 264 in various network conditions and drain minimal battery and computing 265 power of device. gRPC provides native iOS and Android Java libraries 266 for more efficient communication for applications with backend 267 services such that battery, data are efficiently used and developers 268 have more control of communication with servers using gRPC APIs. 270 2.2.4. High performance access to Cloud Services 272 The expectations from high request-rate cloud services like storage 273 and pub/sub messaging systems are to be very efficient and low cost 274 from a compute and networking point of view. Hence, gRPC based APIs 275 are being used for services like Google Cloud BigTable and Google 276 Cloud PubSub. External products like etcd (underlying storage system 277 for kubernetes) also relies on gRPC. 279 2.2.5. Secure and low overhead communications in embedded systems 281 With its integrated authentication model and a IDL like nano- 282 protobuf, gRPC could be ideal for secure device-to-device and device- 283 to-cloud communication as well. This use case is still under 284 development. 286 2.2.6. Unified inter-process and remote communication 288 gRPC can provide a unified programming model for both inter-process 289 communication and remote service communication. This use case is 290 still under development. 292 3. Security Considerations 294 As applied to network configuration and monitoring, any transport 295 protocol and RPC framework must have support for secure, 296 authenticated communication. gRPC supports a number of security 297 mechanisms that are suitable for use in network management, including 298 TLS-based transport, and client and server authentication. These 299 will be detailed further in subsequent drafts. 301 4. IANA Considerations 303 None at this time. In the future, there may be proposals to 304 designate specific application ports for gRPC-based telemetry and 305 configuration traffic. 307 5. References 309 5.1. Normative references 311 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, 312 "Simple Network Management Protocol (SNMP)", RFC 1157, DOI 313 10.17487/RFC1157, May 1990, 314 . 316 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 317 "Introduction and Applicability Statements for Internet- 318 Standard Management Framework", RFC 3410, DOI 10.17487/ 319 RFC3410, December 2002, 320 . 322 [RFC3176] Phaal, P., Panchen, S., and N. McKee, "InMon Corporation's 323 sFlow: A Method for Monitoring Traffic in Switched and 324 Routed Networks", RFC 3176, DOI 10.17487/RFC3176, 325 September 2001, . 327 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 328 "Specification of the IP Flow Information Export (IPFIX) 329 Protocol for the Exchange of Flow Information", STD 77, 330 RFC 7011, DOI 10.17487/RFC7011, September 2013, 331 . 333 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 334 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 335 10.17487/RFC7540, May 2015, 336 . 338 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 339 and A. Bierman, Ed., "Network Configuration Protocol 340 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 341 . 343 5.2. Informative references 345 [GRPC-DESIGN] 346 Ryan, L., "gRPC Motivation and Design Principles", 347 September 2015, . 349 [GRPC-WWW] 350 "gRPC Web site (grpc.io)", September 2015, 351 . 353 [ST-ARISTA] 354 "Arista Networks goarista GitHub repository", July 2016, 355 . 357 [ST-CISCO] 358 "Cisco Systems bigmuddy GitHub repository", April 2016, 359 . 362 [GRPC-CISCO] 363 "Cisco Systems grpc GitHub repository", February 2016, 364 . 366 [ST-JUNIPER] 367 "Juniper Networks open-nti GitHub repository", July 2016, 368 . 370 [GRPC-JUNIPER] 371 Juniper Networks, "Next-Generation Network Configuration 372 and Management", May 2016, 373 . 376 [GNMI-SPEC] 377 Borman, P., Hines, M., Lebsack, C., Morrow, C., Shaikh, 378 A., and R. Shakir, "gRPC Network Management Interface", 379 November 2016, 380 . 383 [TL1] Telcordia, "GR-831-CORE - Operations Application Messages 384 - Language for Operations Application Messages", November 385 1996, . 388 [I-D.kumar-rtgwg-grpc-protocol] 389 Kumar, A., Kolhe, J., Ghemawat, S., and L. Ryan, "gRPC 390 Protocol", kumar-rtgwg-grpc-protocol-00 (work in 391 progress), July 2016. 393 [I-D.swhyte-i2rs-data-collection-system] 394 Whyte, S., Hines, M., and W. Kumari, "Bulk Network Data 395 Collection System", draft-swhyte-i2rs-data-collection- 396 system-00 (work in progress), October 2013. 398 [I-D.openconfig-netmod-opstate] 399 Shakir, R., Shaikh, A., and M. Hines, "Consistent Modeling 400 of Operational State Data in YANG", draft-openconfig- 401 netmod-opstate-01 (work in progress), July 2015. 403 Appendix A. Change summary 405 A.1. Changes between revisions -00 and -01 407 o Added reference to gRPC Network Management Interface 408 specification. 410 o Updated author contact information. 412 Authors' Addresses 414 Varun Talwar 415 Google 416 1600 Amphitheatre Pkwy 417 Mountain View, CA 94043 418 US 420 Email: varuntalwar@google.com 421 Jayant Kolhe 422 Google 423 1600 Amphitheatre Pkwy 424 Mountain View, CA 94043 425 US 427 Email: jkolhe@google.com 429 Anees Shaikh 430 Google 431 1600 Amphitheatre Pkwy 432 Mountain View, CA 94043 433 US 435 Email: aashaikh@google.com 437 Joshua George 438 Cisco 439 170 W Tasman Dr 440 San Jose, CA 95134 441 US 443 Email: jgeorge@cisco.com