idnits 2.17.1 draft-ietf-idr-sr-policy-path-segment-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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 11, 2020) is 1347 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-09 == Outdated reference: A later version (-22) exists of draft-ietf-spring-mpls-path-segment-02 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-08 == Outdated reference: A later version (-30) exists of draft-ietf-mpls-bfd-directed-15 Summary: 1 error (**), 0 flaws (~~), 5 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: February 12, 2021 H. Chen 6 China Telecom 7 W. Cheng 8 China Mobile 9 K. Talaulikar 10 Cisco Systems 11 August 11, 2020 13 SR Policy Extensions for Path Segment and Bidirectional Path 14 draft-ietf-idr-sr-policy-path-segment-01 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 February 12, 2021. 54 Copyright Notice 56 Copyright (c) 2020 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 . . . . . . . . . . . . . . 6 77 4.1. Reverse Path Segment List Sub-TLV . . . . . . . . . . . . 7 78 5. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 8 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . 10 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] , or other IDs that can identify 114 a path. Also, this document defines extensions to BGP to distribute 115 SR policies carrying Path Segment and bidirectional path information. 117 2. Terminology 119 This memo makes use of the terms defined in [RFC8402] and 120 [I-D.ietf-idr-segment-routing-te-policy]. 122 2.1. Requirements Language 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 126 "OPTIONAL" in this document are to be interpreted as described in BCP 127 14 [RFC2119] [RFC8174] when, and only when, they appear in all 128 capitals, as shown here. 130 3. Path Segment in SR Policy 132 As defined in [I-D.ietf-idr-segment-routing-te-policy] , the SR 133 Policy encoding structure is as follows: 135 SR Policy SAFI NLRI: 136 Attributes: 137 Tunnel Encaps Attribute (23) 138 Tunnel Type: SR Policy 139 Binding SID 140 Preference 141 Priority 142 Policy Name 143 Explicit NULL Label Policy (ENLP) 144 Segment List 145 Weight 146 Segment 147 Segment 148 ... 149 ... 151 An SR path can be specified by an Segment List sub-TLV that contains 152 a set of segment sub-TLVs and other sub-TLVs as shown above. As 153 defined in [I-D.ietf-spring-segment-routing-policy], a candidate path 154 includes multiple SR paths specified by SID list. The Path Segment 155 can be used for identifying an SR path(specified by SID list) from 156 the headend and the tailend. Also, it can be used for identifying an 157 SR candidate path in some use cases if needed. This document defines 158 a new Path Segment sub-TLV within Segment List sub-TLV, the details 159 will be described at section 3.1. The new SR Policy encoding 160 structure with Path Segmentg sub-TLV is expressed as below: 162 SR Policy SAFI NLRI: 163 Attributes: 164 Tunnel Encaps Attribute (23) 165 Tunnel Type: SR Policy 166 Binding SID 167 Preference 168 Priority 169 Policy Name 170 Explicit NULL Label Policy (ENLP) 171 Segment List 172 Weight 173 Path Segment 174 Segment 175 Segment 176 ... 177 Segment List 178 Weight 179 Path Segment 180 Segment 181 Segment 182 ... 183 ... 185 The Path Segment is used to identified an SR path, and it can be used 186 in OAM or IOAM use cases. When all the SID Lists within a candidate 187 path share the same Path Segment ID, the Path Segment can be used to 188 collect the aggregated information of the candidate path. Multiple 189 Path Segment MAY be included in a Segment List for different use 190 cases, all of them SHOULD be inserted into the SID List. 192 3.1. SR Path Segment Sub-TLV 194 This section defines an SR Path Segment sub-TLV. 196 An SR Path Segment sub-TLV is included in the segment list sub-TLV to 197 identify an SID list. It has the following format: 199 0 1 2 3 200 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 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Type | Length | Flags | ST | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Path Segment ID (Variable depends on ST) | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 Figure 1. Path Segment sub-TLV 208 Where: 210 Type: to be assigned by IANA. 212 Length: the total length of the value field not including Type and 213 Length fields. 215 Flags: 8 bits of flags. Following flags are defined: 217 0 1 2 3 4 5 6 7 218 +--+--+--+--+--+--+--+--+ 219 | Reserved |G | 220 +--+--+--+--+--+--+--+--+ 222 G-Flag: Global flag. Set when the Path Segment is global within an 223 SR domain. The rest bits of Flag are reserved and MUST be set to 0 224 on transmission and MUST be ignored on receipt. 226 ST: Segment type, specifies the type of the Path Segment, and it has 227 following types: 229 o 0: SR-MPLS Path Segment 231 o 1-255:Reserved 233 Path Segment ID: The Path Segment ID of an SR path. The Path Segment 234 type is indicated by the Segment Type(ST) field. It can be a Path 235 Segment in SR-MPLS [I-D.ietf-spring-mpls-path-segment], or other IDs 236 that identifies a path. When ST is 0, the Path Segment ID is a SR- 237 MPLS Path Segment, and format is shown below. 239 0 1 2 3 240 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 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | Type | Length | Flags | ST=0 | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Path Segment Label | TC |S| TTL | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 Figure 2. SR-MPLS Path Segment sub-TLV 248 4. SR Policy for Bidirectional Path 250 In some scenarios, for example, mobile backhaul transport network, 251 there are requirements to support bidirectional path. In SR, a 252 bidirectional path can be represented as a binding of two 253 unidirectional SR paths. This document also defines a Reverse 254 Segment List sub-TLV to describe the reverse path associated with the 255 forward path specified by the Segment List. An SR policy carrying SR 256 bidirectional path information is expressed as below: 258 SR Policy SAFI NLRI: 259 Attributes: Tunnel Encaps Attribute (23) 260 Tunnel Type: SR Policy 261 Binding SID 262 Preference 263 Priority 264 Policy Name 265 Explicit NULL Label Policy (ENLP) 266 Segment List 267 Weight 268 Path Segment 269 Segment 270 Segment 271 ... 272 Reverse Segment List 273 Path Segment 274 Segment 275 Segment 276 ... 278 4.1. Reverse Path Segment List Sub-TLV 280 A Reverse Path Segment List sub-TLV is defined to specify an SR 281 reverse path associated with the path specified by the Segment List, 282 and it has the following format: 284 0 1 2 3 285 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 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | Type | Length | RESERVED | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | Sub-TLVs (Variable) | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 Figure 3. SR Reverse Path Segment List Sub-TLV 293 where: 295 Type: TBA. 297 Length: the total length of the sub-TLVs encoded within the Reverse 298 Path Segment List Sub-TLV not including the Type and Length fields. 300 RESERVED: 1 octet of reserved bits. SHOULD be unset on transmission 301 and MUST be ignored on receipt. 303 sub-TLVs, reuse the sub-TLVs in Segment List defined in 304 [I-D.ietf-idr-segment-routing-te-policy]. 306 o One or more mandatory SR Path Segment sub-TLVs that contains the 307 Path Segments of the reverse SR path. 309 o One or more Segment sub-TLVs to specify the reverse SR path. 311 The Segment sub-TLVs in the Reverse Path Segment List sub-TLV 312 provides the information of the reverse SR path, which can be used 313 for directing egress BFD peer to use specific path for the reverse 314 direction of the BFD session [I-D.ietf-mpls-bfd-directed] or other 315 applications. 317 5. Operations 319 The document does not bring new operation beyond the description of 320 operations defined in [I-D.ietf-idr-segment-routing-te-policy]. The 321 existing operations defined in 322 [I-D.ietf-idr-segment-routing-te-policy] can apply to this document 323 directly. 325 Typically but not limit to, the unidirectional or bidirectional SR 326 policies carrying path identification infomation are configured by a 327 controller. 329 After configuration, the unidirectional or bidirectional SR policies 330 carrying path identification infomation will be advertised by BGP 331 update messages. The operation of advertisement is the same as 332 defined in [I-D.ietf-idr-segment-routing-te-policy], as well as the 333 reception. 335 The consumer of the unidirectional or bidirectional SR policies is 336 not the BGP process, it can be any applications, such as performance 337 measurement [I-D.gandhi-spring-udp-pm]. The operation of sending 338 information to consumers is out of scope of this document. 340 6. IANA Considerations 342 This document defines new Sub-TLVs in following registries: 344 6.1. Existing Registry: BGP Tunnel Encapsulation Attribute sub-TLVs 346 This document defines new sub-TLVs in the registry "SR Policy List 347 Sub-TLVs" [I-D.ietf-idr-segment-routing-te-policy] to be assigned by 348 IANA: 350 Codepoint Description Reference 351 ------------------------------------------------------------- 352 TBA Path Segment sub-TLV This document 353 TBA Reverse Segment List sub-TLV This document 355 7. Security Considerations 357 TBA 359 8. Contributors 361 Mach(Guoyi) Chen 362 Huawei Technologies 363 Huawei Campus, No. 156 Beiqing Rd. 364 Beijing 100095 365 China 367 Email: Mach.chen@huawei.com 369 Jie Dong 370 Huawei Technologies 371 Huawei Campus, No. 156 Beiqing Rd. 372 Beijing 100095 373 China 375 Email: jie.dong@huawei.com 377 James N Guichard 378 Futurewei Technologies 379 2330 Central Express Way 380 Santa Clara 381 USA 383 Email: james.n.guichard@futurewei.com 385 9. Acknowledgements 387 Many thanks to Shraddha Hedge for her detailed review and 388 professional comments. 390 10. References 392 10.1. Normative References 394 [I-D.ietf-idr-segment-routing-te-policy] 395 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 396 Rosen, E., Jain, D., and S. Lin, "Advertising Segment 397 Routing Policies in BGP", draft-ietf-idr-segment-routing- 398 te-policy-09 (work in progress), May 2020. 400 [I-D.ietf-spring-mpls-path-segment] 401 Cheng, W., Li, H., Chen, M., Gandhi, R., and R. Zigler, 402 "Path Segment in MPLS Based Segment Routing Network", 403 draft-ietf-spring-mpls-path-segment-02 (work in progress), 404 February 2020. 406 [I-D.ietf-spring-segment-routing-policy] 407 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 408 P. Mattes, "Segment Routing Policy Architecture", draft- 409 ietf-spring-segment-routing-policy-08 (work in progress), 410 July 2020. 412 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 413 Requirement Levels", BCP 14, RFC 2119, 414 DOI 10.17487/RFC2119, March 1997, 415 . 417 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 418 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 419 May 2017, . 421 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 422 Decraene, B., Litkowski, S., and R. Shakir, "Segment 423 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 424 July 2018, . 426 10.2. Informative References 428 [I-D.gandhi-spring-udp-pm] 429 Gandhi, R., Filsfils, C., daniel.voyer@bell.ca, d., 430 Salsano, S., Ventre, P., and M. Chen, "UDP Path for In- 431 band Performance Measurement for Segment Routing 432 Networks", draft-gandhi-spring-udp-pm-02 (work in 433 progress), September 2018. 435 [I-D.ietf-mpls-bfd-directed] 436 Mirsky, G., Tantsura, J., Varlashkin, I., and M. Chen, 437 "Bidirectional Forwarding Detection (BFD) Directed Return 438 Path for MPLS Label Switched Paths (LSPs)", draft-ietf- 439 mpls-bfd-directed-15 (work in progress), August 2020. 441 Authors' Addresses 443 Cheng Li 444 Huawei Technologies 445 Huawei Campus, No. 156 Beiqing Rd. 446 Beijing 100095 447 China 449 Email: c.l@huawei.com 451 Zhenbin Li 452 Huawei Technologies 453 Huawei Campus, No. 156 Beiqing Rd. 454 Beijing 100095 455 China 457 Email: lizhenbin@huawei.com 459 Huanan Chen 460 China Telecom 461 109 West Zhongshan Ave 462 Guangzhou 463 China 465 Email: chenhn8.gd@chinatelecom.cn 467 Weiqiang Cheng 468 China Mobile 469 Beijing 470 China 472 Email: chengweiqiang@chinamobile.com 473 Ketan Talaulikar 474 Cisco Systems 476 Email: ketant@cisco.com