idnits 2.17.1 draft-dhody-pce-stateful-pce-lspdb-realtime-sync-01.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 (December 28, 2016) is 2675 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 (-21) exists of draft-ietf-pce-stateful-pce-18 == Outdated reference: A later version (-10) exists of draft-ietf-pce-stateful-sync-optimizations-07 == Outdated reference: A later version (-11) exists of draft-ietf-pce-pce-initiated-lsp-07 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group D. Dhody 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track December 28, 2016 5 Expires: July 1, 2017 7 Realtime Synchronization between Redundant Stateful PCEs. 8 draft-dhody-pce-stateful-pce-lspdb-realtime-sync-01 10 Abstract 12 The Path Computation Element Communication Protocol (PCEP) provides 13 mechanisms for Path Computation Elements (PCEs) to perform path 14 computations in response to Path Computation Clients (PCCs) requests. 16 The stateful PCE further extentds PCEP to enable stateful control of 17 MPLS-TE and GMPLS Label Switched Paths (LSPs) via PCEP and 18 maintaining of these LSPs at the stateful PCE. This document 19 describes the mechanisms of realtime LSP Database (LSP-DB) 20 synchronization between stateful PCEs. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on July 1, 2017. 39 Copyright Notice 41 Copyright (c) 2016 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Architectural Considerations . . . . . . . . . . . . . . . . 4 60 4. Functions to Support LSP-DB Synchronization . . . . . . . . . 4 61 5. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 5.1. Relatime LSP-DB Synchronization between redundant 63 Stateful PCEs . . . . . . . . . . . . . . . . . . . . . . 5 64 5.2. Other Considerations . . . . . . . . . . . . . . . . . . 8 65 6. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 8 66 6.1. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 8 67 6.2. The PCUpd Message . . . . . . . . . . . . . . . . . . . . 8 68 7. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 7.1. Stateful PCE Capability TLV . . . . . . . . . . . . . . . 8 70 7.2. Speaker Entity Identifier TLV . . . . . . . . . . . . . . 9 71 7.3. REALTIME-SYNC TLV . . . . . . . . . . . . . . . . . . . . 9 72 7.4. PCE-CAP-FLAGS sub-TLV . . . . . . . . . . . . . . . . . . 10 73 8. Other Considerations . . . . . . . . . . . . . . . . . . . . 10 74 8.1. PCE Initiated LSP . . . . . . . . . . . . . . . . . . . . 10 75 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 76 10. Manageability Considerations . . . . . . . . . . . . . . . . 10 77 10.1. Control of Function and Policy . . . . . . . . . . . . . 10 78 10.2. Information and Data Models . . . . . . . . . . . . . . 11 79 10.3. Liveness Detection and Monitoring . . . . . . . . . . . 11 80 10.4. Verify Correct Operations . . . . . . . . . . . . . . . 11 81 10.5. Requirements On Other Protocols . . . . . . . . . . . . 11 82 10.6. Impact On Network Operations . . . . . . . . . . . . . . 11 83 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 84 11.1. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . 11 85 11.2. PCE-CAP-FLAGS sub-TLV . . . . . . . . . . . . . . . . . 11 86 11.3. REALTIME-SYNC TLV . . . . . . . . . . . . . . . . . . . 12 87 11.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . 12 88 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 89 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 90 13.1. Normative References . . . . . . . . . . . . . . . . . . 12 91 13.2. Informative References . . . . . . . . . . . . . . . . . 13 92 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 14 93 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 95 1. Introduction 97 [RFC5440] describes the Path Computation Element Protocol (PCEP) as 98 the communication between a Path Computation Client (PCC) and a Path 99 Computation Element (PCE), or between PCEs, enabling computation of 100 Multiprotocol Label Switching (MPLS) for Traffic Engineering Label 101 Switched Paths (TE LSPs). 103 [I-D.ietf-pce-stateful-pce] specifies a set of extensions to PCEP to 104 enable stateful control of LSPs in compliance with [RFC4655]. It 105 includes mechanisms for LSP state synchronization between a PCC and a 106 PCE, i.e., all stateful PCEs synchronize their LSP states from the 107 network. It further describe the handling of redundant stateful 108 PCEs, where all PCEs receive the state from the network (PCCs). When 109 the primary PCE fails, another PCE can take over. 111 Apart from the synchronization from the network, it is also useful if 112 there is realtime synchronization mechanism between the stateful 113 PCEs. As stateful PCE make changes to its delegated LSPs, these 114 changes (pending LSPs and the sticky resources) can be synchronized 115 immediately to the other PCEs. Further PCE may also synchronize any 116 status change of its delegated LSPs to other PCEs. Note that some 117 synchronization issues are identified in [RFC7399]. 119 It should be noted that in some deployments the PCE function is part 120 of the central controller architecture with multiple instances of PCE 121 for load balancing and backup which uses proprietary mechanics to 122 maintain consistent state between these PCE instance. In such 123 deployment PCEP MAY not used as a database synchronization mechanism. 125 This document specifies the mechanisms of realtime LSP-DB 126 synchronization between redundant stateful PCEs via PCEP. 128 1.1. Requirements Language 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in [RFC2119]. 134 2. Terminology 136 The terminology is as per [RFC5440] and [I-D.ietf-pce-stateful-pce]. 138 LSP-DB: A database of LSPs that are active in the network as 139 maintained by a stateful PCE. 141 Sticky Resources: The temporarily assigned resources that are 142 allocated to a pending LSP and are provisionally blocked. 144 3. Architectural Considerations 146 Distributed computation model ([RFC4655]) refers to a domain or 147 network that may include multiple PCEs where computation of paths is 148 shared among the PCEs, this is further clarified in [RFC7399]. 150 When multiple stateful PCEs are operating in the network, they could 151 be either - 153 Primary or Backup PCE: A backup PCE exists to perform functions in 154 the network, only in the event of a failure of the primary PCE. 155 In this case, all LSPs to be delegated are under primary stateful 156 PCE control while other PCEs in the domain act as backup. 158 Load-Balanced 'Backup' PCE: Load-Balanced PCEs share the computation 159 load at all times, as well as act backup to each other. One PCE 160 MAY serve a set of PCCs as the primary computation server, and 161 only addresses requests from other PCCs in the event of the 162 failure of some other PCE. Delegated LSPs are thus distributed 163 among stateful PCEs. 165 In either case it is beneficial for the PCE to synchronize changes of 166 its delegated LSPs to the other PCEs in realtime. This should 167 include - 169 o Any update made by the PCE to its delegated LSP. 171 o Any status change learned from the network. 173 Note that the state synchronization as per 174 [I-D.ietf-pce-stateful-pce] and 175 [I-D.ietf-pce-stateful-sync-optimizations]remains unchanged. This 176 include initial state synchronization as well as LSP state reports. 177 The mechanism described in this document are in addition to those 178 already present in [I-D.ietf-pce-stateful-pce]. 180 4. Functions to Support LSP-DB Synchronization 182 [I-D.ietf-pce-stateful-pce] specifies new functions to support a 183 stateful PCE. It also specifies that a function can be initiated 184 either from a PCC towards a PCE (C-E) or from a PCE towards a PCC 185 (E-C). 187 o Capability negotiation (E-C,C-E) 189 o LSP state synchronization (C-E) 191 o LSP update request (E-C) 192 o LSP state report (C-E) 194 o LSP control delegation (C-E,E-C) 196 o Stateful PCE discovery 198 This document extends some of these functions to support realtime 199 LSP-DB synchronization. These are initiated from a PCE towards 200 another PCE (E-E). 202 Capability negotiation (E-E): both the PCEs must announce during 203 PCEP session establishment that they support PCEP Stateful PCE 204 extensions defined in [I-D.ietf-pce-stateful-pce]. It should also 205 declare whether it has realtime synchronization capability between 206 PCEs. This is done via Open message. 208 LSP state report (E-E): a PCE sends an LSP state report to a PCE 209 whenever the state of an delegated LSP changes. This is usually 210 triggered on receiving the state report from the PCC. This is 211 done via PCRpt message. 213 LSP update request (E-E): When a PCE requests modification of 214 attributes of a delegated LSP, this information should also be 215 sent to other PCEs. This is done via PCUpd message. This is 216 needed to synchronize the pending LSPs and sticky resources. 218 Stateful PCE discovery: PCE can advertise its realtime 219 synchronization capability between PCEs via IGP. 221 5. Operations 223 5.1. Relatime LSP-DB Synchronization between redundant Stateful PCEs 225 PCE (including redundant stateful PCEs) learn LSP state from the 226 PCCs. Apart from that, for each LSP delegated to a stateful PCE - 228 o When it sends an LSP Update (PCUpd message) to the PCC for the 229 delegated LSP, it also sends an LSP update to other stateful PCEs. 231 o When it receives an LSP report (LSRpt message) from the PCC for 232 the delegated LSP, it also sends an LSP report to other stateful 233 PCEs. 235 Thus a PCE may learn LSP state from both the PCC as well as the PCE 236 to which LSP is delegated. 238 In Figure 1, PCE1 is the primary stateful PCE and PCE2 is the backup 239 stateful PCE (all LSPs are delegated to PCE1). PCC1 and PCC2 240 synchronize the LSP-DB with PCE1 and PCE2 after session 241 initialization phase. 243 PCC1 and PCC2 delegates LSP1 and LSP2 to the primary PCE1. Whenever 244 there is an update in LSP, PCE1 sends a PCUpd message to 245 corresponding PCC and also to backup PCE2. This is LSP update 246 request as described in Section 4 and uses PCUpd message. This makes 247 sure that the pending LSP changes and sticky resources are backed up. 248 The PCC sends a PCRpt message to the primary PCE, indicating the 249 LSP's status, the primary PCE further synchronizes the state with 250 backup PCEs via PCRpt message. 252 +----+ +----+ +----+ +----+ 253 |PCC1| |PCC2| |PCE1| |PCE2| 254 +-+--+ +-+--+ +-+--+ +-+--+ 255 | | | | 256 |---- LSP SYNC ---+----------------->| | 257 | |---- LSP SYNC --->| | 258 | | | | 259 | |---- LSP SYNC ----+------------------>| 260 |---- LSP SYNC ---+------------------+------------------>| 261 | | | | 262 |-- PCRpt,lsp1,D -+----------------->| | 263 |<----------------+----PCUpd,lsp1 ---| | 264 | | |--- PCUpd,lsp1 --->| 265 |-- PCRpt,lsp1,up-+----------------->| | 266 |-- PCRpt,lsp1,up-+------------------+------------------>| 267 | | |----PCRpt,lsp1,up->| 268 | | | | 269 | |-- PCRpt,lsp2,D ->| | 270 | |<---PCUpd,lsp2 ---| | 271 | | |--- PCUpd,lsp2---->| 272 | |-- PCRpt,lsp2,up->| | 273 | |-- PCRpt,lsp2,up--+------------------>| 274 | | |----PCRpt,lsp2,up->| 275 | | | | 277 Figure 1: Relatime LSP-DB synchronization between primary and backup 278 stateful PCEs 280 The backup PCE is used only in case the primary PCE fails. At the 281 time of failure of primary PCE (PCE1), the backup PCE (PCE2) act as a 282 primary. 284 In Figure 2, PCE1 and PCE2 are load-balanced stateful PCEs and share 285 the computation load as well as act as backup to each other. PCC1 286 and PCC2 synchronize their LSP-DB with both PCEs after session 287 initialization phase as per [I-D.ietf-pce-stateful-pce]. 289 PCC1 delegates LSP1 to PCE1. Whenever there is an update in LSP1, 290 PCE1 sends the PCUpd message to PCC1 and other stateful PCEs (PCE2). 291 Similarly, PCC2 delegates LSP2 to PCE2. Whenever there is an update 292 in LSP2, PCE2 sends the PCUpd message to PCC2 and other stateful PCEs 293 (PCE1). This is LSP update request as described in Section 4 and it 294 makes sure that the pending LSP changes and sticky resources are 295 synchronized. The PCC sends an PCRpt message to the all load- 296 balanced PCEs as per [I-D.ietf-pce-stateful-pce], indicating the 297 LSP's status. The PCE to which LSP is delegated, also sends report 298 message to other PCEs. 300 +----+ +----+ +----+ +----+ 301 |PCC1| |PCC2| |PCE1| |PCE2| 302 +-+--+ +-+--+ +-+--+ +-+--+ 303 | | | | 304 |---- LSP SYNC ---+----------------->| | 305 |---- LSP SYNC ---+------------------+------------------>| 306 | |---- LSP SYNC --->| | 307 | |---- LSP SYNC ----+------------------>| 308 | | | | 309 |-- PCRpt,lsp1,D -+----------------->| | 310 | |-- PCRpt,lsp2,D --+------------------>| 311 | | | | 312 | | | | 313 |<----------------+----PCUpd, lsp1---| | 314 | | |--- PCUpd, lsp1--->| 315 |-- PCRpt,lsp1,up-+----------------->| | 316 |-- PCRpt,lsp1,up-+------------------+------------------>| 317 | | |----PCRpt,lsp1,up->| 318 | | | | 319 | | | | 321 | |<---PCUpd, lsp2---|-------------------| 322 | | |<--- PCUpd, lsp2 --| 323 | |-- PCRpt,lsp2,up--+------------------>| 324 | | |<---PCRpt,lsp1,up--| 325 | |-- PCRpt,lsp2,up->| | 326 | | | | 328 Figure 2: Relatime LSP-DB synchronization between load-balanced 329 stateful PCEs 331 At the time of failure of one of the PCEs (say PCE1), the other PCE 332 (PCE2) may take up the load. 334 5.2. Other Considerations 336 o The computation mechanism and how PCE chooses to handle the sticky 337 resources during computation is out of scope of this document. 339 o This document does not tackle the issue about TED synchronization 340 which is described in detail in [RFC7399]. 342 6. PCEP Messages 344 [Editor's Note: There are ongoing discussions to come up with a 345 singular extention for inter-stateful-PCE communications. This 346 section will be updated based on the outcome of the discussion.] 348 6.1. The PCRpt Message 350 The format of PCRpt message is defined in 351 [I-D.ietf-pce-stateful-pce]. It specifies the PCRpt message is sent 352 from PCC to PCE in reporting the LSP state. This document extends 353 the usage of PCRpt message between redundant stateful PCEs for 354 realtime LSP synchronization as described in Section 5.1. A unique 355 PLSP-ID needs to be generated at the PCE and should also carry the 356 PCC generated PLSP-ID along in a REALTIME-SYNC TLV in the LSP object. 358 6.2. The PCUpd Message 360 The format of PCUpd Message is defined in 361 [I-D.ietf-pce-stateful-pce]. It specifies the PCUpd message is sent 362 from PCE to PCC to request changes in LSP attributes. This document 363 extends the usage of PCUpd message between stateful PCEs for realtime 364 LSP synchronization as described in Section 5.1. Whenever there is a 365 PCUpd message sent from PCE to PCC, PCE should also send it to other 366 PCEs along with the PCC generated PLSP-ID in a REALTIME-SYNC TLV in 367 the LSP object. 369 7. TLVs 371 7.1. Stateful PCE Capability TLV 373 As per [I-D.ietf-pce-stateful-pce], STATEFUL-PCE-CAPABILITY TLV can 374 be used in the OPEN object for stateful PCE capability negotiation. 375 A stateful PCE must announce during PCEP session establishment that 376 they support PCEP stateful PCE extensions defined in 377 [I-D.ietf-pce-stateful-pce]. A new flag is added - 379 R (REALTIME-SYNC-PCE - 1 bit): if set to 1 by PCE, the PCE has the 380 capability for realtime synchronization between PCEs. In case of 381 PCC, this bit has no meaning and is simply ignored. 383 7.2. Speaker Entity Identifier TLV 385 [I-D.ietf-pce-stateful-sync-optimizations] describes 'Speaker Entity 386 Identifier TLV' to be included in OPEN object. This document uses 387 the same TLV in the LSP object for realtime sync between redundant 388 stateful PCEs. 390 For a PCE that supports realtime sync (REALTIME-SYNC-PCE R flag in 391 Stateful PCE Capability TLV), the PCC MUST include 'Speaker Entity 392 Identifier TLV' in the OPEN message. Note a PCC may have to bring 393 down the current session and include the TLV in the subsequent open 394 message. 396 Any realtime state synchronization (PCRpt or PCUpd message between 397 PCEs) MUST include 'Speaker Entity Identifier TLV' in LSP object with 398 the PCC's speaker identity. If the TLV is missing, the PCE will 399 generate an error with error-type 6 (mandatory object missing) and 400 error-value TBD1 (Speaker Entity Identifier TLV missing) and close 401 the session. 403 The format of Speaker Entity Identifier is defined in 404 [I-D.ietf-pce-stateful-sync-optimizations]. 406 7.3. REALTIME-SYNC TLV 408 PCC uses the PLSP-ID in LSP object to uniquely identify an LSP. For 409 PCE to PCE realtime sync, another unique PLSP-ID needs to be 410 generated at the PCE and should also carry the PCC's generated PLSP- 411 ID in the REALTIME-SYNC TLV. This way redundant PCE can correlate 412 the LSP from the state received from the PCCs. 414 This TLV MUST be encoded in the PCRpt and PCUpd message between 415 redundant stateful PCEs. If the TLV is missing, the PCE will 416 generate an error with error-type 6 (mandatory object missing) and 417 error-value TBD2 (REALTIME-SYNC TLV missing) and close the session. 419 The format of the REALTIME-SYNC TLV is shown in the following figure: 421 0 1 2 3 422 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 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | Type=TBD3 | Length=4 | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | PCC's PLSP-ID | reserved | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 Figure 3: REALTIME-SYNC TLV format 431 The type of the TLV is to be assigned by IANA and it has a fixed 432 length of 4 octets. The value contains the following fields: 434 PCC's PLSP-ID (20 bits): The PCC's original PLSP-ID as received in 435 the PCRpt message from the PCC. This along with Speaker Entity 436 Identifier TLV can be used to co-relate information received from 437 the network (PCCs). 439 7.4. PCE-CAP-FLAGS sub-TLV 441 [RFC5088] and [RFC5089] describe the mechanism to advertise the PCE 442 Discovery information via OSPF and IS-IS respectively along with 443 processing rules for the sub-TLVs. [I-D.ietf-pce-stateful-pce] 444 further enhances the optional PCE-CAP-FLAGS sub-TLV used to advertise 445 PCE stateful capabilities. 447 Further a new bit is added - 449 Bit Capabilities 451 TBD4 Realtime Sync between PCEs 453 If this bit is set to 1, the PCE has the capability for realtime 454 synchronization between PCEs. 456 8. Other Considerations 458 8.1. PCE Initiated LSP 460 [I-D.ietf-pce-pce-initiated-lsp] describes the setup and teardown of 461 PCE-initiated LSPs under the active stateful PCE model. As the PCE 462 sends PCInitiate message to PCC to create or delete LSP, the PCE 463 should also send PCUpd message to other PCEs. For the initiation, 464 the PCUpd message should have PCC's PLSP-ID as zero. The rest of the 465 processing remains unchanged. 467 9. Security Considerations 469 This document does not introduce any new security concerns besides 470 those in [I-D.ietf-pce-stateful-pce]. 472 10. Manageability Considerations 474 10.1. Control of Function and Policy 476 A PCE may be deployed to act only as a backup (Section 5.1), an 477 operator SHOULD be able to configure a PCE as backup. 479 10.2. Information and Data Models 481 [RFC7420] describes the PCEP MIB, there are no new MIB Objects for 482 this document. 484 10.3. Liveness Detection and Monitoring 486 Mechanisms defined in this document do not imply any new liveness 487 detection and monitoring requirements in addition to those already 488 listed in [RFC5440]. 490 10.4. Verify Correct Operations 492 Mechanisms defined in this document do not imply any new operation 493 verification requirements in addition to those already listed in 494 [RFC5440]. 496 10.5. Requirements On Other Protocols 498 Mechanisms defined in this document do not imply any new requirements 499 on other protocols. 501 10.6. Impact On Network Operations 503 Mechanisms defined in this document do not have any impact on network 504 operations in addition to those already listed in [RFC5440]. 506 11. IANA Considerations 508 11.1. STATEFUL-PCE-CAPABILITY TLV 510 As discussed in Section 7.1, a new STATEFUL-PCE-CAPABILITY TLV Flag 511 Field has been defined. IANA has made the following allocation from 512 the PCEP "STATEFUL-PCE-CAPABILITY TLV Flag Field" sub-registry: 514 Bit Description Reference 516 TBD REALTIME-SYNC-PCE [This I.D.] 518 11.2. PCE-CAP-FLAGS sub-TLV 520 As discussed in Section 7.1, a new bit is added, IANA is requested to 521 allocate a new bit in "PCE Capability Flags" registry for backup 522 stateful PCE capability as follows: 524 Bit Description Reference 526 TBD4 Realtime Sync between PCEs [This I.D.] 528 11.3. REALTIME-SYNC TLV 530 This document defines the following new PCEP TLV: 532 Value Meaning Reference 533 TBD3 REALTIME-SYNC TLV This document 535 11.4. PCEP-Error Object 537 IANA is requested to make the following allocation in the "PCEP-ERROR 538 Object Error Types and Values" registry. 540 Error-Type Meaning Reference 541 6 Mandatory Object missing [RFC5440] 542 Error-Value= TBD2 This document 543 Speaker Entity Identifier TLV 544 missing 545 Error-Value= TBD3 This document 546 REALTIME-SYNC TLV missing 548 12. Acknowledgments 550 Thanks to Adrian Farrel and Daniel King for writing [RFC7399]. 552 We would like to thank Avantika Kumar for her useful comments and 553 suggestions. 555 13. References 557 13.1. Normative References 559 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 560 Requirement Levels", BCP 14, RFC 2119, 561 DOI 10.17487/RFC2119, March 1997, 562 . 564 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 565 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 566 DOI 10.17487/RFC5440, March 2009, 567 . 569 [I-D.ietf-pce-stateful-pce] 570 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 571 Extensions for Stateful PCE", draft-ietf-pce-stateful- 572 pce-18 (work in progress), December 2016. 574 [I-D.ietf-pce-stateful-sync-optimizations] 575 Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 576 and D. Dhody, "Optimizations of Label Switched Path State 577 Synchronization Procedures for a Stateful PCE", draft- 578 ietf-pce-stateful-sync-optimizations-07 (work in 579 progress), December 2016. 581 13.2. Informative References 583 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 584 Element (PCE)-Based Architecture", RFC 4655, 585 DOI 10.17487/RFC4655, August 2006, 586 . 588 [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 589 Zhang, "OSPF Protocol Extensions for Path Computation 590 Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088, 591 January 2008, . 593 [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 594 Zhang, "IS-IS Protocol Extensions for Path Computation 595 Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089, 596 January 2008, . 598 [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path 599 Computation Element Architecture", RFC 7399, 600 DOI 10.17487/RFC7399, October 2014, 601 . 603 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 604 Hardwick, "Path Computation Element Communication Protocol 605 (PCEP) Management Information Base (MIB) Module", 606 RFC 7420, DOI 10.17487/RFC7420, December 2014, 607 . 609 [I-D.ietf-pce-pce-initiated-lsp] 610 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 611 Extensions for PCE-initiated LSP Setup in a Stateful PCE 612 Model", draft-ietf-pce-pce-initiated-lsp-07 (work in 613 progress), July 2016. 615 Appendix A. Contributor Addresses 617 Udayasree Palle 618 Huawei Technologies 619 Divyasree Techno Park, Whitefield 620 Bangalore, Karnataka 560066 621 India 623 EMail: udayasree.palle@huawei.com 625 Xian Zhang 626 Huawei Technologies 627 Bantian, Longgang District 628 Shenzhen 518129 629 P.R.China 631 EMail: zhang.xian@huawei.com 633 Venugopal Reddy Kondreddy 634 Huawei Technologies 635 Divyashree Techno Park, Whitefield 636 Bangalore, Karnataka 560066 637 India 639 EMail: venugopalreddyk@huawei.com 641 Author's Address 643 Dhruv Dhody 644 Huawei Technologies 645 Divyasree Techno Park, Whitefield 646 Bangalore, Karnataka 560066 647 India 649 EMail: dhruv.ietf@gmail.com