Subject: Re: [nvo3] Fwd: New Version Notification for draft-herbert-gue-fragmentation-00.txt

From: Joe Touch <[email-masked]>
Date: Wed, 01 Apr 2015 12:55:04 -0700

On 3/25/2015 9:58 PM, Tom Herbert wrote:
> This draft describes a fragmentation option for GUE. The option is
> intended for use cases where GUE is used over a network where we might
> not be able to control or know what the link MTUs in a tunnel are.
> This also provides a answer to the interesting degenerative case where
> someone configures an MTU of 1280 on the link and there is an attempt
> to encapsulate an IPv6 packet of size 1280-- in this case the packet
> size + encapsulation > link MTU & we cannot send a ICMP PTB since 1280
> is specified minimum MTU for IPv6.
> 
> This describes only the mechanics of fragmentation/reassembly in GUE.
> It does cover the the semantics of use such as how to determine tunnel
> Path MTU, when to fragment.

FWIW, there are a few issues that should be addressed. RFC4459 suggests
a taxonomy, but it's informational (and IMO incorrect) on a few points.

Below are suggestions.

Joe

---

Section 1, also Sec 3.1:

There are two separate trigger points for MTU handling:

	A- the tunnel path MTU
		this is defined by the protocols over
		which the tunnel is defined to operate

	B- the tunnel egress reassembly maximum
		this is specified by the tunnel protocol
		description

The following cases should be handled as follows:

	1. encaps packet <= A
		send as-is

	2. A < encaps packet <= B
		fragment and reassemble

	3. encaps packet >B
		drop and send PTB

If you don't want to ever do frag/reassembly, then make sure A=B.

Note that A cannot match B whenever a tunnel mechanism is used
"recursively", e.g., GUE over GUE, even indirectly (GUE over IP over GUE).

---

The wrap of the IPv4 frag field and the impact of avoiding fragmentation
is described in RFC 6864.

---

---

From: Tom Herbert <[email-masked]>
Date: Fri, 3 Apr 2015 11:35:31 -0700

>         2. A < encaps packet <= B

Thanks, Joe. We can probably add some general guidelines like this to
the draft. I think #3 is provided for when the link MTU of tunnel <=
B.

> "recursively", e.g., GUE over GUE, even indirectly (GUE over IP over GUE).

Each tunneling layer should have its own concept of both link MTU and
path MTU for the tunnel. So the link MTU in an inner tunnel could
define the path MTU in an outer tunnel.

> is described in RFC 6864.
Will add a reference to that RFC.

Thanks,
Tom

---

From: Joe Touch <[email-masked]>
Date: Fri, 03 Apr 2015 11:44:21 -0700

Hi, Tom,

Notes interspersed below.

Joe

> the draft. I think #3 is provided for when the link MTU of tunnel <=

B is the tunnel reassembly MTU, as defined above.

The MTU of the individual links of the tunnel is a constraint only if
the egress cannot do reassembly. In that case, B = A.

> define the path MTU in an outer tunnel.

It is the reassembly MTU of the tunnel that defines the tunnel's MTU as
viewed from the outside.

The links within the tunnel define the tunnel's path MTU, but that's
only relevant to the view of the tunnel from the outside when there is
no reassembly.

E.g.: consider ATM (any link layer is essentially a tunnel, FWIW).

For ATM, the link MTU is 48 bytes of payload, but the path MTU is 9K
because the ingress and egress support AAL-5.