Hi, Fred,
On 6/25/2013 3:01 PM, Templin, Fred L wrote:
Hi Joe,
-----Original Message-----
From: Joe Touch [mailto:[email protected]]
Sent: Tuesday, June 25, 2013 2:38 PM
To: Templin, Fred L
Cc: Carlos Pignataro (cpignata); Ronald Bonica; Internet Area
Subject: Re: [Int-area] New Version Notification for draft-bonica-
intarea-gre-mtu-00.txt
Hi, Fred,
...
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.
I have a slightly different view, but one that still involves
fragmentation. The GRE tunnel MUST observe the minimum IPv6 MTU
of 1280 bytes.
In what it sends over IP (i.e., in the chunks it uses to transit from
ingress to egress). There's no reason to impose that limit on what it
receives at the ingress.
What I am suggesting is that the tunnel ingress sets an indefinite
MTU, meaning that all packets are admitted into the tunnel regardless
of their size. But, see more below...
But, to uphold the de facto Internet cell size of
1500 bytes we should extend this up to 1500. So, if the MTU within
the tunnel is unknown and/or unknowable, then the ingress MUST use
fragmentation to make sure that packets no larger than 1500 bytes
get through - the egress then gets to reassemble.
This is an artificial limit that is unnecessary.
What I am after is a fragmentation threshold designed to set an
upper bound on the amount the tunnel egress will have to reassemble.
This also happens to be the size of packets that MUST make it through
the tunnel. IPv6 says that this value must be set to 1280 at a minimum.
I am saying that it should be bumped up to 1500 to mirror the minimum
MTU used on the vast majority of links in the Internet today. But, see
more below...
You're introducing an artificial limit based on the assumption that GRE
should never transit more than the minimum, but there's no reason for
that limit; GRE is sourcing packets to the egress, and can easily
generate and reassemble fragments. The rest of the path may impose a
limit - such as based on transiting Ethernet, but there's no reason to
introduce that limit here.
IMO, MTU is just that - "MAXIMUM". Not 'preferred'. So if GRE *can*
transit packets arriving at the ingress that are 65535-IP-GRE, why
should it do otherwise?
What I am saying is that all packets are admitted into the tunnel
regardless of their size, but the tunnel will use fragmentation only
for those packets that MUST make it through to the other side, i.e.,
all packets that are no larger than 1500 bytes.
Why? Why are you introducing that as an artificial constraint for GRE?
This means that the
tunnel egress need only configure a reassembly buffer size of 1500
bytes plus the tunnel overhead. Packets larger than 1500 bytes will
still make it through the tunnel (in one piece) if the MTU within the
tunnel can accommodate that size. But, the most the ingress will ever
ask the egress to reassemble is 1500 (plus overhead).
IP reassembly requires tsupport for max-size IP packets, not just ones
whose sizes you like ;-)
(yes, it *can* be configured lower if desired, just as with any other
link, but there's no reason to assume 'lower than maximum' as a
default)
Packets larger than 1500 can be admitted into the tunnel unfragmented
and allowed to sink or swim on their own.
Whether and how much GRE fragments what it receives at an ingress ought
to be determined by its understanding of its own ingress-egress MTU
capability. However, those fragments are not directly related to what
the tunnel can transit *because* the ingress can fragment and the
egress
can reassemble.
Right. The egress has to reassemble whatever the ingress fragments.
What I am saying is that the ingress put a conservative upper bound
on the amount it will ever ask the egress to reassemble.
If the egress supports IPv6, the upper bound is already 66635. Why are
you introducing a lower constraint when that's already required?
Acting like the ingress and egress can't participate in frag/reassembly
of the outer packet introduces an artificial limit to GRE tunnels. If
that's what you want to do - or what has already been done - that's
fine, but *that* is what is suboptimal.
No, I fully agree that *some* fragmentation and reassembly is
necessary. I'm just saying that the ingress should set a limit
on the most it would ever ask the egress to reassemble. But,
that does *not* put an artificial limit on the tunnel MTU.
But that's what you're doing; you will reject packets larger than 1500
that transit, even though you can reassemble them (and you have to if
you implement IPv6 reassembly anyway).
I understand what you're trying to save, but an IP encapsulation egress
is still required to support IPv6 host-side capabilities, so there's no
savings.
> The ingress may or may not
get ICMP PTBs if one of these is dropped, but the source should be
using RFC4821 when it sends packets larger than 1500 bytes anyway,
so loss of PTBs should not affect the hosts.
Agreed on that point, but not the 1500-byte transit limit.
Please reread the algorithm I proposed, Joe. What I am suggesting
is an "infinite" tunnel ingress MTU - not a 1500 byte MTU.
Thanks - Fred
[email protected]
Joe
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
