Carrying SR-Algorithm in Path Computation Element Communication Protocol (PCEP).

4.1.1. SR PCE Capability Sub-TLV

The SR-PCE-CAPABILITY Sub-TLV is defined in Section 4.1.2 of [RFC8664] 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 Section 4.2 and the SR-Algorithm TLV described in Section 4.4 for LSPs setup using Path Setup Type 1 (Segment Routing) [RFC8664]. It does not indicate support for these extensions for other Path Setup Types.¶

4.1.2. SRv6 PCE Capability sub-TLV

The SRv6-PCE-CAPABILITY sub-TLV is defined in Section 4.1.1 of [RFC9603] 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 Section 4.3 and the SR-Algorithm TLV described in Section 4.4 for LSPs setup using Path Setup Type 3 (SRv6) [RFC9603]. It does not indicate support for these extensions for other Path Setup Types.¶

4.5.1. Path Min Delay Metric value

[RFC7471] and [RFC8570] define "Min/Max Unidirectional Link Delay Sub-TLV" to advertise the link minimum and maximum delay in microseconds in a 24-bit field.¶

[RFC5440] defines the METRIC object with a 32-bit metric value encoded in IEEE floating point format (see [IEEE.754.1985]).¶

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.¶

4.5.2. Path Min Delay Metric

The minimum Link Delay metric is defined in [RFC7471] and [RFC8570] 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)}.¶

4.5.3. P2MP Path Min Delay Metric

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)}.¶

4.5.4. Path Bandwidth Metric value

The Section 4 of [I-D.ietf-lsr-flex-algo-bw-con] 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 Section 5.2.1, procedures described in sections 4.1 and 5 from [I-D.ietf-lsr-flex-algo-bw-con] 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 [I-D.ietf-lsr-flex-algo-bw-con] 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 Section 4.5.6 and Section 4.5.6.¶

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.¶

4.5.5. Path Bandwidth Metric

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)}.¶

4.5.6. P2MP Path Bandwidth Metric

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)}.¶

4.5.7. User Defined Metric

The Section 2 of [I-D.ietf-lsr-flex-algo-bw-con] 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.¶

5.1.1. SR-ERO

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 Section 5.2.1 of [RFC8664]¶

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 Section 4.2, 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").¶

5.1.2. SRv6-ERO

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 Section 5.2.1 of [RFC8664]¶

The Algorithm field in the SRv6-ERO subobject MUST be included in the position specified in Section 4.3, 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 Section 4.3, 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").¶

5.2.1. Flexible Algorithm Path Computation

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 [RFC9350]. 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 [RFC9350], but there were no corresponding metric types defined for "Min Unidirectional Link Delay" from [RFC9350] and "Bandwidth Metric", "User Defined Metric" from [I-D.ietf-lsr-flex-algo-bw-con]. Section 4.5 of this document is introducing them. Note that the defined "Path Bandwidth Metric" is accumulative and is different from the Bandwidth Object defined in [RFC5440]¶

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 Section 7.2 of [RFC5440] and processing rules described in [I-D.ietf-pce-stateful-pce-optional]. 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.¶

5.2.2. Path computation with SID Filtering

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.¶

          +----------+    +----------+
          |   PCC    | -- |   PCE    |
          +----------+    +----------+
             /    \
         10 /      \ 20
           /        \
   +---------+    +---------+
   |   R2    |    |   R3    |
   +---------+    +---------+
          \         /
        10 \       / 10
            \     /
          +----------+
          |    R4    |
          +----------+

In the example shown in Figure 4, 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.¶

5.2.3. New Metric types

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