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

["zhangli (CE)" <[e-mail]>]

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]<mailto:[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]><mailto:&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]><mailto:&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