idnits 2.17.1 draft-chen-pce-pcc-ted-05.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 copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 7, 2019) is 1717 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 366, but no explicit reference was found in the text == Unused Reference: 'RFC3630' is defined on line 376, but no explicit reference was found in the text == Unused Reference: 'RFC7752' is defined on line 383, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4655 -- Obsolete informational reference (is this intentional?): RFC 7752 (Obsoleted by RFC 9552) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). 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: January 8, 2020 Verizon 6 X. Liu 7 Volta Networks 8 L. Liu 9 Fujitsu 10 Z. Li 11 China Mobile 12 July 7, 2019 14 Static PCEP Link State 15 draft-chen-pce-pcc-ted-05 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 January 8, 2020. 41 Copyright Notice 43 Copyright (c) 2019 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 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Conventions Used in This Document . . . . . . . . . . . . . . 3 61 4. Link Information . . . . . . . . . . . . . . . . . . . . . . 3 62 5. Extensions to PCEP . . . . . . . . . . . . . . . . . . . . . 4 63 5.1. Extension to Existing Message . . . . . . . . . . . . . . 4 64 5.1.1. TLVs . . . . . . . . . . . . . . . . . . . . . . . . 4 65 5.1.2. Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . 5 66 5.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 6 67 5.2.1. PCC Procedures . . . . . . . . . . . . . . . . . . . 6 68 5.2.2. PCE Procedures . . . . . . . . . . . . . . . . . . . 7 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 71 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 8 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 74 9.2. Informative References . . . . . . . . . . . . . . . . . 9 75 Appendix A. New Message . . . . . . . . . . . . . . . . . . . . 10 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 78 1. Introduction 80 A PCE architecture is described in RFC 4655, in which a Traffic 81 Engineering Database (TED) for a PCE is constructed based on the link 82 information from IGP (OSPF or IS-IS) running in the domain for which 83 the PCE is responsible. 85 For a domain without running IGP, the PCE responsible for the domain 86 may obtain the link information from a PCC running on each node in 87 the domain. 89 This document presents extensions to the Path Computation Element 90 Communication Protocol (PCEP) for a PCC to advertise the information 91 about the links attached to the node running the PCC and for a PCE to 92 build the TED based on the information received from the PCC. 94 2. Terminology 96 ABR: Area Border Router. Router used to connect two IGP areas 97 (Areas in OSPF or levels in IS-IS). 99 ASBR: Autonomous System (AS) Border Router. Router used to connect 100 together ASes via inter-AS links. 102 This document uses terminology defined in [RFC5440]. 104 3. Conventions Used in This Document 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. 110 4. Link Information 112 Since no IGP runs over any link, we may not obtain any link 113 information via IGP. But links are configured. 115 For a point-to-point (P2P) link between nodes A and B, from A's point 116 of view, we have the following link information: 118 1) Link Type: P2P 119 2) Local IP address 120 3) Remote IP address 121 4) Traffic engineering metric 122 5) Maximum bandwidth 123 6) Maximum reservable bandwidth 124 7) Unreserved bandwidth 125 8) Administrative group 126 9) SRLG 128 A link ID for the link is obtained if a user configures it; 129 otherwise, no link ID (i.e., the Router ID of A's neighbor) may be 130 obtained since no IGP adjacency over the link is formed. 132 For a broadcast link connecting multiple nodes, on each of the nodes 133 X, we have the same link information as above except for: 135 a) Link Type: Multi-access, 136 b) Local IP address with mask length, and 137 c) No Remote IP address. 139 In other words, the information about the broadcast link obtained by 140 node X comprises a), b), 4) to 9), but does not include any remote IP 141 address or link ID. A link ID for the link is obtained if a user 142 configures it; otherwise, no link ID (i.e., the interface address of 143 the designated router for the link) may be obtained since no IGP 144 selects it. 146 A PCE constructs a TED for its responsible domain after receiving the 147 link information from the PCC running on every node in the domain. 149 5. Extensions to PCEP 151 5.1. Extension to Existing Message 153 An existing Notification message may be extended to advertise the 154 information about links. Alternatively, a new message can be used 155 (refer to Appendix A). 157 The following new Notification-type (NT) and Notification-value (NV) 158 of a NOTIFICATION object in a Notification message are defined: 160 o NT=8 (TBD): Links 162 * NV=1: Update Links. NT=8 and NV=1 indicates that the PCC 163 requests the PCE to update the link information based on the 164 TLVs in the object, which are described below. 166 * NV=2: Withdraw Links. NT=8 and NV=2 indicates that the PCC 167 asks the PCE to remove the Links indicated by the TLVs in the 168 object. 170 5.1.1. TLVs 172 A link TLV and a Router-ID TLV are defined. The format of the link 173 TLV is illustrated below. The Type=tTBD1 indicates a link TLV Type. 174 The Length indicates the size of the Link Sub-TLVs. 176 0 1 2 3 177 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 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | Type (tTBD1) | Length | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | Link Sub-TLVs | 182 ~ ~ 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 A link TLV describes a single link. It comprises a number of link 186 sub-TLVs for the information described in section 4, which are the 187 sub-TLVs defined in RFC 3630 or their equivalents except for the 188 local IP address with mask length defined below. 190 The format of the Router-ID TLV is shown below. The Type=tTBD2 191 indicates a Router-ID TLV Type. The Length indicates the size of the 192 ID and flags field. 194 0 1 2 3 195 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 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | Type (tTBD2) | Length | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 |B|E|I| Flags | | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 201 | 32-bit/48-bit ID ~ 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 Flag B: Set to 1 indicating ABR (B is for Border) 204 Flag E: Set to 1 indicating ASBR (E is for External) 205 Flag I: Set to 1 indicating ID of local router (I is for ID) 207 Undefined flags MUST be set to zero. The ID indicates the ID of a 208 router. For a router not running IGP, the ID may be the 32-bit or 209 48-bit ID of the router configured. 211 5.1.2. Sub-TLVs 213 The format of the Sub-TLV for a local IPv4 address with mask length 214 is shown below. The Type=stTBD1 indicates a local IPv4 Address with 215 mask length. The Length indicates the size of the IPv4 address and 216 Mask Length. The IPv4 Address indicates the local IPv4 address of a 217 link. The Mask Length indicates the length of the IPv4 address mask. 219 0 1 2 3 220 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 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Type (stTBD1) | Length | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | IPv4 Address | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | Mask Length | 227 +-+-+-+-+-+-+-+-+ 229 The format of the Sub-TLV for a local IPv6 address with mask length 230 is illustrated below. The Type=stTBD2 indicates a local IPv6 Address 231 with mask length. The Length indicates the size of the IPv6 address 232 and Mask Length. The IPv6 Address indicates the local IPv6 address 233 of a link. The Mask Length indicates the length of the IPv6 address 234 mask. 236 0 1 2 3 237 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 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Type (stTBD2) | Length | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | IPv6 Address (16 bytes) | 242 ~ ~ 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Mask Length | 245 +-+-+-+-+-+-+-+-+ 247 5.2. Procedures 249 5.2.1. PCC Procedures 251 1. New or Changed Links 253 After the session between a PCC and a PCE is established, the PCC 254 sends the PCE a message containing the information about the links 255 attached to the node running the PCC. 257 For any new or changed links, the PCC sends the PCE a message 258 containing the information about these links with indication of 259 Update Links. 261 For example, for a new P2P link from node A, the PCC running on A 262 sends the PCE a Notification message having a NOTIFICATION object 263 with NT=8 and NV=1 (indicating Update Links), which contains a 264 Router-ID TLV, followed by a link TLV. The former comprises A's ID 265 and flag I set to 1. The latter comprises the Sub-TLVs for the 266 information described in section 4. 268 For multiple new or changed links from node A, the PCC running on A 269 sends the PCE a Notification message having a NOTIFICATION object 270 with NT=8 and NV=1, which contains a Router-ID TLV for A's ID, 271 followed by multiple link TLVs for the links. 273 2. Links Down 275 For links down, the PCC sends the PCE a message containing the 276 information about these links with indication of Withdraw Links. 278 For example, for multiple links from node A down, the PCC running on 279 A sends the PCE a Notification message having a NOTIFICATION object 280 with NT=8 and NV=2 (indicating Withdraw Links), which contains a 281 Router-ID TLV for A's ID, followed by multiple link TLVs for the 282 links. The TLV for a P2P link comprises the Sub-TLVs for the 283 information on 1), 2) and 3) described in section 4. The TLV for a 284 broadcast link comprises the Sub-TLVs for the information on a) and 285 b) described in section 4. 287 3. Simplified Message 289 Alternatively, the messages may be simplified. For each node, the 290 source IP address of the PCC running on the node may be used as the 291 ID of the node. The PCE knows the address after the session between 292 the PCE and the PCC is up. Thus, a message containing the 293 information about links does not need include any router-ID TLV. 295 For example, for a new P2P link attached to node A, the PCC running 296 on A sends the PCE a Notification message having a NOTIFICATION 297 object with NT=8 and NV=1 (indicating Update Links), which contains a 298 link TLV comprising the Sub-TLVs for the information on 1) to 9) 299 described in section 4. The object does not contain any Router-ID 300 TLV for node A. 302 5.2.2. PCE Procedures 304 A PCE stores into its TED the links for each node according to the 305 messages for the links received from the PCC running on the node. 306 For a message containing Update Links, it updates the links 307 accordingly. For a message containing Withdraw Links, it removes the 308 links. When a node is down, the PCE removes the links attached to 309 the node. 311 For a new P2P link between node A and B with no link ID configured, 312 when receiving a message containing the link from the PCC running on 313 A, the PCE stores the link for A (i.e., the link from A) into its 314 TED. It will find the link's remote end B using the remote IP 315 address of the link. After finding B, it associates the link for A 316 with B and the link for B with A. This creates a bidirectional 317 connection between A and B. 319 For a new broadcast link connecting multiple nodes with no link ID 320 configured, when receiving a message containing the link from the PCC 321 running on each of the nodes X, the PCE stores the link for X (i.e., 322 the link from X) into its TED. It will find the link's remote end P 323 using the link's local IP address with network mask. P is a Pseudo 324 node identified by the local IP address of the designated node 325 selected from the nodes connected to the link. After finding P, it 326 associates the link for X with P and the link for P with X. This 327 creates a bidirectional connection between X and P. 329 The first node and second node from which the PCE receives a message 330 containing the link is selected as the designed node and backup 331 designed node respectively. After the designed node is down, the 332 backup designed node becomes the designed node and the node other 333 than the designed node with the largest local IP address connecting 334 to the link is selected as the backup designed node. 336 When the old designed node is down and the backup designed node 337 becomes the new designed node, the PCE updates its TED through 338 removing the link between each of nodes X and old P (the Pseudo node 339 corresponding to the old designed node) and adding a link between 340 each of nodes X (still connecting to the broadcast link) and new P 341 (the Pseudo node corresponding to the new designed node). 343 6. Security Considerations 345 The mechanism described in this document does not raise any new 346 security issues for the PCEP protocols. 348 7. IANA Considerations 350 This section specifies requests for IANA allocation. 352 8. Acknowledgement 354 The authors would like to thank Jescia Chen, and Eric Wu for their 355 valuable comments on this draft. 357 9. References 359 9.1. Normative References 361 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 362 Requirement Levels", BCP 14, RFC 2119, 363 DOI 10.17487/RFC2119, March 1997, 364 . 366 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 367 Element (PCE)-Based Architecture", RFC 4655, 368 DOI 10.17487/RFC4655, August 2006, 369 . 371 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 372 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 373 DOI 10.17487/RFC5440, March 2009, 374 . 376 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 377 (TE) Extensions to OSPF Version 2", RFC 3630, 378 DOI 10.17487/RFC3630, September 2003, 379 . 381 9.2. Informative References 383 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 384 S. Ray, "North-Bound Distribution of Link-State and 385 Traffic Engineering (TE) Information Using BGP", RFC 7752, 386 DOI 10.17487/RFC7752, March 2016, 387 . 389 Appendix A. New Message 391 A new message may be defined to advertise the information on links. 392 The format of the message for the information on Links (IL for short) 393 is as follows: 395 ::= 396 where: 397 ::= [] 399 Where the value of the Message-Type in the Common Header indicates 400 the new message type. The exact value is to be assigned by IANA. A 401 new RP (NRP) object will be defined, which follows the Common Header. 403 A new flag W (Withdraw) in the NRP object is defined to indicate 404 whether the links are withdrawn. When flag W is set to one, the PCE 405 removes the links in the message after receiving it from the PCC. 406 When flag W is set to zero, the PCE adds/updates the links in the 407 message. 409 An alternative to flag W in the NRP object is a similar flag W in 410 each LINK object. For example, when the flag is set to one in the 411 LINK object, the PCE removes the links in the object. When the flag 412 is set to zero, the PCE adds/updates the links in the object. 414 The format of a LINK object body is as follows: 416 Object-Class = ocTBD1 (LINK) Object-Type = 1 (Link) 417 0 1 2 3 418 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 |W| Flags | (Router-ID TLV) | 421 +-+-+-+-+-+-+-+-+ + 422 ~ ~ 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | Link TLVs | 425 ~ ~ 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 Flag W=1 indicates Withdraw links. W=0 indicates Updated links. 429 Router-ID TLV is optional. Link TLVs are mandatory. They are the 430 same as described in section 5. 432 Authors' Addresses 434 Huaimo Chen 435 Futurewei 436 Boston, MA 437 USA 439 EMail: Huaimo.chen@futurewei.com 441 Mehmet Toy 442 Verizon 443 USA 445 EMail: mehmet.toy@verizon.com 447 Xufeng Liu 448 Volta Networks 449 McLean, VA 450 USA 452 EMail: xufeng.liu.ietf@gmail.com 454 Lei Liu 455 Fujitsu 456 USA 458 EMail: liulei.kddi@gmail.com 460 Zhenqiang Li 461 China Mobile 462 No.32 Xuanwumenxi Ave., Xicheng District 463 Beijing 100032 464 P.R. China 466 EMail: li_zhenqiang@hotmail.com