Reducing the cc: a little and trimming the response. > On Feb 4, 2022, at 9:49 AM, Gorry Fairhurst <gorry@xxxxxxxxxxxxxx> wrote: > > On 04/02/2022 16:08, Templin (US), Fred L wrote: >> Gorry, thanks and see also below: >> >> Fred >> >>> >>> 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 >>> >>> > > 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.
Attachment:
signature.asc
Description: Message signed with OpenPGP
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
