Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing (SR) Policy Candidate Paths

3.1. SR Policy Identifier

SR Policy Identifier uniquely identifies the SR Policy [RFC9256] within the network. SR Policy Identifier MUST be the same for all SR Policy Candidate Paths in the same SRPA. SR Policy Identifier MUST NOT change for a given SR Policy Candidate Path during its lifetime. SR Policy Identifier MUST be different for different SRPAs. When these rules are not satisfied, the PCEP speaker MUST send a PCErr message with Error-Type = 26 "Association Error", Error Value = 20 "SR Policy Identifier Mismatch". SR Policy Identifier consist of:¶

• Headend router where the SR Policy originates.¶

• Color of SR Policy.¶

• Endpoint of SR Policy.¶

3.2. SR Policy Candidate Path Identifier

SR Policy Candidate Path Identifier uniquely identifies the SR Policy Candidate Path within the context of an SR Policy. SR Policy Candidate Path Identifier MUST NOT change for a given LSP during its lifetime. SR Policy Candidate Path Identifier MUST be different for distinct Candidate Paths within the same SRPA. When these rules are not satisfied, the PCEP speaker MUST send a PCErr message with Error-Type = 26 "Association Error", Error Value = 21 "SR Policy Candidate Path Identifier Mismatch". SR Policy Candidate Path Identifier consist of:¶

• Protocol Origin.¶

• Originator.¶

• Discriminator.¶

3.3. SR Policy Candidate Path Attributes

SR Policy Candidate Path Attributes carry non-key information about the Candidate Path and MAY change during the lifetime of the LSP. SR Policy Candidate Path Attributes consist of:¶

• Preference.¶

• Optionally, the SR Policy Candidate Path name.¶

• Optionally, the SR Policy name.¶

4.1. Association Parameters

As per [RFC9256], an SR Policy is identified through the tuple <headend, color, endpoint>. The headend is encoded in the 'Association Source' field in the ASSOCIATION object and the color and endpoint are encoded as part of the Extended Association ID TLV.¶

The Association Parameters (see Section 2) consist of:¶

• Association Type: set to 6 "SR Policy Association".¶

• Association Source (IPv4/IPv6): set to the headend IP address.¶

• Association ID (16-bit): set to "1" (this 16-bit field is not utilized, just set to a fixed value).¶

• Extended Association ID TLV: encodes the Color and Endpoint of the SR Policy.¶

The Association Source MUST be set to the headend value of the SR Policy, as defined in [RFC9256] Section 2.1.¶

The 16-bit Association ID field in the ASSOCIATION object MUST be set to the value of "1".¶

The Extended Association ID TLV MUST be included and it MUST be in the following format:¶

   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 = 31           |       Length = 8 or 20        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                             Color                             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  ~                           Endpoint                            ~
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type: Extended Association ID TLV, type = 31 [RFC8697].¶

Length: Either 8 or 20, depending on whether IPv4 or IPv6 address is encoded in the Endpoint field.¶

Color: SR Policy color value, non-zero as per [RFC9256] Section 2.1.¶

Endpoint: can be either IPv4 or IPv6. This value MAY be different from the one contained in the Destination address field in the END-POINTS object, or in the Tunnel Endpoint Address field in the LSP-IDENTIFIERS TLV.¶

If the PCEP speaker receives an SRPA object whose Association Parameters do not follow the above specification, then the PCEP speaker MUST send PCErr message with Error-Type = 26 "Association Error", Error-Value = 20 "SR Policy Identifier Mismatch".¶

The purpose of choosing the Association Parameters in this way is to guarantee that there is no possibility of a race condition when multiple PCEP speakers want to associate the same SR Policy at the same time. By adhering to this format, all PCEP speakers come up with the same Association Parameters independently of each other based on the SR Policy [RFC9256] parameters. Thus, there is no chance that different PCEP speakers will come up with different Association Parameters for the same SR Policy.¶

The last hop of the computed SR Policy Candidate Path MAY differ from the Endpoint contained in the <headend, color, endpoint> tuple. An example use case is to terminate the SR Policy before reaching the Endpoint and have decapsulated traffic go the rest of the way to the Endpoint node using the native IGP path(s). In this example, the destination of the SR Policy Candidate Paths will be some node before the Endpoint, but the Endpoint value is still used at the head-end to steer traffic with that Endpoint IP into the SR Policy. Destination of the SR Policy Candidate Path is signaled using the END-POINTS object and/or LSP-IDENTIFIERS TLV, as per the usual PCEP procedures. When neither END-POINTS object nor LSP-IDENTIFIERS TLV is present, the PCEP speaker MUST extract the destination from the Endpoint field in the SRPA Extended Association ID TLV.¶

4.2. Association Information

The SRPA object may carry the following TLVs:¶

• SRPOLICY-POL-NAME TLV: (optional) encodes SR Policy Name string.¶

• SRPOLICY-CPATH-ID TLV: (mandatory) encodes SR Policy Candidate Path Identifier.¶

• SRPOLICY-CPATH-NAME TLV: (optional) encodes SR Policy Candidate Path string name.¶

• SRPOLICY-CPATH-PREFERENCE TLV: (optional) encodes SR Policy Candidate Path preference value.¶

Out of these TLVs, the SRPOLICY-CPATH-ID TLV is mandatory, all others are optional. When a mandatory TLV is missing from the SRPA object, the PCEP speaker MUST send a PCErr message with Error-Type = 6 "Mandatory Object Missing", Error-Value = 21 "Missing SR Policy Mandatory TLV".¶

This document specifies four new TLVs to be carried in the SRPA object. Only one TLV instance of each type can be carried, and only the first occurrence is processed. Any others MUST 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            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  ~                       SR Policy Name                          ~
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Proto. Origin |                      MBZ                      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                         Originator ASN                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  |                       Originator Address                      |
  |                                                               |
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                         Discriminator                         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  ~                 SR Policy Candidate Path Name                 ~
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                           Preference                          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.1. SR Policy Capability TLV

The SRPOLICY-CAPABILITY TLV is an optional TLV for the OPEN object. It is used at session establishment time to learn the other PCEP peer's capabilities with respect to SR Policy.¶

   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                   |L|S|I|E|P|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type: 71 for "SRPOLICY-CAPABILITY TLV.¶

Length: 4.¶

P-flag: If set to '1' by a PCEP speaker, the P flag indicates that the PCEP speaker supports the handling of COMPUTATION-PRIORITY TLV for the SR Policy, see Section 5.2. If this flag is not set, then the PCEP speaker MUST NOT send the COMPUTATION-PRIORITY TLV and SHOULD ignore it on receipt.¶

E-Flag: If set to '1' by a PCEP speaker, the E flag indicates that the PCEP speaker supports the handling of ENLP TLV for the SR Policy, see Section 5.3. If this flag is not set, then the PCEP speaker MUST NOT send the ENLP TLV and SHOULD ignore it on receipt.¶

I-Flag: If set to '1' by a PCEP speaker, the I flag indicates that the PCEP speaker supports the handling of INVALIDATION TLV for the SR Policy, see Section 5.4. If this flag is not set, then the PCEP speaker MUST NOT send the INVALIDATION TLV and SHOULD ignore it on receipt.¶

S-Flag: If set to '1' by a PCEP speaker, the S flag indicates that the PCEP speaker supports the handling of "Specified-BSID-only" behavior for the SR Policy, see Section 5.5. If this flag is not set, then the PCEP speaker MUST NOT set the Specified-BSID-only flag in the TE-PATH-BINDING TLV and SHOULD ignore it on receipt.¶

L-Flag: If set to '1' by a PCEP speaker, the L flag indicates that the PCEP speaker supports the stateless (PCReq/PCRep) operations for the SR Policy, see Section 5.6. If the PCE did not set this flag then the PCC SHOULD NOT send PCReq messages to this PCE for the SR Policy.¶

Unassigned bits MUST be set to '0' on transmission and MUST be ignored on receipt.¶

5.2. Computation Priority TLV

The COMPUTATION-PRIORITY TLV is an optional TLV for the LSP object. It is used to signal the numerical computation priority, as specified in Section 2.12 of [RFC9256]. If the TLV is absent from the LSP object, a default Priority value of 128 is used.¶

   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            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |    Priority    |                     MBZ                      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type: 68 for "COMPUTATION-PRIORITY" TLV.¶

Length: 4.¶

Priority: Numerical priority with which this LSP is to be recomputed by the PCE upon topology change.¶

5.3. Explicit Null Label Policy (ENLP) TLV

To steer an unlabeled IP packet into an SR policy, it is necessary to create a label stack for that packet, and push one or more labels onto that stack. The Explicit NULL Label Policy (ENLP) TLV is an optional TLV used to indicate whether an Explicit NULL Label [RFC3032] must be pushed on an unlabeled IP packet before any other labels. The contents of this TLV are used by the SRPM as described in section 4.1 of [RFC9256]. If an ENLP TLV is not present, the decision of whether to push an Explicit NULL label on a given packet is a matter of local configuration. Note that Explicit Null is currently only defined for SR MPLS and not for SRv6. Therefore the PCEP speaker SHOULD ignore the presence of this TLV for SRv6 Policies.¶

   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            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |    ENLP        |                     MBZ                      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type: 69 for "ENLP" TLV.¶

Length: 4.¶

ENLP (Explicit NULL Label Policy): Indicates whether Explicit NULL labels are to be pushed on unlabeled IP packets that are being steered into a given SR policy. The values of this field are specified in section Section 6.6.¶

The ENLP reserved values may be used for future extensions and implementations SHOULD ignore the ENLP TLV with these values. The behavior signaled in this TLV MAY be overridden by local configuration. The section 4.1 of [RFC9256] describes the behavior on the headend for the handling of the explicit null label.¶

5.4. Invalidation TLV

The INVALIDATION TLV is an optional TLV for the LSP object. It is used to control traffic steering into the LSP during the time when the LSP is operationally down/invalid. In the context of SR Policy, this TLV facilitates the Drop-upon-invalid behavior, specified in Section 8.2 of [RFC9256]. Normally, if the LSP is down/invalid then it stops attracting traffic and traffic that would have been destined to that LSP is redirected somewhere else, such as via IGP or via another LSP. The Drop-upon-invalid behavior specifies that the LSP keeps attracting traffic and the traffic has to be dropped at the head-end. Such an LSP is said to be "in drop state". While in the drop state, the LSP operational state is "UP", as indicated by the O-flag in the LSP object. However the ERO object MAY be empty, if no valid path has been computed.¶

The INVALIDATION TLV is used in both directions between PCEP peers:¶

• PCE -> PCC: PCE specifies to the PCC whether to enable or disable Drop-upon-invalid (Config).¶

• PCC -> PCE: PCC reports the current setting of the Drop-upon-invalid (Config) and also whether the LSP is currently in the drop state (Oper).¶

   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            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   Oper        |   Config      |              MBZ              |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type: 70 for "INVALIDATION" TLV.¶

Length: 4.¶

Oper: encodes the current state of the LSP, i.e., whether it is actively dropping traffic right now. This field can be set to non-zero values only by the PCC, it MUST be set to 0 by the PCE and SHOULD be ignored by the PCC.¶

   0 1 2 3 4 5 6 7
  +-+-+-+-+-+-+-+-+
  |             |D|
  +-+-+-+-+-+-+-+-+

• D: dropping - the LSP is currently attracting traffic and actively dropping it.¶

• The unassigned bits in the Flag octet MUST be set to zero upon transmission and MUST be ignored upon receipt.¶

Config: encodes the current setting of the Drop-upon-invalid feature.¶

   0 1 2 3 4 5 6 7
  +-+-+-+-+-+-+-+-+
  |             |D|
  +-+-+-+-+-+-+-+-+

• D: drop enabled - the Candidate Path has Drop-upon-invalid feature enabled.¶

• The unassigned bits in the Flag octet MUST be set to zero upon transmission and MUST be ignored upon receipt.¶

5.5. Specified-BSID-only

Specified-BSID-only functionality is defined in Section 6.2.3 of [RFC9256]. When specified-BSID-only is enabled for a particular binding SID, it means that the given binding SID is required to be allocated and programmed for the LSP to be operationally up. If the binding SID cannot be allocated or programmed for some reason, then the LSP must stay down.¶

To signal specified-BSID-only, a new bit: S (Specified-BSID-only) is allocated in the "TE-PATH-BINDING TLV Flag field" of the TE-PATH-BINDING TLV [I-D.ietf-pce-binding-label-sid]. When this bit is set for a particular BSID, it means that the BSID follows the Specified-BSID-only behavior. It is possible to have a mix of BSIDs for the same LSP: some with S=1 and some with S=0.¶

5.6. Stateless Operation

[RFC8231] Section 5.8.2, allows delegation of an LSP in operationally down state, but at the same time mandates the use of PCReq before sending PCRpt. This document updates [RFC8231] Section 5.8.2, by making this section not applicable to SR Policy LSPs. Thus, when a PCC wants to delegate an SR Policy LSP, it MAY proceed directly to sending PCRpt, without first sending PCReq and waiting for PCRep. This has the advantage of reducing the number of PCEP messages and simplifying the implementation.¶

Furthermore, a PCEP speaker is not required to support PCReq/PCRep at all for SR Policies. The PCEP speaker can indicate support for PCReq/PCRep via the "L-Flag" in the SRPOLICY-CAPABILITY TLV (See Section 5.1). When this flag is cleared, or when the SRPOLICY-CAPABILITY TLV is absent, the given peer SHOULD NOT be sent PCReq/PCRep messages for SR Policy LSPs. Conversely when this flag is set, the peer can receive and process PCReq/PCRep messages for SR Policy LSPs.¶

The above applies only to SR Policy LSPs and does not affect other LSP types, such as RSVP-TE LSPs. For other LSP types, [RFC8231] Section 5.8.2 continues to apply.¶