idnits 2.17.00 (12 Aug 2021) /tmp/idnits19338/draft-rajagopalan-pce-pcep-color-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (14 November 2021) is 181 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-05) exists of draft-ietf-pce-multipath-03 == Outdated reference: A later version (-07) exists of draft-ietf-pce-segment-routing-policy-cp-06 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-14 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group B. Rajagopalan 3 Internet-Draft V. Beeram 4 Intended status: Standards Track Juniper Networks 5 Expires: 18 May 2022 S. Peng 6 Q. Xiong 7 ZTE Corporation 8 M. Koldychev 9 Cisco Systems Inc. 10 G. Mishra 11 Verizon Communications Inc. 12 14 November 2021 14 Path Computation Element Protocol(PCEP) Extension for Color 15 draft-rajagopalan-pce-pcep-color-01 17 Abstract 19 Color is a 32-bit numerical attribute that is used to associate a 20 Traffic Engineering (TE) tunnel or policy with an intent or objective 21 (e.g. low latency). This document specifies an extension to Path 22 Computation Element Protocol (PCEP) to carry the color attribute. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in [RFC2119]. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on 18 May 2022. 47 Copyright Notice 49 Copyright (c) 2021 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 54 license-info) in effect on the date of publication of this document. 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. Code Components 57 extracted from this document must include Simplified BSD License text 58 as described in Section 4.e of the Trust Legal Provisions and are 59 provided without warranty as described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Use case: RSVP-TE Color . . . . . . . . . . . . . . . . . . . 3 65 3. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 3 66 4. TLV Format . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 69 6.1. PCEP TLV Type Indicator . . . . . . . . . . . . . . . . . 5 70 6.2. STATEFUL-PCE-CAPABILITY TLV Flag Field . . . . . . . . . 5 71 6.3. LSP-ERROR-CODE TLV Error Code Field . . . . . . . . . . . 5 72 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 75 8.2. Informative References . . . . . . . . . . . . . . . . . 7 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 78 1. Introduction 80 A Traffic Engineering (TE) tunnel or policy can be associated with an 81 intent or objective (e.g. low latency) by marking it with a color. 82 This color attribute is used as a guiding criterion for mapping 83 services onto the TE tunnel or policy ([RFC9012]). The term color 84 used in this document is NOT to be interpreted as the 'thread color' 85 specified in [RFC3063] or the 'resource color' (or 'link color') 86 specified in [RFC3630], [RFC5329], [RFC5305] and [RFC7308]. 88 Color is part of the tuple that identifies a Segment Routing (SR) 89 policy ([I-D.ietf-spring-segment-routing-policy]) and is included in 90 the Path Computation Element Protocol (PCEP) extensions defined for 91 carrying the SR policy identifiers 92 ([I-D.ietf-pce-segment-routing-policy-cp]). The color encoding 93 specified in SR policy identifier cannot be reused for other types of 94 path setup. 96 This document introduces a generic optional PCEP TLV called the Color 97 TLV to carry the color attribute and discusses its usage with RSVP-TE 98 Label Switched Paths (LSPs). 100 In addition to catering to the use-case discussed in this document, 101 the Color TLV can also be used to reference SR Composite Candidate 102 Paths as specified in ([I-D.ietf-pce-multipath]). An implementation 103 MAY also provide a local policy option to use this TLV to reference a 104 set of path constraints and optimization objectives. 106 2. Use case: RSVP-TE Color 108 The color attribute can be used as one of the guiding criteria in 109 selecting the RSVP-TE LSP as a next hop for service prefixes. While 110 the specific details of how the service prefixes are associated with 111 the appropriate RSVP-TE LSPs are outside the scope of this 112 specification, the envisioned high level usage of the color attribute 113 is as follows. 115 The service prefixes are marked with some indication of the type of 116 underlay they need. The underlay LSPs carry corresponding markings, 117 which we refer to as color in this specification, enabling an ingress 118 node to associate the service prefixes with the appropriate underlay 119 LSPs. 121 As an example, for a BGP-based service, the originating PE could 122 attach some community, e.g. the Color Extended Community [RFC9012] 123 with the service route. A receiving PE could use locally configured 124 policies to associate service routes carrying Color Extended 125 Community 'X' with underlay RSVP-TE LSPs of color 'Y'. 127 BGP Color Extended Community is commonly used to perform service 128 mapping, although this specification does not mandate its usage. 130 The procedure discussed for service mapping in this section can be 131 applied to any underlay path setup type. 133 3. Protocol Operation 135 The STATEFUL-PCE-CAPABILITY negotiation message is enhanced to carry 136 the color capability, which allows PCC (Path Computation Client) and 137 PCE (Path Computation Element) to determine how incompatibility 138 should be handled, should only one of them support color. An older 139 implementation that does not recognize the new color TLV would ignore 140 it upon receipt. This can sometimes result in undesirable behavior. 141 For example, if PCE passes color to a PCC that does not understand 142 colors, the LSP may not be used as intended. A PCE that clearly 143 knows the PCC's color capability can handle such cases better, and 144 vice versa. Following are the rules for handling mismatch in color 145 capability. 147 A PCE that has color capability MUST NOT send color TLV to a PCC that 148 does not have color capability. A PCE that does not have color 149 capability can ignore color marking reported by PCC. 151 When a PCC is interacting with a PCE that does not have color 152 capability, the PCC 154 * SHOULD NOT report color to the PCE. 156 * MUST NOT override the local color, if it is configured, based on 157 any messages coming from the PCE. 159 Section 4 defines the format of the color TLV. The placement of the 160 TLV depends on the purpose for which it is used. For RSVP's service 161 mapping use case discussed in this document, the color TLV is carried 162 in the LSP Object defined in [RFC8231]. 164 If a PCC is unable to honor a color value passed in an LSP Update 165 request, the PCC must keep the LSP in DOWN state, and include an LSP 166 Error Code value of "Unsupported Color" (TBA3) in LSP State Report 167 message. 169 When LSPs that belong to the same TE tunnel are with in the same Path 170 Protection Association Group [RFC8745], the color is attached only to 171 the primary LSP. If PCC receives color TLV for a secondary LSP, it 172 SHOULD respond with an error code of 4 (Unacceptable Parameters). 174 4. TLV Format 176 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 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | Type | Length=4 | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Color | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 Figure 1: Color TLV 185 Type has the value TBA1. Length carries a value of 4. The 'color' 186 field is 4-bytes long, and carries the actual color value. 188 Section 7.1.1 of RFC8231 [RFC8231] defines STATEFUL-PCE-CAPABILITY 189 flags. The following flag is used to indicate if the speaker 190 supports color capability: 192 C-bit (TBA2): A PCE/PCC that supports color capability must turn 193 on this bit. 195 5. Security Considerations 197 This document defines a new TLV for color, and a new flag in 198 capability negotiation, which do not add any new security concerns 199 beyond those discussed in [RFC5440], [RFC8231] and [RFC8281]. 201 An unauthorized PCE may maliciously associate the LSP with an 202 incorrect color. The procedures described in [RFC8253] and [RFC7525] 203 can be used to protect against this attack. 205 6. IANA Considerations 207 6.1. PCEP TLV Type Indicator 209 IANA is requested to allocate a new value in the "PCEP TLV Type 210 Indicators" sub-registry of the PCEP Numbers registry as follows: 212 Value Description Reference 213 ---------------------------------------------- 214 TBA1 Color This document 216 6.2. STATEFUL-PCE-CAPABILITY TLV Flag Field 218 IANA is requested to allocate a new bit value in the "STATEFUL-PCE- 219 CAPABILITY TLV Flag Field" sub-registry of the PCEP Numbers registry 220 as follows: 222 Value Description Reference 223 ---------------------------------------------- 224 TBA2 COLOR-CAPABILITY This document 226 6.3. LSP-ERROR-CODE TLV Error Code Field 228 IANA is requested to allocate a new error code in the "LSP-ERROR-CODE 229 TLV Error Code Field" sub-registry of the PCEP Numbers registry as 230 follows: 232 Value Meaning Reference 233 ---------------------------------------------- 234 TBA3 Unsupported Color This document 236 7. Acknowledgments 238 The authors would like to thank Kaliraj Vairavakkalai, Colby Barth, 239 Natrajan Venkataraman and Tarek Saad for their review and 240 suggestions. 242 8. References 244 8.1. Normative References 246 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 247 Requirement Levels", BCP 14, RFC 2119, 248 DOI 10.17487/RFC2119, March 1997, 249 . 251 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 252 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 253 DOI 10.17487/RFC5440, March 2009, 254 . 256 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 257 "Recommendations for Secure Use of Transport Layer 258 Security (TLS) and Datagram Transport Layer Security 259 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 260 2015, . 262 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 263 Computation Element Communication Protocol (PCEP) 264 Extensions for Stateful PCE", RFC 8231, 265 DOI 10.17487/RFC8231, September 2017, 266 . 268 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 269 "PCEPS: Usage of TLS to Provide a Secure Transport for the 270 Path Computation Element Communication Protocol (PCEP)", 271 RFC 8253, DOI 10.17487/RFC8253, October 2017, 272 . 274 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 275 Computation Element Communication Protocol (PCEP) 276 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 277 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 278 . 280 [RFC8745] Ananthakrishnan, H., Sivabalan, S., Barth, C., Minei, I., 281 and M. Negi, "Path Computation Element Communication 282 Protocol (PCEP) Extensions for Associating Working and 283 Protection Label Switched Paths (LSPs) with Stateful PCE", 284 RFC 8745, DOI 10.17487/RFC8745, March 2020, 285 . 287 [RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder, 288 "The BGP Tunnel Encapsulation Attribute", RFC 9012, 289 DOI 10.17487/RFC9012, April 2021, 290 . 292 8.2. Informative References 294 [I-D.ietf-pce-multipath] 295 Koldychev, M., Sivabalan, S., Saad, T., Beeram, V. P., 296 Bidgoli, H., Yadav, B., and S. Peng, "PCEP Extensions for 297 Signaling Multipath Information", Work in Progress, 298 Internet-Draft, draft-ietf-pce-multipath-03, 25 October 299 2021, . 302 [I-D.ietf-pce-segment-routing-policy-cp] 303 Koldychev, M., Sivabalan, S., Barth, C., Peng, S., and H. 304 Bidgoli, "PCEP extension to support Segment Routing Policy 305 Candidate Paths", Work in Progress, Internet-Draft, draft- 306 ietf-pce-segment-routing-policy-cp-06, 22 October 2021, 307 . 310 [I-D.ietf-spring-segment-routing-policy] 311 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 312 P. Mattes, "Segment Routing Policy Architecture", Work in 313 Progress, Internet-Draft, draft-ietf-spring-segment- 314 routing-policy-14, 25 October 2021, 315 . 318 [RFC3063] Ohba, Y., Katsube, Y., Rosen, E., and P. Doolan, "MPLS 319 Loop Prevention Mechanism", RFC 3063, 320 DOI 10.17487/RFC3063, February 2001, 321 . 323 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 324 (TE) Extensions to OSPF Version 2", RFC 3630, 325 DOI 10.17487/RFC3630, September 2003, 326 . 328 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 329 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 330 2008, . 332 [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., 333 "Traffic Engineering Extensions to OSPF Version 3", 334 RFC 5329, DOI 10.17487/RFC5329, September 2008, 335 . 337 [RFC7308] Osborne, E., "Extended Administrative Groups in MPLS 338 Traffic Engineering (MPLS-TE)", RFC 7308, 339 DOI 10.17487/RFC7308, July 2014, 340 . 342 Authors' Addresses 344 Balaji Rajagopalan 345 Juniper Networks 347 Email: balajir@juniper.net 349 Vishnu Pavan Beeram 350 Juniper Networks 352 Email: vbeeram@juniper.net 354 Shaofu Peng 355 ZTE Corporation 357 Email: peng.shaofu@zte.com.cn 359 Quan Xiong 360 ZTE Corporation 362 Email: xiong.quan@zte.com.cn 364 Mike Koldychev 365 Cisco Systems Inc. 367 Email: mkoldych@cisco.com 368 Gyan Mishra 369 Verizon Communications Inc. 371 Email: gyan.s.mishra@verizon.com