idnits 2.17.00 (12 Aug 2021) /tmp/idnits2160/draft-chen-pce-pcc-ted-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (10 January 2022) is 124 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) == Unused Reference: 'RFC4655' is defined on line 364, but no explicit reference was found in the text == Unused Reference: 'RFC3630' is defined on line 374, but no explicit reference was found in the text == Unused Reference: 'RFC7752' is defined on line 381, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4655 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group H. Chen 3 Internet-Draft Futurewei 4 Intended status: Standards Track M. Toy 5 Expires: 14 July 2022 Verizon 6 X. Liu 7 Volta Networks 8 L. Liu 9 Fujitsu 10 Z. Li 11 China Mobile 12 10 January 2022 14 Static PCEP Link State 15 draft-chen-pce-pcc-ted-10 17 Abstract 19 This document presents extensions to the Path Computation Element 20 Communication Protocol (PCEP) for a PCC to advertise the information 21 about the links without running IGP and for a PCE to build a TED 22 based on the information received. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on 14 July 2022. 41 Copyright Notice 43 Copyright (c) 2022 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 48 license-info) in effect on the date of publication of this document. 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. Code Components 51 extracted from this document must include Revised BSD License text as 52 described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Revised BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 59 3. Conventions Used in This Document . . . . . . . . . . . . . . 3 60 4. Link Information . . . . . . . . . . . . . . . . . . . . . . 3 61 5. Extensions to PCEP . . . . . . . . . . . . . . . . . . . . . 4 62 5.1. Extension to Existing Message . . . . . . . . . . . . . . 4 63 5.1.1. TLVs . . . . . . . . . . . . . . . . . . . . . . . . 4 64 5.1.2. Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . 5 65 5.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 6 66 5.2.1. PCC Procedures . . . . . . . . . . . . . . . . . . . 6 67 5.2.2. PCE Procedures . . . . . . . . . . . . . . . . . . . 7 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 70 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 8 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 73 9.2. Informative References . . . . . . . . . . . . . . . . . 9 74 Appendix A. New Message . . . . . . . . . . . . . . . . . . . . 9 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 77 1. Introduction 79 A PCE architecture is described in RFC 4655, in which a Traffic 80 Engineering Database (TED) for a PCE is constructed based on the link 81 information from IGP (OSPF or IS-IS) running in the domain for which 82 the PCE is responsible. 84 For a domain without running IGP, the PCE responsible for the domain 85 may obtain the link information from a PCC running on each node in 86 the domain. 88 This document presents extensions to the Path Computation Element 89 Communication Protocol (PCEP) for a PCC to advertise the information 90 about the links attached to the node running the PCC and for a PCE to 91 build the TED based on the information received from the PCC. 93 2. Terminology 95 ABR: Area Border Router. Router used to connect two IGP areas 96 (Areas in OSPF or levels in IS-IS). 98 ASBR: Autonomous System (AS) Border Router. Router used to connect 99 together ASes via inter-AS links. 101 This document uses terminology defined in [RFC5440]. 103 3. Conventions Used in This Document 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [RFC2119]. 109 4. Link Information 111 Since no IGP runs over any link, we may not obtain any link 112 information via IGP. But links are configured. 114 For a point-to-point (P2P) link between nodes A and B, from A's point 115 of view, we have the following link information: 117 1) Link Type: P2P 118 2) Local IP address 119 3) Remote IP address 120 4) Traffic engineering metric 121 5) Maximum bandwidth 122 6) Maximum reservable bandwidth 123 7) Unreserved bandwidth 124 8) Administrative group 125 9) SRLG 127 A link ID for the link is obtained if a user configures it; 128 otherwise, no link ID (i.e., the Router ID of A's neighbor) may be 129 obtained since no IGP adjacency over the link is formed. 131 For a broadcast link connecting multiple nodes, on each of the nodes 132 X, we have the same link information as above except for: 134 a) Link Type: Multi-access, 135 b) Local IP address with mask length, and 136 c) No Remote IP address. 138 In other words, the information about the broadcast link obtained by 139 node X comprises a), b), 4) to 9), but does not include any remote IP 140 address or link ID. A link ID for the link is obtained if a user 141 configures it; otherwise, no link ID (i.e., the interface address of 142 the designated router for the link) may be obtained since no IGP 143 selects it. 145 A PCE constructs a TED for its responsible domain after receiving the 146 link information from the PCC running on every node in the domain. 148 5. Extensions to PCEP 150 5.1. Extension to Existing Message 152 An existing Notification message may be extended to advertise the 153 information about links. Alternatively, a new message can be used 154 (refer to Appendix A). 156 The following new Notification-type (NT) and Notification-value (NV) 157 of a NOTIFICATION object in a Notification message are defined: 159 o NT=8 (TBD): Links 161 * NV=1: Update Links. NT=8 and NV=1 indicates that the PCC 162 requests the PCE to update the link information based on the 163 TLVs in the object, which are described below. 165 * NV=2: Withdraw Links. NT=8 and NV=2 indicates that the PCC 166 asks the PCE to remove the Links indicated by the TLVs in the 167 object. 169 5.1.1. TLVs 171 A link TLV and a Router-ID TLV are defined. The format of the link 172 TLV is illustrated below. The Type=tTBD1 indicates a link TLV Type. 173 The Length indicates the size of the Link Sub-TLVs. 175 0 1 2 3 176 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 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | Type (tTBD1) | Length | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Link Sub-TLVs | 181 ~ ~ 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 A link TLV describes a single link. It comprises a number of link 185 sub-TLVs for the information described in section 4, which are the 186 sub-TLVs defined in RFC 3630 or their equivalents except for the 187 local IP address with mask length defined below. 189 The format of the Router-ID TLV is shown below. The Type=tTBD2 190 indicates a Router-ID TLV Type. The Length indicates the size of the 191 ID and flags field. 193 0 1 2 3 194 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 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | Type (tTBD2) | Length | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 |B|E|I| Flags | | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 200 | 32-bit/48-bit ID ~ 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 Flag B: Set to 1 indicating ABR (B is for Border) 203 Flag E: Set to 1 indicating ASBR (E is for External) 204 Flag I: Set to 1 indicating ID of local router (I is for ID) 206 Undefined flags MUST be set to zero. The ID indicates the ID of a 207 router. For a router not running IGP, the ID may be the 32-bit or 208 48-bit ID of the router configured. 210 5.1.2. Sub-TLVs 212 The format of the Sub-TLV for a local IPv4 address with mask length 213 is shown below. The Type=stTBD1 indicates a local IPv4 Address with 214 mask length. The Length indicates the size of the IPv4 address and 215 Mask Length. The IPv4 Address indicates the local IPv4 address of a 216 link. The Mask Length indicates the length of the IPv4 address mask. 218 0 1 2 3 219 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 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | Type (stTBD1) | Length | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | IPv4 Address | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | Mask Length | 226 +-+-+-+-+-+-+-+-+ 228 The format of the Sub-TLV for a local IPv6 address with mask length 229 is illustrated below. The Type=stTBD2 indicates a local IPv6 Address 230 with mask length. The Length indicates the size of the IPv6 address 231 and Mask Length. The IPv6 Address indicates the local IPv6 address 232 of a link. The Mask Length indicates the length of the IPv6 address 233 mask. 235 0 1 2 3 236 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 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Type (stTBD2) | Length | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | IPv6 Address (16 bytes) | 241 ~ ~ 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Mask Length | 244 +-+-+-+-+-+-+-+-+ 246 5.2. Procedures 248 5.2.1. PCC Procedures 250 1. New or Changed Links 252 After the session between a PCC and a PCE is established, the PCC 253 sends the PCE a message containing the information about the links 254 attached to the node running the PCC. 256 For any new or changed links, the PCC sends the PCE a message 257 containing the information about these links with indication of 258 Update Links. 260 For example, for a new P2P link from node A, the PCC running on A 261 sends the PCE a Notification message having a NOTIFICATION object 262 with NT=8 and NV=1 (indicating Update Links), which contains a 263 Router-ID TLV, followed by a link TLV. The former comprises A's ID 264 and flag I set to 1. The latter comprises the Sub-TLVs for the 265 information described in section 4. 267 For multiple new or changed links from node A, the PCC running on A 268 sends the PCE a Notification message having a NOTIFICATION object 269 with NT=8 and NV=1, which contains a Router-ID TLV for A's ID, 270 followed by multiple link TLVs for the links. 272 2. Links Down 273 For links down, the PCC sends the PCE a message containing the 274 information about these links with indication of Withdraw Links. 276 For example, for multiple links from node A down, the PCC running on 277 A sends the PCE a Notification message having a NOTIFICATION object 278 with NT=8 and NV=2 (indicating Withdraw Links), which contains a 279 Router-ID TLV for A's ID, followed by multiple link TLVs for the 280 links. The TLV for a P2P link comprises the Sub-TLVs for the 281 information on 1), 2) and 3) described in section 4. The TLV for a 282 broadcast link comprises the Sub-TLVs for the information on a) and 283 b) described in section 4. 285 3. Simplified Message 287 Alternatively, the messages may be simplified. For each node, the 288 source IP address of the PCC running on the node may be used as the 289 ID of the node. The PCE knows the address after the session between 290 the PCE and the PCC is up. Thus, a message containing the 291 information about links does not need include any router-ID TLV. 293 For example, for a new P2P link attached to node A, the PCC running 294 on A sends the PCE a Notification message having a NOTIFICATION 295 object with NT=8 and NV=1 (indicating Update Links), which contains a 296 link TLV comprising the Sub-TLVs for the information on 1) to 9) 297 described in section 4. The object does not contain any Router-ID 298 TLV for node A. 300 5.2.2. PCE Procedures 302 A PCE stores into its TED the links for each node according to the 303 messages for the links received from the PCC running on the node. 304 For a message containing Update Links, it updates the links 305 accordingly. For a message containing Withdraw Links, it removes the 306 links. When a node is down, the PCE removes the links attached to 307 the node. 309 For a new P2P link between node A and B with no link ID configured, 310 when receiving a message containing the link from the PCC running on 311 A, the PCE stores the link for A (i.e., the link from A) into its 312 TED. It will find the link's remote end B using the remote IP 313 address of the link. After finding B, it associates the link for A 314 with B and the link for B with A. This creates a bidirectional 315 connection between A and B. 317 For a new broadcast link connecting multiple nodes with no link ID 318 configured, when receiving a message containing the link from the PCC 319 running on each of the nodes X, the PCE stores the link for X (i.e., 320 the link from X) into its TED. It will find the link's remote end P 321 using the link's local IP address with network mask. P is a Pseudo 322 node identified by the local IP address of the designated node 323 selected from the nodes connected to the link. After finding P, it 324 associates the link for X with P and the link for P with X. This 325 creates a bidirectional connection between X and P. 327 The first node and second node from which the PCE receives a message 328 containing the link is selected as the designed node and backup 329 designed node respectively. After the designed node is down, the 330 backup designed node becomes the designed node and the node other 331 than the designed node with the largest local IP address connecting 332 to the link is selected as the backup designed node. 334 When the old designed node is down and the backup designed node 335 becomes the new designed node, the PCE updates its TED through 336 removing the link between each of nodes X and old P (the Pseudo node 337 corresponding to the old designed node) and adding a link between 338 each of nodes X (still connecting to the broadcast link) and new P 339 (the Pseudo node corresponding to the new designed node). 341 6. Security Considerations 343 The mechanism described in this document does not raise any new 344 security issues for the PCEP protocols. 346 7. IANA Considerations 348 This section specifies requests for IANA allocation. 350 8. Acknowledgement 352 The authors would like to thank Jescia Chen, and Eric Wu for their 353 valuable comments on this draft. 355 9. References 357 9.1. Normative References 359 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 360 Requirement Levels", BCP 14, RFC 2119, 361 DOI 10.17487/RFC2119, March 1997, 362 . 364 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 365 Computation Element (PCE)-Based Architecture", RFC 4655, 366 DOI 10.17487/RFC4655, August 2006, 367 . 369 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 370 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 371 DOI 10.17487/RFC5440, March 2009, 372 . 374 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 375 (TE) Extensions to OSPF Version 2", RFC 3630, 376 DOI 10.17487/RFC3630, September 2003, 377 . 379 9.2. Informative References 381 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 382 S. Ray, "North-Bound Distribution of Link-State and 383 Traffic Engineering (TE) Information Using BGP", RFC 7752, 384 DOI 10.17487/RFC7752, March 2016, 385 . 387 Appendix A. New Message 389 A new message may be defined to advertise the information on links. 390 The format of the message for the information on Links (IL for short) 391 is as follows: 393 ::= 394 where: 395 ::= [] 397 Where the value of the Message-Type in the Common Header indicates 398 the new message type. The exact value is to be assigned by IANA. A 399 new RP (NRP) object will be defined, which follows the Common Header. 401 A new flag W (Withdraw) in the NRP object is defined to indicate 402 whether the links are withdrawn. When flag W is set to one, the PCE 403 removes the links in the message after receiving it from the PCC. 404 When flag W is set to zero, the PCE adds/updates the links in the 405 message. 407 An alternative to flag W in the NRP object is a similar flag W in 408 each LINK object. For example, when the flag is set to one in the 409 LINK object, the PCE removes the links in the object. When the flag 410 is set to zero, the PCE adds/updates the links in the object. 412 The format of a LINK object body is as follows: 414 Object-Class = ocTBD1 (LINK) Object-Type = 1 (Link) 415 0 1 2 3 416 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 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 |W| Flags | (Router-ID TLV) | 419 +-+-+-+-+-+-+-+-+ + 420 ~ ~ 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | Link TLVs | 423 ~ ~ 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 Flag W=1 indicates Withdraw links. W=0 indicates Updated links. 427 Router-ID TLV is optional. Link TLVs are mandatory. They are the 428 same as described in section 5. 430 Authors' Addresses 432 Huaimo Chen 433 Futurewei 434 Boston, MA, 435 United States of America 437 Email: Huaimo.chen@futurewei.com 439 Mehmet Toy 440 Verizon 441 United States of America 443 Email: mehmet.toy@verizon.com 445 Xufeng Liu 446 Volta Networks 447 McLean, VA 448 United States of America 450 Email: xufeng.liu.ietf@gmail.com 452 Lei Liu 453 Fujitsu 454 United States of America 456 Email: liulei.kddi@gmail.com 457 Zhenqiang Li 458 China Mobile 459 No.32 Xuanwumenxi Ave., Xicheng District 460 Beijing 461 100032 462 P.R. China 464 Email: li_zhenqiang@hotmail.com