Network Working Group M. Koldychev Internet-Draft S. Sivabalan Intended status: Informational Cisco Systems, Inc. Expires: May 2, 2020 T. Saad V. Beeram Juniper Networks, Inc. H. Bidgoli Nokia B. Yadav Ciena October 30, 2019 PCEP Extensions for Signaling Multipath Information draft-koldychev-pce-multipath-00 Abstract This document introduces a mechanism to communicate multipath information in PCEP as a set of Explicit Route Objects (EROs). A special object is defined to carry per ERO attributes. This mechanism is applicable to SR-TE and RSVP-TE. 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 http://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 May 2, 2020. Copyright Notice Copyright (c) 2019 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 (http://trustee.ietf.org/license-info) in effect on the date of Koldychev, et al. Expires May 2, 2020 [Page 1] Internet-Draft PCEP Extensions for Multipath October 2019 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Terms and Abbreviations . . . . . . . . . . . . . . . . . 3 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Signaling Multiple Segment-Lists of an SR Candidate-Path 4 3.2. Splitting of Requested Bandwidth . . . . . . . . . . . . 4 3.3. Providing Backup ERO for Protection . . . . . . . . . . . 4 4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 4 4.1. Multipath Capability TLV . . . . . . . . . . . . . . . . 4 4.2. ERO Attributes Object . . . . . . . . . . . . . . . . . . 5 4.3. Multipath Weight TLV . . . . . . . . . . . . . . . . . . 6 4.4. Multipath Backup TLV . . . . . . . . . . . . . . . . . . 6 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 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 to 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) Koldychev, et al. Expires May 2, 2020 [Page 2] Internet-Draft PCEP Extensions for Multipath October 2019 that allow a stateful PCE to compute and initiate Traffic Engineering (TE) paths, as well as 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 one). 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: Endpoint: The IPv4 or IPv6 endpoint address of the SR policy in question, as described in [I-D.ietf-spring-segment-routing-policy]. PCEP Tunnel: The object identified by the PLSP-ID, as per [I-D.koldychev-pce-operational]. Tunnel Instance: The object identified by the LSP-Identifiers TLV, as per [I-D.koldychev-pce-operational]. 3. Motivation This extension is motivated by the use-cases described below. Koldychev, et al. Expires May 2, 2020 [Page 3] Internet-Draft PCEP Extensions for Multipath October 2019 3.1. Signaling Multiple Segment-Lists of an SR Candidate-Path The Candidate-Path of an SR Policy corresponds to a PCEP Tunnel, 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 Tunnel Instance can contain only a single 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 Gbit of bandwidth, but all links in the network have only 50 Gbit capacity. The PCE can return two paths, that can each carry 50 Gbit. The PCC can then equally or unequally split the incoming 100 Gbit of traffic among the two 50 Gbit paths. Section 4.3 introduces a new TLV that carries the ERO path weight that allows distributing of incoming traffic on to the multiple ERO path(s). 3.3. Providing Backup ERO for Protection It is desirable for the PCE to compute and signal to the PCC a backup ERO path that is used to protect a primary ERO path. In this case, an indication specify a primary or backup. When multipath is used, a backup ERO path may protect one or more primary ERO path. For this reason, a primary and backup path identifiers are needed to indicate which backup ERO path(s) protect which primary ERO 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: 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. Koldychev, et al. Expires May 2, 2020 [Page 4] Internet-Draft PCEP Extensions for Multipath October 2019 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. ERO Attributes Object We define the ERO-ATTRIB object that is used to carry per-ERO information and to act as a separator between several ERO objects. The ERO-ATTRIB object always precedes the ERO that it applies to. If multiple ERO objects are present, then each ERO object MUST be preceded by an ERO-ATTRIB object that describes it. 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| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Optional TLVs ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: ERO-ATTRIB object format Flags: to be extended in the future. Oper: operational state of the ERO, same values as the identically named field in the LSP object. Koldychev, et al. Expires May 2, 2020 [Page 5] Internet-Draft PCEP Extensions for Multipath October 2019 4.3. Multipath Weight TLV We define the MULTIPATH-WEIGHT TLV that MAY be present in the ERO_ATTRIBUTES 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 carries is derived from the ratio of its weight to the sum of all other multipath ERO weights. 4.4. Multipath Backup TLV This document introduces a new MULTIPATH-BACKUP TLV that is optional and can be present in the ERO_ATTRIBUTES object. This TLV is used to indicate the presence of a backup ERO path that is used for protection in case of failure of the primary ERO 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ERO Path ID. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Backup ERO Path ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: MULTIPATH-BACKUP TLV format Koldychev, et al. Expires May 2, 2020 [Page 6] Internet-Draft PCEP Extensions for Multipath October 2019 Type: TBD3 for "MULTIPATH-BACKUP" TLV Length: 8 Flags: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |P|B|F| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ P: If set, indicates the ERO is for a primary path B: If set, indicates the ERO is for a backup path F: If set, indicates this primary ERO is also protected. The backup ERO Path ID indicates the ERO of the backup path. ERO Path ID: an identifier that identifies a primary path in the set of ERO(s) Backup ERO Path ID: an identifier that identifies the backup path ERO in the set of ERO(s) 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 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. Koldychev, et al. Expires May 2, 2020 [Page 7] Internet-Draft PCEP Extensions for Multipath October 2019 6. 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 | +------------+-----------------------------------+------------------+ 7. Security Considerations None at this time. 8. Acknowledgement Thanks to Dhruv Dhody for ideas and discussion. 9. References 9.1. Normative References [I-D.barth-pce-segment-routing-policy-cp] Koldychev, M., Sivabalan, S., Barth, C., and C. Li, "PCEP extension to support Segment Routing Policy Candidate Paths", draft-barth-pce-segment-routing-policy-cp-03 (work in progress), July 2019. [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., daniel.voyer@bell.ca, d., bogdanov@google.com, b., and P. Mattes, "Segment Routing Policy Architecture", draft-ietf-spring-segment-routing- policy-03 (work in progress), May 2019. Koldychev, et al. Expires May 2, 2020 [Page 8] Internet-Draft PCEP Extensions for Multipath October 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, 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, . 9.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, . Authors' Addresses Mike Koldychev Cisco Systems, Inc. Email: mkoldych@cisco.com Siva Sivabalan Cisco Systems, Inc. Email: msiva@cisco.com Koldychev, et al. Expires May 2, 2020 [Page 9] Internet-Draft PCEP Extensions for Multipath October 2019 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 May 2, 2020 [Page 10]