idnits 2.17.1 draft-ietf-pce-association-group-07.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 (December 18, 2018) is 1927 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'This I-D' is mentioned on line 981, but not defined -- 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 (~~), 3 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: June 21, 2019 Individual Contributor 6 S. Sivabalan 7 Cisco Systems, Inc. 8 H. Ananthakrishnan 9 Packet Design 10 D. Dhody 11 Huawei 12 Y. Tanaka 13 NTT Communications Corporation 14 December 18, 2018 16 PCEP Extensions for Establishing Relationships Between Sets of LSPs 17 draft-ietf-pce-association-group-07 19 Abstract 21 This document introduces a generic mechanism to create a grouping of 22 LSPs in the context of a Path Computation Element (PCE). This 23 grouping can then be used to define associations between sets of LSPs 24 or between a set of LSPs and a set of attributes (such as 25 configuration parameters or behaviors), and is equally applicable to 26 the stateful PCE (active and passive modes) as well as the stateless 27 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 June 21, 2019. 54 Copyright Notice 56 Copyright (c) 2018 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, PCReq, PCRep, PCErr. 155 This document uses the following terms defined in [RFC8051]: Stateful 156 PCE, Active Stateful PCE, Passive Stateful PCE, Delegation. 158 This document uses the following terms defined in [RFC8231]: LSP 159 State Report, LSP Update Request, State Timeout Interval. 161 This document uses the following terms defined in [RFC8281]: PCE- 162 initiated LSP, PCInitiate. 164 3. Architectural Overview 166 3.1. Motivation 168 Stateful PCE provides the ability to update existing LSPs and to 169 instantiate new ones. To enable support for PCE-controlled make- 170 before-break and for protection, there is a need to define 171 associations between LSPs. For example, the association between the 172 original and the re-optimized path in the make-before break scenario, 173 or between the working and protection path in end-to-end protection. 174 Another use for LSP grouping is for applying a common set of 175 configuration parameters or behaviors to a set of LSPs. 177 For a stateless PCE, it might be useful to associate a path 178 computation request to an association group, thus enabling it to 179 associate a common set of policy, configuration parameters or 180 behaviors with the request. 182 Some associations could be created dynamically, such as association 183 between the working and protections LSPs of a tunnel. Whereas some 184 association could be created by the operator manually, such as policy 185 based association, where the LSP could join an operator-configured 186 existing association. 188 Rather than creating separate mechanisms for each use case, this 189 document defines a generic mechanism that can be reused as needed. 191 3.2. Relationship with the SVEC List 193 Note that, [RFC5440] defines a mechanism for the synchronization of a 194 set of path computation requests by using the SVEC (Synchronization 195 VECtor) object, that specifies the list of synchronized requests that 196 can either be dependent or independent. The SVEC object identify the 197 relationship between the set of path computation requests, identified 198 by 'Request-ID-number' in RP (Request Parameters) object. [RFC6007] 199 further clarifies the use of the SVEC list for synchronized path 200 computations when computing dependent requests as well as describes a 201 number of usage scenarios for SVEC lists within single-domain and 202 multi-domain environments. 204 The motivation behind the association group defined in this document 205 and the SVEC object are quite different. The PCEP extensions that 206 defines new association type, should clarify the relationship between 207 SVEC object and association type, if any. 209 3.3. Operation Overview 211 LSPs are associated with other LSPs with which they interact by 212 adding them to a common association group. Association groups as 213 defined in this document can be applied to LSPs originating at the 214 same head end or different head ends. 216 Some associations could be created dynamically by a PCEP speaker and 217 the associations (along with the set of LSPs) are conveyed to a PCEP 218 peer. Whereas, some associations are configured by the operator on 219 the PCEP peers involved before hand, a PCEP speaker then could ask 220 for a LSP to join the operator-configured association. Usage of 221 dynamic and configured association is usually dependent on the type 222 of the association. 224 For the operator-configured association, the association parameters 225 such as the association identifier, association type, as well as the 226 association source IP address is manually configured by the operator. 227 In case of dynamic association, the association parameters such as 228 the association identifier is allocated dynamically by the PCEP 229 speaker, the association source is set as local PCEP speaker address, 230 unless local policy dictates otherwise, in which case association 231 source is set based on the local policy. 233 The dynamically created association can be reported to the PCEP peer 234 via the PCEP messages as per the stateful extensions. While the 235 operator-configured association are known to the PCEP peer before 236 hand, a PCEP peer could ask for a LSP to join the operator-configured 237 association via the stateful PCEP messages. 239 The association are properties of the LSP and thus could be stored in 240 the LSP state database. The dynamic association exist as long as the 241 LSP state. In case of PCEP session termination, the LSP state clean 242 up MUST also take care of associations. 244 Multiple types of associations can exist, each with their own 245 association identifier space. The definition of the different 246 association types and their behaviors is outside the scope of this 247 document. The establishment and removal of the association 248 relationship can be done on a per LSP basis. An LSP may join 249 multiple association groups, of different or of the same association 250 type. 252 3.4. Operator-configured Association Range 254 Some association types are dynamic, some are operator-configured and 255 some could be both. For the association types that could be both 256 dynamic and operator-configured and use the same association source, 257 it is necessary to configure a range of association identifiers that 258 are marked for operator-configured associations to avoid any 259 association identifier clash within the scope of the association 260 source. 262 A range of association identifier for each association-type (and 263 association-source) are kept for the operator-configured 264 associations. Dynamic associations MUST NOT use the association 265 identifier from this range. 267 This range as set at the PCEP speaker (PCC or PCE, as an association 268 source) needs to be communicated to a PCEP peer in the Open Message. 269 A new TLV is defined in this specification for this purpose 270 (Section 5). See Appendix A for an example. 272 Association identifier range for sources other than the PCEP speaker 273 (for example an NMS system) is not communicated in PCEP and the 274 procedure for operator-configured association range setting is 275 outside the scope of this document. 277 4. Discovery of Supported Association Types 279 This section defines PCEP extensions so as to support the capability 280 advertisement of the association types supported by a PCEP speaker. 282 A new PCEP ASSOC-Type-List (Association Types list) TLV is defined. 283 The PCEP ASSOC-Type-List TLV is carried within an OPEN object. This 284 way, during PCEP session-setup phase, a PCEP speaker can advertise to 285 a PCEP peer the list of supported association-types. 287 4.1. ASSOC-Type-List TLV 289 The PCEP ASSOC-Type-List TLV is optional. It MAY be carried within 290 an OPEN object sent by a PCEP speaker in an Open message to a PCEP 291 peer so as to indicate the list of supported association-types. 293 The PCEP ASSOC-Type-List TLV format is compliant with the PCEP TLV 294 format defined in [RFC5440]. That is, the TLV is composed of 2 295 octets for the type, 2 octets specifying the TLV length, and a Value 296 field. The Length field defines the length of the value portion in 297 octets. The TLV is padded to 4-octet alignment, and padding is not 298 included in the Length field (e.g., a 3-octet value would have a 299 length of three, but the total size of the TLV would be eight 300 octets). 302 The PCEP ASSOC-Type-List TLV has the following format: 304 TYPE: TBD 305 LENGTH: N * 2 (where N is the number of association types) 306 VALUE: list of 2-byte association type code points, identifying 307 the association types supported by the sender of the Open 308 message. 310 0 1 2 3 311 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 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Assoc-type #1 | Assoc-type #2 | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 // // 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Assoc-type #N | padding | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 Figure 1: The ASSOC-Type-List TLV format 322 Assoc-type (2 bytes): Association type code point identifier. IANA 323 manages the "ASSOCIATION Type Field" code point registry (see 324 Section 7.4). 326 4.1.1. Procedure 328 A PCEP speaker MAY include an ASSOC-Type-List TLV within an OPEN 329 object in an Open message sent to a PCEP peer in order to advertise a 330 set of one or more supported association types. The ASSOC-Type-List 331 TLV MUST NOT appear more than once in an OPEN object. If it appears 332 more than once, the PCEP session MUST be rejected with error type 1 333 and error value 1 (PCEP session establishment failure / Reception of 334 an invalid Open message). As specified in [RFC5440], a PCEP peer 335 that does not recognize the ASSOC-Type-List TLV will silently ignore 336 it. 338 The use of ASSOC-Type-List TLV is OPTIONAL. Thus the absence of the 339 ASSOC-Type-List TLV in an OPEN object MUST be interpreted as an 340 absence of information on the list of supported association types 341 (rather than the association-type is not supported). The PCEP 342 speaker could still use the ASSOCIATION object, if the peer does not 343 support the association, it would react as per the procedure 344 described in Section 6.4. 346 Association type (to be defined in other documents) can specify if 347 the association type advertisement is mandatory for it. For a 348 association type that specify that the advertisement is mandatory, a 349 missing Assoc-type in the ASSOC-Type-List TLV (or missing ASSOC-Type- 350 List TLV) is to be interpreted as the association type is not 351 supported by the PCEP speaker. 353 It is RECOMMENDED that the PCEP implementation include all supported 354 association-types (including optional) to ease the operations of the 355 PCEP peer. 357 5. Operator-configured Association Range TLV 359 This section defines PCEP extension to support the advertisement of 360 the Operator-configured Association Range used for an association- 361 type by the PCEP speaker (as an association source). 363 A new PCEP OP-CONF-ASSOC-RANGE (Operator-configured Association 364 Range) TLV is defined. The PCEP OP-CONF-ASSOC-RANGE TLV is carried 365 within an OPEN object. This way, during PCEP session-setup phase, a 366 PCEP speaker can advertise to a PCEP peer the Operator-configured 367 Association Range for an association type. 369 The PCEP OP-CONF-ASSOC-RANGE TLV is optional. It MAY be carried 370 within an OPEN object sent by a PCEP speaker in an Open message to a 371 PCEP peer. The OP-CONF-ASSOC-RANGE TLV format is compliant with the 372 PCEP TLV format defined in [RFC5440]. That is, the TLV is composed 373 of 2 bytes for the type, 2 bytes specifying the TLV length, and a 374 Value field. The Length field defines the length of the value 375 portion in bytes. 377 The PCEP OP-CONF-ASSOC-RANGE TLV has the following format: 379 TYPE: 29 (Early allocation by IANA) 380 LENGTH: N * 8 (where N is the number of association types) 381 VALUE: 383 0 1 2 3 384 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 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | Reserved | Assoc-type #1 | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | Start-Assoc-ID #1 | Range #1 | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 // // 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | Reserved | Assoc-type #N | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | Start-Assoc-ID #N | Range #N | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 Figure 2: The OP-CONF-ASSOC-RANGE TLV format 399 The Value portion includes the following fields, repeated for each 400 association type: 402 Reserved (2 bytes): This field MUST be set to 0 on transmission 403 and MUST be ignored on receipt. 405 Assoc-type (2 bytes): The association type (Section 7.4). The 406 association type are defined in separate documents. 408 Start-Assoc-ID (2 bytes): The start association identifier for the 409 Operator-configured Association Range for the particular 410 association type. The values 0 and 0xffff MUST NOT be used. 412 Range (2 bytes): The number of associations marked for the 413 Operator-configured Associations. The Range MUST be greater than 414 0, and it MUST be such that (Start-Assoc-ID + Range) do not cross 415 the association identifier range of 0xffff. 417 5.1. Procedure 419 A PCEP speaker MAY include an OP-CONF-ASSOC-RANGE TLV within an OPEN 420 object in an Open message sent to a PCEP peer in order to advertise 421 the Operator-configured Association Range for an association type. 422 The OP-CONF-ASSOC-RANGE TLV MUST NOT appear more than once in an OPEN 423 object. If it appears more than once, the PCEP session MUST be 424 rejected with error type 1 and error value 1 (PCEP session 425 establishment failure / Reception of an invalid Open message). 427 As specified in [RFC5440], a PCEP peer that does not recognize the 428 OP-CONF-ASSOC-RANGE TLV will silently ignore it. 430 The Operator-configured Association Range SHOULD be included for each 431 association type that could be both dynamic and operator-configured. 432 For association types that are only dynamic or only operator- 433 configured, this TLV MAY be skipped, in which case the full range of 434 association identifier is considered dynamic or operator-configured 435 respectively. Each association type (that are defined in separate 436 documents) can specify the default value for the operator-configured 437 association range for their respective association type. 439 The absence of the OP-CONF-ASSOC-RANGE TLV in an OPEN object MUST be 440 interpreted as an absence of explicit Operator-configured Association 441 Range at the PCEP peer. In which case, the default behavior as per 442 each association type would be applied. If the association source is 443 not a PCEP speaker, the default value for the operator-configured 444 association range is used for the association source. 446 If the Assoc-Type is not recognized or supported by the PCEP speaker, 447 it MUST ignore that respective Start-Assoc-ID and Range. If the 448 Start-Assoc-ID or Range are set incorrectly, the PCEP session MUST be 449 rejected with error type 1 and error value 1 (PCEP session 450 establishment failure / Reception of an invalid Open message). The 451 PCEP speaker originating OP-CONF-ASSOC-RANGE TLV MUST NOT carry 452 overlapping range for an association-type. If a PCEP peer receives 453 overlapping range for the association type, it MUST consider the Open 454 message malformed and MUST reject the PCEP session with error type 1 455 and error value 1 (PCEP session establishment failure / Reception of 456 an invalid Open message). 458 In case, there is an operator-configured association that was 459 configured with association parameters (such as association 460 identifier, association type and association source) at the local 461 PCEP speaker, later the PCEP session gets established with the 462 association source and a new operator-configured range is learned 463 during session establishment. At this time, the local PCEP speaker 464 MUST remove any associations that were not in the new operator 465 configured range (by removing any LSPs that are part of it (and 466 notifying this change to the PCEP peer)). If a PCEP speaker receives 467 an association for an operator configured association and the 468 association identifier is not in the operator-configured association 469 range for the association-type and association-source, it MUST 470 generate an error (as described in Section 6.4). 472 6. ASSOCIATION Object 474 6.1. Object Definition 476 Association groups and their memberships are defined using a new 477 ASSOCIATION object. 479 ASSOCIATION Object-Class is 40 (Early allocation by IANA). 481 ASSOCIATION Object-Type is 1 for IPv4 and its format is shown in 482 Figure 3: 484 0 1 2 3 485 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 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | Reserved | Flags |R| 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | Association type | Association ID | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | IPv4 Association Source | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 // Optional TLVs // 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 Figure 3: The IPv4 ASSOCIATION Object format 498 ASSOCIATION Object-Type is 2 for IPv6 and its format is shown in 499 Figure 4: 501 0 1 2 3 502 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 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | Reserved | Flags |R| 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | Association type | Association ID | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | | 509 | IPv6 Association Source | 510 | | 511 | | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 // Optional TLVs // 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 Figure 4: The IPv6 ASSOCIATION Object format 518 Reserved (2-byte): MUST be set to 0 and ignored upon receipt. 520 Flags (2-byte): The following flags are currently defined: 522 R (Removal - 1 bit): when set, the requesting PCEP peer requires the 523 removal of an LSP from the association group. When unset, the 524 PCEP peer indicates that the LSP is added or retained as part of 525 the association group. This flag is used for the ASSOCIATION 526 object in the PCRpt and the PCUpd message, the flag is ignored in 527 other PCEP messages. 529 Association type (2-byte): the association type (Section 7.4). The 530 association type are defined in separate documents. 532 Association ID (2-byte): the identifier of the association group. 533 When combined with other association parameters, such as Association 534 Type and Association Source, this value uniquely identifies an 535 association group. The value 0xffff and 0x0 are reserved. The value 536 0xffff is used to indicate all association groups and could be used 537 with R flag to indicate removal for all associations for the LSP 538 within the scope of association type and association source. 540 Association Source: 4 or 16 bytes - A valid IPv4 or IPv6 address that 541 provides scoping for the Association ID. See Section 6.1.3 for 542 details. 544 Optional TLVs: The optional TLVs follow the PCEP TLV format of 545 [RFC5440]. This document defines two optional TLVs. Other documents 546 can define more TLVs in future. 548 6.1.1. Global Association Source TLV 550 The Global Association Source TLV is an optional TLV for use in the 551 Association Object. The meaning and the usage of Global Association 552 Source is as per [RFC6780]. 554 0 1 2 3 555 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 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | Type | Length | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | Global Association Source | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 Figure 5: The Global Association Source TLV format 564 Type: 30 (Early allocation by IANA). 566 Length: Fixed value of 4 bytes. 568 Global Association Source: as defined in [RFC6780]. 570 6.1.2. Extended Association ID TLV 572 The Extended Association ID TLV is an optional TLV for use in the 573 Association Object. The meaning and the usage of Extended 574 Association ID is as per [RFC6780]. 576 0 1 2 3 577 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 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | Type | Length | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 // Extended Association ID // 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 Figure 6: The Extended Association ID TLV format 586 Type: 31 (Early allocation by IANA). 588 Length: variable. 590 Extended Association ID: as defined in [RFC6780]. 592 6.1.3. Association Source 594 The Association Source field in the ASSOCIATION object is set to a 595 valid IP address to identify the node that originate the association. 596 In case of dynamic associations, the association source is usually 597 set as the local PCEP speaker address, unless local policy dictates 598 otherwise, in which case association source is set based on the local 599 policy. In case of PCE redundancy, local policy could set the source 600 as virtual IP which identify all instances of PCE. In case of 601 operator configured association, the association source is manually 602 configured and it could be set as one of the PCEP speakers, Network 603 Management System (NMS), or any other valid IP address that scopes 604 the association identifier for the association type. 606 6.1.4. Unique Identification for an Association Group 608 The combination of the mandatory fields Association type, Association 609 ID and Association Source in the ASSOCIATION object uniquely identify 610 the association group. If the optional TLVs - Global Association 611 Source or Extended Association ID are included, then they MUST be 612 included in combination with mandatory fields to uniquely identifying 613 the association group. In this document, all these fields are called 614 'association parameters'. Note that the ASSOCIATION object MAY 615 include other optional TLVs (not defined in this document) based on 616 the association types, that provides 'information' related to the 617 association type, this document uses the term 'association 618 information' for it. 620 6.2. Relationship with the RSVP ASSOCIATION 622 The format of PCEP ASSOCIATION Object defined in this document, is 623 aligned with the RSVP ASSOCIATION object ([RFC6780]). Various 624 Association-Types related to RSVP association are defined in 625 [RFC4872], [RFC4873], and [RFC7551]. The PCEP extensions that 626 defines new association type, should clarify how the PCEP association 627 would work with RSVP association and vice-versa. 629 6.3. Object Encoding in PCEP messages 631 Message formats in this document are expressed using Reduced BNF 632 (RBNF) as used in [RFC5440] and defined in [RFC5511]. 634 6.3.1. Stateful PCEP messages 636 The ASSOCIATION Object is OPTIONAL and MAY be carried in the Path 637 Computation Update (PCUpd), Path Computation Report (PCRpt) and Path 638 Computation Initiate (PCInitiate) messages. 640 When carried in PCRpt message, it is used to report the association 641 group membership pertaining to a LSP to a stateful PCE. The PCRpt 642 message are used for both initial state synchronization operations 643 (Section 5.6 of [RFC8231]) as well as whenever the state of the LSP 644 changes. The associations MUST be included during the state 645 synchronization operations. 647 The PCRpt message can also be used to remove an LSP from one or more 648 association groups by setting the R flag to 1 in the ASSOCIATION 649 object. 651 The PCRpt message is defined in [RFC8231] and updated as below: 653 ::= 654 655 Where: 657 ::= [] 659 ::= [] 660 661 [] 662 663 Where: 664 ::= 665 [] 666 668 ::= [] 670 When an LSP is delegated to a stateful PCE, the stateful PCE can 671 create a new association group for this LSP, or associate it with one 672 or more existing association groups. This is done by including the 673 ASSOCIATION Object in a PCUpd message. A stateful PCE can also 674 remove a delegated LSP from one or more association groups by setting 675 the R flag to 1 in the ASSOCIATION object. 677 The PCUpd message is defined in [RFC8231] and updated as below: 679 ::= 680 681 Where: 683 ::= [] 685 ::= 686 687 [] 688 689 Where: 690 ::= 692 ::= [] 694 Unless, a PCEP speaker wants to delete an association from an LSP or 695 make changes to the association, it does not need to carry the 696 ASSOCIATION object in future stateful messages. 698 A PCE initiating a new LSP, can also include the association groups 699 that this LSP belongs to. This is done by including the ASSOCIATION 700 Object in a PCInitiate message. The PCInitiate message is defined in 701 [RFC8281] and updated as below: 703 ::= 704 705 Where: 707 ::= 708 [] 710 ::= (| 711 ) 713 ::= 714 715 [] 716 717 [] 718 [] 720 Where: 721 ::= [] 723 6.3.2. Request Message 725 In case of passive stateful or stateless PCE, the ASSOCIATION Object 726 is OPTIONAL and MAY be carried in the Path Computation Request 727 (PCReq) message. 729 When carried in a PCReq message, the ASSOCIATION Object is used to 730 associate the path computation request to an association group. The 731 association (and the other LSPs) should be known to the PCE before 732 hand. These could be operator-configured or dynamically learned 733 before via stateful PCEP messages. The R flag in ASSOCIATION object 734 within PCReq message MUST be set to 0 while sending and ignored on 735 receipt. 737 The PCReq message is defined in [RFC5440] and updated in [RFC8231] , 738 it is further updated below for association: 740 ::= 741 [] 742 744 Where: 745 ::= [] 746 ::= [] 748 ::= 749 750 [] 751 [] 752 [] 753 [] 754 [] 755 [[]] 756 [] 757 [] 759 Where: 760 ::= [] 762 Note that LSP object MAY be present for the passive stateful PCE 763 mode. 765 6.3.3. Reply Message 767 In case of passive stateful or stateless PCE, the ASSOCIATION Object 768 is OPTIONAL and MAY be carried in the Path Computation Reply (PCRep) 769 message with the NO-PATH object. The ASSOCIATION object in PCRep 770 message, indicates the association group that cause the PCE to fail 771 to find a path. 773 The PCRep message is defined in [RFC5440] and updated in [RFC8231] , 774 it is further updated below for association: 776 ::= 777 778 Where: 780 ::=[] 782 ::= 783 [] 784 [] 785 [] 786 [] 787 [] 789 Where: 790 ::= [] 792 Note that LSP object MAY be present for the passive stateful PCE 793 mode. 795 6.4. Processing Rules 797 Association groups can be operator-configured on the necessary PCEP 798 speakers and the PCEP speakers can join the existing association 799 groups. In addition, a PCC or a PCE can create association groups 800 dynamically and the PCEP speaker can also report the associations to 801 its peer via PCEP messages. The operator configured association is 802 created via configurations (where all association parameters are 803 manually set) and exist until explicitly removed via configurations. 804 The PCEP speaker can add LSPs to these configured association and 805 carry this via stateful PCEP messages. The dynamic association are 806 created dynamically by the PCEP speaker (where all association 807 parameters are populated dynamically). The association groups is 808 attached to LSP state and the association exist till there is an 809 existing LSP state as part of the association. As described in 810 Section 6.1.4, the association parameters is combination of 811 Association type, Association ID and Association Source as well as 812 optional global source and extended association identifier that 813 uniquely identify the association group. The information related to 814 the association types encoded via the TLVs of a particular 815 association type (not described in this document) are the association 816 information (Section 6.1.4). 818 If a PCEP speaker does not recognize the ASSOCIATION object, it will 819 return a PCErr message with Error-Type "Unknown Object" as described 820 in [RFC5440]. If a PCEP speaker understand the ASSOCIATION object 821 but does not support the association-type, it MUST return a PCErr 822 message with Error-Type 26 (Early allocation by IANA) "Association 823 Error" and Error-Value 1 "Association-type is not supported". If any 824 association parameters are invalid in the ASSOCIATION object, the 825 PCEP speaker would consider this as malformed object and handle it as 826 malformed message [RFC5440]. On receiving a PCEP message with 827 ASSOCIATION, if a PCEP speaker finds that too many LSPs belong to the 828 association group, it MUST return a PCErr message with Error-Type 26 829 (Early allocation by IANA) "Association Error" and Error-Value 2 "Too 830 many LSPs in the association group". If a PCEP speaker cannot handle 831 a new associations, it MUST return a PCErr message with Error-Type 26 832 (Early allocation by IANA) "Association Error" and Error-Value 3 "Too 833 many association groups". These number MAY be set by operator or 834 decided based on a local policy. 836 If a PCE peer is unwilling or unable to process the ASSOCIATION 837 object, it MUST return a PCErr message with the Error-Type "Not 838 supported object" and follow the relevant procedures described in 839 [RFC5440]. On receiving a PCEP message with ASSOCIATION, if a PCEP 840 speaker could not add the LSP to the association group for any 841 reason, it MUST return a PCErr message with Error-Type 26 (Early 842 allocation by IANA) "Association Error" and Error-Value 7 "Cannot 843 join the association group". 845 If a PCEP speaker receives ASSOCIATION object for an operator 846 configured association and the association identifier is not in the 847 operator-configured association range for the association-type and 848 association-source, it MUST return a PCErr message with Error-Type 26 849 (Early allocation by IANA) "Association Error" and Error-Value 8 850 "Association identifier not in range". 852 If a PCEP speaker receives ASSOCIATION in PCReq message, and the 853 association is not known (association is not configured, or created 854 dynamically, or learned from a PCEP peer), it MUST return a PCErr 855 message with Error-Type 26 (Early allocation by IANA) "Association 856 Error" and Error-Value 4 "Association unknown". 858 If the association information (related to the association group as a 859 whole) received from the peer does not match with the local operator 860 configured information, it MUST return a PCErr message with Error- 861 Type 26 (Early allocation by IANA) "Association Error" and Error- 862 Value 5 "Operator-configured association information mismatch". On 863 receiving association information (related to the association group 864 as a whole) that does not match with the association information 865 previously received about the same association from a peer, it MUST 866 return a PCErr message with Error-Type 26 (Early allocation by IANA) 867 "Association Error" and Error-Value 6 "Association information 868 mismatch". Note that information related to each LSP within the 869 association as part of the association information TLVs could be 870 different. 872 If a PCEP speaker receives ASSOCIATION object with R bit set for 873 removal, and the association group (identified by association 874 parameters) is not known, it MUST return a PCErr message with Error- 875 Type 26 (Early allocation by IANA) "Association Error" and Error- 876 Value 4 "Association unknown". 878 The dynamic associations are cleared along with the LSP state 879 information as per the [RFC8231]. When a PCEP session is terminated, 880 after expiry of State Timeout Interval at PCC, the LSP state 881 associated with that PCEP session is reverted to operator-defined 882 default parameters or behaviors. Same procedure is also followed for 883 the association groups. On session termination at the PCE, when the 884 LSP state reported by PCC is cleared, the association groups are also 885 cleared. When there are no LSPs in an association group, the 886 association is considered to be empty and thus deleted. 888 In case the LSP is delegated to another PCE on session failure, the 889 associations (and association information) set by the PCE remains 890 intact, unless updated by the new PCE that takes over. 892 Upon LSP delegation revocation, the PCC MAY clear the association 893 created by the PCE, but in order to avoid traffic loss, it SHOULD 894 perform this in a make-before-break fashion (same as [RFC8231]). 896 7. IANA Considerations 898 IANA maintains the "Path Computation Element Protocol (PCEP) Numbers" 899 registry at . 901 7.1. PCEP Object 903 The "PCEP Numbers" registry contains a subregistry "PCEP Objects". 904 IANA is requested to confirm the early allocation of the following 905 code point in the PCEP Objects registry. 907 Object-Class Value Name Reference 909 40 (Early allocation by Association [This 910 IANA) I-D] 911 Object-Type 912 0: Reserved 913 1: IPv4 914 2: IPv6 916 7.2. PCEP TLV 918 IANA is requested to confirm the early allocation of the following 919 code point in the "PCEP TLV Type Indicators registry". 921 Value Meaning Reference 922 29 (Early Operator-configured [This I-D] 923 allocation by Association Range 924 IANA) 925 30 (Early Global Association Source [This I-D] 926 allocation by 927 IANA) 928 31 (Early Extended Association Id [This I-D] 929 allocation by 930 IANA) 932 IANA is also requested to make a new assignment for the existing 933 "PCEP TLV Type Indicators" registry as follows: 935 Value Meaning Reference 936 TBD ASSOC-Type-List [This I-D] 938 7.3. Association Flags 940 This document requests IANA to create a subregistry of the "PCEP 941 Numbers" for the bits carried in the Flags field of the ASSOCIATION 942 object. The subregistry is called "ASSOCIATION Flags Field". New 943 values are assigned by Standards Action [RFC8126]. Each bit should 944 be tracked with the following qualities: 946 o Bit number (counting from bit 0 as the most significant bit) 948 o Capability description 950 o Defining RFC 952 Bit Description Reference 954 15 R (Removal) [This I-D] 956 7.4. Association Type 958 This document requests IANA to create a subregistry of the "PCEP 959 Numbers" for the Association Type field of the the ASSOCIATION 960 object. The subregistry is called "ASSOCIATION Type Field". New 961 values are to be assigned by Standards Action [RFC8126]. Each value 962 should be tracked with the following qualities: 964 o Type 966 o Name 968 o Reference 970 There are no association type specified in this document, future 971 document should request the assignment of association types from this 972 subregistry. 974 7.5. PCEP-Error Object 976 IANA is requested to confirm the early allocation of the following 977 code points within the "PCEP-ERROR Object Error Types and Values" 978 sub-registry of the "PCEP Numbers" registry, as follows: 980 Error-Type Meaning 981 26 Association Error [This I-D] 982 (early Error-value=0: 983 alloc by Unassigned 984 IANA) Error-value=1: 985 Association-type is not supported 986 Error-value=2: 987 Too many LSPs in the association group 988 Error-value=3: 989 Too many association groups 990 Error-value=4: 991 Association unknown 992 Error-value=5: 993 Operator-configured association 994 information mismatch 995 Error-value=6: 996 Association information mismatch 997 Error-value=7: 998 Cannot join the association group 999 Error-value=8: 1000 Association identifier not in range 1002 8. Security Considerations 1004 The security considerations described in [RFC8231] and [RFC5440] 1005 apply to the extensions described in this document as well. 1006 Additional considerations related to a malicious PCEP speaker are 1007 introduced, as associations could be spoofed and could be used as an 1008 attack vector. An attacker could report too many associations in an 1009 attempt to load the PCEP peer. The PCEP peer responds with PCErr as 1010 described in Section 6.4. An attacker could impact LSP operations by 1011 creating bogus associations. Further, association groups could 1012 provides an adversary with the opportunity to eavesdrop on the 1013 relationship between the LSPs. Thus securing the PCEP session using 1014 Transport Layer Security (TLS) [RFC8253], as per the recommendations 1015 and best current practices in [RFC7525], is RECOMMENDED. 1017 Much of the information carried in the ASSOCIATION object, as per 1018 this document is not extra sensitive. It often reflects information 1019 that can also be derived from the LSP Database, but association 1020 provides a much easier grouping of related LSPs and messages. 1021 Implementations and operator can and should use indirect values in 1022 ASSOCIATION as a way to hide any sensitive business relationships. 1024 9. Manageability Considerations 1026 All manageability requirements and considerations listed in [RFC5440] 1027 and [RFC8231] apply to PCEP protocol extensions defined in this 1028 document. In addition, requirements and considerations listed in 1029 this section apply. 1031 9.1. Control of Function and Policy 1033 A PCE or PCC implementation MUST allow operator-configured 1034 associations and SHOULD allow setting of the operator-configured 1035 association range (Section 3.4) as described in this document. 1037 9.2. Information and Data Models 1039 An implementation SHOULD allow the operator to view the associations 1040 configured or created dynamically. Further implementation SHOULD 1041 allow to view associations reported by each peer, and the current set 1042 of LSPs in the association. To serve this purpose, the PCEP YANG 1043 module [I-D.ietf-pce-pcep-yang] includes association groups. 1045 It might also be useful to find out how many associations for each 1046 association type currently exist and to know how many free 1047 association identifiers are available for a particular association 1048 type and source. 1050 9.3. Liveness Detection and Monitoring 1052 Mechanisms defined in this document do not imply any new liveness 1053 detection and monitoring requirements in addition to those already 1054 listed in [RFC5440]. 1056 9.4. Verify Correct Operations 1058 Mechanisms defined in this document do not imply any new operation 1059 verification requirements in addition to those already listed in 1060 [RFC5440] and [RFC8231]. 1062 9.5. Requirements On Other Protocols 1064 Mechanisms defined in this document do not imply any new requirements 1065 on other protocols. 1067 9.6. Impact On Network Operations 1069 Mechanisms defined in [RFC5440] and [RFC8231] also apply to PCEP 1070 extensions defined in this document. 1072 10. Acknowledgments 1074 We would like to thank Yuji Kamite and Joshua George for their 1075 contributions to this document. Also thanks to Venugopal Reddy, 1076 Cyril Margaria, Rakesh Gandhi and Adrian Farrel for their useful 1077 comments. 1079 11. Contributors 1080 Stephane Litkowski 1081 Orange 1083 Email: stephane.litkowski@orange.com 1085 Xian Zhang 1086 Huawei Technologies 1087 F3-1-B RnD Center, Huawei Base 1088 Bantian, Longgang District 1089 Shenzhen 518129 1090 China 1092 Email: zhang.xian@huawei.com 1094 Mustapha Aissaoui 1095 Nokia 1097 Email: mustapha.aissaoui@nokia.com 1099 12. References 1101 12.1. Normative References 1103 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1104 Requirement Levels", BCP 14, RFC 2119, 1105 DOI 10.17487/RFC2119, March 1997, 1106 . 1108 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1109 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1110 DOI 10.17487/RFC5440, March 2009, 1111 . 1113 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 1114 Used to Form Encoding Rules in Various Routing Protocol 1115 Specifications", RFC 5511, DOI 10.17487/RFC5511, April 1116 2009, . 1118 [RFC6780] Berger, L., Le Faucheur, F., and A. Narayanan, "RSVP 1119 ASSOCIATION Object Extensions", RFC 6780, 1120 DOI 10.17487/RFC6780, October 2012, 1121 . 1123 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1124 Writing an IANA Considerations Section in RFCs", BCP 26, 1125 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1126 . 1128 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1129 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1130 May 2017, . 1132 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1133 Computation Element Communication Protocol (PCEP) 1134 Extensions for Stateful PCE", RFC 8231, 1135 DOI 10.17487/RFC8231, September 2017, 1136 . 1138 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 1139 Computation Element Communication Protocol (PCEP) 1140 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 1141 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 1142 . 1144 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 1145 "PCEPS: Usage of TLS to Provide a Secure Transport for the 1146 Path Computation Element Communication Protocol (PCEP)", 1147 RFC 8253, DOI 10.17487/RFC8253, October 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 [I-D.ietf-pce-pcep-yang] 1189 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 1190 YANG Data Model for Path Computation Element 1191 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 1192 yang-09 (work in progress), October 2018. 1194 Appendix A. Example for Operator-configured Association Range 1196 Consider an association type T1 (which allows both dynamic and 1197 operator-configured association with a default range of (0x1000 to 1198 0xffff)). Consider that because of need of the network, the PCE 1199 needs to create more dynamic associations and would like to change 1200 the association range to (0xbffe to 0xffff) instead. During PCEP 1201 session establishment the PCE would advertise the new range, the PCC 1202 could skip advertising as the default values are used. If a PCC is 1203 creating a dynamic association (with PCC as association source) it 1204 needs to pick a free association identifier for type T1 in the range 1205 of (0x1 to 0x0fff) where as if a PCE is creating a dynamic 1206 association (with PCE as association source) it needs to pick a free 1207 association identifier from the range (0x1 to 0xbffd). Similarly if 1208 a operator configured association is manually configured with PCC as 1209 association source, it should be from the range (0x1000 to 0xffff) 1210 where as if PCE is association source, it should be from (0xbffe to 1211 0xffff). In case the association source is not PCC or PCE as set as 1212 NMS id, then the default range of (0x1000 to 0xffff) is considered. 1214 Authors' Addresses 1215 Ina Minei 1216 Google, Inc. 1217 1600 Amphitheatre Parkway 1218 Mountain View, CA 94043 1219 US 1221 Email: inaminei@google.com 1223 Edward Crabbe 1224 Individual Contributor 1226 Email: edward.crabbe@gmail.com 1228 Siva Sivabalan 1229 Cisco Systems, Inc. 1230 170 West Tasman Dr. 1231 San Jose, CA 95134 1232 US 1234 Email: msiva@cisco.com 1236 Hariharan Ananthakrishnan 1237 Packet Design 1239 Email: hari@packetdesign.com 1241 Dhruv Dhody 1242 Huawei 1243 Divyashree Techno Park, Whitefield 1244 Bangalore, KA 560066 1245 India 1247 Email: dhruv.ietf@gmail.com 1249 Yosuke Tanaka 1250 NTT Communications Corporation 1251 Granpark Tower 3-4-1 Shibaura, Minato-ku 1252 Tokyo 108-8118 1253 Japan 1255 Email: yosuke.tanaka@ntt.com