idnits 2.17.1 draft-ietf-pce-remote-initiated-gmpls-lsp-05.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 7) being 66 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 19 instances of too long lines in the document, the longest one being 22 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- The document date (June 30, 2018) is 2127 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: 'RFC 8231' is mentioned on line 99, but not defined == Missing Reference: 'RFC6387' is mentioned on line 202, but not defined == Unused Reference: 'RFC5440' is defined on line 340, but no explicit reference was found in the text == Unused Reference: 'RFC5623' is defined on line 344, but no explicit reference was found in the text == Unused Reference: 'RFC 6107' is defined on line 350, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 5623 Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PCE Working Group Zafar Ali 2 Internet Draft Siva Sivabalan 3 Intended status: Standard Track Clarence Filsfils 4 Expires: December 29, 2018 Cisco Systems 5 Robert Varga 6 Pantheon Technologies 7 Victor Lopez 8 Oscar Gonzalez de Dios 9 Telefonica I+D 10 Xian Zhang 11 Huawei 12 June 30, 2018 14 Path Computation Element Communication Protocol (PCEP) 15 Extensions for remote-initiated GMPLS LSP Setup 16 draft-ietf-pce-remote-initiated-gmpls-lsp-05.txt 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current 26 Internet-Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other 30 documents at any time. It is inappropriate to use Internet-Drafts 31 as reference material or to cite them other than as "work in 32 progress." 34 This Internet-Draft will expire on December 31, 2018. 36 Copyright Notice 38 Copyright (c) 2017 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Internet-Draft draft-ietf-pce-remote-initiated-gmpls-lsp-05.txt 53 Abstract 55 RFC8281 specifies procedures that can be used for creation 56 and deletion of PCE-initiated LSPs in the active stateful PCE model. 57 However, this specification focuses on MPLS networks, and does not 58 cover remote instantiation of paths in GMPLS-controlled networks. 59 This document complements RFC8281 by addressing the requirements 60 for remote-initiated GMPLS LSPs. 62 Conventions used in this document 64 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 65 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 66 this document are to be interpreted as described in RFC 2119 67 [RFC2119]. 69 Table of Contents 71 1. Introduction ............................................ 3 72 2. Requirements for Remote-Initiated GMPLS LSPs ............ 3 73 3. PCEP Extensions for Remote-Initiated GMPLS LSPs ......... 4 74 3.1. Generalized Endpoint in LSP Initiate Message ........ 4 75 3.2. GENERALIZED-BANDWIDTH object in LSP Initiate Message. 5 76 3.3. Protection Attributes in LSP Initiate Message ....... 5 77 3.4. ERO in LSP Initiate Object .......................... 5 78 3.4.1. ERO with explicit label control ............... 5 79 3.4.2. ERO with Path Keys ............................ 6 80 3.4.3. Switch Layer Object ........................... 6 81 3.5. LSP delegation and cleanup .......................... 7 82 4. Security Considerations ................................. 7 83 5. IANA Considerations ..................................... 7 84 5.1. PCEP-Error Object ................................... 7 85 6. Contributing Authors .................................... 7 86 7. Acknowledgments ......................................... 7 87 8. References .............................................. 7 88 8.1. Normative References ................................ 7 89 8.2. Informative References .............................. 8 90 Authors Addresses .......................................... 8 91 Internet-Draft draft-ietf-pce-remote-initiated-gmpls-lsp-05.txt 93 1. Introduction 95 The Path Computation Element communication Protocol (PCEP) 96 provides mechanisms for Path Computation Elements (PCEs) to 97 perform route computations in response to Path Computation 98 Clients (PCCs) requests. PCEP Extensions for PCE-initiated LSP 99 Setup in a Stateful PCE Model draft [RFC 8231] describes a set 100 of extensions to PCEP to enable active control of MPLS-TE and 101 GMPLS network. 103 [RFC 8281] describes the setup and teardown of PCE-initiated LSPs 104 under the active stateful PCE model, without the need for local 105 configuration on the PCC. This enables realization of a dynamic 106 network that is centrally controlled and deployed. However, this 107 specification is focused on MPLS networks, and does not cover the 108 GMPLS networks (e.g., WSON, OTN, SONET/ SDH, etc. technologies). 109 This document complements [RFC 8281] by addressing the requirements 110 for remote-initiated GMPLS LSPs. These requirements are covered in 111 Section 2 of this draft. The PCEP extensions for remote initiated 112 GMPLS LSPs are specified in Section 3. 114 2. Requirements for Remote-Initiated GMPLS LSPs 116 [RFC 8281] specifies procedures 117 that can be used for creation and deletion of PCE-initiated LSPs 118 under the active stateful PCE model. However, this specification 119 does not address GMPLS requirements outlined in the following: 121 - GMPLS support multiple switching capabilities on per TE link 122 basis. GMPLS LSP creation requires knowledge of LSP switching 123 capability (e.g., TDM, L2SC, OTN-TDM, LSC, etc.) to be used 124 [RFC3471], [RFC3473]. 126 - GMPLS LSP creation requires knowledge of the encoding type 127 (e.g., lambda photonic, Ethernet, SONET/ SDH, G709 OTN, etc.) 128 to be used by the LSP [RFC3471], [RFC3473]. 130 - GMPLS LSP creation requires information of the generalized 131 payload (G-PID) to be carried by the LSP [RFC3471], [RFC3473]. 133 - GMPLS LSP creation requires specification of data flow 134 specific traffic parameters (also known as Tspec), which are 135 technology specific. 137 - GMPLS also specifics support for asymmetric bandwidth 138 requests [RFC6387]. 140 Internet-Draft draft-ietf-pce-remote-initiated-gmpls-lsp-05.txt 142 - GMPLS extends the addressing to include unnumbered interface 143 identifiers, as defined in [RFC3477]. 145 - In some technologies path calculation is tightly coupled with 146 label selection along the route. For example, path calculation 147 in a WDM network may include lambda continuity and/ or lambda 148 feasibility constraints and hence a path computed by the PCE 149 is associated with a specific lambda (label). Hence, in such 150 networks, the label information needs to be provided to a PCC 151 in order for a PCE to initiate GMPLS LSPs under the active 152 stateful PCE model. I.e., explicit label control may be 153 required. 155 - GMPLS specifics protection context for the LSP, as defined in 156 [RFC4872] and [RFC4873]. 158 3. PCEP Extensions for Remote-Initiated GMPLS LSPs 160 LSP initiate (PCInitiate) message defined in [RFC 8281] needs to 161 be extended to include GMPLS specific PCEP objects as follows: 163 3.1. Generalized Endpoint in LSP Initiate Message 165 This document does not modify the usage of END-POINTS object for 166 PCE initiated LSPs as specified in [RFC 8281]. It augments the 167 usage as specified below. 169 END-POINTS object has been extended by [I-D. draft-ietf-pce-gmpls- 170 pcep-extensions] to include a new object type called "Generalized 171 Endpoint". PCInitiate message sent by a PCE to a PCC to trigger 172 a GMPLS LSP instantiation SHOULD include the END-POINTS with 173 Generalized Endpoint object type. Furthermore, the END-POINTS 174 object MUST contain "label request" TLV. The label request TLV 175 is used to specify the switching type, encoding type and GPID of 176 the LSP being instantiated by the PCE. 178 If the END-POINTS Object of type Generalized Endpoint is missing 179 the label request TLV, the PCC MUST send a PCErr message with 180 Error-type=6 (Mandatory Object missing) and Error-value= TBA 181 (label request TLV missing). 183 If the PCC does not support the END-POINTS Object of type 184 Generalized Endpoint, the PCC MUST send a PCErr message with 185 Error-type = 3 (Unknown Object), Error-value = 2(unknown object 186 type). 188 Internet-Draft draft-ietf-pce-remote-initiated-gmpls-lsp-05.txt 190 The unnumbered endpoint TLV can be used to specify unnumbered 191 endpoint addresses for the LSP being instantiated by the PCE. 192 The END-POINTS MAY contain other TLVs defined in [I-D. draft- 193 ietf-pce-gmpls-pcep-extensions]. 195 3.2. GENERALIZED-BANDWIDTH object in LSP Initiate Message 197 LSP initiate message defined in [RFC 8281] can optionally include 198 the BANDWIDTH object. However, the following possibilities cannot 199 be represented in the BANDWIDTH object: 201 - Asymmetric bandwidth (different bandwidth in forward and 202 reverse direction), as described in [RFC6387]. 204 - Technology specific GMPLS parameters (e.g., Tspec for 205 SDH/SONET, G.709, ATM, MEF, etc.) are not supported. 207 GENERALIZED-BANDWIDTH object has been defined in [I-D. draft- 208 ietf-pce-gmpls-pcep-extensions] to address the above-mentioned limitation 209 of the BANDWIDTH object. 211 This document specifies the use of GENERALIZED-BANDWIDTH object 212 in PCInitiate message. Specifically, GENERALIZED-BANDWIDTH 213 object MAY be included in the PCInitiate message. The 214 GENERALIZED-BANDWIDTH object in PCInitiate message is used to 215 specify technology specific Tspec and asymmetrical bandwidth 216 values for the LSP being instantiated by the PCE. 218 3.3. Protection Attributes in LSP Initiate Message 220 This document does not modify the usage of LSPA object for PCE 221 initiated LSPs as specified in [RFC 8281]. It augments the usage of LSPA object in LSP 222 Initiate Message to carry the end-to-end protection context this 223 also includes the protection state information. 225 The LSP Protection Information TLV of LSPA in the PCInitiate 226 message can be used to specify protection attributes of the LSP 227 being instantiated by the PCE. 229 3.4. ERO in LSP Initiate Object 231 This document does not modify the usage of ERO object for PCE 232 initiated LSPs as specified in [RFC 8281]. It augments the usage as specified in the 233 following sections. 235 3.4.1. ERO with explicit label control 237 As mentioned earlier, there are technologies and scenarios where 238 active stateful PCE requires explicit label control in order to 239 instantiate an LSP. 241 Explicit label control (ELC) is a procedure supported by RSVP- 242 TE, where the outgoing label(s) is (are) encoded in the ERO. [I- 243 D. draft-ietf-pce-gmpls-pcep-extensions] extends the object of PCEP 244 Internet-Draft draft-ietf-pce-remote-initiated-gmpls-lsp-05.txt 246 to include explicit label control. The ELC procedure enables the 247 PCE to provide such label(s) directly in the path ERO. 249 The extended ERO object in PCInitiate message can be used to 250 specify label along with ERO to PCC for the LSP being 251 instantiated by the active stateful PCE. 253 3.4.2. ERO with Path Keys 255 There are many scenarios in packet and optical networks where 256 the route information of an LSP may not be provided to the PCC 257 for confidentiality reasons. A multi-domain or multi-layer 258 network is an example of such networks. Similarly, a GMPLS User- 259 Network Interface (UNI) [RFC4208] is also an example of such 260 networks. 262 In such scenarios, ERO containing the entire route cannot be 263 provided to PCC (by PCE). Instead, PCE provides an ERO with Path 264 Keys to the PCC. For example, in the case UNI interface between 265 the router and the optical nodes, the ERO in the LSP Initiate 266 Message may be constructed as follows: 268 - The first hop is a strict hop that provides the egress 269 interface information at PCC. This interface information is 270 used to get to a network node that can extend the rest of the 271 ERO. (Please note that in the cases where the network node is 272 not directly connected with the PCC, this part of ERO may 273 consist of multiple hops and may be loose). 274 - The following(s) hop in the ERO may provide the network node 275 with the path key [RFC5520] that can be resolved to get the 276 contents of the route towards the destination. 277 - There may be further hops but these hops may also be encoded 278 with the path keys (if needed). 280 This document does not change encoding or processing roles for 281 the path keys, which are defined in [RFC5520]. 283 3.4.3. Switch Layer Object 285 [draft-ietf-pce-inter-layer-ext-07] specifies the SWITCH-LAYER 286 object which defines and specifies the switching layer (or 287 layers) in which a path MUST or MUST NOT be established. A 288 switching layer is expressed as a switching type and encoding 289 type. [I-D. draft-ietf-pce-gmpls-pcep-extensions], which defines the GMPLS 290 extensions for PCEP, suggests using the SWITCH-LAYER object. 291 Thus, SWITCH-LAYER object can be used in the PCInitiate message 292 Internet-Draft draft-ietf-pce-remote-initiated-gmpls-lsp-05.txt 294 to specify the switching layer (or layers) of the LSP being 295 remotely initiated. 297 3.5. LSP delegation and cleanup 299 LSP delegation and cleanup procedure specified in [I-D. draft- 300 ietf-pce-gmpls-pcep-extensions] are equally applicable to GMPLS LSPs and 301 this document does not modify the associated usage. 303 4. Security Considerations 305 To be added in future revision of this document. 307 5. IANA Considerations 309 5.1. PCEP-Error Object 311 This document defines the following new Error-Value: 313 Error-Type Error Value 315 6 Error-value=TBA: Label Request TLV missing 317 6. Contributing Authors 319 Sajal Agarwal 320 Cisco Systems 321 Email: sajaagar@cisco.com 323 7. Acknowledgments 325 The authors would like to thank George Swallow and Jan Medved 326 for their comments. 328 8. References 330 8.1. Normative References 332 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 333 Requirement Levels", BCP 14, RFC 2119, March 1997. 335 [RFC 8281] Crabbe, E., Minei, I., 336 Sivabalan, S., Varga, R., "PCEP Extensions for PCE- 337 initiated LSP Setup in a Stateful PCE Model", RFC 8281, 338 December 2017. 340 [RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path 341 Computation Element (PCE) Communication Protocol 342 (PCEP)", RFC 5440, March 2009. 344 [RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, 345 "Framework for PCE-Based Inter-Layer MPLS and GMPLS 346 Traffic Engineering", RFC 5623, September 2009. 348 Internet-Draft draft-ietf-pce-remote-initiated-gmpls-lsp-05.txt 350 [RFC 6107] Shiomoto, K., Ed., and A. Farrel, Ed., "Procedures 351 for Dynamically Signaled Hierarchical Label Switched 352 Paths", RFC 6107, February 2011. 354 8.2. Informative References 356 [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label 357 Switching (GMPLS) Signaling Functional Description", 358 RFC 3471, January 2003. 360 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 361 Switching (GMPLS) Signaling Resource ReserVation 362 Protocol-Traffic Engineering (RSVP-TE) Extensions", 363 RFC 3473, January 2003. 365 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered 366 Links in Resource ReSerVation Protocol - Traffic 367 Engineering (RSVP-TE)", RFC 3477, January 2003. 369 [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, 370 Ed., "RSVP-TE Extensions in Support of End-to-End 371 Generalized Multi-Protocol Label Switching (GMPLS) 372 Recovery", RFC 4872, May 2007. 374 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. 375 Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007. 377 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 378 "Generalized Multiprotocol Label Switching (GMPLS) 379 User-Network Interface (UNI): Resource ReserVation 380 Protocol-Traffic Engineering (RSVP-TE) Support for the 381 Overlay Model", RFC 4208, October 2005. 383 [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, 384 "Preserving Topology Confidentiality in Inter-Domain 385 Path Computation Using a Path-Key-Based Mechanism", 386 RFC 5520, April 2009. 388 Authors Addresses 390 Zafar Ali 391 Cisco Systems 392 Email: zali@cisco.com 394 Siva Sivabalan 395 Cisco Systems 396 Email: msiva@cisco.com 398 Clarence Filsfils 399 Internet-Draft draft-ietf-pce-remote-initiated-gmpls-lsp-05.txt 401 Cisco Systems 402 Email: cfilsfil@cisco.com 404 Robert Varga 405 Pantheon Technologies 407 Victor Lopez 408 Telefonica I+D 409 Email: vlopez@tid.es 411 Oscar Gonzalez de Dios 412 Telefonica I+D 413 Email: ogondio@tid.es 415 Xian Zhang 416 Huawei Technologies 417 Email: zhang.xian@huawei.com