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

From: "Ramesh Sivakolundu (sramesh)" <[email-masked]>
Date: Wed, 11 Apr 2018 20:41:05 +0000

I concur with the reasons given and agree that minimizing the header overhead added to live data traffic at each node is critical. The IPPM Working group should move forward with the header definitions for various encapsulation.

Regards,

-Ramesh

From: ippm <[email-masked]> on behalf of "Frank Brockners (fbrockne)" <[email-masked]>
Date: Wednesday, April 11, 2018 at 3:02 AM
To: IETF IPPM WG <[email-masked]>
Subject: [ippm] encapsulation of IOAM data in various protocols - follow up from WG discussion in London

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.
* 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.
* 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.
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