idnits 2.17.1 draft-dhodylee-pce-pcep-ls-23.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 : ---------------------------------------------------------------------------- == There are 17 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (5 March 2022) is 776 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'TBD3' is mentioned on line 571, but not defined == Missing Reference: 'TBD5' is mentioned on line 648, but not defined == Missing Reference: 'This I-D' is mentioned on line 1278, but not defined == Outdated reference: A later version (-17) exists of draft-ietf-idr-rfc7752bis-10 == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-18 == Outdated reference: A later version (-11) exists of draft-ietf-pce-vn-association-05 == Outdated reference: A later version (-01) exists of draft-kondreddy-pce-pcep-ls-sync-optimizations-00 -- Obsolete informational reference (is this intentional?): RFC 5316 (Obsoleted by RFC 9346) -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group D. Dhody 3 Internet-Draft S. Peng 4 Intended status: Experimental Huawei Technologies 5 Expires: 6 September 2022 Y. Lee 6 Samsung Electronics 7 D. Ceccarelli 8 Ericsson 9 A. Wang 10 China Telecom 11 G. Mishra 12 Verizon Inc. 13 S. Sivabalan 14 Ciena Corporation 15 5 March 2022 17 PCEP extensions for Distribution of Link-State and TE Information 18 draft-dhodylee-pce-pcep-ls-23 20 Abstract 22 In order to compute and provide optimal paths, a Path Computation 23 Elements (PCEs) require an accurate and timely Traffic Engineering 24 Database (TED). Traditionally, this TED has been obtained from a 25 link state (LS) routing protocol supporting the traffic engineering 26 extensions. 28 This document extends the Path Computation Element Communication 29 Protocol (PCEP) with Link-State and TE Information as an experimental 30 extension. 32 Requirements Language 34 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 35 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 36 "OPTIONAL" in this document are to be interpreted as described in BCP 37 14 [RFC2119] [RFC8174] when, and only when, they appear in all 38 capitals, as shown here. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at https://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on 6 September 2022. 57 Copyright Notice 59 Copyright (c) 2022 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 64 license-info) in effect on the date of publication of this document. 65 Please review these documents carefully, as they describe your rights 66 and restrictions with respect to this document. Code Components 67 extracted from this document must include Revised BSD License text as 68 described in Section 4.e of the Trust Legal Provisions and are 69 provided without warranty as described in the Revised BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 74 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6 77 4. Requirements for PCEP extensions . . . . . . . . . . . . . . 7 78 5. New Functions to distribute link-state (and TE) via PCEP . . 8 79 6. Overview of Extensions to PCEP . . . . . . . . . . . . . . . 9 80 6.1. New Messages . . . . . . . . . . . . . . . . . . . . . . 9 81 6.2. Capability Advertisement . . . . . . . . . . . . . . . . 9 82 6.3. Initial Link-State (and TE) Synchronization . . . . . . . 10 83 6.3.1. Optimizations for LS Synchronization . . . . . . . . 12 84 6.4. LS Report . . . . . . . . . . . . . . . . . . . . . . . . 12 85 7. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 12 86 8. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 13 87 8.1. LS Report Message . . . . . . . . . . . . . . . . . . . . 13 88 8.2. The PCErr Message . . . . . . . . . . . . . . . . . . . . 13 89 9. Objects and TLV . . . . . . . . . . . . . . . . . . . . . . . 14 90 9.1. TLV Format . . . . . . . . . . . . . . . . . . . . . . . 14 91 9.2. Open Object . . . . . . . . . . . . . . . . . . . . . . . 14 92 9.2.1. LS Capability TLV . . . . . . . . . . . . . . . . . . 14 93 9.3. LS Object . . . . . . . . . . . . . . . . . . . . . . . . 15 94 9.3.1. Routing Universe TLV . . . . . . . . . . . . . . . . 17 95 9.3.2. Route Distinguisher TLV . . . . . . . . . . . . . . . 18 96 9.3.3. Virtual Network TLV . . . . . . . . . . . . . . . . . 18 97 9.3.4. Local Node Descriptors TLV . . . . . . . . . . . . . 18 98 9.3.5. Remote Node Descriptors TLV . . . . . . . . . . . . . 19 99 9.3.6. Node Descriptors Sub-TLVs . . . . . . . . . . . . . . 20 100 9.3.7. Link Descriptors TLV . . . . . . . . . . . . . . . . 21 101 9.3.8. Prefix Descriptors TLV . . . . . . . . . . . . . . . 21 102 9.3.9. PCEP-LS Attributes . . . . . . . . . . . . . . . . . 22 103 9.3.9.1. Node Attributes TLV . . . . . . . . . . . . . . . 22 104 9.3.9.2. Link Attributes TLV . . . . . . . . . . . . . . . 22 105 9.3.9.3. Prefix Attributes TLV . . . . . . . . . . . . . . 23 106 9.3.10. Removal of an Attribute . . . . . . . . . . . . . . . 23 107 10. Other Considerations . . . . . . . . . . . . . . . . . . . . 24 108 10.1. Inter-AS Links . . . . . . . . . . . . . . . . . . . . . 24 109 11. Security Considerations . . . . . . . . . . . . . . . . . . . 24 110 12. Manageability Considerations . . . . . . . . . . . . . . . . 24 111 12.1. Control of Function and Policy . . . . . . . . . . . . . 24 112 12.2. Information and Data Models . . . . . . . . . . . . . . 25 113 12.3. Liveness Detection and Monitoring . . . . . . . . . . . 25 114 12.4. Verify Correct Operations . . . . . . . . . . . . . . . 25 115 12.5. Requirements On Other Protocols . . . . . . . . . . . . 26 116 12.6. Impact On Network Operations . . . . . . . . . . . . . . 26 117 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 118 13.1. PCEP Messages . . . . . . . . . . . . . . . . . . . . . 26 119 13.2. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 26 120 13.3. LS Object . . . . . . . . . . . . . . . . . . . . . . . 26 121 13.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . 27 122 13.5. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 28 123 13.6. PCEP-LS Sub-TLV Type Indicators . . . . . . . . . . . . 28 124 14. TLV Code Points Summary . . . . . . . . . . . . . . . . . . . 29 125 15. Implementation Status . . . . . . . . . . . . . . . . . . . . 30 126 15.1. Hierarchical Transport PCE controllers . . . . . . . . . 30 127 15.2. ONOS-based Controller (MDSC and PNC) . . . . . . . . . . 31 128 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 129 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 130 17.1. Normative References . . . . . . . . . . . . . . . . . . 31 131 17.2. Informative References . . . . . . . . . . . . . . . . . 32 132 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 35 133 A.1. All Nodes . . . . . . . . . . . . . . . . . . . . . . . . 35 134 A.2. Designated Node . . . . . . . . . . . . . . . . . . . . . 37 135 A.3. Between PCEs . . . . . . . . . . . . . . . . . . . . . . 37 136 Appendix B. Contributor Addresses . . . . . . . . . . . . . . . 38 137 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 139 1. Introduction 141 In Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS), 142 a Traffic Engineering Database (TED) is used in computing paths for 143 connection-oriented packet services and for circuits. The TED 144 contains all relevant information that a Path Computation Element 145 (PCE) needs to perform its computations. It is important that the 146 TED be 'complete and accurate' each time the PCE performs a path 147 computation. 149 In MPLS and GMPLS, interior gateway routing protocols (Interior 150 Gateway Protocol (IGPs)) have been used to create and maintain a copy 151 of the TED at each node running the IGP. One of the benefits of the 152 PCE architecture [RFC4655] is the use of computationally more 153 sophisticated path computation algorithms and the realization that 154 these may need enhanced processing power (not necessarily available 155 at each node). 157 Section 4.3 of [RFC4655] describes the potential load of the TED on a 158 network node and proposes an architecture where the TED is maintained 159 by the PCE rather than the network nodes. However, it does not 160 describe how a PCE would obtain the information needed to populate 161 its TED. PCE may construct its TED by participating in the IGP 162 ([RFC3630] and [RFC5305] for MPLS-TE; [RFC4203] and [RFC5307] for 163 GMPLS). An alternative mechanism is offered by BGP-LS 164 [I-D.ietf-idr-rfc7752bis] . 166 [RFC8231] describes a set of extensions to PCEP to provide stateful 167 control. A stateful PCE has access to not only the information 168 carried by the network's IGP, but also the set of active paths and 169 their reserved resources for its computations. Path Computation 170 Client (PCC) can delegate the rights to modify the LSP parameters to 171 an Active Stateful PCE. This requires PCE to quickly be updated on 172 any changes in the topology/TED, so that PCE can meet the need for 173 updating LSPs effectively and in a timely manner. The fastest way 174 for a PCE to be updated on TED changes is via a direct session with 175 each network node and with an incremental update from each network 176 node with only the attributes that gets modified. 178 [RFC8281] describes the setup, maintenance, and teardown of PCE- 179 initiated LSPs under the stateful PCE model, without the need for 180 local configuration on the PCC, thus allowing for a dynamic network 181 that is centrally controlled and deployed. This model requires 182 timely topology and TED update at the PCE. 184 [RFC5440] describes the specifications for the Path Computation 185 Element Communication Protocol (PCEP). PCEP specifies the 186 communication between a PCC and a PCE, or between two PCEs based on 187 the PCE architecture [RFC4655]. 189 This document describes a mechanism by which link-state and TE 190 information can be collected from networks and shared with PCE using 191 the PCEP itself. This is achieved using a new PCEP message format. 192 The mechanism is applicable to physical and virtual links as well as 193 further subjected to various policies. 195 A network node maintains one or more databases for storing link-state 196 and TE information about nodes and links in any given area. Link 197 attributes stored in these databases include: local/remote IP 198 addresses, local/remote interface identifiers, link metric, and TE 199 metric, link bandwidth, reservable bandwidth, per CoS class 200 reservation state, preemption, and Shared Risk Link Groups (SRLG). 201 The node's PCEP process can retrieve topology from these databases 202 and distribute it to a PCE, either directly or via another PCEP 203 Speaker, using the encoding specified in this document. 205 Further [RFC6805] describes Hierarchical-PCE architecture, where a 206 parent PCE maintains a domain topology map. To build this domain 207 topology map, the child PCE can carry the border nodes and inter- 208 domain link information to the parent PCE using the mechanism 209 described in this document. Further as described in [RFC8637], the 210 child PCE can also transport abstract Link-State and TE information 211 from child PCE to a Parent PCE using the mechanism described in this 212 document to build an abstract topology at the parent PCE. 214 [RFC8231] describe LSP state synchronization between PCCs and PCEs in 215 case of stateful PCE. This document does not make any change to the 216 LSP state synchronization process. The mechanism described in this 217 document are on top of the existing LSP state synchronization. 219 1.1. Scope 221 The procedures described in this document are experimental. The 222 experiment is intended to enable research for the usage of PCEP to 223 populate the Link-State and TE Information from a PCC to the PCE. 224 For this purpose, this document specifies new PCEP message and 225 object/TLVs. 227 The new message introduced by this document will not be understood by 228 legacy implementations. On receiving the message, a legacy 229 implementation will behave according to the rules for a unknown 230 message as per [RFC5440]. It is assumed that this experiment will be 231 conducted only when both the PCE and PCC form part of the experiment. 233 It is possible that a PCC or PCE can operate with peers, some of 234 which form part of the experiment and some that do not. In this 235 case, the capability exchange required before using this extension 236 would take care of the mismatch. A PCEP speaker that offers this 237 feature to its peer that does not support or does not wish to support 238 the feature will not receive indication of support in the Open 239 message, and so is expected to not use the feature. Thus this 240 experimentation would not clash with or cause harm to existing 241 deployments. Further since a PCEP speaker would use the new message 242 only after capability exchange, there is no danger of this 243 experimentation "escaping" to the wider Internet. A PCEP speaker 244 that receives the new message that is part of the feature when use of 245 the feature has not been agreed, will send an error message as 246 described in Section 6.9 of [RFC5440]. A PCEP speaker that receives 247 the new object that is part of the feature when use of the feature 248 has not been agreed, will send an error message as described in 249 Section 7.2 of [RFC5440]. 251 The experiment will end three years after the RFC is published. At 252 that point, the RFC authors will attempt to determine how widely this 253 has been implemented and deployed. When the results of 254 implementation and deployment are available, this document (or part 255 there of) will be updated and refined, and then it could be moved 256 from Experimental to Standards Track. 258 2. Terminology 260 The terminology is as per [RFC4655] and [RFC5440]. 262 3. Applicability 264 The mechanism specified in this draft is applicable to deployments: 266 * Where there is no IGP or BGP-LS running in the network. 268 * Where there is no IGP or BGP-LS running at the PCE to learn link- 269 state and TE information. 271 * Where there is IGP or BGP-LS running but with a need for a faster 272 and direct TE and link-state population and convergence at the 273 PCE. 275 - A PCE may receive partial information (say basic TE, link- 276 state) from IGP and other information (optical and impairment) 277 from PCEP. 279 - A PCE may receive an incremental update (as opposed to the full 280 (entire) information of the node/link). 282 - A PCE may receive full information from both existing 283 mechanisms (IGP or BGP-LS) and PCEP. 285 * Where there is a need for transporting (abstract) Link-State and 286 TE information from child PCE to a Parent PCE in H-PCE [RFC6805]; 287 as well as for Provisioning Network Controller (PNC) to Multi- 288 Domain Service Coordinator (MDSC) in Abstraction and Control of TE 289 Networks (ACTN) [RFC8453]. 291 * Where there is an existing PCEP session between all the nodes and 292 the PCE-based central controller (PCECC) [RFC8283], and the 293 operator would like to use PCEP as direct southbound interface to 294 all the nodes in the network. This enables the operator to use 295 PCEP as a single direct protocol between the controller and all 296 the nodes in the network. In this mode, all nodes send only the 297 local information. 299 Based on the local policy and deployment scenario, a PCC chooses to 300 send only local information or both local and remote learned 301 information. How a PCE manages the link-state (and TE) information 302 is implementation specific and thus out of the scope of this 303 document. 305 The prefix information in PCEP-LS can also help in determining the 306 domain of the tunnel destination in the H-PCE (and ACTN) scenario. 307 Section 4.5 of [RFC6805] describe various mechanisms and procedures 308 that might be used, PCEP-LS provides a simple mechanism to exchange 309 this information within PCEP. 311 [RFC8453] defines three types of topology abstraction - (1) Native/ 312 White Topology; (2) Black Topology; and (3) Grey Topology. Based on 313 the local policy, the PNC (or child PCE) would share the domain 314 topology to the MDSC (or Parent PCE) based on the abstraction type. 315 The protocol extensions defined in this document can carry any type 316 of topology abstraction. 318 4. Requirements for PCEP extensions 320 Following key requirements associated with link-state (and TE) 321 distribution are identified for PCEP: 323 1. The PCEP speaker supporting this draft MUST have a mechanism to 324 advertise the Link-State (and TE) distribution capability. 326 2. PCC supporting this draft MUST have the capability to report the 327 link-state (and TE) information to the PCE. This MUST include 328 self originated (local) information and MAY also allow remote 329 information learned via routing protocols. PCC MUST be capable 330 to do the initial bulk sync at the time of session initialization 331 as well as any changes there after. 333 3. A PCE MAY learn link-state (and TE) from PCEP as well as from 334 existing mechanisms like IGP/BGP-LS. PCEP extensions MUST have a 335 mechanism to correlate the information learned via other means. 336 There MUST NOT be any changes to the existing link-state (and TE) 337 population mechanism via IGP/BGP-LS. PCEP extension SHOULD keep 338 the properties in a protocol (IGP or BGP-LS) neutral way, such 339 that an implementation need not know about any OSPF or IS-IS or 340 BGP-LS protocol specifics. 342 4. It SHOULD be possible to encode only the changes in link-state 343 (and TE) properties (after the initial sync) in PCEP messages. 344 This leads to faster convergence. 346 5. The same mechanism SHOULD be used for both MPLS TE as well as 347 GMPLS, optical, and impairment aware properties. 349 6. The same mechanism SHOULD be used for PCE to PCE Link-state (and 350 TE) synchronization. 352 5. New Functions to distribute link-state (and TE) via PCEP 354 Several new functions are required in PCEP to support distribution of 355 link-state (and TE) information. A function can be initiated either 356 from a PCC towards a PCE (C-E) or from a PCE towards a PCC (E-C). 357 The new functions are: 359 * Capability advertisement (E-C,C-E): both the PCC and the PCE MUST 360 announce during PCEP session establishment that they support PCEP 361 extensions for distribution of link-state (and TE) information 362 defined in this document. 364 * Link-State (and TE) synchronization (C-E): after the session 365 between the PCC and a PCE is initialized, the PCE must learn Link- 366 State (and TE) information before it can perform path 367 computations. In the case of stateful PCE it is RECOMMENDED that 368 this operation be done before LSP state synchronization. 370 * Link-State (and TE) Report (C-E): a PCC sends an LS (and TE) 371 report to a PCE whenever the Link-State and TE information 372 changes. 374 6. Overview of Extensions to PCEP 376 6.1. New Messages 378 In this document, we define a new PCEP message called LS Report 379 (LSRpt), a PCEP message sent by a PCC to a PCE to report link-state 380 (and TE) information. Each LS Report in an LSRpt message can contain 381 the node or link properties. A unique PCEP specific LS identifier 382 (LS-ID) is also carried in the message to identify a node or link and 383 that remains constant for the lifetime of a PCEP session. This 384 identifier on its own is sufficient when no IGP or BGP-LS running in 385 the network for PCE to learn link-state (and TE) information. In 386 case PCE learns some information from PCEP and some from the existing 387 mechanism, the PCC SHOULD include the mapping of IGP or BGP-LS 388 identifier to map the information populated via PCEP with IGP/BGP-LS. 389 See Section 8.1 for details. 391 6.2. Capability Advertisement 393 During PCEP Initialization Phase, PCEP Speakers (PCE or PCC) 394 advertise their support of LS (and TE) distribution via PCEP 395 extensions. A PCEP Speaker includes the "LS Capability" TLV, 396 described in Section 9.2.1, in the OPEN Object to advertise its 397 support for PCEP-LS extensions. The presence of the LS Capability 398 TLV in PCC's OPEN Object indicates that the PCC is willing to send LS 399 Reports with local link-state (and TE) information. The presence of 400 the LS Capability TLV in PCE's Open message indicates that the PCE is 401 interested in receiving LS Reports with local link-state (and TE) 402 information. 404 The PCEP extensions for LS (and TE) distribution MUST NOT be used if 405 one or both PCEP Speakers have not included the LS Capability TLV in 406 their respective OPEN message. If the PCE that supports the 407 extensions of this draft but did not advertise this capability, then 408 upon receipt of an LSRpt message from the PCC, it SHOULD generate a 409 PCErr with error-type 19 (Invalid Operation), error-value TBD1 410 (Attempted LS Report if LS capability was not advertised) and it will 411 terminate the PCEP session. 413 The LS reports sent by PCC MAY carry the remote link-state (and TE) 414 information learned via existing means like IGP and BGP-LS only if 415 both PCEP Speakers set the R (remote) Flag in the "LS Capability" TLV 416 to 'Remote Allowed (R Flag = 1)'. If this is not the case and LS 417 reports carry remote link-state (and TE) information, then a PCErr 418 with error-type 19 (Invalid Operation) and error-value TBD1 419 (Attempted LS Report if LS remote capability was not advertised) and 420 it will terminate the PCEP session. 422 6.3. Initial Link-State (and TE) Synchronization 424 The purpose of LS Synchronization is to provide a checkpoint-in-time 425 state replica of a PCC's link-state (and TE) database in a PCE. 426 State Synchronization is performed immediately after the 427 Initialization phase (see [RFC5440]). In case of stateful PCE 428 ([RFC8231]) it is RECOMMENDED that the LS synchronization should be 429 done before LSP state synchronization. 431 During LS Synchronization, a PCC first takes a snapshot of the state 432 of its database, then sends the snapshot to a PCE in a sequence of LS 433 Reports. Each LS Report sent during LS Synchronization has the SYNC 434 Flag in the LS Object set to 1. The end of synchronization marker is 435 an LSRpt message with the SYNC Flag set to 0 for an LS Object with 436 LS-ID equal to the reserved value 0. If the PCC has no link-state to 437 synchronize, it will only send the end of synchronization marker. 439 Either the PCE or the PCC MAY terminate the session using the PCEP 440 session termination procedures during the synchronization phase. If 441 the session is terminated, the PCE MUST clean up the state it 442 received from this PCC. The session re-establishment MUST be re- 443 attempted per the procedures defined in [RFC5440], including the use 444 of a back-off timer. 446 If the PCC encounters a problem which prevents it from completing the 447 LS synchronization, it MUST send a PCErr message with error-type TBD2 448 (LS Synchronization Error) and error-value 2 (indicating an internal 449 PCC error) to the PCE and terminate the session. 451 The PCE does not send positive acknowledgments for properly received 452 LS synchronization messages. It MUST respond with a PCErr message 453 with error-type TBD2 (LS Synchronization Error) and error-value 1 454 (indicating an error in processing the LSRpt) if it encounters a 455 problem with the LS Report it received from the PCC and it MUST 456 terminate the session. 458 The LS reports can carry local as well as remote link-state (and TE) 459 information depending on the R flag in LS capability TLV. 461 The successful LS Synchronization sequence is shown in Figure 1. 463 +-+-+ +-+-+ 464 |PCC| |PCE| 465 +-+-+ +-+-+ 466 | | 467 |-----LSRpt, SYNC=1----->| (Sync start) 468 | | 469 |-----LSRpt, SYNC=1----->| 470 | . | 471 | . | 472 | . | 473 |-----LSRpt, SYNC=1----->| 474 | . | 475 | . | 476 | . | 477 | | 478 |-----LSRpt, SYNC=0----->| (End of sync marker 479 | | LS Report 480 | | for LS-ID=0) 481 | | (Sync done) 483 Figure 1: Successful LS synchronization 485 The sequence where the PCE fails during the LS Synchronization phase 486 is shown in Figure 2. 488 +-+-+ +-+-+ 489 |PCC| |PCE| 490 +-+-+ +-+-+ 491 | | 492 |-----LSRpt, SYNC=1----->| 493 | | 494 |-----LSRpt, SYNC=1----->| 495 | . | 496 | . | 497 | . | 498 |-----LSRpt, SYNC=1----->| 499 | | 500 |---LSRpt,SYNC=1 | 501 | \ ,-PCErr---| 502 | \ / | 503 | \/ | 504 | /\ | 505 | / `-------->| (Ignored) 506 |<--------` | 508 Figure 2: Failed LS synchronization (PCE failure) 510 The sequence where the PCC fails during the LS Synchronization phase 511 is shown in Figure 3. 513 +-+-+ +-+-+ 514 |PCC| |PCE| 515 +-+-+ +-+-+ 516 | | 517 |-----LSRpt, SYNC=1----->| 518 | | 519 |-----LSRpt, SYNC=1----->| 520 | . | 521 | . | 522 | . | 523 |-------- PCErr--------->| 524 | | 526 Figure 3: Failed LS synchronization (PCC failure) 528 6.3.1. Optimizations for LS Synchronization 530 These optimizations are described in 531 [I-D.kondreddy-pce-pcep-ls-sync-optimizations]. 533 6.4. LS Report 535 The PCC MUST report any changes in the link-state (and TE) 536 information to the PCE by sending an LS Report carried on an LSRpt 537 message to the PCE. Each node and Link would be uniquely identified 538 by a PCEP LS identifier (LS-ID). The LS reports may carry local as 539 well as remote link-state (and TE) information depending on the R 540 flag in LS capability TLV. It MAY also include the mapping of IGP or 541 BGP-LS identifier to map the information populated via PCEP with IGP/ 542 BGP-LS identifiers. 544 More details about the LSRpt message are in Section 8.1. 546 7. Transport 548 A permanent PCEP session (section 4.2.8 of [RFC5440]) MUST be 549 established between a PCE and PCC supporting link-state (and TE) 550 distribution via PCEP. In the case of session failure, session re- 551 establishment is re-attempted as per the procedures defined in 552 [RFC5440]. 554 8. PCEP Messages 556 As defined in [RFC5440], a PCEP message consists of a common header 557 followed by a variable-length body made of a set of objects that can 558 be either mandatory or optional. An object is said to be mandatory 559 in a PCEP message when the object must be included for the message to 560 be considered valid. For each PCEP message type, a set of rules is 561 defined that specify the set of objects that the message can carry. 562 An implementation MUST form the PCEP messages using the object 563 ordering specified in this document. 565 8.1. LS Report Message 567 A PCEP LS Report message (also referred to as LSRpt message) is a 568 PCEP message sent by a PCC to a PCE to report the link-state (and TE) 569 information. An LSRpt message can carry more than one LS Reports (LS 570 object). The Message-Type field of the PCEP common header for the 571 LSRpt message is set to [TBD3]. 573 The format of the LSRpt message is as follows: 575 ::= 576 577 Where: 579 ::= [] 581 The LS object is a mandatory object which carries LS information of a 582 node/prefix or a link. Each LS object has a unique LS-ID as 583 described in Section 9.3. If the LS object is missing, the receiving 584 PCE MUST send a PCErr message with Error-type=6 (Mandatory Object 585 missing) and Error-value=[TBD4] (LS object missing). 587 A PCE may choose to implement a limit on the LS information a single 588 PCC can populate. If an LSRpt is received that causes the PCE to 589 exceed this limit, it MUST send a PCErr message with error-type 19 590 (invalid operation) and error-value 4 (indicating resource limit 591 exceeded) in response to the LSRpt message triggering this condition 592 and SHOULD terminate the session. 594 8.2. The PCErr Message 596 If a PCEP speaker has advertised the LS capability on the PCEP 597 session, the PCErr message MAY include the LS object. If the error 598 reported is the result of an LS report, then the LS-ID number MUST be 599 the one from the LSRpt that triggered the error. 601 The format of a PCErr message from [RFC5440] is extended as follows: 603 ::= 604 ( [] ) | 605 [] 607 ::=[] 609 ::=[ | ] 610 612 ::=[] 614 ::=[] 616 ::=[] 618 9. Objects and TLV 620 The PCEP objects defined in this document are compliant with the PCEP 621 object format defined in [RFC5440]. The P flag and the I flag of the 622 PCEP objects defined in this document MUST always be set to 0 on 623 transmission and MUST be ignored on receipt since these flags are 624 exclusively related to path computation requests. 626 9.1. TLV Format 628 The TLV and the sub-TLV format (and padding) in this document, is as 629 per section 7.1 of [RFC5440]. 631 9.2. Open Object 633 This document defines a new optional TLV for use in the OPEN Object. 635 9.2.1. LS Capability TLV 637 The LS-CAPABILITY TLV is an optional TLV for use in the OPEN Object 638 for link-state (and TE) distribution via PCEP capability 639 advertisement. Its format is shown in the following figure: 641 0 1 2 3 642 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 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 | Type=[TBD5] | Length=4 | 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 | Flags |R| 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 The type of the TLV is [TBD5] and it has a fixed length of 4 octets. 650 The value comprises a single field - Flags (32 bits): 652 * R (remote allowed - 1 bit): if set to 1 by a PCC, the R Flag 653 indicates that the PCC allows reporting of remote LS information 654 learned via other means like IGP and BGP-LS; if set to 1 by a PCE, 655 the R Flag indicates that the PCE is capable of receiving remote 656 LS information (from the PCC point of view). The R Flag must be 657 advertised by both PCC and PCE for LSRpt messages to report remote 658 as well as local LS information on a PCEP session. The TLVs 659 related to IGP/BGP-LS identifier MUST be encoded when both PCEP 660 speakers have the R Flag set. 662 Unassigned bits are considered reserved. They MUST be set to 0 on 663 transmission and MUST be ignored on receipt. 665 Advertisement of the LS capability implies support of local link- 666 state (and TE) distribution, as well as the objects, TLVs and 667 procedures defined in this document. 669 9.3. LS Object 671 The LS (link-state) object MUST be carried within LSRpt messages and 672 MAY be carried within PCErr messages. The LS object contains a set 673 of fields used to specify the target node or link. It also contains 674 a flag indicating to a PCE that the LS synchronization is in 675 progress. The TLVs used with the LS object correlate with the IGP/ 676 BGP-LS encodings. 678 LS Object-Class is TBD6. 680 Four Object-Type values are defined for the LS object so far: 682 * LS Node: LS Object-Type is 1. 684 * LS Link: LS Object-Type is 2. 686 * LS IPv4 Topology Prefix: LS Object-Type is 3. 688 * LS IPv6 Topology Prefix: LS Object-Type is 4. 690 The format of all types of LS object is as follows: 692 0 1 2 3 693 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 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 | Protocol-ID | Flag |R|S| 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 | LS-ID | 698 | | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 // TLVs // 701 | | 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 Protocol-ID (8-bit): The field provides the source information. The 705 protocol could be an IGP, BGP-LS, or an abstraction algorithm. In 706 case PCC only provides local information of the PCC, it MUST use 707 Protocol-ID as Direct. The following values are defined (some of the 708 initial values are the same as [I-D.ietf-idr-rfc7752bis]): 710 +-------------+----------------------------------+ 711 | Protocol-ID | Source protocol | 712 +-------------+----------------------------------+ 713 | 1 | IS-IS Level 1 | 714 | 2 | IS-IS Level 2 | 715 | 3 | OSPFv2 | 716 | 4 | Direct | 717 | 5 | Static configuration | 718 | 6 | OSPFv3 | 719 | 7 | BGP | 720 | 8 | RSVP-TE | 721 | 9 | Segment Routing | 722 | 10 | PCEP | 723 | 11 | Abstraction | 724 +-------------+----------------------------------+ 726 Flags (24-bit): 728 * S (SYNC - 1 bit): the S Flag MUST be set to 1 on each LSRpt sent 729 from a PCC during LS Synchronization. The S Flag MUST be set to 0 730 in other LSRpt messages sent from the PCC. 732 * R (Remove - 1 bit): On LSRpt messages, the R Flag indicates that 733 the node/link/prefix has been removed from the PCC and the PCE 734 SHOULD remove from its database. Upon receiving an LS Report with 735 the R Flag set to 1, the PCE SHOULD remove all state for the 736 node/link/prefix identified by the LS Identifiers from its 737 database. 739 LS-ID(64-bit): A PCEP-specific identifier for the node, link, or 740 prefix information. A PCC creates a unique LS-ID for each node/link/ 741 prefix that is constant for the lifetime of a PCEP session. The PCC 742 will advertise the same LS-ID on all PCEP sessions it maintains at a 743 given time. All subsequent PCEP messages then address the node/link/ 744 prefix by the LS-ID. The values of 0 and 0xFFFFFFFFFFFFFFFF are 745 reserved. 747 Unassigned bits are considered reserved. They MUST be set to 0 on 748 transmission and MUST be ignored on receipt. 750 TLVs that may be included in the LS Object are described in the 751 following sections. 753 9.3.1. Routing Universe TLV 755 In the case of remote link-state (and TE) population when existing 756 IGP/BGP-LS are also used, OSPF and IS-IS may run multiple routing 757 protocol instances over the same link as described in 758 [I-D.ietf-idr-rfc7752bis]. See [RFC8202] and [RFC6549] for more 759 information. These instances define an independent "routing 760 universe". The 64-bit 'Identifier' field is used to identify the 761 "routing universe" where the LS object belongs. The LS objects 762 representing IGP objects (nodes or links or prefix) from the same 763 routing universe MUST have the same 'Identifier' value; LS objects 764 with different 'Identifier' values MUST be considered to be from 765 different routing universes. 767 The format of the optional ROUTING-UNIVERSE TLV is shown in the 768 following figure: 770 0 1 2 3 771 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 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 | Type=[TBD7] | Length=8 | 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 | Identifier | 776 | | 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 The below table lists the 'Identifier' values that are defined as 780 well-known in this draft (same as [I-D.ietf-idr-rfc7752bis]). 782 +------------+-----------------------------------+ 783 | Identifier | Routing Universe | 784 +------------+-----------------------------------+ 785 | 0 | Default Layer 3 Routing topology | 786 +------------+-----------------------------------+ 788 If this TLV is not present the default value 0 is assumed. 790 9.3.2. Route Distinguisher TLV 792 To allow identification of VPN link, node, and prefix information in 793 PCEP-LS, a Route Distinguisher (RD) [RFC4364] is used. The LS 794 objects from the same VPN MUST have the same RD; LS objects with 795 different RD values MUST be considered to be from different VPNs. 797 The ROUTE-DISTINGUISHER TLV is defined in [RFC9168] as a Flow 798 Specification TLVs with a separate registry. This document also adds 799 the ROUTE-DISTINGUISHER TLV with TBD15 in the PCEP TLV registry to be 800 used inside the LS object. 802 9.3.3. Virtual Network TLV 804 To realize ACTN, the MDSC needs to build a multi-domain topology. 805 This topology is best served if this is an abstracted view of the 806 underlying network resources of each domain. It is also important to 807 provide a customer view of the network slice for each customer. 808 There is a need to control the level of abstraction based on the 809 deployment scenario and business relationship between the 810 controllers. 812 Virtual service coordination function in ACTN incorporates customer 813 service-related knowledge into the virtual network operations in 814 order to seamlessly operate virtual networks while meeting customer's 815 service requirements. [I-D.ietf-teas-actn-requirements] describes 816 various VN operations initiated by a customer/application. In this 817 context, there is a need for associating the abstracted link-state 818 and TE topology with a VN "construct" to facilitate VN operations in 819 PCE architecture. 821 VIRTUAL-NETWORK-TLV as per [I-D.ietf-pce-vn-association] can be 822 included in LS object to identify the link, node, and prefix 823 information belongs to a particular VN. 825 9.3.4. Local Node Descriptors TLV 827 As described in [I-D.ietf-idr-rfc7752bis], each link is anchored by a 828 pair of Router-IDs that are used by the underlying IGP, namely, 829 48-bit ISO System-ID for IS-IS and 32-bit Router-ID for OSPFv2 and 830 OSPFv3. In case of additional auxiliary Router-IDs used for TE, 831 these MUST also be included in the link attribute TLV (see 832 Section 9.3.9.2). 834 It is desirable that the Router-ID assignments inside the Node 835 Descriptors TLV are globally unique. Some considerations for 836 globally unique Node/Link/Prefix identifiers are described in 837 [I-D.ietf-idr-rfc7752bis]. 839 The Local Node Descriptors TLV contains Node Descriptors for the node 840 anchoring the local end of the link. This TLV MUST be included in 841 the LS Report when during a given PCEP session a node/link/prefix is 842 first reported to a PCE. A PCC sends to a PCE the first LS Report 843 either during State Synchronization, or when a new node/link/prefix 844 is learned at the PCC. The value contains one or more Node 845 Descriptor Sub-TLVs, which allows the specification of a flexible key 846 for any given node/link/prefix information such that the global 847 uniqueness of the node/link/prefix is ensured. 849 This TLV is applicable for all LS Object-Type. 851 0 1 2 3 852 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 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 | Type=[TBD8] | Length | 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 | | 857 // Node Descriptor Sub-TLVs (variable) // 858 | | 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 The value contains one or more Node Descriptor Sub-TLVs defined in 862 Section 9.3.6. 864 9.3.5. Remote Node Descriptors TLV 866 The Remote Node Descriptors contain Node Descriptors for the node 867 anchoring the remote end of the link. This TLV MUST be included in 868 the LS Report when during a given PCEP session a link is first 869 reported to a PCE. A PCC sends to a PCE the first LS Report either 870 during State Synchronization, or when a new link is learned at the 871 PCC. The length of this TLV is variable. The value contains one or 872 more Node Descriptor Sub-TLVs defined in Section 9.3.6. 874 This TLV is applicable for LS Link Object-Type. 876 0 1 2 3 877 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 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 | Type=[TBD9] | Length | 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 | | 882 // Node Descriptor Sub-TLVs (variable) // 883 | | 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 9.3.6. Node Descriptors Sub-TLVs 888 The Node Descriptors TLV (Local and Remote) carries one or more Node 889 Descriptor Sub-TLV follows the format of all PCEP TLVs as defined in 890 [RFC5440], however, the Type values are selected from a new PCEP-LS 891 sub-TLV IANA registry (see Section 13.6). 893 Type values are chosen so that there can be commonality with BGP-LS 894 [I-D.ietf-idr-rfc7752bis]. This is possible because the "BGP-LS Node 895 Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs" 896 registry marks 0-255 as reserved. Thus the space of the sub-TLV 897 values for the Type field can be partitioned as shown below - 899 Range | 900 ---------------+--------------------------------------------- 901 0 | Reserved - must not be allocated. 902 | 903 1 .. 255 | New PCEP sub-TLV allocated according to the 904 | registry defined in this document. 905 | 906 256 .. 65535 | Per BGP registry defined by 907 | [I-D.ietf-idr-rfc7752bis]. 908 | Not to be allocated in this registry. 910 All Node Descriptors TLVs defined for BGP-LS can then be used with 911 PCEP-LS as well. One new PCEP sub-TLVs for Node Descriptor are 912 defined in this document. 914 +----------+-------------------+----------+----------------+ 915 | Sub-TLV | Description | Length |Value defined in| 916 +----------+-------------------+----------+----------------+ 917 | 1 | SPEAKER-ENTITY-ID | Variable | [RFC8232] | 918 +----------+-------------------+----------+----------------+ 920 A new sub-TLV type (1) is allocated for SPEAKER-ENTITY-ID sub-TLV. 921 The length and value fields are as per [RFC8232]. 923 9.3.7. Link Descriptors TLV 925 The Link Descriptors TLV contains Link Descriptors for each link. 926 This TLV MUST be included in the LS Report when during a given PCEP 927 session a link is first reported to a PCE. A PCC sends to a PCE the 928 first LS Report either during State Synchronization, or when a new 929 link is learned at the PCC. The length of this TLV is variable. The 930 value contains one or more Link Descriptor Sub-TLVs. 932 The 'Link descriptor' TLVs uniquely identify a link among multiple 933 parallel links between a pair of anchor routers similar to 934 [I-D.ietf-idr-rfc7752bis]. 936 This TLV is applicable for LS Link Object-Type. 938 0 1 2 3 939 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 940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 | Type=[TBD10] | Length | 942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 943 | | 944 // Link Descriptor Sub-TLVs (variable) // 945 | | 946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 948 All Link Descriptors TLVs defined for BGP-LS can then be used with 949 PCEP-LS as well. No new PCEP sub-TLVs for Link Descriptor are 950 defined in this document. 952 The format and semantics of the 'value' fields in most 'Link 953 Descriptor' sub-TLVs correspond to the format and semantics of value 954 fields in IS-IS Extended IS Reachability sub-TLVs, defined in 955 [RFC5305], [RFC5307] and [RFC6119]. Although the encodings for 'Link 956 Descriptor' TLVs were originally defined for IS-IS, the TLVs can 957 carry data sourced either by IS-IS or OSPF or direct. 959 The information about a link present in the LSA/LSP originated by the 960 local node of the link determines the set of sub-TLVs in the Link 961 Descriptor of the link as described in [I-D.ietf-idr-rfc7752bis]. 963 9.3.8. Prefix Descriptors TLV 965 The Prefix Descriptors TLV contains Prefix Descriptors that uniquely 966 identify an IPv4 or IPv6 Prefix originated by a Node. This TLV MUST 967 be included in the LS Report when during a given PCEP session a 968 prefix is first reported to a PCE. A PCC sends to a PCE the first LS 969 Report either during State Synchronization, or when a new prefix is 970 learned at the PCC. The length of this TLV is variable. 972 This TLV is applicable for LS Prefix Object-Types for both IPv4 and 973 IPv6. 975 0 1 2 3 976 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 977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 978 | Type=[TBD11] | Length | 979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 980 | | 981 // Prefix Descriptor Sub-TLVs (variable) // 982 | | 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 985 All Prefix Descriptors TLVs defined for BGP-LS can then be used with 986 PCEP-LS as well. No new PCEP sub-TLVs for Prefix Descriptor are 987 defined in this document. 989 9.3.9. PCEP-LS Attributes 991 9.3.9.1. Node Attributes TLV 993 This is an optional attribute that is used to carry node attributes. 994 This TLV is applicable for LS Node Object-Type. 996 0 1 2 3 997 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 998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 999 | Type=[TBD12] | Length | 1000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1001 | | 1002 // Node Attributes Sub-TLVs (variable) // 1003 | | 1004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1006 All Node Attributes TLVs defined for BGP-LS can then be used with 1007 PCEP-LS as well. No new PCEP sub-TLVs for Node Attributes are 1008 defined in this document. 1010 9.3.9.2. Link Attributes TLV 1012 This TLV is applicable for LS Link Object-Type. The format and 1013 semantics of the 'value' fields in some 'Link Attribute' sub-TLVs 1014 correspond to the format and semantics of the 'value' fields in IS-IS 1015 Extended IS Reachability sub-TLVs, defined in [RFC5305], [RFC5307] 1016 and [I-D.ietf-idr-rfc7752bis]. Although the encodings for 'Link 1017 Attribute' TLVs were originally defined for IS-IS, the TLVs can carry 1018 data sourced either by IS-IS or OSPF or direct. 1020 0 1 2 3 1021 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 1022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1023 | Type=[TBD13] | Length | 1024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1025 | | 1026 // Link Attributes Sub-TLVs (variable) // 1027 | | 1028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1030 All Link Attributes TLVs defined for BGP-LS can then be used with 1031 PCEP-LS as well. No new PCEP sub-TLVs for Link Attributes are 1032 defined in this document. 1034 9.3.9.3. Prefix Attributes TLV 1036 This TLV is applicable for LS Prefix Object-Types for both IPv4 and 1037 IPv6. Prefixes are learned from the IGP (IS-IS or OSPF) or BGP 1038 topology with a set of IGP attributes (such as metric, route tags, 1039 etc.). This section describes the different attributes related to 1040 the IPv4/IPv6 prefixes. Prefix Attributes TLVs SHOULD be encoded in 1041 the LS Prefix Object. 1043 0 1 2 3 1044 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 1045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1046 | Type=[TBD14] | Length | 1047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1048 | | 1049 // Prefix Attributes Sub-TLVs (variable) // 1050 | | 1051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1053 All Prefix Attributes TLVs defined for BGP-LS can then be used with 1054 PCEP-LS as well. No new PCEP sub-TLVs for Prefix Attributes are 1055 defined in this document. 1057 9.3.10. Removal of an Attribute 1059 One of the key objectives of PCEP-LS is to encode and carry only the 1060 impacted attributes of a Node, a Link, or a Prefix. To accommodate 1061 this requirement, in case of a removal of an attribute, the sub-TLV 1062 MUST be included with no 'value' field and length=0 to indicate that 1063 the attribute is removed. On receiving a sub-TLV with zero length, 1064 the receiver removes the attribute from the database. An absence of 1065 a sub-TLV that was included earlier MUST be interpreted as no change. 1067 10. Other Considerations 1069 10.1. Inter-AS Links 1071 The main source of LS (and TE) information is the IGP, which is not 1072 active on inter-AS links. In some cases, the IGP may have 1073 information of inter-AS links ([RFC5392], [RFC5316]). In other 1074 cases, an implementation SHOULD provide a means to inject inter-AS 1075 links into PCEP. The exact mechanism used to provision the inter-AS 1076 links is outside the scope of this document. 1078 11. Security Considerations 1080 This document extends PCEP for LS (and TE) distribution including a 1081 new LSRpt message with a new object and TLVs. Procedures and 1082 protocol extensions defined in this document do not effect the 1083 overall PCEP security model. See [RFC5440], [RFC8253]. Tampering 1084 with the LSRpt message may have an effect on path computations at 1085 PCE. It also provides adversaries an opportunity to eavesdrop and 1086 learn sensitive information and plan sophisticated attacks on the 1087 network infrastructure. The PCE implementation SHOULD provide 1088 mechanisms to prevent strains created by network flaps and amount of 1089 LS (and TE) information. Thus it is suggested that any mechanism 1090 used for securing the transmission of other PCEP message be applied 1091 here as well. As a general precaution, it is RECOMMENDED that these 1092 PCEP extensions only are activated on authenticated and encrypted 1093 sessions belonging to the same administrative authority. 1095 Further, as stated in [RFC6952], PCEP implementations SHOULD support 1096 the TCP-AO [RFC5925] and not use TCP MD5 because of TCP MD5's known 1097 vulnerabilities and weaknesses. PCEP also support Transport Layer 1098 Security (TLS) [RFC8253] as per the recommendations and best current 1099 practices in [RFC7525]. 1101 12. Manageability Considerations 1103 All manageability requirements and considerations listed in [RFC5440] 1104 apply to PCEP protocol extensions defined in this document. In 1105 addition, requirements, and considerations listed in this section 1106 apply. 1108 12.1. Control of Function and Policy 1110 A PCE or PCC implementation MUST allow configuring the PCEP-LS 1111 capabilities as described in this document. 1113 A PCC implementation SHOULD allow configuration to suggest if remote 1114 information learned via routing protocols should be reported or not. 1116 An implementation SHOULD allow the operator to specify the maximum 1117 number of LS data to be reported. 1119 An implementation SHOULD also allow the operator to create abstracted 1120 topologies that are reported to the peers and create different 1121 abstractions for different peers. 1123 An implementation SHOULD allow the operator to configure a 64-bit 1124 identifier for Routing Universe TLV. 1126 12.2. Information and Data Models 1128 An implementation SHOULD allow the operator to view the LS 1129 capabilities advertised by each peer. To serve this purpose, the 1130 PCEP YANG module [I-D.ietf-pce-pcep-yang] can be extended to include 1131 advertised capabilities. 1133 An implementation SHOULD also provide the statistics: 1135 * Total number of LSRpt sent/received, as well as per neighbor 1137 * Number of errors received for LSRpt, per neighbor 1139 * Total number of locally originated Link-State Information 1141 These statistics should be recorded as absolute counts since system 1142 or session start time. An implementation MAY also enhance this 1143 information by recording peak per-second counts in each case. 1145 An operator SHOULD define an import policy to limit inbound LSRpt to 1146 "drop all LSRpt from a particular peer" as well provide means to 1147 limit inbound LSRpts. 1149 12.3. Liveness Detection and Monitoring 1151 Mechanisms defined in this document do not imply any new liveness 1152 detection and monitoring requirements in addition to those already 1153 listed in [RFC5440]". 1155 12.4. Verify Correct Operations 1157 Mechanisms defined in this document do not imply any new operation 1158 verification requirements in addition to those already listed in 1159 [RFC5440] . 1161 12.5. Requirements On Other Protocols 1163 Mechanisms defined in this document do not imply any new requirements 1164 on other protocols. 1166 12.6. Impact On Network Operations 1168 Mechanisms defined in this document do not have any impact on network 1169 operations in addition to those already listed in [RFC5440]. 1171 13. IANA Considerations 1173 This document requests IANA actions to allocate code points for the 1174 protocol elements defined in this document. 1176 13.1. PCEP Messages 1178 IANA created a registry for "PCEP Messages". Each PCEP message has a 1179 message type value. This document defines a new PCEP message value. 1181 Value Meaning Reference 1182 TBD3 LSRpt [This I-D] 1184 13.2. PCEP Objects 1186 This document defines the following new PCEP Object-classes and 1187 Object-values: 1189 Object-Class Value Name Reference 1190 TBD6 LS Object [This I-D] 1191 Object-Type=1 1192 (LS Node) 1193 Object-Type=2 1194 (LS Link) 1195 Object-Type=3 1196 (LS IPv4 Prefix) 1197 Object-Type=4 1198 (LS IPv6 Prefix) 1200 13.3. LS Object 1202 This document requests that a new sub-registry, named "LS Object 1203 Protocol-ID Field", is created within the "Path Computation Element 1204 Protocol (PCEP) Numbers" registry to manage the Flag field of the LSP 1205 object. New values are to be assigned by Standards Action [RFC8126]. 1207 Value Meaning Reference 1208 0 Reserved [This I-D] 1209 1 IS-IS Level 1 [This I-D] 1210 2 IS-IS Level 2 [This I-D] 1211 3 OSPFv2 [This I-D] 1212 4 Direct [This I-D] 1213 5 Static configuration [This I-D] 1214 6 OSPFv3 [This I-D] 1215 7 BGP [This I-D] 1216 8 RSVP-TE [This I-D] 1217 9 Segment Routing [This I-D] 1218 10 PCEP [This I-D] 1219 11 Abstraction [This I-D] 1220 12-255 Unassigned 1222 Further, this document also requests that a new sub-registry, named 1223 "LS Object Flag Field", is created within the "Path Computation 1224 Element Protocol (PCEP) Numbers" registry to manage the Flag field of 1225 the LSP object.New values are to be assigned by Standards Action 1226 [RFC8126]. Each bit should be tracked with the following qualities: 1228 * Bit number (counting from bit 0 as the most significant bit) 1230 * Capability description 1232 * Defining RFC 1234 The following values are defined in this document: 1236 Bit Description Reference 1237 0-21 Unassigned 1238 22 R (Remove bit) [This I-D] 1239 23 S (Sync bit) [This I-D] 1241 13.4. PCEP-Error Object 1243 IANA is requested to make the following allocation in the "PCEP-ERROR 1244 Object Error Types and Values" registry. 1246 Error-Type Meaning Reference 1247 6 Mandatory Object missing [RFC5440] 1248 Error-Value=TBD4 [This I-D] 1249 (LS object missing) 1251 19 Invalid Operation [RFC8231] 1252 Error-Value=TBD1 [This I-D] 1253 (Attempted LS Report if LS 1254 remote capability was not 1255 advertised) 1257 TBD2 LS Synchronization Error [This I-D] 1258 Error-Value=1 1259 (An error in processing the 1260 LSRpt) 1261 Error-Value=2 1262 (An internal PCC error) 1264 13.5. PCEP TLV Type Indicators 1266 This document defines the following new PCEP TLVs. 1268 Value Meaning Reference 1269 TBD5 LS-CAPABILITY TLV [This I-D] 1270 TBD7 ROUTING-UNIVERSE TLV [This I-D] 1271 TBD15 ROUTE-DISTINGUISHER TLV [This I-D] 1272 TBD8 Local Node Descriptors TLV [This I-D] 1273 TBD9 Remote Node Descriptors TLV [This I-D] 1274 TBD10 Link Descriptors TLV [This I-D] 1275 TBD11 Prefix Descriptors TLV [This I-D] 1276 TBD12 Node Attributes TLV [This I-D] 1277 TBD13 Link Attributes TLV [This I-D] 1278 TBD14 Prefix Attributes TLV [This I-D] 1280 13.6. PCEP-LS Sub-TLV Type Indicators 1282 This document specifies the PCEP-LS Sub-TLVs. IANA is requested to 1283 create an "PCEP-LS Sub-TLV Types" sub-registry for the sub-TLVs 1284 carried in the PCEP-LS TLV (Local and Remote Node Descriptors TLV, 1285 Link Descriptors TLV, Prefix Descriptors TLV, Node Attributes TLV, 1286 Link Attributes TLV and Prefix Attributes TLV. 1288 Allocations from this registry are to be made according to the 1289 following assignment policies [RFC8126]: 1291 Range | Assignment policy 1292 ---------------+--------------------------------------------------- 1293 0 | Reserved - must not be allocated. 1294 | 1295 1 .. 251 | Specification Required 1296 | 1297 252 .. 255 | Experimental Use 1298 | 1299 256 .. 65535 | Reserved - must not be allocated. 1300 | Usage mirrors the BGP-LS TLV registry 1301 | [I-D.ietf-idr-rfc7752bis] 1302 | 1304 IANA is requested to pre-populate this registry with values defined 1305 in this document as follows, taking the new values from the range 1 1306 to 251: 1308 Value | Meaning 1309 -------+------------------------ 1310 1 | SPEAKER-ENTITY-ID 1312 14. TLV Code Points Summary 1314 This section contains the global table of all TLVs in LS object 1315 defined in this document. 1317 +-----------+---------------------+---------------+-----------------+ 1318 | TLV | Description | Ref TLV | Value defined | 1319 | | | | in: | 1320 +-----------+---------------------+---------------+-----------------+ 1321 | TBD7 | Routing Universe | -- | Sec 9.2.1 | 1322 | TBD15 | Route | -- | Sec 9.2.2 | 1323 | | Distinguisher | | | 1324 | * | Virtual Network | -- | [ietf-pce- | 1325 | | | | vn-association] | 1326 | TBD8 | Local Node | 256 | [I-D.ietf-idr- | 1327 | | | | rfc7752bis] | 1328 | | Descriptors | | /3.2.1.2 | 1329 | TBD9 | Remote Node | 257 | [I-D.ietf-idr- | 1330 | | | | rfc7752bis] | 1331 | | Descriptors | | /3.2.1.3 | 1332 | TBD10 | Link Descriptors | -- | Sec 9.2.8 | 1333 | TBD11 | Prefix Descriptors | -- | Sec 9.2.9 | 1334 | TBD12 | Node Attributes | -- | Sec 9.2.10.1 | 1335 | TBD13 | Link Attributes | -- | Sec 9.2.10.2 | 1336 | TBD14 | Prefix Attributes | -- | Sec 9.2.10.3 | 1337 +-----------+---------------------+---------------+-----------------+ 1339 * this TLV is defined in a different PCEP document 1341 Figure 4: TLV Table 1343 15. Implementation Status 1345 The PCEP-LS protocol extensions as described in this I-D were 1346 implemented and tested for a variety of applications. Apart from the 1347 below implementation, there exist other experimental implementations 1348 done for optical networks. 1350 15.1. Hierarchical Transport PCE controllers 1352 The PCEP-LS has been implemented as part of IETF97 Hackathon and 1353 Bits-N-Bites demonstration. The use-case demonstrated was DCI use- 1354 case of ACTN architecture in which to show the following scenarios: 1356 - connectivity services on the ACTN based recursive hierarchical 1357 SDN/PCE platform that has the three-tier level SDN controllers 1358 (two-tier level MDSC and PNC) on the top of the PTN systems 1359 managed by EMS. 1361 - Integration test of two tier-level MDSC: The SBI of the low 1362 level MDSC is the YANG based Korean national standards and the one 1363 of the high-level MDSC the PCEP-LS based ACTN protocols. 1365 - Performance test of three types of SDN controller based recovery 1366 schemes including protection, reactive, and proactive restoration. 1367 PCEP-LS protocol was used to demonstrate a quick report of failed 1368 network components. 1370 15.2. ONOS-based Controller (MDSC and PNC) 1372 Huawei (PNC, MDSC) and SKT (MDSC) implemented PCEP-LS during 1373 Hackathon and IETF97 Bits-N-Bites demonstration. The demonstration 1374 was ONOS-based ACTN architecture in which to show the following 1375 capabilities: 1377 Both packet PNC and optical PNC (with optical PCEP-LS extensions) 1378 implemented PCEP-LS on its SBI as well as its NBI (towards MDSC). 1380 SKT orchestrator (acting as MDSC) also supported PCEP-LS (as well 1381 as RestConf) towards packet and optical PNCs on its SBI. 1383 Further description can be found at ONOS-PCEP 1384 (https://wiki.onosproject.org/display/ONOS/PCEP+Protocol) and the 1385 code at ONOS-PCEP-GITHUB 1386 (https://github.com/opennetworkinglab/onos/tree/master/protocols/ 1387 pcep). 1389 16. Acknowledgments 1391 This document borrows some of the structure and text from the 1392 [I-D.ietf-idr-rfc7752bis]. 1394 Thanks to Eric Wu, Venugopal Kondreddy, Mahendra Singh Negi, 1395 Avantika, and Zhengbin Li for the reviews. 1397 Thanks to Ramon Casellas for his comments and suggestions based on 1398 his implementation experience. 1400 17. References 1402 17.1. Normative References 1404 [I-D.ietf-idr-rfc7752bis] 1405 Talaulikar, K., "Distribution of Link-State and Traffic 1406 Engineering Information Using BGP", Work in Progress, 1407 Internet-Draft, draft-ietf-idr-rfc7752bis-10, 10 November 1408 2021, . 1411 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1412 Requirement Levels", BCP 14, RFC 2119, 1413 DOI 10.17487/RFC2119, March 1997, 1414 . 1416 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1417 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 1418 2008, . 1420 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 1421 in Support of Generalized Multi-Protocol Label Switching 1422 (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, 1423 . 1425 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1426 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1427 DOI 10.17487/RFC5440, March 2009, 1428 . 1430 [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic 1431 Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119, 1432 February 2011, . 1434 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1435 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1436 May 2017, . 1438 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 1439 and D. Dhody, "Optimizations of Label Switched Path State 1440 Synchronization Procedures for a Stateful PCE", RFC 8232, 1441 DOI 10.17487/RFC8232, September 2017, 1442 . 1444 17.2. Informative References 1446 [I-D.ietf-pce-pcep-yang] 1447 Dhody, D., Hardwick, J., Beeram, V. P., and J. Tantsura, 1448 "A YANG Data Model for Path Computation Element 1449 Communications Protocol (PCEP)", Work in Progress, 1450 Internet-Draft, draft-ietf-pce-pcep-yang-18, 25 January 1451 2022, . 1454 [I-D.ietf-pce-vn-association] 1455 Lee, Y., Zheng, H., and D. Ceccarelli, "Path Computation 1456 Element communication Protocol (PCEP) extensions for 1457 Establishing Relationships between sets of LSPs and 1458 Virtual Networks", Work in Progress, Internet-Draft, 1459 draft-ietf-pce-vn-association-05, 15 October 2021, 1460 . 1463 [I-D.ietf-teas-actn-requirements] 1464 Lee, Y., Ceccarelli, D., Miyasaka, T., Shin, J. Y., and K. 1465 Lee, "Requirements for Abstraction and Control of TE 1466 Networks", Work in Progress, Internet-Draft, draft-ietf- 1467 teas-actn-requirements-09, 2 March 2018, 1468 . 1471 [I-D.kondreddy-pce-pcep-ls-sync-optimizations] 1472 Kondreddy, V. R. and M. S. Negi, "Optimizations of PCEP 1473 Link-State(LS) Synchronization Procedures", Work in 1474 Progress, Internet-Draft, draft-kondreddy-pce-pcep-ls- 1475 sync-optimizations-00, 9 October 2015, 1476 . 1479 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 1480 (TE) Extensions to OSPF Version 2", RFC 3630, 1481 DOI 10.17487/RFC3630, September 2003, 1482 . 1484 [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in 1485 Support of Generalized Multi-Protocol Label Switching 1486 (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, 1487 . 1489 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1490 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1491 2006, . 1493 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 1494 Computation Element (PCE)-Based Architecture", RFC 4655, 1495 DOI 10.17487/RFC4655, August 2006, 1496 . 1498 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in 1499 Support of Inter-Autonomous System (AS) MPLS and GMPLS 1500 Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316, 1501 December 2008, . 1503 [RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in 1504 Support of Inter-Autonomous System (AS) MPLS and GMPLS 1505 Traffic Engineering", RFC 5392, DOI 10.17487/RFC5392, 1506 January 2009, . 1508 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1509 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 1510 June 2010, . 1512 [RFC6549] Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 Multi- 1513 Instance Extensions", RFC 6549, DOI 10.17487/RFC6549, 1514 March 2012, . 1516 [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the 1517 Path Computation Element Architecture to the Determination 1518 of a Sequence of Domains in MPLS and GMPLS", RFC 6805, 1519 DOI 10.17487/RFC6805, November 2012, 1520 . 1522 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 1523 BGP, LDP, PCEP, and MSDP Issues According to the Keying 1524 and Authentication for Routing Protocols (KARP) Design 1525 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 1526 . 1528 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1529 "Recommendations for Secure Use of Transport Layer 1530 Security (TLS) and Datagram Transport Layer Security 1531 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1532 2015, . 1534 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1535 Writing an IANA Considerations Section in RFCs", BCP 26, 1536 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1537 . 1539 [RFC8202] Ginsberg, L., Previdi, S., and W. Henderickx, "IS-IS 1540 Multi-Instance", RFC 8202, DOI 10.17487/RFC8202, June 1541 2017, . 1543 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1544 Computation Element Communication Protocol (PCEP) 1545 Extensions for Stateful PCE", RFC 8231, 1546 DOI 10.17487/RFC8231, September 2017, 1547 . 1549 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 1550 "PCEPS: Usage of TLS to Provide a Secure Transport for the 1551 Path Computation Element Communication Protocol (PCEP)", 1552 RFC 8253, DOI 10.17487/RFC8253, October 2017, 1553 . 1555 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 1556 Computation Element Communication Protocol (PCEP) 1557 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 1558 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 1559 . 1561 [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An 1562 Architecture for Use of PCE and the PCE Communication 1563 Protocol (PCEP) in a Network with Central Control", 1564 RFC 8283, DOI 10.17487/RFC8283, December 2017, 1565 . 1567 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 1568 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 1569 DOI 10.17487/RFC8453, August 2018, 1570 . 1572 [RFC8637] Dhody, D., Lee, Y., and D. Ceccarelli, "Applicability of 1573 the Path Computation Element (PCE) to the Abstraction and 1574 Control of TE Networks (ACTN)", RFC 8637, 1575 DOI 10.17487/RFC8637, July 2019, 1576 . 1578 [RFC9168] Dhody, D., Farrel, A., and Z. Li, "Path Computation 1579 Element Communication Protocol (PCEP) Extension for Flow 1580 Specification", RFC 9168, DOI 10.17487/RFC9168, January 1581 2022, . 1583 Appendix A. Examples 1585 These examples are for illustration purposes only to show how the new 1586 PCEP-LS message could be encoded. They are not meant to be an 1587 exhaustive list of all possible use cases and combinations. 1589 A.1. All Nodes 1591 Each node (PCC) in the network chooses to provide its own local node 1592 and link information, and in this way PCE can build the full link- 1593 state and TE information. 1595 +--------------------+ +--------------------+ 1596 | | | | 1597 | RTA |192.0.2.0/24 | RTB | 1598 | 11.11.11.11 |--------------------| 33.33.33.34 | 1599 | Area 0 | 192.0.2.0/24 | Area 0 | 1600 | | | | 1601 +--------------------+ +--------------------+ 1602 RTA 1603 --- 1604 LS Node 1605 TLV - Local Node Descriptors 1606 Sub-TLV - 514: OSPF Area-ID: 0.0.0.0 1607 Sub-TLV - 515: IGP Router-ID: 11.11.11.11 1608 TLV - Node Attributes TLV 1609 Sub-TLV(s) 1611 LS Link 1612 TLV - Local Node Descriptors 1613 Sub-TLV - 514: OSPF Area-ID: 0.0.0.0 1614 Sub-TLV - 515: IGP Router-ID: 11.11.11.11 1615 TLV - Remote Node Descriptors 1616 Sub-TLV - 514: OSPF Area-ID: 0.0.0.0 1617 Sub-TLV - 515: IGP Router-ID: 22.22.22.22 1618 TLV - Link Descriptors 1619 Sub-TLV - 259: IPv4 interface: 192.0.2.1 1620 Sub-TLV - 260: IPv4 neighbor: 192.0.2.2 1621 TLV - Link Attributes TLV 1622 Sub-TLV(s) 1624 RTB 1625 --- 1626 LS Node 1627 TLV - Local Node Descriptors 1628 Sub-TLV - 514: OSPF Area-ID: 0.0.0.0 1629 Sub-TLV - 515: IGP Router-ID: 22.22.22.22 1630 TLV - Node Attributes TLV 1631 Sub-TLV(s) 1633 LS Link 1634 TLV - Local Node Descriptors 1635 Sub-TLV - 514: OSPF Area-ID: 0.0.0.0 1636 Sub-TLV - 515: IGP Router-ID: 22.22.22.22 1637 TLV - Remote Node Descriptors 1638 Sub-TLV - 514: OSPF Area-ID: 0.0.0.0 1639 Sub-TLV - 515: IGP Router-ID: 11.11.11.11 1640 TLV - Link Descriptors 1641 Sub-TLV - 259: IPv4 interface: 192.0.2.2 1642 Sub-TLV - 260: IPv4 neighbor: 192.0.2.1 1643 TLV - Link Attributes TLV 1644 Sub-TLV(s) 1646 A similar example with IPv6 address (say 2001:db8::1 and 2001:db8::2) 1647 for the links could be imagined with all other information as same 1648 and just IPv6 interface and neighbor TLVs. 1650 A.2. Designated Node 1652 A designated node(s) in the network will provide its own local node 1653 as well as all learned remote information, and in this way PCE can 1654 build the full link-state and TE information. 1656 As described in Appendix A.1, the same LS Node and Link objects will 1657 be generated with a difference that it would be a designated router 1658 say RTA that generate all this information. 1660 A.3. Between PCEs 1662 As per Hierarchical-PCE [RFC6805], Parent PCE builds an abstract 1663 domain topology map with each domain as an abstract node and inter- 1664 domain links as an abstract link. Each child PCE may provide this 1665 information to the parent PCE. Considering the example in figure 1 1666 of [RFC6805], following LS object will be generated: 1668 PCE1 1669 ---- 1670 LS Node 1671 TLV - Local Node Descriptors 1672 Sub-TLV - 512: Autonomous System: 100 (Domain 1) 1673 Sub-TLV - 515: IGP Router-ID: 11.11.11.11 (abstract) 1675 LS Link 1676 TLV - Local Node Descriptors 1677 Sub-TLV - 512: Autonomous System: 100 1678 Sub-TLV - 515: IGP Router-ID: 11.11.11.11 (abstract) 1679 TLV - Remote Node Descriptors 1680 Sub-TLV - 512: Autonomous System: 200 (Domain 2) 1681 Sub-TLV - 515: IGP Router-ID: 22.22.22.22 (abstract) 1682 TLV - Link Descriptors 1683 Sub-TLV - 259: IPv4 interface: 192.0.2.1 1684 Sub-TLV - 260: IPv4 neighbor: 192.0.2.2 1685 TLV - Link Attributes TLV 1686 Sub-TLV(s) 1688 LS Link 1689 TLV - Local Node Descriptors 1690 Sub-TLV - 512: Autonomous System: 100 1691 Sub-TLV - 515: IGP Router-ID: 11.11.11.11 (abstract) 1692 TLV - Remote Node Descriptors 1693 Sub-TLV - 512: Autonomous System: 200 1694 Sub-TLV - 515: IGP Router-ID: 22.22.22.22 (abstract) 1695 TLV - Link Descriptors 1696 Sub-TLV - 259: IPv4 interface: 198.51.100.1 1697 Sub-TLV - 260: IPv4 neighbor: 198.51.100.2 1699 TLV - Link Attributes TLV 1700 Sub-TLV(s) 1702 LS Link 1703 TLV - Local Node Descriptors 1704 Sub-TLV - 512: Autonomous System: 100 1705 Sub-TLV - 515: IGP Router-ID: 11.11.11.11 (abstract) 1706 TLV - Remote Node Descriptors 1707 Sub-TLV - 512: Autonomous System: 400 (Domain 4) 1708 Sub-TLV - 515: IGP Router-ID: 44.44.44.44 (abstract) 1709 TLV - Link Descriptors 1710 Sub-TLV - 259: IPv4 interface: 203.0.113.1 1711 Sub-TLV - 260: IPv4 neighbor: 203.0.113.2 1712 TLV - Link Attributes TLV 1713 Sub-TLV(s) 1715 * similar information will be generated by other PCE 1716 to help form the abstract domain topology. 1718 Further the exact border nodes and abstract internal path between the 1719 border nodes may also be transported to the Parent PCE to enable ACTN 1720 as described in [RFC8637] using the similar LS node and link objects 1721 encodings. 1723 Appendix B. Contributor Addresses 1724 Udayasree Palle 1726 EMail: udayasreereddy@gmail.com 1728 Sergio Belotti 1729 Nokia 1731 EMail: sergio.belotti@nokia.com 1733 Satish Karunanithi 1734 Huawei Technologies 1735 Divyashree Techno Park, Whitefield 1736 Bangalore, Karnataka 560066 1737 India 1739 Email: satishk@huawei.com 1741 Cheng Li 1742 Huawei Technologies 1743 Huawei Campus, No. 156 Beiqing Rd. 1744 Beijing 100095 1745 China 1747 Email: c.l@huawei.com 1749 Authors' Addresses 1751 Dhruv Dhody 1752 Huawei Technologies 1753 Divyashree Techno Park, Whitefield 1754 Bangalore 560066 1755 Karnataka 1756 India 1757 Email: dhruv.ietf@gmail.com 1759 Shuping Peng 1760 Huawei Technologies 1761 Huawei Bld., No.156 Beiqing Rd. 1762 Beijing 1763 100095 1764 China 1765 Email: pengshuping@huawei.com 1766 Young Lee 1767 Samsung Electronics 1768 Seoul 1769 South Korea 1770 Email: younglee.tx@gmail.com 1772 Daniele Ceccarelli 1773 Ericsson 1774 Torshamnsgatan,48 1775 Stockholm 1776 Sweden 1777 Email: daniele.ceccarelli@ericsson.com 1779 Aijun Wang 1780 China Telecom 1781 Beiqijia Town, Changping District 1782 Beijing 1783 102209 1784 China 1785 Email: wangaijun@tsinghua.org.cn 1787 Gyan Mishra 1788 Verizon Inc. 1789 Email: gyan.s.mishra@verizon.com 1791 Siva Sivabalan 1792 Ciena Corporation 1793 Email: ssivabal@ciena.com