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

From: Greg Mirsky <[email-masked]>
Date: Mon, 14 May 2018 14:23:41 -0700

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.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 14 May 2018 22:51:58 +0000

Dear Greg,

One follow-up request, based on one of your comments:
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:

Do you think the draft “OAM Header for use in Overlay Networks” should be renamed to something like “OAM Header for use in a rather small and very limited number of Overlay Networks” or “OAM Header for use in Geneve, SFC NSH, and BIER”? (It is not clear what Geneve, NSH, and BIER have in common that scopes them in and scopes others out, but…) Otherwise, it is deceiving.

Thanks,

Carlos.

From: nvo3 <[email-masked]> on behalf of Greg Mirsky <[email-masked]>
Date: Monday, May 14, 2018 at 5:24 PM
To: NVO3 <[email-masked]>
Subject: [nvo3] Follow-up the discussion of OOAM Header at NVO3 meeting in London

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:

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.

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.

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.

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.

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.

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 14 May 2018 15:56:37 -0700

Hi Carlos,
you've missed a couple other protocols where OOAM Header may be used - GUE
and VxLAN-GPE as mentioned in the Introduction.

Regards,
Greg

On Mon, May 14, 2018 at 3:51 PM, Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> 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:
>
>
>
> Do you think the draft “*OAM Header for use in Overlay Networks*” should
> be renamed to something like “*OAM Header for use in a rather small and
> very limited number of Overlay Networks*” or “*OAM Header for use in
> Geneve, SFC NSH, and BIER*”? (It is not clear what Geneve, NSH, and BIER
> have in common that scopes them in and scopes others out, but…) Otherwise,
> it is deceiving.
>
>
>
> Thanks,
>
>
>
> Carlos.
>
>
>
> *From: *nvo3 <[email-masked]> on behalf of Greg Mirsky <
> [email-masked]>
> *Date: *Monday, May 14, 2018 at 5:24 PM
> *To: *NVO3 <[email-masked]>
> *Subject: *[nvo3] Follow-up the discussion of OOAM Header at NVO3 meeting
> in London
>
>
>
> Dear All,
>
> 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.
>
>
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 14 May 2018 23:00:06 +0000

Hi, Greg,

Thanks for the clarification and apologies for the omission — my main point was that, if it is not all, it is not “for use in Overlay Networks”.

The title could be “OAM Header for use in Geneve, SFC NSH, and BIER, and maybe GUE and VxLAN-GPE”. Would that be inclusive?

Reminded me of https://xkcd.com/927/

Thanks,

— Carlos Pignataro

On May 14, 2018, at 6:56 PM, Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

Hi Carlos,
you've missed a couple other protocols where OOAM Header may be used - GUE and VxLAN-GPE as mentioned in the Introduction.

Regards,
Greg

On Mon, May 14, 2018 at 3:51 PM, Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>> wrote:
Dear Greg,

Thanks,

Carlos.

From: nvo3 <[email-masked]<mailto:[email-masked]>> on behalf of Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Date: Monday, May 14, 2018 at 5:24 PM
To: NVO3 <[email-masked]<mailto:[email-masked]>>
Subject: [nvo3] Follow-up the discussion of OOAM Header at NVO3 meeting in London

Dear All,

Sam: [].