idnits 2.17.1 draft-ietf-idr-sr-policy-path-segment-04.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 (July 8, 2021) is 1021 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 (-26) exists of draft-ietf-idr-segment-routing-te-policy-11 == Outdated reference: A later version (-22) exists of draft-ietf-spring-mpls-path-segment-04 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-11 == Outdated reference: A later version (-07) exists of draft-ietf-spring-srv6-path-segment-00 == Outdated reference: A later version (-30) exists of draft-ietf-mpls-bfd-directed-17 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Interdomain Routing Working Group C. Li 3 Internet-Draft Z. Li 4 Intended status: Standards Track Huawei Technologies 5 Expires: January 9, 2022 Y. Yin 6 China Telecom 7 W. Cheng 8 China Mobile 9 K. Talaulikar 10 Cisco Systems 11 July 8, 2021 13 SR Policy Extensions for Path Segment and Bidirectional Path 14 draft-ietf-idr-sr-policy-path-segment-04 16 Abstract 18 A Segment Routing (SR) policy is a set of candidate SR paths 19 consisting of one or more segment lists with necessary path 20 attributes. For each SR path, it may also have its own path 21 attributes, and Path Segment is one of them. A Path Segment is 22 defined to identify an SR path, which can be used for performance 23 measurement, path correlation, and end-2-end path protection. Path 24 Segment can be also used to correlate two unidirectional SR paths 25 into a bidirectional SR path which is required in some scenarios, for 26 example, mobile backhaul transport network. 28 This document defines extensions to BGP to distribute SR policies 29 carrying Path Segment and bidirectional path information. 31 Requirements Language 33 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 34 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 35 document are to be interpreted as described in RFC 2119 [RFC2119]. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on January 9, 2022. 54 Copyright Notice 56 Copyright (c) 2021 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (https://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 74 3. Path Segment in SR Policy . . . . . . . . . . . . . . . . . . 3 75 3.1. SR Path Segment Sub-TLV . . . . . . . . . . . . . . . . . 5 76 4. SR Policy for Bidirectional Path . . . . . . . . . . . . . . 7 77 4.1. Reverse Path Segment List Sub-TLV . . . . . . . . . . . . 7 78 5. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 8 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 80 6.1. Existing Registry: BGP Tunnel Encapsulation Attribute 81 sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . . 9 82 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 83 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 84 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 85 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 86 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 87 10.2. Informative References . . . . . . . . . . . . . . . . . 11 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 90 1. Introduction 92 Segment routing (SR) [RFC8402] is a source routing paradigm that 93 explicitly indicates the forwarding path for packets at the ingress 94 node. The ingress node steers packets into a specific path according 95 to the Segment Routing Policy ( SR Policy) as defined in 96 [I-D.ietf-spring-segment-routing-policy]. For distributing SR 97 policies to the headend, [I-D.ietf-idr-segment-routing-te-policy] 98 specifies a mechanism by using BGP, and new sub-TLVs are defined for 99 SR Policies in BGP UPDATE message. 101 In many use cases such as performance measurement, the path to which 102 the packets belong is required to be identified. Futhermore, in some 103 scenarios, for example, mobile backhaul transport network, there are 104 requirements to support bidirectional path. However, there is no 105 path identification information for each Segment List in the SR 106 Policies defined in [I-D.ietf-spring-segment-routing-policy]. Also, 107 the SR Policies defined in [I-D.ietf-spring-segment-routing-policy] 108 only supports unidirectional SR paths. 110 Therefore, this document defines the extension to SR policies that 111 carry Path Segment in the Segment List and support bidirectional 112 path. The Path Segment can be a Path Segment in SR-MPLS 113 [I-D.ietf-spring-mpls-path-segment] and SRv6 114 [I-D.ietf-spring-srv6-path-segment], or other IDs that can identify a 115 path. Also, this document defines extensions to BGP to distribute SR 116 policies carrying Path Segment and bidirectional path information. 118 2. Terminology 120 This memo makes use of the terms defined in [RFC8402] and 121 [I-D.ietf-idr-segment-routing-te-policy]. 123 2.1. Requirements Language 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 127 "OPTIONAL" in this document are to be interpreted as described in BCP 128 14 [RFC2119] [RFC8174] when, and only when, they appear in all 129 capitals, as shown here. 131 3. Path Segment in SR Policy 133 As defined in [I-D.ietf-idr-segment-routing-te-policy] , the SR 134 Policy encoding structure is as follows: 136 SR Policy SAFI NLRI: 137 Attributes: 138 Tunnel Encaps Attribute (23) 139 Tunnel Type: SR Policy 140 Binding SID 141 Preference 142 Priority 143 Policy Name 144 Explicit NULL Label Policy (ENLP) 145 Segment List 146 Weight 147 Segment 148 Segment 149 ... 150 ... 152 An SR path can be specified by an Segment List sub-TLV that contains 153 a set of segment sub-TLVs and other sub-TLVs as shown above. As 154 defined in [I-D.ietf-spring-segment-routing-policy], a candidate path 155 includes multiple SR paths specified by SID list. The Path Segment 156 can be used for identifying an SR path(specified by SID list) from 157 the headend and the tailend. Also, it can be used for identifying an 158 SR candidate path in some use cases if needed. This document defines 159 a new Path Segment sub-TLV within Segment List sub-TLV, the details 160 will be described at section 3.1. The new SR Policy encoding 161 structure with Path Segmentg sub-TLV is expressed as below: 163 SR Policy SAFI NLRI: 164 Attributes: 165 Tunnel Encaps Attribute (23) 166 Tunnel Type: SR Policy 167 Binding SID 168 Preference 169 Priority 170 Policy Name 171 Explicit NULL Label Policy (ENLP) 172 Segment List 173 Weight 174 Path Segment 175 Segment 176 Segment 177 ... 178 Segment List 179 Weight 180 Path Segment 181 Segment 182 Segment 183 ... 184 ... 186 The Path Segment is used to identified an SR path, and it can be used 187 in OAM or IOAM use cases. When all the SID Lists within a candidate 188 path share the same Path Segment ID, the Path Segment can be used to 189 collect the aggregated information of the candidate path. Multiple 190 Path Segment MAY be included in a Segment List for different use 191 cases, all of them SHOULD be inserted into the SID List. 193 3.1. SR Path Segment Sub-TLV 195 This section defines an SR Path Segment sub-TLV. 197 An SR Path Segment sub-TLV is included in the segment list sub-TLV to 198 identify an SID list. It has the following format: 200 0 1 2 3 201 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 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | Type | Length | Flags | ST | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Path Segment ID (Variable depends on ST) | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 Figure 1. Path Segment sub-TLV 209 Where: 211 Type: to be assigned by IANA. 213 Length: the total length of the value field not including Type and 214 Length fields. 216 Flags: 8 bits of flags. Following flags are defined: 218 0 1 2 3 4 5 6 7 219 +--+--+--+--+--+--+--+--+ 220 | Reserved |L | 221 +--+--+--+--+--+--+--+--+ 223 L-Flag: Local flag. Set when the Path Segment has local significance 224 on an SR node. The rest bits of Flag are reserved and MUST be set to 225 0 on transmission and MUST be ignored on receipt. 227 ST: Segment type, specifies the type of the Path Segment, and it has 228 following types: 230 o 0: SR-MPLS Path Segment 232 o 1: SRv6 Path Segment 234 o 2-255:Reserved 236 Path Segment ID: The Path Segment ID of an SR path. The Path Segment 237 type is indicated by the Segment Type(ST) field. It can be a Path 238 Segment in SR-MPLS [I-D.ietf-spring-mpls-path-segment], a Path 239 Segment in SRv6 [I-D.ietf-spring-srv6-path-segment], or other IDs 240 that identifies a path. When ST is 0, the Path Segment ID is a SR- 241 MPLS Path Segment, and format is shown below. 243 0 1 2 3 244 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 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Type | Length | Flags | ST=0 | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Path Segment Label | TC |S| TTL | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 Figure 2. SR-MPLS Path Segment sub-TLV 252 When ST is 1, the Path Segment ID is a 128-bit SRv6 Path Segment. 254 4. SR Policy for Bidirectional Path 256 In some scenarios, for example, mobile backhaul transport network, 257 there are requirements to support bidirectional path. In SR, a 258 bidirectional path can be represented as a binding of two 259 unidirectional SR paths. This document also defines a Reverse 260 Segment List sub-TLV to describe the reverse path associated with the 261 forward path specified by the Segment List. An SR policy carrying SR 262 bidirectional path information is expressed as below: 264 SR Policy SAFI NLRI: 265 Attributes: Tunnel Encaps Attribute (23) 266 Tunnel Type: SR Policy 267 Binding SID 268 Preference 269 Priority 270 Policy Name 271 Explicit NULL Label Policy (ENLP) 272 Segment List 273 Weight 274 Path Segment 275 Segment 276 Segment 277 ... 278 Reverse Segment List 279 Path Segment 280 Segment 281 Segment 282 ... 284 4.1. Reverse Path Segment List Sub-TLV 286 A Reverse Path Segment List sub-TLV is defined to specify an SR 287 reverse path associated with the path specified by the Segment List, 288 and it has the following format: 290 0 1 2 3 291 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 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Type | Length | RESERVED | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Sub-TLVs (Variable) | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 Figure 3. SR Reverse Path Segment List Sub-TLV 299 where: 301 Type: TBA. 303 Length: the total length of the sub-TLVs encoded within the Reverse 304 Path Segment List Sub-TLV not including the Type and Length fields. 306 RESERVED: 1 octet of reserved bits. SHOULD be unset on transmission 307 and MUST be ignored on receipt. 309 sub-TLVs, reuse the sub-TLVs in Segment List defined in 310 [I-D.ietf-idr-segment-routing-te-policy]. 312 o One or more mandatory SR Path Segment sub-TLVs that contains the 313 Path Segments of the reverse SR path. 315 o One or more Segment sub-TLVs to specify the reverse SR path. 317 The Segment sub-TLVs in the Reverse Path Segment List sub-TLV 318 provides the information of the reverse SR path, which can be used 319 for directing egress BFD peer to use specific path for the reverse 320 direction of the BFD session [I-D.ietf-mpls-bfd-directed] or other 321 applications. 323 5. Operations 325 The document does not bring new operation beyond the description of 326 operations defined in [I-D.ietf-idr-segment-routing-te-policy]. The 327 existing operations defined in 328 [I-D.ietf-idr-segment-routing-te-policy] can apply to this document 329 directly. 331 Typically but not limit to, the unidirectional or bidirectional SR 332 policies carrying path identification infomation are configured by a 333 controller. 335 After configuration, the unidirectional or bidirectional SR policies 336 carrying path identification infomation will be advertised by BGP 337 update messages. The operation of advertisement is the same as 338 defined in [I-D.ietf-idr-segment-routing-te-policy], as well as the 339 reception. 341 The consumer of the unidirectional or bidirectional SR policies is 342 not the BGP process, it can be any applications, such as performance 343 measurement [I-D.gandhi-spring-udp-pm]. The operation of sending 344 information to consumers is out of scope of this document. 346 6. IANA Considerations 348 This document defines new Sub-TLVs in following registries: 350 6.1. Existing Registry: BGP Tunnel Encapsulation Attribute sub-TLVs 352 This document defines new sub-TLVs in the registry "SR Policy List 353 Sub-TLVs" [I-D.ietf-idr-segment-routing-te-policy] to be assigned by 354 IANA: 356 Codepoint Description Reference 357 ------------------------------------------------------------- 358 TBA Path Segment sub-TLV This document 359 TBA Reverse Segment List sub-TLV This document 361 7. Security Considerations 363 TBA 365 8. Contributors 366 Mach(Guoyi) Chen 367 Huawei Technologies 368 Huawei Campus, No. 156 Beiqing Rd. 369 Beijing 100095 370 China 372 Email: Mach.chen@huawei.com 374 Jie Dong 375 Huawei Technologies 376 Huawei Campus, No. 156 Beiqing Rd. 377 Beijing 100095 378 China 380 Email: jie.dong@huawei.com 382 James N Guichard 383 Futurewei Technologies 384 2330 Central Express Way 385 Santa Clara 386 USA 388 Email: james.n.guichard@futurewei.com 390 Huanan Chen 391 China Telecom 392 109 West Zhongshan Ave 393 Guangzhou 394 China 396 Email: chenhuan6@chinatelecom.cn 398 9. Acknowledgements 400 Many thanks to Shraddha Hedge for her detailed review and 401 professional comments. 403 10. References 405 10.1. Normative References 407 [I-D.ietf-idr-segment-routing-te-policy] 408 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 409 Rosen, E., Jain, D., and S. Lin, "Advertising Segment 410 Routing Policies in BGP", draft-ietf-idr-segment-routing- 411 te-policy-11 (work in progress), November 2020. 413 [I-D.ietf-spring-mpls-path-segment] 414 Cheng, W., Li, H., Chen, M., Gandhi, R., and R. Zigler, 415 "Path Segment in MPLS Based Segment Routing Network", 416 draft-ietf-spring-mpls-path-segment-04 (work in progress), 417 April 2021. 419 [I-D.ietf-spring-segment-routing-policy] 420 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 421 P. Mattes, "Segment Routing Policy Architecture", draft- 422 ietf-spring-segment-routing-policy-11 (work in progress), 423 April 2021. 425 [I-D.ietf-spring-srv6-path-segment] 426 Li, C., Cheng, W., Chen, M., Dhody, D., and R. Gandhi, 427 "Path Segment for SRv6 (Segment Routing in IPv6)", draft- 428 ietf-spring-srv6-path-segment-00 (work in progress), 429 November 2020. 431 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 432 Requirement Levels", BCP 14, RFC 2119, 433 DOI 10.17487/RFC2119, March 1997, 434 . 436 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 437 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 438 May 2017, . 440 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 441 Decraene, B., Litkowski, S., and R. Shakir, "Segment 442 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 443 July 2018, . 445 10.2. Informative References 447 [I-D.gandhi-spring-udp-pm] 448 Gandhi, R., Filsfils, C., Voyer, D., Salsano, S., Ventre, 449 P. L., and M. Chen, "UDP Path for In-band Performance 450 Measurement for Segment Routing Networks", draft-gandhi- 451 spring-udp-pm-02 (work in progress), September 2018. 453 [I-D.ietf-mpls-bfd-directed] 454 Mirsky, G., Tantsura, J., Varlashkin, I., and M. Chen, 455 "Bidirectional Forwarding Detection (BFD) Directed Return 456 Path for MPLS Label Switched Paths (LSPs)", draft-ietf- 457 mpls-bfd-directed-17 (work in progress), February 2021. 459 Authors' Addresses 461 Cheng Li 462 Huawei Technologies 463 Huawei Campus, No. 156 Beiqing Rd. 464 Beijing 100095 465 China 467 Email: c.l@huawei.com 469 Zhenbin Li 470 Huawei Technologies 471 Huawei Campus, No. 156 Beiqing Rd. 472 Beijing 100095 473 China 475 Email: lizhenbin@huawei.com 477 Yuanyang Yin 478 China Telecom 479 Guangzhou 480 China 482 Email: yinyuany@chinatelecom.cn 484 Weiqiang Cheng 485 China Mobile 486 Beijing 487 China 489 Email: chengweiqiang@chinamobile.com 491 Ketan Talaulikar 492 Cisco Systems 494 Email: ketant@cisco.com