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