idnits 2.17.1 draft-bonica-6man-comp-rtg-hdr-09.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 3 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 20, 2019) is 1612 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 668 -- Looks like a reference, but probably isn't: '1' on line 669 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6man R. Bonica 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track Y. Kamite 5 Expires: May 23, 2020 NTT Communications Corporation 6 T. Niwa 7 KDDI 8 A. Alston 9 D. Henriques 10 Liquid Telecom 11 L. Jalil 12 Verizon 13 N. So 14 F. Xu 15 Reliance Jio 16 G. Chen 17 Baidu 18 Y. Zhu 19 China Telecom 20 Y. Zhou 21 ByteDance 22 November 20, 2019 24 The IPv6 Compressed Routing Header (CRH) 25 draft-bonica-6man-comp-rtg-hdr-09 27 Abstract 29 This document defines two new IPv6 Routing header types. 30 Generically, they are called the Compressed Routing Header (CRH). 31 More specifically, the 16-bit version of the CRH is called the CRH- 32 16, while the 32-bit version of the CRH is called the CRH-32. SRm6 33 nodes use the CRH to steer packets from segment to segment along SRm6 34 paths. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on May 23, 2020. 53 Copyright Notice 55 Copyright (c) 2019 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (https://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 72 3. The Compressed Routing Header (CRH) . . . . . . . . . . . . . 3 73 4. The Segment Forwarding Information Base (SFIB) . . . . . . . 5 74 5. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 5 75 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 5.2. CRH Specific . . . . . . . . . . . . . . . . . . . . . . 6 77 5.2.1. Computing Minimum CRH Length . . . . . . . . . . . . 7 78 5.2.2. Topological Instructions That Control Adjacency 79 Segments . . . . . . . . . . . . . . . . . . . . . . 8 80 5.2.3. Topological Instructions That Control Node Segments . 9 81 5.2.4. Topological Instructions That Control Binding 82 Segments . . . . . . . . . . . . . . . . . . . . . . 9 83 6. Mutability . . . . . . . . . . . . . . . . . . . . . . . . . 10 84 7. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . 10 85 8. Management Considerations . . . . . . . . . . . . . . . . . . 10 86 9. ICMPv6 Considerations . . . . . . . . . . . . . . . . . . . . 10 87 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 88 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 89 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 90 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 91 13.1. Normative References . . . . . . . . . . . . . . . . . . 11 92 13.2. Informative References . . . . . . . . . . . . . . . . . 12 93 Appendix A. CRH Processing Examples . . . . . . . . . . . . . . 12 94 A.1. SR Path Contains Node Segments Only . . . . . . . . . . . 14 95 A.2. SR Path Contains Node Segments Only And Preserves The 96 First SID . . . . . . . . . . . . . . . . . . . . . . . . 14 97 A.3. SR Path Contains Adjacency Segments Only . . . . . . . . 15 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 100 1. Introduction 102 This document defines two new IPv6 [RFC8200] Routing header types. 103 Generically, they are called the Compressed Routing Header (CRH). 104 More specifically, the 16-bit version of the CRH is called the CRH- 105 16, while the 32-bit version of the CRH is called the CRH-32. SRm6 106 [I-D.bonica-spring-srv6-plus] nodes use the CRH to steer packets from 107 segment to segment along SRm6 paths. 109 For details regarding SRm6 paths, segments, Segment Identifiers 110 (SIDs) and instructions, see [I-D.bonica-spring-srv6-plus]. 112 2. Requirements Language 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 116 "OPTIONAL" in this document are to be interpreted as described in BCP 117 14 [RFC2119] [RFC8174] when, and only when, they appear in all 118 capitals, as shown here. 120 3. The Compressed Routing Header (CRH) 122 Both CRH versions (i.e., CRH-16 and CRH-32) contain the following 123 fields: 125 o Next Header - Defined in [RFC8200]. Identifies the type of header 126 immediately following the CRH. 128 o Hdr Ext Len - Defined in [RFC8200]. Length of the CRH in 8-octet 129 units, not including the first 8 octets. 131 o Routing Type - Defined in [RFC8200]. Value TBD by IANA. (For 132 CRH-16, the suggested value is 5. For CRH-32, the suggested value 133 is 6.) 135 o Segments Left - Defined in [RFC8200]. Number of route segments 136 remaining, i.e., number of explicitly listed intermediate nodes 137 still to be visited before reaching the final destination. 139 o SID List - Represents the SRm6 path as an ordered list of SIDs. 140 SIDs are listed in reverse order, with SID[0] representing the 141 final segment, SID[1] representing the penultimate segment, and so 142 forth. SIDs are listed in reverse order so that Segments Left can 143 be used as an index to the SID List. The SID indexed by Segments 144 Left is called the current SID. 146 In the CRH-16 (Figure 1), each SID list entry is encoded in 16-bits. 147 In the CRH-32 (Figure 2), each SID list entry is encoded in 32-bits. 148 In networks where the smallest feasible Maximum SID Value (MSV) 149 [I-D.bonica-spring-srv6-plus] is greater than 65,535, CRH-32 is 150 required. Otherwise, CRH-16 is preferred. 152 When choosing between the CRH-16 and CRH-32, network operators should 153 consider average size of packets on their network. If short (e.g., 154 voice) packets constitute a significant portion of network traffic, 155 the overhead associated with the CRH-32 may be significant. 156 Therefore, the network operator should consider the CRH-16. 158 In all cases, the CRH MUST end on a 64-bit boundary. Therefore, the 159 CRH MAY be padded with zeros. 161 0 1 2 3 162 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 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | SID[0] | SID[1] | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 168 | ......... 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 171 Figure 1: CRH-16 173 0 1 2 3 174 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 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 + SID[0] + 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 + SID[1] + 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 // // 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 + SID[n] + 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 Figure 2: CRH-32 189 4. The Segment Forwarding Information Base (SFIB) 191 A segment ingress node maintains one Segment Forwarding Information 192 Base (SFIB) entry for each segment that it originates. Each SFIB 193 entry contains the following information: 195 o A SID. 197 o A segment type. 199 o Topological instruction parameters. 201 The following are valid segment types: 203 o Adjacency. 205 o Node. 207 o Binding. 209 The following parameters are associated with topological instructions 210 that control adjacency segments: 212 o An IPv6 address that identifies an interface on the segment egress 213 node. 215 o An interface identifier. 217 Node segments are associated with a single topological instruction 218 parameter. This parameter is an IPv6 address that identifies an 219 interface on the segment egress node. 221 The following parameters are associated with topological instructions 222 that control binding segments: 224 o An IPv6 address that identifies an interface on the first segment 225 egress node in the binding segment. 227 o A SID list length. 229 o A SID list. 231 5. Processing Rules 232 5.1. General 234 [RFC8200] defines rules that apply to IPv6 extension headers, in 235 general, and IPv6 Routing headers, in particular. All of these rules 236 apply to the CRH. 238 For example: 240 o Extension headers (except for the Hop-by-Hop Options header) are 241 not processed, inserted, or deleted by any node along a packet's 242 delivery path, until the packet reaches the node (or each of the 243 set of nodes, in the case of multicast) identified in the 244 Destination Address field of the IPv6 header. 246 o If, while processing a received packet, a node encounters a 247 Routing header with an unrecognized Routing Type value, the 248 required behavior of the node depends on the value of the Segments 249 Left field. If Segments Left is zero, the node must ignore the 250 Routing header and proceed to process the next header in the 251 packet, whose type is identified by the Next Header field in the 252 Routing header. If Segments Left is non-zero, the node must 253 discard the packet and send an ICMPv6 [RFC4443] Parameter Problem, 254 Code 0, message to the packet's Source Address, pointing to the 255 unrecognized Routing Type. 257 o If, after processing a Routing header of a received packet, an 258 intermediate node determines that the packet is to be forwarded 259 onto a link whose link MTU is less than the size of the packet, 260 the node must discard the packet and send an ICMPv6 Packet Too Big 261 message to the packet's Source Address. 263 5.2. CRH Specific 265 When a node recognizes and processes a CRH, it executes the following 266 procedure: 268 o If the IPv6 Source Address is a link-local address, discard the 269 packet. 271 o If the IPv6 Source Address is a multicast address, discard the 272 packet. 274 o If Segments Left equals 0, skip over the CRH and process the next 275 header in the packet. 277 o If Hdr Ext Len indicates that the CRH is larger than the 278 implementation can process, discard the packet and send an ICMPv6 279 Parameter Problem, Code 0, message to the Source Address, pointing 280 to the Hdr Ext Len field. 282 o Compute L, the minimum CRH length (See (Section 5.2.1)). 284 o If L is greater than Hdr Ext Len, discard the packet and send an 285 ICMPv6 Parameter Problem, Code 0, message to the Source Address, 286 pointing to the Segments Left field. 288 o Decrement the packet's Hop Count. 290 o If the Hop Count has expired, discard the packet and send an 291 ICMPv6 Time Expired message to the packet's source node. 293 o Decrement Segments Left 295 o Search for the current SID in the SFIB. 297 o If the above-mentioned search does not return an SFIB entry, 298 discard the packet and send an ICMPv6 Parameter Problem, Code 0, 299 message to the Source Address, pointing to the current SID. 301 o If the above-mentioned search returns an SFIB entry that 302 represents an adjacency segment, execute the topological 303 instruction described in Section 5.2.2. 305 o If the above-mentioned search returns an SFIB entry that 306 represents a node segment, execute the topological instruction 307 described in Section 5.2.3. 309 o If the above-mentioned search returns an SFIB entry that 310 represents a binding segment, execute the topological instruction 311 described in Section 5.2.4. 313 The above stated rules are demonstrated in Appendix A. 315 5.2.1. Computing Minimum CRH Length 317 The algorithm described in this section accepts the following CRH 318 fields as its input parameters: 320 o Routing Type (i.e., CRH-16 or CRH-32). 322 o Segments Left. 324 It yields L, the minimum CRH length. The minimum CRH length is 325 measured in 8-octet units, not including the first 8 octets. 327 329 switch(Routing Type) { 330 case CRH-16: 331 if (Segments Left <= 2) 332 return(0) 333 sidsBeyondFirstWord = Segments Left - 2; 334 sidPerWord = 4; 335 case CRH-32: 336 if (Segments Left <= 1) 337 return(0) 338 sidsBeyondFirstWord = Segments Left - 1; 339 sdsPerWord = 2; 340 case default: 341 return(0xFF); 342 } 344 words = sidsBeyondFirstWord div sidsPerWord; 345 if (sidsBeyondFirstWord mod sidsPerWord) 346 words++; 348 return(words) 350 352 5.2.2. Topological Instructions That Control Adjacency Segments 354 A topological instruction that controls an adjacency segment accepts 355 the following parameters: 357 o An IPv6 address that identifies an interface on the segment egress 358 node. 360 o An interface identifier. 362 The instruction behaves as follows: 364 o If the interface that was received as a parameter is not 365 operational, discard the packet and send an ICMPv6 Destination 366 Unreachable message (Code: 5, Source Route Failed) to the packet's 367 source node. 369 o Overwrite the packet's Destination Address with the IPv6 address 370 that was received as a parameter. 372 o Forward the packet through the above-mentioned interface. 374 5.2.3. Topological Instructions That Control Node Segments 376 A topological instruction that controls a node segment accepts a 377 single parameter. This parameter is an IPv6 address that identifies 378 an interface on the segment egress node. 380 The instruction behaves as follows: 382 o If the segment ingress node does not have a viable route to the 383 IPv6 address included as a parameter, discard the packet and send 384 an ICMPv6 Destination Unreachable message (Code:1 Net Unreachable) 385 to the packet's source node. 387 o Overwrite the packet's Destination Address with the destination 388 address that was included as a parameter. 390 o Forward the packet to the next hop along the least cost path to 391 the segment egress node. If there are multiple least cost paths 392 to the segment egress node (i.e., Equal Cost Multipath), execute 393 procedures so that all packets belonging to a flow are forwarded 394 through the same next hop. 396 5.2.4. Topological Instructions That Control Binding Segments 398 A topological instruction that controls an binding segment accepts 399 the following parameters: 401 o An IPv6 address that identifies an interface on the first segment 402 egress node in the binding segment. 404 o A SID list length. 406 o A SID list. 408 The instruction behaves as follows: 410 o If the segment ingress node does not have a viable route to the 411 IPv6 address received as a parameter, discard the packet and send 412 an ICMPv6 Destination Unreachable message (Code:1 Net Unreachable) 413 to the packet's source node. 415 o Prepend a CRH to the packet. Copy the SID list length, received 416 as a parameter, to the CRH Segments Left field. Also copy the SID 417 list, received as a parameter, to the CRH SID list. 419 o Prepend an IPv6 header to the packet. Copy the IPv6 address, 420 received as a parameter, to the IPv6 Destination Address. 422 o Forward the packet to the next hop along the least cost path to 423 the IPv6 address received as a parameter. If there are multiple 424 least cost paths to the IPv6 address received as a parameter 425 (i.e., Equal Cost Multipath), execute procedures so that all 426 packets belonging to a flow are forwarded through the same next 427 hop. 429 6. Mutability 431 In the CRH, the Segments Left field is mutable. All remaining fields 432 are immutable. 434 7. Compliance 436 In order to be compliant with this specification, an SRm6 437 implementation MUST: 439 o Be able to process IPv6 options as described in Section 4.2 of 440 [RFC8200]. 442 o Be able to process the Routing header as described in Section 4.4 443 of [RFC8200]. 445 o Support the CRH-16 and the CRH-32. 447 8. Management Considerations 449 PING and TRACEROUTE [RFC2151] both operate correctly in the presence 450 of the CRH. 452 9. ICMPv6 Considerations 454 SRm6 implementations MUST comply with the ICMPv6 processing rules 455 specified in Section 2.4 of [RFC4443]. For example: 457 o An SRm6 implementation MUST NOT originate an ICMPv6 error message 458 in response to another ICMPv6 error message. 460 o An SRm6 implementation MUST rate limit the ICMPv6 messages that it 461 originates. 463 10. Security Considerations 465 SRm6 domains MUST NOT span security domains. In order to enforce 466 this requirement, security domain edge routers MUST do one of the 467 following: 469 o Discard all inbound SRm6 packets whose IPv6 destination address 470 represents domain infrastructure. 472 o Authenticate [RFC4302] [RFC4303] all inbound SRm6 packets whose 473 IPv6 destination address represents domain infrastructure. 475 11. IANA Considerations 477 IANA is requested to make the following entries in the Internet 478 Protocol Version 6 (IPv6) Parameters "Routing Type" registry: 480 Suggested 481 Value Description Reference 482 ----------------------------------------------------------------------- 483 5 Compressed Routing Header (16-bit) (CRH-16) This document 484 6 Compressed Routing Header (32-bit) (CRH-32) This document 486 12. Acknowledgements 488 Thanks to Naveen Kottapalli, Joel Halpern, Tony Li, Gerald Schmidt, 489 Nancy Shaw, and Chandra Venkatraman for their comments. 491 13. References 493 13.1. Normative References 495 [I-D.bonica-spring-srv6-plus] 496 Bonica, R., Hegde, S., Kamite, Y., Alston, A., Henriques, 497 D., Jalil, L., Halpern, J., Linkova, J., and G. Chen, 498 "Segment Routing Mapped To IPv6 (SRm6)", draft-bonica- 499 spring-srv6-plus-06 (work in progress), October 2019. 501 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 502 Requirement Levels", BCP 14, RFC 2119, 503 DOI 10.17487/RFC2119, March 1997, 504 . 506 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 507 DOI 10.17487/RFC4302, December 2005, 508 . 510 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 511 RFC 4303, DOI 10.17487/RFC4303, December 2005, 512 . 514 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 515 Control Message Protocol (ICMPv6) for the Internet 516 Protocol Version 6 (IPv6) Specification", STD 89, 517 RFC 4443, DOI 10.17487/RFC4443, March 2006, 518 . 520 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 521 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 522 May 2017, . 524 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 525 (IPv6) Specification", STD 86, RFC 8200, 526 DOI 10.17487/RFC8200, July 2017, 527 . 529 13.2. Informative References 531 [RFC2151] Kessler, G. and S. Shepard, "A Primer On Internet and TCP/ 532 IP Tools and Utilities", FYI 30, RFC 2151, 533 DOI 10.17487/RFC2151, June 1997, 534 . 536 Appendix A. CRH Processing Examples 538 This appendix demonstrates CRH processing in the following scenarios: 540 o SR path contains node segments only (Appendix A.1). 542 o SR path contains node segments only and preserves the first SID 543 (Appendix A.2). 545 o SR path contains adjacency segments only (Appendix A.3). 547 ----------- 548 2001:db8:0:2/64 |Node: I2 | 2001:db8:0:4/64 549 ----------------------|Loopback: |-------------------- 550 | ::2 |2001:db8::2| ::1 | 551 | ----------- | 552 | ::1 :: 2| 553 ----------- ----------- ----------- 554 |Node: S |2001:db8:0:1/64|Node: I1 |2001:db8:0:3/64|Node: I3 | 555 |Loopback |---------------|Loopback: |---------------|Loopback: | 556 |2001:db8::a| ::1 ::2 |2001:db8::1| ::1 ::2 |2001:db8::3| 557 ----------- ----------- ----------- 558 | ::1 559 ----------- | 560 |Node: D | 2001:db8:0:b/64 | 561 |Loopback: |--------------------- 562 |2001:db8::b| ::2 563 ----------- 565 Figure 3: Reference Topology 567 Figure 3 provides a reference topology that is used in all examples. 569 +--------------------+-----+--------------+--------------+ 570 | Instantiating Node | SID | Segment Type | IPv6 Address | 571 +--------------------+-----+--------------+--------------+ 572 | All | 1 | Node | 2001:db8::1 | 573 | All | 2 | Node | 2001:db8::2 | 574 | All | 3 | Node | 2001:db8::3 | 575 | All | 10 | Node | 2001:db8::a | 576 | All | 11 | Node | 2001:db8::b | 577 +--------------------+-----+--------------+--------------+ 579 Table 1: Node SIDs 581 Table 1 describes SFIB entries that are instantiated on all nodes. 582 All of these SFIB entries represent node segments. 584 +--------------------+-----+-----------------+-----------+ 585 | Instantiating Node | SID | IPv6 Address | Interface | 586 +--------------------+-----+-----------------+-----------+ 587 | S | 129 | 2001:db8:0:1::2 | S -> I1 | 588 | S | 130 | 2001:db8:0:2::2 | S -> I2 | 589 | I1 | 129 | 2001:db8:0:3::2 | I1 -> I3 | 590 | I2 | 129 | 2001:db8:0:4::2 | I2 -> I3 | 591 | I3 | 129 | 2001:db8:0:b::2 | I3 -> D | 592 +--------------------+-----+-----------------+-----------+ 594 Table 2: Adjacency SIDs 596 Table 2 describes SFIB entries that are instantiated on specific 597 nodes. All of these SFIB entries represent adjacency segments. 599 A.1. SR Path Contains Node Segments Only 601 In this example, Node S sends a packet to Node D, though a node 602 segment that terminates on I3. In this example, I3 does not appear 603 in the CRH segment list. Therefore, the destination node may not be 604 able to send return traffic through the same path. 606 +-------------------------------------+-------------------+ 607 | As the packet travels from S to I3: | | 608 +-------------------------------------+-------------------+ 609 | Source Address = 2001:db8::a | Segments Left = 1 | 610 | Destination Address = 2001:db8::3 | SID[0] = 11 | 611 +-------------------------------------+-------------------+ 613 +-------------------------------------+-------------------+ 614 | As the packet travels from I3 to D: | | 615 +-------------------------------------+-------------------+ 616 | Source Address = 2001:db8::a | Segments Left = 0 | 617 | Destination Address = 2001:db8::b | SID[0] = 11 | 618 +-------------------------------------+-------------------+ 620 A.2. SR Path Contains Node Segments Only And Preserves The First SID 622 In this example, Node S sends a packet to Node D, through a node 623 segment that terminates on I3. In this example, I3 appears in the 624 CRH segment list. Therefore, the destination node can send return 625 traffic through the same path. 627 +-------------------------------------+-------------------+ 628 | As the packet travels from S to I3: | | 629 +-------------------------------------+-------------------+ 630 | Source Address = 2001:db8::a | Segments Left = 1 | 631 | Destination Address = 2001:db8::3 | SID[0] = 11 | 632 | | SID[1] = 3 | 633 +-------------------------------------+-------------------+ 635 +-------------------------------------+-------------------+ 636 | As the packet travels from I3 to D: | | 637 +-------------------------------------+-------------------+ 638 | Source Address = 2001:db8::a | Segments Left = 0 | 639 | Destination Address = 2001:db8::b | SID[0] = 11 | 640 | | SID[1] = 3 | 641 +-------------------------------------+-------------------+ 643 A.3. SR Path Contains Adjacency Segments Only 645 In this example, Node S sends a packet to Node D, via two adjacency 646 segments.. 648 +---------------------------------------+-------------------+ 649 | As the packet travels from S to I1: | | 650 +---------------------------------------+-------------------+ 651 | Source Address = 2001:db8::a | Segments Left = 2 | 652 | Destination Address = 2001:db8:0:1::2 | SID[0] = 129 | 653 | | SID[1] = 129 | 654 +---------------------------------------+-------------------+ 656 +---------------------------------------+-------------------+ 657 | As the packet travels from I1 to I3: | | 658 +---------------------------------------+-------------------+ 659 | Source Address = 2001:db8::a | Segments Left = 1 | 660 | Destination Address = 2001:db8:0:3::2 | SID[0] = 129 | 661 | | SID[1] = 129 | 662 +---------------------------------------+-------------------+ 664 +---------------------------------------+-------------------+ 665 | As the packet travels from I3 to D: | | 666 +---------------------------------------+-------------------+ 667 | Source Address = 2001:db8::a | Segments Left = 0 | 668 | Destination Address = 2001:db8:0:b::2 | SID[0] = 129 | 669 | | SID[1] = 129 | 670 +---------------------------------------+-------------------+ 672 Authors' Addresses 674 Ron Bonica 675 Juniper Networks 676 2251 Corporate Park Drive 677 Herndon, Virginia 20171 678 USA 680 Email: rbonica@juniper.net 682 Yuji Kamite 683 NTT Communications Corporation 684 3-4-1 Shibaura, Minato-ku 685 Tokyo 108-8118 686 Japan 688 Email: y.kamite@ntt.com 689 Tomonobu Niwa 690 KDDI 691 3-22-7, Yoyogi, Shibuya-ku 692 Tokyo 151-0053 693 Japan 695 Email: to-niwa@kddi.com 697 Andrew Alston 698 Liquid Telecom 699 Nairobi 700 Kenya 702 Email: Andrew.Alston@liquidtelecom.com 704 Daniam Henriques 705 Liquid Telecom 706 Johannesburg 707 South Africa 709 Email: daniam.henriques@liquidtelecom.com 711 Luay Jalil 712 Verizon 713 Richardson, Texas 714 USA 716 Email: luay.jalil@one.verizon.com 718 Ning So 719 Reliance Jio 720 3010 Gaylord PKWY, Suite 150 721 Frisco, Texas 75034 722 USA 724 Email: Ning.So@ril.com 725 Fengman Xu 726 Reliance Jio 727 3010 Gaylord PKWY, Suite 150 728 Frisco, Texas 75034 729 USA 731 Email: Fengman.Xu@ril.com 733 Gang Chen 734 Baidu 735 No.10 Xibeiwang East Road Haidian District 736 Beijing 100193 737 P.R. China 739 Email: phdgang@gmail.com 741 Yongqing Zhu 742 China Telecom 743 109 West Zhongshan Ave, Tianhe District 744 Guangzhou 745 P.R. China 747 Email: zhuyq.gd@chinatelecom.cn 749 Yifeng Zhou 750 ByteDance 751 Building 1, AVIC Plaza, 43 N 3rd Ring W Rd Haidian 752 District 753 Beijing 100000 754 P.R. China 756 Email: yifeng.zhou@bytedance.com