Authors,

While reviewing this document during AUTH48, please resolve (as necessary) 
the following questions, which are also in the XML file.

1) <!-- [rfced] May we update the document title as shown below for 
clarity?  

Original:
  Performance Measurement for Segment Routing Networks with MPLS Data
                                 Plane

Perhaps:
  Performance Measurement for Segment Routing Networks over the MPLS Data Plane

-->


2) <!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->


3) <!-- [rfced] We have updated the text below for readability and to 
clarify the relationship between SR-MPLS and its expansion. Please review 
and let us know any objections.

Original:
   This document specifies the application of the MPLS loss and delay
   measurement techniques, originally defined in RFC 6374, RFC 7876, and
   RFC 9341 within Segment Routing (SR) networks that utilize the MPLS
   data plane (SR-MPLS).  

Current:
   This document specifies the application of the MPLS loss and delay
   measurement techniques (originally defined in RFCs 6374, 7876, and 9341)
   within Segment Routing (SR) networks that utilize the MPLS data plane, 
   also referred to as Segment Routing over MPLS (SR-MPLS).

-->


4) <!-- [rfced] We have updated the text below to demonstrate a 1:1
relationship between abbreviation and expansion. Please review.

Original:

   Segment Routing (SR), as specified in [RFC8402], leverages the source
   routing paradigm and applies to both the Multiprotocol Label
   Switching (SR-MPLS) and IPv6 (SRv6) data planes.  

Current:

   Segment Routing (SR), as specified in [RFC8402], leverages the source
   routing paradigm and applies to both the Multiprotocol Label
   Switching (MPLS) and Internet Protocol version 6 (IPv6) data planes.
   These are referred to as Segment Routing over MPLS (SR-MPLS) and
   Segment Routing over IPv6 (SRv6), respectively.

-->


5) <!-- [rfced] For clarity, please consider whether the following 
suggested update conveys the intended meaning.  

Original:
   This document defines Return Path and Block Number TLV extensions for
   [RFC6374], in Section 6, for delay and loss measurement in SR-MPLS
   networks.

Current:
   This document extends [RFC6374] by defining Return Path and Block 
   Number TLVs (see Section 6) for delay and loss measurement in 
   SR-MPLS networks.
-->


6) <!-- [rfced] Does "also apply" mean "can also be used"? 

Original:
   These TLV extensions also apply to MPLS Label Switched
   Paths (LSPs) [RFC3031].

Perhaps:
   These TLVs can also be used in MPLS Label Switched
   Paths (LSPs) [RFC3031].
-->


7) <!-- [rfced] Seemingly, Success (0x1) is a Control Code.  If this is 
correct, may we udpate the text as follows? 

Original:
   The responder that supports this TLV MUST return
   Success in "Control Code" [RFC6374] if it is the intended destination
   for the query.

Perhaps:
   The responder that supports this TLV MUST return
   Control Code 0x1 (Success) [RFC6374] if it is the intended destination
   for the query.
-->


8) <!-- [rfced] Could the text below be adjusted for clarity? Specifically, 
what is being sent as "the destination address"?

Original:
   When the querier sets an IP address and a UDP port in the URO TLV, the
   response message MUST be sent to that IP address as the destination address
   and UDP port as the destination port.

Perhaps:
   When the querier sets an IP address and a UDP port in the URO TLV, the
   response message MUST be sent to that IP address, with that IP address as
   the destination address and the UDP port as the destination port.
-->


9) <!-- [rfced] May we update "out-of-band response messages" to 
"Out-of-Band Response Requested messages..."?  It is unclear whether the 
text refers to the Response Requested messages or res ponses to Out-of-Band 
Response Requested messages.  

Original:
   In one-way measurement mode defined in Section 2.4 of [RFC6374], the
   querier can receive "out-of-band" response messages with an IP/UDP
   header by properly setting the UDP Return Object (URO) TLV in the
   query message. 
-->


10) <!-- [rfced] How may we update the text below for clarity and 
readability?

Original:
   In two-way measurement mode defined in Section 2.4 of [RFC6374], the
   response messages SHOULD be sent back in-band on the same link or the
   same end-to-end SR-MPLS path (same set of links and nodes) in the
   reverse direction to the querier, in order to perform accurate two-
   way delay measurement.

Perhaps:
   In the two-way measurement mode defined in Section 2.4 of [RFC6374], 
   the response messages SHOULD be sent back one of two ways: either 
   they are sent back in-band on the same link, or they are sent back 
   on the same end-to-end SR-MPLS path (i.e., the same set of links and 
   nodes) in the reverse direction to the querier. This is done in order 
   to perform accurate two-way delay measurement.

-->


11) <!-- [rfced] For readability, we suggest the update below.  Please 
review to ensure it does not impact the intended meaning. 

Original:
   The querier can request in the query message for the responder
   to send the response message back on a given return path using the
   MPLS Label Stack sub-TLV in the Return Path TLV defined in this
   document.

Perhaps:
   In the query message, the querier can request that the responder send 
   the response message back on a given return path using the MPLS Label 
   Stack Sub-TLV in the Return Path TLV defined in this document.
-->


12) <!-- [rfced] Please review these similar sentences and let us know if 
we may update them for readability. 

More specifically, what does "which" refer to in the examples below? Does 
it refer to the ACH or the different values in parentheses?

In addition, we were unable to find "Combined DM+LM" in RFC 6374 as seen in
the third example. Should this be updated to "combined LM/DM message" as 
used in RFC 6374?

Original:
   As defined in [RFC6374], MPLS Delay Measurement (DM) query and
   response messages use the Associated Channel Header (ACH) (value
   0x000C for delay measurement) [RFC6374], which identifies the message
   type and the message payload as defined in Section 3.2 [RFC6374]
   following the ACH.  

   As defined in [RFC6374], MPLS LM query and response messages use the
   Associated Channel Header (ACH) (value 0x000A for direct loss
   measurement or value 0x000B for inferred loss measurement), which
   identifies the message type and the message payload defined in
   Section 3.1 [RFC6374] following the ACH.  

   As defined in [RFC6374], Combined DM+LM query and response messages
   use the Associated Channel Header (ACH) (value 0x000D for direct loss
   and delay measurement or value 0x000E for inferred loss and delay
   measurement), which identifies the message type and the message
   payload defined in Section 3.3 [RFC6374] following the ACH.  

Perhaps:
   As defined in [RFC6374], MPLS Delay Measurement (DM) query and response
   messages use the Associated Channel Header (ACH) (with the value 0x000C 
   for delay measurement). This value identifies the message type and the
   message payload that follow the ACH, as defined in Section 3.2 of 
   [RFC6374].

   As defined in [RFC6374], MPLS LM query and response messages use the ACH
   (with the value 0x000A for direct loss measurement or the value 0x000B 
   for inferred loss measurement). This value identifies the message type 
   and the message payload that follow the ACH, as defined in Section 3.1 
   of [RFC6374].

   As defined in [RFC6374], combined DM+LM query and response messages use 
   the ACH (with the value 0x000D for direct loss and delay measurement or 
   the value 0x000E for inferred loss and delay measurement). This value
   identifies the message type and the message payload that follows the 
   ACH, as defined in Section 3.3 of [RFC6374].

-->


13) <!-- [rfced] In the instances below, we have adjusted "for accounting 
received traffic". Please review to ensure these changes do not alter your 
meaning.

Original:
   The Path Segment Identifier (PSID) [RFC9545] MUST be carried in the
   received data packet for the traffic flow under measurement for 
   accounting received traffic on the egress node of the SR-MPLS Policy.

   Different values of PSID can be used per Candidate-Path for accounting
   received traffic to measure packet loss at the Candidate- Path level.

Current:
   The Path Segment Identifier (PSID) [RFC9545] MUST be carried in the
   received data packet for the traffic flow under measurement, in order to
   account for received traffic on the egress node of the SR-MPLS Policy.

   Different values of the PSID can be used per Candidate-Path to account 
   for received traffic and to measure packet loss at the Candidate-Path 
   level.
-->


14) <!-- [rfced] In the text below, does "while" mean "at the same time", 
or does it represent a contrast (like "whereas" or "on the other hand")?

Original:
   The LM query and response messages defined in [RFC6374] are used to
   measure packet loss for the block of data packets transmitted with
   the previous marking while data packets carry alternate marking.

Perhaps:
   The LM query and response messages defined in [RFC6374] are used to 
   measure packet loss for the block of data packets transmitted with the 
   previous marking, whereas data packets carry alternate marking.
-->


15) <!-- [rfced] FYI - The quoted text below appears differently in RFC 
9341. We have updated to match RFC 9341.

Original:
   "The assumption of the block number mechanism is that the measurement
   nodes are time synchronized" as specified in Section 4.3 of [RFC9341]
   is not necessary, as the block number on the responder can be
   synchronized based on the received LM query messages.

Current:
   Section 4.3 of [RFC9341] specifies: "The assumption of this BN
   mechanism is that the measurement nodes are time synchronized." However, 
   this is not necessary, as the block number on the responder can be 
   synchronized based on the received LM query messages.

-->


16) <!-- [rfced] Is "LSE" singular or plural in the text below?

Original:
   The MPLS Label Stack contains a list of 32-bit LSE that includes a
   20-bit label value, 8-bit TTL value, 3-bit TC value, and 1-bit EOS
   (S) field.  

Perhaps (LSE is plural):
   The MPLS Label Stack contains a list of 32-bit LSEs that each include a
   20-bit label value, an 8-bit TTL value, a 3-bit TC value, and a 1-bit 
   EOS (S) field.

-->


17) <!-- [rfced]  We have removed "TLV" from the Descriptions to align with 
the IANA registries <https://www.iana.org/assignments/g-ach-parameters>.  
Please let us know any corrections. 

Original:
 | TBA1  | Return Path TLV  | This document |
 | TBA2  | Block Number TLV | This document |

Current:
| 5    | Return Path  | RFC 9779  |
| 6    | Block Number | RFC 9779  |
-->


18) <!-- [rfced] Should the registry name be plural?  Note that we will ask 
IANA to update their registry if this change is accepted. 

Current: Return Path Sub-TLV Type
Perhaps: Return Path Sub-TLV Types 
-->


19) <!-- [rfced] Much of this text duplicates what appears in the table.  
Perhaps the text should just indicate that the code points are assigned as 
defined in Table 2? 

Section 12: 
   All code points in the range 0 through 175 in this registry
   shall be allocated according to the "IETF Review" procedure as
   specified in [RFC8126].  Code points in the range 176 through 239 in
   this registry shall be allocated according to the "First Come, First
   Served" procedure as specified in [RFC8126].  Remaining code points
   are allocated according to Table 2:

Table 2: 
          | Value     |       Description       | Reference     |
          +===========+=========================+===============+
          | 1 - 175   |       IETF Review       | This document |
          | 176 - 239 | First Come First Served | This document |
          | 240 - 251 |     Experimental Use    | This document |
          | 252 - 254 |       Private Use       | This document |
-->


20) <!-- [rfced] Would it make sense to refer to the MPLS Review Team 
(assuming that is correct), as we are unsure what MPLS-RT refers to and we 
are unable to find information about it. 

Original:
   Thanks to Huaimo Chen, Yimin Shen, and Xufeng Liu for MPLS-RT expert
   review, ...
-->


21) <!-- [rfced] [IEEE802.1AX] references the 2008 version of this IEEE 
Standard.  May we update this reference to use the current standard from 
2020 as seen in the following URL: 
<https://ieeexplore.ieee.org/document/9105034>? -->


22) <!-- [rfced] We removed the quotes around Control Code throughout to 
align with use in RFC 6374.  We have also removed the quotes and 
capitalized "in-band response requested" and "out-of-band response 
requested" to match what appears in RFC 6374 and the IANA registry.  Please 
review and let us know if corrections are needed. 
-->


23) <!-- [rfced] Please review the following changes and questions 
regarding the terms used in this document:

a) RFC 8402 uses "node-SID" and "Anycast-SID" rather than "node SID" and
"Anycast SID". May we update these to match the usage from RFC 8402?

b) We note different capitalization of label stack vs. Label Stack.  We believe 
the lowercase "label stack" is used in general text, but "Label Stack" is 
capitalized when it refers to the the TLV.  Please confirm that MPLS Label 
Stack is capitalized correctly in the following:

Original: 
   The MPLS Label Stack contains a list of 32-bit LSE that includes a
   20-bit label value, 8-bit TTL value, 3-bit TC value, and 1-bit EOS
   (S) field.  An MPLS Label Stack Sub-TLV may carry a stack of labels
   or a Binding SID label [RFC8402] of the Return SR-MPLS Policy.
-->


24) <!-- [rfced] Please review the following questions and changes 
regarding the abbreviations used in this document.

a) Per Section 3.6 of RFC 7322 ("RFC Style Guide"), abbreviations should be
expanded upon first use. Is "EOS" in the text below an abbreviation? If so,
how may it be expanded?

1-bit EOS (S) field


b) FYI - We have expanded the abbreviation below. Please review to
ensure correctness.

Border Gateway Protocol - Link State  (BGP-LS)

-->


25) <!-- [rfced] Please review the "Inclusive Language" portion of the 
online Style Guide 
<https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.  Updates of this nature 
typically result in more precise language, which is helpful for readers.

Note that our script did not flag any words in particular, but this should 
still be reviewed as a best practice. -->


Thank you.

RFC Editor



On Apr 16, 2025, at 3:52 PM, rfc-edi...@rfc-editor.org wrote:

*****IMPORTANT*****

Updated 2025/04/16

RFC Author(s):
--------------

Instructions for Completing AUTH48

Your document has now entered AUTH48.  Once it has been reviewed and 
approved by you and all coauthors, it will be published as an RFC.  
If an author is no longer available, there are several remedies 
available as listed in the FAQ (https://www.rfc-editor.org/faq/).

You and you coauthors are responsible for engaging other parties 
(e.g., Contributors or Working Group) as necessary before providing 
your approval.

Planning your review 
---------------------

Please review the following aspects of your document:

*  RFC Editor questions

   Please review and resolve any questions raised by the RFC Editor 
   that have been included in the XML file as comments marked as 
   follows:

   <!-- [rfced] ... -->

   These questions will also be sent in a subsequent email.

*  Changes submitted by coauthors 

   Please ensure that you review any changes submitted by your 
   coauthors.  We assume that if you do not speak up that you 
   agree to changes submitted by your coauthors.

*  Content 

   Please review the full content of the document, as this cannot 
   change once the RFC is published.  Please pay particular attention to:
   - IANA considerations updates (if applicable)
   - contact information
   - references

*  Copyright notices and legends

   Please review the copyright notice and legends as defined in
   RFC 5378 and the Trust Legal Provisions 
   (TLP – https://trustee.ietf.org/license-info).

*  Semantic markup

   Please review the markup in the XML file to ensure that elements of  
   content are correctly tagged.  For example, ensure that <sourcecode> 
   and <artwork> are set correctly.  See details at 
   <https://authors.ietf.org/rfcxml-vocabulary>.

*  Formatted output

   Please review the PDF, HTML, and TXT files to ensure that the 
   formatted output, as generated from the markup in the XML file, is 
   reasonable.  Please note that the TXT will have formatting 
   limitations compared to the PDF and HTML.


Submitting changes
------------------

To submit changes, please reply to this email using ‘REPLY ALL’ as all 
the parties CCed on this message need to see your changes. The parties 
include:

   *  your coauthors
   
   *  rfc-edi...@rfc-editor.org (the RPC team)

   *  other document participants, depending on the stream (e.g., 
      IETF Stream participants are your working group chairs, the 
      responsible ADs, and the document shepherd).
     
   *  auth48archive@rfc-editor.org, which is a new archival mailing list 
      to preserve AUTH48 conversations; it is not an active discussion 
      list:
     
     *  More info:
        
https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
     
     *  The archive itself:
        https://mailarchive.ietf.org/arch/browse/auth48archive/

     *  Note: If only absolutely necessary, you may temporarily opt out 
        of the archiving of messages (e.g., to discuss a sensitive matter).
        If needed, please add a note at the top of the message that you 
        have dropped the address. When the discussion is concluded, 
        auth48archive@rfc-editor.org will be re-added to the CC list and 
        its addition will be noted at the top of the message. 

You may submit your changes in one of two ways:

An update to the provided XML file
 — OR —
An explicit list of changes in this format

Section # (or indicate Global)

OLD:
old text

NEW:
new text

You do not need to reply with both an updated XML file and an explicit 
list of changes, as either form is sufficient.

We will ask a stream manager to review and approve any changes that seem
beyond editorial in nature, e.g., addition of new text, deletion of text, 
and technical changes.  Information about stream managers can be found in 
the FAQ.  Editorial changes do not require approval from a stream manager.


Approving for publication
--------------------------

To approve your RFC for publication, please reply to this email stating
that you approve this RFC for publication.  Please use ‘REPLY ALL’,
as all the parties CCed on this message need to see your approval.


Files 
-----

The files are available here:
   https://www.rfc-editor.org/authors/rfc9779.xml
   https://www.rfc-editor.org/authors/rfc9779.html
   https://www.rfc-editor.org/authors/rfc9779.pdf
   https://www.rfc-editor.org/authors/rfc9779.txt

Diff file of the text:
   https://www.rfc-editor.org/authors/rfc9779-diff.html
   https://www.rfc-editor.org/authors/rfc9779-rfcdiff.html (side by side)

Diff of the XML: 
   https://www.rfc-editor.org/authors/rfc9779-xmldiff1.html


Tracking progress
-----------------

The details of the AUTH48 status of your document are here:
   https://www.rfc-editor.org/auth48/rfc9779

Please let us know if you have any questions.  

Thank you for your cooperation,

RFC Editor

--------------------------------------
RFC9779 (draft-ietf-mpls-rfc6374-sr-17)

Title            : Performance Measurement for Segment Routing Networks with 
MPLS Data Plane
Author(s)        : R. Gandhi, C. Filsfils, D. Voyer, S. Salsano, M. Chen
WG Chair(s)      : Nicolai Leymann, Tarek Saad, Tony Li

Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van de Velde


-- 
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org

Reply via email to