idnits 2.17.1 draft-bonica-6man-comp-rtg-hdr-08.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 (October 15, 2019) is 1617 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 651 -- Looks like a reference, but probably isn't: '1' on line 652 == Outdated reference: A later version (-06) exists of draft-bonica-spring-srv6-plus-05 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 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: April 17, 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 G. Yang 20 China Telecom 21 Y. Zhou 22 ByteDance 23 October 15, 2019 25 The IPv6 Compressed Routing Header (CRH) 26 draft-bonica-6man-comp-rtg-hdr-08 28 Abstract 30 This document defines two new IPv6 Routing header types. 31 Generically, they are called the Compressed Routing Header (CRH). 32 More specifically, the 16-bit version of the CRH is called the CRH- 33 16, while the 32-bit version of the CRH is called the CRH-32. SRm6 34 nodes use the CRH to steer packets from segment to segment along SRm6 35 paths. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on April 17, 2020. 54 Copyright Notice 56 Copyright (c) 2019 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (https://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 73 3. The Compressed Routing Header (CRH) . . . . . . . . . . . . . 3 74 4. The Segment Forwarding Information Base (SFIB) . . . . . . . 4 75 5. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 5 76 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5 77 5.2. CRH Specific . . . . . . . . . . . . . . . . . . . . . . 6 78 5.2.1. Computing Minimum CRH Length . . . . . . . . . . . . 7 79 5.2.2. Topological Instructions That Control Adjacency 80 Segments . . . . . . . . . . . . . . . . . . . . . . 8 81 5.2.3. Topological Instructions That Control Node Segments . 9 82 5.2.4. Topological Instructions That Control Binding 83 Segments . . . . . . . . . . . . . . . . . . . . . . 9 84 6. Mutability . . . . . . . . . . . . . . . . . . . . . . . . . 10 85 7. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . 10 86 8. Management Considerations . . . . . . . . . . . . . . . . . . 10 87 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 88 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 89 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 90 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 91 12.1. Normative References . . . . . . . . . . . . . . . . . . 11 92 12.2. Informative References . . . . . . . . . . . . . . . . . 12 93 Appendix A. CRH Processing Examples . . . . . . . . . . . . . . 12 94 A.1. SR Path Contains Node Segments Only . . . . . . . . . . . 13 95 A.2. SR Path Contains Node Segments Only And Preserves The 96 First SID . . . . . . . . . . . . . . . . . . . . . . . . 14 98 A.3. SR Path Contains Adjacency Segments Only . . . . . . . . 14 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 101 1. Introduction 103 This document defines two new IPv6 [RFC8200] Routing header types. 104 Generically, they are called the Compressed Routing Header (CRH). 105 More specifically, the 16-bit version of the CRH is called the CRH- 106 16, while the 32-bit version of the CRH is called the CRH-32. SRm6 107 [I-D.bonica-spring-srv6-plus] nodes use the CRH to steer packets from 108 segment to segment along SRm6 paths. 110 For details regarding SRm6 paths, segments, Segment Identifiers 111 (SIDs) and instructions, see [I-D.bonica-spring-srv6-plus]. 113 2. Requirements Language 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 117 "OPTIONAL" in this document are to be interpreted as described in BCP 118 14 [RFC2119] [RFC8174] when, and only when, they appear in all 119 capitals, as shown here. 121 3. The Compressed Routing Header (CRH) 123 Both CRH versions (i.e., CRH-16 and CRH-32) contain the following 124 fields: 126 o Next Header - Defined in [RFC8200]. Identifies the type of header 127 immediately following the CRH. 129 o Hdr Ext Len - Defined in [RFC8200]. Length of the CRH in 8-octet 130 units, not including the first 8 octets. 132 o Routing Type - Defined in [RFC8200]. Value TBD by IANA. (For 133 CRH-16, the suggested value is 5. For CRH-32, the suggested value 134 is 6.) 136 o Segments Left - Defined in [RFC8200]. Number of route segments 137 remaining, i.e., number of explicitly listed intermediate nodes 138 still to be visited before reaching the final destination. 140 o SID List - Represents the SRm6 path as an ordered list of SIDs. 141 SIDs are listed in reverse order, with SID[0] representing the 142 final segment, SID[1] representing the penultimate segment, and so 143 forth. SIDs are listed in reverse order so that Segments Left can 144 be used as an index to the SID List. The SID indexed by Segments 145 Left is called the current SID. 147 In the CRH-16 (Figure 1), each SID list entry is encoded in 16-bits. 148 In the CRH-32 (Figure 2), each SID list entry is encoded in 32-bits. 149 In networks where the smallest feasible Maximum SID Value (MSV) 150 [I-D.bonica-spring-srv6-plus] is greater than 65,535, CRH-32 is 151 required. Otherwise, CRH-16 is preferred. 153 In all cases, the CRH MUST end on a 64-bit boundary. Therefore, the 154 CRH MAY be padded with zeros. 156 0 1 2 3 157 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 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | SID[0] | SID[1] | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 163 | ......... 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 166 Figure 1: CRH-16 168 0 1 2 3 169 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 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 + SID[0] + 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 + SID[1] + 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 // // 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 + SID[n] + 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 Figure 2: CRH-32 184 4. The Segment Forwarding Information Base (SFIB) 186 A segment ingress node maintains one Segment Forwarding Information 187 Base (SFIB) entry for each segment that it originates. Each SFIB 188 entry contains the following information: 190 o A SID. 192 o A segment type. 194 o Topological instruction parameters. 196 The following are valid segment types: 198 o Adjacency. 200 o Node. 202 o Binding. 204 The following parameters are associated with topological instructions 205 that control adjacency segments: 207 o An IPv6 address that identifies an interface on the segment egress 208 node. 210 o An interface identifier. 212 Node segments are associated with a single topological instruction 213 parameter. This parameter is an IPv6 address that identifies an 214 interface on the segment egress node. 216 The following parameters are associated with topological instructions 217 that control binding segments: 219 o An IPv6 address that identifies an interface on the first segment 220 egress node in the binding segment. 222 o A SID list length. 224 o A SID list. 226 5. Processing Rules 228 5.1. General 230 [RFC8200] defines rules that apply to IPv6 extension headers, in 231 general, and IPv6 Routing headers, in particular. All of these rules 232 apply to the CRH. 234 For example: 236 o Extension headers (except for the Hop-by-Hop Options header) are 237 not processed, inserted, or deleted by any node along a packet's 238 delivery path, until the packet reaches the node (or each of the 239 set of nodes, in the case of multicast) identified in the 240 Destination Address field of the IPv6 header. 242 o If, while processing a received packet, a node encounters a 243 Routing header with an unrecognized Routing Type value, the 244 required behavior of the node depends on the value of the Segments 245 Left field. If Segments Left is zero, the node must ignore the 246 Routing header and proceed to process the next header in the 247 packet, whose type is identified by the Next Header field in the 248 Routing header. If Segments Left is non-zero, the node must 249 discard the packet and send an ICMPv6 [RFC4443] Parameter Problem, 250 Code 0, message to the packet's Source Address, pointing to the 251 unrecognized Routing Type. 253 o If, after processing a Routing header of a received packet, an 254 intermediate node determines that the packet is to be forwarded 255 onto a link whose link MTU is less than the size of the packet, 256 the node must discard the packet and send an ICMPv6 Packet Too Big 257 message to the packet's Source Address. 259 5.2. CRH Specific 261 When a node recognizes and processes a CRH, it executes the following 262 procedure: 264 o If the IPv6 Source Address is a link-local address, discard the 265 packet. 267 o If the IPv6 Source Address is a multicast address, discard the 268 packet. 270 o If Segments Left equals 0, skip over the CRH and process the next 271 header in the packet. 273 o If Hdr Ext Len indicates that the CRH is larger than the 274 implementation can process, discard the packet and send an ICMPv6 275 Parameter Problem, Code 0, message to the Source Address, pointing 276 to the Hdr Ext Len field. 278 o Compute L, the minimum CRH length (See Section 5.2.1). 280 o If L is greater than Hdr Ext Len, discard the packet and send an 281 ICMPv6 Parameter Problem, Code 0, message to the Source Address, 282 pointing to the Segments Left field. 284 o Decrement the packet's Hop Count. 286 o If the Hop Count has expired, discard the packet and send an 287 ICMPv6 Time Expired message to the packet's source node. 289 o Decrement Segments Left 291 o Search for the current SID in the SFIB. 293 o If the above-mentioned search does not return an SFIB entry, 294 discard the packet and send an ICMPv6 Parameter Problem, Code 0, 295 message to the Source Address, pointing to the current SID. 297 o If the above-mentioned search returns an SFIB entry that 298 represents an adjacency segment, execute the topological 299 instruction described in Section 5.2.2. 301 o If the above-mentioned search returns an SFIB entry that 302 represents a node segment, execute the topological instruction 303 described in Section 5.2.3. 305 o If the above-mentioned search returns an SFIB entry that 306 represents a binding segment, execute the topological instruction 307 described in Section 5.2.4. 309 The above stated rules are demonstrated in Appendix A. 311 5.2.1. Computing Minimum CRH Length 313 The algorithm described in this section accepts the following CRH 314 fields as its input parameters: 316 o Routing Type (i.e., CRH-16 or CRH-32). 318 o Segments Left. 320 It yields L, the minimum CRH length. The minimum CRH length is 321 measured in 8-octet units, not including the first 8 octets. 323 325 switch(Routing Type) { 326 case CRH-16: 327 if (Segments Left <= 2) 328 return(0) 329 sidsBeyondFirstWord = Segments Left - 2; 330 sidPerWord = 4; 331 case CRH-32: 332 if (Segments Left <= 1) 333 return(0) 334 sidsBeyondFirstWord = Segments Left - 1; 335 sdsPerWord = 2; 336 case default: 337 return(0xFF); 338 } 340 words = sidsBeyondFirstWord div sidsPerWord; 341 if (sidsBeyondFirstWord mod sidsPerWord) 342 words++; 344 return(words) 346 348 5.2.2. Topological Instructions That Control Adjacency Segments 350 A topological instruction that controls an adjacency segment accepts 351 the following parameters: 353 o An IPv6 address that identifies an interface on the segment egress 354 node. 356 o An interface identifier. 358 The instruction behaves as follows: 360 o If the interface that was received as a parameter is not 361 operational, discard the packet and send an ICMPv6 Destination 362 Unreachable message (Code: 5, Source Route Failed) to the packet's 363 source node. 365 o Overwrite the packet's Destination Address with the IPv6 address 366 that was received as a parameter. 368 o Forward the packet through the above-mentioned interface. 370 5.2.3. Topological Instructions That Control Node Segments 372 A topological instruction that controls a node segment accepts a 373 single parameter. This parameter is an IPv6 address that identifies 374 an interface on the segment egress node. 376 The instruction behaves as follows: 378 o If the segment ingress node does not have a viable route to the 379 IPv6 address included as a parameter, discard the packet and send 380 an ICMPv6 Destination Unreachable message (Code:1 Net Unreachable) 381 to the packet's source node. 383 o Overwrite the packet's Destination Address with the destination 384 address that was included as a parameter. 386 o Forward the packet to the next hop along the least cost path to 387 the segment egress node. If there are multiple least cost paths 388 to the segment egress node (i.e., Equal Cost Multipath), execute 389 procedures so that all packets belonging to a flow are forwarded 390 through the same next hop. 392 5.2.4. Topological Instructions That Control Binding Segments 394 A topological instruction that controls an binding segment accepts 395 the following parameters: 397 o An IPv6 address that identifies an interface on the first segment 398 egress node in the binding segment. 400 o A SID list length. 402 o A SID list. 404 The instruction behaves as follows: 406 o If the segment ingress node does not have a viable route to the 407 IPv6 address received as a parameter, discard the packet and send 408 an ICMPv6 Destination Unreachable message (Code:1 Net Unreachable) 409 to the packet's source node. 411 o Prepend a CRH to the packet. Copy the SID list length, received 412 as a parameter, to the CRH Segments Left field. Also copy the SID 413 list, received as a parameter, to the CRH SID list. 415 o Prepend an IPv6 header to the packet. Copy the IPv6 address, 416 received as a parameter, to the IPv6 Destination Address. 418 o Forward the packet to the next hop along the least cost path to 419 the IPv6 address received as a parameter. If there are multiple 420 least cost paths to the IPv6 address received as a parameter 421 (i.e., Equal Cost Multipath), execute procedures so that all 422 packets belonging to a flow are forwarded through the same next 423 hop. 425 6. Mutability 427 In the CRH, the Segments Left field is mutable. All remaining fields 428 are immutable. 430 7. Compliance 432 In order to be compliant with this specification, an SRm6 433 implementation MUST: 435 o Be able to process IPv6 options as described in Section 4.2 of 436 [RFC8200]. 438 o Be able to process the Routing header as described in Section 4.4 439 of [RFC8200]. 441 o Support the CRH-16 and the CRH-32. 443 8. Management Considerations 445 PING and TRACEROUTE [RFC2151] both operate correctly in the presence 446 of the CRH. 448 9. Security Considerations 450 SRm6 domains MUST NOT span security domains. In order to enforce 451 this requirement, security domain edge routers MUST do one of the 452 following: 454 o Discard all inbound SRm6 packets whose IPv6 destination address 455 represents domain infrastructure. 457 o Authenticate [RFC4302] [RFC4303] all inbound SRm6 packets whose 458 IPv6 destination address represents domain infrastructure. 460 10. IANA Considerations 462 IANA is requested to make the following entries in the Internet 463 Protocol Version 6 (IPv6) Parameters "Routing Type" registry: 465 Suggested 466 Value Description Reference 467 ----------------------------------------------------------------------- 468 5 Compressed Routing Header (16-bit) (CRH-16) This document 469 6 Compressed Routing Header (32-bit) (CRH-32) This document 471 11. Acknowledgements 473 Thanks to Naveen Kottapalli, Joel Halpern, Tony Li, Gerald Schmidt, 474 Nancy Shaw, and Chandra Venkatraman for their comments. 476 12. References 478 12.1. Normative References 480 [I-D.bonica-spring-srv6-plus] 481 Bonica, R., Hegde, S., Kamite, Y., Alston, A., Henriques, 482 D., Halpern, J., Linkova, J., and G. Chen, "IPv6 Support 483 for Segment Routing: SRv6+", draft-bonica-spring- 484 srv6-plus-05 (work in progress), August 2019. 486 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 487 Requirement Levels", BCP 14, RFC 2119, 488 DOI 10.17487/RFC2119, March 1997, 489 . 491 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 492 DOI 10.17487/RFC4302, December 2005, 493 . 495 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 496 RFC 4303, DOI 10.17487/RFC4303, December 2005, 497 . 499 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 500 Control Message Protocol (ICMPv6) for the Internet 501 Protocol Version 6 (IPv6) Specification", STD 89, 502 RFC 4443, DOI 10.17487/RFC4443, March 2006, 503 . 505 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 506 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 507 May 2017, . 509 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 510 (IPv6) Specification", STD 86, RFC 8200, 511 DOI 10.17487/RFC8200, July 2017, 512 . 514 12.2. Informative References 516 [RFC2151] Kessler, G. and S. Shepard, "A Primer On Internet and TCP/ 517 IP Tools and Utilities", FYI 30, RFC 2151, 518 DOI 10.17487/RFC2151, June 1997, 519 . 521 Appendix A. CRH Processing Examples 523 This appendix demonstrates CRH processing in the following scenarios: 525 o SR path contains node segments only (Appendix A.1). 527 o SR path contains node segments only and preserves the first SID 528 (Appendix A.2). 530 o SR path contains adjacency segments only (Appendix A.3). 532 ----------- 533 2001:db8:0:2/64 |Node: I2 | 2001:db8:0:4/64 534 ----------------------|Loopback: |-------------------- 535 | ::2 |2001:db8::2| ::1 | 536 | ----------- | 537 | ::1 :: 2| 538 ----------- ----------- ----------- 539 |Node: S |2001:db8:0:1/64|Node: I1 |2001:db8:0:3/64|Node: I3 | 540 |Loopback |---------------|Loopback: |---------------|Loopback: | 541 |2001:db8::a| ::1 ::2 |2001:db8::1| ::1 ::2 |2001:db8::3| 542 ----------- ----------- ----------- 543 | ::1 544 ----------- | 545 |Node: D | 2001:db8:0:b/64 | 546 |Loopback: |--------------------- 547 |2001:db8::b| ::2 548 ----------- 550 Figure 3: Reference Topology 552 Figure 3 provides a reference topology that is used in all examples. 554 +--------------------+-----+--------------+--------------+ 555 | Instantiating Node | SID | Segment Type | IPv6 Address | 556 +--------------------+-----+--------------+--------------+ 557 | All | 1 | Node | 2001:db8::1 | 558 | All | 2 | Node | 2001:db8::2 | 559 | All | 3 | Node | 2001:db8::3 | 560 | All | 10 | Node | 2001:db8::a | 561 | All | 11 | Node | 2001:db8::b | 562 +--------------------+-----+--------------+--------------+ 564 Table 1: Node SIDs 566 Table 1 describes SFIB entries that are instantiated on all nodes. 567 All of these SFIB entries represent node segments. 569 +--------------------+-----+-----------------+-----------+ 570 | Instantiating Node | SID | IPv6 Address | Interface | 571 +--------------------+-----+-----------------+-----------+ 572 | S | 129 | 2001:db8:0:1::2 | S -> I1 | 573 | S | 130 | 2001:db8:0:2::2 | S -> I2 | 574 | I1 | 129 | 2001:db8:0:3::2 | I1 -> I3 | 575 | I2 | 129 | 2001:db8:0:4::2 | I2 -> I3 | 576 | I3 | 129 | 2001:db8:0:b::2 | I3 -> D | 577 +--------------------+-----+-----------------+-----------+ 579 Table 2: Adjacency SIDs 581 Table 2 describes SFIB entries that are instantiated on specific 582 nodes. All of these SFIB entries represent adjacency segments. 584 A.1. SR Path Contains Node Segments Only 586 In this example, Node S sends a packet to Node D, though a node 587 segment that terminates on I3. In this example, I3 does not appear 588 in the CRH segment list. Therefore, the destination node may not be 589 able to send return traffic through the same path. 591 +-------------------------------------+-------------------+ 592 | As the packet travels from S to I3: | | 593 +-------------------------------------+-------------------+ 594 | Source Address = 2001:db8::a | Segments Left = 1 | 595 | Destination Address = 2001:db8::3 | SID[0] = 11 | 596 +-------------------------------------+-------------------+ 597 +-------------------------------------+-------------------+ 598 | As the packet travels from I3 to D: | | 599 +-------------------------------------+-------------------+ 600 | Source Address = 2001:db8::a | Segments Left = 0 | 601 | Destination Address = 2001:db8::b | SID[0] = 11 | 602 +-------------------------------------+-------------------+ 604 A.2. SR Path Contains Node Segments Only And Preserves The First SID 606 In this example, Node S sends a packet to Node D, through a node 607 segment that terminates on I3. In this example, I3 appears in the 608 CRH segment list. Therefore, the destination node can send return 609 traffic through the same path. 611 +-------------------------------------+-------------------+ 612 | As the packet travels from S to I3: | | 613 +-------------------------------------+-------------------+ 614 | Source Address = 2001:db8::a | Segments Left = 1 | 615 | Destination Address = 2001:db8::3 | SID[0] = 11 | 616 | | SID[1] = 3 | 617 +-------------------------------------+-------------------+ 619 +-------------------------------------+-------------------+ 620 | As the packet travels from I3 to D: | | 621 +-------------------------------------+-------------------+ 622 | Source Address = 2001:db8::a | Segments Left = 0 | 623 | Destination Address = 2001:db8::b | SID[0] = 11 | 624 | | SID[1] = 3 | 625 +-------------------------------------+-------------------+ 627 A.3. SR Path Contains Adjacency Segments Only 629 In this example, Node S sends a packet to Node D, via two adjacency 630 segments.. 632 +---------------------------------------+-------------------+ 633 | As the packet travels from S to I1: | | 634 +---------------------------------------+-------------------+ 635 | Source Address = 2001:db8::a | Segments Left = 2 | 636 | Destination Address = 2001:db8:0:1::2 | SID[0] = 129 | 637 | | SID[1] = 129 | 638 +---------------------------------------+-------------------+ 639 +---------------------------------------+-------------------+ 640 | As the packet travels from I1 to I3: | | 641 +---------------------------------------+-------------------+ 642 | Source Address = 2001:db8::a | Segments Left = 1 | 643 | Destination Address = 2001:db8:0:3::2 | SID[0] = 129 | 644 | | SID[1] = 129 | 645 +---------------------------------------+-------------------+ 647 +---------------------------------------+-------------------+ 648 | As the packet travels from I3 to D: | | 649 +---------------------------------------+-------------------+ 650 | Source Address = 2001:db8::a | Segments Left = 0 | 651 | Destination Address = 2001:db8:0:b::2 | SID[0] = 129 | 652 | | SID[1] = 129 | 653 +---------------------------------------+-------------------+ 655 Authors' Addresses 657 Ron Bonica 658 Juniper Networks 659 2251 Corporate Park Drive 660 Herndon, Virginia 20171 661 USA 663 Email: rbonica@juniper.net 665 Yuji Kamite 666 NTT Communications Corporation 667 3-4-1 Shibaura, Minato-ku 668 Tokyo 108-8118 669 Japan 671 Email: y.kamite@ntt.com 673 Tomonobu Niwa 674 KDDI 675 3-22-7, Yoyogi, Shibuya-ku 676 Tokyo 151-0053 677 Japan 679 Email: to-niwa@kddi.com 680 Andrew Alston 681 Liquid Telecom 682 Nairobi 683 Kenya 685 Email: Andrew.Alston@liquidtelecom.com 687 Daniam Henriques 688 Liquid Telecom 689 Johannesburg 690 South Africa 692 Email: daniam.henriques@liquidtelecom.com 694 Luay Jalil 695 Verizon 696 Richardson, Texas 697 USA 699 Email: luay.jalil@one.verizon.com 701 Ning So 702 Reliance Jio 703 3010 Gaylord PKWY, Suite 150 704 Frisco, Texas 75034 705 USA 707 Email: Ning.So@ril.com 709 Fengman Xu 710 Reliance Jio 711 3010 Gaylord PKWY, Suite 150 712 Frisco, Texas 75034 713 USA 715 Email: Fengman.Xu@ril.com 716 Gang Chen 717 Baidu 718 No.10 Xibeiwang East Road Haidian District 719 Beijing 100193 720 P.R. China 722 Email: phdgang@gmail.com 724 Yongqing Zhu 725 China Telecom 726 109 West Zhongshan Ave, Tianhe District 727 Guangzhou 728 P.R. China 730 Email: zhuyq.gd@chinatelecom.cn 732 Guangming Yang 733 China Telecom 734 109 West Zhongshan Ave, Tianhe District 735 Guangzhou 736 P.R. China 738 Email: yanggm.gd@chinatelecom.cn 740 Yifeng Zhou 741 ByteDance 742 Building 1, AVIC Plaza, 43 N 3rd Ring W Rd Haidian District 743 Beijing 100000 744 P.R. China 746 Email: yifeng.zhou@bytedance.com