Re: [Int-area] 答复: 答复: 答复: 答复: 答复: Is the UDP destination port number resource running out?// re: I-D Action: draft-ietf-intarea-gue-04.txt

[Tom Herbert <[e-mail]>]

On Thu, May 25, 2017 at 6:36 PM, Xuxiaohu <[e-mail]> wrote:
> Tom,
>
>> -----邮件原件-----
>> 发件人: Tom Herbert [mailto:[e-mail]]
>> 发送时间: 2017年5月26日 0:00
>> 收件人: Xuxiaohu
>> 抄送: Joe Touch; [e-mail]
>> 主题: 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 <[e-mail]> wrote:
>> >
>> >
>> >> -----邮件原件-----
>> >> 发件人: Tom Herbert [mailto:[e-mail]]
>> >> 发送时间: 2017年5月21日 0:01
>> >> 收件人: Xuxiaohu
>> >> 抄送: Joe Touch; [e-mail]
>> >> 主题: 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 <[e-mail]>
>> wrote:
>> >> >
>> >> >
>> >> >> -----邮件原件-----
>> >> >> 发件人: Joe Touch [mailto:[e-mail]]
>> >> >> 发送时间: 2017年5月20日 12:15
>> >> >> 收件人: Xuxiaohu; Tom Herbert
>> >> >> 抄送: [e-mail]
>> >> >> 主题: 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:[e-mail]]
>> >> >> >> 发送时间: 2017年5月20日 11:41
>> >> >> >> 收件人: Xuxiaohu; Tom Herbert
>> >> >> >> 抄送: [e-mail]
>> >> >> >> 主题: 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