[nvo3] Follow-up the discussion of OOAM Header at NVO3 meeting in London

[Greg Mirsky <[e-mail]>]

Dear All,
following the presentation of the OOAM Header we had very good discussion
in London. Many thanks to all who have asked so many good questions. Below
please find my answers, follow-up notes in-lined in the minutes from the
meeting under GIM>> tag:

Frank Brockners: Would help the document if you added the
applicability section that said how that particular header would be
slotted in with Geneve, GRE, and the likes. What you have now work
well for protocols that have a pointer of next header of 8 bits. That
would not work for 16 bit protocol pointers.

GIM>> GRE is not in scope of this proposal. As noted in the
Introduction, OOAM Header aimed at Geneve, SFC NSH and BIER. It may be
used in VXLAN-GPE and GUE:

   New protocols that support overlay networks like VxLAN-GPE
   [I-D.ietf-nvo3-vxlan-gpe], GUE [I-D.ietf-nvo3-gue], Geneve
   [I-D.ietf-nvo3-geneve], BIER [RFC8296], and NSH [RFC8300] support
   multi-protocol payload, e.g.  Ethernet, IPv4/IPv6, and recognize
   Operations, Administration, and Maintenance (OAM) as one of distinct
   types.  That ensures that Overlay OAM (OOAM)packets are sharing fate
   with Overlay data packet traversing the underlay.

GIM>> Regarding use of 16 bits long field for Protocol Type in Geneve.
I think that this is valid question that NVO3 WG should discuss not
only for OOAM Header but for the Geneve proposal. Benefits of using
EtherType rather than new protocol registry like, for example in
VxLAN-GPE, are not obvious to me.

 Showing how that fits in a general way would give more appeal for
people to care about it.
Greg: Are you suggesting that different encapsulations have different
length of the next protocol field?
Frank: It depends where you want to go with this. If you have GRE,
next type will be ethertype. I wonder where it does apply, how does
that apply, and adding that to the document would be of great help.
Greg: I will look into the document, but our original goal was to use
ion new encapsulations like BIER, Geneve, SFC. Whether that is
applicable to GRE we need to discuss.
Frank. Having applicability and deployment section would be good.
Greg: In BIER, Geneve, and NSH it looks not different.
Sam: [].
?/Cisco: Curious to know - this seems to be an inband OAM type. How
would this relate to IOAM work in IPPM?
Greg: I would stress that inband behavior of OAM is the function of
the encapsulation layer. If it draws only from the encapsulation layer
and not from the payload then any type of OAM will be inband. In order
to ensure that active OAM is inband with the data flow it puts certain
restrictions on how the following decision should be drawn. One of the
examples that we have is an example how this type of encapsulation can
be used for IOAM. The format of the header is something that we can
discuss.
?/Cisco: Can you explain how the next protocol is supposed to be used?
Do you need to look at the first part of the header?
Greg: Yes. If next protocol is 0 it means you have only OAM control
packet. If you have nonzero it means that there is something following
after the control packet.
?/Cisco: I will take this offline.
Greg: Next protocol registry is something that we can discuss.
Ilango: The OAM proposal that you have is applicable at different
layers, it could be on the overlay layer, it could be on the service
layer. Both could coexist, and the document does not have enough
applicability information for this case.

GIM>> If this is in reference to, for example, SFC NSH over Geneve,
then yes, one can construct a packet with OAM message on each layer.
Consider Geneve header, followed by its OAM, i.e. OOAM header and OAM
message.  This Geneve OAM message, in turn, is followed by NSH. And
the NSH header is followed by SFC OAM, which includes OOAM Header and
SFC OAM message. Is this the scenario you consider? It is certainly
interesting but, I think, may not necessarily be described in this
document. It may be more suitable to be analyzed in SFC OAM document.

Greg: I would personally think that the same packet for the OAM for
different layers.
Ilango: Not necessarily. NSH can be transported on multiple different
transports. If you go through multiple encapsulations before reaching
the service node. OAM as part of the NSH header is independent from
OAM in the overlay layer.
Greg: It would be interesting and helpful to get some operational
considerations where one packet is OAM for NSH and overlay transport
at the same time. How to identify where the fault happened. It is much
easier if it is done on the on the different layers.
Ilango: Can you clarify that in the further version of the document?
Greg: This can be applied on both layers but independently.
Parviz: Back to Frank’s question on applicability - you are going to
change behavior of SFC nodes? Is it going to impact the behavior of
the SF node, or is it transparent?
Greg: If we talk about active OAM, we have multilayer OAM individual
document in SFC WG, the scope is SFF.
Parviz: Forwarding behavior?
Greg: Forwarding behavior is based on SFF, not SF.
Parviz: The behavior of the forwarding node is captured?
Greg: The expected behavior - the document introduces echo request and
reply, and SFF can reply to the sender out of band as requested.
Sam: Clarification question. Are you going to pursue this in other
WGs? Are you going to pursue to get a common solution?
Greg: If the WG in the current work in the header - there is a
dependency between OOAM DT and this work in header. If both documents
get adopted I will pursue a common solution, if not I will continue
with SFC.

GIM>> As was mentioned, in draft-wang-sfc-multi-layer-oam
<https://tools.ietf.org/html/draft-wang-sfc-multi-layer-oam-06> have
proposed use the header for SFC OAM with introduction of SFC Echo
Request and Echo Reply.