idnits 2.17.1 draft-ietf-bier-path-mtu-discovery-12.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 (5 April 2022) is 751 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 (-13) exists of draft-ietf-bier-ping-07 == Outdated reference: A later version (-15) exists of draft-ietf-bier-oam-requirements-11 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BIER Working Group G. Mirsky 3 Internet-Draft Ericsson 4 Intended status: Standards Track T. Przygienda 5 Expires: 7 October 2022 Juniper Networks 6 A. Dolganow 7 Individual contributor 8 5 April 2022 10 Path Maximum Transmission Unit Discovery (PMTUD) for Bit Index Explicit 11 Replication (BIER) Layer 12 draft-ietf-bier-path-mtu-discovery-12 14 Abstract 16 This document describes Path Maximum Transmission Unit Discovery 17 (PMTUD) in Bit Indexed Explicit Replication (BIER) layer. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on 7 October 2022. 36 Copyright Notice 38 Copyright (c) 2022 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Revised BSD License text as 47 described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Revised BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Conventions used in this document . . . . . . . . . . . . 2 54 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 2 55 1.1.2. Requirements Language . . . . . . . . . . . . . . . . 3 56 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 57 3. PMTUD Mechanism for BIER . . . . . . . . . . . . . . . . . . 4 58 3.1. Data TLV for BIER Ping . . . . . . . . . . . . . . . . . 6 59 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 61 6. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 7 62 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 64 7.2. Informative References . . . . . . . . . . . . . . . . . 7 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 67 1. Introduction 69 In packet switched networks, when a host seeks to transmit data to a 70 target destination, the data is transmitted as a set of packets. In 71 many cases, it is more efficient to use the largest size packets that 72 are less than or equal to the least Maximum Transmission Unit (MTU) 73 for any forwarding device along the routed path to the IP destination 74 for these packets. Such "least MTU" is known as Path MTU (PMTU). 75 Fragmentation or packet drop, silent or not, may occur on hops along 76 the route where an MTU is smaller than the size of the datagram. To 77 avoid any of the listed above behaviors, the packet source must find 78 the value of the least MTU, i.e., PMTU, that will be encountered 79 along the route that a set of packets will follow to reach the given 80 set of destinations. Such MTU determination along a specific path is 81 referred to as path MTU discovery (PMTUD). 83 [RFC8279] introduces and explains Bit Index Explicit Replication 84 (BIER) architecture and how it supports the forwarding of multicast 85 data packets. [I-D.ietf-bier-ping] introduced BIER Ping as a 86 transport-independent OAM mechanism to detect and localize failures 87 in the BIER data plane. This document specifies how BIER Ping can be 88 used to perform efficient PMTUD in the BIER domain. 90 1.1. Conventions used in this document 92 1.1.1. Terminology 94 This document uses terminology defined in [RFC8279]. Familiarity 95 with this specification and the terminology used is expected. 97 1.1.2. Requirements Language 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 101 "OPTIONAL" in this document are to be interpreted as described in BCP 102 14 [RFC2119] [RFC8174] when, and only when, they appear in all 103 capitals, as shown here. 105 2. Problem Statement 107 [I-D.ietf-bier-oam-requirements] sets forth the requirement to define 108 PMTUD protocol for BIER domain. This document describes the 109 extension to [I-D.ietf-bier-ping] for use in the BIER PMTUD solution. 111 Current PMTUD mechanisms ([RFC1191], [RFC8201], and [RFC4821]) are 112 primarily targeted to work on point-to-point, i.e. unicast paths. 113 These mechanisms use packet fragmentation control by disabling 114 fragmentation of the probe packet. As a result, a transient node 115 that cannot forward a probe packet that is bigger than its link MTU 116 sends to the packet source an error notification, otherwise the 117 packet destination may respond with a positive acknowledgment. Thus, 118 possibly through a series of iterations, varying the size of the 119 probe packet, the packet source discovers the PMTU of the particular 120 path. 122 Applying such existing PMTUD solutions are inefficient for point-to- 123 multipoint paths constructed for multicast traffic. Probe packets 124 must be flooded through the whole set of multicast distribution paths 125 over and over again until the very last egress responds with a 126 positive acknowledgment. Consider the multicast network presented in 127 Figure 1, where MTU on all links but one (B, D) is the same. If MTU 128 on the link (B, D) is smaller than the MTU on the other links, using 129 existing PMTUD mechanism probes will unnecessarily flood to leaf 130 nodes E, F, and G for the second and consecutive times and positive 131 responses will be generated and received by root A repeatedly. 133 ----- 134 --| D | 135 ----- / ----- 136 --| B |-- 137 / ----- \ ----- 138 / --| E | 139 ----- / ----- 140 | A |--- ----- 141 ----- \ --| F | 142 \ ----- / ----- 143 --| C |-- 144 ----- \ ----- 145 --| G | 146 ----- 148 Figure 1: Multicast network 150 3. PMTUD Mechanism for BIER 152 A BFIR selects a set of BFERs for the specific multicast 153 distribution. Such a BFIR determines, by explicitly controlling a 154 subset of targeted BFERs and transmitting a series of probe packets, 155 the MTU of that multicast distribution tree. In the case of ECMP, 156 BFIR MAY test each path by variating the value in the Entropy field. 157 The critical step is that in case of failure at an intermediate BFR 158 to forward towards the subset of targeted downstream BFERs, the BFR 159 responds with a partial (compared to the one it received in the 160 request) bitmask towards the originating BFIR in error notification. 161 That allows for retransmission of the next probe with a smaller MTU 162 address only towards the failed downstream BFERs instead of all BFERs 163 addressed in the previous probe. In the scenario discussed in 164 Section 2 the second and all following (if needed) probes will be 165 sent only to the node D since MTU discovery of E, F, and G has been 166 completed already by the first probe successfully. 168 Consider the network displayed in Figure 1 to be a presentation of a 169 BIER domain and all nodes to be BFRs. To discover MTU over BIER 170 domain to BFERs D, F, E, and G BFIR A will use BIER Ping with Data 171 TLV, defined in Section 3.1. Size of the first probe set to M_max 172 determined as minimal MTU value of BFIR's links to BIER domain. As 173 has been assumed in Section 2, MTUs of all links but the link (B, D) 174 are the same. Thus BFERs E, F, and G would receive BIER Echo Request 175 and will send their respective replies to BFIR A. BFR B may pass the 176 packet which is too large to forward over egress link (B, D) to the 177 appropriate network layer for error processing where it would be 178 recognized as a BIER Echo Request packet. BFR B MUST send BIER Echo 179 Reply to BFIR A and MUST include Downstream Mapping TLV, defined in 180 [I-D.ietf-bier-ping] setting its fields in the following fashion: 182 * MTU SHOULD be set to the minimal MTU value among all egress BIER 183 links, logical links between this and downstream BFRs, that could 184 be used to reach B's downstream BFERs; 186 * Address Type MAY be set to any value defined in Section 3.3.4 187 [I-D.ietf-bier-ping]. 189 * I flag MUST be cleared to direct the responding BFR not to include 190 the Incoming SI-BitString TLV in the BIER Echo Response. 192 * Downstream Interface Address field MUST be zeroed. 194 * List of Sub-TLVs MUST include the Egress Bitstring sub-TLV with 195 the list of all BFERs that cannot be reached because the egress 196 MTU turned out to be too small. 198 The BFIR will receive either of the two types of packets: 200 * a positive Echo Reply from one of BFERs to which the probe has 201 been sent. In this case, the bit corresponding to the BFER MUST 202 be cleared from the bitmask string (BMS); 204 * a negative Echo Reply with bit string listing unreached BFERs and 205 recommended MTU value MTU'. The BFIR MUST add the bit string to 206 its BMS and set the size of the next probe as min(MTU, MTU') 208 If a negative Echo Reply is received, the BFIR MUST wait for the 209 expiration of the Echo Request before transmitting the updated Echo 210 Request. If upon expiration of the Echo Request timer BFIR didn't 211 receive any Echo Replies, then the size of the probe SHOULD be 212 decreased. There are scenarios when an implementation of the PMTUD 213 would not decrease the size of the probe. For example, suppose upon 214 expiration of the Echo Request timer BFIR didn't receive any Echo 215 Reply. In that case, BFIR MAY continue to retransmit the probe using 216 the initial size and MAY apply probe delay retransmission procedures. 217 The algorithm used to delay retransmission procedures on BFIR is 218 outside the scope of this specification. The BFIR sends probes using 219 BMS and locally defined retransmission procedures, but not more 220 frequently than after the Echo Request timer expired, until either 221 the bit string is clear, i.e., contains no set bits, or until the 222 BFIR retransmission procedure terminates and PMTU discovery is 223 declared unsuccessful. In the case of convergence of the procedure, 224 the size of the last probe indicates the PMTU size that can be used 225 for all BFERs in the initial BMS without incurring fragmentation. 227 Thus we conclude that in order to comply with the requirement in 228 [I-D.ietf-bier-oam-requirements]: 230 * a BFR SHOULD support PMTUD; 232 * a BFR MAY use defined per BIER sub-domain MTU value as initial MTU 233 value for discovery or use it as MTU for this BIER sub-domain to 234 reach BFERs; 236 * a BFIR MUST have a locally defined PMTUD probe retransmission 237 procedure. 239 3.1. Data TLV for BIER Ping 241 There needs to be a control for probe size in order to support the 242 BIER PMTUD. Data TLV format is presented in Figure 2. 244 0 1 2 3 245 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 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Type (TBA1) | Length | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | Data | 250 ~ ~ 251 | | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 Figure 2: Data TLV format 256 * Type: indicates Data TLV, to be allocated by IANA Section 4. 258 * Length: the length of the Data field in octets. 260 * Data: n octets (n = Length) of arbitrary data. The receiver 261 SHOULD ignore it. 263 4. IANA Considerations 265 IANA is requested to assign a new Type value for Data TLV Type from 266 its registry of TLV and sub-TLV Types of BIER Ping as follows: 268 +=======+=============+===============+ 269 | Value | Description | Reference | 270 +=======+=============+===============+ 271 | TBA1 | Data | This document | 272 +-------+-------------+---------------+ 274 Table 1: Data TLV Type 276 5. Security Considerations 278 Routers that support PMTUD based on this document are subject to the 279 same security considerations as defined in [I-D.ietf-bier-ping] 281 6. Acknowledgment 283 Authors greatly appreciate thorough review and the most detailed 284 comments by Eric Gray. 286 7. References 288 7.1. Normative References 290 [I-D.ietf-bier-ping] 291 Kumar, N., Pignataro, C., Akiya, N., Zheng, L., Chen, M., 292 and G. Mirsky, "BIER Ping and Trace", Work in Progress, 293 Internet-Draft, draft-ietf-bier-ping-07, 11 May 2020, 294 . 297 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 298 DOI 10.17487/RFC1191, November 1990, 299 . 301 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 302 Requirement Levels", BCP 14, RFC 2119, 303 DOI 10.17487/RFC2119, March 1997, 304 . 306 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 307 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 308 . 310 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 311 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 312 May 2017, . 314 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 315 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 316 DOI 10.17487/RFC8201, July 2017, 317 . 319 7.2. Informative References 321 [I-D.ietf-bier-oam-requirements] 322 Mirsky, G., Kumar, N., Chen, M., and S. Pallagatti, 323 "Operations, Administration and Maintenance (OAM) 324 Requirements for Bit Index Explicit Replication (BIER) 325 Layer", Work in Progress, Internet-Draft, draft-ietf-bier- 326 oam-requirements-11, 15 November 2020, 327 . 330 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 331 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 332 Explicit Replication (BIER)", RFC 8279, 333 DOI 10.17487/RFC8279, November 2017, 334 . 336 Authors' Addresses 338 Greg Mirsky 339 Ericsson 340 Email: gregimirsky@gmail.com 342 Tony Przygienda 343 Juniper Networks 344 Email: prz@juniper.net 346 Andrew Dolganow 347 Individual contributor 348 Email: adolgano@gmail.com