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

["Frank Brockners (fbrockne)" <[e-mail]>]

Tom,

the term "overhead" here refers to the number of extra bytes used in the parent protocol to carry IOAM data. IOAM data itself is of course not counted for the comparison, because it would need to be carried in both cases.

Using your Geneve reference as an example, in order to carry IOAM data, we need to add another Geneve Option class along with type fields etc. per the Geneve draft spec - which sums up to 4 bytes:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   |  Option Class  =  TBD_IOAM    |     Type      |R|R|R| Length  | 

The OOAM header requires 8 bytes to serve the very same purpose:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | V |           Msg Type        |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Flags             |    Reserved   |   Next Prot   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

HTH.

Frank



-----Original Message-----
From: Tom Herbert <[e-mail]> 
Sent: Donnerstag, 12. April 2018 23:53
To: Greg Mirsky <[e-mail]>
Cc: Frank Brockners (fbrockne) <[e-mail]>; NVO3 <[e-mail]>; [e-mail]; Service Function Chaining IETF list <[e-mail]>; IETF IPPM WG <[e-mail]>
Subject: Re: [Int-area] [ippm] encapsulation of IOAM data in various protocols - follow up from WG discussion in London

On Thu, Apr 12, 2018 at 2:50 PM, Greg Mirsky <[e-mail]> wrote:
> Hi Tom,
> could you please mention which drafts, iOAM or OOAM, you refer to. 
> Please note, that OOAM supports both active and hybrid OAM methods, 
> while iOAM only the latter.

Section 3 of draft-brockners-ippm-ioam-geneve-00 for instance.

>
> Regards,
> Greg
>
> On Thu, Apr 12, 2018 at 11:46 PM, Tom Herbert <[e-mail]> wrote:
>>
>> 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.
>> Greg,
>>
>> I'm missing something here. I looked at the drafts you referenced and 
>> each of them looks like the overhead for OAM is greater that four 
>> bytes. In each there is some overhead equivalent to type/length, for 
>> instance in Geneve four bytes are needed for option class, type, and 
>> length. Unless the the OAM data is zero length, I don't see how this 
>> adds up to only four bytes of overhead.
>>
>> 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 
>> > GIM>> 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
>> >
>
>