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

[John Lemon <[e-mail]>]

Hi Greg,

I never stated "that mere fact of existing implementation should cancel
discussion of technical characteristics of the proposed approaches to
hybrid OAM". I just noted implementation status as AN important thing to
consider. I also noted that "I've seen several good arguments for why the
existing IOAM implementation [...] meets the needs for IOAM." I'm not
trying to end discussion of the technical characteristics. I'm stating that
I believe that it has been well argued that IOAM is mature enough that it
is clear that it is sufficiently different from OOAM as to not share the
same header.

I hope that clarifies my intent.

Regards, John


On Thu, Apr 19, 2018 at 9:30 AM, Greg Mirsky <[e-mail]> wrote:

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