Re: [ippm] Second WGLC for draft-ietf-ippm-ioam-data
Mickey Spiegel <mspiegel@barefootnetworks.com> Sat, 30 May 2020 22:35 UTC
Return-Path: <mspiegel@barefootnetworks.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A4203A0B38 for <ippm@ietfa.amsl.com>; Sat, 30 May 2020 15:35:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.698
X-Spam-Level:
X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: invalid data)" header.d=barefootnetworks.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 cXugZLZVVwbZ for <ippm@ietfa.amsl.com>; Sat, 30 May 2020 15:35:01 -0700 (PDT)
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (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 7783D3A0B35 for <ippm@ietf.org>; Sat, 30 May 2020 15:35:01 -0700 (PDT)
Received: by mail-ed1-x536.google.com with SMTP id c35so4479799edf.5 for <ippm@ietf.org>; Sat, 30 May 2020 15:35:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=barefootnetworks.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=T9H4vMTDBHbjgTX+sCjM1QilFE7O64DRRKhcX3mJ2wg=; b=XiggfQpiESQCvvvdpAKLYmXb2spKl8A1bGph/p/u/LQCYFq8hksLCE6a/TXoBCrgaP E7gt2zfgP3J7eZUPULZfq1JgNp9+4SrM/eUTP9pJzj4BbtuslwGnSRr6vtixwMxBz5yG Fc5v59MrqystRdsdUpgaXaATLvFGrW/cqMDVc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=T9H4vMTDBHbjgTX+sCjM1QilFE7O64DRRKhcX3mJ2wg=; b=dW0loEE4qMTJMZltTb/E1k0BgDydsK1PEiyU7rrpyEhX8Gtw9oMyhn8pp+bu/vByCS iJtVloW78j6GtY9cT8tqxNpfx8KmBlfqtXr186LVK0mPglZ8nSlfl6I7/LUXQ2gH4uEX Tk6FSEXu4AB6PZjIuYTzUdtvDaQN19eZxjDynxdb/aLeYfeWaMPn/fB/C0z23sbsZp4O DaNZns8hQc3ImxcvR5qCMW4EY7PAZlYuhs9OQ/rTiKCEIk5qf4T1Lj8Iy9hqJxSHzAkl U/GhZO11H9V1Ei/AKMNGz5za97tu5U7YjtC13IXoVnijw/p5y+ZCihTAtnxxNAPY1M7N u/mQ==
X-Gm-Message-State: AOAM533hk8fUMczs70zGPLj/dVbSEv9hwsei6QRHegpOaueSWfW40YQV SoSZQ00Rxz8efp2gIhWEKzVFnlO/AAnBga0fgMYt+Q==
X-Google-Smtp-Source: ABdhPJz3J0snFFG30DcoWvwAdE1Kd2PPb+KraiNFzq3T1GsK7bHZ/2U/TM3F//s52fM8DnT8OdYTb5FOPQj+QTEBLyY=
X-Received: by 2002:a50:f106:: with SMTP id w6mr8624329edl.131.1590878099833; Sat, 30 May 2020 15:34:59 -0700 (PDT)
MIME-Version: 1.0
References: <BYAPR11MB2584659A9B2E9D40C08FF6A7DA8F0@BYAPR11MB2584.namprd11.prod.outlook.com> <202005301541296990515@zte.com.cn>
In-Reply-To: <202005301541296990515@zte.com.cn>
From: Mickey Spiegel <mspiegel@barefootnetworks.com>
Date: Sat, 30 May 2020 15:34:51 -0700
Message-ID: <CACYmcDoTKWQ6ZzGtF7P99PBwgY4B631DKCR-s9S6HiXH9awF0A@mail.gmail.com>
To: xiao.min2@zte.com.cn
Cc: "Frank Brockners (fbrockne)" <fbrockne@cisco.com>, Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>, IETF IPPM WG <ippm@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000059bc205a6e52ce6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/jxqBJpPWOsruBeXTRx2fOBv_7Dg>
Subject: Re: [ippm] Second WGLC for draft-ietf-ippm-ioam-data
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 30 May 2020 22:35:05 -0000
Frank and Xiao Min, Please see comments inline with [MS]. On Sat, May 30, 2020 at 12:42 AM <xiao.min2@zte.com.cn> wrote: > Hi Frank, > > > Please see my inline response with <XM2>. > > > Best Regards, > > Xiao Min > 原始邮件 > *发件人:*FrankBrockners(fbrockne) <fbrockne@cisco.com> > *收件人:*肖敏10093570; > *抄送人:*ippm@ietf.org <ippm@ietf.org>;tpauly=40apple.com@dmarc.ietf.org > <tpauly=40apple.com@dmarc.ietf.org>; > *日 期 :*2020年05月29日 19:00 > *主 题 :**RE: Re:[ippm] Second WGLC for draft-ietf-ippm-ioam-data* > > Hi Xiao Min, > > > > There have been quite a few proposals for additional data fields for IOAM > tracing, see e.g.https://github.com/inband-oam/ietf/issues/154 > > What we agreed in the past IPPM meetings was that we’d focus on finalizing > draft-ietf-ippm-ioam-data so that we have a stable foundation that we can > build upon. The definition of new fields is to be covered by new drafts. > > <XM2> I understand. It's reasonable, and by the way, I support its > publication. > > > > On your case for a second timestamp: This has been discussed in the past, > and so far the consensus was that a timestamp field and a transit-delay > field cover things quite flexibly, given that you can derive associated > times with simple operations (e.g. if timestamp covers packet-egress time > and you also capture transit-delay, you could easily calculate > packet-ingress time). > > <XM2> I understand your argument and it's acceptable to me, nevertheless, > the current text in section 4.4.2 doesn't reflect your statement that > timestamp can cover packet-egress time. > > In section 4.4.2, it says: > > timestamp seconds: 4-octet unsigned integer. Absolute timestamp in > seconds that specifies the time at which the packet was received > by the node. > > timestamp subseconds: 4-octet unsigned integer. Absolute timestamp > in subseconds that specifies the time at which the packet was > received by the node. > > Could you please direct me to the words in section 4.4.2 that say the > timestamp can cover packet-egress time? > [MS] In an earlier message, Frank wrote: draft-ietf-ippm-ioam-data already includes an option to timestamp packets > (see e.g. sections 4.4.2 and 4.6 in draft-ietf-ippm-ioam-data-09) which you > can use exactly the same way as you propose below, i.e. you can use the > timestamp field for the time, at which the packet was transmitted by the > node. What draft-ietf-ippm-ioam-data asks you to do is to properly document > when you timestamp the packet. [MS] This is not correct. As Xiao Min pointed out, in the IOAM Trace, the timestamp definition specifies "the time at which the packet was received by the node". [MS] In the IOAM Edge-to-Edge option, the timestamp behaves as described in Frank's comment above, varying in different implementations. [MS] Even with the timestamp fixed as an ingress timestamp, I agree with Frank's main point. An egress timestamp can be derived from the ingress timestamp plus the transit delay. Mickey > > > > Cheers, Frank > > > > *From:* xiao.min2@zte.com.cn <xiao.min2@zte.com.cn> > *Sent:* Freitag, 29. Mai 2020 11:00 > *To:* Frank Brockners (fbrockne) <fbrockne@cisco.com> > *Cc:* ippm@ietf.org; tpauly=40apple.com@dmarc.ietf.org > *Subject:* Re:[ippm] Second WGLC for draft-ietf-ippm-ioam-data > > > > Hi Frank, > > > > Many thanks for your reply to my comment. > > Please see my inline response with <XM>. > > > > Best Regards, > > Xiao Min > > 原始邮件 > > *发件人:*FrankBrockners(fbrockne) <fbrockne@cisco.com> > > *收件人:*肖敏10093570;ippm@ietf.org <ippm@ietf.org>;tpauly= > 40apple.com@dmarc.ietf.org <tpauly=40apple.com@dmarc.ietf.org>; > > *日**期**:*2020年05月29日 16:05 > > *主**题**:**RE: [ippm] Second WGLC for draft-ietf-ippm-ioam-data* > > Hi Xiao Min, > > > > my understanding is that there are devices which can calculate transit > delay, which is why the field was introduced quite a while ago. > > <XM> OK, I see, then it's very reasonable to reserve this field of transit > delay. > > > > draft-ietf-ippm-ioam-data already includes an option to timestamp packets > (see e.g. sections 4.4.2 and 4.6 in draft-ietf-ippm-ioam-data-09) which you > can use exactly the same way as you propose below, i.e. you can use the > timestamp field for the time, at which the packet was transmitted by the > node. What draft-ietf-ippm-ioam-data asks you to do is to properly document > when you timestamp the packet. > > <XM> My suggestion might not be clear enough. Actually I want to have two > timestamps carried in the hop-by-hop trace option data, one timestamp for > the receiving time and another timestamp for the transmitting time, then > after the IOAM Data is exported to the collecter, the collecter can use the > two timestamps to calculate the transit delay of each IOAM transit node. Do > you see it possible to add one more timestamp as IOAM node data field into > section 4.4.2? > > > > Cheers, Frank > > > > *From:* ippm <ippm-bounces@ietf.org>*On Behalf Of *xiao.min2@zte.com.cn > *Sent:* Freitag, 15. Mai 2020 09:51 > *To:* ippm@ietf.org; tpauly=40apple.com@dmarc.ietf.org > *Subject:* Re: [ippm] Second WGLC for draft-ietf-ippm-ioam-data > > > > Hi all, > > > > I have a comment on this draft. > > I was told by the implementers of my company that it's difficult to add > accurate transit delay into the trace option data. The reason is that in > order to calculate transit delay, the node firstly needs to obtain the time > at which the packet is transmitted by the node, which is obtained at PHY > layer, otherwise, the node can't do any calculation after the time is > obtained. > > If the above issue is common across different implementations, I suggest > to substitute the "transit delay" with '"timestamp" of the time at which > the packet is transmitted by the node. > > > > Best Regards, > > Xiao Min > > 原始邮件 > > *发件人:*TommyPauly <tpauly=40apple.com@dmarc.ietf.org> > > *收件人:*IETF IPPM WG <ippm@ietf.org>; > > *日期:*2020年05月15日 01:16 > > *主**题**:**[ippm] Second WGLC for draft-ietf-ippm-ioam-data* > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > > Hi IPPM, > > > > At our virtual interim meeting, we decided to > put draft-ietf-ippm-ioam-data through a second last call, based on the new > revisions, in mid-May. This email starts a two-week WGLC for this draft. > > > > The latest version can be found here: > https://tools.ietf.org/html/draft-ietf-ippm-ioam-data-09 > > > > This last call will end on *Thursday, May 28*. Please reply to > ippm@ietf.org with your reviews and comments. > > > > Thanks, > > Tommy & Ian > > > > > > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm >
- [ippm] Second WGLC for draft-ietf-ippm-ioam-data Tommy Pauly
- Re: [ippm] Second WGLC for draft-ietf-ippm-ioam-d… xiao.min2
- Re: [ippm] Second WGLC for draft-ietf-ippm-ioam-d… Greg Mirsky
- Re: [ippm] Second WGLC for draft-ietf-ippm-ioam-d… Frank Brockners (fbrockne)
- Re: [ippm] Second WGLC for draft-ietf-ippm-ioam-d… Tommy Pauly
- Re: [ippm] Second WGLC for draft-ietf-ippm-ioam-d… Frank Brockners (fbrockne)
- Re: [ippm] Second WGLC for draft-ietf-ippm-ioam-d… xiao.min2
- Re: [ippm] Second WGLC for draft-ietf-ippm-ioam-d… Frank Brockners (fbrockne)
- Re: [ippm] Second WGLC for draft-ietf-ippm-ioam-d… xiao.min2
- Re: [ippm] Second WGLC for draft-ietf-ippm-ioam-d… Mickey Spiegel
- Re: [ippm] Second WGLC for draft-ietf-ippm-ioam-d… MORTON, ALFRED C (AL)
- Re: [ippm] Second WGLC for draft-ietf-ippm-ioam-d… Frank Brockners (fbrockne)
- Re: [ippm] Second WGLC for draft-ietf-ippm-ioam-d… MORTON, ALFRED C (AL)
- Re: [ippm] Second WGLC for draft-ietf-ippm-ioam-d… Frank Brockners (fbrockne)
- Re: [ippm] Second WGLC for draft-ietf-ippm-ioam-d… Frank Brockners (fbrockne)