Hi Bruno, Thank you for the review.
We have posted rev-07 that addresses your comments. Please see replies inline with <RG>... On Wed, Sep 2, 2026 at 10:07 AM <[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] > To unsubscribe send an email to [email protected] >
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
