Early Review of draft-ietf-nvo3-vxlan-gpe-02
review-ietf-nvo3-vxlan-gpe-02-rtgdir-early-frost-2016-07-07-00

Hi,

I've been selected from the Routing Directorate to perform a QA review
of this document. The philosophy behind QA reviews can be found at


https://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa

  In brief, QA
reviews are intended to uncover issues or facilitate wider discussion at
an earlier stage than Last Call.

General comment:

The draft is clear and reasonably complete, though quite sparse in
providing rationale for various decisions. Discussion of manageability
and security considerations is virtually absent; greater attention to
these areas may help the document mature, as will providing some
high-level guidance or statement of intent (e.g. plans for future work)
on important topics declared out of scope, such as OAM and peer
capability verification.

Overall, my main concern with this work is that it's not clear (at least
from this draft) what the plan is for VXLAN protocol evolution in the
IETF and how this work fits in to that plan. The protocol described in
the draft takes great pains to be as similar to and compatible with
VXLAN as possible, yet runs on its own UDP port. Is it not possible or
desirable to extend VXLAN itself? Is this work meant to be the basis for
future VXLAN evolution? Are we going to end up with lots of other
slightly different variations of VXLAN running on different ports in the
future?

These issues need to be considered by the ADs and chairs as well as the
authors if they haven't been already, and a definite plan arrived at and
documented or referenced in this draft.

Specific comments follow.

---

Abstract:
OAM is expanded as "operations, administration and management". BCP 161
recommends "Operations, Administration, and Maintenance".

---

Section 2:
The phrase "out of scope" is used twice, in reference to VTEP multicast
configuration and control-plane-based mapping. It's not clear if this
means out of scope of this document, of the VXLAN spec, or something
else.

---

Section 2, last paragraph:
"If the encapsulated packet is an Ethernet frame..." Isn't what's
encapsulated always an Ethernet frame?
"If the encapsulated packet is an IP packet..." What does this mean if
the encapsulated thing is always an Ethernet frame?

---

Section 3:
I'd recommend stating clearly at the beginning of this section that
VXLAN GPE uses a different UDP port than RFC 7348 VXLAN, and that GPE
packets only flow over this new port. This ought to go in the
Introduction also and maybe even the Abstract.

---

Section 3.1:
Can the rationale for the P bit be explained in the document? Since GPE
packets are indicated by their own UDP port, can't the Next Protocol
field always be present? And as long as you're defining your own
protocol values, wouldn't you want to choose 0x0 for Ethernet to
correspond to VXLAN, thereby possibly simplifying things for
implementations?

---

Section 3.1:
It's somewhat problematic to declare the Version field as being part of
the Flags field, since a multi-bit version number isn't a flag.

---

Section 3.1:
The I bit is carried over from RFC 7348, but the obvious question not
addressed here or there is, in what situation would the bit be zero? Is
this bit serving a useful function?

---

Section 3.1, VNI:
"Inner packets belonging to different VNIs cannot communicate with each
other" needs some rephrasing; maybe "Each inner packet belongs to
exactly one VNI, and traffic cannot flow between distinct VNIs unless
explicitly allowed by policy."

---

Section 3.2:
The Next Protocol Field description refers to "the lower 8 bits of the
first word". Shouldn't this be "Bits 24-31 of the GPE header"?

---

Section 3.2:
Can the draft explain why it's necessary to allocate another IANA
protocol type registry? Are there no existing ones that can serve?

---

Section 3.2:
The NSH and idrtun references don't have associated RFC numbers or draft
names/links? The connection between MPLS and the idrtun draft probably
needs some elaboration, too.

---

Section 4:
Are Figure 3 and Figure 4 both necessary? The only difference appears to
be whether the outer Ethernet frame encapsulates an IPv4 or v6 packet.
Figure 4 has an extraneous caption called "Figure X".

---

Section 4.2:
s/MUST never/MUST NOT/

---

Section 5.1:
The use of both lowercase and uppercase MUSTs in this paragraph may be
misleading. The paragraph is just reiterating behavior specified in RFC
7348, not specifying new requirements. Perhaps use "will" instead.

---

Section 5.2, last sentence:
Capabilities determination may be out of scope, but seems essential if
GPE communication is ever to take place. Can the authors say anything
more here about how they expect this to work, e.g. explicit
configuration? Is a future draft planned on the subject?

---

Section 10.3:
"There are ten flag bits at the beginning of the VXLAN GPE header"
presumably should be "eight flag bits".

---

Section 11:
Some of your Informative references presumably should be Normative, e.g.
RFCs 7348 and 6830.

---

Cheers,
-d