idnits 2.17.1 draft-chen-pce-h-discovery-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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (10 January 2022) is 827 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: 'RFC6805' is defined on line 386, but no explicit reference was found in the text == Unused Reference: 'RFC2328' is defined on line 399, but no explicit reference was found in the text == Unused Reference: 'RFC4271' is defined on line 403, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 6805 Summary: 2 errors (**), 0 flaws (~~), 4 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 Hierarchical PCE Determination 15 draft-chen-pce-h-discovery-10 17 Abstract 19 This document presents extensions to the Path Computation Element 20 Communication Protocol (PCEP) for determining parent child relations 21 and exchanging the information between a parent and a child PCE in a 22 hierarchical PCE system. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Conventions Used in This Document . . . . . . . . . . . . . . 3 60 4. Extensions to PCEP . . . . . . . . . . . . . . . . . . . . . 4 61 4.1. Determination of Parent Child Relation . . . . . . . . . 4 62 4.2. Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . . 5 63 4.2.1. Domain Sub-TLV . . . . . . . . . . . . . . . . . . . 5 64 4.2.2. PCE ID Sub-TLV . . . . . . . . . . . . . . . . . . . 5 65 4.3. Procedures . . . . . . . . . . . . . . . . . . . . . . . 7 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 68 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 9 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 71 8.2. Informative References . . . . . . . . . . . . . . . . . 9 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 74 1. Introduction 76 A hierarchical PCE architecture is described in RFC 6805, in which a 77 parent PCE has a number of child PCEs. A child PCE may also be a 78 parent PCE, which has multiple child PCEs. 80 For a parent PCE, it needs to obtain the information about each of 81 its child PCEs. The information about a child PCE comprises the 82 address or ID of the PCE and the domain for which the PCE is 83 responsible. It may also include the position of the PCE, which 84 indicates whether the PCE is a leaf (i.e., only a child) or branch 85 (i.e., a child and also a parent). In addition, the information may 86 indicate whether the child PCE and its responsible domain is in a 87 same organization as the parent PCE. 89 For a child PCE, it needs to obtain the information about its parent 90 PCE, which includes the address or ID of the parent PCE. The 91 information may also indicate whether the parent PCE is in a same 92 organization as the child PCE. 94 After a user configures a parent PCE and a child PCE over a session, 95 this parent child PCE relation needs to be determined in the protocol 96 level. This is similar to OSPF and BGP. After an adjacency between 97 two OSPF routers is configured by a user, the OSPF protocol (refer to 98 RFC 2328, Section 7) will determine whether the adjacency is allowed 99 based on the parameters configured, and forms the OSPF adjacency 100 after the determination. After a peer relation between two BGP 101 routers is configured by a user, the BGP protocol (refer to RFC 4271, 102 Section 8) will determine whether the peer is allowed based on the 103 parameters configured, and forms the BGP peer relation after the 104 determination. 106 For a parent child PCE relation determination, the PCE protocol needs 107 to check or confirm whether the parent child PCE relation is allowed 108 based on the parameters configured. If so, the child PCE has to send 109 its parent PCE the information about it and vice versa. 111 This document presents extensions to the Path Computation Element 112 Communication Protocol (PCEP) for determining parent child relations 113 and exchanging the information between a parent and a child PCE in a 114 hierarchical PCE system. 116 2. Terminology 118 The following terminology is used in this document. 120 Parent Domain: A domain higher up in a domain hierarchy such that it 121 contains other domains (child domains) and potentially other links 122 and nodes. 124 Child Domain: A domain lower in a domain hierarchy such that it has 125 a parent domain. 127 Parent PCE: A PCE responsible for selecting a path across a parent 128 domain and any number of child domains by coordinating with child 129 PCEs and examining a topology map that shows domain inter- 130 connectivity. 132 Child PCE: A PCE responsible for computing the path across one or 133 more specific (child) domains. A child PCE maintains a 134 relationship with at least one parent PCE. 136 TED: Traffic Engineering Database. 138 This document uses terminology defined in [RFC5440]. 140 3. Conventions Used in This Document 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in [RFC2119]. 146 4. Extensions to PCEP 148 This section describes the extensions to PCEP for determining the 149 relation between a parent PCE and a child PCE and exchanging the 150 information between a parent and a child PCE in a hierarchical PCE 151 system. A child PCE is simply called a child and a parent PCE is 152 called a parent in the following sections. 154 4.1. Determination of Parent Child Relation 156 During a PCEP session establishment between two PCEP speakers, each 157 of them advertises its capabilities for Hierarchical PCE (H-PCE for 158 short) through the Open Message with the Open Object containing a new 159 TLV to indicate its capabilities for H-PCE. This new TLV is called 160 H-PCE capability TLV. It has the following format. 162 0 1 2 3 163 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 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | Type = TBD1 | Length | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 |P|C|S|B| Capability Flags | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | Optional Sub-TLVs | 170 ~ ~ 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 The type of the TLV is TBD1. It has a length of 4 octets plus the 174 size of optional Sub-TLVs. The value of the TLV comprises a 175 capability flags field of 32 bits, which are numbered from the most 176 significant as bit zero. Some of them are defined as follows. The 177 others are not defined and MUST be set to zero. 179 o P (Parent - 1 bit): Bit 0 is used as P flag. It is set to 1 180 indicating a parent. 182 o C (Child - 1 bit): Bit 1 is used as C flag. It is set to 1 183 indicating a child. 185 o S (Same Org - 1 bit): Bit 2 is used as S flag. It is set to 1 186 indicating a PCE in a same organization as its remote peer. 188 o B (Both - 1 bit): Bit 3 is used as B flag. It is set to 1 189 indicating a PCE as both a child and a parent. 191 The following Sub-TLVs are defined: 193 o A Domain Sub-TLV containing an AS number and optional area, and 195 o PCE-ID Sub-TLV containing the ID of a PCE. 197 4.2. Sub-TLVs 199 When a child sends its parent a Open message, it places the 200 information about it in the message through using some optional Sub- 201 TLVs. When a parent sends each of its child PCEs a Open message, it 202 puts the information about it in the message. 204 4.2.1. Domain Sub-TLV 206 A domain is an AS or an area in an AS. An AS is identified by an AS 207 number. An area in an AS is identified by the combination of the AS 208 and the area. The former is indicated by an AS number and the latter 209 by an area number. A domain is represented by a domain Sub-TLV 210 containing an AS number and a optional area number. 212 The format of the domain Sub-TLV is shown below: 214 0 1 2 3 215 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 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | Type (tTBD1) | Length | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | AS Number (4 bytes) | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 ~ Optional Area Number ~ 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 where Length is four plus size of area number. 226 An AS is represented by a domain Sub-TLV containing only the AS 227 number of the AS. In this case, the Length is four. An area in an 228 AS is represented by a domain Sub-TLV containing the AS number of the 229 AS and the area number of the area. In this case, the Length is 230 eight. 232 4.2.2. PCE ID Sub-TLV 234 An Identifier (ID) of a PCE (PCE ID for short) is a 32-bit number 235 that uniquely identifies the PCE among all PCEs. This 32-bit number 236 for PCE ID SHOULD NOT be zero. 238 The format of the PCE ID Sub-TLV is shown below: 240 0 1 2 3 241 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 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Type (tTBD3) | Length (4) | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | PCE ID (4 bytes) | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 The PCE ID Sub-TLV specifies an non zero number as the identifier of the PCE. 250 Alternatively, an IP address attached to a PCE can also be used as an 251 identifier of the PCE. The format of an IPv4 address Sub-TLV is 252 shown below: 254 0 1 2 3 255 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 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Type (tTBD4) | Length (4) | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | IPv4 Address (4 bytes) | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 The IPv4 address Sub-TLV specifies an IPv4 address associated with 263 the PCE, which is used as the identifier of the PCE. 265 The format of an IPv6 address Sub-TLV is shown below: 267 0 1 2 3 268 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 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Type (tTBD5) | Length (16) | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | IPv6 Address (16 bytes) | 273 ~ ~ 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 The IPv6 Sub-TLV specifies an IPv6 address associated with the PCE, 277 which is used as the identifier of the PCE. 279 4.3. Procedures 281 For two PCEs A and B configured as parent and child, they determine 282 parent child relation through Open messages in the initialization 283 phase. The following is a sequence of events related. 285 A B 286 Configure B Configure A 287 as its child as its parent 288 Open (P=1, A's ID) 289 -------------------> Same as configured 290 A is B's parent 291 Open (C=1, B's ID) 292 Same as configured <------------------- 293 B is A's child 295 A sends B a Open message with P=1 and A's ID after B is configured as 296 its child on it. B sends A a Open message with C=1 and B's ID after 297 A is configured as its parent on it. 299 When A receives the Open message from B and determines C=1 and the 300 PCE ID of B in the message is the same as the PCE ID of the child 301 locally configured, B is A's child. 303 When B receives the Open message from A and determines P=1 and the 304 PCE ID of A in the message is the same as the PCE ID of the parent 305 locally configured, A is B's parent. 307 The Open message from child B to its parent A contains B's domain, 308 which is represented by a domain Sub-TLV in the H-PCE capability TLV. 309 If child B is also a parent, the B flag in the TLV is set to 1. 311 The PCE ID in a Open message may be represented in one of the 312 following ways: 314 o The source IP address of the message (i.e., PCE session). 316 o A PCE ID Sub-TLV in the H-PCE capability TLV. 318 o An IP address Sub-TLV in the H-PCE capability TLV. 320 When the IP address Sub-TLV is used, the address in the Sub-TLV MUST 321 be the same as the source IP address of the PCE session. 323 For a child that is a leaf, it is normally responsible for one 324 domain, which is contained in the message to its parent. 326 For a child that is a branch (i.e., also a parent of multiple child 327 PCEs), it may be directly responsible for one domain, which is 328 contained in the message to its parent. In addition, it is 329 responsible for the domains of its child PCEs. In other words, it is 330 responsible for computing paths crossing the domains through working 331 together with its child PCEs. If these domains are all areas of an 332 AS, the AS is included in the message to its parent. 334 A parent stores the information about each of its child PCEs 335 received. When the session to one of them is down, it removes the 336 information about the child on that session. 338 A child stores the information about its parent received. When the 339 session to the parent is down, it removes the information about the 340 parent. 342 If there already exists a session between A and B and the 343 configurations on parent and child are issued on them, the procedures 344 above may be executed through bringing down the existing session and 345 establishing a new session between them. Alternatively, they may 346 determine parent child relation through using extended Notification 347 messages in the same procedures as using Open messages described 348 above without bringing down the existing session. 350 The following new Notification-type and Notification-value are 351 defined for H-PCE: 353 o Notification-type=5 (TBD): Determination of H-PCE 355 * Notification-value=1: The information about a parent PCE or a 356 child PCE. A Notification-type=5, Notification-value=1 357 indicates that the PCE sends its peer the information about it 358 and a TLV containing the information is in the Notification 359 object. The format and contents of the TLV is the same as the 360 H-PCE capability TLV described above. The only difference may 361 be the type of the TLV. 363 5. Security Considerations 365 The mechanism described in this document does not raise any new 366 security issues for the PCEP protocols. 368 6. IANA Considerations 370 This section specifies requests for IANA allocation. 372 7. Acknowledgement 374 The authors would like to Jescia Chen, Adrian Farrel for their 375 valuable comments on this draft. 377 8. References 379 8.1. Normative References 381 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 382 Requirement Levels", BCP 14, RFC 2119, 383 DOI 10.17487/RFC2119, March 1997, 384 . 386 [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the 387 Path Computation Element Architecture to the Determination 388 of a Sequence of Domains in MPLS and GMPLS", RFC 6805, 389 DOI 10.17487/RFC6805, November 2012, 390 . 392 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 393 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 394 DOI 10.17487/RFC5440, March 2009, 395 . 397 8.2. Informative References 399 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 400 DOI 10.17487/RFC2328, April 1998, 401 . 403 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 404 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 405 DOI 10.17487/RFC4271, January 2006, 406 . 408 Authors' Addresses 410 Huaimo Chen 411 Futurewei 412 Boston, MA, 413 United States of America 415 Email: Huaimo.chen@futurewei.com 416 Mehmet Toy 417 Verizon 418 United States of America 420 Email: mehmet.toy@verizon.com 422 Xufeng Liu 423 Volta Networks 424 McLean, VA 425 United States of America 427 Email: xufeng.liu.ietf@gmail.com 429 Lei Liu 430 Fujitsu 431 United States of America 433 Email: liulei.kddi@gmail.com 435 Zhenqiang Li 436 China Mobile 437 No.32 Xuanwumenxi Ave., Xicheng District 438 Beijing 439 100032 440 P.R. China 442 Email: li_zhenqiang@hotmail.com