Network Working Group M. Koldychev Internet-Draft S. Sivabalan Intended status: Standards Track Cisco Systems, Inc. Expires: August 24, 2020 T. Saad V. Beeram Juniper Networks, Inc. H. Bidgoli Nokia B. Yadav Ciena February 21, 2020 PCEP Extensions for Signaling Multipath Information draft-koldychev-pce-multipath-01 Abstract Current PCEP standards allow only one intended and/or actual path to be present in a PCEP report or update. Applications that require multipath support such as SR Policy require an extension to allow signaling multiple intended and/or actual paths within a single PCEP message. This document introduces such an extension. Encoding of multiple intended and/or actual paths is done by encoding multiple Explicit Route Objects (EROs) and/or multiple Record Route Objects (RROs). A special separator object is defined in this document, to facilitate this. This mechanism is applicable to SR-TE and RSVP-TE and is dataplane agnostic. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on August 24, 2020. Koldychev, et al. Expires August 24, 2020 [Page 1] Internet-Draft PCEP Extensions for Multipath February 2020 Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Terms and Abbreviations . . . . . . . . . . . . . . . . . 3 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Signaling Multiple Segment-Lists of an SR Candidate-Path 4 3.2. Splitting of Requested Bandwidth . . . . . . . . . . . . 4 3.3. Providing Backup path for Protection . . . . . . . . . . 4 4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 4 4.1. Multipath Capability TLV . . . . . . . . . . . . . . . . 4 4.2. Path Attributes Object . . . . . . . . . . . . . . . . . 5 4.3. Multipath Weight TLV . . . . . . . . . . . . . . . . . . 6 4.4. Multipath Backup TLV . . . . . . . . . . . . . . . . . . 7 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Signaling Multiple Paths for Loadbalancing . . . . . . . 8 5.2. Signaling Multiple Paths for Protection . . . . . . . . . 9 6. PCEP Message Extensions . . . . . . . . . . . . . . . . . . . 9 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. SR Policy Candidate-Path with Multiple Segment-Lists . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 11 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 12.1. Normative References . . . . . . . . . . . . . . . . . . 11 12.2. Informative References . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Koldychev, et al. Expires August 24, 2020 [Page 2] Internet-Draft PCEP Extensions for Multipath February 2020 1. Introduction Path Computation Element (PCE) Communication Protocol (PCEP) [RFC5440] enables the communication between a Path Computation Client (PCC) and a Path Control Element (PCE), or between two PCEs based on the PCE architecture [RFC4655]. PCEP Extensions for the Stateful PCE Model [RFC8231] describes a set of extensions to PCEP that enable active control of Multiprotocol Label Switching Traffic Engineering (MPLS-TE) and Generalized MPLS (GMPLS) tunnels. [RFC8281] describes the setup and teardown of PCE- initiated LSPs under the active stateful PCE model, without the need for local configuration on the PCC, thus allowing for dynamic centralized control of a network. PCEP Extensions for Segment Routing [I-D.ietf-pce-segment-routing] specifies extensions to the Path Computation Element Protocol (PCEP) that allow a stateful PCE to compute and initiate Traffic Engineering (TE) paths, as well as for a PCC to request a path subject to certain constraint(s) and optimization criteria in SR networks. Segment Routing Policy for Traffic Engineering [I-D.ietf-spring-segment-routing-policy] details the concepts of SR Policy and approaches to steering traffic into an SR Policy. In particular, it describes the SR candidate-path as a collection of one or more Segment-Lists. The current PCEP standards only allow for signaling of one Segment-List per Candidate-Path. PCEP extension to support Segment Routing Policy Candidate Paths [I-D.barth-pce-segment-routing-policy-cp] specifically avoids defining how to signal multipath information, and states that this will be defined in another document. This document defines the required extensions that allow the signaling of multipath information via PCEP. 2. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. 2.1. Terms and Abbreviations The following terms are used in this document: PCEP Tunnel: Koldychev, et al. Expires August 24, 2020 [Page 3] Internet-Draft PCEP Extensions for Multipath February 2020 The object identified by the PLSP-ID, see [I-D.koldychev-pce-operational] for more details. 3. Motivation This extension is motivated by the use-cases described below. 3.1. Signaling Multiple Segment-Lists of an SR Candidate-Path The Candidate-Path of an SR Policy is the unit of report/update in PCEP, see [I-D.barth-pce-segment-routing-policy-cp]. Each Candidate- Path can contain multiple Segment-Lists and each Segment-List is encoded by one SR-ERO object. However, each PCEP LSP can contain only a single SR-ERO object, which prevents us from encoding multiple Segment- Lists within the same SR Candidate-Path. With the help of the protocol extensions defined in this document, this limitation is overcome. 3.2. Splitting of Requested Bandwidth A PCC may request a path with 100 Gbps of bandwidth, but all links in the network have only 50 Gbps capacity. The PCE can return two paths, that can each carry 50 Gbps. The PCC can then equally or unequally split the incoming 100 Gbps of traffic among the two 50 Gbps paths. Section 4.3 introduces a new TLV that carries the path weight that allows for distribution of incoming traffic on to the multiple paths. 3.3. Providing Backup path for Protection It is desirable for the PCE to compute and signal to the PCC a backup path that is used to protect a primary path. When multipath is used, a backup path may protect one or more primary paths. For this reason, a primary and backup path identifiers are needed to indicate which backup path(s) protect which primary path(s). Section 4.4 introduces a new TLV that carries the required information. 4. Protocol Extensions 4.1. Multipath Capability TLV We define the MULTIPATH-CAP TLV that MAY be present in the OPEN object and/or the LSP object. The purpose of this TLV is two-fold: Koldychev, et al. Expires August 24, 2020 [Page 4] Internet-Draft PCEP Extensions for Multipath February 2020 1. From PCC: it tells how many multipaths the PCC can install in forwarding. 2. From PCE: it tells that the PCE supports this standard and how many multipaths the PCE can compute. Only the first instance of this TLV can be processed, subsequent instances SHOULD be ignored. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Multipaths | Reserved |B|W| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: MULTIPATH-CAP TLV format Type: TBD1 for "MULTIPATH-CAP" TLV. Length: 4. Number of Multipaths: the maximum number of multipaths that a PCE can return. The value 0 indicates unlimited number. B-flag: whether MULTIPATH-BACKUP-TLV is supported. W-flag: whether MULTIPATH-WEIGHT-TLV is supported. Reserved: zero on transmit, ignore on receipt. 4.2. Path Attributes Object We define the PATH-ATTRIB object that is used to carry per-path information and to act as a separator between several ERO/RRO objects in the intended-path/actual-path RBNF element. The PATH-ATTRIB object always precedes the ERO/RRO that it applies to. If multiple ERO/RRO objects are present, then each ERO/RRO object MUST be preceded by an PATH-ATTRIB object that describes it. Koldychev, et al. Expires August 24, 2020 [Page 5] Internet-Draft PCEP Extensions for Multipath February 2020 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Oper| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path ID. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Optional TLVs ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: PATH-ATTRIB object format Flags: to be extended in the future. Oper: operational state of the path, same values as the identically named field in the LSP object. Path ID: 4-octet identifier that identifies a path in the set of multiple paths. 4.3. Multipath Weight TLV We define the MULTIPATH-WEIGHT TLV that MAY be present in the PATH- ATTRIB object. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Weight | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: MULTIPATH-WEIGHT TLV format Type: TBD2 for "MULTIPATH-WEIGHT" TLV. Length: 4. Weight: weight of this path within the multipath, if W-ECMP is desired. The fraction of flows a specific ERO/RRO carries is derived from the ratio of its weight to the sum of all other multipath ERO/ RRO weights. Koldychev, et al. Expires August 24, 2020 [Page 6] Internet-Draft PCEP Extensions for Multipath February 2020 4.4. Multipath Backup TLV This document introduces a new MULTIPATH-BACKUP TLV that is optional and can be present in the PATH-ATTRIB object. This TLV is used to indicate the presence of a backup path that is used for protection in case of failure of the primary path. The format of the MULTIPATH-BACKUP TLV is: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Backup Path Number | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Backup Path ID 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Backup Path ID 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Backup Path ID n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: MULTIPATH-BACKUP TLV format Type: TBD3 for "MULTIPATH-BACKUP" TLV Length: variable - multiple of 4-octets Backup Path Number: Number of backup path(s). Flags: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |B| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ B: If set, indicates a pure backup path. This is a path that only carries rerouted traffic after the protected path fails. If this flag is not set, or if the MULTIPATH-BACKUP TLV is not carried in the PATH-ATTRIB object of an ERO or SERO, then the path is assumed to be primary that carries normal traffic. Backup Path ID(s): a series of 4-octet identifier(s) that identify the backup path(s) in the set that protect this primary path. Koldychev, et al. Expires August 24, 2020 [Page 7] Internet-Draft PCEP Extensions for Multipath February 2020 5. Operation When the PCC wants to indicate to the PCE that it wants to get multipaths instead of a single path, it can do one or both of the following: 1. Send the MULTIPATH-CAP TLV in the OPEN object during session establishment. This applies to all PCEP Tunnels on the PCC, unless overridden by PCEP Tunnel specific information. 2. Send the MULTIPATH-CAP TLV in the LSP object for a particular PCEP Tunnel in the PCRpt message. This applies to the specified PCEP Tunnel and overrides the information from the OPEN object. When PCE computes the path for a PCEP Tunnel, it MUST NOT return more multipaths than the corresponding value of "Number of Multipaths" from the MULTIPATH-CAP TLV. If this TLV is absent (from both OPEN and LSP objects), then the "Number of Multipaths" is assumed to be 1. If the PCE supports this standard, then it MUST include the MULTIPATH-CAP TLV in the OPEN object. This tells the PCC that it can report multiple ERO/RRO objects to this PCE. If the PCE does not include the MULTIPATH-CAP TLV in the OPEN object, then the PCC MUST assume that the PCE does not support this standard and fall back to reporting only a single ERO/RRO. 5.1. Signaling Multiple Paths for Loadbalancing The PATH-ATTRIB object can be used to signal multiple path(s) and indicate (un)equal loadbalancing amongst the set of multipaths. In this case, the PATH-ATTRIB is populated for each ERO or SERO as follows: 1. The PCE assigns a unique Path ID to each ERO or SERO path and populates it inside the PATH-ATTRIB object. The Path ID is unique within the context of a PLSP or PCEP Tunnel. 2. The MULTIPATH-WEIGHT TLV MAY be carried inside the PATH-ATTRIB object. A weight is populated to reflect the relative loadshare that is to be carried by the path. If the MULTIPATH-WEIGHT is not carried inside a PATH-ATTRIB object, the default weight 1 MUST be assumed when computing the loadshare. 3. The fraction of flows carried by a specific primary path is derived from the ratio of its weight to the sum of all other multipath weights. Koldychev, et al. Expires August 24, 2020 [Page 8] Internet-Draft PCEP Extensions for Multipath February 2020 5.2. Signaling Multiple Paths for Protection The PATH-ATTRIB object can be used to describe a set of backup path(s) protecting a primary path. In this case, the PATH-ATTRIB is populated for each ERO or SERO as follows: 1. The PCE assigns a unique Path ID to each ERO or SERO path and populates it inside the PATH-ATTRIB object. The Path ID is unique within the context of a PLSP or PCEP Tunnel. 2. The MULTIPATH-BACKUP TLV MUST be added inside the PATH-ATTRIB object for each ERO or SERO that is protected. The backup path ID(s) are populated in the MULTIPATH-BACKUP TLV to reflect the set of backup path(s) protecting the primary path. The Length field and Backup Path Number in the MULTIPATH-BACKUP are updated according to the number of backup path ID(s) included. 3. The MULTIPATH-BACKUP TLV MAY be added inside the PATH-ATTRIB object for each ERO or SERO that is unprotected. In this case, MULTIPATH-BACKUP does not carry any backup path IDs in the TLV. If the path acts as a pure backup - i.e. the path only carries rerouted traffic after the protected path(s) fail- then the B flag MUST be set. 6. PCEP Message Extensions The RBNF of PCReq, PCRep, PCRpt, PCUpd and PCInit messages currently use intended-path and/or actual-path: ::= (|) [] ::= (|) [] In this standard, we extend these two elements: ::= [](|) [] ::= [](|) [] 7. Examples Koldychev, et al. Expires August 24, 2020 [Page 9] Internet-Draft PCEP Extensions for Multipath February 2020 7.1. SR Policy Candidate-Path with Multiple Segment-Lists Consider how the following sample SR Policy, taken from [I-D.ietf-spring-segment-routing-policy], would be represented in a PCRpt message. SR policy POL1 Candidate-path CP1 Preference 200 Weight W1, SID-List1 Weight W2, SID-List2 Candidate-path CP2 Preference 100 Weight W3, SID-List3 Weight W4, SID-List4 As specified in [I-D.barth-pce-segment-routing-policy-cp], CP1 and CP2 are signaled as separate state-report elements and each has a unique PLSP-ID, assigned by the PCC. Let us assign PLSP-ID 100 to CP1 and PLSP-ID 200 to CP2. The state-report for CP1 can be encoded as: = The state-report for CP2 can be encoded as: = The above sample state-report elements only specify the minimum mandatory objects, of course other objects like SRP, LSPA, METRIC, etc., are allowed to be inserted. Note that the syntax Koldychev, et al. Expires August 24, 2020 [Page 10] Internet-Draft PCEP Extensions for Multipath February 2020 , simply means that this is PATH-ATTRIB object with PATH_ID field set to "1" and with a Weight TLV carrying weight of "W1". 8. IANA Considerations IANA is requested to make the assignment of a new value for the existing "PCEP TLV Type Indicators" registry as follows: +------------+-----------------------------------+-----------------+ | TLV Type | TLV Name | Reference | | Value | | | +------------+-----------------------------------+-----------------+ | TBD1 | MULTIPATH-CAP | This document | +------------+-----------------------------------+-----------------+ | TBD2 | MULTIPATH-WEIGHT | This document | +------------+-----------------------------------+-----------------+ | TBD3 | MULTIPATH-BACKUP | This document | +------------+-----------------------------------+-----------------+ 9. Security Considerations None at this time. 10. Acknowledgement Thanks to Dhruv Dhody for ideas and discussion. 11. Contributors Andrew Stone Nokia Email: andrew.stone@nokia.com 12. References 12.1. Normative References [I-D.barth-pce-segment-routing-policy-cp] Koldychev, M., Sivabalan, S., Barth, C., Li, C., and H. Bidgoli, "PCEP extension to support Segment Routing Policy Candidate Paths", draft-barth-pce-segment-routing-policy- cp-04 (work in progress), October 2019. Koldychev, et al. Expires August 24, 2020 [Page 11] Internet-Draft PCEP Extensions for Multipath February 2020 [I-D.ietf-pce-segment-routing] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., and J. Hardwick, "PCEP Extensions for Segment Routing", draft-ietf-pce-segment-routing-16 (work in progress), March 2019. [I-D.ietf-spring-segment-routing-policy] Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and P. Mattes, "Segment Routing Policy Architecture", draft- ietf-spring-segment-routing-policy-06 (work in progress), December 2019. [I-D.koldychev-pce-operational] Koldychev, M., Sivabalan, S., Negi, M., Achaval, D., and H. Kotni, "PCEP Operational Clarification", draft- koldychev-pce-operational-00 (work in progress), July 2019. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, . [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE", RFC 8231, DOI 10.17487/RFC8231, September 2017, . [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, . 12.2. Informative References [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, . Koldychev, et al. Expires August 24, 2020 [Page 12] Internet-Draft PCEP Extensions for Multipath February 2020 Authors' Addresses Mike Koldychev Cisco Systems, Inc. Email: mkoldych@cisco.com Siva Sivabalan Cisco Systems, Inc. Email: msiva@cisco.com Tarek Saad Juniper Networks, Inc. Email: tsaad@juniper.net Vishnu Pavan Beeram Juniper Networks, Inc. Email: vbeeram@juniper.net Hooman Bidgoli Nokia Email: hooman.bidgoli@nokia.com Bhupendra Yadav Ciena Email: byadav@ciena.com Koldychev, et al. Expires August 24, 2020 [Page 13]