On Thu, Apr 12, 2018 at 3:31 PM, Mickey Spiegel
<mspie...@barefootnetworks.com> wrote:
> Tom,
>
> On Thu, Apr 12, 2018 at 2:46 PM, Tom Herbert <t...@herbertland.com> wrote:
>>
>> On Thu, Apr 12, 2018 at 9:54 AM, Greg Mirsky <gregimir...@gmail.com>
>> 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)
>> > <fbroc...@cisco.com> 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.
>
>
> The four versus eight bytes just refers to the fields in the four bytes of
> IOAM
> info, that is common to all IOAM options. Beyond that, there are IOAM option
> specific fields. For example if doing one of the IOAM trace options, there
> are
> four bytes of trace option header, including the IOAM-trace-type, NodeLen,
> Flags, and RemainingLen fields. These are followed by the node data list
> containing the per hop IOAM information.
>
All of that and people are worried about having four extra bytes of
overhead? :-)

How big are these encapsulation headers in data packets going to be?

Tom

> In looking at the OOAM header content, it has nothing to do with any of the
> IOAM information after the first four bytes. It contains another variant of
> the
> information in the first four bytes of IOAM info, spread out over eight
> bytes.
>
>>
>> Tom
>>
>> >
>> > GIM>> The difference in four octets is because OOAM Header:
>> >
>> > provides more flexibility, e.g. Flags field and Reserved fields;
>
>
> The flags field only has one defined flag at the moment, for a timestamp
> block. For IOAM trace we need per hop timestamps, which the timestamp
> block cannot address, i.e. the timestamp block is redundant for IOAM.
>
>>
>> > supports larger OAM packets than iOAM header;
>
>
> For IOAM purposes, 1020 octets is more than enough.
>
>>
>> > is future proof by supporting versioning (Version field).
>
>
> IMO, taking the first two bits of the IOAM-Type to define a Version field
> would be a good thing. This does not require adding four more bytes of
> overhead. 64 IOAM-Types is more than enough.
>
>>
>> >>
>> >> * 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
>> >> i...@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/ippm
>> >>
>> >
>> >
>> > _______________________________________________
>> > Int-area mailing list
>> > Int-area@ietf.org
>> > https://www.ietf.org/mailman/listinfo/int-area
>> >
>>
>> _______________________________________________
>> ippm mailing list
>> i...@ietf.org
>> https://www.ietf.org/mailman/listinfo/ippm
>
>

_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Reply via email to