[nvo3] Comments on draft-ietf-nvo3-vxlan-gpe

[Greg Mirsky <[e-mail]>]

Dear Editors, et al.,
I've read the latest -07 version and would like to share my comments and
questions with you:

   - in the earlier version of the draft, the O-bit was introduced and
   defined as:

OAM Flag Bit (O bit):  The O bit is set to indicate that the packet is an
OAM packet.

At the same time, in the latest version, the new Next Protocol value (0x81)
to identify iOAM Data was introduced. Hence are my questions:


   - What must be the value of the O-bit when the value of the Next
   Protocol field is iOAM?
   - Do you plan to define the Next Protocol values for active OAM
   protocols, e.g., Echo Request/Reply, BFD, Performance Monitoring?
   - How to interpret the situation when the O-bit value is 1 but the value
   of the Next Protocol field is, for example, NSH, i.e., not any of OAM
   protocols?


   - I believe that the use of the dedicated OAM flag and the Next Protocol
   field for a fixed-size header that cannot include meta-data is unwarranted
   and adds unnecessary complexity. I suggest not to use O-bit in the
   VXLAN-GPE header and release it into the Reserved field.  I don't see the
   apparent benefit of using the flag, as the VXLA-GPE uses the fixed size
   header and the header cannot carry OAM data in it. The only role the
   VXLAN-GPE header must perform, in my opinion, is to unambiguously identify
   the payload type that immediately follows the header as OAM (demultiplexing
   OAM protocols may be done in OAM Header shim).

Much appreciate your consideration.

Regards,
Greg