Re: [Int-area] 答复: Is the UDP destination port number resource running out?// re: I-D Action: draft-ietf-intarea-gue-04.txt

[Tom Herbert <[e-mail]>]

On Fri, May 19, 2017 at 6:39 PM, Xuxiaohu <[e-mail]> wrote:
> Hi Tom,
>
> Thanks for your quick response. Please see my reply inline.
>
>> -----邮件原件-----
>> 发件人: Tom Herbert [mailto:[e-mail]]
>> 发送时间: 2017年5月19日 22:57
>> 收件人: Xuxiaohu
>> 抄送: [e-mail]
>> 主题: 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 <[e-mail]> 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