Subject: Re: [nvo3] I-D Action: draft-ietf-nvo3-geneve-04.txt

From: Dave Dolson <[email-masked]>
Date: Wed, 19 Jul 2017 14:01:25 +0000

This document shows IPv6 encapsulation, but provides no guidance about setting the Outer IPv6 flow label.
I would expect the flow label to be described with similar language to the UDP source port, since Flow Label is the obvious way to load-balance traffic across links.

Also, I don't know why the Outer Ethernet header is specified in the packet format. I think the Outer IPv4 could be carried in any link-layer or pseudo-wire. Or is the intent that this encapsulation is only valid on physical Ethernet?

-Dave

-----Original Message-----
From: nvo3 [mailto:[email-masked]] On Behalf Of Ganga, Ilango S
Sent: Tuesday, March 14, 2017 6:56 AM
To: [email-masked]
Subject: Re: [nvo3] I-D Action: draft-ietf-nvo3-geneve-04.txt

Hi All,

As per the direction from the NVO3 virtual interim meeting on Mar 01, 2017, we have updated the Geneve draft to reflect the recommendations from the NVO3 Encap Design Team.

Regards,
Ilango

-----Original Message-----
From: nvo3 [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, March 13, 2017 2:56 PM
To: [email-masked]
Cc: [email-masked]
Subject: [nvo3] I-D Action: draft-ietf-nvo3-geneve-04.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Virtualization Overlays of the IETF.

        Title           : Geneve: Generic Network Virtualization Encapsulation
        Authors         : Jesse Gross
                          Ilango Ganga
                          T. Sridhar
	Filename        : draft-ietf-nvo3-geneve-04.txt
	Pages           : 26
	Date            : 2017-03-13

Abstract:
   Network virtualization involves the cooperation of devices with a
   wide variety of capabilities such as software and hardware tunnel
   endpoints, transit fabrics, and centralized control clusters.  As a
   result of their role in tying together different elements in the
   system, the requirements on tunnels are influenced by all of these
   components.  Flexibility is therefore the most important aspect of a
   tunnel protocol if it is to keep pace with the evolution of the
   system.  This draft describes Geneve, a protocol designed to
   recognize and accommodate these changing capabilities and needs.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-nvo3-geneve/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-nvo3-geneve-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-nvo3-geneve-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/

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

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

---

From: Dan Wing <[email-masked]>
Date: Wed, 19 Jul 2017 19:29:33 +0000

> On Jul 19, 2017, at 7:01 AM, Dave Dolson <[email-masked]> wrote:
> 

See recent discussion on IPv6 flow label before/after https://www.ietf.org/mail-archive/web/nvo3/current/msg06192.html.

-d

> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dnvo3-2Dgeneve_&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=IMDU0f3LtPMQf5XkZ06fNg&m=c1ucx0nQYX9aNIHlbBuNBPkLaXdfqUReErSxsEbyvKQ&s=jl8mAMv9fc56a9uC-yCIvpgqv0KhMzBJrS85eBojrO8&e= 
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dnvo3-2Dgeneve-2D04&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=IMDU0f3LtPMQf5XkZ06fNg&m=c1ucx0nQYX9aNIHlbBuNBPkLaXdfqUReErSxsEbyvKQ&s=Om_KsrOpgl0eSZslhSg1NJKca_DKHWIYhzTcox3oUWE&e= 
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dnvo3-2Dgeneve-2D04&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=IMDU0f3LtPMQf5XkZ06fNg&m=c1ucx0nQYX9aNIHlbBuNBPkLaXdfqUReErSxsEbyvKQ&s=8sN33BmwNDw6L-WqsBTd6iir0yFZwwc3aV02Hhk2U4I&e= 
> 
> 
> https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_internet-2Ddrafts_&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=IMDU0f3LtPMQf5XkZ06fNg&m=c1ucx0nQYX9aNIHlbBuNBPkLaXdfqUReErSxsEbyvKQ&s=q5sfpOsCL35peVBp35W-sWqGHn2h_ZbVD-sC9XCPnkw&e= 
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_nvo3&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=IMDU0f3LtPMQf5XkZ06fNg&m=c1ucx0nQYX9aNIHlbBuNBPkLaXdfqUReErSxsEbyvKQ&s=QM_nHIi2lR4qv4GDPGfly1LGEtEwdId1jwKUSe27U4g&e= 
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_nvo3&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=IMDU0f3LtPMQf5XkZ06fNg&m=c1ucx0nQYX9aNIHlbBuNBPkLaXdfqUReErSxsEbyvKQ&s=QM_nHIi2lR4qv4GDPGfly1LGEtEwdId1jwKUSe27U4g&e= 
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_nvo3&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=IMDU0f3LtPMQf5XkZ06fNg&m=c1ucx0nQYX9aNIHlbBuNBPkLaXdfqUReErSxsEbyvKQ&s=QM_nHIi2lR4qv4GDPGfly1LGEtEwdId1jwKUSe27U4g&e=

---

From: Dave Dolson <[email-masked]>
Date: Wed, 19 Jul 2017 20:21:52 +0000

That email doesn't provide a very satisfying answer.
Even if flow label is not observed, it wouldn't hurt to set it properly.
In this tussle, flow labels are going to have to be set before any equipment uses them.

-----Original Message-----
From: Dan Wing [mailto:[email-masked]] 
Sent: Wednesday, July 19, 2017 9:30 PM
To: Dave Dolson
Cc: Ganga, Ilango S; [email-masked]
Subject: Re: [nvo3] I-D Action: draft-ietf-nvo3-geneve-04.txt

-d

---

From: Dan Wing <[email-masked]>
Date: Wed, 19 Jul 2017 20:54:31 +0000

> In this tussle, flow labels are going to have to be set before any equipment uses them.

Agreed on all 3 points of your points.

My (implied) point is that IPv6 nodes can't rely solely on flow label, but need to also hash flow information into UDP source port (like VXLAN does) to deal with:
  o IPv6 equipment that does not (yet) examine flow label, and 
  o NAT64 where the v4 network needs to benefit from ECMP and the v4 receiver needs to benefit from CPU balancing.

-d

> See recent discussion on IPv6 flow label before/after https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_nvo3_current_msg06192.html&d=DwIFAg&c=uilaK90D4TOVoH58JNXRgQ&r=IMDU0f3LtPMQf5XkZ06fNg&m=yX05JotFPhiCz3lyg97M_zlqpQa2-KUBs6zMQ2JhMus&s=URnITYl9Mhs0TUJ7CNT2SzTC88A45ACri7hgPDzHtFM&e= .
> 
> -d
> 
> 
>>