| Internet-Draft | PCEP-SRv6 | June 2023 |
| Li, et al. | Expires 30 December 2023 | [Page] |
Segment Routing (SR) can be used to steer packets through an IPv6 or MPLS network using the source routing paradigm. SR enables any head-end node to select any path without relying on a hop-by-hop signaling technique (e.g., LDP or RSVP-TE).¶
A Segment Routed Path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), explicit configuration, or a PCE.¶
Since SR can be applied to both MPLS and IPv6 forwarding planes, a PCE should be able to compute SR-Path for both MPLS and IPv6 forwarding planes. The PCEP extension and mechanisms to support SR-MPLS have been defined. This document describes the extensions required for SR support for IPv6 data plane in the Path Computation Element communication Protocol(PCEP).¶
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 30 December 2023.¶
Copyright (c) 2023 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.¶
As defined in [RFC8402], Segment Routing (SR) architecture allows the source node to steer a packet through a path indicated by an ordered list of instructions, called segments. A segment can represent any instruction, topological or service-based, and it can have a semantic local to an SR node or global within an SR domain.¶
When the SR architecture is applied to the MPLS forwarding plane, it is called SR-MPLS. When the SR architecture is applied to the IPv6 data plane, is is called SRv6 (Segment Routing over IPv6 data plane) [RFC8754].¶
An SR path can be derived from an IGP Shortest Path Tree(SPT), but SR-TE(Segment Routing Traffic Engineering) paths may not follow IGP SPT. Such paths may be chosen by a suitable network planning tool, or a PCE and provisioned on the ingress node.¶
[RFC5440] describes 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. A PCE or a PCC operating as a PCE (in hierarchical PCE environment) computes paths for MPLS Traffic Engineering LSPs (MPLS-TE LSPs) based on various constraints and optimization criteria.¶
[RFC8231] specifies extensions to PCEP that allow a stateful PCE to compute and recommend network paths in compliance with [RFC4657] and defines objects and TLVs for MPLS-TE LSPs. Stateful PCEP extensions provide synchronization of LSP state between a PCC and a PCE or between a pair of PCEs, delegation of LSP control, reporting of LSP state from a PCC to a PCE, controlling the setup and path routing of an LSP from a PCE to a PCC. Stateful PCEP extensions are intended for an operational model in which LSPs are configured on the PCC, and control over them is delegated to the PCE.¶
A mechanism to dynamically initiate LSPs on a PCC based on the requests from a stateful PCE or a controller using stateful PCE is specified in [RFC8281]. As per [RFC8664], it is possible to use a stateful PCE for computing one or more SR-TE paths taking into account various constraints and objective functions. Once a path is chosen, the stateful PCE can initiate an SR-TE path on a PCC using PCEP extensions specified in [RFC8281] using the SR specific PCEP extensions specified in [RFC8664]. [RFC8664] specifies PCEP extensions for supporting a SR-TE LSP for the MPLS data plane. This document extends [RFC8664] to support SR for the IPv6 data plane. Additionally, using procedures described in this document, a PCC can request an SRv6 path from either a stateful or stateless PCE. This specification relies on the PATH-SETUP-TYPE TLV and procedures specified in [RFC8408].¶
This specification provides a mechanism for a network controller (acting as a PCE) to instantiate candidate paths for an SR Policy onto a head-end node (acting as a PCC) using PCEP. For more information on the SR Policy Architecture, see [RFC9256] which is 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This document uses the following terms defined in [RFC5440]: PCC, PCE, PCEP, PCEP Peer.¶
This document uses the following terms defined in [RFC8051]: Stateful PCE, Delegation.¶
The message formats in this document are specified using Routing Backus-Naur Format (RBNF) encoding as specified in [RFC5511].¶
Further, following terms are used in the document,¶
Maximum SID Depth.¶
Path Setup Type.¶
Segment Routing.¶
Segment Identifier.¶
Segment Routing for IPv6 forwarding plane.¶
IPv6 Segment Routing Header.¶
IPv6 Segment List (List of IPv6 SIDs representing a path in IPv6 SR domain in the context of this document)¶
Further, note that the term LSP used in the PCEP specifications, would be equivalent to an SRv6 Path (represented as a list of SRv6 segments) in the context of supporting SRv6 in PCEP.¶
Basic operations for PCEP speakers are as per [RFC8664]. SRv6 Paths computed by a PCE can be represented as an ordered list of SRv6 segments of 128-bit value.¶
[RFC8664] defined a new Explicit Route Object (ERO) subobject denoted by "SR-ERO subobject" capable of carrying a SID as well as the identity of the node/adjacency represented by the SID for SR-MPLS. SR-capable PCEP speakers can generate and/or process such an ERO subobject. An ERO containing SR-ERO subobjects can be included in the PCEP Path Computation Reply (PCRep) message defined in [RFC5440], the PCEP LSP Initiate Request message (PCInitiate) defined in [RFC8281], as well as in the PCEP LSP Update Request (PCUpd) and PCEP LSP State Report (PCRpt) messages defined in [RFC8231]. [RFC8664] also defines a new Reported Route Object(RRO) called SR-RRO to represents the SID list that was applied by the PCC, that is, the actual path taken by the LSP in SR-MPLS network.¶
This document defines new subobjects "SRv6-ERO" and "SRv6-RRO" in the ERO and the RRO respectively to carry the SRv6 SID (IPv6 Address). SRv6-capable PCEP speakers MUST be able to generate and/or process these subobjects.¶
When a PCEP session between a PCC and a PCE is established, both PCEP speakers exchange their capabilities to indicate their ability to support SRv6 specific functionality as described in Section 4.1.1.¶
In summary, this document,¶
In SR networks, an SR source node encodes all packets being steered onto an SR path with a list of segments. The segment list has all necessary information to guide the packets from the ingress node to the egress node of the path, and hence there is no need for any signaling protocol.¶
For the use of an IPv6 control plane but an MPLS data plane, mechanism remains the same as specified in [RFC8664].¶
This document describes the extension to support SRv6 in PCEP. A PCC or PCE indicates its ability to support SRv6 during the PCEP session Initialization Phase via a new SRv6-PCE-CAPABILITY sub-TLV (see details in Section 4.1.1).¶
As defined in [RFC5440], a PCEP message consists of a common header followed by a variable length body made up of mandatory and/or optional objects. This document does not require any changes in the format of PCReq and PCRep messages specified in [RFC5440], PCInitiate message specified in [RFC8281], and PCRpt and PCUpd messages specified in [RFC8231]. However, PCEP messages pertaining to SRv6 MUST include PATH-SETUP-TYPE TLV in the RP or SRP object to clearly identify that SRv6 is intended.¶
This document defines a new Path Setup Type (PST) [RFC8408] for SRv6, as follows.¶
A PCEP speaker indicates its support of the function described in this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the OPEN object with this new PST "3" included in the PST list.¶
This document also defines the SRv6-PCE-CAPABILITY sub-TLV. PCEP speakers use this sub-TLV to exchange information about their SRv6 capability. If a PCEP speaker includes PST=3 in the PST List of the PATH-SETUP-TYPE-CAPABILITY TLV then it MUST also include the SRv6-PCE-CAPABILITY sub-TLV inside the PATH-SETUP-TYPE-CAPABILITY TLV. For further error handling, please see Section 5.¶
The format of the SRv6-PCE-CAPABILITY sub-TLV is shown in the following figure.¶
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=27 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Flags |N|X| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MSD-Type | MSD-Value | MSD-Type | MSD-Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // ... // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MSD-Type | MSD-Value | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The code point for the TLV type is 27 and the format is compliant with the PCEP TLV format defined in [RFC5440]. That is, the sub-TLV is composed of 2 octets for the type, 2 octets specifying the length, and a Value field. The Type field when set to 27 identifies the SRv6-PCE-CAPABILITY sub-TLV and the presence of the sub-TLV indicates the support for the SRv6 paths in PCEP. The Length field defines the length of the value portion in octets. The TLV is padded to 4-octet alignment, and padding is not included in the Length field. The number of (MSD-Type,MSD-Value) pairs can be determined from the Length field of the TLV.¶
The value comprises of -¶
Reserved: 2 octet, this field MUST be set to 0 on transmission, and ignored on receipt.¶
Flags: 2 octet, two bits are currently assigned in this document. Section 9.5¶
This document defines a new Path Setup Type (PST=3) for SRv6. In order to indicate that the path is for SRv6, any RP or SRP object MUST include the PATH-SETUP-TYPE TLV as specified in [RFC8408], where PST is set to 3.¶
In order to support SRv6, a new "SRv6-ERO" subobject is defined for inclusion in the ERO.¶
An SRv6-ERO subobject is formatted as shown in the following figure.¶
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 |V|T|F|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Endpoint Behavior |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SRv6 SID (optional) |
| (128-bit) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// NAI (variable, optional) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SID Structure (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields in the SRv6-ERO subobject are as follows:¶
The 'L' Flag: Indicates whether the subobject represents a loose-hop (see [RFC3209]). If this flag is set to zero, a PCC MUST NOT overwrite the SID value present in the SRv6-ERO subobject. Otherwise, a PCC MAY expand or replace one or more SID values in the received SRv6-ERO based on its local policy.¶
Type: indicates the content of the subobject, i.e. when the field is set to 40, the suboject is an SRv6-ERO subobject representing an SRv6 SID.¶
Length: Contains the total length of the subobject in octets. The Length MUST be at least 24, and MUST be a multiple of 4. An SRv6-ERO subobject MUST contain at least one of an SRv6-SID or an NAI. The S and F bit in the Flags field indicates whether the SRv6-SID or NAI fields are absent.¶
NAI Type (NT): Indicates the type and format of the NAI contained in the object body, if any is present. If the F bit is set to one (see below) then the NT field has no meaning and MUST be ignored by the receiver. This document reuses NT types defined in [RFC8664], but assigns them new meanings appropriate to SRv6.¶
If NT value is 0, the NAI MUST NOT be included.¶
When NT value is 2, the NAI is as per the 'IPv6 Node ID' format defined in [RFC8664], which specifies an IPv6 address. This is used to identify the owner of the SRv6 Identifier. This is optional, as the LOC (the locator portion) of the SRv6 SID serves a similar purpose (when present).¶
When NT value is 4, the NAI is as per the 'IPv6 Adjacency' format defined in [RFC8664], which specify a pair of IPv6 addresses. This is used to identify the IPv6 Adjacency and used with the SRv6 Adj-SID.¶
When NT value is 6, the NAI is as per the 'link-local IPv6 addresses' format defined in [RFC8664], which specify a pair of (global IPv6 address, interface ID) tuples. It is used to identify the IPv6 Adjacency and used with the SRv6 Adj-SID.¶
SR-MPLS specific NT types are not valid in SRv6-ERO.¶
Flags: Used to carry additional information pertaining to the SRv6-SID. 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.¶
Reserved: MUST be set to zero while sending and ignored on receipt.¶
Endpoint Behavior: A 16-bit field representing the behavior associated with the SRv6 SIDs. This information is optional, but it is recommended to signal it always if possible. It could be used for maintainability and diagnostic purpose. If behavior is not known, the opaque value '0xFFFF' is used [RFC8986].¶
SRv6 SID: SRv6 Identifier is an 128-bit IPv6 address representing the SRv6 segment.¶
NAI: The NAI associated with the SRv6-SID. The NAI's format depends on the value in the NT field, and is described in [RFC8664].¶
At least one SRv6-SID or the NAI MUST be included in the SRv6-ERO subobject, and both MAY be included.¶
The SID Structure is an optional part of the SR-ERO subobject, as described in Section 4.3.1.¶
[RFC8986] defines an SRv6 SID as consisting of LOC:FUNCT:ARG, where a locator (LOC) is encoded in the L most significant bits of the SID, followed by F bits of function (FUNCT) and A bits of arguments (ARG). A locator may be represented as B:N where B is the SRv6 SID locator block (IPv6 prefix allocated for SRv6 SIDs by the operator) and N is the identifier of the parent node instantiating the SID called locator node.¶
It is formatted as shown in the following figure.¶
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LB Length | LN Length | Fun. Length | Arg. Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:¶
LB Length: 1 octet. SRv6 SID Locator Block length in bits.¶
LN Length: 1 octet. SRv6 SID Locator Node length in bits.¶
Fun. Length: 1 octet. SRv6 SID Function length in bits.¶
Arg. Length: 1 octet. SRv6 SID Arguments length in bits.¶
The sum of all four sizes in the SID Structure must be lower or equal to 128 bits. If the sum of all four sizes advertised in the SID Structure is larger than 128 bits, the corresponding SRv6 SID MUST be considered invalid and a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-Value = 37 ("Invalid SRv6 SID Structure") is returned.¶
Reserved: MUST be set to zero while sending and ignored on receipt.¶
Flags: Currently no flags are defined. Unassigned bits must be set to zero while sending and ignored on receipt.¶
The SRv6 SID Structure provides the detailed encoding information of an SRv6 SID, which is useful in the use cases that require to know the SRv6 SID structure. When a PCEP speaker receives the SRv6 SID and its structure information, the SRv6 SID can be parsed based on the SRv6 SID Structure and/or possible local policies. The SRv6 SID Structure could be used by the PCE for ease of operations and monitoring. For example, this information could be used for validation of SRv6 SIDs being instantiated in the network and checked for conformance to the SRv6 SID allocation scheme chosen by the operator as described in Section 3.2 of [RFC8986]. In the future, PCE can also be utilized to verify and automate the security of the SRv6 domain by provisioning filtering rules at the domain boundaries as described in Section 5 of [RFC8754]. The details of these potential applications are outside the scope of this document.¶
The optional elements in the SRv6-ERO subobject i.e. SRv6 SID, NAI and the SID Structure MUST be encoded in the order as depicted in Figure 2. The presence of each of them is indicated by the respective flags i.e. S flag, F flag and T flag.¶
In order to ensure future compatibility, any optional elements added to the SRv6-ERO subobject in the future must specify their order and request the Internet Assigned Numbers Authority (IANA) to allocate a flag to indicate their presence from the subregistry created in Section 9.2.¶
In order to support SRv6, a new "SRv6-RRO" subobject is defined for inclusion in the RRO.¶
A PCC reports an SRv6 path to a PCE by sending a PCRpt message, per [RFC8231]. The RRO on this message represents the SID list that was applied by the PCC, that is, the actual path taken. The procedures of [RFC8664] with respect to the RRO apply equally to this specification without change.¶
An RRO contains one or more subobjects called "SRv6-RRO subobjects" whose format is shown below.¶
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=40 | Length | NT | Flags |V|T|F|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Endpoint Behavior |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SRv6 SID(optional) |
| (128-bit) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// NAI (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SID Structure (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the SRv6-RRO subobject is the same as that of the SRv6-ERO subobject, but without the L flag.¶
The V flag has no meaning in the SRv6-RRO and is ignored on receipt at the PCE.¶
Ordering of SRv6-RRO subobjects by PCC in PCRpt message remains as per [RFC8664].¶
The ordering of optional elements in the SRv6-RRO subobject is the same as described in Section 4.3.1.2.¶
A PCC indicates that it is capable of supporting the head-end functions for SRv6 by including the SRv6-PCE-CAPABILITY sub-TLV in the Open message that it sends to a PCE. A PCE indicates that it is capable of computing SRv6 paths by including the SRv6-PCE-CAPABILITY sub-TLV in the Open message that it sends to a PCC.¶
If a PCEP speaker receives a PATH-SETUP-TYPE-CAPABILITY TLV with a PST list containing PST=3, but the SRv6-PCE-CAPABILITY sub-TLV is absent, then the PCEP speaker MUST send a PCErr message with Error-Type = 10 (Reception of an invalid object) and Error-Value = 34 (Missing PCE-SRv6-CAPABILITY sub-TLV) and MUST then close the PCEP session. If a PCEP speaker receives a PATH-SETUP-TYPE-CAPABILITY TLV with an SRv6-PCE-CAPABILITY sub-TLV, but the PST list does not contain PST=3, then the PCEP speaker MUST ignore the SRv6-PCE-CAPABILITY sub-TLV.¶
The number of SRv6 SIDs that can be imposed by a PCC on a packet depends on the PCC's IPv6 data plane capability. If a PCC sets the X flag to 1 then the MSD is not used and MUST NOT be included. If a PCE receives an SRv6-PCE-CAPABILITY sub-TLV with the X flag set to 1 then it MUST ignore any MSD-Type, MSD-Value fields and assume that the sender can impose any length of SRH. If a PCC sets the X flag to zero, then it sets the SRv6 MSD-Type, MSD-Value fields that it can impose on a packet. If a PCE receives an SRv6-PCE-CAPABILITY sub-TLV with the X flag as set, and SRv6 MSD-Type or MSD-Value fields are set then it is considered as an error and the PCE MUST respond with a PCErr message (Error-Type = 1 "PCEP session establishment failure" and Error-Value = 1 "reception of an invalid Open message or a non Open message."). In case the MSD-Type in SRv6-PCE-CAPABILITY sub-TLV received by the PCE does not correspond to one of the SRv6 MSD types, the PCE MUST respond with a PCErr message (Error-Type = 1 "PCEP session establishment failure" and Error-Value = 1 "reception of an invalid Open message or a non Open message.").¶
Note that the MSD-Type, MSD-Value exchanged via the SRv6-PCE-CAPABILITY sub-TLV indicates the SRv6 SID imposition limit for the PCC node. However, if a PCE learns these via alternate mechanisms, e.g routing protocols [RFC9352], then it ignores the values in the SRv6-PCE-CAPABILITY sub-TLV. Furthermore, whenever a PCE learns any other SRv6 MSD types that may be defined in the future via alternate mechanisms, it MUST use those values regardless of the values exchanged in the SRv6-PCE-CAPABILITY sub-TLV.¶
A PCE MUST NOT send SRv6 paths with a number of SIDs exceeding that SRv6 MSD value (based on the SRv6 MSD Type). If a PCC needs to modify the SRv6 MSD value signaled via the Open message, it MUST close the PCEP session and re-establish it with the new value. If a PCEP session is established with a non-zero SRv6 MSD value, and the PCC receives an SRv6 path containing more SIDs than specified in the SRv6 MSD value (based on the SRv6 MSD type), the PCC MUST send a PCErr message with Error-Type = 10 (Reception of an invalid object) and Error-Value = TBD1 (Unsupported number of SRv6-ERO subobjects). If a PCEP session is established with an SRv6 MSD value of zero, then the PCC MAY specify an SRv6 MSD for each path computation request that it sends to the PCE, by including a "maximum SID depth" metric object on the request similar to [RFC8664].¶
The N flag, X flag and (MSD-Type,MSD-Value) pair inside the SRv6-PCE-CAPABILITY sub-TLV are meaningful only in the Open message sent to a PCE. As such,the flags MUST be set to zero and a (MSD-Type,MSD-Value) pair MUST NOT be present in the SRv6-PCE-CAPABILITY sub-TLV in an Open message sent to a PCC. Similarly, a PCC MUST ignore N,X flag and any (MSD-Type,MSD-Value) pair in a received Open message. If a PCE receives multiple SRv6-PCE-CAPABILITY sub-TLVs in an Open message, it processes only the first sub-TLV received.¶
The processing of ERO remains unchanged in accordance with both [RFC5440] and [RFC8664].¶
If a PCC does not support the SRv6 PCE Capability and thus cannot recognize the SRv6-ERO or SRv6-RRO subobjects. It should respond according to the rules for a malformed object as described in [RFC5440].¶
On receiving an SRv6-ERO, a PCC MUST validate that the Length field, the S bit, the F bit, the T bit, and the NT field are consistent, as follows.¶
If a PCC finds that the NT field, Length field, S bit, F bit, and T bit are not consistent, it 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 a PCC does not recognize or support the value in the NT field, it MUST consider the entire ERO invalid and send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error- value = TBD2 ("Unsupported NAI Type in the SRv6-ERO/SRv6-RRO subobject").¶
If a PCC receives an SRv6-ERO subobject in which the S and F bits are both set to 1 (that is, both the SID and NAI are absent), it MUST consider the entire ERO invalid and send a PCErr message with Error- Type = 10 ("Reception of an invalid object") and Error-value = TBD3 ("Both SID and NAI are absent in the SRv6-ERO subobject").¶
If a PCC receives an SRv6-ERO subobject in which the S bit is set to 1 and the F bit is set to zero (that is, the SID is absent and the NAI is present), but the PCC does not support NAI resolution, it MUST consider the entire ERO invalid and send a PCErr message with Error- Type = 4 ("Not supported object") and Error-value = 4 ("Unsupported parameter").¶
If a PCC detects that the subobjects of an ERO are a mixture of SRv6- ERO subobjects and subobjects of other types, then it MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = TBD4 ("ERO mixes SRv6-ERO subobjects with other subobject types").¶
In case a PCEP speaker receives an SRv6-ERO subobject, when the PST is not set to 3 or SRv6-PCE-CAPABILITY sub-TLV was not exchanged, it MUST send a PCErr message with Error-Type = 19 ("Invalid Operation") and Error-Value = 19 ("Attempted SRv6 when the capability was not advertised").¶
If a PCC receives a list of SRv6 segments, and the number of SRv6 segments exceeds the SRv6 MSD that the PCC can impose on the packet (SRH), it MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-Value = TBD5 ("Unsupported number of SRv6-ERO subobjects") as per [RFC8664].¶
The SRv6-ERO contains a sequence of subobjects. According to [RFC9256], each SRv6-ERO subobject in the sequence identifies a segment that the traffic will be directed to, in the order given. That is, the first subobject identifies the first segment the traffic will be directed to, the second SRv6-ERO subobject represents the second segment, and so on.¶
The syntax checking rules that apply to the SRv6-RRO subobject are identical to those of the SRv6-ERO subobject, except as noted below.¶
If a PCEP speaker receives an SRv6-RRO subobject in which both SRv6 SID and NAI are absent, it MUST consider the entire RRO invalid and send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-Value = 35 ("Both SID and NAI are absent in SRv6-RRO subobject").¶
If a PCE detects that the subobjects of an RRO are a mixture of SRv6-RRO subobjects and subobjects of other types, then it MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-Value = 36 ("RRO mixes SRv6-RRO subobjects with other subobject types").¶
The mechanism by which the PCC learns the path is outside the scope of this document.¶
The security considerations described in [RFC5440], section 2.5 of [RFC6952], [RFC8231], [RFC8281], [RFC8253] and [RFC8664] are applicable to this specification. No additional security measure is required.¶
Note that this specification enables a network controller to instantiate an SRv6 path in the network. This creates an additional vulnerability if the security mechanisms of [RFC5440], [RFC8231], and [RFC8281] are not used. If there is no integrity protection on the session, then an attacker could create an SRv6 path that may not subjected to the further verification checks. Further, the MSD field in the Open message could disclose node forwarding capabilities if suitable security mechanisms are not in place.¶
All manageability requirements and considerations listed in [RFC5440], [RFC8231], [RFC8281], and [RFC8664] apply to PCEP protocol extensions defined in this document. In addition, requirements and considerations listed in this section apply.¶
A PCEP implementation SHOULD allow the operator to configure the SRv6 capability. Further a policy to accept NAI only for the SRv6 SHOULD be allowed to be set.¶
The PCEP YANG module is out of the scope of this document and defined in other drafts. An augmented YANG module for SRv6 is also specified in another draft that allows for SRv6 capability and MSD configurations as well as to monitor the SRv6 paths set in the network.¶
Mechanisms defined in this document do not imply any new liveness detection and monitoring requirements in addition to those already listed in [RFC5440].¶
Verification of the mechanisms defined in this document can be built on those already listed in [RFC5440], [RFC8231], and [RFC8664].¶
Mechanisms defined in this document do not imply any new requirements on other protocols.¶
[Note to the RFC Editor - remove this section before publication, as well as remove the reference to [RFC7942].¶
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 [RFC7942]. 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 [RFC7942], "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".¶
This document defines a new subobject type for the PCEP explicit route object (ERO), and a new subobject type for the PCEP reported route object (RRO). The code points for subobject types of these objects is maintained in the RSVP parameters registry, under the EXPLICIT_ROUTE and REPORTED_ROUTE objects. IANA is requested to confirm the following allocations in the RSVP Parameters registry for each of the new subobject types defined in this document.¶
Object Subobject Subobject Type --------------------- -------------------------- ------------------ EXPLICIT_ROUTE SRv6-ERO (PCEP-specific) 40 REPORTED_ROUTE SRv6-RRO (PCEP-specific) 40¶
IANA is requested to create a new sub-registry, named "SRv6-ERO Flag Field", within the "Path Computation Element Protocol (PCEP) Numbers" registry to manage the 12-bit Flag field of the SRv6-ERO subobject. New values are to be assigned by Standards Action [RFC8126]. Each bit should be tracked with the following qualities.¶
The following values are defined in this document.¶
Bit Description Reference
----- ------------------ --------------
0-7 Unassigned
8 SID Verification (V) This document
9 SID Structure is This document
present (T)
10 NAI is absent (F) This document
11 SID is absent (S) This document
¶
This document defines a new value in the sub-registry "LSP-ERROR-CODE TLV Error Code Field" in the "Path Computation Element Protocol(PCEP) Numbers" registry.¶
Value Meaning Reference
--- ----------------------- -----------
TBD2 SID Verification fails This document
¶
IANA maintains a sub-registry, named "PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators", within the "Path Computation Element Protocol (PCEP) Numbers" registry to manage the type indicator space for sub-TLVs of the PATH-SETUP-TYPE-CAPABILITY TLV. IANA is requested to confirm the following allocations in the sub-registry.¶
Value Meaning Reference ----- ------- --------- 27 SRv6-PCE-CAPABILITY This Document¶
IANA is requested to create a new sub-registry, named "SRv6 Capability Flag Field", within the "Path Computation Element Protocol (PCEP) Numbers" registry to manage the 16-bit Flag field of the SRv6-PCE-CAPABILITY sub-TLV. New values are to be assigned by Standards Action [RFC8126]. Each bit should be tracked with the following qualities.¶
The following values are defined in this document.¶
Bit Description Reference
----- ------------------ --------------
0-13 Unassigned
14 Node or Adjacency This document
Identifier (NAI) is
supported (N)
15 Unlimited Maximum SID This document
Depth (X)
¶
[RFC8408] created a sub-registry within the "Path Computation Element Protocol (PCEP) Numbers" registry called "PCEP Path Setup Types". IANA is requested to confirm the following allocations in the sub-registry.¶
Value Description Reference
----- ----------- ---------
3 Traffic engineering path is This Document
setup using SRv6.
¶
IANA is requested to confirm the following allocations in the PCEP-ERROR Object Error Types and Values registry for the following new error-values.¶
Error-Type Meaning
---------- -------
10 Reception of an invalid object
Error-value = 34 (Missing
PCE-SRv6-CAPABILITY sub-TLV)
Error-value = 35 (Both SID and NAI are absent
in SRv6-RRO subobject)
Error-value = 36 (RRO mixes SRv6-RRO subobjects
with other subobject types)
Error-value = 37 (Invalid SRv6 SID Structure)
19 Invalid Operation
Error-value = 19 (Attempted SRv6 when the
capability was not advertised)
¶
IANA is requested to make a new allocations in the PCEP-ERROR Object Error Types and Values registry for the following new error-values.¶
Error-Type Meaning
---------- -------
10 Reception of an invalid object
Error-value = TBD1 (Unsupported number of
SRv6-ERO subobjects)
Error-value = TBD2 (Unsupported NAI Type
in the SRv6-ERO/SRv6-RRO subobject)
Error-value = TBD3 (Both SID and NAI are
absent in the SRv6-ERO subobject)
Error-value = TBD4 (ERO mixes SRv6-ERO
subobjects with other subobject types)
Error-value = TBD5 (Unsupported number
of SRv6-ERO subobjects)
¶
The authors would like to thank Jeff Tantsura, Adrian Farrel, Aijun Wang, Khasanov Boris, Ketan Talaulikar and Robert Varga for valuable suggestions.¶