Authors,
While reviewing this document during AUTH48, please resolve (as necessary) the
following questions, which are also in the XML file.
1) <!-- [rfced] Title
a.) As "Path Monitoring System/Head-end" is not mentioned in the
abstract, may we clarify the title as follows so that it aligns more
closely with the abstract? It will also help avoid the awkward
hyphenation of "Path Monitoring System/Head-end based".
Original:
Path Monitoring System/Head-end based MPLS Ping and Traceroute in Inter-
domain Segment Routing Networks
Perhaps:
Mechanisms for MPLS Ping and Traceroute Procedures in Inter-Domain
Segment Routing Networks
b.) Note that we have updated the short title, which appears in the
running header in the PDF output. Please review.
Original:
Inter-as-OAM
Current:
MPLS Ping and Traceroute in Inter-Domain SR Networks
-->
2) <!-- [rfced] FYI - We have slightly adjusted Figure 1 to reduce the width of
the artwork in order to fit the 72-character limit. Please review. -->
3) <!-- [rfced] Please review the following questions regarding the text below:
a.) To improve readability, may we remove the "/" characters and update
the text as follows?
b.) In addition, may we expand "SID" as follows (as Section 3.6 of RFC 7322
suggests that abbreviations should be expanded upon first use)?
Original:
AS1, AS2, and AS3 are SR enabled and the egress links have PeerNode
SID/PeerAdj SID/ PeerSet SID configured and advertised via [RFC9086].
PeerNode SID/PeerAdj SID/PeerSet SID are referred to as Egress Peer
Engineering SIDs (EPE- SIDs) in this document.
Perhaps:
AS1, AS2, and AS3 are SR enabled, and the egress links have the following
Segment Identifiers (SIDs) configured and advertised via [RFC9086]:
PeerNode SID, PeerAdj SID, and PeerSet SID. The PeerNode SID, PeerAdj
SID, and PeerSet SID are referred to as Egress Peer Engineering SIDs (EPE-
SIDs) in this document.
-->
4) <!--[rfced] To avoid the repetition of "based", may we update this sentence
as follows?
Original:
[RFC7743] describes an Echo-relay based solution based on advertising
a new Relay Node Address Stack TLV containing a stack of Echo-relay
IP addresses.
Perhaps:
[RFC7743] describes an Echo-relay-based solution that is predicated on
advertising a new Relay Node Address Stack TLV containing a stack of
Echo-relay IP addresses.
-->
5) <!-- [rfced] Please review our questions regarding the citations in the text
below:
Original:
The connectivity to the remote PEs can be achieved using BGP-Labeled
Unicast (BGP-LU) [RFC8277] or by stacking the labels for each domain
as described in [RFC8604].
a.) We were unable to find the term "BGP-Labeled Unicast (BGP-LU)" used in
RFC 8277 or other previous RFCs. How may we update this citation accordingly?
b.) We were unable to find content about "stacking labels" in RFC 8064. Please
review and let us know if any updates are needed.
-->
6) <!-- [rfced] Please review our updates to the text below to ensure these
changes do not alter your intended meaning.
Original:
This document defines the Type-A, Type-C, and Type-D Segment sub-TLVs
usage and processing when it appears in TLV 21(Reply Path TLV).
Current:
This document defines the usage and processing of the Type-A, Type-C, and
Type-D Segment sub-TLVs when they appear in TLV 21 (Reply Path TLV).
-->
7) <!-- [rfced] May we add "(MBZ)" to the text following Figure 4 to reflect
similar text that appears following Figure 5?
Original (appears after Figure 4):
When A-flag is unset, this
field has no meaning and thus MUST be set to zero on transmission and
ignored on receipt.
Original (appears after Figure 5):
When A-flag is unset, this
field has no meaning and thus MUST be set to zero (MBZ) on transmission and
ignored on receipt.
-->
8) <!-- [rfced] FYI - We have removed the second sentence from the definition
below as it repeats information from the first sentence. Please review and
let us know if further updates are needed.
Original:
SID: optional: 4-octet field containing label, TC, S and TTL as
defined in Section 4.1. The SID is optional and specifies a 4-octet
MPLS SID containing label, TC, S, and TTL as defined in Section 4.1.
When the SID field is present, it MUST be used for constructing the
Reply Path.
Current:
SID: Optional 4-octet field containing the labels TC, S, and TTL as
defined in Section 4.1. When the SID field is present, it MUST be
used for constructing the Reply Path.
-->
9) <!-- [rfced] FYI - We have updated the text below for clarity; please review.
Original:
If optional MPLS SID is present in the Type-C/Type-D segments SID
MUST be used to encode the echo reply with MPLS labels.
Current:
If an optional MPLS SID is present in the Type-C/Type-D segments, the SID
MUST be used to encode the echo reply with MPLS labels.
-->
10) <!--[rfced] IANA queries
(Note: After this document completes AUTH48, we will ask IANA to update their
registry accordingly.)
a.) To reflect the definition of "Type-A", should a comma be added after
"SID only" in the Sub-TLV Name of Sub-Type 46?
Current:
Type-A: SID only, in the form of an MPLS label
...
+==========+====================================+=============+
| Sub-Type | Sub-TLV Name | Reference |
+==========+====================================+=============+
| 46 | SID only in the form of MPLS label | Section 4.1 |
| | | of RFC 9716 |
b.) As other values registered in the "Reply Path Return Codes" registry do
not include periods, we have removed the periods from the descriptions of
the following values registered by this document. Please let us know of
any objections.
Original:
TBA1 Use Reply Path TLV from this echo
reply for building next echo request.
TBA2 Local policy does not allow dynamic
return Path building.
Current:
0x0006 Use Reply Path TLV from this echo
reply for building the next echo request
0x0007 Local policy does not allow dynamic
return path building
-->
11) <!-- [rfced] FYI - We have updated the [IEEE-802.1AE] reference entry as
follows. Please review.
Original:
[IEEE-802.1AE]
IEEE, "IEEE Standard for Local and metropolitan area
networks-Media Access Control (MAC) Security", August
2023.
Current:
[IEEE-802.1AE]
IEEE, "IEEE Standard for Local and metropolitan area
networks-Media Access Control (MAC) Security", IEEE Std
8021.AE-2018, DOI 10.1109/IEEESTD.2018.8585421, December
2018, <https://ieeexplore.ieee.org/document/8585421>.
-->
12) <!--[rfced] FYI - The section previously titled "APPENDIX" has
been moved after the references and is now titled as "Examples".
Please review.
-->
13) <!--[rfced] As the "/" character can mean "and", "or", or "and/or",
"the controller/PMS or head-end node" is unclear in the sentence
below. Please review and let us know how this sentence may be clarified.
Original:
Topology of AS1 and AS2 are
advertised via BGP-Link State (BGP-LS) to the controller/PMS or head-
end node.
-->
14) <!-- [rfced] Please review our changes to the text below to ensure these
updates do not alter your intended meaning.
Original:
The same Reply Path TLV is sufficient for any router in AS2 to send the
reply. Because the first label(N-ASBR4) can direct echo reply to ASBR4 and
the second one (EPE-ASBR4-ASBR1) to direct echo reply to AS1.
...
The example described in the above paragraphs can be extended to
multiple ASes by following the same procedure of each ASBR adding
Node-SID and EPE-SID on receiving echo requests from neighboring AS.
Current:
The same Reply Path TLV is sufficient for any router in AS2 to send the
reply. This is because the first label (N-ASBR4) can direct the echo reply
to ASBR4 and the second one (EPE-ASBR4-ASBR1) can direct the echo reply to
AS1.
...
The example described in the above paragraphs can be extended to multiple
ASes. This is done by following the same procedure for each ASBR, i.e.,
adding Node-SIDs and EPE-SIDs on receiving echo requests from neighboring
ASes.
-->
15) <!--[rfced] We are having some difficulty understanding how "while sending
the echo reply" fits into this sentence. May we clarify this sentence as
follows?
Original:
ABR1 receives the echo request
and while sending the echo reply adds its node Label to the Reply
Path TLV and sets the Reply path return code to TBA1.
Perhaps:
ABR1 receives the echo request, adds its node Label to the Reply
Path TLV (while sending the echo reply), and sets the Reply path return
code to 0x0006.
-->
16) <!-- [rfced] Terminology:
a.) The following terms appear to be capitalized inconsistently throughout this
document. Please review these different uses and let us know how to update for
consistency.
A-Flag vs. A-flag vs. A Flag
Reply Path return code vs. reply path return code vs. Reply path return code
Segment Types vs. segment Types vs. segment types
SR path vs. SR Path
SR Policy vs. SR policy
b.) We note inconsistencies in the terms listed below. We updated to the form
on the right. Please let us know any concerns.
Inter-AS vs. inter-AS
Inter-domain vs. inter-domain
Sub-TLV vs. sub-TLV
Label vs. label (when used generally)
Segment Sub-TLV vs. segment sub-TLV vs. Segment sub-TLV
MPLS Label vs. MPLS label
IPv4 node address vs. IPv4 Node Address
IPv6 node address vs. IPv6 Node Address
c.) We have updated the following terms to reflect how they appear in
previously published RFCs. Please review and let us know of any objections.
BGP Peering Segments > BGP peering segments (per RFC 8402)
Centralized BGP Egress Peer Engineering > centralized BGP Egress Peer
Engineering (per RFC 9087)
d.) FYI - We have removed quotation marks from around the following field
names to reflect how field names are more commonly used throughout the text.
Original:
The Segment Types described above contain the following flags in the
"Flags" field (codes to be assigned by IANA from the new registry
"Segment Sub-TLV Flags"):
...
A-Flag: This flag indicates the presence of SR Algorithm ID in the
"SR-Algorithm" field applicable to various segment Types.
Current:
The Segment Types described above contain the following flags in the
Flags field (codes assigned by IANA from the "Segment ID Sub-TLV
Flags" registry):
...
A-Flag: This flag indicates the presence of an SR Algorithm ID in
the SR Algorithm field applicable to various segment Types.
e.) Per RFC 8029, may we capitalize all instances of "return code"?
-->
17) <!-- [rfced] FYI - We have added expansions for abbreviations upon first use
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each expansion
in the document carefully to ensure correctness.
Forwarding Equivalence Class (FEC)
Media Access Control Security (MACsec)
-->
18) <!-- [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[IEEE-802.1AE] 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/kf/ap
On Jan 23, 2025, at 3:02 PM, [email protected] wrote:
*****IMPORTANT*****
Updated 2025/01/23
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/rfc9716.xml
https://www.rfc-editor.org/authors/rfc9716.html
https://www.rfc-editor.org/authors/rfc9716.pdf
https://www.rfc-editor.org/authors/rfc9716.txt
Diff file of the text:
https://www.rfc-editor.org/authors/rfc9716-diff.html
https://www.rfc-editor.org/authors/rfc9716-rfcdiff.html (side by side)
Diff of the XML:
https://www.rfc-editor.org/authors/rfc9716-xmldiff1.html
Tracking progress
-----------------
The details of the AUTH48 status of your document are here:
https://www.rfc-editor.org/auth48/rfc9716
Please let us know if you have any questions.
Thank you for your cooperation,
RFC Editor
--------------------------------------
RFC9716 (draft-ietf-mpls-spring-inter-domain-oam-20)
Title : Path Monitoring System/Head-end based MPLS Ping and
Traceroute in Inter-domain Segment Routing Networks
Author(s) : S. Hegde, K. Arora, M. Srivastava, S. Ninan, N. Kumar
WG Chair(s) : Nicolai Leymann, Tarek Saad, Tony Li
Area Director(s) : Jim Guichard, John Scudder, Gunter Van de Velde
--
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
