Subject: Re: [Last-Call] Last Call: <draft-ietf-6man-mtu-option-12.txt> (IPv6 Minimum Path MTU Hop-by-Hop Option) to Experimental RFC

From: "Templin (US), Fred L" <[email-masked]>
Date: Thu, 3 Feb 2022 21:16:25 +0000

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:[email-masked]] On Behalf Of The IESG
> Sent: Thursday, January 27, 2022 4:38 PM
> To: IETF-Announce <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked]
> 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
> [email-masked] mailing lists by 2022-02-10. Exceptionally, comments may
> be sent to [email-masked] 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
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 3 Feb 2022 13:47:18 -0800

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 <[email-masked]> wrote:
> 
> -- 
> last-call mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/last-call

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Thu, 3 Feb 2022 22:13:15 +0000

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:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, February 03, 2022 1:47 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; IETF-Announce <[email-masked]>; [email-masked]
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

Joe

—
Joe Touch, temporal epistemologist
www.strayalpha.com<http://www.strayalpha.com>

On Feb 3, 2022, at 1:16 PM, Templin (US), Fred L <[email-masked]<mailto:[email-masked]>> wrote:

Fred

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of The IESG
Sent: Thursday, January 27, 2022 4:38 PM
To: IETF-Announce <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Last Call: <draft-ietf-6man-mtu-option-12.txt> (IPv6 Minimum Path MTU Hop-by-Hop Option) to 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
[email-masked]<mailto:[email-masked]> mailing lists by 2022-02-10. Exceptionally, comments may
be sent to [email-masked]<mailto:[email-masked]> instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

--
last-call mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/last-call

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 3 Feb 2022 15:14:18 -0800

Fair enough. Two more bytes burned for largely no reason for the foreseeable future, but so be it.
—
Joe Touch, temporal epistemologist
www.strayalpha.com

> On Feb 3, 2022, at 2:13 PM, Templin (US), Fred L <[email-masked]> wrote:
> 
> Hi Joe,
>  
> https://tma.ifip.org/2018/wp-content/uploads/sites/3/2018/06/tma2018_paper57.pdf <https://tma.ifip.org/2018/wp-content/uploads/sites/3/2018/06/tma2018_paper57.pdf>
>  
> www.strayalpha.com <http://www.strayalpha.com/>
> 
> 
> On Feb 3, 2022, at 1:16 PM, Templin (US), Fred L <[email-masked] <mailto:[email-masked]>> wrote:
>  
> From: ipv6 [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of The IESG
> To: IETF-Announce <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]> mailing lists by 2022-02-10. Exceptionally, comments may
> be sent to [email-masked] <mailto:[email-masked]> instead. In either case, please retain the beginning
> https://datatracker.ietf.org/doc/draft-ietf-6man-mtu-option/ <https://datatracker.ietf.org/doc/draft-ietf-6man-mtu-option/>
> 
> 
>   https://datatracker.ietf.org/ipr/4567/ <https://datatracker.ietf.org/ipr/4567/>
> 
> 
> 
> 
> 
> 
> [email-masked] <mailto:[email-masked]>
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/last-call <https://www.ietf.org/mailman/listinfo/last-call>
>  
> -- 
> last-call mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/last-call <https://www.ietf.org/mailman/listinfo/last-call>

---

From: Tom Herbert <[email-masked]>
Date: Thu, 3 Feb 2022 15:37:16 -0800

> 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

---

From: Mark Smith <[email-masked]>
Date: Fri, 4 Feb 2022 11:04:54 +1100

> two formats based on the option length.

Or perhaps another spec to describe how the IPv6 Jumbogram EH works in
combination with this.

Regards,
Mark.

> > > If and when we ever get close to 64K, we could easily declare all 1’s
> as indicating the need for an extended value
> >
> > Cc: [email-masked]; [email-masked]; IETF-Announce <
> [email-masked]>; [email-masked]
> > 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
> >
> > 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.
> >
> > Subject: Last Call: <draft-ietf-6man-mtu-option-12.txt> (IPv6 Minimum
> Path MTU Hop-by-Hop Option) to Experimental RFC
> >

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Fri, 4 Feb 2022 00:35:26 +0000

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

> From: Tom Herbert [mailto:[email-masked]]
> Sent: Thursday, February 03, 2022 3:37 PM
> To: [email-masked]
> Cc: Templin (US), Fred L <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; IETF-
> Announce <[email-masked]>; [email-masked]
> 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
>

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 3 Feb 2022 18:13:25 -0800

Sure - that works.

I’m just hoping we don’t create something so future-proofed that it is present-prevented.

Joe

—

> On Feb 3, 2022, at 3:37 PM, Tom Herbert <[email-masked]> wrote:
>

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 4 Feb 2022 12:36:28 +0000

See below at bottom.

On 04/02/2022 02:13, [email-masked] wrote:
> www.strayalpha.com <http://www.strayalpha.com>
>
>>> www.strayalpha.com <http://www.strayalpha.com>
>>>
>>>> If and when we ever get close to 64K, we could easily declare all 
>>>> 1’s as indicating the need for an extended value
>>>
>>> Cc: [email-masked]; [email-masked]; 
>>> IETF-Announce <[email-masked]>; [email-masked]
>>> <draft-ietf-6man-mtu-option-12.txt> (IPv6 Minimum Path MTU 
>>> Hop-by-Hop Option) to Experimental RFC
>>>
>>> If and when we ever get close to 64K, we could easily declare all 
>>> 1’s as indicating the need for an extended value.
>>>
>>> Subject: Last Call: <draft-ietf-6man-mtu-option-12.txt> (IPv6 
>>> Minimum Path MTU Hop-by-Hop Option) to Experimental RFC
>>>
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

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Fri, 4 Feb 2022 16:08:31 +0000

Gorry, thanks and see also below:

Fred

> From: last-call [mailto:[email-masked]] On Behalf Of Gorry Fairhurst
> Sent: Friday, February 04, 2022 4:36 AM
> To: [email-masked]; Tom Herbert <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked]; Templin (US), Fred L <[email-masked]>; IETF-
> >>> [email-masked]

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

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 4 Feb 2022 17:49:34 +0000

> for the forseeable future.

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).

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

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Fri, 4 Feb 2022 21:29:45 +0000

Hi Gorry,

> From: Gorry Fairhurst [mailto:[email-masked]]
> Sent: Friday, February 04, 2022 9:50 AM
> To: Templin (US), Fred L <[email-masked]>; [email-masked]; Tom Herbert <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked]; IETF-Announce <[email-masked]>; 6man-
> [email-masked]

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. 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.

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.

Thanks - Fred

---

From: Tom Herbert <[email-masked]>
Date: Fri, 4 Feb 2022 14:09:18 -0800

On Fri, Feb 4, 2022 at 1:30 PM Templin (US), Fred L
<[email-masked]> wrote:
> 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 is no reason that IP Parcels cannot very quickly

Perhaps, but to me at least the value proposition of IP parcels isn't
yet clear (see my comments on the IP parscels thread).

> out of the tube. And, it truly would not take a lot of effort to get it right the
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).

Tom

---

From: Ole Troan <[email-masked]>
Date: Fri, 4 Feb 2022 23:48:23 +0100

> On 4 Feb 2022, at 23:11, Tom Herbert <[email-masked]> wrote:
> 
> The obvious concern with this

Burnt into hardware that will never support packets larger than 64kB doesn’t sound like a problem to me. 

O.

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Sat, 5 Feb 2022 00:25:12 +0000

Hi Ole,

> From: Ole Troan [mailto:[email-masked]]
> Sent: Friday, February 04, 2022 2:48 PM
> To: Tom Herbert <[email-masked]>
> Cc: Templin (US), Fred L <[email-masked]>; Gorry Fairhurst <[email-masked]>; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; IETF-Announce <[email-masked]>; [email-masked]

No, that does not work. A path could include a heterogeneous mix of jumbo-aware
and non-jumbo MTU option hardware. And, if the first one (or a few) hardware elements
in the path are jumbo-aware before reaching a non-jumbo hardware element it will
simply drop the packet. Hence, all hardware needs to be jumbo-aware from the very
beginning when the MTU option draft becomes an RFC.

Fred

> O. =

---

From: Bob Hinden <[email-masked]>
Date: Sat, 5 Feb 2022 10:21:49 -0800

Reducing the cc: a little and trimming the response.

> On Feb 4, 2022, at 9:49 AM, Gorry Fairhurst <[email-masked]> wrote:
> 
> 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).
> 
> 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.

The HBH option is designed to work with the IPv6 header’s header length, not with Jumbograms (RFC 2675).  I agree with Gorry that if it is helpful, we could say that in the draft.

I also agree with Gorry that making packets larger than 64K work on the internet is a big undertaking, that will touch many areas.  We have had RFC2675 Jumbograms since 1999, it doesn’t appear to be any uptaked.   To me, the current state of “IP Parcels” is at a very early stage, that is, an individual draft in the INT area.  I don’t think it warrants changing <draft-ietf-6man-mtu-option> to accommodate it.

Bob

p.s. I can think of a few ways that this option could accommodate Jumbograms without changing the format, but won’t go into that here.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 6 Feb 2022 08:58:43 +1300

>> 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).
>>
>> 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.
> I also agree with Gorry that making packets larger than 64K work on the 
internet is a big undertaking, that will touch many areas.  We have had RFC2675 Jumbograms since 1999, it doesn’t appear to be any uptaked.

https://mailarchive.ietf.org/arch/msg/ipv6/MeVE88345dPY7AcvYI8pN5mU8A0/

> To me, the current state of “IP Parcels” is at a very early stage, that is, an individual draft in the INT area.  I don’t think it warrants changing <draft-ietf-6man-mtu-option> to accommodate it.
> 
> Bob
> 

Don't bother. Jumbograms were always intended to be used in what we'd now 
call "limited domain" deployments with well understood operational constraints, so PMTUD simply isn't needed.

    Brian