Cisco Systems, Inc.

Eurovea Central 3. Pribinova 10 Bratislava 811 09 Slovakia ssidor@cisco.com

Cisco Systems, Inc.

2300 East President George Richardson TX 75082 United States of America atokar@cisco.com

ZTE Corporation

No.50 Software Avenue Nanjing Jiangsu 210012 China peng.shaofu@zte.com.cn

Huawei Technologies

Huawei Campus, No. 156 Beiqing Rd. Beijing 100095 China pengshuping@huawei.com

Nokia

andrew.stone@nokia.com

PCE Working Group This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) to enhance support for Segment Routing (SR) with a focus on the use of Segment Identifiers (SIDs) and SR-Algorithms in Traffic Engineering (TE). The SR-Algorithm associated with a SID defines the path computation algorithm used by Interior Gateway Protocols (IGPs). This document proposes an approach for informing PCEP peers about the SR-Algorithm associated with each SID used, as well as signaling a specific SR-Algorithm as a constraint to the Path Computation Element (PCE). The mechanisms for specifying an SR-Algorithm constraint allow for refined path computations that meet specific operational needs, such as low-latency or high-bandwidth paths based primarily on operator-defined criteria using Flexible Algorithms. Additionally, this document updates RFC 8664 and RFC 9603 to allow encoding of SR-Algorithm of specific SID in Explicit Route Object (ERO) subobjects.

describes the Path Computation Element Communication Protocol (PCEP) for communication between a Path Computation Client (PCC) and a Path Computation Element (PCE) or between a pair of PCEs. This document specifies extensions to PCEP to enhance support for Segment Routing (SR) Traffic Engineering (TE). Specifically, it focuses on the use of Segment Identifiers (SIDs) and SR-Algorithms. An SR-Algorithm associated with a SID defines the path computation algorithm used by Interior Gateway Protocols (IGPs). This document introduces mechanisms for PCEP peers to exchange information about the SR-Algorithm associated with each SID and to signal specific SR-Algorithm constraints to the PCE for path computation. Furthermore, this document updates and enabling the encoding of SR-Algorithms for specific SIDs within ERO subobjects. The PCEP extensions for the SR-Algorithm based path computation include: Extending the OPEN Object to indicate support for SR-Algorithm. Extending SR-ERO, SRv6-ERO, SR-RRO and SRv6-RRO Subobjects to include Algorithm field Extending the Label Switched Path Attributes (LSPA) Object to include SR-Algorithm constraint Defining several new types for METRIC Object required to support SR-Algorithm based path computation The mechanisms described in this document are equally applicable to both SR-MPLS and SRv6.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

This document uses the following terms defined in : ERO, LSPA, PCC, PCE, PCEP, PCEP Peer, and PCEP speaker. This document uses the following term defined in : LSP. This document uses the following term defined in and : ASLA. This document uses the following terms defined in : NAI and SR-DB The following terminologies are used in this document: Point-to-Multipoint. The FAD selected according to the rules described in . The base PCEP specification originally defined the use of the PCE architecture for MPLS and GMPLS networks with LSPs instantiated using the RSVP-TE signaling protocol. Over time, support for additional path setup types, such as SRv6, has been introduced . The term "LSP" is used extensively in PCEP specifications and, in the context of this document, refers to a Candidate Path within an SR Policy, which may be an SRv6 path (still represented using the LSP Object as specified in .

Existing PCEP specifications lack the mechanisms to explicitly signal and negotiate SR-Algorithm capabilities and constraints. This limits the ability of PCEs to make informed path computation decisions based on the specific SR-Algorithms supported and desired within the network. This document builds on the concepts introduced in to extend the applicability of Flexible Algorithms for SR-TE paths in PCEP. Flexible Algorithms allow the customization of routing behavior by defining link attributes specific to SR-Algorithms and also specifying constraints as part of FADs. The PCE leverages these FADs to compute paths that adhere to operator-defined criteria, such as minimizing delay or optimizing bandwidth utilization. In the context of SR-TE, the PCE must ensure that paths computed using Flexible Algorithms are congruent with the desired routing policies and constraints. This involves using the same ordered rules to select Flexible Algorithm Definitions (FADs) when multiple options are available and considering node participation in the specified SR-Algorithm during path computation. The PCE must also optimize paths based on metrics defined within the FAD, ensuring alignment with the operator's objectives. The introduction of new metric types, such as Path Min Delay Metric and Path Bandwidth Metric, further enhances the ability of PCE to compute paths that meet these criteria. The PCE and the headend router may independently compute SR-TE paths with different SR-Algorithms. This information needs to be exchanged between PCEP peers for purposes such as data collection and troubleshooting. In scenarios involving multiple (redundant) PCEs, when a headend receives a path from the primary PCE, it needs to be able to report the complete path information, including the SR-Algorithm, to a backup PCE. This is essential for high availability (HA) scenarios, ensuring that the backup PCE can correctly verify Prefix SIDs. The introduction of an SR-Algorithm TLV within the LSPA object allows operators to specify SR-Algorithm constraints directly, thereby refining path computations to meet specific needs, such as low-latency paths. The ability to specify an SR-Algorithm per SID in ERO and RRO is crucial for multiple reasons for example: SID types without algorithm specified - Certain SID types, such as Binding SIDs (BSIDs) , may not have an SR-algorithm specified. It may be inaccurate to state that an entire end-to-end path adheres to a specific algorithm if it includes a BSID from another policy. Topologies with two Interior Gateway Protocol (IGP) domains, each using the same FAD but with differing algorithm numbers.

The SR-PCE-CAPABILITY Sub-TLV is defined in to be included in the PATH-SETUP-TYPE-CAPABILITY TLV. This document defines the following flag in the SR-PCE-CAPABILITY Sub-TLV: SR-Algorithm Capability (S): If the S-flag is set, a PCEP speaker indicates support for the Algorithm field in the SR-ERO subobject described in and the SR-Algorithm TLV described in for LSPs setup using Path Setup Type 1 (Segment Routing) . It does not indicate support for these extensions for other Path Setup Types.

The SRv6-PCE-CAPABILITY sub-TLV is defined in to be included in the PATH-SETUP-TYPE-CAPABILITY TLV. This document defines the following flag in the SRv6-PCE-CAPABILITY sub-TLV: SR-Algorithm Capability (S): If the S-flag is set, a PCEP speaker indicates support for the Algorithm field in the SRv6-ERO Subobject described in and the SR-Algorithm TLV described in for LSPs setup using Path Setup Type 3 (SRv6) . It does not indicate support for these extensions for other Path Setup Types.

This document updates the SR-ERO subobject format defined in with Algorithm field and new flag "A" in Flags field as shown in .

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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Type=36 | Length | NT | Flags |A|F|S|C|M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // NAI (variable, optional) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Algorithm | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Flags: A-flag (SR-Algorithm Flag): If set to '1' by a PCEP speaker, the Algorithm field is included in the SR-ERO subobject as shown in and the length of the subobject is extended by 4 octets. If this flag is set to 0, then the Algorithm field is absent and processing described in applies. Algorithm (8 bits): SR-Algorithm value from registry "IGP Algorithm Types" of "Interior Gateway Protocol (IGP) Parameters" IANA registry. This document updates the SR-ERO subobject validation defined in by extending existing validation to include Algorithm field and A bit as follows. On receiving an SR-ERO, a PCC MUST validate that the Length field, S bit, F bit, A bit, NT field, and Algorithm are consistent, as follows.

• If A bit is 1
  • If NT=0, the F bit MUST be 1, the S bit MUST be zero, and the Length MUST be 12.
  • If NT=1, the F bit MUST be zero. If the S bit is 1, the Length MUST be 12; otherwise, the Length MUST be 16.
  • If NT=2, the F bit MUST be zero. If the S bit is 1, the Length MUST be 24; otherwise, the Length MUST be 28.
  • If NT=3, the F bit MUST be zero. If the S bit is 1, the Length MUST be 16; otherwise, the Length MUST be 20.
  • If NT=4, the F bit MUST be zero. If the S bit is 1, the Length MUST be 40; otherwise, the Length MUST be 44.
  • If NT=5, the F bit MUST be zero. If the S bit is 1, the Length MUST be 24; otherwise, the Length MUST be 28.
  • If NT=6, the F bit MUST be zero. If the S bit is 1, the Length MUST be 48; otherwise, the Length MUST be 52.
• If A bit is 0, consistency rules defined in applies.

This document updates the SRv6-ERO subobject format defined in with Algorithm field and new flag "A" in Flags field as shown in .

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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Type=40 | Length | NT | Flags |A|V|T|F|S| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Algorithm | Endpoint Behavior | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | SRv6 SID (optional) | | (128-bit) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // NAI (variable, optional) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID Structure (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Flags: A-flag (SR-Algorithm Flag): If set to '1' by a PCEP speaker, the Algorithm field is included in SRv6-ERO subobject as specified in . If this flag is set to 0, then the Algorithm field is absent and processing described in applies. Algorithm (8 bits): SR-Algorithm value from registry "IGP Algorithm Types" of "Interior Gateway Protocol (IGP) Parameters" IANA registry.

A new TLV for the LSPA Object is introduced to carry the SR-Algorithm constraint (). This TLV SHOULD only be used when PST (Path Setup type) = 1 or 3 for SR-MPLS and SRv6 respectively. Only the first instance of this TLV MUST be processed, subsequent instances MUST be ignored. The format of the SR-Algorithm TLV is as follows:

Type (16 bits): 66. Length (16 bits): 4. The 32-bit value is formatted as follows. MUST be set to zero by the sender and MUST be ignored by the receiver. This document defines the following flag bits. The other bits MUST be set to zero by the sender and MUST be ignored by the receiver. S (Strict): If set, the path computation at the PCE MUST fail if the specified SR-Algorithm constraint cannot be satisfied. If unset, the PCE SHOULD try to compute the path with SR-algorithm constraint specified. If the path computation using the specified SR-Algorithm constraint fails, the PCE SHOULD try to compute a path that does not satisfy the constraint. F (Flexible Algorithm Path Computation): If set, the PCE MUST perform path computation according to the Flexible Algorithm procedures outlined in . If unset, the PCE MUST adhere to the path computation procedures with SID filtering defined in . The flag MUST be ignored if the Algorithm field is set to a value in the range of 0 to 127. SR-Algorithm to be used during path computation.

The METRIC object is defined in . This document specifies new types for the METRIC object to enable the encoding of optimization metric types derived from the FAD during Flexible Algorithm path computation (see ). While these new metric types are defined to support this specific use case, and their application is not restricted to Flexible Algorithm path computation and may be utilized in other relevant scenarios. T=22: Path Min Delay metric () T=23: P2MP Path Min Delay metric () T=24: Path Bandwidth Metric () T=25: P2MP Path Bandwidth Metric () T=128-255: User-defined metric () The following terminology is used and expanded along the way. A network comprises of a set of N links {Li, (i=1...N)}. A path P of a point-to-point (P2P) LSP is a list of K links {Lpi,(i=1...K)}. A P2MP tree T comprises a set of M destinations {Dest_j,(j=1...M)}.

and define "Min/Max Unidirectional Link Delay Sub-TLV" to advertise the link minimum and maximum delay in microseconds in a 24-bit field. defines the METRIC object with a 32-bit metric value encoded in IEEE floating point format (see ). The encoding for the Path Min Delay metric value is quantified in units of microseconds and encoded in IEEE floating point format. The conversion from 24-bit integer to 32-bit IEEE floating point could introduce some loss of precision.

The minimum Link Delay metric is defined in and as "Min Unidirectional Link Delay". The Path Min Link Delay metric represents measured minimum link delay value over a configurable interval. The Path Min Delay metric type of the METRIC object in PCEP represents the sum of the Min Link Delay metric of all links along a P2P path. A Min Link Delay metric of link L is denoted D(L). A Path Min Delay metric for the P2P path P = Sum {D(Lpi), (i=1...K)}.

The P2MP Path Min Delay metric type of the METRIC object in PCEP encodes the Path Min Delay metric for the destination that observes the worst delay metric among all destinations of the P2MP tree. The P2P Path Min Delay metric of the path to destination Dest_j is denoted by PMDM(Dest_j). The P2MP Path Min Delay metric for the P2MP tree T = Maximum{PMDM(Dest_j), (j=1...M)}.

The defines a new metric type "Bandwidth Metric", which may be advertised in their link metric advertisements. When performing Flexible Algorithm path computation as described in , procedures described in sections 4.1 and 5 from MUST be followed with automatic metric calculation attempted. When performing path computation for other algorithms (0-127) and the Generic Metric sub-TLV with Bandwidth metric type is not advertised for a link, the PCE implementation MAY apply a local policy to derive a metric value (similar to the procedures in Sections 4.1.3 and 4.1.4 of or the link MAY be treated as if the metric value is unavailable (e.g. by using a default value). If the Bandwidth metric value is advertised for a link, the PCE MUST use the advertised value to compute the path metric in accordance with and . The Path Bandwidth metric value is encoded in IEEE floating point format. The conversion from 24-bit integer to 32-bit IEEE floating point could introduce some loss of precision.

The Path Bandwidth metric type of the METRIC object in PCEP represents the sum of the Bandwidth Metric of all links along a P2P path. Note: the link Bandwidth Metric utilized in the formula may be the original metric advertised on the link, which may have a value inversely proportional to the link capacity. A Bandwidth Metric of link L is denoted B(L). A Path Bandwidth metric for the P2P path P = Sum {B(Lpi), (i=1...K)}.

The Bandwidth metric type of the METRIC object in PCEP encodes the Path Bandwidth metric for the destination that observes the worst bandwidth metric among all destinations of the P2MP tree. The P2P Bandwidth metric of the path to destination Dest_j is denoted by BM(Dest_j). The P2MP Path Bandwidth metric for the P2MP tree T = Maximum{BM(Dest_j), (j=1...M)}.

The defined a new metric type range for "User defined metric", which may be advertised in their link metric advertisements. These are user defined and can be assigned by an operator for local use. User Defined metric values are encoded using the IEEE floating-point format. The conversion from 24-bit integer to 32-bit IEEE floating point could introduce some loss of precision. The proposed metric type range was chosen to allow mapping with values assigned in the "IGP Metric-Type Registry". For example, the User Defined metric type 130 of the METRIC object in PCEP can represent the sum of the User Defined Metric 130 of all links along a P2P. User Defined Metrics are equally applicable to P2P and P2MP paths.

The PCEP extensions defined in () of this document MUST NOT be used unless both PCEP speakers have indicated support by setting the S flag in the Path Setup Type Sub-TLV corresponding to the PST of the LSP. If this condition is not met, the receiving PCEP speaker MUST respond with a PCErr message with Error-Type 19 (Invalid Operation) and Error-Value TBD3 (Attempted use of SR-Algorithm without advertised capability). The SR-Algorithm used in this document refers to a complete range of SR-Algorithm values (0-255) if a specific section does not specify otherwise. Valid SR-Algorithm values are defined in the registry "IGP Algorithm Types" of "Interior Gateway Protocol (IGP) Parameters" IANA registry. Refer to and for the definition of SR-Algorithm in Segment Routing. and are describing the use of the SR-Algorithm in IGP. Note that some RFCs are referring to SR-Algorithm with different names, for example "Prefix-SID Algorithm" and "SR Algorithm".

If a PCC receives the Algorithm field in the ERO subobject within PCInitiate, PCUpd, or PCRep messages and the path received from those messages is being included in the ERO of PCRpt message, then the PCC MUST include the Algorithm field in the encoded subobjects with the received SR-Algorithm value. As per and , the format of the SR-RRO subobject is the same as that of the SR-ERO subobject, but without the L-Flag, therefore SR-RRO subobject may also carry the A flag and Algorithm field.

A PCEP speaker MAY set the A flag and include the Algorithm field in an SR-ERO subobject if the S flag has been advertised in SR-PCE-CAPABILITY Sub-TLV by both PCEP speakers. If the PCEP peer receives an SR-ERO subobject with the A flag set or with the SR-Algorithm included, but the S flag was not advertised in SR-PCE-CAPABILITY Sub-TLV, then it MUST consider the entire ERO as invalid as described in The Algorithm field in the SR-ERO subobject MUST be included after optional SID, NAI, or SID structure and length of SR-ERO subobject MUST be increased with additional 4 bytes for Reserved and Algorithm field. If the length and the A flag are not consistent as specified in , PCEP peer MUST consider the entire ERO invalid and MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = 11 ("Malformed object"). If the SID value is absent (S bit is set to 1), the NAI value is present (F bit is set to 0) and Algorithm field is set (A bit is set to 1), the PCC is responsible for choosing the SRv6-SID value based on values specified in NAI and Algorithm fields. If the PCC cannot find a SID index in the SR-DB, it MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = 14 ("Unknown SID").

A PCEP speaker MAY set the A flag and include the Algorithm field in an SRv6-ERO subobject if the S flag has been advertised in SRv6-PCE-CAPABILITY sub-TLV by both PCEP speakers. If the PCEP peer receives SRv6-ERO subobject with the A flag set or with the SR-Algorithm included, but the S flag was not advertised in SRv6-PCE-CAPABILITY Sub-TLV, then it MUST consider the entire ERO as invalid as described in The Algorithm field in the SRv6-ERO subobject MUST be included in the position specified in , the length of the SRv6-ERO subobject is not impacted by the inclusion of the Algorithm field. If the length and the A flag are not consistent as specified in , PCEP peer MUST consider the entire ERO invalid and MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = 11 ("Malformed object"). If the SRv6-SID value is absent (S bit is set to 1), the NAI value is present (F bit is set to 0) and Algorithm field is set (A bit is set to 1), the PCC is responsible for choosing the SRv6-SID value based on values specified in NAI and Algorithm fields. If the PCC cannot find a SID index in the SR-DB, it MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = 14 ("Unknown SID").

To signal a specific SR-Algorithm constraint to the PCE, the headend MUST encode the SR-Algorithm TLV inside the LSPA object. If PCC received an LSPA object with SR-Algorithm TLV as part of PCInitiate, PCUpd messages, then it MUST include LSPA object with SR-Algorithm TLV in PCRpt message as part of intended-attribute-list. If PCE received an LSPA object with SR-Algorithm TLV in PCRpt or PCReq, then it MUST include the LSPA object with SR-Algorithm TLV in PCUpd message, or PCRep message in case of an unsuccessful path computation based on rules described in . A PCEP peer that did not advertise the S flag in the Path Setup Type Sub-TLV corresponding to the LSP's PST MUST ignore the SR-Algorithm TLV on receipt. Path computation must occur on the topology associated with the specified SR-Algorithm. The PCE MUST NOT use Prefix SIDs of SR-Algorithm other than specified in SR-Algorithm constraint. It is allowed to use other SID types (e.g., Adjacency or BSID), but only from nodes participating in specified SR-Algorithm. Furthermore, the inclusion of a path BSID from another policy is allowed only if the path associated with such a policy fully satisfies all the constraints of the current path computation. This ensures that while leveraging BSIDs from different policies, requirements of the SR-Algorithm constraints are maintained. Specified SR-Algorithm constraint is applied to the end-to-end SR policy path. Using different SR-Algorithm constraint in each domain or part of the topology in single path computation is out of the scope of this document. One possible solution is to determine FAD mapping using PCE local policy. If the PCE is unable to find a path with the given SR-Algorithm constraint or it does not support a combination of specified constraints, it MUST use empty ERO in PCInitiate for LSP instantiation or PCUpd message if an update is required or NO-PATH object in PCRep to indicate that it was not able to find the valid path. If the headend is part of multiple IGP domains and the winning FAD for the specified SR-Algorithm has different constraints in each domain, the PCE implementation MAY have a local policy with a defined behavior for selecting a FAD for such path computation, or it may not support it at all. If such path computation is not supported, PCE MUST send a PCErr message with Error-Type = 29 (Path computation failure) and Error-value = TBD4 (Unsupported combination of constraints). If the NO-PATH object is included in PCRep, then PCE MAY include SR-Algorithm TLV to indicate constraint, which cannot be satisfied as described in section 7.5 of . SR-Algorithm does not replace the Objective Function defined in

This section is applicable only to the Flexible Algorithms range of SR-Algorithm values. The PCE must follow the IGP Flexible Algorithm path computation logic as described in . This includes using the same ordered rules to select a FAD if multiple FADs are available, considering the node participation of the specified SR-Algorithm during path computation, using ASLA-specific link attributes, and applying other rules for Flexible Algorithm path computation described in that document. The PCE must optimize the computed path based on the metric type specified in the FAD. The optimization metric type included in PCEP messages from the PCC MUST be ignored. The PCE SHOULD use the metric type from the FAD in messages sent to the PCC. If a corresponding metric type is not defined in PCEP, PCE SHOULD NOT include any METRIC object for the optimization metric. There are corresponding metric types in PCEP for IGP and TE metric from FAD introduced in , but there were no corresponding metric types defined for "Min Unidirectional Link Delay" from and "Bandwidth Metric", "User Defined Metric" from . of this document is introducing them. Note that the defined "Path Bandwidth Metric" is accumulative and is different from the Bandwidth Object defined in The PCE MUST use constraints specified in the FAD and also constraints (except optimization metric type) directly included in PCEP messages from PCC. The PCE implementation MAY decide to ignore specific constraints received from PCC based on existing processing rules for PCEP Objects and TLVs, e.g. P flag described in and processing rules described in . If the PCE does not support a specified combination of constraints, it MUST fail path computation and respond with a PCEP message with PCInitiate or PCUpd message with empty ERO or PCRep with NO-PATH object. PCC MUST NOT include constraints from FAD in PCEP message sent to PCE as it can result in undesired behavior in various cases. PCE SHOULD NOT include constraints from FAD in PCEP messages sent to PCC. The combinations of constraints specified in the FAD and constraints directly included in PCEP messages from PCC may decrease the chance that Flex-algo specific Prefix SIDs represent optimal path while satisfying all specified constraints, as a result a longer SID list may be required for the computed path. Adding more constraints on top of FAD requires complex path computation and may reduce the benefit of this scheme.

The SR-Algorithm constraint acts as a filter, restricting which SIDs may be used as a result of the path computation function. Path computation is done based on optimization metric type and constraints specified in the PCEP message received from PCC. If the specified SR-Algorithm is a Flexible Algorithm, the PCE must ensure that the IGP path of Flexible Algorithm SIDs is congruent with computed path.

In the example shown in , values next to links represent the IGP metric assigned to those links. It is assumed that the FAD for Flexible Algorithm 128 is advertised with only the metric type IGP and no constraints from the PCC node. The PCE computes the path for the SR-TE Policy configured on the PCC with the policy endpoint set to the prefix of R4 router and the optimization metric set to the IGP metric. All nodes depicted in the diagram are part of the same IGP domain. If all nodes in the diagram participate in Flexible Algorithm 128, the Flexible Algorithm SID for Algorithm 128 from node R4 can be used by the PCE. In this case, the computed path (PCC - R2 - R4) is congruent with the IGP path associated with the SID. However, if node R2 does not participate in Flexible Algorithm 128 while all other nodes do, the IGP path associated with the of Flexible Algorithm SID of node R4 will no longer be congruent with the computed path. In such scenarios, the PCE must ensure that the Flexible Algorithm SID is not used in the computed segment list.

All the rules of processing the METRIC object as explained in and are applicable to new metric types defined in this document.

All manageability requirements and considerations listed in , , , and apply to PCEP extensions defined in this document. In addition, the requirements and considerations listed in this section apply.

A PCE or PCC implementation SHOULD allow the capability of supporting PCEP extensions introduced in this document to be enabled or disabled as part of the global configuration.

An implementation SHOULD allow the operator to view the capability defined in this document. Sections 4.1 and 4.1.1 of should be extended to include the capabilities introduced in Sections 3.1.1 and 3.1.2 for PCEP peer.

An implementation SHOULD also allow the operator to view FADs, which MAY be used in Flexible Algorithm path computation defined in . An implementation SHOULD allow the operator to view nodes participating in the specified SR-Algorithm.

This document inherits considerations from documents describing IGP Flexible Algorithm - for example and .

This document inherits considerations from documents describing IGP Flexible Algorithm - for example and .

[Note to the RFC Editor - remove this section before publication, as well as remove the reference to RFC 7942.] This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in . The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. According to , "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".

Organization: Cisco Systems Implementation: IOS-XR PCC and PCE. Description: SR-MPLS part with experimental codepoints. Maturity Level: Production. Coverage: Partial. Contact: ssidor@cisco.com

Organization: Huawei Implementation: NE Series Routers Description: SR Policy with SR Algorithm. Maturity Level: Production. Coverage: Partial. Contact: pengshuping@huawei.com

The security considerations described in , , , , , and in itself. Note that this specification introduces the possibility of computing paths by PCE based on Flexible Algorithm related topology attributes and based on the metric type and constraints from FAD. This creates additional vulnerabilities, which are already described for the path computation done by IGP like those described in Security Considerations section of , but which are also applicable to path computation done by PCE. Hence, securing the PCEP session using Transport Layer Security (TLS) is RECOMMENDED.

IANA maintains a registry, named "SR Capability Flag Field", within the "Path Computation Element Protocol (PCEP) Numbers" registry group to manage the Flags field of the SR-PCE-CAPABILITY TLV. IANA is requested to confirm the following early allocation: Bit Description Reference 5SR-Algorithm CapabilityThis document

IANA maintains a registry, named "SRv6 PCE Capability Flags", within the "Path Computation Element Protocol (PCEP) Numbers" registry group to manage the Flags field of SRv6-PCE-CAPABILITY sub-TLV. IANA is requested to make the following assignment: Bit Description Reference TBD1SR-Algorithm CapabilityThis document

IANA maintains a registry, named "SR-ERO Flag Field", within the "Path Computation Element Protocol (PCEP) Numbers" registry group to manage the Flags field of the SR-ERO Subobject. IANA is requested to confirm the following early allocation: Bit Description Reference 7SR-Algorithm Flag (A)This document

IANA maintains a registry, named "SRv6-ERO Flag Field", within the "Path Computation Element Protocol (PCEP) Numbers" registry group to manage the Flags field of the SRv6-ERO subobject. IANA is requested to make the following assignment: Bit Description Reference TBD2SR-Algorithm Flag (A)This document

IANA maintains a registry, named "PCEP TLV Type Indicators", within the "Path Computation Element Protocol (PCEP) Numbers" registry group. IANA is requested to confirm the early allocation of a new TLV type for the new LSPA TLV specified in this document. Type Description Reference 66SR-AlgorithmThis document

IANA maintains a registry for "METRIC Object T Field" within the "Path Computation Element Protocol (PCEP) Numbers" registry group. IANA is requested to confirm the early allocated codepoints as follows: Type Description Reference 22Path Min Delay MetricThis document 23P2MP Path Min Delay MetricThis document 24Path Bandwidth MetricThis document 25P2MP Path Bandwidth MetricThis document 128-255User Defined Metric This document

IANA is requested to allocate new error types and error values within the "PCEP-ERROR Object Error Types and Values" sub-registry of the PCEP Numbers registry for the following errors. Error-Type Meaning Error-Value 19Invalid OperationTBD3:Attempted use of SR-Algorithm without advertised capability 29Path computation failureTBD4:Unsupported combination of constraints

IEEE

Would like to thank Adrian Farrel, Aijun Wang, Boris Khasanov, Dhruv Dhody, Jie Dong, Marina Fizgeer, Nagendra Nainar, Rakesh Gandhi, Russ White for review and suggestions.

Mike Koldychev Ciena Corporation Email: mkoldych@proton.me Zafar Ali Cisco Systems, Inc. Email: zali@cisco.com Stephane Litkowski Cisco Systems, Inc. Email: slitkows.ietf@gmail.com Siva Sivabalan Ciena Email: msiva282@gmail.com Tarek Saad Cisco Systems, Inc. Email: tsaad.net@gmail.com Mahendra Singh Negi RtBrick Inc Email: mahend.ietf@gmail.com Tom Petch Email: ietfc@btconnect.com