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

Greg Mirsky <gregimirsky@gmail.com> Thu, 12 April 2018 21:56 UTC

Return-Path: <gregimirsky@gmail.com>
X-Original-To: nvo3@ietfa.amsl.com
Delivered-To: nvo3@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4238512D77A; Thu, 12 Apr 2018 14:56:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I0DhagjZj07z; Thu, 12 Apr 2018 14:56:15 -0700 (PDT)
Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7A3712AF83; Thu, 12 Apr 2018 14:56:14 -0700 (PDT)
Received: by mail-lf0-x236.google.com with SMTP id b189-v6so9859200lfe.2; Thu, 12 Apr 2018 14:56:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FB2yzuZofrNdAYIaFgvxgT+74i3/Ogq/NpHcIQuYhck=; b=E2iZMHJmkdRQcIqejKW8SWbx47v3Wn64x6Cvnv7VfnGvVpfwyrm7h10qb/33RX7BIb 9eSrHgO09kYukhC3AToOIW1MrBxDhzwLIUN+GopnfWBHkcmxE1Yf1GLgMSFUxx9oLxO2 i/PqrhsJY+NTxCL+Txr4cnWyjwDSIZLsfNRWSpph1cjdXjO8EV+UP6wycyyxRZJJ2lUP B3Mn6gyVlPH9PChO45aR2M83XJLnyTmkSpjal8J+7GJSiSan2zV3nNTVOIll5oxcN5rv 3QvOPTQ2MiD7hxIdO8Pia/AMfWoHL5Rm4wD7pufaPPMnoY1I3b7uFTOBdLIr3J5eF9QN p6Tw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FB2yzuZofrNdAYIaFgvxgT+74i3/Ogq/NpHcIQuYhck=; b=reh2+SeyfgaHT/cM9VsKROU0ArYHEq1jWpwZDRzL8jy6NX61k8Ymb4Iwl309WzOp3I 1RP7xE5U/1C3t5XUA7qKNsPV5RhAfDcD39wuzBI8//gB3hs1VfwPnoeX2p2nwv5/N8+4 1Bk+r4aqQ2LAdGvHOgKtnrrZwujD+QVwfBl7jGDBuk0VF8OC3Lnv/Qu+SX/EOOfjUmmZ dEj5qiM2qOHbKWoMVaJcJVyaLPrb+RsUO1CSF9cJEjFU3EOlxhAVwVVdABCuGSPClaX7 a6WTx/b0gN7TWIq1bCQXGABoElhNedO/2JjrB7+NRL92o/5J9j5cJzM4+P7pI7mVGfLi fnpw==
X-Gm-Message-State: ALQs6tC/wKtNHFv/LITPR7gKQn/LB8vovFZXB8+nl4BJ+msyi6SZkU8z 9XtMxRgTHZevFio4WKAqhrwWKykCRA/oeSlwkXP6Lw==
X-Google-Smtp-Source: AIpwx496q6SLmENT7UR0OFtHSYZWOHkHimJ4uJYXE0QyEuhaqoaiXgPj2Y0x1+X+WE2GkJK3C0Qs6Ovch0tyRRvs6jc=
X-Received: by 2002:a19:aacd:: with SMTP id t196-v6mr6860922lfe.60.1523570172975; Thu, 12 Apr 2018 14:56:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.46.73.66 with HTTP; Thu, 12 Apr 2018 14:56:12 -0700 (PDT)
In-Reply-To: <CALx6S35boQabs9-8Jvn4eDeEdojCxGJJpg+1gXOP0NzBY5nBWw@mail.gmail.com>
References: <ff0c9182d1f14ec48b352e41fedaf58e@XCH-RCD-008.cisco.com> <CA+RyBmUNHcQZtTGJj67V=DqPkwV6GXWDUQJGjwT7ODEFg_QQFA@mail.gmail.com> <CALx6S36ojk0z+iOhNhFqF2A+acXC1=xHPEN7G0Y_9+itC+WiGQ@mail.gmail.com> <CA+RyBmXGbia0q3p46ZR94pMy-WzPvJb-0QK7JsHLikhSWgRQcQ@mail.gmail.com> <CALx6S35boQabs9-8Jvn4eDeEdojCxGJJpg+1gXOP0NzBY5nBWw@mail.gmail.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Thu, 12 Apr 2018 23:56:12 +0200
Message-ID: <CA+RyBmXB3qqxO0cXBxk455mRYTQrSJBiLEoN+FPv0CuDW6DmgA@mail.gmail.com>
To: Tom Herbert <tom@herbertland.com>
Cc: "Frank Brockners (fbrockne)" <fbrockne@cisco.com>, NVO3 <nvo3@ietf.org>, int-area@ietf.org, Service Function Chaining IETF list <sfc@ietf.org>, IETF IPPM WG <ippm@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f361500569add2e1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nvo3/GX0S7oUBgiPRvehjwOsItDP0tAk>
Subject: Re: [nvo3] [Int-area] [ippm] encapsulation of IOAM data in various protocols - follow up from WG discussion in London
X-BeenThere: nvo3@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" <nvo3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nvo3>, <mailto:nvo3-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nvo3/>
List-Post: <mailto:nvo3@ietf.org>
List-Help: <mailto:nvo3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nvo3>, <mailto:nvo3-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Apr 2018 21:56:19 -0000

Hi Tom,
I'll let Frank answer your question as it is on iOAM, not OOAM.

Regards,
Greg

On Thu, Apr 12, 2018 at 11:53 PM, Tom Herbert <tom@herbertland.com> wrote:

> On Thu, Apr 12, 2018 at 2:50 PM, Greg Mirsky <gregimirsky@gmail.com>
> 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 <tom@herbertland.com>
> wrote:
> >>
> >> On Thu, Apr 12, 2018 at 9:54 AM, Greg Mirsky <gregimirsky@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)
> >> > <fbrockne@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.
> >>
> >> 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
> >> >> ippm@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
> >> >
> >
> >
>