idnits 2.17.1 draft-dhodylee-pce-pcep-ls-19.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 23 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 5 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 24, 2020) is 1242 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'TBD3' is mentioned on line 529, but not defined == Missing Reference: 'TBD5' is mentioned on line 606, but not defined == Missing Reference: 'This I-D' is mentioned on line 1237, but not defined == Outdated reference: A later version (-17) exists of draft-ietf-idr-rfc7752bis-05 == Outdated reference: A later version (-13) exists of draft-ietf-pce-pcep-flowspec-12 == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-15 == Outdated reference: A later version (-11) exists of draft-ietf-pce-vn-association-03 == 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 (~~), 11 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: May 28, 2021 Y. Lee 6 Samsung Electronics 7 D. Ceccarelli 8 Ericsson 9 A. Wang 10 China Telecom 11 G. Mishra 12 Verizon Inc. 13 November 24, 2020 15 PCEP extensions for Distribution of Link-State and TE Information 16 draft-dhodylee-pce-pcep-ls-19 18 Abstract 20 In order to compute and provide optimal paths, a Path Computation 21 Elements (PCEs) require an accurate and timely Traffic Engineering 22 Database (TED). Traditionally, this TED has been obtained from a 23 link state (LS) routing protocol supporting the traffic engineering 24 extensions. 26 This document extends the Path Computation Element Communication 27 Protocol (PCEP) with Link-State and TE Information. 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 33 "OPTIONAL" in this document are to be interpreted as described in BCP 34 14 [RFC2119] [RFC8174] when, and only when, they appear in all 35 capitals, as shown here. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on May 28, 2021. 54 Copyright Notice 56 Copyright (c) 2020 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (https://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5 74 4. Requirements for PCEP extensions . . . . . . . . . . . . . . 6 75 5. New Functions to distribute link-state (and TE) via PCEP . . 7 76 6. Overview of Extensions to PCEP . . . . . . . . . . . . . . . 7 77 6.1. New Messages . . . . . . . . . . . . . . . . . . . . . . 7 78 6.2. Capability Advertisement . . . . . . . . . . . . . . . . 8 79 6.3. Initial Link-State (and TE) Synchronization . . . . . . . 8 80 6.3.1. Optimizations for LS Synchronization . . . . . . . . 11 81 6.4. LS Report . . . . . . . . . . . . . . . . . . . . . . . . 11 82 7. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 11 83 8. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 12 84 8.1. LS Report Message . . . . . . . . . . . . . . . . . . . . 12 85 8.2. The PCErr Message . . . . . . . . . . . . . . . . . . . . 12 86 9. Objects and TLV . . . . . . . . . . . . . . . . . . . . . . . 13 87 9.1. TLV Format . . . . . . . . . . . . . . . . . . . . . . . 13 88 9.2. Open Object . . . . . . . . . . . . . . . . . . . . . . . 13 89 9.2.1. LS Capability TLV . . . . . . . . . . . . . . . . . . 13 90 9.3. LS Object . . . . . . . . . . . . . . . . . . . . . . . . 14 91 9.3.1. Routing Universe TLV . . . . . . . . . . . . . . . . 16 92 9.3.2. Route Distinguisher TLV . . . . . . . . . . . . . . . 17 93 9.3.3. Virtual Network TLV . . . . . . . . . . . . . . . . . 17 94 9.3.4. Local Node Descriptors TLV . . . . . . . . . . . . . 17 95 9.3.5. Remote Node Descriptors TLV . . . . . . . . . . . . . 18 96 9.3.6. Node Descriptors Sub-TLVs . . . . . . . . . . . . . . 19 97 9.3.7. Link Descriptors TLV . . . . . . . . . . . . . . . . 20 98 9.3.8. Prefix Descriptors TLV . . . . . . . . . . . . . . . 20 99 9.3.9. PCEP-LS Attributes . . . . . . . . . . . . . . . . . 21 100 9.3.9.1. Node Attributes TLV . . . . . . . . . . . . . . . 21 101 9.3.9.2. Link Attributes TLV . . . . . . . . . . . . . . . 21 102 9.3.9.3. Prefix Attributes TLV . . . . . . . . . . . . . . 22 103 9.3.10. Removal of an Attribute . . . . . . . . . . . . . . . 22 104 10. Other Considerations . . . . . . . . . . . . . . . . . . . . 23 105 10.1. Inter-AS Links . . . . . . . . . . . . . . . . . . . . . 23 106 11. Security Considerations . . . . . . . . . . . . . . . . . . . 23 107 12. Manageability Considerations . . . . . . . . . . . . . . . . 23 108 12.1. Control of Function and Policy . . . . . . . . . . . . . 23 109 12.2. Information and Data Models . . . . . . . . . . . . . . 24 110 12.3. Liveness Detection and Monitoring . . . . . . . . . . . 24 111 12.4. Verify Correct Operations . . . . . . . . . . . . . . . 24 112 12.5. Requirements On Other Protocols . . . . . . . . . . . . 25 113 12.6. Impact On Network Operations . . . . . . . . . . . . . . 25 114 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 115 13.1. PCEP Messages . . . . . . . . . . . . . . . . . . . . . 25 116 13.2. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 25 117 13.3. LS Object . . . . . . . . . . . . . . . . . . . . . . . 25 118 13.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . 26 119 13.5. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 27 120 13.6. PCEP-LS Sub-TLV Type Indicators . . . . . . . . . . . . 27 121 14. TLV Code Points Summary . . . . . . . . . . . . . . . . . . . 28 122 15. Implementation Status . . . . . . . . . . . . . . . . . . . . 29 123 15.1. Hierarchical Transport PCE controllers . . . . . . . . . 29 124 15.2. ONOS-based Controller (MDSC and PNC) . . . . . . . . . . 30 125 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 126 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 127 17.1. Normative References . . . . . . . . . . . . . . . . . . 30 128 17.2. Informative References . . . . . . . . . . . . . . . . . 31 129 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 35 130 A.1. All Nodes . . . . . . . . . . . . . . . . . . . . . . . . 35 131 A.2. Designated Node . . . . . . . . . . . . . . . . . . . . . 36 132 A.3. Between PCEs . . . . . . . . . . . . . . . . . . . . . . 36 133 Appendix B. Contributor Addresses . . . . . . . . . . . . . . . 38 134 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 136 1. Introduction 138 In Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS), 139 a Traffic Engineering Database (TED) is used in computing paths for 140 connection-oriented packet services and for circuits. The TED 141 contains all relevant information that a Path Computation Element 142 (PCE) needs to perform its computations. It is important that the 143 TED be 'complete and accurate' each time the PCE performs a path 144 computation. 146 In MPLS and GMPLS, interior gateway routing protocols (Interior 147 Gateway Protocol (IGPs)) have been used to create and maintain a copy 148 of the TED at each node running the IGP. One of the benefits of the 149 PCE architecture [RFC4655] is the use of computationally more 150 sophisticated path computation algorithms and the realization that 151 these may need enhanced processing power (not necessarily available 152 at each node). 154 Section 4.3 of [RFC4655] describes the potential load of the TED on a 155 network node and proposes an architecture where the TED is maintained 156 by the PCE rather than the network nodes. However, it does not 157 describe how a PCE would obtain the information needed to populate 158 its TED. PCE may construct its TED by participating in the IGP 159 ([RFC3630] and [RFC5305] for MPLS-TE; [RFC4203] and [RFC5307] for 160 GMPLS). An alternative mechanism is offered by BGP-LS 161 [I-D.ietf-idr-rfc7752bis] . 163 [RFC8231] describes a set of extensions to PCEP to provide stateful 164 control. A stateful PCE has access to not only the information 165 carried by the network's IGP, but also the set of active paths and 166 their reserved resources for its computations. Path Computation 167 Client (PCC) can delegate the rights to modify the LSP parameters to 168 an Active Stateful PCE. This requires PCE to quickly be updated on 169 any changes in the topology/TED, so that PCE can meet the need for 170 updating LSPs effectively and in a timely manner. The fastest way 171 for a PCE to be updated on TED changes is via a direct session with 172 each network node and with an incremental update from each network 173 node with only the attributes that gets modified. 175 [RFC8281] describes the setup, maintenance, and teardown of PCE- 176 initiated LSPs under the stateful PCE model, without the need for 177 local configuration on the PCC, thus allowing for a dynamic network 178 that is centrally controlled and deployed. This model requires 179 timely topology and TED update at the PCE. 181 [RFC5440] describes the specifications for the Path Computation 182 Element Communication Protocol (PCEP). PCEP specifies the 183 communication between a PCC and a PCE, or between two PCEs based on 184 the PCE architecture [RFC4655]. 186 This document describes a mechanism by which link-state and TE 187 information can be collected from networks and shared with PCE using 188 the PCEP itself. This is achieved using a new PCEP message format. 189 The mechanism is applicable to physical and virtual links as well as 190 further subjected to various policies. 192 A network node maintains one or more databases for storing link-state 193 and TE information about nodes and links in any given area. Link 194 attributes stored in these databases include: local/remote IP 195 addresses, local/remote interface identifiers, link metric, and TE 196 metric, link bandwidth, reservable bandwidth, per CoS class 197 reservation state, preemption, and Shared Risk Link Groups (SRLG). 198 The node's PCEP process can retrieve topology from these databases 199 and distribute it to a PCE, either directly or via another PCEP 200 Speaker, using the encoding specified in this document. 202 Further [RFC6805] describes Hierarchical-PCE architecture, where a 203 parent PCE maintains a domain topology map. To build this domain 204 topology map, the child PCE can carry the border nodes and inter- 205 domain link information to the parent PCE using the mechanism 206 described in this document. Further as described in [RFC8637], the 207 child PCE can also transport abstract Link-State and TE information 208 from child PCE to a Parent PCE using the mechanism described in this 209 document to build an abstract topology at the parent PCE. 211 [RFC8231] describe LSP state synchronization between PCCs and PCEs in 212 case of stateful PCE. This document does not make any change to the 213 LSP state synchronization process. The mechanism described in this 214 document are on top of the existing LSP state synchronization. 216 2. Terminology 218 The terminology is as per [RFC4655] and [RFC5440]. 220 3. Applicability 222 The mechanism specified in this draft is applicable to deployments: 224 o Where there is no IGP or BGP-LS running in the network. 226 o Where there is no IGP or BGP-LS running at the PCE to learn link- 227 state and TE information. 229 o Where there is IGP or BGP-LS running but with a need for a faster 230 and direct TE and link-state population and convergence at the 231 PCE. 233 * A PCE may receive partial information (say basic TE, link- 234 state) from IGP and other information (optical and impairment) 235 from PCEP. 237 * A PCE may receive an incremental update (as opposed to the full 238 (entire) information of the node/link). 240 * A PCE may receive full information from both existing 241 mechanisms (IGP or BGP-LS) and PCEP. 243 o Where there is a need for transporting (abstract) Link-State and 244 TE information from child PCE to a Parent PCE in H-PCE [RFC6805]; 245 as well as for Provisioning Network Controller (PNC) to Multi- 246 Domain Service Coordinator (MDSC) in Abstraction and Control of TE 247 Networks (ACTN) [RFC8453]. 249 o Where there is an existing PCEP session between all the nodes and 250 the PCE-based central controller (PCECC) [RFC8283], and the 251 operator would like to use PCEP as direct southbound interface to 252 all the nodes in the network. This enables the operator to use 253 PCEP as a single direct protocol between the controller and all 254 the nodes in the network. In this mode, all nodes send only the 255 local information. 257 Based on the local policy and deployment scenario, a PCC chooses to 258 send only local information or both local and remote learned 259 information. How a PCE manages the link-state (and TE) information 260 is implementation specific and thus out of the scope of this 261 document. 263 The prefix information in PCEP-LS can also help in determining the 264 domain of the tunnel destination in the H-PCE (and ACTN) scenario. 265 Section 4.5 of [RFC6805] describe various mechanisms and procedures 266 that might be used, PCEP-LS provides a simple mechanism to exchange 267 this information within PCEP. 269 [RFC8453] defines three types of topology abstraction - (1) Native/ 270 White Topology; (2) Black Topology; and (3) Grey Topology. Based on 271 the local policy, the PNC (or child PCE) would share the domain 272 topology to the MDSC (or Parent PCE) based on the abstraction type. 273 The protocol extensions defined in this document can carry any type 274 of topology abstraction. 276 4. Requirements for PCEP extensions 278 Following key requirements associated with link-state (and TE) 279 distribution are identified for PCEP: 281 1. The PCEP speaker supporting this draft MUST have a mechanism to 282 advertise the Link-State (and TE) distribution capability. 284 2. PCC supporting this draft MUST have the capability to report the 285 link-state (and TE) information to the PCE. This MUST include 286 self originated (local) information and also allow remote 287 information learned via routing protocols. PCC MUST be capable 288 to do the initial bulk sync at the time of session initialization 289 as well as changes after. 291 3. A PCE MAY learn link-state (and TE) from PCEP as well as from 292 existing mechanisms like IGP/BGP-LS. PCEP extensions MUST have a 293 mechanism to link the information learned via other means. There 294 MUST NOT be any changes to the existing link-state (and TE) 295 population mechanism via IGP/BGP-LS. PCEP extension SHOULD keep 296 the properties in a protocol (IGP or BGP-LS) neutral way, such 297 that an implementation may not need to know about any OSPF or IS- 298 IS or BGP protocol specifics. 300 4. It SHOULD be possible to encode only the changes in link-state 301 (and TE) properties (after the initial sync) in PCEP messages. 302 This leads to faster convergence. 304 5. The same mechanism SHOULD be used for both MPLS TE as well as 305 GMPLS, optical, and impairment aware properties. 307 6. The same mechanism SHOULD be used for PCE to PCE Link-state (and 308 TE) synchronization. 310 5. New Functions to distribute link-state (and TE) via PCEP 312 Several new functions are required in PCEP to support distribution of 313 link-state (and TE) information. A function can be initiated either 314 from a PCC towards a PCE (C-E) or from a PCE towards a PCC (E-C). 315 The new functions are: 317 o Capability advertisement (E-C,C-E): both the PCC and the PCE MUST 318 announce during PCEP session establishment that they support PCEP 319 extensions for distribution of link-state (and TE) information 320 defined in this document. 322 o Link-State (and TE) synchronization (C-E): after the session 323 between the PCC and a PCE is initialized, the PCE must learn Link- 324 State (and TE) information before it can perform path 325 computations. In the case of stateful PCE it is RECOMMENDED that 326 this operation be done before LSP state synchronization. 328 o Link-State (and TE) Report (C-E): a PCC sends an LS (and TE) 329 report to a PCE whenever the Link-State and TE information 330 changes. 332 6. Overview of Extensions to PCEP 334 6.1. New Messages 336 In this document, we define a new PCEP message called LS Report 337 (LSRpt), a PCEP message sent by a PCC to a PCE to report link-state 338 (and TE) information. Each LS Report in an LSRpt message can contain 339 the node or link properties. A unique PCEP specific LS identifier 340 (LS-ID) is also carried in the message to identify a node or link and 341 that remains constant for the lifetime of a PCEP session. This 342 identifier on its own is sufficient when no IGP or BGP-LS running in 343 the network for PCE to learn link-state (and TE) information. In 344 case PCE learns some information from PCEP and some from the existing 345 mechanism, the PCC SHOULD include the mapping of IGP or BGP-LS 346 identifier to map the information populated via PCEP with IGP/BGP-LS. 347 See Section 8.1 for details. 349 6.2. Capability Advertisement 351 During PCEP Initialization Phase, PCEP Speakers (PCE or PCC) 352 advertise their support of LS (and TE) distribution via PCEP 353 extensions. A PCEP Speaker includes the "LS Capability" TLV, 354 described in Section 9.2.1, in the OPEN Object to advertise its 355 support for PCEP-LS extensions. The presence of the LS Capability 356 TLV in PCC's OPEN Object indicates that the PCC is willing to send LS 357 Reports with local link-state (and TE) information. The presence of 358 the LS Capability TLV in PCE's Open message indicates that the PCE is 359 interested in receiving LS Reports with local link-state (and TE) 360 information. 362 The PCEP extensions for LS (and TE) distribution MUST NOT be used if 363 one or both PCEP Speakers have not included the LS Capability TLV in 364 their respective OPEN message. If the PCE that supports the 365 extensions of this draft but did not advertise this capability, then 366 upon receipt of an LSRpt message from the PCC, it SHOULD generate a 367 PCErr with error-type 19 (Invalid Operation), error-value TBD1 368 (Attempted LS Report if LS capability was not advertised) and it will 369 terminate the PCEP session. 371 The LS reports sent by PCC MAY carry the remote link-state (and TE) 372 information learned via existing means like IGP and BGP-LS only if 373 both PCEP Speakers set the R (remote) Flag in the "LS Capability" TLV 374 to 'Remote Allowed (R Flag = 1)'. If this is not the case and LS 375 reports carry remote link-state (and TE) information, then a PCErr 376 with error-type 19 (Invalid Operation) and error-value TBD1 377 (Attempted LS Report if LS remote capability was not advertised) and 378 it will terminate the PCEP session. 380 6.3. Initial Link-State (and TE) Synchronization 382 The purpose of LS Synchronization is to provide a checkpoint-in-time 383 state replica of a PCC's link-state (and TE) database in a PCE. 384 State Synchronization is performed immediately after the 385 Initialization phase (see [RFC5440]). In case of stateful PCE 386 ([RFC8231]) it is RECOMMENDED that the LS synchronization should be 387 done before LSP state synchronization. 389 During LS Synchronization, a PCC first takes a snapshot of the state 390 of its database, then sends the snapshot to a PCE in a sequence of LS 391 Reports. Each LS Report sent during LS Synchronization has the SYNC 392 Flag in the LS Object set to 1. The end of synchronization marker is 393 an LSRpt message with the SYNC Flag set to 0 for an LS Object with 394 LS-ID equal to the reserved value 0. If the PCC has no link-state to 395 synchronize, it will only send the end of synchronization marker. 397 Either the PCE or the PCC MAY terminate the session using the PCEP 398 session termination procedures during the synchronization phase. If 399 the session is terminated, the PCE MUST clean up the state it 400 received from this PCC. The session re-establishment MUST be re- 401 attempted per the procedures defined in [RFC5440], including the use 402 of a back-off timer. 404 If the PCC encounters a problem which prevents it from completing the 405 LS synchronization, it MUST send a PCErr message with error-type TBD2 406 (LS Synchronization Error) and error-value 2 (indicating an internal 407 PCC error) to the PCE and terminate the session. 409 The PCE does not send positive acknowledgments for properly received 410 LS synchronization messages. It MUST respond with a PCErr message 411 with error-type TBD2 (LS Synchronization Error) and error-value 1 412 (indicating an error in processing the LSRpt) if it encounters a 413 problem with the LS Report it received from the PCC and it MUST 414 terminate the session. 416 The LS reports can carry local as well as remote link-state (and TE) 417 information depending on the R flag in LS capability TLV. 419 The successful LS Synchronization sequence is shown in Figure 1. 421 +-+-+ +-+-+ 422 |PCC| |PCE| 423 +-+-+ +-+-+ 424 | | 425 |-----LSRpt, SYNC=1----->| (Sync start) 426 | | 427 |-----LSRpt, SYNC=1----->| 428 | . | 429 | . | 430 | . | 431 |-----LSRpt, SYNC=1----->| 432 | . | 433 | . | 434 | . | 435 | | 436 |-----LSRpt, SYNC=0----->| (End of sync marker 437 | | LS Report 438 | | for LS-ID=0) 439 | | (Sync done) 441 Figure 1: Successful LS synchronization 443 The sequence where the PCE fails during the LS Synchronization phase 444 is shown in Figure 2. 446 +-+-+ +-+-+ 447 |PCC| |PCE| 448 +-+-+ +-+-+ 449 | | 450 |-----LSRpt, SYNC=1----->| 451 | | 452 |-----LSRpt, SYNC=1----->| 453 | . | 454 | . | 455 | . | 456 |-----LSRpt, SYNC=1----->| 457 | | 458 |---LSRpt,SYNC=1 | 459 | \ ,-PCErr---| 460 | \ / | 461 | \/ | 462 | /\ | 463 | / `-------->| (Ignored) 464 |<--------` | 466 Figure 2: Failed LS synchronization (PCE failure) 468 The sequence where the PCC fails during the LS Synchronization phase 469 is shown in Figure 3. 471 +-+-+ +-+-+ 472 |PCC| |PCE| 473 +-+-+ +-+-+ 474 | | 475 |-----LSRpt, SYNC=1----->| 476 | | 477 |-----LSRpt, SYNC=1----->| 478 | . | 479 | . | 480 | . | 481 |-------- PCErr--------->| 482 | | 484 Figure 3: Failed LS synchronization (PCC failure) 486 6.3.1. Optimizations for LS Synchronization 488 These optimizations are described in 489 [I-D.kondreddy-pce-pcep-ls-sync-optimizations]. 491 6.4. LS Report 493 The PCC MUST report any changes in the link-state (and TE) 494 information to the PCE by sending an LS Report carried on an LSRpt 495 message to the PCE. Each node and Link would be uniquely identified 496 by a PCEP LS identifier (LS-ID). The LS reports may carry local as 497 well as remote link-state (and TE) information depending on the R 498 flag in LS capability TLV. In case the R flag is set, it MAY also 499 include the mapping of IGP or BGP-LS identifier to map the 500 information populated via PCEP with IGP/BGP-LS identifiers. 502 More details about the LSRpt message are in Section 8.1. 504 7. Transport 506 A permanent PCEP session (section 4.2.8 of [RFC5440]) MUST be 507 established between a PCE and PCC supporting link-state (and TE) 508 distribution via PCEP. In the case of session failure, session re- 509 establishment is re-attempted as per the procedures defined in 510 [RFC5440]. 512 8. PCEP Messages 514 As defined in [RFC5440], a PCEP message consists of a common header 515 followed by a variable-length body made of a set of objects that can 516 be either mandatory or optional. An object is said to be mandatory 517 in a PCEP message when the object must be included for the message to 518 be considered valid. For each PCEP message type, a set of rules is 519 defined that specify the set of objects that the message can carry. 520 An implementation MUST form the PCEP messages using the object 521 ordering specified in this document. 523 8.1. LS Report Message 525 A PCEP LS Report message (also referred to as LSRpt message) is a 526 PCEP message sent by a PCC to a PCE to report the link-state (and TE) 527 information. An LSRpt message can carry more than one LS Reports (LS 528 object). The Message-Type field of the PCEP common header for the 529 LSRpt message is set to [TBD3]. 531 The format of the LSRpt message is as follows: 533 ::= 534 535 Where: 537 ::= [] 539 The LS object is a mandatory object which carries LS information of a 540 node/prefix or a link. Each LS object has a unique LS-ID as 541 described in Section 9.3. If the LS object is missing, the receiving 542 PCE MUST send a PCErr message with Error-type=6 (Mandatory Object 543 missing) and Error-value=[TBD4] (LS object missing). 545 A PCE may choose to implement a limit on the LS information a single 546 PCC can populate. If an LSRpt is received that causes the PCE to 547 exceed this limit, it MUST send a PCErr message with error-type 19 548 (invalid operation) and error-value 4 (indicating resource limit 549 exceeded) in response to the LSRpt message triggering this condition 550 and SHOULD terminate the session. 552 8.2. The PCErr Message 554 If a PCEP speaker has advertised the LS capability on the PCEP 555 session, the PCErr message MAY include the LS object. If the error 556 reported is the result of an LS report, then the LS-ID number MUST be 557 the one from the LSRpt that triggered the error. 559 The format of a PCErr message from [RFC5440] is extended as follows: 561 ::= 562 ( [] ) | 563 [] 565 ::=[] 567 ::=[ | ] 568 570 ::=[] 572 ::=[] 574 ::=[] 576 9. Objects and TLV 578 The PCEP objects defined in this document are compliant with the PCEP 579 object format defined in [RFC5440]. The P flag and the I flag of the 580 PCEP objects defined in this document MUST always be set to 0 on 581 transmission and MUST be ignored on receipt since these flags are 582 exclusively related to path computation requests. 584 9.1. TLV Format 586 The TLV and the sub-TLV format (and padding) in this document, is as 587 per section 7.1 of [RFC5440]. 589 9.2. Open Object 591 This document defines a new optional TLV for use in the OPEN Object. 593 9.2.1. LS Capability TLV 595 The LS-CAPABILITY TLV is an optional TLV for use in the OPEN Object 596 for link-state (and TE) distribution via PCEP capability 597 advertisement. Its format is shown in the following figure: 599 0 1 2 3 600 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 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | Type=[TBD5] | Length=4 | 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 | Flags |R| 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 The type of the TLV is [TBD5] and it has a fixed length of 4 octets. 608 The value comprises a single field - Flags (32 bits): 610 o R (remote allowed - 1 bit): if set to 1 by a PCC, the R Flag 611 indicates that the PCC allows reporting of remote LS information 612 learned via other means like IGP and BGP-LS; if set to 1 by a PCE, 613 the R Flag indicates that the PCE is capable of receiving remote 614 LS information (from the PCC point of view). The R Flag must be 615 advertised by both PCC and PCE for LSRpt messages to report remote 616 as well as local LS information on a PCEP session. The TLVs 617 related to IGP/BGP-LS identifier MUST be encoded when both PCEP 618 speakers have the R Flag set. 620 Unassigned bits are considered reserved. They MUST be set to 0 on 621 transmission and MUST be ignored on receipt. 623 Advertisement of the LS capability implies support of local link- 624 state (and TE) distribution, as well as the objects, TLVs and 625 procedures defined in this document. 627 9.3. LS Object 629 The LS (link-state) object MUST be carried within LSRpt messages and 630 MAY be carried within PCErr messages. The LS object contains a set 631 of fields used to specify the target node or link. It also contains 632 a flag indicating to a PCE that the LS synchronization is in 633 progress. The TLVs used with the LS object correlate with the IGP/ 634 BGP-LS encodings. 636 LS Object-Class is TBD6. 638 Four Object-Type values are defined for the LS object so far: 640 o LS Node: LS Object-Type is 1. 642 o LS Link: LS Object-Type is 2. 644 o LS IPv4 Topology Prefix: LS Object-Type is 3. 646 o LS IPv6 Topology Prefix: LS Object-Type is 4. 648 The format of all types of LS object is as follows: 650 0 1 2 3 651 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 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | Protocol-ID | Flag |R|S| 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | LS-ID | 656 | | 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 // TLVs // 659 | | 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 Protocol-ID (8-bit): The field provides the source information. The 663 protocol could be an IGP, BGP-LS, or an abstraction algorithm. In 664 case PCC only provides local information of the PCC, it MUST use 665 Protocol-ID as Direct. The following values are defined (some of the 666 initial values are the same as [I-D.ietf-idr-rfc7752bis]): 668 +-------------+----------------------------------+ 669 | Protocol-ID | Source protocol | 670 +-------------+----------------------------------+ 671 | 1 | IS-IS Level 1 | 672 | 2 | IS-IS Level 2 | 673 | 3 | OSPFv2 | 674 | 4 | Direct | 675 | 5 | Static configuration | 676 | 6 | OSPFv3 | 677 | 7 | BGP | 678 | 8 | RSVP-TE | 679 | 9 | Segment Routing | 680 | 10 | PCEP | 681 | 11 | Abstraction | 682 +-------------+----------------------------------+ 684 Flags (24-bit): 686 o S (SYNC - 1 bit): the S Flag MUST be set to 1 on each LSRpt sent 687 from a PCC during LS Synchronization. The S Flag MUST be set to 0 688 in other LSRpt messages sent from the PCC. 690 o R (Remove - 1 bit): On LSRpt messages, the R Flag indicates that 691 the node/link/prefix has been removed from the PCC and the PCE 692 SHOULD remove from its database. Upon receiving an LS Report with 693 the R Flag set to 1, the PCE SHOULD remove all state for the 694 node/link/prefix identified by the LS Identifiers from its 695 database. 697 LS-ID(64-bit): A PCEP-specific identifier for the node, link, or 698 prefix information. A PCC creates a unique LS-ID for each node/link/ 699 prefix that is constant for the lifetime of a PCEP session. The PCC 700 will advertise the same LS-ID on all PCEP sessions it maintains at a 701 given time. All subsequent PCEP messages then address the node/link/ 702 prefix by the LS-ID. The values of 0 and 0xFFFFFFFFFFFFFFFF are 703 reserved. 705 Unassigned bits are considered reserved. They MUST be set to 0 on 706 transmission and MUST be ignored on receipt. 708 TLVs that may be included in the LS Object are described in the 709 following sections. 711 9.3.1. Routing Universe TLV 713 In the case of remote link-state (and TE) population when existing 714 IGP/BGP-LS are also used, OSPF and IS-IS may run multiple routing 715 protocol instances over the same link as described in 716 [I-D.ietf-idr-rfc7752bis]. See [RFC8202] and [RFC6549] for more 717 information. These instances define an independent "routing 718 universe". The 64-bit 'Identifier' field is used to identify the 719 "routing universe" where the LS object belongs. The LS objects 720 representing IGP objects (nodes or links or prefix) from the same 721 routing universe MUST have the same 'Identifier' value; LS objects 722 with different 'Identifier' values MUST be considered to be from 723 different routing universes. 725 The format of the optional ROUTING-UNIVERSE TLV is shown in the 726 following figure: 728 0 1 2 3 729 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 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 | Type=[TBD7] | Length=8 | 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 | Identifier | 734 | | 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 The below table lists the 'Identifier' values that are defined as 738 well-known in this draft (same as [I-D.ietf-idr-rfc7752bis]). 740 +------------+-----------------------------------+ 741 | Identifier | Routing Universe | 742 +------------+-----------------------------------+ 743 | 0 | Default Layer 3 Routing topology | 744 +------------+-----------------------------------+ 746 If this TLV is not present the default value 0 is assumed. 748 9.3.2. Route Distinguisher TLV 750 To allow identification of VPN link, node, and prefix information in 751 PCEP-LS, a Route Distinguisher (RD) [RFC4364] is used. The LS 752 objects from the same VPN MUST have the same RD; LS objects with 753 different RD values MUST be considered to be from different VPNs. 755 The ROUTE-DISTINGUISHER TLV is defined in 756 [I-D.ietf-pce-pcep-flowspec] as a Flow Specification TLVs with a 757 seperate registry. This document also adds the ROUTE-DISTINGUISHER 758 TLV with TBD15 in the PCEP TLV registry to be used inside the LS 759 object. 761 9.3.3. Virtual Network TLV 763 To realize ACTN, the MDSC needs to build a multi-domain topology. 764 This topology is best served if this is an abstracted view of the 765 underlying network resources of each domain. It is also important to 766 provide a customer view of the network slice for each customer. 767 There is a need to control the level of abstraction based on the 768 deployment scenario and business relationship between the 769 controllers. 771 Virtual service coordination function in ACTN incorporates customer 772 service-related knowledge into the virtual network operations in 773 order to seamlessly operate virtual networks while meeting customer's 774 service requirements. [I-D.ietf-teas-actn-requirements] describes 775 various VN operations initiated by a customer/application. In this 776 context, there is a need for associating the abstracted link-state 777 and TE topology with a VN "construct" to facilitate VN operations in 778 PCE architecture. 780 VIRTUAL-NETWORK-TLV as per [I-D.ietf-pce-vn-association] can be 781 included in LS object to identify the link, node, and prefix 782 information belongs to a particular VN. 784 9.3.4. Local Node Descriptors TLV 786 As described in [I-D.ietf-idr-rfc7752bis], each link is anchored by a 787 pair of Router-IDs that are used by the underlying IGP, namely, 788 48-bit ISO System-ID for IS-IS and 32-bit Router-ID for OSPFv2 and 789 OSPFv3. In case of additional auxiliary Router-IDs used for TE, 790 these MUST also be included in the link attribute TLV (see 791 Section 9.3.9.2). 793 It is desirable that the Router-ID assignments inside the Node 794 Descriptors TLV are globally unique. Some considerations for 795 globally unique Node/Link/Prefix identifiers are described in 796 [I-D.ietf-idr-rfc7752bis]. 798 The Local Node Descriptors TLV contains Node Descriptors for the node 799 anchoring the local end of the link. This TLV MUST be included in 800 the LS Report when during a given PCEP session a node/link/prefix is 801 first reported to a PCE. A PCC sends to a PCE the first LS Report 802 either during State Synchronization, or when a new node/link/prefix 803 is learned at the PCC. The value contains one or more Node 804 Descriptor Sub-TLVs, which allows the specification of a flexible key 805 for any given node/link/prefix information such that the global 806 uniqueness of the node/link/prefix is ensured. 808 This TLV is applicable for all LS Object-Type. 810 0 1 2 3 811 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 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 | Type=[TBD8] | Length | 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 | | 816 // Node Descriptor Sub-TLVs (variable) // 817 | | 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 The value contains one or more Node Descriptor Sub-TLVs defined in 821 Section 9.3.6. 823 9.3.5. Remote Node Descriptors TLV 825 The Remote Node Descriptors contain Node Descriptors for the node 826 anchoring the remote end of the link. This TLV MUST be included in 827 the LS Report when during a given PCEP session a link is first 828 reported to a PCE. A PCC sends to a PCE the first LS Report either 829 during State Synchronization, or when a new link is learned at the 830 PCC. The length of this TLV is variable. The value contains one or 831 more Node Descriptor Sub-TLVs defined in Section 9.3.6. 833 This TLV is applicable for LS Link Object-Type. 835 0 1 2 3 836 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 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 838 | Type=[TBD9] | Length | 839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 | | 841 // Node Descriptor Sub-TLVs (variable) // 842 | | 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 9.3.6. Node Descriptors Sub-TLVs 847 The Node Descriptors TLV (Local and Remote) carries one or more Node 848 Descriptor Sub-TLV follows the format of all PCEP TLVs as defined in 849 [RFC5440], however, the Type values are selected from a new PCEP-LS 850 sub-TLV IANA registry (see Section 13.6). 852 Type values are chosen so that there can be commonality with BGP-LS 853 [I-D.ietf-idr-rfc7752bis]. This is possible because the "BGP-LS Node 854 Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs" 855 registry marks 0-255 as reserved. Thus the space of the sub-TLV 856 values for the Type field can be partitioned as shown below - 858 Range | 859 ---------------+--------------------------------------------- 860 0 | Reserved - must not be allocated. 861 | 862 1 .. 255 | New PCEP sub-TLV allocated according to the 863 | registry defined in this document. 864 | 865 256 .. 65535 | Per BGP registry defined by 866 | [I-D.ietf-idr-rfc7752bis]. 867 | Not to be allocated in this registry. 869 All Node Descriptors TLVs defined for BGP-LS can then be used with 870 PCEP-LS as well. One new PCEP sub-TLVs for Node Descriptor are 871 defined in this document. 873 +----------+-------------------+----------+----------------+ 874 | Sub-TLV | Description | Length |Value defined in| 875 +----------+-------------------+----------+----------------+ 876 | 1 | SPEAKER-ENTITY-ID | Variable | [RFC8232] | 877 +----------+-------------------+----------+----------------+ 879 A new sub-TLV type (1) is allocated for SPEAKER-ENTITY-ID sub-TLV. 880 The length and value fields are as per [RFC8232]. 882 9.3.7. Link Descriptors TLV 884 The Link Descriptors TLV contains Link Descriptors for each link. 885 This TLV MUST be included in the LS Report when during a given PCEP 886 session a link is first reported to a PCE. A PCC sends to a PCE the 887 first LS Report either during State Synchronization, or when a new 888 link is learned at the PCC. The length of this TLV is variable. The 889 value contains one or more Link Descriptor Sub-TLVs. 891 The 'Link descriptor' TLVs uniquely identify a link among multiple 892 parallel links between a pair of anchor routers similar to 893 [I-D.ietf-idr-rfc7752bis]. 895 This TLV is applicable for LS Link Object-Type. 897 0 1 2 3 898 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 899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 | Type=[TBD10] | Length | 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 | | 903 // Link Descriptor Sub-TLVs (variable) // 904 | | 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 907 All Link Descriptors TLVs defined for BGP-LS can then be used with 908 PCEP-LS as well. No new PCEP sub-TLVs for Link Descriptor are 909 defined in this document. 911 The format and semantics of the 'value' fields in most 'Link 912 Descriptor' sub-TLVs correspond to the format and semantics of value 913 fields in IS-IS Extended IS Reachability sub-TLVs, defined in 914 [RFC5305], [RFC5307] and [RFC6119]. Although the encodings for 'Link 915 Descriptor' TLVs were originally defined for IS-IS, the TLVs can 916 carry data sourced either by IS-IS or OSPF or direct. 918 The information about a link present in the LSA/LSP originated by the 919 local node of the link determines the set of sub-TLVs in the Link 920 Descriptor of the link as described in [I-D.ietf-idr-rfc7752bis]. 922 9.3.8. Prefix Descriptors TLV 924 The Prefix Descriptors TLV contains Prefix Descriptors that uniquely 925 identify an IPv4 or IPv6 Prefix originated by a Node. This TLV MUST 926 be included in the LS Report when during a given PCEP session a 927 prefix is first reported to a PCE. A PCC sends to a PCE the first LS 928 Report either during State Synchronization, or when a new prefix is 929 learned at the PCC. The length of this TLV is variable. 931 This TLV is applicable for LS Prefix Object-Types for both IPv4 and 932 IPv6. 934 0 1 2 3 935 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 936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 937 | Type=[TBD11] | Length | 938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 939 | | 940 // Prefix Descriptor Sub-TLVs (variable) // 941 | | 942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 944 All Prefix Descriptors TLVs defined for BGP-LS can then be used with 945 PCEP-LS as well. No new PCEP sub-TLVs for Prefix Descriptor are 946 defined in this document. 948 9.3.9. PCEP-LS Attributes 950 9.3.9.1. Node Attributes TLV 952 This is an optional attribute that is used to carry node attributes. 953 This TLV is applicable for LS Node Object-Type. 955 0 1 2 3 956 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 957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 958 | Type=[TBD12] | Length | 959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 960 | | 961 // Node Attributes Sub-TLVs (variable) // 962 | | 963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 965 All Node Attributes TLVs defined for BGP-LS can then be used with 966 PCEP-LS as well. No new PCEP sub-TLVs for Node Attributes are 967 defined in this document. 969 9.3.9.2. Link Attributes TLV 971 This TLV is applicable for LS Link Object-Type. The format and 972 semantics of the 'value' fields in some 'Link Attribute' sub-TLVs 973 correspond to the format and semantics of the 'value' fields in IS-IS 974 Extended IS Reachability sub-TLVs, defined in [RFC5305], [RFC5307] 975 and [I-D.ietf-idr-rfc7752bis]. Although the encodings for 'Link 976 Attribute' TLVs were originally defined for IS-IS, the TLVs can carry 977 data sourced either by IS-IS or OSPF or direct. 979 0 1 2 3 980 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 981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 982 | Type=[TBD13] | Length | 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 | | 985 // Link Attributes Sub-TLVs (variable) // 986 | | 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 989 All Link Attributes TLVs defined for BGP-LS can then be used with 990 PCEP-LS as well. No new PCEP sub-TLVs for Link Attributes are 991 defined in this document. 993 9.3.9.3. Prefix Attributes TLV 995 This TLV is applicable for LS Prefix Object-Types for both IPv4 and 996 IPv6. Prefixes are learned from the IGP (IS-IS or OSPF) or BGP 997 topology with a set of IGP attributes (such as metric, route tags, 998 etc.). This section describes the different attributes related to 999 the IPv4/IPv6 prefixes. Prefix Attributes TLVs SHOULD be encoded in 1000 the LS Prefix Object. 1002 0 1 2 3 1003 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 1004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1005 | Type=[TBD14] | Length | 1006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1007 | | 1008 // Prefix Attributes Sub-TLVs (variable) // 1009 | | 1010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1012 All Prefix Attributes TLVs defined for BGP-LS can then be used with 1013 PCEP-LS as well. No new PCEP sub-TLVs for Prefix Attributes are 1014 defined in this document. 1016 9.3.10. Removal of an Attribute 1018 One of the key objectives of PCEP-LS is to encode and carry only the 1019 impacted attributes of a Node, a Link, or a Prefix. To accommodate 1020 this requirement, in case of a removal of an attribute, the sub-TLV 1021 MUST be included with no 'value' field and length=0 to indicate that 1022 the attribute is removed. On receiving a sub-TLV with zero length, 1023 the receiver removes the attribute from the database. An absence of 1024 a sub-TLV that was included earlier MUST be interpreted as no change. 1026 10. Other Considerations 1028 10.1. Inter-AS Links 1030 The main source of LS (and TE) information is the IGP, which is not 1031 active on inter-AS links. In some cases, the IGP may have 1032 information of inter-AS links ([RFC5392], [RFC5316]). In other 1033 cases, an implementation SHOULD provide a means to inject inter-AS 1034 links into PCEP. The exact mechanism used to provision the inter-AS 1035 links is outside the scope of this document. 1037 11. Security Considerations 1039 This document extends PCEP for LS (and TE) distribution including a 1040 new LSRpt message with a new object and TLVs. Procedures and 1041 protocol extensions defined in this document do not effect the 1042 overall PCEP security model. See [RFC5440], [RFC8253]. Tampering 1043 with the LSRpt message may have an effect on path computations at 1044 PCE. It also provides adversaries an opportunity to eavesdrop and 1045 learn sensitive information and plan sophisticated attacks on the 1046 network infrastructure. The PCE implementation SHOULD provide 1047 mechanisms to prevent strains created by network flaps and amount of 1048 LS (and TE) information. Thus it is suggested that any mechanism 1049 used for securing the transmission of other PCEP message be applied 1050 here as well. As a general precaution, it is RECOMMENDED that these 1051 PCEP extensions only are activated on authenticated and encrypted 1052 sessions belonging to the same administrative authority. 1054 Further, as stated in [RFC6952], PCEP implementations SHOULD support 1055 the TCP-AO [RFC5925] and not use TCP MD5 because of TCP MD5's known 1056 vulnerabilities and weaknesses. PCEP also support Transport Layer 1057 Security (TLS) [RFC8253] as per the recommendations and best current 1058 practices in [RFC7525]. 1060 12. Manageability Considerations 1062 All manageability requirements and considerations listed in [RFC5440] 1063 apply to PCEP protocol extensions defined in this document. In 1064 addition, requirements, and considerations listed in this section 1065 apply. 1067 12.1. Control of Function and Policy 1069 A PCE or PCC implementation MUST allow configuring the PCEP-LS 1070 capabilities as described in this document. 1072 A PCC implementation SHOULD allow configuration to suggest if remote 1073 information learned via routing protocols should be reported or not. 1075 An implementation SHOULD allow the operator to specify the maximum 1076 number of LS data to be reported. 1078 An implementation SHOULD also allow the operator to create abstracted 1079 topologies that are reported to the peers and create different 1080 abstractions for different peers. 1082 An implementation SHOULD allow the operator to configure a 64-bit 1083 identifier for Routing Universe TLV. 1085 12.2. Information and Data Models 1087 An implementation SHOULD allow the operator to view the LS 1088 capabilities advertised by each peer. To serve this purpose, the 1089 PCEP YANG module [I-D.ietf-pce-pcep-yang] can be extended to include 1090 advertised capabilities. 1092 An implementation SHOULD also provide the statistics: 1094 o Total number of LSRpt sent/received, as well as per neighbour 1096 o Number of errors received for LSRpt, per neighbour 1098 o Total number of locally originated Link-State Information 1100 These statistics should be recorded as absolute counts since system 1101 or session start time. An implementation MAY also enhance this 1102 information by recording peak per-second counts in each case. 1104 An operator SHOULD define an import policy to limit inbound LSRpt to 1105 "drop all LSRpt from a particular peer" as well provide means to 1106 limit inbound LSRpts. 1108 12.3. Liveness Detection and Monitoring 1110 Mechanisms defined in this document do not imply any new liveness 1111 detection and monitoring requirements in addition to those already 1112 listed in [RFC5440]". 1114 12.4. Verify Correct Operations 1116 Mechanisms defined in this document do not imply any new operation 1117 verification requirements in addition to those already listed in 1118 [RFC5440] . 1120 12.5. Requirements On Other Protocols 1122 Mechanisms defined in this document do not imply any new requirements 1123 on other protocols. 1125 12.6. Impact On Network Operations 1127 Mechanisms defined in this document do not have any impact on network 1128 operations in addition to those already listed in [RFC5440]. 1130 13. IANA Considerations 1132 This document requests IANA actions to allocate code points for the 1133 protocol elements defined in this document. 1135 13.1. PCEP Messages 1137 IANA created a registry for "PCEP Messages". Each PCEP message has a 1138 message type value. This document defines a new PCEP message value. 1140 Value Meaning Reference 1141 TBD3 LSRpt [This I-D] 1143 13.2. PCEP Objects 1145 This document defines the following new PCEP Object-classes and 1146 Object-values: 1148 Object-Class Value Name Reference 1149 TBD6 LS Object [This I-D] 1150 Object-Type=1 1151 (LS Node) 1152 Object-Type=2 1153 (LS Link) 1154 Object-Type=3 1155 (LS IPv4 Prefix) 1156 Object-Type=4 1157 (LS IPv6 Prefix) 1159 13.3. LS Object 1161 This document requests that a new sub-registry, named "LS Object 1162 Protocol-ID Field", is created within the "Path Computation Element 1163 Protocol (PCEP) Numbers" registry to manage the Flag field of the LSP 1164 object. New values are to be assigned by Standards Action [RFC8126]. 1166 Value Meaning Reference 1167 0 Reserved [This I-D] 1168 1 IS-IS Level 1 [This I-D] 1169 2 IS-IS Level 2 [This I-D] 1170 3 OSPFv2 [This I-D] 1171 4 Direct [This I-D] 1172 5 Static configuration [This I-D] 1173 6 OSPFv3 [This I-D] 1174 7 BGP [This I-D] 1175 8 RSVP-TE [This I-D] 1176 9 Segment Routing [This I-D] 1177 10 PCEP [This I-D] 1178 11 Abstraction [This I-D] 1179 12-255 Unassigned 1181 Further, this document also requests that a new sub-registry, named 1182 "LS Object Flag Field", is created within the "Path Computation 1183 Element Protocol (PCEP) Numbers" registry to manage the Flag field of 1184 the LSP object.New values are to be assigned by Standards Action 1185 [RFC8126]. Each bit should be tracked with the following qualities: 1187 o Bit number (counting from bit 0 as the most significant bit) 1189 o Capability description 1191 o Defining RFC 1193 The following values are defined in this document: 1195 Bit Description Reference 1196 0-21 Unassigned 1197 22 R (Remove bit) [This I-D] 1198 23 S (Sync bit) [This I-D] 1200 13.4. PCEP-Error Object 1202 IANA is requested to make the following allocation in the "PCEP-ERROR 1203 Object Error Types and Values" registry. 1205 Error-Type Meaning Reference 1206 6 Mandatory Object missing [RFC5440] 1207 Error-Value=TBD4 [This I-D] 1208 (LS object missing) 1210 19 Invalid Operation [RFC8231] 1211 Error-Value=TBD1 [This I-D] 1212 (Attempted LS Report if LS 1213 remote capability was not 1214 advertised) 1216 TBD2 LS Synchronization Error [This I-D] 1217 Error-Value=1 1218 (An error in processing the 1219 LSRpt) 1220 Error-Value=2 1221 (An internal PCC error) 1223 13.5. PCEP TLV Type Indicators 1225 This document defines the following new PCEP TLVs. 1227 Value Meaning Reference 1228 TBD5 LS-CAPABILITY TLV [This I-D] 1229 TBD7 ROUTING-UNIVERSE TLV [This I-D] 1230 TBD15 ROUTE-DISTINGUISHER TLV [This I-D] 1231 TBD8 Local Node Descriptors TLV [This I-D] 1232 TBD9 Remote Node Descriptors TLV [This I-D] 1233 TBD10 Link Descriptors TLV [This I-D] 1234 TBD11 Prefix Descriptors TLV [This I-D] 1235 TBD12 Node Attributes TLV [This I-D] 1236 TBD13 Link Attributes TLV [This I-D] 1237 TBD14 Prefix Attributes TLV [This I-D] 1239 13.6. PCEP-LS Sub-TLV Type Indicators 1241 This document specifies the PCEP-LS Sub-TLVs. IANA is requested to 1242 create an "PCEP-LS Sub-TLV Types" sub-registry for the sub-TLVs 1243 carried in the PCEP-LS TLV (Local and Remote Node Descriptors TLV, 1244 Link Descriptors TLV, Prefix Descriptors TLV, Node Attributes TLV, 1245 Link Attributes TLV and Prefix Attributes TLV. 1247 Allocations from this registry are to be made according to the 1248 following assignment policies [RFC8126]: 1250 Range | Assignment policy 1251 ---------------+--------------------------------------------------- 1252 0 | Reserved - must not be allocated. 1253 | 1254 1 .. 251 | Specification Required 1255 | 1256 252 .. 255 | Experimental Use 1257 | 1258 256 .. 65535 | Reserved - must not be allocated. 1259 | Usage mirrors the BGP-LS TLV registry 1260 | [I-D.ietf-idr-rfc7752bis] 1261 | 1263 IANA is requested to pre-populate this registry with values defined 1264 in this document as follows, taking the new values from the range 1 1265 to 251: 1267 Value | Meaning 1268 -------+------------------------ 1269 1 | SPEAKER-ENTITY-ID 1271 14. TLV Code Points Summary 1273 This section contains the global table of all TLVs in LS object 1274 defined in this document. 1276 +-----------+---------------------+---------------+-----------------+ 1277 | TLV | Description | Ref TLV | Value defined | 1278 | | | | in: | 1279 +-----------+---------------------+---------------+-----------------+ 1280 | TBD7 | Routing Universe | -- | Sec 9.2.1 | 1281 | TBD15 | Route | -- | Sec 9.2.2 | 1282 | | Distinguisher | | | 1283 | * | Virtual Network | -- | [ietf-pce- | 1284 | | | | vn-association] | 1285 | TBD8 | Local Node | 256 | [I-D.ietf-idr- | 1286 | | | | rfc7752bis] | 1287 | | Descriptors | | /3.2.1.2 | 1288 | TBD9 | Remote Node | 257 | [I-D.ietf-idr- | 1289 | | | | rfc7752bis] | 1290 | | Descriptors | | /3.2.1.3 | 1291 | TBD10 | Link Descriptors | -- | Sec 9.2.8 | 1292 | TBD11 | Prefix Descriptors | -- | Sec 9.2.9 | 1293 | TBD12 | Node Attributes | -- | Sec 9.2.10.1 | 1294 | TBD13 | Link Attributes | -- | Sec 9.2.10.2 | 1295 | TBD14 | Prefix Attributes | -- | Sec 9.2.10.3 | 1296 +-----------+---------------------+---------------+-----------------+ 1298 * this TLV is defined in a different PCEP document 1300 TLV Table 1302 15. Implementation Status 1304 The PCEP-LS protocol extensions as described in this I-D were 1305 implemented and tested for a variety of applications. Apart from the 1306 below implementation, there exist other experimental implementations 1307 done for optical networks. 1309 15.1. Hierarchical Transport PCE controllers 1311 The PCEP-LS has been implemented as part of IETF97 Hackathon and 1312 Bits-N-Bites demonstration. The use-case demonstrated was DCI use- 1313 case of ACTN architecture in which to show the following scenarios: 1315 - connectivity services on the ACTN based recursive hierarchical 1316 SDN/PCE platform that has the three-tier level SDN controllers 1317 (two-tier level MDSC and PNC) on the top of the PTN systems 1318 managed by EMS. 1320 - Integration test of two tier-level MDSC: The SBI of the low 1321 level MDSC is the YANG based Korean national standards and the one 1322 of the high-level MDSC the PCEP-LS based ACTN protocols. 1324 - Performance test of three types of SDN controller based recovery 1325 schemes including protection, reactive, and proactive restoration. 1326 PCEP-LS protocol was used to demonstrate a quick report of failed 1327 network components. 1329 15.2. ONOS-based Controller (MDSC and PNC) 1331 Huawei (PNC, MDSC) and SKT (MDSC) implemented PCEP-LS during 1332 Hackathon and IETF97 Bits-N-Bites demonstration. The demonstration 1333 was ONOS-based ACTN architecture in which to show the following 1334 capabilities: 1336 Both packet PNC and optical PNC (with optical PCEP-LS extensions) 1337 implemented PCEP-LS on its SBI as well as its NBI (towards MDSC). 1339 SKT orchestrator (acting as MDSC) also supported PCEP-LS (as well 1340 as RestConf) towards packet and optical PNCs on its SBI. 1342 Further description can be found at and the code at 1343 . 1345 16. Acknowledgments 1347 This document borrows some of the structure and text from the 1348 [I-D.ietf-idr-rfc7752bis]. 1350 Thanks to Eric Wu, Venugopal Kondreddy, Mahendra Singh Negi, 1351 Avantika, and Zhengbin Li for the reviews. 1353 Thanks to Ramon Casellas for his comments and suggestions based on 1354 his implementation experience. 1356 17. References 1358 17.1. Normative References 1360 [I-D.ietf-idr-rfc7752bis] 1361 Talaulikar, K., "Distribution of Link-State and Traffic 1362 Engineering Information Using BGP", draft-ietf-idr- 1363 rfc7752bis-05 (work in progress), November 2020. 1365 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1366 Requirement Levels", BCP 14, RFC 2119, 1367 DOI 10.17487/RFC2119, March 1997, 1368 . 1370 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1371 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 1372 2008, . 1374 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 1375 in Support of Generalized Multi-Protocol Label Switching 1376 (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, 1377 . 1379 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1380 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1381 DOI 10.17487/RFC5440, March 2009, 1382 . 1384 [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic 1385 Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119, 1386 February 2011, . 1388 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1389 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1390 May 2017, . 1392 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 1393 and D. Dhody, "Optimizations of Label Switched Path State 1394 Synchronization Procedures for a Stateful PCE", RFC 8232, 1395 DOI 10.17487/RFC8232, September 2017, 1396 . 1398 17.2. Informative References 1400 [I-D.ietf-pce-pcep-flowspec] 1401 Dhody, D., Farrel, A., and Z. Li, "PCEP Extension for Flow 1402 Specification", draft-ietf-pce-pcep-flowspec-12 (work in 1403 progress), October 2020. 1405 [I-D.ietf-pce-pcep-yang] 1406 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 1407 YANG Data Model for Path Computation Element 1408 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 1409 yang-15 (work in progress), October 2020. 1411 [I-D.ietf-pce-vn-association] 1412 Lee, Y., Zheng, H., and D. Ceccarelli, "Path Computation 1413 Element communication Protocol (PCEP) extensions for 1414 Establishing Relationships between sets of LSPs and 1415 Virtual Networks", draft-ietf-pce-vn-association-03 (work 1416 in progress), October 2020. 1418 [I-D.ietf-teas-actn-requirements] 1419 Lee, Y., Ceccarelli, D., Miyasaka, T., Shin, J., and K. 1420 Lee, "Requirements for Abstraction and Control of TE 1421 Networks", draft-ietf-teas-actn-requirements-09 (work in 1422 progress), March 2018. 1424 [I-D.kondreddy-pce-pcep-ls-sync-optimizations] 1425 Kondreddy, V. and M. Negi, "Optimizations of PCEP Link- 1426 State(LS) Synchronization Procedures", draft-kondreddy- 1427 pce-pcep-ls-sync-optimizations-00 (work in progress), 1428 October 2015. 1430 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 1431 (TE) Extensions to OSPF Version 2", RFC 3630, 1432 DOI 10.17487/RFC3630, September 2003, 1433 . 1435 [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in 1436 Support of Generalized Multi-Protocol Label Switching 1437 (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, 1438 . 1440 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1441 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1442 2006, . 1444 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1445 Element (PCE)-Based Architecture", RFC 4655, 1446 DOI 10.17487/RFC4655, August 2006, 1447 . 1449 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in 1450 Support of Inter-Autonomous System (AS) MPLS and GMPLS 1451 Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316, 1452 December 2008, . 1454 [RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in 1455 Support of Inter-Autonomous System (AS) MPLS and GMPLS 1456 Traffic Engineering", RFC 5392, DOI 10.17487/RFC5392, 1457 January 2009, . 1459 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1460 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 1461 June 2010, . 1463 [RFC6549] Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 Multi- 1464 Instance Extensions", RFC 6549, DOI 10.17487/RFC6549, 1465 March 2012, . 1467 [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the 1468 Path Computation Element Architecture to the Determination 1469 of a Sequence of Domains in MPLS and GMPLS", RFC 6805, 1470 DOI 10.17487/RFC6805, November 2012, 1471 . 1473 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 1474 BGP, LDP, PCEP, and MSDP Issues According to the Keying 1475 and Authentication for Routing Protocols (KARP) Design 1476 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 1477 . 1479 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1480 "Recommendations for Secure Use of Transport Layer 1481 Security (TLS) and Datagram Transport Layer Security 1482 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1483 2015, . 1485 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1486 Writing an IANA Considerations Section in RFCs", BCP 26, 1487 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1488 . 1490 [RFC8202] Ginsberg, L., Previdi, S., and W. Henderickx, "IS-IS 1491 Multi-Instance", RFC 8202, DOI 10.17487/RFC8202, June 1492 2017, . 1494 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1495 Computation Element Communication Protocol (PCEP) 1496 Extensions for Stateful PCE", RFC 8231, 1497 DOI 10.17487/RFC8231, September 2017, 1498 . 1500 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 1501 "PCEPS: Usage of TLS to Provide a Secure Transport for the 1502 Path Computation Element Communication Protocol (PCEP)", 1503 RFC 8253, DOI 10.17487/RFC8253, October 2017, 1504 . 1506 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 1507 Computation Element Communication Protocol (PCEP) 1508 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 1509 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 1510 . 1512 [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An 1513 Architecture for Use of PCE and the PCE Communication 1514 Protocol (PCEP) in a Network with Central Control", 1515 RFC 8283, DOI 10.17487/RFC8283, December 2017, 1516 . 1518 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 1519 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 1520 DOI 10.17487/RFC8453, August 2018, 1521 . 1523 [RFC8637] Dhody, D., Lee, Y., and D. Ceccarelli, "Applicability of 1524 the Path Computation Element (PCE) to the Abstraction and 1525 Control of TE Networks (ACTN)", RFC 8637, 1526 DOI 10.17487/RFC8637, July 2019, 1527 . 1529 Appendix A. Examples 1531 These examples are for illustration purposes only to show how the new 1532 PCEP-LS message could be encoded. They are not meant to be an 1533 exhaustive list of all possible use cases and combinations. 1535 A.1. All Nodes 1537 Each node (PCC) in the network chooses to provide its own local node 1538 and link information, and in this way PCE can build the full link- 1539 state and TE information. 1541 +--------------------+ +--------------------+ 1542 | | | | 1543 | RTA |10.1.1.1 | RTB | 1544 | 1.1.1.1 |--------------------| 2.2.2.2 | 1545 | Area 0 | 10.1.1.2| Area 0 | 1546 | | | | 1547 +--------------------+ +--------------------+ 1548 RTA 1549 --- 1550 LS Node 1551 TLV - Local Node Descriptors 1552 Sub-TLV - 514: OSPF Area-ID: 0.0.0.0 1553 Sub-TLV - 515: Router-ID: 1.1.1.1 1554 TLV - Node Attributes TLV 1555 Sub-TLV(s) 1557 LS Link 1558 TLV - Local Node Descriptors 1559 Sub-TLV - 514: OSPF Area-ID: 0.0.0.0 1560 Sub-TLV - 515: Router-ID: 1.1.1.1 1561 TLV - Remote Node Descriptors 1562 Sub-TLV - 514: OSPF Area-ID: 0.0.0.0 1563 Sub-TLV - 515: Router-ID: 2.2.2.2 1564 TLV - Link Descriptors 1565 Sub-TLV - 259: IPv4 interface: 10.1.1.1 1566 Sub-TLV - 260: IPv4 neighbor: 10.1.1.2 1567 TLV - Link Attributes TLV 1568 Sub-TLV(s) 1570 RTB 1571 --- 1572 LS Node 1573 TLV - Local Node Descriptors 1574 Sub-TLV - 514: OSPF Area-ID: 0.0.0.0 1575 Sub-TLV - 515: Router-ID: 2.2.2.2 1577 TLV - Node Attributes TLV 1578 Sub-TLV(s) 1580 LS Link 1581 TLV - Local Node Descriptors 1582 Sub-TLV - 514: OSPF Area-ID: 0.0.0.0 1583 Sub-TLV - 515: Router-ID: 2.2.2.2 1584 TLV - Remote Node Descriptors 1585 Sub-TLV - 514: OSPF Area-ID: 0.0.0.0 1586 Sub-TLV - 515: Router-ID: 1.1.1.1 1587 TLV - Link Descriptors 1588 Sub-TLV - 259: IPv4 interface: 10.1.1.2 1589 Sub-TLV - 260: IPv4 neighbor: 10.1.1.1 1590 TLV - Link Attributes TLV 1591 Sub-TLV(s) 1593 A.2. Designated Node 1595 A designated node(s) in the network will provide its own local node 1596 as well as all learned remote information, and in this way PCE can 1597 build the full link-state and TE information. 1599 As described in Appendix A.1, the same LS Node and Link objects will 1600 be generated with a difference that it would be a designated router 1601 say RTA that generate all this information. 1603 A.3. Between PCEs 1605 As per Hierarchical-PCE [RFC6805], Parent PCE builds an abstract 1606 domain topology map with each domain as an abstract node and inter- 1607 domain links as an abstract link. Each child PCE may provide this 1608 information to the parent PCE. Considering the example in figure 1 1609 of [RFC6805], following LS object will be generated: 1611 PCE1 1612 ---- 1613 LS Node 1614 TLV - Local Node Descriptors 1615 Sub-TLV - 512: Autonomous System: 100 (Domain 1) 1616 Sub-TLV - 515: Router-ID: 11.11.11.11 (abstract) 1618 LS Link 1619 TLV - Local Node Descriptors 1620 Sub-TLV - 512: Autonomous System: 100 1621 Sub-TLV - 515: Router-ID: 11.11.11.11 (abstract) 1622 TLV - Remote Node Descriptors 1623 Sub-TLV - 512: Autonomous System: 200 (Domain 2) 1624 Sub-TLV - 515: Router-ID: 22.22.22.22 (abstract) 1625 TLV - Link Descriptors 1626 Sub-TLV - 259: IPv4 interface: 11.1.1.1 1627 Sub-TLV - 260: IPv4 neighbor: 11.1.1.2 1628 TLV - Link Attributes TLV 1629 Sub-TLV(s) 1631 LS Link 1632 TLV - Local Node Descriptors 1633 Sub-TLV - 512: Autonomous System: 100 1634 Sub-TLV - 515: Router-ID: 11.11.11.11 (abstract) 1635 TLV - Remote Node Descriptors 1636 Sub-TLV - 512: Autonomous System: 200 1637 Sub-TLV - 515: Router-ID: 22.22.22.22 (abstract) 1638 TLV - Link Descriptors 1639 Sub-TLV - 259: IPv4 interface: 12.1.1.1 1640 Sub-TLV - 260: IPv4 neighbor: 12.1.1.2 1641 TLV - Link Attributes TLV 1642 Sub-TLV(s) 1644 LS Link 1645 TLV - Local Node Descriptors 1646 Sub-TLV - 512: Autonomous System: 100 1647 Sub-TLV - 515: Router-ID: 11.11.11.11 (abstract) 1648 TLV - Remote Node Descriptors 1649 Sub-TLV - 512: Autonomous System: 400 (Domain 4) 1650 Sub-TLV - 515: Router-ID: 44.44.44.44 (abstract) 1651 TLV - Link Descriptors 1652 Sub-TLV - 259: IPv4 interface: 13.1.1.1 1653 Sub-TLV - 260: IPv4 neighbor: 13.1.1.2 1654 TLV - Link Attributes TLV 1655 Sub-TLV(s) 1657 * similar information will be generated by other PCE 1658 to help form the abstract domain topology. 1660 Further the exact border nodes and abstract internal path between the 1661 border nodes may also be transported to the Parent PCE to enable ACTN 1662 as described in [RFC8637] using the similar LS node and link objects 1663 encodings. 1665 Appendix B. Contributor Addresses 1667 Udayasree Palle 1669 EMail: udayasreereddy@gmail.com 1671 Sergio Belotti 1672 Nokia 1674 EMail: sergio.belotti@nokia.com 1676 Satish Karunanithi 1677 Huawei Technologies 1678 Divyashree Techno Park, Whitefield 1679 Bangalore, Karnataka 560066 1680 India 1682 Email: satishk@huawei.com 1684 Cheng Li 1685 Huawei Technologies 1686 Huawei Campus, No. 156 Beiqing Rd. 1687 Beijing 100095 1688 China 1690 Email: c.l@huawei.com 1692 Authors' Addresses 1694 Dhruv Dhody 1695 Huawei Technologies 1696 Divyashree Techno Park, Whitefield 1697 Bangalore, Karnataka 560066 1698 India 1700 EMail: dhruv.ietf@gmail.com 1701 Shuping Peng 1702 Huawei Technologies 1703 Huawei Bld., No.156 Beiqing Rd. 1704 Beijing 100095 1705 China 1707 EMail: pengshuping@huawei.com 1709 Young Lee 1710 Samsung Electronics 1711 Seoul 1712 South Korea 1714 EMail: younglee.tx@gmail.com 1716 Daniele Ceccarelli 1717 Ericsson 1718 Torshamnsgatan,48 1719 Stockholm 1720 Sweden 1722 EMail: daniele.ceccarelli@ericsson.com 1724 Aijun Wang 1725 China Telecom 1726 Beiqijia Town, Changping District 1727 Beijing, Beijing 102209 1728 China 1730 EMail: wangaj3@chinatelecom.cn 1732 Gyan Mishra 1733 Verizon Inc. 1735 EMail: gyan.s.mishra@verizon.com