idnits 2.17.1 draft-li-6man-srv6-path-segment-encap-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 (September 4, 2020) is 1329 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 165 -- Looks like a reference, but probably isn't: '4' on line 284 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-18 == Outdated reference: A later version (-07) exists of draft-li-spring-srv6-path-segment-05 == Outdated reference: A later version (-11) exists of draft-gandhi-spring-twamp-srpm-10 == 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-segment-routing-policy-08 Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6man Working Group C. Li 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track W. Cheng 5 Expires: March 8, 2021 China Mobile 6 Z. Li 7 D. Dhody 8 Huawei Technologies 9 September 4, 2020 11 Encapsulation of Path Segment in SRv6 12 draft-li-6man-srv6-path-segment-encap-03 14 Abstract 16 Segment Routing (SR) allows for a flexible definition of end-to-end 17 paths by encoding paths as sequences of sub-paths, called "segments". 18 Segment routing architecture can be implemented over IPv6 data plane, 19 called SRv6. In some use-cases such as end-to-end SR Path Protection 20 and Performance Measurement (PM), SRv6 path need to be identified. 21 This document defines the encoding and processing of Path Segment in 22 SRv6 networks. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on March 8, 2021. 41 Copyright Notice 43 Copyright (c) 2020 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 60 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Encoding of SRv6 Path Segment . . . . . . . . . . . . . . . . 3 62 2.1. Encapsulation of SRv6 Path Segment . . . . . . . . . . . 4 63 2.2. Format of SRv6 Path Segment . . . . . . . . . . . . . . . 5 64 2.2.1. SRv6 Path Segment: Locator and Local ID . . . . . . . 5 65 2.2.2. SRv6 Path Segment: Global ID . . . . . . . . . . . . 5 66 3. Processing of SRv6 Path Segment . . . . . . . . . . . . . . . 6 67 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 69 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 70 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 72 7.2. Informative References . . . . . . . . . . . . . . . . . 8 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 75 1. Introduction 77 Segment routing (SR) [RFC8402] is a source routing paradigm that 78 explicitly indicates the forwarding path for packets at the ingress 79 node by inserting an ordered list of instructions, called segments. 81 When segment routing is deployed on IPv6 dataplane, it is called SRv6 82 [RFC8754], and it uses the a new IPv6 [RFC8200] Extension Header (EH) 83 called the IPv6 Segment Routing Header (SRH) [RFC8754] to construct 84 SRv6 path. As per [I-D.ietf-spring-srv6-network-programming], an 85 SRv6 segment is a 128-bit value, which can be represented as 86 LOC:FUNCT, where LOC is the L most significant bits and FUNCT is the 87 128-L least significant bits. Most often the LOC part of the SID is 88 routable and leads to the node which instantiates that SID. The 89 FUNCT part of the SID is an opaque identification of a local function 90 bound to the SID. 92 In several use cases, such as binding bidirectional path 93 [I-D.ietf-pce-sr-bidir-path] and end-to-end performance measurement 94 [I-D.gandhi-spring-twamp-srpm], the ability to implement path 95 identification is a pre-requisite. In SRv6, an SRv6 path can be 96 identified by the content of the segment list. However, the segment 97 list may not be a good key to identify an SRv6 path, since the length 98 of segment list is too long and flexible according to the number of 99 SIDs. Therefore, [I-D.li-spring-srv6-path-segment] defines SRv6 Path 100 Segment in order to identify an SRv6 path. 102 This document defines the encoding and processing of SRv6 Path 103 Segment in SRv6 networks. 105 1.1. Requirements Language 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 109 "OPTIONAL" in this document are to be interpreted as described in BCP 110 14 [RFC2119] [RFC8174] when, and only when, they appear in all 111 capitals, as shown here. 113 1.2. Terminology 115 PM: Performance Measurement. 117 SID: Segment ID. 119 SL: Segment List. 121 SR: Segment Routing. 123 SRH: Segment Routing Header. 125 PSID: Path Segment Identifier. 127 PSP: Penultimate Segment Popping. 129 Further, this document makes use of the terms defined in [RFC8402] 130 and [I-D.ietf-spring-srv6-network-programming]. 132 2. Encoding of SRv6 Path Segment 134 This section will describe the encoding of SRv6 Path Segment 135 [I-D.li-spring-srv6-path-segment] in SRH. As per 136 [I-D.li-spring-srv6-path-segment], an SRv6 Path Segment is a 128-bits 137 value, which identifies an SRv6 path. Depending on the use case, an 138 SRv6 Path Segment can identify: 140 o an SRv6 path within an SRv6 domain 142 o an SRv6 Policy 143 o a Candidate-paths or a SID-List in a SRv6 Policy 144 [I-D.ietf-spring-segment-routing-policy]. 146 2.1. Encapsulation of SRv6 Path Segment 148 The SRv6 Path Segment MUST appear only once in a SID list, and it 149 MUST appear at the last entry, so the SRv6 Path Segment MUST NOT be 150 copied to the IPv6 destination address. The format of the SRv6 Path 151 Segment follows the format described in section 2.2. 153 In order to indicate the existence of Path Segment in the SRH, this 154 document defines a P-bit in SRH flag field. The encapsulation of 155 SRv6 Path Segment is shown below. 157 0 1 2 3 158 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 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Last Entry | Flags |P| Tag | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | | 165 | Segment List[0] (128 bits IPv6 address) | 166 | | 167 | | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | | 170 | | 171 ... 172 | | 173 | | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | | 176 | Segment List[n-1] (128 bits IPv6 address) | 177 | | 178 | | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | | 181 | SRv6 Path Segment (Segment List[n],128 bits IPv6 value) | 182 | | 183 | | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 // // 186 // Optional Type Length Value objects (variable) // 187 // // 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 Figure 1. SRv6 Path Segment in SID List 192 o P-bit: set when SRv6 Path Segment is inserted. It SHOULD be 193 ignored when a node does not support SRv6 Path Segment processing. 195 2.2. Format of SRv6 Path Segment 197 This document proposes two types of SRv6 Path Segment format. 199 Editor's Note: Authors would like to request comments of these 200 encoding mechanisms of SRv6 Path Segment. The appropriate encoding 201 will be maintained while the rest will be deleted in the future 202 version of this document. 204 2.2.1. SRv6 Path Segment: Locator and Local ID 206 As per [I-D.ietf-spring-srv6-network-programming], an SRv6 segment is 207 a 128-bit value, which can be represented as LOC:FUNCT, where LOC is 208 the L most significant bits and FUNCT is the 128-L least significant 209 bits. L is called the locator length and is flexible. Each operator 210 is free to use the locator length it chooses. Most often the LOC 211 part of the SID is routable and leads to the node which instantiates 212 that SID. The FUNCT part of the SID is an opaque identification of a 213 local function bound to the SID. The FUNCT value zero is invalid. 215 SRv6 Path Segment can follow the format, where the LOC part 216 identifies the egress node that allocates the Path Segment, and the 217 FUNCT part is an unique local ID to identify an SRv6 Path towards to 218 the egress on the egress. 220 The Function Type of SRv6 Path Segment is END.PSID (End Function with 221 Path Segment Identifier, to be allocated by IANA). 223 The proposed P bit can be used to identify that the last SID is an 224 SRv6 Path Segment. 226 +--------------------------------------------------------------+ 227 | Locator | Function ID | 228 +--------------------------------------------------------------+ 230 |<-------------------------128 bits--------------------------->| 232 Figure 2. PSID in Format LOC:FUNCT 234 2.2.2. SRv6 Path Segment: Global ID 236 An SRv6 Path Segment ID can be a Global ID, and its format depends on 237 the use case. 239 The SRv6 Path Segment will not be copied to the IPv6 Destination 240 Address, so the SRv6 Path Segment ID can be allocated from an 241 independent 128-bits ID Space. In this case, a new table should be 242 maintained at the node for SRv6 Path Segment. The proposed P bit can 243 be used to identify that the last SID is an SRv6 Path Segment and 244 need to be looked up in the SRv6 Path Segment table. 246 +--------------------------------------------------------------+ 247 | Global ID/PSID | 248 +--------------------------------------------------------------+ 250 |<-------------------------128 bits--------------------------->| 252 Figure 3. A Global ID as an PSID 254 3. Processing of SRv6 Path Segment 256 As per [I-D.li-spring-srv6-path-segment], an SRv6 Path Segment is a 257 local segment allocated by an egress node. An SRv6 Path Segment can 258 be allocated through several ways, such as CLI, BGP 259 [I-D.ietf-idr-sr-policy-path-segment], PCEP 260 [I-D.ietf-pce-sr-path-segment] or other means. The mechanisms 261 through which an SRv6 Path Segment is allocated is out of scope of 262 this document. 264 When the SRv6 Path Segment is allocated by the egress, it MUST be 265 distributed to the ingress node. In this case, only the egress will 266 process the SRv6 Path Segment, and other nodes specified by SIDs in 267 the SID list do not know how to process the SRv6 Path Segment. 269 An SRv6 Path Segment may be distributed to the SRv6 nodes along the 270 SRv6 path. In this case, the SRv6 nodes that learn SRv6 Path Segment 271 may process the SRv6 Path Segment depending on the use case. 273 When the SRv6 Path Segment is used, the following rules apply: 275 o The SRv6 Path Segment MUST appear only once in a SID list, and it 276 MUST appear at the last entry. Only the one that appears at the 277 last entry in the SID list will be processed. SRv6 Path Segment 278 appears at other location in the SID list will be treated as an 279 error. 281 o When an SRv6 Path Segment is inserted, the SL MUST be initiated to 282 be less than the value of Last Entry, and will not point to SRv6 283 Path Segment. For instance, when the Last entry is 4, the SID 284 List[4] is the SRv6 Path Segment, so the SL MUST be set to 3 or 285 other numbers less than Last entry. 287 o The SRv6 Path Segment MUST NOT be copied to the IPv6 destination 288 address. 290 o Penultimate Segment Popping (PSP, as defined in 291 [I-D.ietf-spring-srv6-network-programming]) MUST be disabled. 293 o The ingress needs to set the P-bit when an SRv6 Path Segment is 294 inserted in the SID List. Nodes that supporting SRv6 Path Segment 295 processing will inspect the last entry to process SRv6 Path 296 Segment when the P-bit is set. When the P-bit is unset, the nodes 297 will not inspect the last entry. 299 o The specific SRv6 Path Segment processing depends on use cases, 300 and it is out of scope of this document. 302 4. IANA Considerations 304 TBA 306 5. Security Considerations 308 TBA 310 6. Acknowledgements 312 TBA 314 7. References 316 7.1. Normative References 318 [I-D.ietf-spring-srv6-network-programming] 319 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 320 Matsushima, S., and Z. Li, "SRv6 Network Programming", 321 draft-ietf-spring-srv6-network-programming-18 (work in 322 progress), August 2020. 324 [I-D.li-spring-srv6-path-segment] 325 Li, C., Cheng, W., Chen, M., Dhody, D., and R. Gandhi, 326 "Path Segment for SRv6 (Segment Routing in IPv6)", draft- 327 li-spring-srv6-path-segment-05 (work in progress), March 328 2020. 330 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 331 Requirement Levels", BCP 14, RFC 2119, 332 DOI 10.17487/RFC2119, March 1997, 333 . 335 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 336 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 337 May 2017, . 339 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 340 (IPv6) Specification", STD 86, RFC 8200, 341 DOI 10.17487/RFC8200, July 2017, 342 . 344 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 345 Decraene, B., Litkowski, S., and R. Shakir, "Segment 346 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 347 July 2018, . 349 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 350 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 351 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 352 . 354 7.2. Informative References 356 [I-D.gandhi-spring-twamp-srpm] 357 Gandhi, R., Filsfils, C., Voyer, D., Chen, M., and B. 358 Janssens, "Performance Measurement Using TWAMP Light for 359 Segment Routing Networks", draft-gandhi-spring-twamp- 360 srpm-10 (work in progress), August 2020. 362 [I-D.ietf-idr-sr-policy-path-segment] 363 Li, C., Li, Z., Telecom, C., Cheng, W., and K. Talaulikar, 364 "SR Policy Extensions for Path Segment and Bidirectional 365 Path", draft-ietf-idr-sr-policy-path-segment-01 (work in 366 progress), August 2020. 368 [I-D.ietf-pce-sr-bidir-path] 369 Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong, 370 "PCEP Extensions for Associated Bidirectional Segment 371 Routing (SR) Paths", draft-ietf-pce-sr-bidir-path-02 (work 372 in progress), March 2020. 374 [I-D.ietf-pce-sr-path-segment] 375 Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong, 376 "Path Computation Element Communication Protocol (PCEP) 377 Extension for Path Segment in Segment Routing (SR)", 378 draft-ietf-pce-sr-path-segment-01 (work in progress), May 379 2020. 381 [I-D.ietf-spring-segment-routing-policy] 382 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 383 P. Mattes, "Segment Routing Policy Architecture", draft- 384 ietf-spring-segment-routing-policy-08 (work in progress), 385 July 2020. 387 Authors' Addresses 389 Cheng Li 390 Huawei Technologies 392 Email: c.l@huawei.com 394 Weiqiang Cheng 395 China Mobile 397 Email: chengweiqiang@chinamobile.com 399 Zhenbin Li 400 Huawei Technologies 401 Huawei Campus, No. 156 Beiqing Rd. 402 Beijing 100095 403 China 405 Email: lizhenbin@huawei.com 407 Dhruv Dhody 408 Huawei Technologies 409 Divyashree Techno Park, Whitefield 410 Bangalore 560066 411 India 413 Email: dhruv.ietf@gmail.com