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. IPv4 and IPv6 can be directly encapsulated since they have a protocol number (can be encapsulated by version 0). 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. 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
