idnits 2.17.1 draft-dhodylee-pce-pcep-ls-03.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 3 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 (March 15, 2016) is 2961 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TBD3' is mentioned on line 496, but not defined == Missing Reference: 'TBD5' is mentioned on line 570, but not defined == Missing Reference: 'TBD6' is mentioned on line 600, but not defined == Missing Reference: 'This I-D' is mentioned on line 1261, but not defined == Unused Reference: 'I-D.ietf-isis-te-metric-extensions' is defined on line 1470, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 5316 (Obsoleted by RFC 9346) -- Obsolete informational reference (is this intentional?): RFC 6822 (Obsoleted by RFC 8202) == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-13 == Outdated reference: A later version (-11) exists of draft-ietf-pce-pce-initiated-lsp-05 == Outdated reference: A later version (-18) exists of draft-ietf-pce-pceps-09 == Outdated reference: A later version (-01) exists of draft-kondreddy-pce-pcep-ls-sync-optimizations-00 == Outdated reference: A later version (-03) exists of draft-leedhody-teas-pcep-ls-02 == Outdated reference: A later version (-02) exists of draft-ceccarelli-teas-actn-framework-01 Summary: 0 errors (**), 0 flaws (~~), 13 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group D. Dhody 3 Internet-Draft Y. Lee 4 Intended status: Standards Track Huawei Technologies 5 Expires: September 16, 2016 D. Ceccarelli 6 Ericsson 7 March 15, 2016 9 PCEP Extension for Distribution of Link-State and TE Information. 10 draft-dhodylee-pce-pcep-ls-03 12 Abstract 14 In order to compute and provide optimal paths, Path Computation 15 Elements (PCEs) require an accurate and timely Traffic Engineering 16 Database (TED). Traditionally this TED has been obtained from a link 17 state (LS) routing protocol supporting traffic engineering 18 extensions. 20 This document extends the Path Computation Element Communication 21 Protocol (PCEP) with Link-State and TE Information. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 16, 2016. 40 Copyright Notice 42 Copyright (c) 2016 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5 61 4. Requirements for PCEP extension . . . . . . . . . . . . . . . 6 62 5. New Functions to distribute link-state (and TE) via PCEP . . 6 63 6. Overview of Extension to PCEP . . . . . . . . . . . . . . . . 7 64 6.1. New Messages . . . . . . . . . . . . . . . . . . . . . . 7 65 6.2. Capability Advertisement . . . . . . . . . . . . . . . . 7 66 6.3. Initial Link-State (and TE) Synchronization . . . . . . . 8 67 6.3.1. Optimizations for LS Synchronization . . . . . . . . 10 68 6.4. LS Report . . . . . . . . . . . . . . . . . . . . . . . . 11 69 7. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 8. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 11 71 8.1. LS Report Message . . . . . . . . . . . . . . . . . . . . 11 72 8.2. The PCErr Message . . . . . . . . . . . . . . . . . . . . 12 73 9. Objects and TLV . . . . . . . . . . . . . . . . . . . . . . . 12 74 9.1. Open Object . . . . . . . . . . . . . . . . . . . . . . . 13 75 9.1.1. LS Capability TLV . . . . . . . . . . . . . . . . . . 13 76 9.2. LS Object . . . . . . . . . . . . . . . . . . . . . . . . 13 77 9.2.1. Routing Universe TLV . . . . . . . . . . . . . . . . 15 78 9.2.2. Local Node Descriptors TLV . . . . . . . . . . . . . 16 79 9.2.3. Remote Node Descriptors TLV . . . . . . . . . . . . . 17 80 9.2.4. Node Descriptors Sub-TLVs . . . . . . . . . . . . . . 17 81 9.2.5. Multi-Topology ID TLV . . . . . . . . . . . . . . . . 18 82 9.2.6. Link Descriptors TLV . . . . . . . . . . . . . . . . 18 83 9.2.7. Prefix Descriptors TLV . . . . . . . . . . . . . . . 20 84 9.2.8. PCEP-LS Attributes . . . . . . . . . . . . . . . . . 21 85 9.2.8.1. Node Attributes TLV . . . . . . . . . . . . . . . 21 86 9.2.8.2. Link Attributes TLV . . . . . . . . . . . . . . . 22 87 9.2.8.3. Prefix Attributes TLV . . . . . . . . . . . . . . 23 88 9.2.9. Removal of an Attribute . . . . . . . . . . . . . . . 24 89 10. Other Considerations . . . . . . . . . . . . . . . . . . . . 25 90 10.1. Inter-AS Links . . . . . . . . . . . . . . . . . . . . . 25 91 11. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 25 92 12. Security Considerations . . . . . . . . . . . . . . . . . . . 25 93 13. Manageability Considerations . . . . . . . . . . . . . . . . 25 94 13.1. Control of Function and Policy . . . . . . . . . . . . . 25 95 13.2. Information and Data Models . . . . . . . . . . . . . . 25 96 13.3. Liveness Detection and Monitoring . . . . . . . . . . . 25 97 13.4. Verify Correct Operations . . . . . . . . . . . . . . . 26 98 13.5. Requirements On Other Protocols . . . . . . . . . . . . 26 99 13.6. Impact On Network Operations . . . . . . . . . . . . . . 26 100 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 101 14.1. PCEP Messages . . . . . . . . . . . . . . . . . . . . . 26 102 14.2. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 26 103 14.3. LS Object . . . . . . . . . . . . . . . . . . . . . . . 26 104 14.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . 27 105 14.5. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 27 106 14.6. PCEP-LS Sub-TLV Type Indicators . . . . . . . . . . . . 28 107 15. TLV/Sub-TLV Code Points Summary . . . . . . . . . . . . . . . 31 108 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 109 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 110 17.1. Normative References . . . . . . . . . . . . . . . . . . 31 111 17.2. Informative References . . . . . . . . . . . . . . . . . 32 112 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 35 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 115 1. Introduction 117 In Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS), 118 a Traffic Engineering Database (TED) is used in computing paths for 119 connection oriented packet services and for circuits. The TED 120 contains all relevant information that a Path Computation Element 121 (PCE) needs to perform its computations. It is important that the 122 TED be complete and accurate each time, the PCE performs a path 123 computation. 125 In MPLS and GMPLS, interior gateway routing protocols (IGPs) have 126 been used to create and maintain a copy of the TED at each node 127 running the IGP. One of the benefits of the PCE architecture 128 [RFC4655] is the use of computationally more sophisticated path 129 computation algorithms and the realization that these may need 130 enhanced processing power not necessarily available at each node 131 participating in an IGP. 133 Section 4.3 of [RFC4655] describes the potential load of the TED on a 134 network node and proposes an architecture where the TED is maintained 135 by the PCE rather than the network nodes. However, it does not 136 describe how a PCE would obtain the information needed to populate 137 its TED. PCE may construct its TED by participating in the IGP 138 ([RFC3630] and [RFC5305] for MPLS-TE; [RFC4203] and [RFC5307] for 139 GMPLS). An alternative is offered by BGP-LS 140 [I-D.ietf-idr-ls-distribution] . 142 [I-D.ietf-pce-stateful-pce] describes a set of extensions to PCEP to 143 provide stateful control. A stateful PCE has access to not only the 144 information carried by the network's Interior Gateway Protocol (IGP), 145 but also the set of active paths and their reserved resources for its 146 computations. PCC can delegate the rights to modify the LSP 147 parameters to an Active Stateful PCE. This requires PCE to quickly 148 be updated on any changes in the Topology and TEDB, so that PCE can 149 meet the need for updating LSPs effectively and in a timely manner. 150 The fastest way for a PCE to be updated on TED changes is via a 151 direct interface with each network node and with incremental update 152 from each network node with only the attribute that is modified. 154 [I-D.ietf-pce-pce-initiated-lsp] describes the setup, maintenance and 155 teardown of PCE-initiated LSPs under the stateful PCE model, without 156 the need for local configuration on the PCC, thus allowing for a 157 dynamic network that is centrally controlled and deployed. This 158 model requires timely topology and TED update at the PCE. 160 [I-D.leedhody-teas-pcep-ls] proposes some other approaches for 161 learning and maintaining the Link-State and TE information directly 162 on a PCE as an alternative to IGPs and BGP flooding and investigate 163 the impact from the PCE, routing protocol, and node perspectives. 165 [RFC5440] describes the specifications for the Path Computation 166 Element Communication Protocol (PCEP). PCEP specifies the 167 communication between a Path Computation Client (PCC) and a Path 168 Computation Element (PCE), or between two PCEs based on the PCE 169 architecture [RFC4655]. 171 This document describes a mechanism by which Link State and TE 172 information can be collected from networks and shared with PCE using 173 the PCEP itself. This is achieved using a new PCEP message format. 174 The mechanism is applicable to physical and virtual links as well as 175 further subjected to various policies. 177 A network node maintains one or more databases for storing link-state 178 and TE information about nodes and links in any given area. Link 179 attributes stored in these databases include: local/remote IP 180 addresses, local/ remote interface identifiers, link metric and TE 181 metric, link bandwidth, reservable bandwidth, per CoS class 182 reservation state, preemption and Shared Risk Link Groups (SRLG). 183 The node's PCEP process can retrieve topology from these databases 184 and distribute it to a PCE, either directly or via another PCEP 185 Speaker, using the encoding specified in this document. 187 Further [RFC6805] describes Hierarchical-PCE architecture, where a 188 parent PCE maintains a domain topology map. The child PCE MAY 189 transport (abstract) Link-State and TE information from child PCE to 190 a Parent PCE using the mechanism described in this document. 192 [I-D.ietf-pce-stateful-pce] describe LSP state synchronization 193 between PCCs and PCEs in case of stateful PCE. This document does 194 not make any change to the LSP state synchronization process. The 195 mechanism described in this document are on top of the existing LSP 196 state synchronization. 198 1.1. Requirements Language 200 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 201 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 202 document are to be interpreted as described in [RFC2119]. 204 2. Terminology 206 The terminology is as per [RFC4655] and [RFC5440]. 208 3. Applicability 210 As per [I-D.leedhody-teas-pcep-ls], the mechanism specified in this 211 draft is applicable to: 213 o Where there is no IGP or BGP-LS running in the network. 215 o Where there is no IGP or BGP-LS running at the PCE to learn link- 216 state and TE information. 218 o Where there is IGP or BGP-LS running but with a need for a faster 219 TE and link-state population and convergence at the PCE. 221 * A PCE may receive partial information (say basic TE, link- 222 state) from IGP and other information (optical and impairment) 223 from PCEP. 225 * A PCE may receive an incremental update (as opposed to the 226 entire information of the node/link). 228 * A PCE may receive full information from both existing mechanism 229 (IGP or BGP) and PCEP. 231 o Where there is a need for transporting (abstract) Link-State and 232 TE information from child PCE to a Parent PCE in H-PCE [RFC6805]; 233 as well as for Physical Network Controller (PNC) to Multi-Domain 234 Service Coordinator (MDSC) in Abstraction and Control of TE 235 Networks (ACTN) [I-D.ceccarelli-teas-actn-framework]. 237 A PCC may further choose to send only local information or both local 238 and remote learned information. 240 How a PCE manages the link-state (and TE) information is 241 implementation specific and thus out of scope of this document. 243 4. Requirements for PCEP extension 245 Following key requirements associated with link-state (and TE) 246 distribution are identified for PCEP: 248 1. The PCEP speaker supporting this draft MUST be a mechanism to 249 advertise the Link-State (and TE) distribution capability. 251 2. PCC supporting this draft MUST have the capability to report the 252 link-state (and TE) information to the PCE. This includes self 253 originated information and remote information learned via routing 254 protocols. PCC MUST be capable to do the initial bulk sync at 255 the time of session initialization as well as changes after. 257 3. A PCE MAY learn link-state (and TE) from PCEP as well as from 258 existing mechanism like IGP/BGP-LS. PCEP extension MUST have a 259 mechanism to link the information learned via other means. There 260 MUST NOT be any changes to the existing link-state (and TE) 261 population mechanism via IGP/BGP-LS. PCEP extension SHOULD keep 262 the properties in a protocol (IGP or BGP-LS) neutral way, such 263 that an implementation may not need to know about any OSPF or IS- 264 IS or BGP protocol specifics. 266 4. It SHOULD be possible to encode only the changes in link-state 267 (and TE) properties (after the initial sync) in PCEP messages. 269 5. The same mechanism should be used for both MPLS TE as well as 270 GMPLS, optical and impairment aware properties. 272 6. The same mechanism should be used for PCE to PCE Link-state (and 273 TE) synchronization. 275 7. The extension in this draft SHOULD be extensible to support 276 various architecture options listed in 277 [I-D.leedhody-teas-pcep-ls]. 279 5. New Functions to distribute link-state (and TE) via PCEP 281 Several new functions are required in PCEP to support distribution of 282 link-state (and TE) information. A function can be initiated either 283 from a PCC towards a PCE (C-E) or from a PCE towards a PCC (E-C). 284 The new functions are: 286 o Capability advertisement (E-C,C-E): both the PCC and the PCE must 287 announce during PCEP session establishment that they support PCEP 288 extensions for distribution of link-state (and TE) information 289 defined in this document. 291 o Link-State (and TE) synchronization (C-E): after the session 292 between the PCC and a PCE is initialized, the PCE must learn Link- 293 State (and TE) information before it can perform path 294 computations. In case of stateful PCE it is RECOMENDED that this 295 operation be done before LSP state synchronization. 297 o Link-State (and TE) Report (C-E): a PCC sends a LS (and TE) report 298 to a PCE whenever the Link-State and TE information changes. 300 6. Overview of Extension to PCEP 302 6.1. New Messages 304 In this document, we define a new PCEP messages called LS Report 305 (LSRpt), a PCEP message sent by a PCC to a PCE to report link-state 306 (and TE) information. Each LS Report in a LSRpt message can contain 307 the node or link properties. An unique PCEP specific LS identifier 308 (LS-ID) is also carried in the message to identify a node or link and 309 that remains constant for the lifetime of a PCEP session. This 310 identifier on its own is sufficient when no IGP or BGP-LS running in 311 the network for PCE to learn link-state (and TE) information. Incase 312 PCE learns some information from PCEP and some from the existing 313 mechanism, the PCC SHOULD include the mapping of IGP or BGP-LS 314 identifier to map the information populated via PCEP with IGP/BGP-LS. 315 See Section 8.1 for details. 317 6.2. Capability Advertisement 319 During PCEP Initialization Phase, PCEP Speakers (PCE or PCC) 320 advertise their support of LS (and TE) distribution via PCEP 321 extensions. A PCEP Speaker includes the "LS Capability" TLV, 322 described in Section 9.1.1, in the OPEN Object to advertise its 323 support for PCEP-LS extensions. The presence of the LS Capability 324 TLV in PCC's OPEN Object indicates that the PCC is willing to send LS 325 Reports whenever local link-state (and TE) information changes. The 326 presence of the LS Capability TLV in PCE's OPEN message indicates 327 that the PCE is interested in receiving LS Reports whenever local 328 link-state (and TE) information changes. 330 The PCEP protocol extensions for LS (and TE) distribution MUST NOT be 331 used if one or both PCEP Speakers have not included the LS Capability 332 TLV in their respective OPEN message. If the PCE that supports the 333 extensions of this draft but did not advertise this capability, then 334 upon receipt of a LSRpt message from the PCC, it SHOULD generate a 335 PCErr with error-type 19 (Invalid Operation), error-value TBD1 336 (Attempted LS Report if LS capability was not advertised) and it will 337 terminate the PCEP session. 339 The LS reports sent by PCC MAY carry the remote link-state (and TE) 340 information learned via existing means like IGP and BGP-LS only if 341 both PCEP Speakers set the R (remote) Flag in the "LS Capability" TLV 342 to 'Remote Allowed (R Flag = 1)'. If this is not the case and LS 343 reports carry remote link-state (and TE) information, then a PCErr 344 with error-type 19 (Invalid Operation) and error-value TBD1 345 (Attempted LS Report if LS remote capability was not advertised) and 346 it will terminate the PCEP session. 348 6.3. Initial Link-State (and TE) Synchronization 350 The purpose of LS Synchronization is to provide a checkpoint-in- time 351 state replica of a PCC's link-state (and TE) data base in a PCE. 352 State Synchronization is performed immediately after the 353 Initialization phase (see [RFC5440]]). In case of stateful PCE 354 ([I-D.ietf-pce-stateful-pce]) it is RECOMENDED that the LS 355 synchronization should be done before LSP state synchronization. 357 During LS Synchronization, a PCC first takes a snapshot of the state 358 of its database, then sends the snapshot to a PCE in a sequence of LS 359 Reports. Each LS Report sent during LS Synchronization has the SYNC 360 Flag in the LS Object set to 1. The end of synchronization marker is 361 a LSRpt message with the SYNC Flag set to 0 for an LS Object with LS- 362 ID equal to the reserved value 0. If the PCC has no link-state to 363 synchronize, it will only send the end of synchronization marker. 365 Either the PCE or the PCC MAY terminate the session using the PCEP 366 session termination procedures during the synchronization phase. If 367 the session is terminated, the PCE MUST clean up state it received 368 from this PCC. The session re-establishment MUST be re-attempted per 369 the procedures defined in [RFC5440], including use of a back-off 370 timer. 372 If the PCC encounters a problem which prevents it from completing the 373 LS synchronization, it MUST send a PCErr message with error-type TBD2 374 (LS Synchronization Error) and error-value 2 (indicating an internal 375 PCC error) to the PCE and terminate the session. 377 The PCE does not send positive acknowledgements for properly received 378 LS synchronization messages. It MUST respond with a PCErr message 379 with error-type TBD2 (LS Synchronization Error) and error-value 1 380 (indicating an error in processing the LSRpt) if it encounters a 381 problem with the LS Report it received from the PCC and it MUST 382 terminate the session. 384 The LS reports can carry local as well as remote link-state (and TE) 385 information depending on the R flag in LS capability TLV. 387 The successful LS Synchronization sequences is shown in Figure 1. 389 +-+-+ +-+-+ 390 |PCC| |PCE| 391 +-+-+ +-+-+ 392 | | 393 |-----LSRpt, SYNC=1----->| (Sync start) 394 | | 395 |-----LSRpt, SYNC=1----->| 396 | . | 397 | . | 398 | . | 399 |-----LSRpt, SYNC=1----->| 400 | . | 401 | . | 402 | . | 403 | | 404 |-----LSRpt, SYNC=0----->| (End of sync marker 405 | | LS Report 406 | | for LS-ID=0) 407 | | (Sync done) 409 Figure 1: Successful LS synchronization 411 The sequence where the PCE fails during the LS Synchronization phase 412 is shown in Figure 2. 414 +-+-+ +-+-+ 415 |PCC| |PCE| 416 +-+-+ +-+-+ 417 | | 418 |-----LSRpt, SYNC=1----->| 419 | | 420 |-----LSRpt, SYNC=1----->| 421 | . | 422 | . | 423 | . | 424 |-----LSRpt, SYNC=1----->| 425 | | 426 |---LSRpt,SYNC=1 | 427 | \ ,-PCErr---| 428 | \ / | 429 | \/ | 430 | /\ | 431 | / `-------->| (Ignored) 432 |<--------` | 434 Figure 2: Failed LS synchronization (PCE failure) 436 The sequence where the PCC fails during the LS Synchronization phase 437 is shown in Figure 3. 439 +-+-+ +-+-+ 440 |PCC| |PCE| 441 +-+-+ +-+-+ 442 | | 443 |-----LSRpt, SYNC=1----->| 444 | | 445 |-----LSRpt, SYNC=1----->| 446 | . | 447 | . | 448 | . | 449 |-------- PCErr--------->| 450 | | 452 Figure 3: Failed LS synchronization (PCC failure) 454 6.3.1. Optimizations for LS Synchronization 456 These optimizations are described in 457 [I-D.kondreddy-pce-pcep-ls-sync-optimizations]. 459 6.4. LS Report 461 The PCC MUST report any changes in the link-state (and TE) 462 information to the PCE by sending a LS Report carried on a LSRpt 463 message to the PCE. Each node and Link would be uniquely identified 464 by a PCEP LS identifier (LS-ID). The LS reports may carry local as 465 well as remote link-state (and TE) information depending on the R 466 flag in LS capability TLV. In case R flag is set, It MAY also 467 include the mapping of IGP or BGP-LS identifier to map the 468 information populated via PCEP with IGP/BGP-LS. 470 More details about LSRpt message are in Section 8.1. 472 7. Transport 474 A permanent PCEP session MUST be established between a PCE and PCC 475 supporting link-state (and TE) distribution via PCEP. In the case of 476 session failure, session re-establishment MUST be re-attempted per 477 the procedures defined in [RFC5440]. 479 8. PCEP Messages 481 As defined in [RFC5440], a PCEP message consists of a common header 482 followed by a variable-length body made of a set of objects that can 483 be either mandatory or optional. An object is said to be mandatory 484 in a PCEP message when the object must be included for the message to 485 be considered valid. For each PCEP message type, a set of rules is 486 defined that specify the set of objects that the message can carry. 487 An implementation MUST form the PCEP messages using the object 488 ordering specified in this document. 490 8.1. LS Report Message 492 A PCEP LS Report message (also referred to as LSRpt message) is a 493 PCEP message sent by a PCC to a PCE to report the link-state (and TE) 494 information. A LSRpt message can carry more than one LS Reports. 495 The Message-Type field of the PCEP common header for the LSRpt 496 message is set to [TBD3]. 498 The format of the LSRpt message is as follows: 500 ::= 501 502 Where: 504 ::= [] 505 The LS object is a mandatory object which carries LS information of a 506 node or a link. Each LS object has an unique LS-ID as described in 507 Section 9.2. If the LS object is missing, the receiving PCE MUST 508 send a PCErr message with Error-type=6 (Mandatory Object missing) and 509 Error-value=[TBD4] (LS object missing). 511 A PCE may choose to implement a limit on the LS information a single 512 PCC can populate. If a LSRpt is received that causes the PCE to 513 exceed this limit, it MUST send a PCErr message with error-type 19 514 (invalid operation) and error-value 4 (indicating resource limit 515 exceeded) in response to the LSRpt message triggering this condition 516 and SHOULD terminate the session. 518 8.2. The PCErr Message 520 If a PCEP speaker has advertised the LS capability on the PCEP 521 session, the PCErr message MAY include the LS object. If the error 522 reported is the result of an LS report, then the LS-ID number MUST be 523 the one from the LSRpt that triggered the error. 525 The format of a PCErr message from [RFC5440] is extended as follows: 527 The format of the PCErr message is as follows: 529 ::= 530 ( [] ) | 531 [] 533 ::=[] 535 ::=[ | ] 536 538 ::=[] 540 ::=[] 542 ::=[] 544 9. Objects and TLV 546 The PCEP objects defined in this document are compliant with the PCEP 547 object format defined in [RFC5440]. The P flag and the I flag of the 548 PCEP objects defined in this document MUST always be set to 0 on 549 transmission and MUST be ignored on receipt since these flags are 550 exclusively related to path computation requests. 552 9.1. Open Object 554 This document defines a new optional TLV for use in the OPEN Object. 556 9.1.1. LS Capability TLV 558 The LS-CAPABILITY TLV is an optional TLV for use in the OPEN Object 559 for link-state (and TE) distribution via PCEP capability 560 advertisement. Its format is shown in the following figure: 562 0 1 2 3 563 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 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | Type=[TBD5] | Length=4 | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | Flags |R| 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 The type of the TLV is [TBD5] and it has a fixed length of 4 octets. 572 The value comprises a single field - Flags (32 bits): 574 o R (remote - 1 bit): if set to 1 by a PCC, the R Flag indicates 575 that the PCC allows reporting of remote LS information learned via 576 other means like IGP and BGP-LS; if set to 1 by a PCE, the R Flag 577 indicates that the PCE is capable of receiving remote LS 578 information (from the PCC point of view). The R Flag must be 579 advertised by both a PCC and a PCE for LSRpt messages to report 580 remote as well as local LS information on a PCEP session. The 581 TLVs related to IGP/BGP-LS identifier MUST be encoded when both 582 PCEP speakers have the R Flag set. 584 Unassigned bits are considered reserved. They MUST be set to 0 on 585 transmission and MUST be ignored on receipt. 587 Advertisement of the LS capability implies support of local link- 588 state (and TE) distribution, as well as the objects, TLVs and 589 procedures defined in this document. 591 9.2. LS Object 593 The LS (link-state) object MUST be carried within LSRpt messages and 594 MAY be carried within PCErr messages. The LS object contains a set 595 of fields used to specify the target node or link. It also contains 596 a flag indicating to a PCE that the LS synchronization is in 597 progress. The TLVs used with the LS object correlate with the IGP/ 598 BGP-LS encodings. 600 LS Object-Class is [TBD6]. 602 Four Object-Type values are defined for the LS object so far: 604 o LS Node: LS Object-Type is 1. 606 o LS Link: LS Object-Type is 2. 608 o LS IPv4 Topology Prefix: LS Object-Type is 3. 610 o LS IPv6 Topology Prefix: LS Object-Type is 4. 612 The format of all types of LS object is as follows: 614 0 1 2 3 615 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 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 | Protocol-ID | Flag |R|S| 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 | LS-ID | 620 | | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 // TLVs // 623 | | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 Protocol-ID (8-bit): The field provide the source information. 627 Incase PCC only provides local information (R flag is not set), it 628 MUST use Protocol-ID as Direct. The following values are defined 629 (same as [I-D.ietf-idr-ls-distribution]): 631 +-------------+----------------------------------+ 632 | Protocol-ID | Source protocol | 633 +-------------+----------------------------------+ 634 | 1 | IS-IS Level 1 | 635 | 2 | IS-IS Level 2 | 636 | 3 | OSPFv2 | 637 | 4 | Direct | 638 | 5 | Static configuration | 639 | 6 | OSPFv3 | 640 | 7 | BGP-LS | 641 +-------------+----------------------------------+ 643 Flags (24-bit): 645 o S (SYNC - 1 bit): the S Flag MUST be set to 1 on each LSRpt sent 646 from a PCC during LS Synchronization. The S Flag MUST be set to 0 647 in other LSRpt messages sent from the PCC. 649 o R (Remove - 1 bit): On LSRpt messages the R Flag indicates that 650 the node/link/prefix has been removed from the PCC and the PCE 651 SHOULD remove from its database. Upon receiving an LS Report with 652 the R Flag set to 1, the PCE SHOULD remove all state for the 653 node/link/prefix identified by the LS Identifiers from its 654 database. 656 LS-ID(64-bit): A PCEP-specific identifier for the node or link or 657 prefix information. A PCC creates an unique LS-ID for each 658 node/link/prefix that is constant for the lifetime of a PCEP session. 659 The PCC will advertise the same LS-ID on all PCEP sessions it 660 maintains at a given times. All subsequent PCEP messages then 661 address the node/link/prefix by the LS-ID. The values of 0 and 662 0xFFFFFFFFFFFFFFFF are reserved. 664 Unassigned bits are considered reserved. They MUST be set to 0 on 665 transmission and MUST be ignored on receipt. 667 TLVs that may be included in the LS Object are described in the 668 following sections. 670 9.2.1. Routing Universe TLV 672 In case of remote link-state (and TE) population when existing IGP/ 673 BGP-LS are also used, OSPF and IS-IS may run multiple routing 674 protocol instances over the same link as described in 675 [I-D.ietf-idr-ls-distribution]. See [RFC6822] and [RFC6549] for more 676 information. These instances define independent "routing universes". 677 The 64-Bit 'Identifier' field is used to identify the "routing 678 universe" where the LS object belongs. The LS objects representing 679 IGP objects (nodes or links or prefix) from the same routing universe 680 MUST have the same 'Identifier' value; LS objects with different 681 'Identifier' values MUST be considered to be from different routing 682 universes. 684 The format of the ROUTING-UNIVERSE TLV is shown in the following 685 figure: 687 0 1 2 3 688 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 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 | Type=[TBD7] | Length=8 | 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 | Identifier | 693 | | 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 Below table lists the 'Identifier' values that are defined as well- 697 known in this draft (same as [I-D.ietf-idr-ls-distribution]). 699 +------------+-----------------------------------+ 700 | Identifier | Routing Universe | 701 +------------+-----------------------------------+ 702 | 0 | Default Layer 3 Routing topology | 703 | 1-31 | Reserved | 704 +------------+-----------------------------------+ 706 If this TLV is not present the default value 0 is assumed. 708 9.2.2. Local Node Descriptors TLV 710 As described in [I-D.ietf-idr-ls-distribution], each link is anchored 711 by a pair of Router-IDs that are used by the underlying IGP, namely, 712 48 Bit ISO System-ID for IS-IS and 32 bit Router-ID for OSPFv2 and 713 OSPFv3. Incase of additional auxiliary Router-IDs used for TE, these 714 MUST also be included in the link attribute TLV (see 715 Section 9.2.8.2). 717 It is desirable that the Router-ID assignments inside the Node 718 Descriptor are globally unique. Some considerations for globally 719 unique Node/Link/Prefix identifiers are described in 720 [I-D.ietf-idr-ls-distribution]. 722 The Local Node Descriptors TLV contains Node Descriptors for the node 723 anchoring the local end of the link. This TLV MUST be included in 724 the LS Report when during a given PCEP session a node/link/prefix is 725 first reported to a PCE. A PCC sends to a PCE the first LS Report 726 either during State Synchronization, or when a new node/link/prefix 727 is learned at the PCC. The value contains one or more Node 728 Descriptor Sub-TLVs, which allows specification of a flexible key for 729 any given node/link/prefix information such that global uniqueness of 730 the node/link/prefix is ensured. 732 This TLV is applicable for all LS Object-Type. 734 0 1 2 3 735 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 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 | Type=[TBD8] | Length | 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 | | 740 // Node Descriptor Sub-TLVs (variable) // 741 | | 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 The value contains one or more Node Descriptor Sub-TLVs defined in 745 Section 9.2.4. 747 9.2.3. Remote Node Descriptors TLV 749 The Remote Node Descriptors contains Node Descriptors for the node 750 anchoring the remote end of the link. This TLV MUST be included in 751 the LS Report when during a given PCEP session a link is first 752 reported to a PCE. A PCC sends to a PCE the first LS Report either 753 during State Synchronization, or when a new link is learned at the 754 PCC. The length of this TLV is variable. The value contains one or 755 more Node Descriptor Sub-TLVs defined in Section 9.2.4. 757 This TLV is applicable for LS Link Object-Type. 759 0 1 2 3 760 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 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 | Type=[TBD9] | Length | 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 | | 765 // Node Descriptor Sub-TLVs (variable) // 766 | | 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 9.2.4. Node Descriptors Sub-TLVs 771 The Node Descriptor Sub-TLV type Type and lengths are listed in the 772 following table: 774 +--------------------+-------------------+----------+ 775 | Sub-TLV | Description | Length | 776 +--------------------+-------------------+----------+ 777 | 0 | Reserved | - | 778 | 1 | Autonomous System | 4 | 779 | 2 | BGP-LS Identifier | 4 | 780 | 3 | OSPF Area-ID | 4 | 781 | 4 | IGP Router-ID | Variable | 782 | 5 | Multi-Topology-ID | Variable | 783 +--------------------+-------------------+----------+ 785 The sub-TLV values in Node Descriptor TLVs are defined as follows 786 (similar to [I-D.ietf-idr-ls-distribution]): 788 o Autonomous System: opaque value (32 Bit AS Number) 790 o BGP-LS Identifier: opaque value (32 Bit ID). In conjunction with 791 ASN, uniquely identifies the BGP-LS domain as described in 793 [I-D.ietf-idr-ls-distribution]. This sub-TLV is present only if 794 the node implements BGP-LS and the ID is set by the operator. 796 o OSPF Area ID: It is used to identify the 32 Bit area to which the 797 LS object belongs. Area Identifier allows the different LS 798 objects of the same node to be discriminated. 800 o IGP Router ID: opaque value. Usage is described in 801 [I-D.ietf-idr-ls-distribution] for IGP Router ID. In case only 802 local information is transported and PCE learns link-state (and 803 TE) information only from PCEP, it contain the unique local TE 804 IPv4 or IPv6 router ID. 806 o Multi-Topology-ID: Usage is described in 807 [I-D.ietf-idr-ls-distribution] for MT-ID. 809 o There can be at most one instance of each sub-TLV type present in 810 any Node Descriptor. 812 9.2.5. Multi-Topology ID TLV 814 The Multi-Topology ID (MT-ID) TLV carries one or more IS-IS or OSPF 815 Multi-Topology IDs for a link, node or prefix. The semantics of the 816 IS-IS MT-ID are defined in Section 7.2 of [RFC5120]. The MT-ID TLV 817 MAY be present in a Link Descriptor, a Prefix Descriptor, or in the 818 attribute of a node (Node Attributes TLV) in LS object. 820 The format and handling of the MT-ID TLV is as defined in 821 [I-D.ietf-idr-ls-distribution]. 823 In a Link or Prefix Descriptor, only a single MT-ID TLV containing 824 the MT-ID of the topology where the link or the prefix is reachable 825 is allowed. In case one wants to advertise multiple topologies for a 826 given Link Descriptor or Prefix Descriptor, multiple reports need to 827 be generated where each LS object contains an unique MT-ID. In the 828 attribute of a node (Node Attributes TLV) in LS object, one MT-ID TLV 829 containing the array of MT-IDs of all topologies where the node is 830 reachable is allowed. 832 9.2.6. Link Descriptors TLV 834 The Link Descriptors TLV contains Link Descriptors for each link. 835 This TLV MUST be included in the LS Report when during a given PCEP 836 session a link is first reported to a PCE. A PCC sends to a PCE the 837 first LS Report either during State Synchronization, or when a new 838 link is learned at the PCC. The length of this TLV is variable. The 839 value contains one or more Link Descriptor Sub-TLVs. 841 The 'Link descriptor' TLVs uniquely identify a link among multiple 842 parallel links between a pair of anchor routers similar to 843 [I-D.ietf-idr-ls-distribution]. 845 This TLV is applicable for LS Link Object-Type. 847 0 1 2 3 848 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 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 | Type=[TBD10] | Length | 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 | | 853 // Link Descriptor Sub-TLVs (variable) // 854 | | 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 The Link Descriptor Sub-TLV type and lengths are listed in the 858 following table: 860 +-----------+---------------------+---------------+-----------------+ 861 | Sub-TLV | Description | IS-IS TLV | Value defined | 862 | | | /Sub-TLV | in: | 863 +-----------+---------------------+---------------+-----------------+ 864 | 6 | Link Local/Remote | 22/4 | [RFC5307]/1.1 | 865 | | Identifiers | | | 866 | 7 | IPv4 interface | 22/6 | [RFC5305]/3.2 | 867 | | address | | | 868 | 8 | IPv4 neighbor | 22/8 | [RFC5305]/3.3 | 869 | | address | | | 870 | 9 | IPv6 interface | 22/12 | [RFC6119]/4.2 | 871 | | address | | | 872 | 10 | IPv6 neighbor | 22/13 | [RFC6119]/4.3 | 873 | | address | | | 874 | 5 | Multi-Topology | - | [I-D.ietf-idr- | 875 | | identifier | | ls-distribution]| 876 | | | | /3.2.1.5 | 877 +-----------+---------------------+---------------+-----------------+ 879 The format and semantics of the 'value' fields in most 'Link 880 Descriptor' sub-TLVs correspond to the format and semantics of value 881 fields in IS-IS Extended IS Reachability sub-TLVs, defined in 882 [RFC5305], [RFC5307] and [RFC6119]. Although the encodings for 'Link 883 Descriptor' TLVs were originally defined for IS-IS, the TLVs can 884 carry data sourced either by IS-IS or OSPF or direct. 886 The information about a link present in the LSA/LSP originated by the 887 local node of the link determines the set of sub-TLVs in the Link 888 Descriptor of the link as described in 889 [I-D.ietf-idr-ls-distribution]. 891 9.2.7. Prefix Descriptors TLV 893 The Prefix Descriptors TLV contains Prefix Descriptors uniquely 894 identify an IPv4 or IPv6 Prefix originated by a Node. This TLV MUST 895 be included in the LS Report when during a given PCEP session a 896 prefix is first reported to a PCE. A PCC sends to a PCE the first LS 897 Report either during State Synchronization, or when a new prefix is 898 learned at the PCC. The length of this TLV is variable. 900 This TLV is applicable for LS Prefix Object-Types for both IPv4 and 901 IPv6. 903 0 1 2 3 904 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 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 906 | Type=[TBD11] | Length | 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 908 | | 909 // Prefix Descriptor Sub-TLVs (variable) // 910 | | 911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 913 The value contains one or more Prefix Descriptor Sub-TLVs defined 914 below - 916 +--------------+-----------------------+----------+-----------------+ 917 | TLV Code | Description | Length | Value defined | 918 | Point | | | in: | 919 +--------------+-----------------------+----------+-----------------+ 920 | 5 | Multi-Topology | variable | [I-D.ietf-idr- | 921 | | Identifier | | ls-distribution]| 922 | | | | /3.2.1.5 | 923 | 11 | OSPF Route Type | 1 | [I-D.ietf-idr- | 924 | | | | ls-distribution]| 925 | | | | /3.2.3.1 | 926 | 12 | IP Reachability | variable | [I-D.ietf-idr- | 927 | | Information | | ls-distribution]| 928 | | | | /3.2.3.2 | 929 +--------------+-----------------------+----------+-----------------+ 931 9.2.8. PCEP-LS Attributes 933 9.2.8.1. Node Attributes TLV 935 This is an optional attribute that is used to carry node attributes. 936 This TLV is applicable for LS Node 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=[TBD12] | Length | 942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 943 | | 944 // Node Attributes Sub-TLVs (variable) // 945 | | 946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 948 The Node Attributes Sub-TLV type and lengths are listed in the 949 following table: 951 +--------------+-----------------------+----------+-----------------+ 952 | Sub TLV | Description | Length | Value defined | 953 | | | | in: | 954 +--------------+-----------------------+----------+-----------------+ 955 | 5 | Multi-Topology | variable | [I-D.ietf-idr- | 956 | | Identifier | | ls-distribution]| 957 | | | | /3.2.1.5 | 958 | 13 | Node Flag Bits | 1 | [I-D.ietf-idr- | 959 | | | | ls-distribution]| 960 | | | | /3.3.1.1 | 961 | 14 | Opaque Node | variable | [I-D.ietf-idr- | 962 | | Properties | | ls-distribution]| 963 | | | | /3.3.1.5 | 964 | 15 | Node Name | variable | [I-D.ietf-idr- | 965 | | | | ls-distribution]| 966 | | | | /3.3.1.3 | 967 | 16 | IS-IS Area Identifier | variable | [I-D.ietf-idr- | 968 | | | | ls-distribution]| 969 | | | | /3.3.1.2 | 970 | 17 | IPv4 Router-ID of | 4 | [RFC5305]/4.3 | 971 | | Local Node | | | 972 | 18 | IPv6 Router-ID of | 16 | [RFC6119]/4.1 | 973 | | Local Node | | | 974 +--------------+-----------------------+----------+-----------------+ 976 9.2.8.2. Link Attributes TLV 978 This TLV is applicable for LS Link Object-Type. The format and 979 semantics of the 'value' fields in some 'Link Attribute' sub-TLVs 980 correspond to the format and semantics of value fields in IS-IS 981 Extended IS Reachability sub-TLVs, defined in [RFC5305], [RFC5307] 982 and [I-D.ietf-idr-ls-distribution]. Although the encodings for 'Link 983 Attribute' TLVs were originally defined for IS-IS, the TLVs can carry 984 data sourced either by IS-IS or OSPF or direct. 986 0 1 2 3 987 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 988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 989 | Type=[TBD13] | Length | 990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 991 | | 992 // Link Attributes Sub-TLVs (variable) // 993 | | 994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 996 The following 'Link Attribute' sub-TLVs are valid : 998 +-----------+---------------------+--------------+------------------+ 999 | Sub-TLV | Description | IS-IS TLV | Defined in: | 1000 | | | /Sub-TLV | | 1001 | | | BGP-LS TLV | | 1002 +-----------+---------------------+--------------+------------------+ 1003 | 17 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 | 1004 | | Local Node | | | 1005 | 18 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 | 1006 | | Local Node | | | 1007 | 19 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 | 1008 | | Remote Node | | | 1009 | 20 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 | 1010 | | Remote Node | | | 1011 | 21 | Link Local/Remote | 22/4 | [RFC5307]/1.1 | 1012 | | Identifiers | | | 1013 | 22 | Administrative | 22/3 | [RFC5305]/3.1 | 1014 | | group (color) | | | 1015 | 23 | Maximum link | 22/9 | [RFC5305]/3.3 | 1016 | | bandwidth | | | 1017 | 24 | Max. reservable | 22/10 | [RFC5305]/3.5 | 1018 | | link bandwidth | | | 1019 | 25 | Unreserved | 22/11 | [RFC5305]/3.6 | 1020 | | bandwidth | | | 1021 | 26 | TE Default Metric | 22/18 | [I-D.ietf-idr- | 1022 | | | | ls-distribution] | 1023 | | | | /3.3.2.3 | 1024 | 27 | Link Protection | 22/20 | [RFC5307]/1.2 | 1025 | | Type | | | 1026 | 28 | MPLS Protocol Mask | 1094 | [I-D.ietf-idr- | 1027 | | | | ls-distribution] | 1028 | | | | /3.3.2.2 | 1029 | 29 | IGP Metric | 1095 | [I-D.ietf-idr- | 1030 | | | | ls-distribution] | 1031 | | | | /3.3.2.4 | 1032 | 30 | Shared Risk Link | 1096 | [I-D.ietf-idr- | 1033 | | Group | | ls-distribution] | 1034 | | | | /3.3.2.5 | 1035 | 31 | Opaque link | 1097 | [I-D.ietf-idr- | 1036 | | attributes | | ls-distribution] | 1037 | | | | /3.3.2.6 | 1038 | 32 | Link Name attribute | 1098 | [I-D.ietf-idr- | 1039 | | | | ls-distribution] | 1040 | | | | /3.3.2.7 | 1041 | 33 | Unidirectional | 22/xx | [I-D.ietf-isis- | 1042 | | Link Delay | | te-metric- | 1043 | | | | extensions] | 1044 | 34 | Min/Max | 22/xx | [I-D.ietf-isis- | 1045 | | Unidirectional Link | | te-metric- | 1046 | | Delay | | extensions] | 1047 | 35 | Unidirectional | 22/xx | [I-D.ietf-isis- | 1048 | | Delay Variation | | te-metric- | 1049 | | | | extensions] | 1050 | 36 | Unidirectional | 22/xx | [I-D.ietf-isis- | 1051 | | Packet Loss | | te-metric- | 1052 | | | | extensions] | 1053 | 37 | Unidirectional | 22/xx | [I-D.ietf-isis- | 1054 | | Residual Bandwidth | | te-metric- | 1055 | | | | extensions] | 1056 | 38 | Unidirectional | 22/xx | [I-D.ietf-isis- | 1057 | | Available Bandwidth | | te-metric- | 1058 | | | | extensions] | 1059 | 39 | Unidirectional | 22/xx | [I-D.ietf-isis- | 1060 | | Bandwidth | | te-metric- | 1061 | | Utilization | | extensions] | 1062 | 40 | Extended Admin | 22/14 | [RFC7308]/2.1 | 1063 | | Group (EAG) | | | 1064 +-----------+---------------------+--------------+------------------+ 1066 9.2.8.3. Prefix Attributes TLV 1068 This TLV is applicable for LS Prefix Object-Types for both IPv4 and 1069 IPv6. Prefixes are learned from the IGP (IS-IS or OSPF) or BGP 1070 topology with a set of IGP attributes (such as metric, route tags, 1071 etc.). This section describes the different attributes related to 1072 the IPv4/IPv6 prefixes. Prefix Attributes TLVs SHOULD be encoded in 1073 the LS Prefix Object. 1075 0 1 2 3 1076 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 1077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1078 | Type=[TBD14] | Length | 1079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1080 | | 1081 // Prefix Attributes Sub-TLVs (variable) // 1082 | | 1083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1085 The following 'Prefix Attribute' sub-TLVs are valid : 1087 +-----------+---------------------+--------------+------------------+ 1088 | Sub-TLV | Description | BGP-LS TLV | Defined in: | 1089 +-----------+---------------------+--------------+------------------+ 1090 | 41 | IGP Flags | 1152 | [I-D.ietf-idr- | 1091 | | | | ls-distribution] | 1092 | | | | /3.3.3.1 | 1093 | 42 | Route Tag | 1153 | [I-D.ietf-idr- | 1094 | | | | ls-distribution] | 1095 | | | | /3.3.3.2 | 1096 | 43 | Extended Tag | 1154 | [I-D.ietf-idr- | 1097 | | | | ls-distribution] | 1098 | | | | /3.3.3.3 | 1099 | 44 | Prefix Metric | 1155 | [I-D.ietf-idr- | 1100 | | | | ls-distribution] | 1101 | | | | /3.3.3.4 | 1102 | 45 | OSPF Forwarding | 1156 | [I-D.ietf-idr- | 1103 | | Address | | ls-distribution] | 1104 | | | | /3.3.3.5 | 1105 | 46 | Opaque Prefix | 1157 | [I-D.ietf-idr- | 1106 | | Attribute | | ls-distribution] | 1107 | | | | /3.3.3.6 | 1108 +-----------+---------------------+--------------+------------------+ 1110 9.2.9. Removal of an Attribute 1112 One of a key objective of PCEP-LS is to encode and carry only the 1113 impacted attributes of a Node, a Link or a Prefix. To accommodate 1114 this requirement, incase of a removal of an attribute, the sub-TLV 1115 MUST be included with no 'value' field and length=0 to indicate that 1116 the attribute is removed. On receiving a sub-TLV with zero length, 1117 the receiver removes the attribute from the database. 1119 10. Other Considerations 1121 10.1. Inter-AS Links 1123 The main source of LS (and TE) information is the IGP, which is not 1124 active on inter-AS links. In some cases, the IGP may have 1125 information of inter-AS links ([RFC5392], [RFC5316]). In other 1126 cases, an implementation SHOULD provide a means to inject inter-AS 1127 links into PCEP. The exact mechanism used to provision the inter-AS 1128 links is outside the scope of this document. 1130 11. Processing Rules 1132 12. Security Considerations 1134 This document extends PCEP for LS (and TE) distribution including a 1135 new LSRpt message with new object and TLVs. Procedures and protocol 1136 extensions defined in this document do not effect the overall PCEP 1137 security model. See [RFC5440], [I-D.ietf-pce-pceps]. Tampering with 1138 the LSRpt message may have an effect on path computations at PCE. It 1139 also provides adversaries an opportunity to eavesdrop and learn 1140 sensitive information and plan sophisticated attacks on the network 1141 infrastructure. The PCE implementation SHOULD provide mechanisms to 1142 prevent strains created by network flaps and amount of LS (and TE) 1143 information. Thus it is suggested that any mechanism used for 1144 securing the transmission of other PCEP message be applied here as 1145 well. As a general precaution, it is RECOMMENDED that these PCEP 1146 extensions only be activated on authenticated and encrypted sessions 1147 belonging to the same administrative authority. 1149 13. Manageability Considerations 1151 13.1. Control of Function and Policy 1153 TBD. 1155 13.2. Information and Data Models 1157 TBD. 1159 13.3. Liveness Detection and Monitoring 1161 TBD. 1163 13.4. Verify Correct Operations 1165 TBD. 1167 13.5. Requirements On Other Protocols 1169 TBD. 1171 13.6. Impact On Network Operations 1173 TBD. 1175 14. IANA Considerations 1177 This document requests IANA actions to allocate code points for the 1178 protocol elements defined in this document. 1180 14.1. PCEP Messages 1182 IANA created a registry for PCEP messages. Each PCEP message has a 1183 message type value. This document defines a new PCEP message value. 1185 Value Meaning Reference 1186 TBD3 LSRpt [This I-D] 1188 14.2. PCEP Objects 1190 This document defines the following new PCEP Object-classes and 1191 Object-values: 1193 Object-Class Value Name Reference 1194 TBD6 LS Object [This I-D] 1195 Object-Type=1 1196 (LS Node) 1197 Object-Type=2 1198 (LS Link) 1199 Object-Type=3 1200 (LS IPv4 Prefix) 1201 Object-Type=4 1202 (LS IPv6 Prefix) 1204 14.3. LS Object 1206 This document requests that a new sub-registry, named "LS Object Flag 1207 Field", is created within the "Path Computation Element Protocol 1208 (PCEP) Numbers" registry to manage the Flag field of the LSP 1209 object.New values are to be assigned by Standards Action [RFC5226]. 1210 Each bit should be tracked with the following qualities: 1212 o Bit number (counting from bit 0 as the most significant bit) 1214 o Capability description 1216 o Defining RFC 1218 The following values are defined in this document: 1220 Bit Description Reference 1221 0-21 Unassigned 1222 22 R (Remove bit) [This I-D] 1223 23 S (Sync bit) [This I-D] 1225 14.4. PCEP-Error Object 1227 IANA is requested to make the following allocation in the "PCEP-ERROR 1228 Object Error Types and Values" registry. 1230 Error-Type Meaning Reference 1231 6 Mandatory Object missing [RFC5440] 1232 Error-Value=TBD4 [This I-D] 1233 (LS object missing) 1235 19 Invalid Operation [I-D.ietf-pce-stateful-pce] 1236 Error-Value=TBD1 [This I-D] 1237 (Attempted LS Report if LS 1238 remote capability was not 1239 advertised) 1241 TBD2 LS Synchronization Error [This I-D] 1242 Error-Value=1 1243 (An error in processing the 1244 LSRpt) 1245 Error-Value=2 1246 (An internal PCC error) 1248 14.5. PCEP TLV Type Indicators 1250 This document defines the following new PCEP TLVs. 1252 Value Meaning Reference 1253 TBD5 LS-CAPABILITY TLV [This I-D] 1254 TBD7 ROUTING-UNIVERSE TLV [This I-D] 1255 TBD8 Local Node Descriptors TLV [This I-D] 1256 TBD9 Remote Node Descriptors TLV [This I-D] 1257 TBD10 Link Descriptors TLV [This I-D] 1258 TBD11 Prefix Descriptors TLV [This I-D] 1259 TBD12 Node Attributes TLV [This I-D] 1260 TBD13 Link Attributes TLV [This I-D] 1261 TBD14 Prefix Attributes TLV [This I-D] 1263 14.6. PCEP-LS Sub-TLV Type Indicators 1265 This document specifies the PCEP-LS Sub-TLVs. IANA is requested to 1266 create an "PCEP-LS Sub-TLV Types" sub-registry in the "PCEP TLV Type 1267 Indicators" for the sub-TLVs carried in the PCEP-LS TLV (Local and 1268 Remote Node Descriptors TLV, Link Descriptors TLV, Prefix Descriptors 1269 TLV, Node Attributes TLV, Link Attributes TLV and Prefix Attributes 1270 TLV. This document defines the following types: 1272 +-----------+---------------------+---------------+-----------------+ 1273 | Sub-TLV | Description | Ref | Value defined | 1274 | | | Sub-TLV | in: | 1275 +-----------+---------------------+---------------+-----------------+ 1276 | 1 | Autonomous System | 512 | [I-D.ietf-idr- | 1277 | | | | ls-distribution]| 1278 | | | | /3.2.1.4 | 1279 | 2 | BGP-LS Identifier | 513 | [I-D.ietf-idr- | 1280 | | | | ls-distribution]| 1281 | | | | /3.2.1.4 | 1282 | 3 | OSPF Area-ID | 514 | [I-D.ietf-idr- | 1283 | | | | ls-distribution]| 1284 | | | | /3.2.1.4 | 1285 | 4 | IGP Router-ID | 515 | [I-D.ietf-idr- | 1286 | | | | ls-distribution]| 1287 | | | | /3.2.1.4 | 1288 | 5 | Multi-Topology-ID | 263 | [I-D.ietf-idr- | 1289 | | | | ls-distribution]| 1290 | | | | /3.2.1.5 | 1291 | 6 | Link Local/Remote | 22/4 | [RFC5307]/1.1 | 1292 | | Identifiers | | | 1293 | 7 | IPv4 interface | 22/6 | [RFC5305]/3.2 | 1294 | | address | | | 1295 | 8 | IPv4 neighbor | 22/8 | [RFC5305]/3.3 | 1296 | | address | | | 1297 | 9 | IPv6 interface | 22/12 | [RFC6119]/4.2 | 1298 | | address | | | 1299 | 10 | IPv6 neighbor | 22/13 | [RFC6119]/4.3 | 1300 | | address | | | 1301 | 11 | OSPF Route Type | 264 | [I-D.ietf-idr- | 1302 | | | | ls-distribution]| 1303 | | | | /3.2.3.1 | 1304 | 12 | IP Reachability | 265 | [I-D.ietf-idr- | 1305 | | Information | | ls-distribution]| 1306 | | | | /3.2.3.2 | 1307 | 13 | Node Flag Bits | 1024 | [I-D.ietf-idr- | 1308 | | | | ls-distribution]| 1309 | | | | /3.3.1.1 | 1310 | 14 | Opaque Node | 1025 | [I-D.ietf-idr- | 1311 | | Properties | | ls-distribution]| 1312 | | | | /3.3.1.5 | 1313 | 15 | Node Name | 1026 | [I-D.ietf-idr- | 1314 | | | | ls-distribution]| 1315 | | | | /3.3.1.3 | 1316 | 16 | IS-IS Area | 1027 | [I-D.ietf-idr- | 1317 | | Identifier | | ls-distribution]| 1318 | | | | /3.3.1.2 | 1319 | 17 | IPv4 Router-ID of | 134/-- | [RFC5305]/4.3 | 1320 | | Local Node | | | 1321 | 18 | IPv6 Router-ID of | 140/-- | [RFC6119]/4.1 | 1322 | | Local Node | | | 1323 | 19 | IPv4 Router-ID of | 134/-- | [RFC5305]/4.3 | 1324 | | Remote Node | | | 1325 | 20 | IPv6 Router-ID of | 140/-- | [RFC6119]/4.1 | 1326 | | Remote Node | | | 1327 | 21 | Link Local/Remote | 22/4 | [RFC5307]/1.1 | 1328 | | Identifiers | | | 1329 | 22 | Administrative | 22/3 | [RFC5305]/3.1 | 1330 | | group (color) | | | 1331 | 23 | Maximum link | 22/9 | [RFC5305]/3.3 | 1332 | | bandwidth | | | 1333 | 24 | Max. reservable | 22/10 | [RFC5305]/3.5 | 1334 | | link bandwidth | | | 1335 | 25 | Unreserved | 22/11 | [RFC5305]/3.6 | 1336 | | bandwidth | | | 1337 | 26 | TE Default Metric | 22/18 | [I-D.ietf-idr- | 1338 | | | | ls-distribution]| 1339 | | | | /3.3.2.3 | 1340 | 27 | Link Protection | 22/20 | [RFC5307]/1.2 | 1341 | | Type | | | 1342 | 28 | MPLS Protocol Mask | 1094 | [I-D.ietf-idr- | 1343 | | | | ls-distribution]| 1344 | | | | /3.3.2.2 | 1345 | 29 | IGP Metric | 1095 | [I-D.ietf-idr- | 1346 | | | | ls-distribution]| 1347 | | | | /3.3.2.4 | 1348 | 30 | Shared Risk Link | 1096 | [I-D.ietf-idr- | 1349 | | Group | | ls-distribution]| 1350 | | | | /3.3.2.5 | 1351 | 31 | Opaque link | 1097 | [I-D.ietf-idr- | 1352 | | attributes | | ls-distribution]| 1353 | | | | /3.3.2.6 | 1354 | 32 | Link Name attribute | 1098 | [I-D.ietf-idr- | 1355 | | | | ls-distribution]| 1356 | | | | /3.3.2.7 | 1357 | 33 | Unidirectional | 22/xx | [I-D.ietf-isis- | 1358 | | Link Delay | | te-metric- | 1359 | | | | extensions] | 1360 | 34 | Min/Max | 22/xx | [I-D.ietf-isis- | 1361 | | Unidirectional Link | | te-metric- | 1362 | | Delay | | extensions] | 1363 | 35 | Unidirectional | 22/xx | [I-D.ietf-isis- | 1364 | | Delay Variation | | te-metric- | 1365 | | | | extensions] | 1366 | 36 | Unidirectional | 22/xx | [I-D.ietf-isis- | 1367 | | Packet Loss | | te-metric- | 1368 | | | | extensions] | 1369 | 37 | Unidirectional | 22/xx | [I-D.ietf-isis- | 1370 | | Residual Bandwidth | | te-metric- | 1371 | | | | extensions] | 1372 | 38 | Unidirectional | 22/xx | [I-D.ietf-isis- | 1373 | | Available Bandwidth | | te-metric- | 1374 | | | | extensions] | 1375 | 39 | Unidirectional | 22/xx | [I-D.ietf-isis- | 1376 | | Bandwidth | | te-metric- | 1377 | | Utilization | | extensions] | 1378 | 40 | Extended Admin | 22/14 | [RFC7308]/2.1 | 1379 | | Group (EAG) | | | 1380 | 41 | IGP Flags | 1152 | [I-D.ietf-idr- | 1381 | | | | ls-distribution]| 1382 | | | | /3.3.3.1 | 1383 | 42 | Route Tag | 1153 | [I-D.ietf-idr- | 1384 | | | | ls-distribution]| 1385 | | | | /3.3.3.2 | 1386 | 43 | Extended Tag | 1154 | [I-D.ietf-idr- | 1387 | | | | ls-distribution]| 1388 | | | | /3.3.3.3 | 1389 | 44 | Prefix Metric | 1155 | [I-D.ietf-idr- | 1390 | | | | ls-distribution]| 1391 | | | | /3.3.3.4 | 1392 | 45 | OSPF Forwarding | 1156 | [I-D.ietf-idr- | 1393 | | Address | | ls-distribution]| 1394 | | | | /3.3.3.5 | 1395 | 46 | Opaque Prefix | 1157 | [I-D.ietf-idr- | 1396 | | Attribute | | ls-distribution]| 1397 | | | | /3.3.3.6 | 1398 +-----------+---------------------+---------------+-----------------+ 1400 New values are to be assigned by Standards Action [RFC5226]. 1402 15. TLV/Sub-TLV Code Points Summary 1404 This section contains the global table of all TLVs/Sub-TLVs in LS 1405 object defined in this document. 1407 +-----------+---------------------+---------------+-----------------+ 1408 | TLV | Description | Ref TLV | Value defined | 1409 | | | | in: | 1410 +-----------+---------------------+---------------+-----------------+ 1411 | TBD7 | Routing Universe | -- | Sec 9.2.1 | 1412 | TBD8 | Local Node | 256 | [I-D.ietf-idr- | 1413 | | Descriptors | | ls-distribution]| 1414 | | | | /3.2.1.2 | 1415 | TBD9 | Remote Node | 257 | [I-D.ietf-idr- | 1416 | | Descriptors | | ls-distribution]| 1417 | | | | /3.2.1.3 | 1418 | TBD10 | Link Descriptors | -- | Sec 9.2.6 | 1419 | TBD11 | Prefix Descriptors | -- | Sec 9.2.7 | 1420 | TBD12 | Node Attributes | -- | Sec 9.2.8.1 | 1421 | TBD13 | Link Attributes | -- | Sec 9.2.8.2 | 1422 | TBD14 | Prefix Attributes | -- | Sec 9.2.8.3 | 1423 +-----------+---------------------+---------------+-----------------+ 1425 TLV Table 1427 Refer Section 14.6 for the table of Sub-TLVs. 1429 16. Acknowledgments 1431 This document borrows some of the structure and text from the 1432 [I-D.ietf-idr-ls-distribution]. 1434 Thanks to Eric Wu, Venugopal Kondreddy, Mahendra Singh Negi, 1435 Avantika, and Zhengbin Li for the reviews. 1437 17. References 1439 17.1. Normative References 1441 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1442 Requirement Levels", BCP 14, RFC 2119, 1443 DOI 10.17487/RFC2119, March 1997, 1444 . 1446 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1447 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 1448 2008, . 1450 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 1451 in Support of Generalized Multi-Protocol Label Switching 1452 (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, 1453 . 1455 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1456 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1457 DOI 10.17487/RFC5440, March 2009, 1458 . 1460 [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic 1461 Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119, 1462 February 2011, . 1464 [I-D.ietf-idr-ls-distribution] 1465 Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. 1466 Ray, "North-Bound Distribution of Link-State and TE 1467 Information using BGP", draft-ietf-idr-ls-distribution-13 1468 (work in progress), October 2015. 1470 [I-D.ietf-isis-te-metric-extensions] 1471 Previdi, S., Giacalone, S., Ward, D., Drake, J., and W. 1472 Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", 1473 draft-ietf-isis-te-metric-extensions-11 (work in 1474 progress), February 2016. 1476 17.2. Informative References 1478 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 1479 (TE) Extensions to OSPF Version 2", RFC 3630, 1480 DOI 10.17487/RFC3630, September 2003, 1481 . 1483 [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in 1484 Support of Generalized Multi-Protocol Label Switching 1485 (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, 1486 . 1488 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1489 Element (PCE)-Based Architecture", RFC 4655, 1490 DOI 10.17487/RFC4655, August 2006, 1491 . 1493 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 1494 Topology (MT) Routing in Intermediate System to 1495 Intermediate Systems (IS-ISs)", RFC 5120, 1496 DOI 10.17487/RFC5120, February 2008, 1497 . 1499 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1500 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1501 DOI 10.17487/RFC5226, May 2008, 1502 . 1504 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in 1505 Support of Inter-Autonomous System (AS) MPLS and GMPLS 1506 Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316, 1507 December 2008, . 1509 [RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in 1510 Support of Inter-Autonomous System (AS) MPLS and GMPLS 1511 Traffic Engineering", RFC 5392, DOI 10.17487/RFC5392, 1512 January 2009, . 1514 [RFC6549] Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 Multi- 1515 Instance Extensions", RFC 6549, DOI 10.17487/RFC6549, 1516 March 2012, . 1518 [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the 1519 Path Computation Element Architecture to the Determination 1520 of a Sequence of Domains in MPLS and GMPLS", RFC 6805, 1521 DOI 10.17487/RFC6805, November 2012, 1522 . 1524 [RFC6822] Previdi, S., Ed., Ginsberg, L., Shand, M., Roy, A., and D. 1525 Ward, "IS-IS Multi-Instance", RFC 6822, 1526 DOI 10.17487/RFC6822, December 2012, 1527 . 1529 [I-D.ietf-pce-stateful-pce] 1530 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 1531 Extensions for Stateful PCE", draft-ietf-pce-stateful- 1532 pce-13 (work in progress), December 2015. 1534 [I-D.ietf-pce-pce-initiated-lsp] 1535 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 1536 Extensions for PCE-initiated LSP Setup in a Stateful PCE 1537 Model", draft-ietf-pce-pce-initiated-lsp-05 (work in 1538 progress), October 2015. 1540 [I-D.ietf-pce-pceps] 1541 Lopez, D., Dios, O., Wu, W., and D. Dhody, "Secure 1542 Transport for PCEP", draft-ietf-pce-pceps-09 (work in 1543 progress), March 2016. 1545 [I-D.kondreddy-pce-pcep-ls-sync-optimizations] 1546 Kondreddy, V. and M. Negi, "Optimizations of PCEP Link- 1547 State(LS) Synchronization Procedures", draft-kondreddy- 1548 pce-pcep-ls-sync-optimizations-00 (work in progress), 1549 October 2015. 1551 [I-D.leedhody-teas-pcep-ls] 1552 Lee, Y., Dhody, D., and D. Ceccarelli, "Architecture and 1553 Requirement for Distribution of Link-State and TE 1554 Information via PCEP.", draft-leedhody-teas-pcep-ls-02 1555 (work in progress), March 2016. 1557 [I-D.ceccarelli-teas-actn-framework] 1558 Ceccarelli, D. and Y. Lee, "Framework for Abstraction and 1559 Control of Traffic Engineered Networks", draft-ceccarelli- 1560 teas-actn-framework-01 (work in progress), March 2016. 1562 Appendix A. Contributor Addresses 1564 Udayasree Palle 1565 Huawei Technologies 1566 Divyashree Techno Park, Whitefield 1567 Bangalore, Karnataka 560037 1568 India 1570 EMail: udayasree.palle@huawei.com 1572 Sergio Belotti 1573 Alcatel-Lucent 1574 Italy 1576 EMail: sergio.belotti@alcatel-lucent.com 1578 Veerendranatha Reddy Vallem 1579 Huawei Technologies 1580 Divyashree Techno Park, Whitefield 1581 Bangalore, Karnataka 560037 1582 India 1584 Email: veerendranatharv@huawei.com 1586 Authors' Addresses 1588 Dhruv Dhody 1589 Huawei Technologies 1590 Divyashree Techno Park, Whitefield 1591 Bangalore, Karnataka 560066 1592 India 1594 EMail: dhruv.ietf@gmail.com 1596 Young Lee 1597 Huawei Technologies 1598 5340 Legacy Drive, Building 3 1599 Plano, TX 75023 1600 USA 1602 EMail: leeyoung@huawei.com 1603 Daniele Ceccarelli 1604 Ericsson 1605 Torshamnsgatan,48 1606 Stockholm 1607 Sweden 1609 EMail: daniele.ceccarelli@ericsson.com