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
>