Re: [ippm] New Version Notification for draft-gandhi-ippm-stamp-ioam-00.txt

Rakesh Gandhi <> Sat, 07 October 2023 14:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4E953C151522 for <>; Sat, 7 Oct 2023 07:37:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.105
X-Spam-Status: No, score=-7.105 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_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wlpgIgb5ZTpG for <>; Sat, 7 Oct 2023 07:37:10 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::1130]) (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 (Postfix) with ESMTPS id 70665C151520 for <>; Sat, 7 Oct 2023 07:37:10 -0700 (PDT)
Received: by with SMTP id 00721157ae682-5a24b03e22eso37662157b3.0 for <>; Sat, 07 Oct 2023 07:37:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1696689429; x=1697294229;; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=p7F6QMfP84hWWCLI+508m2qn2Z82k5uEVDEELF8h09s=; b=MEwfhgBzpTDVXb22ycdKm+nTFnyzqM5CSYkJT4dHCjbN+uPAmTNfoElXzlxN0Punb1 KY4H+0yQN0hh4zV5y5Wjz2dQJ3H3SL56pJZeI9Gf5vqQpJW9vsgAkcwynm5HGg26kJ7O YBupQFyO/A7Z9TlZKIJ2Mg2vCzXu/8Dkh9CQC+UkK7jDiBN1kbzq7y8d3fFYx7IyJElv F8P6aTpxZT22H2VMF67dhZ9AHCiN/YsXp5IiqP3jiWY/CJSBVRgVOZUx2BaTeg13oJdm 5AwyLu2S023XtSlyG0HdPfInKT5s6lfgpF0clxwv1YiDNe15hcN9fB98j08MD1mu2D+z JwVg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1696689429; x=1697294229; 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=p7F6QMfP84hWWCLI+508m2qn2Z82k5uEVDEELF8h09s=; b=lJaT8IpCsE6wblMxo+J1QI+YPD2gWnHlf7eobmFkk6C+g4386qMXbapa9hyV1/K1Ba 1UmNWr9sQCx33EqMe5ubPAMaD9hgaxZF7/94o7LrRyI51WTXm565LKZUuP9SubfzjY9o fru/3m2ieKp4jtk2RrOtwzedUQPq9xU4CKNdkvgPpgHHI41V6V0MmKb6xWnrUxTP+nCJ O3Phg3MbZvFr/jnpaurNXd2rstmjr2GNljdd90b/NCoMylIo5g0CZjhbBKIYadtKXAJB 757d5bbXb0q91iedQCR9guWQixu5sAh3HwQ5jR9SoOXPgdg8kwtGS4SY8dwtkEe+Ukqw fAGw==
X-Gm-Message-State: AOJu0YyLR7kB/LPm60t79KmeZh+u4+rycZW17I4RN4BTtcdkdCCWkD7c WSbYF4Piqv6yKE3gmWHYB9mWcEeTy55FA7Mcww==
X-Google-Smtp-Source: AGHT+IFG7qWKMs10XcWs7s3i80PCN1NRD47TXCYF+hSRbR9RgkSCUqsDts3COouDBfBAWA8qb3UsK7XXYIOzFvtC9bE=
X-Received: by 2002:a81:430b:0:b0:5a5:575:e86f with SMTP id q11-20020a81430b000000b005a50575e86fmr9144580ywa.34.1696689429476; Sat, 07 Oct 2023 07:37:09 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
From: Rakesh Gandhi <>
Date: Sat, 07 Oct 2023 10:36:58 -0400
Message-ID: <>
To: Greg Mirsky <>
Content-Type: multipart/alternative; boundary="000000000000bcfa8e0607214ae0"
Archived-At: <>
Subject: Re: [ippm] New Version Notification for draft-gandhi-ippm-stamp-ioam-00.txt
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 07 Oct 2023 14:37:11 -0000

Hi Greg,

Thank you for your comments. Please see inline with <RG2>...

On Mon, Aug 21, 2023 at 6:44 PM Greg Mirsky <> wrote:

> Hi Rakesh,
> I appreciate your consideration of my notes. I have added follow-ups below
> under the GIM>> tag.
> Regards,
> Greg
> On Mon, Aug 21, 2023 at 6:59 AM Rakesh Gandhi <>
> wrote:
>> Thanks Greg for your comments. Please see inline tagged with <RG>...
>> On Thu, Aug 17, 2023 at 9:18 PM Greg Mirsky <>
>> wrote:
>>> Hi Rakesh,
>>> thank you for bringing this contribution to the discussion. I have
>>> several notes on the problem and solution presented in the draft. Please
>>> find those below:
>>>    - As I understand it, the purpose of the proposed STAMP extensions
>>>    is to return collected in IOAM Preallocated or Incremental trace type modes
>>>    operational and telemetry information. That seems like not a generic
>>>    solution. I think that collection of on-path telemetry information is more
>>>    suitable for the management plane, not for OAM. If we consider Large-Scale
>>>    Measurement of Broadband Performance (LMAP) architecture, when a STAMP test
>>>    packet is combined with the IOAM Header, the Session-Reflector, from the
>>>    PoV of on-path telemetry measurement, may be viewed as the Measurement
>>>    Agent that exports information to a Collector. And such a Collector could
>>>    be co-located with the Session-Sender or be placed in several nodes. Would
>>>    you agree? It seems to me like a more generic solution would be beneficial
>>>    for operators.
>> <RG> Active measurement mode for IOAM is defined in RFC 9378. The draft
>> simply uses STAMP probe packets for active measurement and leverages
>> midpoint treatment as described in RFC 9378.
> GIM>> I don't think that RFC 9378 is intended to define anything. I think
> that it, as the Informational track document, provides information that
> might be useful to a reader. IOAM's Active flag, as I understand it, could
> be useful in case the payload is not a conventional test packet that is
> identified by, for example, a UDP destination port. In that case, we could
> expect that an IOAM edge node will drop the packet if the IOAM header
> carries the Active flag. Since your proposal uses the STAMP test message, I
> cannot find an additional benefit of using the IOAM Active flag. Am I
> missing something here?

<RG2> Agree that STAMP packet would not require an active flag. I believe
the active measurement is within the scope of IOAM.

>>>    - And a minor note about the applicability of IOAM in the MPLS
>>>    Network Action discussion. As I understand it, the MPLS WG is still in the
>>>    discussion of which mode of IOAM tracing to support with the MNA solution.
>>>    It could be that only the IOAM-DEX mode will be supported with In-Stack
>>>    Data (ISD) MNA. It seems like if that is the direction the MPLS WG takes,
>>>    the proposed STAMP extensions would not be useful in MPLS underlays, e.g.,
>>>    IP/MPLS or SR-MPLS.
>> <RG> Solution for MPLS Network Action (MNA) Sub-stack is defined in the
>> MPLS WG document. It can be carried by STAMP packets for MPLS data planes
>> that can leverage midpoint treatment for active measurement.
> GIM>> I got confused by the second sentence. Do you envision IOAM being
> part of STAMP when the underlay is an MPLS network? If you could draw an
> example of such an arrangement, that would be most helpful.

<RG2> Yes. I believe this is in the draft in Section 3.2.


>> thanks,
>> Rakesh
>> My notes above, as I think of it, are also relevant to the work presented
>>> at our IETF-117 session. In fact, these notes are an extended version of my
>>> comments at the mic.
>>> Regards,
>>> Greg
>>> On Thu, Aug 17, 2023 at 6:50 AM Rakesh Gandhi <>
>>> wrote:
>>>> Hi WG,
>>>> Like to request your review comments and thoughts on the following new
>>>> draft on STAMP extensions for HBH.
>>>> Thanks,
>>>> Rakesh
>>>>> A new version of I-D, draft-gandhi-ippm-stamp-ioam-00.txt
>>>>> has been successfully submitted by Rakesh Gandhi and posted to the
>>>>> IETF repository.
>>>>> Name:           draft-gandhi-ippm-stamp-ioam
>>>>> Revision:       00
>>>>> Title:          Simple TWAMP (STAMP) Extensions for Hop-By-Hop and
>>>>> Edge-To-Edge Measurements
>>>>> Document date:  2023-08-16
>>>>> Group:          Individual Submission
>>>>> Pages:          13
>>>>> URL:
>>>>> Status:
>>>>> Htmlized:
>>>>> Abstract:
>>>>>    Simple Two-Way Active Measurement Protocol (STAMP) defined in RFC
>>>>>    8762 and its optional extensions defined in RFC 8972 can be used for
>>>>>    Edge-To-Edge (E2E) active measurement.  In Situ Operations,
>>>>>    Administration, and Maintenance (IOAM) data fields defined in RFC
>>>>>    9197 and RFC 9326 can be used for recording and collecting
>>>>> Hop-By-Hop
>>>>>    (HBH) and E2E operational and telemetry information.  This document
>>>>>    extends STAMP to carry IOAM data fields for HBH and E2E two-way
>>>>>    active measurement and telemetry.  The STAMP extensions are generic
>>>>>    and allow to carry and reflect any type of IPv6 option and MPLS
>>>>>    Network Action Sub-Stacks for two-way active measurement.
>>>>> The IETF Secretariat
>>>>> _______________________________________________
>>>> ippm mailing list