idnits 2.17.1 draft-ietf-bier-path-mtu-discovery-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 : ---------------------------------------------------------------------------- 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 (July 16, 2017) is 2448 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-01 == Outdated reference: A later version (-08) exists of draft-ietf-bier-architecture-07 == Outdated reference: A later version (-14) exists of draft-ietf-bier-oam-requirements-03 Summary: 0 errors (**), 0 flaws (~~), 4 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 ZTE Corp. 4 Intended status: Standards Track T. Przygienda 5 Expires: January 17, 2018 Juniper Networks 6 A. Dolganow 7 Nokia 8 July 16, 2017 10 Path Maximum Transmission Unit Discovery (PMTUD) for Bit Index Explicit 11 Replication (BIER) Layer 12 draft-ietf-bier-path-mtu-discovery-02 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 http://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 January 17, 2018. 36 Copyright Notice 38 Copyright (c) 2017 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 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Conventions used in this document . . . . . . . . . . . . 3 55 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3 56 1.1.2. Requirements Language . . . . . . . . . . . . . . . . 3 57 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 58 3. PMTUD Mechanism for BIER . . . . . . . . . . . . . . . . . . 4 59 3.1. Data TLV for BIER Ping . . . . . . . . . . . . . . . . . 6 60 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 62 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 7 63 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 65 7.2. Informative References . . . . . . . . . . . . . . . . . 8 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 68 1. Introduction 70 In packet switched networks, when a host seeks to transmit data to a 71 target destination, the data is transmitted as a set of packets. In 72 many cases it is more efficient to use the largest size packets that 73 are less than or equal to the least Maximum Transmission Unit (MTU) 74 for any forwarding device along the routed path to the IP destination 75 for these packets. Such "least MTU" is known as Path MTU (PMTU). 76 Fragmentation or packet drop, silent or not, may occur on hops along 77 the route where a MTU is smaller than the size of the datagram. To 78 avoid any of the listed above behaviors, the packet source must find 79 the value of the least MTU, i.e. PMTU, that will be encountered along 80 the route that a set of packets will follow to reach the given set of 81 destinations. Such MTU determination along a specific path is 82 referred to as path MTU discovery (PMTUD). 84 [I-D.ietf-bier-architecture] introduces and explains Bit Index 85 Explicit Replication (BIER) architecture and how it supports 86 forwarding of multicast data packets. A BIER domain consists of Bit- 87 Forwarding Routers (BFRs) that are uniquely identified by their 88 respective BFR-ids. An ingress border router (acting as a Bit 89 Forwarding Ingress Router (BFIR)) inserts a Forwarding Bit Mask 90 (F-BM) into a packet. Each targeted egress node (referred to as a 91 Bit Forwarding Egress Router (BFER)) is represented by Bit Mask 92 Position (BMP) in the BMS. A transit or intermediate BIER node, 93 referred as BFR, forwards BIER encapsulated packets to BFERs, 94 identified by respective BMPs, according to a Bit Index Forwarding 95 Table (BIFT). 97 1.1. Conventions used in this document 99 1.1.1. Terminology 101 BFR: Bit-Forwarding Router 103 BFER: Bit-Forwarding Egress Router 105 BFIR: Bit-Forwarding Ingress Router 107 BIER: Bit Index Explicit Replication 109 BIFT: Bit Index Forwarding Tree 111 F-BM: Forwarding Bit Mask 113 MTU: Maximum Transmission Unit 115 OAM: Operations, Administration and Maintenance 117 PMTUD: Path MTU Discovery 119 1.1.2. Requirements Language 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 123 "OPTIONAL" in this document are to be interpreted as described in BCP 124 14 [RFC2119] [RFC8174] when, and only when, they appear in all 125 capitals, as shown here. 127 2. Problem Statement 129 [I-D.ietf-bier-oam-requirements] sets forth the requirement to define 130 PMTUD protocol for BIER domain. This document describes the 131 extension to [I-D.ietf-bier-ping] for use in BIER PMTUD solution. 133 Current PMTUD mechanisms ([RFC1191], [RFC8201], and [RFC4821]) are 134 primarily targeted to work on point-to-point, i.e. unicast paths. 135 These mechanisms use packet fragmentation control by disabling 136 fragmentation of the probe packet. As a result, a transient node 137 that cannot forward a probe packet that is bigger than its link MTU 138 sends to the packet source an error notification, otherwise the 139 packet destination may respond with a positive acknowledgement. 140 Thus, possibly through a series of iterations, varying the size of 141 the probe packet, the packet source discovers the PMTU of the 142 particular path. 144 Thus applied such existing PMTUD solutions are inefficient for point- 145 to-multipoint paths constructed for multicast traffic. Probe packets 146 must be flooded through the whole set of multicast distribution paths 147 over and over again until the very last egress responds with a 148 positive acknowledgement. Consider without loss of generality an 149 example multicast network presented in Figure 1, where MTU on all 150 links but one (B,D) is the same. If MTU on link (B,D) is smaller 151 than the MTU on the other links, using existing PMTUD mechanism 152 probes will unnecessary flood to leaf nodes E, F, and G for the 153 second and consecutive times and positive responses will be generated 154 and received by root A repeatedly. 156 ----- 157 --| D | 158 ----- / ----- 159 --| B |-- 160 / ----- \ ----- 161 / --| E | 162 ----- / ----- 163 | A |--- ----- 164 ----- \ --| F | 165 \ ----- / ----- 166 --| C |-- 167 ----- \ ----- 168 --| G | 169 ----- 171 Figure 1: Multicast network 173 3. PMTUD Mechanism for BIER 175 A BFIR selects a set of BFERs for the specific multicast 176 distribution. Such a BFIR determines, by explicitly controlling 177 subset of targeted BFERs and transmitting series of probe packets, 178 the MTU of that multicast distribution tree. The critical step is 179 that in case of failure at an intermediate BFR to forward towards the 180 subset of targeted downstream BFERs, the BFR responds with a partial 181 (compared to the one it received in the request) bitmask towards the 182 originating BFIR in error notification. That allows for 183 retransmission of the next probe with smaller MTU address only 184 towards the failed downstream BFERs instead of all BFERs addressed in 185 the previous probe. In the scenario discussed in Section 2 the 186 second and all following (if needed) probes will be sent only to the 187 node D since MTU discovery of E, F, and G has been completed already 188 by the first probe successfully. 190 [I-D.ietf-bier-ping] introduced BIER Ping as a transport-independent 191 OAM mechanism to detect and localize failures in the BIER data plane. 192 This document specifies how BIER Ping can be used to perform 193 efficient PMTUD in the BIER domain. 195 Consider the network displayed in Figure 1 to be presentation of a 196 BIER domain and all nodes to be BFRs. To discover MTU over BIER 197 domain to BFERs D, F, E, and G BFIR A will use BIER Ping with Data 198 TLV, defined in Section 3.1. Size of the first probe set to M_max 199 determined as minimal MTU value of BFIR's links to BIER domain. As 200 has been assumed in Section 2, MTUs of all links but link (B,D) are 201 the same. Thus BFERs E. F, and G would receive BIER Echo Request 202 and will send their respective replies to BFIR A. BFR B may pass the 203 packet which is too large to forward over egress link (B, D) to the 204 appropriate network layer for error processing where it would be 205 recognized as a BIER Echo Request packet. BFR B MUST send BIER Echo 206 Reply to BFIR A and MUST include Downstream Mapping TLV, defined in 207 [I-D.ietf-bier-ping] setting its fields in the following fashion: 209 o MTU SHOULD be set to the minimal MTU value among all egress BIER 210 links, logical links between this and downstream BFRs, that could 211 be used to reach B's downstream BFERs; 213 o Address Type MUST be set to 0 [Ed.note: we need to define 0 as 214 valid value for the Address Type field with the specific semantics 215 to "Ignore" it.] 217 o I flag MUST be cleared; 219 o Downstream Interface Address field (4 octets) MUST be zeroed and 220 MUST include in the Egress Bitstring sub-TLV the list of all BFERs 221 that cannot be reached because the attempted MTU turned out to be 222 too small. 224 The BFIR will receive either of the two types of packets: 226 o a positive Echo Reply from one of BFERs to which the probe has 227 been sent. In this case the bit corresponding to the BFER MUST be 228 cleared from the BMS; 230 o a negative Echo Reply with bit string listing unreached BFERs and 231 recommended MTU value MTU'. The BFIR MUST add the bit string to 232 its BMS and set size of the next probe as min(MTU, MTU') 234 If upon expiration of the Echo Request timer BFIR didn't receive any 235 Echo Replies, then the size of the probe SHOULD be decreased. There 236 are scenarios when an implementation of the PMTUD would not decrease 237 the size of the probe. For example, if upon expiration of the Echo 238 Request timer BFIR didn't receive any Echo Reply, then BFIR MAY 239 continue to retransmit the probe using the initial size and MAY apply 240 probe delay retransmission procedures. The algorithm used to delay 241 retransmission procedures on BFIR is outside the scope of this 242 specification. The BFIR sends probes using BMS and locally defined 243 retransmission procedures until either the bit string is clear, i.e. 244 contains no set bits, or until the BFIR retransmission procedure 245 terminates and PMTU discovery is declared unsuccessful. In case of 246 convergence of the procedure, the size of the last probe indicates 247 the PMTU size that can be used for all BFERs in the initial BMS 248 without incurring fragmentation. 250 Thus we conclude that in order to comply with the requirement in 251 [I-D.ietf-bier-oam-requirements]: 253 o a BFR SHOULD support PMTUD; 255 o a BFR MAY use defined per BIER sub-domain MTU value as initial MTU 256 value for discovery or use it as MTU for this BIER sub-domain to 257 reach BFERs; 259 o a BFIR MUST have a locally defined of PMTUD probe retransmission 260 procedure. 262 3.1. Data TLV for BIER Ping 264 There needs to be a control for probe size in order to support the 265 BIER PMTUD. Data TLV format is presented in Figure 2. 267 0 1 2 3 268 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 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Type (TBA1) | Length | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Data | 273 ~ ~ 274 | | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 Figure 2: Data TLV format 279 o Type: indicates Data TLV, to be allocated by IANA Section 4. 281 o Length: the length of the Data field in octets. 283 o Data: n octets (n = Length) of arbitrary data. The receiver 284 SHOULD ignore it. 286 4. IANA Considerations 288 IANA is requested to assign new Type value for Data TLV Type from its 289 registry of TLV and sub-TLV Types of BIER Ping as follows: 291 +-------+-------------+---------------+ 292 | Value | Description | Reference | 293 +-------+-------------+---------------+ 294 | TBA1 | Data | This document | 295 +-------+-------------+---------------+ 297 Table 1: Data TLV Type 299 5. Security Considerations 301 Routers that support PMTUD based on this document are subject to the 302 same security considerations as defined in [I-D.ietf-bier-ping] 304 6. Acknowledgement 306 Authors greatly appreciate thorough review and the most detailed 307 comments by Eric Gray. 309 7. References 311 7.1. Normative References 313 [I-D.ietf-bier-ping] 314 Kumar, N., Pignataro, C., Akiya, N., Zheng, L., Chen, M., 315 and G. Mirsky, "BIER Ping and Trace", draft-ietf-bier- 316 ping-01 (work in progress), January 2017. 318 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 319 DOI 10.17487/RFC1191, November 1990, 320 . 322 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 323 Requirement Levels", BCP 14, RFC 2119, 324 DOI 10.17487/RFC2119, March 1997, 325 . 327 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 328 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 329 . 331 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 332 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 333 May 2017, . 335 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 336 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 337 DOI 10.17487/RFC8201, July 2017, 338 . 340 7.2. Informative References 342 [I-D.ietf-bier-architecture] 343 Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and 344 S. Aldrin, "Multicast using Bit Index Explicit 345 Replication", draft-ietf-bier-architecture-07 (work in 346 progress), June 2017. 348 [I-D.ietf-bier-oam-requirements] 349 Mirsky, G., Nordmark, E., Pignataro, C., Kumar, N., 350 Aldrin, S., Zheng, L., Chen, M., Akiya, N., and S. 351 Pallagatti, "Operations, Administration and Maintenance 352 (OAM) Requirements for Bit Index Explicit Replication 353 (BIER) Layer", draft-ietf-bier-oam-requirements-03 (work 354 in progress), January 2017. 356 Authors' Addresses 358 Greg Mirsky 359 ZTE Corp. 361 Email: gregimirsky@gmail.com 363 Tony Przygienda 364 Juniper Networks 366 Email: prz@juniper.net 368 Andrew Dolganow 369 Nokia 371 Email: andrew.dolganow@nokia.com