Subject: [[email-masked]: New Version Notification for draft-jones-6man-historic-rfc2675-00.txt]

From: Tom Jones <[email-masked]>
Date: Wed, 8 May 2019 13:57:43 +0100

Hello 6man,

We have put this together to change the status of RFC2675 to Historic
and would like to request discussion in the working group.

- Tom and Gorry

----- Forwarded message from [email-masked] -----

Date: Wed, 08 May 2019 05:30:11 -0700
From: [email-masked]
To: Tom Jones <[email-masked]>, Godred Fairhurst <[email-masked]>, Gorry Fairhurst
	<[email-masked]>
Subject: New Version Notification for draft-jones-6man-historic-rfc2675-00.txt

A new version of I-D, draft-jones-6man-historic-rfc2675-00.txt
has been successfully submitted by Tom Jones and posted to the
IETF repository.

Name:		draft-jones-6man-historic-rfc2675
Revision:	00
Title:		Change Status of RFC 2675 to Historic
Document date:	2019-05-08
Group:		Individual Submission
Pages:		12
URL:            https://www.ietf.org/internet-drafts/draft-jones-6man-historic-rfc2675-00.txt
Status:         https://datatracker.ietf.org/doc/draft-jones-6man-historic-rfc2675/
Htmlized:       https://tools.ietf.org/html/draft-jones-6man-historic-rfc2675-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-jones-6man-historic-rfc2675

Abstract:
   This document changes the status of RFC2675, IPv6 Jumbograms, from
   Proposed Standard to Historic.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

----- End forwarded message -----

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 8 May 2019 14:01:45 +0100

> and would like to request discussion in the working group.

This looks sensible.  If something has never really been implemented in 
the first 25 years of a protocol's existence, and adds complication, 
there doesn't seem to be a compelling reason to keep it lying around.

Nick

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 8 May 2019 15:12:50 +0200 (CEST)

> and would like to request discussion in the working group.

I'd like to see the abstract to include the difference between jumbograms 
and jumboframes. This is explained later in the introduction but I think 
it's important to mention this in the abstract to avoid confusion.

Apart from that, looks good to me.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Ole Troan <[email-masked]>
Date: Wed, 8 May 2019 18:07:51 +0200

> and would like to request discussion in the working group.

IPv6 jumbograms was intended for some super computer inter connect with a massive MTU.
I don't know of any use of it, but is it harmful if the specification is left there in place?

I don't expect any implementation supporting it unless they also support data-link layers with an MTU > 64K.
Or is that the problem you are trying to solve, that a TCP implementation must handle datagrams larger than 64K?
Is there any other solution?

Cheers,
Ole

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

---

From: 神明達哉 <[email-masked]>
Date: Wed, 8 May 2019 10:07:21 -0700

At Wed, 8 May 2019 18:07:51 +0200,

> I don't expect any implementation supporting it unless they also support
data-link layers with an MTU > 64K.

FWIW, (most if not all) BSD variants have been supporting jumbograms
for many years (admittedly I don't know if it's still working as
originally implemented, but the code is still there).  When I worked
on the implementation I confirmed its behavior with a loopback
interface configured to have an MTU larger than 64KB.  In that sense,
this statement of the draft is probably too strong:

   This also removes the need for testing Jumbogram support, which
   otherwise require links with a MTU greater than 65,535 bytes, making
   testing of implementations impractical without significant effort.

It's not a straightforward effort, but I don't think it requires a
"significant" one.

In any case, I agree there has been probably no real world deployment
of jumbograms.  I don't have a strong opinion about whether to
deprecate it.

--
JINMEI, Tatuya

---

From: Bob Hinden <[email-masked]>
Date: Wed, 8 May 2019 10:26:48 -0700

Hi,

> On May 8, 2019, at 9:07 AM, Ole Troan <[email-masked]> wrote:
> 
>> Hello 6man,
>> 

Are there any current network interfaces that can support packets larger than 65,535 octets?   As I remember, it was intended for network interfaces like hyperchannel that could support packets larger than 65,535.    Did we every define an IPv6 over Hyperchannel specification?

As a co-author of RFC2675, I am OK with making it historic.   It was very limited in use when first defined, and hasn’t gotten better.   

Thanks,
Bob

---

From: Loganaden Velvindron <[email-masked]>
Date: Wed, 8 May 2019 21:34:36 +0400

Comment in-line.

> for many years (admittedly I don't know if it's still working as

Indeed, according to this
https://www.freebsd.org/doc/en/books/developers-handbook/ipv6.html#ipv6-jumbo

You need to re-compile the kernel to get support for it. So it's not
shipped by default.

I think that it's worth mentioning it that in the draft.

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Wed, 08 May 2019 18:30:07 +0000

On 8 May 2019, at 17:26, Bob Hinden wrote:

> Are there any current network interfaces that can support packets 
> larger than 65,535 octets?

On a standardised interface/protocol (*) or just capable to?

I seem to remember that at least Altera’s 40/100G Ethernet MAC/PHY 
Core had no frame size limits in cut-through mode.  So I’d assume that 
off-the-shelf FPGA hardware might be able to generate (and receive) such 
packets.  Maybe someone more knowledgeable in that are could confirm 
this?

> As a co-author of RFC2675, I am OK with making it historic.   It was 
> very limited in use when first defined, and hasn’t gotten better.

Can RFCs be resurrected from historic to “alive”?

/bz

(*) That said, large jumboframes never were IEEE standardised, right?

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 9 May 2019 08:35:36 +1200

> As a co-author of RFC2675, I am OK with making it historic.   It was very limited in use when first defined, and hasn’t gotten better. 

I disagree. This was designed for a specific usage scenario that was of some concern to me at the time: use within data-intensive data centres handling distributed applications dealing with very large datasets. (At CERN we were already thinking about the future LHC datasets back in the 1990s.) There was hardware in use at the time (HIPPI) that allowed exceedingly large frames. Now things haven't worked out exactly as we expected, but scientific datasets are only getting bigger as time goes on. Jumbograms might be needed in future data scientific data centres.

I don't think we should obsolete this possibility. It is very much a case in point of a limited domain protocol that will never be used over the open Internet. If unused, it's harmless. General-purpose transport protocols don't need to consider it.

It's absolutely reasonable to make it an OPTIONAL feature of IPv6 implementations, which is already the case in practice. An RFC that clarifies it as optional would be a fine thing.

Oh look, we have an RFC that says it's optional:

"  Jumbograms are relevant only to IPv6 nodes that may be attached to
   links with a link MTU greater than 65,575 octets, and need not be
   implemented or understood by IPv6 nodes that do not support
   attachment to links with such large MTUs."

That's RFC2675. We're fine as we are.

If the Transport area wants to make a policy that transport protocols do not need to support jumbograms, that's fine too.

Regards
     Brian

---

From: "Dale W. Carder" <[email-masked]>
Date: Wed, 8 May 2019 22:15:47 -0500

> Are there any current network interfaces that can support packets larger than 65,535 octets?   As I remember, it was intended for network interfaces like hyperchannel that could support packets lar…

RFC4755 points out that infiniband's connected mode can do 2^31.  (IIRC,
the "fragmentation" is done at a lower hardware layer)

If not causing active harm, I would think deprecating IPv6 jumbograms would 
be quite premature.

Dale

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 9 May 2019 16:00:09 +1200

> the "fragmentation" is done at a lower hardware layer)

Right, after HIPPI came Infiniband and Fibre Channel, and there was supposed to be SCI (scalable coherent interconnect), but I believe that was a market failure. The point is that the HPC community is interested in jumbo transfers within one building or one rack.

> If not causing active harm, I would think deprecating IPv6 jumbograms would 

Agreed, but evidence of actual deployment and usage seems to be very hard to find. As noted earlier, there certainly seems to be no reason that general-purpose transport protocols would need to consider jumbograms.

    Brian

---

From: Mark Smith <[email-masked]>
Date: Thu, 9 May 2019 15:01:59 +1000

> Agreed, but evidence of actual deployment and usage seems to be very hard to find. As noted earlier, there certainly seems to be no reason that general-purpose transport protocols would need to con…

I wonder if it could be useful for inter-VM or inter-container
communication via an emulated NIC that supports an MTU > 64K.

Regards,
Mark.

---

From: Tom Jones <[email-masked]>
Date: Thu, 9 May 2019 06:29:23 +0000

> Is there any other solution?

I came to this from as an operating system maintainer, removing
Jumbograms is a one time ~350 line diff and it saves us maintaining
complexity in our v6 stack. 

Preparing this draft it is clear to me that Jumbograms are being carried
forward in the RFC series 'just because'. Most of the time they are an
off hand mention, in some cases there are changes to protocol formats to
handle the protocol. 

This seems like a lot of work for a protocol with no known deployments
on the Internet. 

- Tom

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 9 May 2019 08:31:19 +0200

Le 09/05/2019 à 06:00, Brian E Carpenter a écrit :
>>>>> We have put this together to change the status of RFC2675 to
>>>>> Historic and would like to request discussion in the working
>>>>> group.
>>>> 
>>>> IPv6 jumbograms was intended for some super computer inter
>>>> connect with a massive MTU. I don't know of any use of it, but
>>>> is it harmful if the specification is left there in place?
>>>> 
>>> 
>>> larger than 65,535 octets?   As I remember, it was intended for
>>> network interfaces like hyperchannel that could support packets
>>> larger than 65,535.    Did we every define an IPv6 over
>>> Hyperchannel specification?
>> 
>> RFC4755 points out that infiniband's connected mode can do 2^31.
>> (IIRC, the "fragmentation" is done at a lower hardware layer)
> 
> Right, after HIPPI came Infiniband and Fibre Channel, and there was
> supposed to be SCI (scalable coherent interconnect), but I believe
> that was a market failure. The point is that the HPC community is
> interested in jumbo transfers within one building or one rack.
> 
>> If not causing active harm, I would think deprecating IPv6
>> jumbograms would be quite premature.
> 
> Agreed, but evidence of actual deployment and usage seems to be very
> hard to find.

I could try to ping -s our CERN or Lyon interconnect, if my contact 
provides an address.

Alex

  As noted earlier, there certainly seems to be no reason
> that general-purpose transport protocols would need to consider
> jumbograms.
> 
> Brian
> 
> IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Tom Jones <[email-masked]>
Date: Thu, 9 May 2019 06:36:02 +0000

> I think that it's worth mentioning it that in the draft.

Ah, I will raise my hand and admit I hadn't seen large MTU support in
FreeBSDs loopback interface.

I have a diff for FreeBSD that removes Jumbogram support:
https://reviews.freebsd.org/D19960

As far as I can tell Jumbogram support is always built into the kernel,
interface support is probably not. 

I think more telling is the text at the bottom of that section:

	"TCP/UDP over jumbogram is not supported at this moment. This is because
	we have no medium (other than loopback) to test this. Contact us if you
	need this.

	IPsec does not work on jumbograms. This is due to some specification
	twists in supporting AH with jumbograms (AH header size influences
	payload length, and this makes it real hard to authenticate inbound
	packet with jumbo payload option as well as AH).

	There are fundamental issues in *BSD support for jumbograms. We would
	like to address those, but we need more time to finalize these. To name
	a few:

	mbuf pkthdr.len field is typed as "int" in 4.4BSD, so it will not hold
	jumbogram with len > 2G on 32bit architecture CPUs. If we would like to
	support jumbogram properly, the field must be expanded to hold 4G + IPv6
	header + link-layer header. Therefore, it must be expanded to at least
	int64_t (u_int32_t is NOT enough).

	We mistakingly use "int" to hold packet length in many places. We need
	to convert them into larger integral type. It needs a great care, as we
	may experience overflow during packet length computation.

	We mistakingly check for ip6_plen field of IPv6 header for packet
	payload length in various places. We should be checking mbuf pkthdr.len
	instead. ip6_input() will perform sanity check on jumbo payload option
	on input, and we can safely use mbuf pkthdr.len afterwards.

	TCP code needs a careful update in bunch of places, of course."

I am not sure how accurate these comments still are. It is not a great
story for Jumbogram support. If we cannot do TCP, UDP or IPSEC there is
a lot of work to do to make support more than a tick in a box.

- Tom

---

From: Ole Troan <[email-masked]>
Date: Thu, 9 May 2019 09:56:21 +0200

> a lot of work to do to make support more than a tick in a box.

I don't think these are conflicting goals.
You can remove Jumbo support from implementations, while still leaving RFC2675 as is.

If and when Jumbos see usage, your guess is as good as mine if those implementations would need the transport layers as we know them, and certainly if they would reuse the implementations in common OSs.

Best regards,
Ole

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 9 May 2019 15:39:41 +0200

> interested in jumbo transfers within one building or one rack.

I wonder whether the maximum value of the MTU on Tera-bit Ethernet may 
exceed that of others.

Alex

> hard to find. As noted earlier, there certainly seems to be no reason

---

From: "Dale W. Carder" <[email-masked]>
Date: Thu, 9 May 2019 15:08:35 -0500

Thus spake Brian E Carpenter ([email-masked]) on Thu, May 09, 2019 at 04:00:09PM +1200:
> Agreed, but evidence of actual deployment and usage seems to be very hard to find.

My interpretation of the linux implementation of IPOIB is that it's
currently capped at 64K due to that implementation's IPv4 compatibility.

I also agree that implementation is optional as you pointed from the abstract 
text of RFC2675.

> As noted earlier, there certainly seems to be no reason that general-purpose transport protocols
would need to consider jumbograms. 

Yes, I certainly could agree that we can ease restrictions on the transport 
layer, but I don't think that has to come at the expense of removing the
possibility for new transport protocols that could take advantage of
jumbograms later.

Dale

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 10 May 2019 09:45:12 +1200

On 09-May-19 18:29, Tom Jones wrote:
> forward in the RFC series 'just because'.

Yes, just because the original motivation still remains potentially valid.

But since the RFC itself states that support is optional, and only applies where there is a physical interface capable of supporting in, each stack maintainer may freely choose whether to support it.

> Most of the time they are an

I'd have thought there was also work in not supporting it, too, to send the required ICMP errors in reply to a Jumbo Payload option or IPv6 Payload Length == 0. Even if we obsoleted the option, that would remain necessary.
 
> This seems like a lot of work for a protocol with no known deployments

There is less work involved in leaving the RFC alone than in obsoleting it.

   Brian

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 17 May 2019 19:57:49 -0400

6MAN

Here is my take on jumbograms as I have done extensive research, testing and deployment of Jumbo frames within enterprises as well as super jumbo.

Jumbo = any frame size greater then 1500 = 1501 to 8999
Super Jumbo = any frame sizes greater then 9000 = 9000 to 65535
Jumbograms 16 bit to 32 bit field change 65536 to roughly 4.2Billion bytes

So really the two manor benefits of Jumbo is cpu processing and throughout gains as you in

Sent from my iPhone

> On May 9, 2019, at 5:45 PM, Brian E Carpenter <[email-masked]> wrote:
>

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 17 May 2019 20:51:46 -0400

Sorry accidentally hit send .. 

6MAN

So the two manor benefits of Jumbo is cpu processing and throughout gains as the frame size increases the  IPv4 or IPv6 overhead is reduced thus increasing then bandwidth throughput.  

The basic concept I have used in deployments of Jumbo and Super Jumbo is that the network L3 or L2 port has to have a higher MTU then the hosts to avoid fragmentation which is the killer of network as a for IPv4 and ICMP unreachable is sent Type 3 code 4 if DF bit is set and the hosts have to dynamically adjust the MTU via path mtu discovery as long as fully enabled end to end along network path which we have seen issue with firewalls not passing pmtud.  From a deployment perspective of super jumbo to edge hosts the hosts have been data center servers primarily for Mainframe to Mainframe and storage backup on super jumbo 9100 over a Cisco mpls core which started as 9216 and migrated to 65535 mpls core for future bump of sever to server jumbo to slightly less 200 or so bytes less some round number like 65000 when server and mainframe hosts start supporting super jumbo up to max 65535.

The problem with fragmentation from a network perspective is that that it had to be processed in software and thus leads to increased cpu processing and significant impact as well as not being able to rely on pmtud as pmtud is generally not passed by firewalls you really have to be careful how you deploy jumbo and it rally requires one basic concept and that is that the network mtu must be greater then or equal to host port mtu to avoid fragmentation.  That is key to jumbo deployments.

So another very important concept related to Super jumbo deployment that can be applied to IPv6 jumbograms deployment is that when going from super jumbo to non jumbo endpoints.

Also to use adjust-mss going from jumbo to non jumbo endpoints on the router to avoid fragmentation.

This is a lot to digest.  Let me work on getting this all put together more cleanly.

I can work on providing some input into this draft  learnings from super jumbo deployments that we can apply to jumbograms.

Gyan

Sent from my iPhone

> On May 17, 2019, at 7:57 PM, Gyan Mishra <[email-masked]> wrote:
> 
> 6MAN
>

---

From: Doug Barton <[email-masked]>
Date: Sat, 18 May 2019 18:30:53 -0700

> There is less work involved in leaving the RFC alone than in obsoleting it.

I agree with Brian's reasoning, and wanted to raise one other point that 
I haven't seen mentioned.

In IPv4 world the only way to increase throughput is to send the same <= 
1500 packets faster and faster, because "PMTU is hard." 4821 didn't 
really help in this area, and as the speed of light isn't likely to 
change any time soon, we're pretty much stuck.

We have a little more hope for IPv6 though. My understanding is that by 
and large folks are being smarter about filtering ICMPv6, so "better" 
PMTU support is at least a reasonable goal.

We currently face limitations for massive packets in hardware/silicon, 
but that will get better over time. In some measure on its own, and will 
continue to improve for network gear if the market demands it.

For some time now I've been kicking around the idea in my brain that one 
way we could get more of both content and eyeball networks enthused 
about IPv6 would be to promote widespread support for 9k packets. I was 
doing that on an internal network 10 years ago, and I'd like to hope 
that both the hardware and software have improved since then. There will 
no doubt be some pain involved, but if people are willing to put the 
effort in it will have a large upside.

We may never get to the point where jumbograms are practical, and if we 
do, we may not want to implement them as 2675 describes. But if it's not 
hurting anything now, why put it out to pasture?

Doug

---

From: Tim Chown <[email-masked]>
Date: Mon, 20 May 2019 08:45:16 +0000

On 19 May 2019, at 02:30, Doug Barton <[email-masked]<mailto:[email-masked]>> wrote:

I agree with Brian's reasoning, and wanted to raise one other point that I haven't seen mentioned.

In IPv4 world the only way to increase throughput is to send the same <= 1500 packets faster and faster, because "PMTU is hard." 4821 didn't really help in this area, and as the speed of light isn't likely to change any time soon, we're pretty much stuck.

We have a little more hope for IPv6 though. My understanding is that by and large folks are being smarter about filtering ICMPv6, so "better" PMTU support is at least a reasonable goal.

We currently face limitations for massive packets in hardware/silicon, but that will get better over time. In some measure on its own, and will continue to improve for network gear if the market demands it.

For some time now I've been kicking around the idea in my brain that one way we could get more of both content and eyeball networks enthused about IPv6 would be to promote widespread support for 9k packets. I was doing that on an internal network 10 years ago, and I'd like to hope that both the hardware and software have improved since then. There will no doubt be some pain involved, but if people are willing to put the effort in it will have a large upside.

We may never get to the point where jumbograms are practical, and if we do, we may not want to implement them as 2675 describes. But if it's not hurting anything now, why put it out to pasture?

9K MTU is used pretty widely in R&E networks where large scale data transfers are increasingly routine.  The best example of a community shifting significant data volumes worldwide is probably the WLCG (worldwide Large Hadron Collider computing grid - http://wlcg.web.cern.ch/).  The WLCG is an interesting IPv6 case as they mandated a while ago that all the Tier 1 and 2 distributed storage nodes must be dual-stacked by this year, one reason for which was to support deploying IPv6-only worker CPU clusters which could then draw from those.  How many of their sites use 9K MTU, I don't know.   My colleague at Imperial College London thinks that they do not as yet, despite peaking at 40Gbit/s of data from CERN over IPv6, and recently being upgraded to 100G.  I'll ask further...

Tim

Doug

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

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 20 May 2019 19:41:19 -0400

Dough 

I agree with what you and Brian stated that the IETF standards are future looking and not necessarily now in the present or near term future but further down the road.

As I stated I have written some design documents related to super Jumbo 9000 deployment that if my design guidelines are followed any enterprise or Service Provider can easily go Jumbo from and infrastructure perspective and just as overlay architectures  continue to be mainstream like vxlan evpn and vxlan PBB as examples as is IPv6 dual stack the theory of “as you build out a Super Jumbo infrastructure they will come” apps will come on board clammering for high throughout low cpu processing and latency and from that perspective from a network and host OS perspective we are definitely there now for super Jumbo 9000.  Even now in the mpls core I have deployed many networks to date bumping from 9216 to 65535 for future super jumbo for customers and host OS and NIC to eventually have enough memory bump mtu close to 65535 subtracting out mpls and misc overhead bytes.

The IETF being future minded and forward looking I can definitely see way down the road going from 16 bit to 32 bit field supporting up to 4.2Billion byte MTU is futuristic for even IPv6 but does not mean we throw in the towel and say it will never happen.

Cases and point is most networks would never have thought of going to 9000 super jumbo but with MPLS  or SR-MPLS or SRV6 core with customer edge AS overhead bytes such as IPSEC,  IPv6 next headers options evolution overhead, DMVPN overlay dual stack tunnels over MPLS overhead that will continue to be added and evolving requiring larger packet sizes it is impossible to predict the future but having flexibility and options available from a developer perspective always make sense versus being pigeonholed into a corner with no options or workarounds.

Gyan
 
Sent from my iPhone

> On May 20, 2019, at 4:45 AM, Tim Chown <[email-masked]> wrote:
> 
>> On 19 May 2019, at 02:30, Doug Barton <[email-masked]> wrote:
>> 
>>> I'd have thought there was also work in not supporting it, too, to send the required ICMP errors in reply to a Jumbo Payload option or IPv6 Payload Length == 0. Even if we obsoleted the option, that would remain necessary..
>>>

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 21 May 2019 12:31:51 +0000

Gyan Mishra wrote on 20/05/2019 23:41:
> now in the mpls core I have deployed many networks to date bumping from 
> 9216 to 65535 for future super jumbo for customers and host OS and NIC 
> to eventually have enough memory bump mtu close to 65535 subtracting out 
> mpls and misc overhead bytes.

Not much networking kit supports MTU > 11k.

Nick

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 22 May 2019 08:47:17 +1200

> Not much networking kit supports MTU > 11k.

Jumbograms were specifically designed on that assumption, hence the restriction to interfaces capable of supporting >64K MTUs and the entirely optional nature of the whole thing.

Again, I don't see any reason to change the content or status of the RFC.

    Brian

---

From: Erik Kline <[email-masked]>
Date: Tue, 21 May 2019 13:51:29 -0700

On Tue, 21 May 2019 at 13:47, Brian E Carpenter <[email-masked]>
wrote:

> Jumbograms were specifically designed on that assumption, hence the
> restriction to interfaces capable of supporting >64K MTUs and the entirely
> optional nature of the whole thing.
>

Agreed.

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 23 May 2019 01:48:29 -0400

I agree with the draft making 2675 historic that we will never reach the
need to expand the payload length field from 16bit to 32 bit. We could
always revisit in the future but very doubtful it would ever happen.

Sorry my comment on usage of 65535 MTU was wrong.

I have deployed 9216 within the core and 9100 to the CE infrastructure
edges  giving 116 bytes of overhead for MPLS and Misc overhead bytes for
customer traffic to use 9100 Super Jumbo as necessary for apps requiring
high throughput.  We have never used any MTU beyond 9216 and to date I
don't think and Router or host OS vendor supports.

Gyan

On Tue, May 21, 2019 at 4:51 PM Erik Kline <[email-masked]> wrote:

>
>
> On Tue, 21 May 2019 at 13:47, Brian E Carpenter <
> [email-masked]> wrote:
>

-- 
Gyan S. Mishra
IT Network Engineering & Technology Consultant
Routing & Switching / Service Provider MPLS & IPv6 Expert
www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT
Mobile – 202-734-1000