Hi Tom, > -----邮件原件----- > 发件人: Tom Herbert [mailto:t...@herbertland.com] > 发送时间: 2017年5月20日 23:46 > 收件人: Xuxiaohu > 抄送: int-area@ietf.org > 主题: Re: 答复: [Int-area] Is the UDP destination port number resource running > out?// re: I-D Action: draft-ietf-intarea-gue-04.txt > > On Fri, May 19, 2017 at 6:39 PM, Xuxiaohu <xuxia...@huawei.com> wrote: > > Hi Tom, > > > > Thanks for your quick response. Please see my reply inline. > > > >> -----邮件原件----- > >> 发件人: Tom Herbert [mailto:t...@herbertland.com] > >> 发送时间: 2017年5月19日 22:57 > >> 收件人: Xuxiaohu > >> 抄送: int-area@ietf.org > >> 主题: 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 <xuxia...@huawei.com> > 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.
There had been a Foo-over-UDP draft (see https://tools.ietf.org/html/draft-yong-tsvwg-udp-encap-4-ip-tunneling-01). However, the reality is that different Foo's are specified in dedicated drafts since many foo-specific considerations need to be specified. > > > > 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. Could you explain how to support the encapsulation of Ethernet without the 4-octect overhead? By the way, why Ethernet is the only other candidate since GUE is claimed to be generic? > > > >> > 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. If GRE-in-UDP is not enough, what about GENEVE? (cced to NVO3) Best regards, Xiaohu > Tom _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
