idnits 2.17.1 draft-ietf-idr-bgp-ls-link-mtu-02.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 are 3 instances 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (28 November 2021) is 880 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) -- Obsolete informational reference (is this intentional?): RFC 7752 (Obsoleted by RFC 9552) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Zhu 3 Internet-Draft China Telecom 4 Intended status: Standards Track Z. Hu 5 Expires: 1 June 2022 S. Peng 6 Huawei Technologies 7 R. Mwehaire 8 MTN Uganda Ltd. 9 28 November 2021 11 Signaling Maximum Transmission Unit (MTU) using BGP-LS 12 draft-ietf-idr-bgp-ls-link-mtu-02 14 Abstract 16 BGP Link State (BGP-LS) describes a mechanism by which link-state and 17 TE information can be collected from networks and shared with 18 external components using the BGP routing protocol. The centralized 19 controller (PCE/SDN) completes the service path calculation based on 20 the information transmitted by the BGP-LS and delivers the result to 21 the Path Computation Client (PCC) through the PCEP or BGP protocol. 23 Segment Routing (SR) leverages the source routing paradigm, which can 24 be directly applied to the MPLS architecture with no change on the 25 forwarding plane and applied to the IPv6 architecture, with a new 26 type of routing header, called SRH. The SR uses the IGP protocol as 27 the control protocol. Compared to the MPLS tunneling technology, the 28 SR does not require additional signaling. Therefore, the SR does not 29 support the negotiation of the Path MTU. Since multiple labels or 30 SRv6 SIDs are pushed in the packets, it is more likely that the 31 packet size exceeds the path mtu of SR tunnel. 33 This document specifies the extensions to BGP Link State (BGP-LS) to 34 carry maximum transmission unit (MTU) messages of link. The PCE/SDN 35 calculates the Path MTU while completing the service path calculation 36 based on the information transmitted by the BGP-LS. 38 Requirements Language 40 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 41 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 42 document are to be interpreted as described in RFC 2119 [RFC2119]. 44 Status of This Memo 46 This Internet-Draft is submitted in full conformance with the 47 provisions of BCP 78 and BCP 79. 49 Internet-Drafts are working documents of the Internet Engineering 50 Task Force (IETF). Note that other groups may also distribute 51 working documents as Internet-Drafts. The list of current Internet- 52 Drafts is at https://datatracker.ietf.org/drafts/current/. 54 Internet-Drafts are draft documents valid for a maximum of six months 55 and may be updated, replaced, or obsoleted by other documents at any 56 time. It is inappropriate to use Internet-Drafts as reference 57 material or to cite them other than as "work in progress." 59 This Internet-Draft will expire on 1 June 2022. 61 Copyright Notice 63 Copyright (c) 2021 IETF Trust and the persons identified as the 64 document authors. All rights reserved. 66 This document is subject to BCP 78 and the IETF Trust's Legal 67 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 68 license-info) in effect on the date of publication of this document. 69 Please review these documents carefully, as they describe your rights 70 and restrictions with respect to this document. Code Components 71 extracted from this document must include Revised BSD License text as 72 described in Section 4.e of the Trust Legal Provisions and are 73 provided without warranty as described in the Revised BSD License. 75 Table of Contents 77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 78 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 79 3. Deploying scenarios . . . . . . . . . . . . . . . . . . . . . 5 80 4. BGP_LS Extensions for Link MTU . . . . . . . . . . . . . . . 6 81 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 83 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 84 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 86 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 87 9.2. Informative References . . . . . . . . . . . . . . . . . 7 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 90 1. Introduction 92 [RFC7752]describes the implementation mechanism of BGP-LS by which 93 link-state and TE information can be collected from networks and 94 shared with external components using the BGP routing protocol 95 [RFC4271]. BGP-LS allows the necessary Link-State Database (LSDB) 96 and Traffic Engineering Database (TEDB) information to be collected 97 from the IGP within the network, filtered according to configurable 98 policy, and distributed to the PCE as necessary. 100 The appropriate MTU size guarantees efficient data transmission. If 101 the MTU size is too small and the packet size is large, fragmentation 102 may occur too much and packets are discarded by the QoS queue. If 103 the MTU configuration is too large, packet transmission may be slow. 104 Path MTU is the maximum length of a packet that can pass through a 105 path without fragmentation. [RFC1191] describes a technique for 106 dynamically discovering the maximum transmission unit (MTU) of an 107 arbitrary internet path. 109 The traditional MPLS tunneling technology has signaling for 110 establishing a path. [RFC3988] defines the mechanism for 111 automatically discovering the Path MTU of LSPs. For a certain FEC, 112 the LSR compares the MTU advertised by all downstream devices with 113 the MTU of the FEC output interface in the local device, and 114 calculates the minimum value for the upstream device. 116 [RFC3209] specify the mechanism of MTU signaling in RSVP-TE. The 117 ingress node of the RSVP-TE tunnel sends a Path message to the 118 downstream device. The Adspec object in the Path message carries the 119 MTU. Each node along the tunnel receives a Path message, compares 120 the MTU value in the Adspec object with the interface MTU value and 121 MPLS MTU configured on the physical output interface of the local 122 tunnel, obtains the minimum MTU value, and puts it into the newly 123 constructed Path message and continues to send it to the downstream 124 equipment. Thus, the MTU carried in the Path message received by the 125 Egress node is the minimum value of the path MTU. The Egress node 126 brings the negotiated Path MTU back to the Ingress node through the 127 Resv message. 129 Segment Routing (SR) described in [RFC8402] leverages the source 130 routing paradigm. Segment Routing can be directly applied to the 131 MPLS architecture with no change on the forwarding plane [RFC8660] 132 and applied to the IPv6 architecture with a new type of routing 133 header called the SR header (SRH) [RFC8754]. 134 [I-D.ietf-idr-bgp-ls-segment-routing-ext] defines SR extensions to 135 BGP-LS and specifies the TLVs and sub-TLVs for advertising SR 136 information. Based on the SR information reported by the BGP-LS, the 137 SDN can calculate the end-to-end explicit SR-TE paths or SR Policies. 139 Nevertheless, Segment Routing is a tunneling technology based on the 140 IGP protocol as the control protocol, and there is no additional 141 signaling for establishing the path. so the Segment Routing tunnel 142 cannot currently support the negotiation mechanism of the MTU. 143 Multiple labels or SRv6 SIDs are pushed in the packets. This causes 144 the length of the packets encapsulated in the Segment Routing tunnel 145 to increase during packet forwarding. This is more likely to cause 146 packet size exceed the traditional MPLS packet size. 148 This document specify the extension to BGP Link State (BGP-LS) to 149 carry link maximum transmission unit (MTU) messages. 151 2. Terminology 153 This draft refers to the terms defined in [RFC8201], [RFC4821] and 154 [RFC3988]. 156 MTU: Maximum Transmission Unit, the size in bytes of the largest IP 157 packet, including the IP header and payload, that can be 158 transmitted on a link or path. Note that this could more properly 159 be called the IP MTU, to be consistent with how other standards 160 organizations use the acronym MTU. 162 Link MTU: The Maximum Transmission Unit, i.e., maximum IP packet 163 size in bytes, that can be conveyed in one piece over a link. Be 164 aware that this definition is different from the definition used 165 by other standards organizations. 167 For IETF documents, link MTU is uniformly defined as the IP MTU 168 over the link. This includes the IP header, but excludes link 169 layer headers and other framing that is not part of IP or the IP 170 payload. 172 Be aware that other standards organizations generally define link 173 MTU to include the link layer headers. 175 For the MPLS data plane, this size includes the IP header and data (or 176 other payload) and the label stack but does not include any lower-layer 177 headers. A link may be an interface (such as Ethernet or Packet-over- 178 SONET), a tunnel (such as GRE or IPsec), or an LSP. 180 Path: The set of links traversed by a packet between a source node 181 and a destination node. 183 Path MTU, or PMTU: The minimum link MTU of all the links in a path 184 between a source node and a destination node. 186 3. Deploying scenarios 188 This document suggests a solution to extension to BGP Link State 189 (BGP-LS) to carry maximum transmission unit (MTU) messages. The MTU 190 information of the link is acquired through the process of collecting 191 link state and TE information by BGP-LS. Concretely, a router 192 maintains one or more databases for storing link-state information 193 about nodes and links in any given area. The router's BGP process 194 can retrieve topology from these IGP, BGP and other sources, and 195 distribute it to a consumer, either directly or via a peer BGP 196 speaker (typically a dedicated Route Reflector). [RFC7176] specifies 197 a possible way of using the ISIS mechanism and extensions for link 198 MTU Sub-TLV. In the case of inter-AS scenario (e.g., BGP EPE), the 199 link MTU of the inter-AS link can be collected via BGP-LS directly. 201 As per [RFC7752], the collection of link-state and TE information and 202 its distribution to consumers is shown in the following figure. 204 +-----------+ 205 | Consumer | 206 +-----------+ 207 ^ 208 | 209 +-----------+ 210 | BGP | +-----------+ 211 | Speaker | | Consumer | 212 +-----------+ +-----------+ 213 ^ ^ ^ ^ 214 | | | | 215 +---------------+ | +-------------------+ | 216 | | | | 217 +-----------+ +-----------+ +-----------+ 218 | BGP | | BGP | | BGP | 219 | Speaker | | Speaker | . . . | Speaker | 220 +-----------+ +-----------+ +-----------+ 221 ^ ^ ^ 222 | | | 223 IGP, BGP, Others IGP, BGP, Others IGP, BGP, Others 225 Figure 1: Collection of Link-State and TE Information 227 Please note that this signaled MTU may be different from the actual 228 MTU, which is usually from configuration mismatches in a control 229 plane and a data plane component. 231 4. BGP_LS Extensions for Link MTU 233 [RFC7752] defines the BGP-LS NLRI that can be a Node NLRI, a Link 234 NLRI or a Prefix NLRI. The corresponding BGP-LS attribute is a Node 235 Attribute, a Link Attribute or a Prefix Attribute. [RFC7752] defines 236 the TLVs that map link-state information to BGP-LS NLRI and the BGP- 237 LS attribute. Therefore, according to this document, a new sub-TLV 238 is added to the Link Attribute TLV. It is an independent attribute 239 TLV that can be used for the link NLRI advertised with all the 240 Protocol IDs. 242 The format of the sub-TLV is as shown below. 244 x TYPE - TBD 245 x LENGTH - Total length of the value field, it should be 2 246 x VALUE - 2-byte MTU value of the link 248 No. of Octets 249 +-----------------+ 250 | MTU value | 2 251 +-----------------+ 253 Figure 2. Sub-TLV Format for Link MTU 255 Whenever there is a change in MTU value represented by Link Attribute 256 TLV, BGP-LS should re-originate the respective TLV with the new MTU 257 value. 259 5. IANA Considerations 261 This document requests assigning a new code-point from the BGP-LS 262 Link Descriptor and Attribute TLVs registry as specified in section 263 4. 265 Value Description Reference 266 ---------------------- ---------------------------- -------------- 267 TBD Link MTU This document 269 6. Security Considerations 271 This document does not introduce security issues beyond those 272 discussed in RFC7752. 274 7. Acknowledgements 276 8. Contributors 278 Gang Yan 279 Huawei 280 China 282 Email:yangang@huawei.com 284 Junda Yao 285 Huawei 286 China 288 Email:yaojunda@huawei.com 290 9. References 292 9.1. Normative References 294 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 295 Requirement Levels", BCP 14, RFC 2119, 296 DOI 10.17487/RFC2119, March 1997, 297 . 299 9.2. Informative References 301 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 302 Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., 303 and M. Chen, "Border Gateway Protocol - Link State (BGP- 304 LS) Extensions for Segment Routing", Work in Progress, 305 Internet-Draft, draft-ietf-idr-bgp-ls-segment-routing-ext- 306 18, 15 April 2021, . 309 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 310 DOI 10.17487/RFC1191, November 1990, 311 . 313 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 314 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 315 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 316 . 318 [RFC3988] Black, B. and K. Kompella, "Maximum Transmission Unit 319 Signalling Extensions for the Label Distribution 320 Protocol", RFC 3988, DOI 10.17487/RFC3988, January 2005, 321 . 323 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 324 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 325 DOI 10.17487/RFC4271, January 2006, 326 . 328 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 329 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 330 . 332 [RFC7176] Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, 333 D., and A. Banerjee, "Transparent Interconnection of Lots 334 of Links (TRILL) Use of IS-IS", RFC 7176, 335 DOI 10.17487/RFC7176, May 2014, 336 . 338 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 339 S. Ray, "North-Bound Distribution of Link-State and 340 Traffic Engineering (TE) Information Using BGP", RFC 7752, 341 DOI 10.17487/RFC7752, March 2016, 342 . 344 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 345 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 346 DOI 10.17487/RFC8201, July 2017, 347 . 349 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 350 Decraene, B., Litkowski, S., and R. Shakir, "Segment 351 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 352 July 2018, . 354 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 355 Decraene, B., Litkowski, S., and R. Shakir, "Segment 356 Routing with the MPLS Data Plane", RFC 8660, 357 DOI 10.17487/RFC8660, December 2019, 358 . 360 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 361 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 362 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 363 . 365 Authors' Addresses 367 Yongqing Zhu 368 China Telecom 369 109, West Zhongshan Road, Tianhe District. 370 Guangzhou 371 510000 372 China 374 Email: zhuyq8@chinatelecom.cn 376 Zhibo Hu 377 Huawei Technologies 378 Huawei Bld., No.156 Beiqing Rd. 379 Beijing 380 100095 381 China 383 Email: huzhibo@huawei.com 385 Shuping Peng 386 Huawei Technologies 387 Huawei Bld., No.156 Beiqing Rd. 388 Beijing 389 100095 390 China 392 Email: pengshuping@huawei.com 394 Robbins Mwehaire 395 MTN Uganda Ltd. 396 Uganda 398 Email: Robbins.Mwehair@mtn.com