Re: [ippm] Fwd: New Version Notification for draft-mirsky-ippm-hybrid-two-step-07.txt

Greg Mirsky <gregimirsky@gmail.com> Mon, 17 May 2021 02:22 UTC

Return-Path: <gregimirsky@gmail.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 05F0C3A227B; Sun, 16 May 2021 19:22:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 s8xPPJB8psLB; Sun, 16 May 2021 19:22:26 -0700 (PDT)
Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 438C73A2274; Sun, 16 May 2021 19:22:23 -0700 (PDT)
Received: by mail-lf1-x136.google.com with SMTP id i22so6402344lfl.10; Sun, 16 May 2021 19:22:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YjSV/bdvSu/fAsyIgHxq5rrMvxz3Q9WSZjXP/jZ9/uk=; b=PMoOR1mAtpIBsQXkwAuW+KxbJ6iDZI9nC4IF+AOqY4cxaFHCEy8d6NntDjjsy/WBT0 kl6A7mwVt7KAPF2zYbfhl9hMw2n219TjH86XA+ag8bFNj+3LILeMnsGW8QNLfRk7QsyC HMJuB6ml2q6Y1xZTPKQHk604QT48qVdjqEIQqq3NGssniAxXrI+NEGiuKAgXwQyV1Wwh bEZEzE5t0w+3Aid/uXitVC49X0kCUfGs/bfcgGjYdYWOkrcwAPGYdeJTnLLHede6CXj1 dgJFoWEjCeWBiepobZv0aXSHfwcZ9+4xsyiC5ifSk3IdGCP2DtgqpIs39oZTMrknwplz gRbg==
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=YjSV/bdvSu/fAsyIgHxq5rrMvxz3Q9WSZjXP/jZ9/uk=; b=BP50QvcSuQDq5cLWmrcUTj5KZZi5YA1wSvpMCh38cr5YqsmEy0NSn8qCX6E62L72ng 9rlBaFAicZemkVr1DFlZOn5UIPPTY+yAhZt6vTA7mDyvUJ0qgMZBd9bSRpGMyk+75T/3 xYwrg+gsmuiAI7O+RuhZbsWfZRdM5GAAzj9i6g5XUtCPfoc2V4MPivZ+M4Hze96iJUmu g1wYYng7jtiublU11dlB6iURK7d6WWRvUwNQGJiebIlZS4ypNxfpPG8KhVDNZueooVW6 5WWmkL7CFt4fPb5+tl0UMN3hrouvMJuicMVH7s/uoDuhNxoFll6lZJ0a91pWilbP/F5w EEJw==
X-Gm-Message-State: AOAM533MFvghqtcDdgHYRSRhzN2GhY8xQrDokX5KPH2bQ5pQINSsF/fB /l9ODwfFcHBntRPWpA0E/+sxgDjQUuxUZ1STd8I=
X-Google-Smtp-Source: ABdhPJx/qhO3T2VSNU6Yt3aV8L5uQ0UC/fgnS0fOB0XlGg4Sm7JeztItAyV/l81wJjopEM42N/BE7WL/IstkZJNJzog=
X-Received: by 2002:a05:6512:114e:: with SMTP id m14mr42278669lfg.385.1621218139945; Sun, 16 May 2021 19:22:19 -0700 (PDT)
MIME-Version: 1.0
References: <160713850373.20757.3773225088751978175@ietfa.amsl.com> <CA+RyBmXnS587yKBSJvkMx1eE8WKbqf8PvF5i8VU6PzhH8MD-_w@mail.gmail.com> <BYAPR11MB258488F725A9E19B67707ADFDA9E9@BYAPR11MB2584.namprd11.prod.outlook.com>
In-Reply-To: <BYAPR11MB258488F725A9E19B67707ADFDA9E9@BYAPR11MB2584.namprd11.prod.outlook.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Sun, 16 May 2021 19:22:10 -0700
Message-ID: <CA+RyBmVYkfVDnUPZ5b5+45QWDvSyJgTW94R8Owrn5n1nQN46oA@mail.gmail.com>
To: "Frank Brockners (fbrockne)" <fbrockne@cisco.com>
Cc: IETF IPPM WG <ippm@ietf.org>, "draft-mirsky-ippm-hybrid-two-step@ietf.org" <draft-mirsky-ippm-hybrid-two-step@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000055c11205c27d438b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/_NGgV5kLPA32w3kGz-fbH5UdwlU>
Subject: Re: [ippm] Fwd: New Version Notification for draft-mirsky-ippm-hybrid-two-step-07.txt
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: Mon, 17 May 2021 02:22:32 -0000

Hi Frank,
apologies for the delay. I've prepared the update and hope it follows your
suggestion:
OLD TEXT:
   The HTS method uses the HTS Follow-up packet, referred to as the
   follow-up packet, to collect measurement and network state data from
   the nodes.  The node that creates the HTS Trigger also generates the
   HTS Follow-up packet.  The follow-up packet contains characteristic
   information, copied from the trigger packet, sufficient for
   participating HTS nodes to associate it with the original packet.
   The exact composition of the characteristic information is specific
   for each transport network, and its definition is outside the scope
   of this document.

NEW TEXT:
   The HTS method uses the HTS Follow-up packet, referred to as the
   follow-up packet, to collect measurement and network state data from
   the nodes.  The node that creates the HTS Trigger also generates the
   HTS Follow-up packet.  The follow-up packet contains characteristic
   information, copied from the trigger packet, sufficient for
   participating HTS nodes to associate it with the original packet.  As
   the follow-up packet is expected to traverse the same sequence of
   nodes, one element of the characteristic information is the
   information that determines the path in the data plane.  For example,
   in a segment routing domain [RFC8402], a list of segment identifiers
   of the trigger packet is applied to the follow-up packet.  And in the
   case of the service function chain based on the Network Service
   Header [RFC8300], the Base Header and Service Path Header of the
   trigger packet will be applied to the follow-up packet.  Also, when
   HTS is used to collect the telemetry information in an IOAM domain,
   the IOAM trace option header [I-D.ietf-ippm-ioam-data] of the trigger
   packet is applied in the follow-up packet.  The follow-up packet also
   uses the same network information used to load-balance flows in
   equal-cost multipath (ECMP) as the trigger packet, e.g., IPv6 Flow
   Label [RFC6437] or an entropy label [RFC6790].  The exact composition
   of the characteristic information is specific for each transport
   network, and its definition is outside the scope of this document.

I much appreciate your feedback.

Regards,
Greg

On Thu, Feb 25, 2021 at 8:06 AM Frank Brockners (fbrockne) <
fbrockne@cisco.com> wrote:

> Hi Greg,
>
>
>
> Per the discussion in the last IOAM DT meeting: One particular aspect that
> your updated version (thanks for that) does not yet cover is how the “HTS
> trigger packet” and the “HTS follow-up packet” would be associated to each
> other. Section 4 mentions that “The exact composition of the characteristic
> information is specific for each transport network, and its definition is
> outside the scope of this document.”, still it would be great to have at
> least one or two examples on how this would be achieved. Would you mind
> outlining an example or two?
>
>
>
> Thanks, Frank
>
>
>
> *From:* ippm <ippm-bounces@ietf.org> *On Behalf Of * Greg Mirsky
> *Sent:* Samstag, 5. Dezember 2020 21:39
> *To:* IETF IPPM WG <ippm@ietf.org>rg>; IPPM Chairs <ippm-chairs@ietf.org>
> *Cc:* draft-mirsky-ippm-hybrid-two-step@ietf.org
> *Subject:* [ippm] Fwd: New Version Notification for
> draft-mirsky-ippm-hybrid-two-step-07.txt
>
>
>
> Dear All,
>
> the new version of the Hybrid Two-Step draft introduces the Authentication
> sub-TLV and defines its use in protecting the integrity of the data
> collected from each node. the Authentication sub-TLV may be added to the
> Telemetry Data TLV in which the node copies telemetry information as
> specified in the Trigger packet. The Telemetry Data TLV, in turn, collected
> in the HTS Follow-up packet(s).
>
> Also added is the request to allocate the HTS option from the IOAM
> Option-Type registry.
>
> Of course, some editorial changes.
>
> The authors believe that the draft provides a sufficiently detailed
> specification of the HTS protocol which is complementary to IOAM Trace
> Options, IOAM Direct Export, and Postcard-Based Telemetry methods of
> collecting the telemetry information. We would greatly appreciate the
> consideration of its adoption by the IPPM WG.
>
>
>
> Regards,
>
> Greg
>
> ---------- Forwarded message ---------
> From: <internet-drafts@ietf.org>
> Date: Fri, Dec 4, 2020 at 7:21 PM
> Subject: New Version Notification for
> draft-mirsky-ippm-hybrid-two-step-07.txt
> To: Haoyu Song <hsong@futurewei.com>om>, Wang Lingqiang <
> wang.lingqiang@zte.com.cn>gt;, Greg Mirsky <gregimirsky@gmail.com>om>, Guo Zhui
> <guo.zhui@zte.com.cn>
>
>
>
>
> A new version of I-D, draft-mirsky-ippm-hybrid-two-step-07.txt
> has been successfully submitted by Greg Mirsky and posted to the
> IETF repository.
>
> Name:           draft-mirsky-ippm-hybrid-two-step
> Revision:       07
> Title:          Hybrid Two-Step Performance Measurement Method
> Document date:  2020-12-04
> Group:          Individual Submission
> Pages:          17
> URL:
> https://www.ietf.org/archive/id/draft-mirsky-ippm-hybrid-two-step-07.txt
> Status:
> https://datatracker.ietf.org/doc/draft-mirsky-ippm-hybrid-two-step/
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-mirsky-ippm-hybrid-two-step
> Htmlized:
> https://tools.ietf.org/html/draft-mirsky-ippm-hybrid-two-step-07
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-mirsky-ippm-hybrid-two-step-07
>
> Abstract:
>    Development of, and advancements in, automation of network operations
>    brought new requirements for measurement methodology.  Among them is
>    the ability to collect instant network state as the packet being
>    processed by the networking elements along its path through the
>    domain.  This document introduces a new hybrid measurement method,
>    referred to as hybrid two-step, as it separates the act of measuring
>    and/or calculating the performance metric from the act of collecting
>    and transporting network state.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>