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, [email protected] 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
* [email protected] (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).
* [email protected], 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,
[email protected] 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 -- [email protected]
To unsubscribe send an email to [email protected]
