idnits 2.17.1 draft-ietf-spring-srv6-path-segment-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 : ---------------------------------------------------------------------------- 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 (November 27, 2021) is 881 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 290 -- Looks like a reference, but probably isn't: '4' on line 380 == Outdated reference: A later version (-09) exists of draft-ietf-idr-sr-policy-path-segment-04 == Outdated reference: A later version (-13) exists of draft-ietf-pce-sr-bidir-path-08 == Outdated reference: A later version (-09) exists of draft-ietf-pce-sr-path-segment-04 == Outdated reference: A later version (-22) exists of draft-ietf-spring-mpls-path-segment-05 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-14 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING Working Group C. Li 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track W. Cheng 5 Expires: May 31, 2022 China Mobile 6 M. Chen 7 D. Dhody 8 Huawei Technologies 9 Y. Zhu 10 China Telecom 11 November 27, 2021 13 Path Segment for SRv6 (Segment Routing in IPv6) 14 draft-ietf-spring-srv6-path-segment-03 16 Abstract 18 Segment Routing (SR) allows for a flexible definition of end-to-end 19 paths by encoding an ordered list of instructions, called "segments". 20 The SR architecture can be implemented over an MPLS data plane as 21 well as an IPv6 data plane. 23 Currently, Path Segment has been defined to identify an SR path in 24 SR-MPLS networks, and is used for various use-cases such as end-to- 25 end SR Path Protection and Performance Measurement (PM) of an SR 26 path. This document defines the Path Segment to identify an SRv6 27 path in an IPv6 network. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on May 31, 2022. 46 Copyright Notice 48 Copyright (c) 2021 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 65 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 66 2. Use Cases for SRv6 Path Segment . . . . . . . . . . . . . . . 4 67 3. SRv6 Path Segment . . . . . . . . . . . . . . . . . . . . . . 5 68 3.1. Format of an SRv6 Path Segment . . . . . . . . . . . . . 5 69 3.1.1. SRv6 Path Segment: Locator and Local ID . . . . . . . 5 70 3.1.2. SRv6 Path Segment: Global ID . . . . . . . . . . . . 6 71 4. Encoding of an SRv6 Path Segment . . . . . . . . . . . . . . 6 72 4.1. SRH.P-flag . . . . . . . . . . . . . . . . . . . . . . . 6 73 5. SRv6 Path Segment Allocation . . . . . . . . . . . . . . . . 8 74 6. Processing of SRv6 Path Segment . . . . . . . . . . . . . . . 8 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 77 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 78 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 79 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 81 11.2. Informative References . . . . . . . . . . . . . . . . . 11 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 84 1. Introduction 86 Segment routing (SR) [RFC8402] is a source routing paradigm that 87 explicitly indicates the forwarding path for packets at the ingress 88 node by inserting an ordered list of instructions, called segments. 90 When segment routing is deployed on an MPLS data plane, called SR- 91 MPLS [RFC8660], a segment identifier (SID) is present as an MPLS 92 label. When segment routing is deployed on an IPv6 data plane, a SID 93 is presented as a 128-bit value, and it can be an IPv6 address of a 94 local interface but it does not have to be. To support SR in an IPv6 95 network, a Segment Routing Header (SRH) [RFC8754] is used. 97 In an SR-MPLS network, when a packet is transmitted along an SR path, 98 the labels in the MPLS label stack will be swapped or popped, so no 99 label or only the last label may be left in the MPLS label stack when 100 the packet reaches the egress node. Thus, the egress node can not 101 determine from which ingress node or SR path the packet came from. 102 Therefore, to identify an SR-MPLS path, a Path Segment is defined in 103 [I-D.ietf-spring-mpls-path-segment]. 105 Likewise, a path needs to be identified in an SRv6 network for 106 several use cases such as binding bidirectional paths 107 [I-D.ietf-pce-sr-bidir-path] and end-to-end performance measurement 108 [I-D.gandhi-spring-udp-pm]. 110 An SRv6 path MAY be identified by the content of a segment list. 111 However, the segment list may not be a good key, since the length of 112 a segment list is flexible according to the number of required SIDs. 113 Also, the length of a segment list may be too long to be a key when 114 it contains many SIDs. For instance, if packet A uses an SRH with 3 115 SIDs while Packet B uses an SRH with 10 SIDs, the key to identify 116 these two paths will be a 384-bits value and a 1280-bits value, 117 respectively. Further, an SRv6 path cannot be identified by the 118 information carried by the SRH in reduced mode [RFC8754] as the first 119 SID is not present. 121 Furthermore, different SRv6 policies may use the same segment list 122 for different candidate paths, so the traffic of different SRv6 123 policies are merged, resulting in the inability to measure the 124 performance of the specific path. 126 To solve the above issues, this document defines a new SRv6 segment 127 called "SRv6 Path Segment", which is a 128-bits value, to identify an 128 SRv6 path. 130 When the SRv6 Path Segment is used in reduced mode SRH [RFC8754], the 131 entire path information is indicated by the Path Segment, and the 132 performance will be better than using the entire segment list as the 133 path identifier, while the overhead is equivalent to the SRH in 134 normal mode. Furthermore, with SRv6 Path Segment, each SRv6 135 candidate path can be identified and measured, even when they use the 136 same segment list. 138 An SRv6 Path Segment MUST NOT be copied to the IPv6 destination 139 address, so it is not routable. 141 1.1. Requirements Language 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 145 "OPTIONAL" in this document are to be interpreted as described in BCP 146 14 [RFC2119] [RFC8174] when, and only when, they appear in all 147 capitals, as shown here. 149 1.2. Terminology 151 MPLS: Multiprotocol Label Switching. 153 PM: Performance Measurement. 155 SID: Segment ID. 157 SR: Segment Routing. 159 SR-MPLS: Segment Routing with MPLS data plane. 161 SRH: Segment Routing Header. 163 PSID: Path Segment Identifier. 165 PSP: Penultimate Segment Popping. 167 Further, this document makes use of the terms defined in [RFC8402] 168 and [RFC8986]. 170 2. Use Cases for SRv6 Path Segment 172 Similar to SR-MPLS Path Segment [I-D.ietf-spring-mpls-path-segment], 173 SRv6 Path Segment may also be used to identify an SRv6 Path in some 174 use cases: 176 o Performance Measurement: For Passive measurement [RFC7799], path 177 identification at the measuring points is the pre-requisite 178 [I-D.ietf-spring-mpls-path-segment]. SRv6 Path segment can be 179 used by the measuring points (e.g., the ingress/egress nodes of an 180 SRv6 path) or a centralized controller to correlate the packets 181 counts/timestamps, then packet loss/delay can be calculated. 183 o Bi-directional SRv6 Path Association: In some scenarios, such as 184 mobile backhaul transport networks, there are requirements to 185 support bidirectional paths. Like SR-MPLS 186 [I-D.ietf-spring-mpls-path-segment], to support bidirectional SRv6 187 paths, a straightforward way is to bind two unidirectional SRv6 188 paths to a single bidirectional path. SRv6 Path segments can be 189 used to correlate the two unidirectional SRv6 paths at both ends 190 of the path. [I-D.ietf-pce-sr-bidir-path] defines how to use PCEP 191 and Path Segment to initiate a bidirectional SR path. 193 o End-to-end Path Protection: For end-to-end 1+1 path protection 194 (i.e., Live-Live case), the egress node of an SRv6 path needs to 195 know the set of paths that constitute the primary and the 196 secondary(s), to select the primary packet for onward 197 transmission, and to discard the packets from the secondary(s), so 198 each SRv6 path needs a unique path identifier at the egress node, 199 which can be an SRv6 Path Segment. 201 3. SRv6 Path Segment 203 As defined in [RFC8986], an SRv6 segment is a 128-bit value. 205 To identify an SRv6 path, this document defines a new segment called 206 SRv6 Path Segment. 208 Depending on the use case, an SRv6 Path Segment identifies: 210 o an SRv6 path within an SRv6 domain 212 o an SRv6 Policy 214 o a Candidate-path or a SID-List in a SRv6 Policy 215 [I-D.ietf-spring-segment-routing-policy] 217 Note that, based on the use-case, a SRv6 Path Segment can be used for 218 different SID-Lists within an SR Policy. 220 3.1. Format of an SRv6 Path Segment 222 This document proposes two types of SRv6 Path Segment format. 224 3.1.1. SRv6 Path Segment: Locator and Local ID 226 As per [RFC8986], an SRv6 segment is a 128-bit value, which can be 227 represented as LOC:FUNCT, where LOC is the L most significant bits 228 and FUNCT is the 128-L least significant bits. L is called the 229 locator length and is flexible. Each network operator is free to use 230 the locator length it chooses. Most often the LOC part of the SID is 231 routable and leads to the node which instantiates that SID. The 232 FUNCT part of the SID is an opaque identification of a local function 233 bound to the SID. The FUNCT value zero is invalid. 235 SRv6 Path Segment can follow the format, where the LOC part 236 identifies the egress node that allocates the Path Segment, and the 237 FUNCT part is a unique local ID to identify an SRv6 Path and its 238 endpoint behavior. 240 The Function Type of an SRv6 Path Segment is END.PSID (End Function 241 with Path Segment Identifier). 243 +--------------------------------------------------------------+ 244 | Locator | Function ID | 245 +--------------------------------------------------------------+ 247 |<-------------------------128 bits--------------------------->| 249 Figure 2. PSID in Format LOC:FUNCT 251 3.1.2. SRv6 Path Segment: Global ID 253 An SRv6 Path Segment ID can be a Global ID, and its format depends on 254 the use case. 256 The SRv6 Path Segment will not be copied to the IPv6 Destination 257 Address, so the SRv6 Path Segment ID can be allocated from an 258 independent 128-bits ID Space. In this case, a new table should be 259 maintained at the node for SRv6 Path Segment. 261 +--------------------------------------------------------------+ 262 | Global ID/PSID | 263 +--------------------------------------------------------------+ 265 |<-------------------------128 bits--------------------------->| 267 Figure 3. A Global ID as an PSID 269 4. Encoding of an SRv6 Path Segment 271 This section describes the SRv6 Path Segment encoding in SRH. 273 The SRv6 Path Segment MUST appear only once in a segment list, and it 274 MUST appear as the last entry in the segment list. 276 4.1. SRH.P-flag 278 To indicate the existence of a Path Segment in the SRH, this document 279 defines a P-flag in the SRH flag field. The encapsulation of SRv6 280 Path Segment is shown below. 282 0 1 2 3 283 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 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | Last Entry | Flags |P| Tag | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | | 290 | Segment List[0] (128 bits IPv6 address) | 291 | | 292 | | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | | 295 | | 296 ... 297 | | 298 | | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | | 301 | Segment List[n-1] (128 bits IPv6 address) | 302 | | 303 | | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | | 306 | SRv6 Path Segment (Segment List[n],128 bits IPv6 value) | 307 | | 308 | | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 // // 311 // Optional Type Length Value objects (variable) // 312 // // 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 Figure 1. SRv6 Path Segment in SID List 317 o P-bit: set when SRv6 Path Segment is inserted. It MUST be ignored 318 when a node does not support SRv6 Path Segment processing. 320 SRH.P-bit processing can be enabled or disabled by configuration on 321 devices, it can be done by CLI, NETCONF YANG or other ways, and this 322 is out of the scope of this document. 324 The pseudo code of SRH.P-bit processing is described as below. 326 S01. if SRH.P-flag processing is enabled: 327 S02. if SRH.P-flag is set: 328 S03. SRv6 Path Segment processing ;;ref1 330 Ref1: The SRv6 Path Segment processing is accosiated with the 331 specific application, such as SRv6 Path Segment based Performance 332 measurement, so this is out of the scope of this document. 334 In some use cases, only the egress need to process the SRv6 Path 335 Segment, therefore, the P-bit processing can be done at the egress 336 node only while the intermediate nodes do not need to process it. 337 This feature can be enabled by configuration like CLI , NETCONF YANG 338 or other ways. In this case, the pseudo code is described as below. 340 S01. if SRH.P-flag processing is enabled: 341 S02. if intermediate node processing is disabled: 342 S03. if SRH.P-flag is set and SRH.SL == 0: 343 S03. SRv6 Path Segment processing 344 S04 else: 345 S05. if SRH.P-flag is set: 346 S06. SRv6 Path Segment processing 348 5. SRv6 Path Segment Allocation 350 A Path Segment is a local segment allocated by an egress node. A 351 Path Segment can be allocated through several ways, such as CLI, BGP 352 [I-D.ietf-idr-sr-policy-path-segment], PCEP 353 [I-D.ietf-pce-sr-path-segment] or other ways. The mechanisms through 354 which a Path Segment is allocated are out of scope of this document. 356 When a Path Segment is allocated by the egress, it MUST be 357 distributed to the ingress node of the path that identified by the 358 path segment. In this case, only the egress will process the Path 359 Segment, and other nodes specified by SIDs in the segment list do not 360 know how to process the Path Segment. 362 Depending on the use case, a Path Segment may be distributed to the 363 SRv6 nodes along the SRv6 path. In this case, the SRv6 nodes that 364 learned the Path Segment may process the Path Segment depending on 365 the use case. 367 6. Processing of SRv6 Path Segment 369 When the SRv6 Path Segment is used, the following rules apply: 371 o The SRv6 Path Segment MUST appear only once in a segment list, and 372 it MUST appear as the last entry. Only the one that appears as 373 the last entry in the SID list will be processed. An SRv6 Path 374 Segment that appears at any other location in the SID list will be 375 treated as an error. 377 o When an SRv6 Path Segment is inserted, the SL MUST be initiated to 378 be less than the value of Last Entry, and will not point to SRv6 379 Path Segment. For instance, when the Last entry is 4, the SID 380 List[4] is the SRv6 Path Segment, so the SL MUST be set to 3 or 381 other numbers less than Last entry. 383 o The SRv6 Path Segment MUST NOT be copied to the IPv6 destination 384 address. 386 o Penultimate Segment Popping (PSP, as defined in [RFC8986]) MUST be 387 disabled. 389 o The ingress needs to set the P-bit when an SRv6 Path Segment is 390 inserted in the SID List. Nodes that support SRv6 Path Segment 391 processing will inspect the last entry to process SRv6 Path 392 Segment when the P-bit is set. When the P-bit is unset, the nodes 393 will not inspect the last entry. 395 o The specific SRv6 Path Segment processing depends on use cases, 396 and it is out of scope of this document. 398 7. IANA Considerations 400 This I-D requests the IANA to allocate, within the "SRv6 Endpoint 401 Behaviors" sub-registry belonging to the top-level "Segment-routing 402 with IPv6 data plane (SRv6) Parameters" registry, the following 403 allocations: 405 Value Description Reference 406 -------------------------------------------------------------- 407 TBA1 End.PSID - SRv6 Path Segment [This.ID] 409 This document also requests IANA to allocate bit position TBA within 410 the "Segment Routing Header Flags" registry defined in [RFC8402]. 412 8. Security Considerations 414 This document does not introduce additional security requirements and 415 mechanisms other than the ones described in [RFC8402]. 417 9. Contributors 418 Zhenbin Li 419 Huawei Technologies 420 Huawei Campus, No. 156 Beiqing Rd. 421 Beijing 100095 422 China 424 Email: lizhenbin@huawei.com 426 Jie Dong 427 Huawei Technologies 428 Huawei Campus, No. 156 Beiqing Rd. 429 Beijing 100095 430 China 432 Email: jie.dong@huawei.com 434 10. Acknowledgements 436 The authors would like to thank Stefano Previdi and Zafar Ali for 437 their valuable comments and suggestions. 439 11. References 441 11.1. Normative References 443 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 444 Requirement Levels", BCP 14, RFC 2119, 445 DOI 10.17487/RFC2119, March 1997, 446 . 448 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 449 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 450 May 2017, . 452 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 453 Decraene, B., Litkowski, S., and R. Shakir, "Segment 454 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 455 July 2018, . 457 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 458 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 459 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 460 . 462 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 463 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 464 (SRv6) Network Programming", RFC 8986, 465 DOI 10.17487/RFC8986, February 2021, 466 . 468 11.2. Informative References 470 [I-D.gandhi-spring-udp-pm] 471 Gandhi, R., Filsfils, C., Voyer, D., Salsano, S., Ventre, 472 P. L., and M. Chen, "UDP Path for In-band Performance 473 Measurement for Segment Routing Networks", draft-gandhi- 474 spring-udp-pm-02 (work in progress), September 2018. 476 [I-D.ietf-idr-sr-policy-path-segment] 477 Li, C., Li, Z., Yin, Y., Cheng, W., and K. Talaulikar, "SR 478 Policy Extensions for Path Segment and Bidirectional 479 Path", draft-ietf-idr-sr-policy-path-segment-04 (work in 480 progress), July 2021. 482 [I-D.ietf-pce-sr-bidir-path] 483 Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong, 484 "Path Computation Element Communication Protocol (PCEP) 485 Extensions for Associated Bidirectional Segment Routing 486 (SR) Paths", draft-ietf-pce-sr-bidir-path-08 (work in 487 progress), September 2021. 489 [I-D.ietf-pce-sr-path-segment] 490 Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong, 491 "Path Computation Element Communication Protocol (PCEP) 492 Extension for Path Segment in Segment Routing (SR)", 493 draft-ietf-pce-sr-path-segment-04 (work in progress), 494 August 2021. 496 [I-D.ietf-spring-mpls-path-segment] 497 Cheng, W., Li, H., Chen, M., Gandhi, R., and R. Zigler, 498 "Path Segment in MPLS Based Segment Routing Network", 499 draft-ietf-spring-mpls-path-segment-05 (work in progress), 500 August 2021. 502 [I-D.ietf-spring-segment-routing-policy] 503 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 504 P. Mattes, "Segment Routing Policy Architecture", draft- 505 ietf-spring-segment-routing-policy-14 (work in progress), 506 October 2021. 508 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 509 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 510 May 2016, . 512 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 513 Decraene, B., Litkowski, S., and R. Shakir, "Segment 514 Routing with the MPLS Data Plane", RFC 8660, 515 DOI 10.17487/RFC8660, December 2019, 516 . 518 Authors' Addresses 520 Cheng Li 521 Huawei Technologies 523 Email: c.l@huawei.com 525 Weiqiang Cheng 526 China Mobile 528 Email: chengweiqiang@chinamobile.com 530 Mach(Guoyi) Chen 531 Huawei Technologies 533 Email: mach.chen@huawei.com 535 Dhruv Dhody 536 Huawei Technologies 537 Divyashree Techno Park, Whitefield 538 Bangalore, Karnataka 560066 539 India 541 Email: dhruv.ietf@gmail.com 543 Yongqing Zhu 544 China Telecom 545 Guangzhou 547 Email: zhuyq8@chinatelecom.cn