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

[Greg Mirsky <[e-mail]>]

Hi Tom,
I think you refer to the proposal on how to apply RFC 8321
<https://tools.ietf.org/html/rfc8321> in IPv6 networks. Using two bits-long
field for Alternate Marking is just one option as you can find in the draft
on compact Alt.marking
<https://tools.ietf.org/html/draft-mizrahi-ippm-compact-alternate-marking-01>.
But to answer your question, there's no connection or dependency between
the Alternate Marking method and OOAM. Will note that we have documents on
the applicability of the Alternate Marking method in BIER, SFC NSH, and
Geneve.

Regards,
Greg

On Thu, Apr 12, 2018 at 8:37 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.
> >
>
> 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
> >
>