idnits 2.17.1 draft-li-6man-srv6-path-segment-encap-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 (November 4, 2019) is 1628 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-05 == Outdated reference: A later version (-07) exists of draft-li-spring-srv6-path-segment-03 == Outdated reference: A later version (-11) exists of draft-gandhi-spring-twamp-srpm-03 == Outdated reference: A later version (-09) exists of draft-ietf-idr-sr-policy-path-segment-00 == 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-segment-routing-policy-03 == Outdated reference: A later version (-07) exists of draft-li-pce-sr-bidir-path-06 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: May 7, 2020 China Mobile 6 Z. Li 7 D. Dhody 8 Huawei Technologies 9 November 4, 2019 11 Encapsulation of Path Segment in SRv6 12 draft-li-6man-srv6-path-segment-encap-01 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 May 7, 2020. 41 Copyright Notice 43 Copyright (c) 2019 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 [I-D.ietf-6man-segment-routing-header], and it uses the a new IPv6 83 [RFC8200] Extension Header (EH) called the IPv6 Segment Routing 84 Header (SRH) [I-D.ietf-6man-segment-routing-header] to construct SRv6 85 path. As per [I-D.ietf-spring-srv6-network-programming], an SRv6 86 segment is a 128-bit value, which can be represented as LOC:FUNCT, 87 where LOC is the L most significant bits and FUNCT is the 128-L least 88 significant bits. Most often the LOC part of the SID is routable and 89 leads to the node which instantiates that SID. The FUNCT part of the 90 SID is an opaque identification of a local function bound to the SID. 92 In several use cases, such as binding bidirectional path 93 [I-D.li-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-6man-segment-routing-header] 319 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 320 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 321 (SRH)", draft-ietf-6man-segment-routing-header-26 (work in 322 progress), October 2019. 324 [I-D.ietf-spring-srv6-network-programming] 325 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 326 Matsushima, S., and Z. Li, "SRv6 Network Programming", 327 draft-ietf-spring-srv6-network-programming-05 (work in 328 progress), October 2019. 330 [I-D.li-spring-srv6-path-segment] 331 Li, C., Cheng, W., Chen, M., Dhody, D., Li, Z., Dong, J., 332 and R. Gandhi, "Path Segment for SRv6 (Segment Routing in 333 IPv6)", draft-li-spring-srv6-path-segment-03 (work in 334 progress), August 2019. 336 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 337 Requirement Levels", BCP 14, RFC 2119, 338 DOI 10.17487/RFC2119, March 1997, 339 . 341 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 342 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 343 May 2017, . 345 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 346 (IPv6) Specification", STD 86, RFC 8200, 347 DOI 10.17487/RFC8200, July 2017, 348 . 350 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 351 Decraene, B., Litkowski, S., and R. Shakir, "Segment 352 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 353 July 2018, . 355 7.2. Informative References 357 [I-D.gandhi-spring-twamp-srpm] 358 Gandhi, R., Filsfils, C., Voyer, D., Chen, M., and B. 359 Janssens, "Performance Measurement Using TWAMP Light for 360 Segment Routing Networks", draft-gandhi-spring-twamp- 361 srpm-03 (work in progress), October 2019. 363 [I-D.ietf-idr-sr-policy-path-segment] 364 Li, C., Li, Z., Telecom, C., Cheng, W., and K. Talaulikar, 365 "SR Policy Extensions for Path Segment and Bidirectional 366 Path", draft-ietf-idr-sr-policy-path-segment-00 (work in 367 progress), October 2019. 369 [I-D.ietf-pce-sr-path-segment] 370 Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong, 371 "Path Computation Element Communication Protocol (PCEP) 372 Extension for Path Segment in Segment Routing (SR)", 373 draft-ietf-pce-sr-path-segment-00 (work in progress), 374 October 2019. 376 [I-D.ietf-spring-segment-routing-policy] 377 Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and 378 P. Mattes, "Segment Routing Policy Architecture", draft- 379 ietf-spring-segment-routing-policy-03 (work in progress), 380 May 2019. 382 [I-D.li-pce-sr-bidir-path] 383 Li, C., Chen, M., Cheng, W., Li, Z., Dong, J., Gandhi, R., 384 and Q. Xiong, "PCEP Extensions for Associated 385 Bidirectional Segment Routing (SR) Paths", draft-li-pce- 386 sr-bidir-path-06 (work in progress), August 2019. 388 Authors' Addresses 390 Cheng Li 391 Huawei Technologies 393 Email: chengli13@huawei.com 395 Weiqiang Cheng 396 China Mobile 398 Email: chengweiqiang@chinamobile.com 400 Zhenbin Li 401 Huawei Technologies 402 Huawei Campus, No. 156 Beiqing Rd. 403 Beijing 100095 404 China 406 Email: lizhenbin@huawei.com 408 Dhruv Dhody 409 Huawei Technologies 410 Divyashree Techno Park, Whitefield 411 Bangalore 560066 412 India 414 Email: dhruv.ietf@gmail.com