idnits 2.17.1 draft-li-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 (June 27, 2019) is 1757 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-06 == 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 (-07) exists of draft-li-spring-srv6-path-segment-00 == Outdated reference: A later version (-30) exists of draft-ietf-mpls-bfd-directed-11 Summary: 1 error (**), 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 Huawei Technologies 4 Intended status: Standards Track H. Chen 5 Expires: December 29, 2019 China Telecom 6 M. Chen 7 J. Dong 8 Z. Li 9 Huawei Technologies 10 June 27, 2019 12 SR Policy Extensions for Path Segment and Bidirectional Path 13 draft-li-idr-sr-policy-path-segment-00 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 December 29, 2019. 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 . . . . . . . . . . . . . . 6 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 a Path Segment in SRv6 112 [I-D.li-spring-srv6-path-segment], or other IDs that can identify a 113 path. Also, this document defines extensions to BGP to distribute SR 114 policies carriying Path Segment and bidirectional path 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: SRv6 Path Segment 227 o 2-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, or a Path Segment in SRv6 [I-D.li-spring-srv6-path-segment], 233 which is a 128-bits value, or other IDs that can identify a 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. Acknowledgements 394 Many thanks to Shraddha Hedge for her detailed review and 395 professional comments. 397 9. References 399 9.1. Normative References 401 [I-D.ietf-idr-segment-routing-te-policy] 402 Previdi, S., Filsfils, C., Jain, D., Mattes, P., Rosen, 403 E., and S. Lin, "Advertising Segment Routing Policies in 404 BGP", draft-ietf-idr-segment-routing-te-policy-06 (work in 405 progress), May 2019. 407 [I-D.ietf-spring-mpls-path-segment] 408 Cheng, W., Li, H., Chen, M., Gandhi, R., and R. Zigler, 409 "Path Segment in MPLS Based Segment Routing Network", 410 draft-ietf-spring-mpls-path-segment-00 (work in progress), 411 March 2019. 413 [I-D.ietf-spring-segment-routing-policy] 414 Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., 415 bogdanov@google.com, b., and P. Mattes, "Segment Routing 416 Policy Architecture", draft-ietf-spring-segment-routing- 417 policy-03 (work in progress), May 2019. 419 [I-D.li-spring-srv6-path-segment] 420 Li, C., Chen, M., Dhody, D., Li, Z., Dong, J., and R. 421 Gandhi, "Path Segment for SRv6 (Segment Routing in IPv6)", 422 draft-li-spring-srv6-path-segment-00 (work in progress), 423 October 2018. 425 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 426 Requirement Levels", BCP 14, RFC 2119, 427 DOI 10.17487/RFC2119, March 1997, 428 . 430 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 431 Decraene, B., Litkowski, S., and R. Shakir, "Segment 432 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 433 July 2018, . 435 9.2. Informative References 437 [I-D.gandhi-spring-udp-pm] 438 Gandhi, R., Filsfils, C., daniel.voyer@bell.ca, d., 439 Salsano, S., Ventre, P., and M. Chen, "UDP Path for In- 440 band Performance Measurement for Segment Routing 441 Networks", draft-gandhi-spring-udp-pm-02 (work in 442 progress), September 2018. 444 [I-D.ietf-mpls-bfd-directed] 445 Mirsky, G., Tantsura, J., Varlashkin, I., and M. Chen, 446 "Bidirectional Forwarding Detection (BFD) Directed Return 447 Path", draft-ietf-mpls-bfd-directed-11 (work in progress), 448 April 2019. 450 Authors' Addresses 452 Cheng Li 453 Huawei Technologies 454 Huawei Campus, No. 156 Beiqing Rd. 455 Beijing 100095 456 China 458 Email: chengli13@huawei.com 459 Huanan Chen 460 China Telecom 461 109 West Zhongshan Ave 462 Guangzhou 463 China 465 Email: chenhn8.gd@chinatelecom.cn 467 Mach(Guoyi) Chen 468 Huawei Technologies 469 Huawei Campus, No. 156 Beiqing Rd. 470 Beijing 100095 471 China 473 Email: Mach.chen@huawei.com 475 Jie Dong 476 Huawei Technologies 477 Huawei Campus, No. 156 Beiqing Rd. 478 Beijing 100095 479 China 481 Email: jie.dong@huawei.com 483 Zhenbin Li 484 Huawei Technologies 485 Huawei Campus, No. 156 Beiqing Rd. 486 Beijing 100095 487 China 489 Email: lizhenbin@huawei.com