On Fri, May 19, 2017 at 6:39 PM, Xuxiaohu <[email protected]> wrote: > Hi Tom, > > Thanks for your quick response. Please see my reply inline. > >> -----邮件原件----- >> 发件人: Tom Herbert [mailto:[email protected]] >> 发送时间: 2017年5月19日 22:57 >> 收件人: Xuxiaohu >> 抄送: [email protected] >> 主题: Re: [Int-area] Is the UDP destination port number resource running out?// >> re: I-D Action: draft-ietf-intarea-gue-04.txt >> >> Hi Xuxiaohu, >> >> Thanks for the comments. Some response are inline. >> >> On Thu, May 18, 2017 at 7:53 PM, Xuxiaohu <[email protected]> wrote: >> > Hi all, >> > >> > With regard to directly encapsulating IPvx packet in UDP, I think the >> > following >> argument for using Version 1 of GUE is not valid: >> > >> > "This technique saves encapsulation overhead on costly links >> > for the common use of IP encapsulation, and also obviates the need to >> > allocate a separate port number for IP-over-UDP encapsulation." >> > >> > First, I don't think the encapsulation overhead of 4 bytes is a matter. >> >> I'm not sure everyone would agree with that. The case was made when we were >> discussing it that the savings would be beneficial for some deployments. > > If the saving is beneficial, it'd better to assign a dedicated port number > for each UDP payload type( e.g., IP packet), rather than combining the UDP > port number dedicated for GUE and the version field within the GUE header > together to indicate whether the UDP payload is GUE or IP (or even other > payload type if the GUE is devoted to help save the UDP port number resource > for the IETF community:))
Xuxiaohu, We have already implemented the facility to directly encapsulate an IP protocol directly in UDP. This is FOU-over-UDP (FOU) and in fact GRE-in-UDP is just one sub case of the implementation. I know people are using FOU for various protocols in their networks, however I doubt we get very far if we requested 256 ports to directly encapsulate each IP protocol! It might make sense to document FOU as informational. > > BTW, what happens if any other GUE payload has the same desire of saving the > 4 byte GUE header overhead? The only other candidate beyond IPv4 and IPv6 that has been suggested is Ethernet which would be EtherIP. That is pretty feasible to support if there is enough desire. > >> > However, the premise is that it's meaningful for the IETF to develop >> > such a GENERIC and COVERALL encapsulation method which is still >> > looking for nails:) >> >> The protocol is called *Generic* UDP Encapsulation for reason. > > I know that you are trying to specify a generic UDP encapsulation. However, > there has been a generic UDP encapsulation scheme that is GRE-in-UDP > [RFC8086]. Furthermore, there is another generic UDP encapsulation scheme > called GENEVE that the NVO3 group is working on. It's better for the IETF > community to avoid specifying multiple similar encapsulation schemes and > therefore the NVo3 WG co-chairs and the corresponding AD try their best to > reach a consensus of working together on a single encapsulation on the basis > of GENEVE among the WG members. Do you still believe it's helpful for the > industry to specify one additional generic encapsulation scheme in another > IETF WG? > Yes. The reason we needed to define GUE is that no other encapsulation protocol satisfies the requirements. GRE comes close, and in fact GUE is based on GRE. We love GRE for the datacenter. It's generic, extensible, simple, flag-fields are super efficient, and all hardware we tested works well with it. The downside of GRE is that it's extensibility is quite limited; we can only get 12 bytes for fields. That's just not enough. The particular need we had was to add security to authenticate the header. We actually we're able to "find" 64 bits of in the fields by overloading checksum and sequence number, but that is really not enough for security. Besides that, there are other needs for extensibility like fragmentation, checksum, payload transform. We'll only ever need a handful of such extensions, but it's more than can be fit into GRE. So GUE is an answer. It has the same efficiency of GRE but is more extensible. Since it is a new protocol we are able to add a few other nice to have features like header length, encap by IP protocol, and private data block. Section 6 in the draft gives a motivation for GUE. Tom _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
