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