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

Hi Tianran,
I think that I have a general understanding of STAMP and IOAM. I agree that
combining STAMP and IOAM can be operationally useful. But I cannot find any
need for any extensions to STAMP in order to achieve those advantages. IOAM
works on a network layer, e.g., IPv6, MPLS, or even Service
Function Chaining with Network Service Header. But the application of IOAM
to a data flow or a flow of test packets does not require any special
add-ons on the part of the protocol that sources those packets. For
example, if IOAM is added to the encapsulation of ICMPv6 or LSP Ping, would
that, in your opinion, require an extension to ICMPv6 or LSP Ping? I don't
see the path of extending this and that protocol as a good approach. In my
opinion, exporting on-path IOAM information is a task for a function that
is part of the management plane. And if an operator sees a benefit of
combining IOAM with a bidirectional protocol, e.g., BFD or STAMP, then that
is a part of the configuration process that can be approached using an
extension of a YANG model.

Regards,
Greg

On Thu, Aug 17, 2023 at 6:39 PM Tianran Zhou <zhoutianran@huawei.com> wrote:

> Hi Greg,
>
>
>
> > I think that collection of on-path telemetry information is more
> suitable for the management plane, not for OAM.
>
>
>
> It seems you think this is to collect on-path telemetry data.
>
> IMHO, this is the key misunderstanding of the proposal. It’s not on-path
> telemetry. It’s actually active probe, just with IOAM in network layer(say
> IPv6) to collect node information.
>
> As described in our draft, with only one end to end stamp session, the
> probe can get hop by hop measurement. Together with SR, this probe can also
> go through a designated path.
>
> https://datatracker.ietf.org/doc/draft-wang-ippm-stamp-hbh-extensions/
>
>
>
> Best,
> Tianran
>
>
>
> *From:* ippm [mailto:ippm-bounces@ietf.org] *On Behalf Of *Greg Mirsky
> *Sent:* Friday, August 18, 2023 9:19 AM
> *To:* Rakesh Gandhi <rgandhi.ietf@gmail.com>
> *Cc:* IETF IPPM WG <ippm@ietf.org>
> *Subject:* Re: [ippm] New Version Notification for
> draft-gandhi-ippm-stamp-ioam-00.txt
>
>
>
> 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.
>    - 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.
>
> 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 <rgandhi.ietf@gmail.com>
> 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:
> https://www.ietf.org/archive/id/draft-gandhi-ippm-stamp-ioam-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-gandhi-ippm-stamp-ioam/
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-gandhi-ippm-stamp-ioam
>
>
> 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
> ippm@ietf.org
> https://www.ietf.org/mailman/listinfo/ippm
>
>