idnits 2.17.1 draft-litkowski-pce-state-sync-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 (January 11, 2020) is 1565 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) == Outdated reference: A later version (-15) exists of draft-ietf-pce-association-diversity-13 -- Obsolete informational reference (is this intentional?): RFC 7752 (Obsoleted by RFC 9552) 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 S. Litkowski 3 Internet-Draft S. Sivabalan 4 Intended status: Standards Track Cisco 5 Expires: July 14, 2020 C. Li 6 H. Zheng 7 Huawei Technologies 8 January 11, 2020 10 Inter Stateful Path Computation Element (PCE) Communication Procedures. 11 draft-litkowski-pce-state-sync-07 13 Abstract 15 The Path Computation Element Communication Protocol (PCEP) provides 16 mechanisms for Path Computation Elements (PCEs) to perform path 17 computations in response to Path Computation Clients (PCCs) requests. 18 The stateful PCE extensions allow stateful control of Multi-Protocol 19 Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE 20 LSPs) using PCEP. 22 A Path Computation Client (PCC) can synchronize an LSP state 23 information to a Stateful Path Computation Element (PCE). The 24 stateful PCE extension allows a redundancy scenario where a PCC can 25 have redundant PCEP sessions towards multiple PCEs. In such a case, 26 a PCC gives control on a LSP to only a single PCE, and only one PCE 27 is responsible for path computation for this delegated LSP. The 28 document does not state the procedures related to an inter-PCE 29 stateful communication. 31 There are some use cases, where an inter-PCE stateful communication 32 can bring additional resiliency in the design, for instance when some 33 PCC-PCE sessions fails. The inter-PCE stateful communication may 34 also provide a faster update of the LSP states when such an event 35 occurs. Finally, when, in a redundant PCE scenario, there is a need 36 to compute a set of paths that are part of a group (so there is a 37 dependency between the paths), there may be some cases where the 38 computation of all paths in the group is not handled by the same PCE: 39 this situation is called a split-brain. This split-brain scenario 40 may lead to computation loops between PCEs or suboptimal path 41 computation. 43 This document describes the procedures to allow a stateful 44 communication between PCEs for various use-cases and also the 45 procedures to prevent computations loops. 47 Requirements Language 49 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 50 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 51 "OPTIONAL" in this document are to be interpreted as described in BCP 52 14 [RFC2119] [RFC8174] when, and only when, they appear in all 53 capitals, as shown here. 55 Status of This Memo 57 This Internet-Draft is submitted in full conformance with the 58 provisions of BCP 78 and BCP 79. 60 Internet-Drafts are working documents of the Internet Engineering 61 Task Force (IETF). Note that other groups may also distribute 62 working documents as Internet-Drafts. The list of current Internet- 63 Drafts is at https://datatracker.ietf.org/drafts/current/. 65 Internet-Drafts are draft documents valid for a maximum of six months 66 and may be updated, replaced, or obsoleted by other documents at any 67 time. It is inappropriate to use Internet-Drafts as reference 68 material or to cite them other than as "work in progress." 70 This Internet-Draft will expire on July 14, 2020. 72 Copyright Notice 74 Copyright (c) 2020 IETF Trust and the persons identified as the 75 document authors. All rights reserved. 77 This document is subject to BCP 78 and the IETF Trust's Legal 78 Provisions Relating to IETF Documents 79 (https://trustee.ietf.org/license-info) in effect on the date of 80 publication of this document. Please review these documents 81 carefully, as they describe your rights and restrictions with respect 82 to this document. Code Components extracted from this document must 83 include Simplified BSD License text as described in Section 4.e of 84 the Trust Legal Provisions and are provided without warranty as 85 described in the Simplified BSD License. 87 Table of Contents 89 1. Introduction and Problem Statement . . . . . . . . . . . . . 3 90 1.1. Reporting LSP changes . . . . . . . . . . . . . . . . . . 4 91 1.2. Split-brain . . . . . . . . . . . . . . . . . . . . . . . 5 92 1.3. Applicability to H-PCE . . . . . . . . . . . . . . . . . 12 93 2. Proposed solution . . . . . . . . . . . . . . . . . . . . . . 12 94 2.1. State-sync session . . . . . . . . . . . . . . . . . . . 12 95 2.2. Master/Slave relationship between PCE . . . . . . . . . . 14 96 3. Procedures and Protocol Extensions . . . . . . . . . . . . . 14 97 3.1. Opening a state-sync session . . . . . . . . . . . . . . 14 98 3.1.1. Capability Advertisement . . . . . . . . . . . . . . 14 99 3.2. State synchronization . . . . . . . . . . . . . . . . . . 15 100 3.3. Incremental updates and report forwarding rules . . . . . 16 101 3.4. Maintaining LSP states from different sources . . . . . . 17 102 3.5. Computation priority between PCEs and sub-delegation . . 18 103 3.6. Passive stateful procedures . . . . . . . . . . . . . . . 19 104 3.7. PCE initiation procedures . . . . . . . . . . . . . . . . 20 105 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 20 106 4.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 20 107 4.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 22 108 4.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . . . 24 109 5. Using Master/Slave computation and state-sync sessions to 110 increase scaling . . . . . . . . . . . . . . . . . . . . . . 25 111 6. PCEP-PATH-VECTOR-TLV . . . . . . . . . . . . . . . . . . . . 27 112 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 113 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 114 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 115 9.1. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 28 116 9.2. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 28 117 9.3. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 29 118 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 119 10.1. Normative References . . . . . . . . . . . . . . . . . . 29 120 10.2. Informative References . . . . . . . . . . . . . . . . . 29 121 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 30 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 124 1. Introduction and Problem Statement 126 The Path Computation Element communication Protocol (PCEP) [RFC5440]" 127 provides mechanisms for Path Computation Elements (PCEs) to perform 128 path computations in response to Path Computation Clients' (PCCs) 129 requests. 131 A stateful PCE [RFC8231] is capable of considering, for the purposes 132 of path computation, not only the network state in terms of links and 133 nodes (referred to as the Traffic Engineering Database or TED) but 134 also the status of active services (previously computed paths, and 135 currently reserved resources, stored in the Label Switched Paths 136 Database (LSP-DB). 138 [RFC8051] describes general considerations for a stateful PCE 139 deployment and examines its applicability and benefits, as well as 140 its challenges and limitations through a number of use cases. 142 The examples in this section are for illustrative purpose to showcase 143 the need for inter-PCE stateful PCEP sessions. 145 1.1. Reporting LSP changes 147 When using a stateful PCE ([RFC8231]), a PCC can synchronize an LSP 148 state information to the stateful PCE. If the PCC grants the control 149 on the LSP to the PCE (called delegation [RFC8231]), the PCE can 150 update the LSP parameters at any time. 152 In a multi PCE deployment (redundancy, loadbalancing...), with the 153 current specification defined in [RFC8231], when a PCE makes an 154 update, it is the PCC that is in charge of reporting the LSP status 155 to all PCEs with LSP parameter change which brings additional hops 156 and delays in notifying the overall network of the LSP parameter 157 change. 159 This delay may affect the reaction time of the other PCEs, if they 160 need to take action after being notified of the LSP parameter change. 162 Apart from the synchronization from the PCC, it is also useful if 163 there is synchronization mechanism between the stateful PCEs. As 164 stateful PCE make changes to its delegated LSPs, these changes 165 (pending LSPs and the sticky resources [RFC7399]) can be synchronized 166 immediately to the other PCEs. 168 +----------+ 169 | PCC1 | LSP1 170 +----------+ 171 / \ 172 / \ 173 +---------+ +---------+ 174 | PCE1 | | PCE2 | 175 +---------+ +---------+ 176 \ / 177 \ / 178 +----------+ 179 | PCC2 | LSP2 180 +----------+ 182 In the figure above, we consider a load-balanced PCE architecture, so 183 PCE1 is responsible to compute paths for PCC1 and PCE2 is responsible 184 to compute paths for PCC2. When PCE1 triggers an LSP update for 185 LSP1, it sends a PCUpd message to PCC1 containing the new parameters 186 for LSP1. PCC1 will take the parameters into account and will send a 187 PCRpt message to PCE1 and PCE2 reflecting the changes. PCE2 will so 188 be notified of the change only after receiving the PCRpt message from 189 PCC1. 191 Let's consider that the LSP1 parameters changed in such a way that 192 LSP1 will take over resources from LSP2 with a higher priority. 193 After receiving the report from PCC1, PCE2 will therefore try to find 194 a new path for LSP2. If we consider that there is a round trip delay 195 of about 150 milliseconds (ms) between the PCEs and PCC1 and a round 196 trip delay of 10 ms between the two PCEs, if will take more than 150 197 ms for PCE2 to be notified of the change. 199 Adding a PCEP session between PCE1 and PCE2 may allow to reduce the 200 synchronization time, so PCE2 can react more quickly by taking the 201 pending LSPs and attached resources into account during path 202 computation and reoptimization. 204 1.2. Split-brain 206 In a resiliency case, a PCC has redundant PCEP sessions towards 207 multiple PCEs. In such a case, a PCC gives control on an LSP to a 208 single PCE only, and only this PCE is responsible for the path 209 computation for the delegated LSP: the PCC achieves this by setting 210 the D flag only towards the active PCE [RFC8231] selected for 211 delegation. The election of the active PCE to delegate an LSP is 212 controlled by each PCC. The PCC usually elects the active PCE by a 213 local configured policy (by setting a priority). Upon PCEP session 214 failure, or active PCE failure, PCC may decide to elect a new active 215 PCE by sending new PCRpt message with D flag set to this new active 216 PCE. When the failed PCE or PCEP session comes back online, it will 217 be up to the implementation to do pre-emption. Doing pre-emption may 218 lead to some disruption on the existing path if path results from 219 both PCEs are not exactly the same. By considering a network with 220 multiple PCCs and implementing multiple stateful PCEs for redundancy 221 purpose, there is no guarantee that at any time all the PCCs delegate 222 their LSPs to the same PCE. 224 +----------+ 225 | PCC1 | LSP1 226 +----------+ 227 / \ 228 / \ 229 +---------+ +---------+ 230 | PCE1 | | PCE2 | 231 +---------+ +---------+ 232 \ / 233 *fail* \ / 234 +----------+ 235 | PCC2 | LSP2 236 +----------+ 238 In the example above, we consider that by configuration, both PCCs 239 will firstly delegate their LSPs to PCE1. So, PCE1 is responsible 240 for computing a path for both LSP1 and LSP2. If the PCEP session 241 between PCC2 and PCE1 fails, PCC2 will delegate LSP2 to PCE2. So 242 PCE1 becomes responsible only for LSP1 path computation while PCE2 is 243 responsible for the path computation of LSP2. When the PCC2-PCE1 244 session is back online, PCC2 will keep using PCE2 as active PCE 245 (consider no pre-emption in this example). So the result is a 246 permanent situation where each PCE is responsible for a subset of 247 path computation. 249 This situation is called a split-brain scenario, as there are 250 multiple computation brains running at the same time while a central 251 computation unit was required in some deployments/usecases. 253 Further, there are use cases where a particular LSP path computation 254 is linked to another LSP path computation: the most common use case 255 is path disjointness (see [I-D.ietf-pce-association-diversity]). The 256 set of LSPs that are dependant to each other may start from a 257 different head-end. 259 _________________________________________ 260 / \ 261 / +------+ +------+ \ 262 | | PCE1 | | PCE2 | | 263 | +------+ +------+ | 264 | | 265 | +------+ +------+ | 266 | | PCC1 | ----------------------> | PCC2 | | 267 | +------+ +------+ | 268 | | 269 | | 270 | +------+ +------+ | 271 | | PCC3 | ----------------------> | PCC4 | | 272 | +------+ +------+ | 273 | | 274 \ / 275 \_________________________________________/ 277 _________________________________________ 278 / \ 279 / +------+ +------+ \ 280 | | PCE1 | | PCE2 | | 281 | +------+ +------+ | 282 | | 283 | +------+ 10 +------+ | 284 | | PCC1 | ----- R1 ---- R2 ------- | PCC2 | | 285 | +------+ | | +------+ | 286 | | | | 287 | | | | 288 | +------+ | | +------+ | 289 | | PCC3 | ----- R3 ---- R4 ------- | PCC4 | | 290 | +------+ +------+ | 291 | | 292 \ / 293 \_________________________________________/ 295 In the figure above, the requirement is to create two link-disjoint 296 LSPs: PCC1->PCC2 and PCC3->PCC4. In the topology, all links cost 297 metric is set to 1 except for the link 'R1-R2' which has a metric of 298 10. The PCEs are responsible for the path computation and PCE1 is 299 the active primary PCE for all PCCs in the nominal case. 301 Scenario 1: 303 In the normal case (PCE1 as active primary PCE), consider that 304 PCC1->PCC2 LSP is configured first with the link disjointness 305 constraint, PCE1 sends a PCUpd message to PCC1 with the ERO: 306 R1->R3->R4->R2->PCC2 (shortest path). PCC1 signals and installs the 307 path. When PCC3->PCC4 is configured, the PCEs already knows the path 308 of PCC1->PCC2 and can compute a link-disjoint path : the solution 309 requires to move PCC1->PCC2 onto a new path to let room for the new 310 LSP. PCE1 sends a PCUpd message to PCC1 with the new ERO: 311 R1->R2->PCC2 and a PCUpd to PCC3 with the following ERO: 312 R3->R4->PCC4. In the normal case, there is no issue for PCE1 to 313 compute a link-disjoint path. 315 Scenario 2: 317 Consider that PCC1 lost its PCEP session with PCE1 (all other PCEP 318 sessions are UP). PCC1 delegates its LSP to PCE2. 320 +----------+ 321 | PCC1 | LSP: PCC1->PCC2 322 +----------+ 323 \ 324 \ D=1 325 +---------+ +---------+ 326 | PCE1 | | PCE2 | 327 +---------+ +---------+ 328 D=1 \ / D=0 329 \ / 330 +----------+ 331 | PCC3 | LSP: PCC3->PCC4 332 +----------+ 334 Consider that the PCC1->PCC2 LSP is configured first with the link 335 disjointness constraint, PCE2 (which is the new active primary PCE 336 for PCC1) sends a PCUpd message to PCC1 with the ERO: 337 R1->R3->R4->R2->PCC2 (shortest path). When PCC3->PCC4 is configured, 338 PCE1 is not aware of LSPs from PCC1 any more, so it cannot compute a 339 disjoint path for PCC3->PCC4 and will send a PCUpd message to PCC3 340 with a shortest path ERO: R3->R4->PCC4. When PCC3->PCC4 LSP will be 341 reported to PCE2 by PCC3, PCE2 will ensure disjointness computation 342 and will correctly move PCC1->PCC2 (as it owns delegation for this 343 LSP) on the following path: R1->R2->PCC2. With this sequence of 344 event and these PCEP sessions, disjointness is ensured. 346 Scenario 3: 348 +----------+ 349 | PCC1 | LSP: PCC1->PCC2 350 +----------+ 351 / \ 352 D=1 / \ D=0 353 +---------+ +---------+ 354 | PCE1 | | PCE2 | 355 +---------+ +---------+ 356 / D=1 357 / 358 +----------+ 359 | PCC3 | LSP: PCC3->PCC4 360 +----------+ 362 Consider the above PCEP sessions and the PCC1->PCC2 LSP is configured 363 first with the link disjointness constraint, PCE1 computes the 364 shortest path as it is the only LSP in the disjoint association group 365 that it is aware of: R1->R3->R4->R2->PCC2 (shortest path). When 366 PCC3->PCC4 is configured, PCE2 must compute a disjoint path for this 367 LSP. The only solution found is to move PCC1->PCC2 LSP on another 368 path, but PCE2 cannot do it as it does not have delegation for this 369 LSP. In this set-up, PCEs are not able to find a disjoint path. 371 Scenario 4: 373 +----------+ 374 | PCC1 | LSP: PCC1->PCC2 375 +----------+ 376 / \ 377 D=1 / \ D=0 378 +---------+ +---------+ 379 | PCE1 | | PCE2 | 380 +---------+ +---------+ 381 D=0 \ / D=1 382 \ / 383 +----------+ 384 | PCC3 | LSP: PCC3->PCC4 385 +----------+ 387 Consider the above PCEP sessions and that PCEs are configured to 388 fallback to shortest path if disjointness cannot be found as 389 described in [I-D.ietf-pce-association-diversity]. The PCC1->PCC2 390 LSP is configured first, PCE1 computes shortest path as it is the 391 only LSP in the disjoint association group that it is aware of: 392 R1->R3->R4->R2->PCC2 (shortest path). When PCC3->PCC4 is configured, 393 PCE2 must compute a disjoint path for this LSP. The only solution 394 found is to move PCC1->PCC2 LSP on another path, but PCE2 cannot do 395 it as it does not have delegation for this LSP. PCE2 then provides 396 shortest path for PCC3->PCC4: R3->R4->PCC4. When PCC3 receives the 397 ERO, it reports it back to both PCEs. When PCE1 becomes aware of 398 PCC3->PCC4 path, it recomputes the constrained shortest path first 399 (CSPF) algorithm and provides a new path for PCC1->PCC2: 400 R1->R2->PCC2. The new path is reported back to all PCEs by PCC1. 401 PCE2 recomputes also CSPF to take into account the new reported path. 402 The new computation does not lead to any path update. 404 Scenario 5: 406 _____________________________________ 407 / \ 408 / +------+ +------+ \ 409 | | PCE1 | | PCE2 | | 410 | +------+ +------+ | 411 | | 412 | +------+ 100 +------+ | 413 | | | -------------------- | | | 414 | | PCC1 | ----- R1 ----------- | PCC2 | | 415 | +------+ | +------+ | 416 | | | | | 417 | 6 | | 2 | 2 | 418 | | | | | 419 | +------+ | +------+ | 420 | | PCC3 | ----- R3 ----------- | PCC4 | | 421 | +------+ 10 +------+ | 422 | | 423 \ / 424 \_____________________________________/ 426 Now, consider a new network topology with the same PCEP sessions as 427 the previous example. Suppose that both LSPs are configured almost 428 at the same time. PCE1 will compute a path for PCC1->PCC2 while PCE2 429 will compute a path for PCC3->PCC4. As each PCE is not aware of the 430 path of the second LSP in the association group (not reported yet), 431 each PCE is computing shortest path for the LSP. PCE1 computes ERO: 432 R1->PCC2 for PCC1->PCC2 and PCE2 computes ERO: R3->R1->PCC2->PCC4 for 433 PCC3->PCC4. When these shortest paths will be reported to each PCE. 434 Each PCE will recompute disjointness. PCE1 will provide a new path 435 for PCC1->PCC2 with ERO: PCC1->PCC2. PCE2 will provide also a new 436 path for PCC3->PCC4 with ERO: R3->PCC4. When those new paths will be 437 reported to both PCEs, this will trigger CSPF again. PCE1 will 438 provide a new more optimal path for PCC1->PCC2 with ERO: R1->PCC2 and 439 PCE2 will also provide a more optimal path for PCC3->PCC4 with ERO: 440 R3->R1->PCC2->PCC4. So we come back to the initial state. When 441 those paths will be reported to both PCEs, this will trigger CSPF 442 again. An infinite loop of CSPF computation is then happening with a 443 permanent flap of paths because of the split-brain situation. 445 This permanent computation loop comes from the inconsistency between 446 the state of the LSPs as seen by each PCE due to the split-brain: 447 each PCE is trying to modify at the same time its delegated path 448 based on the last received path information which de facto 449 invalidates this received path information. 451 Scenario 6: multi-domain 453 Domain/Area 1 Domain/Area 2 454 ________________ ________________ 455 / \ / \ 456 / +------+ | | +------+ \ 457 | | PCE1 | | | | PCE3 | | 458 | +------+ | | +------+ | 459 | | | | 460 | +------+ | | +------+ | 461 | | PCE2 | | | | PCE4 | | 462 | +------+ | | +------+ | 463 | | | | 464 | +------+ | | +------+ | 465 | | PCC1 | | | | PCC2 | | 466 | +------+ | | +------+ | 467 | | | | 468 | | | | 469 | +------+ | | +------+ | 470 | | PCC3 | | | | PCC4 | | 471 | +------+ | | +------+ | 472 \ | | | 473 \_______________/ \________________/ 475 In the example above, suppose that the disjoint LSPs from PCC1 to 476 PCC2 and from PCC4 to PCC3 are created. All the PCEs have the 477 knowledge of both domain topologies (e.g. using BGP-LS [RFC7752]). 478 For operation/management reason, each domain uses its own group of 479 redundant PCEs. PCE1/PCE2 in domain 1 have PCEP sessions with PCC1 480 and PCC3 while PCE3/PCE4 in domain 2 have PCEP sessions with PCC2 and 481 PCC4. As PCE1/2 do not know about LSPs from PCC2/4 and PCE3/4 do not 482 know about LSPs from PCC1/3, there is no possibility to compute the 483 disjointness constraint. This scenario can also be seen as a split- 484 brain scenario. This multi-domain architecture (with multiple groups 485 of PCEs) can also be used in a single domain, where an operator wants 486 to limit the failure domain by creating multiple groups of PCEs 487 maintaining a subset of PCCs. As for the multi-domain example, there 488 will be no possibility to compute disjoint path starting from head- 489 ends managed by different PCE groups. 491 In this document, we propose a solution that address the possibility 492 to compute LSP association based constraints (like disjointness) in 493 split-brain scenarios while preventing computation loops. 495 1.3. Applicability to H-PCE 497 [I-D.ietf-pce-stateful-hpce] describes general considerations and use 498 cases for the deployment of Stateful PCE(s) using the Hierarchical 499 PCE [RFC6805] architecture. In this architecture there is a clear 500 need to communicate between a child stateful PCE and a parent 501 stateful PCE. The procedures and extensions as described in 502 Section 3 are equally applicable to H-PCE scenario. 504 2. Proposed solution 506 Our solution is based on : 508 o The creation of the inter-PCE stateful PCEP session with specific 509 procedures. 511 o A Master/Slave relationship between PCEs. 513 2.1. State-sync session 515 This document proposes to set-up a PCEP session between the stateful 516 PCEs. Creating such a session is already authorized by multiple 517 scenarios like the one described in [RFC4655] (multiple PCEs that are 518 handling part of the path computation) and [RFC6805] (hierarchical 519 PCE) but was only focused on stateless PCEP sessions. As stateful 520 PCE brings additional features (LSP state synchronization, path 521 update, delegation, ...), thus some new behaviours need to be 522 defined. 524 This inter-PCE PCEP session will allow exchange of LSP states between 525 PCEs that would help some scenario where PCEP sessions are lost 526 between PCC and PCE. This inter-PCE PCEP session is called a state- 527 sync session. 529 For example, in the scenario below, there is no possibility to 530 compute disjointness as there is no PCE that is aware of both LSPs. 532 +----------+ 533 | PCC1 | LSP: PCC1->PCC2 534 +----------+ 535 / 536 D=1 / 537 +---------+ +---------+ 538 | PCE1 | | PCE2 | 539 +---------+ +---------+ 540 / D=1 541 / 542 +----------+ 543 | PCC3 | LSP: PCC3->PCC4 544 +----------+ 546 If we add a state-sync session, PCE1 will be able to do state 547 synchronization via PCRpt messages for its LSP to PCE2 and PCE2 will 548 do the same. All the PCEs will be aware of all LSPs even if PCC->PCE 549 session are down. PCEs will then be able to compute disjoint paths. 551 +----------+ 552 | PCC1 | LSP : PCC1->PCC2 553 +----------+ 554 / 555 D=1 / 556 +---------+ PCEP +---------+ 557 | PCE1 | ----- | PCE2 | 558 +---------+ +---------+ 559 / D=1 560 / 561 +----------+ 562 | PCC3 | LSP : PCC3->PCC4 563 +----------+ 565 The procedures associated with this state-sync session are defined in 566 Section 3. 568 By just adding this state-sync session, it does not ensure that a 569 path with LSP association based constraints can always be computed 570 and does not prevent computation loop, but it increases resiliency 571 and ensures that PCEs will have the state information for all LSPs. 572 In addition, this session will allow for a PCE to update the other 573 PCEs providing a faster synchronization mechanism than relying on 574 PCCs only. 576 2.2. Master/Slave relationship between PCE 578 As seen in Section 1, performing a path computation in a split-brain 579 scenario (multiple PCEs responsible for computation) may provide a 580 non optimal LSP placement, no path or computation loops. To provide 581 the best efficiency, an LSP association constraint based computation 582 requires that a single PCE performs the path computation for all LSPs 583 in the association group. Note that, it could be all LSPs belonging 584 to a particular association group, or all LSPs from a particular PCC, 585 or all LSPs in the network that need to be delegated to a single PCE 586 based on the deployment scenarios. 588 This document propose to add a priority mechanism between PCEs to 589 elect a single computing PCE. Using this priority mechanism, PCEs 590 can agree on the PCE that will be responsible for the computation for 591 a particular association group, or set of LSPs. The priority could 592 be set per association, per PCC, or for all LSPs. How this priority 593 is set or advertised is out of scope of this document. The rest of 594 the text consider association group as an example. 596 When a single PCE is performing the computation for a particular 597 association group, no computation loop can happen and an optimal 598 placement will be provided. The other PCEs will only act as state 599 collectors and forwarders. 601 In the scenario described in Section 2.1, PCE1 and PCE2 will decide 602 that PCE1 will be responsible for the path computation of both LSPs. 603 If we first configure PCC1->PCC2, PCE1 computes shortest path at it 604 is the only LSP in the disjoint-group that it is aware of: 605 R1->R3->R4->R2->PCC2 (shortest path). When PCC3->PCC4 is configured, 606 PCE2 will not perform computation even if it has delegation but 607 forwards the delegation via PCRpt message to PCE1 through the state- 608 sync session. PCE1 will then perform disjointness computation and 609 will move PCC1->PCC2 onto R1->R2->PCC2 and provides an ERO to PCE2 610 for PCC3->PCC4: R3->R4->PCC4. The PCE2 will further update the PCC3 611 with the new path. 613 3. Procedures and Protocol Extensions 615 3.1. Opening a state-sync session 617 3.1.1. Capability Advertisement 619 A PCE indicates its support of state-sync procedures during the PCEP 620 Initialization phase [RFC5440]. The OPEN object in the Open message 621 MUST contains the "Stateful PCE Capability" TLV defined in [RFC8231]. 622 A new P (INTER-PCE-CAPABILITY) flag is introduced to indicate the 623 support of state-sync. 625 This document adds a new bit in the Flags field with : 627 P (INTER-PCE-CAPABILITY - 1 bit): If set to 1 by a PCEP Speaker, 628 the PCEP speaker indicates that the session MUST follow the state- 629 sync procedures as described in this document. The P bit MUST be 630 set by both speakers: if a PCEP Speaker receives a STATEFUL-PCE- 631 CAPABILITY TLV with P=0 while it advertised P=1 or if both set P 632 flag to 0, the session SHOULD be set-up but the state-sync 633 procedures MUST NOT be applied on this session. 635 The U flag [RFC8231] MUST be set when sending the STATEFUL-PCE- 636 CAPABILITY TLV with the P flag set. In case the U flag is not set 637 along with the P flag, the state sync capability is not enabled and 638 it is considered as if P flag is not set. The S flag MAY be set if 639 optimized synchronization is required as per [RFC8232]. 641 3.2. State synchronization 643 When the state sync capability has been negotiated between stateful 644 PCEs, each PCEP speaker will behave as a PCE and as a PCC at the same 645 time regarding the state synchronization as defined in [RFC8231]. 646 This means that each PCEP Speaker: 648 o MUST send a PCRpt message towards its neighbour with S flag set 649 for each LSP in its LSP database learned from a PCC. (PCC role) 651 o MUST send the End Of Synchronization Marker towards its neighbour 652 when all LSPs have been reported. (PCC role) 654 o MUST wait for the LSP synchronization from its neighbour to end 655 (receiving an End Of Synchronization Marker). (PCE role) 657 The process of synchronization runs in parallel on each PCE (with no 658 defined order). 660 Optimized state synchronization procedures MAY be used, as defined in 661 [RFC8232]. 663 When a PCEP Speaker sends a PCRpt on a state-sync session, it MUST 664 add the SPEAKER-IDENTITY-TLV (defined in [RFC8232]) in the LSP 665 Object, the value used will refer to the 'owner' PCC of the LSP. If 666 a PCEP Speaker receives a PCRpt on a state-sync session without this 667 TLV, it MUST discard the PCRpt message and it MUST reply with a PCErr 668 message using error-type=6 (Mandatory Object missing) and error- 669 value=TBD1 (SPEAKER-IDENTITY-TLV missing). 671 3.3. Incremental updates and report forwarding rules 673 During the life of an LSP, its state may change (path, constraints, 674 operational state...) and a PCC will advertise a new PCRpt to the PCE 675 for each such change. 677 When propagating LSP state changes from a PCE to other PCEs, it is 678 mandatory to ensure that a PCE always uses the freshest state coming 679 from the PCC. 681 When a PCE receives a new PCRpt from a PCC with the LSP-DB-VERSION, 682 the PCE MUST forward the PCRpt to all its state-sync sessions and 683 MUST add the appropriate SPEAKER-IDENTITY-TLV in the PCRpt. In 684 addition, it MUST add a new ORIGINAL-LSP-DB-VERSION TLV (described 685 below). The ORIGINAL-LSP-DB-VERSION contains the LSP-DB-VERSION 686 coming from the PCC. 688 When a PCE receives a new PCRpt from a PCC without the LSP-DB- 689 VERSION, it SHOULD NOT forward the PCRpt on any state-sync sessions 690 and log such an event on the first occurrence. 692 When a PCE receives a new PCRpt from a PCC with the R flag set and a 693 LSP-DB-VERSION TLV, the PCE MUST forward the PCRpt to all its state- 694 sync sessions keeping the R flag set (Remove) and MUST add the 695 appropriate SPEAKER-IDENTITY-TLV and ORIGINAL-LSP-DB-VERSION TLV in 696 the PCRpt message. 698 When a PCE receives a PCRpt from a state-sync session, it MUST NOT 699 forward the PCRpt to other state-sync sessions. This helps to 700 prevent message loops between PCEs. As a consequence, a full mesh of 701 PCEP sessions between PCEs is REQUIRED. 703 When a PCRpt is forwarded, all the original objects and values are 704 kept. As an example, the PLSP-ID used in the forwarded PCRpt will be 705 the same as the original one used by the PCC. Thus an implementation 706 supporting this document MUST consider SPEAKER-IDENTITY-TLV and PLSP- 707 ID together to uniquely identify an LSP on the state-sync session. 709 The ORIGINAL-LSP-DB-VERSION TLV is encoded as follows and MUST always 710 contain the LSP-DB-VERSION received from the owner PCC of the LSP: 712 0 1 2 3 713 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 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 | Type=TBD2 | Length=8 | 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 | LSP State DB Version Number | 718 | | 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 Using the ORIGINAL-LSP-DB-VERSION TLV allows a PCE to keep using 722 optimized synchronization ([RFC8232]) with another PCE. In such a 723 case, the PCE will send a PCRpt to another PCE with both ORIGINAL- 724 LSP-DB-VERSION TLV and LSP-DB-VERSION TLV. The ORIGINAL-LSP-DB- 725 VERSION TLV will contain the version number as allocated by the PCC 726 while the LSP-DB-VERSION will contain the version number allocated by 727 the local PCE. 729 3.4. Maintaining LSP states from different sources 731 When a PCE receives a PCRpt on a state-sync session, it stores the 732 LSP information into the original PCC address context (as the LSP 733 belongs to the PCC). A PCE SHOULD maintain a single state for a 734 particular LSP and SHOULD maintain the list of sources it learned a 735 particular state from. 737 A PCEP speaker may receive a state information for a particular LSP 738 from different sources: the PCC that owns the LSP (through a regular 739 PCEP session) and some PCEs (through PCEP state-sync sessions). A 740 PCEP speaker MUST always keep the freshest state in its LSP database, 741 overriding the previously received information. 743 A PCE, receiving a PCRpt from a PCC, updates the state of the LSP in 744 its LSP-DB with the new received information. When receiving a PCRpt 745 from another PCE, a PCE SHOULD update the LSP state only if the 746 ORIGINAL-LSP-DB-VERSION present in the PCRpt is greater than the 747 current ORIGINAL-LSP-DB-VERSION of the stored LSP state. This 748 ensures that a PCE never tries to update its stored LSP state with an 749 old information. Each time a PCE updates an LSP state in its LSP-DB, 750 it SHOULD reset the source list associated with the LSP state and 751 SHOULD add the source speaker address in the source list. When a PCE 752 receives a PCRpt which has an ORIGINAL-LSP-DB-VERSION (if coming from 753 a PCE) or an LSP-DB-VERSION (if coming from the PCC) equals to the 754 current ORIGINAL-LSP-DB-VERSION of the stored LSP state, it SHOULD 755 add the source speaker address in the source list. 757 When a PCE receives a PCRpt requesting an LSP deletion from a 758 particular source, it SHOULD remove this particular source from the 759 list of sources associated with this LSP. 761 When the list of sources becomes empty for a particular LSP, the LSP 762 state MUST be removed. This means that all the sources must send a 763 PCRpt with R=1 for an LSP to make the PCE remove the LSP state. 765 3.5. Computation priority between PCEs and sub-delegation 767 A computation priority is necessary to ensure that a single PCE will 768 perform the computation for all the LSPs in an association group: 769 this will allow for a more optimized LSP placement and will prevent 770 computation loops. 772 All PCEs in the network that are handling LSPs in a common LSP 773 association group SHOULD be aware of each other including the 774 computation priority of each PCE. Note that there is no need for PCC 775 to be aware of this. The computation priority is a number and the 776 PCE having the highest priority SHOULD be responsible for the 777 computation. If several PCEs have the same priority value, their IP 778 address SHOULD be used as a tie-breaker to provide a rank: the 779 highest IP address has more priority. How PCEs are aware of the 780 priority of each other is out of scope of this document, but as 781 example learning priorities could be done through PCE discovery or 782 local configuration. 784 The definition of the priority could be global so the highest 785 priority PCE will handle all path computations or more granular, so a 786 PCE may have highest priority for only a subset of LSPs or 787 association-groups. 789 A PCEP Speaker receiving a PCRpt from a PCC with D flag set that does 790 not have the highest computation priority, SHOULD forward the PCRpt 791 on all state-sync sessions (as per Section 3.3) and SHOULD set D flag 792 on the state-sync session towards the highest priority PCE, D flag 793 will be unset to all other state-sync sessions. This behaviour is 794 similar to the delegation behaviour handled at PCC side and is called 795 a sub-delegation (the PCE sub-delegates the control of the LSP to 796 another PCE). When a PCEP Speaker sub-delegates a LSP to another 797 PCE, it looses the control on the LSP and cannot update it any more 798 by its own decision. When a PCE receives a PCRpt with D flag set on 799 a state-sync session, as a regular PCE, it is granted control over 800 the LSP. 802 If the highest priority PCE is failing or if the state-sync session 803 between the local PCE and the highest priority PCE failed, the local 804 PCE MAY decide to delegate the LSP to the next highest priority PCE 805 or to take back control on the LSP. It is a local policy decision. 807 When a PCE has the delegation for an LSP and needs to update this 808 LSP, it MUST send a PCUpd message to all state-sync sessions and to 809 the PCC session on which it received the delegation. The D-Flag 810 would be unset in the PCUpd for state-sync sessions where as D-Flag 811 would be set for the PCC. In case of sub-delegation, the computing 812 PCE will send the PCUpd only to all state-sync sessions (as it has no 813 direct delegation from a PCC). The D-Flag would be set for the 814 state-sync session to the PCE that sub-delegated this LSP and the 815 D-Flag would be unset for other state-sync sessions. 817 The PCUpd sent over a state-sync session MUST contain the SPEAKER- 818 IDENTITY-TLV in the LSP Object (the value used must identify the 819 target PCC). The PLSP-ID used is the original PLSP-ID generated by 820 the PCC and learned from the forwarded PCRpt. If a PCE receives a 821 PCUpd on a state-sync session without the SPEAKER-IDENTITY-TLV, it 822 MUST discard the PCUpd and MUST reply with a PCErr message using 823 error-type=6 (Mandatory Object missing) and error-value=TBD1 824 (SPEAKER-IDENTITY-TLV missing). 826 When a PCE receives a valid PCUpd on a state-sync session, it SHOULD 827 forward the PCUpd to the appropriate PCC (identified based on the 828 SPEAKER-IDENTITY-TLV value) that delegated the LSP originally and 829 SHOULD remove the SPEAKER-IDENTITY-TLV from the LSP Object. The 830 acknowledgement of the PCUpd is done through a cascaded mechanism, 831 and the PCC is the only responsible of triggering the 832 acknowledgement: when the PCC receives the PCUpd from the local PCE, 833 it acknowledges it with a PCRpt as per [RFC8231]. When receiving the 834 new PCRpt from the PCC, the local PCE uses the defined forwarding 835 rules on the state-sync session so the acknowledgement is relayed to 836 the computing PCE. 838 A PCE SHOULD NOT compute a path using an association-group constraint 839 if it has delegation for only a subset of LSPs in the group. In this 840 case, an implementation MAY use a local policy on PCE to decide if 841 PCE does not compute path at all for this set of LSP or if it can 842 compute a path by relaxing the association-group constraint. 844 3.6. Passive stateful procedures 846 In the passive stateful PCE architecture, the PCC is responsible for 847 triggering a path computation request using a PCReq message to its 848 PCE. Similarly to PCRpt Message, which remains unchanged for passive 849 mode, if a PCE receives a PCReq for an LSP and if this PCE finds that 850 it does not have the highest computation priority of this LSP, or 851 groups..., it MUST forward the PCReq message to the highest priority 852 PCE over the state-sync session. When the highest priority PCE 853 receives the PCReq, it computes the path and generates a PCRep 854 message towards the PCE that made the request. This PCE will then 855 forward the PCRep to the requesting PCC. The handling of LSP object 856 and the SPEAKER-IDENTITY-TLV in PCReq and PCRep is similar to PCRpt/ 857 PCUpd messages. 859 3.7. PCE initiation procedures 861 TBD 863 4. Examples 865 The examples in this section are for illustrative purpose to show how 866 the behaviour of the state sync inter-PCE sessions. 868 4.1. Example 1 869 _________________________________________ 870 / \ 871 / +------+ +------+ \ 872 | | PCE1 | | PCE2 | | 873 | +------+ +------+ | 874 | | 875 | +------+ 10 +------+ | 876 | | PCC1 | ----- R1 ---- R2 ------- | PCC2 | | 877 | +------+ | | +------+ | 878 | | | | 879 | | | | 880 | +------+ | | +------+ | 881 | | PCC3 | ----- R3 ---- R4 ------- | PCC4 | | 882 | +------+ +------+ | 883 | | 884 \ / 885 \_________________________________________/ 887 +----------+ 888 | PCC1 | LSP : PCC1->PCC2 889 +----------+ 890 / 891 D=1 / 892 +---------+ +---------+ 893 | PCE1 |----| PCE2 | 894 +---------+ +---------+ 895 / D=1 896 / 897 +----------+ 898 | PCC3 | LSP : PCC3->PCC4 899 +----------+ 901 PCE1 computation priority 100 902 PCE2 computation priority 200 904 Consider the PCEP sessions as shown above, where computation priority 905 is global for all the LSPs and link disjoint between LSPs PCC1->PCC2 906 and PCC3->PCC4 is required. 908 Consider the PCC1->PCC2 is configured first and PCC1 delegates the 909 LSP to PCE1, but as PCE1 does not have the highest computation 910 priority, it sub-delegates the LSP to PCE2 by sending a PCRpt with 911 D=1 and including the SPEAKER-IDENTITY-TLV over the state-sync 912 session. PCE2 receives the PCRpt and as it has delegation for this 913 LSP, it computes the shortest path: R1->R3->R4->R2->PCC2. It then 914 sends a PCUpd to PCE1 (including the SPEAKER-IDENTITY-TLV) with the 915 computed ERO. PCE1 forwards the PCUpd to PCC1 (removing the SPEAKER- 916 IDENTITY-TLV). PCC1 acknowledges the PCUpd by a PCRpt to PCE1. PCE1 917 forwards the PCRpt to PCE2. 919 When PCC3->PCC4 is configured, PCC3 delegates the LSP to PCE2, PCE2 920 can compute a disjoint path as it has knowledge of both LSPs and has 921 delegation also for both. The only solution found is to move 922 PCC1->PCC2 LSP on another path, PCE2 can move PCC1->PCC2 as it has 923 sub-delegation for it. It creates a new PCUpd with new ERO: 924 R1->R2-PCC2 towards PCE1 which forwards to PCC1. PCE2 sends a PCUpd 925 to PCC3 with the path: R3->R4->PCC4. 927 In this set-up, PCEs are able to find a disjoint path while without 928 state-sync and computation priority they could not. 930 4.2. Example 2 931 _____________________________________ 932 / \ 933 / +------+ +------+ \ 934 | | PCE1 | | PCE2 | | 935 | +------+ +------+ | 936 | | 937 | +------+ 100 +------+ | 938 | | | -------------------- | | | 939 | | PCC1 | ----- R1 ----------- | PCC2 | | 940 | +------+ | +------+ | 941 | | | | | 942 | 6 | | 2 | 2 | 943 | | | | | 944 | +------+ | +------+ | 945 | | PCC3 | ----- R3 ----------- | PCC4 | | 946 | +------+ 10 +------+ | 947 | | 948 \ / 949 \_____________________________________/ 951 +----------+ 952 | PCC1 | LSP : PCC1->PCC2 953 +----------+ 954 / \ 955 D=1 / \ D=0 956 +---------+ +---------+ 957 | PCE1 |----| PCE2 | 958 +---------+ +---------+ 959 D=0 \ / D=1 960 \ / 961 +----------+ 962 | PCC3 | LSP : PCC3->PCC4 963 +----------+ 965 PCE1 computation priority 200 966 PCE2 computation priority 100 968 In this example, suppose both LSPs are configured almost at the same 969 time. PCE1 sub-delegates PCC1->PCC2 to PCE2 while PCE2 keeps 970 delegation for PCC3->PCC4, PCE2 computes a path for PCC1->PCC2 and 971 PCC3->PCC4 and can achieve disjointness computation easily. No 972 computation loop happens in this case. 974 4.3. Example 3 976 _________________________________________ 977 / \ 978 / +------+ +------+ \ 979 | | PCE1 | | PCE2 | | 980 | +------+ +------+ | 981 | | 982 | +------+ 10 +------+ | 983 | | PCC1 | ----- R1 ---- R2 ------- | PCC2 | | 984 | +------+ | | +------+ | 985 | | | | 986 | | | | 987 | +------+ | | +------+ | 988 | | PCC3 | ----- R3 ---- R4 ------- | PCC4 | | 989 | +------+ +------+ | 990 | | 991 \ / 992 \_________________________________________/ 994 +----------+ 995 | PCC1 | LSP : PCC1->PCC2 996 +----------+ 997 / 998 D=1 / 999 +---------+ +---------+ +---------+ 1000 | PCE1 |----| PCE2 |----| PCE3 | 1001 +---------+ +---------+ +---------+ 1002 / D=1 1003 / 1004 +----------+ 1005 | PCC3 | LSP : PCC3->PCC4 1006 +----------+ 1008 PCE1 computation priority 100 1009 PCE2 computation priority 200 1010 PCE3 computation priority 300 1012 With the PCEP sessions as shown above, consider the need to have link 1013 disjoint LSPs PCC1->PCC2 and PCC3->PCC4. 1015 Suppose PCC1->PCC2 is configured first, PCC1 delegates the LSP to 1016 PCE1, but as PCE1 does not have the highest computation priority, it 1017 will sub-delegate the LSP to PCE2 (as it not aware of PCE3 and has no 1018 way to reach it). PCE2 cannot compute a path for PCC1->PCC2 as it 1019 does not have the highest priority and is not allowed to sub-delegate 1020 the LSP again towards PCE3 as per Section 3. 1022 When PCC3->PCC4 is configured, PCC3 delegates the LSP to PCE2 that 1023 performs sub-delegation to PCE3. As PCE3 will have knowledge of only 1024 one LSP in the group, it cannot compute disjointness and can decide 1025 to fallback to a less constrained computation to provide a path for 1026 PCC3->PCC4. In this case, it will send a PCUpd to PCE2 that will be 1027 forwarded to PCC3. 1029 Disjointness cannot be achieved in this scenario because of lack of 1030 state-sync session between PCE1 and PCE3, but no computation loop 1031 happens. Thus it is advised for all PCEs that support state-sync to 1032 have a full mesh sessions between each other. 1034 5. Using Master/Slave computation and state-sync sessions to increase 1035 scaling 1037 The Primary/Backup computation and state-sync sessions architecture 1038 can be used to increase the scaling of the PCE architecture. If the 1039 number of PCCs is really high, it may be too resource consuming for a 1040 single PCE to maintain all the PCEP sessions while at the same time 1041 performing all path computations. Using master/slave computation and 1042 state-sync sessions may allow to create groups of PCEs that manage a 1043 subset of the PCCs and perform some or no path computations. 1044 Decoupling PCEP session maintenance and computation will allow to 1045 increase scaling of the PCE architecture. 1047 +----------+ 1048 | PCC500 | 1049 +----------+-+ 1050 | PCC1 | 1051 +----------+ 1052 / \ 1053 / \ 1054 +---------+ +---------+ 1055 | PCE1 |---| PCE2 | 1056 +---------+ +---------+ 1057 | \ / | 1058 | \/ | 1059 | /\ | 1060 | / \ | 1061 +---------+ +---------+ 1062 | PCE3 |---| PCE4 | 1063 +---------+ +---------+ 1064 \ / 1065 \ / 1066 +----------+ 1067 | PCC501 | 1068 +----------+-+ 1069 | PCC1000 | 1070 +----------+ 1072 In the figure above, two groups of PCEs are created: PCE1/2 maintain 1073 PCEP sessions with PCC1 up to PCC500, while PCE3/4 maintain PCEP 1074 sessions with PCC501 up to PCC1000. A granular master/slave policy 1075 is set-up as follows to load-share computation between PCEs: 1077 o PCE1 has priority 200 for association ID 1 up to 300, association 1078 source 0.0.0.0. All other PCEs have a decreasing priority for 1079 those associations. 1081 o PCE3 has priority 200 for association ID 301 up to 500, 1082 association source 0.0.0.0. All other PCEs have a decreasing 1083 priority for those associations. 1085 If some PCCs delegate LSPs with association ID 1 up to 300 and 1086 association source 0.0.0.0, the receiving PCE (if not PCE1) will sub- 1087 delegate the LSPs to PCE1. PCE1 becomes responsible for the 1088 computation of these LSP associations while PCE3 is responsible for 1089 the computation of another set of associations. 1091 The procedures describe in this document could help greatly in load- 1092 sharing between a group of stateful PCEs. 1094 6. PCEP-PATH-VECTOR-TLV 1096 This document allows PCEP messages to be propagated among PCEP 1097 speaker. It may be useful to track informations about the 1098 propagation of the messages. One of the use case is a message loop 1099 detection mechanism, but other use cases like hop by hop information 1100 recording may also be implemented. 1102 This document introduces the PCEP-PATH-VECTOR-TLV (type TBD3) with 1103 the following format: 1105 0 1 2 3 1106 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 1107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1108 | Type=TBD3 | Length (variable) | 1109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1110 | PCEP-SPEAKER-INFORMATION#1 | 1111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1112 | ... | 1113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1114 | ... | 1115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1116 | PCEP-SPEAKER-INFORMATION#n | 1117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1119 The TLV format and padding rules are as per [RFC5440]. 1121 The PCEP-SPEAKER-INFORMATION field has the following format: 1123 0 1 2 3 1124 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 1125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1126 | Length (variable) | ID Length (variable) | 1127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1128 | Speaker Entity identity (variable) | 1129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1130 | SubTLVs (optional) | 1131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1133 Length: defines the total length of the PCEP-SPEAKER-INFORMATION 1134 field. 1136 ID Length: defines the length of the Speaker identity actual field 1137 (non-padded). 1139 Speaker Entity identity: same possible values as the SPEAKER- 1140 IDENTIFIER-TLV. Padded with trailing zeroes to a 4-byte boundary. 1142 The PCEP-SPEAKER-INFORMATION may also carry some optional subTLVs 1143 so each PCEP speaker can add local informations that could be 1144 recorded. This document does not define any subTLV. 1146 The PCEP-PATH-VECTOR-TLV MAY be added in the LSP Object. Its usage 1147 is purely optional. 1149 The list of speakers within the PCEP-PATH-VECTOR-TLV MUST be ordered. 1150 When sending a PCEP message (PCRpt, PCUpd or PCInitiate), a PCEP 1151 Speaker MAY add the PCEP-PATH-VECTOR-TLV with a PCEP-SPEAKER- 1152 INFORMATION containing its own informations. If the PCEP message 1153 sent is the result of a previously received PCEP message, and if the 1154 PCEP-PATH-VECTOR-TLV was already present in the initial message, the 1155 PCEP speaker MAY append a new PCEP-SPEAKER-INFORMATION containing its 1156 own informations. 1158 7. Security Considerations 1160 TBD. 1162 8. Acknowledgements 1164 TBD. 1166 9. IANA Considerations 1168 This document requests IANA actions to allocate code points for the 1169 protocol elements defined in this document. 1171 9.1. PCEP-Error Object 1173 IANA is requested to allocate a new Error Value for the Error Type 9. 1175 Error-Type Meaning Reference 1176 6 Mandatory Object Missing [RFC5440] 1177 Error-value=TBD1: SPEAKER-IDENTITY-TLV This document 1178 missing 1180 9.2. PCEP TLV Type Indicators 1182 IANA is requested to allocate new TLV Type Indicator values within 1183 the "PCEP TLV Type Indicators" sub-registry of the PCEP Numbers 1184 registry, as follows: 1186 Value Meaning Reference 1187 TBD2 ORIGINAL-LSP-DB-VERSION-TLV This document 1188 TBD3 PCEP-PATH-VECTOR-TLV This document 1190 9.3. STATEFUL-PCE-CAPABILITY TLV 1192 IANA is requested to allocate a new bit value in the STATEFUL-PCE- 1193 CAPABILITY TLV Flag Field sub-registry. 1195 Bit Description Reference 1196 TBD INTER-PCE-CAPABILITY This document 1198 10. References 1200 10.1. Normative References 1202 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1203 Requirement Levels", BCP 14, RFC 2119, 1204 DOI 10.17487/RFC2119, March 1997, 1205 . 1207 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1208 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1209 DOI 10.17487/RFC5440, March 2009, 1210 . 1212 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1213 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1214 May 2017, . 1216 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1217 Computation Element Communication Protocol (PCEP) 1218 Extensions for Stateful PCE", RFC 8231, 1219 DOI 10.17487/RFC8231, September 2017, 1220 . 1222 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 1223 and D. Dhody, "Optimizations of Label Switched Path State 1224 Synchronization Procedures for a Stateful PCE", RFC 8232, 1225 DOI 10.17487/RFC8232, September 2017, 1226 . 1228 10.2. Informative References 1230 [I-D.ietf-pce-association-diversity] 1231 Litkowski, S., Sivabalan, S., Barth, C., and M. Negi, 1232 "Path Computation Element Communication Protocol (PCEP) 1233 Extension for LSP Diversity Constraint Signaling", draft- 1234 ietf-pce-association-diversity-13 (work in progress), 1235 December 2019. 1237 [I-D.ietf-pce-stateful-hpce] 1238 Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., and D. King, 1239 "Hierarchical Stateful Path Computation Element (PCE)", 1240 draft-ietf-pce-stateful-hpce-15 (work in progress), 1241 October 2019. 1243 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1244 Element (PCE)-Based Architecture", RFC 4655, 1245 DOI 10.17487/RFC4655, August 2006, 1246 . 1248 [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the 1249 Path Computation Element Architecture to the Determination 1250 of a Sequence of Domains in MPLS and GMPLS", RFC 6805, 1251 DOI 10.17487/RFC6805, November 2012, 1252 . 1254 [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path 1255 Computation Element Architecture", RFC 7399, 1256 DOI 10.17487/RFC7399, October 2014, 1257 . 1259 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 1260 S. Ray, "North-Bound Distribution of Link-State and 1261 Traffic Engineering (TE) Information Using BGP", RFC 7752, 1262 DOI 10.17487/RFC7752, March 2016, 1263 . 1265 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 1266 Stateful Path Computation Element (PCE)", RFC 8051, 1267 DOI 10.17487/RFC8051, January 2017, 1268 . 1270 Appendix A. Contributors 1272 Dhruv Dhody 1273 Huawei Technologies 1274 Divyashree Techno Park, Whitefield 1275 Bangalore, Karnataka 560066 1276 India 1278 Email: dhruv.ietf@gmail.com 1280 Authors' Addresses 1281 Stephane Litkowski 1282 Cisco 1284 Email: slitkows.ietf@gmail.com 1286 Siva Sivabalan 1287 Cisco 1289 Email: msiva@cisco.com 1291 Cheng Li 1292 Huawei Technologies 1293 Huawei Campus, No. 156 Beiqing Rd. 1294 Beijing 100095 1295 China 1297 Email: chengli13@huawei.com 1299 Haomian Zheng 1300 Huawei Technologies 1301 H1, Huawei Xiliu Beipo Village, Songshan Lake 1302 Dongguan, Guangdong 523808 1303 China 1305 Email: zhenghaomian@huawei.com