idnits 2.17.1 draft-rajagopalan-pcep-rsvp-color-00.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 (January 15, 2021) is 1189 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) == Missing Reference: 'TO-BE-ASSIGNED-BY-IANA' is mentioned on line 149, but not defined ** Obsolete normative reference: RFC 5512 (Obsoleted by RFC 9012) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) == Outdated reference: A later version (-17) exists of draft-kaliraj-idr-bgp-classful-transport-planes-06 Summary: 2 errors (**), 0 flaws (~~), 3 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: July 19, 2021 G. Mishra 6 Verizon Communications Inc. 7 January 15, 2021 9 Path Computation Element Protocol(PCEP) Extension for RSVP Color 10 draft-rajagopalan-pcep-rsvp-color-00 12 Abstract 14 This document specifies extensions to Path Computation Element 15 Protocol (PCEP) to carry a newly defined attribute of RSVP LSP called 16 'color' that can be used as a guiding criterion for selecting the LSP 17 as a next hop for a service route. 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in [RFC2119]. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on July 19, 2021. 42 Copyright Notice 44 Copyright (c) 2021 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 3 61 3. TLV Format . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 4. Usage with BGP-CT . . . . . . . . . . . . . . . . . . . . . . 4 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 65 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 68 8.2. Informative References . . . . . . . . . . . . . . . . . 6 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 71 1. Introduction 73 This document defines a new RSVP LSP property, called "color", that 74 can be exchanged over PCEP. The 'color' field can be used as one of 75 the guiding criteria in selecting the LSP as a next hop for service 76 prefixes. 78 While the specific details of how the service prefixes are associated 79 with the appropriate RSVP LSP's are outside the scope of this 80 specification, the envisioned high level usage of the 'color' field 81 is as follows. 83 The service prefixes are marked with some indication of the type of 84 underlay they need. The underlay LSP's carry corresponding markings, 85 which we refer to as "color" in this specification, enabling an 86 ingress node to associate the service prefixes with the appropriate 87 underlay LSP's. 89 As an example, for a BGP-based service, the originating PE could 90 attach some community, e.g. the Extended Color Community [RFC5512] 91 with the service route. A receiving PE could use locally configured 92 policies to associate service routes carrying Extended Color 93 Community 'X' with underlay RSVP LSP's of color 'Y'. 95 While the Extended Color Community provides a convenient method to 96 perform the mapping, the policy on the ingress node is free to 97 classify on any property of the route to select underlay RSVP LSP's 98 of a certain color. 100 2. Protocol Operation 102 The STATEFUL-PCE-CAPABILITY negotiation message is enhanced to carry 103 the color capability, which allows PCC & PCE to determine how 104 incompatibility should be handled, should only one of them support 105 color. An older implementation that does not recognize the new color 106 TLV would ignore it upon receipt. This can sometimes result in 107 undesirable behavior. For example, if PCE passes color to a PCC that 108 does not understand colors, the LSP may not be used as intended. A 109 PCE that clearly knows the PCC's color capability can handle such 110 cases better, and vice versa. Following are the rules for handling 111 mismatch in color capability. 113 A PCE that has color capability MUST NOT send color TLV to a PCC that 114 does not have color capability. A PCE that does not have color 115 capability can ignore color marking reported by PCC. 117 When a PCC is interacting with a PCE that does not have color 118 capability, the PCC 120 o SHOULD NOT report color to the PCE. 122 o MUST NOT override the local color, if it is configured, based on 123 any messages coming from the PCE. 125 The actual color value itself is carried in a newly defined TLV in 126 the LSP Object defined in [RFC8231]. 128 If a PCC is unable to honor a color value passed in an LSP Update 129 request, the PCC must keep the LSP in DOWN state, and include an LSP 130 Error Code value of "Unsupported Color" [Value to be assigned by 131 IANA] in LSP State Report message. 133 If an RSVP tunnel has multiple LSP's associated with it, the PCE 134 should designate one of the LSP's as primary, and attach the color 135 with that LSP. If PCC receives color TLV for an LSP that it treats 136 as secondary, it SHOULD respond with an error code of 4 (Unacceptable 137 Parameters). 139 3. TLV Format 140 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 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | Type | Length=4 | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | Color | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 Figure 1: Color TLV in LSP Object 149 Type has the value [TO-BE-ASSIGNED-BY-IANA]. Length carries a value 150 of 4. The 'color' field is 4-bytes long, and carries the actual 151 color value. 153 Section 7.1.1 of RFC8231 [RFC8231] defines STATEFUL-PCE-CAPABILITY 154 flags. The following flag is used to indicate if the speaker 155 supports color capability: 157 C-bit (TO-BE-ASSIGNED-BY-IANA): A PCE/PCC that supports color 158 capability must turn on this bit. 160 4. Usage with BGP-CT 162 RSVP LSP's marked with color can also be used for inter-domain 163 service mapping as defined in BGP-CT 164 [I-D.kaliraj-idr-bgp-classful-transport-planes]. In BGP-CT, the 165 mapping community of the service route is used to select a 166 "resolution scheme", which in turn selects LSP's of various 167 "transport classes" in the defined order of preference. The 'color' 168 field defined in this specification could be used to associate the 169 RSVP LSP with a particular transport class. 171 A colored RSVP LSP can also be exported into BGP-CT for inter-domain 172 classful transport. 174 5. Security Considerations 176 This document defines a new TLV for color, and a new flag in 177 capability negotiation, which do not add any new security concerns 178 beyond those discussed in [RFC5440], [RFC8231] and [RFC8281]. 180 An unauthorized PCE may maliciously associate the LSP with an 181 incorrect color. The procedures described in [RFC8253] and [RFC7525] 182 can be used to protect against this attack. 184 6. IANA Considerations 186 IANA is requested to assign code points for the following: 188 o Code point for "Color" TLV from the sub-registry "PCEP TLV Type 189 Indicators". 191 o C-bit value from the sub-registry "STATEFUL-PCE-CAPABILITY TLV 192 Flag Field". 194 o An error code for "Unsupported color" from the sub-registry "LSP- 195 ERROR-CODE TLV Error Code Field". 197 7. Acknowledgments 199 The authors would like to thank Kaliraj Vairavakkalai, Colby Barth & 200 Natrajan Venkataraman for their review & suggestions, which helped 201 improve this specification. 203 8. References 205 8.1. Normative References 207 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 208 Requirement Levels", BCP 14, RFC 2119, 209 DOI 10.17487/RFC2119, March 1997, 210 . 212 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 213 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 214 DOI 10.17487/RFC5440, March 2009, 215 . 217 [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation 218 Subsequent Address Family Identifier (SAFI) and the BGP 219 Tunnel Encapsulation Attribute", RFC 5512, 220 DOI 10.17487/RFC5512, April 2009, 221 . 223 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 224 "Recommendations for Secure Use of Transport Layer 225 Security (TLS) and Datagram Transport Layer Security 226 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 227 2015, . 229 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 230 Computation Element Communication Protocol (PCEP) 231 Extensions for Stateful PCE", RFC 8231, 232 DOI 10.17487/RFC8231, September 2017, 233 . 235 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 236 "PCEPS: Usage of TLS to Provide a Secure Transport for the 237 Path Computation Element Communication Protocol (PCEP)", 238 RFC 8253, DOI 10.17487/RFC8253, October 2017, 239 . 241 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 242 Computation Element Communication Protocol (PCEP) 243 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 244 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 245 . 247 8.2. Informative References 249 [I-D.kaliraj-idr-bgp-classful-transport-planes] 250 Vairavakkalai, K., Venkataraman, N., Rajagopalan, B., 251 Mishra, G., Khaddam, M., and X. Xu, "BGP Classful 252 Transport Planes", draft-kaliraj-idr-bgp-classful- 253 transport-planes-06 (work in progress), January 2021. 255 Authors' Addresses 257 Balaji Rajagopalan 258 Juniper Networks 260 Email: balajir@juniper.net 262 Vishnu Pavan Beeram 263 Juniper Networks 265 Email: vbeeram@juniper.net 267 Gyan Mishra 268 Verizon Communications Inc. 270 Email: gyan.s.mishra@verizon.com