Re: [ippm] Call for adoption for draft-mirsky-ippm-hybrid-two-step

Greg Mirsky <gregimirsky@gmail.com> Tue, 26 September 2023 04:27 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 803FBC151982 for <ippm@ietfa.amsl.com>; Mon, 25 Sep 2023 21:27:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.104
X-Spam-Level:
X-Spam-Status: No, score=-7.104 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_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l0LoIyXkY-xn for <ippm@ietfa.amsl.com>; Mon, 25 Sep 2023 21:27:40 -0700 (PDT)
Received: from mail-yw1-x1131.google.com (mail-yw1-x1131.google.com [IPv6:2607:f8b0:4864:20::1131]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B058CC15171F for <ippm@ietf.org>; Mon, 25 Sep 2023 21:27:40 -0700 (PDT)
Received: by mail-yw1-x1131.google.com with SMTP id 00721157ae682-59f6767a15dso51018687b3.0 for <ippm@ietf.org>; Mon, 25 Sep 2023 21:27:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695702459; x=1696307259; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=9g1hY4TY5VWiHRj0whMCMxPeLCgafFXQxTR3mMuIRmk=; b=JCsM8KS1GxgAe7LIynsjPv/rnsG1PgxGq71IWq+G0TXcB1minkAECRdZAjrtYe8MwJ M0u6auR9H3k9Qgaz1cixF0K6k79CZNEEjgC5NqQ8G3ah25g3GBnBD4+ro5wsJ+yWcBgJ O/YG4W1Cef0CExnBALLgCnQffmcPiUn8UbHAC+F3udniR2Gh8l5RzdmE2GgChVG9umYI mBzkX9V7YvCX5aEJlbB1HTg7Ytwbx5Ew/s1MQLA7+dGGNdl8wx1TM2mWPNcMSkykzDCD 5GOyjDZoxtFfB13dKpHIXuvLcdsoW/u2F/pTpoM+2Lflv1dlPURMliJpr5M6g5DmZIOq wpyQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695702459; x=1696307259; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=9g1hY4TY5VWiHRj0whMCMxPeLCgafFXQxTR3mMuIRmk=; b=UZ0Ka+ovzcSFwOPVcpTQGO4XccRAgs0Z1Ir0AfQEiWurl2/ywc+kj0CmRpJp42M3FN tstl/zmINBnsh3CBlfMTWb+t7M0UfUasyA1AyGDW2S4fCc/TCkcVllrDIzi731Bsf31W IbqshfwBP5Xueo6NhP5IiJEsa+FuXPI3mxzwD+dAJRhyijYSvclwcxsSYC+dczTy/7L7 aJiPUVu4bFQBqDfFo4cq00Nmw/0Nhxc0eHsq+0R6/1FCuA4XSYrmDbdbBlo+GvIdNhTd IBpDNoohOLbkru2jOxnXc3JYGxT70hbue9bIg/FzqRv/gP5msBZMUyjA2qD657OOgr1x dHNQ==
X-Gm-Message-State: AOJu0Yww5UtVj394hLSCEHXnBMxc/tM4bqGw46UwdYq7Q7ZlTR9Aep+O 3e32H9ofclDAYzBqZM7aYQenaoaNk2Rd7SWRjmE=
X-Google-Smtp-Source: AGHT+IEzVxUC+4xhvPQ66TmI4N/EnnLlMUfhbgtYU9cOpgW/rs+68PG6FkSPYbiFmYOD34b2wnU3lMFvi1mMHm4g0aE=
X-Received: by 2002:a25:b20c:0:b0:d7b:9b9b:2fc3 with SMTP id i12-20020a25b20c000000b00d7b9b9b2fc3mr1241084ybj.3.1695702459293; Mon, 25 Sep 2023 21:27:39 -0700 (PDT)
MIME-Version: 1.0
References: <148C83FD-7102-405E-85AF-C29D0A265EB2@apple.com> <BY3PR13MB478715F8E6E77838AB513A0C9AFAA@BY3PR13MB4787.namprd13.prod.outlook.com> <CAM4esxR2qL5Eb1XMaOHzuU8Ro-KJfvrx2Dwy7pzMDyECSt_2Jw@mail.gmail.com>
In-Reply-To: <CAM4esxR2qL5Eb1XMaOHzuU8Ro-KJfvrx2Dwy7pzMDyECSt_2Jw@mail.gmail.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Mon, 25 Sep 2023 21:27:28 -0700
Message-ID: <CA+RyBmUaoGORAgtqPr9x7a1v00LAcKzBSYyuSgeerFN-k-Wazg@mail.gmail.com>
To: Martin Duke <martin.h.duke@gmail.com>
Cc: Haoyu Song <haoyu.song@futurewei.com>, Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>, IETF IPPM WG <ippm@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000bb24f306063b7e6d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/7NLdMdVTSX7PRUYNfP-dVx6xyew>
Subject: Re: [ippm] Call for adoption for draft-mirsky-ippm-hybrid-two-step
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.39
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: Tue, 26 Sep 2023 04:27:44 -0000

Hi Martin,
thank you for your kind consideration of this work and your thoughtful
comments. Please find my notes below under the GIM>> tag.

Regards,
Greg

On Thu, Sep 21, 2023 at 1:45 PM Martin Duke <martin.h.duke@gmail.com> wrote:

> I agree that this type of work is in-charter.
>
> I can't speak to whether this answers a big need or anyone would deploy
> it, but I don't see a fundamental problem with adoption, assuming there are
> satisfactory answers to the questions below.
>
GIM>> Thank you, Martin.

>
> I can see how something like this could go haywire, with followon packets
> getting misrouted, reordered, or lost, and wonder if we have enough
> experience with it to be a standard, or if we should instead aim for
> experimental.
>
GIM>> I agree that perhaps not all the corner cases have been sufficiently
analyzed and described in this version. I hope that if the fundamental
mechanism is seen as plausible, then handling the error cases can be
resolved by pulling together the expertise of the WG.

>
> Some more minor comments:
>
> I found the motivation in the introduction to be a bit hard to understand,
> and the abstract could use a sentence or two explaining what this protocol
> specifically does.
>
GIM>> Will work on update to clarify that.

>
> IIUC since the last major presentation @IETF 113, the model seems to have
> evolved from each intermediate node generating its own followon packet,
> instead the ingress node generates one and each intermediate node appends
> to the followup. I hope that's right?
>
GIM>> That is an option, than can be used based on the mode selected by an
operator. The goal of designing HTS is to provide an efficient mechanism
for collecting telemetry information generated by an on-path OAM protocol,
e.g., IOAM. The ability of a transit node to generate an additional
followup packet is intended to assist in collecting as much as possible of
available in the network telemetry information in case when the
ingress-originated packet is lost.

>
> It's also disturbing to me that there doesn't seem to be strong wire-image
> synchronization between the trigger packet and followon packet via a common
> sequence number or something else. This could lead to confusion at the
> egress.
>
GIM>> Thank you for pointing that out. We'll discuss and enhance the
mechanism with the followup packet sequencing mechanism.

>
> What assurances are there that the followon packet followed the same path
> from ingress to egress as the trigger packet? What are the consequences of
> this not happening and remaining undetected?
>
GIM>> It is assumed that the characteristic information that identifies the
flow monitored by the op-path OAM and the trigger packet also used to
identify the associated with it followup packets. I agree that a followup
packet may be misdirected. Will work on the detection mechanism in the
future versions.

>
> This is not very important, but I find "hybrid two-step" to be a
> nondescriptive name, and might prefer something like "IOAM Followon".
>
GIM>> While IOAM is an important on-path OAM mechanism, we believe that
other on-path mechanisms, e.g., the Alternate Marking method, can benefit
from combination with HTS.

>
> Martin
>
>
> On Tue, Sep 19, 2023 at 11:28 AM Haoyu Song <haoyu.song@futurewei.com>
> wrote:
>
>> IPPM WG,
>>
>>
>>
>> As a coauthor, I support the adoption of the draft as the WG document.
>> The hybrid approach complements with the other IOAM approaches well and has
>> its own merits.  Thanks!
>>
>>
>>
>> Best,
>>
>> Haoyu
>>
>>
>>
>> *From:* ippm <ippm-bounces@ietf.org> *On Behalf Of * Tommy Pauly
>> *Sent:* Wednesday, September 13, 2023 9:22 AM
>> *To:* IETF IPPM WG <ippm@ietf.org>
>> *Subject:* [ippm] Call for adoption for draft-mirsky-ippm-hybrid-two-step
>>
>>
>>
>> Hello IPPM,
>>
>>
>>
>> This email starts a call for adoption for
>> draft-mirsky-ippm-hybrid-two-step. This draft has been around for a while
>> and discussed several times on list and in WG meetings.
>>
>>
>>
>> https://datatracker.ietf.org/doc/draft-mirsky-ippm-hybrid-two-step/
>>
>> https://www.ietf.org/archive/id/draft-mirsky-ippm-hybrid-two-step-15.html
>>
>>
>>
>> Please review the document and email the list with your comments, and if
>> you think IPPM should adopt this work.
>>
>>
>>
>> This call for adoption will last three weeks and end on *October 4th*.
>>
>>
>>
>> Best,
>>
>> Tommy
>> _______________________________________________
>> 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
>