Internet-Draft PCEP Color March 2024
Rajagopalan, et al. Expires 30 September 2024 [Page]
Workgroup:
PCE Working Group
Internet-Draft:
draft-ietf-pce-pcep-color-03
Published:
Intended Status:
Standards Track
Expires:
Authors:
B. Rajagopalan
Juniper Networks
V. Beeram
Juniper Networks
S. Peng
ZTE Corporation
M. Koldychev
Cisco Systems Inc.
G. Mishra
Verizon Communications Inc.

Path Computation Element Protocol(PCEP) Extension for Color

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.

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

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 30 September 2024.

Table of Contents

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 ([I-D.ietf-spring-segment-routing-policy]) 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 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.

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.

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

Section 4 defines the format of the color TLV. The placement of the 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].

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" (TBA3) in LSP State Report message.

When LSPs that belong to the same TE tunnel are with in 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

   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 TBA1. 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:

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

IANA is requested to allocate a new value in the "PCEP TLV Type Indicators" sub-registry of the PCEP Numbers registry as follows:

   Value    Description             Reference
   ----------------------------------------------
   TBA1     Color                   This document

6.2. STATEFUL-PCE-CAPABILITY TLV Flag Field

IANA is requested to allocate a new bit value in the "STATEFUL-PCE-CAPABILITY TLV Flag Field" sub-registry of the PCEP Numbers registry as follows:

   Value    Description             Reference
   ----------------------------------------------
   TBA2     COLOR-CAPABILITY        This document

6.3. LSP-ERROR-CODE TLV Error Code Field

IANA is requested to allocate 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
   ----------------------------------------------
   TBA3     Unsupported Color       This document

7. Acknowledgments

The authors would like to thank Kaliraj Vairavakkalai, Colby Barth, Natrajan Venkataraman and Tarek Saad for their review and suggestions.

8. Contributors

The following people have contributed to this document

Quan Xiong
ZTE Corporation

9. References

9.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <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, , <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, , <https://www.rfc-editor.org/info/rfc7525>.
[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, , <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, , <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, , <https://www.rfc-editor.org/info/rfc8281>.
[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, , <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, , <https://www.rfc-editor.org/info/rfc9012>.

9.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-10, , <https://datatracker.ietf.org/doc/html/draft-ietf-pce-multipath-10>.
[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, , <https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp-15>.
[I-D.ietf-spring-segment-routing-policy]
Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and P. Mattes, "Segment Routing Policy Architecture", Work in Progress, Internet-Draft, draft-ietf-spring-segment-routing-policy-22, , <https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-22>.
[RFC3063]
Ohba, Y., Katsube, Y., Rosen, E., and P. Doolan, "MPLS Loop Prevention Mechanism", RFC 3063, DOI 10.17487/RFC3063, , <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, , <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, , <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, , <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, , <https://www.rfc-editor.org/info/rfc7308>.

Authors' Addresses

Balaji Rajagopalan
Juniper Networks
Vishnu Pavan Beeram
Juniper Networks
Shaofu Peng
ZTE Corporation
Mike Koldychev
Cisco Systems Inc.
Gyan Mishra
Verizon Communications Inc.