idnits 2.17.1 draft-dhody-pce-stateful-pce-lspdb-realtime-sync-00.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-pce-stateful-pce]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: It should be noted that in some deployments the PCE function is part of the central controller architecture with multiple instances of PCE for load balancing and backup which uses proprietary mechanics to maintain consistent state between these PCE instance. In such deployment PCEP MAY NOT used as a database synchronization mechanism. -- The document date (June 27, 2016) is 2859 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-14 == Outdated reference: A later version (-10) exists of draft-ietf-pce-stateful-sync-optimizations-05 == Outdated reference: A later version (-11) exists of draft-ietf-pce-pce-initiated-lsp-05 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). 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 June 27, 2016 5 Expires: December 29, 2016 7 Realtime Synchronization between Redundant Stateful PCEs. 8 draft-dhody-pce-stateful-pce-lspdb-realtime-sync-00 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 [I-D.ietf-pce-stateful-pce] specifies a set of extensions to PCEP to 17 enable stateful control of MPLS-TE and GMPLS Label Switched Paths 18 (LSPs) via PCEP and maintaining of these LSPs at the stateful PCE. 19 This document describes the mechanisms of realtime LSP Database (LSP- 20 DB) 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 December 29, 2016. 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 via [I-D.sivabalan-pce-disco-stateful] 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 6.1. The PCRpt Message 346 The format of PCRpt message is defined in 347 [I-D.ietf-pce-stateful-pce]. It specifies the PCRpt message is sent 348 from PCC to PCE in reporting the LSP state. This document extends 349 the usage of PCRpt message between redundant stateful PCEs for 350 realtime LSP synchronization as described in Section 5.1. A unique 351 PLSP-ID needs to be generated at the PCE and should also carry the 352 PCC generated PLSP-ID along in a REALTIME-SYNC TLV in the LSP object. 354 6.2. The PCUpd Message 356 The format of PCUpd Message is defined in 357 [I-D.ietf-pce-stateful-pce]. It specifies the PCUpd message is sent 358 from PCE to PCC to request changes in LSP attributes. This document 359 extends the usage of PCUpd message between stateful PCEs for realtime 360 LSP synchronization as described in Section 5.1. Whenever there is a 361 PCUpd message sent from PCE to PCC, PCE should also send it to other 362 PCEs along with the PCC generated PLSP-ID in a REALTIME-SYNC TLV in 363 the LSP object. 365 7. TLVs 367 7.1. Stateful PCE Capability TLV 369 As per [I-D.ietf-pce-stateful-pce], STATEFUL-PCE-CAPABILITY TLV can 370 be used in the OPEN object for stateful PCE capability negotiation. 371 A stateful PCE must announce during PCEP session establishment that 372 they support PCEP stateful PCE extensions defined in 373 [I-D.ietf-pce-stateful-pce]. A new flag is added - 375 R (REALTIME-SYNC-PCE - 1 bit): if set to 1 by PCE, the PCE has the 376 capability for realtime synchronization between PCEs. In case of 377 PCC, this bit has no meaning and is simply ignored. 379 7.2. Speaker Entity Identifier TLV 381 [I-D.ietf-pce-stateful-sync-optimizations] describes 'Speaker Entity 382 Identifier TLV' to be included in OPEN object. This document uses 383 the same TLV in the LSP object for realtime sync between redundant 384 stateful PCEs. 386 For a PCE that supports realtime sync (REALTIME-SYNC-PCE R flag in 387 Stateful PCE Capability TLV), the PCC MUST include 'Speaker Entity 388 Identifier TLV' in the OPEN message. Note a PCC may have to bring 389 down the current session and include the TLV in the subsequent open 390 message. 392 Any realtime state synchronization (PCRpt or PCUpd message between 393 PCEs) MUST include 'Speaker Entity Identifier TLV' in LSP object with 394 the PCC's speaker identity. If the TLV is missing, the PCE will 395 generate an error with error-type 6 (mandatory object missing) and 396 error-value TBD1 (Speaker Entity Identifier TLV missing) and close 397 the session. 399 The format of Speaker Entity Identifier is defined in 400 [I-D.ietf-pce-stateful-sync-optimizations]. 402 7.3. REALTIME-SYNC TLV 404 PCC uses the PLSP-ID in LSP object to uniquely identify an LSP. For 405 PCE to PCE realtime sync, another unique PLSP-ID needs to be 406 generated at the PCE and should also carry the PCC's generated PLSP- 407 ID in the REALTIME-SYNC TLV. This way redundant PCE can correlate 408 the LSP from the state received from the PCCs. 410 This TLV MUST be encoded in the PCRpt and PCUpd message between 411 redundant stateful PCEs. If the TLV is missing, the PCE will 412 generate an error with error-type 6 (mandatory object missing) and 413 error-value TBD2 (REALTIME-SYNC TLV missing) and close the session. 415 The format of the REALTIME-SYNC TLV is shown in the following figure: 417 0 1 2 3 418 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 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | Type=[TBD3] | Length=4 | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | PCC's PLSP-ID | reserved | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 Figure 3: REALTIME-SYNC TLV format 427 The type of the TLV is to be assigned by IANA and it has a fixed 428 length of 4 octets. The value contains the following fields: 430 PCC's PLSP-ID (20 bits): The PCC's original PLSP-ID as received in 431 the PCRpt message from the PCC. This along with Speaker Entity 432 Identifier TLV can be used to co-relate information received from 433 the network (PCCs). 435 7.4. PCE-CAP-FLAGS sub-TLV 437 [RFC5088] and [RFC5089] describe the mechanism to advertise the PCE 438 Discovery information via OSPF and IS-IS respectively along with 439 processing rules for the sub-TLVs. 440 [I-D.sivabalan-pce-disco-stateful] further enhances the optional PCE- 441 CAP-FLAGS sub-TLV used to advertise PCE stateful capabilities. 443 Further a new bit is added - 445 Bit Capabilities 447 TBD4 Realtime Sync between PCEs 449 If this bit is set to 1, the PCE has the capability for realtime 450 synchronization between PCEs. 452 8. Other Considerations 454 8.1. PCE Initiated LSP 456 [I-D.ietf-pce-pce-initiated-lsp] describes the setup and teardown of 457 PCE-initiated LSPs under the active stateful PCE model. As the PCE 458 sends PCInitiate message to PCC to create or delete LSP, the PCE 459 should also send PCUpd message to other PCEs. For the initiation, 460 the PCUpd message should have PCC's PLSP-ID as zero. The rest of the 461 processing remains unchanged. 463 9. Security Considerations 465 This document does not introduce any new security concerns besides 466 those in [I-D.ietf-pce-stateful-pce]. 468 10. Manageability Considerations 470 10.1. Control of Function and Policy 472 A PCE may be deployed to act only as a backup (Section 5.1), an 473 operator SHOULD be able to configure a PCE as backup. 475 10.2. Information and Data Models 477 [RFC7420] describes the PCEP MIB, there are no new MIB Objects for 478 this document. 480 10.3. Liveness Detection and Monitoring 482 Mechanisms defined in this document do not imply any new liveness 483 detection and monitoring requirements in addition to those already 484 listed in [RFC5440]. 486 10.4. Verify Correct Operations 488 Mechanisms defined in this document do not imply any new operation 489 verification requirements in addition to those already listed in 490 [RFC5440]. 492 10.5. Requirements On Other Protocols 494 Mechanisms defined in this document do not imply any new requirements 495 on other protocols. 497 10.6. Impact On Network Operations 499 Mechanisms defined in this document do not have any impact on network 500 operations in addition to those already listed in [RFC5440]. 502 11. IANA Considerations 504 11.1. STATEFUL-PCE-CAPABILITY TLV 506 As discussed in Section 7.1, a new STATEFUL-PCE-CAPABILITY TLV Flag 507 Field has been defined. IANA has made the following allocation from 508 the PCEP "STATEFUL-PCE-CAPABILITY TLV Flag Field" sub-registry: 510 Bit Description Reference 512 TBD REALTIME-SYNC-PCE [This I.D.] 514 11.2. PCE-CAP-FLAGS sub-TLV 516 As discussed in Section 7.1, a new bit is added, IANA is requested to 517 allocate a new bit in "PCE Capability Flags" registry for backup 518 stateful PCE capability as follows: 520 Bit Description Reference 522 TBD4 Realtime Sync between PCEs [This I.D.] 524 11.3. REALTIME-SYNC TLV 526 This document defines the following new PCEP TLV: 528 Value Meaning Reference 529 TBD3 REALTIME-SYNC TLV This document 531 11.4. PCEP-Error Object 533 IANA is requested to make the following allocation in the "PCEP-ERROR 534 Object Error Types and Values" registry. 536 Error-Type Meaning Reference 537 6 Mandatory Object missing [RFC5440] 538 Error-Value= TBD2 This document 539 Speaker Entity Identifier TLV 540 missing 541 Error-Value= TBD3 This document 542 REALTIME-SYNC TLV missing 544 12. Acknowledgments 546 Thanks to Adrian Farrel and Daniel King for writing [RFC7399]. 548 We would like to thank Avantika Kumar for her useful comments and 549 suggestions. 551 13. References 553 13.1. Normative References 555 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 556 Requirement Levels", BCP 14, RFC 2119, 557 DOI 10.17487/RFC2119, March 1997, 558 . 560 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 561 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 562 DOI 10.17487/RFC5440, March 2009, 563 . 565 [I-D.ietf-pce-stateful-pce] 566 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 567 Extensions for Stateful PCE", draft-ietf-pce-stateful- 568 pce-14 (work in progress), March 2016. 570 [I-D.ietf-pce-stateful-sync-optimizations] 571 Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 572 and D. Dhody, "Optimizations of Label Switched Path State 573 Synchronization Procedures for a Stateful PCE", draft- 574 ietf-pce-stateful-sync-optimizations-05 (work in 575 progress), April 2016. 577 13.2. Informative References 579 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 580 Element (PCE)-Based Architecture", RFC 4655, 581 DOI 10.17487/RFC4655, August 2006, 582 . 584 [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 585 Zhang, "OSPF Protocol Extensions for Path Computation 586 Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088, 587 January 2008, . 589 [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 590 Zhang, "IS-IS Protocol Extensions for Path Computation 591 Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089, 592 January 2008, . 594 [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path 595 Computation Element Architecture", RFC 7399, 596 DOI 10.17487/RFC7399, October 2014, 597 . 599 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 600 Hardwick, "Path Computation Element Communication Protocol 601 (PCEP) Management Information Base (MIB) Module", 602 RFC 7420, DOI 10.17487/RFC7420, December 2014, 603 . 605 [I-D.ietf-pce-pce-initiated-lsp] 606 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 607 Extensions for PCE-initiated LSP Setup in a Stateful PCE 608 Model", draft-ietf-pce-pce-initiated-lsp-05 (work in 609 progress), October 2015. 611 [I-D.sivabalan-pce-disco-stateful] 612 Sivabalan, S., Medved, J., and X. Zhang, "IGP Extensions 613 for Stateful PCE Discovery", draft-sivabalan-pce-disco- 614 stateful-03 (work in progress), January 2014. 616 Appendix A. Contributor Addresses 618 Udayasree Palle 619 Huawei Technologies 620 Divyasree Techno Park, Whitefield 621 Bangalore, Karnataka 560066 622 India 624 EMail: udayasree.palle@huawei.com 626 Xian Zhang 627 Huawei Technologies 628 Bantian, Longgang District 629 Shenzhen 518129 630 P.R.China 632 EMail: zhang.xian@huawei.com 634 Venugopal Reddy Kondreddy 635 Huawei Technologies 636 Divyashree Techno Park, Whitefield 637 Bangalore, Karnataka 560066 638 India 640 EMail: venugopalreddyk@huawei.com 642 Author's Address 644 Dhruv Dhody 645 Huawei Technologies 646 Divyasree Techno Park, Whitefield 647 Bangalore, Karnataka 560066 648 India 650 EMail: dhruv.ietf@gmail.com