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

[Xuxiaohu <[e-mail]>]

Hi Tom,

Thanks for your quick response. Please see my reply inline.

> -----邮件原件-----
> 发件人: Tom Herbert [mailto:[e-mail]]
> 发送时间: 2017年5月19日 22:57
> 收件人: Xuxiaohu
> 抄送: [e-mail]
> 主题: Re: [Int-area] Is the UDP destination port number resource running out?//
> re: I-D Action: draft-ietf-intarea-gue-04.txt
> 
> Hi Xuxiaohu,
> 
> Thanks for the comments. Some response are inline.
> 
> On Thu, May 18, 2017 at 7:53 PM, Xuxiaohu <[e-mail]> wrote:
> > Hi all,
> >
> > With regard to directly encapsulating IPvx packet in UDP, I think the following
> argument for using Version 1 of GUE is not valid:
> >
> > "This technique saves encapsulation overhead on costly links
> >    for the common use of IP encapsulation, and also obviates the need to
> >    allocate a separate port number for IP-over-UDP encapsulation."
> >
> > First, I don't think the encapsulation overhead of 4 bytes is a matter.
> 
> I'm not sure everyone would agree with that. The case was made when we were
> discussing it that the savings would be beneficial for some deployments.

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:))  

BTW, what happens if any other GUE payload has the same desire of saving the 4 byte GUE header overhead?

> > However, the premise is that it's meaningful for the IETF to develop
> > such a GENERIC and COVERALL encapsulation method which is still
> > looking for nails:)
> 
> The protocol is called *Generic* UDP Encapsulation for reason.

I know that you are trying to specify a generic UDP encapsulation. However, there has been a generic UDP encapsulation scheme that is GRE-in-UDP [RFC8086]. Furthermore, there is another generic UDP encapsulation scheme called GENEVE that the NVO3 group is working on. It's better for the IETF community to avoid specifying multiple similar encapsulation schemes and therefore the NVo3 WG co-chairs and the corresponding AD try their best to reach a consensus of working together on a single encapsulation on the basis of GENEVE among the WG members. Do you still believe it's helpful for the industry to specify one additional generic encapsulation scheme in another IETF WG?

> > If I remembered correctly, this draft was originally adopted by the NVO3 WG
> which is focused on multi-tenancy, although this draft has nothing to do with
> multi-tenancy:) Latter it becomes a INTAREA WG draft. by the way, did I miss
> the WG adoption call for this draft in the INTAREA WG or the WG adoption call
> isn't occurred at all?
> >
> It was adopted after Seoul IETF.
> 
> > Second, UDP itself has been widely used as a tunnel technology due to its
> load-balancing capability. See LISP [RFC6830], VXLAN [RFC7346], MPLS-in-UDP
> [RFC7510], GRE-in-UDP [RFC8086], ESP-in-UDP [RFC3948], TRILL-in-UDP,
> NSH-in-UDP, VXLAN-GPE, GENEVE, GUE, ... The destination port is used to
> distinguish these different UDP tunnel payload types. For IP-in-UDP, there has
> been a draft (https://tools.ietf.org/html/draft-xu-intarea-ip-in-udp) which was
> originally discussed in Softwire WG
> (https://tools.ietf.org/html/draft-xu-softwire-ip-in-udp) . IMHO, it seems ugly to
> use a version field within the GUE header to distinguish IPvx header from the
> GUE header itself. Is the UDP destination port number resource running out?
> 
> From RFC7605, section 6 "Conservation":
> 
> "Assigned port numbers are a limited resource that is globally shared by the
> entire Internet community.  As of 2014, approximately 5850 TCP and 5570
> UDP port numbers had been assigned out of a total range of 49151.  As a
> result of past conservation, current assigned port use is small and the current
> rate of assignment avoids the need for transition to larger number spaces.  This
> conservation also helps avoid the need for IANA to rely on assigned port
> number reclamation, which is practically impossible even though procedurally
> permitted [RFC6335].

If the port number resource was scarce, it'd better for the IETF to recommend using the GRE-in-UDP [RFC8086] for any new payload type which is desired to be transported over UDP UNIFORMLY rather than SELECTIVELY, IMHO.

> Also, it's not just the assignment that is a pain, port numbers to need to be
> managed in networks. If we introduce a new port number in the datacenter
> management tools, firewalls, packet capture need to be updated.

The version numbers need to be managed as well:)

> A feature of GUE is that the payload transform option allows DTLS to be done
> on the payload. This obviates needing to ask for two port numbers (a DTLS
> variant and non-DTLS variant) as several of the encapsulation methods you
> listed above have done.
> 
> > If so, why not use GRE-in-UDP to carry GUE so as to save one more UDP
> destination port number?
> >
> Then we'd be talking about having to reserve an Ethertype for GUE.

EtherType is a two-octet field which has the same length as the UDP port number. Fortunately, it seems that the IEEE doesn't scant the assignment of the Ethertype code resource. Hence you don't need to worry about it.
 
> > Third, if the GUE devotes itself to save the UDP destination port
> > number for the interest of the internet community, the 2-bit version
> > field abused as a payload type indicator is obviously not enough:)
> >
> I'm not sure how it's "obviously not enough". Version 1 handles the currently
> deployed two IP protocol versions. The technique allows for supporting two
> more IP protocol versions to be supported without burning another version
> number.

It seems that your are attempting to repeat the notorious first nibble issue associated with MPLS (for more details about the first nibble issue, please refer to https://tools.ietf.org/html/draft-xu-mpls-payload-protocol-identifier-02) in your GUE design.

Best regards,
Xiaohu

> Tom
> 
> > Best regards,
> > Xiaohu
> >
> >> -----邮件原件-----
> >> 发件人: Int-area [mailto:[e-mail]] 代表
> >> [e-mail]
> >> 发送时间: 2017年5月19日 6:53
> >> 收件人: [e-mail]
> >> 抄送: [e-mail]
> >> 主题: [Int-area] I-D Action: draft-ietf-intarea-gue-04.txt
> >>
> >>
> >> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> >> This draft is a work item of the Internet Area Working Group of the IETF.
> >>
> >>         Title           : Generic UDP Encapsulation
> >>         Authors         : Tom Herbert
> >>                           Lucy Yong
> >>                           Osama Zia
> >>       Filename        : draft-ietf-intarea-gue-04.txt
> >>       Pages           : 37
> >>       Date            : 2017-05-18
> >>
> >> Abstract:
> >>    This specification describes Generic UDP Encapsulation (GUE), which
> >>    is a scheme for using UDP to encapsulate packets of different IP
> >>    protocols for transport across layer 3 networks. By encapsulating
> >>    packets in UDP, specialized capabilities in networking hardware for
> >>    efficient handling of UDP packets can be leveraged. GUE specifies
> >>    basic encapsulation methods upon which higher level constructs, such
> >>    as tunnels and overlay networks for network virtualization, can be
> >>    constructed. GUE is extensible by allowing optional data fields as
> >>    part of the encapsulation, and is generic in that it can encapsulate
> >>    packets of various IP protocols.
> >>
> >>
> >> The IETF datatracker status page for this draft is:
> >> https://datatracker.ietf.org/doc/draft-ietf-intarea-gue/
> >>
> >> There are also htmlized versions available at:
> >> https://tools.ietf.org/html/draft-ietf-intarea-gue-04
> >> https://datatracker.ietf.org/doc/html/draft-ietf-intarea-gue-04
> >>
> >> A diff from the previous version is available at:
> >> https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-gue-04
> >>
> >>
> >> Please note that it may take a couple of minutes from the time of
> >> submission until the htmlized version and diff are available at tools.ietf.org.
> >>
> >> Internet-Drafts are also available by anonymous FTP at:
> >> ftp://ftp.ietf.org/internet-drafts/
> >>
> >> _______________________________________________
> >> Int-area mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/int-area
> > _______________________________________________
> > Int-area mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/int-area