HI Tom, > -----Original Message----- > From: Tom Herbert [mailto:tom@xxxxxxxxxxxxxxx] > Sent: Friday, February 04, 2022 4:33 PM > To: Templin (US), Fred L <Fred.L.Templin@xxxxxxxxxx> > Cc: Gorry Fairhurst <gorry@xxxxxxxxxxxxxx>; touch@xxxxxxxxxxxxxx; draft-ietf-6man-mtu-option@xxxxxxxx; ipv6@xxxxxxxx; last- > call@xxxxxxxx; IETF-Announce <ietf-announce@xxxxxxxx>; 6man-chairs@xxxxxxxx > Subject: [EXTERNAL] Re: [Last-Call] Re: Last Call: <draft-ietf-6man-mtu-option-12.txt> (IPv6 Minimum Path MTU Hop-by-Hop Option) to > Experimental RFC > > EXT email: be mindful of links/attachments. > > > > On Fri, Feb 4, 2022 at 4:21 PM Templin (US), Fred L > <Fred.L.Templin@xxxxxxxxxx> wrote: > > > > Hi Tom, > > > > > -----Original Message----- > > > From: Tom Herbert [mailto:tom@xxxxxxxxxxxxxxx] > > > Sent: Friday, February 04, 2022 2:09 PM > > > To: Templin (US), Fred L <Fred.L.Templin@xxxxxxxxxx> > > > Cc: Gorry Fairhurst <gorry@xxxxxxxxxxxxxx>; touch@xxxxxxxxxxxxxx; draft-ietf-6man-mtu-option@xxxxxxxx; ipv6@xxxxxxxx; last- > > > call@xxxxxxxx; IETF-Announce <ietf-announce@xxxxxxxx>; 6man-chairs@xxxxxxxx > > > Subject: Re: [Last-Call] [EXTERNAL] Re: Last Call: <draft-ietf-6man-mtu-option-12.txt> (IPv6 Minimum Path MTU Hop-by-Hop Option) to > > > Experimental RFC > > > > > > EXT email: be mindful of links/attachments. > > > > > > > > > > > > On Fri, Feb 4, 2022 at 1:30 PM Templin (US), Fred L > > > <Fred.L.Templin@xxxxxxxxxx> wrote: > > > > > > > > Hi Gorry, > > > > > > > > > -----Original Message----- > > > > > From: Gorry Fairhurst [mailto:gorry@xxxxxxxxxxxxxx] > > > > > Sent: Friday, February 04, 2022 9:50 AM > > > > > To: Templin (US), Fred L <Fred.L.Templin@xxxxxxxxxx>; touch@xxxxxxxxxxxxxx; Tom Herbert <tom@xxxxxxxxxxxxxxx> > > > > > Cc: draft-ietf-6man-mtu-option@xxxxxxxx; ipv6@xxxxxxxx; last-call@xxxxxxxx; IETF-Announce <ietf-announce@xxxxxxxx>; 6man- > > > > > chairs@xxxxxxxx > > > > > Subject: Re: [Last-Call] [EXTERNAL] Re: Last Call: <draft-ietf-6man-mtu-option-12.txt> (IPv6 Minimum Path MTU Hop-by-Hop > Option) to > > > > > Experimental RFC > > > > > > > > > > EXT email: be mindful of links/attachments. > > > > > > > > > > > > > > > > > > > > On 04/02/2022 16:08, Templin (US), Fred L wrote: > > > > > > Gorry, thanks and see also below: > > > > > > > > > > > > Fred > > > > > > > > > > > >> -----Original Message----- > > > > > >> From: last-call [mailto:last-call-bounces@xxxxxxxx] On Behalf Of Gorry Fairhurst > > > > > >> Sent: Friday, February 04, 2022 4:36 AM > > > > > >> To: touch@xxxxxxxxxxxxxx; Tom Herbert <tom@xxxxxxxxxxxxxxx> > > > > > >> Cc: draft-ietf-6man-mtu-option@xxxxxxxx; ipv6@xxxxxxxx; last-call@xxxxxxxx; Templin (US), Fred L <Fred.L.Templin@xxxxxxxxxx>; > > > IETF- > > > > > >> Announce <ietf-announce@xxxxxxxx>; 6man-chairs@xxxxxxxx > > > > > >> Subject: Re: [Last-Call] [EXTERNAL] Re: Last Call: <draft-ietf-6man-mtu-option-12.txt> (IPv6 Minimum Path MTU Hop-by-Hop > Option) > > > to > > > > > >> Experimental RFC > > > > > >> > > > > > >> EXT email: be mindful of links/attachments. > > > > > >> > > > > > >> > > > > > >> > > > > > >> See below at bottom. > > > > > >> > > > > > >> On 04/02/2022 02:13, touch@xxxxxxxxxxxxxx wrote: > > > > > >>> Sure - that works. > > > > > >>> > > > > > >>> I’m just hoping we don’t create something so future-proofed that it is > > > > > >>> present-prevented. > > > > > >>> > > > > > >>> Joe > > > > > >>> > > > > > >>> — > > > > > >>> Joe Touch, temporal epistemologist > > > > > >>> www.strayalpha.com <http://www.strayalpha.com> > > > > > >>> > > > > > >>>> On Feb 3, 2022, at 3:37 PM, Tom Herbert <tom@xxxxxxxxxxxxxxx> wrote: > > > > > >>>> > > > > > >>>> On Thu, Feb 3, 2022 at 3:16 PM touch@xxxxxxxxxxxxxx > > > > > >>>> <touch@xxxxxxxxxxxxxx> wrote: > > > > > >>>>> Fair enough. Two more bytes burned for largely no reason for the > > > > > >>>>> foreseeable future, but so be it. > > > > > >>>> Joe, > > > > > >>>> > > > > > >>>> It's more like eight more bytes burned since both two byte fields need > > > > > >>>> to be extended to four bytes and the EH needs to be padded to have > > > > > >>>> length in units of eight bytes. Given that MTU's that exceed 64K are > > > > > >>>> exceedingly rare, this does seem like a lot of overhead to add to > > > > > >>>> potentially every packet. Also, if the sender already knows that its > > > > > >>>> local MTU is less than 64K, the discovery that the network supports a > > > > > >>>> higher MTU doesn't seem to be useful information. An alternative might > > > > > >>>> be to define a long format of the option with larger MTU fields that > > > > > >>>> can coexist with the already defined option. This could be done by > > > > > >>>> using the same option type number, but discriminating between to the > > > > > >>>> two formats based on the option length. > > > > > >>>> > > > > > >>>> Tom > > > > > >>>> > > > > > >>>>> — > > > > > >>>>> Joe Touch, temporal epistemologist > > > > > >>>>> www.strayalpha.com <http://www.strayalpha.com> > > > > > >>>>> > > > > > >>>>> On Feb 3, 2022, at 2:13 PM, Templin (US), Fred L > > > > > >>>>> <Fred.L.Templin@xxxxxxxxxx> wrote: > > > > > >>>>> > > > > > >>>>> Hi Joe, > > > > > >>>>> > > > > > >>>>>> Why stop at 32 bits? They COULD expand to 128. Or 1024. Or more. > > > > > >>>>> RFC4443 PTB stops at 32 bits and RFC2675 Jumbo Payload stops at 32bits. > > > > > >>>>> So should this. > > > > > >>>>> > > > > > >>>>>> If and when we ever get close to 64K, we could easily declare all > > > > > >>>>>> 1’s as indicating the need for an extended value > > > > > >>>>> IP parcels give a reason for link MTUs > 64K, and link designers > > > > > >>>>> will start to take note. > > > > > >>>>> > > > > > >>>>>> IMO, let’s not complicate things unnecessarily now. > > > > > >>>>> I understand, but the problem is this document is reserving one of > > > > > >>>>> the few scarce HBH > > > > > >>>>> option codes still available. And, once locked in at whatever MTU > > > > > >>>>> field size we agree > > > > > >>>>> on it will be impossible to change in the future. It is not > > > > > >>>>> complicated to make the field > > > > > >>>>> sizes 32bits now, which would match RFCs 2675 and 4443. > > > > > >>>>> > > > > > >>>>> Fred > > > > > >>>>> > > > > > >>>>> From: ipv6 [mailto:ipv6-bounces@xxxxxxxx] On Behalf Of > > > > > >>>>> touch@xxxxxxxxxxxxxx > > > > > >>>>> Sent: Thursday, February 03, 2022 1:47 PM > > > > > >>>>> To: last-call@xxxxxxxx > > > > > >>>>> Cc: draft-ietf-6man-mtu-option@xxxxxxxx; ipv6@xxxxxxxx; > > > > > >>>>> IETF-Announce <ietf-announce@xxxxxxxx>; 6man-chairs@xxxxxxxx > > > > > >>>>> Subject: [EXTERNAL] Re: [Last-Call] Last Call: > > > > > >>>>> <draft-ietf-6man-mtu-option-12.txt> (IPv6 Minimum Path MTU > > > > > >>>>> Hop-by-Hop Option) to Experimental RFC > > > > > >>>>> > > > > > >>>>> Why stop at 32 bits? They COULD expand to 128. Or 1024. Or more. > > > > > >>>>> > > > > > >>>>> Right now, anything above 1500 is a unicorn outside closed > > > > > >>>>> environments (e.g., data centers): > > > > > >>>>> https://tma.ifip.org/2018/wp-content/uploads/sites/3/2018/06/tma2018_paper57.pdf > > > > > >>>>> > > > > > >>>>> A lot of the point of this option is to figure out what number below > > > > > >>>>> 1500 works - and/or when numbers even below those required for IPv6 > > > > > >>>>> minimums are needed. > > > > > >>>>> > > > > > >>>>> If and when we ever get close to 64K, we could easily declare all > > > > > >>>>> 1’s as indicating the need for an extended value. > > > > > >>>>> > > > > > >>>>> IMO, let’s not complicate things unnecessarily now. > > > > > >>>>> > > > > > >>>>> Joe > > > > > >>>>> > > > > > >>>>> — > > > > > >>>>> Joe Touch, temporal epistemologist > > > > > >>>>> www.strayalpha.com > > > > > >>>>> > > > > > >>>>> > > > > > >>>>> On Feb 3, 2022, at 1:16 PM, Templin (US), Fred L > > > > > >>>>> <Fred.L.Templin@xxxxxxxxxx> wrote: > > > > > >>>>> > > > > > >>>>> I have a comment - section 5 ("IPv6 Minimum Path MTU Hop-by-Hop > > > > > >>>>> Option") sets > > > > > >>>>> aside two 16-bit fields to record MTU values. This places an upper > > > > > >>>>> bound limit of > > > > > >>>>> (2**16 - 1) octets on the MTU that can be recorded at each hop, but > > > > > >>>>> this will be > > > > > >>>>> too small for IP parcels which can grow to (64 * (2**16 -1)) octets. > > > > > >>>>> And, if support > > > > > >>>>> for true jumbos may be needed in the future the fields should > > > > > >>>>> probably permit sizes > > > > > >>>>> up to (2**32 -1) octets which would require 32-bit fields. > > > > > >>>>> > > > > > >>>>> Fred > > > > > >>>>> > > > > > >>>>> > > > > > >>>>> -----Original Message----- > > > > > >>>>> From: ipv6 [mailto:ipv6-bounces@xxxxxxxx] On Behalf Of The IESG > > > > > >>>>> Sent: Thursday, January 27, 2022 4:38 PM > > > > > >>>>> To: IETF-Announce <ietf-announce@xxxxxxxx> > > > > > >>>>> Cc: draft-ietf-6man-mtu-option@xxxxxxxx; ipv6@xxxxxxxx; > > > > > >>>>> 6man-chairs@xxxxxxxx > > > > > >>>>> Subject: Last Call: <draft-ietf-6man-mtu-option-12.txt> (IPv6 > > > > > >>>>> Minimum Path MTU Hop-by-Hop Option) to Experimental RFC > > > > > >>>>> > > > > > >>>>> EXT email: be mindful of links/attachments. > > > > > >>>>> > > > > > >>>>> > > > > > >>>>> > > > > > >>>>> > > > > > >>>>> The IESG has received a request from the IPv6 Maintenance WG (6man) to > > > > > >>>>> consider the following document: - 'IPv6 Minimum Path MTU Hop-by-Hop > > > > > >>>>> Option' > > > > > >>>>> <draft-ietf-6man-mtu-option-12.txt> as Experimental RFC > > > > > >>>>> > > > > > >>>>> The IESG plans to make a decision in the next few weeks, and > > > > > >>>>> solicits final > > > > > >>>>> comments on this action. Please send substantive comments to the > > > > > >>>>> last-call@xxxxxxxx mailing lists by 2022-02-10. Exceptionally, > > > > > >>>>> comments may > > > > > >>>>> be sent to iesg@xxxxxxxx instead. In either case, please retain the > > > > > >>>>> beginning > > > > > >>>>> of the Subject line to allow automated sorting. > > > > > >>>>> > > > > > >>>>> Abstract > > > > > >>>>> > > > > > >>>>> > > > > > >>>>> This document specifies a new IPv6 Hop-by-Hop option that is used to > > > > > >>>>> record the minimum Path MTU along the forward path between a source > > > > > >>>>> host to a destination host. The recorded value can then be > > > > > >>>>> communicated back to the source using the return Path MTU field in > > > > > >>>>> the option. > > > > > >>>>> > > > > > >>>>> > > > > > >>>>> > > > > > >>>>> > > > > > >>>>> The file can be obtained via > > > > > >>>>> https://datatracker.ietf.org/doc/draft-ietf-6man-mtu-option/ > > > > > >>>>> > > > > > >>>>> > > > > > >>>>> The following IPR Declarations may be related to this I-D: > > > > > >>>>> > > > > > >>>>> https://datatracker.ietf.org/ipr/4567/ > > > > > >>>>> > > > > > >>>>> > > > > > >>>>> > > > > > >>>>> > > > > > >>>>> > > > > > >>>>> > > > > > >>>>> -------------------------------------------------------------------- > > > > > >>>>> IETF IPv6 working group mailing list > > > > > >>>>> ipv6@xxxxxxxx > > > > > >>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > > > >>>>> -------------------------------------------------------------------- > > > > > >>>>> > > > > > >>>>> > > > > > >>>>> -- > > > > > >>>>> last-call mailing list > > > > > >>>>> last-call@xxxxxxxx > > > > > >>>>> https://www.ietf.org/mailman/listinfo/last-call > > > > > >>>>> > > > > > >>>>> > > > > > >>>>> -- > > > > > >>>>> last-call mailing list > > > > > >>>>> last-call@xxxxxxxx > > > > > >>>>> https://www.ietf.org/mailman/listinfo/last-call > > > > > >>>>> > > > > > >>>>> > > > > > >>>>> -------------------------------------------------------------------- > > > > > >>>>> IETF IPv6 working group mailing list > > > > > >>>>> ipv6@xxxxxxxx > > > > > >>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > > > >>>>> -------------------------------------------------------------------- > > > > > >>>> -- > > > > > >>>> last-call mailing list > > > > > >>>> last-call@xxxxxxxx > > > > > >>>> https://www.ietf.org/mailman/listinfo/last-call > > > > > >> Thanks for asking this: I'm going to push back a little on extending the > > > > > >> method to future-proof it... > > > > > >> > > > > > >> The motivation for an HBH option is to help support equipment that > > > > > >> indeed wishes to deploy a larger MTU, targeting jumbo Ethernet frames. > > > > > >> > > > > > >> Personally: I 'm not convinced we should add to this spec to provdie > > > > > >> extensibility for future experiments with new IP link technologies > > > > > >> supporting greater than 64KB. I'll argue for the target purpose a fixed > > > > > >> sized HBH option is more deployable, and likely to be useful for the > > > > > >> "foreseeable" future. > > > > > >> > > > > > >> If it helps, we could add text saying a host wishing to use a MTU larger > > > > > >> than 64KB must not use this HBH option, although that might be obvious. > > > > > > I think what is being asked is very simple and not hard at all to implement. It > > > > > > is just a simple test of the option length - if the length is 4 the option is in > > > > > > "short form", and if the length is 8 the option is in "long form". > > > > > > > > > > > > But, the overriding consideration is that there is an impending use of Jumbos > > > > > > that we believe will begin to emerge in the near term called: "IP Parcels". If > > > > > > you have not heard about them yet, I strongly suggest you have a quick look: > > > > > > > > > > > > https://datatracker.ietf.org/doc/draft-templin-intarea-parcels/ > > > > > > > > > > > > IP Parcels should become an early adopter of your MTU option, but they can > > > > > > be larger than 64K (up to 4M) and would very soon want to begin using the > > > > > > long form. Plus, the MTU option would only be used on path qualification > > > > > > messages and not on every single packet so using the long form would not > > > > > > introduce any unnecessary inefficiencies. > > > > > > > > > > > > So yes - please include both long and short forms of the MTU option in the > > > > > > first publication - because it is very likely going to cast the option in stone > > > > > > for the forseeable future. > > > > > > > > > > > > Thanks - Fred > > > > > > > > > > > >> Gorry > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> -- > > > > > >> last-call mailing list > > > > > >> last-call@xxxxxxxx > > > > > >> https://www.ietf.org/mailman/listinfo/last-call > > > > > > > > > > I did read the draft you pointed to thanks, because I anticipated that > > > > > your query might be linked to this topic - my thought is that if your > > > > > work was to proceed in future at the IETF, then you might be able to > > > > > take advantage of the HBH option proposed in the draft for traversing > > > > > standard links (i.e. with KB of MTU). > > > > > > > > It is true that "standard" today is for small numbers of KB of MTU (or, as much > > > > as 64KB for tunnels and loopbacks), but with IP Parcels there is no reason that > > > > "standard" in the not too distant future could very quickly become 100's of KB > > > > of MTU or even more. > > > > > > Hi Fred, > > > > > > I appreciate the ambition, but history doesn't seem to support your > > > thesis with regards increasing link MTUs. For instance, we've had 9K > > > Ethernet jumbo frames for a while, but it's only recently that > > > hyperscalers like Google have been able to take advantage of them. The > > > good news with that is probably that most vendor hardware supports 9K > > > jumbograms, but it's likely is no widespread hardware support for > > > greater MTUs up to 64K, much less support for link MTUs greater than > > > 64K. We know from experience that if a hardware change is required for > > > a new featured, like increasing link MTU, it takes many years to see > > > any substantial deployment. > > > > There have been large-MTU links in the past such as HiPPI with its 64K MTU. > > But, one reason that modern links have been stuck at 9KB (and more often > > not even that) is that the CRC-32 link integrity check is insufficient for ensuring > > integrity for larger sizes. But, that is assuming that the entire payload is covered > > by a single ULP integrity check, whereas with parcels there are multiple ULP > > segments - each with its own integrity check. So, a link of the not-too-distant > > future could pass a parcel while using a weak link-layer integrity check with > > the understanding that ULPs will engage their own integrity checks on a > > per-segment (as opposed to per-packet) basis. This greatly reduces the > > dependence on strong link-layer integrity checks. > > > > > > There is no reason that IP Parcels cannot very quickly > > > > become mainstream and drive innovation into new link technologies that will > > > > make these (baby) jumbos part of the evolving architecture. > > > > > > > > > > Perhaps, but to me at least the value proposition of IP parcels isn't > > > yet clear (see my comments on the IP parscels thread). > > > > I didn’t realize you were still awaiting comments on that thread; > > I will take a look. But, think of IP parcels as "large packets with > > multiple smaller payloads; each with its own integrity check". That > > is both good for the network and good for the end systems. > > > > > > I believe your MTU option draft will want to be on board with this from the > > > > onset rather than try to do a rework X years from now after the toothpaste is > > > > out of the tube. And, it truly would not take a lot of effort to get it right the > > > > first time. > > > > > > > If the option length is used to discriminate short and long formats of > > > the option, then defining the long option in the future would only be > > > an incremental change to the protocol. To that end, instead of > > > backtracking the draft in Last Call, I would suggest to just add some > > > words that the option format is purposely designed to be extensible by > > > adding formats of different length. The obvious concern with this > > > approach is that vendors might burn in the protocol into hardware, > > > however I believe this problem is adequately mitigated by the various > > > programmable hardware techniques (note that while software programmed > > > protocols will solve the problem of quickly deploying new L3/L4 > > > protocols, changing L1/L2 characteristics like larger MTU still > > > requires hardware change). > > > > No, that would not work because the toothpaste would be out of the tube. > > A path could then include a heterogeneous mix of middleboxes some of > > which understand jumbo MTU options and others that do not; and, all > > would be standards-compliant, but they would not be interoperable! > > It really needs to happen that long-form and short-form are supported > > in the MTU options draft in the first iteration. > > > Right, but the point of the option is to discover the "minimum path > MTU" which is the minimum link MTU in the path. If the path was > heterogeneous as you say it might be, then the MTU returned from the > option would always be less than 64K anyway. It seems like the long > format would only provide more useful information than the short > format when all links in the path and the local MTU are all greater > than 64K. Not necessarily true; the path could consist of a set of links with MTUs: Source -> 4M -> 2M -> 512K -> 256K -> 100K -> Destination and the long-format would be needed at all hops to convey the 100K MTU to the Destination. But, even if the path were something like: Source -> 4M -> 2M -> 9K -> 1500 -> 100K -> Destination the source would still insert the long-format and each hop along the path would need to forward the long format even though the MTU dips below 64KB. It would make little sense for the middleboxes to translate the long format into short format because that would be computationally expensive. But, the destination could convert from short format to long format, for example, when it returns a responsive message with the MTU option. So, the decision point for short format vs. long format on the initial leg is the MTU of the outgoing interface, and the decision point on the return leg is the "or" of the incoming MTU option value being larger than 64KB or the return interface being larger than 64KB. Fred > > Tom > > > Thanks - Fred > > > > > > > > Tom > > > > > > > Thanks - Fred > > > > > > > > > If your thought was to use packets and frames larger than 64 KB, then > > > > > there would be many issues to consider. There are various possibilities > > > > > including a new header that might be the best way forward for those > > > > > paths that wish to support this approach - I'd expect you'd need new > > > > > functionality anyway at routers to handle this change in architecture. > > > > > This was not what was considered in draft-ietf-6man-mtu-option. > > > > > > > > > > Gorry > > > > > > -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
