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