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

[Greg Mirsky <[e-mail]>]

Hi Frank, et. al,
we have a very good discussion, thank you. I have a question and appreciate
your consideration:

   - encapsulation documents refer to IOAM HDR, its length is reflected in
   the field labeled either Length or IOAM HDR len. But I cannot find the
   definition of IOAM HDR. What is the IOAM HDR?


Regards,
Greg


On Wed, Apr 11, 2018 at 3:02 AM, Frank Brockners (fbrockne) <
[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.
>
> * 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
>
> _______________________________________________
> ippm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ippm
>
>