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

[Greg Mirsky <[e-mail]>]

Hi John,
I don't argue with the importance of interoperable implementations (though
early implementations accept the risk of non-compliance with the final
specification, for example, SFC NSH). At the same time, I don't think that
mere fact of existing implementation should cancel discussion of technical
characteristics of the proposed approaches to hybrid OAM.

Regards,
Greg

On Thu, Apr 19, 2018 at 9:09 AM, John Lemon <[e-mail]> wrote:

> I never saw a response to the request for a pointer to an OOAM
> implementation, so I assume none exist.
>
> I've seen several good arguments for why the existing IOAM implementation,
> for which several implementations exist, meets the needs for IOAM.
>
> I think it is time to put to bed the request to examine merging OOAM and
> IOAM. Let's move forward with IOAM and not hold it up.
>
> Respectfully, John
>
>
> On Thu, Apr 12, 2018 at 11:06 AM, Frank Brockners (fbrockne) <
> [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-10
>> 0-hackathon-sessa-in-situ-oam-ioam - where we’ve shown IPv6 and
>> VXLAN-GPE with IOAM – on 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: There are protocol encapsulations for
>> VXLAN-GPE, NSH, and IPv6 implemented in 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]>
>> *Sent:* Donnerstag, 12. April 2018 18:54
>> *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,
>>
>> 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]> 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]
>> https://www.ietf.org/mailman/listinfo/ippm
>>
>>
>>
>> _______________________________________________
>> ippm mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ippm
>>
>>
>