idnits 2.17.1 draft-tian-spring-srv6-deployment-consideration-03.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 : ---------------------------------------------------------------------------- ** There are 39 instances of too long lines in the document, the longest one being 4 characters in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 9, 2020) is 1380 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-spring-srv6-network-programming' is defined on line 964, but no explicit reference was found in the text == Unused Reference: 'RFC5659' is defined on line 979, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-6man-segment-routing-header' is defined on line 996, but no explicit reference was found in the text == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-16 == Outdated reference: A later version (-13) exists of draft-ietf-6man-spring-srv6-oam-05 == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-09 == Outdated reference: A later version (-13) exists of draft-ietf-pce-pcep-flowspec-09 == Outdated reference: A later version (-13) exists of draft-ietf-rtgwg-segment-routing-ti-lfa-03 == Outdated reference: A later version (-15) exists of draft-ietf-spring-nsh-sr-02 == Outdated reference: A later version (-09) exists of draft-ietf-spring-sr-service-programming-02 == Outdated reference: A later version (-15) exists of draft-matsushima-spring-srv6-deployment-status-07 == Outdated reference: A later version (-16) exists of draft-song-ippm-postcard-based-telemetry-07 Summary: 1 error (**), 0 flaws (~~), 14 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Tian 3 Internet-Draft F. Zhao 4 Intended status: Informational CAICT 5 Expires: January 10, 2021 C. Xie 6 China Telecom 7 T. Li 8 J. Ma 9 China Unicom 10 R. Mwehaire 11 MTN Uganda Ltd. 12 E. Chingwena 13 MTN Group Limited 14 S. Peng, Ed. 15 Z. Li 16 Y. Xiao 17 Huawei Technologies 18 July 9, 2020 20 SRv6 Deployment Consideration 21 draft-tian-spring-srv6-deployment-consideration-03 23 Abstract 25 SRv6 has significant advantages over SR-MPLS and has attracted more 26 and more attention and interest from network operators and verticals. 27 Smooth network migration towards SRv6 is a key focal point and this 28 document provides network design and migration guidance and 29 recommendations on solutions in various scenarios. Deployment cases 30 with SRv6 are also introduced. 32 Requirements Language 34 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 35 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 36 document are to be interpreted as described in RFC 2119 [RFC2119]. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at https://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on January 10, 2021. 55 Copyright Notice 57 Copyright (c) 2020 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (https://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. Advantages of SRv6 . . . . . . . . . . . . . . . . . . . . . 4 74 2.1. IP Route Aggregation . . . . . . . . . . . . . . . . . . 4 75 2.2. End-to-end Service Auto-start . . . . . . . . . . . . . . 5 76 2.3. On-Demand Upgrade . . . . . . . . . . . . . . . . . . . . 6 77 2.4. Simplified Service Deployment . . . . . . . . . . . . . . 7 78 2.4.1. Carrier's Carrier . . . . . . . . . . . . . . . . . . 7 79 2.4.2. LDP over TE . . . . . . . . . . . . . . . . . . . . . 8 80 3. Compatibility Challenges . . . . . . . . . . . . . . . . . . 9 81 3.1. Fast Reroute (FRR) . . . . . . . . . . . . . . . . . . . 9 82 3.2. Traffic Engineering (TE) . . . . . . . . . . . . . . . . 10 83 3.3. Service Function Chaining (SFC) . . . . . . . . . . . . . 10 84 3.4. IOAM . . . . . . . . . . . . . . . . . . . . . . . . . . 10 85 4. Solutions for mitigating the compatibility challenges . . . . 11 86 4.1. Traffic Engineering . . . . . . . . . . . . . . . . . . . 12 87 4.1.1. Binding SID (BSID) . . . . . . . . . . . . . . . . . 12 88 4.1.2. PCEP FlowSpec . . . . . . . . . . . . . . . . . . . . 12 89 4.2. SFC . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 90 4.2.1. Stateless SFC . . . . . . . . . . . . . . . . . . . . 12 91 4.2.2. Stateful SFC . . . . . . . . . . . . . . . . . . . . 13 92 4.3. Light Weight IOAM . . . . . . . . . . . . . . . . . . . . 13 93 4.4. Postcard Telemetry . . . . . . . . . . . . . . . . . . . 14 94 5. Design Guidance for SRv6 Network . . . . . . . . . . . . . . 14 95 5.1. Locator and Address Planning . . . . . . . . . . . . . . 14 96 5.2. PSP . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 97 6. Incremental Deployment Guidance for SRv6 Migration . . . . . 15 98 7. Migration Guidance for SRv6/SR-MPLS Co-existence Scenario . . 16 99 8. Deployment cases . . . . . . . . . . . . . . . . . . . . . . 17 100 8.1. China Telecom Si'chuan . . . . . . . . . . . . . . . . . 18 101 8.2. China Unicom . . . . . . . . . . . . . . . . . . . . . . 19 102 8.3. MTN Uganda . . . . . . . . . . . . . . . . . . . . . . . 20 103 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 104 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21 105 11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 21 106 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 21 107 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 108 13.1. Normative References . . . . . . . . . . . . . . . . . . 22 109 13.2. Informative References . . . . . . . . . . . . . . . . . 22 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 112 1. Introduction 114 SRv6 is the instantiation of Segment Routing deployed on the IPv6 115 data plane [RFC8200]. Therefore, in order to support SRv6, the 116 network must first be enabled for IPv6. Over the past several years, 117 IPv6 has been actively promoted all over the world, and the 118 deployments of IPv6 have been ever-increasing which provides the 119 basis for the deployments of SRv6. 121 With IPv6 as its data plane, for network migration towards SRv6, both 122 software and hardware need to be upgraded. Compared with other new 123 protocols, only IGP and BGP need to be extended to support SRv6, 124 which significantly simplifies the software upgrade required. While 125 the hardware needs to support the new SRv6 header SRH [RFC8754], the 126 design of SRv6 assures compatibility with the existing IPv6 network 127 as an SRv6 SID is designed as a 128-bit IPv6 address and the 128 encapsulation of an SRv6 packet is the same as an IPv6 packet. When 129 only L3VPN over SRv6 BE (Best-Effort) is deployed, there will be no 130 SRH. Therefore, no additional hardware capabilities are required but 131 only software upgrade for protocol extensions. 133 As the number of services supported by SRv6 increase, e.g. SFC, 134 network slicing, iOAM etc., more SIDs in the SRH may impose new 135 requirements on the hardware. Besides upgrading the hardware, 136 various solutions have already been proposed to relieve the imposed 137 pressure on the hardware, such as Binding SID (BSID) etc. to 138 guarantee the compatibility with the existing network. On the other 139 hand SRv6 has many more advantages over SR-MPLS for the network 140 migration to support new services. 142 This document summarizes the advantages of SRv6 and provides network 143 migration guidance and recommendations on solutions in various 144 scenarios. 146 2. Advantages of SRv6 148 Compared with SR-MPLS, SRv6 has significant advantages especially in 149 large scale networking scenarios. 151 2.1. IP Route Aggregation 153 The increasing complexity of service deployment is of concern for 154 network operators, especially in large-scale networking scenarios. 155 With solutions such as multi-segment PW and Option A [RFC4364], the 156 number of service-touch points has increased, and the services, with 157 associated OAM features cannot be deployed end-to-end. 159 o With Seamless MPLS or SR-MPLS, since the MPLS label itself does 160 not have reachability information, it must be attached to a 161 routable address. The 32-bit host route needs to leak across 162 domains. For an extreme case, as shown in Figure 1a, in a large 163 scale networking scenario, millions of host route LSPs might need 164 to be imported, which places big challenges on the capabilities of 165 the edge nodes. 167 o With SRv6, owing to its native IP feature of route aggregation as 168 shown in Figure 1b, the aggregated routes can be imported across 169 network domains. For large scale networking, only very few 170 aggregated routes are needed in order to start end-to-end 171 services, which also reduces the scalability requirements on the 172 edge nodes. 174 /------Metro------\ /----Core----\ /------Metro-------\ 175 LB PE1 ASBR ASBR PE2 LB 176 1.1.1.1 2.2.2.2 177 +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ 178 |A | |B | |ER| | | |PE| | | |PE| | | |ER| |B | |A | 179 +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ 180 SR-LSP SR-LSP SR-LSP SR-LSP SR-LSP 181 |<--->|<---------->| |<--------->| |<--------->|<--->| 182 BGP-LSP 183 |<---------------------------------------------------------->| 184 +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ 185 +IP + +IP + +IP + +IP + +IP + +IP + +IP + +IP + +IP + 186 +ETH+ +VPN+ +VPN+ +VPN+ +VPN+ +VPN+ +VPN+ +VPN+ +ETH+ 187 +---+ +BGP+ +BGP+ +BGP+ +BGP+ +BGP+ +BGP+ +BGP+ +---+ 188 +SR + +SR + +ETH+ +SR + +ETH+ +SR + +SR + 189 +ETH+ +ETH+ +---+ +ETH+ +---+ +ETH+ +ETH+ 190 +---+ +---+ +---+ +---+ +---+ 192 (a) SR-MPLS 194 /------Metro------\ /----Core----\ /------Metro-------\ 195 LOC PE1 ASBR ASBR PE2 LOC 196 A1::100:: A2::200:: 197 +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ 198 |A | |B | |ER| | | |PE| | | |PE| | | |ER| |B | |A | 199 +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ 200 \_____A1::/80____/ \__A0::/80__/ \____A2::/80____/ 201 Aggregated Route Aggregated Route Aggregated Route 202 +---+ +----------+ +----------+ +----------+ +---+ 203 +IP + + IP + + IP + + IP + +IP + 204 +ETH + +w./wo.SRH + +w./wo.SRH + +w./wo.SRH + +ETH+ 205 +---+ + ETH + + ETH + + ETH + +---+ 206 +----------+ +----------+ +----------+ 208 (b) SRv6 210 Figure 1. Large-scale Networking with (a) SR-MPLS vs. (b) SRv6 212 2.2. End-to-end Service Auto-start 214 In the SR cross-domain scenario, in order to set up end-to-end SR 215 tunnels, the SIDs in each domain need to be imported to other 216 domains. 218 o With SR-MPLS, SRGB and Node SID need overall network-wide 219 planning, and in the cross-domain scenario, it is difficult or 220 sometimes even impossible to perform as the node SIDs in different 221 domains may collide. BGP Prefix SID can be used for the cross- 222 domain SID import, but the network operator must be careful when 223 converting the SID to avoid SID collision. Moreover, the pre- 224 allocated SRGB within each domain needs to consider the total 225 number of devices in all other domains, which raises difficulties 226 for the network-wide planning. 228 o With SRv6, owing to its native IP feature of route reachability, 229 if the IPv6 address space is carefully planned, and the aggregated 230 routes are imported by using BGP4+ (BGP IPv6), the services will 231 auto-start in the cross-domain scenario. 233 2.3. On-Demand Upgrade 235 The MPLS label itself does not hold any reachability information, so 236 it must be attached to a routable address, which means that the 237 matching relationship between the label and FEC needs to be 238 maintained along the path. 240 SR-MPLS uses the MPLS data plane. When the network migrates to SR- 241 MPLS, there are two ways, as shown in Figure 2: 243 1. MPLS/SR-MPLS Dual stack: the entire network is upgraded first and 244 then deploy SR-MPLS. 246 2. MPLS and SR-MPLS interworking: mapping servers are deployed at 247 some of the intermediate nodes and then removed once the entire 248 network is upgraded 250 Regardless of which migration option is chosen, big changes in a wide 251 area is required at the initial stage therefore causing a long time- 252 to-market. 254 In contrast, the network can be migrated to SRv6 on demand. Wherever 255 the services need to be turned on, only the relevant devices need to 256 be upgraded to enable SRv6, and all other devices only need to 257 support IPv6 forwarding and need not be aware of SRv6. When Traffic 258 Engineering (TE) services are needed, only the key nodes along the 259 path need to be upgraded to support SRv6. 261 (~~~~~~MPLS/SR-MPLS~~~~~~~) 262 ( +---+ +---+ +---+ ) 263 MPLS Migration Options Option 1 ( |SM | |SM | |SM | ) 264 --->( +---+ +---+ +---+ ) 265 / ( +---+ +---+ +---+ ) 266 (~~~~~~~~~~MPLS~~~~~~~~~~~) / ( |SM | |SM | |SM | ) 267 ( +---+ +---+ +---+ ) / ( +---+ +---+ +---+ ) 268 ( | M | | M | | M | ) / ~~~~~~~~~~~~~~~~~~~~~~~~~~ 269 ( +---+ +---+ +---+ ) \ 270 ( +---+ +---+ +---+ ) \ (~~MPLS~~|~~~~~SR-MPLS~~~~~) 271 ( | M | | M | | M | ) \ ( +---+ | +---+ +---+ ) 272 ( +---+ +---+ +---+ ) \ ( | M | | |SM | |SM | ) 273 ~~~~~~~~~~~~~~~~~~~~~~~~~~ --->( +---+ | +---+ +---+ ) 274 Option 2 ( +---+ | +---+ +---+ ) 275 ( | M | | |SM | |SM | ) 276 ( +---+ | +---+ +---+ ) 277 ~~~~~~~~~~~~~~~~~~~~~~~~~~ 278 SRv6 Migration 280 (~~~~~~~~~~MPLS~~~~~~~~~~~) (~~~~~~SRv6 on demand~~~~~) 281 ( +---+ +---+ +---+ ) ( +---+ +---+ +---+ ) 282 ( | M | | M | | M | ) ( |S6 | | M | | M | ) 283 ( +---+ +---+ +---+ ) ----------> ( +---+ +---+ +---+ ) 284 ( +---+ +---+ +---+ ) ( +---+ +---+ +---+ ) 285 ( | M | | M | | M | ) ( | M | | M | |S6 | ) 286 ( +---+ +---+ +---+ ) ( +---+ +---+ +---+ ) 287 ~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~ 289 Figure 2. MPLS Domain Migration vs. SRv6 On-Demand Upgrade 291 2.4. Simplified Service Deployment 293 With SRv6, the service deployment can be significantly simplified in 294 some scenarios. 296 2.4.1. Carrier's Carrier 298 When the customer of the VPN service carrier (Provider Carrier) is 299 itself a VPN service carrier (Customer Carrier), it becomes the 300 scenario of Carrier's Carrier. For this scenario, with SRv6, the 301 service deployment can be significantly simplified. 303 To achieve better scalability, the CEs of the Provider Carrier (i.e. 304 the PEs of the Customer Carriers) only distribute the internal 305 network routes to the PEs of the Provider Carrier. The customers' 306 routes of the Customer Carriers (i.e. from CE3 and CE4) will not be 307 distributed into the network of the Provide Carrier. Therefore, LDP 308 or Labeled BGP will be run between the CEs of the Provider Carrier 309 (i.e. CE1 and CE2 in the Figure 3) and the PEs of the Provider 310 Carrier (i.e. PE1 and PE2 in the Figure 3), and LDP will be run 311 between the CEs of the Provider Carrier (i.e. the PEs of the Customer 312 Carriers) and the PEs of the Customer Carrier (i.e. PE3 and PE4 in 313 the Figure 3). MP-BGP will be run between the PEs of the Customer 314 Carrier. The overall service deployment is very complex. 316 If SRv6 is deployed by the Customer Carrier and the Provider Carrier, 317 no LDP will be ever needed. The Locator routes and Loopback routes 318 of the Customer Carriers can be distributed into the network of the 319 Provider Carrier via BGP, and within each carrier's network only IGP 320 is needed. The end-to-end VPN services can be provided just based on 321 the IPv6 interconnections, and the customer carrier is just like a 322 normal CE to the provider carrier, which significantly simplified the 323 VPN service deployment. 325 Customer Carrier Provider Carrier Customer Carrier 326 /------------\ /-------------\ /-----------\ 327 +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ 328 |CE3|--|PE3| |CE1|--|PE1| |PE2|--|CE2| |PE4|--|CE4| 329 +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ 331 MPLS IGP/LDP IGP/LDP MP-IBGP IGP/LDP IGP/LDP 332 or Labeled BGP or Labeled BGP 334 SR-MPLS IGP Labeled BGP MP-IBGP Labeled BGP IGP 336 SRv6 IGP BGP MP-IBGP BGP IGP 337 |<--------->||<---->||<---------->||<--->||<--------->| 338 MP-IBGP 339 |<--------------------------------------------------->| 340 Figure 3. Service deployment with MPLS, SR-MPLS and SRv6 342 2.4.2. LDP over TE 344 In a MPLS network, generally RSVP-TE is deployed in the P nodes of 345 the network, and LDP is running between these P nodes and the PE 346 nodes. Customers access to VPN services via the PE nodes. This 347 scenario is called LDP over TE, which is a typical deployment for 348 carriers who want to achieve the TE capability over MPLS network 349 while keep scalability. However, such network configuration and 350 service deployment are very complex. 352 With SRv6 which can provide both TE capability and IP reachability, 353 the service deployment can be significantly simplified. Only IGP and 354 BGP are needed in the network to launch VPN services. 356 +---+ +---+ +---+ +---+ +---+ +---+ 357 |CE1|---------|PE1|------|P1 |\-------/|P2 |------|PE2|--------|CE2| 358 +---+ +---+ +---+ \ / +---+ +---+ +---+ 359 / 360 +---+ +---+ +---+ / \ +---+ +---+ +---+ 361 |CE3|---------|PE3|------|P3 |/-------\|P4 |------|PE4|--------|CE4| 362 +---+ +---+ +---+ +---+ +---+ +---+ 364 MPLS LDP RSVP-TE LDP 366 SR-MPLS IGP (SR-MPLS) 368 SRv6 IGP (SRv6) 369 |<-------->|<------------>|<------->| 370 MP-BGP 371 |<--------------------------------->| 372 Figure 4. Service deployment with (a) MPLS/SR-MPLS vs. (b) SRv6 374 3. Compatibility Challenges 376 By adopting SR Policy, state in the network devices can be greatly 377 reduced, which ultimately evolves the network into a stateless 378 fabric. However, it also brings compatibility challenges on the 379 legacy devices. In particular, the legacy devices need to upgrade 380 software and/or hardware in order to support the processing of SRH. 382 Furthermore, as the segments in the segment list increase the SR 383 Policy incrementally expands, the encapsulation header overhead 384 increases, which imposes high performance requirements on the 385 performance of hardware forwarding (i.e. the capability of the 386 chipset). 388 This section identifies the challenges for legacy devices imposed by 389 SRv6 in the following SPRING use cases. 391 3.1. Fast Reroute (FRR) 393 FRR is deployed to cope with link or node failures by precomputing 394 backup paths. By relying on SR, Topology Independent Loop-free 395 Alternate Fast Re-route (TI-LFA) 396 [I-D.ietf-rtgwg-segment-routing-ti-lfa] provides a local repair 397 mechanism with the ability to activate the data plane switch-over on 398 to a loop-free backup path irrespective of topologies prior and after 399 the failure. 401 Using SR, there is no need to create state in the network in order to 402 enforce FRR behavior. Correspondingly, the Point of Local Repair, 403 i.e. the protecting router, needs to insert a repair list at the head 404 of the segment list in the SRH, encoding the explicit post- 405 convergence path to the destination. This action will increase the 406 length of the segment list in the SRH as shown in Figure 1. 408 3.2. Traffic Engineering (TE) 410 TE enables network operators to control specific traffic flows going 411 through configured explicit paths. There are loose and strict 412 options. With the loose option, only a small number of hops along 413 the path is explicitly expressed, while the strict option specifies 414 each individual hop in the explicit path, e.g. to encode a low 415 latency path from one network node to another. 417 With SRv6, the strict source-routed explicit paths will result in a 418 long segment list in the SRH as shown in Figure 1, which places high 419 requirements on the devices. 421 3.3. Service Function Chaining (SFC) 423 The SR segments can also encode instructions, called service 424 segments, for steering packets through services running on physical 425 service appliances or virtual network functions (VNF) running in a 426 virtual environment [I-D.ietf-spring-sr-service-programming]. These 427 service segments can also be integrated in an SR policy along with 428 node and adjacency segments. This feature of SR will further 429 increase the length of the segment list in the SRH as shown in 430 Figure 1. 432 In terms of SR awareness, there are two types of services, i.e. SR- 433 aware and SR-unaware services, which both impose new requirements on 434 the hardware. The SR-aware service needs to be fully capable of 435 processing SR traffic, while for the SR-unaware services, an SR proxy 436 function needs to be defined. 438 If the Network Service Header (NSH) based SFC [RFC8300] has already 439 been deployed in the network, the compatibility with existing NSH is 440 required. 442 3.4. IOAM 444 IOAM, i.e. "in-situ" Operations, Administration, and Maintenance 445 (OAM), encodes telemetry and operational information within the data 446 packets to complement other "out-of-band" OAM mechanisms, e.g. ICMP 447 and active probing. The IOAM data fields, i.e. a node data list, 448 hold the information collected as the packets traverse the IOAM 449 domain [I-D.ietf-ippm-ioam-data], which is populated iteratively 450 starting with the last entry of the list. 452 The IOAM data can be embedded into a variety of transports. To 453 support the IOAM on the SRv6 data plane, the O-flag in the SRH is 454 defined [I-D.ietf-6man-spring-srv6-oam], which implements the "punt a 455 timestamped copy and forward" or "forward and punt a timestamped 456 copy" behavior. The IOAM data fields, i.e. the node data list, are 457 encapsulated in the IOAM TLV in SRH, which further increases the 458 length of the SRH as shown in Figure 1. 460 +-----------+ 461 |IPv6 packet| 462 +-----------+ 463 / / 464 +-----------+ / IOAM Info / 465 |IPv6 packet| / / 466 +-----------+ +-----------+ +-----------+ 467 |IPv6 packet| / / / / 468 +-----------+ +-----------+ / / / / 469 |IPv6 packet| / / / SF Chain / / SF Chain / 470 +-----------+ +-----------+ / TE Path / / / / / 471 |IPv6 packet| /TI-LFA Path/ / / / / / / 472 +-----------+ +-----------+ +-----------+ +-----------+ +-----------+ 473 |SA,DA | |SA,DA | |SA,DA | |SA,DA | |SA,DA | 474 +-----------+ +-----------+ +-----------+ +-----------+ +-----------+ 475 SRv6 BE SRv6 BE+ SRv6 TE SRv6 SFC SRv6 SFC+ 476 TI-LFA IOAM 478 Figure 1. Evolution of SRv6 SRH 480 Compatibility challenges for legacy devices can be summarized as 481 follows: 483 o Legacy devices need to upgrade software and/or hardware in order 484 to support the processing of SRH 486 o As the SRH expands, the encapsulation overhead increases and 487 correspondingly the effective payload decreases 489 o As the SRH expands, the hardware forwarding performance reduces 490 which requires higher capabilities of the chipset 492 4. Solutions for mitigating the compatibility challenges 494 This section provides solutions to mitigate the challenges outlined 495 in section 2. 497 4.1. Traffic Engineering 499 With strict traffic engineering, the resultant long SID list in the 500 SRH raises high requirements on the hardware chipset, which can be 501 mitigated by the following solutions. 503 4.1.1. Binding SID (BSID) 505 Binding SID [RFC8402] involves a list of SIDs and is bound to an SR 506 Policy. The node(s) that imposes the bound policy needs to store the 507 SID list. When a node receives a packet with its active segment as a 508 BSID, the node will steer the packet in to the bound policy 509 accordingly. 511 To reduce the long SID list of a strict TE explicit path, BSID can be 512 used at selective nodes, maybe according to the processing capacity 513 of the hardware chipset. BSID can also be used to impose the repair 514 list in the TI-LFA as described in Section 2.1. 516 4.1.2. PCEP FlowSpec 518 When the SR architecture adopts a centralized model, the SDN 519 controller (e.g. Path Computation Element (PCE)) only needs to apply 520 the SR policy at the head-end. There is no state maintained at 521 midpoints and tail-ends. Eliminating state in the network (midpoints 522 and tail-points) is a key benefit of utilizing SR. However, it also 523 leads to a long SID list for expressing a strict TE path. 525 PCEP FlowSpec [I-D.ietf-pce-pcep-flowspec] provides a trade-off 526 solution. PCEP FlowSpec is able to disseminate Flow Specifications 527 (i.e. filters and actions) to indicate how the classified traffic 528 flows will be treated. In an SR-enabled network, PCEP FlowSpec can 529 be applied at the midpoints to enforce traffic engineering policies 530 where it is needed. In that case, state needs to be maintained at 531 the corresponding midpoints of a TE explicit path, but the SID list 532 can be shortened. 534 4.2. SFC 536 Currently two approaches are proposed to support SFC over SRv6, i.e. 537 stateless SFC [I-D.ietf-spring-sr-service-programming] and stateful 538 SFC [I-D.ietf-spring-nsh-sr]. 540 4.2.1. Stateless SFC 542 A service can also be assigned an SRv6 SID which is integrated into 543 an SR policy and used to steer traffic to it. In terms of the 544 capability of processing the SR information in the received packets, 545 there are two types of services, i.e. SR-aware service and SR-unware 546 service. An SR-aware service can process the SRH in the received 547 packets. An SR-unaware service, i.e. legacy service, is not able to 548 process the SR information in the traffic it receives, and may drop 549 the received packets. In order to support such services in an SRv6 550 domain, the SR proxy is introduced to handle the processing of SRH on 551 behalf of the SR-unware service. The service SID associated with the 552 SR-unaware service is instantiated on the SR proxy, which is used to 553 steer traffic to the service. 555 The SR proxy intercepts the SR traffic destined for the service via 556 the locally instantiated service SID, removes the SR information, and 557 sends the non-SR traffic out on a given interface to the service. 558 When receiving the traffic coming back from the service, the SR proxy 559 will restore the SR information and forwards it to the next segment 560 in the segment list. 562 4.2.2. Stateful SFC 564 The NSH and SR can be integrated in order to support SFC in an 565 efficient and cost-effective manner while maintaining separation of 566 the service and transport planes. 568 In this NSH-SR integration solution, NSH and SR work jointly and 569 complement each other. Specifically, SR is responsible for steering 570 packets along a given Service Function Path (SFP) while NSH is for 571 maintaining the SFC instance context, i.e. Service Path Identifier 572 (SPI), Service Index (SI), and any associated metadata. 574 When a service chain is established, a packet associated with that 575 chain will be first encapsulated with an NSH and then an SRH, and 576 forwarded in the SR domain. When the packet arrives at an SFF and 577 needs to be forwarded to an SF, the SFF performs a lookup based on 578 the service SID associated with the SF to retrieve the next-hop 579 context (a MAC address) between the SFF and SF. Then the SFF strips 580 the SRH and forwards the packet with NSH carrying metadata to the SF 581 where the packet will be processed as specified in [RFC8300]. In 582 this case, the SF is not required to be capable of the SR operation, 583 neither is the SR proxy. Meanwhile, the stripped SRH will be updated 584 and stored in a cache in the SFF, indexed by the NSH SPI for the 585 forwarding of the packet coming back from the SF. 587 4.3. Light Weight IOAM 589 In most cases, after the IPv6 Destination Address (DA) is updated 590 according to the active segment in the SRH, the SID in the SRH will 591 not be used again. However, the entire SID list in the SRH will 592 still be carried in the packet along the path till a PSP/USP is 593 enforced. 595 The light weight IOAM method [I-D.li-spring-passive-pm-for-srv6-np] 596 makes use of the used segments in the SRH to carry the IOAM 597 information, which saves the extra space in the SRH and mitigate the 598 requirements on the hardware. 600 4.4. Postcard Telemetry 602 Existing in-situ OAM techniques incur encapsulation and header 603 overhead issues as described in section 2. Postcard-based Telemetry 604 with Packet Marking for SRv6 on-path 605 OAM[I-D.song-ippm-postcard-based-telemetry], provides a solution that 606 avoids the extra overhead for encapsulating telemetry-related 607 instruction and metadata in SRv6 packets. 609 5. Design Guidance for SRv6 Network 611 5.1. Locator and Address Planning 613 Address Planning is a very important factor for s successful network 614 design, especially an IPv6 network, which will directly affect the 615 design of routing, tunnel, and security. A good address plan can 616 bring big benefit for service deployment and network operation. 618 If a network has already deployed IPv6 and set up IPv6 subnets, one 619 of the subnets can be selected for the SRv6 Locator planning, and the 620 existing IPv6 address plan will not be impacted. 622 If a network has not yet deployed IPv6 and there has not been an 623 address plan, it needs to perform the IPv6 address planning first 624 taking the following steps, 626 1. to decide the IPv6 address planning principles 628 2. to choose the IPv6 address assignment methods 630 3. to assign the IPv6 address in a hierarchical manner 632 For an SRv6 network, in the first step for IPv6 address planning, the 633 following principles are suggested to follow, 635 1. Unification: all the IPv6 addresses SHOULD be planned altogether, 636 including service addresses for end users, platform addresses 637 (for IPTV, DHCP servers), and network addresses for network 638 devices interconnection. 640 2. Uniqueness: every single address SHOULD be unique. 642 3. Separation: service addresses and network addresses SHOULD be 643 planned separately; the SRv6 Locator subnet, the Loopback 644 interface addresses and the link addresses SHOULD be planned 645 separately. 647 4. Aggregatability: when being distributed across IGP/BGP domains, 648 the addresses in the preassigned subnets (e.g. SRv6 Locator 649 subnet, the Loopback interface subnet) SHOULD be aggregatable, 650 which will make the routing easier. 652 5. Security: fast tracability of the assigned addresses SHOULD be 653 facilitated, which will make the traffic filtering easier. 655 6. Evolvablity: enough address space SHOULD be reserved for each 656 subset for future service development. 658 Considering the above-mentioned IPv6 address planning principles, it 659 has been adopted in some deployment cases to set Locator length 660 96bits, function length 20bits, and args 12bits. 662 5.2. PSP 664 When Locator is imported in ISIS, the system will automatically 665 assign END SID with Flavors such as PSP (Penultimate Segment Pop) and 666 distribute the Locator subnet route through ISIS. 668 The Flavor PSP, that is, SRH is popped at penultimate segment, 669 provides the following benefits, 671 1. Reduce the load of ultimate segment endpoint. Ultimate segment 672 endpoint tends to have heavy load since it needs to handle the 673 inner IP/IPv6/Ethernet payload and demultiplex the packet to the 674 right overlay service. 676 2. Support of incremental deployment on existing network where the 677 ultimate segment endpoint is low-end device that is not fully 678 capable of handling SRH. 680 6. Incremental Deployment Guidance for SRv6 Migration 682 Incremental deployment is the key for a smooth network migration to 683 SRv6. In order to quickly launch SRv6 network services and enjoy the 684 benefits brought by SRv6, the recommended incremental SRv6 deployment 685 steps are given as follows. These are based on practical deployment 686 experience earned from the use cases described in 687 [I-D.matsushima-spring-srv6-deployment-status]. 689 The referenced network topology is shown in Figure 5. 691 /---- Path 1 ----\ 692 +------+ +----+ +---/--+ +---\--+ +----+ +------+ 693 |Site 1|----|PE 1|----|ASBR 1| IP Core |ASBR 2|----|PE 2|----|Site 2| 694 +------+ +----+ +---\--+ +---/--+ +----+ +------+ 695 \---- Path 2 ----/ 697 Figure 5. Reference Network Topology 699 Step1. All the network devices are upgraded to support IPv6. 701 Step 2. According to service demands, only a set of selected PE 702 devices are upgraded to support SRv6 in order to immediately deploy 703 SRv6 overlay VPN services. For instance, in Figure 3, PE1 and PE2 704 are SRv6-enabled. 706 Step 3. Besides the PE devices, some P devices are upgraded to 707 support SRv6 in order to deploy loose TE which enables network path 708 adjustment and optimization. SFC is also a possible service provided 709 by upgrading some of the network devices. 711 Step 4. All the network devices are upgraded to support SRv6. In 712 this case, it is now possible to deploy strict TE, which enables the 713 deterministic networking and other strict security inspection. 715 7. Migration Guidance for SRv6/SR-MPLS Co-existence Scenario 717 As the network migration to SRv6 is progressing, in most cases 718 SRv6-based services and SR-MPLS-based services will coexist. 720 As shown in Figure 6, in the Non-Standalone (NSA) case specified by 721 3GPP Release 15, 5G networks will be supported by existing 4G 722 infrastructure. 4G eNB connects to CSG 2, 5G gNB connects to CSG 1, 723 and EPC connects to RSG 1. 725 To support the 4G services, network services need to be provided 726 between CSG 2 and RSG 1 for interconnecting 4G eNB and EPC, while for 727 the 5G services, network services need to be deployed between CSG 1 728 and RSG 1 for interconnecting 5G gNB and EPC. Meanwhile, to support 729 X2 interface between the eNB and gNB, network services also need to 730 be deployed between the CSG 1 and CSG 2. 732 +-----+ 733 | eNB |------\ 734 +-----+ \ 735 +-----+ 736 |CSG 2|-------+-----+ +-----+ +-----+ 737 /+-----+ |ASG 1|-------------|RSG 1|------| EPC | 738 +-----+ +--/--+ +-----+ +-----+ +-----+ 739 | gNB |-----|CSG 1| Domain 1 | Domain 2 | 740 +-----+ +--\--+ +-----+ +-----+ 741 \+-----+ |ASG 2|-------------|RSG 2| 742 |CSG 3|-------+-----+ +-----+ 743 +-----+ 745 Figure 6. A 3GPP Non-Standalone deployment case 747 As shown in Figure 6, in most of the current network deployments, 748 MPLS-based network services may have already existed between CSG 2 749 and RSG 1 for interconnecting 4G eNB and EPC for 4G services. 751 When 5G services are to be supported, more stringent network services 752 are required, e.g. low latency and high bandwidth. SRv6-based 753 network services could be deployed between CSG 1 and RSG 1 for 754 interconnecting 5G gNB and EPC. 756 In order to perform smooth network migration, a dual-stack solution 757 can be adopted which deploys both SRv6 and MPLS stack in one node. 759 With the dual-stack solution, only CSG 1 and RSG 1 need to be 760 upgraded with SRv6/MPLS dual stack. In this case, CSG 1 can 761 immediately start SRv6-based network services to RSG 1 for support of 762 5G services, but continue to use MPLS-based services to CSG 2 for X2 763 interface communications. The upgrade at CSG 1 will not affect the 764 existing 4G services supported by the MPLS-based network services 765 between CSG 2 and RSG 1. RSG1 can provide MPLS services to CSG2 for 766 4G services as well as SRv6 services to CSG 1 for 5G services. 768 8. Deployment cases 770 With the current network, the launch of leased line service is slow, 771 the network operation and maintainence is complex, and the 772 configuration points are many. SRv6 can solve the issues above. 773 There have already been several successful SRv6 deployments following 774 the incremental deployment guidance shown in Section 3. 776 8.1. China Telecom Si'chuan 778 China Telecom Si'chuan (Si'chuan Telecom) has enabled SRv6 at the PE 779 node of the Magic-Mirror DC in Mei'shan, Cheng'du, Pan'zhihua and 780 other cities. The SRv6 BE tunnel has been deployed through the 163 781 backbone network which has the IPv6 capability. It enables the fast 782 launch of the Magic-Mirror video service, the interconnection of the 783 DCs in various cities, and the isolation of video services. The 784 deployment case is shown in Figure 7. 786 /---------163--------\ 787 +------+ / \ +-------+ 788 | Magic| +----+ +--/-+ +--\-+ +----+ | Magic | 789 |Mirror|----|PE 1|----|CR 1| IP Backbone |CR 2|----|PE 2|----|Mirror | 790 | DC 1 | +----+ +--\-+ +--/-+ +----+ | DC 2 | 791 +------+ \ / +-------+ 792 +-\---+ +---/-+ 793 |ASBR1|----CN2-----|ASBR2| 794 +-----+ +-----+ 796 IGP/IBGP EBGP IGP/IBGP 797 |<------->|<-------------------------->|<-------->| 798 EBGP VPNv4 Peer 799 |<----------------------------------------------->| 800 L3VPN over SRv6 801 |<----------------------------------------------->| 803 Figure 7. China Telecom Si'chuan deployment case 805 As shown in Figure 7, IGP (some cities such as Chengdu deploy ISIS, 806 while other cities such as Panzhihua deploy OSPF) and IBGP are 807 deployed between PE and CR, and EBGP is deployed between CRs of 808 cities in order to advertise the aggregation route. EBGP VPNv4 peers 809 are set up between PEs in different cities to deliver VPN private 810 network routes. 812 The packet enters the SRv6 BE tunnel from the egress PE of DC, and 813 the packet is forwarded according to the Native IP of the 163 814 backbone network. When the packet reaches the peer PE, the SRH is 815 decapsulated, and then the IP packet is forwarded in the VRF 816 according to the service SID (for example, End.DT4). 818 In order to further implement the path selection, ASBRs can be 819 upgraded to support SRv6. Different SRv6 policies are configured on 820 the DC egress PE so that different VPN traffic reaches the peer PE 821 through the 163 backbone network and the CN2 backbone network 822 respectively. 824 8.2. China Unicom 826 China Unicom has deployed SRv6 L3VPN over 169 IPv6 backbone network 827 from Guangzhou to Beijing to provide inter-domain Cloud VPN service. 828 The deployment case is shown in Figure 8. 830 /-------------\ /------------\ /-----------\ 831 +-/-+ Guangzhou +-\-+ +-/-+ IPv6 +-\-+ +-/-+ Beijing +-\-+ 832 |PE1| |CR1|---|CR2| Backbone |CR3|---|CR4| |PE2| 833 +-\-+ Metro +-/-+ +-\-+ 169 +-/-+ +-\-+ Metro +-/-+ 834 \-------------/ \------------/ \-----------/ 836 |<--OSPF/ISIS-->|<-EBGP->|<-Native IPv6->|<-EBGP->|<-OSPF/ISIS->| 837 |<----------------------- EBGP VPNv4 Peer --------------------->| 838 |<----------------------- L3VPN over SRv6 --------------------->| 840 Figure 8. China Unicom SRv6 L3VPN case 842 In Guangzhou and Beijing metro networks, routers exchange basic 843 routing information using IGP(OSPF/ISIS). The prefixes of IPv6 844 loopback address and SRv6 locator of routers are different, and both 845 of them need to be imported into the IGP. The 169 backbone is a 846 native IPv6 network. Between metro and backbone, the border routers 847 establish EBGP peer with each other, e.g. CR1 with CR2, CR3 with 848 CR4, to form basic connectivity. All of these constitute the 849 foundation of overlay services, and have not been changed. 851 PE1 and PE2 establish EBGP peer and advertise VPNv4 routes with each 852 other. If one site connects to two PEs, metro network will use multi 853 RD, community and local preference rules to choose one best route and 854 one backup. 856 After basic routing among networks and VPN routes between the two PEs 857 are all ready, two PEs encapsulate and forward VPN traffic within 858 SRv6 tunnel. The tunnel is SRv6 best effort (BE) tunnel. It 859 introduces only outer IPv6 header but not SRH header into traffic 860 packets. After encapsulation, the packet is treated as common IPv6 861 packet and forwarded to the egress PE, which performs decapsulation 862 and forwards the VPN traffic according to specific VRF. 864 Guangdong Unicom has also lauched the SRv6 L3VPN among Guangzhou, 865 Shenzhen, and Dongguan, which has passed the interop test between 866 different vendors. 868 With SRv6 enabled at the PE devices, the VPN service can be launched 869 very quickly without impact on the existing traffic. With SRv6 TE 870 further deployed, more benefits of using SRv6 can be exploited. 872 8.3. MTN Uganda 874 MTN Uganda has enabled SRv6 at the MPBN PE/P nodes. The SRv6 BE 875 tunnel has been deployed through the MPBN network which has the IPv6 876 capability. It enables the fast service provisoning for mobile 877 service, enterprise service and internal IT services, and also 878 improves service SLA such as service monitoring and availability. 879 The deployment case is shown in Figure 9. 881 +-----+ 882 | eNB |----\ 883 +-----+ \ 884 +-----+ /------------\ 885 |CSG 2|-----+-----+ +-----+ +--/--+ +--\--+ 886 /+-----+ |ASG 1|------|RSG 1|------|ASBR1| |ASBR4| 887 +-----+ +--/--+ IPV6 +-----+ IPV6 +-----+ +-----+ IPV6 +-----+ 888 | gNB |---|CSG 1| Domain 1 | Domain 1 | | Domain 2 | 889 +-----+ +--\--+ +-----+ +-----+ +-----+ IPCORE +-----+ 890 \+-----+ |ASG 2|------|RSG 2|------|ASBR2| |ASBR3| 891 |CSG 3|-----+-----+ +-----+ +--\--+ +--/--+ 892 +-----+ \------------/ 893 |<--------------ISIS------------->|<---EBGP-->|<----ISIS----->| 894 Phase I: 895 |<-----RSVP TE----->|<--RSVP TE-->|<-OPTIONA->|<---SRv6 BE--->| 896 Phase II: 897 |<-----------------L2/3 EVPN over SRv6 Policy --------------->| 898 Figure 9. MTN Uganda Deployment Case 900 As shown in the Figure 9, 902 In the phase I, SRv6 BE was deployed in MPBN network. All services 903 in the MPBN will be carried through SRv6 BE in the core network. The 904 Option A is deployed between the IPRAN network and Core network. 906 In the phase II, SRv6 Policy will be deployed E2E from IPRAN to Core. 907 Cross-domain path selection is available for mobile and enterprise 908 services. The service will be carried in SRv6 Policy through the 909 entire MPBN network. 911 L3VPN and L2VPN services will evolve to EVPN to simplify the network 912 operation and management. 914 9. IANA Considerations 916 There are no IANA considerations in this document. 918 10. Security Considerations 920 TBD. 922 11. Acknowledgement 924 The section on the PSP use cases is inspired from the discussions 925 over the mailing list. The authors would like to acknowledge the 926 constructive discussions from Daniel Voyer, Jingrong Xie, etc.. 928 12. Contributors 930 Hailong Bai 931 China Unicom 932 China 934 Email: 936 Jichun Ma 937 China Unicom 938 China 940 Email: 942 Huizhi Wen 943 Huawei Technologies 944 China 946 Email: wenhuizhi@huawei.com 948 Ruizhao Hu 949 Huawei Technologies 950 China 952 Email: huruizhao@huawei.com 954 Jianwei Mao 955 Huawei 956 China 958 Email: maojianwei@huawei.com 960 13. References 962 13.1. Normative References 964 [I-D.ietf-spring-srv6-network-programming] 965 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 966 Matsushima, S., and Z. Li, "SRv6 Network Programming", 967 draft-ietf-spring-srv6-network-programming-16 (work in 968 progress), June 2020. 970 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 971 Requirement Levels", BCP 14, RFC 2119, 972 DOI 10.17487/RFC2119, March 1997, 973 . 975 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 976 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 977 2006, . 979 [RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi- 980 Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, 981 DOI 10.17487/RFC5659, October 2009, 982 . 984 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 985 (IPv6) Specification", STD 86, RFC 8200, 986 DOI 10.17487/RFC8200, July 2017, 987 . 989 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 990 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 991 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 992 . 994 13.2. Informative References 996 [I-D.ietf-6man-segment-routing-header] 997 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 998 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 999 (SRH)", draft-ietf-6man-segment-routing-header-26 (work in 1000 progress), October 2019. 1002 [I-D.ietf-6man-spring-srv6-oam] 1003 Ali, Z., Filsfils, C., Matsushima, S., Voyer, D., and M. 1004 Chen, "Operations, Administration, and Maintenance (OAM) 1005 in Segment Routing Networks with IPv6 Data plane (SRv6)", 1006 draft-ietf-6man-spring-srv6-oam-05 (work in progress), 1007 June 2020. 1009 [I-D.ietf-ippm-ioam-data] 1010 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 1011 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 1012 P., remy@barefootnetworks.com, r., daniel.bernier@bell.ca, 1013 d., and J. Lemon, "Data Fields for In-situ OAM", draft- 1014 ietf-ippm-ioam-data-09 (work in progress), March 2020. 1016 [I-D.ietf-pce-pcep-flowspec] 1017 Dhody, D., Farrel, A., and Z. Li, "PCEP Extension for Flow 1018 Specification", draft-ietf-pce-pcep-flowspec-09 (work in 1019 progress), June 2020. 1021 [I-D.ietf-rtgwg-segment-routing-ti-lfa] 1022 Litkowski, S., Bashandy, A., Filsfils, C., Decraene, B., 1023 Francois, P., Voyer, D., Clad, F., and P. Camarillo, 1024 "Topology Independent Fast Reroute using Segment Routing", 1025 draft-ietf-rtgwg-segment-routing-ti-lfa-03 (work in 1026 progress), March 2020. 1028 [I-D.ietf-spring-nsh-sr] 1029 Guichard, J., Song, H., Tantsura, J., Halpern, J., 1030 Henderickx, W., Boucadair, M., and S. Hassan, "Network 1031 Service Header (NSH) and Segment Routing Integration for 1032 Service Function Chaining (SFC)", draft-ietf-spring-nsh- 1033 sr-02 (work in progress), April 2020. 1035 [I-D.ietf-spring-sr-service-programming] 1036 Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, 1037 d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., 1038 Henderickx, W., and S. Salsano, "Service Programming with 1039 Segment Routing", draft-ietf-spring-sr-service- 1040 programming-02 (work in progress), March 2020. 1042 [I-D.li-spring-passive-pm-for-srv6-np] 1043 Li, C. and M. Chen, "Passive Performance Measurement for 1044 SRv6 Network Programming", draft-li-spring-passive-pm-for- 1045 srv6-np-00 (work in progress), March 2018. 1047 [I-D.matsushima-spring-srv6-deployment-status] 1048 Matsushima, S., Filsfils, C., Ali, Z., Li, Z., and K. 1049 Rajaraman, "SRv6 Implementation and Deployment Status", 1050 draft-matsushima-spring-srv6-deployment-status-07 (work in 1051 progress), April 2020. 1053 [I-D.song-ippm-postcard-based-telemetry] 1054 Song, H., Zhou, T., Li, Z., Shin, J., and K. Lee, 1055 "Postcard-based On-Path Flow Data Telemetry", draft-song- 1056 ippm-postcard-based-telemetry-07 (work in progress), April 1057 2020. 1059 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 1060 "Network Service Header (NSH)", RFC 8300, 1061 DOI 10.17487/RFC8300, January 2018, 1062 . 1064 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1065 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1066 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1067 July 2018, . 1069 Authors' Addresses 1071 Hui Tian 1072 CAICT 1073 China 1075 Email: tianhui@caict.ac.cn 1077 Feng Zhao 1078 CAICT 1079 China 1081 Email: zhaofeng@caict.ac.cn 1083 Chongfeng Xie 1084 China Telecom 1085 China 1087 Email: xiechf.bri@chinatelecom.cn 1089 Tong Li 1090 China Unicom 1091 China 1093 Email: litong@chinaunicom.cn 1094 Jichun Ma 1095 China Unicom 1096 China 1098 Email: majc16@chinaunicom.cn 1100 Robbins Mwehaire 1101 MTN Uganda Ltd. 1102 Uganda 1104 Email: Robbins.Mwehair@mtn.com 1106 Edmore Chingwena 1107 MTN Group Limited 1108 South Africa 1110 Email: Edmore.Chingwena@mtn.com 1112 Shuping Peng 1113 Huawei Technologies 1114 China 1116 Email: pengshuping@huawei.com 1118 Zhenbin Li 1119 Huawei Technologies 1120 China 1122 Email: lizhenbin@huawei.com 1124 Yaqun Xiao 1125 Huawei Technologies 1126 China 1128 Email: xiaoyaqun@huawei.com