idnits 2.17.1 draft-li-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 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 (August 8, 2019) is 1723 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-00 == 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-11 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 Huawei Technologies 4 Intended status: Standards Track H. Chen 5 Expires: February 9, 2020 China Telecom 6 M. Chen 7 J. Dong 8 Z. Li 9 Huawei Technologies 10 August 8, 2019 12 SR Policy Extensions for Path Segment and Bidirectional Path 13 draft-li-idr-sr-policy-path-segment-01 15 Abstract 17 A Segment Routing (SR) policy is a set of candidate SR paths 18 consisting of one or more segment lists with necessary path 19 attributes. For each SR path, it may also have its own path 20 attributes, and Path Segment is one of them. A Path Segment is 21 defined to identify an SR path, which can be used for performance 22 measurement, path correlation, and end-2-end path protection. Path 23 Segment can be also used to correlate two unidirctional SR paths into 24 a bidirectional SR path which is required in some scenarios, for 25 example, mobile backhaul transport network. 27 This document defines extensions to BGP to distribute SR policies 28 carrying Path Segment and bidirectional path information. 30 Requirements Language 32 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 33 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 34 document are to be interpreted as described in RFC 2119 [RFC2119]. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on February 9, 2020. 53 Copyright Notice 55 Copyright (c) 2019 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (https://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 72 3. Path Segment in SR Policy . . . . . . . . . . . . . . . . . . 3 73 3.1. SR Path Segment Sub-TLV . . . . . . . . . . . . . . . . . 4 74 4. SR Policy for Bidirectional Path . . . . . . . . . . . . . . 5 75 4.1. SR Bidirectional Path Sub-TLV . . . . . . . . . . . . . . 6 76 4.2. SR Reverse Path Segment List Sub-TLV . . . . . . . . . . 7 77 5. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 8 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 79 6.1. Existing Registry: BGP Tunnel Encapsulation Attribute 80 sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . . 8 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 82 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 84 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 85 9.2. Informative References . . . . . . . . . . . . . . . . . 10 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 88 1. Introduction 90 Segment routing (SR) [RFC8402] is a source routing paradigm that 91 explicitly indicates the forwarding path for packets at the ingress 92 node. The ingress node steers packets into a specific path according 93 to the Segment Routing Policy ( SR Policy) as defined in 94 [I-D.ietf-spring-segment-routing-policy]. For distributing SR 95 policies to the headend, [I-D.ietf-idr-segment-routing-te-policy] 96 specifies a mechanism by using BGP, and new sub-TLVs are defined for 97 SR Policies in BGP UPDATE message. 99 In many use cases such as performance measurement, the path to which 100 the packets belong is required to be identified. Futhermore, in some 101 scenarios, for example, mobile backhaul transport network, there are 102 requirements to support bidirectional path. However, there is no 103 path identification information for each Segment List in the SR 104 Policies defined in [I-D.ietf-spring-segment-routing-policy]. Also, 105 the SR Policies defined in [I-D.ietf-spring-segment-routing-policy] 106 only supports unidirectional SR paths. 108 Therefore, this document defines the extension to SR policies that 109 carry Path Segment in the Segment List and support bidirectional 110 path. The Path Segment can be a Path Segment in SR-MPLS 111 [I-D.ietf-spring-mpls-path-segment] , or other IDs that can identify 112 a path. Also, this document defines extensions to BGP to distribute 113 SR policies carriying Path Segment and bidirectional path 114 information. 116 2. Terminology 118 This memo makes use of the terms defined in [RFC8402] and 119 [I-D.ietf-idr-segment-routing-te-policy]. 121 3. Path Segment in SR Policy 123 As defined in [I-D.ietf-idr-segment-routing-te-policy] , the SR 124 Policy encoding structure is as follows: 126 SR Policy SAFI NLRI: 127 Attributes: 128 Tunnel Encaps Attribute (23) 129 Tunnel Type: SR Policy 130 Binding SID 131 Preference 132 Priority 133 Policy Name 134 Explicit NULL Label Policy (ENLP) 135 Segment List 136 Weight 137 Segment 138 Segment 139 ... 140 ... 142 An SR path can be specified by an Segment List sub-TLV that contains 143 a set of segment sub-TLVs and other sub-TLVs as shown above. As 144 defined in [I-D.ietf-spring-segment-routing-policy], a candidate path 145 includes multiple SR paths specified by SID list. The Path Segment 146 can be used for idendifying an SR path(specified by SID list). Also, 147 it can be used for identifying an SR candidate path or an SR Policy 148 in some use cases if needed. New SR Policy encoding structure is 149 expressed as below: 151 SR Policy SAFI NLRI: 152 Attributes: 153 Tunnel Encaps Attribute (23) 154 Tunnel Type: SR Policy 155 Binding SID 156 Preference 157 Priority 158 Policy Name 159 Explicit NULL Label Policy (ENLP) 160 Path Segment 161 Segment List 162 Weight 163 Path Segment 164 Segment 165 Segment 166 ... 167 Segment List 168 Weight 169 Path Segment 170 Segment 171 Segment 172 ... 173 ... 175 The Path Segment can appear at both segment-list level and candidate 176 path level, and generally it SHOULD also appear only at one level 177 depending upon use case. Path segment at segment list level and at 178 candidate path level may be same or may be different based on usecase 179 and the ID allocation scope. When multiple Path Segments appear in 180 both levels, it means the the Path Segment associated with candidate 181 path and segment list SHOULD both be inserted into the SID list. 183 3.1. SR Path Segment Sub-TLV 185 This section defines an SR Path Segment sub-TLV. 187 An SR Path Segment sub-TLV can be included in the segment list sub- 188 TLV to identify an SID list, and it MUST appear only once within a 189 Segment List sub-TLV. It has the following format: 191 0 1 2 3 192 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 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | Type | Length | Flag | ST | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | Path Segment (Variable depends on ST) | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 Figure 1. Path Segment sub-TLV 200 Where: 202 Type: to be assigned by IANA (suggested value 10). 204 Length: the total length of the value field not including Type and 205 Length fields. 207 Flag: 8 bits of flags. Following flags are defined: 209 0 1 2 3 4 5 6 7 210 +--+--+--+--+--+--+--+--+ 211 | Reserved |G | 212 +--+--+--+--+--+--+--+--+ 214 G-Flag: Global flag. Set when the Path Segment is global within an 215 SR domain. 217 Reserved: 5 bits reserved and MUST be set to 0 on transmission and 218 MUST be ignored on receipt. 220 ST: Segment type, specifies the type of the Path Segment, and it has 221 following types: 223 o 0: SR-MPLS Path Segment 225 o 1-255:Reserved 227 Path Segment: The Path Segment of an SR path. The Path Segment type 228 is indicated by the Segment Type(ST) field. It can be a Path Segment 229 in SR-MPLS [I-D.ietf-spring-mpls-path-segment], which is 32-bits 230 value, which is a 128-bits value, or other IDs that can identify a 231 path. 233 4. SR Policy for Bidirectional Path 235 In some scenarios, for example, mobile backhaul transport network, 236 there are requirements to support bidirectional path. In SR, a 237 bidirectional path can be represented as a binding of two 238 unidirectional SR paths. This document also defines new sub-TLVs to 239 describe an SR bidirectional path. An SR policy carrying SR 240 bidirectional path information is expressed as below: 242 SR Policy SAFI NLRI: 243 Attributes: Tunnel Encaps Attribute (23) 244 Tunnel Type: SR Policy 245 Binding SID 246 Preference 247 Priority 248 Policy Name 249 Explicit NULL Label Policy (ENLP) 250 Bidirectioanl Path 251 Segment List 252 Weight 253 Path Segment 254 Segment 255 Segment 256 ... 257 Reverse Segment List 258 Weight 259 Path Segment 260 Segment 261 Segment 262 ... 264 4.1. SR Bidirectional Path Sub-TLV 266 This section defines an SR bidirectional path sub-TLV to specify a 267 bidirectional path, which contains a Segment List sub-TLV 268 [I-D.ietf-idr-segment-routing-te-policy] and an associated Reverse 269 Path Segment List as defined at section 4.2. The SR bidirectional 270 path sub-TLV has the following format: 272 0 1 2 3 273 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 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | Type | Length | RESERVED | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | Sub-TLVs (Variable) | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 Figure 2. SR Bidirectional path sub-TLV 281 Where: 283 Type: TBA, and the suggest value is 14. 285 Length: the total length of the sub-TLVs encoded within the SR 286 Bidirectional Path Sub-TLV not including Type and Length fields. 288 RESERVED: 1 octet of reserved bits. SHOULD be unset on transmission 289 and MUST be ignored on receipt. 291 Sub-TLVs: 293 o An Segment List sub-TLV 295 o An associated Reverse Path Segment List sub-TLV 297 4.2. SR Reverse Path Segment List Sub-TLV 299 An SR Reverse Path Segment List sub-TLV is defined to specify an SR 300 reverse path associated with the path specified by the Segment List 301 in the same SR Bidirectional Path Sub-TLV, and it has the following 302 format: 304 0 1 2 3 305 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 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Type | Length | RESERVED | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Sub-TLVs (Variable) | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 Figure 2. SR Reverse Path Segment List Sub-TLV 313 where: 315 Type: TBA, and suggest value is 127. 317 Length: the total length of the sub-TLVs encoded within the SR 318 Reverse Path Segment List Sub-TLV not including the Type and Length 319 fields. 321 RESERVED: 1 octet of reserved bits. SHOULD be unset on transmission 322 and MUST be ignored on receipt. 324 sub-TLVs, reuse the sub-TLVs in Segment List defined in 325 [I-D.ietf-idr-segment-routing-te-policy]. 327 o An optional single Weight sub-TLV. 329 o An mandatory SR Path Segment sub-TLV that contains the Path 330 Segment of the reverse SR path. 332 o Zero or more Segment sub-TLVs to specify the reverse SR path. 334 The Segment sub-TLVs in the Reverse Path Segment List sub-TLV 335 provides the information of the reverse SR path, which can be used 336 for directing egress BFD peer to use specific path for the reverse 337 direction of the BFD session [I-D.ietf-mpls-bfd-directed] or other 338 applications. 340 5. Operations 342 The document does not bring new operation beyong the description of 343 operations defined in [I-D.ietf-idr-segment-routing-te-policy]. The 344 existing operations defined in 345 [I-D.ietf-idr-segment-routing-te-policy] can apply to this document 346 directly. 348 Typically but not limit to, the unidirectional or bidirectional SR 349 policies carrying path identification infomation are configured by a 350 controller. 352 After configuration, the unidirectional or bidirectional SR policies 353 carrying path identification infomation will be advertised by BGP 354 update messages. The operation of advertisement is the same as 355 defined in [I-D.ietf-idr-segment-routing-te-policy], as well as the 356 receiption. 358 The consumer of the unidirectional or bidirectional SR policies is 359 not the BGP process, it can be any applications, such as performance 360 measurement [I-D.gandhi-spring-udp-pm]. The operation of sending 361 information to consumers is out of scope of this document. 363 6. IANA Considerations 365 This document defines new Sub-TLVs in following registries: 367 6.1. Existing Registry: BGP Tunnel Encapsulation Attribute sub-TLVs 369 This document defines new sub-TLVs in the registry "BGP Tunnel 370 Encapsulation Attribute sub-TLVs" to be assigned by IANA: 372 Codepoint Description Reference 373 ------------------------------------------------------------- 374 14 Path Segment sub-TLV This document 375 15 SR Bidirectional Path sub-TLV This document 376 127 Reverse Segment List sub-TLV This document 378 This document defines new sub-TLVs in the registry "SR Policy List 379 Sub-TLVs" [I-D.ietf-idr-segment-routing-te-policy] to be assigned by 380 IANA: 382 Codepoint Description Reference 383 ------------------------------------------------------------- 384 14 Path Segment sub-TLV This document 386 7. Security Considerations 388 TBA 390 8. Acknowledgements 392 Many thanks to Shraddha Hedge for her detailed review and 393 professional comments. 395 9. References 397 9.1. Normative References 399 [I-D.ietf-idr-segment-routing-te-policy] 400 Previdi, S., Filsfils, C., Mattes, P., Rosen, E., Jain, 401 D., and S. Lin, "Advertising Segment Routing Policies in 402 BGP", draft-ietf-idr-segment-routing-te-policy-07 (work in 403 progress), July 2019. 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-00 (work in progress), 409 March 2019. 411 [I-D.ietf-spring-segment-routing-policy] 412 Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., 413 bogdanov@google.com, b., and P. Mattes, "Segment Routing 414 Policy Architecture", draft-ietf-spring-segment-routing- 415 policy-03 (work in progress), May 2019. 417 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 418 Requirement Levels", BCP 14, RFC 2119, 419 DOI 10.17487/RFC2119, March 1997, 420 . 422 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 423 Decraene, B., Litkowski, S., and R. Shakir, "Segment 424 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 425 July 2018, . 427 9.2. Informative References 429 [I-D.gandhi-spring-udp-pm] 430 Gandhi, R., Filsfils, C., daniel.voyer@bell.ca, d., 431 Salsano, S., Ventre, P., and M. Chen, "UDP Path for In- 432 band Performance Measurement for Segment Routing 433 Networks", draft-gandhi-spring-udp-pm-02 (work in 434 progress), September 2018. 436 [I-D.ietf-mpls-bfd-directed] 437 Mirsky, G., Tantsura, J., Varlashkin, I., and M. Chen, 438 "Bidirectional Forwarding Detection (BFD) Directed Return 439 Path", draft-ietf-mpls-bfd-directed-11 (work in progress), 440 April 2019. 442 Authors' Addresses 444 Cheng Li 445 Huawei Technologies 446 Huawei Campus, No. 156 Beiqing Rd. 447 Beijing 100095 448 China 450 Email: chengli13@huawei.com 452 Huanan Chen 453 China Telecom 454 109 West Zhongshan Ave 455 Guangzhou 456 China 458 Email: chenhn8.gd@chinatelecom.cn 460 Mach(Guoyi) Chen 461 Huawei Technologies 462 Huawei Campus, No. 156 Beiqing Rd. 463 Beijing 100095 464 China 466 Email: Mach.chen@huawei.com 467 Jie Dong 468 Huawei Technologies 469 Huawei Campus, No. 156 Beiqing Rd. 470 Beijing 100095 471 China 473 Email: jie.dong@huawei.com 475 Zhenbin Li 476 Huawei Technologies 477 Huawei Campus, No. 156 Beiqing Rd. 478 Beijing 100095 479 China 481 Email: lizhenbin@huawei.com