Re: [Int-area] [nvo3] Fwd: New Version Notification for draft-ietf-nvo3-gue-03.txt

[Joe Touch <[e-mail]>]

On 6/16/2016 11:58 PM, Xuxiaohu wrote:
>
>> -----Original Message-----
>> From: Joe Touch [mailto:[e-mail]]
>> Sent: Friday, June 17, 2016 12:28 PM
>> To: Xuxiaohu; Tom Herbert
>> Cc: [e-mail]; [e-mail]
>> Subject: Re: [nvo3] [Int-area] Fwd: New Version Notification for
>> draft-ietf-nvo3-gue-03.txt
>>
>> On 6/16/2016 8:09 PM, Xuxiaohu wrote:
>>> Hi Tom,
>>>
>>> By the way, I have just had a look at your draft. It seems that this draft itself
>> has nothing to do with the multi-tenancy capability which is the focus of the
>> NOV3 current charter.
>>
>> FWIW, I agree it would be useful to add text to discuss the relationship to NVO3.
> Sound fair. An alternative is to pursue this doc in TSVWG or INTAREA first, once this draft is adopted by TSVWG or INTAREA and becomes stable enough, turn to NVo3 to pursue draft-hy-nvo3-gue-4-nvo. Otherwise, it seems unwise to build network overlay on a unstable UDP-based tunneling technology.

I don't see the benefit of moving this document out of NVO3 to obtain
this feedback. You're already getting it from very active members of
both TSVWG and INTAREA in this discussion, and there are already
procedures for cross-area review.

Joe

>
> Xiaohu
>
>>>  In addition, according to section 7 (Motivation for GUE) of this draft, it seems
>> that GUE is intended to be a generic UDP-based tunneling technology. Therefore,
>> should this draft be pursued in some WGs other than NVO3, e.g., TSVWG or
>> INTAREA.
>> It will definitely get review there, but to some extent it already is - there are TSV
>> and INT area feedback in this thread.
>>
>>>  In this way, it would be helpful for us to better understand the differences
>> between GUE and GRE-in-UDP, and whether the concerns made by Joe Touch
>> (see below) have been addressed successfully, especially when considering the
>> case where the version is set to 1 (i.e., directly encapsulating IP packet over
>> UDP).
>>
>> I agree that these issues should be addressed here too, though - to be fair - some
>> of them already are.
>
>> Joe
>>
>>>
>>> +++++++++
>>> 	- stronger checksums
>>>
>>> 	- fragmentation support
>>>
>>> 	- signalling support (e.g., to test whether a tunnel is up or
>>> 	to measure MTUs)
>>>
>>> 	- support for robust ID fields (related to fragmentation,
>>> 	e.g., to overcome the limits of IPv4 ID as per RFC 6864)
>>> ++++++++++
>>>