idnits 2.17.1 draft-litkowski-pce-state-sync-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 8, 2019) is 1877 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-06 == Outdated reference: A later version (-15) exists of draft-ietf-pce-stateful-hpce-06 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). 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: September 9, 2019 Cisco 6 C. Li 7 H. Zheng 8 Huawei Technologies 9 March 8, 2019 11 Inter Stateful Path Computation Element (PCE) Communication Procedures. 12 draft-litkowski-pce-state-sync-05 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 an event occurs. 36 Finally, when, in a redundant PCE scenario, there is a need to 37 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 September 9, 2019. 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 . . . . . . . . . . . . . . . . . . 3 92 1.2. Split-brain . . . . . . . . . . . . . . . . . . . . . . . 4 93 1.3. Applicability to H-PCE . . . . . . . . . . . . . . . . . 11 94 2. Proposed solution . . . . . . . . . . . . . . . . . . . . . . 11 95 2.1. State-sync session . . . . . . . . . . . . . . . . . . . 11 96 2.2. Master/Slave relationship between PCE . . . . . . . . . . 13 97 3. Procedures and protocol extensions . . . . . . . . . . . . . 13 98 3.1. Opening a state-sync session . . . . . . . . . . . . . . 13 99 3.1.1. Capability advertisement . . . . . . . . . . . . . . 13 100 3.2. State synchronization . . . . . . . . . . . . . . . . . . 14 101 3.3. Incremental updates and report forwarding rules . . . . . 14 102 3.4. Maintaining LSP states from different sources . . . . . . 16 103 3.5. Computation priority between PCEs and sub-delegation . . 16 104 3.6. Passive stateful procedures . . . . . . . . . . . . . . . 18 105 3.7. PCE initiation procedures . . . . . . . . . . . . . . . . 18 106 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 18 107 4.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 19 108 4.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 20 109 4.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . . . 22 110 5. Using Master/Slave computation and state-sync sessions to 111 increase scaling . . . . . . . . . . . . . . . . . . . . . . 23 112 6. PCEP-PATH-VECTOR-TLV . . . . . . . . . . . . . . . . . . . . 25 113 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 114 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 115 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 116 9.1. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 26 117 9.2. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 26 118 9.3. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 27 119 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 120 10.1. Normative References . . . . . . . . . . . . . . . . . . 27 121 10.2. Informative References . . . . . . . . . . . . . . . . . 27 122 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 28 123 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 125 1. Introduction and problem statement 127 1.1. Reporting LSP changes 129 When using a stateful PCE ([RFC8231]), a Path Computation Client 130 (PCC) can synchronize an LSP state information to the stateful Path 131 Computation Element (PCE). If the PCC grants the control on the LSP 132 to the PCE (called delegation [RFC8231]), the PCE can update the LSP 133 parameters at any time. 135 In a multi PCE deployment (redundancy, loadbalancing...), with the 136 current specification defined in [RFC8231], when a PCE makes an 137 update, it is the PCC that is in charge of reporting the LSP status 138 to all PCEs with LSP parameter change which brings additional hops 139 and delays in notifying the overall network of the LSP parameter 140 change. 142 This delay may affect the reaction time of the other PCEs, if they 143 need to take action after being notified of the LSP parameter change. 145 Apart from the synchronization from the PCC, it is also useful if 146 there is synchronization mechanism between the stateful PCEs. As 147 stateful PCE make changes to its delegated LSPs, these changes 148 (pending LSPs and the sticky resources [RFC7399]) can be synchronized 149 immediately to the other PCEs. 151 +----------+ 152 | PCC1 | LSP1 153 +----------+ 154 / \ 155 / \ 156 +---------+ +---------+ 157 | PCE1 | | PCE2 | 158 +---------+ +---------+ 159 \ / 160 \ / 161 +----------+ 162 | PCC2 | LSP2 163 +----------+ 165 In the figure above, we consider a loadbalanced PCE architecture, so 166 PCE1 is responsible to compute paths for PCC1 and PCE2 is responsible 167 to compute paths for PCC2. When PCE1 triggers an LSP update for 168 LSP1, it sends a PCUpd message to PCC1 for LSP1 containing the new 169 parameters. PCC1 will take the parameters into account and will send 170 a PCRpt message to PCE1 and PCE2 reflecting the changes. PCE2 will 171 so be notified of the change only after receiving the PCRpt message 172 from PCC1. 174 Let's consider that the LSP1 parameters changed in such a way that 175 LSP1 will take over resources from LSP2 with a higher priority. 176 After receiving the report from PCC1, PCE2 will therefore try to find 177 a new path for LSP2. If we consider that there is a round trip delay 178 of about 150msec between the PCEs and PCC1 and a round trip delay of 179 10msec between the two PCEs, if will take more than 150msec for PCE2 180 to be notified of the change. 182 Adding a PCEP session between PCE1 and PCE2 may allow to reduce the 183 syncronization time, so PCE2 can react more quickly by taking the 184 pending LSPs and attached resources into account during path 185 computation and reoptimization. 187 1.2. Split-brain 189 In a resiliency case, a PCC has redundant PCEP sessions towards 190 multiple PCEs. In such a case, a PCC gives control on an LSP to a 191 single PCE only, and only this PCE is responsible for the path 192 computation for the delegated LSP: the PCC achieves this by setting 193 the D flag only towards the active PCE [RFC8231]. The election of 194 the active PCE to delegate an LSP is controlled by each PCC. The PCC 195 usually elects the active PCE by a local configured policy (by 196 setting a priority). Upon PCEP session failure, or active PCE 197 failure, PCC may decide to elect a new active PCE by sending new 198 PCRpt message with D flag set to this new active PCE. When the 199 failed PCE or PCEP session comes back online, it will be up to the 200 implementation to do preemption. Doing preemption may lead to some 201 traffic disruption on the existing path if path results from both 202 PCEs are not exactly the same. By considering a network with 203 multiple PCCs and implementing multiple stateful PCEs for redundancy 204 purpose, there is no guarantee that at any time all the PCCs delegate 205 their LSPs to the same PCE. 207 +----------+ 208 | PCC1 | LSP1 209 +----------+ 210 / \ 211 / \ 212 +---------+ +---------+ 213 | PCE1 | | PCE2 | 214 +---------+ +---------+ 215 \ / 216 *fail* \ / 217 +----------+ 218 | PCC2 | LSP2 219 +----------+ 221 In the example above, we consider that by configuration, both PCCs 222 will firstly delegate their LSP to PCE1. So PCE1 is responsible for 223 computing a path for LSP1 and LSP2. If the PCEP session between PCC2 224 and PCE1 fails, PCC2 will delegate LSP2 to PCE2. So PCE1 becomes 225 responsible only for LSP1 path computation while PCE2 is responsible 226 for the path computation of LSP2. When the PCC2-PCE1 session is back 227 online, PCC2 will keep using PCE2 as active PCE (no preemption in 228 this example). So the result is a permanent situation where each PCE 229 is responsible for a subset of path computation. 231 We call this situation a split-brain scenario as there are multiple 232 computation brains running at the same time while a central 233 computation unit was required in some deployments/usecases. 235 Further, there are use cases where a particular LSP path computation 236 is linked to another LSP path computation: the most common use case 237 is path disjointness (see [I-D.ietf-pce-association-diversity]). The 238 set of LSPs that are dependant to each other may start from a 239 different head-end. 241 _________________________________________ 242 / \ 243 / +------+ +------+ \ 244 | | PCE1 | | PCE2 | | 245 | +------+ +------+ | 246 | | 247 | +------+ +------+ | 248 | | PCC1 | ----------------------> | PCC2 | | 249 | +------+ +------+ | 250 | | 251 | | 252 | +------+ +------+ | 253 | | PCC3 | ----------------------> | PCC4 | | 254 | +------+ +------+ | 255 | | 256 \ / 257 \_________________________________________/ 259 _________________________________________ 260 / \ 261 / +------+ +------+ \ 262 | | PCE1 | | PCE2 | | 263 | +------+ +------+ | 264 | | 265 | +------+ 10 +------+ | 266 | | PCC1 | ----- R1 ---- R2 ------- | PCC2 | | 267 | +------+ | | +------+ | 268 | | | | 269 | | | | 270 | +------+ | | +------+ | 271 | | PCC3 | ----- R3 ---- R4 ------- | PCC4 | | 272 | +------+ +------+ | 273 | | 274 \ / 275 \_________________________________________/ 277 In the figure above, the requirement is to create two link-disjoint 278 LSPs: PCC1->PCC2 and PCC3->PCC4. In the topology, all link metrics 279 are equal to 1 except the link R1-R2 which has a metric of 10. The 280 PCEs are responsible for the path computation and PCE1 is the active 281 PCE for all PCCs in the nominal case. 283 Scenario 1: 285 In the normal case (PCE1 as active PCE), we first configure 286 PCC1->PCC2 LSP, as the only constraint is path disjointness, PCE1 287 sends a PCUpd message to PCC1 with the ERO: R1->R3->R4->R2->PCC2 288 (shortest path). PCC1 signals and installs the path. When 289 PCC3->PCC4 is configured, the PCE already knows the path of 290 PCC1->PCC2 and can compute a link-disjoint path : the solution 291 requires to move PCC1->PCC2 onto a new path to let room for the new 292 LSP. PCE1 sends a PCUpd message to PCC1 with the new ERO: 293 R1->R2->PCC2 and a PCUpd to PCC3 with the following ERO: 294 R3->R4->PCC4. In the normal case, there is no issue for PCE1 to 295 compute a link-disjoint path. 297 Scenario 2: 299 Now we consider that PCC1 lost its PCEP session with PCE1 (all other 300 PCEP sessions are UP). PCC1 delegates its LSP to PCE2. 302 +----------+ 303 | PCC1 | LSP: PCC1->PCC2 304 +----------+ 305 \ 306 \ D=1 307 +---------+ +---------+ 308 | PCE1 | | PCE2 | 309 +---------+ +---------+ 310 D=1 \ / D=0 311 \ / 312 +----------+ 313 | PCC3 | LSP: PCC3->PCC4 314 +----------+ 316 We first configure PCC1->PCC2 LSP, as the only constraint is path 317 disjointness, PCE2 (which is the new active PCE for PCC1) sends a 318 PCUpd message to PCC1 with the ERO: R1->32->R4->R2->PCC2 (shortest 319 path). When PCC3->PCC4 is configured, PCE1 is not aware of LSPs from 320 PCC1 anymore, so it cannot compute a disjoint path for PCC3->PCC4 and 321 will send a PCUpd message to PCC2 with a shortest path ERO: 322 R3->R4->PCC4. When PCC3->PCC4 LSP will be reported to PCE2 by PCC2, 323 PCE2 will ensure disjointness computation and will correctly move 324 PCC1->PCC2 (as it owns delegation for this LSP) on the following 325 path: R1->R2->PCC2. With this sequence of event and this PCEP 326 session topology, disjointness is ensured. 328 Scenario 3: 330 +----------+ 331 | PCC1 | LSP: PCC1->PCC2 332 +----------+ 333 / \ 334 D=1 / \ D=0 335 +---------+ +---------+ 336 | PCE1 | | PCE2 | 337 +---------+ +---------+ 338 / D=1 339 / 340 +----------+ 341 | PCC3 | LSP: PCC3->PCC4 342 +----------+ 344 With this new PCEP session topology, we first configure PCC1->PCC2, 345 PCE1 computes the shortest path as it is the only LSP in the disjoint 346 association group that it is aware of: R1->R3->R4->R2->PCC2 (shortest 347 path). When PCC3->PCC4 is configured, PCE2 must compute a disjoint 348 path for this LSP. The only solution found is to move PCC1->PCC2 LSP 349 on another path, but PCE2 cannot do it as it does not have delegation 350 for this LSP. In this setup, PCEs are not able to find a disjoint 351 path. 353 Scenario 4: 355 +----------+ 356 | PCC1 | LSP: PCC1->PCC2 357 +----------+ 358 / \ 359 D=1 / \ D=0 360 +---------+ +---------+ 361 | PCE1 | | PCE2 | 362 +---------+ +---------+ 363 D=0 \ / D=1 364 \ / 365 +----------+ 366 | PCC3 | LSP: PCC3->PCC4 367 +----------+ 369 With this new PCEP session topology, we consider that PCEs are 370 configured to fallback to shortest path if disjointness cannot be 371 found. We first configure PCC1->PCC2, PCE1 computes shortest path as 372 it is the only LSP in the disjoint association group that it is aware 373 of: R1->R3->R4->R2->PCC2 (shortest path). When PCC3->PCC4 is 374 configured, PCE2 must compute a disjoint path for this LSP. The only 375 solution found is to move PCC1->PCC2 LSP on another path, but PCE2 376 cannot do it as it does not have delegation for this LSP. PCE2 then 377 provides shortest path for PCC3->PCC4: R3->R4->PCC4. When PCC3 378 receives the ERO, it reports it back to both PCEs. When PCE1 becomes 379 aware of PCC3->PCC4 path, it recomputes the constrained shortest path 380 first (CSPF) algorithm and provides a new path for PCC1->PCC2: 381 R1->R2->PCC2. The new path is reported back to all PCEs by PCC1. 382 PCE2 recomputes also CSPF to take into account the new reported path. 383 The new computation does not lead to any path update. 385 Scenario 5: 387 _____________________________________ 388 / \ 389 / +------+ +------+ \ 390 | | PCE1 | | PCE2 | | 391 | +------+ +------+ | 392 | | 393 | +------+ 100 +------+ | 394 | | | -------------------- | | | 395 | | PCC1 | ----- R1 ----------- | PCC2 | | 396 | +------+ | +------+ | 397 | | | | | 398 | 6 | | 2 | 2 | 399 | | | | | 400 | +------+ | +------+ | 401 | | PCC3 | ----- R3 ----------- | PCC4 | | 402 | +------+ 10 +------+ | 403 | | 404 \ / 405 \_____________________________________/ 407 Now we consider a new network topology with the same PCEP session 408 topology as the previous example. We configure both LSPs almost at 409 the same time. PCE1 will compute a path for PCC1->PCC2 while PCE2 410 will compute a path for PCC3->PCC4. As each other is not aware of 411 the path of the second LSP in the association group (not reported 412 yet), each PCE is computing shortest path for the LSP. PCE1 computes 413 ERO: R1->PCC2 for PCC1->PCC2 and PCE2 computes ERO: 414 R3->R1->PCC2->PCC4 for PCC3->PCC4. When these shortest paths will be 415 reported to each PCE. Each PCE will recompute disjointness. PCE1 416 will provide a new path for PCC1->PCC2 with ERO: PCC1->PCC2. PCE2 417 will provide also a new path for PCC3->PCC4 with ERO: R3->PCC4. When 418 those new paths will be reported to both PCEs, this will trigger CSPF 419 again. PCE1 will provide a new more optimal path for PCC1->PCC2 with 420 ERO: R1->PCC2 and PCE2 will also provide a more optimal path for 421 PCC3->PCC4 with ERO: R3->R1->PCC2->PCC4. So we come back to the 422 initial state. When those paths will be reported to both PCEs, this 423 will trigger CSPF again. An infinite loop of CSPF computation is 424 then happening with a permanent flap of paths because of the split- 425 brain situation. 427 This permanent computation loop comes from the inconsistency between 428 the state of the LSPs as seen by each PCE due to the split-brain: 429 each PCE is trying to modify at the same time its delegated path 430 based on the last received path information which defacto invalidates 431 this received path information. 433 Scenario 6: multi-domain 435 Domain/Area 1 Domain/Area 2 436 ________________ ________________ 437 / \ / \ 438 / +------+ | | +------+ \ 439 | | PCE1 | | | | PCE3 | | 440 | +------+ | | +------+ | 441 | | | | 442 | +------+ | | +------+ | 443 | | PCE2 | | | | PCE4 | | 444 | +------+ | | +------+ | 445 | | | | 446 | +------+ | | +------+ | 447 | | PCC1 | | | | PCC2 | | 448 | +------+ | | +------+ | 449 | | | | 450 | | | | 451 | +------+ | | +------+ | 452 | | PCC3 | | | | PCC4 | | 453 | +------+ | | +------+ | 454 \ | | | 455 \_______________/ \________________/ 457 In the example above, we want to create disjoint LSPs from PCC1 to 458 PCC2 and from PCC4 to PCC3. All the PCEs have the knowledge of both 459 domain topologies (e.g. using BGP-LS). For operation/management 460 reason, each domain uses its own group of redundant PCEs. PCE1/PCE2 461 in domain 1 have PCEP sessions with PCC1 and PCC3 while PCE3/PCE4 in 462 domain 2 have PCEP sessions with PCC2 and PCC4. As PCE1/2 do not 463 know about LSPs from PCC2/4 and PCE3/4 do not know about LSPs from 464 PCC1/3, there is no possibility to compute the disjointness 465 constraint. This scenario can also be seen as a split-brain 466 scenario. This multi-domain architecture (with multiple groups of 467 PCEs) can also be used in a single domain, where an operator wants to 468 limit the failure domain by creating multiple groups of PCEs 469 maintaining a subset of PCCs. As for the multi-domain example, there 470 will be no possibility to compute disjoint path starting from head- 471 ends managed by different PCE groups. 473 In this document, we will propose a solution that address the 474 possibility to compute LSP association based constraints (like 475 disjointness) in split-brain scenarios while preventing computation 476 loops. 478 1.3. Applicability to H-PCE 480 [I-D.ietf-pce-stateful-hpce] describes general considerations and use 481 cases for the deployment of Stateful PCE(s) using the Hierarchical 482 PCE [RFC6805] architecture. In this architecture there is a clear 483 need to communicate between a child stateful PCE and a parent 484 stateful PCE. The procedures and extensions as described in 485 Section 3 are equally applicable to H-PCE. 487 2. Proposed solution 489 Our solution is based on : 491 o The creation of the inter-PCE stateful PCEP session with specific 492 procedures. 494 o A Master/Slave relationship between PCEs. 496 2.1. State-sync session 498 We propose to create a PCEP session between the stateful PCEs. 499 Creating such session is already authorized by multiple scenarios 500 like the one described in [RFC4655] (multiple PCEs that are handling 501 part of the path computation) and [RFC6805] (hierarchical PCE) but 502 was only focused on stateless PCEP sessions. As stateful PCE brings 503 additional features (LSP state synchronization, path update ...), 504 thus some new behaviors need to be defined. 506 This inter-PCE PCEP session will allow exchange of LSP states between 507 PCEs that would help some scenario where PCEP sessions are lost 508 between PCC and PCE. This inter-PCE PCEP session is called a state- 509 sync session. 511 For example, in the scenario below, there is no possibility to 512 compute disjointness as there is no PCE aware of both LSPs. 514 +----------+ 515 | PCC1 | LSP: PCC1->PCC2 516 +----------+ 517 / 518 D=1 / 519 +---------+ +---------+ 520 | PCE1 | | PCE2 | 521 +---------+ +---------+ 522 / D=1 523 / 524 +----------+ 525 | PCC3 | LSP: PCC3->PCC4 526 +----------+ 528 If we add a state-sync session, PCE1 will be able to send PCRpt 529 messages for its LSP to PCE2 and PCE2 will do the same. All the PCEs 530 will be aware of all LSPs even if PCC->PCE session are down. PCEs 531 will then be able to compute disjoint paths. 533 +----------+ 534 | PCC1 | LSP : PCC1->PCC2 535 +----------+ 536 / 537 D=1 / 538 +---------+ PCEP +---------+ 539 | PCE1 | ----- | PCE2 | 540 +---------+ +---------+ 541 / D=1 542 / 543 +----------+ 544 | PCC3 | LSP : PCC3->PCC4 545 +----------+ 547 The procedures associated with this state-sync session are defined in 548 Section 3. 550 Adding this state-sync session does not ensure that a path with LSP 551 association based constraints can always be computed and does not 552 prevent computation loop, but it increases resiliency and ensures 553 that PCEs will have the state information for all LSPs. In addition, 554 this session will allow for a PCE to update the other PCEs providing 555 a faster synchronization mechanism than relying on PCCs only. 557 2.2. Master/Slave relationship between PCE 559 As seen in Section 1, performing a path computation in a split-brain 560 scenario (multiple PCEs responsible for computation) may provide a 561 non optimal LSP placement, no path or computation loops. To provide 562 the best efficiency, an LSP association constraint based computation 563 requires that a single PCE performs the path computation for all LSPs 564 in the association group. Note that, it could be all LSPs belonging 565 to a particular association group, or all LSPs from a particular PCC, 566 or all LSPs in the network that need to be delegated to a single PCE 567 based on the deployment scenarios. 569 We propose to add a priority mechanism between PCEs to elect a single 570 computing PCE. Using this priority mechanism, PCEs can agree on the 571 PCE that will be responsible for the computation for a particular 572 association group, or set of LSPs. The priority could be set per 573 association, per PCC, or for all LSPs. How this priority is set or 574 advertised is out of scope of this document. The rest of the text 575 consider association group as an example. 577 When a single PCE is performing the computation for a particular 578 association group, no computation loop can happen and an optimal 579 placement will be provided. The other PCEs will only act as state 580 collectors and forwarders. 582 In the scenario described in Section 2.1, PCE1 and PCE2 will decide 583 that PCE1 will be responsible for the path computation of both LSPs. 584 If we first configure PCC1->PCC2, PCE1 computes shortest path at it 585 is the only LSP in the disjoint-group that it is aware of: 586 R1->R3->R4->R2->PCC2 (shortest path). When PCC3->PCC4 is configured, 587 PCE2 will not perform computation even if it has delegation but 588 forwards the PCRpt to PCE1 through the state-sync session. PCE1 will 589 then perform disjointness computation and will move PCC1->PCC2 onto 590 R1->R2->PCC2 and provides an ERO to PCE2 for PCC3->PCC4: 591 R3->R4->PCC4. 593 3. Procedures and protocol extensions 595 3.1. Opening a state-sync session 597 3.1.1. Capability advertisement 599 A PCE indicates its support of state-sync procedures during the PCEP 600 Initialization phase. The OPEN object in the Open message MUST 601 contains the "Stateful PCE Capability" TLV defined in [RFC8231]. A 602 new P (INTER-PCE-CAPABILITY) flag is introduced to indicate the 603 support of state-sync. 605 This document adds a new bit in the Flags field with : 607 P (INTER-PCE-CAPABILITY - 1 bit): If set to 1 by a PCEP Speaker, 608 the PCEP speaker indicates that the session MUST follow the state- 609 sync procedures as described in this document. The P bit MUST be 610 set by both speakers: if a PCEP Speaker receives a STATEFUL-PCE- 611 CAPABILITY TLV with P=0 while it advertised P=1 or if both set P 612 flag to 0, the session SHOULD be setup but the state-sync 613 procedures MUST NOT be applied on this session. 615 The U flag [RFC8231] MUST be set when sending the STATEFUL-PCE- 616 CAPABILITY TLV with the P flag set. S flag MAY be set if optimized 617 synchronization is required as per [RFC8232]. 619 3.2. State synchronization 621 When the INTER-PCE-CAPABILITY has been negotiated, each PCEP speaker 622 will behave as a PCE and as a PCC at the same time regarding the 623 state synchronization as defined in [RFC8231]. This means that each 624 PCEP Speaker: 626 o MUST send a PCRpt message towards its neighbor with S flag set for 627 each LSP in its LSP database learned from a PCC. (PCC role) 629 o MUST send the End Of Synchronization Marker towards its neighbor 630 when all LSPs have been reported. (PCC role) 632 o MUST wait for the LSP synchronization from its neighbor to end 633 (receiving an End Of Synchronization Marker). (PCE role) 635 The process of synchronization runs in parallel on each PCE (no 636 defined order). 638 Optimized synchronization MAY be used as defined in [RFC8232]. 640 When a PCEP Speaker sends a PCRpt on a state-sync session, it MUST 641 add the SPEAKER-IDENTITY-TLV (defined in [RFC8232]) in the LSP 642 Object, the value used will refer to the 'owner' PCC of the LSP. If 643 a PCEP Speaker receives a PCRpt on a state-sync session without this 644 TLV, it MUST discard the PCRpt message and it MUST reply with a PCErr 645 message using error-type=6 (Mandatory Object missing) and error- 646 value=TBD1 (SPEAKER-IDENTITY-TLV missing). 648 3.3. Incremental updates and report forwarding rules 650 During the life of an LSP, its state may change (path, constraints, 651 operational state...) and a PCC will advertise a new PCRpt to the PCE 652 for each such change. 654 When propagating LSP state changes from a PCE to other PCEs, it is 655 mandatory to ensure that a PCE always uses the freshest state coming 656 from the PCC. 658 When a PCE receives a new PCRpt from a PCC with the LSP-DB-VERSION, 659 the PCE MUST forward the PCRpt to all its state-sync sessions and 660 MUST add the appropriate SPEAKER-IDENTITY-TLV in the PCRpt. In 661 addition, it MUST add a new ORIGINAL-LSP-DB-VERSION TLV (described 662 below). The ORIGINAL-LSP-DB-VERSION contains the LSP-DB-VERSION 663 coming from the PCC. 665 When a PCE receives a new PCRpt from a PCC without the LSP-DB- 666 VERSION, it SHOULD NOT forward the PCRpt on any state-sync sessions. 668 When a PCE receives a new PCRpt from a PCC with the R flag set and a 669 LSP-DB-VERSION TLV, the PCE MUST forward the PCRpt to all its state- 670 sync sessions keeping the R flag set (Remove) and MUST add the 671 appropriate SPEAKER-IDENTITY-TLV and ORIGINAL-LSP-DB-VERSION TLV in 672 the PCRpt. 674 When a PCE receives a PCRpt from a state-sync session, it MUST NOT 675 forward the PCRpt to other state-sync sessions. This helps to 676 prevent message loops between PCEs. As a consequence, a full mesh of 677 PCEP sessions between PCEs is required. 679 When a PCRpt is forwarded, all the original objects and values are 680 kept. As an example, the PLSP-ID used in the forwarded PCRpt will be 681 the same as the original one used by the PCC. Thus an implementation 682 supporting this document MUST consider SPEAKER-IDENTITY-TLV and PLSP- 683 ID together to uniquely identify an LSP on the state-sync session. 685 The ORIGINAL-LSP-DB-VERSION TLV is encoded as follows and SHOULD 686 always contain the LSP-DB-VERSION received from the owner PCC of the 687 LSP: 689 0 1 2 3 690 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 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 | Type=TBD2 | Length=8 | 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 | LSP State DB Version Number | 695 | | 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 Using the ORIGINAL-LSP-DB-VERSION TLV allows a PCE to keep using 699 optimized synchronization ([RFC8232]) with another PCE. In such a 700 case, the PCE will send a PCRpt to another PCE with both ORIGINAL- 701 LSP-DB-VERSION TLV and LSP-DB-VERSION TLV. The ORIGINAL-LSP-DB- 702 VERSION TLV will contain the version number as allocated by the PCC 703 while the LSP-DB-VERSION will contain the version number allocated by 704 the local PCE. 706 3.4. Maintaining LSP states from different sources 708 When a PCE receives a PCRpt on a state-sync session, it stores the 709 LSP information into the original PCC address context (as the LSP 710 belongs to the PCC). A PCE SHOULD maintain a single state for a 711 particular LSP and SHOULD maintain the list of sources it learned a 712 particular state from. 714 A PCEP speaker may receive a state information for a particular LSP 715 from different sources: the PCC that owns the LSP (through a regular 716 PCEP session) and some PCEs (through PCEP state-sync sessions). A 717 PCEP speaker MUST always keep the freshest state in its LSP database, 718 overriding the previously received information. 720 A PCE, receiving a PCRpt from a PCC, updates the state of the LSP in 721 its LSPDB with the new received information. When receiving a PCRpt 722 from another PCE, a PCE SHOULD update the LSP state only if the 723 ORIGINAL-LSP-DB-VERSION present in the PCRpt is greater than the 724 current ORIGINAL-LSP-DB-VERSION of the stored LSP state. This 725 ensures that a PCE never tries to update its stored LSP state with an 726 old information. Each time a PCE updates an LSP state in its LSPDB, 727 it SHOULD reset the source list associated with the LSP state and 728 SHOULD add the source speaker address in the source list. When a PCE 729 receives a PCRpt which has an ORIGINAL-LSP-DB-VERSION (if coming from 730 a PCE) or an LSP-DB-VERSION (if coming from the PCC) equals to the 731 current ORIGINAL-LSP-DB-VERSION of the stored LSP state, it SHOULD 732 add the source speaker address in the source list. 734 When a PCE receives a PCRpt requesting an LSP deletion from a 735 particular source, it SHOULD remove this particular source from the 736 list of sources associated with this LSP. 738 When the list of sources becomes empty for a particular LSP, the LSP 739 state MUST be removed. This means that all the sources must send a 740 PCRpt with R=1 for an LSP to make the PCE remove the LSP state. 742 3.5. Computation priority between PCEs and sub-delegation 744 A computation priority is necessary to ensure that a single PCE will 745 perform the computation for all the LSPs in an association group: 746 this will allow for a more optimized LSP placement and will prevent 747 computation loops. 749 All PCEs in the network that are handling LSPs in a common LSP 750 association group SHOULD be aware of each other including the 751 computation priority of each PCE. Note that there is no need for PCC 752 to be aware of this. The computation priority is a number and the 753 PCE having the highest priority SHOULD be responsible for the 754 computation. If several PCEs have the same priority value, their IP 755 address SHOULD be used as a tie-breaker to provide a rank: the 756 highest IP address has more priority. How PCEs are aware of the 757 priority of each other is out of scope of this document, but as 758 example learning priorities could be done through IGP informations or 759 local configuration. 761 The definition of the priority MAY be global so the highest priority 762 PCE will handle all path computations or more granular, so a PCE may 763 have highest priority for only a subset of LSPs or association- 764 groups. 766 A PCEP Speaker receiving a PCRpt from a PCC with D flag set that does 767 not have the highest computation priority, SHOULD forward the PCRpt 768 on all state-sync sessions (as per Section 3.3) and SHOULD set D flag 769 on the state-sync session towards the highest priority PCE, D flag 770 will be unset to all other state-sync sessions. This behavior is 771 similar to the delegation behavior handled at PCC side and is called 772 a sub-delegation (the PCE sub-delegates the control of the LSP to 773 another PCE). When a PCEP Speaker sub-delegates a LSP to another 774 PCE, it looses the control on the LSP and cannot update it anymore by 775 its own decision. When a PCE receives a PCRpt with D flag set on a 776 state-sync session, as a regular PCE, it becomes granted to update 777 the LSP. 779 If the highest priority PCE is failing or if the state-sync session 780 between the local PCE and the highest priority PCE failed, the local 781 PCE MAY decide to delegate the LSP to the next highest priority PCE 782 or to take back control on the LSP. It is a local policy decision. 784 When a PCE has the delegation for an LSP and needs to update this 785 LSP, it MUST send a PCUpda message to all state-sync sessions and to 786 the PCC session on which it received the delegation. The D-Flag 787 would be unset in the PCUpd for state-sync sessions where as D-Flag 788 would be set for the PCC. In case of sub-delegation, the computing 789 PCE will send the PCUpd only to all state-sync sessions (as it has no 790 direct delegation from a PCC). The D-Flag would be set for the 791 state-sync session to the PCE that sub-delegated this LSP and the 792 D-Flag would be unset for other state-sync sessions. 794 The PCUpd sent over a state-sync session MUST contain the SPEAKER- 795 IDENTITY-TLV in the LSP Object (the value used must identify the 796 target PCC). The PLSP-ID used is the original PLSP-ID generated by 797 the PCC and learned from the forwarded PCRpt. If a PCE receives a 798 PCUpd on a state-sync session without the SPEAKER-IDENTITY-TLV, it 799 MUST discard the PCUpd and MUST reply with a PCErr message using 800 error-type=6 (Mandatory Object missing) and error-value=TBD1 801 (SPEAKER-IDENTITY-TLV missing). 803 When a PCE receives a valid PCUpd on a state-sync session, it SHOULD 804 forward the PCUpd to the appropriate PCC (identified based on the 805 SPEAKER-IDENTITY-TLV value) that delegated the LSP originally and 806 SHOULD remove the SPEAKER-IDENTITY-TLV from the LSP Object. The 807 acknowledgment of the PCUpd is done through a cascaded mechanism, and 808 the PCC is the only responsible of triggering the acknowledgment: 809 when the PCC receives the PCUpd from the local PCE, it acknowledges 810 it with a PCRpt as per [RFC8231]. When receiving the new PCRpt from 811 the PCC, the local PCE uses the defined forwarding rules on the 812 state-sync session so the acknowledgment is relayed to the computing 813 PCE. 815 A PCE SHOULD NOT compute a path using an association-group constraint 816 if it has delegation for only a subset of LSPs in the group. In this 817 case, an implementation MAY use a local policy on PCE to decide if 818 PCE does not compute path at all for this set of LSP or if it can 819 compute a path by relaxing the association-group constraint. 821 3.6. Passive stateful procedures 823 In the passive stateful PCE architecture, the PCC is responsible of 824 triggering a path computation request using a PCReq message to its 825 PCE. Similarly to PCRpt Message, which remains unchanged for passive 826 mode, if a PCE receives a PCReq for an LSP and if this PCE finds that 827 it does not have the highest computation priority of this LSP, or 828 groups..., it MUST forward the PCRequest to the highest priority PCE 829 over the state-sync session. When the highest priority PCE receives 830 the PCRequest, it computes the path and generates a PCReply only to 831 the PCE that is received the PCReq from. This PCE will then forward 832 the PCRep to the requesting PCC. The handling of LSP object and the 833 SPEAKER-IDENTITY-TLV in PCRequ and PCRep is similar to PCRpt/PCUpd. 835 3.7. PCE initiation procedures 837 TBD 839 4. Examples 840 4.1. Example 1 842 _________________________________________ 843 / \ 844 / +------+ +------+ \ 845 | | PCE1 | | PCE2 | | 846 | +------+ +------+ | 847 | | 848 | +------+ 10 +------+ | 849 | | PCC1 | ----- R1 ---- R2 ------- | PCC2 | | 850 | +------+ | | +------+ | 851 | | | | 852 | | | | 853 | +------+ | | +------+ | 854 | | PCC3 | ----- R3 ---- R4 ------- | PCC4 | | 855 | +------+ +------+ | 856 | | 857 \ / 858 \_________________________________________/ 860 +----------+ 861 | PCC1 | LSP : PCC1->PCC2 862 +----------+ 863 / 864 D=1 / 865 +---------+ +---------+ 866 | PCE1 |----| PCE2 | 867 +---------+ +---------+ 868 / D=1 869 / 870 +----------+ 871 | PCC3 | LSP : PCC3->PCC4 872 +----------+ 874 PCE1 computation priority 100 875 PCE2 computation priority 200 877 With this PCEP session topology where computation priority is global 878 for all LSPs, we still want to have link disjoint LSPs PCC1->PCC2 and 879 PCC3->PCC4. 881 We first configure PCC1->PCC2, PCC1 delegates the LSP to PCE1, but as 882 PCE1 does not have the highest computation priority, it will sub- 883 delegate the LSP to PCE2 by sending a PCRpt with D=1 and including 884 the SPEAKER-IDENTITY-TLV over the state-sync session. PCE2 receives 885 the PCRpt and as it has delegation for this LSP, it computes the 886 shortest path: R1->R3->R4->R2->PCC2. It then sends a PCUpd to PCE1 887 (including the SPEAKER-IDENTITY-TLV) with the computed ERO. PCE1 888 forwards the PCUpd to PCC1 (removing the SPEAKER-IDENTITY-TLV). PCC1 889 acknowledges the PCUpd by a PCRpt to PCE1. PCE1 forwards the PCRpt 890 to PCE2. 892 When PCC3->PCC4 is configured, PCC3 delegates the LSP to PCE2, PCE2 893 can compute a disjoint path as it has knowledge of both LSPs and has 894 delegation also for both. The only solution found is to move 895 PCC1->PCC2 LSP on another path, PCE2 can move PCC3->PCC4 as it has 896 delegation for it. It creates a new PCUpd with new ERO: R1->R2-PCC2 897 towards PCE1 which forwards to PCC1. PCE2 sends a PCUpd to PCC3 with 898 the path: R3->R4->PCC4. 900 In this setup, PCEs are able to find a disjoint path while without 901 state-sync and computation priority they could not. 903 4.2. Example 2 904 _____________________________________ 905 / \ 906 / +------+ +------+ \ 907 | | PCE1 | | PCE2 | | 908 | +------+ +------+ | 909 | | 910 | +------+ 100 +------+ | 911 | | | -------------------- | | | 912 | | PCC1 | ----- R1 ----------- | PCC2 | | 913 | +------+ | +------+ | 914 | | | | | 915 | 6 | | 2 | 2 | 916 | | | | | 917 | +------+ | +------+ | 918 | | PCC3 | ----- R3 ----------- | PCC4 | | 919 | +------+ 10 +------+ | 920 | | 921 \ / 922 \_____________________________________/ 924 +----------+ 925 | PCC1 | LSP : PCC1->PCC2 926 +----------+ 927 / \ 928 D=1 / \ D=0 929 +---------+ +---------+ 930 | PCE1 |----| PCE2 | 931 +---------+ +---------+ 932 D=0 \ / D=1 933 \ / 934 +----------+ 935 | PCC3 | LSP : PCC3->PCC4 936 +----------+ 938 PCE1 computation priority 200 939 PCE2 computation priority 100 941 In this example, we configure both LSPs almost at the same time. 942 PCE1 sub-delegates PCC1->PCC2 to PCE2 while PCE2 keeps delegation for 943 PCC3->PCC4, PCE2 computes a path for PCC1->PCC2 and PCC3->PCC4 and 944 can achieve disjointness computation easily. No computation loop 945 happens in this case. 947 4.3. Example 3 949 _________________________________________ 950 / \ 951 / +------+ +------+ \ 952 | | PCE1 | | PCE2 | | 953 | +------+ +------+ | 954 | | 955 | +------+ 10 +------+ | 956 | | PCC1 | ----- R1 ---- R2 ------- | PCC2 | | 957 | +------+ | | +------+ | 958 | | | | 959 | | | | 960 | +------+ | | +------+ | 961 | | PCC3 | ----- R3 ---- R4 ------- | PCC4 | | 962 | +------+ +------+ | 963 | | 964 \ / 965 \_________________________________________/ 967 +----------+ 968 | PCC1 | LSP : PCC1->PCC2 969 +----------+ 970 / 971 D=1 / 972 +---------+ +---------+ +---------+ 973 | PCE1 |----| PCE2 |----| PCE3 | 974 +---------+ +---------+ +---------+ 975 / D=1 976 / 977 +----------+ 978 | PCC3 | LSP : PCC3->PCC4 979 +----------+ 981 PCE1 computation priority 100 982 PCE2 computation priority 200 983 PCE2 computation priority 300 985 With this PCEP session topology, we still want to have link disjoint 986 LSPs PCC1->PCC2 and PCC3->PCC4. 988 We first configure PCC1->PCC2, PCC1 delegates the LSP to PCE1, but as 989 PCE1 does not have the highest computation priority, it will sub- 990 delegate the LSP to PCE2 (as it cannot reach PCE3 through a state- 991 sync session). PCE2 cannot compute a path for PCC1->PCC2 as it does 992 not have the highest priority and cannot sub-delegate the LSP again 993 towards PCE3. 995 When PCC3->PCC4 is configured, PCC3 delegates the LSP to PCE2 that 996 performs sub-delegation to PCE3. As PCE3 will have knowledge of only 997 one LSP in the group, it cannot compute disjointness and can decide 998 to fallback to a less constrained computation to provide a path for 999 PCC3->PCC4. In this case, it will send a PCUpd to PCE2 that will be 1000 forwarded to PCC3. 1002 Disjointness cannot be achieved in this scenario because of lack of 1003 state-sync session between PCE1 and PCE3, but no computation loop 1004 happens. Thus it is advised for all PCEs that support state-sync to 1005 have a full mesh sessions between each other. 1007 5. Using Master/Slave computation and state-sync sessions to increase 1008 scaling 1010 The Primary/Backup computation and state-sync sessions architecture 1011 can be used to increase the scaling of the PCE architecture. If the 1012 number of PCCs is really high, it may be too resource consuming for a 1013 single PCE to maintain all the PCEP sessions while at the same time 1014 performing all path computations. Using master/slave computation and 1015 state-sync sessions may allow to create groups of PCEs that manage a 1016 subset of the PCCs and perform some or no path computations. 1017 Decoupling PCEP session maintenance and computation will allow to 1018 increase scaling of the PCE architecture. 1020 +----------+ 1021 | PCC500 | 1022 +----------+-+ 1023 | PCC1 | 1024 +----------+ 1025 / \ 1026 / \ 1027 +---------+ +---------+ 1028 | PCE1 |---| PCE2 | 1029 +---------+ +---------+ 1030 | \ / | 1031 | \/ | 1032 | /\ | 1033 | / \ | 1034 +---------+ +---------+ 1035 | PCE3 |---| PCE4 | 1036 +---------+ +---------+ 1037 \ / 1038 \ / 1039 +----------+ 1040 | PCC501 | 1041 +----------+-+ 1042 | PCC1000 | 1043 +----------+ 1045 In the figure above, two groups of PCEs are created: PCE1/2 maintain 1046 PCEP sessions with PCC1 up to PCC500, while PCE3/4 maintain PCEP 1047 sessions with PCC501 up to PCC1000. A granular master/slave policy 1048 is setup as follows to loadshare computation between PCEs: 1050 o PCE1 has priority 200 for association ID 1 up to 300, association 1051 source 0.0.0.0. All other PCEs have a decreasing priority for 1052 those associations. 1054 o PCE3 has priority 200 for association ID 301 up to 500, 1055 association source 0.0.0.0. All other PCEs have a decreasing 1056 priority for those associations. 1058 If some PCCs delegate LSPs with association ID 1 up to 300 and 1059 association source 0.0.0.0, the receiving PCE (if not PCE1) will sub- 1060 delegate the LSPs to PCE1. PCE1 becomes responsible for the 1061 computation of these LSP associations while PCE3 is responsible for 1062 the computation of another set of associations. 1064 6. PCEP-PATH-VECTOR-TLV 1066 This document allows PCEP messages to be propagated among PCEP 1067 speaker. It may be useful to track informations about the 1068 propagation of the messages. One of the use case is a message loop 1069 detection mechanism, but other use cases like hop by hop information 1070 recording may also be implemented. 1072 This document introduces the PCEP-PATH-VECTOR-TLV (type TBD2) with 1073 the following format: 1075 0 1 2 3 1076 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 1077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1078 | Type=TBD3 | Length (variable) | 1079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1080 | PCEP-SPEAKER-INFORMATION#1 | 1081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1082 | ... | 1083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1084 | PCEP-SPEAKER-INFORMATION#2 | 1085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1086 | ... | 1087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1089 The TLV format and padding rules are as per [RFC5440]. 1091 The PCEP-SPEAKER-INFORMATION field has the following format: 1093 0 1 2 3 1094 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 1095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1096 | Length (variable) | ID Length (variable) | 1097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1098 | Speaker Entity identity (variable) | 1099 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1100 | SubTLVs (optional) | 1101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1103 Length: defines the total length of the PCEP-SPEAKER-INFORMATION 1104 field. 1106 ID Length: defines the length of the Speaker identity actual field 1107 (non-padded). 1109 Speaker Entity identity: same possible values as the SPEAKER- 1110 IDENTIFIER-TLV. Padded with trailing zeroes to a 4-byte boundary. 1112 The PCEP-SPEAKER-INFORMATION may also carry some optional subTLVs 1113 so each PCEP speaker can add local informations that could be 1114 recorded. This document does not define any subTLV. 1116 The PCEP-PATH-VECTOR-TLV MAY be added in the LSP-Object. Its usage 1117 is purely optional. 1119 The list of speakers within the PCEP-PATH-VECTOR-TLV MUST be ordered. 1120 When sending a PCEP message (PCRpt, PCUpd or PCInitiate), a PCEP 1121 Speaker MAY add the PCEP-PATH-VECTOR-TLV with a PCEP-SPEAKER- 1122 INFORMATION containing its own informations. If the PCEP message 1123 sent is the result of a previously received PCEP message, and if the 1124 PCEP-PATH-VECTOR-TLV was already present in the initial message, the 1125 PCEP speaker MAY append a new PCEP-SPEAKER-INFORMATION containing its 1126 own informations. 1128 7. Security Considerations 1130 TBD. 1132 8. Acknowledgements 1134 TBD. 1136 9. IANA Considerations 1138 This document requests IANA actions to allocate code points for the 1139 protocol elements defined in this document. 1141 9.1. PCEP-Error Object 1143 IANA is requested to allocate a new Error Value for the Error Type 9. 1145 Error-Type Meaning Reference 1146 6 Mandatory Object Missing [RFC5440] 1147 Error-value=TBD1: SPEAKER-IDENTITY-TLV This document 1148 missing 1150 9.2. PCEP TLV Type Indicators 1152 IANA is requested to allocate new TLV Type Indicator values within 1153 the "PCEP TLV Type Indicators" sub-registry of the PCEP Numbers 1154 registry, as follows: 1156 Value Meaning Reference 1157 TBD2 ORIGINAL-LSP-DB-VERSION-TLV This document 1158 TBD3 PCEP-PATH-VECTOR-TLV This document 1160 9.3. STATEFUL-PCE-CAPABILITY TLV 1162 IANA is requested to allocate a new bit value in the STATEFUL-PCE- 1163 CAPABILITY TLV Flag Field sub-registry. 1165 Bit Description Reference 1166 TBD INTER-PCE-CAPABILITY This document 1168 10. References 1170 10.1. Normative References 1172 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1173 Requirement Levels", BCP 14, RFC 2119, 1174 DOI 10.17487/RFC2119, March 1997, 1175 . 1177 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1178 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1179 DOI 10.17487/RFC5440, March 2009, 1180 . 1182 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1183 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1184 May 2017, . 1186 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1187 Computation Element Communication Protocol (PCEP) 1188 Extensions for Stateful PCE", RFC 8231, 1189 DOI 10.17487/RFC8231, September 2017, 1190 . 1192 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 1193 and D. Dhody, "Optimizations of Label Switched Path State 1194 Synchronization Procedures for a Stateful PCE", RFC 8232, 1195 DOI 10.17487/RFC8232, September 2017, 1196 . 1198 10.2. Informative References 1200 [I-D.ietf-pce-association-diversity] 1201 Litkowski, S., Sivabalan, S., Barth, C., and M. Negi, 1202 "Path Computation Element communication Protocol (PCEP) 1203 extension for signaling LSP diversity constraint", draft- 1204 ietf-pce-association-diversity-06 (work in progress), 1205 February 2019. 1207 [I-D.ietf-pce-stateful-hpce] 1208 Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., King, D., 1209 and O. Dios, "Hierarchical Stateful Path Computation 1210 Element (PCE).", draft-ietf-pce-stateful-hpce-06 (work in 1211 progress), October 2018. 1213 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1214 Element (PCE)-Based Architecture", RFC 4655, 1215 DOI 10.17487/RFC4655, August 2006, 1216 . 1218 [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the 1219 Path Computation Element Architecture to the Determination 1220 of a Sequence of Domains in MPLS and GMPLS", RFC 6805, 1221 DOI 10.17487/RFC6805, November 2012, 1222 . 1224 [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path 1225 Computation Element Architecture", RFC 7399, 1226 DOI 10.17487/RFC7399, October 2014, 1227 . 1229 Appendix A. Contributors 1231 Dhruv Dhody 1232 Huawei Technologies 1233 Divyashree Techno Park, Whitefield 1234 Bangalore, Karnataka 560066 1235 India 1237 Email: dhruv.ietf@gmail.com 1239 Authors' Addresses 1241 Stephane Litkowski 1242 Orange 1244 Email: stephane.litkowski@orange.com 1246 Siva Sivabalan 1247 Cisco 1249 Email: msiva@cisco.com 1250 Cheng Li 1251 Huawei Technologies 1252 Huawei Campus, No. 156 Beiqing Rd. 1253 Beijing 100095 1254 China 1256 Email: chengli13@huawei.com 1258 Haomian Zheng 1259 Huawei Technologies 1260 H1-1-A043S Huawei Industrial Base, Songshanhu 1261 Dongguan, Guangdong 523808 1262 China 1264 Email: zhenghaomian@huawei.com