Comments inline. ------------------------------------------------------------------From:Joe Touch <to...@strayalpha.com>Send Time:2018年5月18日(星期五) 11:55To:Tom Herbert <t...@herbertland.com>Cc:徐小虎(义先) <xiaohu....@alibaba-inc.com>; Int-area <int-area-boun...@ietf.org>; sarik...@ieee.org <sarik...@ieee.org>; Internet Area <int-area@ietf.org>Subject:Re: [Int-area] Request a WG adoption call for draft-xu-intarea-ip-in-udp It’s also entirely possible that the UDP tunnel will end up needing a signaling channel of the kind already available in GUE. [Xiaohu] I have not heard such a need for a signaling channel in the IP-in-UDP tunneling applicability. If you knew any, please list it explicitly and then let's check its necessity. IMO, the unnecessary complexity would be using bits in the port space to provide an indication already available further inside the packet (here, in the first few bits). [Xiaohu] IMHO, using the first few bits of the GUE payload to indicate the type of the GUE payload is a bad idea. It seems as funny as the idea of using the first nibble of the MPLS payload as a protocol field to indicate the MPLS payload type. Xiaohu Joe On May 17, 2018, at 6:52 PM, Tom Herbert <t...@herbertland.com> wrote: On Thu, May 17, 2018 at 6:41 PM, 徐小虎(义先) <xiaohu....@alibaba-inc.com> wrote: It's different. In GUE variant 1, the tunnel decapsulation device needs to read the UDP destination port to determine that the UDP payload is a GUE and then to read the first two nibble of the GUE payload to determine whether the UDP payload is actually an IP payload. It introduces an absolutely unnecessary complexity in the procedure, especially for chips.
I don't follow. In SW this is a grand total of a single mask and conditional (maybe 3 assembly instructions). In HW this is nothing more than programming the TCAM with entries that match GUE v0, GUE v1 IPv4, GUE v1 IPv6. Complexity of implementation is completely insignificant. Tom Xiaohu ------------------------------------------------------------------ From:Templin (US), Fred L <fred.l.temp...@boeing.com> Send Time:2018年5月18日(星期五) 09:28 To:Joe Touch <to...@strayalpha.com>; sarik...@ieee.org <sarik...@ieee.org> Cc:Internet Area <int-area@ietf.org> Subject:Re: [Int-area] 回复： Request a WG adoption call for draft-xu-intarea-ip-in-udp Because it isn’t different. Again, see GUE variant 1. Correct. There is no reason to progress another draft that does the same thing as GUE variant 1. Fred From: Int-area [mailto:int-area-boun...@ietf.org] On Behalf Of Joe Touch Sent: Thursday, May 17, 2018 7:55 AM To: sarik...@ieee.org Cc: Internet Area <int-area@ietf.org> Subject: Re: [Int-area] 回复： Request a WG adoption call for draft-xu-intarea-ip-in-udp Because it isn’t different. Again, see GUE variant 1. On May 17, 2018, at 7:18 AM, Behcet Sarikaya <sarikaya2...@gmail.com> wrote: On Wed, May 16, 2018 at 10:22 PM, 徐小虎(义先) <xiaohu....@alibaba-inc.com> wrote: It doesn't matter whether or not it's already there. IMHO, given the popularity of different overlay technologies such as VXLAN and MPLS-in-UDP in practice, GUE initially and mainly targeted as a DC overlay approach has little change to be widely deployed within data centers. As such, if the only possible applicability of GUE is for directly carrying IP over UDP, I don't understand why we need such a overhead associated with the variation of GUE. In another word, why not directly assign a port to indicate IP-in-UDP, instead of using the GUE protocol variant number to indicate. By the way, this the GUE protocol variant number usage reminds me of the notorious misuse of the first nibble of the MPLS payload to indicate the type of the MPLS payload:) I agree and support the adoption. I supported GUE in the past.. Why not have another way of UDP encapsulation with the possibility of a different area of applicability? Regards, Behcet Xiaohu ------------------------------------------------------------------ From:Joe Touch <to...@strayalpha.com> Send Time:2018年5月16日(星期三) 15:45 To:徐小虎(义先) <xiaohu....@alibaba-inc.com> Cc:Tom Herbert <t...@herbertland.com>; Internet Area <int-area@ietf.org>; intarea-chairs <intarea-cha...@tools.ietf.org>; draft-xu-intarea-ip-in-udp <draft-xu-intarea-ip-in-...@tools.ietf.org> Subject:Re: [Int-area] 回复： Request a WG adoption call for draft-xu-intarea-ip-in-udp It’s not complex. It’s already there. So there continues to be no reason to waste either a port number or further time discussing this draft. Joe On May 15, 2018, at 9:01 PM, 徐小虎(义先) <xiaohu....@alibaba-inc.com> wrote: IMHO，there seems no need to introduce such complexity into GUE just for the purpose of saving one port number. Xiaohu 来自钉钉专属商务邮箱 ------------------------------------------------------------------ 发件人：Tom Herbert<t...@herbertland.com> 日 期：2018年05月16日 11:55:49 收件人：徐小虎(义先)<xiaohu....@alibaba-inc.com> 抄 送：Erik Kline<e...@google.com>; Internet Area<int-area@ietf.org>; draft-xu-intarea-ip-in-udp<draft-xu-intarea-ip-in-...@tools.ietf.org>; intarea-chairs<intarea-cha...@tools.ietf.org> 主 题：Re: [Int-area] Request a WG adoption call for draft-xu-intarea-ip-in-udp On Tue, May 15, 2018 at 8:33 PM, 徐小虎(义先) <xiaohu....@alibaba-inc.com> wrote: Hi Eric, Good question. This draft (draft-xu-intarea-ip-in-udp) describes a native UDP encapsulation scheme for IP packets, which is straightforward and light-weighted, just as MPLS-in-UDP [RFC7510] and TRILL-in-UDP (https://tools.ietf.org/html/draft-ietf-trill-over-ip-16#page-20) and etc. GUE variant 1 implements native UDP encapsulation for IPv4 and IPv6. Except for a different port number, there is no protocol difference between that and doing IP in UDP as separate protocol. Tom Best regards, Xiaohu ------------------------------------------------------------------ From:Erik Kline <e...@google.com> Send Time:2018年5月16日(星期三) 11:07 To:徐小虎(义先) <xiaohu....@alibaba-inc.com> Cc:intarea-chairs <intarea-cha...@tools.ietf.org>; draft-xu-intarea-ip-in-udp <draft-xu-intarea-ip-in-...@tools.ietf.org>; Internet Area <int-area@ietf.org> Subject:Re: [Int-area] Request a WG adoption call for draft-xu-intarea-ip-in-udp Should this document make some comment about its relation, or lack of relation, to https://tools.ietf.org/html/draft-ietf-intarea-gue ? On Wed, 16 May 2018 at 11:53, 徐小虎(义先) <xiaohu....@alibaba-inc.com> wrote: Hi co-chairs, We would like to request a WG adoption call for this draft ( https://tools.ietf.org/html/draft-xu-intarea-ip-in-udp-07) since it has been stable enough and the solution as described in this draft is needed in practice. Best regards, Xiaohu (on behalf of all co-authors) _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
_______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
