idnits 2.17.1 draft-ietf-pce-association-group-04.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 (September 1, 2017) is 2421 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 702, but not defined == Outdated reference: A later version (-11) exists of draft-ietf-pce-pce-initiated-lsp-10 -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) == Outdated reference: A later version (-18) exists of draft-ietf-pce-pceps-16 == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-05 Summary: 0 errors (**), 0 flaws (~~), 5 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: March 5, 2018 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 September 1, 2017 16 PCEP Extensions for Establishing Relationships Between Sets of LSPs 17 draft-ietf-pce-association-group-04 19 Abstract 21 This document introduces a generic mechanism to create a grouping of 22 LSPs in the context of a PCE. This grouping can then be used to 23 define associations between sets of LSPs or between a set of LSPs and 24 a set of attributes (such as configuration parameters or behaviors), 25 and is equally applicable to stateful PCE (active and passive modes) 26 and stateless PCE. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 32 "OPTIONAL" in this document are to be interpreted as described in BCP 33 14 [RFC2119] [RFC8174] when, and only when, they appear in all 34 capitals, as shown here. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on March 5, 2018. 53 Copyright Notice 55 Copyright (c) 2017 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 72 3. Architectural Overview . . . . . . . . . . . . . . . . . . . 4 73 3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 74 3.2. Operation Overview . . . . . . . . . . . . . . . . . . . 4 75 3.3. Operator-configured Association Range . . . . . . . . . . 5 76 4. Operator-configured Association Range TLV . . . . . . . . . . 5 77 4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 7 78 5. ASSOCIATION Object . . . . . . . . . . . . . . . . . . . . . 7 79 5.1. Object Definition . . . . . . . . . . . . . . . . . . . . 7 80 5.1.1. Global Association Source TLV . . . . . . . . . . . . 9 81 5.1.2. Extended Association ID TLV . . . . . . . . . . . . . 9 82 5.2. Object Encoding in PCEP messages . . . . . . . . . . . . 10 83 5.2.1. Stateful PCEP messages . . . . . . . . . . . . . . . 10 84 5.2.2. Request Message . . . . . . . . . . . . . . . . . . . 12 85 5.3. Processing Rules . . . . . . . . . . . . . . . . . . . . 13 86 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 87 6.1. PCEP Object . . . . . . . . . . . . . . . . . . . . . . . 15 88 6.2. PCEP TLV . . . . . . . . . . . . . . . . . . . . . . . . 15 89 6.3. Association Flags . . . . . . . . . . . . . . . . . . . . 15 90 6.4. Association Type . . . . . . . . . . . . . . . . . . . . 16 91 6.5. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 16 92 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 93 8. Manageability Considerations . . . . . . . . . . . . . . . . 17 94 8.1. Control of Function and Policy . . . . . . . . . . . . . 17 95 8.2. Information and Data Models . . . . . . . . . . . . . . . 17 96 8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 17 97 8.4. Verify Correct Operations . . . . . . . . . . . . . . . . 18 98 8.5. Requirements On Other Protocols . . . . . . . . . . . . . 18 99 8.6. Impact On Network Operations . . . . . . . . . . . . . . 18 100 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 101 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 102 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 103 11.1. Normative References . . . . . . . . . . . . . . . . . . 19 104 11.2. Informative References . . . . . . . . . . . . . . . . . 19 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 107 1. Introduction 109 [RFC5440] describes the Path Computation Element Protocol PCEP. PCEP 110 enables the communication between a Path Computation Client (PCC) and 111 a Path Control Element (PCE), or between PCE and PCE, for the purpose 112 of computation of Multiprotocol Label Switching (MPLS) as well as 113 Generalzied MPLS (GMPLS) for Traffic Engineering Label Switched Path 114 (TE LSP) characteristics. 116 Stateful pce [I-D.ietf-pce-stateful-pce] specifies a set of 117 extensions to PCEP to enable stateful control of TE LSPs between and 118 across PCEP sessions in compliance with [RFC4657] and focuses on a 119 model where LSPs are configured on the PCC and control over them is 120 delegated to the PCE. The model of operation where LSPs are 121 initiated from the PCE is described in 122 [I-D.ietf-pce-pce-initiated-lsp]. 124 This document introduces a generic mechanism to create a grouping of 125 LSPs. This grouping can then be used to define associations between 126 sets of LSPs or between a set of LSPs and a set of attributes (such 127 as configuration parameters or behaviors), and is equally applicable 128 to stateful PCE (active and passive modes) and stateless PCE. The 129 associations could be created dynamically and conveyed to a PCEP peer 130 within PCEP, or it could be configured by an operator on the PCEP 131 peers. Refer Section 3.2 for more details. 133 2. Terminology 135 This document uses the following terms defined in [RFC5440]: PCC, 136 PCE, PCEP Peer. 138 This document uses the following terms defined in [RFC8051]: Stateful 139 PCE, Delegation. 141 This document uses the following terms defined in 142 [I-D.ietf-pce-stateful-pce]: Redelegation Timeout Interval, LSP State 143 Report, LSP Update Request. 145 This document uses the following terms defined in 146 [I-D.ietf-pce-pce-initiated-lsp]: PCE-initiated LSP, LSP Initiate. 148 The following term is defined in this document: 150 Association Timeout Interval: when a PCEP session is terminated, a 151 PCC waits for this time period before deleting associations created 152 by the PCEP peer. 154 3. Architectural Overview 156 3.1. Motivation 158 Stateful PCE provides the ability to update existing LSPs and to 159 instantiate new ones. To enable support for PCE-controlled make- 160 before-break and for protection, there is a need to define 161 associations between LSPs. For example, the association between the 162 original and the re-optimized path in the make-before break scenario, 163 or between the working and protection path in end-to-end protection. 164 Another use for LSP grouping is for applying a common set of 165 configuration parameters or behaviors to a set of LSPs. 167 For a stateless PCE, it might be useful to associate a path 168 computation request to an association group, thus enabling it to 169 associate a common set of policy, configuration parameters or 170 behaviors with the request. 172 Some associations could be created dynamically, such as association 173 between the working and protections LSPs of a tunnel. Whereas some 174 association could be created by the operator manually, such as policy 175 based association, where the LSP could join an operator-configured 176 existing association. 178 Rather than creating separate mechanisms for each use case, this 179 draft defines a generic mechanism that can be reused as needed. 181 3.2. Operation Overview 183 LSPs are associated with other LSPs with which they interact by 184 adding them to a common association group. Association groups as 185 defined in this document can be applied to LSPs originating at the 186 same head end or different head ends. 188 Some associations could be created dynamically by a PCEP speaker and 189 the associations (along with the set of LSPs) are conveyed to a PCEP 190 peer. Whereas, some associations are configured by the operator on 191 the PCEP peers involved before hand, a PCEP speaker then could ask 192 for a LSP to join the operator-configured association. Usage of 193 dynamic and configured is usually dependent on the type of the 194 association. 196 For the operator-configured association, the association identifier, 197 type, as well as the association source IP address is manually 198 configured by the operator. In case of dynamic association, the 199 association identifier is allocated dynamically by the PCEP speaker. 201 The dynamically created association can be reported to the PCEP peer 202 via the PCEP messages as per the stateful extensions. While the 203 operator-configured association are known to the PCEP peer before 204 hand, a PCEP peer could ask for a LSP to join the operator-configured 205 association via the stateful PCEP messages. 207 The association are properties of the LSP and thus could be stored in 208 the LSP state database. The dynamic association exist as long as the 209 LSP state. In case of PCEP session termination, the LSP state clean 210 up SHOULD also take care of associations. 212 Multiple types of associations can exist, each with their own 213 association identifier space. The definition of the different 214 association types and their behaviors is outside the scope of this 215 document. The establishment and removal of the association 216 relationship can be done on a per LSP basis. An LSP may join 217 multiple association groups, of different or of the same association 218 type. 220 3.3. Operator-configured Association Range 222 Some association types are dynamic, some are operator-configured and 223 some could be both. For the association types that could be dynamic 224 and operator-configured, it is necessary to configure a range of 225 association identifiers that are marked for operator-configured 226 associations to avoid any association identifier clash. 228 A range of association identifier for each association-type are kept 229 for the operator-configured associations. Dynamic associations MUST 230 NOT use the association identifier from this range. 232 This range needs to be communicated to a PCEP peer in the Open 233 Message. A new TLV is defined in this specification for this purpose 234 (Section 4). 236 4. Operator-configured Association Range TLV 238 This section defines PCEP extension to support the advertisement of 239 the Operator-configured Association Range used for an association- 240 type. 242 A new PCEP OP-CONF-ASSOC-RANGE (Operator-configured Association 243 Range) TLV is defined. The PCEP OP-CONF-ASSOC-RANGE TLV is carried 244 within an OPEN object. This way, during PCEP session-setup phase, a 245 PCEP speaker can advertise to a PCEP peer the Operator-configured 246 Association Range for an association type. 248 The PCEP OP-CONF-ASSOC-RANGE TLV is optional. It MAY be carried 249 within an OPEN object sent by a PCEP speaker in an Open message to a 250 PCEP peer. The OP-CONF-ASSOC-RANGE TLV format is compliant with the 251 PCEP TLV format defined in [RFC5440]. That is, the TLV is composed 252 of 2 octets for the type, 2 octets specifying the TLV length, and a 253 Value field. The Length field defines the length of the value 254 portion in octets. 256 The PCEP OP-CONF-ASSOC-RANGE TLV has the following format: 258 TYPE: TBD 259 LENGTH: N * 8 (where N is the number of association types) 260 VALUE: 262 0 1 2 3 263 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 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Reserved | Assoc-type #1 | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Start-Assoc-ID #1 | Range #1 | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 // // 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | Reserved | Assoc-type #N | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | Start-Assoc-ID #N | Range #N | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 Figure 1: The OP-CONF-ASSOC-RANGE TLV format 278 The Value portion includes the following fields, repeated for each 279 association type: 281 Reserved (2 bytes): This field MUST be set to 0 on transmission 282 and MUST be ignored on receipt. 284 Assoc-type (2 bytes): The association type. 286 Start-Assoc-ID (2 bytes): The start association identifier for the 287 Operator-configured Association Range for the particular 288 association type. 290 Range (2 bytes): The number of associations marked for the 291 Operator-configured Associations. 293 4.1. Procedure 295 A PCEP speaker MAY include an OP-CONF-ASSOC-RANGE TLV within an OPEN 296 object in an Open message sent to a PCEP peer in order to advertise 297 the Operator-configured Association Range for an association type. 298 The OP-CONF-ASSOC-RANGE TLV MUST NOT appear more than once in an OPEN 299 object. If it appears more than once, the PCEP session MUST be 300 rejected with error type 1 and error value 1 (PCEP session 301 establishment failure / Reception of an invalid Open message). 303 As specified in [RFC5440], a PCEP peer that does not recognize the 304 OP-CONF-ASSOC-RANGE TLV will silently ignore it. 306 The Operator-configured Association Range SHOULD be included for each 307 association type that could be both dynamic and operator-configured. 308 For association types that are only dynamic or only operator- 309 configured, this TLV can be skipped, in which case the full range of 310 association identifier is considered dynamic or operator-configured 311 respectively. Each association type (that are defined in separate 312 documents) can specify the default value for the operator-configured 313 association range for their respective association type. 315 The absence of the OP-CONF-ASSOC-RANGE TLV in an OPEN object MUST be 316 interpreted as an absence of explicit Operator-configured Association 317 Range at the PCEP peer. In which case, the default behavior as per 318 each association type would be applied. 320 5. ASSOCIATION Object 322 5.1. Object Definition 324 Association groups and their memberships are defined using a new 325 ASSOCIATION object. 327 ASSOCIATION Object-Class is to be assigned by IANA (TBD). 329 ASSOCIATION Object-Type is 1 for IPv4 and its format is shown in 330 Figure 2: 332 0 1 2 3 333 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 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | Reserved | Flags |R| 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Association type | Association ID | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | IPv4 Association Source | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 // Optional TLVs // 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 Figure 2: The IPv4 ASSOCIATION Object format 346 ASSOCIATION Object-Type is 2 for IPv6 and its format is shown in 347 Figure 3: 349 0 1 2 3 350 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 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | Reserved | Flags |R| 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | Association type | Association ID | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | | 357 | IPv6 Association Source | 358 | | 359 | | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 // Optional TLVs // 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 Figure 3: The IPv6 ASSOCIATION Object format 366 Reserved (2-byte): MUST be set to 0 and ignored upon receipt. 368 Flags (2-byte): The following flags are currently defined: 370 R (Removal - 1 bit): when set, the requesting PCE peer requires the 371 removal of an LSP from the association group. This flag is used 372 for ASSOCIATION object in PCRpt and PCUpd message, the flag is 373 ignored in other PCEP messages. 375 Association type (2-byte): the association type (for example 376 protection). The association type are defined in separate documents. 378 Association ID (2-byte): the identifier of the association group. 379 When combined with Type and Association Source, this value uniquely 380 identifies an association group. The value 0xffff and 0x0 are 381 reserved. The value 0xffff is used to indicate all association 382 groups. 384 Association Source: 4 or 16 bytes - An IPv4 or IPv6 address. This 385 could be the IP address of the PCEP speaker that created a dynamic 386 association, an operator configured IP address, or an IP address 387 selected as per the local policy. The value such as 0.0.0.0 or 388 ::/128 are acceptable. 390 Optional TLVs: The optional TLVs follow the PCEP TLV format of 391 [RFC5440]. This document defines two optional TLVs. Other documents 392 can define more TLVs. 394 5.1.1. Global Association Source TLV 396 The Global Association Source TLV is an optional TLV for use in the 397 Association Object. 399 0 1 2 3 400 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 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Type | Length | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | Global Association Source | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 Figure 4: The Global Association Source TLV format 409 Type: To be allocated by IANA. 411 Length: Fixed value of 4 bytes. 413 Global Association Source: as defined in [RFC6780]. 415 5.1.2. Extended Association ID TLV 417 The Extended Association ID TLV is an optional TLV for use in the 418 Association Object. 420 0 1 2 3 421 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 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | Type | Length | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 // Extended Association ID // 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 Figure 5: The Extended Association ID TLV format 430 Type: To be allocated by IANA. 432 Length: variable. 434 Extended Association ID: as defined in [RFC6780]. 436 5.2. Object Encoding in PCEP messages 438 5.2.1. Stateful PCEP messages 440 The ASSOCIATION Object is OPTIONAL and MAY be carried in the Path 441 Computation Update (PCUpd), Path Computation Report (PCRpt) and Path 442 Computation Initiate (PCInitiate) messages. 444 When carried in PCRpt message, it is used to report the association 445 group membership information pertaining to a LSP to a stateful PCE. 446 It can also be used to remove an LSP from one or more association 447 groups by setting the R flag to 1 in the ASSOCIATION object. Unless, 448 a PCE wants to delete an association from an LSP, it does not need to 449 carry the ASSOCIATION object in future messages. 451 The PCRpt message is defined in [I-D.ietf-pce-stateful-pce] and 452 updated as below: 454 ::= 455 456 Where: 458 ::= [] 460 ::= [] 461 462 [] 463 464 Where: 465 ::= 466 [] 467 469 ::= [] 471 When an LSP is delegated to a stateful PCE, the stateful PCE can 472 initiate a new association group for this LSP, or associate it with 473 one or more existing association groups. This is done by including 474 the ASSOCIATION Object in a PCUpd message. A stateful PCE can also 475 remove a delegated LSP from one or more association groups by setting 476 the R flag to 1 in the ASSOCIATION object. 478 The PCUpd message is defined in [I-D.ietf-pce-stateful-pce] and 479 updated as below: 481 ::= 482 483 Where: 485 ::= [] 487 ::= 488 489 [] 490 491 Where: 492 ::= 494 ::= [] 496 A PCE initiating a new LSP, can include the association group 497 information. This is done by including the ASSOCIATION Object in a 498 PCInitiate message. The PCInitiate message is defined in 499 [I-D.ietf-pce-pce-initiated-lsp] and updated as below: 501 ::= 502 503 Where: 505 ::= 506 [] 508 ::= (| 509 ) 511 ::= 512 513 [] 514 515 [] 516 [] 518 Where: 519 ::= [] 521 5.2.2. Request Message 523 In case of passive stateful or stateless PCE, the ASSOCIATION Object 524 is OPTIONAL and MAY be carried in the Path Computation Request 525 (PCReq) message. 527 When carried in a PCReq message, the ASSOCIATION Object is used to 528 associate the path computation request to an association group. The 529 association (and the other LSPs) should be known to the PCE before 530 hand. These could be operator-configured or dynamically learned 531 before. The R flag in ASSOCIATION object within PCReq message MUST 532 be set to 0 while sending and ignored on receipt. 534 The PCReq message is defined in [RFC5440] and updated in [I-D.ietf- 535 pce-stateful-pce], it is further updated below for association: 537 ::= 538 [] 539 541 Where: 542 ::= [] 543 ::= [] 545 ::= 546 547 [] 548 [] 549 [] 550 [] 551 [] 552 [[]] 553 [] 554 [] 556 Where: 557 ::= [] 559 Note that LSP object MAY be present for the passive stateful PCE 560 mode. 562 5.3. Processing Rules 564 Association groups can be operator-configured on the necessary PCC 565 and PCE. In addition, a PCC or a PCE can create association groups 566 dynamically. The PCEP speaker can reports the association to its 567 peer via PCEP messages. If a PCEP speaker does not recognize the 568 ASSOCIATION object, it will return a PCErr message with Error-Type 569 "Unknown Object" as described in [RFC5440]. If a PCEP speaker 570 understand the ASSOCIATION object but does not support the 571 association-type, it MUST return a PCErr message with Error-Type TBD 572 "Association Error" and Error-Value 1 "Association-type is not 573 supported". On receiving a PCEP message with ASSOCIATION, if a PCEP 574 speaker finds that too many LSPs belong to the association group, it 575 MUST return a PCErr message with Error-Type TBD "Association Error" 576 and Error-Value 2 "Too many LSPs in the association group". If a 577 PCEP speaker cannot handle a new associations, it MUST return a PCErr 578 message with Error-Type TBD "Association Error" and Error-Value 3 579 "Too many association groups". These number MAY be set by operator 580 or decided based on a local policy. 582 If a PCE speaker receives ASSOCIATION in PCReq message, and the 583 association information is not known (association is not configured, 584 or created dynamically, or learned from a PCEP peer), it MUST return 585 a PCErr message with Error-Type TBD "Association Error" and Error- 586 Value 4 "Association unknown". If the association information 587 received from the peer does not match with the local operator 588 configured information, it MUST return a PCErr message with Error- 589 Type TBD "Association Error" and Error-Value 5 "Operator-configured 590 association information mismatch". On receiving association 591 information that does not match with the association information 592 previously received about the same association from a peer, it MUST 593 return a PCErr message with Error-Type TBD "Association Error" and 594 Error-Value 6 "Association information mismatch". If a PCE peer is 595 unwilling or unable to process the ASSOCIATION object, it MUST return 596 a PCErr message with the Error-Type "Not supported object" and follow 597 the relevant procedures described in [RFC5440]. On receiving a PCEP 598 message with ASSOCIATION, if a PCEP speaker could not add the LSP to 599 the association group for any reason, it MUST return a PCErr message 600 with Error-Type TBD "Association Error" and Error-Value 7 "Cannot 601 join the association group". 603 The association information is cleared along with the LSP state 604 information as per the [I-D.ietf-pce-stateful-pce]. When a PCEP 605 session is terminated, after expiry of State Timeout Interval at PCC, 606 the LSP state associated with that PCEP session is reverted to 607 operator-defined default parameters or behaviors. Same procedure is 608 also followed for the association information. On session 609 termination at the PCE, when the LSP state reported by PCC is 610 cleared, the association information is also cleared. Where there 611 are no LSPs in a association group, the association is considered to 612 be deleted. 614 In case the LSP is delegated to another PCE on session failure, the 615 association information set by the PCE remains intact, unless updated 616 by the new PCE. 618 Upon LSP delegation revocation, the PCC MAY clear the association 619 created by the PCE, but in order to avoid traffic loss, it can 620 perform this in a make-before-break fashion, which is the same as 621 what is defined in [I-D.ietf-pce-stateful-pce] for handling LSP state 622 cleanup. 624 If a PCE speaker receives ASSOCIATION object with R bit set for 625 removal, and the association information is not known, it MUST return 626 a PCErr message with Error-Type TBD "Association Error" and Error- 627 Value 4 "Association unknown". 629 6. IANA Considerations 631 IANA maintains the "Path Computation Element Protocol (PCEP) Numbers" 632 registry at . 634 6.1. PCEP Object 636 The "PCEP Numbers" registry contains a subregistry "PCEP Objects". 637 This document request IANA to allocate code points from this 638 registry. 640 Object-Class Value Name Reference 642 TBD Association [This I-D] 643 Object-Type 644 0: Reserved 645 1: IPv4 646 2: IPv6 648 6.2. PCEP TLV 650 IANA is requested to make the assignment of the new code points for 651 the existing "PCEP TLV Type Indicators" registry as follows: 653 Value Meaning Reference 654 TBD Operator-configured [This I-D] 655 Association Range 656 TBD Global Association Source [This I-D] 657 TBD Extended Association Id [This I-D] 659 6.3. Association Flags 661 This document requests IANA to create a subregistry of the "PCEP 662 Numbers" for the bits carried in the Flags field of the ASSOCIATION 663 object. The subregistry is called "ASSOCIATION Flags Field". New 664 values are assigned by Standards Action [RFC8126]. Each bit should 665 be tracked with the following qualities: 667 o Bit number (counting from bit 0 as the most significant bit) 669 o Capability description 671 o Defining RFC 673 Bit Description Reference 675 15 R (Removal) [This I-D] 677 6.4. Association Type 679 This document requests IANA to create a subregistry of the "PCEP 680 Numbers" for the Association Type field of the the ASSOCIATION 681 object. The subregistry is called "ASSOCIATION Type Field". New 682 values are to be assigned by Standards Action [RFC8126]. Each value 683 should be tracked with the following qualities: 685 o Type 687 o Name 689 o Reference 691 There are no association type specified in this document, future 692 document should request the assignment of association types from this 693 subregistry. 695 6.5. PCEP-Error Object 697 IANA is requested to allocate new error values within the "PCEP-ERROR 698 Object Error Types and Values" sub-registry of the "PCEP Numbers" 699 registry, as follows: 701 Error-Type Meaning 702 TBD Association Error [This I-D] 703 Error-value=1: 704 Association-type is not supported 705 Error-value=2: 706 Too many LSPs in the association group 707 Error-value=3: 708 Too many association groups 709 Error-value=4: 710 Association unknown 711 Error-value=5: 712 Operator-configured association 713 information mismatch 714 Error-value=6: 715 Association information mismatch 716 Error-value=7: 717 Cannot join the association group 719 7. Security Considerations 721 The security considerations described in [I-D.ietf-pce-stateful-pce] 722 and [RFC5440] apply to the extensions described in this document as 723 well. Additional considerations related to a malicious PCEP speaker 724 are introduced, as associations could be spoofed and could be used as 725 an attack vector. An attacker could report too many associations in 726 an attempt to load the PCEP peer. The PCEP peer responds with PCErr 727 as described in Section 5.3. An attacker could impact LSP operations 728 by creating bogus associations. Further, association information 729 could provides an adversary with the opportunity to eavesdrop on the 730 relationship between the LSPs. Thus securing the PCEP session using 731 Transport Layer Security (TLS) [I-D.ietf-pce-pceps], as per the 732 recommendations and best current practices in [RFC7525], is 733 RECOMMENDED. 735 8. Manageability Considerations 737 All manageability requirements and considerations listed in [RFC5440] 738 and [I-D.ietf-pce-stateful-pce] apply to PCEP protocol extensions 739 defined in this document. In addition, requirements and 740 considerations listed in this section apply. 742 8.1. Control of Function and Policy 744 A PCE or PCC implementation MUST allow operator-configured 745 associations as described in this document. The identifier MUST be 746 from the operator-configured identifier range Section 3.3. 748 8.2. Information and Data Models 750 An implementation SHOULD allow the operator to view the associations 751 configured or created dynamically. Further implementation SHOULD 752 allow to view associations reported by each peer, and the current set 753 of LSPs in the association . To serve this purpose, the PCEP YANG 754 module [I-D.ietf-pce-pcep-yang] can be extended to include 755 association information. 757 8.3. Liveness Detection and Monitoring 759 Mechanisms defined in this document do not imply any new liveness 760 detection and monitoring requirements in addition to those already 761 listed in [RFC5440]. 763 8.4. Verify Correct Operations 765 Mechanisms defined in this document do not imply any new operation 766 verification requirements in addition to those already listed in 767 [RFC5440] and [I-D.ietf-pce-stateful-pce]. 769 8.5. Requirements On Other Protocols 771 Mechanisms defined in this document do not imply any new requirements 772 on other protocols. 774 8.6. Impact On Network Operations 776 Mechanisms defined in [RFC5440] and [I-D.ietf-pce-stateful-pce] also 777 apply to PCEP extensions defined in this document. 779 9. Acknowledgements 781 We would like to thank Yuji Kamite and Joshua George for their 782 contributions to this document. Also thanks to Venugopal Reddy, 783 Cyril Margaria and Rakesh Gandhi for their useful comments. 785 10. Contributors 787 Stephane Litkowski 788 Orange 790 Email: stephane.litkowski@orange.com 792 Xian Zhang 793 Huawei Technologies 794 F3-1-B RnD Center, Huawei Base 795 Bantian, Longgang District 796 Shenzhen 518129 797 China 799 Email: zhang.xian@huawei.com 801 Mustapha Aissaoui 802 Nokia 804 Email: mustapha.aissaoui@nokia.com 806 11. References 808 11.1. Normative References 810 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 811 Requirement Levels", BCP 14, RFC 2119, 812 DOI 10.17487/RFC2119, March 1997, . 815 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 816 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 817 DOI 10.17487/RFC5440, March 2009, . 820 [RFC6780] Berger, L., Le Faucheur, F., and A. Narayanan, "RSVP 821 ASSOCIATION Object Extensions", RFC 6780, 822 DOI 10.17487/RFC6780, October 2012, . 825 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 826 Writing an IANA Considerations Section in RFCs", BCP 26, 827 RFC 8126, DOI 10.17487/RFC8126, June 2017, 828 . 830 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 831 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 832 May 2017, . 834 [I-D.ietf-pce-stateful-pce] 835 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 836 Extensions for Stateful PCE", draft-ietf-pce-stateful- 837 pce-21 (work in progress), June 2017. 839 [I-D.ietf-pce-pce-initiated-lsp] 840 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 841 Extensions for PCE-initiated LSP Setup in a Stateful PCE 842 Model", draft-ietf-pce-pce-initiated-lsp-10 (work in 843 progress), June 2017. 845 11.2. Informative References 847 [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation 848 Element (PCE) Communication Protocol Generic 849 Requirements", RFC 4657, DOI 10.17487/RFC4657, September 850 2006, . 852 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 853 "Recommendations for Secure Use of Transport Layer 854 Security (TLS) and Datagram Transport Layer Security 855 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 856 2015, . 858 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 859 Stateful Path Computation Element (PCE)", RFC 8051, 860 DOI 10.17487/RFC8051, January 2017, . 863 [I-D.ietf-pce-pceps] 864 Lopez, D., Dios, O., Wu, Q., and D. Dhody, "Secure 865 Transport for PCEP", draft-ietf-pce-pceps-16 (work in 866 progress), August 2017. 868 [I-D.ietf-pce-pcep-yang] 869 Dhody, D., Hardwick, J., Beeram, V., and j. 870 jefftant@gmail.com, "A YANG Data Model for Path 871 Computation Element Communications Protocol (PCEP)", 872 draft-ietf-pce-pcep-yang-05 (work in progress), June 2017. 874 Authors' Addresses 876 Ina Minei 877 Google, Inc. 878 1600 Amphitheatre Parkway 879 Mountain View, CA 94043 880 US 882 Email: inaminei@google.com 884 Edward Crabbe 885 Individual Contributor 887 Email: edward.crabbe@gmail.com 889 Siva Sivabalan 890 Cisco Systems, Inc. 891 170 West Tasman Dr. 892 San Jose, CA 95134 893 US 895 Email: msiva@cisco.com 896 Hariharan Ananthakrishnan 897 Packet Design 899 Email: hari@packetdesign.com 901 Dhruv Dhody 902 Huawei 903 Divyashree Techno Park, Whitefield 904 Bangalore, KA 560066 905 India 907 Email: dhruv.ietf@gmail.com 909 Yosuke Tanaka 910 NTT Communications Corporation 911 Granpark Tower 3-4-1 Shibaura, Minato-ku 912 Tokyo 108-8118 913 Japan 915 Email: yosuke.tanaka@ntt.com