idnits 2.17.1 draft-ietf-pce-association-group-10.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 (August 1, 2019) is 1701 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) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) ** Downref: Normative reference to an Informational RFC: RFC 8051 == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-12 == Outdated reference: A later version (-11) exists of draft-ietf-pce-stateful-path-protection-07 == Outdated reference: A later version (-15) exists of draft-ietf-pce-association-diversity-08 Summary: 2 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 I. Minei 3 Internet-Draft Google, Inc. 4 Intended status: Standards Track E. Crabbe 5 Expires: February 2, 2020 Individual Contributor 6 S. Sivabalan 7 Cisco Systems, Inc. 8 H. Ananthakrishnan 9 Netflix 10 D. Dhody 11 Huawei 12 Y. Tanaka 13 NTT Communications Corporation 14 August 1, 2019 16 Path Computation Element Communication Protocol (PCEP) Extensions for 17 Establishing Relationships Between Sets of Label Switched Paths (LSPs) 18 draft-ietf-pce-association-group-10 20 Abstract 22 This document introduces a generic mechanism to create a grouping of 23 Label Switched Paths (LSPs) in the context of a Path Computation 24 Element (PCE). This grouping can then be used to define associations 25 between sets of LSPs or between a set of LSPs and a set of attributes 26 (such as configuration parameters or behaviours), and is equally 27 applicable to the stateful PCE (active and passive modes) as well as 28 the stateless PCE. 30 Requirements Language 32 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 33 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 34 "OPTIONAL" in this document are to be interpreted as described in BCP 35 14 [RFC2119] [RFC8174] when, and only when, they appear in all 36 capitals, as shown here. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at https://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on February 2, 2020. 55 Copyright Notice 57 Copyright (c) 2019 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (https://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 3. Architectural Overview . . . . . . . . . . . . . . . . . . . 4 75 3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 76 3.2. Relationship with the SVEC List . . . . . . . . . . . . . 5 77 3.3. Operation Overview . . . . . . . . . . . . . . . . . . . 5 78 3.4. Operator-configured Association Range . . . . . . . . . . 6 79 4. Discovery of Supported Association Types . . . . . . . . . . 7 80 4.1. ASSOC-Type-List TLV . . . . . . . . . . . . . . . . . . . 7 81 4.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 8 82 5. Operator-configured Association Range TLV . . . . . . . . . . 8 83 5.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 10 84 6. ASSOCIATION Object . . . . . . . . . . . . . . . . . . . . . 11 85 6.1. Object Definition . . . . . . . . . . . . . . . . . . . . 11 86 6.1.1. Global Association Source TLV . . . . . . . . . . . . 13 87 6.1.2. Extended Association ID TLV . . . . . . . . . . . . . 13 88 6.1.3. Association Source . . . . . . . . . . . . . . . . . 14 89 6.1.4. Unique Identification for an Association Group . . . 14 90 6.2. Relationship with the RSVP ASSOCIATION . . . . . . . . . 15 91 6.3. Object Encoding in PCEP messages . . . . . . . . . . . . 15 92 6.3.1. Stateful PCEP messages . . . . . . . . . . . . . . . 15 93 6.3.2. Request Message . . . . . . . . . . . . . . . . . . . 17 94 6.3.3. Reply Message . . . . . . . . . . . . . . . . . . . . 18 95 6.4. Processing Rules . . . . . . . . . . . . . . . . . . . . 19 97 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 98 7.1. PCEP Object . . . . . . . . . . . . . . . . . . . . . . . 21 99 7.2. PCEP TLV . . . . . . . . . . . . . . . . . . . . . . . . 22 100 7.3. Association Flags . . . . . . . . . . . . . . . . . . . . 22 101 7.4. Association Type . . . . . . . . . . . . . . . . . . . . 23 102 7.5. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 23 103 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 104 9. Manageability Considerations . . . . . . . . . . . . . . . . 24 105 9.1. Control of Function and Policy . . . . . . . . . . . . . 24 106 9.2. Information and Data Models . . . . . . . . . . . . . . . 24 107 9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 25 108 9.4. Verify Correct Operations . . . . . . . . . . . . . . . . 25 109 9.5. Requirements on Other Protocols . . . . . . . . . . . . . 25 110 9.6. Impact on Network Operations . . . . . . . . . . . . . . 25 111 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 112 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 113 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 114 12.1. Normative References . . . . . . . . . . . . . . . . . . 26 115 12.2. Informative References . . . . . . . . . . . . . . . . . 27 116 Appendix A. Example for Operator-configured Association Range . 28 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 119 1. Introduction 121 [RFC5440] describes the Path Computation Element (PCE) Communication 122 Protocol (PCEP). PCEP enables the communication between a Path 123 Computation Client (PCC) and a PCE, or between PCE and PCE, for the 124 purpose of computation of Multiprotocol Label Switching (MPLS) as 125 well as Generalized MPLS (GMPLS) Traffic Engineering Label Switched 126 Path (TE LSP) characteristics. 128 [RFC8231] specifies a set of extensions to PCEP to enable stateful 129 control of TE LSPs within and across PCEP sessions in compliance with 130 [RFC4657]. It includes mechanisms to effect LSP State 131 Synchronization between PCCs and PCEs, delegation of control over 132 LSPs to PCEs, and PCE control of timing and sequence of path 133 computations within and across PCEP sessions. The model of operation 134 where LSPs are initiated from the PCE is described in [RFC8281]. 136 [RFC4872] defines the RSVP ASSOCIATION object, which was defined in 137 the context of GMPLS-controlled Label Switched Paths (LSPs) to be 138 used to associate recovery LSPs with the LSP they are protecting. 139 This object also has broader applicability as a mechanism to 140 associate RSVP state and [RFC6780] described how the ASSOCIATION 141 object can be more generally applied by defining the Extended 142 ASSOCIATION Object. 144 This document introduces a generic mechanism to create a grouping of 145 LSPs. This grouping can then be used to define associations between 146 sets of LSPs or between a set of LSPs and a set of attributes (such 147 as configuration parameters or behaviours), and is equally applicable 148 to stateful PCE (active and passive modes) and stateless PCE. The 149 associations could be created dynamically and conveyed to a PCEP peer 150 within PCEP, or it could be configured manually by an operator on the 151 PCEP peers. Refer Section 3.3 for more details. 153 2. Terminology 155 This document uses the following terms defined in [RFC5440]: PCC, 156 PCE, PCEP Peer, Path Computation Request (PCReq), Path Computation 157 Reply (PCRep), and PCEP Error (PCErr). 159 This document uses the following terms defined in [RFC8051]: Stateful 160 PCE, Active Stateful PCE, Passive Stateful PCE, and Delegation. 162 This document uses the following terms defined in [RFC8231]: LSP 163 State Report (PCRpt), LSP Update Request (PCUpd), and State Timeout 164 Interval. 166 This document uses the following terms defined in [RFC8281]: PCE- 167 initiated LSP, and LSP Initiate Request (PCInitiate). 169 3. Architectural Overview 171 3.1. Motivation 173 Stateful PCE provides the ability to update existing LSPs and to 174 instantiate new ones. There are various situations where several 175 LSPs need to share common information. E.g., to support for PCE- 176 controlled make-before-break, an association between the original and 177 the re-optimized path is desired. Similarly, for end-to-end 178 protection, the association between working and protection LSPs is 179 required (see [I-D.ietf-pce-stateful-path-protection]). For diverse 180 paths, an association between a group of LSPs could be used (see 181 [I-D.ietf-pce-association-diversity]). Another use for the LSP 182 grouping is for applying a common set of configuration parameters or 183 behaviours to a set of LSPs. 185 For a stateless PCE, it might be useful to associate a path 186 computation request to an association group, thus enabling it to 187 associate a common set of policy, configuration parameters or 188 behaviours with the request. 190 Some associations could be created dynamically, such as association 191 between the working and protection LSPs of a tunnel, whereas some 192 associations could be created by the operator manually, such as 193 policy-based association, where the LSP could join an operator- 194 configured existing association. 196 Rather than creating separate mechanisms for each use case, this 197 document defines a generic mechanism that can be reused as needed. 199 3.2. Relationship with the SVEC List 201 Note that, [RFC5440] defines a mechanism for the synchronization of a 202 set of path computation requests by using the SVEC (Synchronization 203 VECtor) object, that specifies the list of synchronized requests that 204 can either be dependent or independent. The SVEC object identifies 205 the relationship between the set of path computation requests, 206 identified by 'Request-ID-number' in RP (Request Parameters) object. 207 [RFC6007] further clarifies the use of the SVEC list for synchronized 208 path computations when computing dependent requests as well as 209 describes a number of usage scenarios for SVEC lists within single- 210 domain and multi-domain environments. 212 The motivation behind the association group defined in this document 213 and the SVEC object are quite different, though some use cases may 214 overlap. PCEP extensions that define a new association type should 215 clarify the relationship between the SVEC object and the association 216 type, if any. 218 3.3. Operation Overview 220 LSPs are associated with other LSPs with which they interact by 221 adding them to a common association group. Association groups as 222 defined in this document can be applied to LSPs originating at the 223 same head end or different head ends. 225 Some associations could be created dynamically by a PCEP speaker and 226 the associations (along with the set of LSPs) are conveyed to a PCEP 227 peer. Whereas some associations are configured by the operator on 228 the PCEP peers involved beforehand, a PCEP speaker then could ask for 229 a LSP to join the operator-configured association. Usage of dynamic 230 and configured association is usually dependent on the type of the 231 association. 233 For the operator-configured association, the association parameters 234 such as the association identifier, association type, as well as the 235 association source IP address, are manually configured by the 236 operator. In case of dynamic association, the association parameters 237 such as the association identifier, are allocated dynamically by the 238 PCEP speaker, the association source is set as local PCEP speaker 239 address, unless local policy dictates otherwise, in which case 240 association source is set based on the local policy. 242 The dynamically created association can be reported to the PCEP peer 243 via the PCEP messages as per the stateful extensions. When the 244 operator-configured association is known to the PCEP peer beforehand, 245 a PCEP peer could ask for a LSP to join the operator-configured 246 association via the stateful PCEP messages. 248 The associations are properties of the LSP and thus could be stored 249 in the LSP state database. The dynamic association exists as long as 250 the LSP state exists. In case of PCEP session termination, the LSP 251 state clean-up MUST also take care of associations. 253 Multiple types of associations can exist, each with their own 254 association identifier space. The definition of the different 255 association types and their behaviours is outside the scope of this 256 document. The establishment and removal of the association 257 relationship can be done on a per LSP basis. An LSP may join 258 multiple association groups, of different or of the same association 259 type. 261 3.4. Operator-configured Association Range 263 Some association types are dynamic, some are operator-configured and 264 some could be both. For the association types that could be both 265 dynamic and operator-configured and use the same association source, 266 it is necessary to distinguish a range of association identifiers 267 that are marked for operator-configured associations to avoid any 268 association identifier clash within the scope of the association 269 source. This document assumes that these two ranges are configured. 271 A range of association identifiers for each Association type (and 272 Association Source) are kept for the operator-configured 273 associations. Dynamic associations MUST NOT use the association 274 identifier from this range. 276 This range as set at the PCEP speaker (PCC or PCE, as an association 277 source) needs to be communicated to a PCEP peer in the Open Message. 278 A new TLV is defined in this specification for this purpose 279 (Section 5). See Appendix A for an example. 281 Association identifier range for sources other than the PCEP speaker 282 (for example an NMS system) is not communicated in PCEP and the 283 procedure for operator-configured association range setting is 284 outside the scope of this document. 286 4. Discovery of Supported Association Types 288 This section defines PCEP extensions so as to support the capability 289 advertisement of the association types supported by a PCEP speaker. 291 A new PCEP ASSOC-Type-List (Association Types list) TLV is defined. 292 The PCEP ASSOC-Type-List TLV is carried within an OPEN object. This 293 way, during PCEP session-setup phase, a PCEP speaker can advertise to 294 a PCEP peer the list of supported Association types. 296 4.1. ASSOC-Type-List TLV 298 The PCEP ASSOC-Type-List TLV is OPTIONAL. It MAY be carried within 299 an OPEN object sent by a PCEP speaker in an Open message to a PCEP 300 peer so as to indicate the list of supported Association types. 302 The PCEP ASSOC-Type-List TLV format is compliant with the PCEP TLV 303 format defined in [RFC5440]. That is, the TLV is composed of 2 304 octets for the type, 2 octets specifying the TLV length, and a Value 305 field. The Length field defines the length of the value portion in 306 octets. The TLV is padded to 4-octet alignment, and padding is not 307 included in the Length field (e.g., a 3-octet value would have a 308 length of three, but the total size of the TLV would be eight 309 octets). 311 The PCEP ASSOC-Type-List TLV has the following format: 313 TYPE: TBD 314 LENGTH: N * 2 (where N is the number of association types) 315 VALUE: list of 2-byte association type code points, identifying 316 the association types supported by the sender of the Open 317 message. 319 0 1 2 3 320 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 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Type | Length | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Assoc-type #1 | Assoc-type #2 | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 // // 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Assoc-type #N | padding | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 Figure 1: The ASSOC-Type-List TLV format 333 Assoc-type (2 bytes): Association type code point identifier. IANA 334 manages the "ASSOCIATION Type Field" code point registry (see 335 Section 7.4). 337 4.1.1. Procedure 339 An ASSOC-Type-List TLV within an OPEN object in an Open message is 340 included by a PCEP speaker in order to advertise a set of one or more 341 supported association types. The ASSOC-Type-List TLV MUST NOT appear 342 more than once in an OPEN object. If it appears more than once, the 343 PCEP session MUST be rejected with error type 1 and error value 1 344 (PCEP session establishment failure / Reception of an invalid Open 345 message). As specified in [RFC5440], a PCEP peer that does not 346 recognize the ASSOC-Type-List TLV will silently ignore it. 348 Association type (to be defined in other documents) can specify if 349 the association type advertisement is mandatory for it. Thus, the 350 ASSOC-Type-List TLV MUST be included if at least one mandatory 351 association type needs to be advertised and the ASSOC-Type-List TLV 352 MAY be included otherwise. For an association type that specifies 353 that the advertisement is mandatory, a missing Assoc-type in the 354 ASSOC-Type-List TLV (or missing ASSOC-Type-List TLV) is to be 355 interpreted as the association type is not supported by the PCEP 356 speaker. 358 The absence of the ASSOC-Type-List TLV in an OPEN object MUST be 359 interpreted as an absence of information on the list of supported 360 Association types (rather than the Association type is not 361 supported). In this case, the PCEP speaker could still use the 362 ASSOCIATION object: if the peer does not support the association, it 363 will react as per the procedure described in Section 6.4. 365 In case the use of the ASSOC-Type-List TLV is triggered by support 366 for a mandatory association type, then it is RECOMMENDED that the 367 PCEP implementation include all supported Association types 368 (including optional) to ease the operations of the PCEP peer. 370 5. Operator-configured Association Range TLV 372 This section defines PCEP extension to support the advertisement of 373 the Operator-configured Association Range used for an Association 374 type by the PCEP speaker (as an Association source). 376 A new PCEP OP-CONF-ASSOC-RANGE (Operator-configured Association 377 Range) TLV is defined. The PCEP OP-CONF-ASSOC-RANGE TLV is carried 378 within an OPEN object. This way, during PCEP session-setup phase, a 379 PCEP speaker can advertise to a PCEP peer the Operator-configured 380 Association Range for an association type. 382 The PCEP OP-CONF-ASSOC-RANGE TLV is OPTIONAL. It MAY be carried 383 within an OPEN object sent by a PCEP speaker in an Open message to a 384 PCEP peer. The OP-CONF-ASSOC-RANGE TLV format is compliant with the 385 PCEP TLV format defined in [RFC5440]. That is, the TLV is composed 386 of 2 bytes for the type, 2 bytes specifying the TLV length, and a 387 Value field. The Length field defines the length of the value 388 portion in bytes. 390 The PCEP OP-CONF-ASSOC-RANGE TLV has the following format: 392 TYPE: 29 (Early allocation by IANA) 393 LENGTH: N * 8 (where N is the number of association types) 394 VALUE: 396 0 1 2 3 397 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 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | Type | Length | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | Reserved | Assoc-type #1 | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | Start-Assoc-ID #1 | Range #1 | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 // // 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Reserved | Assoc-type #N | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | Start-Assoc-ID #N | Range #N | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 Figure 2: The OP-CONF-ASSOC-RANGE TLV format 414 The Value portion includes the following fields, repeated for each 415 association type: 417 Reserved (2 bytes): This field MUST be set to 0 on transmission 418 and MUST be ignored on receipt. 420 Assoc-type (2 bytes): The association type (Section 7.4). The 421 association types are defined in separate documents. 423 Start-Assoc-ID (2 bytes): The start association identifier for the 424 Operator-configured Association Range for the particular 425 association type. The values 0 and 0xffff MUST NOT be used and on 426 receipt of these values in the TLV, the session is rejected with 427 error message sent (see Section 5.1). 429 Range (2 bytes): The number of associations marked for the 430 Operator-configured Associations. The Range MUST be greater than 431 0, and it MUST be such that (Start-Assoc-ID + Range) do not cross 432 the association identifier range of 0xffff. In case this 433 condition is not satisfied, the session is rejected with error 434 message sent (see Section 5.1). 436 5.1. Procedure 438 A PCEP speaker MAY include an OP-CONF-ASSOC-RANGE TLV within an OPEN 439 object in an Open message sent to a PCEP peer in order to advertise 440 the Operator-configured Association Range for an association type. 441 The OP-CONF-ASSOC-RANGE TLV MUST NOT appear more than once in an OPEN 442 object. If it appears more than once, the PCEP session MUST be 443 rejected with error type 1 and error value 1 (PCEP session 444 establishment failure / Reception of an invalid Open message). 446 As specified in [RFC5440], a PCEP peer that does not recognize the 447 OP-CONF-ASSOC-RANGE TLV will silently ignore it. 449 The Operator-configured Association Range SHOULD be included for each 450 association type that could be both dynamic and operator-configured. 451 For association types that are only dynamic or only operator- 452 configured, this TLV MAY be skipped, in which case the full range of 453 association identifier is considered dynamic or operator-configured 454 respectively. Each association type (that are defined in separate 455 documents) can specify the default value for the operator-configured 456 association range for their respective association type. 458 The absence of the OP-CONF-ASSOC-RANGE TLV in an OPEN object MUST be 459 interpreted as an absence of explicit Operator-configured Association 460 Range at the PCEP peer. In this case, the default behavior as per 461 each association type applies. If the association source is not a 462 PCEP speaker, the default value for the operator-configured 463 association range is used for the association source. 465 If the Assoc-type is not recognized or supported by the PCEP speaker, 466 it MUST ignore that respective Start-Assoc-ID and Range. If the 467 Assoc-type is recognized/supported but the Start-Assoc-ID or Range 468 are set incorrectly, the PCEP session MUST be rejected with error 469 type 1 and error value 1 (PCEP session establishment failure / 470 Reception of an invalid Open message). The incorrect range include 471 the case when the (Start-Assoc-ID + Range) crosses the association 472 identifier range of 0xffff. 474 A given Assoc-type MAY appear more than once in the OP-CONF-ASSOC- 475 RANGE TLV in the case of a non-contiguous Operator-configured 476 Association Range. The PCEP speaker originating this TLV MUST NOT 477 carry overlapping ranges for an association type. If a PCEP peer 478 receives overlapping ranges for an association type, it MUST consider 479 the Open message malformed and MUST reject the PCEP session with 480 error type 1 and error value 1 (PCEP session establishment failure / 481 Reception of an invalid Open message). 483 There may be cases where an operator-configured association was 484 configured with association parameters (such as association 485 identifier, association type and association source) at the local 486 PCEP speaker, and later the PCEP session gets established with the 487 association source and a new operator-configured range is learned 488 during session establishment. At this time, the local PCEP speaker 489 MUST remove any associations that are not in the new operator- 490 configured range (by disassociating any LSPs that are part of it (and 491 notifying this change to the PCEP peer)). If a PCEP speaker receives 492 an association for an operator-configured association and the 493 association identifier is not in the operator-configured association 494 range for the association type and association source, it MUST 495 generate an error (as described in Section 6.4). 497 6. ASSOCIATION Object 499 6.1. Object Definition 501 Association groups and their memberships are defined using a new 502 ASSOCIATION object. 504 ASSOCIATION Object-Class is 40 (Early allocation by IANA). 506 ASSOCIATION Object-Type is 1 for IPv4 and its format is shown in 507 Figure 3: 509 0 1 2 3 510 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 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | Reserved | Flags |R| 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | Association type | Association ID | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | IPv4 Association Source | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 // Optional TLVs // 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 Figure 3: The IPv4 ASSOCIATION Object format 523 ASSOCIATION Object-Type is 2 for IPv6 and its format is shown in 524 Figure 4: 526 0 1 2 3 527 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 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | Reserved | Flags |R| 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | Association type | Association ID | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | | 534 | IPv6 Association Source | 535 | | 536 | | 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 // Optional TLVs // 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 Figure 4: The IPv6 ASSOCIATION Object format 543 Reserved (2-byte): MUST be set to 0 and ignored upon receipt. 545 Flags (2-byte): The following flags are currently defined: 547 R (Removal - 1 bit): when set, the requesting PCEP peer requires the 548 removal of an LSP from the association group. When unset, the 549 PCEP peer indicates that the LSP is added or retained as part of 550 the association group. This flag is used for the ASSOCIATION 551 object in the PCRpt and the PCUpd message, the flag is ignored in 552 other PCEP messages. 554 The unassigned flags MUST be set to zero on transmission and MUST be 555 ignored on receipt. 557 Association type (2-byte): the association type (Section 7.4). The 558 association types are defined in separate documents. 560 Association ID (2-byte): the identifier of the association group. 561 When combined with other association parameters, such as Association 562 Type and Association Source, this value uniquely identifies an 563 association group. The values 0xffff and 0x0 are reserved. The 564 value 0xffff is used to indicate all association groups and could be 565 used with R flag to indicate removal for all associations for the LSP 566 within the scope of association type and association source. 568 Association Source: Contains a valid IPv4 address (4 bytes) if the 569 ASSOCIATION Object-Type is 1 or a valid IPv6 address (16 bytes) if 570 the ASSOCIATION Object-Type is 2. The address provides scoping for 571 the Association ID. See Section 6.1.3 for details. 573 Optional TLVs: The optional TLVs follow the PCEP TLV format of 574 [RFC5440]. This document defines two optional TLVs. Other documents 575 can define more TLVs in future. 577 6.1.1. Global Association Source TLV 579 The Global Association Source TLV is an optional TLV for use in the 580 Association Object. The meaning and the usage of Global Association 581 Source is as per Section 4 of [RFC6780]. 583 0 1 2 3 584 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 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | Type | Length | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 | Global Association Source | 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 Figure 5: The Global Association Source TLV format 593 Type: 30 (Early allocation by IANA). 595 Length: Fixed value of 4 bytes. 597 Global Association Source: as defined in Section 4 of [RFC6780]. 599 6.1.2. Extended Association ID TLV 601 The Extended Association ID TLV is an optional TLV for use in the 602 Association Object. The meaning and the usage of Extended 603 Association ID is as per Section 4 of [RFC6780]. 605 0 1 2 3 606 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 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | Type | Length | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 // Extended Association ID // 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 Figure 6: The Extended Association ID TLV format 615 Type: 31 (Early allocation by IANA). 617 Length: variable. 619 Extended Association ID: as defined in Section 4 of [RFC6780]. 621 6.1.3. Association Source 623 The Association Source field in the ASSOCIATION object is set to a 624 valid IP address to identify the node that originates the 625 association. In case of dynamic associations, the association source 626 is usually set as the local PCEP speaker address, unless local policy 627 dictates otherwise, in which case association source is set based on 628 the local policy. In case of PCE redundancy, local policy could set 629 the source as a virtual IP address which identifies all instances of 630 the PCE. In case of operator-configured association, the association 631 source is manually configured and it could be set as one of the PCEP 632 speakers, Network Management System (NMS), or any other valid IP 633 address that scopes the association identifier for the association 634 type. 636 6.1.4. Unique Identification for an Association Group 638 The combination of the mandatory fields Association type, Association 639 ID and Association Source in the ASSOCIATION object uniquely identify 640 the association group. If the optional TLVs - Global Association 641 Source or Extended Association ID are included, then they MUST be 642 included in combination with mandatory fields to uniquely identify 643 the association group. In this document, all these fields are 644 collectively called 'association parameters'. Note that the 645 ASSOCIATION object MAY include other optional TLVs (not defined in 646 this document) based on the association types, that provides 647 'information' related to the association type, this document uses the 648 term 'association information' for it. 650 6.2. Relationship with the RSVP ASSOCIATION 652 The format of PCEP ASSOCIATION Object defined in this document is 653 aligned with the RSVP ASSOCIATION object ([RFC6780]). Various 654 Association types related to RSVP association are defined in 655 [RFC4872], [RFC4873], and [RFC7551]. The PCEP extensions that define 656 new association types, should clarify how the PCEP associations would 657 work with RSVP associations and vice-versa. 659 6.3. Object Encoding in PCEP messages 661 Message formats in this document are expressed using Reduced BNF 662 (RBNF) as used in [RFC5440] and defined in [RFC5511]. 664 6.3.1. Stateful PCEP messages 666 The ASSOCIATION Object MAY be carried in the Path Computation Update 667 (PCUpd), Path Computation Report (PCRpt) and Path Computation 668 Initiate (PCInitiate) messages. 670 When carried in PCRpt message, it is used to report the association 671 group membership pertaining to a LSP to a stateful PCE. The PCRpt 672 message are used for both initial state synchronization operations 673 (Section 5.6 of [RFC8231]) as well as whenever the state of the LSP 674 changes. If the LSP belongs to an association group, then the 675 associations MUST be included during the state synchronization 676 operations. 678 The PCRpt message can also be used to remove an LSP from one or more 679 association groups by setting the R flag to 1 in the ASSOCIATION 680 object. 682 When an LSP is first reported to the PCE, the PCRpt message MUST 683 include all the association groups that it belongs to. Any 684 subsequent report message SHOULD include only the associations that 685 are being modified or removed. 687 The PCRpt message is defined in [RFC8231] and updated as below: 689 ::= 690 691 Where: 693 ::= [] 695 ::= [] 696 697 [] 698 699 Where: 700 ::= 701 [] 702 704 ::= [] 706 When an LSP is delegated to a stateful PCE, the stateful PCE can 707 create a new association group for this LSP, or associate it with one 708 or more existing association groups. This is done by including the 709 ASSOCIATION Object in a PCUpd message. A stateful PCE can also 710 remove a delegated LSP from one or more association groups by setting 711 the R flag to 1 in the ASSOCIATION object. 713 The PCUpd message SHOULD include the association groups that are 714 being modified or removed, there is no need to include associations 715 that remains unchanged. 717 The PCUpd message is defined in [RFC8231] and updated as below: 719 ::= 720 721 Where: 723 ::= [] 725 ::= 726 727 [] 728 729 Where: 730 ::= 732 ::= [] 734 Unless a PCEP speaker wants to delete an association from an LSP or 735 make changes to the association, it does not need to carry the 736 ASSOCIATION object in future stateful messages. 738 A PCE initiating a new LSP can also include the association groups 739 that this LSP belongs to. This is done by including the ASSOCIATION 740 Object in a PCInitiate message. The PCInitiate message MUST include 741 all the association groups that it belongs to. The PCInitiate 742 message is defined in [RFC8281] and updated as below: 744 ::= 745 746 Where: 748 ::= 749 [] 751 ::= (| 752 ) 754 ::= 755 756 [] 757 758 [] 759 [] 761 Where: 762 ::= [] 764 6.3.2. Request Message 766 In case of passive (stateful or stateless) PCE, the ASSOCIATION 767 Object is OPTIONAL and MAY be carried in the Path Computation Request 768 (PCReq) message. 770 When carried in a PCReq message, the ASSOCIATION Object is used to 771 associate the path computation request to an association group. The 772 association (and the other LSPs) should be known to the PCE 773 beforehand. These could be operator-configured or dynamically 774 learned before via stateful PCEP messages. The R flag in ASSOCIATION 775 object within PCReq message MUST be set to 0 while sending and 776 ignored on receipt. 778 The PCReq message is defined in [RFC5440] and updated in [RFC8231] , 779 it is further updated below for association: 781 ::= 782 [] 783 785 Where: 786 ::= [] 787 ::= [] 789 ::= 790 791 [] 792 [] 793 [] 794 [] 795 [] 796 [[]] 797 [] 798 [] 800 Where: 801 ::= [] 803 Note that the LSP object MAY be present for the passive stateful PCE 804 mode. 806 6.3.3. Reply Message 808 In case of passive (stateful or stateless) PCE, the ASSOCIATION 809 Object is OPTIONAL and MAY be carried in the Path Computation Reply 810 (PCRep) message with the NO-PATH object. The ASSOCIATION object in 811 PCRep message indicates the association group that cause the PCE to 812 fail to find a path. 814 The PCRep message is defined in [RFC5440] and updated in [RFC8231] , 815 it is further updated below for association: 817 ::= 818 819 Where: 821 ::=[] 823 ::= 824 [] 825 [] 826 [] 827 [] 828 [] 830 Where: 831 ::= [] 833 Note that the LSP object MAY be present for the passive stateful PCE 834 mode. 836 6.4. Processing Rules 838 Association groups can be operator-configured on the necessary PCEP 839 speakers and the PCEP speakers can join the existing association 840 groups. In addition, a PCC or a PCE can create association groups 841 dynamically and the PCEP speaker can also report the associations to 842 its peer via PCEP messages. The operator-configured associations are 843 created via configurations (where all association parameters are 844 manually set) and exist until explicitly removed via configurations. 845 The PCEP speaker can add LSPs to these configured associations and 846 carry this via stateful PCEP messages. The dynamic associations are 847 created dynamically by the PCEP speaker (where all association 848 parameters are populated dynamically). The association group is 849 attached to the LSP state, and the association group exists till 850 there is at least one LSP as part of the association. As described 851 in Section 6.1.4, the association parameters are the combination of 852 Association type, Association ID and Association Source as well as 853 optional global source and extended association identifier, that 854 uniquely identifies an association group. The information related to 855 the association types encoded via the TLVs of a particular 856 association type (not described in this document) are the association 857 information (Section 6.1.4). 859 If a PCEP speaker does not recognize the ASSOCIATION object in the 860 stateful message, it will return a PCErr message with Error-Type 861 "Unknown Object" as described in [RFC5440]. In case of PCReq 862 message, the PCE would react based on the P flag as per [RFC5440]. 863 If a PCEP speaker understands the ASSOCIATION object but does not 864 support the Association type, it MUST return a PCErr message with 865 Error-Type 26 (Early allocation by IANA) "Association Error" and 866 Error-Value 1 "Association type is not supported". If any 867 association parameters are invalid in the ASSOCIATION object, the 868 PCEP speaker would consider this as malformed object and handle it as 869 malformed message [RFC5440]. On receiving a PCEP message with 870 ASSOCIATION, if a PCEP speaker finds that too many LSPs belong to the 871 association group, it MUST return a PCErr message with Error-Type 26 872 (Early allocation by IANA) "Association Error" and Error-Value 2 "Too 873 many LSPs in the association group". If a PCEP speaker cannot handle 874 a new association, it MUST return a PCErr message with Error-Type 26 875 (Early allocation by IANA) "Association Error" and Error-Value 3 "Too 876 many association groups". These numbers MAY be set by operator or 877 decided based on a local policy. 879 If a PCE peer is unwilling or unable to process the ASSOCIATION 880 object in the stateful message, it MUST return a PCErr message with 881 the Error-Type "Not supported object" and follow the relevant 882 procedures described in [RFC5440]. In case of PCReq message, the PCE 883 would react based on the P flag as per [RFC5440]. On receiving a 884 PCEP message with ASSOCIATION, if a PCEP speaker could not add the 885 LSP to the association group for any reason, it MUST return a PCErr 886 message with Error-Type 26 (Early allocation by IANA) "Association 887 Error" and Error-Value 7 "Cannot join the association group". 889 If a PCEP speaker receives an ASSOCIATION object for an operator- 890 configured association and the association identifier is not in the 891 operator-configured association range for the Association type and 892 Association Source, it MUST return a PCErr message with Error-Type 26 893 (Early allocation by IANA) "Association Error" and Error-Value 8 894 "Association identifier not in range". 896 If a PCEP speaker receives ASSOCIATION in PCReq message, and the 897 association is not known (association is not configured, or created 898 dynamically, or learned from a PCEP peer), it MUST return a PCErr 899 message with Error-Type 26 (Early allocation by IANA) "Association 900 Error" and Error-Value 4 "Association unknown". 902 If the association information (related to the association group as a 903 whole) received from the peer does not match with the local operator- 904 configured information, it MUST return a PCErr message with Error- 905 Type 26 (Early allocation by IANA) "Association Error" and Error- 906 Value 5 "Operator-configured association information mismatch". On 907 receiving association information (related to the association group 908 as a whole) that does not match with the association information 909 previously received about the same association from a peer, it MUST 910 return a PCErr message with Error-Type 26 (Early allocation by IANA) 911 "Association Error" and Error-Value 6 "Association information 912 mismatch". Note that information related to each LSP within the 913 association as part of the association information TLVs could be 914 different. 916 If a PCEP speaker receives an ASSOCIATION object with the R bit set 917 for removal, and the association group (identified by association 918 parameters) is not known, it MUST return a PCErr message with Error- 919 Type 26 (Early allocation by IANA) "Association Error" and Error- 920 Value 4 "Association unknown". 922 The dynamic associations are cleared along with the LSP state 923 information as per the [RFC8231]. When a PCEP session is terminated, 924 after expiry of State Timeout Interval at PCC, the LSP state 925 associated with that PCEP session is reverted to operator-defined 926 default parameters or behaviours. Same procedure is also followed 927 for the association groups. On session termination at the PCE, when 928 the LSP state reported by PCC is cleared, the association groups are 929 also cleared. When there are no LSPs in an association group, the 930 association is considered to be empty and thus deleted. 932 In case the LSP is delegated to another PCE on session failure, the 933 associations (and association information) set by the PCE remains 934 intact, unless updated by the new PCE that takes over. 936 Upon LSP delegation revocation, the PCC MAY clear the association 937 created by the PCE, but in order to avoid traffic loss, it SHOULD 938 perform this in a make-before-break fashion (same as [RFC8231]). 940 7. IANA Considerations 942 IANA maintains the "Path Computation Element Protocol (PCEP) Numbers" 943 registry at . 945 7.1. PCEP Object 947 The "PCEP Numbers" registry contains a subregistry "PCEP Objects". 948 IANA is requested to confirm the early allocation of the following 949 code point in the PCEP Objects registry. 951 Object-Class Value Name Reference 953 40 (Early allocation by Association [This.I-D] 954 IANA) 955 Object-Type 956 0: Reserved 957 1: IPv4 958 2: IPv6 960 7.2. PCEP TLV 962 IANA is requested to confirm the early allocation of the following 963 code point in the "PCEP TLV Type Indicators" registry. 965 Value Meaning Reference 966 29 (Early Operator-configured [This.I-D] 967 allocation by Association Range 968 IANA) 969 30 (Early Global Association Source [This.I-D] 970 allocation by 971 IANA) 972 31 (Early Extended Association ID [This.I-D] 973 allocation by 974 IANA) 976 IANA is requested to fix the meaning for value 31 in the above 977 registry to 'Extended Association ID', it is currently mentioned as 978 'Extended Association Id'. 980 IANA is also requested to make a new assignment for the existing 981 "PCEP TLV Type Indicators" registry as follows: 983 Value Meaning Reference 984 TBD ASSOC-Type-List [This.I-D] 986 7.3. Association Flags 988 This document requests IANA to create a subregistry of the "PCEP 989 Numbers" for the bits carried in the Flags field of the ASSOCIATION 990 object. The subregistry is called "ASSOCIATION Flags Field". New 991 values are assigned by Standards Action [RFC8126]. Each bit should 992 be tracked with the following qualities: 994 o Bit number (counting from bit 0 as the most significant bit) 996 o Capability description 998 o Defining RFC 1000 Bit Description Reference 1002 15 R (Removal) [This.I-D] 1004 7.4. Association Type 1006 This document requests IANA to create a subregistry of the "PCEP 1007 Numbers" for the Association Type field of the the ASSOCIATION 1008 object. The subregistry is called "ASSOCIATION Type Field". New 1009 values are to be assigned by Standards Action [RFC8126]. Each value 1010 should be tracked with the following qualities: 1012 o Type 1014 o Name 1016 o Reference 1018 There are no association types specified in this document, future 1019 documents should request the assignment of association types from 1020 this subregistry. 1022 7.5. PCEP-Error Object 1024 IANA is requested to confirm the early allocation of the following 1025 code points within the "PCEP-ERROR Object Error Types and Values" 1026 sub-registry of the "PCEP Numbers" registry, as follows: 1028 Error-Type Meaning 1029 26 Association Error [This.I-D] 1030 (early Error-value=0: 1031 alloc by Unassigned 1032 IANA) Error-value=1: 1033 Association type is not supported 1034 Error-value=2: 1035 Too many LSPs in the association group 1036 Error-value=3: 1037 Too many association groups 1038 Error-value=4: 1039 Association unknown 1040 Error-value=5: 1041 Operator-configured association 1042 information mismatch 1043 Error-value=6: 1044 Association information mismatch 1045 Error-value=7: 1046 Cannot join the association group 1047 Error-value=8: 1048 Association identifier not in range 1050 8. Security Considerations 1052 The security considerations described in [RFC8231] and [RFC5440] 1053 apply to the extensions described in this document as well. 1054 Additional considerations related to a malicious PCEP speaker are 1055 introduced, as associations could be spoofed and could be used as an 1056 attack vector. An attacker could attempt to create too many 1057 associations in an attempt to load the PCEP peer. The PCEP peer 1058 responds with PCErr as described in Section 6.4. An attacker could 1059 impact LSP operations by creating bogus associations. Further, 1060 association groups could provides an adversary with the opportunity 1061 to eavesdrop on the relationship between the LSPs. Thus securing the 1062 PCEP session using Transport Layer Security (TLS) [RFC8253], as per 1063 the recommendations and best current practices in [RFC7525], is 1064 RECOMMENDED. 1066 Much of the information carried in the ASSOCIATION object, as per 1067 this document is not extra sensitive. It often reflects information 1068 that can also be derived from the LSP Database, but association 1069 provides a much easier grouping of related LSPs and messages. 1070 Implementations and operator can and should use indirect values in 1071 ASSOCIATION as a way to hide any sensitive business relationships. 1073 9. Manageability Considerations 1075 All manageability requirements and considerations listed in [RFC5440] 1076 and [RFC8231] apply to PCEP protocol extensions defined in this 1077 document. In addition, requirements and considerations listed in 1078 this section apply. 1080 9.1. Control of Function and Policy 1082 A PCE or PCC implementation MUST allow operator-configured 1083 associations and SHOULD allow setting of the operator-configured 1084 association range (Section 3.4) as described in this document. 1086 9.2. Information and Data Models 1088 The PCEP YANG module is defined in [I-D.ietf-pce-pcep-yang]. In 1089 future, this YANG module should be extended or augmented to provide 1090 the following additional information relating to association groups. 1092 An implementation SHOULD allow the operator to view the associations 1093 configured or created dynamically. Further implementation SHOULD 1094 allow to view associations reported by each peer, and the current set 1095 of LSPs in the association. 1097 It might also be useful to find out how many associations for each 1098 association type currently exist and to know how many free 1099 association identifiers are available for a particular association 1100 type and source. 1102 9.3. Liveness Detection and Monitoring 1104 Mechanisms defined in this document do not imply any new liveness 1105 detection and monitoring requirements in addition to those already 1106 listed in [RFC5440]. 1108 9.4. Verify Correct Operations 1110 Mechanisms defined in this document do not imply any new operation 1111 verification requirements in addition to those already listed in 1112 [RFC5440] and [RFC8231]. 1114 9.5. Requirements on Other Protocols 1116 Mechanisms defined in this document do not imply any new requirements 1117 on other protocols. 1119 9.6. Impact on Network Operations 1121 Mechanisms defined in [RFC5440] and [RFC8231] also apply to PCEP 1122 extensions defined in this document. 1124 10. Acknowledgments 1126 We would like to thank Yuji Kamite and Joshua George for their 1127 contributions to this document. Also thanks to Venugopal Reddy, 1128 Cyril Margaria, Rakesh Gandhi, Mike Koldychev, and Adrian Farrel for 1129 their useful comments. 1131 We would like to thank Julien Meuric for shepherding this document 1132 and providing comments with text suggestions. 1134 Thanks to Stig Venaas for the RTGDIR review comments. 1136 Thanks to Alvaro Retana, Mirja Kuhlewind, Martin Vigoureux, Barry 1137 Leiba, Eric Vyncke, Suresh Krishnan, and Benjamin Kaduk for the IESG 1138 comments. 1140 11. Contributors 1141 Stephane Litkowski 1142 Orange 1144 Email: stephane.litkowski@orange.com 1146 Xian Zhang 1147 Huawei Technologies 1148 F3-1-B RnD Center, Huawei Base 1149 Bantian, Longgang District 1150 Shenzhen 518129 1151 China 1153 Email: zhang.xian@huawei.com 1155 Mustapha Aissaoui 1156 Nokia 1158 Email: mustapha.aissaoui@nokia.com 1160 12. References 1162 12.1. Normative References 1164 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1165 Requirement Levels", BCP 14, RFC 2119, 1166 DOI 10.17487/RFC2119, March 1997, 1167 . 1169 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1170 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1171 DOI 10.17487/RFC5440, March 2009, 1172 . 1174 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 1175 Used to Form Encoding Rules in Various Routing Protocol 1176 Specifications", RFC 5511, DOI 10.17487/RFC5511, April 1177 2009, . 1179 [RFC6780] Berger, L., Le Faucheur, F., and A. Narayanan, "RSVP 1180 ASSOCIATION Object Extensions", RFC 6780, 1181 DOI 10.17487/RFC6780, October 2012, 1182 . 1184 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1185 "Recommendations for Secure Use of Transport Layer 1186 Security (TLS) and Datagram Transport Layer Security 1187 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1188 2015, . 1190 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 1191 Stateful Path Computation Element (PCE)", RFC 8051, 1192 DOI 10.17487/RFC8051, January 2017, 1193 . 1195 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1196 Writing an IANA Considerations Section in RFCs", BCP 26, 1197 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1198 . 1200 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1201 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1202 May 2017, . 1204 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1205 Computation Element Communication Protocol (PCEP) 1206 Extensions for Stateful PCE", RFC 8231, 1207 DOI 10.17487/RFC8231, September 2017, 1208 . 1210 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 1211 Computation Element Communication Protocol (PCEP) 1212 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 1213 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 1214 . 1216 12.2. Informative References 1218 [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation 1219 Element (PCE) Communication Protocol Generic 1220 Requirements", RFC 4657, DOI 10.17487/RFC4657, September 1221 2006, . 1223 [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, 1224 Ed., "RSVP-TE Extensions in Support of End-to-End 1225 Generalized Multi-Protocol Label Switching (GMPLS) 1226 Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007, 1227 . 1229 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, 1230 "GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873, 1231 May 2007, . 1233 [RFC6007] Nishioka, I. and D. King, "Use of the Synchronization 1234 VECtor (SVEC) List for Synchronized Dependent Path 1235 Computations", RFC 6007, DOI 10.17487/RFC6007, September 1236 2010, . 1238 [RFC7551] Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE 1239 Extensions for Associated Bidirectional Label Switched 1240 Paths (LSPs)", RFC 7551, DOI 10.17487/RFC7551, May 2015, 1241 . 1243 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 1244 "PCEPS: Usage of TLS to Provide a Secure Transport for the 1245 Path Computation Element Communication Protocol (PCEP)", 1246 RFC 8253, DOI 10.17487/RFC8253, October 2017, 1247 . 1249 [I-D.ietf-pce-pcep-yang] 1250 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 1251 YANG Data Model for Path Computation Element 1252 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 1253 yang-12 (work in progress), July 2019. 1255 [I-D.ietf-pce-stateful-path-protection] 1256 Ananthakrishnan, H., Sivabalan, S., Barth, C., Minei, I., 1257 and M. Negi, "PCEP Extensions for Associating Working and 1258 Protection LSPs with Stateful PCE", draft-ietf-pce- 1259 stateful-path-protection-07 (work in progress), June 2019. 1261 [I-D.ietf-pce-association-diversity] 1262 Litkowski, S., Sivabalan, S., Barth, C., and M. Negi, 1263 "Path Computation Element Communication Protocol (PCEP) 1264 Extension for LSP Diversity Constraint Signaling", draft- 1265 ietf-pce-association-diversity-08 (work in progress), July 1266 2019. 1268 Appendix A. Example for Operator-configured Association Range 1270 Consider an association type T1 (which allows both dynamic and 1271 operator-configured association with a default range of <0x1000, 1272 0xffff>). Consider that, because of need of the network, the PCE 1273 needs to create more dynamic associations and would like to change 1274 the association range to <0xbffe, 0xffff> instead. During PCEP 1275 session establishment the PCE would advertise the new range, the PCC 1276 could skip advertising as the default values are used. If a PCC is 1277 creating a dynamic association (with PCC as association source) it 1278 needs to pick a free association identifier for type T1 in the range 1279 of <0x1, 0x0fff> whereas if a PCE is creating a dynamic association 1280 (with PCE as association source) it needs to pick a free association 1281 identifier from the range <0x1, 0xbffd>. Similarly if an operator- 1282 configured association is manually configured with the PCC as 1283 association source, it should be from the range <0x1000, 0xffff> 1284 whereas if the PCE is association source, it should be from <0xbffe, 1285 0xffff>. In case the association source is not a PCEP peer (for 1286 example an NMS system), then the default range of <0x1000, 0xffff> is 1287 considered. 1289 Authors' Addresses 1291 Ina Minei 1292 Google, Inc. 1293 1600 Amphitheatre Parkway 1294 Mountain View, CA 94043 1295 US 1297 Email: inaminei@google.com 1299 Edward Crabbe 1300 Individual Contributor 1302 Email: edward.crabbe@gmail.com 1304 Siva Sivabalan 1305 Cisco Systems, Inc. 1306 170 West Tasman Dr. 1307 San Jose, CA 95134 1308 US 1310 Email: msiva@cisco.com 1312 Hariharan Ananthakrishnan 1313 Netflix 1315 Email: hari@netflix.com 1317 Dhruv Dhody 1318 Huawei 1319 Divyashree Techno Park, Whitefield 1320 Bangalore, KA 560066 1321 India 1323 Email: dhruv.ietf@gmail.com 1324 Yosuke Tanaka 1325 NTT Communications Corporation 1326 Granpark Tower 3-4-1 Shibaura, Minato-ku 1327 Tokyo 108-8118 1328 Japan 1330 Email: yosuke.tanaka@ntt.com