Skip to main content

Path Computation Element Protocol(PCEP) Extension for Color
draft-rajagopalan-pce-pcep-color-02

Document Type Active Internet-Draft (candidate for pce WG)
Authors Balaji Rajagopalan , Vishnu Pavan Beeram , Shaofu Peng , Quan Xiong , Mike Koldychev , Gyan Mishra
Last updated 2022-11-30 (Latest revision 2022-07-06)
Replaces draft-rajagopalan-pcep-rsvp-color
Stream Internet Engineering Task Force (IETF)
Intended RFC status (None)
Formats
Stream WG state Call For Adoption By WG Issued
Document shepherd (None)
IESG IESG state I-D Exists
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-rajagopalan-pce-pcep-color-02
PCE Working Group                                         B. Rajagopalan
Internet-Draft                                                 V. Beeram
Intended status: Standards Track                        Juniper Networks
Expires: 7 January 2023                                          S. Peng
                                                                Q. Xiong
                                                         ZTE Corporation
                                                            M. Koldychev
                                                      Cisco Systems Inc.
                                                               G. Mishra
                                             Verizon Communications Inc.
                                                             6 July 2022

      Path Computation Element Protocol(PCEP) Extension for Color
                  draft-rajagopalan-pce-pcep-color-02

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 7 January 2023.

Rajagopalan, et al.      Expires 7 January 2023                 [Page 1]
Internet-Draft                 PCEP Color                      July 2022

Copyright Notice

   Copyright (c) 2022 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
   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
   2.  Use case: RSVP-TE Color . . . . . . . . . . . . . . . . . . .   3
   3.  Protocol Operation  . . . . . . . . . . . . . . . . . . . . .   3
   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  . . . . . . . . .   5
     6.3.  LSP-ERROR-CODE TLV Error Code Field . . . . . . . . . . .   5
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   6
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

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.

Rajagopalan, et al.      Expires 7 January 2023                 [Page 2]
Internet-Draft                 PCEP Color                      July 2022

   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

Rajagopalan, et al.      Expires 7 January 2023                 [Page 3]
Internet-Draft                 PCEP Color                      July 2022

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

Rajagopalan, et al.      Expires 7 January 2023                 [Page 4]
Internet-Draft                 PCEP Color                      July 2022

      C-bit (TBA2): 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

   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

Rajagopalan, et al.      Expires 7 January 2023                 [Page 5]
Internet-Draft                 PCEP Color                      July 2022

7.  Acknowledgments

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

8.  References

8.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)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
              2015, <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, 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>.

Rajagopalan, et al.      Expires 7 January 2023                 [Page 6]
Internet-Draft                 PCEP Color                      July 2022

   [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>.

8.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. Mishra, "PCEP
              Extensions for Signaling Multipath Information", Work in
              Progress, Internet-Draft, draft-ietf-pce-multipath-06, 17
              May 2022, <https://www.ietf.org/archive/id/draft-ietf-pce-
              multipath-06.txt>.

   [I-D.ietf-pce-segment-routing-policy-cp]
              Koldychev, M., Sivabalan, S., Barth, C., Peng, S., and H.
              Bidgoli, "PCEP extension to support Segment Routing Policy
              Candidate Paths", Work in Progress, Internet-Draft, draft-
              ietf-pce-segment-routing-policy-cp-07, 21 April 2022,
              <https://www.ietf.org/archive/id/draft-ietf-pce-segment-
              routing-policy-cp-07.txt>.

   [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, 22 March 2022,
              <https://www.ietf.org/archive/id/draft-ietf-spring-
              segment-routing-policy-22.txt>.

   [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>.

Rajagopalan, et al.      Expires 7 January 2023                 [Page 7]
Internet-Draft                 PCEP Color                      July 2022

   [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>.

Authors' Addresses

   Balaji Rajagopalan
   Juniper Networks
   Email: balajir@juniper.net

   Vishnu Pavan Beeram
   Juniper Networks
   Email: vbeeram@juniper.net

   Shaofu Peng
   ZTE Corporation
   Email: peng.shaofu@zte.com.cn

   Quan Xiong
   ZTE Corporation
   Email: xiong.quan@zte.com.cn

   Mike Koldychev
   Cisco Systems Inc.
   Email: mkoldych@cisco.com

   Gyan Mishra
   Verizon Communications Inc.
   Email: gyan.s.mishra@verizon.com

Rajagopalan, et al.      Expires 7 January 2023                 [Page 8]