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

John Lemon <john.lemon@broadcom.com> Thu, 19 April 2018 16:09 UTC

Return-Path: <john.lemon@broadcom.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 2913B12DA51 for <nvo3@ietfa.amsl.com>; Thu, 19 Apr 2018 09:09:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=broadcom.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 szCH-BqH5KIb for <nvo3@ietfa.amsl.com>; Thu, 19 Apr 2018 09:09:29 -0700 (PDT)
Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::229]) (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 1F36F12DA46 for <nvo3@ietf.org>; Thu, 19 Apr 2018 09:09:25 -0700 (PDT)
Received: by mail-wr0-x229.google.com with SMTP id z73-v6so15549268wrb.0 for <nvo3@ietf.org>; Thu, 19 Apr 2018 09:09:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TnIKROjqurI/AVxekyILnwe0FF79ayW1+W4rtkdKG0s=; b=dq20W7spxth0zv1U/pqblfFOVVUcf2wfwrxiC6DrVZafa1QTjQqCXVnZ0kUWxLHdyL iLjALiqx8Wt5Bcep4AYUUVi41ICaIrQTrplxF1NTudVI3ppx+QrwDR5yyl4Qzwkeqzd4 xXUVhOOtpe/4oCSSyLDDGrqCDhUPrR2OWtwJk=
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=TnIKROjqurI/AVxekyILnwe0FF79ayW1+W4rtkdKG0s=; b=BDlron2ckeWJAuZWcY2koIot4jXtiD878Pz8AwxdXgTGA/WkYks38h7ob0iasbzpE8 tuWkyNuS3P/TD816MSCgCw0UP4n0pZiw1jg3op80dFH1mb0VFe6ofitG4cathCe90OG+ 2I7S1+sFDxv9/BbGzARbl0SKniP8JsPRsSt0PMMtDPJJEIpmtCq34hvWuOU2C8Ad57ZL FyS6bHaJi5jtKW9nRQbstvzrK7yJCSQDlGxL9tjtP8hVx9hU0+rKK9eklZttOZOYJzq8 nAfQd2wRn2AZdLoWCkSUWzJ3qjGExOBn7LUJRMA9TEAaZTltlVVQNUMXdNsdCo9AiZ48 KT4Q==
X-Gm-Message-State: ALQs6tC/GGs1s4g7Dr3f9yGFkRZciXxwUtS7BPrs88wLvfq247M682Ep l2iA85JJxwZhv/HfmDP/1r3BjlQ6+WuCDb1vtbmSgw==
X-Google-Smtp-Source: AIpwx4+D0ZTNstH4ix52cYM8pPgM8tTgQ7RA0YlKrredfq77hMzXFqRTg1AfPe+hJ2X0RSBJTa+12/RFoHfIiUsktBw=
X-Received: by 10.28.140.204 with SMTP id o195mr5167383wmd.35.1524154163516; Thu, 19 Apr 2018 09:09:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.170.155 with HTTP; Thu, 19 Apr 2018 09:09:22 -0700 (PDT)
In-Reply-To: <f48b40357e644666bdd5c51c63118f80@XCH-RCD-008.cisco.com>
References: <ff0c9182d1f14ec48b352e41fedaf58e@XCH-RCD-008.cisco.com> <CA+RyBmUNHcQZtTGJj67V=DqPkwV6GXWDUQJGjwT7ODEFg_QQFA@mail.gmail.com> <f48b40357e644666bdd5c51c63118f80@XCH-RCD-008.cisco.com>
From: John Lemon <john.lemon@broadcom.com>
Date: Thu, 19 Apr 2018 09:09:22 -0700
Message-ID: <CAPOJaHwZau-+jRRqK99dtTrw0t7E4gZRL_wM4ks9OWJ-YC1dpg@mail.gmail.com>
To: "Frank Brockners (fbrockne)" <fbrockne@cisco.com>
Cc: Greg Mirsky <gregimirsky@gmail.com>, NVO3 <nvo3@ietf.org>, "int-area@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="001a1145b872800055056a35cb70"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nvo3/Dxf2yD5anugN9A2cKs0R92X8-WI>
Subject: Re: [nvo3] [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, 19 Apr 2018 16:09:33 -0000

I never saw a response to the request for a pointer to an OOAM
implementation, so I assume none exist.

I've seen several good arguments for why the existing IOAM implementation,
for which several implementations exist, meets the needs for IOAM.

I think it is time to put to bed the request to examine merging OOAM and
IOAM. Let's move forward with IOAM and not hold it up.

Respectfully, John


On Thu, Apr 12, 2018 at 11:06 AM, Frank Brockners (fbrockne) <
fbrockne@cisco.com> wrote:

> Hi Greg,
>
>
>
> thanks – and it seems that we’re on the same page with regards to
> efficiency (4 bytes of non-required overhead) and maturity (or lack of) of
> OOAM.
>
>
>
> On the IOAM implementation: There are several implementations of IOAM.
> Some of which have recently been worked on and shown at an IETF hackathon,
> see https://datatracker.ietf.org/meeting/100/materials/slides-
> 100-hackathon-sessa-in-situ-oam-ioam - where we’ve shown IPv6 and
> VXLAN-GPE with IOAM – on FD.io/VPP as well as on Barefoot Tofino. You
> probably also remember the Netronome/Broadcom demo -
> https://www.youtube.com/watch?v=j9FbD4a3F4E .
>
> Below you seem to be specifically referring to the IOAM open source
> implementation in FD.io/VPP: There are protocol encapsulations for
> VXLAN-GPE, NSH, and IPv6 implemented in FD.io/VPP. The current code uses
> the “next header approach” for VXLAN-GPE and it leverages MD-Type 2 for
> NSH. As you’re well aware, there the discussion in SFC whether to use
> MD-Type 2 or next header encapsulating IOAM data in NSH isn’t yet settled,
> hence we’ll refrain from updating the code until SFC WG has come to a
> conclusion.
>
>
>
> Could you provide a pointer to an OOAM implementation?
>
>
>
> Thanks,
>
> Frank
>
>
>
> *From:* Greg Mirsky <gregimirsky@gmail.com>
> *Sent:* Donnerstag, 12. April 2018 18:54
> *To:* Frank Brockners (fbrockne) <fbrockne@cisco.com>
> *Cc:* IETF IPPM WG <ippm@ietf.org>; NVO3 <nvo3@ietf.org>; Service
> Function Chaining IETF list <sfc@ietf.org>; int-area@ietf.org
> *Subject:* Re: [ippm] encapsulation of IOAM data in various protocols -
> follow up from WG discussion in London
>
>
>
> 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.
>
> 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
> <https://tools.ietf.org/html/draft-ooamdt-rtgwg-demand-cc-cv-03>.
>
>
>
> 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
>
>
>
> _______________________________________________
> ippm mailing list
> ippm@ietf.org
> https://www.ietf.org/mailman/listinfo/ippm
>
>