rfc9603.original   rfc9603.txt 
PCE Working Group C. Li Internet Engineering Task Force (IETF) 李呈 (C. Li), Ed.
Internet-Draft Huawei Technologies Request for Comments: 9603 华为技术有限公司 (Huawei Technologies)
Intended status: Standards Track P. Kaladharan Category: Standards Track P. Kaladharan
Expires: 6 October 2024 RtBrick Inc ISSN: 2070-1721 RtBrick Inc
S. Sivabalan S. Sivabalan
Ciena Corporation
M. Koldychev M. Koldychev
Cisco Systems, Inc. Ciena Corporation
Y. Zhu Y. Zhu
China Telecom China Telecom
4 April 2024 July 2024
Path Computation Element Communication Protocol (PCEP) Extensions for Path Computation Element Communication Protocol (PCEP) Extensions for
IPv6 Segment Routing IPv6 Segment Routing
draft-ietf-pce-segment-routing-ipv6-25
Abstract Abstract
Segment Routing (SR) can be used to steer packets through a network Segment Routing (SR) can be used to steer packets through a network
using the IPv6 or MPLS data plane, employing the source routing using the IPv6 or MPLS data plane, employing the source routing
paradigm. paradigm.
A Segment Routed Path can be derived from a variety of mechanisms, An SR Path can be derived from a variety of mechanisms, including an
including an IGP Shortest Path Tree (SPT), explicit configuration, or IGP Shortest Path Tree (SPT), explicit configuration, or a Path
a Path Computation Element(PCE). Computation Element (PCE).
Since SR can be applied to both MPLS and IPv6 data-planes, a PCE Since SR can be applied to both MPLS and IPv6 data planes, a PCE
should be able to compute an SR Path for both MPLS and IPv6 data- should be able to compute an SR Path for both MPLS and IPv6 data
planes. The Path Computation Element communication Protocol (PCEP) planes. The Path Computation Element Communication Protocol (PCEP)
extension and mechanisms to support SR-MPLS have been defined. This extension and mechanisms to support SR-MPLS have been defined. This
document outlines the necessary extensions to support SR for the IPv6 document outlines the necessary extensions to support SR for the IPv6
data-plane within PCEP. data plane within PCEP.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is a product of the Internet Engineering Task Force
Task Force (IETF). Note that other groups may also distribute (IETF). It represents the consensus of the IETF community. It has
working documents as Internet-Drafts. The list of current Internet- received public review and has been approved for publication by the
Drafts is at https://datatracker.ietf.org/drafts/current/. Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Internet-Drafts are draft documents valid for a maximum of six months Information about the current status of this document, any errata,
and may be updated, replaced, or obsoleted by other documents at any and how to provide feedback on it may be obtained at
time. It is inappropriate to use Internet-Drafts as reference https://www.rfc-editor.org/info/rfc9603.
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 6 October 2024.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology
3. Overview of PCEP Operation in SRv6 Networks . . . . . . . . . 5 3. Overview of PCEP Operation in SRv6 Networks
3.1. Operation Overview . . . . . . . . . . . . . . . . . . . 6 3.1. Operation Overview
3.2. SRv6-Specific PCEP Message Extensions . . . . . . . . . . 6 3.2. SRv6-Specific PCEP Message Extensions
4. Object Formats . . . . . . . . . . . . . . . . . . . . . . . 6 4. Object Formats
4.1. The OPEN Object . . . . . . . . . . . . . . . . . . . . . 6 4.1. The OPEN Object
4.1.1. The SRv6 PCE Capability sub-TLV . . . . . . . . . . . 6 4.1.1. The SRv6 PCE Capability sub-TLV
4.2. The RP/SRP Object . . . . . . . . . . . . . . . . . . . . 8 4.2. The RP/SRP Object
4.3. ERO . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. ERO
4.3.1. SRv6-ERO Subobject . . . . . . . . . . . . . . . . . 8 4.3.1. SRv6-ERO Subobject
4.3.1.1. SID Structure . . . . . . . . . . . . . . . . . . 11 4.3.1.1. SID Structure
4.3.1.2. Order of the Optional fields . . . . . . . . . . 12 4.3.1.2. Order of the Optional Fields
4.4. RRO . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.4. RRO
4.4.1. SRv6-RRO Subobject . . . . . . . . . . . . . . . . . 13 4.4.1. SRv6-RRO Subobject
5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 13 5. Procedures
5.1. Exchanging the SRv6 Capability . . . . . . . . . . . . . 14 5.1. Exchanging the SRv6 Capability
5.2. ERO Processing . . . . . . . . . . . . . . . . . . . . . 15 5.2. ERO Processing
5.2.1. SRv6 ERO Validation . . . . . . . . . . . . . . . . . 15 5.2.1. SRv6 ERO Validation
5.2.2. Interpreting the SRv6-ERO . . . . . . . . . . . . . . 16 5.2.2. Interpreting the SRv6-ERO
5.3. RRO Processing . . . . . . . . . . . . . . . . . . . . . 16 5.3. RRO Processing
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 6. Security Considerations
7. Manageability Considerations . . . . . . . . . . . . . . . . 17 7. Manageability Considerations
7.1. Control of Function and Policy . . . . . . . . . . . . . 17 7.1. Control of Function and Policy
7.2. Information and Data Models . . . . . . . . . . . . . . . 18 7.2. Information and Data Models
7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 18 7.3. Liveness Detection and Monitoring
7.4. Verify Correct Operations . . . . . . . . . . . . . . . . 18 7.4. Verify Correct Operations
7.5. Requirements On Other Protocols . . . . . . . . . . . . . 18 7.5. Requirements on Other Protocols
7.6. Impact On Network Operations . . . . . . . . . . . . . . 18 7.6. Impact on Network Operations
8. IANA Considerations
8. Implementation Status . . . . . . . . . . . . . . . . . . . . 18 8.1. PCEP ERO and RRO Subobjects
8.1. Cisco's Commercial Delivery . . . . . . . . . . . . . . . 19 8.2. New SRv6-ERO NAI Type Registry
8.2. Huawei's Commercial Delivery . . . . . . . . . . . . . . 19 8.3. New SRv6-ERO Flag Registry
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 8.4. LSP-ERROR-CODE TLV
9.1. PCEP ERO and RRO subobjects . . . . . . . . . . . . . . . 19 8.5. PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators
9.2. New SRv6-ERO NAI Type Registry . . . . . . . . . . . . . 20 8.6. SRv6 PCE Capability Flags
9.3. New SRv6-ERO Flag Registry . . . . . . . . . . . . . . . 20 8.7. New Path Setup Type
9.4. LSP-ERROR-CODE TLV . . . . . . . . . . . . . . . . . . . 21 8.8. ERROR Objects
9.5. PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators . . . 21 9. References
9.6. SRv6 PCE Capability Flags . . . . . . . . . . . . . . . . 21 9.1. Normative References
9.7. New Path Setup Type . . . . . . . . . . . . . . . . . . . 22 9.2. Informative References
9.8. ERROR Objects . . . . . . . . . . . . . . . . . . . . . . 22 Acknowledgements
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 Contributors
10.1. Normative References . . . . . . . . . . . . . . . . . . 23 Authors' Addresses
10.2. Informative References . . . . . . . . . . . . . . . . . 24
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 26
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
As defined in [RFC8402], Segment Routing (SR) architecture allows the As defined in [RFC8402], Segment Routing (SR) architecture allows the
source node to steer a packet through a path indicated by an ordered source node to steer a packet through a path indicated by an ordered
list of instructions, called segments. A segment can represent any list of instructions, called "segments". A segment can represent any
instruction, topological or service-based, and it can have a semantic instruction, topological or service based, and it can have a semantic
local to an SR node or global within an SR domain. local to an SR node or global within an SR domain.
[RFC5440] describes Path Computation Element communication Protocol [RFC5440] describes Path Computation Element Communication Protocol
(PCEP) for communication between a Path Computation Client (PCC) and (PCEP) for communication between a Path Computation Client (PCC) and
a PCE or between a pair of PCEs. A PCE or a PCC operating as a PCE a PCE or between a pair of PCEs. A PCE or a PCC operating as a PCE
(in a hierarchical PCE environment) computes paths for MPLS Traffic (in a hierarchical PCE environment) computes paths for MPLS Traffic
Engineering LSPs (MPLS-TE LSPs) based on various constraints and Engineering Label Switched Paths (MPLS-TE LSPs) based on various
optimization criteria. constraints and optimization criteria.
[RFC8231] specifies extensions to PCEP that allow a stateful PCE to [RFC8231] specifies extensions to PCEP that allow a stateful PCE to
compute and recommend network paths in compliance with [RFC4657] and compute and recommend network paths in compliance with [RFC4657] and
defines objects and TLVs for MPLS-TE LSPs. Stateful PCEP extensions defines objects and TLVs for MPLS-TE LSPs. Stateful PCEP extensions
provide synchronization of LSP state between a PCC and a PCE or provide synchronization of LSP state between a PCC and a PCE or
between a pair of PCEs, delegation of LSP control, reporting of LSP 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 state from a PCC to a PCE, and controlling the setup and path routing
an LSP from a PCE to a PCC. Stateful PCEP extensions are intended 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 for an operational model in which LSPs are configured on the PCC, and
control over them is delegated to the PCE. control over them is delegated to the PCE.
A mechanism to dynamically initiate LSPs on a PCC based on the A mechanism to dynamically initiate LSPs on a PCC based on the
requests from a stateful PCE or a controller using stateful PCE is requests from a stateful PCE or a controller using stateful PCE is
specified in [RFC8281]. As per [RFC8664], it is possible to use a specified in [RFC8281]. As per [RFC8664], it is possible to use a
stateful PCE for computing one or more SR-TE paths taking into stateful PCE for computing one or more SR-TE paths taking into
account various constraints and objective functions. Once a path is account various constraints and objective functions. Once a path is
computed, the stateful PCE can initiate an SR-TE path on a PCC using computed, the stateful PCE can initiate an SR-TE path on a PCC using
PCEP extensions specified in [RFC8281] and the SR-specific PCEP PCEP extensions specified in [RFC8281] and the SR-specific PCEP
extensions specified in [RFC8664]. extensions specified in [RFC8664].
[RFC8664] specifies PCEP extensions for supporting a SR-TE LSP for [RFC8664] specifies PCEP extensions for supporting an SR-TE LSP for
the MPLS data-plane. This document extends [RFC8664] to support SR the MPLS data plane. This document extends [RFC8664] to support SR
for the IPv6 data-plane. Additionally, using procedures described in for the IPv6 data plane. Additionally, using procedures described in
this document, a PCC can request an SRv6 path from either a stateful this document, a PCC can request an SRv6 path from either a stateful
or stateless PCE. This specification relies on the PATH-SETUP-TYPE or stateless PCE. This specification relies on the PATH-SETUP-TYPE
TLV and procedures specified in [RFC8408]. TLV and procedures specified in [RFC8408].
This specification provides a mechanism for a network controller This specification provides a mechanism for a network controller
(acting as a PCE) to instantiate candidate paths for an SR Policy (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 onto a head-end node (acting as a PCC) using PCEP. For more
information on the SR Policy Architecture, see [RFC9256] which information on the SR Policy architecture, see [RFC9256], which
applies to both SR-MPLS and SRv6. applies to both SR-MPLS and SRv6.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Terminology 2. Terminology
This document uses the following terms defined in [RFC5440]: PCC, This document uses the following terms defined in [RFC5440]: PCC,
PCE, PCEP, PCEP Peer. PCE, PCEP, PCEP Peer.
This document uses the following terms defined in [RFC8051]: Stateful This document uses the following terms defined in [RFC8051]: Stateful
PCE, Delegation. PCE, Delegation.
Further, the following terms are used in the document, Further, the following terms are used in the document:
MSD: Maximum SID Depth. MSD: Maximum SID Depth
PST: Path Setup Type. PST: Path Setup Type
SR: Segment Routing. SR: Segment Routing
SID: Segment Identifier. SID: Segment Identifier
SRv6: Segment Routing over IPv6 data-plane. SRv6: Segment Routing over IPv6 data plane
SRH: IPv6 Segment Routing Header [RFC8754]. SRH: IPv6 Segment Routing Header [RFC8754]
SRv6 Path: IPv6 Segment List (List of IPv6 SIDs representing a path SRv6 path: IPv6 Segment List (A list of IPv6 SIDs representing a
in IPv6 SR domain in the context of this document) path in IPv6 SR domain in the context of this document.)
Further, note that the term LSP used in the PCEP specifications, Further, note that the term "LSP" used in the PCEP specifications
would be equivalent to an SRv6 Path (represented as a list of SRv6 would be equivalent to an SRv6 path (represented as a list of SRv6
segments) in the context of supporting SRv6 in PCEP. segments) in the context of supporting SRv6 in PCEP.
3. Overview of PCEP Operation in SRv6 Networks 3. Overview of PCEP Operation in SRv6 Networks
Basic operations for PCEP speakers are built on [RFC8664]. Basic operations for PCEP speakers are built on [RFC8664].
In PCEP messages, route information is carried in the Explicit Route In PCEP messages, route information is carried in the Explicit Route
Object (ERO), which consists of a sequence of subobjects. [RFC8664] Object (ERO), which consists of a sequence of subobjects. [RFC8664]
defined a new Explicit Route Object (ERO) subobject denoted by "SR- defined a new ERO subobject denoted by "SR-ERO subobject" that is
ERO subobject" capable of carrying a SID as well as the identity of capable of carrying a SID as well as the identity of the node/
the node/adjacency represented by the SID for SR-MPLS. SR-capable adjacency represented by the SID for SR-MPLS. SR-capable PCEP
PCEP speakers can generate and/or process such an ERO subobject. An speakers can generate and/or process such an ERO subobject. An ERO
ERO containing SR-ERO subobjects can be included in the PCEP Path containing SR-ERO subobjects can be included in the PCEP Path
Computation Reply (PCRep) message defined in [RFC5440], the PCEP LSP Computation Reply (PCRep) message defined in [RFC5440], the PCEP LSP
Initiate Request message (PCInitiate) defined in [RFC8281], as well Initiate Request message (PCInitiate) defined in [RFC8281], as well
as in the PCEP LSP Update Request (PCUpd) and PCEP LSP State Report as in the PCEP LSP Update Request (PCUpd) and PCEP LSP State Report
(PCRpt) messages defined in [RFC8231]. [RFC8664] also defines a new (PCRpt) messages defined in [RFC8231]. [RFC8664] also defines a new
Reported Route Object(RRO) called SR-RRO to represent the SID list Reported Route Object (RRO), called "SR-RRO", to represent the SID
that was applied by the PCC, that is, the actual path taken by the list that was applied by the PCC, which is the actual path taken by
LSP in SR-MPLS network. the LSP in SR-MPLS network.
The SRv6 Paths computed by a PCE can be represented as an ordered The SRv6 paths computed by a PCE can be represented as an ordered
list of SRv6 segments. This document defines new subobjects list of SRv6 segments. This document defines new subobjects
"SRv6-ERO" and "SRv6-RRO" in the ERO and the RRO respectively to "SRv6-ERO" and "SRv6-RRO" in the ERO and the RRO, respectively, to
carry the SRv6 SID. SRv6-capable PCEP speakers MUST be able to carry the SRv6 SID. SRv6-capable PCEP speakers MUST be able to
generate and/or process these subobjects. generate and/or process these subobjects.
When a PCEP session between a PCC and a PCE is established, both PCEP When a PCEP session between a PCC and a PCE is established, both PCEP
speakers exchange their capabilities to indicate their ability to speakers exchange their capabilities to indicate their ability to
support SRv6 specific functionality as described in Section 4.1.1. support SRv6-specific functionality as described in Section 4.1.1.
In summary, this document, In summary, this document defines:
* Defines a new PCEP capability for SRv6. * a new PCEP capability for SRv6,
* Defines a new subobject SRv6-ERO in ERO. * a new subobject SRv6-ERO in ERO,
* Defines a new subobject SRv6-RRO in RRO. * a new subobject SRv6-RRO in RRO, and
* Defines a new path setup type (PST) [RFC8408] carried in the PATH- * a new Path Setup type (PST) [RFC8408], carried in the PATH-SETUP-
SETUP-TYPE TLV and the PATH-SETUP-TYPE-CAPABILITY TLV. TYPE and PATH-SETUP-TYPE-CAPABILITY TLVs.
3.1. Operation Overview 3.1. Operation Overview
In SR networks, an SR source node [RFC8754] steers a packet into an In SR networks, an SR source node [RFC8754] steers a packet into an
SR Policy resulting in a segment list. SR Policy resulting in a segment list.
When SR leverages the IPv6 data-plane (i.e. SRv6), the PCEP When SR leverages the IPv6 data plane (i.e., SRv6), the PCEP
procedures and mechanisms are extended in this document. procedures and mechanisms are extended in this document.
This document describes the extension to support SRv6 in PCEP. A PCC This document describes the extension to support SRv6 in PCEP. A PCC
or PCE indicates its ability to support SRv6 during the PCEP session or PCE indicates its ability to support SRv6 during the PCEP session
Initialization Phase via a new SRv6-PCE-CAPABILITY sub-TLV (see initialization phase via a new SRv6-PCE-CAPABILITY sub-TLV (see
details in Section 4.1.1). details in Section 4.1.1).
3.2. SRv6-Specific PCEP Message Extensions 3.2. SRv6-Specific PCEP Message Extensions
As defined in [RFC5440], a PCEP message consists of a common header As defined in [RFC5440], a PCEP message consists of a common header
followed by a variable length body made up of mandatory and/or followed by a variable-length body made up of mandatory and/or
optional objects. This document does not require any changes in the optional objects. This document does not require any changes in the
format of PCReq and PCRep messages specified in [RFC5440], PCInitiate format of PCReq and PCRep messages specified in [RFC5440], the
message specified in [RFC8281], and PCRpt and PCUpd messages PCInitiate message specified in [RFC8281], or PCRpt and PCUpd
specified in [RFC8231]. However, PCEP messages pertaining to SRv6 messages specified in [RFC8231]. However, PCEP messages pertaining
MUST include PATH-SETUP-TYPE TLV in the RP (Request Parameters) or to SRv6 MUST include PATH-SETUP-TYPE TLV in the Request Parameters
SRP (Stateful PCE Request Parameters) object to clearly identify that (RP) or Stateful PCE Request Parameters (SRP) object to clearly
SRv6 is intended. identify that SRv6 is intended.
4. Object Formats 4. Object Formats
4.1. The OPEN Object 4.1. The OPEN Object
4.1.1. The SRv6 PCE Capability sub-TLV 4.1.1. The SRv6 PCE Capability sub-TLV
This document defines a new Path Setup Type (PST) [RFC8408] for SRv6, This document defines a new Path Setup Type (PST) [RFC8408] for SRv6,
as follows. as follows:
* PST = 3 : Path is setup using SRv6. PST=3: Path is set up using SRv6.
A PCEP speaker indicates its support of the function described in A PCEP speaker indicates its support of the function described in
this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the OPEN this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the OPEN
object with this new PST "3" included in the PST list. object with this new PST (value 3) included in the PST list.
This document also defines the SRv6-PCE-CAPABILITY sub-TLV. PCEP This document also defines the SRv6-PCE-CAPABILITY sub-TLV. PCEP
speakers use this sub-TLV to exchange information about their SRv6 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 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- PATH-SETUP-TYPE-CAPABILITY TLV, then it MUST also include the SRv6-
PCE-CAPABILITY sub-TLV inside the PATH-SETUP-TYPE-CAPABILITY TLV. PCE-CAPABILITY sub-TLV inside the PATH-SETUP-TYPE-CAPABILITY TLV.
For further error handling, please see Section 5. For further error handling, please see Section 5.
The format of the SRv6-PCE-CAPABILITY sub-TLV is shown in the The format of the SRv6-PCE-CAPABILITY sub-TLV is shown in Figure 1.
following figure.
0 1 2 3 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 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 | | Type=27 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |N| | | Reserved | Flags |N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSD-Type | MSD-Value | MSD-Type | MSD-Value | | MSD-Type | MSD-Value | MSD-Type | MSD-Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// ... // // ... //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSD-Type | MSD-Value | Padding | | MSD-Type | MSD-Value | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: SRv6-PCE-CAPABILITY sub-TLV format Figure 1: SRv6-PCE-CAPABILITY Sub-TLV Format
The code point for the TLV type is 27 and the format is compliant 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 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, 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 and a Value field. When set to 27, the Type field identifies the
SRv6-PCE-CAPABILITY sub-TLV and the presence of the sub-TLV indicates SRv6-PCE-CAPABILITY sub-TLV, and the presence of the sub-TLV
the support for the SRv6 paths in PCEP. The Length field defines the indicates the support for the SRv6 paths in PCEP. The Length field
length of the value portion in octets. The sub-TLV is padded to defines the length of the value portion in octets. The sub-TLV is
4-octet alignment, and padding is not included in the Length field. padded to 4-octet alignment, and padding is not included in the
The (MSD-Type,MSD-Value) pairs are OPTIONAL. The number of (MSD- Length field. The (MSD-Type,MSD-Value) pairs are OPTIONAL. The
Type,MSD-Value) pairs can be determined from the Length field of the number of (MSD-Type,MSD-Value) pairs can be determined by the Length
TLV. field of the TLV.
The value comprises of - The value is comprised of:
Reserved: 2 octet, this field MUST be set to 0 on transmission, * Reserved: 2 octets; this field MUST be set to 0 on transmission
and ignored on receipt. and ignored on receipt.
Flags: 2 octet, one bit is currently assigned in this document. * Flags: 2 octets; one bit is currently assigned in Section 8.6
Section 9.6
- N bit (bit position 14): A PCC sets this flag bit to 1 to - N bit (bit position 14): A PCC sets this flag bit to 1 to
indicate that it is capable of resolving a Node or Adjacency indicate that it is capable of resolving a Node or Adjacency
Identifier (NAI) to an SRv6-SID. Identifier (NAI) to an SRv6-SID.
- Unassigned bits MUST be set to 0 on transmission and ignored on - Unassigned bits MUST be set to 0 on transmission and ignored on
receipt receipt
A pair of (MSD-Type, MSD-Value): Where MSD-Type (1 octet) is as * A pair of (MSD-Type,MSD-Value): Where MSD-Type (1 octet) is as per
per the IGP MSD Type registry created by [RFC8491] and populated the IGP MSD Type registry created by [RFC8491] and populated with
with SRv6 MSD types as per [RFC9352]; MSD-Value (1 octet) is as SRv6 MSD types as per [RFC9352], and where MSD-Value (1 octet) is
per [RFC8491]. as per [RFC8491].
The SRv6 MSD information advertised via SRv6-PCE-Capability sub-TLV The SRv6 MSD information advertised via SRv6-PCE-Capability sub-TLV
conveys the SRv6 capabilities of the PCEP speaker alone. However, conveys the SRv6 capabilities of the PCEP speaker alone. However,
when it comes to the computation of an SR Policy for the SRv6 data- when it comes to the computation of an SR Policy for the SRv6 data
plane, the SRv6 MSD capabilities of all the intermediate SRv6 plane, the SRv6 MSD capabilities of the intermediate SRv6 Endpoint
Endpoint node as well as the tail-end node also need to be considered node and the tail-end node also need to be considered to ensure those
to ensure those midpoints are able to correctly process their midpoints are able to correctly process their segments and for the
segments and for the tail-end to dispose of the SRv6 encapsulation. tail-end to dispose of the SRv6 encapsulation. The SRv6 MSD
The SRv6 MSD capabilities of other nodes might be learned as part of capabilities of other nodes might be learned as part of the topology
the topology information via BGP-LS[RFC9514] or via PCEP if the PCE information via the Border Gateway Protocol - Link State (BGP-LS)
also happens to have PCEP sessions to those nodes. [RFC9514] or via PCEP if the PCE also happens to have PCEP sessions
with those nodes.
It is recommended that the SRv6 MSD information be not included in It is recommended that the SRv6 MSD information not be included in
the SRv6-PCE-Capability sub-TLV in deployments where the PCE is able the SRv6-PCE-Capability sub-TLV in deployments where the PCE is able
to obtain this via IGP/BGP-LS as part of the topology information. to obtain this via IGP/BGP-LS as part of the topology information.
4.2. The RP/SRP Object 4.2. The RP/SRP Object
This document defines a new Path Setup Type (PST=3) for SRv6. In 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 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 MUST include the PATH-SETUP-TYPE TLV as specified in [RFC8408], where
PST is set to 3. PST is set to 3.
4.3. ERO 4.3. ERO
In order to support SRv6, a new "SRv6-ERO" subobject is defined for In order to support SRv6, a new "SRv6-ERO" subobject is defined for
inclusion in the ERO. inclusion in the ERO.
4.3.1. SRv6-ERO Subobject 4.3.1. SRv6-ERO Subobject
An SRv6-ERO subobject is formatted as shown in the following figure. An SRv6-ERO subobject is formatted as shown in Figure 2.
0 1 2 3 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 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| |L| Type=40 | Length | NT | Flags |V|T|F|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Endpoint Behavior | | Reserved | Endpoint Behavior |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| SRv6 SID (conditional) | | SRv6 SID (conditional) |
| (128-bit) | | (128-bit) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// NAI (variable, conditional) // // NAI (variable, conditional) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| SID Structure (conditional) | | SID Structure (conditional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: SRv6-ERO Subobject Format Figure 2: SRv6-ERO Subobject Format
The fields in the SRv6-ERO subobject are as follows: The fields in the SRv6-ERO subobject are as follows:
The 'L' Flag: Indicates whether the subobject represents a loose-hop * The "L" flag: Indicates whether the subobject represents a loose
(see [RFC3209]). If this flag is set to zero, a PCC MUST NOT hop (see [RFC3209]). If this flag is set to zero, a PCC MUST NOT
overwrite the SID value present in the SRv6-ERO subobject. overwrite the SID value present in the SRv6-ERO subobject.
Otherwise, a PCC MAY expand or replace one or more SID values in the Otherwise, a PCC MAY expand or replace one or more SID values in
received SRv6-ERO based on its local policy. the received SRv6-ERO based on its local policy.
Type: indicates the content of the subobject, i.e. when the field is * Type: Indicates the content of the subobject, i.e., when the field
set to 40, the suboject is an SRv6-ERO subobject representing an SRv6 is set to 40, the subobject is an SRv6-ERO subobject representing
SID. an SRv6 SID.
Length: Contains the total length of the subobject in octets. The * 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 Length MUST be at least 24 and MUST be a multiple of 4. An
subobject MUST contain at least one of an SRv6-SID or an NAI. The S SRv6-ERO subobject MUST contain at least one of an SRv6-SID or an
and F bit in the Flags field indicates whether the SRv6-SID or NAI NAI. The S and F bits in the Flags field indicates whether the
fields are absent. SRv6-SID or NAI fields are absent.
NAI Type (NT): Indicates the type and format of the NAI contained in * NAI Type (NT): Indicates the type and format of the NAI contained
the object body, if any is present. If the F bit is set to one (see in the object body, if any are present. If the F bit is set to
below) then the NT field has no meaning and MUST be ignored by the one (see below), then the NT field has no meaning and MUST be
receiver. This document creates a new PCEP SRv6-ERO NAI Types ignored by the receiver. This document creates a new PCEP
registry in Section 9.2 and allocates the following values. SRv6-ERO NAI Types registry in Section 8.2 and allocates the
following values:
If NT value is 0, the NAI MUST NOT be included. - 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 - 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 defined in [RFC8664], which specifies an IPv6 address. This is
used to identify the owner of the SRv6 Identifier. 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 optional, as the LOC (the locator portion) of the SRv6 SID
a similar purpose (when present). serves a similar purpose (when present).
When NT value is 4, the NAI is as per the 'IPv6 Adjacency' format - When NT value is 4, the NAI is as per the "IPv6 adjacency"
defined in [RFC8664], which specify a pair of IPv6 addresses. format defined in [RFC8664], which specify a pair of IPv6
This is used to identify the IPv6 Adjacency and used with the SRv6 addresses. This is used to identify the IPv6 adjacency and
Adj-SID. used with the SRv6 Adj-SID.
When NT value is 6, the NAI is as per the 'link-local IPv6 - When NT value is 6, the NAI is as per the "link-local IPv6
addresses' format defined in [RFC8664], which specify a pair of addresses" format defined in [RFC8664], which specify a pair of
(global IPv6 address, interface ID) tuples. It is used to (global IPv6 address, interface ID) tuples. It is used to
identify the IPv6 Adjacency and used with the SRv6 Adj-SID. identify the IPv6 adjacency and used with the SRv6 Adj-SID.
Flags: Used to carry additional information pertaining to the * Flags: Used to carry additional information pertaining to the
SRv6-SID. This document defines the following flag bits. The other SRv6-SID. This document defines the following flag bits. The
bits MUST be set to zero by the sender and MUST be ignored by the other bits MUST be set to zero by the sender and MUST be ignored
receiver. This document creates a new registry SRv6-ERO Flag Field by the receiver. This document creates a new registry SRv6-ERO
registry in Section 9.3 and allocates the following values. Flag Field registry in Section 8.3 and allocates the following
values.
* S: When this bit is set to 1, the SRv6-SID value in the subobject - S: When this bit is set to 1, the SRv6-SID value in the
body is absent. In this case, the PCC is responsible for choosing subobject body is absent. In this case, the PCC is responsible
the SRv6-SID value, e.g., by looking up in the SR-DB using the NAI for choosing the SRv6-SID value, e.g., by looking up in the SR-
which, in this case, MUST be present in the subobject. If the S DB using the NAI that, in this case, MUST be present in the
bit is set to 1 then F bit MUST be set to zero. subobject. If the S bit is set to 1, then the F bit MUST be
set to zero.
* F: When this bit is set to 1, the NAI value in the subobject body - F: When this bit is set to 1, the NAI value in the subobject
is absent. The F bit MUST be set to 1 if NT=0, and otherwise MUST body is absent. The F bit MUST be set to 1 if NT=0; otherwise,
be set to zero. The S and F bits MUST NOT both be set to 1. it 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 - 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 subobject body is present. The T bit MUST be set to 0 when the
is set to 1. If the T bit is set when the S bit is set, the T bit S bit is set to 1. If the T bit is set when the S bit is set,
MUST be ignored. Thus, the T bit indicates the presence of an the T bit MUST be ignored. Thus, the T bit indicates the
optional 8-byte SID Structure when SRv6 SID is included. The SID presence of an optional 8-byte SID Structure when SRv6 SID is
Structure is defined in Section 4.3.1.1. included. The SID Structure is defined in Section 4.3.1.1.
* V: The "SID verification" bit usage is as per Section 5.1 of - V: The "SID verification" bit usage is as per Section 5.1 of
[RFC9256]. If a PCC "Verification fails" for a SID, it MUST [RFC9256]. If a PCC "Verification fails" for a SID, it MUST
report this error by including the LSP-ERROR-CODE TLV with LSP report this error by including the LSP-ERROR-CODE TLV with LSP
error-value "SID Verification fails" in the LSP object in the Error-value "SID Verification fails" in the LSP object in the
PCRpt message to the PCE. PCRpt message to the PCE.
Reserved: MUST be set to zero while sending and ignored on receipt. * Reserved: MUST be set to zero while sending and ignored on
receipt.
Endpoint Behavior: A 16-bit field representing the behavior * Endpoint Behavior: A 16-bit field representing the behavior
associated with the SRv6 SIDs. This information is optional, but it associated with the SRv6 SIDs. This information is optional, but
is recommended to signal it always if possible. It could be used for providing it is recommended whenever possible. It could be used
maintainability and diagnostic purpose. If behavior is not known, for maintainability and diagnostic purposes. If behavior is not
value '0xFFFF' defined in the registry "SRv6 Endpoint Behaviors" is known, value "0xFFFF" as defined in the "SRv6 Endpoint Behaviors"
used [RFC8986]. registry is used [RFC8986].
SRv6 SID: SRv6 Identifier is an 128-bit value representing the SRv6 * SRv6 SID: SRv6 Identifier is a 128-bit value representing the SRv6
segment. segment.
NAI: The NAI associated with the SRv6-SID. The NAI's format depends * NAI: The NAI associated with the SRv6-SID. The NAI's format
on the value in the NT field, and is described in [RFC8664]. 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 At least one SRv6-SID or the NAI MUST be included in the SRv6-ERO
subobject, and both MAY be included. subobject, and both MAY be included.
4.3.1.1. SID Structure 4.3.1.1. SID Structure
The SID Structure is an optional part of the SR-ERO subobject, as The SID Structure is an optional part of the SR-ERO subobject, as
described in Section 4.3.1. described in Section 4.3.1.
[RFC8986] defines an SRv6 SID as consisting of LOC:FUNCT:ARG, where a [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, 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). 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 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 block (IPv6 prefix allocated for SRv6 SIDs by the operator) and N is
the identifier of the parent node instantiating the SID called the identifier of the parent node instantiating the SID called
locator node. "locator node".
It is formatted as shown in the following figure. The SID Structure is formatted as shown in Figure 3.
0 1 2 3 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 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 | | LB Length | LN Length | Fun. Length | Arg. Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags | | Reserved | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: SID Structure Format Figure 3: SID Structure Format
where: Where:
LB Length: 1 octet. SRv6 SID Locator Block length in bits. * LB Length: 1 octet; SRv6 SID Locator Block length in bits
LN Length: 1 octet. SRv6 SID Locator Node length in bits. * LN Length: 1 octet; SRv6 SID Locator Node length in bits
Fun. Length: 1 octet. SRv6 SID Function length in bits. * Fun. Length: 1 octet; SRv6 SID Function length in bits
Arg. Length: 1 octet. SRv6 SID Arguments 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 The sum of all four sizes in the SID Structure must be less than or
to 128 bits. If the sum of all four sizes advertised in the SID equal to 128 bits. If the sum of all four sizes advertised in the
Structure is larger than 128 bits, the corresponding SRv6 SID MUST be SID Structure is larger than 128 bits, the corresponding SRv6 SID
considered invalid and a PCErr message with Error-Type = 10 MUST be considered invalid and a PCErr message with Error-Type = 10
("Reception of an invalid object") and Error-Value = 37 ("Invalid ("Reception of an invalid object") and Error-value = 37 ("Invalid
SRv6 SID Structure") is returned. SRv6 SID Structure") is returned.
Reserved: MUST be set to zero while sending and ignored on receipt. * Reserved: MUST be set to zero while sending and ignored on
receipt.
Flags: Currently no flags are defined. Unassigned bits must be set * Flags: Currently no flags are defined.
to zero while sending and ignored on receipt.
* Unassigned bits must be set to zero while sending and ignored on
receipt.
The SRv6 SID Structure provides the detailed encoding information of The SRv6 SID Structure provides the detailed encoding information of
an SRv6 SID, which is useful in the use cases that require to know an SRv6 SID, which is helpful in the use cases that require the SRv6
the SRv6 SID structure. When a PCEP speaker receives the SRv6 SID SID structure to be known. When a PCEP speaker receives the SRv6 SID
and its structure information, the SRv6 SID can be parsed based on and its structure information, the SRv6 SID can be parsed based on
the SRv6 SID Structure and/or possible local policies. The SRv6 SID the SRv6 SID Structure and/or possible local policies. The SRv6 SID
Structure could be used by the PCE for ease of operations and Structure could be used by the PCE for ease of operations and
monitoring. For example, this information could be used for monitoring. For example, this information could be used for
validation of SRv6 SIDs being instantiated in the network and checked validation of SRv6 SIDs being instantiated in the network and checked
for conformance to the SRv6 SID allocation scheme chosen by the for conformance with the SRv6 SID allocation scheme chosen by the
operator as described in Section 3.2 of [RFC8986]. In the future, operator as described in Section 3.2 of [RFC8986]. In the future,
PCE might also be utilized to verify and automate the security of the PCE might also be utilized to verify and automate the security of the
SRv6 domain by provisioning filtering rules at the domain boundaries SRv6 domain by provisioning filtering rules at the domain boundaries
as described in Section 5 of [RFC8754]. The details of these as described in Section 5 of [RFC8754]. The details of these
potential applications are outside the scope of this document. potential applications are outside the scope of this document.
4.3.1.2. Order of the Optional fields 4.3.1.2. Order of the Optional Fields
The optional elements in the SRv6-ERO subobject i.e. SRv6 SID, NAI 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 and the SID Structure, MUST be encoded in the order as depicted in
Figure 2. The presence or absence of each of them is indicated by Figure 2. The presence or absence of each of them is indicated by
the respective flags i.e. S flag, F flag and T flag. the respective flags, i.e., S flag, F flag, and T flag.
In order to ensure future compatibility, any optional elements added In order to ensure future compatibility, any optional elements added
to the SRv6-ERO subobject in the future must specify their order and to the SRv6-ERO subobject in the future must specify their order and
request the Internet Assigned Numbers Authority (IANA) to allocate a request that the Internet Assigned Numbers Authority (IANA) allocate
flag to indicate their presence from the subregistry created in a flag to indicate their presence from the subregistry created in
Section 9.3. Section 8.3.
4.4. RRO 4.4. RRO
In order to support SRv6, a new "SRv6-RRO" subobject is defined for In order to support SRv6, a new "SRv6-RRO" subobject is defined for
inclusion in the RRO. inclusion in the RRO.
4.4.1. SRv6-RRO Subobject 4.4.1. SRv6-RRO Subobject
A PCC reports an SRv6 path to a PCE by sending a PCRpt message, per 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 [RFC8231]. The RRO on this message represents the SID list that was
applied by the PCC, that is, the actual path taken. The procedures applied by the PCC, that is, the actual path taken. The procedures
of [RFC8664] with respect to the RRO apply equally to this of [RFC8664] with respect to the RRO apply equally to this
specification without change. specification without change.
An RRO contains one or more subobjects called "SRv6-RRO subobjects" An RRO contains one or more subobjects called "SRv6-RRO subobjects",
whose format is shown below. whose format is shown in Figure 4.
0 1 2 3 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 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| | Type=40 | Length | NT | Flags |V|T|F|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Endpoint Behavior | | Reserved | Endpoint Behavior |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| SRv6 SID(optional) | | SRv6 SID(optional) |
| (128-bit) | | (128-bit) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// NAI (variable) // // NAI (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| SID Structure (optional) | | SID Structure (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: SRv6-RRO Subobject Format Figure 4: SRv6-RRO Subobject Format
The format of the SRv6-RRO subobject is the same as that of the The format of the SRv6-RRO subobject is the same as that of the
SRv6-ERO subobject, but without the L flag. SRv6-ERO subobject but without the L flag.
The V flag has no meaning in the SRv6-RRO and is ignored on receipt The V flag has no meaning in the SRv6-RRO and is ignored on receipt
at the PCE. at the PCE.
Ordering of SRv6-RRO subobjects by PCC in PCRpt message remains as The ordering of SRv6-RRO subobjects by PCC in PCRpt message remains
per [RFC8664]. as per [RFC8664].
The ordering of optional elements in the SRv6-RRO subobject is the The ordering of optional elements in the SRv6-RRO subobject is the
same as described in Section 4.3.1.2. same as described in Section 4.3.1.2.
5. Procedures 5. Procedures
5.1. Exchanging the SRv6 Capability 5.1. Exchanging the SRv6 Capability
A PCC indicates that it is capable of supporting the head-end A PCC indicates that it is capable of supporting the head-end
functions for SRv6 by including the SRv6-PCE-CAPABILITY sub-TLV in 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 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 capable of computing SRv6 paths by including the SRv6-PCE-CAPABILITY
sub-TLV in the Open message that it sends to a PCC. 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 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 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- absent, then the PCEP speaker MUST send a PCErr message with Error-
Type = 10 (Reception of an invalid object) and Error-Value = 34 Type = 10 ("Reception of an invalid object") and Error-Value = 34
(Missing PCE-SRv6-CAPABILITY sub-TLV) and MUST then close the PCEP ("Missing PCE-SRv6-CAPABILITY sub-TLV") and MUST then close the PCEP
session. If a PCEP speaker receives a PATH-SETUP-TYPE-CAPABILITY TLV 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 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- contain PST=3, then the PCEP speaker MUST ignore the SRv6-PCE-
CAPABILITY sub-TLV. CAPABILITY sub-TLV.
In case the MSD-Type in SRv6-PCE-CAPABILITY sub-TLV received by the In case the MSD-Type in the SRv6-PCE-CAPABILITY sub-TLV received by
PCE does not correspond to one of the SRv6 MSD types, the PCE MUST the PCE does not correspond to one of the SRv6 MSD types, the PCE
respond with a PCErr message (Error-Type = 1 "PCEP session MUST respond with a PCErr message (Error-Type = 1 ("PCEP session
establishment failure" and Error-Value = 1 "reception of an invalid establishment failure") and Error-Value = 1 ("reception of an invalid
Open message or a non Open message."). Open message or a non Open message.")).
Note that the MSD-Type, MSD-Value exchanged via the SRv6-PCE- Note that the (MSD-Type,MSD-Value) pair exchanged via the SRv6-PCE-
CAPABILITY sub-TLV indicates the SRv6 SID imposition limit for the CAPABILITY sub-TLV indicates the SRv6 SID imposition limit for the
sender PCC node only. However, if a PCE learns these via alternate sender PCC node only. However, if a PCE learns these via alternate
mechanisms, e.g. routing protocols [RFC9352], then it ignores the mechanisms, e.g., routing protocols [RFC9352], then it ignores the
values in the SRv6-PCE-CAPABILITY sub-TLV. Furthermore, whenever a 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 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 via alternate mechanisms, it MUST use those values regardless of the
values exchanged in the SRv6-PCE-CAPABILITY sub-TLV. values exchanged in the SRv6-PCE-CAPABILITY sub-TLV.
During path computation, PCE must consider the MSD information of all During path computation, a PCE must consider the MSD information of
the nodes along the path instead of only the MSD information of the all the nodes along the path instead of only the MSD information of
ingress PCC since a packet may be dropped on any node in a forwarding the ingress PCC since a packet may be dropped on any node in a
path because of MSD exceeding. The MSD capabilities of all SR nodes forwarding path because of the SID depth exceeding the MSD of the
along the path can be learned as part of the topology information via node. The MSD capabilities of all SR nodes along the path can be
IGP/BGP-LS or via PCEP if the PCE also happens to have PCEP sessions learned as part of the topology information via IGP/BGP-LS or via
to those nodes. PCEP if the PCE also happens to have PCEP sessions with those nodes.
A PCE MUST NOT send SRv6 paths exceeding the SRv6 MSD capabilities of A PCE MUST NOT send SRv6 paths that exceed the SRv6 MSD capabilities
the PCC. If a PCC needs to modify the SRv6 MSD value signaled via of the PCC. 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 the Open message, it MUST close the PCEP session and re-establish it
with the new value. If the PCC receives an SRv6 path that exceed its with the new value. If the PCC receives an SRv6 path that exceeds
SRv6 MSD capabilities, the PCC MUST send a PCErr message with Error- its SRv6 MSD capabilities, the PCC MUST send a PCErr message with
Type = 10 (Reception of an invalid object) and Error-Value = 39 Error-Type = 10 ("Reception of an invalid object") and Error-value =
(Unsupported number of SRv6-ERO subobjects). 40 ("Unsupported number of SRv6-ERO subobjects").
The N flag and (MSD-Type,MSD-Value) pair inside the SRv6-PCE- The N flag and (MSD-Type,MSD-Value) pair inside the SRv6-PCE-
CAPABILITY sub-TLV are meaningful only in the Open message sent to a 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- 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 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 flags an Open message sent to a PCC. Similarly, a PCC MUST ignore flags
and any (MSD-Type,MSD-Value) pair in a received Open message. If a 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 PCE receives multiple SRv6-PCE-CAPABILITY sub-TLVs in an Open
message, it processes only the first sub-TLV received. message, it processes only the first sub-TLV received.
skipping to change at page 15, line 28 skipping to change at line 677
5.2.1. SRv6 ERO Validation 5.2.1. SRv6 ERO Validation
If a PCC does not support the SRv6 PCE Capability and thus cannot If a PCC does not support the SRv6 PCE Capability and thus cannot
recognize the SRv6-ERO or SRv6-RRO subobjects, it should respond recognize the SRv6-ERO or SRv6-RRO subobjects, it should respond
according to the rules for a malformed object as described in according to the rules for a malformed object as described in
[RFC5440]. [RFC5440].
On receiving an SRv6-ERO, a PCC MUST validate that the Length field, 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 the S bit, the F bit, the T bit, and the NT field are consistent, as
follows. follows:
* If NT=0, the F bit MUST be 1, the S bit MUST be zero and the * If NT=0, the F bit MUST be 1, the S bit MUST be zero, and the
Length MUST be 24. Length MUST be 24.
* If NT=2, the F bit MUST be zero. If the S bit is 1, the Length * 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. 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 * 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. 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 * 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. MUST be 48; otherwise, the Length MUST be 64.
* If T bit is 1, then S bit MUST be zero. * If the T bit is 1, then the S bit MUST be zero.
If a PCC finds that the NT field, Length field, S bit, F bit, and T 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 bit are not consistent, it MUST consider the entire ERO invalid and
MUST send a PCErr message with Error-Type = 10 ("Reception of an MUST send a PCErr message with Error-Type = 10 ("Reception of an
invalid object") and Error-Value = 11 ("Malformed object"). invalid object") and Error-value = 11 ("Malformed object").
If a PCC does not recognize or support the value in the NT field, it 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 MUST consider the entire ERO invalid and send a PCErr message with
Error-Type = 10 ("Reception of an invalid object") and Error- value = Error-Type = 10 ("Reception of an invalid object") and Error-value =
40 ("Unsupported NAI Type in the SRv6-ERO/SRv6-RRO subobject"). 41 ("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 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 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- consider the entire ERO invalid and send a PCErr message with Error-
Type = 10 ("Reception of an invalid object") and Error-value = 41 Type = 10 ("Reception of an invalid object") and Error-value = 42
("Both SID and NAI are absent in the SRv6-ERO subobject"). ("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 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 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 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- consider the entire ERO invalid and send a PCErr message with Error-
Type = 4 ("Not supported object") and Error-value = 4 ("Unsupported Type = 4 ("Not supported object") and Error-value = 4 ("Unsupported
parameter"). parameter").
If a PCC detects that the subobjects of an ERO are a mixture of SRv6- If a PCC detects that the subobjects of an ERO are a mixture of
ERO subobjects and subobjects of other types, then it MUST send a SRv6-ERO subobjects and subobjects of other types, then it MUST send
PCErr message with Error-Type = 10 ("Reception of an invalid object") a PCErr message with Error-Type = 10 ("Reception of an invalid
and Error-value = 42 ("ERO mixes SRv6-ERO subobjects with other object") and Error-value = 43 ("ERO mixes SRv6-ERO subobjects with
subobject types"). other subobject types").
In case a PCEP speaker receives an SRv6-ERO subobject, when the PST 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 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") MUST send a PCErr message with Error-Type = 19 ("Invalid Operation")
and Error-Value = 19 ("Attempted SRv6 when the capability was not and Error-value = 19 ("Attempted SRv6 when the capability was not
advertised"). advertised").
If a PCC receives an SRv6 path that exceeds the SRv6 MSD If a PCC receives an SRv6 path that exceeds the SRv6 MSD
capabilities, it MUST send a PCErr message with Error-Type = 10 capabilities, it MUST send a PCErr message with Error-Type = 10
("Reception of an invalid object") and Error-Value = 43 ("Unsupported ("Reception of an invalid object") and Error-value = 40 ("Unsupported
number of SRv6-ERO subobjects") as per [RFC8664]. number of SRv6-ERO subobjects") as per [RFC8664].
5.2.2. Interpreting the SRv6-ERO 5.2.2. Interpreting the SRv6-ERO
The SRv6-ERO contains a sequence of subobjects. According to The SRv6-ERO contains a sequence of subobjects. According to
[RFC9256], each SRv6-ERO subobject in the sequence identifies a [RFC9256], each SRv6-ERO subobject in the sequence identifies a
segment that the traffic will be directed to, in the order given. segment that the traffic will be directed to, in the order given.
That is, the first subobject identifies the first segment the traffic That is, the first subobject identifies the first segment the traffic
will be directed to, the second SRv6-ERO subobject represents the will be directed to, the second SRv6-ERO subobject represents the
second segment, and so on. second segment, and so on.
5.3. RRO Processing 5.3. RRO Processing
The syntax checking rules that apply to the SRv6-RRO subobject are The syntax-checking rules that apply to the SRv6-RRO subobject are
identical to those of the SRv6-ERO subobject, except as noted below. 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 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 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 send a PCErr message with Error-Type = 10 ("Reception of an invalid
object") and Error-Value = 35 ("Both SID and NAI are absent in object") and Error-value = 35 ("Both SID and NAI are absent in
SRv6-RRO subobject"). SRv6-RRO subobject").
If a PCE detects that the subobjects of an RRO are a mixture of 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 SRv6-RRO subobjects and subobjects of other types, then it MUST send
a PCErr message with Error-Type = 10 ("Reception of an invalid a PCErr message with Error-Type = 10 ("Reception of an invalid
object") and Error-Value = 36 ("RRO mixes SRv6-RRO subobjects with object") and Error-value = 36 ("RRO mixes SRv6-RRO subobjects with
other subobject types"). other subobject types").
The mechanism by which the PCC learns the path is outside the scope The mechanism by which the PCC learns the path is outside the scope
of this document. of this document.
6. Security Considerations 6. Security Considerations
The security considerations described in [RFC5440], section 2.5 of The Security Considerations described in [RFC5440], Section 2.5 of
[RFC6952], [RFC8231], [RFC8281], [RFC8253] and [RFC8664] are [RFC6952], [RFC8231], [RFC8281], [RFC8253], and [RFC8664] are
applicable to this specification. applicable to this specification.
Note that this specification enables a network controller to Note that this specification enables a network controller to
instantiate an SRv6 path in the network. This creates an additional instantiate an SRv6 path in the network. This creates an additional
vulnerability if the security mechanisms of [RFC5440], [RFC8231], and vulnerability if the security mechanisms of [RFC5440], [RFC8231], and
[RFC8281] are not used. If there is no integrity protection on the [RFC8281] are not used. If there is no integrity protection on the
session, then an attacker could create an SRv6 path that may not session, then an attacker could create an SRv6 path that may not be
subjected to the further verification checks. Further, the MSD field subjected to the further verification checks. Further, the MSD field
in the Open message could disclose node forwarding capabilities if in the Open message could disclose node forwarding capabilities if
suitable security mechanisms are not in place. Hence, securing the suitable security mechanisms are not in place. Hence, securing the
PCEP session using Transport Layer Security (TLS) [RFC8253] is PCEP session using Transport Layer Security (TLS) [RFC8253] is
RECOMMENDED. RECOMMENDED.
7. Manageability Considerations 7. Manageability Considerations
All manageability requirements and considerations listed in All manageability requirements and considerations listed in
[RFC5440], [RFC8231], [RFC8281], and [RFC8664] apply to PCEP protocol [RFC5440], [RFC8231], [RFC8281], and [RFC8664] apply to PCEP protocol
extensions defined in this document. In addition, requirements and extensions defined in this document. In addition, requirements and
considerations listed in this section apply. considerations listed in this section apply.
7.1. Control of Function and Policy 7.1. Control of Function and Policy
A PCEP implementation SHOULD allow the operator to configure the SRv6 A PCEP implementation SHOULD allow the operator to configure the SRv6
capability. Further a policy to accept NAI only for the SRv6 SHOULD capability. Further, a policy to accept NAI only for the SRv6 SHOULD
be allowed to be set. be allowed to be set.
7.2. Information and Data Models 7.2. Information and Data Models
The PCEP YANG module is out of the scope of this document and defined The PCEP YANG module is out of the scope of this document; it is
in other documents, for example, [I-D.ietf-pce-pcep-yang]. An defined in other documents, for example, [PCEP-YANG]. An augmented
augmented YANG module for SRv6 is also specified in another document YANG module for SRv6 is also specified in [PCEP-SRv6-YANG] that
[I-D.ietf-pce-pcep-srv6-yang] that allows for SRv6 capability and MSD allows for SRv6 capability and MSD configurations as well as to
configurations as well as to monitor the SRv6 paths set in the monitor the SRv6 paths set in the network.
network.
7.3. Liveness Detection and Monitoring 7.3. Liveness Detection and Monitoring
Mechanisms defined in this document do not imply any new liveness Mechanisms defined in this document do not imply any new liveness
detection and monitoring requirements in addition to those already detection and monitoring requirements in addition to those already
listed in [RFC5440]. listed in [RFC5440].
7.4. Verify Correct Operations 7.4. Verify Correct Operations
Verification of the mechanisms defined in this document can be built Verification of the mechanisms defined in this document can be built
on those already listed in [RFC5440], [RFC8231], and [RFC8664]. on those already listed in [RFC5440], [RFC8231], and [RFC8664].
7.5. Requirements On Other Protocols 7.5. Requirements on Other Protocols
Mechanisms defined in this document do not imply any new requirements Mechanisms defined in this document do not imply any new requirements
on other protocols. on other protocols.
7.6. Impact On Network Operations 7.6. Impact on Network Operations
Mechanisms defined in [RFC5440], [RFC8231], and [RFC8664] also apply Mechanisms defined in [RFC5440], [RFC8231], and [RFC8664] also apply
to PCEP extensions defined in this document. to PCEP extensions defined in this document.
8. Implementation Status 8. IANA Considerations
[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".
8.1. Cisco's Commercial Delivery
* Organization: Cisco Systems, Inc.
* Implementation: IOS-XR PCE and PCC.
* Description: Implementation with experimental codepoints.
* Maturity Level: Production
* Coverage: Partial
* Contact: ssidor@cisco.com
8.2. Huawei's Commercial Delivery
* Organization: Huawei Technologies Co.,Ltd.
* Implementation: Huawei Routers and NCE Controller
* Description: Huawei has Implemented this draft to support PCE- 8.1. PCEP ERO and RRO Subobjects
Initiated SRv6 Policy.
* Maturity Level: Production 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). These have been registered in the "Resource
Reservation Protocol (RSVP) Parameters" registry group as shown
below.
* Coverage: Partial IANA has allocated the following new subobject in the "Subobject type
- 20 EXPLICIT_ROUTE - Type 1 Explicit Route" registry:
* Contact: yuwei.yuwei@huawei.com +=======+==========================+
| Value | Description |
+=======+==========================+
| 40 | SRv6-ERO (PCEP-specific) |
+-------+--------------------------+
9. IANA Considerations Table 1
9.1. PCEP ERO and RRO subobjects IANA has allocated the following new subobject in the "Subobject type
- 21 ROUTE_RECORD - Type 1 Route Record" registry:
This document defines a new subobject type for the PCEP explicit +=======+==========================+
route object (ERO), and a new subobject type for the PCEP reported | Value | Description |
route object (RRO). The code points for subobject types of these +=======+==========================+
objects is maintained in the RSVP parameters registry, under the | 40 | SRv6-RRO (PCEP-specific) |
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 Table 2
--------------------- -------------------------- ------------------
EXPLICIT_ROUTE SRv6-ERO (PCEP-specific) 40
ROUTE_RECORD SRv6-RRO (PCEP-specific) 40
9.2. New SRv6-ERO NAI Type Registry 8.2. New SRv6-ERO NAI Type Registry
IANA is requested to create a new sub-registry, named "PCEP SRv6-ERO IANA has created the "PCEP SRv6-ERO NAI Types" registry within the
NAI Types", within the "Path Computation Element Protocol (PCEP) "Path Computation Element Protocol (PCEP) Numbers" registry group to
Numbers" registry to manage the 4-bit NT field in SRv6-ERO subobject. manage the 4-bit NT field in the SRv6-ERO subobject. The
The allocation policy for this new registry is by IETF registration policy is IETF Review [RFC8126]. IANA has registered
Review[RFC8126].The new registry contains the following values. the values in Table 3.
Value Description Reference +=======+===============================+===========+
----- ----------- --------- | Value | Description | Reference |
0 NAI is absent. This document +=======+===============================+===========+
1 Unassigned | 0 | NAI is absent. | RFC 9603 |
2 NAI is an IPv6 node ID. This document +-------+-------------------------------+-----------+
3 Unassigned | 2 | NAI is an IPv6 node ID. | RFC 9603 |
4 NAI is an IPv6 adjacency This document +-------+-------------------------------+-----------+
with global IPv6 addresses. | 4 | NAI is an IPv6 adjacency with | RFC 9603 |
| | global IPv6 addresses. | |
+-------+-------------------------------+-----------+
| 6 | NAI is an IPv6 adjacency with | RFC 9603 |
| | link-local IPv6 addresses. | |
+-------+-------------------------------+-----------+
5 Unassigned Table 3
6 NAI is an IPv6 adjacency This document
with link-local IPv6 addresses.
7-15 Unassigned
9.3. New SRv6-ERO Flag Registry 8.3. New SRv6-ERO Flag Registry
IANA is requested to create a new sub-registry, named "SRv6-ERO Flag IANA has created the "SRv6-ERO Flag Field" registry within the "Path
Field", within the "Path Computation Element Protocol (PCEP) Numbers" Computation Element Protocol (PCEP) Numbers" registry group to manage
registry to manage the 12-bit Flag field of the SRv6-ERO subobject. the 12-bit Flag field of the SRv6-ERO subobject. New values are to
New values are to be assigned by Standards Action [RFC8126]. Each be assigned by Standards Action [RFC8126]. Each registration should
bit should be tracked with the following qualities. include the following information:
* Bit (counting from bit 0 as the most significant bit) * Bit (counting from bit 0 as the most significant bit)
* Description * Description
* Reference * Reference
The following values are defined in this document. The following values are defined in this document:
Bit Description Reference +=====+==============================+===========+
----- ------------------ -------------- | Bit | Description | Reference |
0-7 Unassigned +=====+==============================+===========+
8 SID Verification (V) This document | 8 | SID Verification (V) | RFC 9603 |
9 SID Structure is This document +-----+------------------------------+-----------+
present (T) | 9 | SID Structure is present (T) | RFC 9603 |
10 NAI is absent (F) This document +-----+------------------------------+-----------+
11 SID is absent (S) This document | 10 | NAI is absent (F) | RFC 9603 |
+-----+------------------------------+-----------+
| 11 | SID is absent (S) | RFC 9603 |
+-----+------------------------------+-----------+
9.4. LSP-ERROR-CODE TLV Table 4
This document defines a new value in the sub-registry "LSP-ERROR-CODE 8.4. LSP-ERROR-CODE TLV
TLV Error Code Field" in the "Path Computation Element Protocol(PCEP)
Numbers" registry.
Value Meaning Reference This document defines a new value in "LSP-ERROR-CODE TLV Error Code
--- ----------------------- ----------- Field" registry within the "Path Computation Element Protocol (PCEP)
TBD SID Verification fails This document Numbers" registry group.
9.5. PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators +=======+========================+===========+
| Value | Meaning | Reference |
+=======+========================+===========+
| 10 | SID Verification fails | RFC 9603 |
+-------+------------------------+-----------+
IANA maintains a sub-registry, named "PATH-SETUP-TYPE-CAPABILITY Sub- Table 5
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 8.5. PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators
----- ------- ---------
27 SRv6-PCE-CAPABILITY This Document
9.6. SRv6 PCE Capability Flags IANA maintains the "PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type
Indicators" registry within the "Path Computation Element Protocol
(PCEP) Numbers" registry group to manage the type indicator space for
sub-TLVs of the PATH-SETUP-TYPE-CAPABILITY TLV. IANA has registered
the following value:
IANA is requested to create a new sub-registry, named "SRv6 +=======+=====================+===========+
Capability Flag Field", within the "Path Computation Element Protocol | Value | Meaning | Reference |
(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 | 27 | SRv6-PCE-CAPABILITY | RFC 9603 |
Action [RFC8126]. Each bit should be tracked with the following +-------+---------------------+-----------+
qualities.
Table 6
8.6. SRv6 PCE Capability Flags
IANA has created the "SRv6 Capability Flag Field" registry within the
"Path Computation Element Protocol (PCEP) Numbers" registry group 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
registration should include the following information:
* Bit (counting from bit 0 as the most significant bit) * Bit (counting from bit 0 as the most significant bit)
* Description * Description
* Reference * Reference
The following values are defined in this document. The following value is defined in this document.
Bit Description Reference +=====+==============================+===========+
----- ------------------ -------------- | Bit | Description | Reference |
0-13 Unassigned +=====+==============================+===========+
14 Node or Adjacency This document | 14 | Node or Adjacency Identifier | RFC 9603 |
Identifier (NAI) is | | (NAI) is supported (N) | |
supported (N) +-----+------------------------------+-----------+
15 Unassigned
9.7. New Path Setup Type Table 7
[RFC8408] created a sub-registry within the "Path Computation Element 8.7. New Path Setup Type
Protocol (PCEP) Numbers" registry called "PCEP Path Setup Types".
IANA is requested to confirm the following allocations in the sub-
registry.
Value Description Reference [RFC8408] created the "PCEP Path Setup Types" registry within the
----- ----------- --------- "Path Computation Element Protocol (PCEP) Numbers" registry group.
3 Traffic engineering path is This Document IANA has allocated the following value:
setup using SRv6.
9.8. ERROR Objects +=======+==========================+===========+
| Value | Description | Reference |
+=======+==========================+===========+
| 3 | Traffic engineering path | RFC 9603 |
| | is set up using SRv6. | |
+-------+--------------------------+-----------+
IANA is requested to confirm the following allocations in the PCEP- Table 8
ERROR Object Error Types and Values registry for the following new
error-values.
Error-Type Meaning 8.8. ERROR Objects
---------- -------
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 new allocations in the PCEP-ERROR Object IANA has allocated the following Error-values in the "PCEP-ERROR
Error Types and Values registry for the following new error-values. Object Error Types and Values" registry within the "Path Computation
Element Protocol (PCEP) Numbers" registry group:
Error-Type Meaning +============+=================+===================================+
---------- ------- | Error-Type | Meaning | Error-value |
10 Reception of an invalid object +============+=================+===================================+
Error-value = TBD (Unsupported number of | 10 | Reception of an | 34: Missing PCE-SRv6-CAPABILITY |
SRv6-ERO subobjects) | | invalid object | sub-TLV |
Error-value = TBD (Unsupported NAI Type | | +-----------------------------------+
in the SRv6-ERO/SRv6-RRO subobject) | | | 35: Both SID and NAI are absent |
Error-value = TBD (Both SID and NAI are | | | in SRv6-RRO subobject |
absent in the SRv6-ERO subobject) | | +-----------------------------------+
Error-value = TBD (ERO mixes SRv6-ERO | | | 36: RRO mixes SRv6-RRO subobjects |
subobjects with other subobject types) | | | with other subobject types |
Error-value = TBD (Unsupported number | | +-----------------------------------+
of SRv6-ERO subobjects) | | | 37: Invalid SRv6 SID Structure |
| | +-----------------------------------+
| | | 40: Unsupported number of |
| | | SRv6-ERO subobjects |
| | +-----------------------------------+
| | | 41: Unsupported NAI Type in the |
| | | SRv6-ERO/SRv6-RRO subobject |
| | +-----------------------------------+
| | | 42: Both SID and NAI are absent |
| | | in the SRv6-ERO subobject |
| | +-----------------------------------+
| | | 43: ERO mixes SRv6-ERO subobjects |
| | | with other subobject types |
+------------+-----------------+-----------------------------------+
| 19 | Invalid | 19: Attempted SRv6 when the |
| | Operation | capability was not advertised |
+------------+-----------------+-----------------------------------+
10. References Table 9
10.1. Normative References 9. References
9.1. Normative References
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/rfc/rfc3209>. <https://www.rfc-editor.org/info/rfc3209>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440, Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009, DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/rfc/rfc5440>. <https://www.rfc-editor.org/info/rfc5440>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/rfc/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
Computation Element Communication Protocol (PCEP) Computation Element Communication Protocol (PCEP)
Extensions for Stateful PCE", RFC 8231, Extensions for Stateful PCE", RFC 8231,
DOI 10.17487/RFC8231, September 2017, DOI 10.17487/RFC8231, September 2017,
<https://www.rfc-editor.org/rfc/rfc8231>. <https://www.rfc-editor.org/info/rfc8231>.
[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
Computation Element Communication Protocol (PCEP) Computation Element Communication Protocol (PCEP)
Extensions for PCE-Initiated LSP Setup in a Stateful PCE Extensions for PCE-Initiated LSP Setup in a Stateful PCE
Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,
<https://www.rfc-editor.org/rfc/rfc8281>. <https://www.rfc-editor.org/info/rfc8281>.
[RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J.
Hardwick, "Conveying Path Setup Type in PCE Communication Hardwick, "Conveying Path Setup Type in PCE Communication
Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408,
July 2018, <https://www.rfc-editor.org/rfc/rfc8408>. July 2018, <https://www.rfc-editor.org/info/rfc8408>.
[RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, [RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg,
"Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491, "Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491,
DOI 10.17487/RFC8491, November 2018, DOI 10.17487/RFC8491, November 2018,
<https://www.rfc-editor.org/rfc/rfc8491>. <https://www.rfc-editor.org/info/rfc8491>.
[RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody,
"PCEPS: Usage of TLS to Provide a Secure Transport for the "PCEPS: Usage of TLS to Provide a Secure Transport for the
Path Computation Element Communication Protocol (PCEP)", Path Computation Element Communication Protocol (PCEP)",
RFC 8253, DOI 10.17487/RFC8253, October 2017, RFC 8253, DOI 10.17487/RFC8253, October 2017,
<https://www.rfc-editor.org/rfc/rfc8253>. <https://www.rfc-editor.org/info/rfc8253>.
[RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
and J. Hardwick, "Path Computation Element Communication and J. Hardwick, "Path Computation Element Communication
Protocol (PCEP) Extensions for Segment Routing", RFC 8664, Protocol (PCEP) Extensions for Segment Routing", RFC 8664,
DOI 10.17487/RFC8664, December 2019, DOI 10.17487/RFC8664, December 2019,
<https://www.rfc-editor.org/rfc/rfc8664>. <https://www.rfc-editor.org/info/rfc8664>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986, (SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021, DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/rfc/rfc8986>. <https://www.rfc-editor.org/info/rfc8986>.
[RFC9514] Dawra, G., Filsfils, C., Talaulikar, K., Ed., Chen, M., [RFC9514] Dawra, G., Filsfils, C., Talaulikar, K., Ed., Chen, M.,
Bernier, D., and B. Decraene, "Border Gateway Protocol - Bernier, D., and B. Decraene, "Border Gateway Protocol -
Link State (BGP-LS) Extensions for Segment Routing over Link State (BGP-LS) Extensions for Segment Routing over
IPv6 (SRv6)", RFC 9514, DOI 10.17487/RFC9514, December IPv6 (SRv6)", RFC 9514, DOI 10.17487/RFC9514, December
2023, <https://www.rfc-editor.org/rfc/rfc9514>. 2023, <https://www.rfc-editor.org/info/rfc9514>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
10.2. Informative References 9.2. Informative References
[RFC4657] Ash, J., Ed. and J.L. Le Roux, Ed., "Path Computation [RFC4657] Ash, J., Ed. and J.L. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol Generic Element (PCE) Communication Protocol Generic
Requirements", RFC 4657, DOI 10.17487/RFC4657, September Requirements", RFC 4657, DOI 10.17487/RFC4657, September
2006, <https://www.rfc-editor.org/rfc/rfc4657>. 2006, <https://www.rfc-editor.org/info/rfc4657>.
[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
BGP, LDP, PCEP, and MSDP Issues According to the Keying BGP, LDP, PCEP, and MSDP Issues According to the Keying
and Authentication for Routing Protocols (KARP) Design and Authentication for Routing Protocols (KARP) Design
Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013,
<https://www.rfc-editor.org/rfc/rfc6952>. <https://www.rfc-editor.org/info/rfc6952>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/rfc/rfc7942>.
[RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a
Stateful Path Computation Element (PCE)", RFC 8051, Stateful Path Computation Element (PCE)", RFC 8051,
DOI 10.17487/RFC8051, January 2017, DOI 10.17487/RFC8051, January 2017,
<https://www.rfc-editor.org/rfc/rfc8051>. <https://www.rfc-editor.org/info/rfc8051>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/rfc/rfc8402>. July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/rfc/rfc8754>. <https://www.rfc-editor.org/info/rfc8754>.
[RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov, [RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
A., and P. Mattes, "Segment Routing Policy Architecture", A., and P. Mattes, "Segment Routing Policy Architecture",
RFC 9256, DOI 10.17487/RFC9256, July 2022, RFC 9256, DOI 10.17487/RFC9256, July 2022,
<https://www.rfc-editor.org/rfc/rfc9256>. <https://www.rfc-editor.org/info/rfc9256>.
[RFC9352] Psenak, P., Ed., Filsfils, C., Bashandy, A., Decraene, B., [RFC9352] Psenak, P., Ed., Filsfils, C., Bashandy, A., Decraene, B.,
and Z. Hu, "IS-IS Extensions to Support Segment Routing and Z. Hu, "IS-IS Extensions to Support Segment Routing
over the IPv6 Data Plane", RFC 9352, DOI 10.17487/RFC9352, over the IPv6 Data Plane", RFC 9352, DOI 10.17487/RFC9352,
February 2023, <https://www.rfc-editor.org/rfc/rfc9352>. February 2023, <https://www.rfc-editor.org/info/rfc9352>.
[I-D.ietf-pce-pcep-yang] [PCEP-YANG]
Dhody, D., Beeram, V. P., Hardwick, J., and J. Tantsura, Dhody, D., Ed., Beeram, V., Hardwick, J., and J. Tantsura,
"A YANG Data Model for Path Computation Element "A YANG Data Model for Path Computation Element
Communications Protocol (PCEP)", Work in Progress, Communications Protocol (PCEP)", Work in Progress,
Internet-Draft, draft-ietf-pce-pcep-yang-23, 18 March Internet-Draft, draft-ietf-pce-pcep-yang-25, 21 May 2024,
2024, <https://datatracker.ietf.org/doc/html/draft-ietf- <https://datatracker.ietf.org/doc/html/draft-ietf-pce-
pce-pcep-yang-23>. pcep-yang-25>.
[I-D.ietf-pce-pcep-srv6-yang] [PCEP-SRv6-YANG]
Li, C., Sivabalan, S., Peng, S., Koldychev, M., and L. Li, C., Sivabalan, S., Peng, S., Koldychev, M., and L.
Ndifor, "A YANG Data Model for Segment Routing (SR) Policy Ndifor, "A YANG Data Model for Segment Routing (SR) Policy
and SR in IPv6 (SRv6) support in Path Computation Element and SR in IPv6 (SRv6) support in Path Computation Element
Communications Protocol (PCEP)", Work in Progress, Communications Protocol (PCEP)", Work in Progress,
Internet-Draft, draft-ietf-pce-pcep-srv6-yang-05, 18 March Internet-Draft, draft-ietf-pce-pcep-srv6-yang-05, 18 March
2024, <https://datatracker.ietf.org/doc/html/draft-ietf- 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
pce-pcep-srv6-yang-05>. pce-pcep-srv6-yang-05>.
Acknowledgements Acknowledgements
The authors would like to thank Jeff Tantsura, Adrian Farrel, Aijun The authors would like to thank Jeff Tantsura, Adrian Farrel, Aijun
Wang, Khasanov Boris, Ketan Talaulikar, Martin Vigoureux, Hariharan Wang, Khasanov Boris, Ketan Talaulikar, Martin Vigoureux, Hariharan
Ananthakrishnan, Xinyue Zhang, John Scudder, Julien Meuric and Robert Ananthakrishnan, Xinyue Zhang, John Scudder, Julien Meuric, and
Varga for valuable suggestions. Robert Varga for valuable suggestions.
Thanks to Gunter Van de Velde, Eric Vyncke, Jim Guichard, and Mahesh Thanks to Gunter Van de Velde, Éric Vyncke, Jim Guichard, and Mahesh
Jethanandani for their comments during the IESG review. Jethanandani for their comments during the IESG review.
Contributors Contributors
Mahendra Singh Negi Mahendra Singh Negi
RtBrick Inc RtBrick Inc
Bangalore Bangalore
Karnataka Karnataka
India India
Email: mahend.ietf@gmail.com Email: mahend.ietf@gmail.com
skipping to change at page 27, line 4 skipping to change at line 1175
India India
Email: dhruv.ietf@gmail.com Email: dhruv.ietf@gmail.com
Huang Wumin Huang Wumin
Huawei Technologies Huawei Technologies
Huawei Building, No. 156 Beiqing Rd. Huawei Building, No. 156 Beiqing Rd.
Beijing Beijing
100095 100095
China China
Email: huangwumin@huawei.com Email: huangwumin@huawei.com
Shuping Peng Shuping Peng
Huawei Technologies Huawei Technologies
Huawei Building, No. 156 Beiqing Rd. Huawei Building, No. 156 Beiqing Rd.
Beijing Beijing
100095 100095
China China
Email: pengshuping@huawei.com Email: pengshuping@huawei.com
Ran Chen Ran Chen
ZTE Corporation ZTE Corporation
China China
Email: chen.ran@zte.com.cn Email: chen.ran@zte.com.cn
Authors' Addresses Authors' Addresses
Cheng Li(Editor) Cheng Li (editor)
Huawei Technologies Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd. Huawei Campus, No. 156 Beiqing Rd.
Beijing Beijing
100095 100095
China China
Email: c.l@huawei.com Email: c.l@huawei.com
Additional contact information:
李呈 (editor)
中国
100095
北京
华为北研所
华为技术有限公司
Prejeeth Kaladharan Prejeeth Kaladharan
RtBrick Inc RtBrick Inc
Bangalore Bangalore
Karnataka Karnataka
India India
Email: prejeeth@rtbrick.com Email: prejeeth@rtbrick.com
Siva Sivabalan Siva Sivabalan
Ciena Corporation Ciena Corporation
Email: msiva282@gmail.com Email: msiva282@gmail.com
Mike Koldychev Mike Koldychev
Cisco Systems, Inc. Ciena Corporation
Canada Canada
Email: mkoldych@cisco.com Email: mkoldych@ciena.com
Yongqing Zhu Yongqing Zhu
China Telecom China Telecom
109 West Zhongshan Ave, Tianhe District 109 West Zhongshan Ave, Tianhe District
Bangalore Bangalore
Guangzhou, Guangzhou,
P.R. China China
Email: zhuyq8@chinatelecom.cn Email: zhuyq8@chinatelecom.cn
 End of changes. 194 change blocks. 
565 lines changed or deleted 551 lines changed or added

This html diff was produced by rfcdiff 1.48.