Hi Lizhong, thanks for your comments! On Tue, Feb 11, 2014 at 6:07 PM, Lizhong Jin <lizho....@gmail.com> wrote: > 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?
- 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 > Regards > Lizhong > >> -----Original Message----- >> From: Tom Herbert [mailto:therb...@google.com] >> Sent: 2014年2月12日 0:03 >> To: nvo3@ietf.org >> 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). >> >> 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: <internet-dra...@ietf.org> >> Date: Fri, Dec 20, 2013 at 9:20 AM >> Subject: New Version Notification for draft-herbert-gue-00.txt >> To: Tom Herbert <therb...@google.com> >> >> >> >> 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 >> > > _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3
