On Fri, May 19, 2017 at 11:09 PM, Xuxiaohu <xuxia...@huawei.com> wrote: > > >> -----邮件原件----- >> 发件人: Joe Touch [mailto:to...@isi.edu] >> 发送时间: 2017年5月20日 12:15 >> 收件人: Xuxiaohu; Tom Herbert >> 抄送: 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 5/19/2017 8:57 PM, Xuxiaohu wrote: >> > Hi Joe, >> > >> >> -----邮件原件----- >> >> 发件人: Joe Touch [mailto:to...@isi.edu] >> >> 发送时间: 2017年5月20日 11:41 >> >> 收件人: Xuxiaohu; Tom Herbert >> >> 抄送: 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 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 _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
