On Thu, May 25, 2017 at 6:36 PM, Xuxiaohu <[email protected]> wrote: > Tom, > >> -----邮件原件----- >> 发件人: Tom Herbert [mailto:[email protected]] >> 发送时间: 2017年5月26日 0:00 >> 收件人: Xuxiaohu >> 抄送: Joe Touch; [email protected] >> 主题: 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 <[email protected]> wrote: >> > >> > >> >> -----邮件原件----- >> >> 发件人: Tom Herbert [mailto:[email protected]] >> >> 发送时间: 2017年5月21日 0:01 >> >> 收件人: Xuxiaohu >> >> 抄送: Joe Touch; [email protected] >> >> 主题: 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 <[email protected]> >> wrote: >> >> > >> >> > >> >> >> -----邮件原件----- >> >> >> 发件人: Joe Touch [mailto:[email protected]] >> >> >> 发送时间: 2017年5月20日 12:15 >> >> >> 收件人: Xuxiaohu; Tom Herbert >> >> >> 抄送: [email protected] >> >> >> 主题: 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:[email protected]] >> >> >> >> 发送时间: 2017年5月20日 11:41 >> >> >> >> 收件人: Xuxiaohu; Tom Herbert >> >> >> >> 抄送: [email protected] >> >> >> >> 主题: 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? >
That is already part of EtherIP (RFC3378). Tom > 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 [email protected] https://www.ietf.org/mailman/listinfo/int-area
