idnits 2.17.1 draft-koldychev-pce-multipath-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 : ---------------------------------------------------------------------------- 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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 30, 2019) is 1639 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-06) exists of draft-barth-pce-segment-routing-policy-cp-03 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-03 == Outdated reference: A later version (-07) exists of draft-koldychev-pce-operational-00 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Koldychev 3 Internet-Draft S. Sivabalan 4 Intended status: Informational Cisco Systems, Inc. 5 Expires: May 2, 2020 T. Saad 6 V. Beeram 7 Juniper Networks, Inc. 8 H. Bidgoli 9 Nokia 10 B. Yadav 11 Ciena 12 October 30, 2019 14 PCEP Extensions for Signaling Multipath Information 15 draft-koldychev-pce-multipath-00 17 Abstract 19 This document introduces a mechanism to communicate multipath 20 information in PCEP as a set of Explicit Route Objects (EROs). A 21 special object is defined to carry per ERO attributes. This 22 mechanism is applicable to SR-TE and RSVP-TE. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on May 2, 2020. 41 Copyright Notice 43 Copyright (c) 2019 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2.1. Terms and Abbreviations . . . . . . . . . . . . . . . . . 3 61 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3.1. Signaling Multiple Segment-Lists of an SR Candidate-Path 4 63 3.2. Splitting of Requested Bandwidth . . . . . . . . . . . . 4 64 3.3. Providing Backup ERO for Protection . . . . . . . . . . . 4 65 4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 4 66 4.1. Multipath Capability TLV . . . . . . . . . . . . . . . . 4 67 4.2. ERO Attributes Object . . . . . . . . . . . . . . . . . . 5 68 4.3. Multipath Weight TLV . . . . . . . . . . . . . . . . . . 6 69 4.4. Multipath Backup TLV . . . . . . . . . . . . . . . . . . 6 70 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 73 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 8 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 76 9.2. Informative References . . . . . . . . . . . . . . . . . 9 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 79 1. Introduction 81 Path Computation Element (PCE) Communication Protocol (PCEP) 82 [RFC5440] enables the communication between a Path Computation Client 83 (PCC) and a Path Control Element (PCE), or between two PCEs based on 84 the PCE architecture [RFC4655]. 86 PCEP Extensions for the Stateful PCE Model [RFC8231] describes a set 87 of extensions to PCEP to enable active control of Multiprotocol Label 88 Switching Traffic Engineering (MPLS-TE) and Generalized MPLS (GMPLS) 89 tunnels. [RFC8281] describes the setup and teardown of PCE-initiated 91 LSPs under the active stateful PCE model, without the need for local 92 configuration on the PCC, thus allowing for dynamic centralized 93 control of a network. 95 PCEP Extensions for Segment Routing [I-D.ietf-pce-segment-routing] 96 specifies extensions to the Path Computation Element Protocol (PCEP) 97 that allow a stateful PCE to compute and initiate Traffic Engineering 98 (TE) paths, as well as a PCC to request a path subject to certain 99 constraint(s) and optimization criteria in SR networks. 101 Segment Routing Policy for Traffic Engineering 102 [I-D.ietf-spring-segment-routing-policy] details the concepts of SR 103 Policy and approaches to steering traffic into an SR Policy. In 104 particular, it describes the SR candidate-path as a collection of one 105 or more Segment-Lists. The current PCEP standards only allow for 106 signaling of one Segment-List per Candidate-Path. PCEP extension to 107 support Segment Routing Policy Candidate Paths 108 [I-D.barth-pce-segment-routing-policy-cp] specifically avoids 109 defining how to signal multipath information, and states that this 110 will be defined in another document (this one). 112 2. Terminology 114 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 115 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 116 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 117 [RFC2119]. 119 2.1. Terms and Abbreviations 121 The following terms are used in this document: 123 Endpoint: 125 The IPv4 or IPv6 endpoint address of the SR policy in question, as 126 described in [I-D.ietf-spring-segment-routing-policy]. 128 PCEP Tunnel: 130 The object identified by the PLSP-ID, as per 131 [I-D.koldychev-pce-operational]. 133 Tunnel Instance: 135 The object identified by the LSP-Identifiers TLV, as per 136 [I-D.koldychev-pce-operational]. 138 3. Motivation 140 This extension is motivated by the use-cases described below. 142 3.1. Signaling Multiple Segment-Lists of an SR Candidate-Path 144 The Candidate-Path of an SR Policy corresponds to a PCEP Tunnel, see 145 [I-D.barth-pce-segment-routing-policy-cp]. Each Candidate-Path can 146 contain multiple Segment-Lists and each Segment-List is encoded by 147 one SR-ERO object. However, each Tunnel Instance can contain only a 148 single ERO object, which prevents us from encoding multiple Segment- 149 Lists within the same SR Candidate-Path. 151 With the help of the protocol extensions defined in this document, 152 this limitation is overcome. 154 3.2. Splitting of Requested Bandwidth 156 A PCC may request a path with 100 Gbit of bandwidth, but all links in 157 the network have only 50 Gbit capacity. The PCE can return two 158 paths, that can each carry 50 Gbit. The PCC can then equally or 159 unequally split the incoming 100 Gbit of traffic among the two 50 160 Gbit paths. Section 4.3 introduces a new TLV that carries the ERO 161 path weight that allows distributing of incoming traffic on to the 162 multiple ERO path(s). 164 3.3. Providing Backup ERO for Protection 166 It is desirable for the PCE to compute and signal to the PCC a backup 167 ERO path that is used to protect a primary ERO path. In this case, 168 an indication specify a primary or backup. 170 When multipath is used, a backup ERO path may protect one or more 171 primary ERO path. For this reason, a primary and backup path 172 identifiers are needed to indicate which backup ERO path(s) protect 173 which primary ERO path(s). Section 4.4 introduces a new TLV that 174 carries the required information. 176 4. Protocol Extensions 178 4.1. Multipath Capability TLV 180 We define the MULTIPATH-CAP TLV that MAY be present in the OPEN 181 object and/or the LSP object. The purpose of this TLV is two-fold: 183 1. From PCC: it tells how many multipaths the PCC can install in 184 forwarding. 186 2. From PCE: it tells that the PCE supports this standard and how 187 many multipaths the PCE can compute. 189 Only the first instance of this TLV can be processed, subsequent 190 instances SHOULD be ignored. 192 0 1 2 3 193 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 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Type | Length | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | Number of Multipaths | Reserved |B|W| 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 Figure 1: MULTIPATH-CAP TLV format 202 Type: TBD1 for "MULTIPATH-CAP" TLV. 204 Length: 4. 206 Number of Multipaths: the maximum number of multipaths that a PCE can 207 return. The value 0 indicates unlimited number. 209 B-flag: whether MULTIPATH-BACKUP-TLV is supported. 211 W-flag: whether MULTIPATH-WEIGHT-TLV is supported. 213 Reserved: zero on transmit, ignore on receipt. 215 4.2. ERO Attributes Object 217 We define the ERO-ATTRIB object that is used to carry per-ERO 218 information and to act as a separator between several ERO objects. 219 The ERO-ATTRIB object always precedes the ERO that it applies to. If 220 multiple ERO objects are present, then each ERO object MUST be 221 preceded by an ERO-ATTRIB object that describes it. 223 0 1 2 3 224 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 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | Flags | Oper| 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 ~ Optional TLVs ~ 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 Figure 2: ERO-ATTRIB object format 233 Flags: to be extended in the future. 235 Oper: operational state of the ERO, same values as the identically 236 named field in the LSP object. 238 4.3. Multipath Weight TLV 240 We define the MULTIPATH-WEIGHT TLV that MAY be present in the 241 ERO_ATTRIBUTES object. 243 0 1 2 3 244 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 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Type | Length | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Weight | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 Figure 3: MULTIPATH-WEIGHT TLV format 253 Type: TBD2 for "MULTIPATH-WEIGHT" TLV. 255 Length: 4. 257 Weight: weight of this path within the multipath, if W-ECMP is 258 desired. The fraction of flows a specific ERO carries is derived 259 from the ratio of its weight to the sum of all other multipath ERO 260 weights. 262 4.4. Multipath Backup TLV 264 This document introduces a new MULTIPATH-BACKUP TLV that is optional 265 and can be present in the ERO_ATTRIBUTES object. 267 This TLV is used to indicate the presence of a backup ERO path that 268 is used for protection in case of failure of the primary ERO path. 269 The format of the MULTIPATH-BACKUP TLV is: 271 0 1 2 3 272 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 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Type | Length | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Flags | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | ERO Path ID. | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Backup ERO Path ID | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 Figure 4: MULTIPATH-BACKUP TLV format 285 Type: TBD3 for "MULTIPATH-BACKUP" TLV 287 Length: 8 289 Flags: 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 |P|B|F| Reserved | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 P: If set, indicates the ERO is for a primary path 297 B: If set, indicates the ERO is for a backup path 299 F: If set, indicates this primary ERO is also protected. The 300 backup ERO Path ID indicates the ERO of the backup path. 302 ERO Path ID: an identifier that identifies a primary path in the set 303 of ERO(s) 305 Backup ERO Path ID: an identifier that identifies the backup path ERO 306 in the set of ERO(s) 308 5. Operation 310 When the PCC wants to indicate to the PCE that it wants to get 311 multipaths instead of a single path, it can do one or both of the 312 following: 314 1. Send the MULTIPATH-CAP TLV in the OPEN object during session 315 establishment. This applies to all PCEP Tunnels on the PCC, 316 unless overridden by PCEP Tunnel specific information. 318 2. Send the MULTIPATH-CAP TLV in the LSP object for a particular 319 PCEP Tunnel in the PCRpt message. This applies to the specified 320 PCEP Tunnel and overrides the information from the OPEN object. 322 When PCE computes the path for a PCEP Tunnel, it MUST NOT return more 323 multipaths than the corresponding value of "Number of Multipaths" 324 from the MULTIPATH-CAP TLV. If this TLV is absent (from both OPEN 325 and LSP objects), then the "Number of Multipaths" is assumed to be 1. 327 If the PCE supports this standard, then it MUST include the 328 MULTIPATH-CAP TLV in the OPEN object. This tells the PCC that it can 329 report multiple ERO objects to this PCE. If the PCE does not include 330 the MULTIPATH-CAP TLV in the OPEN object, then the PCC MUST assume 331 that the PCE does not support this standard and fall back to 332 reporting only a single ERO. 334 6. IANA Considerations 336 IANA is requested to make the assignment of a new value for the 337 existing "PCEP TLV Type Indicators" registry as follows: 339 +------------+-----------------------------------+------------------+ 340 | TLV Type | TLV Name | Reference | 341 | Value | | | 342 +------------+-----------------------------------+------------------+ 343 | TBD1 | MULTIPATH-CAP | This document | 344 +------------+-----------------------------------+------------------+ 345 | TBD2 | MULTIPATH-WEIGHT | This document | 346 +------------+-----------------------------------+------------------+ 347 | TBD3 | MULTIPATH-BACKUP | This document | 348 +------------+-----------------------------------+------------------+ 350 7. Security Considerations 352 None at this time. 354 8. Acknowledgement 356 Thanks to Dhruv Dhody for ideas and discussion. 358 9. References 360 9.1. Normative References 362 [I-D.barth-pce-segment-routing-policy-cp] 363 Koldychev, M., Sivabalan, S., Barth, C., and C. Li, "PCEP 364 extension to support Segment Routing Policy Candidate 365 Paths", draft-barth-pce-segment-routing-policy-cp-03 (work 366 in progress), July 2019. 368 [I-D.ietf-pce-segment-routing] 369 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 370 and J. Hardwick, "PCEP Extensions for Segment Routing", 371 draft-ietf-pce-segment-routing-16 (work in progress), 372 March 2019. 374 [I-D.ietf-spring-segment-routing-policy] 375 Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., 376 bogdanov@google.com, b., and P. Mattes, "Segment Routing 377 Policy Architecture", draft-ietf-spring-segment-routing- 378 policy-03 (work in progress), May 2019. 380 [I-D.koldychev-pce-operational] 381 Koldychev, M., Sivabalan, S., Negi, M., Achaval, D., and 382 H. Kotni, "PCEP Operational Clarification", draft- 383 koldychev-pce-operational-00 (work in progress), July 384 2019. 386 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 387 Requirement Levels", BCP 14, RFC 2119, March 1997. 389 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 390 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 391 DOI 10.17487/RFC5440, March 2009, . 394 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 395 Computation Element Communication Protocol (PCEP) 396 Extensions for Stateful PCE", RFC 8231, DOI 10.17487/ 397 RFC8231, September 2017, . 400 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 401 Computation Element Communication Protocol (PCEP) 402 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 403 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 404 . 406 9.2. Informative References 408 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 409 Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/ 410 RFC4655, August 2006, . 413 Authors' Addresses 415 Mike Koldychev 416 Cisco Systems, Inc. 418 Email: mkoldych@cisco.com 420 Siva Sivabalan 421 Cisco Systems, Inc. 423 Email: msiva@cisco.com 424 Tarek Saad 425 Juniper Networks, Inc. 427 Email: tsaad@juniper.net 429 Vishnu Pavan Beeram 430 Juniper Networks, Inc. 432 Email: vbeeram@juniper.net 434 Hooman Bidgoli 435 Nokia 437 Email: hooman.bidgoli@nokia.com 439 Bhupendra Yadav 440 Ciena 442 Email: byadav@ciena.com