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

[Rakesh Gandhi <[e-mail]>]

Hi Greg,

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

On Mon, Aug 21, 2023 at 6:44 PM Greg Mirsky <[e-mail]> 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 <[e-mail]>
> wrote:
>
>> Thanks Greg for your comments. Please see inline tagged with <RG>...
>>
>> On Thu, Aug 17, 2023 at 9:18 PM Greg Mirsky <[e-mail]>
>> 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?
>

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

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

Thanks,
Rakesh




>
>> 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 <[e-mail]>
>>> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/ippm
>>>>
>>>