PCE Working Group B. Rajagopalan
Internet-Draft V. Beeram
Intended status: Standards Track Juniper Networks
Expires: 29 November 2024 S. Peng
ZTE Corporation
M. Koldychev
Ciena Corporation
G. Mishra
Verizon Communications Inc.
28 May 2024
Path Computation Element Protocol(PCEP) Extension for Color
draft-ietf-pce-pcep-color-04
Abstract
Color is a 32-bit numerical attribute that is used to associate a
Traffic Engineering (TE) tunnel or policy with an intent or objective
(e.g. low latency). This document specifies an extension to Path
Computation Element Protocol (PCEP) to carry the color attribute.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 29 November 2024.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
Rajagopalan, et al. Expires 29 November 2024 [Page 1]
Internet-Draft PCEP Color May 2024
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Use case: RSVP-TE Color . . . . . . . . . . . . . . . . . . . 3
3. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 4
4. TLV Format . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
6.1. PCEP TLV Type Indicator . . . . . . . . . . . . . . . . . 5
6.2. STATEFUL-PCE-CAPABILITY TLV Flag Field . . . . . . . . . 6
6.3. LSP-ERROR-CODE TLV Error Code Field . . . . . . . . . . . 6
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 6
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
10.1. Normative References . . . . . . . . . . . . . . . . . . 7
10.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
A Traffic Engineering (TE) tunnel or policy can be associated with an
intent or objective (e.g. low latency) by marking it with a color.
This color attribute is used as a guiding criterion for mapping
services onto the TE tunnel or policy ([RFC9012]). The term color
used in this document is not to be interpreted as the 'thread color'
specified in [RFC3063] or the 'resource color' (or 'link color')
specified in [RFC3630], [RFC5329], [RFC5305] and [RFC7308].
Color is part of the tuple that identifies a Segment Routing (SR)
policy ([RFC9256]) and is included in the Path Computation Element
Protocol (PCEP) extensions defined for carrying the SR policy
identifiers ([I-D.ietf-pce-segment-routing-policy-cp]). The color
encoding specified in SR policy identifier cannot be reused for other
types of path setup.
This document introduces a generic optional PCEP TLV called the Color
TLV to carry the color attribute and discusses its usage with RSVP-TE
Label Switched Paths (LSPs) in a stateful PCE [RFC8231] deployment.
Rajagopalan, et al. Expires 29 November 2024 [Page 2]
Internet-Draft PCEP Color May 2024
In addition to catering to the use-case discussed in this document,
the Color TLV can also be used to reference SR Composite Candidate
Paths as specified in ([I-D.ietf-pce-multipath]). An implementation
MAY also provide a local policy option to use this TLV to reference a
set of path constraints and optimization objectives.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Use case: RSVP-TE Color
The color attribute can be used as one of the guiding criteria in
selecting the RSVP-TE LSP as a next hop for service prefixes. While
the specific details of how the service prefixes are associated with
the appropriate RSVP-TE LSPs are outside the scope of this
specification, the envisioned high level usage of the color attribute
is as follows.
The service prefixes are marked with some indication of the type of
underlay they need. The underlay LSPs carry corresponding markings,
which we refer to as color in this specification, enabling an ingress
node to associate the service prefixes with the appropriate underlay
LSPs.
As an example, for a BGP-based service, the originating PE could
attach some community, e.g. the Color Extended Community [RFC9012]
with the service route. A receiving PE could use locally configured
policies to associate service routes carrying Color Extended
Community 'X' with underlay RSVP-TE LSPs of color 'Y'.
BGP Color Extended Community is commonly used to perform service
mapping, although this specification does not mandate its usage.
The procedure discussed for service mapping in this section can be
applied to any underlay path setup type.
Rajagopalan, et al. Expires 29 November 2024 [Page 3]
Internet-Draft PCEP Color May 2024
3. Protocol Operation
The STATEFUL-PCE-CAPABILITY negotiation message is enhanced to carry
the color capability, which allows PCC (Path Computation Client) and
PCE (Path Computation Element) to determine how incompatibility
should be handled, should only one of them support color. An older
implementation that does not recognize the new color TLV would ignore
it upon receipt. This can sometimes result in undesirable behavior.
For example, if PCE passes color to a PCC that does not understand
colors, the LSP may not be used as intended. A PCE that clearly
knows the PCC's color capability can handle such cases better, and
vice versa. Following are the rules for handling mismatch in color
capability.
A PCE that has color capability MUST NOT send color TLV to a PCC that
does not have color capability. A PCE that does not have color
capability can ignore color marking reported by PCC.
When a PCC is interacting with a PCE that does not have color
capability, the PCC
* SHOULD NOT report color to the PCE.
* MUST NOT override the local color, if it is configured, based on
any messages coming from the PCE.
Section 4 defines the format of the color TLV. The object used to
carry this TLV depends on the purpose for which it is used. For
RSVP's service mapping use case discussed in this document, the color
TLV is carried in the LSP Object defined in [RFC8231]. The color TLV
is ignored if it shows up in the LSP Object of a message where the
PCEP Path Setup Type [RFC8408] is Segment Routing or SRv6.
If a PCC is unable to honor a color value passed in an LSP Update
request, the PCC must keep the LSP in DOWN state, and include an LSP
Error Code value of "Unsupported Color" (9 - Early allocation by
IANA) in LSP State Report message.
When LSPs that belong to the same TE tunnel are within the same Path
Protection Association Group [RFC8745], the color is attached only to
the primary LSP. If PCC receives color TLV for a secondary LSP, it
SHOULD respond with an error code of 4 (Unacceptable Parameters).
4. TLV Format
Rajagopalan, et al. Expires 29 November 2024 [Page 4]
Internet-Draft PCEP Color May 2024
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Color |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Color TLV
Type has the value 67 (Early allocation by IANA). Length carries a
value of 4. The 'color' field is 4-bytes long, and carries the
actual color value.
Section 7.1.1 of RFC8231 [RFC8231] defines STATEFUL-PCE-CAPABILITY
flags. The following flag is used to indicate if the speaker
supports color capability:
C-bit (Bit 20 - Early allocation by IANA): A PCE/PCC that supports
color capability must turn on this bit.
5. Security Considerations
This document defines a new TLV for color, and a new flag in
capability negotiation, which do not add any new security concerns
beyond those discussed in [RFC5440], [RFC8231] and [RFC8281].
An unauthorized PCE may maliciously associate the LSP with an
incorrect color. The procedures described in [RFC8253] and [RFC7525]
can be used to protect against this attack.
6. IANA Considerations
6.1. PCEP TLV Type Indicator
This document introduces a new value in the "PCEP TLV Type
Indicators" sub-registry of the PCEP Numbers registry as follows:
Value Description Reference
----------------------------------------------
67 Color This document
Note: The code point specified for the new TLV Type Indicator is an
early allocation by IANA.
Rajagopalan, et al. Expires 29 November 2024 [Page 5]
Internet-Draft PCEP Color May 2024
6.2. STATEFUL-PCE-CAPABILITY TLV Flag Field
This document introduces a new bit value in the "STATEFUL-PCE-
CAPABILITY TLV Flag Field" sub-registry of the PCEP Numbers registry
as follows:
Value Description Reference
----------------------------------------------
20 COLOR-CAPABILITY This document
Note: The code point specified for the new STATEFUL-PCE-CAPABILITY
TLV Flag is an early allocation by IANA.
6.3. LSP-ERROR-CODE TLV Error Code Field
This document introduces a new error code in the "LSP-ERROR-CODE TLV
Error Code Field" sub-registry of the PCEP Numbers registry as
follows:
Value Meaning Reference
----------------------------------------------
9 Unsupported Color This document
Note: The code point specified for the new LSP-ERROR-CODE TLV Error
Code is an early allocation by IANA.
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.
Rajagopalan, et al. Expires 29 November 2024 [Page 6]
Internet-Draft PCEP Color May 2024
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 and Tarek Saad for their review and
suggestions.
9. Contributors
The following people have contributed to this document
Quan Xiong
ZTE Corporation
Email: xiong.quan@zte.com.cn
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", RFC 7525, DOI 10.17487/RFC7525, May 2015,
<https://www.rfc-editor.org/info/rfc7525>.
Rajagopalan, et al. Expires 29 November 2024 [Page 7]
Internet-Draft PCEP Color May 2024
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for Stateful PCE", RFC 8231,
DOI 10.17487/RFC8231, September 2017,
<https://www.rfc-editor.org/info/rfc8231>.
[RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody,
"PCEPS: Usage of TLS to Provide a Secure Transport for the
Path Computation Element Communication Protocol (PCEP)",
RFC 8253, DOI 10.17487/RFC8253, October 2017,
<https://www.rfc-editor.org/info/rfc8253>.
[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for PCE-Initiated LSP Setup in a Stateful PCE
Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,
<https://www.rfc-editor.org/info/rfc8281>.
[RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J.
Hardwick, "Conveying Path Setup Type in PCE Communication
Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408,
July 2018, <https://www.rfc-editor.org/info/rfc8408>.
[RFC8745] Ananthakrishnan, H., Sivabalan, S., Barth, C., Minei, I.,
and M. Negi, "Path Computation Element Communication
Protocol (PCEP) Extensions for Associating Working and
Protection Label Switched Paths (LSPs) with Stateful PCE",
RFC 8745, DOI 10.17487/RFC8745, March 2020,
<https://www.rfc-editor.org/info/rfc8745>.
[RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder,
"The BGP Tunnel Encapsulation Attribute", RFC 9012,
DOI 10.17487/RFC9012, April 2021,
<https://www.rfc-editor.org/info/rfc9012>.
10.2. Informative References
[I-D.ietf-pce-multipath]
Koldychev, M., Sivabalan, S., Saad, T., Beeram, V. P.,
Bidgoli, H., Yadav, B., Peng, S., and G. S. Mishra, "PCEP
Extensions for Signaling Multipath Information", Work in
Progress, Internet-Draft, draft-ietf-pce-multipath-11, 8
April 2024, <https://datatracker.ietf.org/doc/html/draft-
ietf-pce-multipath-11>.
Rajagopalan, et al. Expires 29 November 2024 [Page 8]
Internet-Draft PCEP Color May 2024
[I-D.ietf-pce-segment-routing-policy-cp]
Koldychev, M., Sivabalan, 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-15, 17 March 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-pce-
segment-routing-policy-cp-15>.
[RFC3063] Ohba, Y., Katsube, Y., Rosen, E., and P. Doolan, "MPLS
Loop Prevention Mechanism", RFC 3063,
DOI 10.17487/RFC3063, February 2001,
<https://www.rfc-editor.org/info/rfc3063>.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630,
DOI 10.17487/RFC3630, September 2003,
<https://www.rfc-editor.org/info/rfc3630>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, DOI 10.17487/RFC5305, October
2008, <https://www.rfc-editor.org/info/rfc5305>.
[RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed.,
"Traffic Engineering Extensions to OSPF Version 3",
RFC 5329, DOI 10.17487/RFC5329, September 2008,
<https://www.rfc-editor.org/info/rfc5329>.
[RFC7308] Osborne, E., "Extended Administrative Groups in MPLS
Traffic Engineering (MPLS-TE)", RFC 7308,
DOI 10.17487/RFC7308, July 2014,
<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,
A., and P. Mattes, "Segment Routing Policy Architecture",
RFC 9256, DOI 10.17487/RFC9256, July 2022,
<https://www.rfc-editor.org/info/rfc9256>.
Authors' Addresses
Balaji Rajagopalan
Juniper Networks
Email: balajir@juniper.net
Rajagopalan, et al. Expires 29 November 2024 [Page 9]
Internet-Draft PCEP Color May 2024
Vishnu Pavan Beeram
Juniper Networks
Email: vbeeram@juniper.net
Shaofu Peng
ZTE Corporation
Email: peng.shaofu@zte.com.cn
Mike Koldychev
Ciena Corporation
Email: mkoldych@proton.me
Gyan Mishra
Verizon Communications Inc.
Email: gyan.s.mishra@verizon.com
Rajagopalan, et al. Expires 29 November 2024 [Page 10]
