idnits 2.17.1 draft-li-spring-srv6-path-segment-01.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 (June 26, 2019) is 1765 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 202 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-21 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-00 == Outdated reference: A later version (-22) exists of draft-ietf-spring-mpls-path-segment-00 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-03 == Outdated reference: A later version (-07) exists of draft-li-pce-sr-bidir-path-05 == Outdated reference: A later version (-08) exists of draft-li-pce-sr-path-segment-05 Summary: 0 errors (**), 0 flaws (~~), 7 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: December 28, 2019 China Mobile 6 M. Chen 7 D. Dhody 8 Z. Li 9 J. Dong 10 Huawei Technologies 11 R. Gandhi 12 Cisco Systems, Inc. 13 June 26, 2019 15 Path Segment for SRv6 (Segment Routing in IPv6) 16 draft-li-spring-srv6-path-segment-01 18 Abstract 20 Segment Routing (SR) allows for a flexible definition of end-to-end 21 paths by encoding paths as sequences of topological sub-paths, called 22 "segments". Segment routing architecture can be implemented over an 23 MPLS data plane as well as an IPv6 data plane. 25 Further, Path Segment has been defined to identify an SR path in SR- 26 MPLS networks, and used for various use-cases such as end-to-end SR 27 Path Protection and Performance Measurement (PM) of an SR path. 28 Similar to SR-MPLS, this document defines Path Segment in SRv6 29 networks to identify an SRv6 path. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on December 28, 2019. 48 Copyright Notice 50 Copyright (c) 2019 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 67 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. SRv6 Path Segment . . . . . . . . . . . . . . . . . . . . . . 4 69 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 72 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 73 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 75 7.2. Informative References . . . . . . . . . . . . . . . . . 6 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 78 1. Introduction 80 Segment routing (SR) [RFC8402] is a source routing paradigm that 81 explicitly indicates the forwarding path for packets at the ingress 82 node by inserting an ordered list of instructions, called segments. 84 When segment routing is deployed on MPLS dataplane, called SR-MPLS 85 [I-D.ietf-spring-segment-routing-mpls], a segment is an MPLS label. 86 When segment routing is deployed on IPv6 dataplane, called SRv6 87 [I-D.ietf-6man-segment-routing-header], a segment is a 128 bit value, 88 and it can be an IPv6 address of a local interface but it does not 89 have to. For supporting SR, an extended header called Segment 90 Routing Header (SRH), which contains a list of SIDs and several 91 needed information such as Segments Left, has been defined in 92 [I-D.ietf-6man-segment-routing-header]. 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 comes. 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 path 104 [I-D.li-pce-sr-bidir-path] and end-to-end performance measurement 105 [I-D.gandhi-spring-udp-pm]. A SRv6 path can be identified by the 106 full segment list that made up of several SRv6 segments. However, 107 the segment list may not be a good key to identify an SRv6 path, 108 since the the length of segment list is too long and flexible 109 according to the number of SIDs. 111 This document defines a new SRv6 segment called "SRv6 Path Segment" 112 to identify an SRv6 path. Using of Path Segment as an SRv6 SID 113 (instead of path ID carried by an SRH TLV) will see benefit in 114 performance and also ease of using the same concept in SR, 115 irrespective of SR-MPLS and SRv6 data planes. The Path Segment is 116 inserted as the last segment in the segment list and will not affect 117 the order of the original SID list. 119 1.1. Requirements Language 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 123 "OPTIONAL" in this document are to be interpreted as described in BCP 124 14 [RFC2119] [RFC8174] when, and only when, they appear in all 125 capitals, as shown here. 127 1.2. Terminology 129 DM: Delay Measurement. 131 LM: Loss Measurement. 133 MPLS: Multiprotocol Label Switching. 135 PM: Performance Measurement. 137 PSID: Path Segment ID. 139 SID: Segment ID. 141 SL: Segment List. 143 SR: Segment Routing. 145 SR-MPLS: Segment Routing with MPLS data plane. 147 SRH: Segment Routing Header. 149 PSID: Path Segment ID. 151 PSP: Penultimate Segment Popping. 153 Further, this document makes use of the terms defined in [RFC8402] 154 and [I-D.ietf-spring-srv6-network-programming]. 156 2. SRv6 Path Segment 158 As defined in [I-D.ietf-spring-srv6-network-programming], a SRv6 159 segment is a 128 bit value, which can be present as LOC:FUNCT. 161 For identifying an SRv6 path, this document defines a new segment 162 called SRv6 Path Segment. 164 A Path Segment (consisted of LOC and FUNCT part) can identify an SRv6 165 path within an SRv6 domain. Also, the SRv6 Path Segment may be used 166 to identify an SRv6 Policy, its Candidate-path or a SID-List 167 [I-D.ietf-spring-segment-routing-policy] terminating on an egress 168 node depending on the use-case. 170 Note that, based on the use-case, the different SID-Lists of SR 171 Policy may use the same SRv6 Path Segment. 173 3. Operation 175 A Path Segment is a local segment of egress node, it is allocated by 176 the egress node. A Path Segment can be allocated by several ways, 177 such as CLI, BGP [I-D.li-idr-sr-policy-path-segment-distribution], 178 PCEP [I-D.li-pce-sr-path-segment] or other ways. The procedure of 179 Path Segment allocation is out of scope of this document. 181 When the Path Segment is allocated by the egress, it MUST be 182 distributed to the ingress node at minimum. In this case, the 183 transit nodes do not know how to process the Path Segment. 185 A Path Segment is used for path identification and it MUST NOT be 186 copied to the IPv6 destination address. 188 The SRv6 Path Segment MUST be inserted as the last entry in the SID 189 list without affecting the segment left field in the SRH. The last 190 entry field in SRH should be set as the index of the Path Segment, 191 which is the last entry in the SID list. In this case, Path Segment 192 presenting to a transit node is an error condition. 194 Also, PSP of the SRH MUST be disabled. 196 The Path Segment SHOULD appear only once in a SID list, and the one 197 that appears at the last entry in the SID list will be processed 198 while the rests will be ignored. 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | | 202 | Segment List[0] (128 bits IPv6 address) | 203 | | 204 | | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | | 207 | | 208 | ... | 209 | | 210 | | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | | 213 | Segment List[n-1] (128 bits IPv6 address) | 214 | | 215 | | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | | 218 | Path Segment(Segment List[n], 128 bits IPv6 address) | 219 | | 220 | | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 Figure 1. SRv6 Path Segment in SID List 225 If an egress node supports Path Segment processing and related OAM 226 mechanisms are enabled, the node will inspect the last entry in the 227 SID list to obtain the Path Segment. The behavior of Path Segment 228 related function will be defined in the future version of this draft 229 or related use-case drafts. 231 4. IANA Considerations 233 This document does not require any IANA actions. 235 5. Security Considerations 237 This document does not introduce additional security requirements and 238 mechanisms other than the ones described in [RFC8402]. 240 6. Acknowledgements 242 The authors would like to thank Zafar Ali for his valuable comments 243 and suggestions. 245 7. References 247 7.1. Normative References 249 [I-D.ietf-6man-segment-routing-header] 250 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 251 Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment 252 Routing Header (SRH)", draft-ietf-6man-segment-routing- 253 header-21 (work in progress), June 2019. 255 [I-D.ietf-spring-srv6-network-programming] 256 Filsfils, C., Camarillo, P., Leddy, J., 257 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 258 Network Programming", draft-ietf-spring-srv6-network- 259 programming-00 (work in progress), April 2019. 261 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 262 Requirement Levels", BCP 14, RFC 2119, 263 DOI 10.17487/RFC2119, March 1997, 264 . 266 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 267 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 268 May 2017, . 270 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 271 Decraene, B., Litkowski, S., and R. Shakir, "Segment 272 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 273 July 2018, . 275 7.2. Informative References 277 [I-D.gandhi-spring-udp-pm] 278 Gandhi, R., Filsfils, C., daniel.voyer@bell.ca, d., 279 Salsano, S., Ventre, P., and M. Chen, "UDP Path for In- 280 band Performance Measurement for Segment Routing 281 Networks", draft-gandhi-spring-udp-pm-02 (work in 282 progress), September 2018. 284 [I-D.ietf-spring-mpls-path-segment] 285 Cheng, W., Li, H., Chen, M., Gandhi, R., and R. Zigler, 286 "Path Segment in MPLS Based Segment Routing Network", 287 draft-ietf-spring-mpls-path-segment-00 (work in progress), 288 March 2019. 290 [I-D.ietf-spring-segment-routing-mpls] 291 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 292 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 293 data plane", draft-ietf-spring-segment-routing-mpls-22 294 (work in progress), May 2019. 296 [I-D.ietf-spring-segment-routing-policy] 297 Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., 298 bogdanov@google.com, b., and P. Mattes, "Segment Routing 299 Policy Architecture", draft-ietf-spring-segment-routing- 300 policy-03 (work in progress), May 2019. 302 [I-D.li-idr-sr-policy-path-segment-distribution] 303 Li, C., Chen, M., Dong, J., and Z. Li, "Segment Routing 304 Policies for Path Segment and Bidirectional Path", draft- 305 li-idr-sr-policy-path-segment-distribution-01 (work in 306 progress), October 2018. 308 [I-D.li-pce-sr-bidir-path] 309 Li, C., Chen, M., Cheng, W., Li, Z., Dong, J., Gandhi, R., 310 and Q. Xiong, "PCEP Extensions for Associated 311 Bidirectional Segment Routing (SR) Paths", draft-li-pce- 312 sr-bidir-path-05 (work in progress), March 2019. 314 [I-D.li-pce-sr-path-segment] 315 Li, C., Chen, M., Cheng, W., Dong, J., Li, Z., Gandhi, R., 316 and Q. Xiong, "Path Computation Element Communication 317 Protocol (PCEP) Extension for Path Segment in Segment 318 Routing (SR)", draft-li-pce-sr-path-segment-05 (work in 319 progress), March 2019. 321 Authors' Addresses 323 Cheng Li 324 Huawei Technologies 326 Email: chengli13@huawei.com 327 Weiqiang Cheng 328 China Mobile 330 Email: chengweiqiang@chinamobile.com 332 Mach(Guoyi) Chen 333 Huawei Technologies 335 Email: mach.chen@huawei.com 337 Dhruv Dhody 338 Huawei Technologies 339 Divyashree Techno Park, Whitefield 340 Bangalore, Karnataka 560066 341 India 343 Email: dhruv.ietf@gmail.com 345 Zhenbin Li 346 Huawei Technologies 347 Huawei Campus, No. 156 Beiqing Rd. 348 Beijing 100095 349 China 351 Email: lizhenbin@huawei.com 353 Jie Dong 354 Huawei Technologies 355 Huawei Campus, No. 156 Beiqing Rd. 356 Beijing 100095 357 China 359 Email: jie.dong@huawei.com 361 Rakesh Gandhi 362 Cisco Systems, Inc. 363 Canada 365 Email: rgandhi@cisco.com