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

From: Tom Herbert <[email-masked]>
Date: Tue, 11 Feb 2014 08:02:54 -0800

Hello,

I didn't originally forward this to the nv03 draft, but it was
suggested I do. This is a proposal for generic UDP encapsulation (not
specifically for virtualization, but that could be a use case).

Major differences between this and vxlan, nvgre are:

1) Primarily intended to be extensible. This includes reserving a
couple of flags for private use.
2) Header length field to allow middle boxes or devices to skip over
unknown options to find next header.
3) Encapsulates by IP protocol. In particular, we need a clean way to
encapsulate ESP or private security protocol within a data center
(with or without network virtualization).

Thanks,
Tom

---------- Forwarded message ----------
From:  <[email-masked]>
Date: Fri, Dec 20, 2013 at 9:20 AM
Subject: New Version Notification for draft-herbert-gue-00.txt
To: Tom Herbert <[email-masked]>

A new version of I-D, draft-herbert-gue-00.txt
has been successfully submitted by Tom Herbert and posted to the
IETF repository.

Filename:        draft-herbert-gue
Revision:        00
Title:           Generic UDP Encapsulation
Creation date:   2013-12-20
Group:           Individual Submission
Number of pages: 16
URL:             http://www.ietf.org/internet-drafts/draft-herbert-gue-00.txt
Status:          http://datatracker.ietf.org/doc/draft-herbert-gue
Htmlized:        http://tools.ietf.org/html/draft-herbert-gue-00

Abstract:
   This specification describes Generic UDP Encapsulation (GUE), which
   is a scheme for using UDP to encapsulate packets of arbitrary IP
   protocols for transport across layer 3 networks. By encapsulating
   packets in UDP, specialized capabilities in networking hardware for
   efficient handling of UDP packets can be leveraged. GUE specifies
   basic encapsulation methods upon which higher level constructs, such
   tunnels and overlay networks, can be constructed.

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

---

From: "Lizhong Jin" <[email-masked]>
Date: Wed, 12 Feb 2014 10:07:40 +0800

Hi Tom
I reviewed your GUE draft, and it is an interesting draft. Several comments:
1. Section 2.2. 'Protocol' is 8 bits (http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml). Why not use the EtherType which is 16 bits? Or have both to make it general? E.g, have a flag to indicate it is IP protocol number or EtherType.
2. Section 2.2. 'P' Private flag. Why we need two 'P' flags?
3. Section 3.1. How to process TTL of IP header? E.g, in non-virtualization environment, will you copy the TTL from Encapsulated packet to IP header? Some applications, like trace, may require that.
4. Section 3.6. MTU and fragmentation issues. It is suggested to not allow fragmentation at this tunnel level. Same principle is also defined by VxLAN.
5. Section 5. Motivation for GUE. Suggest to also comparing with http://www.ietf.org/id/draft-quinn-vxlan-gpe-00.txt. From my view, the main benefit of GUE is allowing to have private options.

Regards
Lizhong

> -----Original Message-----
> From: Tom Herbert [mailto:[email-masked]]
> Sent: 2014年2月12日 0:03
> To: [email-masked]
> Subject: [nvo3] Fwd: New Version Notification for draft-herbert-gue-00.txt
> 
> Hello,
> 
> I didn't originally forward this to the nv03 draft, but it was suggested I do. This
> is a proposal for generic UDP encapsulation (not specifically for virtualization,
> but that could be a use case).
> 
> 1) Primarily intended to be extensible. This includes reserving a couple of
> flags for private use.
> 2) Header length field to allow middle boxes or devices to skip over unknown
> options to find next header.
> encapsulate ESP or private security protocol within a data center (with or
> without network virtualization).
> 
> Thanks,
> Tom
> 
> 
> A new version of I-D, draft-herbert-gue-00.txt has been successfully
> submitted by Tom Herbert and posted to the IETF repository.
>

---

From: Tom Herbert <[email-masked]>
Date: Wed, 12 Feb 2014 09:37:58 -0800

Hi Lizhong, thanks for your comments!

On Tue, Feb 11, 2014 at 6:07 PM, Lizhong Jin <[email-masked]> wrote:
> 1. Section 2.2. 'Protocol' is 8 bits (http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml). Why not use the EtherType which is 16 bits?

- As I mentioned in the draft, using Internet protocol number covers
L4 (as well as many L3 and L2 protocols). This allows encap of ESP,
SCTP, IPIP etc. EtherType doesn't allow L4.
- IP protocol covers most of the common encapsulation cases: IP, IPv6,
Ethernet, and various L4 protocols. It also allows GRE which can be
used to encapsulate an arbitrary EtherType at cost of additional 4
bytes.
- With the above point, the additional 8 bits for EtherType in the
header seems costly for its benefit to me.
- GUE is modeled after IP extension headers which already carry IP
protocol. In fact, if we separate out the non-UDP part then it could
be defined as an extension header. This becomes a generic header to
carry arbitrary flags and options in a packet.
- Processing an encapsulated IP protocol within an IP packet is more
efficient than an Ethertype. Following the header extension model,
this is just a recursive entry into IP processing. Protocol lookup is
simpler, a 256 entry lookup table is feasible in most implementations,
but 64K table for Ethertypes is less pleasant.
- Several IP protocols have already assigned ports for foo/UDP. ESP,
GRE/UDP proposals for example. Instead of continuing on this trend,
GUE covers all the protocols in one port allocation.

> Or have both to make it general? E.g, have a flag to indicate it is IP protocol number or EtherType.

That could be done, but I think it would be a different type as
opposed to a flag as it would be a different header format.

> 2. Section 2.2. 'P' Private flag. Why we need two 'P' flags?

It's mostly arbitrary. Private fields are valuable to allow data
center operators to define their own packet fields and to experiment
with new ones. I could imagine a use case where one private fields is
used for the "standard" fields, and the second is used for
"experiments".

> 3. Section 3.1. How to process TTL of IP header? E.g, in non-virtualization environment, will you copy the TTL from Encapsulated packet to IP header? Some applications, like trace, may require that.

GUE should not affect the semantics of IP in IP encapsulation for
things like TTL, so whatever is done for IPIP, SIT, IP/GRE, etc.
should continue to work.

> 4. Section 3.6. MTU and fragmentation issues. It is suggested to not allow fragmentation at this tunnel level. Same principle is also defined by VxLAN.

Packets should be be fragmented before tunnel if possible.

> 5. Section 5. Motivation for GUE. Suggest to also comparing with http://www.ietf.org/id/draft-quinn-vxlan-gpe-00.txt. From my view, the main benefit of GUE is allowing to have private options.
It's more than just private options, it's that GUE is *extensible*.
Protocols like vxlan, gre, and GUE are potentially primary protocols
with the data center, as such I believe a key requirement is that the
data center operator be able to adapt the protocol to changing needs
and threats. AFAICT neither vxlan nor nvgre allow for new fields, and
even if they did, without an obvious header length field, things like
middlebox deep inspection break when new options appear (this is what
makes it virtually impossible to add a new field to GRE for instance).

Thanks,
Tom