PCEP Extensions for Segment
Routing leveraging the IPv6 data planeHuawei TechnologiesHuawei Campus, No. 156 Beiqing Rd.Beijing100095Chinac.l@huawei.comRtBrick IncBangaloreKarnatakaIndiamahend.ietf@gmail.comCiena Corporationmsiva282@gmail.comCisco Systems, Inc.Canadamkoldych@cisco.comRtBrick IncBangaloreKarnatakaIndiaprejeeth@rtbrick.comChina Telecom109 West Zhongshan Ave, Tianhe DistrictBangaloreGuangzhouP.R. Chinazhuyq8@chinatelecom.cn
Routing
PCE Working GroupThe Source Packet Routing in Networking (SPRING) architecture
describes how 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).It depends only on "segments" that are advertised by Link-State
IGPs. A Segment Routed Path can be derived from a variety of mechanisms,
including an IGP Shortest Path Tree (SPT), explicit configuration, or a
Path Computation Element (PCE).Since SR can be applied to both MPLS and IPv6 forwarding plane, a PCE
should be able to compute SR-Path for both MPLS and IPv6 forwarding
plane. This document describes the extensions required for SR support
for IPv6 data plane in Path Computation Element communication Protocol
(PCEP). The PCEP extension and mechanism to support SR-MPLS is described
in RFC 8664. This document extends it to support SRv6 (SR over
IPv6).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.As per , with Segment Routing (SR), a node
steers a packet through an ordered list of instructions, called
segments. A segment can represent any instruction, topological or
service-based. A segment can have a semantic local to an SR node or
global within an SR domain. SR allows to enforce a flow through any path
and service chain while maintaining per-flow state only at the ingress
node of the SR domain. Segments can be derived from different
components: IGP, BGP, Services, Contexts, Locater, etc. The list of
segment forming the path is called the Segment List and is encoded in
the packet header. Segment Routing can be applied to the IPv6
architecture with the Segment Routing Header (SRH) . A segment is encoded as an IPv6 address. An ordered
list of segments is encoded as an ordered list of IPv6 addresses in the
routing header. The active segment is indicated by the Destination
Address of the packet. Upon completion of a segment, a pointer in the
new routing header is incremented and indicates the next segment.Segment Routing use cases are described in
and . Segment Routing protocol extensions are
defined in , and .As per , an SRv6 Segment is a 128-bit value.
"SRv6 SID" or simply "SID" are often used as a shorter reference for
"SRv6 Segment". Further details are in an illustration provided in .The SR architecture can be applied to the MPLS forwarding plane
without any change, in which case an SR path corresponds to an MPLS
Label Switching Path (LSP). The SR is applied to IPV6 forwarding plane
using SRH. A SR path can be derived from an IGP Shortest Path Tree
(SPT), but SR-TE 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. 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. specifies extensions to PCEP that allow a stateful
PCE to compute and recommend network paths in compliance with 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 . As per ,
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 using
the SR specific PCEP extensions specified in .
specifies PCEP extensions for supporting a
SR-TE LSP for MPLS data plane. This document extends to support SR for IPv6 data plane. Additionally,
using procedures described in this document, a PCC can request an SRv6
path from either stateful or a stateless PCE. This specification relies
on the PATH-SETUP-TYPE TLV and procedures specified in .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 .This document uses the following terms defined in : PCC, PCE, PCEP Peer.This document uses the following terms defined in : Stateful PCE, Delegation.The message formats in this document are specified using Routing
Backus-Naur Format (RBNF) encoding as specified in .Node or Adjacency Identifier.Path Computation Client.Path Computation Element.Path Computation Element Protocol.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)Further, note that the term LSP used in the PCEP specifications,
would be equivalent to a SRv6 Path (represented as a list of SRv6
segments) in the context of supporting SRv6 in PCEP.Basic operations for PCEP speakers is as per . SRv6 Paths computed by a PCE can be represented as
an ordered list of SRv6 segments of 128-bit value. "SRv6 SID" or simply
"SID" are often used as a shorter reference for "SRv6 Segment" in this
document. 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.
SR-capable PCEP speakers should be able to generate and/or process such
ERO subobject. An ERO containing SR-ERO subobjects can be included in
the PCEP Path Computation Reply (PCRep) message defined in , the PCEP LSP Initiate Request message (PCInitiate)
defined in , as well as in the PCEP LSP Update
Request (PCUpd) and PCEP LSP State Report (PCRpt) messages defined in
defined in .This document define new subobjects "SRv6-ERO" and "SRv6-RRO" in ERO
and RRO respectively to carry SRv6 SID (IPv6 Address). SRv6-capable PCEP
speakers MUST be able to generate and/or process this.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.In summary, this document:Defines a new PCEP capability for SRv6.Defines a new subobject SRv6-ERO in ERO.Defines a new subobject SRv6-RRO in RRO.Defines a new path setup type carried in the PATH-SETUP-TYPE TLV
and the PATH-SETUP-TYPE-CAPABILITY TLV.In SR networks, an ingress node of an SR path appends all outgoing
packets with an SR header consisting of a list of SIDs (IPv6 Prefix in
case of SRv6). The header 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 IPv6 in control plane with MPLS data-plane, mechanism remains
same as This document describes extensions to SR path for IPv6 data plane.
SRv6 Path (i.e. ERO) consists of an ordered set of SRv6 SIDs(see
details in ).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 ).As defined in , 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 , PCInitiate message specified in , and PCRpt and PCUpd messages specified in . 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) for SRv6, as follows:PST = 3 (early allocated by IANA): Path is setup using SRv6.A PCEP speaker MUST indicate 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 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 (early allocated by IANA) 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.The format of the SRv6-PCE-CAPABILITY sub-TLV is shown in the
following figure:The code point for the TLV type (27)(early allocated by IANA) is to be defined by IANA.
The TLV length is variable.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. N bit: A PCC sets this flag bit to 1 to indicate that it
is capable of resolving a Node or Adjacency Identifier (NAI)
to a SRv6-SID.X bit: A PCC sets this bit to 1 to indicate that it does
not impose any limit on MSD (irrespective of the
MSD-Type).Unassigned bits MUST be set to 0 and ignored on
receipt.A pair of (MSD-Type, MSD-Value): Where MSD-Type (1 octet) is
as per the IGP MSD Type registry created by and populated with SRv6 MSD types as per
; MSD-Value (1
octet) is as per .This sub-TLV format is compliant with the PCEP TLV format defined
in . 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 (early allocated by IANA) 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.In order to indicate the SRv6 path, RP or SRP object MUST include
the PATH-SETUP-TYPE TLV specified in . This
document defines a new Path Setup Type (PST=3(early allocated by IANA)) for SRv6.The LSP-IDENTIFIERS TLV MAY be present for the above PST type.In order to support SRv6, new subobject "SRv6-ERO" is defined in
ERO.An SRv6-ERO subobject is formatted as shown in the following
figure.The fields in the SRv6-ERO Subobject are as follows:The 'L' Flag: Indicates whether the subobject represents a
loose-hop (see ). 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 (early allocated by IANA), the suboject is a SRv6-ERO subobject representing a
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 a 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 : 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 , which specifies an
IPv6 address. This is used to identify the owner of the SRv6
Identifier. This is optional, as the LOC (the locater 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 , 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 , 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. S: When this bit is set to 1, the SRv6-SID value in the
subobject body is absent. In this case, the PCC is responsible
for choosing the SRv6-SID value, e.g., by looking up in the
SR-DB using the NAI which, in this case, MUST be present in the
subobject. If the S bit is set to 1 then F bit MUST be set to
zero.F: When this bit is set to 1, the NAI value in the subobject
body is absent. The F bit MUST be set to 1 if NT=0, and
otherwise MUST be set to zero. The S and F bits MUST NOT both be
set to 1.T: When this bit is set to 1, the SID Structure value in the
subobject body is present. The T bit MUST be set to 0 when S bit
is set to 1. If the T bit is set when the S bit is set, the T
bit MUST be ignored. Thus, the T bit indicates the presence of
an optional 8-byte SID Structure when SRv6 SID is included. The
SID Structure is defined in .V: The "SID verification" bit usage is as per Section 5.1 of
.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 and
plays no role in the fields in SRH imposed on the packet. It could
be used for maintainability and diagnostic purpose. If behavior is
not known, 0 is used. The list of Endpoint behavior are defined in
.SRv6 SID: SRv6 Identifier is the 128 bit IPv6 addresses
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 .At least one of the 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 . 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.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 (early allocated by IANA) ("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 . In the
future, PCE could also be used for verification and the automation
for securing the SRv6 domain by provisioning filtering rules at SR
domain boundaries as described in Section 5 of . 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 . The presence of each of them is indicated by the respective flags i.e. S flag, F flag and T flag.To allow for future compatibility, any optional element added to the SRv6-ERO subobject in future MUST specify the order of the optional element and request IANA to allocate a flag to indicate its presence from the subregistry created in .In order to support SRv6, new subobject "SRv6-RRO" is defined in
RRO.A PCC reports an SRv6 path to a PCE by sending a PCRpt message,
per . The RRO on this message represents the
SID list that was applied by the PCC, that is, the actual path
taken. The procedures of 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: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 .The ordering of optional elements in the SRv6-RRO subobject as same as described in .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 (early allocated by IANA), 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 (early allocated by IANA) (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 a SRv6-PCE-CAPABILITY sub-TLV, but the PST
list does not contain PST=3 (early allocated by IANA), then the PCEP speaker MUST ignore the
SRv6-PCE-CAPABILITY sub-TLV.The number of SRv6 SIDs that can be imposed on a packet depends on
the PCC's IPv6 data plane's 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 MUST 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 and SRv6 MSD-Type, MSD-Value fields both set to zero 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 different means,
e.g routing protocols, as specified in: ; ; , then it ignores the values in
the SRv6-PCE-CAPABILITY sub-TLV. Furthermore, whenever a PCE learns
the other advanced SRv6 MSD via different means, it MUST use that
value regardless of the values exchanged in the SRv6-PCE-CAPABILITY
sub-TLV.Once an SRv6-capable PCEP session is established with a non-zero
SRv6 MSD value, the corresponding 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, 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 3
(Unsupported number of Segment 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 .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 from a PCC to a PCE. As such, a PCE MUST set the flags to zero
and not include any (MSD-Type,MSD-Value) pair in the
SRv6-PCE-CAPABILITY sub-TLV in an outbound message to a PCC.
Similarly, a PCC MUST ignore N,X flag and any (MSD-Type,MSD-Value)
pair received from a PCE. If a PCE receives multiple
SRv6-PCE-CAPABILITY sub-TLVs in an Open message, it processes only the
first sub-TLV received.The ERO processing remains as per and
.If a PCC does not support the SRv6 PCE Capability and thus cannot
recognize the SRv6-ERO or SRv6-RRO subobjects, it will respond
according to the rules for a malformed object per .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 NT=0, the F bit MUST be 1, the S bit MUST be zero and the
Length MUST be 24.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 40.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 56.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 64.NT types (1,3, and 5) are not valid for SRv6.If T bit is 1, then S bit MUST be zero.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 PCEP speaker that does not recognize the NT value received
in SRv6-ERO subobject, it would behave as per .In case a PCEP speaker receives the SRv6-ERO subobject, when the
PST is not set to 3 (early allocated by IANA) 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 (early allocated by IANA) ("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 = 3 ("Unsupported number of SR-ERO subobjects") as per .When a PCEP speaker detects that all subobjects of ERO are not of
type 40 (early allocated by IANA), and if it does not handle such ERO, it MUST send a PCErr
message with Error-Type = 10 ("Reception of an invalid object") and
Error-Value = 20 ("Inconsistent SIDs in SR-ERO / SR-RRO subobjects") as per .The SRv6-ERO contains a sequence of subobjects. According to
, 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 PCC interprets the SRv6-ERO by converting it to an SRv6 SRH
plus a next hop. The PCC sends packets along the segment routed path
by prepending the SRH onto the packets and sending the resulting,
modified packet to the next hop.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 (early allocated by IANA) ("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 (early allocated by IANA) ("RRO mixes SRv6-RRO subobjects with other
subobject types").The security considerations described in ,
and , , are applicable to this specification. No additional
security measure is required.All manageability requirements and considerations listed in , , and 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
policy based on which it allocates the SIDs.The PCEP YANG module is defined in . An implementation SHOULD allow the
operator to view the SIDs allocated to the LSP for the SR path.Mechanisms defined in this document do not imply any new liveness
detection and monitoring requirements in addition to those already
listed in .Mechanisms defined in this document do not imply any new operation
verification requirements in addition to those already listed in , , and .Mechanisms defined in this document do not imply any new
requirements on other protocols.Mechanisms defined in , , and also apply to PCEP
extensions defined in this document.[Note to the RFC Editor - remove this section before publication, as
well as remove the reference to .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, Inc.Implementation: IOS-XR PCE and PCC.Description: Implementation with experimental codepoints.Maturity Level: ProductionCoverage: PartialContact: ssidor@cisco.comThis document defines a new subobject type for the PCEP explicit
route object (ERO), and a new subobject type for the PCEP record route
object (RRO). The code points for subobject types of these objects is
maintained in the RSVP parameters registry, under the EXPLICIT_ROUTE
and ROUTE_RECORD objects. IANA is requested to confirm
the following early allocations in
the RSVP Parameters registry for each of the new subobject types
defined in this document.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 Flag field of the SRv6-ERO subobject.
New values are to be assigned by Standards Action . Each bit should be tracked with the following
qualities:Bit number (counting from bit 0 as the most significant
bit)Capability descriptionDefining RFCThe following values are defined in 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 early allocations in the sub-registry: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 Flag field of the
SRv6-PCE-CAPABILITY sub-TLV. New values are to be assigned by
Standards Action . Each bit should be tracked
with the following qualities:Bit number (counting from bit 0 as the most significant
bit)Capability descriptionDefining RFCThe following values are defined in this document: 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 early allocations in the sub-registry:IANA is requested to confirm the following early allocations in the PCEP-ERROR Object
Error Types and Values registry for the following new
error-values:The authors would like to thank Jeff Tantsura, Adrian Farrel, Aijun
Wang, Khasanov Boris, and Robert Varga for valuable suggestions.The following persons contributed to this document: