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

[Greg Mirsky <[e-mail]>]

Hi Frank,
thank you for your expedient response. Yes, clarification and consistent
terminology, of course as different encapsulations allow that, will help.
What I'm looking through the iOAM encapsulation drafts is the answer to
this question How a system that is not using iOAM can get to the data
payload that follows the iOAM message? Is there the field in the iOAM shim
that allows the system to skip over the iOAM message (by iOAM message I
mean iOAM shim and iOAM data)? Would such system be required to parse other
than iOAM shim constructs? I couldn't find this scenario being discussed in
any of iOAM encapsulation drafts. Have I missed it?

Regards,
Greg

On Thu, Apr 19, 2018 at 9:54 AM, Frank Brockners (fbrockne) <
[e-mail]> wrote:

> Hi Greg,
>
>
>
> good catch – there is a bit of loose language in some of the drafts. We’ll
> make things crisper in the next rev. Note that there is no generic “IOAM
> header” but that definition is always within the context of a particular
> encapsulation protocol. draft-weis-ippm-ioam-gre-00 already has a
> definition of the IOAM header (for GRE) – see section 3. For the other
> drafts, we use language like “The IOAM related fields in VXLAN-GPE are
> defined as follows” or “The fields related to the encapsulation of IOAM
> data fields in Geneve are defined as follows”, i.e. the information that is
> required to perform the encapsulation into the parent protocol, along with
> the actual IOAM data fields. Moving forward, we can be crisper and split
> things into an “encapsulation dependent part” and a “data part”.
>
>
>
> Frank
>
>
>
> *From:* Greg Mirsky <[e-mail]>
> *Sent:* Donnerstag, 19. April 2018 18:15
> *To:* Frank Brockners (fbrockne) <[e-mail]>
> *Cc:* IETF IPPM WG <[e-mail]>; NVO3 <[e-mail]>; Service
> Function Chaining IETF list <[e-mail]>; [e-mail]
> *Subject:* Re: [ippm] encapsulation of IOAM data in various protocols -
> follow up from WG discussion in London
>
>
>
> 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
>
>
>