idnits 2.17.1 draft-ietf-pce-association-group-08.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 (March 7, 2019) is 1875 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 informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-09 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). 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: September 8, 2019 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 March 7, 2019 16 PCEP Extensions for Establishing Relationships Between Sets of LSPs 17 draft-ietf-pce-association-group-08 19 Abstract 21 This document introduces a generic mechanism to create a grouping of 22 Label Switched Paths (LSPs) in the context of a Path Computation 23 Element (PCE). This grouping can then be used to define associations 24 between sets of LSPs or between a set of LSPs and a set of attributes 25 (such as configuration parameters or behaviors), and is equally 26 applicable to the stateful PCE (active and passive modes) as well as 27 the stateless PCE. 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 33 "OPTIONAL" in this document are to be interpreted as described in BCP 34 14 [RFC2119] [RFC8174] when, and only when, they appear in all 35 capitals, as shown here. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on September 8, 2019. 54 Copyright Notice 56 Copyright (c) 2019 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (https://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 3. Architectural Overview . . . . . . . . . . . . . . . . . . . 4 74 3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 75 3.2. Relationship with the SVEC List . . . . . . . . . . . . . 5 76 3.3. Operation Overview . . . . . . . . . . . . . . . . . . . 5 77 3.4. Operator-configured Association Range . . . . . . . . . . 6 78 4. Discovery of Supported Association Types . . . . . . . . . . 6 79 4.1. ASSOC-Type-List TLV . . . . . . . . . . . . . . . . . . . 7 80 4.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 7 81 5. Operator-configured Association Range TLV . . . . . . . . . . 8 82 5.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 9 83 6. ASSOCIATION Object . . . . . . . . . . . . . . . . . . . . . 11 84 6.1. Object Definition . . . . . . . . . . . . . . . . . . . . 11 85 6.1.1. Global Association Source TLV . . . . . . . . . . . . 13 86 6.1.2. Extended Association ID TLV . . . . . . . . . . . . . 13 87 6.1.3. Association Source . . . . . . . . . . . . . . . . . 14 88 6.1.4. Unique Identification for an Association Group . . . 14 89 6.2. Relationship with the RSVP ASSOCIATION . . . . . . . . . 14 90 6.3. Object Encoding in PCEP messages . . . . . . . . . . . . 14 91 6.3.1. Stateful PCEP messages . . . . . . . . . . . . . . . 15 92 6.3.2. Request Message . . . . . . . . . . . . . . . . . . . 17 93 6.3.3. Reply Message . . . . . . . . . . . . . . . . . . . . 17 94 6.4. Processing Rules . . . . . . . . . . . . . . . . . . . . 18 95 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 96 7.1. PCEP Object . . . . . . . . . . . . . . . . . . . . . . . 20 97 7.2. PCEP TLV . . . . . . . . . . . . . . . . . . . . . . . . 21 98 7.3. Association Flags . . . . . . . . . . . . . . . . . . . . 21 99 7.4. Association Type . . . . . . . . . . . . . . . . . . . . 22 100 7.5. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 22 101 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 102 9. Manageability Considerations . . . . . . . . . . . . . . . . 23 103 9.1. Control of Function and Policy . . . . . . . . . . . . . 23 104 9.2. Information and Data Models . . . . . . . . . . . . . . . 23 105 9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 24 106 9.4. Verify Correct Operations . . . . . . . . . . . . . . . . 24 107 9.5. Requirements on Other Protocols . . . . . . . . . . . . . 24 108 9.6. Impact on Network Operations . . . . . . . . . . . . . . 24 109 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 110 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24 111 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 112 12.1. Normative References . . . . . . . . . . . . . . . . . . 25 113 12.2. Informative References . . . . . . . . . . . . . . . . . 26 114 Appendix A. Example for Operator-configured Association Range . 27 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 117 1. Introduction 119 [RFC5440] describes the Path Computation Element (PCE) Communication 120 Protocol (PCEP). PCEP enables the communication between a Path 121 Computation Client (PCC) and a PCE, or between PCE and PCE, for the 122 purpose of computation of Multiprotocol Label Switching (MPLS) as 123 well as Generalzied MPLS (GMPLS) Traffic Engineering Label Switched 124 Path (TE LSP) characteristics. 126 [RFC8231] specifies a set of extensions to PCEP to enable stateful 127 control of TE LSPs within and across PCEP sessions in compliance with 128 [RFC4657]. It includes mechanisms to effect LSP State 129 Synchronization between PCCs and PCEs, delegation of control over 130 LSPs to PCEs, and PCE control of timing and sequence of path 131 computations within and across PCEP sessions. The model of operation 132 where LSPs are initiated from the PCE is described in [RFC8281]. 134 [RFC6780] defines the RSVP ASSOCIATION object, which was defined in 135 the context of GMPLS-controlled Label Switched Paths (LSPs) to be 136 used to associate recovery LSPs with the LSP they are protecting. 137 This object also has broader applicability as a mechanism to 138 associate RSVP state and [RFC6780] described how the ASSOCIATION 139 object can be more generally applied. 141 This document introduces a generic mechanism to create a grouping of 142 LSPs. This grouping can then be used to define associations between 143 sets of LSPs or between a set of LSPs and a set of attributes (such 144 as configuration parameters or behaviors), and is equally applicable 145 to stateful PCE (active and passive modes) and stateless PCE. The 146 associations could be created dynamically and conveyed to a PCEP peer 147 within PCEP, or it could be configured manually by an operator on the 148 PCEP peers. Refer Section 3.3 for more details. 150 2. Terminology 152 This document uses the following terms defined in [RFC5440]: PCC, 153 PCE, PCEP Peer, Path Computation Request (PCReq), Path Computation 154 Reply (PCRep), and PCEP Error (PCErr). 156 This document uses the following terms defined in [RFC8051]: Stateful 157 PCE, Active Stateful PCE, Passive Stateful PCE, and Delegation. 159 This document uses the following terms defined in [RFC8231]: LSP 160 State Report (PCRpt), LSP Update Request (PCUpd), and State Timeout 161 Interval. 163 This document uses the following terms defined in [RFC8281]: PCE- 164 initiated LSP, and LSP Initiate Request (PCInitiate). 166 3. Architectural Overview 168 3.1. Motivation 170 Stateful PCE provides the ability to update existing LSPs and to 171 instantiate new ones. There are various situations where several 172 LSPs need to share common information. E.g., to support for PCE- 173 controlled make-before-break, an association between the original and 174 the re-optimized path is desired. Similarly, for end-to-end 175 protection, the association between working and protection LSPs is 176 required. Another use for the LSP grouping is for applying a common 177 set of configuration parameters or behaviors to a set of LSPs. 179 For a stateless PCE, it might be useful to associate a path 180 computation request to an association group, thus enabling it to 181 associate a common set of policy, configuration parameters or 182 behaviors with the request. 184 Some associations could be created dynamically, such as association 185 between the working and protections LSPs of a tunnel, whereas some 186 associations could be created by the operator manually, such as 187 policy-based association, where the LSP could join an operator- 188 configured existing association. 190 Rather than creating separate mechanisms for each use case, this 191 document defines a generic mechanism that can be reused as needed. 193 3.2. Relationship with the SVEC List 195 Note that, [RFC5440] defines a mechanism for the synchronization of a 196 set of path computation requests by using the SVEC (Synchronization 197 VECtor) object, that specifies the list of synchronized requests that 198 can either be dependent or independent. The SVEC object identify the 199 relationship between the set of path computation requests, identified 200 by 'Request-ID-number' in RP (Request Parameters) object. [RFC6007] 201 further clarifies the use of the SVEC list for synchronized path 202 computations when computing dependent requests as well as describes a 203 number of usage scenarios for SVEC lists within single-domain and 204 multi-domain environments. 206 The motivation behind the association group defined in this document 207 and the SVEC object are quite different, though some use case may 208 overlap. The PCEP extensions that defines new association type 209 should clarify the relationship between SVEC object and association 210 type, if any. 212 3.3. Operation Overview 214 LSPs are associated with other LSPs with which they interact by 215 adding them to a common association group. Association groups as 216 defined in this document can be applied to LSPs originating at the 217 same head end or different head ends. 219 Some associations could be created dynamically by a PCEP speaker and 220 the associations (along with the set of LSPs) are conveyed to a PCEP 221 peer. Whereas some associations are configured by the operator on 222 the PCEP peers involved before hand, a PCEP speaker then could ask 223 for a LSP to join the operator-configured association. Usage of 224 dynamic and configured association is usually dependent on the type 225 of the association. 227 For the operator-configured association, the association parameters 228 such as the association identifier, association type, as well as the 229 association source IP address is manually configured by the operator. 230 In case of dynamic association, the association parameters such as 231 the association identifier is allocated dynamically by the PCEP 232 speaker, the association source is set as local PCEP speaker address, 233 unless local policy dictates otherwise, in which case association 234 source is set based on the local policy. 236 The dynamically created association can be reported to the PCEP peer 237 via the PCEP messages as per the stateful extensions. While the 238 operator-configured association are known to the PCEP peer before 239 hand, a PCEP peer could ask for a LSP to join the operator-configured 240 association via the stateful PCEP messages. 242 The associations are properties of the LSP and thus could be stored 243 in the LSP state database. The dynamic association exist as long as 244 the LSP state. In case of PCEP session termination, the LSP state 245 clean-up MUST also take care of associations. 247 Multiple types of associations can exist, each with their own 248 association identifier space. The definition of the different 249 association types and their behaviors is outside the scope of this 250 document. The establishment and removal of the association 251 relationship can be done on a per LSP basis. An LSP may join 252 multiple association groups, of different or of the same association 253 type. 255 3.4. Operator-configured Association Range 257 Some association types are dynamic, some are operator-configured and 258 some could be both. For the association types that could be both 259 dynamic and operator-configured and use the same association source, 260 it is necessary to distinguish a range of association identifiers 261 that are marked for operator-configured associations to avoid any 262 association identifier clash within the scope of the association 263 source. This document assumes that these two ranges are configured. 265 A range of association identifier for each Association type (and 266 Association Source) are kept for the operator-configured 267 associations. Dynamic associations MUST NOT use the association 268 identifier from this range. 270 This range as set at the PCEP speaker (PCC or PCE, as an association 271 source) needs to be communicated to a PCEP peer in the Open Message. 272 A new TLV is defined in this specification for this purpose 273 (Section 5). See Appendix A for an example. 275 Association identifier range for sources other than the PCEP speaker 276 (for example an NMS system) is not communicated in PCEP and the 277 procedure for operator-configured association range setting is 278 outside the scope of this document. 280 4. Discovery of Supported Association Types 282 This section defines PCEP extensions so as to support the capability 283 advertisement of the association types supported by a PCEP speaker. 285 A new PCEP ASSOC-Type-List (Association Types list) TLV is defined. 286 The PCEP ASSOC-Type-List TLV is carried within an OPEN object. This 287 way, during PCEP session-setup phase, a PCEP speaker can advertise to 288 a PCEP peer the list of supported Association types. 290 4.1. ASSOC-Type-List TLV 292 The PCEP ASSOC-Type-List TLV is optional. It MAY be carried within 293 an OPEN object sent by a PCEP speaker in an Open message to a PCEP 294 peer so as to indicate the list of supported Association types. 296 The PCEP ASSOC-Type-List TLV format is compliant with the PCEP TLV 297 format defined in [RFC5440]. That is, the TLV is composed of 2 298 octets for the type, 2 octets specifying the TLV length, and a Value 299 field. The Length field defines the length of the value portion in 300 octets. The TLV is padded to 4-octet alignment, and padding is not 301 included in the Length field (e.g., a 3-octet value would have a 302 length of three, but the total size of the TLV would be eight 303 octets). 305 The PCEP ASSOC-Type-List TLV has the following format: 307 TYPE: TBD 308 LENGTH: N * 2 (where N is the number of association types) 309 VALUE: list of 2-byte association type code points, identifying 310 the association types supported by the sender of the Open 311 message. 313 0 1 2 3 314 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 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | Assoc-type #1 | Assoc-type #2 | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 // // 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Assoc-type #N | padding | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 Figure 1: The ASSOC-Type-List TLV format 325 Assoc-type (2 bytes): Association type code point identifier. IANA 326 manages the "ASSOCIATION Type Field" code point registry (see 327 Section 7.4). 329 4.1.1. Procedure 331 A PCEP speaker MAY include an ASSOC-Type-List TLV within an OPEN 332 object in an Open message sent to a PCEP peer in order to advertise a 333 set of one or more supported association types. The ASSOC-Type-List 334 TLV MUST NOT appear more than once in an OPEN object. If it appears 335 more than once, the PCEP session MUST be rejected with error type 1 336 and error value 1 (PCEP session establishment failure / Reception of 337 an invalid Open message). As specified in [RFC5440], a PCEP peer 338 that does not recognize the ASSOC-Type-List TLV will silently ignore 339 it. 341 The use of ASSOC-Type-List TLV is OPTIONAL. Thus the absence of the 342 ASSOC-Type-List TLV in an OPEN object MUST be interpreted as an 343 absence of information on the list of supported Association types 344 (rather than the Association type is not supported). In this case, 345 the PCEP speaker could still use the ASSOCIATION object: if the peer 346 does not support the association, it will react as per the procedure 347 described in Section 6.4. 349 Association type (to be defined in other documents) can specify if 350 the association type advertisement is mandatory for it. For an 351 association type that specifies that the advertisement is mandatory, 352 a missing Assoc-type in the ASSOC-Type-List TLV (or missing ASSOC- 353 Type-List TLV) is to be interpreted as the association type is not 354 supported by the PCEP speaker. 356 In case the use of the ASSOC-Type-List TLV is triggered by a 357 mandatory association type, then it is RECOMMENDED that the PCEP 358 implementation include all supported Association types (including 359 optional) to ease the operations of the PCEP peer. 361 5. Operator-configured Association Range TLV 363 This section defines PCEP extension to support the advertisement of 364 the Operator-configured Association Range used for an Association 365 type by the PCEP speaker (as an Association source). 367 A new PCEP OP-CONF-ASSOC-RANGE (Operator-configured Association 368 Range) TLV is defined. The PCEP OP-CONF-ASSOC-RANGE TLV is carried 369 within an OPEN object. This way, during PCEP session-setup phase, a 370 PCEP speaker can advertise to a PCEP peer the Operator-configured 371 Association Range for an association type. 373 The PCEP OP-CONF-ASSOC-RANGE TLV is optional. It MAY be carried 374 within an OPEN object sent by a PCEP speaker in an Open message to a 375 PCEP peer. The OP-CONF-ASSOC-RANGE TLV format is compliant with the 376 PCEP TLV format defined in [RFC5440]. That is, the TLV is composed 377 of 2 bytes for the type, 2 bytes specifying the TLV length, and a 378 Value field. The Length field defines the length of the value 379 portion in bytes. 381 The PCEP OP-CONF-ASSOC-RANGE TLV has the following format: 383 TYPE: 29 (Early allocation by IANA) 384 LENGTH: N * 8 (where N is the number of association types) 385 VALUE: 387 0 1 2 3 388 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 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Reserved | Assoc-type #1 | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | Start-Assoc-ID #1 | Range #1 | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 // // 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | Reserved | Assoc-type #N | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | Start-Assoc-ID #N | Range #N | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 Figure 2: The OP-CONF-ASSOC-RANGE TLV format 403 The Value portion includes the following fields, repeated for each 404 association type: 406 Reserved (2 bytes): This field MUST be set to 0 on transmission 407 and MUST be ignored on receipt. 409 Assoc-type (2 bytes): The association type (Section 7.4). The 410 association type are defined in separate documents. 412 Start-Assoc-ID (2 bytes): The start association identifier for the 413 Operator-configured Association Range for the particular 414 association type. The values 0 and 0xffff MUST NOT be used. 416 Range (2 bytes): The number of associations marked for the 417 Operator-configured Associations. The Range MUST be greater than 418 0, and it MUST be such that (Start-Assoc-ID + Range) do not cross 419 the association identifier range of 0xffff. 421 5.1. Procedure 423 A PCEP speaker MAY include an OP-CONF-ASSOC-RANGE TLV within an OPEN 424 object in an Open message sent to a PCEP peer in order to advertise 425 the Operator-configured Association Range for an association type. 426 The OP-CONF-ASSOC-RANGE TLV MUST NOT appear more than once in an OPEN 427 object. If it appears more than once, the PCEP session MUST be 428 rejected with error type 1 and error value 1 (PCEP session 429 establishment failure / Reception of an invalid Open message). 431 As specified in [RFC5440], a PCEP peer that does not recognize the 432 OP-CONF-ASSOC-RANGE TLV will silently ignore it. 434 The Operator-configured Association Range SHOULD be included for each 435 association type that could be both dynamic and operator-configured. 436 For association types that are only dynamic or only operator- 437 configured, this TLV MAY be skipped, in which case the full range of 438 association identifier is considered dynamic or operator-configured 439 respectively. Each association type (that are defined in separate 440 documents) can specify the default value for the operator-configured 441 association range for their respective association type. 443 The absence of the OP-CONF-ASSOC-RANGE TLV in an OPEN object MUST be 444 interpreted as an absence of explicit Operator-configured Association 445 Range at the PCEP peer. In this case, the default behavior as per 446 each association type applies. If the association source is not a 447 PCEP speaker, the default value for the operator-configured 448 association range is used for the association source. 450 If the Assoc-type is not recognized or supported by the PCEP speaker, 451 it MUST ignore that respective Start-Assoc-ID and Range. If the 452 Start-Assoc-ID or Range are set incorrectly, the PCEP session MUST be 453 rejected with error type 1 and error value 1 (PCEP session 454 establishment failure / Reception of an invalid Open message). 456 The Assoc-type MAY appear more than once in the OP-CONF-ASSOC-RANGE 457 TLV in the case of a non-contiguous Operator-configured Association 458 Range. The PCEP speaker originating this TLV MUST NOT carry 459 overlapping ranges for an association type. If a PCEP peer receives 460 overlapping ranges for an association type, it MUST consider the Open 461 message malformed and MUST reject the PCEP session with error type 1 462 and error value 1 (PCEP session establishment failure / Reception of 463 an invalid Open message). 465 There may be cases where an operator-configured association was 466 configured with association parameters (such as association 467 identifier, association type and association source) at the local 468 PCEP speaker, and later the PCEP session gets established with the 469 association source and a new operator-configured range is learned 470 during session establishment. At this time, the local PCEP speaker 471 MUST remove any associations that are not in the new operator- 472 configured range (by disassociating any LSPs that are part of it (and 473 notifying this change to the PCEP peer)). If a PCEP speaker receives 474 an association for an operator-configured association and the 475 association identifier is not in the operator-configured association 476 range for the association type and association source, it MUST 477 generate an error (as described in Section 6.4). 479 6. ASSOCIATION Object 481 6.1. Object Definition 483 Association groups and their memberships are defined using a new 484 ASSOCIATION object. 486 ASSOCIATION Object-Class is 40 (Early allocation by IANA). 488 ASSOCIATION Object-Type is 1 for IPv4 and its format is shown in 489 Figure 3: 491 0 1 2 3 492 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 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | Reserved | Flags |R| 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | Association type | Association ID | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | IPv4 Association Source | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 // Optional TLVs // 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 Figure 3: The IPv4 ASSOCIATION Object format 505 ASSOCIATION Object-Type is 2 for IPv6 and its format is shown in 506 Figure 4: 508 0 1 2 3 509 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 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | Reserved | Flags |R| 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | Association type | Association ID | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | | 516 | IPv6 Association Source | 517 | | 518 | | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 // Optional TLVs // 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 Figure 4: The IPv6 ASSOCIATION Object format 525 Reserved (2-byte): MUST be set to 0 and ignored upon receipt. 527 Flags (2-byte): The following flags are currently defined: 529 R (Removal - 1 bit): when set, the requesting PCEP peer requires the 530 removal of an LSP from the association group. When unset, the 531 PCEP peer indicates that the LSP is added or retained as part of 532 the association group. This flag is used for the ASSOCIATION 533 object in the PCRpt and the PCUpd message, the flag is ignored in 534 other PCEP messages. 536 Association type (2-byte): the association type (Section 7.4). The 537 association type are defined in separate documents. 539 Association ID (2-byte): the identifier of the association group. 540 When combined with other association parameters, such as Association 541 Type and Association Source, this value uniquely identifies an 542 association group. The values 0xffff and 0x0 are reserved. The 543 value 0xffff is used to indicate all association groups and could be 544 used with R flag to indicate removal for all associations for the LSP 545 within the scope of association type and association source. 547 Association Source: 4 or 16 bytes - A valid IPv4 or IPv6 address that 548 provides scoping for the Association ID. See Section 6.1.3 for 549 details. 551 Optional TLVs: The optional TLVs follow the PCEP TLV format of 552 [RFC5440]. This document defines two optional TLVs. Other documents 553 can define more TLVs in future. 555 6.1.1. Global Association Source TLV 557 The Global Association Source TLV is an optional TLV for use in the 558 Association Object. The meaning and the usage of Global Association 559 Source is as per [RFC6780]. 561 0 1 2 3 562 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 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | Type | Length | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | Global Association Source | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 Figure 5: The Global Association Source TLV format 571 Type: 30 (Early allocation by IANA). 573 Length: Fixed value of 4 bytes. 575 Global Association Source: as defined in [RFC6780]. 577 6.1.2. Extended Association ID TLV 579 The Extended Association ID TLV is an optional TLV for use in the 580 Association Object. The meaning and the usage of Extended 581 Association ID is as per [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 // Extended Association ID // 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 Figure 6: The Extended Association ID TLV format 593 Type: 31 (Early allocation by IANA). 595 Length: variable. 597 Extended Association ID: as defined in [RFC6780]. 599 6.1.3. Association Source 601 The Association Source field in the ASSOCIATION object is set to a 602 valid IP address to identify the node that originates the 603 association. In case of dynamic associations, the association source 604 is usually set as the local PCEP speaker address, unless local policy 605 dictates otherwise, in which case association source is set based on 606 the local policy. In case of PCE redundancy, local policy could set 607 the source as a virtual IP address which identifies all instances of 608 the PCE. In case of operator-configured association, the association 609 source is manually configured and it could be set as one of the PCEP 610 speakers, Network Management System (NMS), or any other valid IP 611 address that scopes the association identifier for the association 612 type. 614 6.1.4. Unique Identification for an Association Group 616 The combination of the mandatory fields Association type, Association 617 ID and Association Source in the ASSOCIATION object uniquely identify 618 the association group. If the optional TLVs - Global Association 619 Source or Extended Association ID are included, then they MUST be 620 included in combination with mandatory fields to uniquely identifying 621 the association group. In this document, all these fields are called 622 'association parameters'. Note that the ASSOCIATION object MAY 623 include other optional TLVs (not defined in this document) based on 624 the association types, that provides 'information' related to the 625 association type, this document uses the term 'association 626 information' for it. 628 6.2. Relationship with the RSVP ASSOCIATION 630 The format of PCEP ASSOCIATION Object defined in this document is 631 aligned with the RSVP ASSOCIATION object ([RFC6780]). Various 632 Association types related to RSVP association are defined in 633 [RFC4872], [RFC4873], and [RFC7551]. The PCEP extensions that define 634 new association types, should clarify how the PCEP associations would 635 work with RSVP associations and vice-versa. 637 6.3. Object Encoding in PCEP messages 639 Message formats in this document are expressed using Reduced BNF 640 (RBNF) as used in [RFC5440] and defined in [RFC5511]. 642 6.3.1. Stateful PCEP messages 644 The ASSOCIATION Object is OPTIONAL and MAY be carried in the Path 645 Computation Update (PCUpd), Path Computation Report (PCRpt) and Path 646 Computation Initiate (PCInitiate) messages. 648 When carried in PCRpt message, it is used to report the association 649 group membership pertaining to a LSP to a stateful PCE. The PCRpt 650 message are used for both initial state synchronization operations 651 (Section 5.6 of [RFC8231]) as well as whenever the state of the LSP 652 changes. The associations MUST be included during the state 653 synchronization operations. 655 The PCRpt message can also be used to remove an LSP from one or more 656 association groups by setting the R flag to 1 in the ASSOCIATION 657 object. 659 The PCRpt message is defined in [RFC8231] and updated as below: 661 ::= 662 663 Where: 665 ::= [] 667 ::= [] 668 669 [] 670 671 Where: 672 ::= 673 [] 674 676 ::= [] 678 When an LSP is delegated to a stateful PCE, the stateful PCE can 679 create a new association group for this LSP, or associate it with one 680 or more existing association groups. This is done by including the 681 ASSOCIATION Object in a PCUpd message. A stateful PCE can also 682 remove a delegated LSP from one or more association groups by setting 683 the R flag to 1 in the ASSOCIATION object. 685 The PCUpd message is defined in [RFC8231] and updated as below: 687 ::= 688 689 Where: 691 ::= [] 693 ::= 694 695 [] 696 697 Where: 698 ::= 700 ::= [] 702 Unless a PCEP speaker wants to delete an association from an LSP or 703 make changes to the association, it does not need to carry the 704 ASSOCIATION object in future stateful messages. 706 A PCE initiating a new LSP can also include the association groups 707 that this LSP belongs to. This is done by including the ASSOCIATION 708 Object in a PCInitiate message. The PCInitiate message is defined in 709 [RFC8281] and updated as below: 711 ::= 712 713 Where: 715 ::= 716 [] 718 ::= (| 719 ) 721 ::= 722 723 [] 724 725 [] 726 [] 728 Where: 729 ::= [] 731 6.3.2. Request Message 733 In case of passive (stateful or stateless) PCE, the ASSOCIATION 734 Object is OPTIONAL and MAY be carried in the Path Computation Request 735 (PCReq) message. 737 When carried in a PCReq message, the ASSOCIATION Object is used to 738 associate the path computation request to an association group. The 739 association (and the other LSPs) should be known to the PCE before 740 hand. These could be operator-configured or dynamically learned 741 before via stateful PCEP messages. The R flag in ASSOCIATION object 742 within PCReq message MUST be set to 0 while sending and ignored on 743 receipt. 745 The PCReq message is defined in [RFC5440] and updated in [RFC8231] , 746 it is further updated below for association: 748 ::= 749 [] 750 752 Where: 753 ::= [] 754 ::= [] 756 ::= 757 758 [] 759 [] 760 [] 761 [] 762 [] 763 [[]] 764 [] 765 [] 767 Where: 768 ::= [] 770 Note that the LSP object MAY be present for the passive stateful PCE 771 mode. 773 6.3.3. Reply Message 775 In case of passive (stateful or stateless) PCE, the ASSOCIATION 776 Object is OPTIONAL and MAY be carried in the Path Computation Reply 777 (PCRep) message with the NO-PATH object. The ASSOCIATION object in 778 PCRep message indicates the association group that cause the PCE to 779 fail to find a path. 781 The PCRep message is defined in [RFC5440] and updated in [RFC8231] , 782 it is further updated below for association: 784 ::= 785 786 Where: 788 ::=[] 790 ::= 791 [] 792 [] 793 [] 794 [] 795 [] 797 Where: 798 ::= [] 800 Note that the LSP object MAY be present for the passive stateful PCE 801 mode. 803 6.4. Processing Rules 805 Association groups can be operator-configured on the necessary PCEP 806 speakers and the PCEP speakers can join the existing association 807 groups. In addition, a PCC or a PCE can create association groups 808 dynamically and the PCEP speaker can also report the associations to 809 its peer via PCEP messages. The operator-configured associations are 810 created via configurations (where all association parameters are 811 manually set) and exist until explicitly removed via configurations. 812 The PCEP speaker can add LSPs to these configured associations and 813 carry this via stateful PCEP messages. The dynamic associations are 814 created dynamically by the PCEP speaker (where all association 815 parameters are populated dynamically). The association group is 816 attached to LSP state and the association exist till there is an 817 existing LSP state as part of the association. As described in 818 Section 6.1.4, the association parameters are the combination of 819 Association type, Association ID and Association Source as well as 820 optional global source and extended association identifier, that 821 uniquely identifies an association group. The information related to 822 the association types encoded via the TLVs of a particular 823 association type (not described in this document) are the association 824 information (Section 6.1.4). 826 If a PCEP speaker does not recognize the ASSOCIATION object, it will 827 return a PCErr message with Error-Type "Unknown Object" as described 828 in [RFC5440]. If a PCEP speaker understand the ASSOCIATION object 829 but does not support the Association type, it MUST return a PCErr 830 message with Error-Type 26 (Early allocation by IANA) "Association 831 Error" and Error-Value 1 "Association type is not supported". If any 832 association parameters are invalid in the ASSOCIATION object, the 833 PCEP speaker would consider this as malformed object and handle it as 834 malformed message [RFC5440]. On receiving a PCEP message with 835 ASSOCIATION, if a PCEP speaker finds that too many LSPs belong to the 836 association group, it MUST return a PCErr message with Error-Type 26 837 (Early allocation by IANA) "Association Error" and Error-Value 2 "Too 838 many LSPs in the association group". If a PCEP speaker cannot handle 839 a new associations, it MUST return a PCErr message with Error-Type 26 840 (Early allocation by IANA) "Association Error" and Error-Value 3 "Too 841 many association groups". These numbers MAY be set by operator or 842 decided based on a local policy. 844 If a PCE peer is unwilling or unable to process the ASSOCIATION 845 object, it MUST return a PCErr message with the Error-Type "Not 846 supported object" and follow the relevant procedures described in 847 [RFC5440]. On receiving a PCEP message with ASSOCIATION, if a PCEP 848 speaker could not add the LSP to the association group for any 849 reason, it MUST return a PCErr message with Error-Type 26 (Early 850 allocation by IANA) "Association Error" and Error-Value 7 "Cannot 851 join the association group". 853 If a PCEP speaker receives an ASSOCIATION object for an operator- 854 configured association and the association identifier is not in the 855 operator-configured association range for the Association type and 856 Association Source, it MUST return a PCErr message with Error-Type 26 857 (Early allocation by IANA) "Association Error" and Error-Value 8 858 "Association identifier not in range". 860 If a PCEP speaker receives ASSOCIATION in PCReq message, and the 861 association is not known (association is not configured, or created 862 dynamically, or learned from a PCEP peer), it MUST return a PCErr 863 message with Error-Type 26 (Early allocation by IANA) "Association 864 Error" and Error-Value 4 "Association unknown". 866 If the association information (related to the association group as a 867 whole) received from the peer does not match with the local operator- 868 configured information, it MUST return a PCErr message with Error- 869 Type 26 (Early allocation by IANA) "Association Error" and Error- 870 Value 5 "Operator-configured association information mismatch". On 871 receiving association information (related to the association group 872 as a whole) that does not match with the association information 873 previously received about the same association from a peer, it MUST 874 return a PCErr message with Error-Type 26 (Early allocation by IANA) 875 "Association Error" and Error-Value 6 "Association information 876 mismatch". Note that information related to each LSP within the 877 association as part of the association information TLVs could be 878 different. 880 If a PCEP speaker receives an ASSOCIATION object with the R bit set 881 for removal, and the association group (identified by association 882 parameters) is not known, it MUST return a PCErr message with Error- 883 Type 26 (Early allocation by IANA) "Association Error" and Error- 884 Value 4 "Association unknown". 886 The dynamic associations are cleared along with the LSP state 887 information as per the [RFC8231]. When a PCEP session is terminated, 888 after expiry of State Timeout Interval at PCC, the LSP state 889 associated with that PCEP session is reverted to operator-defined 890 default parameters or behaviors. Same procedure is also followed for 891 the association groups. On session termination at the PCE, when the 892 LSP state reported by PCC is cleared, the association groups are also 893 cleared. When there are no LSPs in an association group, the 894 association is considered to be empty and thus deleted. 896 In case the LSP is delegated to another PCE on session failure, the 897 associations (and association information) set by the PCE remains 898 intact, unless updated by the new PCE that takes over. 900 Upon LSP delegation revocation, the PCC MAY clear the association 901 created by the PCE, but in order to avoid traffic loss, it SHOULD 902 perform this in a make-before-break fashion (same as [RFC8231]). 904 7. IANA Considerations 906 IANA maintains the "Path Computation Element Protocol (PCEP) Numbers" 907 registry at . 909 7.1. PCEP Object 911 The "PCEP Numbers" registry contains a subregistry "PCEP Objects". 912 IANA is requested to confirm the early allocation of the following 913 code point in the PCEP Objects registry. 915 Object-Class Value Name Reference 917 40 (Early allocation by Association [This.I-D] 918 IANA) 919 Object-Type 920 0: Reserved 921 1: IPv4 922 2: IPv6 924 7.2. PCEP TLV 926 IANA is requested to confirm the early allocation of the following 927 code point in the "PCEP TLV Type Indicators" registry. 929 Value Meaning Reference 930 29 (Early Operator-configured [This.I-D] 931 allocation by Association Range 932 IANA) 933 30 (Early Global Association Source [This.I-D] 934 allocation by 935 IANA) 936 31 (Early Extended Association Id [This.I-D] 937 allocation by 938 IANA) 940 IANA is also requested to make a new assignment for the existing 941 "PCEP TLV Type Indicators" registry as follows: 943 Value Meaning Reference 944 TBD ASSOC-Type-List [This.I-D] 946 7.3. Association Flags 948 This document requests IANA to create a subregistry of the "PCEP 949 Numbers" for the bits carried in the Flags field of the ASSOCIATION 950 object. The subregistry is called "ASSOCIATION Flags Field". New 951 values are assigned by Standards Action [RFC8126]. Each bit should 952 be tracked with the following qualities: 954 o Bit number (counting from bit 0 as the most significant bit) 956 o Capability description 958 o Defining RFC 960 Bit Description Reference 962 15 R (Removal) [This.I-D] 964 7.4. Association Type 966 This document requests IANA to create a subregistry of the "PCEP 967 Numbers" for the Association Type field of the the ASSOCIATION 968 object. The subregistry is called "ASSOCIATION Type Field". New 969 values are to be assigned by Standards Action [RFC8126]. Each value 970 should be tracked with the following qualities: 972 o Type 974 o Name 976 o Reference 978 There are no association type specified in this document, future 979 documents should request the assignment of association types from 980 this subregistry. 982 7.5. PCEP-Error Object 984 IANA is requested to confirm the early allocation of the following 985 code points within the "PCEP-ERROR Object Error Types and Values" 986 sub-registry of the "PCEP Numbers" registry, as follows: 988 Error-Type Meaning 989 26 Association Error [This.I-D] 990 (early Error-value=0: 991 alloc by Unassigned 992 IANA) Error-value=1: 993 Association type is not supported 994 Error-value=2: 995 Too many LSPs in the association group 996 Error-value=3: 997 Too many association groups 998 Error-value=4: 999 Association unknown 1000 Error-value=5: 1001 Operator-configured association 1002 information mismatch 1003 Error-value=6: 1004 Association information mismatch 1005 Error-value=7: 1006 Cannot join the association group 1007 Error-value=8: 1008 Association identifier not in range 1010 8. Security Considerations 1012 The security considerations described in [RFC8231] and [RFC5440] 1013 apply to the extensions described in this document as well. 1014 Additional considerations related to a malicious PCEP speaker are 1015 introduced, as associations could be spoofed and could be used as an 1016 attack vector. An attacker could report too many associations in an 1017 attempt to load the PCEP peer. The PCEP peer responds with PCErr as 1018 described in Section 6.4. An attacker could impact LSP operations by 1019 creating bogus associations. Further, association groups could 1020 provides an adversary with the opportunity to eavesdrop on the 1021 relationship between the LSPs. Thus securing the PCEP session using 1022 Transport Layer Security (TLS) [RFC8253], as per the recommendations 1023 and best current practices in [RFC7525], is RECOMMENDED. 1025 Much of the information carried in the ASSOCIATION object, as per 1026 this document is not extra sensitive. It often reflects information 1027 that can also be derived from the LSP Database, but association 1028 provides a much easier grouping of related LSPs and messages. 1029 Implementations and operator can and should use indirect values in 1030 ASSOCIATION as a way to hide any sensitive business relationships. 1032 9. Manageability Considerations 1034 All manageability requirements and considerations listed in [RFC5440] 1035 and [RFC8231] apply to PCEP protocol extensions defined in this 1036 document. In addition, requirements and considerations listed in 1037 this section apply. 1039 9.1. Control of Function and Policy 1041 A PCE or PCC implementation MUST allow operator-configured 1042 associations and SHOULD allow setting of the operator-configured 1043 association range (Section 3.4) as described in this document. 1045 9.2. Information and Data Models 1047 An implementation SHOULD allow the operator to view the associations 1048 configured or created dynamically. Further implementation SHOULD 1049 allow to view associations reported by each peer, and the current set 1050 of LSPs in the association. To serve this purpose, the PCEP YANG 1051 module [I-D.ietf-pce-pcep-yang] includes association groups. 1053 It might also be useful to find out how many associations for each 1054 association type currently exist and to know how many free 1055 association identifiers are available for a particular association 1056 type and source. 1058 9.3. Liveness Detection and Monitoring 1060 Mechanisms defined in this document do not imply any new liveness 1061 detection and monitoring requirements in addition to those already 1062 listed in [RFC5440]. 1064 9.4. Verify Correct Operations 1066 Mechanisms defined in this document do not imply any new operation 1067 verification requirements in addition to those already listed in 1068 [RFC5440] and [RFC8231]. 1070 9.5. Requirements on Other Protocols 1072 Mechanisms defined in this document do not imply any new requirements 1073 on other protocols. 1075 9.6. Impact on Network Operations 1077 Mechanisms defined in [RFC5440] and [RFC8231] also apply to PCEP 1078 extensions defined in this document. 1080 10. Acknowledgments 1082 We would like to thank Yuji Kamite and Joshua George for their 1083 contributions to this document. Also thanks to Venugopal Reddy, 1084 Cyril Margaria, Rakesh Gandhi and Adrian Farrel for their useful 1085 comments. 1087 We would like to thank Julien Meuric for shepherding this document 1088 and providing comments with text suggestions. 1090 11. Contributors 1091 Stephane Litkowski 1092 Orange 1094 Email: stephane.litkowski@orange.com 1096 Xian Zhang 1097 Huawei Technologies 1098 F3-1-B RnD Center, Huawei Base 1099 Bantian, Longgang District 1100 Shenzhen 518129 1101 China 1103 Email: zhang.xian@huawei.com 1105 Mustapha Aissaoui 1106 Nokia 1108 Email: mustapha.aissaoui@nokia.com 1110 12. References 1112 12.1. Normative References 1114 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1115 Requirement Levels", BCP 14, RFC 2119, 1116 DOI 10.17487/RFC2119, March 1997, 1117 . 1119 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1120 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1121 DOI 10.17487/RFC5440, March 2009, 1122 . 1124 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 1125 Used to Form Encoding Rules in Various Routing Protocol 1126 Specifications", RFC 5511, DOI 10.17487/RFC5511, April 1127 2009, . 1129 [RFC6780] Berger, L., Le Faucheur, F., and A. Narayanan, "RSVP 1130 ASSOCIATION Object Extensions", RFC 6780, 1131 DOI 10.17487/RFC6780, October 2012, 1132 . 1134 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1135 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1136 May 2017, . 1138 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1139 Computation Element Communication Protocol (PCEP) 1140 Extensions for Stateful PCE", RFC 8231, 1141 DOI 10.17487/RFC8231, September 2017, 1142 . 1144 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 1145 Computation Element Communication Protocol (PCEP) 1146 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 1147 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 1148 . 1150 12.2. Informative References 1152 [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation 1153 Element (PCE) Communication Protocol Generic 1154 Requirements", RFC 4657, DOI 10.17487/RFC4657, September 1155 2006, . 1157 [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, 1158 Ed., "RSVP-TE Extensions in Support of End-to-End 1159 Generalized Multi-Protocol Label Switching (GMPLS) 1160 Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007, 1161 . 1163 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, 1164 "GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873, 1165 May 2007, . 1167 [RFC6007] Nishioka, I. and D. King, "Use of the Synchronization 1168 VECtor (SVEC) List for Synchronized Dependent Path 1169 Computations", RFC 6007, DOI 10.17487/RFC6007, September 1170 2010, . 1172 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1173 "Recommendations for Secure Use of Transport Layer 1174 Security (TLS) and Datagram Transport Layer Security 1175 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1176 2015, . 1178 [RFC7551] Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE 1179 Extensions for Associated Bidirectional Label Switched 1180 Paths (LSPs)", RFC 7551, DOI 10.17487/RFC7551, May 2015, 1181 . 1183 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 1184 Stateful Path Computation Element (PCE)", RFC 8051, 1185 DOI 10.17487/RFC8051, January 2017, 1186 . 1188 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1189 Writing an IANA Considerations Section in RFCs", BCP 26, 1190 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1191 . 1193 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 1194 "PCEPS: Usage of TLS to Provide a Secure Transport for the 1195 Path Computation Element Communication Protocol (PCEP)", 1196 RFC 8253, DOI 10.17487/RFC8253, October 2017, 1197 . 1199 [I-D.ietf-pce-pcep-yang] 1200 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 1201 YANG Data Model for Path Computation Element 1202 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 1203 yang-09 (work in progress), October 2018. 1205 Appendix A. Example for Operator-configured Association Range 1207 Consider an association type T1 (which allows both dynamic and 1208 operator-configured association with a default range of <0x1000, 1209 0xffff>). Consider that, because of need of the network, the PCE 1210 needs to create more dynamic associations and would like to change 1211 the association range to <0xbffe, 0xffff> instead. During PCEP 1212 session establishment the PCE would advertise the new range, the PCC 1213 could skip advertising as the default values are used. If a PCC is 1214 creating a dynamic association (with PCC as association source) it 1215 needs to pick a free association identifier for type T1 in the range 1216 of <0x1, 0x0fff> whereas if a PCE is creating a dynamic association 1217 (with PCE as association source) it needs to pick a free association 1218 identifier from the range <0x1, 0xbffd>. Similarly if an operator- 1219 configured association is manually configured with the PCC as 1220 association source, it should be from the range <0x1000, 0xffff> 1221 whereas if the PCE is association source, it should be from <0xbffe, 1222 0xffff>. In case the association source is not a PCEP peer (for 1223 example an NMS system), then the default range of <0x1000, 0xffff> is 1224 considered. 1226 Authors' Addresses 1227 Ina Minei 1228 Google, Inc. 1229 1600 Amphitheatre Parkway 1230 Mountain View, CA 94043 1231 US 1233 Email: inaminei@google.com 1235 Edward Crabbe 1236 Individual Contributor 1238 Email: edward.crabbe@gmail.com 1240 Siva Sivabalan 1241 Cisco Systems, Inc. 1242 170 West Tasman Dr. 1243 San Jose, CA 95134 1244 US 1246 Email: msiva@cisco.com 1248 Hariharan Ananthakrishnan 1249 Netflix 1251 Email: hari@netflix.com 1253 Dhruv Dhody 1254 Huawei 1255 Divyashree Techno Park, Whitefield 1256 Bangalore, KA 560066 1257 India 1259 Email: dhruv.ietf@gmail.com 1261 Yosuke Tanaka 1262 NTT Communications Corporation 1263 Granpark Tower 3-4-1 Shibaura, Minato-ku 1264 Tokyo 108-8118 1265 Japan 1267 Email: yosuke.tanaka@ntt.com