Re: [nvo3] [ippm] encapsulation of IOAM data in various protocols - follow up from WG discussion in London

["Carlos Pignataro (cpignata)" <[e-mail]>]

Hi Greg,

Thanks for engaging and for your interest. Please find a couple of follow-ups to your comments, consolidating from the plurality of emails you sent with your responses.

The comparison you are suggestion between IOAM and OOAM is a red-herring, and as such I’ll go quiet and not respond on this thread after this email.

But for completeness:

1. You did not answer this, and again selectively skipped it. Can you please provide and answer?
Could you provide a pointer to an OOAM implementation?

2. You wrote:

Please note, that OOAM supports both active and hybrid OAM methods, while iOAM only the latter.

You are comparing apples with oranges. IOAM *is* a hybrid OAM method. OOAM is neither. It “supports” means that by itself it provides no value.

(And by the way, why Timestamps on this header when the OAM Packet itself will have timestamps if needed?!)

3. You wrote:

  *   the scope of OOAM, contrary to what you've stated, is clearly stated in the draft;

But the scope is not clear, to me at least, since it has no precision (what is included, what is excluded)? Is MPLS an overlay protocol? Is SRv6?

4. You wrote:


  *   what you present as "efficiency" I consider to be serious limitations (lack of versioning, limited size for data, and no future extension)

I do not believe this is an accurate characterization… BFD has less extensibility and more limitations than IOAM, and it’s great because it serves its function.

  *   that should be explained and thoroughly discussed by the WGs that develop corresponding overlay networks before IPPM WG makes any decision.

This is not an “overlay network” issue from the IPPM scope on the protocol. Let’s have a technical discussion and not artificially attempt to slow things down.

Many Thanks,

— Carlos Pignataro



On Apr 12, 2018, at 5:35 PM, Greg Mirsky <[e-mail]<mailto:[e-mail]>> wrote:

Hi Frank,
I think you've misunderstood my response to your statements:

  *   the scope of OOAM, contrary to what you've stated, is clearly stated in the draft;
  *   what you present as "efficiency" I consider to be serious limitations (lack of versioning, limited size for data, and no future extension) that should be explained and thoroughly discussed by the WGs that develop corresponding overlay networks before IPPM WG makes any decision.

Regards,
Greg

On Thu, Apr 12, 2018 at 8:06 PM, Frank Brockners (fbrockne) <[e-mail]<mailto:[e-mail]>> wrote:
Hi Greg,

thanks – and it seems that we’re on the same page with regards to efficiency (4 bytes of non-required overhead) and maturity (or lack of) of OOAM.

On the IOAM implementation: There are several implementations of IOAM. Some of which have recently been worked on and shown at an IETF hackathon, see https://datatracker.ietf.org/meeting/100/materials/slides-100-hackathon-sessa-in-situ-oam-ioam - where we’ve shown IPv6 and VXLAN-GPE with IOAM – on FD.io/VPP<http://FD.io/VPP> as well as on Barefoot Tofino. You probably also remember the Netronome/Broadcom demo - https://www.youtube.com/watch?v=j9FbD4a3F4E .
Below you seem to be specifically referring to the IOAM open source implementation in FD.io/VPP:<http://FD.io/VPP:> There are protocol encapsulations for VXLAN-GPE, NSH, and IPv6 implemented in FD.io/VPP<http://FD.io/VPP>. The current code uses the “next header approach” for VXLAN-GPE and it leverages MD-Type 2 for NSH. As you’re well aware, there the discussion in SFC whether to use MD-Type 2 or next header encapsulating IOAM data in NSH isn’t yet settled, hence we’ll refrain from updating the code until SFC WG has come to a conclusion.

Could you provide a pointer to an OOAM implementation?

Thanks,
Frank

From: Greg Mirsky <[e-mail]<mailto:[e-mail]>>
Sent: Donnerstag, 12. April 2018 18:54
To: Frank Brockners (fbrockne) <[e-mail]<mailto:[e-mail]>>
Cc: IETF IPPM WG <[e-mail]<mailto:[e-mail]>>; NVO3 <[e-mail]<mailto:[e-mail]>>; Service Function Chaining IETF list <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [ippm] encapsulation of IOAM data in various protocols - follow up from WG discussion in London

Hi Frank,
thank you for sharing your points. Please find my notes in-line and tagged GIM>>. I believe that this is very much relevant to work of other working groups that directly work on the overlay encapsulations in the center of the discussion and hence I've added them to the list. Hope we'll have more opinions to reach the conclusion that is acceptable to all.

Regards,
Greg

On Wed, Apr 11, 2018 at 12:02 PM, Frank Brockners (fbrockne) <[e-mail]<mailto:[e-mail]>> wrote:
Back at the IPPM meeting in London, we discussed several drafts dealing with the encapsulation of IOAM data in various protocols (draft-brockners-ippm-ioam-vxlan-gpe-00, draft-brockners-ippm-ioam-geneve-00, draft-weis-ippm-ioam-gre-00). One discussion topic that we decided to take to the list was the question on whether draft-ooamdt-rtgwg-ooam-header could be leveraged.  After carefully considering draft-ooamdt-rtgwg-ooam-header, I came to the conclusion that the “OOAM header” does not meet the needs of IOAM:
* Efficiency: IOAM adds data to live user traffic. As such, an encapsulation needs to be as efficient as possible. The “OOAM header” is 8 bytes long. The approach for IOAM data encapsulation in the above mentioned drafts only requires 4 bytes. Using the OOAM header approach would add an unnecessary overhead of 4 bytes – which is significant.
GIM>> The difference in four octets is because OOAM Header:

  *   provides more flexibility, e.g. Flags field and Reserved fields;
  *   supports larger OAM packets than iOAM header;
  *   is future proof by supporting versioning (Version field).
* Maturity: IOAM has several implementations, which were also shown at recent IETF hackathons – and we’re expecting additional implementations to be publicized soon. Interoperable implementations need timely specifications. Despite the question being asked, the recent thread on OOAM in the NVO3 list hasn’t revealed any implementation of the OOAM header. In addition, the thread revealed that several fundamental questions about the OOAM header are still open, such as whether or how active OAM mechanisms within protocols such as Geneve would apply to the OOAM header. This ultimately means that we won’t get to a timely specification.
GIM>> May I ask which encapsulations supported by the implementations you refer to. Until very recently all iOAM proposals were to use meta-data TLV in, e.g. Geneve and NSH. And if these or some of these implementations already updated to the newly proposed iOAM shim, I don't see problem in making them use OOAM Header. Would you agree?

* Scope: It isn’t entirely clear to which protocols the OOAM header would ultimately apply to. The way the OOAM header is defined, OOAM uses a 8-bit field for “Next Prot”, the next protocol. Some protocols that IOAM data needs to be encapsulated into use 16-bits for their next protocol code points. See e.g. the GRE encapsulation – as specified in draft-weis-ippm-ioam-gre-00.
GIM>> The first paragraph of the Introduction section states:
   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 [I-D.ietf-bier-mpls-encapsulation], and
   NSH [I-D.ietf-sfc-nsh] 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.
I'm updating the OOAM Header draft and along with cleaning nits will update reference to GUE. I think that the list and the statemnt are quite clear in identifying the scope of networks that may benefit from using not only common OOAM Header but common OOAM mechanisms, e.g. Echo Request/Reply<https://tools.ietf.org/html/draft-ooamdt-rtgwg-demand-cc-cv-03>.

With the above in mind, I’d suggest that the WG moves forward with specific definitions for encapsulating IOAM data into protocols – per the above mentioned drafts.

Regards, Frank

_______________________________________________
ippm mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/ippm


_______________________________________________
nvo3 mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/nvo3