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

[Tom Herbert <[e-mail]>]

On Thu, Apr 12, 2018 at 9:54 AM, Greg Mirsky <[e-mail]> wrote:
> 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.
>

What is the relationship between this proposal and
draft-fioccola-v6ops-ipv6-alt-mark which is currently searching for a
way to squeeze out two bits in the IP header for performance
measurement?

Tom

> 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.
>
>> 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
>>
>
>
> _______________________________________________
> Int-area mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/int-area
>