idnits 2.17.1 draft-chen-pce-h-discovery-07.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 (July 10, 2020) is 1383 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 387, but no explicit reference was found in the text == Unused Reference: 'RFC2328' is defined on line 400, but no explicit reference was found in the text == Unused Reference: 'RFC4271' is defined on line 404, 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: January 11, 2021 Verizon 6 X. Liu 7 Volta Networks 8 L. Liu 9 Fujitsu 10 Z. Li 11 China Mobile 12 July 10, 2020 14 Hierarchical PCE Determination 15 draft-chen-pce-h-discovery-07 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 January 11, 2021. 41 Copyright Notice 43 Copyright (c) 2020 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 . . . . . . . . . . . . . . 4 61 4. Extensions to PCEP . . . . . . . . . . . . . . . . . . . . . 4 62 4.1. Determination of Parent Child Relation . . . . . . . . . 4 63 4.2. Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . . 5 64 4.2.1. Domain Sub-TLV . . . . . . . . . . . . . . . . . . . 5 65 4.2.2. PCE ID Sub-TLV . . . . . . . . . . . . . . . . . . . 6 66 4.3. Procedures . . . . . . . . . . . . . . . . . . . . . . . 7 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 69 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 9 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 72 8.2. Informative References . . . . . . . . . . . . . . . . . 9 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 75 1. Introduction 77 A hierarchical PCE architecture is described in RFC 6805, in which a 78 parent PCE has a number of child PCEs. A child PCE may also be a 79 parent PCE, which has multiple child PCEs. 81 For a parent PCE, it needs to obtain the information about each of 82 its child PCEs. The information about a child PCE comprises the 83 address or ID of the PCE and the domain for which the PCE is 84 responsible. It may also include the position of the PCE, which 85 indicates whether the PCE is a leaf (i.e., only a child) or branch 86 (i.e., a child and also a parent). In addition, the information may 87 indicate whether the child PCE and its responsible domain is in a 88 same organization as the parent PCE. 90 For a child PCE, it needs to obtain the information about its parent 91 PCE, which includes the address or ID of the parent PCE. The 92 information may also indicate whether the parent PCE is in a same 93 organization as the child PCE. 95 After a user configures a parent PCE and a child PCE over a session, 96 this parent child PCE relation needs to be determined in the protocol 97 level. This is similar to OSPF and BGP. After an adjacency between 98 two OSPF routers is configured by a user, the OSPF protocol (refer to 99 RFC 2328, Section 7) will determine whether the adjacency is allowed 100 based on the parameters configured, and forms the OSPF adjacency 101 after the determination. After a peer relation between two BGP 102 routers is configured by a user, the BGP protocol (refer to RFC 4271, 103 Section 8) will determine whether the peer is allowed based on the 104 parameters configured, and forms the BGP peer relation after the 105 determination. 107 For a parent child PCE relation determination, the PCE protocol needs 108 to check or confirm whether the parent child PCE relation is allowed 109 based on the parameters configured. If so, the child PCE has to send 110 its parent PCE the information about it and vice versa. 112 This document presents extensions to the Path Computation Element 113 Communication Protocol (PCEP) for determining parent child relations 114 and exchanging the information between a parent and a child PCE in a 115 hierarchical PCE system. 117 2. Terminology 119 The following terminology is used in this document. 121 Parent Domain: A domain higher up in a domain hierarchy such that it 122 contains other domains (child domains) and potentially other links 123 and nodes. 125 Child Domain: A domain lower in a domain hierarchy such that it has 126 a parent domain. 128 Parent PCE: A PCE responsible for selecting a path across a parent 129 domain and any number of child domains by coordinating with child 130 PCEs and examining a topology map that shows domain inter- 131 connectivity. 133 Child PCE: A PCE responsible for computing the path across one or 134 more specific (child) domains. A child PCE maintains a 135 relationship with at least one parent PCE. 137 TED: Traffic Engineering Database. 139 This document uses terminology defined in [RFC5440]. 141 3. Conventions Used in This Document 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in [RFC2119]. 147 4. Extensions to PCEP 149 This section describes the extensions to PCEP for determining the 150 relation between a parent PCE and a child PCE and exchanging the 151 information between a parent and a child PCE in a hierarchical PCE 152 system. A child PCE is simply called a child and a parent PCE is 153 called a parent in the following sections. 155 4.1. Determination of Parent Child Relation 157 During a PCEP session establishment between two PCEP speakers, each 158 of them advertises its capabilities for Hierarchical PCE (H-PCE for 159 short) through the Open Message with the Open Object containing a new 160 TLV to indicate its capabilities for H-PCE. This new TLV is called 161 H-PCE capability TLV. It has the following format. 163 0 1 2 3 164 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 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | Type = TBD1 | Length | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 |P|C|S|B| Capability Flags | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | Optional Sub-TLVs | 171 ~ ~ 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 The type of the TLV is TBD1. It has a length of 4 octets plus the 175 size of optional Sub-TLVs. The value of the TLV comprises a 176 capability flags field of 32 bits, which are numbered from the most 177 significant as bit zero. Some of them are defined as follows. The 178 others are not defined and MUST be set to zero. 180 o P (Parent - 1 bit): Bit 0 is used as P flag. It is set to 1 181 indicating a parent. 183 o C (Child - 1 bit): Bit 1 is used as C flag. It is set to 1 184 indicating a child. 186 o S (Same Org - 1 bit): Bit 2 is used as S flag. It is set to 1 187 indicating a PCE in a same organization as its remote peer. 189 o B (Both - 1 bit): Bit 3 is used as B flag. It is set to 1 190 indicating a PCE as both a child and a parent. 192 The following Sub-TLVs are defined: 194 o A Domain Sub-TLV containing an AS number and optional area, and 196 o PCE-ID Sub-TLV containing the ID of a PCE. 198 4.2. Sub-TLVs 200 When a child sends its parent a Open message, it places the 201 information about it in the message through using some optional Sub- 202 TLVs. When a parent sends each of its child PCEs a Open message, it 203 puts the information about it in the message. 205 4.2.1. Domain Sub-TLV 207 A domain is an AS or an area in an AS. An AS is identified by an AS 208 number. An area in an AS is identified by the combination of the AS 209 and the area. The former is indicated by an AS number and the latter 210 by an area number. A domain is represented by a domain Sub-TLV 211 containing an AS number and a optional area number. 213 The format of the domain Sub-TLV is shown below: 215 0 1 2 3 216 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 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Type (tTBD1) | Length | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | AS Number (4 bytes) | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 ~ Optional Area Number ~ 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 where Length is four plus size of area number. 227 An AS is represented by a domain Sub-TLV containing only the AS 228 number of the AS. In this case, the Length is four. An area in an 229 AS is represented by a domain Sub-TLV containing the AS number of the 230 AS and the area number of the area. In this case, the Length is 231 eight. 233 4.2.2. PCE ID Sub-TLV 235 An Identifier (ID) of a PCE (PCE ID for short) is a 32-bit number 236 that uniquely identifies the PCE among all PCEs. This 32-bit number 237 for PCE ID SHOULD NOT be zero. 239 The format of the PCE ID Sub-TLV is shown below: 241 0 1 2 3 242 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 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Type (tTBD3) | Length (4) | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | PCE ID (4 bytes) | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 The PCE ID Sub-TLV specifies an non zero number as the identifier of the PCE. 251 Alternatively, an IP address attached to a PCE can also be used as an 252 identifier of the PCE. The format of an IPv4 address Sub-TLV is 253 shown below: 255 0 1 2 3 256 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 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Type (tTBD4) | Length (4) | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | IPv4 Address (4 bytes) | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 The IPv4 address Sub-TLV specifies an IPv4 address associated with 264 the PCE, which is used as the identifier of the PCE. 266 The format of an IPv6 address Sub-TLV is shown below: 268 0 1 2 3 269 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 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | Type (tTBD5) | Length (16) | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | IPv6 Address (16 bytes) | 274 ~ ~ 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 The IPv6 Sub-TLV specifies an IPv6 address associated with the PCE, 278 which is used as the identifier of the PCE. 280 4.3. Procedures 282 For two PCEs A and B configured as parent and child, they determine 283 parent child relation through Open messages in the initialization 284 phase. The following is a sequence of events related. 286 A B 287 Configure B Configure A 288 as its child as its parent 289 Open (P=1, A's ID) 290 -------------------> Same as configured 291 A is B's parent 292 Open (C=1, B's ID) 293 Same as configured <------------------- 294 B is A's child 296 A sends B a Open message with P=1 and A's ID after B is configured as 297 its child on it. B sends A a Open message with C=1 and B's ID after 298 A is configured as its parent on it. 300 When A receives the Open message from B and determines C=1 and the 301 PCE ID of B in the message is the same as the PCE ID of the child 302 locally configured, B is A's child. 304 When B receives the Open message from A and determines P=1 and the 305 PCE ID of A in the message is the same as the PCE ID of the parent 306 locally configured, A is B's parent. 308 The Open message from child B to its parent A contains B's domain, 309 which is represented by a domain Sub-TLV in the H-PCE capability TLV. 310 If child B is also a parent, the B flag in the TLV is set to 1. 312 The PCE ID in a Open message may be represented in one of the 313 following ways: 315 o The source IP address of the message (i.e., PCE session). 317 o A PCE ID Sub-TLV in the H-PCE capability TLV. 319 o An IP address Sub-TLV in the H-PCE capability TLV. 321 When the IP address Sub-TLV is used, the address in the Sub-TLV MUST 322 be the same as the source IP address of the PCE session. 324 For a child that is a leaf, it is normally responsible for one 325 domain, which is contained in the message to its parent. 327 For a child that is a branch (i.e., also a parent of multiple child 328 PCEs), it may be directly responsible for one domain, which is 329 contained in the message to its parent. In addition, it is 330 responsible for the domains of its child PCEs. In other words, it is 331 responsible for computing paths crossing the domains through working 332 together with its child PCEs. If these domains are all areas of an 333 AS, the AS is included in the message to its parent. 335 A parent stores the information about each of its child PCEs 336 received. When the session to one of them is down, it removes the 337 information about the child on that session. 339 A child stores the information about its parent received. When the 340 session to the parent is down, it removes the information about the 341 parent. 343 If there already exists a session between A and B and the 344 configurations on parent and child are issued on them, the procedures 345 above may be executed through bringing down the existing session and 346 establishing a new session between them. Alternatively, they may 347 determine parent child relation through using extended Notification 348 messages in the same procedures as using Open messages described 349 above without bringing down the existing session. 351 The following new Notification-type and Notification-value are 352 defined for H-PCE: 354 o Notification-type=5 (TBD): Determination of H-PCE 356 * Notification-value=1: The information about a parent PCE or a 357 child PCE. A Notification-type=5, Notification-value=1 358 indicates that the PCE sends its peer the information about it 359 and a TLV containing the information is in the Notification 360 object. The format and contents of the TLV is the same as the 361 H-PCE capability TLV described above. The only difference may 362 be the type of the TLV. 364 5. Security Considerations 366 The mechanism described in this document does not raise any new 367 security issues for the PCEP protocols. 369 6. IANA Considerations 371 This section specifies requests for IANA allocation. 373 7. Acknowledgement 375 The authors would like to Jescia Chen, Adrian Farrel for their 376 valuable comments on this draft. 378 8. References 380 8.1. Normative References 382 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 383 Requirement Levels", BCP 14, RFC 2119, 384 DOI 10.17487/RFC2119, March 1997, 385 . 387 [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the 388 Path Computation Element Architecture to the Determination 389 of a Sequence of Domains in MPLS and GMPLS", RFC 6805, 390 DOI 10.17487/RFC6805, November 2012, 391 . 393 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 394 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 395 DOI 10.17487/RFC5440, March 2009, 396 . 398 8.2. Informative References 400 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 401 DOI 10.17487/RFC2328, April 1998, 402 . 404 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 405 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 406 DOI 10.17487/RFC4271, January 2006, 407 . 409 Authors' Addresses 411 Huaimo Chen 412 Futurewei 413 Boston, MA 414 USA 416 EMail: Huaimo.chen@futurewei.com 417 Mehmet Toy 418 Verizon 419 USA 421 EMail: mehmet.toy@verizon.com 423 Xufeng Liu 424 Volta Networks 425 McLean, VA 426 USA 428 EMail: xufeng.liu.ietf@gmail.com 430 Lei Liu 431 Fujitsu 432 USA 434 EMail: liulei.kddi@gmail.com 436 Zhenqiang Li 437 China Mobile 438 No.32 Xuanwumenxi Ave., Xicheng District 439 Beijing 100032 440 P.R. China 442 EMail: li_zhenqiang@hotmail.com