idnits 2.17.1 draft-li-idr-sr-policy-path-segment-distribution-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 : ---------------------------------------------------------------------------- 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 (October 22, 2018) is 2006 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-04 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-01 == 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-10 Summary: 0 errors (**), 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 M. Chen 4 Intended status: Standards Track J. Dong 5 Expires: April 25, 2019 Z. Li 6 Huawei Technologies 7 October 22, 2018 9 Segment Routing Policies for Path Segment and Bidirectional Path 10 draft-li-idr-sr-policy-path-segment-distribution-01 12 Abstract 14 An SR policy is a set of candidate SR paths consisting of one or more 15 segment lists with necessary path attributes. For each SR path, it 16 may also have its own path attributes, and Path Segment is one of 17 them. A Path Segment is defined to identify an SR path, which can be 18 used for performance measurement, path correlation, and end-2-end 19 path protection. Path Segment can be also used to correlate two 20 unidirctional SR paths into a bidirectional SR path which is required 21 in some scenarios, for example, mobile backhaul transport network. 23 This document defines extensions to BGP to distribute SR policies 24 carrying Path Segment and bidirectional path information. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in RFC 2119 [RFC2119]. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on April 25, 2019. 49 Copyright Notice 51 Copyright (c) 2018 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3. SR Policy for Path Identifier . . . . . . . . . . . . . . . . 3 69 3.1. SR Path Segment Sub-TLV . . . . . . . . . . . . . . . . . 4 70 4. SR Policy for Bidirectional Path . . . . . . . . . . . . . . 5 71 4.1. SR Bidirectional Path Sub-TLV . . . . . . . . . . . . . . 6 72 4.2. SR Reverse Path Segment List Sub-TLV . . . . . . . . . . 7 73 5. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 76 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 78 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 79 9.2. Informative References . . . . . . . . . . . . . . . . . 9 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 82 1. Introduction 84 Segment routing (SR) [RFC8402] is a source routing paradigm that 85 explicitly indicates the forwarding path for packets at the ingress 86 node. The ingress node steers packets into a specific path according 87 to the Segment Routing Policy ( SR Policy) as defined in 88 [I-D.ietf-spring-segment-routing-policy]. For distributing SR 89 policies to the headend, [I-D.ietf-idr-segment-routing-te-policy] 90 specifies a mechanism by using BGP, and new sub-TLVs are defined for 91 SR Policies in BGP UPDATE message. 93 In many use cases such as performance measurement, the path to which 94 the packets belong is required to be identified. Futhermore, in some 95 scenarios, for example, mobile backhaul transport network, there are 96 requirements to support bidirectional path. However, there is no 97 path identification information for each Segment List in the SR 98 Policies defined in [I-D.ietf-spring-segment-routing-policy]. Also, 99 the SR Policies defined in [I-D.ietf-spring-segment-routing-policy] 100 only supports unidirectional SR paths. 102 Therefore, this document defines the extension to SR policies that 103 carry Path Segment in the Segment List and support bidirectional 104 path. The Path Segment can be a Path Segment in SR-MPLS 105 [I-D.cheng-spring-mpls-path-segment] , or a Path Segment in SRv6 106 [I-D.li-spring-srv6-path-segment], or other IDs that can identify a 107 path. Also, this document defines extensions to BGP to distribute SR 108 policies carriying Path Segment and bidirectional path information. 110 2. Terminology 112 This memo makes use of the terms defined in [RFC8402] and 113 [I-D.ietf-idr-segment-routing-te-policy]. 115 3. SR Policy for Path Identifier 117 As defined in [I-D.ietf-idr-segment-routing-te-policy] , the SR 118 Policy encoding structure is as follows: 120 SR Policy SAFI NLRI: 121 Attributes: 122 Tunnel Encaps Attribute (23) 123 Tunnel Type: SR Policy 124 Binding SID 125 Preference 126 Priority 127 Policy Name 128 Explicit NULL Label Policy (ENLP) 129 Segment List 130 Weight 131 Segment 132 Segment 133 ... 134 ... 136 An SR path can be specified by an Segment List sub-TLV that contains 137 a set of segment sub-TLVs and other sub-TLVs as shown above. As 138 defined in [I-D.ietf-spring-segment-routing-policy], a candidate path 139 includes multiple SR paths specified by SID list. The Path Segment 140 can be used for idendifying an SR path(specified by SID list). Also, 141 it can be used for identifying an SR candidate path or an SR Policy 142 in some use cases if needed. New SR Policy encoding structure is 143 expressed as below: 145 SR Policy SAFI NLRI: 146 Attributes: 147 Tunnel Encaps Attribute (23) 148 Tunnel Type: SR Policy 149 Binding SID 150 Preference 151 Priority 152 Policy Name 153 Explicit NULL Label Policy (ENLP) 154 Path Segment 155 Segment List 156 Weight 157 Path Segment 158 Segment 159 Segment 160 ... 161 Segment List 162 Weight 163 Path Segment 164 Segment 165 Segment 166 ... 167 ... 169 3.1. SR Path Segment Sub-TLV 171 This section defines an SR Path Segment sub-TLV. 173 An SR Path Segment sub-TLV can be included in the segment list sub- 174 TLV to identify an SID list, and it MUST appear only once within a 175 Segment List sub-TLV. It has the following format: 177 0 1 2 3 178 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 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Type | Length | Flag | ST | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | Path Segment (Variable) | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 Figure 1. Path Segment sub-TLV 186 Where: 188 Type: to be assigned by IANA (suggested value 10). 190 Length: the total length of the value field not including Type and 191 Length fields. 193 Flag: 8 bits of flags. Following flags are defined: 195 0 1 2 3 4 5 6 7 196 +--+--+--+--+--+--+--+--+ 197 | Reserved |G | 198 +--+--+--+--+--+--+--+--+ 200 G-Flag: Global flag. Set when the Path Segment is global within an 201 SR domain. 203 Reserved: 5 bits reserved and MUST be set to 0 on transmission and 204 MUST be ignored on receipt. 206 ST: Segment type, specifies the type of the Path Segment, and it has 207 following types: 209 o 0: SR-MPLS Path Segment 211 o 1: SRv6 Path Segment 213 o 2-255:Reserved 215 Path Segment: The Path Segment of an SR path. The Path Segment type 216 is indicated by the Segment Type(ST) field. It can be a Path Segment 217 in SR-MPLS [I-D.cheng-spring-mpls-path-segment], or a Path Segment in 218 SRv6 [I-D.li-spring-srv6-path-segment], or other IDs that can 219 identify a path. 221 4. SR Policy for Bidirectional Path 223 In some scenarios, for example, mobile backhaul transport network, 224 there are requirements to support bidirectional path. In SR, a 225 bidirectional path can be represented as a binding of two 226 unidirectional SR paths. This document also defines new sub-TLVs to 227 describe an SR bidirectional path. An SR policy carrying SR 228 bidirectional path information is expressed as below: 230 SR Policy SAFI NLRI: 231 Attributes: Tunnel Encaps Attribute (23) 232 Tunnel Type: SR Policy 233 Binding SID 234 Preference 235 Priority 236 Policy Name 237 Explicit NULL Label Policy (ENLP) 238 Bidirectioanl Path 239 Segment List 240 Weight 241 Path Segment 242 Segment 243 Segment 244 ... 245 Reverse Segment List 246 Weight 247 Path Segment 248 Segment 249 Segment 250 ... 252 4.1. SR Bidirectional Path Sub-TLV 254 This section defines an SR bidirectional path sub-TLV to specify a 255 bidirectional path, which contains a Segment List sub-TLV 256 [I-D.ietf-idr-segment-routing-te-policy] and an associated Reverse 257 Path Segment List as defined at section 4.2. The SR bidirectional 258 path sub-TLV has the following format: 260 0 1 2 3 261 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 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Type | Length | RESERVED | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Sub-TLVs (Variable) | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 Figure 2. SR Bidirectional path sub-TLV 269 Where: 271 Type: TBA, and the suggest value is 14. 273 Length: the total length of the sub-TLVs encoded within the SR 274 Bidirectional Path Sub-TLV not including Type and Length fields. 276 RESERVED: 1 octet of reserved bits. SHOULD be unset on transmission 277 and MUST be ignored on receipt. 279 Sub-TLVs: 281 o An Segment List sub-TLV 283 o An associated Reverse Path Segment List sub-TLV 285 4.2. SR Reverse Path Segment List Sub-TLV 287 An SR Reverse Path Segment List sub-TLV is defined to specify an SR 288 reverse path associated with the path specified by the Segment List 289 in the same SR Bidirectional Path Sub-TLV, and it has the following 290 format: 292 0 1 2 3 293 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 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Type | Length | RESERVED | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Sub-TLVs (Variable) | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 Figure 2. SR Reverse Path Segment List Sub-TLV 301 where: 303 Type: TBA, and suggest value is 127. 305 Length: the total length of the sub-TLVs encoded within the SR 306 Reverse Path Segment List Sub-TLV not including the Type and Length 307 fields. 309 RESERVED: 1 octet of reserved bits. SHOULD be unset on transmission 310 and MUST be ignored on receipt. 312 sub-TLVs, reuse the sub-TLVs in Segment List defined in 313 [I-D.ietf-idr-segment-routing-te-policy]. 315 o An optional single Weight sub-TLV. 317 o An mandatory SR Path Segment sub-TLV that contains the Path 318 Segment of the reverse SR path. 320 o Zero or more Segment sub-TLVs to specify the reverse SR path. 322 The Segment sub-TLVs in the Reverse Path Segment List sub-TLV 323 provides the information of the reverse SR path, which can be used 324 for directing egress BFD peer to use specific path for the reverse 325 direction of the BFD session [I-D.ietf-mpls-bfd-directed] or other 326 applications. 328 5. Operations 330 The document does not bring new operation beyong the description of 331 operations defined in [I-D.ietf-idr-segment-routing-te-policy]. The 332 existing operations defined in 333 [I-D.ietf-idr-segment-routing-te-policy] can apply to this document 334 directly. 336 Typically but not limit to, the unidirectional or bidirectional SR 337 policies carrying path identification infomation are configured by a 338 controller. 340 After configuration, the unidirectional or bidirectional SR policies 341 carrying path identification infomation will be advertised by BGP 342 update messages. The operation of advertisement is the same as 343 defined in [I-D.ietf-idr-segment-routing-te-policy], as well as the 344 receiption. 346 The consumer of the unidirectional or bidirectional SR policies is 347 not the BGP process, it can be any applications, such as performance 348 measurement [I-D.gandhi-spring-udp-pm]. The operation of sending 349 information to consumers is out of scope of this document. 351 6. IANA Considerations 353 TBA 355 7. Security Considerations 357 TBA 359 8. Acknowledgements 361 TBA 363 9. References 365 9.1. Normative References 367 [I-D.cheng-spring-mpls-path-segment] 368 Cheng, W., Wang, L., Li, H., Chen, M., Gandhi, R., Zigler, 369 R., and S. Zhan, "Path Segment in MPLS Based Segment 370 Routing Network", draft-cheng-spring-mpls-path-segment-03 371 (work in progress), October 2018. 373 [I-D.ietf-idr-segment-routing-te-policy] 374 Previdi, S., Filsfils, C., Jain, D., Mattes, P., Rosen, 375 E., and S. Lin, "Advertising Segment Routing Policies in 376 BGP", draft-ietf-idr-segment-routing-te-policy-04 (work in 377 progress), July 2018. 379 [I-D.ietf-spring-segment-routing-policy] 380 Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., 381 bogdanov@google.com, b., and P. Mattes, "Segment Routing 382 Policy Architecture", draft-ietf-spring-segment-routing- 383 policy-01 (work in progress), June 2018. 385 [I-D.li-spring-srv6-path-segment] 386 Li, C., Chen, M., Dhody, D., Li, Z., Dong, J., and R. 387 Gandhi, "Path Segment for SRv6 (Segment Routing in IPv6)", 388 draft-li-spring-srv6-path-segment-00 (work in progress), 389 October 2018. 391 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 392 Requirement Levels", BCP 14, RFC 2119, 393 DOI 10.17487/RFC2119, March 1997, 394 . 396 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 397 Decraene, B., Litkowski, S., and R. Shakir, "Segment 398 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 399 July 2018, . 401 9.2. Informative References 403 [I-D.gandhi-spring-udp-pm] 404 Gandhi, R., Filsfils, C., daniel.voyer@bell.ca, d., 405 Salsano, S., Ventre, P., and M. Chen, "UDP Path for In- 406 band Performance Measurement for Segment Routing 407 Networks", draft-gandhi-spring-udp-pm-02 (work in 408 progress), September 2018. 410 [I-D.ietf-mpls-bfd-directed] 411 Mirsky, G., Tantsura, J., Varlashkin, I., and M. Chen, 412 "Bidirectional Forwarding Detection (BFD) Directed Return 413 Path", draft-ietf-mpls-bfd-directed-10 (work in progress), 414 September 2018. 416 Authors' Addresses 417 Cheng Li 418 Huawei Technologies 419 Huawei Campus, No. 156 Beiqing Rd. 420 Beijing 100095 421 China 423 Email: chengli13@huawei.com 425 Mach(Guoyi) Chen 426 Huawei Technologies 427 Huawei Campus, No. 156 Beiqing Rd. 428 Beijing 100095 429 China 431 Email: Mach.chen@huawei.com 433 Jie Dong 434 Huawei Technologies 435 Huawei Campus, No. 156 Beiqing Rd. 436 Beijing 100095 437 China 439 Email: jie.dong@huawei.com 441 Zhenbin Li 442 Huawei Technologies 443 Huawei Campus, No. 156 Beiqing Rd. 444 Beijing 100095 445 China 447 Email: lizhenbin@huawei.com