idnits 2.17.00 (12 Aug 2021) /tmp/idnits49538/draft-whh-pce-capability-advertize-00.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 (25 March 2022) is 50 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-pce-segment-routing has been published as RFC 8664 Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group M. Wang 3 Internet-Draft L. Han 4 Intended status: Informational China Mobile 5 Expires: 26 September 2022 M. Huang 6 Z. Han 7 J. Dai 8 CICT 9 25 March 2022 11 PCEP Extension for INTERACTING-CAPBILITY 12 draft-whh-pce-capability-advertize-00 14 Abstract 16 The PCE communication Protocol (PCEP) is used to convey path 17 computation requests and responses both between Path Computation 18 Clients (PCCs), Path Computation Elements (PCEs) and cooperating 19 PCEs, support of traffic engineering in Multiprotocol Label Switching 20 (MPLS), Generalized MPLS (GMPLS) and Segment Routing (SR) networks. 21 In PCEP, due to the different implementing of PCC tunnel capability, 22 especially bidirectional SR tunnels, the PCE can only provides path 23 computation functions between the PCCs which adopt identical 24 mechanisms. 26 With the introduction and evolvement of 5G and other network 27 scenarios, the scale of bearing and transport network has developed 28 to a high level. On the other hand, with the improvement of network 29 slicing ability, network equipments can provide network slicing 30 service, such as enhanced VPNs (VPN+). Transport network employing 31 time slot isolation technology, such as FlexE,MTN,can provide 32 advanced timeslot slicing for the high quality customer services. 33 The high quality customer services, for example industry production 34 service, demand for superior SLA and end-to-end timeslot service 35 slicing, regardless of whether it is across of different network 36 equipment providers or across of different regions. Therefore, there 37 is an urgent need of a method to support PCE to provide end-to-end 38 path computation and establishment of SR tunnels regardless of PCC 39 enables different protocol selections. 41 This document specifies the extensions to PCE communication Protocol 42 (PCEP) to carry bidirectional SR tunnel capability advertisement 43 information in PCEP message to enhance PCE ability to perceive the 44 protocol mechanism supported by PCC. 46 Requirements Language 47 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 48 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 49 "OPTIONAL" in this document are to be interpreted as described in BCP 50 14 [RFC2119] [RFC8174] when, and only when, they appear in all 51 capitals, as shown here. 53 Status of This Memo 55 This Internet-Draft is submitted in full conformance with the 56 provisions of BCP 78 and BCP 79. 58 Internet-Drafts are working documents of the Internet Engineering 59 Task Force (IETF). Note that other groups may also distribute 60 working documents as Internet-Drafts. The list of current Internet- 61 Drafts is at https://datatracker.ietf.org/drafts/current/. 63 Internet-Drafts are draft documents valid for a maximum of six months 64 and may be updated, replaced, or obsoleted by other documents at any 65 time. It is inappropriate to use Internet-Drafts as reference 66 material or to cite them other than as "work in progress." 68 This Internet-Draft will expire on 26 September 2022. 70 Copyright Notice 72 Copyright (c) 2022 IETF Trust and the persons identified as the 73 document authors. All rights reserved. 75 This document is subject to BCP 78 and the IETF Trust's Legal 76 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 77 license-info) in effect on the date of publication of this document. 78 Please review these documents carefully, as they describe your rights 79 and restrictions with respect to this document. Code Components 80 extracted from this document must include Revised BSD License text as 81 described in Section 4.e of the Trust Legal Provisions and are 82 provided without warranty as described in the Revised BSD License. 84 Table of Contents 86 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 87 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 88 3. Overview of SR Tunnel Capability Notification in PCEP . . . . 4 89 4. TLV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 90 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 91 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 92 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 93 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 94 7.2. Informative References . . . . . . . . . . . . . . . . . 8 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 98 1. Introduction 100 [RFC5440]describes the Path Computation Element (PCE) Communication 101 Protocol (PCEP). PCEP defines the communication between a Path 102 Computation Client (PCC) and a PCE, or between PCE and PCE, enabling 103 computation of Multiprotocol Label Switching (MPLS) for Traffic 104 Engineering Label Switched Path (TE LSP) characteristics. 106 [RFC8231] specifies a set of extensions to PCEP to enable stateful 107 control of TE LSPs within and across PCEP sessions in compliance with 108 [RFC4657]. It includes mechanisms to effect LSP State 109 Synchronization between PCCs and PCEs, delegation of control over 110 LSPs to PCEs, and PCE control of timing and sequence of path 111 computations within and across PCEP sessions. The model of operation 112 where LSPs are initiated from the PCE is described in [RFC8281]. 114 [I-D.ietf-pce-segment-routing] specifies extensions to the Path 115 Computation Element Protocol (PCEP)for SR networks, that allow a 116 stateful PCE to compute and initiate SR-TE paths, as well as a PCC to 117 request, report or delegate SR paths. 119 [I-D.li-pce-sr-path-segment] specifies a mechanism to carry the SR 120 path identification information in PCEP messages. 122 [I-D.ietf-pce-binding-label-sid] specifies the binding value as an 123 MPLS label or Segment Identifier. It further specifies an approach 124 for reporting binding label/Segment Identifier (SID) by a Path 125 Computation Client (PCC) to the Path Computation Element (PCE) to 126 support PCE-based Traffic Engineering policies. 128 Two different implementation mechanisms of PCEP are defined in the 129 standard protocol: Passive Stateful PCE and Active Stateful PCE. For 130 Passive Stateful PCE, the PCC sends a path computation request to the 131 PCE, the PCE triggers a path computation and returns either a 132 positive or a negative reply to the PCC. For Active Stateful PCE, to 133 create or update LSP, PCE MUST send LSP Update Request to PCC using 134 PCUpd message or using PCInt message. 136 [I-D.li-pce-sr-path-segment] specifies various modes of operations 137 for SR-path segment. Path Segment can be either allocated by Egress 138 PCC or PCE. This leads to different implementation methods for the 139 extension of Path Segment. Meanwhile PCEP procedure is divided into 140 PCC-initiated and PCE-initiated LSPs[RFC9059].For example, 141 Association ID is used for bidirectional SR tunnel binding. The 142 difference of Association ID allocation between PCC-initiated and 143 PCE-initiated is as follows: In PCC-initiated, the PCE needs to 144 control whether the PCC reports the Association ID or not. If the 145 PCE receives the Association ID reported by the PCC through PCRpt, it 146 will be issued according to the Association ID reported by the PCC; 147 if the PCE has not received the Association ID through the PCC, the 148 PCE will directly assign an ID to the PCC. In PCE-initiated,the PCE 149 directly assigns the AssociationID. 151 This document specifies a new OPTIONAL TLV for multiple PCC 152 interworking scenarios. PCC can employ this TLV to report PCC 153 abilities of supporting different mechanisms of bidirectional SR 154 tunnels. PCE can perceive the specific implementation mode of PCC by 155 parsing this TLV,in order to achieve the compatibility of multiple 156 sets of PCEP standard processes in the management and control system. 157 Particularly, Vendor TLV[RFC7470] can be used as a special 158 implementation mechanism when various capability distinctions have 159 been reconciled in advance. 161 2. Terminology 163 This memo makes use of the terms defined in [RFC4655], 164 [RFC5440],[I-D.li-pce-sr-path-segment], 165 [I-D.ietf-pce-binding-label-sid] and [RFC8042]. 167 3. Overview of SR Tunnel Capability Notification in PCEP 169 SR-PCE-INTERACTING-CAPBILITY TLV clarifies various capability 170 distinctions of PCC. Through this TLV,the PCC sends its own 171 capability information to the PCE,which is used to determine the 172 bidirectional segment routing tunnel capability supported by the PCC, 173 whether the tunnel creation is initiated by the PCC or the PCE, and 174 whether the distribution is supported by the label allocation to the 175 PCC or the PCE,etc. 177 The PCE determines the bidirectional SR tunnel capability supported 178 by the PCC through the acquired capability information of the PCC, 179 and performs corresponding management on the PCC that supports 180 different capabilities according to the capability. The PCE parses 181 this TLV. Through the analysis results of different fields in this 182 tlv, it can preceive which mode of the PCEP standard process is 183 currently supported by PCC,in order to achieve PCEP interoperability. 184 This solution can realize the PCEP implementation to compatible with 185 different PCCs. 187 4. TLV 189 The SR-PCE-INTERACTING-CAPBILITY is an optional TLV associated with 190 the OPEN Object to exchange SR Tunnel Capability Notification of PCEP 191 speakers. When the PCEP session is created, PCC sends an Open 192 message with an OPEN object containing the SR-PCE-INTERACTING- 193 CAPBILITY TLV. 195 When the PCE receives the Open message with a SR-PCE-INTERACTING- 196 CAPBILITY TLV, the PCE can parse the TLV. According to the results 197 of the analysis of each capability field of the TLV, it can realize 198 how the PCC implements the SR tunnel as a basis to send the 199 corresponding PCEP message. In an Open message, a PCC MAY insert one 200 SR-PCE-INTERACTING-CAPBILITY-TLV, PCC can assign different values to 201 the corresponding fields to announce its own PCEP capability. 203 The format of SR-PCE-INTERACTING-CAPBILITY TLV is defined as follows: 205 0 1 2 3 206 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 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | Type = TDB | Length = 4 | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | Reserved | N |FLAGS|S|C|P|B|T|A| 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 Figure 1 SR-PCE-INTERACTING-CAPBILITY TLV format 215 The code point for the TLV type is to be defined by IANA. The TLV 216 length is 4 octets. 218 The 32-bit value is formatted as follows. The "Reserved" is unused. 220 The" Flags "(2 bits) field is unused, and MUST be set to zero on 221 transmission and ignored on reception. This document defines the 222 following flag: 224 o N(Number of PCInt messages sent when creating a tunnel-8 bits): 225 This field indicates the number of times that PCInt messages need to 226 be sent to create a tunnel. If set to 1 by a PCC means sending it 227 once, If set to 2 by a PCC means sending it twice, and supports 228 expansion. 230 o S (SR tunnel initiator-1 bit): This field is used to distinguish 231 the tunnel initiator. If set to 1 by a PCC means that the PCC 232 initiates the tunnel request. If set to 0 by a PCC means that the 233 PCE sends the tunnel information. 235 o C (Configuration tunnel-1bit): This field is used to indicate 236 whether the PCE is configured with a tunnel. If set to 1 by a PCC, 237 the PCE configures the tunnel. If set to 0 by a PCC, the PCE does 238 not configure the tunnel. 240 o P (Path Segment label assignment-1 bit): This field is used to 241 indicate Path Segment label allocation. If set to 1 by a PCC, the 242 Path Segment label is allocated by PCC, If set to 0 by a PCC, the 243 Path Segment label is allocated by PCE. 245 o B (Binding label-1bit): This field is used to indicate the 246 allocation of the adhesive label. If set to 1 by a PCC, the Binding 247 label is allocated by the PCC, If set to 1 by a PCC, the Binding 248 label is allocated by the PCE. 250 o T (Time sequence dependency-1bit): This field indicates whether 251 there is a timing dependency in the protocol interaction. If set to 252 1 by a PCC, it means that there is a strong dependence between PCEP 253 message interaction and time sequence. If set to 0 by a PCC, it 254 means that there is no timing dependency. 256 o A (Association ID 1bit): This field indicates the assignment of the 257 Association ID. If set to 1 by a PCC, it means that the Association 258 ID is allocated by PCC. If set to 0 by a PCC, it means that the 259 association id is allocated by PCE. 261 5. IANA Considerations 263 IANA is requested to make allocations from the registry, as follows: 265 +======+==============================+=================+ 266 | Type | TLV | Reference | 267 +======+==============================+=================+ 268 | TBD1 | SR-PCE-INTERACTING-CAPBILITY | [this document] | 269 +------+------------------------------+-----------------+ 271 6. Security Considerations 273 TBD 275 7. References 277 7.1. Normative References 279 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 280 Requirement Levels", BCP 14, RFC 2119, 281 DOI 10.17487/RFC2119, March 1997, 282 . 284 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 285 Computation Element (PCE)-Based Architecture", RFC 4655, 286 DOI 10.17487/RFC4655, August 2006, 287 . 289 [RFC4657] Ash, J., Ed. and J.L. Le Roux, Ed., "Path Computation 290 Element (PCE) Communication Protocol Generic 291 Requirements", RFC 4657, DOI 10.17487/RFC4657, September 292 2006, . 294 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 295 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 296 DOI 10.17487/RFC5440, March 2009, 297 . 299 [RFC7470] Zhang, F. and A. Farrel, "Conveying Vendor-Specific 300 Constraints in the Path Computation Element Communication 301 Protocol", RFC 7470, DOI 10.17487/RFC7470, March 2015, 302 . 304 [RFC8042] Zhang, Z., Wang, L., and A. Lindem, "OSPF Two-Part 305 Metric", RFC 8042, DOI 10.17487/RFC8042, December 2016, 306 . 308 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 309 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 310 May 2017, . 312 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 313 Computation Element Communication Protocol (PCEP) 314 Extensions for Stateful PCE", RFC 8231, 315 DOI 10.17487/RFC8231, September 2017, 316 . 318 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 319 Computation Element Communication Protocol (PCEP) 320 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 321 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 322 . 324 [RFC9059] Gandhi, R., Ed., Barth, C., and B. Wen, "Path Computation 325 Element Communication Protocol (PCEP) Extensions for 326 Associated Bidirectional Label Switched Paths (LSPs)", 327 RFC 9059, DOI 10.17487/RFC9059, June 2021, 328 . 330 7.2. Informative References 332 [I-D.ietf-pce-binding-label-sid] 333 Sivabalan, S., Filsfils, C., Tantsura, J., Previdi, S., 334 and C. L. (editor), "Carrying Binding Label/Segment 335 Identifier (SID) in PCE-based Networks.", Work in 336 Progress, Internet-Draft, draft-ietf-pce-binding-label- 337 sid-15, 20 March 2022, . 340 [I-D.ietf-pce-segment-routing] 341 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 342 and J. Hardwick, "Path Computation Element Communication 343 Protocol (PCEP) Extensions for Segment Routing", Work in 344 Progress, Internet-Draft, draft-ietf-pce-segment-routing- 345 16, 4 March 2019, . 348 [I-D.li-pce-sr-path-segment] 349 Li, C., Chen, M., Cheng, W., Dong, J., Li, Z., Gandhi, R., 350 and Q. Xiong, "Path Computation Element Communication 351 Protocol (PCEP) Extension for Path Segment in Segment 352 Routing (SR)", Work in Progress, Internet-Draft, draft-li- 353 pce-sr-path-segment-08, 19 August 2019, 354 . 357 Authors' Addresses 359 Minxue Wang 360 China Mobile 361 Beijing 362 China 363 Email: wangminxue@chinamobile.com 365 Liuyan Han 366 China Mobile 367 Beijing 368 China 369 Email: hanliuyan@chinamobile.com 370 Mianzhang Huang 371 CICT 372 Wuhan 373 China 374 Email: mzhuang@fiberhome.com 376 Zhen Han 377 CICT 378 Wuhan 379 China 380 Email: zhhan@fiberhome.com 382 Jinyou Dai 383 CICT 384 Wuhan 385 China 386 Email: djy@fiberhome.com