idnits 2.17.1 draft-ietf-idr-sr-policy-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 (January 24, 2022) is 822 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-14 == Outdated reference: A later version (-22) exists of draft-ietf-spring-mpls-path-segment-07 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-14 == Outdated reference: A later version (-07) exists of draft-ietf-spring-srv6-path-segment-03 == Outdated reference: A later version (-30) exists of draft-ietf-mpls-bfd-directed-18 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: July 28, 2022 Y. Yin 6 China Telecom 7 W. Cheng 8 China Mobile 9 K. Talaulikar 10 Cisco Systems 11 January 24, 2022 13 SR Policy Extensions for Path Segment and Bidirectional Path 14 draft-ietf-idr-sr-policy-path-segment-05 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 July 28, 2022. 54 Copyright Notice 56 Copyright (c) 2022 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 . . . . . . . . . . . . 8 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 | RESERVED | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Path Segment ID (Variable) | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 // SRv6 Endpoint Behavior and SID Structure (optional) // 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 Figure 1. Path Segment sub-TLV 211 Where: 213 o Type: to be assigned by IANA. 215 o Length: the total length of the value field not including Type and 216 Length fields. 218 o Flags: 8 bits of flags. Following flags are defined: 220 0 1 2 3 4 5 6 7 221 +--+--+--+--+--+--+--+--+ 222 | Reserved |B |L | 223 +--+--+--+--+--+--+--+--+ 225 o 227 * L-Flag: Local flag. Set when the Path Segment has local 228 significance on an SR node. 230 * B-Flag: This flag, when set, indicates the presence of the SRv6 231 Endpoint Behavior and SID Structure encoding specified in 232 Section 2.4.4.2.13 of [I-D.ietf-idr-segment-routing-te-policy]. 233 It MUST be ignored when the value of length field is smaller 234 than 18. 236 * The rest bits of Flag are reserved and MUST be set to 0 on 237 transmission and MUST be ignored on receipt. 239 o Path Segment ID: if the length is 2, then no Path Segment ID is 240 present. If the length is 6 then the Path Segment ID is encoded 241 in 4 octets [I-D.ietf-spring-mpls-path-segment] using the format 242 below. TC, S, TTL (Total of 12 bits) are RESERVED and SHOULD be 243 set to zero and MUST be ignored. 245 0 1 2 3 246 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 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Type | Length | Flags | Reserved | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Path Segment Label | TC |S| TTL | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 Figure 2. SR-MPLS Path Segment sub-TLV 254 If the length is 18 then the Path Segment ID contains a 16-octet SRv6 255 Path Segment ID [I-D.ietf-spring-srv6-path-segment]. 257 If the length is larger than 18 and B-flag is set, then SRv6 Endpoint 258 Behavior and SID Structure TLVs 259 [I-D.ietf-idr-segment-routing-te-policy] is included. 261 4. SR Policy for Bidirectional Path 263 In some scenarios, for example, mobile backhaul transport network, 264 there are requirements to support bidirectional path. In SR, a 265 bidirectional path can be represented as a binding of two 266 unidirectional SR paths. This document also defines a Reverse 267 Segment List sub-TLV to describe the reverse path associated with the 268 forward path specified by the Segment List. An SR policy carrying SR 269 bidirectional path information is expressed as below: 271 SR Policy SAFI NLRI: 272 Attributes: Tunnel Encaps Attribute (23) 273 Tunnel Type: SR Policy 274 Binding SID 275 Preference 276 Priority 277 Policy Name 278 Explicit NULL Label Policy (ENLP) 279 Segment List 280 Weight 281 Path Segment 282 Segment 283 Segment 284 ... 285 Reverse Segment List 286 Path Segment 287 Segment 288 Segment 289 ... 291 4.1. Reverse Path Segment List Sub-TLV 293 A Reverse Path Segment List sub-TLV is defined to specify an SR 294 reverse path associated with the path specified by the Segment List, 295 and it has the following format: 297 0 1 2 3 298 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 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Type | Length | RESERVED | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | Sub-TLVs (Variable) | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 Figure 3. SR Reverse Path Segment List Sub-TLV 306 where: 308 Type: TBA. 310 Length: the total length of the sub-TLVs encoded within the Reverse 311 Path Segment List Sub-TLV not including the Type and Length fields. 313 RESERVED: 1 octet of reserved bits. SHOULD be unset on transmission 314 and MUST be ignored on receipt. 316 sub-TLVs, reuse the sub-TLVs in Segment List defined in 317 [I-D.ietf-idr-segment-routing-te-policy]. 319 o One or more mandatory SR Path Segment sub-TLVs that contains the 320 Path Segments of the reverse SR path. 322 o One or more Segment sub-TLVs to specify the reverse SR path. 324 The Segment sub-TLVs in the Reverse Path Segment List sub-TLV 325 provides the information of the reverse SR path, which can be used 326 for directing egress BFD peer to use specific path for the reverse 327 direction of the BFD session [I-D.ietf-mpls-bfd-directed] or other 328 applications. 330 5. Operations 332 The document does not bring new operation beyond the description of 333 operations defined in [I-D.ietf-idr-segment-routing-te-policy]. The 334 existing operations defined in 335 [I-D.ietf-idr-segment-routing-te-policy] can apply to this document 336 directly. 338 Typically but not limit to, the unidirectional or bidirectional SR 339 policies carrying path identification infomation are configured by a 340 controller. 342 After configuration, the unidirectional or bidirectional SR policies 343 carrying path identification infomation will be advertised by BGP 344 update messages. The operation of advertisement is the same as 345 defined in [I-D.ietf-idr-segment-routing-te-policy], as well as the 346 reception. 348 The consumer of the unidirectional or bidirectional SR policies is 349 not the BGP process, it can be any applications, such as performance 350 measurement [I-D.gandhi-spring-udp-pm]. The operation of sending 351 information to consumers is out of scope of this document. 353 6. IANA Considerations 355 This document defines new Sub-TLVs in following registries: 357 6.1. Existing Registry: BGP Tunnel Encapsulation Attribute sub-TLVs 359 This document defines new sub-TLVs in the registry "SR Policy List 360 Sub-TLVs" [I-D.ietf-idr-segment-routing-te-policy] to be assigned by 361 IANA: 363 Codepoint Description Reference 364 ------------------------------------------------------------- 365 TBA Path Segment sub-TLV This document 366 TBA Reverse Segment List sub-TLV This document 368 7. Security Considerations 370 TBA 372 8. Contributors 373 Mach(Guoyi) Chen 374 Huawei Technologies 375 Huawei Campus, No. 156 Beiqing Rd. 376 Beijing 100095 377 China 379 Email: Mach.chen@huawei.com 381 Jie Dong 382 Huawei Technologies 383 Huawei Campus, No. 156 Beiqing Rd. 384 Beijing 100095 385 China 387 Email: jie.dong@huawei.com 389 James N Guichard 390 Futurewei Technologies 391 2330 Central Express Way 392 Santa Clara 393 USA 395 Email: james.n.guichard@futurewei.com 397 Huanan Chen 398 China Telecom 399 109 West Zhongshan Ave 400 Guangzhou 401 China 403 Email: chenhuan6@chinatelecom.cn 405 9. Acknowledgements 407 Many thanks to Shraddha Hedge for her detailed review and 408 professional comments. 410 10. References 412 10.1. Normative References 414 [I-D.ietf-idr-segment-routing-te-policy] 415 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 416 Jain, D., and S. Lin, "Advertising Segment Routing 417 Policies in BGP", draft-ietf-idr-segment-routing-te- 418 policy-14 (work in progress), November 2021. 420 [I-D.ietf-spring-mpls-path-segment] 421 Cheng, W., Li, H., Chen, M., Gandhi, R., and R. Zigler, 422 "Path Segment in MPLS Based Segment Routing Network", 423 draft-ietf-spring-mpls-path-segment-07 (work in progress), 424 December 2021. 426 [I-D.ietf-spring-segment-routing-policy] 427 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 428 P. Mattes, "Segment Routing Policy Architecture", draft- 429 ietf-spring-segment-routing-policy-14 (work in progress), 430 October 2021. 432 [I-D.ietf-spring-srv6-path-segment] 433 Li, C., Cheng, W., Chen, M., Dhody, D., and Y. Zhu, "Path 434 Segment for SRv6 (Segment Routing in IPv6)", draft-ietf- 435 spring-srv6-path-segment-03 (work in progress), November 436 2021. 438 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 439 Requirement Levels", BCP 14, RFC 2119, 440 DOI 10.17487/RFC2119, March 1997, 441 . 443 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 444 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 445 May 2017, . 447 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 448 Decraene, B., Litkowski, S., and R. Shakir, "Segment 449 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 450 July 2018, . 452 10.2. Informative References 454 [I-D.gandhi-spring-udp-pm] 455 Gandhi, R., Filsfils, C., Voyer, D., Salsano, S., Ventre, 456 P. L., and M. Chen, "UDP Path for In-band Performance 457 Measurement for Segment Routing Networks", draft-gandhi- 458 spring-udp-pm-02 (work in progress), September 2018. 460 [I-D.ietf-mpls-bfd-directed] 461 Mirsky, G., Tantsura, J., Varlashkin, I., and M. Chen, 462 "Bidirectional Forwarding Detection (BFD) Directed Return 463 Path for MPLS Label Switched Paths (LSPs)", draft-ietf- 464 mpls-bfd-directed-18 (work in progress), August 2021. 466 Authors' Addresses 468 Cheng Li 469 Huawei Technologies 470 Huawei Campus, No. 156 Beiqing Rd. 471 Beijing 100095 472 China 474 Email: c.l@huawei.com 476 Zhenbin Li 477 Huawei Technologies 478 Huawei Campus, No. 156 Beiqing Rd. 479 Beijing 100095 480 China 482 Email: lizhenbin@huawei.com 484 Yuanyang Yin 485 China Telecom 486 Guangzhou 487 China 489 Email: yinyuany@chinatelecom.cn 491 Weiqiang Cheng 492 China Mobile 493 Beijing 494 China 496 Email: chengweiqiang@chinamobile.com 498 Ketan Talaulikar 499 Cisco Systems 501 Email: ketant.ietf@gmail.com