Re: [nvo3] [ippm] [Int-area] encapsulation of IOAM data in various protocols - follow up from WG discussion in London
Tom Herbert <tom@herbertland.com> Tue, 17 April 2018 14:22 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 BC8AD12EB8B for <nvo3@ietfa.amsl.com>; Tue, 17 Apr 2018 07:22:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 aunU4IQioRAB for <nvo3@ietfa.amsl.com>; Tue, 17 Apr 2018 07:22:50 -0700 (PDT)
Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (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 5A52012EB45 for <nvo3@ietf.org>; Tue, 17 Apr 2018 07:22:47 -0700 (PDT)
Received: by mail-qt0-x22c.google.com with SMTP id j3so19055048qtn.9 for <nvo3@ietf.org>; Tue, 17 Apr 2018 07:22:47 -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=bCTmpLd5F1RIJgSQZYHYotj2csGMi0rsi4ym5PHS4ks=; b=Xd5M8THymwX6fTxUI4CSC/1j6WmAHhSUGeUD0/Ge19PZs8B5PPYJ2e6zP903F2QX2e YzNKhJzsjP0sn7Nr6bm5rmkWj+NdBadp50fYc+bhHVlT7AeSD0qwepHVouKX3kvoeEvN 9bV6RyHA24hHGwe8cjcin9lds65avGplzuMzBeNeKewzd9lVm1fspZv6C+2z7Gq4Ocxr 6MJBpPaf+G1eeSPM/Gnfflw9UG5zw7/kANSuaciL9Q8vZ7R018NK699GlTdtW0unLmoD KVBKUGTtpGBvOsSedo5ota075NWaLyhV+RD9r+ictuXcBXWIe2flhFVPCsx77t/wJvfy 0v0w==
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=bCTmpLd5F1RIJgSQZYHYotj2csGMi0rsi4ym5PHS4ks=; b=TSUlb3hhiPkT6suF+fQYNiBOSvZaMfue9FP/eYt5pTofMTKgXo7ZIRRQ2HHSN4P06G a/lD7giWIUEQsPvFzfRwjMPOybaPhYiDmrbFhe7A6u8gNSqogsxhjok2V00CkLTnHhsQ wJHD4+UbYD8RZcYlS5SCQBBUV+DIM8Aerv/KMxfcd5p24CqVilbvzvGRjE+Wiawx4S3E +nUxyHkZlMc8V4qbV1ShpvNriyPLI43vyFJ3EFV8AQ0kvNt3BK9ZEbfSz3xypmcmcn+T YsxPWjOMRSAVSYL3QZb2w9T2bT14+/XsKMkp8oTgfPBLU9jCD0tr1zAF0hh6+4HlUXlk jMZg==
X-Gm-Message-State: ALQs6tDRDIFQRLwKwVpJzqlUwwb9KpqWUTzS03fhV9aToEg+aBM8xDsd Q1vCevVNk54j5kwTzKRc0obqNKMvHvt1StxI7sKDkA==
X-Google-Smtp-Source: AIpwx489ZldZ8pWRdAwzbNQk77Elxb8+zg0kZjRXvA2oQYp6DDJzpqiLt7v6lNBv2H5BuJ5xiuz681U2HZvkR1ayqGs=
X-Received: by 10.237.62.103 with SMTP id m36mr2518948qtf.279.1523974966090; Tue, 17 Apr 2018 07:22:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.48.35 with HTTP; Tue, 17 Apr 2018 07:22:45 -0700 (PDT)
In-Reply-To: <d0d024faead143259d83fea6446e7237@XCH-RCD-008.cisco.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> <CACYmcDqd2gwUTmjj-BssB1Bh7EAVi6v_Uu6Qq9XXd2RbdMnGGw@mail.gmail.com> <CALx6S37aig+JJ8WPgC6NDeNExJ_qS9LZweSL2TOgD1EPqZRwTQ@mail.gmail.com> <CACYmcDqVzr9y-LyUzJPs98mrmGZynUCUiPwepNBQpsKdyweyPQ@mail.gmail.com> <fb963e482d074551853ce83816f24c7f@XCH-RCD-008.cisco.com> <BBA82579FD347748BEADC4C445EA0F21A6D62FA3@NKGEML515-MBX.china.huawei.com> <8d1b3bb4a1794c4fac3455257e0ab60e@XCH-RCD-008.cisco.com> <BBA82579FD347748BEADC4C445EA0F21A6D62FD6@NKGEML515-MBX.china.huawei.com> <C7371A46-50F6-4A08-9719-5B2AB51091B3@cisco.com> <BBA82579FD347748BEADC4C445EA0F21A6D63236@NKGEML515-MBX.china.huawei.com> <CALx6S377-PdtAno2Jho3E_JfOeHzAc+xzjWckZycdJYsWSqSQA@mail.gmail.com> <BBA82579FD347748BEADC4C445EA0F21A6D638D3@NKGEML515-MBX.china.huawei.com> <d0d024faead143259d83fea6446e7237@XCH-RCD-008.cisco.com>
From: Tom Herbert <tom@herbertland.com>
Date: Tue, 17 Apr 2018 07:22:45 -0700
Message-ID: <CALx6S35_7h7R04OPypFQVvmGdJdxfLstN--mVCZbh0jSEae6DA@mail.gmail.com>
To: "Frank Brockners (fbrockne)" <fbrockne@cisco.com>
Cc: Tianran Zhou <zhoutianran@huawei.com>, "Shwetha Bhandari (shwethab)" <shwethab@cisco.com>, Mickey Spiegel <mspiegel@barefootnetworks.com>, NVO3 <nvo3@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/pgK0QUjel1hfJ1gaCyGpBoqNYr8>
Subject: Re: [nvo3] [ippm] [Int-area] 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: Tue, 17 Apr 2018 14:22:58 -0000
On Tue, Apr 17, 2018 at 12:51 AM, Frank Brockners (fbrockne) <fbrockne@cisco.com> wrote: > > Hi Tianran, > > Tom's note already includes the hint: You'll add IOAM data to the protocol/layer that you're interested in monitoring. Again using Geneve over IPv6 as an example: > * If you're interested in the overlay, i.e. Geneve (e.g. timestamping the packet when it enters and exists the tunnel) - you'd add IOAM data to Geneve > * If you're interested in the underlay, i.e. IPv6 (e.g. you'd like to understand which path packets take in the v6 network) - you'd add IOAM data to IPv6 > * If you're interested in both, then you'd add IOAM data to Geneve and IPv6 > Frank, In that case why not just use a hop-by-hop option for measuring the underlay and a destination option for measuring the overlay? The advantage is that this works _any_ IP encapsulation method or any IP protocol for that matter. I don't believe adding ippm to every encapsulation protocol is straightforward: e.g. draft-brockners-ippm-ioam-geneve describe but notes the limited size of header, draft-weis-ippm-ioam-gre states that a new EtherType would be needed just for this purpose. This also entails additional encapsulation-specific HW support also, whereas support destination and hbh options could be more generic. Tom > Draft draft-ietf-ippm-ioam-data-02 already mentions layering (see section 3): > "Layering: If several encapsulation protocols (e.g., in case of tunneling) are stacked on top of each other, IOAM data-records could be present at every layer. The behavior follows the ships-in-the-night model." > > Given the discussion here, we'll add some additional text in the next revision to make things crisper (e.g. adding an example might help). > > Frank > > -----Original Message----- > From: Tianran Zhou <zhoutianran@huawei.com> > Sent: Dienstag, 17. April 2018 03:18 > To: Tom Herbert <tom@herbertland.com> > Cc: Shwetha Bhandari (shwethab) <shwethab@cisco.com>; Frank Brockners (fbrockne) <fbrockne@cisco.com>; Mickey Spiegel <mspiegel@barefootnetworks.com>; NVO3 <nvo3@ietf.org>; Service Function Chaining IETF list <sfc@ietf.org>; IETF IPPM WG <ippm@ietf.org> > Subject: RE: [ippm] [Int-area] encapsulation of IOAM data in various protocols - follow up from WG discussion in London > > I think it's better that Frank or Shwetha can explain the multi-layer use case in detail. > > Tianran >> -----Original Message----- >> From: Tom Herbert [mailto:tom@herbertland.com] >> Sent: Monday, April 16, 2018 10:40 PM >> To: Tianran Zhou <zhoutianran@huawei.com> >> Cc: Shwetha Bhandari (shwethab) <shwethab@cisco.com>; Frank Brockners >> (fbrockne) <fbrockne@cisco.com>; Mickey Spiegel >> <mspiegel@barefootnetworks.com>; NVO3 <nvo3@ietf.org>; int-area >> <int-area@ietf.org>; Service Function Chaining IETF list >> <sfc@ietf.org>; IETF IPPM WG <ippm@ietf.org> >> Subject: Re: [ippm] [Int-area] encapsulation of IOAM data in various >> protocols - follow up from WG discussion in London >> >> On Mon, Apr 16, 2018 at 6:31 AM, Tianran Zhou <zhoutianran@huawei.com> wrote: >> > Hi Shwetha, >> > >> > You are talking about the outer encapsution. It is straight forward >> > for the underlay to record by the header. But what about the >> > overlay, i.e., inner encapsulation(e.g. geneve)? Without special >> > configuration, intermediate node will not read the inner header, >> > hence not be able to process IOAM.e >> >> Hi Tianran, >> >> I believe that is also not protocol conformant. Intermediate nodes >> should not be processing transport layer data as this can lead to >> misinterpretation and possibly silent data corruption. >> >> For instance, Geneve is a UDP encapsulation protocol with assigned port 6081. >> In order for an intermediate device to process the Geneve >> encapsulation header it would need to look for packets with >> destination port of 6081 since that is the only possible >> discriminator. However, transport port numbers do not have global >> meaning and hosts may use port numbers for other purposes (RFC7605 >> describes this). So a packet to port 6081 might be something other >> than Geneve and may be misinterpreted. If a misinterpreted packet is changed (like ippm data is written) then that would be systematic silent data corruption. >> >> As far as I know, hop-by-hop options is the only protocol confirming >> mechanism that allows an intermediate note to change data of packet in flight. >> Encpasulation is the only conforming mechanism that allows an >> intermediate node to add data (like extension headers) to a packet in flight. >> >> Tom >> >> > Maybe we are not synced by this overlay/underlay use case. :-) >> > >> > Tianran >> > >> > >> > >> > ________________________________ >> > Sent from WeLink >> > >> > 发件人: Shwetha Bhandari (shwethab) >> > 收件人: Tianran Zhou<zhoutianran@huawei.com>;Frank Brockners >> > (fbrockne)<fbrockne@cisco.com>;Mickey >> > Spiegel<mspiegel@barefootnetworks.com>;Tom >> > Herbert<tom@herbertland.com> >> > 抄送: NVO3<nvo3@ietf.org>;int-area<int-area@ietf.org>;Service Function >> > Chaining IETF list<sfc@ietf.org>;IETF IPPM WG<ippm@ietf.org> >> > 主题: Re: [ippm] [Int-area] encapsulation of IOAM data in various >> > protocols - follow up from WG discussion in London >> > 时间: 2018-04-16 18:17:01 >> > >> > Hi Tianran, >> > >> >> If I recall right, it is not written in the ioam data draft. >> > >> > Data draft is defining the data to be carried in IOAM in an >> > encapsulation agnostic way, it does not specify how the >> > encapsulation protocol is configured. >> > >> > >> > >> >> Yes, node by node configuration is an easy way. >> > >> > While it is, it does not have to be a node by node configuration. It >> > can be part of the encapsulation definition. >> > >> > For e.g. If the encapsulation is IPv6 and if we define the data to >> > be carried as HbH options, then based on the Option Type with >> > highest order 2 bits set to 00 then the v6 nodes that implement IOAM >> > will process the option and others will skip over. >> > >> > >> > >> > >> > >> > Thanks, >> > >> > Shwetha >> > >> > >> > >> > From: ippm <ippm-bounces@ietf.org> on behalf of Tianran Zhou >> > <zhoutianran@huawei.com> >> > Date: Monday, April 16, 2018 at 2:36 PM >> > To: "Frank Brockners (fbrockne)" <fbrockne@cisco.com>, Mickey >> > Spiegel <mspiegel@barefootnetworks.com>, Tom Herbert >> > <tom@herbertland.com> >> > Cc: 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> >> > Subject: Re: [ippm] [Int-area] encapsulation of IOAM data in various >> > protocols - follow up from WG discussion in London >> > >> > >> > >> > Hi Frank, >> > >> > >> > >> > If I recall right, it is not written in the ioam data draft. >> > >> > Yes, node by node configuration is an easy way. In the >> > draft-zhou-ippm-ioam-yang, we have the “protocol-type” to indicate >> > the layering. >> > >> > +--rw ioam >> > >> > +--rw ioam-profiles >> > >> > +--rw enabled? boolean >> > >> > +--rw ioam-profile* [profile-name] >> > >> > +--rw profile-name string >> > >> > +--rw filter >> > >> > | +--rw filter-type? ioam-filter-type >> > >> > | +--rw acl-name? -> /acl:acls/acl/name >> > >> > +--rw protocol-type? ioam-protocol-type >> > >> > +--rw incremental-tracing-profile {incremental-trace}? >> > >> > | ... >> > >> > +--rw preallocated-tracing-profile {preallocated-trace}? >> > >> > | ... >> > >> > +--rw pot-profile {proof-of-transit}? >> > >> > | ... >> > >> > +--rw e2e-profile {edge-to-edge}? >> > >> > ... >> > >> > >> > >> > >> > >> > Tianran >> > >> > From: Frank Brockners (fbrockne) [mailto:fbrockne@cisco.com] >> > Sent: Monday, April 16, 2018 4:51 PM >> > To: Tianran Zhou <zhoutianran@huawei.com>; Mickey Spiegel >> > <mspiegel@barefootnetworks.com>; Tom Herbert <tom@herbertland.com> >> > Cc: NVO3 <nvo3@ietf.org>; int-area@ietf.org; Service Function >> > Chaining IETF list <sfc@ietf.org>; IETF IPPM WG <ippm@ietf.org> >> > Subject: RE: [ippm] [Int-area] encapsulation of IOAM data in various >> > protocols - follow up from WG discussion in London >> > >> > >> > >> > Hi Tianran, >> > >> > >> > >> > IOAM is a domain specific feature (see also >> > draft-ietf-ippm-ioam-data-02 sections 3 and 4), which allows an >> > operator to control by means of configuration where and for which >> > traffic IOAM data fields are added/updated/removed from the customer >> > traffic. Using your example of Geneve over IPv6 – with IOAM data in >> > both the Geneve and the IPv6 protocol, one would expect that the >> > operator configures the endpoints of the Geneve tunnel to operate on >> > the IOAM data in Geneve, and the IPv6 routers that the Geneve tunnel >> traverses to operate on the IOAM data in IPv6. >> > >> > >> > >> > Frank >> > >> > >> > >> > From: Tianran Zhou <zhoutianran@huawei.com> >> > Sent: Montag, 16. April 2018 10:37 >> > To: Frank Brockners (fbrockne) <fbrockne@cisco.com>; Mickey Spiegel >> > <mspiegel@barefootnetworks.com>; Tom Herbert <tom@herbertland.com> >> > Cc: NVO3 <nvo3@ietf.org>; int-area@ietf.org; Service Function >> > Chaining IETF list <sfc@ietf.org>; IETF IPPM WG <ippm@ietf.org> >> > Subject: RE: [ippm] [Int-area] encapsulation of IOAM data in various >> > protocols - follow up from WG discussion in London >> > >> > >> > >> > Hi Frank, >> > >> > >> > >> > How does a forwarder know when and where to insert the data? >> > >> > In the case of Geneve over IPv6, do you mean the device need to scan >> > all the protocol stack? Or just the outer encapsulation? >> > >> > >> > >> > Tianran >> > >> > >> > >> > From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Frank >> > Brockners >> > (fbrockne) >> > Sent: Monday, April 16, 2018 3:08 PM >> > To: Mickey Spiegel <mspiegel@barefootnetworks.com>; Tom Herbert >> > <tom@herbertland.com> >> > Cc: NVO3 <nvo3@ietf.org>; int-area@ietf.org; Service Function >> > Chaining IETF list <sfc@ietf.org>; IETF IPPM WG <ippm@ietf.org> >> > Subject: Re: [ippm] [Int-area] encapsulation of IOAM data in various >> > protocols - follow up from WG discussion in London >> > >> > >> > >> > >> > >> > Tom, >> > >> > >> > >> > a quick addition to what Mickey mentioned below: What you seem to >> > have in mind is what draft-ietf-ippm-ioam-data-02 refers to as “layering” >> > (see section 3.), i.e. if you’re running for example Geneve over >> > IPv6, then IOAM data could be encapsulated in both protocols, Geneve >> > and >> > IPv6 – giving you visibility into the “underlay” (IPv6) and the “overlay” >> (Geneve). >> > >> > >> > >> > Frank >> > >> > >> > >> > From: ippm <ippm-bounces@ietf.org> On Behalf Of Mickey Spiegel >> > Sent: Freitag, 13. April 2018 20:22 >> > To: Tom Herbert <tom@herbertland.com> >> > Cc: NVO3 <nvo3@ietf.org>; int-area@ietf.org; Service Function >> > Chaining IETF list <sfc@ietf.org>; IETF IPPM WG <ippm@ietf.org> >> > Subject: Re: [ippm] [Int-area] encapsulation of IOAM data in various >> > protocols - follow up from WG discussion in London >> > >> > >> > >> > Tom, >> > >> > >> > >> > On Thu, Apr 12, 2018 at 10:17 PM, Tom Herbert <tom@herbertland.com> wrote: >> > >> > Mickey, >> > >> > Looking at these ippm drafts more closely, I have a much more >> > fundamental concern. >> > >> > In draft-brockners-ippm-ioam-geneve-00 for instance, there is the >> > text in the introduction: >> > >> > "In-situ OAM (IOAM) records OAM information within the packet while >> > the packet traverses a particular network domain. The term "in-situ" >> > refers to the fact that the IOAM data fields are added to the data >> > packets rather than is being sent within packets specifically >> > dedicated to OAM. This document defines how IOAM data fields are >> > transported as part of the Geneve [I-D.ietf-nvo3-geneve] >> > encapsulation." >> > >> > I assume this means that as packets with Geneve encapsulation >> > traverse the network they are interpreted by intermediate nodes as >> > being Geneve. Since Geneve is a UDP encapsulation, then the >> > destination UDP port number would be used to identify packets as >> > being Geneve. So an intermediate device might be looking for UDP >> > packets destined to port >> > 6081 (the assigned UDP port for Geneve). If my understanding is >> > correct, then this is a problem. >> > >> > UDP port numbers do not have global meaning. An intermediate device >> > may very well see UDP packets destined to port 6081 that are not >> > actually Geneve. This scenario is discussed in RFC7605: >> > >> > "...intermediate device interprets traffic based on the port number. >> > It is important to recognize that any interpretation of port numbers >> > -- except at the endpoints -- may be incorrect, because port numbers >> > are meaningful only at the endpoints." >> > >> > If the UDP data is modified, as the draft would imply, then >> > misinterpretation may also mean silent data corruption of packets. A >> > protocol that would allow this seems pretty incorrect! Note that >> > this would be true also for any UDP encapsulation that the network >> > tries to interpret. >> > >> > >> > >> > The intention is to allow for multiple nodes that a packet traverses >> > >> > to be able to insert IOAM node information in the same trace option, >> > >> > but leave some flexibility regarding which nodes actually do the >> > >> > IOAM processing and the node information. This may vary >> > >> > depending on the transport. >> > >> > >> > >> > In case of a tunneled encapsulation such as Geneve or VXLAN, >> > >> > there may still be multiple hops. For example a network may use >> > >> > Geneve or VXLAN, but only do L2 processing at ToRs, with L3 >> > >> > processing done at aggregation or core switches. In this case >> > >> > many packets would do 2 Geneve or VXLAN hops, so the packet >> > >> > would contain IOAM node information from two nodes. >> > >> > >> > >> > Another example is service function chaining using Geneve or >> > >> > VXLAN rather than NSH. >> > >> > >> > >> > >> > I am also wondering if hop-by-hop options been considered for this >> > application? Their interpretation in the network is unabiguous and >> > they also have the advantage that the work with any IP protocol or >> > encapsulation. >> > >> > >> > >> > IPv6 hop-by-hop options has been considered. See >> > >> > draft-brockners-inband-oam-transport-05. This has not yet been >> > >> > broken out into a separate draft. >> > >> > >> > >> > Mickey >> > >> > >> > >> > >> > Thanks, >> > Tom >> > >> > >> > On Thu, Apr 12, 2018 at 3:31 PM, Mickey Spiegel >> > <mspiegel@barefootnetworks.com> wrote: >> > >> >> Tom, >> >> >> >> On Thu, Apr 12, 2018 at 2: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 >> >>> > GIM>>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. >> >> >> >> >> >> 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. >> >> >> >> 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 >> >>> > GIM>> 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 >> >>> > >> >>> >> >>> _______________________________________________ >> >>> ippm mailing list >> >>> ippm@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/ippm >> >> >> >> >> > >> >
- 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)