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

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 <rgandhi.ietf@gmail.com>
wrote:

> Thanks Greg for your comments. Please see inline tagged with <RG>...
>
> On Thu, Aug 17, 2023 at 9:18 PM Greg Mirsky <gregimirsky@gmail.com> 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.
> https://datatracker.ietf.org/doc/html/rfc9378#name-active-flag
>
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?

>
>
>>    - 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.
> https://datatracker.ietf.org/doc/draft-ietf-mpls-mna-hdr/
>
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.

>
> 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 <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
>>>
>>