> -----邮件原件----- > 发件人: Tom Herbert [mailto:t...@herbertland.com] > 发送时间: 2017年5月21日 0:01 > 收件人: Xuxiaohu > 抄送: Joe Touch; 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 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.
Since GUE is intended to be a generic UDP encapsulation, now let's assume GUE is tunneling MPLS, NSH or BIER. Please continue your rationale once those encapsulations have the same requirement of saving the 4-byte GUE base header overhead as the encapsulation of IP in UDP. Best regards, Xiaohu > Tom > > > Xiaohu > > > >> Joe _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
