idnits 2.17.1 draft-li-apn-problem-statement-usecases-00.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 (March 6, 2020) is 1512 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC8200' is defined on line 607, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 7665 ** Downref: Normative reference to an Informational RFC: RFC 8578 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-10 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Li 3 Internet-Draft S. Peng 4 Intended status: Standards Track Huawei Technologies 5 Expires: September 7, 2020 D. Voyer 6 Bell Canada 7 C. Xie 8 China Telecom 9 P. Liu 10 China Mobile 11 Z. Qin 12 China Unicom 13 K. Ebisawa 14 Toyota Motor Corporation 15 S. Previdi 16 Individual 17 J. Guichard 18 Futurewei Technologies Ltd. 19 March 6, 2020 21 Problem Statement and Use Cases of Application-aware Networking (APN) 22 draft-li-apn-problem-statement-usecases-00 24 Abstract 26 Network operators are facing the challenge of providing better 27 network services for users. As the ever developing 5G and industrial 28 verticals evolve, more and more services that have diverse network 29 requirements such as ultra-low latency and high reliability are 30 emerging, and therefore differentiated service treatment is desired 31 by users. However, network operators are typically unaware of which 32 applications are traversing their network infrastructure, which means 33 that only coarse-grained services can be provided to users. As a 34 result, network operators are only evolving their infrastructure to 35 be large but dumb pipes without corresponding revenue increases that 36 might be enabled by differentiated service treatment. As network 37 technologies evolve including deployments of IPv6, SRv6, Segment 38 Routing over MPLS dataplane, the programmability provided by IPv6 and 39 Segment Routing can be augmented by conveying application related 40 information into the network. Adding application knowledge to the 41 network layer allows applications to specify finer granularity 42 requirements to the network operator. 44 This document analyzes the existing problems caused by lack of 45 application awareness, and outlines various use cases that could 46 benefit from an Application-aware Networking (APN) architecture. 48 Requirements Language 50 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 51 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 52 document are to be interpreted as described in RFC 2119 [RFC2119]. 54 Status of This Memo 56 This Internet-Draft is submitted in full conformance with the 57 provisions of BCP 78 and BCP 79. 59 Internet-Drafts are working documents of the Internet Engineering 60 Task Force (IETF). Note that other groups may also distribute 61 working documents as Internet-Drafts. The list of current Internet- 62 Drafts is at https://datatracker.ietf.org/drafts/current/. 64 Internet-Drafts are draft documents valid for a maximum of six months 65 and may be updated, replaced, or obsoleted by other documents at any 66 time. It is inappropriate to use Internet-Drafts as reference 67 material or to cite them other than as "work in progress." 69 This Internet-Draft will expire on September 7, 2020. 71 Copyright Notice 73 Copyright (c) 2020 IETF Trust and the persons identified as the 74 document authors. All rights reserved. 76 This document is subject to BCP 78 and the IETF Trust's Legal 77 Provisions Relating to IETF Documents 78 (https://trustee.ietf.org/license-info) in effect on the date of 79 publication of this document. Please review these documents 80 carefully, as they describe your rights and restrictions with respect 81 to this document. Code Components extracted from this document must 82 include Simplified BSD License text as described in Section 4.e of 83 the Trust Legal Provisions and are provided without warranty as 84 described in the Simplified BSD License. 86 Table of Contents 88 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 89 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 90 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 91 3.1. Large but Dumb Pipe . . . . . . . . . . . . . . . . . . . 4 92 3.2. Network on Its Own . . . . . . . . . . . . . . . . . . . 4 93 3.3. Decoupling of Network and Applications . . . . . . . . . 5 94 3.4. Challenges of Traditional Differentiated Service 95 Provisioning . . . . . . . . . . . . . . . . . . . . . . 5 97 3.5. Challenges of Supporting New 5G and Edge Computing 98 Technologies . . . . . . . . . . . . . . . . . . . . . . 6 99 4. Key Elements of Application-aware Networking (APN) . . . . . 6 100 4.1. Use cases for Application-aware Networking (APN) . . . . 8 101 4.1.1. Application-aware SLA Guarantee . . . . . . . . . . . 8 102 4.1.2. Application-aware network slicing . . . . . . . . . . 8 103 4.1.3. Application-aware Deterministic Networking . . . . . 9 104 4.1.4. Application-aware Service Function Chaining . . . . . 10 105 4.1.5. Application-aware Network Measurement . . . . . . . . 10 106 5. Application-aware IPv6 Networking (APN6) . . . . . . . . . . 11 107 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 108 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 109 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 110 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 111 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 112 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 113 10.2. Informative References . . . . . . . . . . . . . . . . . 14 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 116 1. Introduction 118 Due to the requirement for differentiated traffic treatment driven by 119 diverse new services, the ability to convey the characteristics of an 120 application's traffic flow and program the network infrastructure 121 accordingly to provide fine-grained service assurance is becoming 122 increasingly necessary for network operators. The Application-aware 123 Networking (APN) architecture is being defined to address the 124 requirements and use cases described in this document. APN takes 125 advantage of network programmability by conveying application related 126 information in the data plane allowing applications to specify finer 127 grained requirements to the network infrastructure. 129 2. Terminology 131 ACL: Access Control List 133 APN: Application-aware Networking 135 APN6: Application-aware Networking for IPv6/SRv6 137 DPI: Deep Packet Inspection 139 PBR: Policy Based Routing 141 QoE: Quality of Experience 143 SDN: Software Defined Networking 144 SLA: Service Level Agreement 146 MPLS: Multiprotocol Label Switching 148 SR: Segment Routing 150 SRv6: Segment Routing over IPv6 dataplane 152 SR-MPLS: Segment Routing over MPLS dataplane 154 VPN: Virtual Private Network 156 TE: Traffic Engineering 158 FRR: Fast Reroute 160 CAPEX: Capital expenditures 162 OPEX: Operating expenditures 164 3. Problem Statement 166 This section summarizes the challenges currently faced by network 167 operators when attempting to provide fine-grained traffic operations 168 to satisfy the various application-awareness requirements demanded by 169 new services that require differentiated service treatment. 171 3.1. Large but Dumb Pipe 173 In today's networks, the infrastructure through which user traffic is 174 forwarded is not able to determine information about the packet, 175 including which application the traffic belongs to, without the 176 introduction of middleware such as DPI, that is, the network and 177 applications are decoupled. It is therefore difficult for network 178 operators to provide fine-grained traffic operations for performance- 179 demanding applications. In order to satisfy the SLA requirements 180 network operators continue to increase the network bandwidth but only 181 carrying very light traffic load (around 30%-40% of its capacity). 182 This situation greatly increases the CAPEX and OPEX but only brings 183 very little revenue from the carried services. 185 3.2. Network on Its Own 187 As the network evolves, technologies such as VPN, TE, FRR, SFC, 188 Network Slicing, etc play important roles in satisfying service 189 isolation, SLA guarantee, and high reliability, etc. These network 190 technologies have themselves been evolving, introducing new features 191 that forces the network operator to be continuously upgrading their 192 network infrastructure. However, none of these network technologies 193 make the network aware of which application traffic belongs to and 194 the fine granularity requirements of the application. Therefore, 195 such continuous network infrastructure upgrade doesn't always enable 196 true fine-grained traffic operation, therefore reducing the ability 197 to bring corresponding revenue increase. 199 3.3. Decoupling of Network and Applications 201 MPLS played a very important role in helping the network enter the 202 generation of All-IP successfully. However, MPLS alone doesn't allow 203 a close interworking with the application layer since MPLS 204 encapsulation is, typically, not used by the packet source. 206 As new services continuously evolve, more encapsulations are 207 required, and this isolation and decoupling has further become the 208 blockage towards the seamless convergence of the network and 209 applications. 211 3.4. Challenges of Traditional Differentiated Service Provisioning 213 Several IETF activities have been reviewed which are primarily 214 intended to evolve the IP architecture to support new service 215 definitions which allow preferential or differentiated treatment to 216 be accorded to certain types of traffic. The challenge when using 217 traditional ways to guarantee an SLA is that the packets are not able 218 to carry enough information for indicating applications and 219 expressing their service/SLA requirements. The network devices 220 mainly rely on the 5-tuple of the packets or DPI. However, there are 221 some challenges for these traditional methods in differentiated 222 service provisioning: 224 1. Five Tuples used for ACL/PBR: five tuples are widely used for 225 ACL/PBR matching of traffic. However, these features cannot 226 provide enough information for the fine-grained service process, 227 and can only provide indirect application information which needs 228 to be translated in order to indicate a specific application. 230 2. Deep Packet Inspection (DPI): If more information is needed, it 231 must be extracted using DPI which can inspect deep into the 232 packets for application specific information. However, this will 233 introduce more CAPEX and OPEX for the network operator and impose 234 security challenges. 236 3. Orchestration and SDN-based Solution: In the era of SDN, 237 typically, an SDN controller is used to manage and operate the 238 network infrastructure and orchestrator elements introduce 239 application requirements so that the network is programmed 240 accordingly. The SDN controller can be aware of the service 241 requirements of the applications on the network through the 242 interface with the orchestrator, and the service requirement is 243 used by the controller for traffic management over the network. 244 However, this method raises the following problems: 246 A. The whole loop is long and time-consuming which is not 247 suitable for fast service provisioning for critical 248 applications; 250 B. Too many interfaces are involved in the loop, as shown in 251 Figure 1, which introduce challenges of standardization and 252 inter-operability. 254 +--------------+ 255 +-----| Orchestrator | -------------------+ 256 | +--------------+ Resource | 257 APP Req. | | Management | 258 +---------+ +---------+ & +---------+ 259 |SDN Ctrl1| |SDN Ctrl2| Service |SDN Ctrl3| 260 +---------+ +---------+ Provisioning +---------+ 261 App Req./ | | \ | \ 262 / | | \ | \ 263 / | | \ | \ 264 +---+ +-----+ +--------+ +-------+ +-------+ +-------+ 265 |APP| | DCN | |Network |..|Network| |Network|..|Network| 266 +---+ +-----+ | D1 | | D3 | | D4 | | D6 | 267 +--------+ +-------+ +-------+ +-------+ 269 Figure 1: Multiple interfaces involved in the long service- 270 provisioning loop 272 3.5. Challenges of Supporting New 5G and Edge Computing Technologies 274 New technologies such as 5G, IoT, and edge computing, are 275 continuously developing leading to more and more new types of 276 services accessing the network. Large volumes of network traffic 277 with diverse requirements such as low latency and high reliability 278 are therefore rapidly increasing. If traditional methods for 279 differentiation of traffic continue to be utilized, it will cause 280 much higher CAPEX and OPEX to satisfy the ever-developing 281 applications' diverse requirements. 283 4. Key Elements of Application-aware Networking (APN) 285 Application-aware Networking (APN) aims to address the problems 286 mentioned in Section 3, associated with fine-grained traffic 287 operations that are required in order to satisfy the various 288 application-awareness requirements demanded by new services that need 289 differentiated service treatment. APN aims to implement a mechanism 290 through which application information is conveyed into the network 291 infrastructure and that describes characteristics of the application 292 associated with a traffic flow (e.g., application identification, 293 network performance requirements), allowing the network to quickly 294 adapt and perform the necessary resource adjustments so to maintain 295 SLA performance guarantees, and hence better serve application fine- 296 grained service requirements. 298 APN has the following key elements: 300 1. Application information is conveyed in the data plane through 301 augmentation of existing encapsulations such as IPv6, SRv6 and 302 MPLS. The conveyed application characteristic information 303 (application-aware information) includes application 304 identification and/or its network performance requirements. This 305 element is not intended to be enforced but rather it provides an 306 open option for applications to decide whether to input this 307 application-aware information into their data stream. When a 308 data packet uses APN and conveys the application information, it 309 is referred in this document as an APN packet. 311 2. Application information and network service provisioning matching 312 providing fine-granularity network service provisioning (traffic 313 operations) and SLA guarantee based on the application-aware 314 information carried in APN packets. This element provides the 315 network capabilities to applications. According to the 316 application-aware information, appropriate network services are 317 selected, provisioned, and provided to the demanding applications 318 to satisfy their performance requirements. 320 3. Network measurement of network performance and update the match 321 between the applications and corresponding network services for 322 better fine-granularity SLA compliance. The network measurement 323 methods include in-band and out-of-band, passive, active, per- 324 packet, per-flow, per node, end-to-end, etc. These methods can 325 also be integrated. 327 Applications | Network 329 Element 1: Conveying -------------------> 330 /|\ 331 Application Info | Network capabilities 332 | (SLA guarantee) 333 | /|\ 334 Element 2: Matching | 335 | 336 Element 3: Network Measurement 338 Figure 2: Illustration of the key elements of APN 340 4.1. Use cases for Application-aware Networking (APN) 342 This section provides the use cases that can benefit from the 343 application awareness introduced by APN. The corresponding 344 requirements for APN are also outlined. 346 4.1.1. Application-aware SLA Guarantee 348 One of the key objectives of APN is for network operators to provide 349 fine-granularity SLA guarantees instead of coarse-grain traffic 350 operations. This will enable them to provide differentiated services 351 for different applications and increase revenue accordingly. Among 352 various applications being carried and running in the network, some 353 revenue-producing applications such as online gaming, video 354 streaming, and enterprise video conferencing have much more demanding 355 performance requirements such as low network latency and high 356 bandwidth. In order to achieve better Quality of Experience (QoE) 357 for end users and engage customers, the network needs to be able to 358 provide fine-granularity and even application-level SLA guarantee. 359 Differentiated service provisioning is also desired. 361 The APN architecture MUST address the following requirements: 363 o APN needs to perform the three key elements as described in 364 Section 4. 366 o Support application-level fine-granularity traffic operation that 367 may include finer QoS scheduling. 369 4.1.2. Application-aware network slicing 371 More and more applications/services with diverse requirements are 372 being carried over and sharing the network operators' network 373 infrastructure. However, it is still desirable to have customized 374 network transport that can support some application's specific 375 requirements, taking into consideration service and resource 376 isolation, which drives the concept of network slicing. 378 Network slicing provides ways to partition the network infrastructure 379 in either the control plane or data plane into multiple network 380 slices that are running in parallel. These network slices can serve 381 diverse services and fulfill their various requirements at the same 382 time. For example, the mission critical application that requires 383 ultra-low latency and high reliability can be provisioned over a 384 separate network slice. 386 The APN architecture MUST address the following requirements: 388 o APN needs to perform the three key elements as described in 389 Section 4 in the context of network slicing. 391 o For the element 2, the APN architecture MUST allow to assign a 392 given traffic flow to specific network slice according to the 393 application information carried in the APN packet. 395 o For the element 3, the APN architecture MUST allow the network 396 measurement of each network slice. 398 4.1.3. Application-aware Deterministic Networking 400 [RFC8578] documents use cases for diverse industry applications that 401 require deterministic flows over multi-hop paths. Deterministic 402 flows provide guaranteed bandwidth, bounded latency, and other 403 properties relevant to the transport of time-sensitive data, and can 404 coexist on an IP network with best-effort traffic. It also provides 405 for highly reliable flows through provision for redundant paths. 407 The APN architecture MUST address the following requirements: 409 o APN needs to perform the three key elements as described in 410 Section 4 in the context of deterministic networking. 412 o For the element 2, the APN architecture MUST allow to assign a 413 given traffic flow to a specific deterministic path according to 414 the application information carried in the APN packet. 416 o For the element 3, the APN architecture MUST allow the network 417 measurement of each application-aware deterministic path. 419 4.1.4. Application-aware Service Function Chaining 421 End-to-end service delivery often needs to go through various service 422 functions, including traditional network service functions such as 423 firewalls, DPIs as well as new application-specific functions, both 424 physical and virtual. The definition and instantiation of an ordered 425 set of service functions and subsequent steering of the traffic 426 through them is called Service Function Chaining (SFC) [RFC7665]. 427 SFC is applicable to both fixed and mobile networks as well as data 428 center networks. 430 Generally, in order to manipulate a specific application traffic 431 along the SFC, a DPI needs to be deployed as the first service 432 function of the chain to detect the application, which will impose 433 high CAPEX and consume long processing time. For encrypted traffic, 434 it even becomes impossible to inspect the application. 436 The APN architecture MUST address the following requirements: 438 o APN needs to perform the three key elements as described in 439 Section 4 in the context of service function chaining. 441 o For the element 1, class information can be conveyed. 443 o For the element 2, the APN architecture MUST allow to assign a 444 given traffic flow to a specific service function chain and MUST 445 allow the subsequent steering according to the application 446 information carried in the APN packets. 448 o For the element 3, the APN architecture MUST allow the network 449 measurement of each application-aware service function chain. 451 4.1.5. Application-aware Network Measurement 453 Network measurement can be used for locating silent failure and 454 predicting QoE satisfaction, which enables real-time SLA awareness/ 455 proactive OAM. Operations, Administration, and Maintenance (OAM) 456 refers to a toolset for fault detection and isolation, and network 457 performance measurement. In-situ Operations, Administration, and 458 Maintenance (IOAM) records operational and telemetry information in 459 the packet while the packet traverses a path between two points in 460 the network. 462 The APN architecture MUST address the following requirements: 464 o APN needs to perform the two key elements as described in 465 Section 4 in the context of network measurement. The network 466 measurement in the element 3 does not need to be considered here. 468 5. Application-aware IPv6 Networking (APN6) 470 As mentioned in Section 3.3, MPLS dataplane is not (or rarely) used 471 at the packet origin (i.e., where the packet is sourced) and 472 therefore it is not possible to assume the MPLS encapsulation is 473 available end-to-end in the traffic flow journey. This scenario is 474 still supported by APN with the ability to classify the packet at the 475 ingress node of the MPLS domain. Of course, it reduces the seamless 476 inter-working between applications and network layer but still APN 477 will improve the resources utilization of the network layer. 479 APN is intended to be dataplane agnostic. Hence, APN architecture, 480 functions and elements are applicable to both IPv6/SRv6 and MPLS 481 dataplanes. However, it is obvious that IPv6/SRv6 dataplane delivers 482 a better option for APN due to its flexibility, address space and 483 later developments of SRv6 as of 484 [I-D.ietf-6man-segment-routing-header] and 485 [I-D.ietf-spring-srv6-network-programming]. Therefore, this document 486 is mostly focused on the IPv6/SRv6 dataplane. MPLS dataplane is also 487 supported by APN but with some limitations such as backward 488 compatibility and limited address space (20 bits label size). 490 In this document we refer to APN6 when APN applies to the IPv6/SRv6 491 dataplane. Application-aware IPv6 Networking (APN6) aims to address 492 APN problems described in Section 3 in the IPv6/SRv6 dataplane. APN6 493 conveys information into the network infrastructure about the 494 characteristics of the application associated with a traffic flow 495 (including application identification and network performance 496 requirements), using IPv6/SRv6 encapsulation allowing the network to 497 quickly adapt and perform the necessary network resource adjustments 498 to maintain SLA performance guarantees, and hence better serve 499 application fine-grained service requirements. 501 The advantages of using IPv6/SRv6 to support APN include, 503 1. Simplicity: Conveying application information with IPv6 504 encapsulation can just be based on IP reachability. 506 2. Seamless convergence: Much easier to achieve seamless convergence 507 between applications and network since both are based on IPv6. 509 3. Great extensibility: IPv6 encapsulation including its extension 510 headers can be used to carry very rich information relevant to 511 applications. 513 4. Backward compatibility: On-demand network upgrade and service 514 provisioning. If the application information is not recognized 515 by the node, the packet will be forwarded based on pure IPv6, 516 which ensure backward compatibility. 518 5. Little dependency: Information conveying and service provisioning 519 are only based on the forwarding plane of devices, which is 520 different from the Orchestration and SDN-based solution which 521 involves multiple elements and diverse interfaces. 523 6. Quick response: Flow-driven and direct response from devices 524 since it is based on the forwarding plane. 526 6. IANA Considerations 528 This document does not include an IANA request. 530 7. Security Considerations 532 Since the application information is conveyed into the network, it 533 does involve some security and privacy issues. 535 First, APN only provides the capability to the applications to 536 provide their profiles and requirements to the network, but it leaves 537 the applications to decide whether to input this information. If the 538 applications decide not to provide any information, they will be 539 treated in the same way as today's network and cannot get the 540 benefits from APN. 542 Once the application information has been carried in the IPv6 packets 543 and conveyed into the network, the IPv6 extension headers, AH and 544 ESP, can be used to guarantee the authenticity of the added 545 application information. 547 Any scheme involving an information exchange between layers 548 (application and network layers in this case) will obviously require 549 an accurate valuation of security mechanism in order to prevent any 550 leak of critical information. Some additional considerations may be 551 required for multi-domain use cases. For example, how to agree upon 552 which application information/ID to use and guarantee authenticity 553 for packets traveling through multiple domains (network operators). 555 8. Acknowledgements 557 The authors would like to acknowledge Robert Raszuk (Bloomberg LP) 558 and Yukito Ueno (NTT Communications Corporation) for their valuable 559 review and comments. 561 9. Contributors 563 Daniel Bernier 564 Bell Canada 565 Canada 567 Email: daniel.bernier@bell.ca 569 Liang Geng 570 China Mobile 571 China 573 Email: gengliang@chinamobile.com 575 Chang Cao 576 China Unicom 577 China 579 Email: caoc15@chinaunicom.cn 581 Chang Liu 582 China Unicom 583 China 585 Email: liuc131@chinaunicom.cn 587 Cong Li 588 China Telecom 589 China 591 Email: licong@chinatelecom.cn 593 10. References 595 10.1. Normative References 597 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 598 Requirement Levels", BCP 14, RFC 2119, 599 DOI 10.17487/RFC2119, March 1997, 600 . 602 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 603 Chaining (SFC) Architecture", RFC 7665, 604 DOI 10.17487/RFC7665, October 2015, 605 . 607 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 608 (IPv6) Specification", STD 86, RFC 8200, 609 DOI 10.17487/RFC8200, July 2017, 610 . 612 [RFC8578] Grossman, E., Ed., "Deterministic Networking Use Cases", 613 RFC 8578, DOI 10.17487/RFC8578, May 2019, 614 . 616 10.2. Informative References 618 [I-D.ietf-6man-segment-routing-header] 619 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 620 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 621 (SRH)", draft-ietf-6man-segment-routing-header-26 (work in 622 progress), October 2019. 624 [I-D.ietf-spring-srv6-network-programming] 625 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 626 Matsushima, S., and Z. Li, "SRv6 Network Programming", 627 draft-ietf-spring-srv6-network-programming-10 (work in 628 progress), February 2020. 630 Authors' Addresses 632 Zhenbin Li 633 Huawei Technologies 634 China 636 Email: lizhenbin@huawei.com 638 Shuping Peng 639 Huawei Technologies 640 China 642 Email: pengshuping@huawei.com 644 Daniel Voyer 645 Bell Canada 646 Canada 648 Email: daniel.voyer@bell.ca 649 Chongfeng Xie 650 China Telecom 651 China 653 Email: xiechf@chinatelecom.cn 655 Peng Liu 656 China Mobile 657 China 659 Email: liupengyjy@chinamobile.com 661 Zhuangzhuang Qin 662 China Unicom 663 China 665 Email: qinzhuangzhuang@chinaunicom.cn 667 Kentaro Ebisawa 668 Toyota Motor Corporation 669 Japan 671 Email: ebisawa@toyota-tokyo.tech 673 Stefano Previdi 674 Individual 675 Italy 677 Email: stefano@previdi.net 679 James N Guichard 680 Futurewei Technologies Ltd. 681 USA 683 Email: jguichar@futurewei.com