idnits 2.17.1 draft-li-spring-srv6-path-segment-06.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 (September 4, 2020) is 1330 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) == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-18 == 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-02 == 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-02 == 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-02 Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). 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: March 8, 2021 China Mobile 6 M. Chen 7 D. Dhody 8 Huawei Technologies 9 R. Gandhi 10 Cisco Systems, Inc. 11 September 4, 2020 13 Path Segment for SRv6 (Segment Routing in IPv6) 14 draft-li-spring-srv6-path-segment-06 16 Abstract 18 Segment Routing (SR) allows for a flexible definition of end-to-end 19 paths by encoding paths as sequences of sub-paths, called "segments". 20 Segment routing architecture can be implemented over an MPLS data 21 plane as well as an IPv6 data plane. 23 Further, Path Segment has been defined in order to identify an SR 24 path in SR-MPLS networks, and used for various use-cases such as end- 25 to-end SR Path Protection and Performance Measurement (PM) of an SR 26 path. Similar to SR-MPLS, this document defines the Path Segment in 27 SRv6 networks in order to identify an SRv6 path. 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 March 8, 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 . . . . . . . . . . . . . . . . . . 3 65 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 66 2. Use Cases of SRv6 Path Segment . . . . . . . . . . . . . . . 4 67 3. SRv6 Path Segment . . . . . . . . . . . . . . . . . . . . . . 5 68 4. SRv6 Path Segment Allocation . . . . . . . . . . . . . . . . 5 69 5. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 72 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 73 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 76 10.2. Informative References . . . . . . . . . . . . . . . . . 7 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 79 1. Introduction 81 Segment routing (SR) [RFC8402] is a source routing paradigm that 82 explicitly indicates the forwarding path for packets at the ingress 83 node by inserting an ordered list of instructions, called segments. 85 When segment routing is deployed on MPLS dataplane, called SR-MPLS 86 [I-D.ietf-spring-segment-routing-mpls], a segment is an MPLS label. 87 When segment routing is deployed on IPv6 dataplane, called SRv6 88 [RFC8754], a segment is a 128 bit value, and it can be an IPv6 89 address of a local interface but it does not have to. For supporting 90 SR, an extended header called Segment Routing Header (SRH), which 91 contains a list of SIDs and several needed information such as 92 Segments Left, has been defined in [RFC8754]. 94 In an SR-MPLS network, when a packet is transmitted along an SR path, 95 the labels in the MPLS label stack will be swapped or popped, so no 96 label or only the last label may be left in the MPLS label stack when 97 the packet reaches the egress node. Thus, the egress node can not 98 determine from which ingress node or SR path the packet came in. For 99 identifying an SR-MPLS path, Path Segment is defined in 100 [I-D.ietf-spring-mpls-path-segment]. 102 Likewise, a path needs to be identified in an SRv6 network for 103 several use cases such as binding bidirectional paths 104 [I-D.ietf-pce-sr-bidir-path] and end-to-end performance measurement 105 [I-D.gandhi-spring-udp-pm]. An SRv6 path can be identified by the 106 content of segment list (i.e., the several SRv6 segments that are in 107 the segment list). 109 However, the segment list may not be a good key to identify an SRv6 110 path, since the the length of segment list is flexible according to 111 the number of SIDs. Also, the length of SID list will be too long to 112 be a key when it contains many SIDs. For instance, if packet A uses 113 the SRH with 3 SIDs while Packet B uses the SRH with 10 SIDs, the key 114 to identify these two paths will be a 384-bits value and a 1280-bits 115 value. 117 This document defines a new SRv6 segment called "SRv6 Path Segment", 118 which is a 128-bits value, to identify an SRv6 path. Using the Path 119 Segment as an SRv6 SID will improve performance and operations in 120 both SR-MPLS and SRv6. 122 Also, In reduced mode [RFC8754], an SRv6 path can not be indentified 123 by the information carried by SRH. When the SRv6 Path Segment is 124 used in reduced SRH [RFC8754], the entire path information is 125 indicated by the Path Segment, and the performance will be better 126 than using SID list as the path identifier, while the overhead equals 127 to the normal SRH. 129 The SRv6 Path Segment will be used for identifying an SRv6 path and 130 path related services, and it will not be updated to the IPv6 131 destination address, so it is not routable. 133 1.1. Requirements Language 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 137 "OPTIONAL" in this document are to be interpreted as described in BCP 138 14 [RFC2119] [RFC8174] when, and only when, they appear in all 139 capitals, as shown here. 141 1.2. Terminology 143 MPLS: Multiprotocol Label Switching. 145 PM: Performance Measurement. 147 SID: Segment ID. 149 SR: Segment Routing. 151 SR-MPLS: Segment Routing with MPLS data plane. 153 SRH: Segment Routing Header. 155 PSID: Path Segment Identifier. 157 PSP: Penultimate Segment Popping. 159 Further, this document makes use of the terms defined in [RFC8402] 160 and [I-D.ietf-spring-srv6-network-programming]. 162 2. Use Cases of SRv6 Path Segment 164 Similar to SR-MPLS Path Segment [I-D.ietf-spring-mpls-path-segment], 165 SRv6 Path Segment also can be used for identifying an SRv6 Path in 166 some use cases: 168 o Performance Measurement: For Passive measurement [RFC7799], path 169 identification at the measuring points is the pre-requisite 170 [I-D.ietf-spring-mpls-path-segment]. SRv6 Path segment can be 171 used by the measuring points (e.g., the ingress/egress nodes of an 172 SRv6 path) or a centralized controller to correlate the packets 173 counts/timestamps, then packet loss/delay can be calculated. 175 o Bi-directioinal SRv6 Path Association: In some scenarios, such as 176 mobile backhaul transport network, there are requirements to 177 support bidirectional path. Similar to SR-MPLS 178 [I-D.ietf-spring-mpls-path-segment], to support bidirectional SRv6 179 path, a straightforward way is to bind two unidirectional SRv6 180 paths to a single bidirectional path. SRv6 Path segments can be 181 used to correlate the two unidirectional SRv6 paths at both ends 182 of the paths. [I-D.ietf-pce-sr-bidir-path] defines how to use 183 PCEP and Path segment to initiate a bidirectional SR path. 185 o End-to-end Path Protection: For end-to-end 1+1 path protection 186 (i.e., Live-Live case), the egress node of an SRv6 path needs to 187 know the set of paths that constitute the primary and the 188 secondary(s), in order to select the primary packet for onward 189 transmission, and to discard the packets from the secondary(s), so 190 each SRv6 path needs a unique path identifier at the egress node, 191 which can be an SRv6 Path Segment. 193 3. SRv6 Path Segment 195 As defined in [I-D.ietf-spring-srv6-network-programming], an SRv6 196 segment is a 128-bit value. 198 In order to identify an SRv6 path, this document defines a new 199 segment called SRv6 Path Segment. 201 The SRv6 Path Segment MUST appear only once in a SID list. The 202 detailed encoding of SRv6 Path Segment is out of scope of this 203 document, and it is defined in [I-D.li-6man-srv6-path-segment-encap]. 205 Depending on the use case, an SRv6 Path Segment identifies: 207 o an SRv6 path within an SRv6 domain 209 o an SRv6 Policy 211 o a Candidate-paths or a SID-List in a SRv6 Policy 212 [I-D.ietf-spring-segment-routing-policy] 214 Note that, based on the use-case, the different SID-Lists of SR 215 Policies may use the same SRv6 Path Segment. 217 4. SRv6 Path Segment Allocation 219 A Path Segment is a local segment allocated by an egress node. A 220 Path Segment can be allocated through several ways, such as CLI, BGP 221 [I-D.ietf-idr-sr-policy-path-segment], PCEP 222 [I-D.ietf-pce-sr-path-segment] or other ways. The mechanisms through 223 which a Path Segment is allocated is out of scope of this document. 225 When the Path Segment is allocated by the egress, it MUST be 226 distributed to the ingress node. In this case, only the egress will 227 process the Path Segment, and other nodes specified by SIDs in the 228 SID list do not know how to process the Path Segment. 230 Depending on the use case, a Path Segment may be distributed to the 231 SRv6 nodes along the SRv6 path. In this case, the SRv6 nodes that 232 learned Path Segment may process the Path Segment depending on the 233 use case. 235 5. Operations 237 An egress node or other SRv6 nodes along the SRv6 path supporting the 238 Path Segment processing will inspect the last entry of the segment 239 list (giving the the node will inspect the last entry in the SID list 240 and obtain the Path Segment. The processing of the Path Segment is 241 described in [I-D.li-6man-srv6-path-segment-encap]. 243 6. IANA Considerations 245 This document does not require any IANA actions. 247 7. Security Considerations 249 This document does not introduce additional security requirements and 250 mechanisms other than the ones described in [RFC8402]. 252 8. Contributors 254 Zhenbin Li 255 Huawei Technologies 256 Huawei Campus, No. 156 Beiqing Rd. 257 Beijing 100095 258 China 260 Email: lizhenbin@huawei.com 262 Jie Dong 263 Huawei Technologies 264 Huawei Campus, No. 156 Beiqing Rd. 265 Beijing 100095 266 China 268 Email: jie.dong@huawei.com 270 9. Acknowledgements 272 The authors would like to thank Stefano Previdi and Zafar Ali for 273 their valuable comments and suggestions. 275 10. References 276 10.1. Normative References 278 [I-D.ietf-spring-srv6-network-programming] 279 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 280 Matsushima, S., and Z. Li, "SRv6 Network Programming", 281 draft-ietf-spring-srv6-network-programming-18 (work in 282 progress), August 2020. 284 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 285 Requirement Levels", BCP 14, RFC 2119, 286 DOI 10.17487/RFC2119, March 1997, 287 . 289 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 290 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 291 May 2017, . 293 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 294 Decraene, B., Litkowski, S., and R. Shakir, "Segment 295 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 296 July 2018, . 298 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 299 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 300 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 301 . 303 10.2. Informative References 305 [I-D.gandhi-spring-udp-pm] 306 Gandhi, R., Filsfils, C., daniel.voyer@bell.ca, d., 307 Salsano, S., Ventre, P., and M. Chen, "UDP Path for In- 308 band Performance Measurement for Segment Routing 309 Networks", draft-gandhi-spring-udp-pm-02 (work in 310 progress), September 2018. 312 [I-D.ietf-idr-sr-policy-path-segment] 313 Li, C., Li, Z., Telecom, C., Cheng, W., and K. Talaulikar, 314 "SR Policy Extensions for Path Segment and Bidirectional 315 Path", draft-ietf-idr-sr-policy-path-segment-01 (work in 316 progress), August 2020. 318 [I-D.ietf-pce-sr-bidir-path] 319 Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong, 320 "PCEP Extensions for Associated Bidirectional Segment 321 Routing (SR) Paths", draft-ietf-pce-sr-bidir-path-02 (work 322 in progress), March 2020. 324 [I-D.ietf-pce-sr-path-segment] 325 Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong, 326 "Path Computation Element Communication Protocol (PCEP) 327 Extension for Path Segment in Segment Routing (SR)", 328 draft-ietf-pce-sr-path-segment-01 (work in progress), May 329 2020. 331 [I-D.ietf-spring-mpls-path-segment] 332 Cheng, W., Li, H., Chen, M., Gandhi, R., and R. Zigler, 333 "Path Segment in MPLS Based Segment Routing Network", 334 draft-ietf-spring-mpls-path-segment-02 (work in progress), 335 February 2020. 337 [I-D.ietf-spring-segment-routing-mpls] 338 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 339 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 340 data plane", draft-ietf-spring-segment-routing-mpls-22 341 (work in progress), May 2019. 343 [I-D.ietf-spring-segment-routing-policy] 344 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 345 P. Mattes, "Segment Routing Policy Architecture", draft- 346 ietf-spring-segment-routing-policy-08 (work in progress), 347 July 2020. 349 [I-D.li-6man-srv6-path-segment-encap] 350 Li, C., Cheng, W., Li, Z., and D. Dhody, "Encapsulation of 351 Path Segment in SRv6", draft-li-6man-srv6-path-segment- 352 encap-02 (work in progress), March 2020. 354 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 355 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 356 May 2016, . 358 Authors' Addresses 360 Cheng Li 361 Huawei Technologies 363 Email: c.l@huawei.com 365 Weiqiang Cheng 366 China Mobile 368 Email: chengweiqiang@chinamobile.com 369 Mach(Guoyi) Chen 370 Huawei Technologies 372 Email: mach.chen@huawei.com 374 Dhruv Dhody 375 Huawei Technologies 376 Divyashree Techno Park, Whitefield 377 Bangalore, Karnataka 560066 378 India 380 Email: dhruv.ietf@gmail.com 382 Rakesh Gandhi 383 Cisco Systems, Inc. 384 Canada 386 Email: rgandhi@cisco.com