idnits 2.17.1 draft-li-spring-compressed-srv6-np-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 (July 22, 2019) is 1732 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) -- Looks like a reference, but probably isn't: '0' on line 459 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-21 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-01 == Outdated reference: A later version (-04) exists of draft-filsfils-spring-srv6-net-pgm-illustration-00 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING Working Group Z. Li 3 Internet-Draft C. Li 4 Intended status: Standards Track S. Peng 5 Expires: January 23, 2020 Z. Wang 6 B. Liu 7 Huawei Technologies 8 July 22, 2019 10 Compressed SRv6 Network Programming 11 draft-li-spring-compressed-srv6-np-00 13 Abstract 15 Segment Routing can be applied to the IPv6 data plane by leveraging a 16 new type of Routing Extension Header, called Segment Routing 17 Header(SRH). However, the overhead introduced by SRH may be a 18 challenge for the current hardware capability, which would have much 19 effect on the forwarding performance and the payload efficiency. 21 This document defines a compressed SRv6 network programming mechanism 22 in order to reduce the overhead of SRv6 by introducing the Compressed 23 Segment Identifier(C-SID) and the Compressed SRH(C-SRH). The C-SRH 24 can be a new Routing Header or an enhancement of SRH, which is 25 compatible with SRH well. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on January 23, 2020. 44 Copyright Notice 46 Copyright (c) 2019 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 64 3. Compressed SID(C-SID) . . . . . . . . . . . . . . . . . . . . 3 65 4. Compressed Segment Routing Header(C-SRH) . . . . . . . . . . 4 66 5. C-SRH Processing . . . . . . . . . . . . . . . . . . . . . . 7 67 6. Illustration . . . . . . . . . . . . . . . . . . . . . . . . 9 68 6.1. Reference Diagram . . . . . . . . . . . . . . . . . . . . 9 69 6.2. Compressed SRv6 Forwarding Example . . . . . . . . . . . 9 70 7. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 72 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 73 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 75 10.2. Informative References . . . . . . . . . . . . . . . . . 13 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 78 1. Introduction 80 Segment routing (SR) [RFC8402] is a source routing paradigm that 81 explicitly indicates the forwarding path for packets at the ingress 82 node by inserting an ordered list of instructions, called segments. 84 When segment routing is deployed on IPv6 data plane, it is called 85 SRv6 [I-D.ietf-6man-segment-routing-header].An SRv6 Segment ID(SID) 86 is a 128-bit value, and it can be represented as LOC:FUNCT where LOC 87 is the L most significant bits and FUNCT is the 128-L least 88 significant bits [I-D.ietf-spring-srv6-network-programming]. L is 89 called the locator length and is flexible. Each operator is free to 90 use the locator length it chooses. The LOC part of the SID is 91 routable and leads to the node which instantiates that SID. 93 For supporting SR, a new routing header called Segment Routing Header 94 (SRH), which contains a list of SIDs and other information such as 95 Segments Left, has been defined in 96 [I-D.ietf-6man-segment-routing-header]. In use cases like Traffic 97 Engineering, an ordered SID List with multiple SIDs is inserted into 98 the SRH to steer packets in an explicit path. 100 However, the overhead of SIDs(16 bytes per SID) may be a challenge 101 for the current hardware processing capability. The large size of 102 SRH will have much effect on the forwarding performance. Also, when 103 the packet is small, the payload efficiency is not ideal due to the 104 large overhead of SRH. When the packet is large, the large overhead 105 of SRH may also cause the packet to be dropped due to PMTU [RFC8200]. 107 This document defines a compressed SRv6 network programming mechanism 108 to order to reduce the overhead of SRv6 by introducing the Compressed 109 Segment Identifier(C-SID) and the Compressed SRH(C-SRH). The C-SRH 110 can be a new Routing Header or an enhancement of SRH, which is 111 compatible with SRH well. 113 2. Terminology 115 This document makes use of the terms defined in 116 [I-D.ietf-6man-segment-routing-header], [RFC8402] and [RFC8200]. The 117 reader is assumed to be familiar with the terminology defined in 118 them. This document introduce the following terms: 120 C-SRH: Compressed Segment Routing Header 122 C-SID: Compressed Segment Identifier 124 C-Tag: Compressed Tag 126 2.1. Requirements Language 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 130 "OPTIONAL" in this document are to be interpreted as described in BCP 131 14 [RFC2119] [RFC8174] when, and only when, they appear in all 132 capitals, as shown here. 134 3. Compressed SID(C-SID) 136 This document defines a Compressed SID(C-SID) to carry the last N 137 bytes of the original SRv6 SID, which is the different part of the 138 SID comparing with other SIDs in the SID List. 140 N is the length of the common prefix among SIDs in the SID list. The 141 common prefix part contains the common part of Locators in the SID 142 list, while the C-SID contains the different part of Locator and 143 Function ID part of an SRv6 SID. 145 The IPv6 DA contains a 128-bits(16 Bytes) SRv6 SID, and it can be 146 separated as two parts: the common prefix part among all SIDs, and 147 the different part of a specific SID called C-SID that includes the 148 different part of the locator and the Function ID. 150 0 N 16 bytes 151 +--------------------------------------------------------------+ 152 | Common Prefix | C-SID | 153 +--------------------------------------------------------------+ 154 |<----------------- Locator ------------------->|<-FunctionID->| 155 |<--->| 156 | 157 Different part of Locator 159 Figure 1. C-SID in IPv6 DA 161 In this way, the common prefix is carried by the IPv6 DA only, and 162 the SIDs in SID list will not carry the prefix part, but only the 163 different part, the C-SID. 165 Therefore, this document does not define any new types of the SRv6 166 Segment. 168 4. Compressed Segment Routing Header(C-SRH) 170 In order to carry the C-SID, this document defines the Compressed 171 Segment Routing Header (C-SRH). 173 The C-SRH can be a new Routing Header which need to introduce a new 174 Routing type or just an enhancement of SRH (Note: the latter is 175 preferred in the document). 177 The C-SRH provides a more efficient encoding mechanism for SRv6, and 178 it can be compatible with the SRv6 very well. 180 0 1 2 3 181 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | Next Header | Hdr Ext Len | Routing Type | Segments Left| 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Last Entry |E| Flag | C-Tag | Tag | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | Segment List[0](16 - C-Tag bytes) | 188 . ... . 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | Segment List[1](16 - C-Tag bytes) | 191 . ... . 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | ... | 194 . ... . 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | Segment List[n](16 - C-Tag bytes) | 197 . ... . 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 // // 200 // Optional Type Length Value objects (variable) // 201 // // 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 Figure 2. Compressed Segment Routing Header 206 where: 208 o Next Header: Defined in [RFC8200] 210 o Hdr Ext Len: Defined in [RFC8200] 212 o Routing Type: 4 when C-SRH is an enhancement of SRH, or other type 213 when C-SRH is a new Routing Header. 215 o Segments Left: Defined in [RFC8200] 217 o Last Entry: contains the index (zero based), in the Segment List, 218 of the last element of the Segment List. 220 o Flags: 222 0 1 2 3 4 5 6 7 223 +-+-+-+-+-+-+-+-+ 224 |E|U U U U U U U| 225 +-+-+-+-+-+-+-+-+ 227 U: Unused and for future use. MUST be 0 on transmission and 228 ignored on receipt. 230 E: Exclude flag, set when the last SID is excluded in compression. 232 1: the last SID is excluded in compression, and it is 16 233 bytes(128 bits) value 235 0: the last is included in compression, and it is a 236 16 - C-Tag bytes value 238 o C-Tag: 4-bit unsigned integer to indicate the length of the common 239 prefix. Therefore, the length of the C-SID in C-SRH is 16 - C-Tag 240 bytes except the last segment if and only if the E-flag is set. 241 When the C-Tag is 0, means the length of C-SIDs in C-SRH is 16 242 bytes, which is compatible with the SRH 243 [I-D.ietf-6man-segment-routing-header]. 245 o Tag: 12 bits value to tag a packet as part of a class or group of 246 packets, e.g., packets sharing the same set of properties as per 247 [I-D.ietf-6man-segment-routing-header]. 249 o Segment List[0]: 16 bytes (128 bits ) IPv6 address when E-flag is 250 set, and last 16 - C-Tag bytes of SID when E-flag is unset. 252 o Segment List[n]: a compressed SRv6 SID, which is the last 16 - 253 C-Tag bytes value of the original nth SRv6 SID. The Segment List 254 is encoded starting from the last segment of the SR Policy, i.e., 255 the first element of the segment list (Segment List [0]) contains 256 the last segment of the SR Policy, the second element contains the 257 penultimate segment of the SR Policy and so on. 259 o Type Length Value (TLV) are described in 260 [I-D.ietf-6man-segment-routing-header]. 262 In some use cases, the last SID may be a normal SID, which has a 263 different prefix against all other SIDs, so it can be excluded in 264 C-SID generation for better compression. 266 The E-flag indicates whether the last SID is excluded in compression. 267 When E-flag is set, Segment List[0] will carry the original SID, 268 otherwise, it carries the compressed SID, i.e. the last 16 - C-Tag 269 bytes of the original Segment List[0]. 271 5. C-SRH Processing 273 The compressed SID List can be generated by the ingress node itself 274 by comparing the SIDs to get the C-Tag value according to the length 275 of the prefix, and derive the compressed SID list. The compressed 276 SID List can also be generated by the Controller and send to the 277 ingress as well which need to introduce the extra protocol extension. 278 (Note: The former is preferred in the document) 280 When the ingress node applies SRv6 policy to packets, a C-SRH can be 281 encapsulated in a new IPv6 header(Encapsulation Mode). The first SID 282 is carried in the DA, and the different parts of all SIDs, as known 283 as C-SIDs, are carried in the SID List of C-SRH. The last SID is 284 inserted according to the E-flag. 286 When an SRv6 endpoint node receives the packets, the node will follow 287 the same processing procedure of SRH, that is, to inspect whether the 288 DA is a local SID or not, if yes, then process the SID according to 289 its function. Otherwise, it will perform regular IPv6 forwarding. 291 When DA is a local SID, then the node will process the C-SRH and the 292 C-SIDs. 294 In C-SID processing, the C-SID will be updated to the IPv6 DA to 295 replace the last 16 - C-Tag bytes. Regarding the last SID, if the 296 E-flag is set, the entire 128 bit of Segment List[0] is updated to 297 IPv6 DA. Otherwise, the C-SID will be updated to replace the last 16 298 - C-Tag bytes of IPv6 DA. After updating the IPv6 DA, the packet 299 will be forwarded accordingly. 301 The pseudo code of C-SRH processing is shown below. 303 01. When a C-SRH is processed { 304 02. If Segments Left is equal to zero { 305 03. Proceed to process the next header in the packet, 306 whose type is identified by the Next Header field in 307 the Routing header. 308 04. } 309 05. Else { 310 06. If local configuration requires TLV processing { 311 07. Perform TLV processing 312 08. } 313 09. If E-flag is set: 314 10. max_last_entry = (Hdr Ext Len - 8 - C-Tag)/(16 - C-Tag) 315 11. Else: 316 12. max_last_entry = (Hdr Ext Len - 8)/(16 - C-Tag) 317 13. If ((Last Entry > max_last_entry) or 318 14. (Segments Left is greater than (Last Entry+1)) { 319 15. Send an ICMP Parameter Problem, Code 0, message to 320 the Source Address, pointing to the Segments Left 321 field, and discard the packet. 322 16. } 323 17. Else { 324 18. Decrement Segments Left by 1. 325 19. if Segments Left > 0 or Segments Left = 0 and E-flag = 0: 326 20. // Update the C-SID to the DA 327 21. Copy Segment List[Segments Left] from the SRH to 328 replace the last 16 - C-Tag bytes of 329 destination address of the IPv6 header. 330 22. else: 331 23. // Segment Left = 0 and E-flag = 1 332 // Segment List[0] is a 16 bytes value. 333 24. Copy Segment List[Segments Left] from the SRH to 334 destination address of the IPv6 header. 335 25. If the IPv6 Hop Limit is less than or equal to 1 { 336 26. Send an ICMP Time Exceeded -- Hop Limit Exceeded in 337 Transit message to the Source Address and discard 338 the packet. 339 27. } 340 28. Else { 341 29. Decrement the Hop Limit by 1 342 30. Resubmit the packet to the IPv6 module for 343 transmission to the new destination. 344 31. } 345 32. } 346 33. } 347 34. } 349 6. Illustration 351 This section describes a simple example to illustrate the usage of 352 C-SID. Similar to [I-D.filsfils-spring-srv6-net-pgm-illustration], 353 in order to ease the reading of the example, we introduce a simple 354 reference diagram and simplified SID allocations. 356 6.1. Reference Diagram 358 Nodes 1 - 8 are SRv6 enabled nodes within the network domain. 360 Nodes CE1, CE2, and CE3 are outside the domain. 362 CE1 and CE2 are tenants of VPN 100. 364 Nodes 1 and 8 act as PE respectively to nodes CE1 and CE3. 366 All the links within the domain have the same IGP metric. 368 The IGP metric shortest-path from 1 to 8 is 1-2-7-8, while the 369 latency-metric shortest-path from 1 to 8 is 1-2-3-4-5-6-7-8. 371 CE2 372 \ 373 4------5 374 | | 375 +-----3------6 376 | | / | 377 | | / | 378 | |/ | 379 Tenant100 CE1---1-----2------7---8---CE3 Tenant100 with 380 IPv4 20/8 382 Figure 3: Reference topology 384 6.2. Compressed SRv6 Forwarding Example 386 This section describes a simple example to show how efficient C-SRH 387 can reduce the overhead of SRv6. 389 In order to ease the reading of the example, it is better to 390 introduce a simplified SID allocations. We assume: 392 o B::/112 is dedicated to the internal SRv6 SID space, which is the 393 common prefix. Therefore the C-SID is a 16-bits value. 395 o A locator expressed in 120 bits and a function expressed in 8 396 bits. 398 o Node k has B::k/120 for its local SID space. Its SIDs will be 399 explicitly allocated from that block. 401 o Node k advertises B::k/120 in its IGP. 403 o Function ::1 (function 1, for short) represents the End function 404 with PSP support. 406 o B::k::1 represents the End function with PSP support allocated by 407 node K, such as B::6::1 represents the End function with PSP 408 support allocated by node 6. 410 o B::8::D100 is an END.DT4 SID initiated by node 8, which is 411 associated with the VRF100. 413 In SRH based SRv6, the PE 1 encapsulates the packets (CE1, CE3) from 414 CE1 to CE3 in an outer IPv6 header with DA = B::3::1 and SRH 415 (B::8::D100, B::7::1, B::6::1, B::5::1, B::4::1, B::3::1, B::2::1; 416 SL=6; NH=4). 418 419 follows the latency-metric shortest-path. The total length of SRH is 420 8+16*7=120 bytes. 422 In Compressed SRv6, PE 1 encapsulates (CE1, CE3) in an outer IPv6 423 header with DA = B::2::1 and C-SRH (B::8::D100, 7::1, 6::1, 5::1, 424 4::1, 3::1, 2::1, SL=6; NH=4) with E-flag set. The C-Tag is 14, 425 since the length of same prefix is 112 bits. Therefore, the total 426 length of C-SRH is 8 + (16-14)*6 + 16 = 36 bytes, then 84 bytes are 427 reduced meaning 70% size of the SRv6 overhead or 87.5% of SIDs 428 (except the last SID) overhead are reduced. 430 The packet leaves node 1 to node 2 according to the FIB associated 431 with the IPv6 DA B::2::1. The packet leaves node 1 can be present as 433 (A::1, B::2::1) 434 (B::8::D100, 7::1, 6::1, 5::1, 4::1, 3::1, 2::1, SL=6; NH=4) 435 (X, Y) 437 When 2 receives the packet, 2 matches B::2::1 in its "My SID Table" 438 and executes the END function behavior to update the IPv6 DA. Since 439 the updated SL is greater than 0, and the C-Tag is 14, then it copies 440 the C-SID that is a 2 bytes value to replace the last 2 bytes of IPv6 441 DA, and then forward the packet according the new IPv6 DA B::3::1. 442 The packet leaves node 2 can be present as 443 (A::1, B::3::1) 444 (B::8::D100, 7::1, 6::1, 5::1, 4::1, 3::1, 2::1, SL=5; NH=4) 445 (X, Y) 447 Similar to node 2, the node 3, 4, 5, and 6 performs the END function 448 behavior to update the IPv6 DA with the corresponding C-SID and then 449 forward the packet by looking up FIB accordingly. Therefore, the 450 packet leaves node 6 can be present as 452 (A::1, B::7::1) 453 (B::8::D100, 7::1, 6::1, 5::1, 4::1, 3::1, 2::1, SL=1; NH=4) 454 (X, Y) 456 When 7 receives the packet, 7 matches B::7::1 in its "My SID Table" 457 and executes the END function behavior to update the IPv6 DA. Since 458 the updated SL is 0 and E-flag is set, then the 128-bits Segment 459 List[0] is copied to the IPv6 DA. Also, the C-SRH is popped since 460 the B::7::1 is an END SID with PSP flavor. Node 7 then performs a 461 lookup on the updated IPv6 DA B::8::D100 to forward the packet along 462 the shortest path to node 8. The packet leaves node 8 can be present 463 as 465 (A::1, B::8::D100) 466 (X, Y) 468 When 8 receives the packet, 8 matches B::8::D100 in its "My SID 469 Table" and executes the END.DT4 function behavior to sends the IP 470 packet (CE1, CE3) to its VPN destination. 472 This example illustrates the procedure of C-SRH based SRv6 473 forwarding, it shows that the longer prefix can reduce more overhead 474 of SRv6. More benefits are described in the section 7. 476 7. Benefits 478 1. Seamless integration with SRv6 Network Programming 480 o No new type(Functions, such as END) of SRv6 SIDs is defined. 481 A C-SID is a sub-set of an SRv6 SID. 483 o Neither redefines the IPv6 address space nor requires any 484 specific IPv6 space. 486 2. Supporting Full Set Functionalities of SRv6 488 o Full set functionalities of SRv6(BE,Loose TE and strict TE,etc.) 489 are supported without any extra routes advertisements. 491 o Function ID information is maintained. 493 3. Control-Plane friendly 495 o No need to make any extensions in Control-Plane to 496 advertise new type of SIDs or binding information. 498 o No indexed mapping table is required 500 o No routing extension is required. 502 o No new routes advertisement is required if without new Locators 504 4. Hardware-friendly 506 o Hardware has the mature capability to overwrite the IPv6 DA. 508 o Avoids any extra lookup in indexed mapping table 510 5. Efficient MTU overhead 512 o C-SRH has the smallest MTU overhead among alternative solutions 513 (VxLAN with SR-MPLS, CRH, uSID), When all the Segment endpoint 514 nodes information is maintained in the packet. 516 6. Scalable SR TE 518 o 8 C-SIDs can be carried in 128 bits when C-SID is 16 bits value 520 o 16 Segment endpoint nodes (1 in DA and 16 in C-SRH including 521 the one in DA) in 40 bytes of overhead. 522 o T.Encaps with a C-SRH of 40 bytes (8 fixed + 2 * 16 523 bytes) 525 o ALL C-SIDs are maintained in C-SRH, which can be used 526 for recording the explicit routing path. 528 7. Saving IPv6 address 530 o Very limited IPv6 address are needed for SID space. Longer 531 Common Prefix means smaller IPv6 address burning and 532 smaller overhead of SRv6. 534 o Very easy to meet the requirement of C-SRH since any operator 535 or person can offer a 112/, 80/ or even 64/ prefix. 537 8. IANA Considerations 539 TBD 541 9. Security Considerations 543 TBD 545 10. References 547 10.1. Normative References 549 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 550 Requirement Levels", BCP 14, RFC 2119, 551 DOI 10.17487/RFC2119, March 1997, 552 . 554 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 555 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 556 May 2017, . 558 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 559 (IPv6) Specification", STD 86, RFC 8200, 560 DOI 10.17487/RFC8200, July 2017, 561 . 563 [I-D.ietf-6man-segment-routing-header] 564 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 565 Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment 566 Routing Header (SRH)", draft-ietf-6man-segment-routing- 567 header-21 (work in progress), June 2019. 569 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 570 Decraene, B., Litkowski, S., and R. Shakir, "Segment 571 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 572 July 2018, . 574 10.2. Informative References 576 [I-D.ietf-spring-srv6-network-programming] 577 Filsfils, C., Camarillo, P., Leddy, J., 578 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 579 Network Programming", draft-ietf-spring-srv6-network- 580 programming-01 (work in progress), July 2019. 582 [I-D.filsfils-spring-srv6-net-pgm-illustration] 583 Filsfils, C., Camarillo, P., Li, Z., Matsushima, S., 584 Decraene, B., Steinberg, D., Lebrun, D., Raszuk, R., and 585 J. Leddy, "Illustrations for SRv6 Network Programming", 586 draft-filsfils-spring-srv6-net-pgm-illustration-00 (work 587 in progress), February 2019. 589 Authors' Addresses 591 Zhenbin Li 592 Huawei Technologies 593 Huawei Campus, No. 156 Beiqing Rd. 594 Beijing 100095 595 China 597 Email: lizhenbin@huawei.com 599 Cheng Li 600 Huawei Technologies 601 Huawei Campus, No. 156 Beiqing Rd. 602 Beijing 100095 603 China 605 Email: chengli13@huawei.com 607 Shuping Peng 608 Huawei Technologies 609 Huawei Campus, No. 156 Beiqing Rd. 610 Beijing 100095 611 China 613 Email: pengshuping@huawei.com 615 Zhongzheng Wang 616 Huawei Technologies 617 Huawei Campus, No. 156 Beiqing Rd. 618 Beijing 100095 619 China 621 Email: wangzhongzhen@huawei.com 622 Bing Liu 623 Huawei Technologies 624 Huawei Campus, No. 156 Beiqing Rd. 625 Beijing 100095 626 China 628 Email: remy.liubing@huawei.com