Tom, > -----邮件原件----- > 发件人: Tom Herbert [mailto:t...@herbertland.com] > 发送时间: 2017年5月26日 0:00 > 收件人: 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 Mon, May 22, 2017 at 7:49 PM, Xuxiaohu <xuxia...@huawei.com> wrote: > > > > > >> -----邮件原件----- > >> 发件人: 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. > > > Xiaohu, > > GUE encapsulates by IP protocol, I don't believe there is a protocol number > for > NSH or BIER so they should not be encapsulated in version 1. There is a > protocol > number for MPLS-IP, however there is no fixed field in the MPLS header (like > the > IP version) so the overlay technique can't work. Furthermore, these three > protocols are already encapsulations, the optimization makes the most sense > for > simple network protocols that are not encapsulations.
If so, it seems a little bit confused to claim it as a generic udp encapsulation. > IPv4 and IPv6 can be directly encapsulated since they have a protocol number > (can be encapsulated by version 0). If the possible payload types of GUE are limited to IPv4, IPv6 and MPLS, and these payloads need to be directly transported over UDP, the most simple way is to allocate a dedicated port number for IP since MPLS has already be assigned one (RFC7510), IMHO. > As I mentioned previously, Ethernet could be directly encapsulated via EtherIP > that has a 4 bit version number at the beginning of its header. The way this > would work is to set a version 1 pattern to indicate EtherIP. For example, we > could specify that 0101 would be EtherIP. When GUE receives such a packet it > will notice it's version one and then see that it is EtherIP (differentiated > from > IPv4 0100 and > IPv6 0110 values). The first four bits are then overwritten by 0011 to make > it a > valid EtherIP header and then the packet is resubmitted to the stack as > EtherIP. To save the 4-byte GUE base header overhead when encapsulating Ethernet over UDP, you propose to insert the additional 16-bit EtherIP header between the UDP header and MAC frame? Xiaohu > Transport protocols (TCP, UDP, SCTP) might also be nice to support with direct > encapsulation in version 1, but unfortunately since they start with a variable > port number there's no way to do that. > > Tom > > > Best regards, > > Xiaohu > > > >> Tom > >> > >> > Xiaohu > >> > > >> >> Joe _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
