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

Hi Carlos,
thank you for sharing your view on the design of the VXLAN-GPE protocol.
Please find my comments in-line tagged GIM>>.

Regards,
Greg

On Fri, Apr 12, 2019 at 5:23 AM Carlos Pignataro (cpignata) <
cpignata@cisco.com> wrote:

> Greg,
>
> You seem to be confusing and mixing things up.
>
> Please see inline.
>
> > On Apr 12, 2019, at 2:50 AM, Greg Mirsky <gregimirsky@gmail.com> wrote:
> >
> > 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?
>
> The O bit “is set to indicate that the packet is an OAM packet”.
> IAOM is not an OAM packet. Hence, O bit clear if VXLAN-GPE encapsulates a
> non-OAM packet and adds an IOAM shim.
>
GIM>> It is a very unexpected statement from you, one of the co-authors of
draft-ietf-ippm-ioam-data
<https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-data/> where the
first paragraph of the Introduction section defines iOAM as Hybrid Type 1
OAM, according to RFC 7799 classification:
   IOAM is to complement
   mechanisms such as Ping or Traceroute, or more recent active probing
   mechanisms as described in [I-D.lapukhov-dataplane-probe].  In terms
   of "active" or "passive" OAM, "in-situ" OAM can be considered a
   hybrid OAM type.  While no extra packets are sent, IOAM adds
   information to the packets therefore cannot be considered passive.
   In terms of the classification given in [RFC7799] IOAM could be
   portrayed as Hybrid Type 1.

>
> >       • Do you plan to define the Next Protocol values for active OAM
> protocols, e.g., Echo Request/Reply, BFD, Performance Monitoring?
>
> I cannot speak to “plans” (replying as “et al.”, not as “editor”), but I
> expect OAM documents ought to have those requested, and you do not need
> necessarily all of those — the nex protocol IPv4 / IPv6 can encapsulate
> ICMP, UDP/BFD, etc., etc., etc., etc.
>
GIM>> Of course, use of the well-known port number, usually it is UDP
destination port, is one of the methods to demultiplex protocols. This
method is broadly used, for example, in MPLS OAM. But this method has some
disadvantages that were pointed out in the discussion of BFD over GENEVE in
Prague by David Black (the last presentation in the minutes
<https://datatracker.ietf.org/meeting/104/materials/minutes-104-nvo3-01>):

David: I want the BFD header to be as close to the thing whose liveness I'm
testing. The more headers you add in the middle, the more ways there are to
break BFD without breaking the forwarding engine. The further away I move
BFD from the chunk of hardware's liveness I care about, the more
opportunities are for BFD and the hardware to not to tell me the same thing.

> >       • 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 expect it means there’s OAM within that NSH (sometimes there’s no such
> things as “OAM Protocols”), or an unhandled OAM protocol.
>
GIM>> Should that, i.e., OAM in NSH or immediately following NSH be
signaled using SFC NSH methods that are already defined in
draft-ietf-sfc-multi-layer-oam
<https://datatracker.ietf.org/doc/draft-ietf-sfc-multi-layer-oam/>? Using
the server layer, as you've suggested, seems as layer violation.

>
> >       • 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.
>
> Disagree.
>
> See example where protocol is IP carrying an OAM packet.
>
GIM>> When IP/UDP encapsulation is used for OAM, there's no, in my opinion,
any need to use the O-bit. The destination IP address must be as described
in RFC 8029 or RFC 5884 and the demultiplexing is done based on the
destination UDP port number. Clearly, O-bit is unnecessary if IP/UDP
encapsulation for OAM being used.

>
> > 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.
> >
>
> Best,
>
> —
> Carlos Pignataro, carlos@cisco.com
>
> “Sometimes I use big words that I do not fully understand, to make myself
> sound more photosynthesis."
>
> > Regards,
> > Greg
> > _______________________________________________
> > nvo3 mailing list
> > nvo3@ietf.org
> > https://www.ietf.org/mailman/listinfo/nvo3
>
>