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