idnits 2.17.1 draft-li-pce-pcep-pmtu-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 (21 October 2021) is 917 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) == Outdated reference: A later version (-11) exists of draft-ietf-pce-multipath-02 == Outdated reference: A later version (-25) exists of draft-ietf-pce-segment-routing-ipv6-09 == Outdated reference: A later version (-06) exists of draft-ietf-idr-bgp-ls-link-mtu-01 Summary: 0 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 S. Peng 3 Internet-Draft C. Li 4 Intended status: Standards Track Huawei Technologies 5 Expires: 24 April 2022 L. Han 6 China Mobile 7 L. Ndifor 8 MTN Cameroon 9 21 October 2021 11 Support for Path MTU (PMTU) in the Path Computation Element (PCE) 12 communication Protocol (PCEP). 13 draft-li-pce-pcep-pmtu-05 15 Abstract 17 The Path Computation Element (PCE) provides path computation 18 functions in support of traffic engineering in Multiprotocol Label 19 Switching (MPLS) and Generalized MPLS (GMPLS) networks. 21 The Source Packet Routing in Networking (SPRING) architecture 22 describes how Segment Routing (SR) can be used to steer packets 23 through an IPv6 or MPLS network using the source routing paradigm. A 24 Segment Routed Path can be derived from a variety of mechanisms, 25 including an IGP Shortest Path Tree (SPT), explicit configuration, or 26 a Path Computation Element (PCE). 28 Since the SR does not require signaling, the path maximum 29 transmission unit (MTU) information for SR path is not available. 30 This document specify the extension to PCE communication protocol 31 (PCEP) to carry path (MTU) in the PCEP messages. 33 Requirements Language 35 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 36 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 37 "OPTIONAL" in this document are to be interpreted as described in BCP 38 14 [RFC2119] [RFC8174] when, and only when, they appear in all 39 capitals, as shown here. 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at https://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on 24 April 2022. 58 Copyright Notice 60 Copyright (c) 2021 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 65 license-info) in effect on the date of publication of this document. 66 Please review these documents carefully, as they describe your rights 67 and restrictions with respect to this document. Code Components 68 extracted from this document must include Simplified BSD License text 69 as described in Section 4.e of the Trust Legal Provisions and are 70 provided without warranty as described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 75 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 3. PCEP Extention . . . . . . . . . . . . . . . . . . . . . . . 5 77 3.1. Extensions to METRIC Object . . . . . . . . . . . . . . . 5 78 3.2. Multi-Path Handling . . . . . . . . . . . . . . . . . . . 6 79 3.3. Stateful PCE and PCE Initiated LSPs . . . . . . . . . . . 7 80 3.4. Segment Routing . . . . . . . . . . . . . . . . . . . . . 7 81 3.5. Path MTU Adjustment . . . . . . . . . . . . . . . . . . . 7 82 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 83 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 84 5.1. METRIC Type . . . . . . . . . . . . . . . . . . . . . . . 8 85 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 8 86 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 87 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 88 7.2. Informative References . . . . . . . . . . . . . . . . . 9 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 91 1. Introduction 93 [RFC5440] describes the Path Computation Element (PCE) Communication 94 Protocol (PCEP). PCEP enables the communication between a Path 95 Computation Client (PCC) and a PCE, or between PCE and PCE, for the 96 purpose of computation of Multiprotocol Label Switching (MPLS) as 97 well as Generalzied MPLS (GMPLS) Traffic Engineering Label Switched 98 Path (TE LSP) characteristics. 100 [RFC8231] specifies a set of extensions to PCEP to enable stateful 101 control of TE LSPs within and across PCEP sessions in compliance with 102 [RFC4657]. It includes mechanisms to effect LSP State 103 Synchronization between PCCs and PCEs, delegation of control over 104 LSPs to PCEs, and PCE control of timing and sequence of path 105 computations within and across PCEP sessions. The model of operation 106 where LSPs are initiated from the PCE is described in [RFC8281]. 108 As per [RFC8402], with Segment Routing (SR), a node steers a packet 109 through an ordered list of instructions, called segments. A segment 110 can represent any instruction, topological or service-based. A 111 segment can have a semantic local to an SR node or global within an 112 SR domain. SR allows to enforce a flow through any path and service 113 chain while maintaining per-flow state only at the ingress node of 114 the SR domain. Segments can be derived from different components: 115 IGP, BGP, Services, Contexts, Locators, etc. The SR architecture can 116 be applied to the MPLS forwarding plane without any change, in which 117 case an SR path corresponds to an MPLS Label Switching Path (LSP). 118 The SR is applied to IPV6 forwarding plane using SRH. A SR path can 119 be derived from an IGP Shortest Path Tree (SPT), but SR-TE paths may 120 not follow IGP SPT. Such paths may be chosen by a suitable network 121 planning tool, or a PCE and provisioned on the ingress node. 123 As per [RFC8664], it is possible to use a stateful PCE for computing 124 one or more SR-TE paths taking into account various constraints and 125 objective functions. Once a path is chosen, the stateful PCE can 126 initiate an SR-TE path on a PCC using PCEP extensions specified in 127 [RFC8281] using the SR specific PCEP extensions specified in 128 [RFC8664]. [RFC8664] specifies PCEP extensions for supporting a SR- 129 TE LSP for MPLS data plane. [I-D.ietf-pce-segment-routing-ipv6] 130 extend PCEP to support SR for IPv6 data plane. 132 The maximum transmission unit (MTU) is the largest size packet or 133 frame, in bytes, that can be sent in a network. An MTU that is too 134 large might cause retransmissions. Too small an MTU might cause the 135 router to send and handle relatively more header overhead and 136 acknowledgments. When an LSP is created across a set of links with 137 different MTU sizes, the ingress router need to know what the 138 smallest MTU is on the LSP path. If this MTU is larger than the MTU 139 of one of the intermediate links, traffic might be dropped, because 140 MPLS packets cannot be fragmented. Also, the ingress router may not 141 be aware of this type of traffic loss, because the control plane for 142 the LSP would still function normally. [RFC3209] specify the 143 mechanism of MTU signaling in RSVP. 145 Since the SR does not require signaling, the path MTU information for 146 SR path is not available. This document specify the extension to 147 PCEP to carry path MTU in the PCEP messages. It is assumed that the 148 PCE is aware of the link MTU as part of the Traffic Engineering 149 Database (TED) population. This could be done via IGP, BGP-LS 150 [I-D.ietf-idr-bgp-ls-link-mtu] or some other means. Thus the PCE can 151 find the path MTU at the time of path computation and include this 152 information as part of the PCEP messages. 154 Though the key use case for path MTU is SR, the PCEP extension (as 155 specified in this document) creates a new metric type for path MTU, 156 making this a generic extension that can be used independent of SR. 158 Note that in SR, the term Maximum SID Depth (MSD) [RFC8491] refers to 159 the maximum number of SIDs that an ingress is capable of imposing on 160 a packet. The PMTU on the other hand determines if the IP 161 fragmentation could be avoided. 163 2. Terminology 165 This draft refers to the terms defined in [RFC8201], [RFC4821] and 166 [RFC3988]. 168 MTU: Maximum Transmission Unit, the size in bytes of the largest IP 169 packet, including the IP header and payload, that can be 170 transmitted on a link or path. Note that this could more properly 171 be called the IP MTU, to be consistent with how other standards 172 organizations use the acronym MTU. 174 Link MTU: The Maximum Transmission Unit, i.e., maximum IP packet 175 size in bytes, that can be conveyed in one piece over a link. Be 176 aware that this definition is different from the definition used 177 by other standards organizations. 179 For IETF documents, link MTU is uniformly defined as the IP MTU 180 over the link. This includes the IP header, but excludes link 181 layer headers and other framing that is not part of IP or the IP 182 payload. 184 Be aware that other standards organizations generally define link 185 MTU to include the link layer headers. 187 For the MPLS data plane, this size includes the IP header and data 188 (or other payload) and the label stack but does not include any 189 lower-layer headers. A link may be an interface (such as Ethernet 190 or Packet-over-SONET), a tunnel (such as GRE or IPsec), or an LSP. 192 Path: The set of links traversed by a packet between a source node 193 and a destination node. 195 Path MTU, or PMTU: The minimum link MTU of all the links in a path 196 between a source node and a destination node. 198 For the MPLS data plane, it is the MTU of an LSP from a given LSR 199 to the egress(es), over each valid (forwarding) path. This size 200 includes the IP header and data (or other payload) and any part of 201 the label stack that was received by the ingress LSR before it 202 placed the packet into the LSP (this part of the label stack is 203 considered part of the payload for this LSP). The size does not 204 include any lower-level headers. 206 3. PCEP Extention 208 3.1. Extensions to METRIC Object 210 The METRIC object is defined in Section 7.8 of [RFC5440], comprising 211 metric-value and metric-type (T field), and a flags field, comprising 212 a number of bit flags (B bit and C bit). This document defines a new 213 type for the METRIC object for Path MTU. 215 * T = TBD: Path MTU. 217 * A network comprises of a set of N links {Li, (i=1...N)}. 219 * A path P of a LSP is a list of K links {Lpi,(i=1...K)}. 221 * A Link MTU of link L is denoted M(L). 223 * A Path MTU metric for the path P = Min {M(Lpi), (i=1...K)}. 225 The Path MTU metric type of the METRIC object in PCEP represents the 226 minimum of the Link MTU of all links along the path. 228 When PCE computes the path, it can also find the Path MTU (based on 229 the above criteria) and include this information in the METRIC object 230 with the above metric type in the PCEP message when replying to the 231 PCC. In a Path Computation Reply (PCRep) message, the PCE MAY insert 232 the METRIC object with an Explicit Route Object (ERO) so as to 233 provide the METRIC (path MTU) for the computed path. The PCE MAY 234 also insert the METRIC object with a NO-PATH object to indicate that 235 the metric constraint could not be satisfied. 237 Further, a PCC MAY use the Path MTU metric in a Path Computation 238 Request (PCReq) message to request a path meeting the MTU requirement 239 of the path. In this case, the B bit MUST be set to suggest a bound 240 (a maximum) for the Path MTU metric that must not be exceeded for the 241 PCC to consider the computed path as acceptable. The Path MTU metric 242 must be less than or equal to the value specified in the metric-value 243 field. 245 A PCC can also use this metric to ask PCE to optimize the path MTU 246 during path computation. In this case, the B bit MUST be cleared. 248 The error handling and processing of the METRIC object is as 249 specified in [RFC5440]. 251 3.2. Multi-Path Handling 253 [I-D.ietf-pce-multipath] extends PCEP to support signaling of 254 multipath information i.e. to all each Candidate-Path to contain 255 multiple Segment-Lists. 257 The PMTU could be supported per segment list as well. The exact 258 mechanism to support this is left for further revision of this 259 document. 261 3.3. Stateful PCE and PCE Initiated LSPs 263 [RFC8231] specifies a set of extensions to PCEP to enable stateful 264 control of MPLS-TE LSPs via PCEP and the maintaining of these LSPs at 265 the stateful PCE. It further distinguishes between an active and a 266 passive stateful PCE. A passive stateful PCE uses LSP state 267 information learned from PCCs to optimize path computations but does 268 not actively update LSP state. In contrast, an active stateful PCE 269 utilizes the LSP delegation mechanism to update LSP parameters in 270 those PCCs that delegated control over their LSPs to the PCE. 271 [RFC8281] describes the setup, maintenance, and teardown of PCE- 272 initiated LSPs under the stateful PCE model. The document defines 273 the PCInitiate message that is used by a PCE to request a PCC to set 274 up a new LSP. 276 The new metric type defined in this document can also be used with 277 the stateful PCE extensions. The format of PCEP messages described 278 in [RFC8231] and [RFC8281] uses and 279 , respectively, (where the 280 is the attribute-list defined in Section 6.5 of [RFC5440]). 282 A PCE MAY include the path MTU metric in PCInitiate or PCUpd message 283 to inform the PCC of the path MTU calculated for the path. A PCC MAY 284 include the path MTU metric as a bound constraint or to indicate 285 optimization criteria (similar to PCReq). 287 3.4. Segment Routing 289 A Segment Routed path (SR path) can be derived from an IGP Shortest 290 Path Tree (SPT). Segment Routed Traffic Engineering paths (SR-TE 291 paths) may not follow IGP SPT. Such paths may be chosen by a 292 suitable network planning tool and provisioned on the source node of 293 the SR-TE path. 295 It is possible to use a PCE for computing one or more SR-TE paths 296 taking into account various constraints and objective functions. 297 Once a path is chosen, the PCE can inform an SR-TE path on a PCC 298 using PCEP extensions specified in [RFC8664]. Further, 299 [I-D.ietf-pce-segment-routing-ipv6] adds the support for IPv6 data 300 plane in SR. 302 The new metric type for path MTU is applicable for the SR-TE path and 303 require no additional extensions. 305 3.5. Path MTU Adjustment 307 The path MTU metric can be used for both primary and protection path. 309 The minimal value of the link MTU along the path is collected, based 310 on which minor adjustment is made to cater for overhead introduced by 311 the protection mechanisms such as TI-LFA. The path MTU is the value 312 of the minimum link MTU minus the overhead. In this way, the ingress 313 node can use the path MTU directly. 315 4. Security Considerations 317 This document defines a new METRIC type that do not add any new 318 security concerns beyond those discussed in [RFC5440] in itself. 319 Some deployments may find the path MTU information to be extra 320 sensitive and could be used to influence path computation and setup 321 with adverse effect. Additionally, snooping of PCEP messages with 322 such data or using PCEP messages for network reconnaissance may give 323 an attacker sensitive information about the operations of the 324 network. Thus, such deployment should employ suitable PCEP security 325 mechanisms like TCP Authentication Option (TCP-AO) [RFC5925] or 326 Transport Layer Security (TLS) [RFC8253]. The procedure based on TLS 327 is considered a security enhancement and thus is much better suited 328 for the sensitive information. 330 5. IANA Considerations 332 This document makes following requests to IANA for action. 334 5.1. METRIC Type 336 IANA maintains the "Path Computation Element Protocol (PCEP) Numbers" 337 registry. Within this registry, IANA maintains a subregistry for 338 "METRIC Object T Field". IANA is requested to make the following 339 allocation: 341 Value Description Reference 342 ---------------------- ---------------------------- -------------- 343 TBD Path MTU This document 345 6. Acknowledgement 347 We would like to thank Dhruv Dhody for his contributions for this 348 document. 350 7. References 352 7.1. Normative References 354 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 355 Requirement Levels", BCP 14, RFC 2119, 356 DOI 10.17487/RFC2119, March 1997, 357 . 359 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 360 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 361 DOI 10.17487/RFC5440, March 2009, 362 . 364 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 365 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 366 May 2017, . 368 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 369 Computation Element Communication Protocol (PCEP) 370 Extensions for Stateful PCE", RFC 8231, 371 DOI 10.17487/RFC8231, September 2017, 372 . 374 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 375 Computation Element Communication Protocol (PCEP) 376 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 377 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 378 . 380 7.2. Informative References 382 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 383 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 384 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 385 . 387 [RFC3988] Black, B. and K. Kompella, "Maximum Transmission Unit 388 Signalling Extensions for the Label Distribution 389 Protocol", RFC 3988, DOI 10.17487/RFC3988, January 2005, 390 . 392 [RFC4657] Ash, J., Ed. and J.L. Le Roux, Ed., "Path Computation 393 Element (PCE) Communication Protocol Generic 394 Requirements", RFC 4657, DOI 10.17487/RFC4657, September 395 2006, . 397 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 398 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 399 . 401 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 402 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 403 June 2010, . 405 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 406 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 407 DOI 10.17487/RFC8201, July 2017, 408 . 410 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 411 "PCEPS: Usage of TLS to Provide a Secure Transport for the 412 Path Computation Element Communication Protocol (PCEP)", 413 RFC 8253, DOI 10.17487/RFC8253, October 2017, 414 . 416 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 417 Decraene, B., Litkowski, S., and R. Shakir, "Segment 418 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 419 July 2018, . 421 [RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, 422 "Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491, 423 DOI 10.17487/RFC8491, November 2018, 424 . 426 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 427 and J. Hardwick, "Path Computation Element Communication 428 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 429 DOI 10.17487/RFC8664, December 2019, 430 . 432 [I-D.ietf-pce-multipath] 433 Koldychev, M., Sivabalan, S., Saad, T., Beeram, V. P., 434 Bidgoli, H., Yadav, B., and S. Peng, "PCEP Extensions for 435 Signaling Multipath Information", Work in Progress, 436 Internet-Draft, draft-ietf-pce-multipath-02, 17 October 437 2021, . 440 [I-D.ietf-pce-segment-routing-ipv6] 441 Li, C., Negi, M., Sivabalan, S., Koldychev, M., 442 Kaladharan, P., and Y. Zhu, "PCEP Extensions for Segment 443 Routing leveraging the IPv6 data plane", Work in Progress, 444 Internet-Draft, draft-ietf-pce-segment-routing-ipv6-09, 27 445 May 2021, . 448 [I-D.ietf-idr-bgp-ls-link-mtu] 449 Zhu, Y., Hu, Z., Peng, S., and R. Mwehaire, "Signaling 450 Maximum Transmission Unit (MTU) using BGP-LS", Work in 451 Progress, Internet-Draft, draft-ietf-idr-bgp-ls-link-mtu- 452 01, 25 May 2021, . 455 Authors' Addresses 457 Shuping Peng 458 Huawei Technologies 459 Huawei Campus, No. 156 Beiqing Rd. 460 Beijing 461 100095 462 China 464 Email: pengshuping@huawei.com 466 Cheng Li 467 Huawei Technologies 468 Huawei Campus, No. 156 Beiqing Rd. 469 Beijing 470 100095 471 China 473 Email: c.l@huawei.com 475 Liuyan Han 476 China Mobile 477 Beijing 478 100053 479 China 481 Email: hanliuyan@chinamobile.com 483 Luc-Fabrice Ndifor 484 MTN Cameroon 485 Cameroon 487 Email: Luc-Fabrice.Ndifor@mtn.com