Tom, yes the idea of a short form / long form as told by the option length sounds just right. The rule could be that if the sender's first-hop link MTU is larger than 64KB then include the long form; else include the short form. The other thing is that the option does not need to be included on every packet; for example, it might go on only a few packets used for path qualification purposes and then omitted after path qualification is complete. Can we have the document revised to include long form / short form versions of the option? Thanks - Fred > -----Original Message----- > From: Tom Herbert [mailto:tom@xxxxxxxxxxxxxxx] > Sent: Thursday, February 03, 2022 3:37 PM > To: touch@xxxxxxxxxxxxxx > Cc: Templin (US), Fred L <Fred.L.Templin@xxxxxxxxxx>; last-call@xxxxxxxx; draft-ietf-6man-mtu-option@xxxxxxxx; ipv6@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 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 > > > > 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
