Hi Ole, > -----Original Message----- > From: Ole Troan [mailto:otroan@xxxxxxxxxxxxx] > Sent: Friday, February 04, 2022 2:48 PM > To: Tom Herbert <tom@xxxxxxxxxxxxxxx> > Cc: Templin (US), Fred L <Fred.L.Templin@xxxxxxxxxx>; Gorry Fairhurst <gorry@xxxxxxxxxxxxxx>; touch@xxxxxxxxxxxxxx; ipv6@xxxxxxxx; > last-call@xxxxxxxx; draft-ietf-6man-mtu-option@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 > > > > > On 4 Feb 2022, at 23:11, Tom Herbert <tom@xxxxxxxxxxxxxxx> wrote: > > > > 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). > > Burnt into hardware that will never support packets larger than 64kB doesn’t sound like a problem to me. 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. = -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
