Re: [nvo3] [Int-area] [ippm] encapsulation of IOAM data in various protocols - follow up from WG discussion in London
Tom Herbert <tom@herbertland.com> Thu, 12 April 2018 21:53 UTC
Return-Path: <tom@herbertland.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 D296E12AF83 for <nvo3@ietfa.amsl.com>; Thu, 12 Apr 2018 14:53:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.609
X-Spam-Level:
X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 W2KkhBrpIoII for <nvo3@ietfa.amsl.com>; Thu, 12 Apr 2018 14:53:17 -0700 (PDT)
Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (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 B8BC312D77A for <nvo3@ietf.org>; Thu, 12 Apr 2018 14:53:17 -0700 (PDT)
Received: by mail-qk0-x22b.google.com with SMTP id v2so7136150qkh.10 for <nvo3@ietf.org>; Thu, 12 Apr 2018 14:53:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=IgLlpyLqm/eJ52btMRF1Sb2UQYVgAHBD6AWIWR1UeJ0=; b=hH81HYQyruLvE1zUu9AKAL1577Dvka3ZFertoeZMKNN4suXPAQVCiKNuFCC2i6KYFv CbGseQCQ3dGoc6SiTZgBkOlEh8hqRqXrlaUq2Gfg7NzuNqKo0bP824tElPl/fv9AGIss 0gBAsduaj2scI7HDZquvHs3TAY7Zmpqc2NLvBm3Wqch2ymj5mNgpm7rsBPvRs9WvpCd+ PS74NRpQ0gH+Olf+qPBu9hayCAgxp0pPU8sKdUBbUFx1z+kup9dpNICIv+GShmhwS4tG kaQ0P9VdfYGG3oyI2zhB0MlIGhvSkh4MvdqTDARpFE5/z8/4GOfOcet79d5yc/ze6RjS szMQ==
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:content-transfer-encoding; bh=IgLlpyLqm/eJ52btMRF1Sb2UQYVgAHBD6AWIWR1UeJ0=; b=KQySQbs1T9AzyUy9q4hlHxDO+qpUAgLhdO2DPPr/vZU5WCFqlTBBI5vWKX+yRA6+j3 H9Dr+t+CqxJz2vr88kEANEELdsBrBrkVLjP3pTnluslLciDwSyo01qW024R1AAqYN2Je cvdcu7J01GdlVYc45wlgR/vpmY1CQXPnOd6OHCOfgCzXAEaQZZyQOPB0mW+6pLeGagrE 6AZ0W3CW85gyX0MJ7V1fl8NLglUbjU1iJtYQj8q29d8Nxnh+h6exvwunuN7A8JG9qpjx tsb4Yw4HCmLN6zeHY7Kit7TrnZyQm+Q2zHf5eOfe+JYiF8yksQQQFn5MwnLEGCPQuQ6e nj1w==
X-Gm-Message-State: ALQs6tB9uaC285y8rLgrPvp8cRSjn8LT+lzEkGNyzGXiczS4qgrbKsy8 dcbAZnZoXyKvNFV9yAWWbtDNlb/bZrHjjv7OK4g+9g==
X-Google-Smtp-Source: AIpwx4+Js6lf9CYXf3VsLcKq1C7MrMG5oTrkJzEWxuhvIrQL5TkjznPIm+H4JXcWfqK6mNHJAqYcyjHDjl1DxcFH3Wk=
X-Received: by 10.55.195.85 with SMTP id a82mr2616603qkj.49.1523569996580; Thu, 12 Apr 2018 14:53:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.200.26.135 with HTTP; Thu, 12 Apr 2018 14:53:16 -0700 (PDT)
In-Reply-To: <CA+RyBmXGbia0q3p46ZR94pMy-WzPvJb-0QK7JsHLikhSWgRQcQ@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>
From: Tom Herbert <tom@herbertland.com>
Date: Thu, 12 Apr 2018 14:53:16 -0700
Message-ID: <CALx6S35boQabs9-8Jvn4eDeEdojCxGJJpg+1gXOP0NzBY5nBWw@mail.gmail.com>
To: Greg Mirsky <gregimirsky@gmail.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: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/nvo3/XDCnXqYOaXUrt17tD-6NcwMId1U>
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:53:23 -0000
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 >> > > >
- Re: [nvo3] [ippm] encapsulation of IOAM data in v… Greg Mirsky
- Re: [nvo3] [ippm] encapsulation of IOAM data in v… Frank Brockners (fbrockne)
- Re: [nvo3] [Int-area] [ippm] encapsulation of IOA… Tom Herbert
- Re: [nvo3] [Int-area] [ippm] encapsulation of IOA… Greg Mirsky
- Re: [nvo3] [ippm] encapsulation of IOAM data in v… Greg Mirsky
- Re: [nvo3] [Int-area] [ippm] encapsulation of IOA… Tom Herbert
- Re: [nvo3] [Int-area] [ippm] encapsulation of IOA… Greg Mirsky
- Re: [nvo3] [Int-area] [ippm] encapsulation of IOA… Tom Herbert
- Re: [nvo3] [Int-area] [ippm] encapsulation of IOA… Greg Mirsky
- Re: [nvo3] [ippm] [Int-area] encapsulation of IOA… Mickey Spiegel
- Re: [nvo3] [Int-area] [ippm] encapsulation of IOA… Carlos Pignataro (cpignata)
- Re: [nvo3] [ippm] encapsulation of IOAM data in v… Carlos Pignataro (cpignata)
- Re: [nvo3] [ippm] [Int-area] encapsulation of IOA… Tom Herbert
- Re: [nvo3] [ippm] [Int-area] encapsulation of IOA… Tom Herbert
- Re: [nvo3] [Int-area] [ippm] encapsulation of IOA… Frank Brockners (fbrockne)
- Re: [nvo3] [Int-area] [ippm] encapsulation of IOA… 徐小虎(义先)
- Re: [nvo3] [Int-area] [ippm] encapsulation of IOA… Frank Brockners (fbrockne)
- Re: [nvo3] [ippm] [Int-area] encapsulation of IOA… Mickey Spiegel
- Re: [nvo3] [sfc] [ippm] [Int-area] encapsulation … Uma Chunduri
- Re: [nvo3] [ippm] [Int-area] encapsulation of IOA… Tom Herbert
- Re: [nvo3] [ippm] [Int-area] encapsulation of IOA… Frank Brockners (fbrockne)
- Re: [nvo3] [ippm] [Int-area] encapsulation of IOA… Tianran Zhou
- Re: [nvo3] [ippm] [Int-area] encapsulation of IOA… Frank Brockners (fbrockne)
- Re: [nvo3] [ippm] [Int-area] encapsulation of IOA… Tianran Zhou
- Re: [nvo3] [ippm] [Int-area] encapsulation of IOA… Shwetha Bhandari (shwethab)
- Re: [nvo3] [ippm] [Int-area] encapsulation of IOA… Tianran Zhou
- Re: [nvo3] [ippm] [Int-area] encapsulation of IOA… Tom Herbert
- Re: [nvo3] [ippm] [Int-area] encapsulation of IOA… Tianran Zhou
- Re: [nvo3] [ippm] [Int-area] encapsulation of IOA… Frank Brockners (fbrockne)
- Re: [nvo3] [ippm] [Int-area] encapsulation of IOA… Tom Herbert
- Re: [nvo3] [ippm] [Int-area] encapsulation of IOA… Frank Brockners (fbrockne)
- Re: [nvo3] [ippm] [Int-area] encapsulation of IOA… Tom Herbert
- Re: [nvo3] [ippm] [Int-area] encapsulation of IOA… Frank Brockners (fbrockne)
- Re: [nvo3] [ippm] [Int-area] encapsulation of IOA… Tom Herbert
- Re: [nvo3] [ippm] encapsulation of IOAM data in v… John Lemon
- Re: [nvo3] [ippm] encapsulation of IOAM data in v… Greg Mirsky
- Re: [nvo3] [ippm] encapsulation of IOAM data in v… Greg Mirsky
- Re: [nvo3] [ippm] encapsulation of IOAM data in v… Frank Brockners (fbrockne)
- Re: [nvo3] [ippm] encapsulation of IOAM data in v… Greg Mirsky
- Re: [nvo3] [ippm] encapsulation of IOAM data in v… John Lemon
- Re: [nvo3] [ippm] encapsulation of IOAM data in v… Frank Brockners (fbrockne)
- Re: [nvo3] [sfc] [ippm] [Int-area] encapsulation … Carlos Pignataro (cpignata)
- Re: [nvo3] [sfc] [ippm] [Int-area] encapsulation … Tom Herbert
- Re: [nvo3] [sfc] [ippm] [Int-area] encapsulation … Carlos Pignataro (cpignata)
- Re: [nvo3] [sfc] [ippm] [Int-area] encapsulation … Tom Herbert
- Re: [nvo3] [sfc] [ippm] [Int-area] encapsulation … Carlos Pignataro (cpignata)