Skip to main content

Geneve: Generic Network Virtualization Encapsulation
draft-ietf-nvo3-geneve-16

Revision differences

Document history

Date Rev. By Action
2020-11-03
16 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2020-09-24
16 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2020-06-30
16 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2020-06-01
16 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2020-06-01
16 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2020-06-01
16 (System) IANA Action state changed to In Progress from Waiting on Authors
2020-05-28
16 (System) IANA Action state changed to Waiting on Authors from In Progress
2020-05-27
16 (System) IANA Action state changed to In Progress from Waiting on Authors
2020-05-04
16 (System) IANA Action state changed to Waiting on Authors from In Progress
2020-05-01
16 (System) IANA Action state changed to In Progress from Waiting on Authors
2020-05-01
16 (System) IANA Action state changed to Waiting on Authors from In Progress
2020-04-28
16 (System) RFC Editor state changed to EDIT
2020-04-28
16 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2020-04-28
16 (System) Announcement was received by RFC Editor
2020-04-28
16 (System) IANA Action state changed to In Progress
2020-04-28
16 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2020-04-28
16 Amy Vezza IESG has approved the document
2020-04-28
16 Amy Vezza Closed "Approve" ballot
2020-04-28
16 Martin Vigoureux IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2020-04-28
16 Martin Vigoureux Ballot approval text was generated
2020-04-27
16 Benjamin Kaduk [Ballot comment]
Thank you for addressing my Discuss points!
2020-04-27
16 Benjamin Kaduk [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss
2020-03-18
16 Alissa Cooper
[Ballot comment]
The Contact in Section 7 should be iesg@ietf.org, not chair@ietf.org. The chair email address is a spam magnet where things will …
[Ballot comment]
The Contact in Section 7 should be iesg@ietf.org, not chair@ietf.org. The chair email address is a spam magnet where things will get lost.
2020-03-18
16 Alissa Cooper [Ballot Position Update] Position for Alissa Cooper has been changed to No Objection from Discuss
2020-03-07
16 Ilango Ganga New version available: draft-ietf-nvo3-geneve-16.txt
2020-03-07
16 (System) New version approved
2020-03-07
16 (System) Request for posting confirmation emailed to previous authors: Jesse Gross , "T. Sridhar" , Ilango Ganga
2020-03-07
16 Ilango Ganga Uploaded new revision
2020-03-04
15 Mirja Kühlewind
[Ballot comment]
Thanks for addressing my process discuss and also my comments!

One more comment on the port assignment though: I think it would be …
[Ballot comment]
Thanks for addressing my process discuss and also my comments!

One more comment on the port assignment though: I think it would be better to only list the new assignment information (and not have the old data written in stone in this RFC), e.g. like this:

  IANA has allocated UDP port 6081 in the Service Name and Transport Protocol
  Port Number Registry [IANA-SN] as the well-known destination port
  for Geneve based on early registration.

  Upon publication of this document, this registration will have its
  reference changed to cite this document [RFC-to-be] and inline with
  [RFC6335] the Assignee and Contact of the port entry should be
  changed to IESG  and IETF Chair
  respectively:

  Service Name: geneve
  Transport Protocol(s): UDP
  Assignee: IESG 
  Contact: IETF Chair
  Description: Generic Network Virtualization Encapsulation (Geneve)
  Reference: [RFC-to-be]
  Port Number: 6081
2020-03-04
15 Mirja Kühlewind [Ballot Position Update] Position for Mirja Kühlewind has been changed to No Objection from Discuss
2020-03-03
15 Roman Danyliw
[Ballot comment]
Thank you for addressing my DISCUSS point.

I support Ben Kaduk’s DISCUSS position.  To reiterate part of his write-up, the role of the …
[Ballot comment]
Thank you for addressing my DISCUSS point.

I support Ben Kaduk’s DISCUSS position.  To reiterate part of his write-up, the role of the transit device which is only permitted to inspect the geneve traffic isn’t clear, especially if end-to-end security is applied.  RFC7365 didn’t provide insight into this architectural element.
2020-03-03
15 Roman Danyliw [Ballot Position Update] Position for Roman Danyliw has been changed to No Objection from Discuss
2020-03-02
15 Magnus Westerlund [Ballot comment]
Thanks for addressing my issue.
2020-03-02
15 Magnus Westerlund [Ballot Position Update] Position for Magnus Westerlund has been changed to No Objection from Discuss
2020-03-01
15 Suresh Krishnan [Ballot comment]
Thanks for addressing my DISCUSS and COMMENT points.
2020-03-01
15 Suresh Krishnan [Ballot Position Update] Position for Suresh Krishnan has been changed to No Objection from Discuss
2020-03-01
15 Barry Leiba [Ballot comment]
Version -15 addresses my DISCUSS and comments; thanks.
2020-03-01
15 Barry Leiba [Ballot Position Update] Position for Barry Leiba has been changed to No Objection from Discuss
2020-02-29
15 Éric Vyncke
[Ballot comment]
Thank you for version -15 that addresses my DISCUSS and most of my COMMENTs. They are kept below for history

---- Original DISCUSS …
[Ballot comment]
Thank you for version -15 that addresses my DISCUSS and most of my COMMENTs. They are kept below for history

---- Original DISCUSS and COMMENTs ---
Thank you for the work put into this document. It solves an interesting problem and the document is easy to read.

I have one DISCUSS that is **trivial to fix** and some COMMENTs, feel free to ignore my COMMENTs even if  I would appreciate your answers to those COMMENTs.

Regards,

-éric

== DISCUSS ==

-- Section 3.3 --
Please use RFC 8200 the 'new' IPv6 standard rather than RFC 2460 ;-)


== COMMENTS ==

-- Generic --
Is it worth mentioning that when transporting an Ethernet frame neither the preamble nor the inter-frame gap are included? (AFAIR, IEEE considers those parts as integral part of the IEEE 802.3 frame)

Is a length of 24 bits for the VNI be enough?

-- Section 1 --
In the list of protocols, rather than presenting the current list as comprehensive, I would suggest to clearly present this list as non-exhaustive.

Is it worth to mention the reasoning behind "one additional defining requirement is the need to carry system state along with the packet data" (beside common sense)

-- Section 4.4.1 --
It is unclear to me whether Geneve endpoints can fragment the Geneve UDP-encapsulated packet itself as the transit routers see only unfragmentable packets.
2020-02-29
15 Éric Vyncke [Ballot Position Update] Position for Éric Vyncke has been changed to No Objection from Discuss
2020-02-29
15 (System) Sub state has been changed to AD Followup from Revised ID Needed
2020-02-29
15 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2020-02-29
15 Ilango Ganga New version available: draft-ietf-nvo3-geneve-15.txt
2020-02-29
15 (System) New version approved
2020-02-29
15 (System) Request for posting confirmation emailed to previous authors: "T. Sridhar" , Ilango Ganga , Jesse Gross
2020-02-29
15 Ilango Ganga Uploaded new revision
2019-12-05
14 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2019-12-05
14 Magnus Westerlund
[Ballot discuss]
I want to discuss the implications of the source port usage and if that needs a bit more consideration of failure cases and …
[Ballot discuss]
I want to discuss the implications of the source port usage and if that needs a bit more consideration of failure cases and ICMP. So Section 3.3 says:

  Source port:  A source port selected by the originating tunnel
      endpoint.  This source port SHOULD be the same for all packets
      belonging to a single encapsulated flow to prevent reordering due
      to the use of different paths.  To encourage an even distribution
      of flows across multiple links, the source port SHOULD be
      calculated using a hash of the encapsulated packet headers using,
      for example, a traditional 5-tuple.  Since the port represents a
      flow identifier rather than a true UDP connection, the entire
      16-bit range MAY be used to maximize entropy.

I think using the different source ports to enable flow hashing is a nice idea. However, I am a bit worried over the implications of using the full 16-bit range without caveats. Specifically in cases where a network error or other failure to forward the Geneve encapsulated packet and that result in any form a return traffic towards the tunnel ingress. Such as ICMP Packet Too Big messages or Port / Host unreachable. These messages needs to be consumed by the Geneve tunneling endpoint to affect the right response to them. However, if the source port is corresponding to any port where there exist a listenser or bi-directional server on the tunnel ingress host, such as SSH, Echo etc. the ICMP messages may be consumed by the wrong entity that only filter on source port and not the destination port.

I believe this issue may require at least a explicit consideration in the document.

Otherwise thanks for thinking through many transport issues for tunnels.
2019-12-05
14 Magnus Westerlund [Ballot Position Update] New position, Discuss, has been recorded for Magnus Westerlund
2019-12-05
14 Suresh Krishnan
[Ballot comment]
I support Ben's DISCUSS position and I would like to ensure that the concerns brought up regarding transit devices and UDP zero checksums …
[Ballot comment]
I support Ben's DISCUSS position and I would like to ensure that the concerns brought up regarding transit devices and UDP zero checksums are resolved. I would also like to ensure that RFC8200 is used as the reference for the IPv6 protocol as stated in Eric's DISCUSS.

* Section 3.3

Have you considered the use of the flow label instead of source port for  in the IPv6 tunnel case? I highly recommend looking at [RFC6438] for further details as it is specifically addresses ECMP for IP-in-IPv6 tunneled traffic.
2019-12-05
14 Suresh Krishnan Ballot comment text updated for Suresh Krishnan
2019-12-05
14 Suresh Krishnan
[Ballot discuss]
* Section 3.3.

This might be an easy DISCUSS to resolve. Since the specification requires the Destination port to be configurable, it is …
[Ballot discuss]
* Section 3.3.

This might be an easy DISCUSS to resolve. Since the specification requires the Destination port to be configurable, it is not clear to me how the "transit" devices will identify Geneve packets being sent to a non-default port (i.e. not 6081). Can you please clarify?
2019-12-05
14 Suresh Krishnan
[Ballot comment]
I support Ben's DISCUSS position and I would like to ensure that the concerns brought up regarding transit devices and UDP zero checksums …
[Ballot comment]
I support Ben's DISCUSS position and I would like to ensure that the concerns brought up regarding transit devices and UDP zero checksums are resolved. I would also like to ensure that RFC8200 is used as the reference for the IPv6 protocol as stated in Eric's discuss.

* Section 3.3

Have you considered the use of the flow label instead of source port for  in the IPv6 tunnel case? I highly recommend looking at [RFC6438] for further details as it is specifically addresses ECMP for IP-in-IPv6 tunneled traffic.
2019-12-05
14 Suresh Krishnan [Ballot Position Update] New position, Discuss, has been recorded for Suresh Krishnan
2019-12-04
14 Adam Roach
[Ballot comment]
Thanks for the work that went into consolidating network tunneling protocols
into a single, unified design. I have one comment that I think …
[Ballot comment]
Thanks for the work that went into consolidating network tunneling protocols
into a single, unified design. I have one comment that I think is rather
important to Geneve's success.

In fact, I'm on the wall about whether this comment should be a DISCUSS, since
I think the current design will render Geneve broadly unusable in a number of
important use-cases.

>  Dest port:  IANA has assigned port 6081 as the fixed well-known
>    destination port for Geneve.  Although the well-known value should
>    be used by default, it is RECOMMENDED that implementations make
>    this configurable.  The chosen port is used for identification of
>    Geneve packets and MUST NOT be reversed for different ends of a
>    connection as is done with TCP.

This behavior -- using 6081 as the destination in both directions -- has the
unfortunate property of violating NAT and Firewall assumptions about the
nature of UDP traffic (see RFC 4748 for a discussion of UDP behavior in NATs).
For example, while RTP was originally specified to typically work in the way
described here (using two unrelated unidirectional flows when a bidirectional
flow was desired), all (or nearly all) modern implementations use a technique
known as "symmetric RTP" (see RFC 4961), which uses port numbers in the same
way as TCP does.

I can't find any discussion of NAT traversal in this document. One might
assume that such responsibility is delegated to the control plane, but it
should be noted that this specific requirement is going to frustrate every NAT
traversal technique that I'm aware of (save for the mostly undeployed NAT-PMP
and similar approaches), regardless of how well-designed the control plane is.

If the working group has already considered NAT/Firewall traversal and decided
to use the specified design anyway [1], please add text laying out the
rationale in this document. If this point has not yet been discussed, I urge
the working group to withdraw its request for publication and to carefully
reconsider the implications of this specific normative requirement.

(I take the point about the design being applicable to "controlled networks,"
but that doesn't necessarily imply the absence of a NAT or a non-NAT Firewall;
and, as Roman notes in his DISCUSS, the applicability statement appears to be
overstated anyway: if crossing public networks -- as this document clearly
anticipates -- using IPv4, the presence of a CG-NAT device will become
increasingly likely as time goes on.)

____
[1] I searched mailarchive.ietf.org and found no such discussion, but did
    not search meeting minutes
2019-12-04
14 Adam Roach [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach
2019-12-04
14 Barry Leiba
[Ballot discuss]
This will be trivial to address:

— Section 1.2 —

  The NVO3 framework [RFC7365] defines many of the concepts commonly …
[Ballot discuss]
This will be trivial to address:

— Section 1.2 —

  The NVO3 framework [RFC7365] defines many of the concepts commonly
  used in network virtualization.

Indeed, and it seems a critical normative reference here.  So why is it in the informative section?
2019-12-04
14 Barry Leiba
[Ballot comment]
I support Ben’s DISCUSS and comments.  In addition:

— Section 3.3 —
In the description of the UDP Checksum, the first paragraph says …
[Ballot comment]
I support Ben’s DISCUSS and comments.  In addition:

— Section 3.3 —
In the description of the UDP Checksum, the first paragraph says the checksum MUST be set for v6, then the second paragraph contradicts that.  You really should note when the MUST is specified that there are exceptions.

— Section 3.5 —
In the description of the Type field, I believe it confuses things to say that it’s 8 bits, and then to say that the first bit is not really part of the type, but has a special meaning.  Why do you not show the C bit and Type field in the main diagram as it is shown in the mini-figure, describe the C bit separately, and define the Type field as 7 bits?
2019-12-04
14 Barry Leiba [Ballot Position Update] New position, Discuss, has been recorded for Barry Leiba
2019-12-04
14 Roman Danyliw
[Ballot discuss]
(1) The threat model assumed by geneve appears to be expressed in conflicting ways.  Section 4.1 notes that RFC8085’s definition of “controlled …
[Ballot discuss]
(1) The threat model assumed by geneve appears to be expressed in conflicting ways.  Section 4.1 notes that RFC8085’s definition of “controlled environment” applies.  However,

- Section 6 notes “When crossing an untrusted link, such as the public Internet, …”

- Section 6.1 notes “Geneve data traffic between tenant systems across such separated networks should be protected from threats when traversing public networks. Any Geneve overlay data leaving the data center network beyond the operator's security domain SHOULD be secured by encryption mechanisms such as IPsec or other VPN mechanisms to protect the communications between the NVEs when they are geographically separated over untrusted network links.” 

The advice provided in Section 6.x is sound.  Nevertheless, it doesn’t appear to describe a “controlled environment”.

(2) Section 6.  Per “Compromised tunnel endpoints may also spoof identifiers in the tunnel header to gain access to networks owned by other tenants”, couldn’t compromised transit devices do the same?

(3) Section 6.1.  Similar to what is discussed in Section 6.2 (for integrity), please refer to the impact of a compromised node on confidentiality.  For example (not verbatim) “A compromised network node or a transit device within a data center may passively monitor Geneve packet data between NVEs; or route traffic for further inspection.”

(4) Section 6.1.  Per “Due to the nature of multi-tenancy in such environments, a tenant system may expect data confidentiality to ensure its packet data is not tampered with (active attack) in transit or a target of unauthorized monitoring (passive attack).”, please provide additional precision on the confidentiality. It is only relative to other tenants, but not from the provider (who can engage in tampering and passive monitoring).
2019-12-04
14 Roman Danyliw
[Ballot comment]
I support Ben Kaduk’s DISCUSS position.  To reiterate part of his write-up, the role of the transit device which is only permitted to …
[Ballot comment]
I support Ben Kaduk’s DISCUSS position.  To reiterate part of his write-up, the role of the transit device which is only permitted to inspect the geneve traffic isn’t clear, especially if end-to-end security is applied.  RFC7365 didn’t provide insight into this architectural element.
2019-12-04
14 Roman Danyliw [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw
2019-12-04
14 Benjamin Kaduk
[Ballot discuss]
This first point is a "discuss discuss" for which I'd like to get a
sense of what the rest of the IESG feels.  …
[Ballot discuss]
This first point is a "discuss discuss" for which I'd like to get a
sense of what the rest of the IESG feels.  I've read the discussion at
https://mailarchive.ietf.org/arch/msg/last-call/ywRKREnxWAlunHR7MSaTM4ScsDs
but I'm left with a similar sense of uncertainty that Daniel has as to
whether the question is fully resolved.  Specifically, "the question"
that I have in mind is to what extent the Geneve architecture includes
support for middleboxes that inspect (but do not modify!) the Geneve
header and inner payload, to what extent the Geneve architecture is
intended to be applicable to scenarios where (end-to-end per-tunnel)
underlay confidentiality protection is necessary, and whether those
requirements are both strong enough to be deemed an internal
inconsistency of requirements/applicability.  "Interposing advanced
middleboxes" and "service interposition" are conceived as possible uses
for Geneve metadata in Sections 1 and 2.2 as a consideration for why
structured tagging is needed on the data plane and not just the control
plane, which to me suggests that such usage is considered a first-class
use case for Geneve.  Section 6.1.1 discusses encryption for traffic
traversing untrusted links between geographically separated data
centers (though perhaps in this case an encrypted tunnel would be used
just for that untrusted transit and leaving the in-datacenter traffic
visible to middleboxes), but Section 6.1 discusses cases where the tenant
may expect the service provider to provide confidentiality as part of
the service.  Would this be above or below the Geneve encapsulation?
Might some customers insist on one or the other?  The consideration from
Section 6.1 that the provider of the underlay and the provider of the
overlay may not be the same could be taken to imply that the overlay
provider itself wants (cryptographic) protection from the underlay
provider.  I don't have a clear picture of how these considerations
interact.  (I also note that, since DTLS is mentioned, DTLS 1.3 is going
the way of TLS 1.3 and not defining any authentication-only
ciphersuites, so if authentication-only service is desired, DTLS may not
be the way of the future, leaving IPsec AH as the leading candidate.)

Some other section-by-section discuss-level points follow, mostly
self-contained/localized issues.

Section 3.5.1

  o  Some options may be defined in such a way that the position in the
      option list is significant.  Options MUST NOT be changed by
      transit devices.

  o  An option SHOULD NOT be dependent upon any other option in the
      packet, i.e., options can be processed independently of one
      another.  [...]

As was already noted, I don't see how these two requirements are
self-consistent.

  size.  A particular option is specified to have either a fixed
  length, which is constant, or a variable length, which may change
  over time or for different use cases.  This property is part of the
  definition of the option and conveyed by the 'Type'.  For fixed

This text is written as if this specification is going to specify
further substructure for the "Type", with respect to certain types that
have fixed length and others that may vary.  Otherwise the property
would be attached to the option value and not the type value, in my
understanding.  With the current way the registry is laid out it seems
like we need to explicitly say that the entity allocating the option
class value needs to specify the interpretation of the 'type' field when
used with that option class.

Section 4.3.1

  2.  If Geneve is used with zero UDP checksum over IPv6 then such
      tunnel endpoint implementation MUST meet all the requirements
      specified in section 4 of [RFC6936] and requirements 1 as
      specified in section 5 of [RFC6936].

This seems to implicitly be saying that the other numbered requirements
in Section 5 of RFC 6936 can be ignored, which is updating the behavior
of a standards-track document.  We need to either be explicit about the
update or justify why (the rest of) that applicability statement is not
applicable here.  If, as the paragraph following the enumerated list
says, the requirements specified in RFC 6936 continue to apply in full,
why do we need to call out a MUST-level requirement here?

  4.  The Geneve tunnel endpoint that encapsulates the tunnel MAY use
      different IPv6 source addresses for each Geneve tunnel that uses
      Zero UDP checksum mode in order to strengthen the decapsulator's
      check of the IPv6 source address (i.e the same IPv6 source
      address is not to be used with more than one IPv6 destination
      address, irrespective of whether that destination address is a
      unicast or multicast address).  When this is not possible, it is
      RECOMMENDED to use each source address for as few Geneve tunnels
      that use zero UDP checksum as is feasible.

This functionality is not usable without some mechanism to signal from
encapsulator to decapsulator that it is in use.

  The requirement to check the source IPv6 address in addition to the
  destination IPv6 address, [...]

I do not see this specified as a requirement, only a MAY-level
suggestion.

Section 4.6

  o  When performing LSO, a NIC MUST replicate the entire Geneve header
      and all options, including those unknown to the device, onto each
      resulting segment.  However, a given option definition may
      override this rule and specify different behavior in supporting
      devices.  [...]

This second sentence makes the MUST in the first no longer a MUST.
2019-12-04
14 Benjamin Kaduk
[Ballot comment]
Section 2.2.1

  recipient.  As new functionality becomes sufficiently well defined to
  add to tunnel endpoints, supporting options can be designed using …
[Ballot comment]
Section 2.2.1

  recipient.  As new functionality becomes sufficiently well defined to
  add to tunnel endpoints, supporting options can be designed using
  ordering restrictions and other techniques to ease parsing.

I'm having trouble parsing the second half of this sentence -- what does
"supporting options" mean as a noun?

  Further, either tunnel endpoints or transit devices MAY use offload
  capabilities of NICs such as checksum offload to improve the
  performance of Geneve packet processing.  The presence of a Geneve
  variable length header SHOULD NOT prevent the tunnel endpoints and
  transit devices from using such offload capabilities.

I agree with the directorate reviewer that this implementation guidance
is unenforcable as normative keywords.

Section 3.1, 3.2

If we're going to give concrete values for the IPv4 protocol/IPv6
NextHeader (17) and destination port (6081), shouldn't we also use the
concreve value for Geneve protocol type (0x6558) that corresponds to the
inner ethernet frame?

I'd also suggest some visual distinction that the "Variable Length
Options" do in fact have variable length, perhaps using the '~'
character in vertical lines.
Similarly, the original ethernet payload need not be 4-byte-aligned and
the figure could make that more prominent.

It's a little awkward to expand FCS on second usage, not first usage.

Section 3.4

      The critical bit allows hardware implementations the flexibility
      to handle options processing in the hardware fastpath or in the
      exception (slow) path without the need to process all the options.
      For example, a critical option such as secure hash to provide
      Geneve header integrity check must be processed by tunnel
      endpoints and typically processed in the hardware fastpath.

I think I'm failing to make a connection between some of these steps.
How does having a critical bit let a header integrity check happen in
the hardware fastpath while deferring other option processing to
software?

  Transit devices MUST maintain consistent forwarding behavior
  irrespective of the value of 'Opt Len', including ECMP link
  selection.  These devices SHOULD be able to forward packets
  containing options without resorting to a slow path.

There seem to be two broad aspects in play here.  First, requiring
insensitivity to "Opt Len" might be because the value would change as a
packet traverses the network.  I think this is forbidden by virtue of
transit devices not being allowed to add/delete options, but please
confirm.  Second, this affects the ability of transit devices to look
past the geneve header to the inner ethernet header and payload.  Given
the substantial discussion we've had in the broader IETF about IPv6
extension headers and the inability of hardware to examine such
variable-length chains to get to the actual upper layer protocol (with
the result that extension headers are largely unusuable on substantial
portions of the internet), it seems like we might conclude from this
statement that either we expect transit devices to not inspect the
upper-layer content or there's a significant chance that this
requirement will be ignored (possibly just by capping the 'Opt Len'
value that is supported), or both.  What makes this setup different from
IPv6 EH such that we expect hardware compliance and a usable deployment?
This is particularly poigniant given that we claim this to be a
requirement on transit devices but allow (in Section 4.5) for endpoints
to use profiles that have a restricted maximum length for the options.
If such profiles are common, the incentive for transit devices to slip
and use the lower maximum length increases.

Section 3.5

      The high order bit of the option type indicates that this is a
      critical option.  If the receiving tunnel endpoint does not
      recognize this option and this bit is set then the packet MUST be
      dropped.  If the 'C' bit (critical bit) is set in any option then
      the 'C' bit in the Geneve base header MUST also be set.  Transit
      devices MUST NOT drop packets on the basis of this bit.  The

nit: since we mention the Geneve header, one might claim that "this bit"
in "MUST NOT drop packets on the basis of this bit" is ambiguous (but
since we said this before for the Geneve header one, I assume we're
talking about the one in the Type field now).

Section 4.4.1

  It is strongly RECOMMENDED that Path MTU Discovery ([RFC1191],
  [RFC8201]) be used by setting the DF bit in the IP header when Geneve
  packets are transmitted over IPv4 (this is the default with IPv6).

Is it the default or the only specified behavior for IPv6?

Section 4.4.3

  outside of the scope of this document.  When physical multicast is in
  use, the 'C' bit in the Geneve header may be used with groups of
  devices with heterogeneous capabilities as each device can interpret
  only the options that are significant to it if they are not critical.

Please double-check this sentence, particularly the "may be used".  If
the intent is, as written, to note that the packets with the 'C' bit set
might take paths with heterogenous paths, I suggest being more explicit
about the consequences that the traffic might only be delivered to some
but not all endpoints.

Section 6

  untrusted boundaries.  In addition, tunnel endpoints should only be
  operated in environments controlled by the service provider, such as
  the hypervisor itself rather than within a customer VM.

Can you say a bit more about how this "should only be operated in
environments controlled by the service provider" meshes with the note in
Section 4.1 that "[i]t is intended for use in public or private data
center environments" (specifically the "public data center" portion) and
the note in Section 6.1 that the provider of the overlay may not be the
same as the provider of the underlay?

Section 6.1.1

  traversing public networks.  Any Geneve overlay data leaving the data
  center network beyond the operator's security domain SHOULD be
  secured by encryption mechanisms such as IPsec or other VPN
  mechanisms to protect the communications between the NVEs when they
  are geographically separated over untrusted network links.

Since we use "mechanisms" in both the IPsec clause and the "other VPN"
clause, the "encryption" does not automatically bind to both clauses
from a grammatical perspective.  Given that "VPN" is currently in use
for both encrypted and non-encrypted schemes (much to my chagrin),
please clarify that the other VPN mechanisms also need to provide
cryptographic confidentiality protection.  (Replacing "VPN mechanisms"
with "VPN technologies" would probably suffice.)

Section 6.2

  network.  To prevent such attacks, an NVE MUST NOT propagate Geneve
  packets beyond the NVE to tenant systems and SHOULD employ packet

We also care about not propagating Geneve packets from the tenant
systems past the NVE, right?

  filtering mechanisms so as not to forward unauthorized traffic
  between TSs in different tenant networks.

What does "TS" stand for, here?

Section 10.2

RFCs 1191, 2460 (er, 8200), 6040, and 8201 should be listed as normative
references.

  [ETYPES]  The IEEE Registration Authority, "IEEE 802 Numbers", 2013,
              .

Hmm, firefox claims the content of this resource is invalid XML, sigh.
2019-12-04
14 Benjamin Kaduk [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk
2019-12-04
14 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2019-12-04
14 Mirja Kühlewind
[Ballot discuss]
Thanks for the really well written document that addresses all transport related question well (and thanks to David for the early TSV review!). …
[Ballot discuss]
Thanks for the really well written document that addresses all transport related question well (and thanks to David for the early TSV review!). I only have one minor process point that need to be addressed before publication:

Inline with RFC6335 the Assignee and Contact of the port entry should also be updated to IESG  and IETF Chair  respectively.
2019-12-04
14 Mirja Kühlewind
[Ballot comment]
1) One small comment/question on the editorial note in sec 4.4.1:
"It was discussed during TSVART early review if the level of
  …
[Ballot comment]
1) One small comment/question on the editorial note in sec 4.4.1:
"It was discussed during TSVART early review if the level of
  requirement for maintaining tunnel MTU at the ingress has to be "MAY"
  or "SHOULD".  The discussion concluded that it was appropriate to
  leave this as "MAY", considering the high level of state to be
  maintained.
I would have preferred a SHOULD and I'm not sure I understand what state your are talking about...?

2) And one more small question on sec 4.4.1. in general:
Is the assumption that all tunnel packets have the same options (and therefore same Geneve header length) at a certain ingress, or should the announced MTU always consider the maximum length that a certain ingress could produce. Would be good to clarify this in the document!

3) Section 6:
"When crossing an untrusted link, such as the public Internet, IPsec
  [RFC4301] may be used to provide authentication and/or encryption of
  the IP packets formed as part of Geneve encapsulation."
Should this maybe be a normative SHOULD and not a lower case "may"?

3) And one random thought on the protocol design (given we all love to design protocols :-) ): Was it considered to require to have critical options first in order to speed up processing?
2019-12-04
14 Mirja Kühlewind Ballot comment and discuss text updated for Mirja Kühlewind
2019-12-04
14 Éric Vyncke
[Ballot discuss]
Thank you for the work put into this document. It solves an interesting problem and the document is easy to read.

I have …
[Ballot discuss]
Thank you for the work put into this document. It solves an interesting problem and the document is easy to read.

I have one DISCUSS that is **trivial to fix** and some COMMENTs, feel free to ignore my COMMENTs even if  I would appreciate your answers to those COMMENTs.

Regards,

-éric

== DISCUSS ==

-- Section 3.3 --
Please use RFC 8200 the 'new' IPv6 standard rather than RFC 2460 ;-)
2019-12-04
14 Éric Vyncke
[Ballot comment]
== COMMENTS ==

-- Generic --
Is it worth mentioning that when transporting an Ethernet frame neither the preamble nor the inter-frame gap …
[Ballot comment]
== COMMENTS ==

-- Generic --
Is it worth mentioning that when transporting an Ethernet frame neither the preamble nor the inter-frame gap are included? (AFAIR, IEEE considers those parts as integral part of the IEEE 802.3 frame)

Is a length of 24 bits for the VNI be enough?

-- Section 1 --
In the list of protocols, rather than presenting the current list as comprehensive, I would suggest to clearly present this list as non-exhaustive.

Is it worth to mention the reasoning behind "one additional defining requirement is the need to carry system state along with the packet data" (beside common sense)

-- Section 4.4.1 --
It is unclear to me whether Geneve endpoints can fragment the Geneve UDP-encapsulated packet itself as the transit routers see only unfragmentable packets.
2019-12-04
14 Éric Vyncke [Ballot Position Update] New position, Discuss, has been recorded for Éric Vyncke
2019-12-04
14 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2019-12-03
14 Alissa Cooper
[Ballot discuss]
Exciting to see this work progressing.

Section 3.5 (and Section 7):

"Type (8 bits):  Type indicating the format of the data contained in …
[Ballot discuss]
Exciting to see this work progressing.

Section 3.5 (and Section 7):

"Type (8 bits):  Type indicating the format of the data contained in
      this option.  Options are primarily designed to encourage future
      extensibility and innovation and so standardized forms of these
      options will be defined in a separate document."
   
I'm a little confused about what is expected to happen with the option classes and types. Are all future option types in the 0x0000..0x00FF range expected to be specified in a single separate document? If not, that should be clarified. I also think there needs to be a normative requirement that such future specifications define all of the types associated with the option classes.

In the registry defined in Section 7, I think the table needs a column for the document to reference for each option class definition. That way when option classes are defined in the 0x0000..0x00FF range, implementers and operators will be able to find the reference and understand the semantics of the types. For the vendor-specific options this can be optional, but still would be nice to list if such documentation exists.
2019-12-03
14 Alissa Cooper
[Ballot comment]
Section 1:

s/Current work/Work/

What is meant by "service based context for interposing advanced middleboxes?" (I think the verb tense is tripping me …
[Ballot comment]
Section 1:

s/Current work/Work/

What is meant by "service based context for interposing advanced middleboxes?" (I think the verb tense is tripping me up -- are the middleboxes already there?)

Section 1.2:

"A transit device MAY be capable of understanding the Geneve packet
  format but does not originate or terminate Geneve packets."
 
I don't think normative MAY is appropriate here.

Section 2.1:

s/the VXLAN spec/the VXLAN spec [RFC7348]/

Section 2.2:

"Transit devices MAY be able to interpret the options"

Normative MAY is not appropriate here. The normative requirement is captured in the last sentence of the paragraph.

Section 4.6:

"Conversely, when performing LRO, a NIC MAY assume that a
      binary comparison of the options (including unknown options) is
      sufficient to ensure equality"
   
Normative MAY is not appropriate here.
2019-12-03
14 Alissa Cooper [Ballot Position Update] New position, Discuss, has been recorded for Alissa Cooper
2019-12-03
14 Mirja Kühlewind [Ballot comment]
(Still reviewing -> therefore ballot position was not sent yet)
2019-12-03
14 Mirja Kühlewind Ballot comment text updated for Mirja Kühlewind
2019-12-03
14 Mirja Kühlewind [Ballot discuss]
Inline with RFC6335 the Assignee and Contact of the port entry should also be updated to IESG  and IETF Chair  respectively.
2019-12-03
14 Mirja Kühlewind [Ballot Position Update] New position, Discuss, has been recorded for Mirja Kühlewind
2019-12-03
14 Alvaro Retana [Ballot Position Update] New position, Yes, has been recorded for Alvaro Retana
2019-11-28
14 Tal Mizrahi Request for Last Call review by RTGDIR Completed: Has Issues. Reviewer: Tal Mizrahi.
2019-11-26
14 Amy Vezza Placed on agenda for telechat - 2019-12-05
2019-11-26
14 Martin Vigoureux IESG state changed to IESG Evaluation from Waiting for Writeup
2019-11-26
14 Martin Vigoureux Ballot has been issued
2019-11-26
14 Martin Vigoureux [Ballot Position Update] New position, Yes, has been recorded for Martin Vigoureux
2019-11-26
14 Martin Vigoureux Created "Approve" ballot
2019-11-26
14 Martin Vigoureux Ballot writeup was changed
2019-11-17
14 Sabrina Tanamal IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK
2019-11-15
14 Jean Mahoney Request for Last Call review by GENART Completed: Ready. Reviewer: Meral Shirazipour. Submission of review completed at an earlier date.
2019-11-09
14 Jean Mahoney Request for Last Call review by GENART Completed: Ready. Reviewer: Meral Shirazipour.
2019-11-07
14 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2019-11-07
14 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-nvo3-geneve-14. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-nvo3-geneve-14. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete.

First, an early registration has been made for port 6081 for UDP only in the Service Name and Transport Protocol Port Number Registry located at:

https://www.iana.org/assignments/service-names-port-numbers/

Upon publication of this document, this registration will have its reference changed to [ RFC-to-be ].

Second, a new registry is to be created called the Geneve Option Class registry.

IANA Question --> Where should this new registry be located? Should it be added to an existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols?

The registration rules for the new registry are (as defined by RFC 8126):

0x0000 - 0x00FF IETF Review
0x0100 - 0xFFEF First Come First Served
0xFFF0 - 0xFFFF Experimental Use

There are initial registrations in the new registry as follows:

+----------------+--------------------------------------+---------------+
| Option Class | Description | Reference |
+----------------+--------------------------------------+---------------+
| 0x0100 | Linux | [ RFC-to-be ] |
| 0x0101 | Open vSwitch (OVS) | [ RFC-to-be ] |
| 0x0102 | Open Virtual Networking (OVN) | [ RFC-to-be ] |
| 0x0103 | In-band Network Telemetry (INT) | [ RFC-to-be ] |
| 0x0104 | VMware, Inc. | [ RFC-to-be ] |
| 0x0105 | Amazon.com, Inc. | [ RFC-to-be ] |
| 0x0106 | Cisco Systems, Inc. | [ RFC-to-be ] |
| 0x0107 | Oracle Corporation | [ RFC-to-be ] |
| 0x0108..0x110 | Amazon.com, Inc. | [ RFC-to-be ] |
+----------------+--------------------------------------+---------------+

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2019-11-07
14 (System) IESG state changed to Waiting for Writeup from In Last Call
2019-11-06
14 Min Ye Request for Last Call review by RTGDIR is assigned to Tal Mizrahi
2019-11-06
14 Min Ye Request for Last Call review by RTGDIR is assigned to Tal Mizrahi
2019-11-06
14 Min Ye Assignment of request for Last Call review by RTGDIR to John Drake was marked no-response
2019-11-05
14 Scott Bradner Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Scott Bradner. Sent review to list.
2019-10-28
14 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Scott Bradner
2019-10-28
14 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Scott Bradner
2019-10-25
14 Min Ye Request for Last Call review by RTGDIR is assigned to John Drake
2019-10-25
14 Min Ye Request for Last Call review by RTGDIR is assigned to John Drake
2019-10-24
14 Jean Mahoney Request for Last Call review by GENART is assigned to Meral Shirazipour
2019-10-24
14 Jean Mahoney Request for Last Call review by GENART is assigned to Meral Shirazipour
2019-10-24
14 Cindy Morgan IANA Review state changed to IANA - Review Needed
2019-10-24
14 Cindy Morgan
The following Last Call announcement was sent out (ends 2019-11-07):

From: The IESG
To: IETF-Announce
CC: draft-ietf-nvo3-geneve@ietf.org, nvo3@ietf.org, Matthew Bocci , matthew.bocci@nokia.com, …
The following Last Call announcement was sent out (ends 2019-11-07):

From: The IESG
To: IETF-Announce
CC: draft-ietf-nvo3-geneve@ietf.org, nvo3@ietf.org, Matthew Bocci , matthew.bocci@nokia.com, nvo3-chairs@ietf.org, martin.vigoureux@nokia.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Geneve: Generic Network Virtualization Encapsulation) to Proposed Standard


The IESG has received a request from the Network Virtualization Overlays WG
(nvo3) to consider the following document: - 'Geneve: Generic Network
Virtualization Encapsulation'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2019-11-07. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

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 document describes Geneve, an encapsulation protocol
  designed to recognize and accommodate these changing capabilities and
  needs.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-nvo3-geneve/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-nvo3-geneve/ballot/

The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/2424/
  https://datatracker.ietf.org/ipr/2423/





2019-10-24
14 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2019-10-24
14 Martin Vigoureux Requested Last Call review by RTGDIR
2019-10-24
14 Martin Vigoureux Last call was requested
2019-10-24
14 Martin Vigoureux Ballot approval text was generated
2019-10-24
14 Martin Vigoureux Ballot writeup was generated
2019-10-24
14 Martin Vigoureux IESG state changed to Last Call Requested from AD Evaluation
2019-10-24
14 Martin Vigoureux Last call announcement was generated
2019-09-12
14 Ilango Ganga New version available: draft-ietf-nvo3-geneve-14.txt
2019-09-12
14 (System) New version approved
2019-09-12
14 (System) Request for posting confirmation emailed to previous authors: Ilango Ganga , Jesse Gross , "T. Sridhar"
2019-09-12
14 Ilango Ganga Uploaded new revision
2019-07-12
13 Martin Vigoureux IESG state changed to AD Evaluation from Publication Requested
2019-04-10
13 Matthew Bocci
draft-ietf-nvo3-geneve-13.txt

Document Shepherd Write-Up

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the …
draft-ietf-nvo3-geneve-13.txt

Document Shepherd Write-Up

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

  Standards Track.
 
  This is appropriate as the draft specifies a new data plane encapsulation
  format intended for overlay networds in NVO3 environments. It specifies
  the associated procedures as well as protocol numbers/registries.

  The intended status is properly indicated.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

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 document describes Geneve, an encapsulation protocol
  designed to recognize and accommodate these changing capabilities and
  needs.

Working Group Summary

  The document describes the Geneve encapsulation format for NVO3. NVO3
  has considered many different encapsulation formats, also including GUE
  (draft-ietf-nvo3-gue-05 and draft-ietf-intarea-gue-07), and VXLAN-GPE
  (draft-ietf-nvo3-vxlan-gpe-06). A design team was chartered to analyse
  the available encapsulations and recommend one to go forward. The
  result of this choice was Geneve, and the design team's conclusions
  are documented in draft-dt-nvo3-encap-01. These conclusions were
  accepted by the working group.

  There are two IPR declarations on the draft. These were made in 2014 prior to
  the draft being adopted as a working group draft, and the working group is
  well aware of these.
   

     
Document Quality
   
  I have no concerns about the quality of the document. I believe it represents
  WG consensus, and it has been widely reviewed and discussed on the list over a
  number of years. The choice of Geneve by the NVO3 encapsulation design team and
  as confirmed by adoption by the working group.
 
  The document has been the subject of early reviews by the Routing Area Directorate,
  Transport Area Review Team, and the Security Area Directorate. Although all
  of these review raise comments, they were all resolved with the agreement of
  the reviewers.
 
  The document also received a significant number of comments from the editor of
  a number of security drafts in NVO3. Most of these were resolved, and all comments
  were addressed on the list or as changes to the document. The most significant
    outstanding comment related to the fact that Geneve recommends using DTLS and
    IPSec for end to end security. This is not possible if transit devices that need to
  inspect the packet header. This limitation is indicated in the draft. There was
  also some discussion around the precise wording of restrictions on the order
  of processing and dependencies between options in the Geneve header, but
  no consensus to change the current text in the draft.
  There was consensus to move forward with the draft.
 
  The document does not specify any MIB changes or additions which would need
  review.

   
Personnel

  The document shepherd is Matthew Bocci (matthew.bocci@nokia.com).
  The responsible Area Director is Martin Vigoureux (martin.vigoureux@nokia.com).

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  The document shepherd reviewed v09 of the document. I had no significant technical
  comments, but I did make some editorial comments that were resolved in
  version 10.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No concerns. The document has received adequate review with significant
  discussion on the WG list. The document has
  been developed within the WG and reviewed over a period of a number of IETFs.
  The document has been the subject of early reviews by the Routing Area Directorate,
  Transport Area Review Team, and the Security Area Directorate. Although all
  of these review raise comments, they were all resolved with the agreement of
  the reviewers.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  No further review required.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  No specific concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  Each author listed in the Authors Addresses section has personally indicated that
  they are not aware of any IPR that has not already been declared in accordance
  with BCP 78 and 79.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  There are two IPR declarations on the draft. These were made in 2014 prior to
  the draft being adopted as a working group draft, and the working group is
  well aware of these. No concerns were raised during working group
  adoption or last call.


 
(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

    I am comfortable that the document represents WG consensus and has
    been reviewed by a reasonable number of active WG participants. It received a
    number of comments and significant discussion in WG last call that
    were addressed by the authors. There were no objections during last call, and
    comments were constructive and supportive of moving the draft forward.
    Prior to the WG last call, a call for interest was conducted which also demonstrated
    consensus in the value of progressing the draft.
   

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  None indicated.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

      ID-Nits passes. There is one minor comment about and obsolete informational
      reference to RFC 2460 (Obsoleted by RFC 8200). This is a case of an Internet
      Standard document obsoleting a Proposed Standard and can be fixed during the
      publication process.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  There are no relevant formal review criteria.

(13) Have all references within this document been identified as
either normative or informative?

  Yes. All references are explicitly identified as informative or normative.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  No

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

  No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  This document does not change the status of any existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  The document includes IANA actions. These are properly indicated.
  There is one requested allocation for a new UDP port (6081). This
  is already recorded in the appropriate IANA registry.
 
  There is also a request for the allocation of a new Geneve option
  class registry. This is properly indicated in the draft.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  There are no new registries requiring Expert Review.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  There are no sections containing formal language that needs reviewing.
2019-04-10
13 Matthew Bocci Responsible AD changed to Martin Vigoureux
2019-04-10
13 Matthew Bocci IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2019-04-10
13 Matthew Bocci IESG state changed to Publication Requested from I-D Exists
2019-04-10
13 Matthew Bocci IESG process started in state Publication Requested
2019-04-10
13 Matthew Bocci Tag Doc Shepherd Follow-up Underway cleared.
2019-04-10
13 Matthew Bocci
draft-ietf-nvo3-geneve-13.txt

Document Shepherd Write-Up

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the …
draft-ietf-nvo3-geneve-13.txt

Document Shepherd Write-Up

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

  Standards Track.
 
  This is appropriate as the draft specifies a new data plane encapsulation
  format intended for overlay networds in NVO3 environments. It specifies
  the associated procedures as well as protocol numbers/registries.

  The intended status is properly indicated.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

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 document describes Geneve, an encapsulation protocol
  designed to recognize and accommodate these changing capabilities and
  needs.

Working Group Summary

  The document describes the Geneve encapsulation format for NVO3. NVO3
  has considered many different encapsulation formats, also including GUE
  (draft-ietf-nvo3-gue-05 and draft-ietf-intarea-gue-07), and VXLAN-GPE
  (draft-ietf-nvo3-vxlan-gpe-06). A design team was chartered to analyse
  the available encapsulations and recommend one to go forward. The
  result of this choice was Geneve, and the design team's conclusions
  are documented in draft-dt-nvo3-encap-01. These conclusions were
  accepted by the working group.

  There are two IPR declarations on the draft. These were made in 2014 prior to
  the draft being adopted as a working group draft, and the working group is
  well aware of these.
   

     
Document Quality
   
  I have no concerns about the quality of the document. I believe it represents
  WG consensus, and it has been widely reviewed and discussed on the list over a
  number of years. The choice of Geneve by the NVO3 encapsulation design team and
  as confirmed by adoption by the working group.
 
  The document has been the subject of early reviews by the Routing Area Directorate,
  Transport Area Review Team, and the Security Area Directorate. Although all
  of these review raise comments, they were all resolved with the agreement of
  the reviewers.
 
  The document also received a significant number of comments from the editor of
  a number of security drafts in NVO3. Most of these were resolved, and all comments
  were addressed on the list or as changes to the document. The most significant
    outstanding comment related to the fact that Geneve recommends using DTLS and
    IPSec for end to end security. This is not possible if transit devices that need to
  inspect the packet header. This limitation is indicated in the draft. There was
  also some discussion around the precise wording of restrictions on the order
  of processing and dependencies between options in the Geneve header, but
  no consensus to change the current text in the draft.
  There was consensus to move forward with the draft.
 
  The document does not specify any MIB changes or additions which would need
  review.

   
Personnel

  The document shepherd is Matthew Bocci (matthew.bocci@nokia.com).
  The responsible Area Director is Martin Vigoureux (martin.vigoureux@nokia.com).

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  The document shepherd reviewed v09 of the document. I had no significant technical
  comments, but I did make some editorial comments that were resolved in
  version 10.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No concerns. The document has received adequate review with significant
  discussion on the WG list. The document has
  been developed within the WG and reviewed over a period of a number of IETFs.
  The document has been the subject of early reviews by the Routing Area Directorate,
  Transport Area Review Team, and the Security Area Directorate. Although all
  of these review raise comments, they were all resolved with the agreement of
  the reviewers.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  No further review required.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  No specific concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  Each author listed in the Authors Addresses section has personally indicated that
  they are not aware of any IPR that has not already been declared in accordance
  with BCP 78 and 79.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  There are two IPR declarations on the draft. These were made in 2014 prior to
  the draft being adopted as a working group draft, and the working group is
  well aware of these. No concerns were raised during working group
  adoption or last call.


 
(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

    I am comfortable that the document represents WG consensus and has
    been reviewed by a reasonable number of active WG participants. It received a
    number of comments and significant discussion in WG last call that
    were addressed by the authors. There were no objections during last call, and
    comments were constructive and supportive of moving the draft forward.
    Prior to the WG last call, a call for interest was conducted which also demonstrated
    consensus in the value of progressing the draft.
   

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  None indicated.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

      ID-Nits passes. There is one minor comment about and obsolete informational
      reference to RFC 2460 (Obsoleted by RFC 8200). This is a case of an Internet
      Standard document obsoleting a Proposed Standard and can be fixed during the
      publication process.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  There are no relevant formal review criteria.

(13) Have all references within this document been identified as
either normative or informative?

  Yes. All references are explicitly identified as informative or normative.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  No

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

  No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  This document does not change the status of any existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  The document includes IANA actions. These are properly indicated.
  There is one requested allocation for a new UDP port (6081). This
  is already recorded in the appropriate IANA registry.
 
  There is also a request for the allocation of a new Geneve option
  class registry. This is properly indicated in the draft.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  There are no new registries requiring Expert Review.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  There are no sections containing formal language that needs reviewing.
2019-04-09
13 Matthew Bocci
draft-ietf-nvo3-geneve-13.txt

Document Shepherd Write-Up

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the …
draft-ietf-nvo3-geneve-13.txt

Document Shepherd Write-Up

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

  Standards Track.
 
  This is appropriate as the draft specifies a new data plane encapsulation
  format intended for overlay networds in NVO3 environments. It specifies
  the associated procedures as well as protocol numbers/registries.

  The intended status is properly indicated.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

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 document describes Geneve, an encapsulation protocol
  designed to recognize and accommodate these changing capabilities and
  needs.

Working Group Summary

  The document describes the Geneve encapsulation format for NVO3. NVO3
  has considered many different encapsulation formats, also including GUE
  (draft-ietf-nvo3-gue-05 and draft-ietf-intarea-gue-07), and VXLAN-GPE
  (draft-ietf-nvo3-vxlan-gpe-06). A design team was chartered to analyse
  the available encapsulations and recommend one to go forward. The
  result of this choice was Geneve, and the design team's conclusions
  are documented in draft-dt-nvo3-encap-01. These conclusions were
  accepted by the working group.

  There are two IPR declarations on the draft. These were made in 2014 prior to
  the draft being adopted as a working group draft, and the working group is
  well aware of these.
   

     
Document Quality
   
  I have no concerns about the quality of the document. I believe it represents
  WG consensus, and it has been widely reviewed and discussed on the list over a
  number of years. The choice of Geneve by the NVO3 encapsulation design team and
  as confirmed by adoption by the working group.
 
  The document has been the subject of early reviews by the Routing Area Directorate,
  Transport Area Review Team, and the Security Area Directorate. Although all
  of these review raise comments, they were all resolved with the agreement of
  the reviewers.
 
  The document also received a significant number of comments from the editor of
  a number of security drafts in NVO3. Most of these were resolved, and all comments
  were addressed on the list or as changes to the document. The most significant
    outstanding comment related to the fact that Geneve recommends using DTLS and
    IPSec for end to end security. This is not possible if transit devices that need to
  inspect the packet header. This limitation is indicated in the draft.
  There was consensus to move forward with the draft.
 
  The document does not specify any MIB changes or additions which would need
  review.

   
Personnel

  The document shepherd is Matthew Bocci (matthew.bocci@nokia.com).
  The responsible Area Director is Martin Vigoureux (martin.vigoureux@nokia.com).

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  The document shepherd reviewed v09 of the document. I had no significant technical
  comments, but I did make some editorial comments that were resolved in
  version 10.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No concerns. The document has received adequate review with significant
  discussion on the WG list. The document has
  been developed within the WG and reviewed over a period of a number of IETFs.
  The document has been the subject of early reviews by the Routing Area Directorate,
  Transport Area Review Team, and the Security Area Directorate. Although all
  of these review raise comments, they were all resolved with the agreement of
  the reviewers.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  No further review required.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  No specific concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  Each author listed in the Authors Addresses section has personally indicated that
  they are not aware of any IPR that has not already been declared in accordance
  with BCP 78 and 79.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  There are two IPR declarations on the draft. These were made in 2014 prior to
  the draft being adopted as a working group draft, and the working group is
  well aware of these. No concerns were raised during working group
  adoption or last call.


 
(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

    I am comfortable that the document represents WG consensus and has
    been reviewed by a reasonable number of active WG participants. It received a
    number of comments and significant discussion in WG last call that
    were addressed by the authors. There were no objections during last call, and
    comments were constructive and supportive of moving the draft forward.
    Prior to the WG last call, a call for interest was conducted which also demonstrated
    consensus in the value of progressing the draft.
   

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  None indicated.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

      ID-Nits passes. There is one minor comment about and obsolete informational
      reference to RFC 2460 (Obsoleted by RFC 8200). This is a case of an Internet
      Standard document obsoleting a Proposed Standard and can be fixed during the
      publication process.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  There are no relevant formal review criteria.

(13) Have all references within this document been identified as
either normative or informative?

  Yes. All references are explicitly identified as informative or normative.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  No

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

  No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  This document does not change the status of any existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  The document includes IANA actions. These are properly indicated.
  There is one requested allocation for a new UDP port (6081). This
  is already recorded in the appropriate IANA registry.
 
  There is also a request for the allocation of a new Geneve option
  class registry. This is properly indicated in the draft.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  There are no new registries requiring Expert Review.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  There are no sections containing formal language that needs reviewing.
2019-04-05
13 Matthew Bocci
draft-ietf-nvo3-geneve-13.txt

Document Shepherd Write-Up

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the …
draft-ietf-nvo3-geneve-13.txt

Document Shepherd Write-Up

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

  Standards Track.
 
  This is appropriate as the draft specifies a new data plane encapsulation
  format intended for overlay networds in NVO3 environments. It specifies
  the associated procedures as well as protocol numbers/registries.

  The intended status is properly indicated.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

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 document describes Geneve, an encapsulation protocol
  designed to recognize and accommodate these changing capabilities and
  needs.

Working Group Summary

  The document describes the Geneve encapsulation format for NVO3. NVO3
  has considered many different encapsulation formats, also including GUE
  (draft-ietf-nvo3-gue-05 and draft-ietf-intarea-gue-07), and VXLAN-GPE
  (draft-ietf-nvo3-vxlan-gpe-06). A design team was chartered to analyse
  the available encapsulations and recommend one to go forward. The
  result of this choice was Geneve, and the design team's conclusions
  are documented in draft-dt-nvo3-encap-01. These conclusions were
  accepted by the working group.

  There are two IPR declarations on the draft. These were made in 2014 prior to
  the draft being adopted as a working group draft, and the working group is
  well aware of these.
   

     
Document Quality
   
  I have no concerns about the quality of the document. I believe it represents
  WG consensus, and it has been widely reviewed and discussed on the list over a
  number of years. The choice of Geneve by the NVO3 encapsulation design team and
  as confirmed by adoption by the working group.
 
  The document has been the subject of early reviews by the Routing Area Directorate,
  Transport Area Review Team, and the Security Area Directorate. Although all
  of these review raise comments, they were all resolved with the agreement of
  the reviewers.
 
  The document also received a significant number of comments from the editor of
  a number of security drafts in NVO3. Most of these were resolved, and all comments
  were addressed on the list or as changes to the document. The most significant
    outstanding comment related to the fact that Geneve recommends using DTLS and
    IPSec for end to end security. This is not possible if transit devices that need to
  inspect the packet header. This limitation is indicated in the draft.
  There was consensus to move forward with the draft.
 
  The document does not specify any MIB changes or additions which would need
  review.

   
Personnel

  The document shepherd is Matthew Bocci (matthew.bocci@nokia.com).
  The responsible Area Director is Martin Vigoureux (martin.vigoureux@nokia.com).

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  The document shepherd reviewed v09 of the document. I had no significant technical
  comments, but I did make some editorial comments that were resolved in
  version 10.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No concerns. The document has received adequate review with significant
  discussion on the WG list. The document has
  been developed within the WG and reviewed over a period of a number of IETFs.
  The document has been the subject of early reviews by the Routing Area Directorate,
  Transport Area Review Team, and the Security Area Directorate. Although all
  of these review raise comments, they were all resolved with the agreement of
  the reviewers.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  No further review required.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  No specific concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  Each author listed in the Authors Addresses section has personally indicated that
  they are not aware of any IPR that has not already been declared in accordance
  with BCP 78 and 79.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  There are no IPR declarations on the draft.


 
(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

    I am comfortable that the document represents WG consensus and has
    been reviewed by a reasonable number of active WG participants. It received a
    number of comments and significant discussion in WG last call that
    were addressed by the authors. There were no objections during last call, and
    comments were constructive and supportive of moving the draft forward.
    Prior to the WG last call, a call for interest was conducted which also demonstrated
    consensus in the value of progressing the draft.
   

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  None indicated.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

      ID-Nits passes. There is one minor comment about and obsolete informational
      reference to RFC 2460 (Obsoleted by RFC 8200). This is a case of an Internet
      Standard document obsoleting a Proposed Standard and can be fixed during the
      publication process.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  There are no relevant formal review criteria.

(13) Have all references within this document been identified as
either normative or informative?

  Yes. All references are explicitly identified as informative or normative.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  No

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

  No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  This document does not change the status of any existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  The document includes IANA actions. These are properly indicated.
  There is one requested allocation for a new UDP port (6081). This
  is already recorded in the appropriate IANA registry.
 
  There is also a request for the allocation of a new Geneve option
  class registry. This is properly indicated in the draft.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  There are no new registries requiring Expert Review.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  There are no sections containing formal language that needs reviewing.
2019-04-05
13 Matthew Bocci Tag Doc Shepherd Follow-up Underway set.
2019-04-05
13 Matthew Bocci IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document
2019-03-26
13 Ilango Ganga New version available: draft-ietf-nvo3-geneve-13.txt
2019-03-26
13 (System) New version approved
2019-03-26
13 (System) Request for posting confirmation emailed to previous authors: Ilango Ganga , Jesse Gross , "T. Sridhar"
2019-03-26
13 Ilango Ganga Uploaded new revision
2019-03-21
12 Yizhou Li Added to session: IETF-104: nvo3  Thu-1050
2019-03-11
12 Ilango Ganga New version available: draft-ietf-nvo3-geneve-12.txt
2019-03-11
12 (System) New version approved
2019-03-11
12 (System) Request for posting confirmation emailed to previous authors: Ilango Ganga , Jesse Gross , "T. Sridhar"
2019-03-11
12 Ilango Ganga Uploaded new revision
2019-03-08
11 Ilango Ganga New version available: draft-ietf-nvo3-geneve-11.txt
2019-03-08
11 (System) New version approved
2019-03-08
11 (System) Request for posting confirmation emailed to previous authors: Ilango Ganga , Jesse Gross , "T. Sridhar"
2019-03-08
11 Ilango Ganga Uploaded new revision
2019-03-03
10 Ilango Ganga New version available: draft-ietf-nvo3-geneve-10.txt
2019-03-03
10 (System) New version approved
2019-03-03
10 (System) Request for posting confirmation emailed to previous authors: Ilango Ganga , Jesse Gross , "T. Sridhar"
2019-03-03
10 Ilango Ganga Uploaded new revision
2019-02-22
09 Ilango Ganga New version available: draft-ietf-nvo3-geneve-09.txt
2019-02-22
09 (System) New version approved
2019-02-22
09 (System) Request for posting confirmation emailed to previous authors: Ilango Ganga , Jesse Gross , "T. Sridhar"
2019-02-22
09 Ilango Ganga Uploaded new revision
2018-11-09
08 David Black Request for Early review by TSVART Completed: On the Right Track. Reviewer: David Black. Sent review to list.
2018-11-06
08 Yizhou Li Added to session: IETF-103: nvo3  Wed-1350
2018-10-25
08 Tero Kivinen Request for Early review by SECDIR Completed: Has Issues. Reviewer: Magnus Nystrom.
2018-10-11
08 Tero Kivinen Request for Early review by SECDIR is assigned to Magnus Nystrom
2018-10-11
08 Tero Kivinen Request for Early review by SECDIR is assigned to Magnus Nystrom
2018-10-09
08 Magnus Westerlund Request for Early review by TSVART is assigned to David Black
2018-10-09
08 Magnus Westerlund Request for Early review by TSVART is assigned to David Black
2018-10-09
08 Matthew Bocci Requested Early review by TSVART
2018-10-09
08 Matthew Bocci Requested Early review by SECDIR
2018-10-07
08 Ilango Ganga New version available: draft-ietf-nvo3-geneve-08.txt
2018-10-07
08 (System) New version approved
2018-10-07
08 (System) Request for posting confirmation emailed to previous authors: Ilango Ganga , Jesse Gross , "T. Sridhar"
2018-10-07
08 Ilango Ganga Uploaded new revision
2018-07-16
07 Yizhou Li Added to session: IETF-102: nvo3  Wed-1330
2018-07-02
07 Ilango Ganga New version available: draft-ietf-nvo3-geneve-07.txt
2018-07-02
07 (System) New version approved
2018-07-02
07 (System) Request for posting confirmation emailed to previous authors: Ilango Ganga , Jesse Gross , "T. Sridhar"
2018-07-02
07 Ilango Ganga Uploaded new revision
2018-03-05
06 Ilango Ganga New version available: draft-ietf-nvo3-geneve-06.txt
2018-03-05
06 (System) New version approved
2018-03-05
06 (System) Request for posting confirmation emailed to previous authors: Ilango Ganga , Jesse Gross , "T. Sridhar"
2018-03-05
06 Ilango Ganga Uploaded new revision
2017-09-12
05 Ilango Ganga New version available: draft-ietf-nvo3-geneve-05.txt
2017-09-12
05 (System) New version approved
2017-09-12
05 (System) Request for posting confirmation emailed to previous authors: Ilango Ganga , Jesse Gross , "T. Sridhar"
2017-09-12
05 Ilango Ganga Uploaded new revision
2017-03-28
04 Matthew Bocci Notification list changed to Matthew Bocci <matthew.bocci@nokia.com>
2017-03-28
04 Matthew Bocci Document shepherd changed to Matthew Bocci
2017-03-28
04 Matthew Bocci Changed consensus to Yes from Unknown
2017-03-28
04 Matthew Bocci Intended Status changed to Proposed Standard from None
2017-03-13
04 Ilango Ganga New version available: draft-ietf-nvo3-geneve-04.txt
2017-03-13
04 (System) New version approved
2017-03-13
04 (System) Request for posting confirmation emailed to previous authors: Ilango Ganga , Jesse Gross , "T. Sridhar"
2017-03-13
04 Ilango Ganga Uploaded new revision
2016-09-20
03 Jesse Gross New version available: draft-ietf-nvo3-geneve-03.txt
2016-09-20
03 Jesse Gross New version approved
2016-09-20
03 Jesse Gross Request for posting confirmation emailed to previous authors: "Jesse Gross" , "Ilango Ganga" , nvo3-chairs@ietf.org
2016-09-20
03 (System) Uploaded new revision
2016-07-08
02 Jesse Gross New version available: draft-ietf-nvo3-geneve-02.txt
2016-07-07
01 Xian Zhang Request for Early review by RTGDIR Completed: Has Issues. Reviewer: John Drake.
2016-06-14
01 Xian Zhang Request for Early review by RTGDIR is assigned to John Drake
2016-06-14
01 Xian Zhang Request for Early review by RTGDIR is assigned to John Drake
2016-01-14
01 Jesse Gross New version available: draft-ietf-nvo3-geneve-01.txt
2015-05-08
00 Benson Schliesser This document now replaces draft-gross-geneve instead of None
2015-05-08
00 Jesse Gross New version available: draft-ietf-nvo3-geneve-00.txt