Hi Rakesh,
From: Rakesh Gandhi <[email protected]> Sent: Monday, September 14, 2026 3:16 PM To: DECRAENE Bruno INNOV/NET <[email protected]> Cc: [email protected]; SPRING WG <[email protected]> Subject: Re: [spring] draft-ietf-spring-stamp-srpm-mpls Hi Bruno, Thank you for the review. We have posted rev-07 that addresses your comments. Thank you. Works for me. --Bruno Please see replies inline with <RG>... On Wed, Sep 2, 2026 at 10:07 AM <[email protected]<mailto:[email protected]>> wrote: [speaking as individual contributor] Hi authors, As part of a discussion on the MPLS MNA defined in this draft, I had the opportunity to read section 7 again [1] Please find below some comments/questions. 1. Offset determination §7.1 “When a Session-Reflector receives a test packet with the MNA Sub-Stack with opcode MNA.TSF, it timestamps the test packet payload at a fixed offset, pops the MNA Sub-Stack (after completing any other network actions), and forwards the test packet as defined in the loopback measurement mode for SR-MPLS paths in this document.” §7.1.1 “The following properties are locally defined by the operator for this opcode. · The timestamp format (e.g., 64-bit PTPv2 or NTPv4), to be added to the Session-Sender test packet payload. · The offset in the Session-Sender test packet payload (e.g., STAMP test packet in Figure 5 of [RFC8762<https://www.rfc-editor.org/info/rfc8762>] with an offset of 16 bytes for Receive Timestamp).” Since this fixed offset must be determined and configured by the network operator, could the document precisely define the starting field and the ending field defining this offset (presumably offset:= ending field – starting field). Trying to guess, is this dependent on whether IPv4 or IPv6 is used for the test packet? Is this dependent on the number of MPLS labels added for the return path? May be the §14.1 (OPS consideration for TSF) could refer to this and point to the relevant specification text. <RG> Added as: The TSF opcode enables the Session-Reflector to write the 64-bit timestamp in the "Receive Timestamp" field [RFC8972], located at a begin offset of 16 bytes from the start of the STAMP test packet payload as shown in the Session-Reflector test packet in Figure 2 of Section 3 of [RFC8972]. 2. MNA.TSF value “A value for the locally configured MPLS Network Action opcode MNA.TSF, called the TSF Network Action, is selected by the operator from the "Private Use Range: 115-126" [RFC9994<https://www.rfc-editor.org/info/rfc9994>] on the Session-Reflector node.” Can you clarify why this specification opted for a Private value, rather than a standardized value? From a network operator standpoint, this represents extra work, for no value that I could determine. <RG> Ok, the draft is updated to use standardized values. <RG> This was also the feedback from the MPLS WG chairs. 3. Configuration “The Session-Sender needs to know if the Session-Reflector is capable of processing the TSF Network Action to avoid dropping the test packets. This capability can be locally configured on the Session-Sender or signaled. Signaling extensions for this capability exchange are outside the scope of this document. » My understanding is that the session sender needs to know other parameters. E.g., the MAN.TSF value, the offset, the timestamp format <RG> The updated draft removes the configuration steps. Thanks, Rakesh (for authors) Thank you, --Bruno [1] https://datatracker.ietf.org/doc/html/draft-ietf-spring-stamp-srpm-mpls-06#name-loopback-measurement-mode-w ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ spring mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
