On 6/25/2013 10:22 AM, Carlos Pignataro (cpignata) wrote:
Joe,
On Jun 25, 2013, at 12:50 PM, "Joe Touch" <[email protected]> wrote:
On 6/25/2013 7:04 AM, Linda Dunbar wrote:
Ron,
Your draft recommends that the ingress node discards the frame and
sends ICMP msg to the source node when the size of GRE encapsulated
frame exceeds link MTU.
We experienced that Window XP doesn't adjust frame size after
receiving ICMP message. Many Linux based applications don't do anything
either with the MTU ICMP message. I think your draft should point those
issues out and recommend fragmentation approach under those circumstances.
Do these apps set DF=1? If so, they ought to be prepared to handle ICMP PTB
messages. If not, they shouldn't be setting PTB.
However, my view remains that PTB is for when a link cannot handle a packet -
not when it chooses not to do so electively. The only packet that ought to be
too big for GRE is one that exceeds the max payload of IP after encapsulation.
Others ought to be fragmented at the GRE ingress and reassembled at the GRE
egress at the outer IP layer, exactly because IP *can* do this.
If a physical link has an MTU of 1500, can you configure it and set it to be
1300, despite the hardware being able to do 1500?
Are you suggesting that a GRE tunnel has a Tunnel MTU of 65535 - encap always?
A GRE tunnel, IMO, has the MTU of whatever its outer encapsulation is.
I.e., GRE over IP with no options has an MTU of 65535-40-{gre_size}.
Beyond that it *cannot* reassemble.
Joe
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
