idnits 2.17.1 draft-ietf-idr-sr-policy-path-segment-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 (March 9, 2021) is 1144 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-03 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-09 == 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-15 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: September 10, 2021 H. Chen 6 China Telecom 7 W. Cheng 8 China Mobile 9 K. Talaulikar 10 Cisco Systems 11 March 9, 2021 13 SR Policy Extensions for Path Segment and Bidirectional Path 14 draft-ietf-idr-sr-policy-path-segment-03 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 September 10, 2021. 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 . . . . . . . . . . . . . . . . . . . . . . . 11 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 9. Acknowledgements 392 Many thanks to Shraddha Hedge for her detailed review and 393 professional comments. 395 10. References 397 10.1. Normative References 399 [I-D.ietf-idr-segment-routing-te-policy] 400 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 401 Rosen, E., Jain, D., and S. Lin, "Advertising Segment 402 Routing Policies in BGP", draft-ietf-idr-segment-routing- 403 te-policy-11 (work in progress), November 2020. 405 [I-D.ietf-spring-mpls-path-segment] 406 Cheng, W., Li, H., Chen, M., Gandhi, R., and R. Zigler, 407 "Path Segment in MPLS Based Segment Routing Network", 408 draft-ietf-spring-mpls-path-segment-03 (work in progress), 409 September 2020. 411 [I-D.ietf-spring-segment-routing-policy] 412 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 413 P. Mattes, "Segment Routing Policy Architecture", draft- 414 ietf-spring-segment-routing-policy-09 (work in progress), 415 November 2020. 417 [I-D.ietf-spring-srv6-path-segment] 418 Li, C., Cheng, W., Chen, M., Dhody, D., and R. Gandhi, 419 "Path Segment for SRv6 (Segment Routing in IPv6)", draft- 420 ietf-spring-srv6-path-segment-00 (work in progress), 421 November 2020. 423 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 424 Requirement Levels", BCP 14, RFC 2119, 425 DOI 10.17487/RFC2119, March 1997, 426 . 428 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 429 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 430 May 2017, . 432 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 433 Decraene, B., Litkowski, S., and R. Shakir, "Segment 434 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 435 July 2018, . 437 10.2. Informative References 439 [I-D.gandhi-spring-udp-pm] 440 Gandhi, R., Filsfils, C., daniel.voyer@bell.ca, d., 441 Salsano, S., Ventre, P., and M. Chen, "UDP Path for In- 442 band Performance Measurement for Segment Routing 443 Networks", draft-gandhi-spring-udp-pm-02 (work in 444 progress), September 2018. 446 [I-D.ietf-mpls-bfd-directed] 447 Mirsky, G., Tantsura, J., Varlashkin, I., and M. Chen, 448 "Bidirectional Forwarding Detection (BFD) Directed Return 449 Path for MPLS Label Switched Paths (LSPs)", draft-ietf- 450 mpls-bfd-directed-15 (work in progress), August 2020. 452 Authors' Addresses 453 Cheng Li 454 Huawei Technologies 455 Huawei Campus, No. 156 Beiqing Rd. 456 Beijing 100095 457 China 459 Email: c.l@huawei.com 461 Zhenbin Li 462 Huawei Technologies 463 Huawei Campus, No. 156 Beiqing Rd. 464 Beijing 100095 465 China 467 Email: lizhenbin@huawei.com 469 Huanan Chen 470 China Telecom 471 109 West Zhongshan Ave 472 Guangzhou 473 China 475 Email: chenhuan6@chinatelecom.cn 477 Weiqiang Cheng 478 China Mobile 479 Beijing 480 China 482 Email: chengweiqiang@chinamobile.com 484 Ketan Talaulikar 485 Cisco Systems 487 Email: ketant@cisco.com