rfc9863.original   rfc9863.txt 
PCE Working Group B. Rajagopalan Internet Engineering Task Force (IETF) B. Rajagopalan
Internet-Draft V. Beeram Request for Comments: 9863 V. Beeram
Intended status: Standards Track Juniper Networks Category: Standards Track Juniper Networks
Expires: 30 August 2025 S. Peng ISSN: 2070-1721 S. Peng
ZTE Corporation ZTE Corporation
M. Koldychev M. Koldychev
Ciena Corporation Ciena Corporation
G. Mishra G. Mishra
Verizon Communications Inc. Verizon Communications Inc.
26 February 2025 September 2025
Path Computation Element Protocol (PCEP) Extension for Color Path Computation Element Protocol (PCEP) Extension for Color
draft-ietf-pce-pcep-color-12
Abstract Abstract
Color is a 32-bit numerical (unsigned integer) attribute used to Color is a 32-bit numerical (unsigned integer) attribute used to
associate a Traffic Engineering (TE) tunnel or policy with an intent associate a Traffic Engineering (TE) tunnel or policy with an intent
or objective. For example, a TE Tunnel constructed to deliver low or objective. For example, a TE Tunnel constructed to deliver low
latency services and whose path is optimized for delay can be tagged latency services and whose path is optimized for delay can be tagged
with a color that represents "low latency." This document specifies with a color that represents "low latency." This document specifies
extensions to the Path Computation Element Protocol (PCEP) to carry extensions to the Path Computation Element Protocol (PCEP) to carry
the color attribute. the color attribute.
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
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 30 August 2025. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9863.
Copyright Notice Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the Copyright (c) 2025 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language
2. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 3 2. Protocol Operation
3. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 4 3. Protocol Extensions
3.1. Color Capability . . . . . . . . . . . . . . . . . . . . 4 3.1. Color Capability
3.2. Color TLV . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. COLOR TLV
4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 4. Security Considerations
5. Manageability Considerations . . . . . . . . . . . . . . . . 5 5. Manageability Considerations
5.1. Control of Function through Configuration and Policy . . 5 5.1. Control of Function through Configuration and Policy
5.2. Information and Data Models . . . . . . . . . . . . . . . 5 5.2. Information and Data Models
5.3. Liveness Detection and Monitoring . . . . . . . . . . . . 5 5.3. Liveness Detection and Monitoring
5.4. Verifying Correct Operation . . . . . . . . . . . . . . . 6 5.4. Verifying Correct Operation
5.5. Requirements on Other Protocols . . . . . . . . . . . . . 6 5.5. Requirements on Other Protocols
5.6. Impact on Network Operation . . . . . . . . . . . . . . . 6 5.6. Impact on Network Operation
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations
6.1. PCEP TLV Type Indicator . . . . . . . . . . . . . . . . . 6 6.1. PCEP TLV Type Indicator
6.2. STATEFUL-PCE-CAPABILITY TLV Flag Field . . . . . . . . . 6 6.2. STATEFUL-PCE-CAPABILITY TLV Flag Field
6.3. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 6 6.3. PCEP-Error Object
6.4. LSP-ERROR-CODE TLV Error Code Field . . . . . . . . . . . 7 6.4. LSP-ERROR-CODE TLV Error Code Field
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 7 7. References
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 7.2. Informative References
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 Acknowledgments
10.1. Normative References . . . . . . . . . . . . . . . . . . 8 Contributors
10.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
A Traffic Engineering (TE) tunnel ([RFC3209]) or Segment Routing (SR) A Traffic Engineering (TE) Tunnel [RFC3209] or Segment Routing (SR)
policy ([RFC9256]) can be associated with an intent or objective policy [RFC9256] can be associated with an intent or objective (e.g.,
(e.g., low latency) by tagging it with a color. This color attribute low latency) by tagging it with a color. This color attribute is
is used as a guiding criterion for mapping services onto the TE used as a guiding criterion for mapping services onto the TE Tunnel
tunnel ([RFC9012]) or SR policy ([RFC9256]). The term color used in [RFC9012] or SR Policy [RFC9256]. The term "color" used in this
this document must not be interpreted as the 'thread color' specified document must not be interpreted as the "thread color" specified in
in [RFC3063] or the 'resource color' (also referred to as 'link [RFC3063] or the "resource color" (also referred to as "link color")
color') specified in [RFC3630], [RFC5329], [RFC5305] and [RFC7308]. specified in [RFC3630], [RFC5329], [RFC5305], and [RFC7308].
[RFC8231] specifies extensions to the Path Computation Element [RFC8231] specifies extensions to the Path Computation Element
Protocol (PCEP) that enable the deployment of a stateful Path Protocol (PCEP) that enable the deployment of a stateful Path
Computation Element (PCE) model. These extensions allow a Path Computation Element (PCE) model. These extensions allow a Path
Computation Client (PCC) to delegate control of the Label Switched Computation Client (PCC) to delegate control of the Label Switched
Paths (LSPs) associated with its TE Tunnels to a stateful PCE. Paths (LSPs) associated with its TE Tunnels to a stateful PCE.
[RFC8281] specifies extensions that allow a PCE to instantiate and [RFC8281] specifies extensions that allow a PCE to instantiate and
manage PCE-initiated LSPs on a PCC under the stateful PCE model. manage PCE-initiated LSPs on a PCC under the stateful PCE model.
[RFC8664] specifies extensions that enable stateful control of SR [RFC8664] specifies extensions that enable stateful control of SR
paths via PCEP. paths via PCEP.
This document introduces extensions to PCEP to allow a color tag to This document introduces extensions to PCEP to allow a color tag to
be assigned to any TE path operated under a stateful PCE model be assigned to any TE path operated under a stateful PCE model
(including those set up using RSVP-TE [RFC8408] or Segment Routing (including those set up using RSVP-TE [RFC8408] or Segment Routing
[RFC8664]). The only exception where the extensions defined in this [RFC8664]). The only exception where the extensions defined in this
document MUST NOT be used to carry the color attribute is for SR document MUST NOT be used to carry the color attribute is for SR
paths established using the extensions defined in paths established using the extensions defined in [RFC9862]. For
[I-D.ietf-pce-segment-routing-policy-cp]. For these SR paths, the these SR paths, the associated color is already included as part of
associated color is already included as part of the SR policy the SR Policy identifier encoding.
identifier encoding.
The mechanism employed by the PCC for mapping services onto a TE path The mechanism employed by the PCC for mapping services onto a TE path
associated with a color attribute is outside the scope of this associated with a color attribute is outside the scope of this
document, as is any other use of the color tag. document, as is any other use of the color tag.
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 BCP "OPTIONAL" in this document are to be interpreted as described in
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. Protocol Operation 2. Protocol Operation
When the PCEP session is created, a PCEP (PCE/PCC) speaker sends an When the PCEP session is created, a PCEP (PCE/PCC) speaker sends an
Open message with an OPEN object that contains the STATEFUL-PCE- Open message with an OPEN object that contains the STATEFUL-PCE-
CAPABILITY TLV, as defined in [RFC8231]. A STATEFUL-PCE-CAPABILITY CAPABILITY TLV, as defined in [RFC8231]. A STATEFUL-PCE-CAPABILITY
TLV Flag (See Section 3.1) is introduced in this document to enable TLV Flag (see Section 3.1) is introduced in this document to enable
the PCEP speaker to advertise color capability. the PCEP speaker to advertise color capability.
In PCRpt, PCUpd, and PCInitiate messages, the LSP object ([RFC8231], In PCRpt, PCUpd, and PCInitiate messages, the LSP object [RFC8231]
[RFC8281]) is a mandatory inclusion and is used to carry information [RFC8281] is a mandatory inclusion and is used to carry information
specific to the target LSP. A TLV called the Color TLV (see specific to the target LSP. A TLV called the COLOR TLV (see
Section 3.2), which MAY be carried in the LSP object, is introduced Section 3.2), which MAY be carried in the LSP object, is introduced
in this document to carry the color attribute associated with the in this document to carry the color attribute associated with the
LSP. Only one COLOR TLV SHOULD be included in the LSP object. If LSP. Only one COLOR TLV SHOULD be included in the LSP object. If
the COLOR TLV appears in the LSP object more than once, only the the COLOR TLV appears in the LSP object more than once, only the
first occurrence is processed, and any others MUST be ignored. first occurrence is processed, and any others MUST be ignored.
A PCEP speaker that has advertised color capability MUST NOT send A PCEP speaker that has advertised color capability MUST NOT send
Color TLV encoded in the LSP object to a PCEP Peer that has not COLOR TLV encoded in the LSP object to a PCEP Peer [RFC5440] that has
advertised color capability. A PCEP speaker that advertises both not advertised color capability. A PCEP speaker that advertises both
color capability and SR Policy Association capability color capability and SR Policy Association [RFC9862] capability MUST
([I-D.ietf-pce-segment-routing-policy-cp]) MUST NOT send Color TLV NOT send COLOR TLV encoded in the LSP object for SR Paths. The COLOR
encoded in the LSP object for SR Paths. The Color TLV is ignored if TLV is ignored if it shows up in the LSP object of a message that
it shows up in the LSP object of a message which carries an carries an ASSOCIATION object of type SR Policy Association
ASSOCIATION object of type SR Policy Association [RFC9862]. The color encoded in the SR Policy Association takes
([I-D.ietf-pce-segment-routing-policy-cp]). The color encoded in the precedence in such a scenario.
SR Policy Association takes precedence in such a scenario.
If a PCC is unable to honor a color value passed in a PCUpd or a If a PCC is unable to honor a color value passed in a PCUpd or a
PCInitiate message, the PCC MUST reject the message and send a PCErr PCInitiate message, the PCC MUST reject the message and send a PCErr
message with Error-type=19 (Invalid Operation) and error-value=TBD1 message with Error-Type=19 (Invalid Operation) and Error-value=31
(Invalid color). This is expected behavior in scenarios where a PCC (Invalid color). This is expected behavior in scenarios where a PCC
implementation does not support a color value of zero for specific implementation does not support a color value of zero for specific
path setup types, and it receives that value in the COLOR TLV of a path setup types, and it receives that value in the COLOR TLV of a
PCUpd or a PCInitiate message. PCUpd or a PCInitiate message.
When LSPs that belong to the same TE tunnel are within the same Path When LSPs that belong to the same TE Tunnel are within the same Path
Protection Association Group [RFC8745], they are all expected to have Protection Association Group [RFC8745], they are all expected to have
the same color attached to them. If a PCEP speaker determines the same color attached to them. If a PCEP speaker determines
inconsistency in the color associated with the LSPs belonging to the inconsistency in the color associated with the LSPs belonging to the
same Path Protection Association Group, it MUST reject the message same Path Protection Association Group, it MUST reject the message
carrying the inconsistent color and send a PCErr message with Error- carrying the inconsistent color and send a PCErr message with Error-
type=19 (Invalid Operation) and error-value=TBD2 (Inconsistent Type=19 (Invalid Operation) and Error-value=32 (Inconsistent color).
color).
3. Protocol Extensions 3. Protocol Extensions
3.1. Color Capability 3.1. Color Capability
Section 7.1.1 of [RFC8231] defines STATEFUL-PCE-CAPABILITY TLV flags. Section 7.1.1 of [RFC8231] defines STATEFUL-PCE-CAPABILITY TLV flags.
The following flag is used to indicate if the speaker supports color The following flag is used to indicate if the speaker supports color
capability: capability:
C-bit (Bit 20): A PCE/PCC indicates that it supports the color C-bit (Bit 20): A PCE/PCC indicates that it supports the color
capability defined in this document by setting this bit. capability defined in this document by setting this bit.
3.2. Color TLV 3.2. COLOR TLV
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 | Length=4 | | Type | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Color | | Color |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Color TLV
Type has the value 67. Length carries a value of 4. The 'color' Figure 1: COLOR TLV
field is 4-bytes long, and carries the actual color value (specified
as an unsigned integer). A color value of zero is allowed. Type: 67
Length: 4
Color: 4-byte field that carries the actual color value (specified
as an unsigned integer). A value of zero is allowed.
4. Security Considerations 4. Security Considerations
This document defines a TLV for color and a flag for color capability This document defines a TLV for color and a flag for color capability
negotiation, which do not add any security concerns beyond those negotiation, which do not add any security concerns beyond those
discussed in [RFC5440], [RFC8231] and [RFC8281]. discussed in [RFC5440], [RFC8231], and [RFC8281].
An unauthorized PCE may maliciously associate the LSP with an An unauthorized PCE may maliciously associate the LSP with an
incorrect color. The procedures described in [RFC8253] and [RFC9325] incorrect color. The procedures described in [RFC8253] and [RFC9325]
can be used to protect against this attack. can be used to protect against this attack.
5. Manageability Considerations 5. Manageability Considerations
This section follows the advice and guidance of [RFC6123]. This section follows the advice and guidance of [RFC6123].
5.1. Control of Function through Configuration and Policy 5.1. Control of Function through Configuration and Policy
skipping to change at page 5, line 38 skipping to change at line 224
(Section 3.1). An implementation supporting this document SHOULD (Section 3.1). An implementation supporting this document SHOULD
allow the configuration of color assignment to a TE Tunnel or an SR allow the configuration of color assignment to a TE Tunnel or an SR
Policy. A PCC MAY have a local policy configuration that specifies Policy. A PCC MAY have a local policy configuration that specifies
how the color tag is used. This policy configuration is outside the how the color tag is used. This policy configuration is outside the
scope of this document. scope of this document.
5.2. Information and Data Models 5.2. Information and Data Models
An implementation supporting this document SHOULD allow the inclusion An implementation supporting this document SHOULD allow the inclusion
of color in the data model used to retrieve the operational state of of color in the data model used to retrieve the operational state of
a TE tunnel or an SR policy. The YANG model in a TE Tunnel or an SR Policy. The YANG model in [YANG-TE] could be
[I-D.ietf-teas-yang-te] could be used to retrieve the operational used to retrieve the operational state of a TE Tunnel, and the YANG
state of a TE tunnel, and the YANG model in model in [SR-POLICY-YANG] could be used to retrieve the operational
[I-D.ietf-spring-sr-policy-yang] could be used to retrieve the state of an SR Policy.
operational state of an SR policy.
5.3. Liveness Detection and Monitoring 5.3. Liveness Detection and Monitoring
The extensions defined in this document do not require any additional The extensions defined in this document do not require any additional
liveness detection and monitoring support. See [RFC5440] and liveness detection and monitoring support. See [RFC5440] and
[RFC5886] for more information. [RFC5886] for more information.
5.4. Verifying Correct Operation 5.4. Verifying Correct Operation
The operator MAY retrieve the operational state of TE Paths to verify The operator MAY retrieve the operational state of TE Paths to verify
skipping to change at page 6, line 23 skipping to change at line 253
5.6. Impact on Network Operation 5.6. Impact on Network Operation
The impact on network operations depends on how the color tag is used The impact on network operations depends on how the color tag is used
in the deployment. This is outside the scope of this document. in the deployment. This is outside the scope of this document.
6. IANA Considerations 6. IANA Considerations
6.1. PCEP TLV Type Indicator 6.1. PCEP TLV Type Indicator
This document introduces a value in the "PCEP TLV Type Indicators" IANA has assigned a value in the "PCEP TLV Type Indicators" registry
registry of the "Path Computation Element Protocol (PCEP) Numbers" of the "Path Computation Element Protocol (PCEP) Numbers" registry
registry group as follows: group as follows:
Value Description Reference +=======+=============+===========+
---------------------------------------------- | Value | Description | Reference |
67 Color This document +=======+=============+===========+
| 67 | Color | RFC 9863 |
+-------+-------------+-----------+
Note: The code point specified for the TLV Type Indicator is an early Table 1
allocation by IANA.
6.2. STATEFUL-PCE-CAPABILITY TLV Flag Field 6.2. STATEFUL-PCE-CAPABILITY TLV Flag Field
This document introduces a bit value in the "STATEFUL-PCE-CAPABILITY IANA has assigned a bit value in the "STATEFUL-PCE-CAPABILITY TLV
TLV Flag Field" registry of the "Path Computation Element Protocol Flag Field" registry of the "Path Computation Element Protocol (PCEP)
(PCEP) Numbers" registry group as follows: Numbers" registry group as follows:
Value Description Reference +=======+==================+===========+
---------------------------------------------- | Value | Description | Reference |
20 COLOR-CAPABILITY This document +=======+==================+===========+
| 20 | COLOR-CAPABILITY | RFC 9863 |
+-------+------------------+-----------+
Note: The code point specified for the STATEFUL-PCE-CAPABILITY TLV Table 2
Flag is an early allocation by IANA.
6.3. PCEP-Error Object 6.3. PCEP-Error Object
This document introduces two Error-values for Error-Type=19 (Invalid IANA has assigned two Error-values for Error-Type=19 (Invalid
Operation) within the "PCEP-ERROR Object Error Types and Values" Operation) within the "PCEP-ERROR Object Error Types and Values"
registry of the "Path Computation Element Protocol (PCEP) Numbers" registry of the "Path Computation Element Protocol (PCEP) Numbers"
registry group as follows: registry group as follows:
Error- Meaning Error-value Reference +============+===================+===================+===========+
Type | Error-Type | Meaning | Error-value | Reference |
------------------------------------------------------------------ +============+===================+===================+===========+
19 Invalid Operation TBD1: Invalid Color This document | 19 | Invalid Operation | 31: Invalid Color | RFC 9863 |
TBD2: Inconsistent Color This document | | +-------------------+-----------+
| | | 32: Inconsistent | RFC 9863 |
| | | Color | |
+------------+-------------------+-------------------+-----------+
Table 3
6.4. LSP-ERROR-CODE TLV Error Code Field 6.4. LSP-ERROR-CODE TLV Error Code Field
An earlier version of this document added an error code in the "LSP- A draft version of this document added an error code in the "LSP-
ERROR-CODE TLV Error Code Field" registry of the "Path Computation ERROR-CODE TLV Error Code Field" registry of the "Path Computation
Element Protocol (PCEP) Numbers" registry group, which was also early Element Protocol (PCEP) Numbers" registry group, which was also early
allocated by the IANA. allocated by the IANA.
IANA is requested to cancel the early allocation made which is not IANA has marked it as deprecated.
needed anymore. As per the instructions from the chairs, please mark
it as deprecated.
Value Meaning Reference
------------------------------------------------------
9 Deprecated (Unsupported Color) This document
7. Implementation Status
[Note to the RFC Editor - remove this section before publication, as
well as remove the reference to RFC 7942.]
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".
At the time of publication of this version, there are no known
implementations. Juniper Networks has plans to implement the
extensions defined in this document.
8. Acknowledgments
The authors would like to thank Kaliraj Vairavakkalai, Colby Barth,
Natrajan Venkataraman, Tarek Saad, Dhruv Dhody, Adrian Farrel, Andrew
Stone, Diego Achaval, and Narasimha Kommuri for their review and
suggestions.
9. Contributors
The following people have contributed to this document:
Quan Xiong +=======+================================+===========+
ZTE Corporation | Value | Meaning | Reference |
Email: xiong.quan@zte.com.cn +=======+================================+===========+
| 9 | Deprecated (Unsupported Color) | RFC 9863 |
+-------+--------------------------------+-----------+
10. References Table 4
10.1. Normative References 7. References
[I-D.ietf-pce-segment-routing-policy-cp] 7.1. Normative References
Koldychev, M., Sivabalan, S., Sidor, S., Barth, C., Peng,
S., and H. Bidgoli, "Path Computation Element
Communication Protocol (PCEP) Extensions for Segment
Routing (SR) Policy Candidate Paths", Work in Progress,
Internet-Draft, draft-ietf-pce-segment-routing-policy-cp-
22, 25 February 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-pce-
segment-routing-policy-cp-22>.
[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/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[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/info/rfc5440>. <https://www.rfc-editor.org/info/rfc5440>.
skipping to change at page 9, line 52 skipping to change at line 379
"The BGP Tunnel Encapsulation Attribute", RFC 9012, "The BGP Tunnel Encapsulation Attribute", RFC 9012,
DOI 10.17487/RFC9012, April 2021, DOI 10.17487/RFC9012, April 2021,
<https://www.rfc-editor.org/info/rfc9012>. <https://www.rfc-editor.org/info/rfc9012>.
[RFC9325] Sheffer, Y., Saint-Andre, P., and T. Fossati, [RFC9325] Sheffer, Y., Saint-Andre, P., and T. Fossati,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November (DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
2022, <https://www.rfc-editor.org/info/rfc9325>. 2022, <https://www.rfc-editor.org/info/rfc9325>.
10.2. Informative References [RFC9862] Koldychev, M., Sivabalan, S., Sidor, S., Barth, C., Peng,
S., and H. Bidgoli, "Path Computation Element
[I-D.ietf-spring-sr-policy-yang] Communication Protocol (PCEP) Extensions for Segment
Raza, S. K., Saleh, T., Shunwan, Z., Voyer, D., Durrani, Routing (SR) Policy Candidate Paths", RFC 9862,
M., Matsushima, S., and V. P. Beeram, "YANG Data Model for DOI 10.17487/RFC9862, September 2025,
Segment Routing Policy", Work in Progress, Internet-Draft, <https://www.rfc-editor.org/info/rfc9862>.
draft-ietf-spring-sr-policy-yang-04, 22 November 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-
sr-policy-yang-04>.
[I-D.ietf-teas-yang-te] 7.2. Informative References
Saad, T., Gandhi, R., Liu, X., Beeram, V. P., and I.
Bryskin, "A YANG Data Model for Traffic Engineering
Tunnels, Label Switched Paths and Interfaces", Work in
Progress, Internet-Draft, draft-ietf-teas-yang-te-37, 9
October 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-teas-yang-te-37>.
[RFC3063] Ohba, Y., Katsube, Y., Rosen, E., and P. Doolan, "MPLS [RFC3063] Ohba, Y., Katsube, Y., Rosen, E., and P. Doolan, "MPLS
Loop Prevention Mechanism", RFC 3063, Loop Prevention Mechanism", RFC 3063,
DOI 10.17487/RFC3063, February 2001, DOI 10.17487/RFC3063, February 2001,
<https://www.rfc-editor.org/info/rfc3063>. <https://www.rfc-editor.org/info/rfc3063>.
[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/info/rfc3209>. <https://www.rfc-editor.org/info/rfc3209>.
skipping to change at page 11, line 15 skipping to change at line 427
[RFC6123] Farrel, A., "Inclusion of Manageability Sections in Path [RFC6123] Farrel, A., "Inclusion of Manageability Sections in Path
Computation Element (PCE) Working Group Drafts", RFC 6123, Computation Element (PCE) Working Group Drafts", RFC 6123,
DOI 10.17487/RFC6123, February 2011, DOI 10.17487/RFC6123, February 2011,
<https://www.rfc-editor.org/info/rfc6123>. <https://www.rfc-editor.org/info/rfc6123>.
[RFC7308] Osborne, E., "Extended Administrative Groups in MPLS [RFC7308] Osborne, E., "Extended Administrative Groups in MPLS
Traffic Engineering (MPLS-TE)", RFC 7308, Traffic Engineering (MPLS-TE)", RFC 7308,
DOI 10.17487/RFC7308, July 2014, DOI 10.17487/RFC7308, July 2014,
<https://www.rfc-editor.org/info/rfc7308>. <https://www.rfc-editor.org/info/rfc7308>.
[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/info/rfc7942>.
[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/info/rfc9256>. <https://www.rfc-editor.org/info/rfc9256>.
[SR-POLICY-YANG]
Raza, S. K., Saleh, T., Zhuang, S., Voyer, D., Durrani,
M., Matsushima, S., and V. P. Beeram, "YANG Data Model for
Segment Routing Policy", Work in Progress, Internet-Draft,
draft-ietf-spring-sr-policy-yang-05, 25 May 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-
sr-policy-yang-05>.
[YANG-TE] Saad, T., Gandhi, R., Liu, X., Beeram, V. P., and I.
Bryskin, "A YANG Data Model for Traffic Engineering
Tunnels, Label Switched Paths and Interfaces", Work in
Progress, Internet-Draft, draft-ietf-teas-yang-te-38, 29
May 2025, <https://datatracker.ietf.org/doc/html/draft-
ietf-teas-yang-te-38>.
Acknowledgments
The authors would like to thank Kaliraj Vairavakkalai, Colby Barth,
Natrajan Venkataraman, Tarek Saad, Dhruv Dhody, Adrian Farrel, Andrew
Stone, Diego Achaval, and Narasimha Kommuri for their review and
suggestions.
Contributors
The following people have contributed to this document:
Quan Xiong
ZTE Corporation
Email: xiong.quan@zte.com.cn
Authors' Addresses Authors' Addresses
Balaji Rajagopalan Balaji Rajagopalan
Juniper Networks Juniper Networks
Email: balajir@juniper.net Email: balajir@juniper.net
Vishnu Pavan Beeram Vishnu Pavan Beeram
Juniper Networks Juniper Networks
Email: vbeeram@juniper.net Email: vbeeram@juniper.net
 End of changes. 41 change blocks. 
199 lines changed or deleted 166 lines changed or added

This html diff was produced by rfcdiff 1.48.