Subject: [Int-area] Why combine IP-in-UDP with GUE?

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 27 Apr 2015 16:41:56 +0000

In case anyone is wondering why I have suggested combining IP-in-UDP with
GUE, there may be some uses where only some packets in a flow need to
include the GUE header whereas the vast majority of packets could go as
IPv4 or IPv6 raw encapsulation. So, having everything together under the
same UDP port number could be advantageous. At least that's what I did
in AERO.

Thanks - Fred
[email-masked]

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 27 Apr 2015 16:48:39 +0000

I will also say that I currently have running code with both IPv4 and IPv6 packets
going over the same IP-in-UDP tunnel and using the same UDP port number
and it works fine - just look at the 4-bit "version" number encoded immediately
following the UDP header. I can demonstrate this at IETF93 if anyone wants
to see it.

Thanks - Fred

> -----Original Message-----
> From: Int-area [mailto:[email-masked]] On Behalf Of Templin, Fred L
> Sent: Monday, April 27, 2015 9:42 AM
> To: Brian Haberman; [email-masked]
> Subject: [Int-area] Why combine IP-in-UDP with GUE?
> 
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: Tom Herbert <[email-masked]>
Date: Mon, 27 Apr 2015 10:09:38 -0700

> same UDP port number could be advantageous. At least that's what I did
What exactly would be the advantages of this?

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 27 Apr 2015 17:18:45 +0000

> From: Tom Herbert [mailto:[email-masked]]
> Sent: Monday, April 27, 2015 10:10 AM
> To: Templin, Fred L
> Cc: Brian Haberman; [email-masked]
> Subject: Re: [Int-area] Why combine IP-in-UDP with GUE?
> 

For one thing, it allows a natural separation of control plane and data plane
(data plane as native IP-in-UDP; control plane as GUE). For another, it takes
care of fragmentation using GUE encapsulation while unfragmented packets
can go as native.

This all comes at a savings of 4bytes per packet, which is debatable as to
whether it is worth the trouble. But, if you think the overhead savings
is insubstantial, I think you would probably not be in favor of IP-in-UDP
native format whether/not it were bundled with GUE, right?

Thanks - Fred

---

From: Tom Herbert <[email-masked]>
Date: Mon, 27 Apr 2015 13:53:00 -0700

On Mon, Apr 27, 2015 at 10:18 AM, Templin, Fred L <[email-masked]
> wrote:

> It's just that I don't see much benefit in these approaches other than the
four bytes savings. IMO, the main drawback of directly encapsulating IP in
UDP is that it instantly becomes a feature frozen in time. We can never
improve upon it or extend it-- we can't change IP fragmentation, we can't
add a header checksum to get to circumvent the unpleasantness of using the
UDP zero checksum with IPv6, we can't add security, etc.

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 27 Apr 2015 21:04:06 +0000

Hi Tom,

Fair enough. Just so I am not mis-interpreted, AERO is really agnostic when
it comes to the encapsulation type. It can use its own encapsulation type,
or it can use GUE, or it can use native IP-in-UDP, or it can use a minimal
encapsulation like GRE, IP-in-IP, etc.

The facilities you cited below (fragmentation, security etc.) are a good reason
to go with something like GUE. And, I agree the main advantage of IP-in-UDP
(perhaps the only advantage?) is the 4 bytes per packet savings.

Thanks – Fred

From: Tom Herbert [mailto:[email-masked]]
Sent: Monday, April 27, 2015 1:53 PM
To: Templin, Fred L
Cc: Brian Haberman; [email-masked]
Subject: Re: [Int-area] Why combine IP-in-UDP with GUE?

On Mon, Apr 27, 2015 at 10:18 AM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:

> From: Tom Herbert [mailto:[email-masked]<mailto:[email-masked]>]
> Cc: Brian Haberman; [email-masked]<mailto:[email-masked]>
> <[email-masked]<mailto:[email-masked]>> wrote:

It's just that I don't see much benefit in these approaches other than the four bytes savings. IMO, the main drawback of directly encapsulating IP in UDP is that it instantly becomes a feature frozen in time. We can never improve upon it or extend it-- we can't change IP fragmentation, we can't add a header checksum to get to circumvent the unpleasantness of using the UDP zero checksum with IPv6, we can't add security, etc.

Thanks - Fred
[email-masked]<mailto:[email-masked]>

> > Thanks - Fred
> > [email-masked]<mailto:[email-masked]>
> >
> > [email-masked]<mailto:[email-masked]>

---

From: Joe Touch <[email-masked]>
Date: Mon, 27 Apr 2015 15:04:05 -0700

Hi, Tom (et al.),

On 4/27/2015 1:53 PM, Tom Herbert wrote:
> It's just that I don't see much benefit in these approaches other than
> the four bytes savings. IMO, the main drawback of directly encapsulating
> IP in UDP is that it instantly becomes a feature frozen in time. We can
> never improve upon it or extend it-- we can't change IP fragmentation,
> we can't add a header checksum to get to circumvent the unpleasantness
> of using the UDP zero checksum with IPv6, we can't add security, etc.

Right - this is one of my concerns with the current draft for IP-in-UDP.

We know of at least four things that tunnels need that IP-in-UDP ignores:

	- stronger checksums

	- fragmentation support
	
	- signalling support (e.g., to test whether a tunnel is up or
	to measure MTUs)

	- support for robust ID fields (related to fragmentation,
	e.g., to overcome the limits of IPv4 ID as per RFC 6864)

That minimally argues for an intermediate header, which at that point
needs to have a version number too. That would then require at least
(IMO) 64 bits up front:

	1 bit - version (0)
	
	1 bit - type (0 = UDP packet, 1 = signal)

	1 bit - more fragments flag (0 for last one)

	13 bits - frag offset (in 8-byte blocks, like IPv4 and IPv6)
	
	16-bit - stronger checksum of the whole packet, e.g., CRC-16
		(I'd rather CRC-32, but CRC-16 might be sufficient)

	32 bits - ID field
		(if fragmented or keep as 0 if not used
		to avoid variable processing)

Note: this is a little like what SEAL attempts, but:
	- it ignores the outer IP ID, which might be 0 as per
	RFC 6484

	- it adds a required checksum

	- it's not extensible

I don't think this is a horrible idea to add this shim header, but IMO
it's important to add these capabilities to the IP-in-UDP to make it
more than a passing hack.

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 27 Apr 2015 22:14:36 +0000

Hi Joe,

You are right, and Tom's GUE already has all of this as does AERO which
has taken the place of SEAL. But, thanks for remembering about SEAL,
as it was a useful stepping stone in getting to this point.

Thanks - Fred

> From: Int-area [mailto:[email-masked]] On Behalf Of Joe Touch
> Sent: Monday, April 27, 2015 3:04 PM
> To: Tom Herbert
> Cc: [email-masked]

---

From: Joe Touch <[email-masked]>
Date: Mon, 27 Apr 2015 16:08:02 -0700

> as it was a useful stepping stone in getting to this point.

Right, but the question is whether there's use for a lightweight variant
that has ONLY the stuff below.

How different would IP-in-UDP + the stuff below be from AERO or GUE?

Joe

---

From: Tom Herbert <[email-masked]>
Date: Mon, 27 Apr 2015 16:26:06 -0700

> How different would IP-in-UDP + the stuff below be from AERO or GUE?
Without any optional fields or flags, the difference with GUE is an
additional four byte header between the UDP header and the
encapsulated IP header. For IPv4 that header is 0x00040000, and for
IPv6 the header is 0x00290000.

Fragmentation is an optional eight byte field
(draft-herbert-gue-fragmentation-00), and the GUE checksum is an
optional 4 byte field with that contains a UDP-lite like checksum
(value and length of checksum'ed data) (draft-herbert-guecsum-00).

A stronger checksum has not been defined for GUE, it could be but I'd
really like a better sense of the use case. We already get UDP
checksum computation for free (NIC checksum offload), and CRC doesn't
provide for security. DTLS might be better to encourage than CRC.
Also, it would be an interesting question as to whether a stronger
checksum should include a pseudo header.

Tom

---

From: Joe Touch <[email-masked]>
Date: Mon, 27 Apr 2015 16:33:47 -0700

> On Mon, Apr 27, 2015 at 4:08 PM, Joe Touch <[email-masked]> wrote:
...
> IPv6 the header is 0x00290000.

OK, well, then, I have to say that I think that's a lot of space to
waste for information that's already available in the first 4 bits of
the payload.

Does GUE actually treat the contents differently based on the type of
packet *while in transit*? If not, then, IMO, it'd be better to drop
those unnecessary 4 bytes.

> (draft-herbert-gue-fragmentation-00),

That's a bit long, IMO. 6 is more than sufficient, including the MF flag.

> and the GUE checksum is an

Sorry, but "ick". IMO, that's a lot of bytes to waste on a weak
checksum. CRC-16 would be stronger and shorter; CRC-32 would be much
stronger than that.

> provide for security. DTLS might be better to encourage than CRC.

The purpose of the checksum is to protect against reassembly errors
ONLY. IMO, a checksum that can't detect misordering that's half-word
aligned (i.e., the Internet checksum) is a bad choice for that.

> checksum should include a pseudo header.

If the purpose is to protect against reassembly errors, then it wouldn't
need to do that.

Joe

---

From: Tom Herbert <[email-masked]>
Date: Mon, 27 Apr 2015 17:11:29 -0700

> those unnecessary 4 bytes.
They're not unnecessary! GUE defines a protocol header, and my example
was to demonstrate the bare minimum header to just do IP-in-UDP. The
other bits provide the extensibility for fragmentation, checksum,
virtual networking, security, etc. and also the protocol number (GUE
can encapsulate anything that can be expressed as an IP protocol). See
draft-ietf-nvo3-gue-00.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 28 Apr 2015 17:13:22 +0000

Hi Tom,

> Sent: Monday, April 27, 2015 5:11 PM
> To: Joe Touch
> Cc: Templin, Fred L; [email-masked]

This loops back again to whether the first four bits of the payload could
be used such as:

  4 - a native IPv4 packet
  6 - a native IPv6 packet
  X - a GUE-encapsulated packet

I know you mentioned that it would require a re-work of the GUE header,
but it looks like you have some spare bits to play with there, right?

Thanks - Fred

---

From: Joe Touch <[email-masked]>
Date: Tue, 28 Apr 2015 10:29:06 -0700

...
>>>> IPv6 the header is 0x00290000

...
>   X - a GUE-encapsulated packet

It loops back to what the service is.

Encapsulation of IP is a service.

There is no justification for differentiating between encapsulation of
IPv4 and IPv6 at the GUE or IP-in-UDP layer.

Nothing on the path should need to see what kind of IP packet it is. If
it does, it can easily parse the first for bits of the IP-in-UDP or GUE
payload - NOT the UDP payload.

Bits in the UDP payload to differentiate between IPv4 and IPv6 repeat
the many mistakes of the past and should be avoided.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 28 Apr 2015 10:30:37 -0700

...

>>> IPv6 the header is 0x00290000.

These should be the same bit pattern in that case.

...
> can encapsulate anything that can be expressed as an IP protocol). See

But you have still not explained how GUE treats IPv4 and IPv6
differently on-path. If not, then those bits aren't needed in the GUE
header to differentiate between IPv4 and IPv6.

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 28 Apr 2015 17:36:40 +0000

Hi Joe,

> From: Joe Touch [mailto:[email-masked]]
> Sent: Tuesday, April 28, 2015 10:29 AM
> To: Templin, Fred L; Tom Herbert
> Cc: [email-masked]

What I mean to say is "the first four bits immediately following the UDP
header". At least, that is what IP-in-UDP and AERO say. Were you thinking
there would be some other four bits?

Thanks - Fred

---

From: Tom Herbert <[email-masked]>
Date: Tue, 28 Apr 2015 10:38:10 -0700

> These should be the same bit pattern in that case.

There are different IP protocol numbers for encapsulating IPv4 and
IPv6. 0x4 is the IP protocol for IPIP, 0x29 is the number for IPv4
encapsulation. Other encapsulations could be 0x47 for GRE in GUE, 0x89
would be number for MPLS, etc.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 28 Apr 2015 17:44:13 +0000

Hi Tom,

> Sent: Tuesday, April 28, 2015 10:38 AM
> To: Joe Touch

Right, that makes two ways of doing things (same as in AERO). First
way is examine the first 4 bits - second way is examine the IP protocol
number in the GUE header. So, the rule could be "if the first four bits
encode some value other than 4 or 6, examine the IP protocol number
in the GUE header".

Thanks - Fred

---

From: Tom Herbert <[email-masked]>
Date: Tue, 28 Apr 2015 10:46:22 -0700

> but it looks like you have some spare bits to play with there, right?

The IP version number would need to coincide with the first four bits
of the GUE header-- this is a two bit GUE protocol version number, the
control bit, and one bit of the header length which is 5 bits. The
only way I think it could work would be to expand the version field to
four bits and shift the control bit right by two bits. This would
result in loss of two flag bits and I don't see how to make this
forward compatible with the current spec.

Tom

---

From: Joe Touch <[email-masked]>
Date: Tue, 28 Apr 2015 10:56:09 -0700

> there would be some other four bits?

It's more clear if we just say "the first four bits of the IP header" -
wherever the encapsulation puts that header.

If that's the case, there's no issue in interpreting X=4 or X=6. We
can't assign meanings to other values without a standards-track doc.

We CAN put a flag bit/field in a shim header that explains that the
service carries more than just IP, and the flag bit/field indicates
"next protocol=IP" or "next protocol=signal", etc.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 28 Apr 2015 10:59:30 -0700

On 4/28/2015 10:38 AM, Tom Herbert wrote:
> encapsulation.

Again, multiple wrongs don't make a right.

Unless you handle encapsulation differently on-path, there's no reason
to include that information in the header. What we ended up with for
IPv4 next-header is a mess where we will continue to need to assign new
numbers for all new IP-in-IP variants, instead of using the version
field for EXACTLY its designed purpose.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 28 Apr 2015 11:02:14 -0700

On 4/28/2015 10:44 AM, Templin, Fred L wrote:
> Right, that makes two ways of doing things (same as in AERO). 

Which means:

a) you now need to decide what to do when the two things disagree. Do
you check this? is this a vulnerability?

b) you now need to have a rule for what to do when you're not using 4 or
6, e.g.:

> So, the rule could be "if the first four bits

Why two rules?

What you really wanted - and needed - was a field in the GUE or AERO
header that said "this is IP, this is signal, this is MPLS, etc.".

Once you say it's IP, you should leave the rest to IP. The same holds
for EVERY other protocol.

Joe

---

From: Lucy yong <[email-masked]>
Date: Tue, 28 Apr 2015 18:24:00 +0000

Hi Fred,

GUE uses UDP port to indicate GUE encapsulation as UDP payload and GUE has prototype field to indicate the payload type. Making an exception and requiring inspection of first nibble at end points is not a good idea.  

I don't like the combination approach. 

Regards,
Lucy

-----Original Message-----
From: Int-area [mailto:[email-masked]] On Behalf Of Templin, Fred L
Sent: Tuesday, April 28, 2015 12:44 PM
To: Tom Herbert; Joe Touch
Cc: [email-masked]
Subject: Re: [Int-area] Why combine IP-in-UDP with GUE?

Hi Tom,

> >>>> Without any optional fields or flags, the difference with GUE is 
> >>>> an additional four byte header between the UDP header and the 

Right, that makes two ways of doing things (same as in AERO). First way is examine the first 4 bits - second way is examine the IP protocol number in the GUE header. So, the rule could be "if the first four bits encode some value other than 4 or 6, examine the IP protocol number in the GUE header".

Thanks - Fred

> >>> Does GUE actually treat the contents differently based on the type 
> >>> of packet *while in transit*? If not, then, IMO, it'd be better to 
> >>> drop those unnecessary 4 bytes.
> >>>
> >> They're not unnecessary! GUE defines a protocol header, and my 
> >> example was to demonstrate the bare minimum header to just do 
> >> IP-in-UDP. The other bits provide the extensibility for 
> >> fragmentation, checksum, virtual networking, security, etc. and 
> >> also the protocol number (GUE can encapsulate anything that can be 
> >> expressed as an IP protocol). See draft-ietf-nvo3-gue-00.
> >
> > differently on-path. If not, then those bits aren't needed in the 
> > GUE header to differentiate between IPv4 and IPv6.
> >
> > Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 28 Apr 2015 11:29:15 -0700

On 4/28/2015 11:24 AM, Lucy yong wrote:
> Hi Fred,
> 
> GUE uses UDP port to indicate GUE encapsulation as UDP payload and 
> GUE has prototype field to indicate the payload type. Making an
> exception and requiring inspection of first nibble at end points is
> not a good idea.
>

If you examine the first 4-bits of the IP field, you will:

	- work with any IP version in the future
	- no need new GUE codepoints for new IP versions

If you keep duplicate information in the header, you will:

	- need to explain what you do when the two fields
	do not match

	- still need to check the first 4 bits of the IP
	header anyway

	- still need to check some bits in the GUE header

There's no downside to using the existing IP version field here, and
there are many downsides to using a duplicate field.

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 28 Apr 2015 18:41:41 +0000

Hi Lucy,

> Sent: Tuesday, April 28, 2015 11:29 AM
> To: Lucy yong; Templin, Fred L; Tom Herbert
> Cc: [email-masked]

Yes, GUE has an officially assigned UDP port number (same as AERO).
That does not mean that a combined IP-in-UDP and GUE approach
could not use that same (single) port number nor a (pseudo) version
field in the first four bits following the UDP header.

Think of IP-in-UDP as simply GUE with header compression.

Thanks - Fred

---

From: Tom Herbert <[email-masked]>
Date: Tue, 28 Apr 2015 11:49:28 -0700

>         - still need to check the first 4 bits of the IP
We've already been handling these case for more than twenty years in
having two Ethertypes for IPv4 and IPv6. This is not a new issue for
the implementation.

> there are many downsides to using a duplicate field.

Fred's approach is only an optimization that could be applied when
encapsulating an IPv4 or v6 packet without any GUE options and so no
GUE header. When the GUE header is present then the protocol field is
set to indicate what the next protocol is. This is the way any other
multi-protocol encapsulation works (e.g. GRE, ESP, IP extension
headers). If you have a proposal for an alternate encoding that
eliminates the proto field please demonstrate it. The UDP-GUE headers
are below. Proto/ctype is an IP protocol number when C bit is not set.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Source port            |      Destination port         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Length              |          Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0x0|C|   Hlen  |  Proto/ctype  |            Flags            |E|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                       Fields (optional)                       ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Extension flags (optional)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                    Extension fields (optional)                ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                    Private data (optional)                    ~
   |                                                               |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

---

From: Joe Touch <[email-masked]>
Date: Tue, 28 Apr 2015 11:52:45 -0700

> having two Ethertypes for IPv4 and IPv6. This is not a new issue for

The rationale for ethertypes was hardware. That was a bad justification
then (esp. because it was transient, depending on hardware capability at
the time).

Again, let's not make the same mistake again and again and again.

Joe

---

From: Lucy yong <[email-masked]>
Date: Tue, 28 Apr 2015 18:53:30 +0000

-----Original Message-----
From: Joe Touch [mailto:[email-masked]] 
Sent: Tuesday, April 28, 2015 1:29 PM
To: Lucy yong; Templin, Fred L; Tom Herbert
Cc: [email-masked]
Subject: Re: [Int-area] Why combine IP-in-UDP with GUE?

On 4/28/2015 11:24 AM, Lucy yong wrote:
> Hi Fred,
> 
> GUE uses UDP port to indicate GUE encapsulation as UDP payload and GUE 
> has prototype field to indicate the payload type. Making an exception 
> and requiring inspection of first nibble at end points is not a good 
> idea.
>

There's no downside to using the existing IP version field here, and there are many downsides to using a duplicate field.
[Lucy] GUE is designed to encapsulate a payload, not just IP payload. GUE protocol field needs to support IP payload type because the tunnel may require other features such as security, fragmentation, etc.

Lucy

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 28 Apr 2015 11:57:16 -0700

> [Lucy] GUE is designed to encapsulate a payload, not just IP payload.
> GUE protocol field needs to support IP payload type because the
> tunnel may require other features such as security, fragmentation,
> etc.

GUE needs to indicate "IP", to differentiate it from other payload types
(e.g., signalling, MPLS, etc.).

But there's no reason GUE needs to indicate *in its header* that the
payload is specifically "IPv4" or "IPv6".

Joe

---

From: Lucy yong <[email-masked]>
Date: Tue, 28 Apr 2015 19:00:33 +0000

Yes, GUE has an officially assigned UDP port number (same as AERO).
That does not mean that a combined IP-in-UDP and GUE approach could not use that same (single) port number nor a (pseudo) version field in the first four bits following the UDP header.

Think of IP-in-UDP as simply GUE with header compression.
[Lucy] Understand, but somehow don't like this compression. 

Lucy

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 28 Apr 2015 19:02:00 +0000

BTW, this style of encapsulation goes back a long time. I gave up on
SEAL when I started working on AERO(bis) in earnest, but the SEAL
work goes back many years:

https://tools.ietf.org/id/draft-templin-intarea-seal-68.txt

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 28 Apr 2015 19:04:58 +0000

Hi Lucy,

> [Lucy] Understand, but somehow don't like this compression.

They say that "beauty is in the eye of the beholder". But, whether we
like it or not, 4 bytes is 4 bytes.

Thanks - Fred

---

From: Lucy yong <[email-masked]>
Date: Tue, 28 Apr 2015 19:06:19 +0000

Joe,

> GUE protocol field needs to support IP payload type because the tunnel 
> may require other features such as security, fragmentation, etc.

GUE needs to indicate "IP", to differentiate it from other payload types (e.g., signalling, MPLS, etc.).

But there's no reason GUE needs to indicate *in its header* that the payload is specifically "IPv4" or "IPv6".
[Lucy] since GUE aims to encapsulation for a payload, it needs a payload field. You suggest that making exception for IPv4 and IPv6, i.e. using first nibble to determine. I am not sure when the first nibble indicate IPv4, does it mean Fred's compression case or GUE header with IPv4 payload.

Lucy

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 28 Apr 2015 13:14:24 -0700

>> [Lucy] since GUE aims to encapsulation for a payload, it needs a
> payload field. 

If GUE encapsulates only IPv4 and IPv6, it would need no payload type field.

If GUE encapsulates other payloads as well as IPv4 and IPv6, then it
needs a payload type field. However, one type should be "IP".

There is no reason for having the GUE header differentiate between
payload=IPv4 and payload=IPv6. The IP version is addressed by the
version field of the IP header. If GUE encapsulates both type of IP the
same way (and it should), it should NOT differentiate between them in
its (GUE) header.

> You suggest that making exception for IPv4 and IPv6, i.e.
> using first nibble to determine. I am not sure when the first nibble
> indicate IPv4, does it mean Fred's compression case or GUE header with
> IPv4 payload.

In this case, you would want a way to differentiate between the
following UDP payloads:

	- IP payload (IPv4 or IPv6)
	- compressed IPv4 or IPv6 payload
	- GUE payload
		which could have IPv4 or IPv6 inside

If these are the first thing after the UDP header, then the UDP header
is the only way to differentiate - that's what we use destination
transport port numbers for.

However, once you say "it's IP", then the IP payload - whether inside
UDP directly (IP-in-UDP), inside GUE inside UDP, or inside a compression
header inside UDP, then the IP payload ought to indicate what type of IP
it is.

The point is simple:
	
	IP is a protocol that has versions

We should treat it as such, not treat every individual version of IP as
a separate encapsulation.

Joe

---

From: Lucy yong <[email-masked]>
Date: Tue, 28 Apr 2015 21:51:26 +0000

Joe and Fred,

If a packet/payload is IP protocol, it is fine to check the first nibble of it to determine IPv4 or IPv6.

But we don't adopt this encoding into another protocol and identify IP (v4 or v6) from it, i.e., the compression mechanism.

Lucy 

-----Original Message-----
From: Joe Touch [mailto:[email-masked]] 
Sent: Tuesday, April 28, 2015 3:14 PM
To: Lucy yong; Templin, Fred L; Tom Herbert
Cc: [email-masked]
Subject: Re: [Int-area] Why combine IP-in-UDP with GUE?

If GUE encapsulates other payloads as well as IPv4 and IPv6, then it needs a payload type field. However, one type should be "IP".

There is no reason for having the GUE header differentiate between
payload=IPv4 and payload=IPv6. The IP version is addressed by the version field of the IP header. If GUE encapsulates both type of IP the same way (and it should), it should NOT differentiate between them in its (GUE) header.

> indicate IPv4, does it mean Fred's compression case or GUE header with

In this case, you would want a way to differentiate between the following UDP payloads:

If these are the first thing after the UDP header, then the UDP header is the only way to differentiate - that's what we use destination transport port numbers for.

However, once you say "it's IP", then the IP payload - whether inside UDP directly (IP-in-UDP), inside GUE inside UDP, or inside a compression header inside UDP, then the IP payload ought to indicate what type of IP it is.

The point is simple:

We should treat it as such, not treat every individual version of IP as a separate encapsulation.

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 28 Apr 2015 22:15:57 +0000

Hi Lucy,

> From: Lucy yong [mailto:[email-masked]]
> Sent: Tuesday, April 28, 2015 2:51 PM
> To: Joe Touch; Templin, Fred L; Tom Herbert
> Cc: [email-masked]
> Subject: RE: [Int-area] Why combine IP-in-UDP with GUE?
> 
> Joe and Fred,
> 

Then, you miss the opportunity to have the best of both worlds in a single
packaging. Call it GUE or something else, but there is no reason to split it
into two docs and miss out on a useful header compression.

Thanks - Fred

> payload=IPv4 and payload=IPv6. The IP version is addressed by the version field of the IP header. If GUE encapsulates both type of IP
> the same way (and it should), it should NOT differentiate between them in its (GUE) header.
> 
> However, once you say "it's IP", then the IP payload - whether inside UDP directly (IP-in-UDP), inside GUE inside UDP, or inside a
> compression header inside UDP, then the IP payload ought to indicate what type of IP it is.
> 
> The point is simple:
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 28 Apr 2015 22:22:57 +0000

Hi, I will say also that there is something broken about IP-in-UDP without
combining with GUE. If the tunnel needs to fragment, the only option is
to fragment at the IP layer and not the tunnel layer. But then, if the outer
IP layer is IPv4, we are limited by the 16-bit ID field. If the outer IP layer is
IPv6, there are concerns for dropping of IPv6 fragments as has been
reported in v6ops and 6man.

Combining with GUE allows for tunnel fragmentation, which is the correct
layer for fragmentation to take place:

https://datatracker.ietf.org/doc/draft-herbert-gue-fragmentation/

Thanks - Fred

> Sent: Tuesday, April 28, 2015 3:16 PM
> To: Lucy yong; Joe Touch; Tom Herbert
> Cc: [email-masked]
> > If these are the first thing after the UDP header, then the UDP header is the only way to differentiate - that's what we use
> destination

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 29 Apr 2015 08:32:23 +0100

I confess that I have only skimmed this thread, but as far
as I can see no one has mentioned OAM. If we are
designing a general purpose encapsulation there
really needs to be an OAM indicator so that OAM
can fate share with the data that it is monitoring.

I don't think it is a factor in this discussion unless
people think that we will be doing super DPI, but
RFC4928 notes an issue when using the first
nibble of a packet as a type identifier in an IP/MPLS
environment. In a nutshell this says avoid 0 and 1 as
well as 4 and 6.

- Stewart

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 29 Apr 2015 08:19:01 +0000

Hi Stewart,

> From: Int-area [mailto:[email-masked]] On Behalf Of Stewart Bryant
> Sent: Wednesday, April 29, 2015 3:32 PM
> To: [email-masked]
> I confess that I have only skimmed this thread, but as far as I can see no one has
> mentioned OAM. If we are designing a general purpose encapsulation there
> really needs to be an OAM indicator so that OAM can fate share with the data
> that it is monitoring.

IP-in-UDP is just intended to be a poor-man's UDP encapsulation for IP and act as a potential replacement of IP-in-IP and IP-in-GRE in Softwire networks. Here the UDP itself is deemed as a tunneling protocol (see Section 3.1 of RFC6936, https://tools.ietf.org/html/rfc6936#page-10). As for a general purpose UDP-based encapsulation which have taken fragmentation, security, OAM, checksum, congestion control and even metadata etc into account, it could be GUE, GENEVE, VXLAN-GPE...

> I don't think it is a factor in this discussion unless people think that we will be
> doing super DPI, but
> RFC4928 notes an issue when using the first nibble of a packet as a type
> identifier in an IP/MPLS environment. In a nutshell this says avoid 0 and 1 as well

In the IP-in-UDP case, a to-be-allocated destination port value is used to indicate that the UDP tunnel payload is an IP packet.  As for whether the encapsulated IP packet is IPv4 or IPv6, it would be         determined according to the Version field in the IP header of the encapsulated IP packet. Therefore, it seems a bit different from the first nibble issue associated with the MPLS encapsulation.

Best regards,
Xiaohu

> as 4 and 6.

---

From: Lucy yong <[email-masked]>
Date: Wed, 29 Apr 2015 14:31:00 +0000

-----Original Message-----
From: Int-area [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Wednesday, April 29, 2015 2:32 AM
To: [email-masked]
Subject: Re: [Int-area] Why combine IP-in-UDP with GUE?

I confess that I have only skimmed this thread, but as far as I can see no one has mentioned OAM. If we are designing a general purpose encapsulation there really needs to be an OAM indicator so that OAM can fate share with the data that it is monitoring.
[Lucy] GUE header has OAM indicator.

I don't think it is a factor in this discussion unless people think that we will be doing super DPI, but
RFC4928 notes an issue when using the first nibble of a packet as a type identifier in an IP/MPLS environment. In a nutshell this says avoid 0 and 1 as well as 4 and 6.
[Lucy] Thank you to point out this. This is why GUE header SHOULD NOT adopt this first nibble approach. However, if GUE payload is IP, it is OK to inspect the first nibble of the payload to determine IPv4 or IPv6 because this aligns with IP protocol. 

Thanks,
Lucy

- Stewart

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 29 Apr 2015 14:38:19 +0000

Hi Lucy,

> From: Int-area [mailto:[email-masked]] On Behalf Of Lucy yong
> Sent: Wednesday, April 29, 2015 7:31 AM
> To: [email-masked]; [email-masked]
> I confess that I have only skimmed this thread, but as far as I can see no one has mentioned OAM. If we are designing a general
> purpose encapsulation there really needs to be an OAM indicator so that OAM can fate share with the data that it is monitoring.
> [Lucy] Thank you to point out this. This is why GUE header SHOULD NOT adopt this first nibble approach.

I think your comment is out of context. It is saying avoid 0, 1, 4 and 6 so as
to not confuse it with IP. It does not say to avoid other numbers (e.g., 7)
that could be used to identify GUE.

Getting back to our earlier discussion, IP-in-UDP and GUE are currently
two half-solutions. Put them together and you get a whole solution.
Keep them apart, and someone else is going to have to write a whole
solution sometime down the line from now. 

Thanks - Fred

> However, if GUE payload is
> IP, it is OK to inspect the first nibble of the payload to determine IPv4 or IPv6 because this aligns with IP protocol.
> 
> Thanks,
> Lucy
> 
> - Stewart
> 
> 
>

---

From: Lucy yong <[email-masked]>
Date: Wed, 29 Apr 2015 14:48:01 +0000

Getting back to our earlier discussion, IP-in-UDP and GUE are currently two half-solutions. Put them together and you get a whole solution.
Keep them apart, and someone else is going to have to write a whole solution sometime down the line from now. 
[Lucy] GUE can support IP payload. Don't know why you state that they are two half-solutions. Is the compression a mandatory requirement here? I think that IP-in-UDP proposal as a compression version is better that use of first nibble. However we need clarify what limitation and constraint the compression solution has. 

Lucy 

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 29 Apr 2015 14:50:42 +0000

Hi Lucy,

> Sent: Wednesday, April 29, 2015 7:48 AM
> To: Templin, Fred L; [email-masked]; [email-masked]
> [Lucy] GUE can support IP payload. Don't know why you state that they are two half-solutions. Is the compression a mandatory
> requirement here? I think that IP-in-UDP proposal as a compression version is better that use of first nibble. However we need clarify
> what limitation and constraint the compression solution has.

GUE is missing header compression, and IP-in-UDP is missing tunnel
fragmentation. That is what I mean when I say that if combined you
get a whole solution.

Thanks - Fred

---

From: Tom Herbert <[email-masked]>
Date: Wed, 29 Apr 2015 09:00:13 -0700

> fragmentation. That is what I mean when I say that if combined you
Adding this header compression just adds a whole bunch of complexity
to the protocol to save a grand total of four bytes for what is likely
a very narrow use case. This is not applicable when GUE is used for
network virtualization, we are encapsulating something other than IP,
we need OAM, or using any other feature of GUE. In my deployment, I
don't have any use case for that since minimally I will be using
remote checksum offload option because that does give a material
performance advantage.

The premise of GUE is simple, it has a simple header that encapsulates
any IP protocol expressed by IP protocol number and allows optional
extensions and control packets-- let's keep it simple! If saving those
four bytes is really important in some deployment and GUE is still
needed in certain case, then just use GUE and IP-in-UDP in tandem.

Tom

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 29 Apr 2015 11:09:03 -0500

Hi Tom,

On Wed, Apr 29, 2015 at 11:00 AM, Tom Herbert <[email-masked]> wrote:
> a very narrow use case.

>This is not applicable when GUE is used for
> network virtualization,

I don't think GUE is a replacement or even an improvement for VXLAN
encapsulation.

While VXLAN is 1-N type of tunneling, GUE is 1-1.

Regards,

Behcet
> we are encapsulating something other than IP,

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 29 Apr 2015 16:28:31 +0000

Hi Tom,

> Sent: Wednesday, April 29, 2015 9:00 AM
> To: Templin, Fred L
> Cc: Lucy yong; [email-masked]; [email-masked]

The only additional requirement is to check the first nibble of the
UDP-encapsulated payload.

> remote checksum offload option because that does give a material

What you have just done is spelled out specific use cases that
require special-purpose solutions - that is not "generic".

> needed in certain case, then just use GUE and IP-in-UDP in tandem.

That would require two different UDP port numbers as opposed to
checking the first nibble, which there was some earlier discussion
about. If you want to call something "generic", then why not make it
truly generic?

Thanks - Fred

---

From: Tom Herbert <[email-masked]>
Date: Wed, 29 Apr 2015 10:06:15 -0700

> I don't think GUE is a replacement or even an improvement for VXLAN
All the arguments as to why VXLAN is insufficient in multi-tenant
deployments was made in nvo3. Please read those and the GUE drafts
(draft-hy-nvo3-gue-4-nvo-01, draft-ietf-nvo3-gue-00, and
draft-hy-gue-4-secure-transport-01). If you have any comments or
questions take them to the nvo3 list.

> While VXLAN is 1-N type of tunneling, GUE is 1-1.
I don't understand what this means.

---

From: Tom Herbert <[email-masked]>
Date: Wed, 29 Apr 2015 10:12:39 -0700

> about. If you want to call something "generic", then why not make it

It already is generic. Encapsulation of IPv4 and IPv6 is already
implemented and deployed. Including this optimization does not make
the protocol more generic.

Anyway, if you want to proceed with this please provide a specific
proposal on how do to it.

Tom

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 29 Apr 2015 17:20:05 +0000

Hi Tom,

> Sent: Wednesday, April 29, 2015 10:13 AM
> To: Templin, Fred L
> >> >> Getting back to our earlier discussion, IP-in-UDP and GUE are currently two half-solutions. Put them together and you get a
> whole
> >> >> solution.

If it is deployed before the document is published as an RFC, then
the deployed base would have to be updated to match the eventual
RFC anyway.

> proposal on how do to it.

Change the GUE header to treat the first nibble as a next header
selector. 4 means IPv4, 6 means IPv6 and X means GUE.

Thanks - Fred

---

From: Lucy yong <[email-masked]>
Date: Wed, 29 Apr 2015 18:14:59 +0000

Hi Fred,

Change the GUE header to treat the first nibble as a next header selector. 4 means IPv4, 6 means IPv6 and X means GUE.
[Lucy] As I mentioned in several previous mails, I don't think that this is a good design for GUE. Even if a compression is required, the solution SHOULD use a separate UDP port to indicate IP first and then check the first nibble for IPv4 or IPv6, which, in fact, is the IP-in-UDP proposal. 

However I agree with Tom that the compression concept does not align with GUE principal. GUE encapsulation should not assume IP payload in first place!  

Regards,
Lucy

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 29 Apr 2015 18:22:56 +0000

Hi Lucy,

> Sent: Wednesday, April 29, 2015 11:15 AM
> Cc: [email-masked]; [email-masked]
> [Lucy] As I mentioned in several previous mails, I don't think that this is a good design for GUE. Even if a compression is required, the
> solution SHOULD use a separate UDP port to indicate IP first and then check the first nibble for IPv4 or IPv6, which, in fact, is the IP-in-
> UDP proposal.

I will say again that the IP-in-UDP proposal as it stands does not have a solution
for tunnel fragmentation (made available by GUE).

> However I agree with Tom that the compression concept does not align with GUE principal. GUE encapsulation should not assume IP

The proposed solution does not assume IP; it assumes a next header
selector in the first nibble of the data following the UDP header. Non
IP can be conveyed when the next header selector indicates GUE.

Thanks - Fred

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 29 Apr 2015 13:30:15 -0500

On Wed, Apr 29, 2015 at 12:06 PM, Tom Herbert <[email-masked]> wrote:
> (draft-hy-nvo3-gue-4-nvo-01,
> draft-ietf-nvo3-gue-00,

I read this draft, I could not see any such arguments. It just
mentions VXLAN as a reference like other things.

If true, it should explicitly address this issue.
I am not sure if it can say more than what it is that is a generic
encapsulation techniques that can be used in the data center to tunnel
things.

But VXLAN is designed to provide VM-to-VM communication.
So the design criteria is completely different in these two techniques.

> and

The key is in VM-to-VM communication. The other VM could be under any
VTEP or NVE.

Regards,

Behcet

---

From: Tom Herbert <[email-masked]>
Date: Wed, 29 Apr 2015 11:42:33 -0700

> So the design criteria is completely different in these two techniques.
GUE has been adopted by nvo3 network virtualization data plane, along
with Geneve and VXLAN-GPE-- VXLAN has not. Again if you have comments
on that use of GUE please take them to nvo3. This thread is about a
generic modification to GUE without respect to the network
virtualization use case.

---

From: Tom Herbert <[email-masked]>
Date: Wed, 29 Apr 2015 11:44:33 -0700

> selector. 4 means IPv4, 6 means IPv6 and X means GUE.
By "specific" I mean down to the bit what *exactly* will this new
proposed GUE header format be.

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 29 Apr 2015 13:47:54 -0500

> generic modification to GUE without respect to the network

I reacted on this thread because you claimed network virtualization
use case now you are saying it is not about that.

I am fine then :-)

Regards,
Behcet

---

From: Lucy yong <[email-masked]>
Date: Wed, 29 Apr 2015 18:47:46 +0000

> [Lucy] As I mentioned in several previous mails, I don't think that 
> this is a good design for GUE. Even if a compression is required, the 
> solution SHOULD use a separate UDP port to indicate IP first and then check the first nibble for IPv4 or IPv6, which, in fact, is the IP-in- UDP proposal.

I will say again that the IP-in-UDP proposal as it stands does not have a solution for tunnel fragmentation (made available by GUE).
[Lucy] That is true. The IP-in-UDP proposal applies the case where no fragmentation at tunnel end point is needed. GUE can deal with it.

> However I agree with Tom that the compression concept does not align 
> with GUE principal. GUE encapsulation should not assume IP payload in first place!

The proposed solution does not assume IP; it assumes a next header selector in the first nibble of the data following the UDP header. Non IP can be conveyed when the next header selector indicates GUE.
[Lucy] the first nibble is intended for indicating version of IP, not for a next header selector. Forcing other protocol to follow this assumption is bad. Please read RFC4928.  There are many cases that GUE payload is IP or other and GUE header is required. The first nibble design splits majority from a corner case as first logic, which is a bad design. The "compression" version does not have the same tunnel property as GUE based tunnel, we should not mix them at design level.

Lucy

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 29 Apr 2015 19:09:00 +0000

Hi Tom,

> Sent: Wednesday, April 29, 2015 11:45 AM
> To: Templin, Fred L
> >> >> >> requirement here? I think that IP-in-UDP proposal as a compression version is better that use of first nibble. However we
> need
> >> >> clarify

Header field formats don't show up well on email threads; the proposal
is that the most significant four bits of the GUE header are used as a
protocol selector - how the other bits in the GUE header are rearranged
is not for me to decide, but the current GUE design does seem to leave
ample reserved bits to accommodate rearrangement.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 29 Apr 2015 19:16:00 +0000

Hi Lucy,

> Sent: Wednesday, April 29, 2015 11:48 AM

Existing tunnel protocols (IP*-in-IP*) are deficient in not providing a tunnel
fragmentation mechanism per Section 3.1.7 of RFC2764.

> The proposed solution does not assume IP; it assumes a next header selector in the first nibble of the data following the UDP header.
> Non IP can be conveyed when the next header selector indicates GUE.
> [Lucy] the first nibble is intended for indicating version of IP, not for a next header selector. Forcing other protocol to follow this
> assumption is bad. Please read RFC4928.  There are many cases that GUE payload is IP or other and GUE header is required. The first
> nibble design splits majority from a corner case as first logic, which is a bad design. The "compression" version does not have the same
> tunnel property as GUE based tunnel, we should not mix them at design level.

I disagree with "bad", and I do not think RFC4928 is applicable when the first nibble
appears within a UDP encapsulation for which there is a specific user of that UDP
port number. ECMP classifications in the network would not reach deeply into a
UDP encapsulation in order to inspect bits specific to that UDP port.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 29 Apr 2015 21:24:37 +0000

Hi, I have been trying to convince myself how it would work if the
IP-in-UDP and GUE remained as two separate UDP port numbers. I
can certainly open multiple UDP sockets in an application and send
and receive packets over the sockets while considering them to be
"bonded" (i.e., treated as one "tunnel"). However, it would look
like two different flows over the network and one flow might get
different treatment from another. For example, NATs would see
two distinct UDP port numbers and would have to set up a mapping
for both ports. With a unified tunneling system, the network would
would see only one 5-tuple for the tunnel; not two or more.

Also, 4 bytes per packet is not insubstantial when the tunnel is
carried over a pay-per-use service like a cellular operator network.

Thanks - Fred

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 30 Apr 2015 00:47:04 +0000

Hi Templin,

> Change the GUE header to treat the first nibble as a next header selector. 4
> means IPv4, 6 means IPv6 and X means GUE.

I fully understand your intention. However, it depends on whether it's widely acceptable to take GUE as IPvx which in turn could carry IPv4 and IPv6 packets.

Best regards,
Xiaohu

> > >> >> > IP, it is OK to inspect the first nibble of the payload to determine IPv4
> or IPv6 because this aligns with IP protocol.
> > >> >> >
> > >> >> > Thanks,
> > >> >> > Lucy
> > >> >> >
> > >> >> > - Stewart
> > >> >> >
> > >> >> >
> > >> >> >

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 30 Apr 2015 03:01:10 +0000

Hi Templin,

> Sent: Thursday, April 30, 2015 3:16 AM
> To: Lucy yong; Tom Herbert
> Cc: [email-masked]
> > > this is a good design for GUE. Even if a compression is required,
> > > the solution SHOULD use a separate UDP port to indicate IP first and
> > > then check the first nibble for IPv4 or IPv6, which, in fact, is the
> > > IP-
> > in- UDP proposal.
> >
> > [Lucy] That is true. The IP-in-UDP proposal applies the case where no
> > fragmentation at tunnel end point is needed. GUE can deal with it.
> 

You may have noticed a fact that most modern routers and switches have been capable of processing jumbo frames for a long while. In other words, fragmentation could be completed avoided in most modern networks. Even in the sparse network environments where fragmentation is still unavoidable, the default configuration which have been widely supported by most vendors (see https://tools.ietf.org/html/draft-ietf-intarea-gre-mtu-03#page-4) should be enough in most cases. That's the reason why that's implemented by many vendors as the DEFAULT configuration, IMHO. BTW, it's preferable to avoid reassembling fragments at the tunnel egress due to the negative impact on the forwarding performance, AFAIK. As such, it's not recommended to perform fragmentation on the tunnel layer and the outer IP layer.

> > The proposed solution does not assume IP; it assumes a next header selector in
> the first nibble of the data following the UDP header.
> > [Lucy] the first nibble is intended for indicating version of IP, not
> > for a next header selector. Forcing other protocol to follow this
> > assumption is bad. Please read RFC4928.  There are many cases that GUE
> > payload is IP or other and GUE header is required. The first nibble design splits
> majority from a corner case as first logic, which is a bad design. The
> "compression" version does not have the same tunnel property as GUE based
> tunnel, we should not mix them at design level.
> 
> I disagree with "bad", and I do not think RFC4928 is applicable when the first
> nibble appears within a UDP encapsulation for which there is a specific user of
> that UDP port number. ECMP classifications in the network would not reach
> deeply into a UDP encapsulation in order to inspect bits specific to that UDP
> port.

Fully agree with your points that the first nibble issue associated with the MPLS encapsulation is a totally different story.

Best regards,
Xiaohu

> > > > >> >> > However, if GUE payload is IP, it is OK to inspect the
> > > > >> >> > first nibble of the payload to determine IPv4 or IPv6 because this
> aligns with IP protocol.
> > > > >> >> >
> > > > >> >> > Thanks,
> > > > >> >> > Lucy
> > > > >> >> >
> > > > >> >> > - Stewart
> > > > >> >> >
> > > > >> >> >
> > > > >> >> >

---

From: Joe Touch <[email-masked]>
Date: Thu, 30 Apr 2015 07:22:08 -0700

...
> You may have noticed a fact that most modern routers and switches 
> have been capable of processing jumbo frames for a long while. In
> other words, fragmentation could be completed avoided in most modern
> networks. 

Jumbo frames are just a larger maximum frame size. Let's say that size is N.

We're talking about IP-in-IP, IP-in-UDP-in-IP, IP-in-GRE-in-IP, etc. In
all cases, you have:
	
	N inside N+header

Unless the headers are 0 bytes long, the encapsulated result is always
larger than the interior contents.

I.e., if N is your limit, you've now exceeded it. The consequence is that:

	any protocol that has non-zero headers and a packet maximum
	always needs fragmentation to be encapsulated in itself

> Even in the sparse network environments where fragmentation
> is still unavoidable, the default configuration which have been
> widely supported by most vendors (see 
> https://tools.ietf.org/html/draft-ietf-intarea-gre-mtu-03#page-4)
> should be enough in most cases. That's the reason why that's
> implemented by many vendors as the DEFAULT configuration, IMHO. 

It's the default because it maximizes router vendor profit and/or
reduced router vendor cost, not because it maximizes network flexibility
or capability.

> BTW,
> it's preferable to avoid reassembling fragments at the tunnel egress
> due to the negative impact on the forwarding performance, AFAIK. 

It is inherently unavoidable for IPv4 packets with DF=1 or all IPv6 packets.

> As
> such, it's not recommended to perform fragmentation on the tunnel
> layer and the outer IP layer.

It's provably required for IPv4 DF=1 and IPv6.

That's why we're trying to address it.

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 30 Apr 2015 15:13:59 +0000

Hi,

> Sent: Thursday, April 30, 2015 7:22 AM
> To: Xuxiaohu; Templin, Fred L; Lucy yong; Tom Herbert
> Cc: [email-masked]

Joe is right. True that larger MTUs are being deployed especially in the core,
but there are still only two magic numbers: 1280 and 1500. Tunnels that can't
do 1280 can be declared non-operational. Tunnels that can't do 1500 when
there may be PMTUD black holes need fragmentation.

Thanks - Fred

---

From: Tom Herbert <[email-masked]>
Date: Thu, 30 Apr 2015 13:08:54 -0700

> selector. 4 means IPv4, 6 means IPv6 and X means GUE.
Okay, thinking about this some more, I suppose we can actually support
direct IP encapsulation just by defining GUE version 0x1 to be direct
IP encapsulation. eg. 01 indicates IP encapsulation, 0100 0110 are
IPv4 and IPv6. This burns one version number and requires a subtle
change in the GUE draft to make it clear that the GUE version defines
defines everything after it, but it is forward compatible and doesn't
impact real GUE.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 30 Apr 2015 20:37:47 +0000

Hi Tom,

> Sent: Thursday, April 30, 2015 1:09 PM
> To: Templin, Fred L

If you can do this, please sign up AERO as a committed GUE user.

Thanks - Fred