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

[Gorry Fairhurst <gorry@xxxxxxxxxxxxxx>]

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.

Gorry




--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call