idnits 2.17.1 draft-ietf-idr-sr-policy-path-segment-00.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 4 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 (October 29, 2019) is 1640 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-07 == Outdated reference: A later version (-22) exists of draft-ietf-spring-mpls-path-segment-01 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-03 == Outdated reference: A later version (-30) exists of draft-ietf-mpls-bfd-directed-12 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: May 1, 2020 H. Chen 6 China Telecom 7 W. Cheng 8 China Mobile 9 K. Talaulikar 10 Cisco Systems 11 October 29, 2019 13 SR Policy Extensions for Path Segment and Bidirectional Path 14 draft-ietf-idr-sr-policy-path-segment-00 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 unidirctional SR paths into 25 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 May 1, 2020. 54 Copyright Notice 56 Copyright (c) 2019 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 3. Path Segment in SR Policy . . . . . . . . . . . . . . . . . . 3 74 3.1. SR Path Segment Sub-TLV . . . . . . . . . . . . . . . . . 4 75 4. SR Policy for Bidirectional Path . . . . . . . . . . . . . . 6 76 4.1. SR Bidirectional Path Sub-TLV . . . . . . . . . . . . . . 6 77 4.2. SR 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 . . . . . . . . . . . . . . . . . . . . . . . . 8 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] , or other IDs that can identify 114 a path. Also, this document defines extensions to BGP to distribute 115 SR policies carriying Path Segment and bidirectional path 116 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 3. Path Segment in SR Policy 125 As defined in [I-D.ietf-idr-segment-routing-te-policy] , the SR 126 Policy encoding structure is as follows: 128 SR Policy SAFI NLRI: 129 Attributes: 130 Tunnel Encaps Attribute (23) 131 Tunnel Type: SR Policy 132 Binding SID 133 Preference 134 Priority 135 Policy Name 136 Explicit NULL Label Policy (ENLP) 137 Segment List 138 Weight 139 Segment 140 Segment 141 ... 142 ... 144 An SR path can be specified by an Segment List sub-TLV that contains 145 a set of segment sub-TLVs and other sub-TLVs as shown above. As 146 defined in [I-D.ietf-spring-segment-routing-policy], a candidate path 147 includes multiple SR paths specified by SID list. The Path Segment 148 can be used for idendifying an SR path(specified by SID list). Also, 149 it can be used for identifying an SR candidate path or an SR Policy 150 in some use cases if needed. New SR Policy encoding structure is 151 expressed as below: 153 SR Policy SAFI NLRI: 154 Attributes: 155 Tunnel Encaps Attribute (23) 156 Tunnel Type: SR Policy 157 Binding SID 158 Preference 159 Priority 160 Policy Name 161 Explicit NULL Label Policy (ENLP) 162 Path Segment 163 Segment List 164 Weight 165 Path Segment 166 Segment 167 Segment 168 ... 169 Segment List 170 Weight 171 Path Segment 172 Segment 173 Segment 174 ... 175 ... 177 The Path Segment can appear at both segment-list level and candidate 178 path level, and generally it SHOULD also appear only at one level 179 depending upon use case. Path segment at segment list level and at 180 candidate path level may be same or may be different based on usecase 181 and the ID allocation scope. When multiple Path Segments appear in 182 both levels, it means the the Path Segment associated with candidate 183 path and segment list SHOULD both be inserted into the SID list. 185 3.1. SR Path Segment Sub-TLV 187 This section defines an SR Path Segment sub-TLV. 189 An SR Path Segment sub-TLV can be included in the segment list sub- 190 TLV to identify an SID list, and it MUST appear only once within a 191 Segment List sub-TLV. It has the following format: 193 0 1 2 3 194 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 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | Type | Length | Flag | ST | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | Path Segment (Variable depends on ST) | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 Figure 1. Path Segment sub-TLV 202 Where: 204 Type: to be assigned by IANA (suggested value 10). 206 Length: the total length of the value field not including Type and 207 Length fields. 209 Flag: 8 bits of flags. Following flags are defined: 211 0 1 2 3 4 5 6 7 212 +--+--+--+--+--+--+--+--+ 213 | Reserved |G | 214 +--+--+--+--+--+--+--+--+ 216 G-Flag: Global flag. Set when the Path Segment is global within an 217 SR domain. 219 Reserved: 5 bits reserved and MUST be set to 0 on transmission and 220 MUST be ignored on receipt. 222 ST: Segment type, specifies the type of the Path Segment, and it has 223 following types: 225 o 0: SR-MPLS Path Segment 227 o 1-255:Reserved 229 Path Segment: The Path Segment of an SR path. The Path Segment type 230 is indicated by the Segment Type(ST) field. It can be a Path Segment 231 in SR-MPLS [I-D.ietf-spring-mpls-path-segment], which is 32-bits 232 value, which is a 128-bits value, or other IDs that can identify a 233 path. 235 4. SR Policy for Bidirectional Path 237 In some scenarios, for example, mobile backhaul transport network, 238 there are requirements to support bidirectional path. In SR, a 239 bidirectional path can be represented as a binding of two 240 unidirectional SR paths. This document also defines new sub-TLVs to 241 describe an SR bidirectional path. An SR policy carrying SR 242 bidirectional path information is expressed as below: 244 SR Policy SAFI NLRI: 245 Attributes: Tunnel Encaps Attribute (23) 246 Tunnel Type: SR Policy 247 Binding SID 248 Preference 249 Priority 250 Policy Name 251 Explicit NULL Label Policy (ENLP) 252 Bidirectioanl Path 253 Segment List 254 Weight 255 Path Segment 256 Segment 257 Segment 258 ... 259 Reverse Segment List 260 Weight 261 Path Segment 262 Segment 263 Segment 264 ... 266 4.1. SR Bidirectional Path Sub-TLV 268 This section defines an SR bidirectional path sub-TLV to specify a 269 bidirectional path, which contains a Segment List sub-TLV 270 [I-D.ietf-idr-segment-routing-te-policy] and an associated Reverse 271 Path Segment List as defined at section 4.2. The SR bidirectional 272 path sub-TLV has the following format: 274 0 1 2 3 275 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 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | Type | Length | RESERVED | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Sub-TLVs (Variable) | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 Figure 2. SR Bidirectional path sub-TLV 283 Where: 285 Type: TBA, and the suggest value is 14. 287 Length: the total length of the sub-TLVs encoded within the SR 288 Bidirectional Path Sub-TLV not including Type and Length fields. 290 RESERVED: 1 octet of reserved bits. SHOULD be unset on transmission 291 and MUST be ignored on receipt. 293 Sub-TLVs: 295 o An Segment List sub-TLV 297 o An associated Reverse Path Segment List sub-TLV 299 4.2. SR Reverse Path Segment List Sub-TLV 301 An SR Reverse Path Segment List sub-TLV is defined to specify an SR 302 reverse path associated with the path specified by the Segment List 303 in the same SR Bidirectional Path Sub-TLV, and it has the following 304 format: 306 0 1 2 3 307 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 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Type | Length | RESERVED | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Sub-TLVs (Variable) | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 Figure 2. SR Reverse Path Segment List Sub-TLV 315 where: 317 Type: TBA, and suggest value is 127. 319 Length: the total length of the sub-TLVs encoded within the SR 320 Reverse Path Segment List Sub-TLV not including the Type and Length 321 fields. 323 RESERVED: 1 octet of reserved bits. SHOULD be unset on transmission 324 and MUST be ignored on receipt. 326 sub-TLVs, reuse the sub-TLVs in Segment List defined in 327 [I-D.ietf-idr-segment-routing-te-policy]. 329 o An optional single Weight sub-TLV. 331 o An mandatory SR Path Segment sub-TLV that contains the Path 332 Segment of the reverse SR path. 334 o Zero or more Segment sub-TLVs to specify the reverse SR path. 336 The Segment sub-TLVs in the Reverse Path Segment List sub-TLV 337 provides the information of the reverse SR path, which can be used 338 for directing egress BFD peer to use specific path for the reverse 339 direction of the BFD session [I-D.ietf-mpls-bfd-directed] or other 340 applications. 342 5. Operations 344 The document does not bring new operation beyong the description of 345 operations defined in [I-D.ietf-idr-segment-routing-te-policy]. The 346 existing operations defined in 347 [I-D.ietf-idr-segment-routing-te-policy] can apply to this document 348 directly. 350 Typically but not limit to, the unidirectional or bidirectional SR 351 policies carrying path identification infomation are configured by a 352 controller. 354 After configuration, the unidirectional or bidirectional SR policies 355 carrying path identification infomation will be advertised by BGP 356 update messages. The operation of advertisement is the same as 357 defined in [I-D.ietf-idr-segment-routing-te-policy], as well as the 358 receiption. 360 The consumer of the unidirectional or bidirectional SR policies is 361 not the BGP process, it can be any applications, such as performance 362 measurement [I-D.gandhi-spring-udp-pm]. The operation of sending 363 information to consumers is out of scope of this document. 365 6. IANA Considerations 367 This document defines new Sub-TLVs in following registries: 369 6.1. Existing Registry: BGP Tunnel Encapsulation Attribute sub-TLVs 371 This document defines new sub-TLVs in the registry "BGP Tunnel 372 Encapsulation Attribute sub-TLVs" to be assigned by IANA: 374 Codepoint Description Reference 375 ------------------------------------------------------------- 376 14 Path Segment sub-TLV This document 377 15 SR Bidirectional Path sub-TLV This document 378 127 Reverse Segment List sub-TLV This document 380 This document defines new sub-TLVs in the registry "SR Policy List 381 Sub-TLVs" [I-D.ietf-idr-segment-routing-te-policy] to be assigned by 382 IANA: 384 Codepoint Description Reference 385 ------------------------------------------------------------- 386 14 Path Segment sub-TLV This document 388 7. Security Considerations 390 TBA 392 8. Contributors 393 Mach(Guoyi) Chen 394 Huawei Technologies 395 Huawei Campus, No. 156 Beiqing Rd. 396 Beijing 100095 397 China 399 Email: Mach.chen@huawei.com 401 Jie Dong 402 Huawei Technologies 403 Huawei Campus, No. 156 Beiqing Rd. 404 Beijing 100095 405 China 407 Email: jie.dong@huawei.com 409 James N Guichard 410 Futurewei Technologies 411 2330 Central Express Way 412 Santa Clara 413 USA 415 Email: james.n.guichard@futurewei.com 417 9. Acknowledgements 419 Many thanks to Shraddha Hedge for her detailed review and 420 professional comments. 422 10. References 424 10.1. Normative References 426 [I-D.ietf-idr-segment-routing-te-policy] 427 Previdi, S., Filsfils, C., Mattes, P., Rosen, E., Jain, 428 D., and S. Lin, "Advertising Segment Routing Policies in 429 BGP", draft-ietf-idr-segment-routing-te-policy-07 (work in 430 progress), July 2019. 432 [I-D.ietf-spring-mpls-path-segment] 433 Cheng, W., Li, H., Chen, M., Gandhi, R., and R. Zigler, 434 "Path Segment in MPLS Based Segment Routing Network", 435 draft-ietf-spring-mpls-path-segment-01 (work in progress), 436 September 2019. 438 [I-D.ietf-spring-segment-routing-policy] 439 Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., 440 bogdanov@google.com, b., and P. Mattes, "Segment Routing 441 Policy Architecture", draft-ietf-spring-segment-routing- 442 policy-03 (work in progress), May 2019. 444 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 445 Requirement Levels", BCP 14, RFC 2119, 446 DOI 10.17487/RFC2119, March 1997, 447 . 449 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 450 Decraene, B., Litkowski, S., and R. Shakir, "Segment 451 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 452 July 2018, . 454 10.2. Informative References 456 [I-D.gandhi-spring-udp-pm] 457 Gandhi, R., Filsfils, C., daniel.voyer@bell.ca, d., 458 Salsano, S., Ventre, P., and M. Chen, "UDP Path for In- 459 band Performance Measurement for Segment Routing 460 Networks", draft-gandhi-spring-udp-pm-02 (work in 461 progress), September 2018. 463 [I-D.ietf-mpls-bfd-directed] 464 Mirsky, G., Tantsura, J., Varlashkin, I., and M. Chen, 465 "Bidirectional Forwarding Detection (BFD) Directed Return 466 Path", draft-ietf-mpls-bfd-directed-12 (work in progress), 467 August 2019. 469 Authors' Addresses 471 Cheng Li 472 Huawei Technologies 473 Huawei Campus, No. 156 Beiqing Rd. 474 Beijing 100095 475 China 477 Email: chengli13@huawei.com 478 Zhenbin Li 479 Huawei Technologies 480 Huawei Campus, No. 156 Beiqing Rd. 481 Beijing 100095 482 China 484 Email: lizhenbin@huawei.com 486 Huanan Chen 487 China Telecom 488 109 West Zhongshan Ave 489 Guangzhou 490 China 492 Email: chenhn8.gd@chinatelecom.cn 494 Weiqiang Cheng 495 China Mobile 496 Beijing 497 China 499 Email: chengweiqiang@chinamobile.com 501 Ketan Talaulikar 502 Cisco Systems 504 Email: ketant@cisco.com