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