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

From: [email-masked]
Date: Mon, 02 Jul 2018 15:54:16 -0700

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

        Title           : Geneve: Generic Network Virtualization Encapsulation
        Authors         : Jesse Gross
                          Ilango Ganga
                          T. Sridhar
	Filename        : draft-ietf-nvo3-geneve-07.txt
	Pages           : 29
	Date            : 2018-07-02

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 are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-nvo3-geneve-07
https://datatracker.ietf.org/doc/html/draft-ietf-nvo3-geneve-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-nvo3-geneve-07

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/

---

From: "Ganga, Ilango S" <[email-masked]>
Date: Mon, 2 Jul 2018 23:36:21 +0000

Hi All,

We refreshed the draft-ietf-nvo3-geneve with the following changes:
1. Clarification on the behavior of transit devices
2. Updated the security considerations section per BCP 72 guidelines, with references
3. Updated option class assignments table

Regards,
Ilango

-----Original Message-----
From: nvo3 [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, July 2, 2018 3:54 PM
To: [email-masked]
Cc: [email-masked]
Subject: [nvo3] I-D Action: draft-ietf-nvo3-geneve-07.txt

Abstract:

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.

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

---

From: Tal Mizrahi <[email-masked]>
Date: Tue, 3 Jul 2018 10:04:33 +0300

Hi Ilango,

Thanks for updating the draft.

A few comments about the latest version:

1. "Options or their ordering, MUST NOT be changed by transit devices."
    I agree that the order must not be changed, but this sentence also
requires that the options will not be changed. I believe in some cases it
may be useful for options to be changed, such as IOAM. I would suggest the
following text instead:
    "The order of options MUST NOT be changed by transit devices."
2. The new security text is very detailed and informative, but I believe
there is a problematic usage of "MUST" requirements.
    - "An NVE, used in multi-tenant environments, MUST have the capability
to encrypt the tenant data end to end between the NVEs."
        => This is a requirement for implementers, but it is not detailed
and specific enough to define what implementers need to implement, and it
is not defined in a way that allows interoperability between different
implementers.
        Moreover, the word MUST does not seem appropriate here.
        Indeed, there should be text that talks about the importance of
encryption, but it is up to the operator whether encryption is required or
not, based on a system-specific threat analysis.
        We should refrain from having MUST requirements that are not
required by all operators, and are too vague to follow.
        Specifically, I suggest to remove the following sentences:
    - "An NVE, used in multi-tenant environments, MUST have the capability
to encrypt the tenant data end to end between the NVEs."
    - "a Geneve NVE MUST have the capability to protect the integrity of
Geneve packets including packet headers, options and payload on
communications between NVE pairs."
    - "a Geneve NVE MUST support an Authentication mechanism"

Thanks,
Tal.

On Tue, Jul 3, 2018 at 2:36 AM, Ganga, Ilango S <[email-masked]>
wrote:

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