[mpls] Re: Comments on draft-mirsky-mpls-stamp-07

[Greg Mirsky <[e-mail]>]

Hi Li,
Thank you for your thoroughness and interest in this work; it is much
appreciated. I've addressed that occurrence and uploaded the new version. I
welcome you as a co-author and look forward to constructive cooperation.

Regards,
Greg

On Wed, Aug 21, 2024 at 7:11 PM zhangli (CE) <[e-mail]> wrote:

> Hi Greg,
>
>
>
> Thanks for your quick response and update, please find my response below
> tagged with Li>>.
>
>
>
> Best regards
>
> Li
>
>
>
> *发件人:* Greg Mirsky <[e-mail]>
> *发送时间:* 2024年8月22日 6:01
> *收件人:* zhangli (CE) <[e-mail]>
> *抄送:* [e-mail]
> *主题:* Re: Comments on draft-mirsky-mpls-stamp-07
>
>
>
> Hi Li,
>
> thank you for your interest in the draft and thoughtful comments; much
> appreciated. Please find my notes below tagged GIM>>. Attached are the
> working version and diff that highlights updates.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Wed, Aug 21, 2024 at 1:54 AM zhangli (CE) <[e-mail]>
> wrote:
>
> Hi Greg,
>
>
>
> I am interested in this draft and I just read it, here are my comments.
>
>
>
> 1.    In the second paragraph of introduction, it writes the “This
> document defines the Reflected Packet Path TLV”. However, this document
> defines “STAMP Session Identifier TLV” in section 3.1, so I suppose the “Reflected
> Packet Path TLV” should be replaced with “STAMP Session Identifier TLV”,
> is it right?
>
> GIM>> Great catch, thank you! You are absolutely correct, it must be
> changed to STAMP Session Identifier TLV. Please check in the working
> version.
>
>
>
> Li >> Good work, I checked the document in the attachment, there is
> another “STAMP Session Identifier TLV” also need to be replaced, it is in
> the seventh paragraph below Figure1 “If the STAMP Session-Reflector cannot
> find the path specified in the Reflected Packet Path TLV…”
>
>
>
>
>
> 2.    In section 3.1, the draft writes that “Reflected Packet Path field
> contains none, one or more sub-TLVs.”, if I understand correctly, each
> sub-TLV describes a route path(such as Non-FEC Path TLV). If there is only
> one reflected path specified, the Session-Reflector will reflect the test
> packet along the specific path. If there are multiple reflected path, how
> should the Session-Reflector do? Reflect the reflected-test packet on all
> the paths?
>
> GIM>> A very good question, thank you. I think that in some environments,
> e.g., SR-MPLS, a sub-TLV that defined for TLV Types 1, 16, and 21
> represents a segment, not the entire path. However, as you've noted,
> Non-FEC Path TLV can be used as alternative to using multiple sub-TLVs.
>
>
>
> Li>> Great, I think I am clear on this point now. The “Reflected Packet
> Path field” is used to describe one reflected path, if the sub-TLV
> represents a segment, then this “field” could contains one or more
> sub-TLVs, if the sub-TLV represents a path(Non-FEC Path TLV), then this
> “field” Should just contain one sub-TLV. Do I understand correctly?
>
>
>
> Best regards
>
>
>
> Li
>
>
>
> ---------- Forwarded message ---------
>
> From: <[e-mail]> <&lt;[e-mail]&gt;>
>
> Date: Mon, Mar 25, 2024 at 5:52 PM
>
> Subject: New Version Notification for draft-mirsky-mpls-stamp-07.txt
>
> To: Greg Mirsky <[e-mail]> <&lt;[e-mail]&gt;>
>
>
>
>
>
> A new version of Internet-Draft draft-mirsky-mpls-stamp-07.txt has been
>
> successfully submitted by Greg Mirsky and posted to the
>
> IETF repository.
>
>
>
> Name:     draft-mirsky-mpls-stamp
>
> Revision: 07
>
> Title:    Simple Two-way Active Measurement Protocol (STAMP) for MPLS Label
>
> Switched Paths (LSPs)
>
> Date:     2024-03-25
>
> Group:    Individual Submission
>
> Pages:    9
>
> URL:      https://www.ietf.org/archive/id/draft-mirsky-mpls-stamp-07.txt
>
> Status:   https://datatracker.ietf.org/doc/draft-mirsky-mpls-stamp/
>
> HTML:     https://www.ietf.org/archive/id/draft-mirsky-mpls-stamp-07.html
>
> HTMLized: https://datatracker.ietf.org/doc/html/draft-mirsky-mpls-stamp
>
> Diff:
>
> https://author-tools.ietf.org/iddiff?url2=draft-mirsky-mpls-stamp-07
>
>
>
> Abstract:
>
>
>
>    Simple Two-way Active Measurement Protocol (STAMP), defined in RFC
>
>    8762 and RFC 8972, is expected to be able to monitor the performance
>
>    of paths between systems that use a wide variety of encapsulations.
>
>    This document defines encapsulation and bootstrapping of a STAMP test
>
>    session over an MPLS Label Switched Path.
>
>
>
>
>
>
>
> The IETF Secretariat
>
>