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 11:09 PM, Xuxiaohu <[e-mail]> wrote:
>
>
>> -----邮件原件-----
>> 发件人: Joe Touch [mailto:[e-mail]]
>> 发送时间: 2017年5月20日 12:15
>> 收件人: Xuxiaohu; Tom Herbert
>> 抄送: [e-mail]
>> 主题: Re: 答复: [Int-area] 答复: Is the UDP destination port number resource
>> running out?// re: I-D Action: draft-ietf-intarea-gue-04.txt
>>
>>
>>
>> On 5/19/2017 8:57 PM, Xuxiaohu wrote:
>> > Hi Joe,
>> >
>> >> -----邮件原件-----
>> >> 发件人: Joe Touch [mailto:[e-mail]]
>> >> 发送时间: 2017年5月20日 11:41
>> >> 收件人: Xuxiaohu; Tom Herbert
>> >> 抄送: [e-mail]
>> >> 主题: Re: [Int-area] 答复: Is the UDP destination port number resource
>> >> running out?// re: I-D Action: draft-ietf-intarea-gue-04.txt
>> >>
>> >>
>> >>
>> >> On 5/19/2017 6:39 PM, Xuxiaohu wrote:
>> >>> 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:))
>> >> FWIW, IANA strives to assign one port for a service.
>> > Great. Hence IPvx should be taken as a service rather than taking IPvx and
>> GUE as a service, IMO.
>> GUE is supposed to be both signalling and content (data), where the data are IP
>> packets.
>
> Since IANA strives to assign one port for a service, IP packet within the UDP tunnel should be assigned a dedicated port. In other words, GUE and IP-in-UDP are distinguished by the different port numbers.
>
>> Take away the IP part and GUE isn't an E anymore.
>> >> Services are expected to have version fields and subtype
>> >> demultiplexing indicators, to so that all message variants of current
>> >> and future versions can use a single port number.
>> > Sure, the version field within the IPvx packet could be used for demultiplexing
>> purpose.
>>
>> That demultiplexes within IPvx. There still needs to be a way to demultiplex
>> non-IPvx packets (control) from IPvx.
>
> Since GUE and IP-in-UDP have different UDP port numbers, I don't know why there is still a need to demultiplex GUE and IP-in-UDP.
>
It's header compression. Consider a scenario that GUE is tunneling
IPv6 and IPv4 and will do GUE fragmentation if necessary on tunnel
ingress.  So some packets will have a fragmentation option and some
won't. For unfragmented packets with no GUE options, they can be sent
in direct encapsulation of IP. This could be done as version 1 of GUE
or in IP-in-UDP as you're suggesting. The problem with the latter is
that it doubles the number of flows in the network. So instead of
punching one hole for a tunnel in a firewall we need two (the fragment
tunnel and non-fragment UDP ports). Packets in individual flows now
can take different paths depending on whether they're fragmented so
this introduces OOO.

Tom

> Xiaohu
>
>> Joe