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

From: Tom Herbert <[email-masked]>
Date: Fri, 10 Jun 2016 10:21:17 -0700

Hello,

We've posted a new version of GUE. The primary addition is that we
added GUE version 1 that allows direct encapsulation of IPv4 and IPv6
over UDP (port 6080). This effectively implements
draft-xu-intarea-ip-in-udp-03 also.

Thanks,
Tom

---------- Forwarded message ----------
From:  <[email-masked]>
Date: Fri, Jun 10, 2016 at 10:14 AM
Subject: New Version Notification for draft-ietf-nvo3-gue-03.txt
To: Tom Herbert <[email-masked]>, Lucy Yong
<[email-masked]>, Osama Zia <[email-masked]>

A new version of I-D, draft-ietf-nvo3-gue-03.txt
has been successfully submitted by Tom Herbert and posted to the
IETF repository.

Name:           draft-ietf-nvo3-gue
Revision:       03
Title:          Generic UDP Encapsulation
Document date:  2016-06-10
Group:          nvo3
Pages:          28
URL:            https://www.ietf.org/internet-drafts/draft-ietf-nvo3-gue-03.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-nvo3-gue/
Htmlized:       https://tools.ietf.org/html/draft-ietf-nvo3-gue-03
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-nvo3-gue-03

Abstract:
   This specification describes Generic UDP Encapsulation (GUE), which
   is a scheme for using UDP to encapsulate packets of arbitrary 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
   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.

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.

The IETF Secretariat

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 16 Jun 2016 09:12:51 +0000

> -----Original Message-----
> From: Int-area [mailto:[email-masked]] On Behalf Of Tom Herbert
> Sent: Saturday, June 11, 2016 1:21 AM
> To: [email-masked]; [email-masked]
> Subject: [Int-area] Fwd: New Version Notification for draft-ietf-nvo3-gue-03.txt
> 
> Hello,
> 
> We've posted a new version of GUE. The primary addition is that we added GUE
> version 1 that allows direct encapsulation of IPv4 and IPv6 over UDP (port
> 6080). This effectively implements
Tom,

What's the real benefit of such implementation of IP-in-UDP compared to the approach as described draft-xu-intarea-ip-in-udp-03? Save one UDP port number?

Best regards,
Xiaohu

> A new version of I-D, draft-ietf-nvo3-gue-03.txt has been successfully submitted
> by Tom Herbert and posted to the IETF repository.
> 
> URL:
> https://www.ietf.org/internet-drafts/draft-ietf-nvo3-gue-03.txt
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: Tom Herbert <[email-masked]>
Date: Thu, 16 Jun 2016 07:36:36 -0700

> What's the real benefit of such implementation of IP-in-UDP compared to the approach as described draft-xu-intarea-ip-in-udp-03? Save one UDP port number?
Yes, saves a port number.

Tom

> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 17 Jun 2016 01:48:42 +0000

> From: Tom Herbert [mailto:[email-masked]]
> Sent: Thursday, June 16, 2016 10:37 PM
> To: Xuxiaohu
> Cc: [email-masked]; [email-masked]
> Subject: Re: [nvo3] [Int-area] Fwd: New Version Notification for
> draft-ietf-nvo3-gue-03.txt
> 
> > What's the real benefit of such implementation of IP-in-UDP compared to the
> approach as described draft-xu-intarea-ip-in-udp-03? Save one UDP port
> number?
> >

To save a port number, the header format is made ugly. Is it worthwhile? If UDP port resource was so sparse as you had imagined, I think the UDP port resource keeper would not allocate two different port numbers for VXLAN and VXLAN-GPE since the P-bit in VXLAN-GPE header is enough to distinguish VXLAN-GPE from VXLAN. For more details, please look at section 3.2 of (https://tools.ietf.org/html/draft-ietf-nvo3-vxlan-gpe-02#page-6). 

Xiaohu

> >> A new version of I-D, draft-ietf-nvo3-gue-03.txt has been
> >> successfully submitted by Tom Herbert and posted to the IETF repository.
> >>
> >> 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.
> >>
> >> The IETF Secretariat
> >>

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 17 Jun 2016 03:09:04 +0000

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

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

Best regards,
Xiaohu

> From: Int-area [mailto:[email-masked]] On Behalf Of Xuxiaohu
> Sent: Friday, June 17, 2016 9:49 AM
> To: Tom Herbert
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Int-area] [nvo3] Fwd: New Version Notification for
> > >> added GUE version 1 that allows direct encapsulation of IPv4 and
> > >> IPv6 over UDP (port 6080). This effectively implements
> To save a port number, the header format is made ugly. Is it worthwhile? If UDP
> port resource was so sparse as you had imagined, I think the UDP port resource
> keeper would not allocate two different port numbers for VXLAN and
> VXLAN-GPE since the P-bit in VXLAN-GPE header is enough to distinguish
> VXLAN-GPE from VXLAN. For more details, please look at section 3.2 of
> (https://tools.ietf.org/html/draft-ietf-nvo3-vxlan-gpe-02#page-6).
> 
> Xiaohu
> 
> > Tom
> >
> > > Best regards,
> > > Xiaohu
> > >
> > >> Thanks,
> > >> Tom
> > >>

---

From: Joe Touch <[email-masked]>
Date: Thu, 16 Jun 2016 21:15:29 -0700

>> Yes, saves a port number.

More than that, GUE was accepted as a WG doc *and* has already been
assigned a port number.

> To save a port number, the header format is made ugly. Is it worthwhile? If UDP port resource was so sparse as you had imagined, I think the UDP port resource keeper would not allocate two differen…
VXLAN was assigned in 2011.

VXLAN-GPE was assigned this year (2016).

If what you say is correct*, then you might be correct in assuming that
a VXLAN-GPE assignment might inhibit a later VXLAN assignment, but
that's not the order things happened.

*(I haven't looked and don't plan to, because the point is irrelevant
even if assumed)

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 16 Jun 2016 21:27:55 -0700

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.

>  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

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 17 Jun 2016 06:41:22 +0000

> From: Joe Touch [mailto:[email-masked]]
> Sent: Friday, June 17, 2016 12:15 PM
> To: Xuxiaohu; Tom Herbert
> >> approach as described draft-xu-intarea-ip-in-udp-03? Save one UDP
> >> port number?

Oh, a WG doc? a doc which has nothing to do with multi-tenancy but happens to be adopted by a WG working on multi-tenancy?

> > To save a port number, the header format is made ugly. Is it worthwhile? If
> UDP port resource was so sparse as you had imagined, I think the UDP port
> resource keeper would not allocate two different port numbers for VXLAN and
> If what you say is correct*, then you might be correct in assuming that a
> VXLAN-GPE assignment might inhibit a later VXLAN assignment, but that's not
> the order things happened.

Your logic seems confused to me. My point is VXLAN-GPE should share the same port number (i.e., 4789) with VXLAN if the port number resource was so sparse. Unless that assumption is fake.

*******************http://www.honeypots.net/misc/services*********************
vxlan              4789        udp    Virtual eXtensible Local     [Lawrence_Kreeger]                                    [Lawrence_Kreeger]                                        2013-04-19   2014-06-17   [RFC 7348]
                                      Area Network (VXLAN)
                   4789        tcp    Reserved
                                      Generic Protocol Extension
vxlan-gpe          4790        udp    for Virtual eXtensible Local [Lawrence_Kreeger]                                    [Lawrence_Kreeger]                                        2014-08-26
                                      Area Network (VXLAN)
                   4790        tcp    Reserved
************************************************************************

> *(I haven't looked and don't plan to, because the point is irrelevant even if
> assumed)
> 
> Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 16 Jun 2016 23:56:52 -0700

> Oh, a WG doc? a doc which has nothing to do with multi-tenancy but happens to be adopted by a WG working on multi-tenancy?
I'm not advocating where this doc *should be* - or should have been -
adopted. I'm simply noting that it already has been adopted. Which does
carry weight in the IANA assignment of ports (as noted in RFC 6335).

> Your logic seems confused to me. My point is VXLAN-GPE should share the same port number (i.e., 4789) with VXLAN if the port number resource was so sparse. Unless that assumption is fake.

Your logic fails to consider that these two requests were not made at
the same time. Also, VXLAN was not made *after* VXLAN-GPE. If either of
these were true, then the argument for a single port number would be
important.

So, in brief, IMO (with my ports hat off) if you had a stronger argument
for UDP-in-IP (i.e., you convinced a WG to adopt it) *and* you proposed
it before GUE made its request, then things might have turned out
differently.

Joe

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 17 Jun 2016 06:58:04 +0000

> Sent: Friday, June 17, 2016 12:28 PM
> > 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.

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.

---

From: Joe Touch <[email-masked]>
Date: Fri, 17 Jun 2016 00:05:35 -0700

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

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

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 17 Jun 2016 07:48:57 +0000

> Sent: Friday, June 17, 2016 2:57 PM
> > Oh, a WG doc? a doc which has nothing to do with multi-tenancy but happens
> to be adopted by a WG working on multi-tenancy?
> I'm not advocating where this doc *should be* - or should have been - adopted.
> I'm simply noting that it already has been adopted. Which does carry weight in
> the IANA assignment of ports (as noted in RFC 6335).
> 
> >
> >> UDP port resource was so sparse as you had imagined, I think the UDP
> >> port resource keeper would not allocate two different port numbers
> >> for VXLAN and VXLAN-GPE since the P-bit in VXLAN-GPE header is enough
> >> to distinguish VXLAN-GPE from VXLAN. For more details, please look at
> >> section 3.2 of
> >> If what you say is correct*, then you might be correct in assuming
> >> that a VXLAN-GPE assignment might inhibit a later VXLAN assignment,
> >> but that's not the order things happened.
> > Your logic seems confused to me. My point is VXLAN-GPE should share the
> same port number (i.e., 4789) with VXLAN if the port number resource was so
> sparse. Unless that assumption is fake.
> 
> Your logic fails to consider that these two requests were not made at the same
> time. Also, VXLAN was not made *after* VXLAN-GPE. If either of these were
> true, then the argument for a single port number would be important.

More confused to me:) Let me make it simpler, VXLAN was allocated a port number in 2011 which is 4789. VXLAN-GPE asked for a port in 2016, why allocate a new number rather than reusing the port number 4789 provided the port number resource was so sparse?  Your answers to the above question seems to be: 1)these two requests were not made at the same time, 2) VXLAN was not made *after* VXLAN-GPE. For the first answer, did you mean, for two proposals which could have shared the same port number, as long as they requests at different time no matter intended or not, they would be assigned two different port numbers. For the second answer, have you seen protocol X be made after an extension protocol to X?:) 

Xiaohu

> So, in brief, IMO (with my ports hat off) if you had a stronger argument for
> UDP-in-IP (i.e., you convinced a WG to adopt it) *and* you proposed it before
> GUE made its request, then things might have turned out differently.

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 17 Jun 2016 08:31:42 +0000

> Sent: Friday, June 17, 2016 3:06 PM
> > 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.

It depends on whether this document is describing an generic UDP-based tunneling technology or a network overlay technology for multi-tenancy. It seems that this document is the former while draft-hy-nvo3-gue-4-nvo is the latter. Besides, IMHO, cross-area review could never replace the detailed and deep work within the most appropriate WG.

Xiaohu

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

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 17 Jun 2016 13:11:20 +0000

Hi,

> Yes, saves a port number.

It also saves an RFC number.

Thanks - Fred
[email-masked]

> Sent: Thursday, June 16, 2016 7:37 AM
> To: Xuxiaohu <[email-masked]>
> Subject: Re: [Int-area] [nvo3] Fwd: New Version Notification for draft-ietf-nvo3-gue-03.txt
> 

It also saves an RFC number.

---

From: Tom Herbert <[email-masked]>
Date: Fri, 17 Jun 2016 08:06:38 -0700

> More confused to me:) Let me make it simpler, VXLAN was allocated a port number in 2011 which is 4789. VXLAN-GPE asked for a port in 2016, why allocate a new number rather than reusing the port num…
VXLAN-GPE requires a different protocol number, the P-bit was not
sufficient. The problem was that VXLAN defined unknown flag bits to be
ignored upon receive. So if a legacy VLXAN device ever received a
VXLAN-GPE packet (P-bit set) it would be misinterpreted as a VLXAN
packet. Effectively this makes VXLAN-GPE a new protocol not a
different version of VXLAN. All of this was discussed on the nvo3
list.

Tom

---

From: Joe Touch <[email-masked]>
Date: Fri, 17 Jun 2016 08:33:14 -0700

On 6/17/2016 8:06 AM, Tom Herbert wrote:
> The problem was that VXLAN defined unknown flag bits to be
> different version of VXLAN.

Right - the issue is that the new protocol is not a *subset* of the
older one.

That was not the case for VXLAN/VXLAN-GPE, but is for GUE/IP-in-UDP.

Joe

---

From: Tom Herbert <[email-masked]>
Date: Fri, 17 Jun 2016 08:35:38 -0700

> To save a port number, the header format is made ugly. Is it worthwhile? If UDP port resource was so sparse as you had imagined, I think the UDP port resource keeper would not allocate two differen…
Xiaohu,

Ugliness is in the eye of the beholder. Personally, I think this
solution is clever and elegant. Also, this was a trivial code change
to make work in GUE.

As for the UDP port number space, I suggest you review RFC6335. From that:

"Conservation of the port number space is required because this space
is a limited resource, so applications are expected to participate in
the traffic demultiplexing process where feasible.  The port numbers
are expected to encode as little information as possible that will
still enable an application to perform further demultiplexing by
itself."

To flip the question around, what would be the value be for allocating
new port numbers to do IP-over-UDP if this can already be done with an
existing port number? The fact that this same port number can be also
used for GUE isn't particularly relevant (i.e. the Swiss Army Knife
point), an implementation is perfectly free to only send IP-in-UDP on
the port and never has to send a single GUE packet (vers. 0).
Semantically and operationally there is no difference between port
6080 or using a new port for IP-in-UDP.

Tom

---

From: Joe Touch <[email-masked]>
Date: Fri, 17 Jun 2016 08:41:10 -0700

On 6/17/2016 1:31 AM, Xuxiaohu wrote:
> It depends on whether this document is describing an generic UDP-based tunneling technology or a network overlay technology for multi-tenancy. It seems that this document is the former while draft-hy-nvo3-gue-4-nvo is the latter. 
So where does IP-in-UDP belong? It's a link for IP, so that belongs in
the group designing/using the link. It's intended for IP, so that
belongs in INTAREA. It uses and ties closely to UDP, so that belongs in
TSVWG. But any service *over* a transport is an application, so it
belongs in APP (do we even have that anymore?).

There's no simple answer.

> Besides, IMHO, cross-area review could never replace the detailed and deep work within the most appropriate WG.
We have IETF-wide LC, cross-area targeted reviews requested by the
document shepherd, and subgroups (e.g., Directorates in most areas,
though it was recently renamed "TSV-Triage" in transport) who already
handle these sort of "multihomed" docs just fine. If that didn't work,
we'd constantly be reshuffling where docs appear, which we don't.

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 17 Jun 2016 15:49:52 +0000

> solution is clever and elegant. Also, this was a trivial code change

Agree.

> Sent: Friday, June 17, 2016 8:36 AM
> > To save a port number, the header format is made ugly. Is it worthwhile? If UDP port resource was so sparse as you had imagined, I
> think the UDP port resource keeper would not allocate two different port numbers for VXLAN and VXLAN-GPE since the P-bit in
> VXLAN-GPE header is enough to distinguish VXLAN-GPE from VXLAN. For more details, please look at section 3.2 of

---

From: Xuxiaohu <[email-masked]>
Date: Mon, 20 Jun 2016 01:56:30 +0000

> Sent: Friday, June 17, 2016 11:07 PM
> To: Xuxiaohu
> Cc: Joe Touch; [email-masked]; [email-masked]
> >> >> More than that, GUE was accepted as a WG doc *and* has already
> >> >> been assigned a port number.
> adopted.
> >> I'm simply noting that it already has been adopted. Which does carry
> >> weight in the IANA assignment of ports (as noted in RFC 6335).
> >>
> >> >
> >> >> UDP port resource was so sparse as you had imagined, I think the
> >> >> UDP port resource keeper would not allocate two different port
> >> >> numbers for VXLAN and VXLAN-GPE since the P-bit in VXLAN-GPE
> >> >> header is enough to distinguish VXLAN-GPE from VXLAN. For more
> >> >> details, please look at section 3.2 of
> >> >> that a VXLAN-GPE assignment might inhibit a later VXLAN
> >> >> assignment, but that's not the order things happened.
> >> same port number (i.e., 4789) with VXLAN if the port number resource
> >> was so sparse. Unless that assumption is fake.
> >>
> >> the same time. Also, VXLAN was not made *after* VXLAN-GPE. If either
> >> of these were true, then the argument for a single port number would be
> important.
> >
> > More confused to me:) Let me make it simpler, VXLAN was allocated a
> > port number in 2011 which is 4789. VXLAN-GPE asked for a port in 2016,
> > why allocate a new number rather than reusing the port number 4789
> > provided the port number resource was so sparse?  Your answers to the
> > above question seems to be: 1)these two requests were not made at the
> > same time, 2) VXLAN was not made *after* VXLAN-GPE. For the first
> > answer, did you mean, for two proposals which could have shared the
> > same port number, as long as they requests at different time no matter
> > intended or not, they would be assigned two different port numbers.
> > For the second answer, have you seen protocol X be made after an
> > extension protocol to X?:)
> >
> VXLAN-GPE requires a different protocol number, the P-bit was not sufficient.
> The problem was that VXLAN defined unknown flag bits to be ignored upon
> receive. So if a legacy VLXAN device ever received a VXLAN-GPE packet (P-bit set)
> it would be misinterpreted as a VLXAN packet. Effectively this makes VXLAN-GPE
> a new protocol not a different version of VXLAN. All of this was discussed on the
> nvo3 list.

In which situation will a legacy VXLAN device receive a VXLAN-GPE packet?

Xiaohu

> Tom
> 
> > Xiaohu
> >
> >> So, in brief, IMO (with my ports hat off) if you had a stronger
> >> argument for UDP-in-IP (i.e., you convinced a WG to adopt it) *and*
> >> you proposed it before GUE made its request, then things might have turned
> out differently.
> >
> >
> >
> >> Joe
> >>
> >

---

From: Xuxiaohu <[email-masked]>
Date: Mon, 20 Jun 2016 02:05:10 +0000

> Sent: Friday, June 17, 2016 11:33 PM
> To: Tom Herbert; Xuxiaohu
> > The problem was that VXLAN defined unknown flag bits to be ignored
> > upon receive. So if a legacy VLXAN device ever received a VXLAN-GPE
> > packet (P-bit set) it would be misinterpreted as a VLXAN packet.
> > Effectively this makes VXLAN-GPE a new protocol not a different
> > version of VXLAN.
> 
> Right - the issue is that the new protocol is not a *subset* of the older one.

If it was a totally new protocol, why call it VXLAN-GPE instead of GPE? Furthermore, what's the meaning of the P-bit in the VXLAN-GPE header since a dedicated port number has been allocated?

Xiaohu

---

From: Xuxiaohu <[email-masked]>
Date: Mon, 20 Jun 2016 02:25:28 +0000

> Sent: Friday, June 17, 2016 11:36 PM
> To: Xuxiaohu
> Ugliness is in the eye of the beholder. Personally, I think this solution is clever and
> elegant. Also, this was a trivial code change to make work in GUE.
> 
> "Conservation of the port number space is required because this space is a
> limited resource, so applications are expected to participate in the traffic
> demultiplexing process where feasible.  The port numbers are expected to
> encode as little information as possible that will still enable an application to
> perform further demultiplexing by itself."
> 
> To flip the question around, what would be the value be for allocating new port
> numbers to do IP-over-UDP if this can already be done with an existing port

Clear and simple, especially in the case where other versions of GUE than 1 (i.e., IP-in-UDP) would never be deployed, as you had mentioned below. 

Xiaohu

> number? The fact that this same port number can be also used for GUE isn't
> particularly relevant (i.e. the Swiss Army Knife point), an implementation is
> perfectly free to only send IP-in-UDP on the port and never has to send a single
> GUE packet (vers. 0).
> >> >> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-nvo3-gue-03
> >> >>
> >> >> Abstract:

---

From: Xuxiaohu <[email-masked]>
Date: Mon, 20 Jun 2016 02:47:17 +0000

> Sent: Friday, June 17, 2016 11:41 PM
> >> > 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.
> > It depends on whether this document is describing an generic UDP-based
> tunneling technology or a network overlay technology for multi-tenancy. It
> seems that this document is the former while draft-hy-nvo3-gue-4-nvo is the
> latter.
> So where does IP-in-UDP belong? It's a link for IP, so that belongs in the group
> designing/using the link. It's intended for IP, so that belongs in INTAREA. It uses
> and ties closely to UDP, so that belongs in TSVWG. But any service *over* a
> transport is an application, so it belongs in APP (do we even have that
> anymore?).
> 

Sure. That's why we usually need to determine a WG which is more suitable for a given draft firstly in the IETF. If you firmly believe the more suitable WG for draft-ietf-nvo3-gue is NVO3, rather than INTAREA and TSVWG, please give your rationale.

Xiaohu

> We have IETF-wide LC, cross-area targeted reviews requested by the document
> shepherd, and subgroups (e.g., Directorates in most areas, though it was
> recently renamed "TSV-Triage" in transport) who already handle these sort of
> "multihomed" docs just fine. If that didn't work, we'd constantly be reshuffling
> where docs appear, which we don't.

---

From: Joe Touch <[email-masked]>
Date: Sun, 19 Jun 2016 20:13:46 -0700

On 6/19/2016 7:47 PM, Xuxiaohu wrote:
> Sure. That's why we usually need to determine a WG which is more suitable for a given draft firstly in the IETF. If you firmly believe the more suitable WG for draft-ietf-nvo3-gue is NVO3, rather than INTAREA and TSVWG, please give your rationale

My rationale is simple - it's sufficient and that's where it already is
a WG doc.

If that were not the case, you'd have a stronger argument.

But I really don't care all that much. If the chairs want to shift WGs,
then they can make the case for a call for adoption elsewhere.

However, given the substantial review this doc has already received both
here and from TSV reviewers, I think that's largely wasted effort.

Joe

---

From: Joe Touch <[email-masked]>
Date: Sun, 19 Jun 2016 20:22:00 -0700

On 6/19/2016 7:25 PM, Xuxiaohu wrote:
> ...
A partial deployment of GUE (which is what you're describing) doesn't
qualify as a distinct service.

Joe

---

From: Xuxiaohu <[email-masked]>
Date: Mon, 20 Jun 2016 04:04:45 +0000

> Sent: Monday, June 20, 2016 11:14 AM
> > Sure. That's why we usually need to determine a WG which is more
> > suitable for a given draft firstly in the IETF. If you firmly believe
> > the more suitable WG for draft-ietf-nvo3-gue is NVO3, rather than
> > INTAREA and TSVWG, please give your rationale
> 
> My rationale is simple - it's sufficient and that's where it already is a WG doc.

There was a famous saying: " it's never too late to mend!"

> If that were not the case, you'd have a stronger argument.

It has been said clearly before, " this draft itself has nothing to do with the multi-tenancy capability which is the focus of the NOV3 current charter. 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. 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).
+++++++++
	- stronger checksums

	- fragmentation support

++++++++++"

Xiaohu

> But I really don't care all that much. If the chairs want to shift WGs, then they
> can make the case for a call for adoption elsewhere.
> 
> However, given the substantial review this doc has already received both here
> and from TSV reviewers, I think that's largely wasted effort.
> 
> Joe

---

From: Joe Touch <[email-masked]>
Date: Sun, 19 Jun 2016 23:29:15 -0500

> On Jun 19, 2016, at 11:04 PM, Xuxiaohu <[email-masked]> wrote:
> 

Let's start with the assumption that gue will happen and that udp-in-ip won't as either an RFC or a separate port. 

Now, is there really something to mend?

Or is this not really about gue?

Joe

---

From: Xuxiaohu <[email-masked]>
Date: Mon, 20 Jun 2016 06:23:31 +0000

> Sent: Monday, June 20, 2016 12:29 PM
> To: Xuxiaohu
> Cc: Tom Herbert; [email-masked]; [email-masked]

Seems meaningless to make that assumption, IMHO.

> Now, is there really something to mend?

Yes, according to the motivation for GUE as described in section 7 of draft-ietf-nvo3-gue (i.e., being a generic UDP-based tunneling technology), it'd better to find a more suitable WG to pursue this work.

Xiaohu