idnits 2.17.1 draft-li-spring-srv6-path-segment-07.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 (October 31, 2020) is 1271 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: '4' on line 307 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-24 == Outdated reference: A later version (-09) exists of draft-ietf-idr-sr-policy-path-segment-01 == Outdated reference: A later version (-13) exists of draft-ietf-pce-sr-bidir-path-03 == Outdated reference: A later version (-09) exists of draft-ietf-pce-sr-path-segment-01 == Outdated reference: A later version (-22) exists of draft-ietf-spring-mpls-path-segment-03 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-08 == Outdated reference: A later version (-06) exists of draft-li-6man-srv6-path-segment-encap-03 Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 2 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 4, 2021 China Mobile 6 M. Chen 7 D. Dhody 8 Huawei Technologies 9 R. Gandhi 10 Cisco Systems, Inc. 11 October 31, 2020 13 Path Segment for SRv6 (Segment Routing in IPv6) 14 draft-li-spring-srv6-path-segment-07 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 4, 2021. 46 Copyright Notice 48 Copyright (c) 2020 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. SRv6 Path Segment Allocation . . . . . . . . . . . . . . . . 6 72 5. Processing of SRv6 Path Segment . . . . . . . . . . . . . . . 7 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 75 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 76 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 78 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 79 10.2. Informative References . . . . . . . . . . . . . . . . . 9 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 82 1. Introduction 84 Segment routing (SR) [RFC8402] is a source routing paradigm that 85 explicitly indicates the forwarding path for packets at the ingress 86 node by inserting an ordered list of instructions, called segments. 88 When segment routing is deployed on an MPLS data plane, called SR- 89 MPLS [I-D.ietf-spring-segment-routing-mpls], a segment identifier 90 (SID) is present as an MPLS label. When segment routing is deployed 91 on an IPv6 data plane, a SID is presented as a 128-bit value, and it 92 can be an IPv6 address of a local interface but it does not have to 93 be. To support SR in an IPv6 network, a Segment Routing Header (SRH) 94 [RFC8754] is used. 96 In an SR-MPLS network, when a packet is transmitted along an SR path, 97 the labels in the MPLS label stack will be swapped or popped, so no 98 label or only the last label may be left in the MPLS label stack when 99 the packet reaches the egress node. Thus, the egress node can not 100 determine from which ingress node or SR path the packet came from. 101 Therefore, to identify an SR-MPLS path, a Path Segment is defined in 102 [I-D.ietf-spring-mpls-path-segment]. 104 Likewise, a path needs to be identified in an SRv6 network for 105 several use cases such as binding bidirectional paths 106 [I-D.ietf-pce-sr-bidir-path] and end-to-end performance measurement 107 [I-D.gandhi-spring-udp-pm]. 109 An SRv6 path MAY be identified by the content of a segment list. 110 However, the segment list may not be a good key, since the length of 111 a segment list is flexible according to the number of required SIDs. 112 Also, the length of a segment list may be too long to be a key when 113 it contains many SIDs. For instance, if packet A uses an SRH with 3 114 SIDs while Packet B uses an SRH with 10 SIDs, the key to identify 115 these two paths will be a 384-bits value and a 1280-bits value, 116 respectively. Further, an SRv6 path cannot be identified by the 117 information carried by the SRH in reduced mode [RFC8754] as the first 118 SID is not present. 120 Furthermore, different SRv6 policies may use the same segment list 121 for different candidate paths, so the traffic of different SRv6 122 policies are merged, resulting in the inability to measure the 123 performance of the specific path. 125 To solve the above issues, this document defines a new SRv6 segment 126 called "SRv6 Path Segment", which is a 128-bits value, to identify an 127 SRv6 path. 129 When the SRv6 Path Segment is used in reduced mode SRH [RFC8754], the 130 entire path information is indicated by the Path Segment, and the 131 performance will be better than using the entire segment list as the 132 path identifier, while the overhead is equivalent to the SRH in 133 normal mode. Furthermore, with SRv6 Path Segment, each SRv6 134 candidate path can be identified and measured, even when they use the 135 same segment list. 137 An SRv6 Path Segment MUST NOT be copied to the IPv6 destination 138 address, so it is not routable. 140 1.1. Requirements Language 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 144 "OPTIONAL" in this document are to be interpreted as described in BCP 145 14 [RFC2119] [RFC8174] when, and only when, they appear in all 146 capitals, as shown here. 148 1.2. Terminology 150 MPLS: Multiprotocol Label Switching. 152 PM: Performance Measurement. 154 SID: Segment ID. 156 SR: Segment Routing. 158 SR-MPLS: Segment Routing with MPLS data plane. 160 SRH: Segment Routing Header. 162 PSID: Path Segment Identifier. 164 PSP: Penultimate Segment Popping. 166 Further, this document makes use of the terms defined in [RFC8402] 167 and [I-D.ietf-spring-srv6-network-programming]. 169 2. Use Cases for SRv6 Path Segment 171 Similar to SR-MPLS Path Segment [I-D.ietf-spring-mpls-path-segment], 172 SRv6 Path Segment may also be used to identify an SRv6 Path in some 173 use cases: 175 o Performance Measurement: For Passive measurement [RFC7799], path 176 identification at the measuring points is the pre-requisite 177 [I-D.ietf-spring-mpls-path-segment]. SRv6 Path segment can be 178 used by the measuring points (e.g., the ingress/egress nodes of an 179 SRv6 path) or a centralized controller to correlate the packets 180 counts/timestamps, then packet loss/delay can be calculated. 182 o Bi-directional SRv6 Path Association: In some scenarios, such as 183 mobile backhaul transport networks, there are requirements to 184 support bidirectional paths. Like SR-MPLS 185 [I-D.ietf-spring-mpls-path-segment], to support bidirectional SRv6 186 paths, a straightforward way is to bind two unidirectional SRv6 187 paths to a single bidirectional path. SRv6 Path segments can be 188 used to correlate the two unidirectional SRv6 paths at both ends 189 of the path. [I-D.ietf-pce-sr-bidir-path] defines how to use PCEP 190 and Path Segment to initiate a bidirectional SR path. 192 o End-to-end Path Protection: For end-to-end 1+1 path protection 193 (i.e., Live-Live case), the egress node of an SRv6 path needs to 194 know the set of paths that constitute the primary and the 195 secondary(s), to select the primary packet for onward 196 transmission, and to discard the packets from the secondary(s), so 197 each SRv6 path needs a unique path identifier at the egress node, 198 which can be an SRv6 Path Segment. 200 3. SRv6 Path Segment 202 As defined in [I-D.ietf-spring-srv6-network-programming], an SRv6 203 segment is a 128-bit value. 205 To identify an SRv6 path, this document defines a new segment called 206 SRv6 Path Segment. 208 The SRv6 Path Segment MUST appear only once in a segment list, and it 209 MUST appear as the last entry in the segment list. To indicate the 210 SRv6 Path Segment, an SRH.P-flag is defined in 211 [I-D.li-6man-srv6-path-segment-encap]. 213 Depending on the use case, an SRv6 Path Segment identifies: 215 o an SRv6 path within an SRv6 domain 217 o an SRv6 Policy 219 o a Candidate-path or a SID-List in a SRv6 Policy 220 [I-D.ietf-spring-segment-routing-policy] 222 Note that, based on the use-case, a SRv6 Path Segment can be used for 223 different SID-Lists within an SR Policy. 225 3.1. Format of an SRv6 Path Segment 227 This document proposes two types of SRv6 Path Segment format. 229 3.1.1. SRv6 Path Segment: Locator and Local ID 231 As per [I-D.ietf-spring-srv6-network-programming], an SRv6 segment is 232 a 128-bit value, which can be represented as LOC:FUNCT, where LOC is 233 the L most significant bits and FUNCT is the 128-L least significant 234 bits. L is called the locator length and is flexible. Each network 235 operator is free to use the locator length it chooses. Most often 236 the LOC part of the SID is routable and leads to the node which 237 instantiates that SID. The FUNCT part of the SID is an opaque 238 identification of a local function bound to the SID. The FUNCT value 239 zero is invalid. 241 SRv6 Path Segment can follow the format, where the LOC part 242 identifies the egress node that allocates the Path Segment, and the 243 FUNCT part is a unique local ID to identify an SRv6 Path and its 244 endpoint behavior. 246 The Function Type of an SRv6 Path Segment is END.PSID (End Function 247 with Path Segment Identifier). 249 +--------------------------------------------------------------+ 250 | Locator | Function ID | 251 +--------------------------------------------------------------+ 253 |<-------------------------128 bits--------------------------->| 255 Figure 2. PSID in Format LOC:FUNCT 257 3.1.2. SRv6 Path Segment: Global ID 259 An SRv6 Path Segment ID can be a Global ID, and its format depends on 260 the use case. 262 The SRv6 Path Segment will not be copied to the IPv6 Destination 263 Address, so the SRv6 Path Segment ID can be allocated from an 264 independent 128-bits ID Space. In this case, a new table should be 265 maintained at the node for SRv6 Path Segment. 267 +--------------------------------------------------------------+ 268 | Global ID/PSID | 269 +--------------------------------------------------------------+ 271 |<-------------------------128 bits--------------------------->| 273 Figure 3. A Global ID as an PSID 275 4. SRv6 Path Segment Allocation 277 A Path Segment is a local segment allocated by an egress node. A 278 Path Segment can be allocated through several ways, such as CLI, BGP 279 [I-D.ietf-idr-sr-policy-path-segment], PCEP 280 [I-D.ietf-pce-sr-path-segment] or other ways. The mechanisms through 281 which a Path Segment is allocated are out of scope of this document. 283 When a Path Segment is allocated by the egress, it MUST be 284 distributed to the ingress node of the path that identified by the 285 path segment. In this case, only the egress will process the Path 286 Segment, and other nodes specified by SIDs in the segment list do not 287 know how to process the Path Segment. 289 Depending on the use case, a Path Segment may be distributed to the 290 SRv6 nodes along the SRv6 path. In this case, the SRv6 nodes that 291 learned the Path Segment may process the Path Segment depending on 292 the use case. 294 5. Processing of SRv6 Path Segment 296 When the SRv6 Path Segment is used, the following rules apply: 298 o The SRv6 Path Segment MUST appear only once in a segment list, and 299 it MUST appear as the last entry. Only the one that appears as 300 the last entry in the SID list will be processed. An SRv6 Path 301 Segment that appears at any other location in the SID list will be 302 treated as an error. 304 o When an SRv6 Path Segment is inserted, the SL MUST be initiated to 305 be less than the value of Last Entry, and will not point to SRv6 306 Path Segment. For instance, when the Last entry is 4, the SID 307 List[4] is the SRv6 Path Segment, so the SL MUST be set to 3 or 308 other numbers less than Last entry. 310 o The SRv6 Path Segment MUST NOT be copied to the IPv6 destination 311 address. 313 o Penultimate Segment Popping (PSP, as defined in 314 [I-D.ietf-spring-srv6-network-programming]) MUST be disabled. 316 o The ingress needs to set the P-bit when an SRv6 Path Segment is 317 inserted in the SID List. Nodes that support SRv6 Path Segment 318 processing will inspect the last entry to process SRv6 Path 319 Segment when the P-bit is set. When the P-bit is unset, the nodes 320 will not inspect the last entry. 322 o The specific SRv6 Path Segment processing depends on use cases, 323 and it is out of scope of this document. 325 6. IANA Considerations 327 This I-D requests the IANA to allocate, within the "SRv6 Endpoint 328 Behaviors" sub-registry belonging to the top-level "Segment-routing 329 with IPv6 data plane (SRv6) Parameters" registry, the following 330 allocations: 332 Value Description Reference 333 -------------------------------------------------------------- 334 TBA1 End.PSID - SRv6 Path Segment [This.ID] 336 7. Security Considerations 338 This document does not introduce additional security requirements and 339 mechanisms other than the ones described in [RFC8402]. 341 8. Contributors 343 Zhenbin Li 344 Huawei Technologies 345 Huawei Campus, No. 156 Beiqing Rd. 346 Beijing 100095 347 China 349 Email: lizhenbin@huawei.com 351 Jie Dong 352 Huawei Technologies 353 Huawei Campus, No. 156 Beiqing Rd. 354 Beijing 100095 355 China 357 Email: jie.dong@huawei.com 359 9. Acknowledgements 361 The authors would like to thank Stefano Previdi and Zafar Ali for 362 their valuable comments and suggestions. 364 10. References 366 10.1. Normative References 368 [I-D.ietf-spring-srv6-network-programming] 369 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 370 Matsushima, S., and Z. Li, "SRv6 Network Programming", 371 draft-ietf-spring-srv6-network-programming-24 (work in 372 progress), October 2020. 374 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 375 Requirement Levels", BCP 14, RFC 2119, 376 DOI 10.17487/RFC2119, March 1997, 377 . 379 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 380 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 381 May 2017, . 383 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 384 Decraene, B., Litkowski, S., and R. Shakir, "Segment 385 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 386 July 2018, . 388 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 389 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 390 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 391 . 393 10.2. Informative References 395 [I-D.gandhi-spring-udp-pm] 396 Gandhi, R., Filsfils, C., daniel.voyer@bell.ca, d., 397 Salsano, S., Ventre, P., and M. Chen, "UDP Path for In- 398 band Performance Measurement for Segment Routing 399 Networks", draft-gandhi-spring-udp-pm-02 (work in 400 progress), September 2018. 402 [I-D.ietf-idr-sr-policy-path-segment] 403 Li, C., Li, Z., Telecom, C., Cheng, W., and K. Talaulikar, 404 "SR Policy Extensions for Path Segment and Bidirectional 405 Path", draft-ietf-idr-sr-policy-path-segment-01 (work in 406 progress), August 2020. 408 [I-D.ietf-pce-sr-bidir-path] 409 Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong, 410 "PCEP Extensions for Associated Bidirectional Segment 411 Routing (SR) Paths", draft-ietf-pce-sr-bidir-path-03 (work 412 in progress), September 2020. 414 [I-D.ietf-pce-sr-path-segment] 415 Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong, 416 "Path Computation Element Communication Protocol (PCEP) 417 Extension for Path Segment in Segment Routing (SR)", 418 draft-ietf-pce-sr-path-segment-01 (work in progress), May 419 2020. 421 [I-D.ietf-spring-mpls-path-segment] 422 Cheng, W., Li, H., Chen, M., Gandhi, R., and R. Zigler, 423 "Path Segment in MPLS Based Segment Routing Network", 424 draft-ietf-spring-mpls-path-segment-03 (work in progress), 425 September 2020. 427 [I-D.ietf-spring-segment-routing-mpls] 428 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 429 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 430 data plane", draft-ietf-spring-segment-routing-mpls-22 431 (work in progress), May 2019. 433 [I-D.ietf-spring-segment-routing-policy] 434 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 435 P. Mattes, "Segment Routing Policy Architecture", draft- 436 ietf-spring-segment-routing-policy-08 (work in progress), 437 July 2020. 439 [I-D.li-6man-srv6-path-segment-encap] 440 Li, C., Cheng, W., Li, Z., and D. Dhody, "Encapsulation of 441 Path Segment in SRv6", draft-li-6man-srv6-path-segment- 442 encap-03 (work in progress), September 2020. 444 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 445 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 446 May 2016, . 448 Authors' Addresses 450 Cheng Li 451 Huawei Technologies 453 Email: c.l@huawei.com 455 Weiqiang Cheng 456 China Mobile 458 Email: chengweiqiang@chinamobile.com 460 Mach(Guoyi) Chen 461 Huawei Technologies 463 Email: mach.chen@huawei.com 464 Dhruv Dhody 465 Huawei Technologies 466 Divyashree Techno Park, Whitefield 467 Bangalore, Karnataka 560066 468 India 470 Email: dhruv.ietf@gmail.com 472 Rakesh Gandhi 473 Cisco Systems, Inc. 474 Canada 476 Email: rgandhi@cisco.com