Internet-Draft | PCEP extension to support CPs validity | June 2025 |
Chen, et al. | Expires 7 December 2025 | [Page] |
This document defines PCEP extensions for signaling the validity control parameters of a candidate path for an SR Policy.¶
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 7 December 2025.¶
Copyright (c) 2025 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
SR Policy architecture is specified in [RFC9256]. An SR Policy comprises one or more candidate paths (CP) of which at a given time one and only one may be active (i.e., installed in forwarding and usable for steering of traffic). Each CP in turn may have one or more SID-List of which one or more may be active; when multiple SID-List are active then traffic is load balanced over them.¶
[I-D.chen-spring-sr-policy-cp-validity] supplemented candidate path validity criterion in [RFC9256]. It defines two validity control parameters under candidate Path to control the validity judgment of candidate Path.¶
PCEP Extensions for Segment Routing [RFC8664] specifies extensions that allow PCEP to work with basic SR-TE paths.¶
PCEP extension to support Segment Routing Policy Candidate Paths [I-D.ietf-pce-segment-routing-policy-cp] specifies extensions that allow PCEP to signal additional attributes of an SR Policy, which are not covered by [RFC8664]. SR Policy is modeled in PCEP as an Association and the SR Candidate Paths are the members of that Association. Thus the PCE can take computation and control decisions about the Candidate Paths, with the additional knowledge that these Candidate Paths belong to the same SR Policy.¶
This document defines PCEP extensions for signaling the validity control parameters of a candidate path for an SR Policy.¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
As defined in [RFC8697] , TE LSPs are associated by adding them to a common association group by a PCEP peer. [I-D.ietf-pce-segment-routing-policy-cp]defines SR Policy Association (SRPA), and the SR Candidate Paths are the members of this Association. We define the CP validity TLV in the SR Policy Association (SRPA) object to signal the validity control parameters of a candidate path.¶
The format of the CP Validity TLV is defined as follows:¶
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | valid SL count| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | valid SL weight | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1. CP Validity TLV¶
where:¶
Type: to be assigned by IANA.¶
Length: the total length of the value field not including Type and Length fields. The total length must be 8.¶
valid SL count: 1-octet field which indicates the minimum number of valid segment Lists under the active candidate path. When the number of valid segment Lists under candidate path is greater than or equal to this field, the candidate path is considered valid. 0 indicates no requirement for SL count. 0xff indicates that the candidate path is considered valid only if all the segment Lists are valid.¶
valid SL weight: 4-octet field which indicates the minimum value of the sum of the weights of the valid segment List under the active candidate Path. When the sum of the weights of the valid segment Lists under the candidate path is greater than or equal to this field, the candidate Path is considered valid. 0 indicates no requirement for weight.0xffffffff indicates that the candidate path is considered valid only if all the segment Lists are valid.¶
Unless specifically stated otherwise, the CP Validity TLV is assumed to be single instance. Meaning, only one instance of the TLV SHOULD be present in the object and only the first instance of the TLV SHOULD be interpreted and subsequent instances SHOULD be ignored.¶
As per [RFC8697], the ASSOCIATION object MAY be carried in the PCUpd, PCRpt, and Path Computation Initiate (PCInitiate) messages. The CP Validity TLV is carried in a SR Policy Association (SRPA) object and MAY also be carried in the PCUpd, PCRpt, and Path Computation Initiate (PCInitiate) messages.¶
When carried in a PCRpt message, this object is used to report the validity control parameters of a candidate path for a SR Policy.¶
When an LSP is delegated to a stateful PCE, the stateful PCE can create the validity control parameters of a candidate path for a SR Policy. This is done by including the CP Validity TLV in a PCUpd message.¶
A PCE initiating a new SR policy can also include the validity control parameters of a candidate path for this policy. This is done by including the CP Validity TLV in a PCInitiate message.¶
This document defines the new TLV for carrying additional information about SR Policy and SR Candidate Paths. IANA is requested to make the assignment of a new value for the existing "PCEP TLV Type Indicators" registry as follows:¶
Value Description Reference ------- ------------------------- -------------- TBD CP Validity TLV This document¶
Procedures and protocol extensions defined in this document do not affect the security considerations discussed in [I-D.ietf-pce-segment-routing-policy-cp].¶
TBD.¶