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. 
(US), Fred L <>Send Time:2018年5月18日(星期五) 09:28To:Joe 
Touch <>; <>Cc:Internet 
Area <>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 thesame thing as GUE variant 1. 
>Fred  From: Int-area []
On Behalf Of Joe Touch
Sent: Thursday, May 17, 2018 7:55 AM
Cc: Internet Area <>
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 <> wrote:  
On Wed, May 16, 2018 at 10:22 PM, 
徐小虎(义先) <> 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  
Touch <>Send Time:2018年5月16日(星期三)
 <>Cc:Tom Herbert <>; Internet 
Area <>;
 intarea-chairs <>; draft-xu-intarea-ip-in-udp 
<>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, 徐小虎(义先)
 <> wrote:IMHO,there
 seems no need to introduce such complexity into GUE just for the purpose of 
saving one port number.


发件人:Tom Herbert<>
日 期:2018年05月16日
抄 送:Erik Kline<>; Internet
主 题:Re:
 [Int-area] Request a WG adoption call for draft-xu-intarea-ip-in-udp

On Tue, May 15, 2018 at 8:33 PM, 徐小虎(义先)
 <> 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

> ( 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.


> Best regards,

> Xiaohu


> ------------------------------------------------------------------

> From:Erik Kline <>

> Send Time:2018年5月16日(星期三)

> To:徐小虎(义先)

> Cc:intarea-chairs <>;

> draft-xu-intarea-ip-in-udp <>;

> Internet Area <>

> 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 ?

> On Wed, 16 May 2018 at 11:53, 徐小虎(义先)

> wrote:


>> Hi co-chairs,


>> We would like to request a WG adoption call for this draft (

> 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 mailing list




Int-area mailing list


Int-area mailing list 

Int-area mailing list
Int-area mailing list

Reply via email to