Hi,
Thank you for the edits.
Pls see inline for replies <SH>..
I could not open the text side-by-side diff link.
Could you pls send the link again ? I want to review the diff before approving.
Rgds
Shraddha
Juniper Business Use Only
-----Original Message-----
From: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>
Sent: 24 January 2025 04:33
To: Shraddha Hegde <shrad...@juniper.net>; kapil...@gmail.com; Mukul Srivastava
<m...@juniper.net>; samson....@gmail.com; nagendrakumar.nai...@gmail.com
Cc: rfc-edi...@rfc-editor.org; mpls-...@ietf.org; mpls-cha...@ietf.org;
adr...@olddog.co.uk; james.n.guich...@futurewei.com;
auth48archive@rfc-editor.org
Subject: Re: AUTH48: RFC-to-be 9716
<draft-ietf-mpls-spring-inter-domain-oam-20> for your review
[External Email. Be cautious of content]
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
<SH> OK
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
-->
<SH> OK
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. -->
<SH> OK
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.
-->
<SH> OK
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.
-->
<SH> OK
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.
-->
<SH> The connectivity to the remote PEs can be achieved by BGP advertisements
With MPLS label bound to the prefix as described in [RFC 8277] or by building
paths using list of segments as described in [RFC8604].
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).
-->
<SH> ok
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.
-->
<SH> OK
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.
-->
<SH> OK
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.
-->
<SH> OK
10) <!--[rfced] IANA queries
(Note: After this document completes AUTH48, we will ask IANA to update their
registry accordingly.)
<SH> OK
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 |
<SH> OK
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
-->
<SH> OK
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://urldefense.com/v3/__https://ieeexplore.ieee.org/document/8585421__;!!NEt6yMaO-gk!HaATadzYlFDiy1PvZZeL81r-taqAVJrT5ZVs4euc40O73gOqOd910nVCLjV9y0m28ygLtwl68evidYtMD3LMsDLl$
>.
-->
<SH> OK
12) <!--[rfced] FYI - The section previously titled "APPENDIX" has been moved
after the references and is now titled as "Examples".
Please review.
-->
<SH> OK
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.
-->
<SH> / means "OR" here.
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.
-->
<SH> OK
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.
-->
<SH> OK.
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
<SH> A-Flag
Reply Path return code vs. reply path return code vs. Reply path return code
<SH> Reply Path return code
Segment Types vs. segment Types vs. segment types
<SH>Segment Types
SR path vs. SR Path
<SH> SR Path
SR Policy vs. SR policy
<SH> 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
<SH> OK
Inter-domain vs. inter-domain
<SH> OK
Sub-TLV vs. sub-TLV
<SH> OK
Label vs. label (when used generally)
<SH> ok
Segment Sub-TLV vs. segment sub-TLV vs. Segment sub-TLV
<SH> OK
MPLS Label vs. MPLS label
<SH> OK
IPv4 node address vs. IPv4 Node Address
<SH> OK
IPv6 node address vs. IPv6 Node Address
<SH> OK
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)
<SH> OK
Centralized BGP Egress Peer Engineering > centralized BGP Egress Peer
Engineering (per RFC 9087)
<SH> OK
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.
<SH> OK
e.) Per RFC 8029, may we capitalize all instances of "return code"?
-->
<SH> OK
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)
-->
<SH> OK
18) <!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide
<https://urldefense.com/v3/__https://www.rfc-editor.org/styleguide/part2/*inclusive_language__;Iw!!NEt6yMaO-gk!HaATadzYlFDiy1PvZZeL81r-taqAVJrT5ZVs4euc40O73gOqOd910nVCLjV9y0m28ygLtwl68evidYtMD8E22Xgr$
> 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.
-->
<SH> OK
Thank you.
RFC Editor/kf/ap
On Jan 23, 2025, at 3:02 PM, rfc-edi...@rfc-editor.org 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://urldefense.com/v3/__https://www.rfc-editor.org/faq/__;!!NEt6yMaO-gk!HaATadzYlFDiy1PvZZeL81r-taqAVJrT5ZVs4euc40O73gOqOd910nVCLjV9y0m28ygLtwl68evidYtMD-k5UviL$
).
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://urldefense.com/v3/__https://trustee.ietf.org/license-info__;!!NEt6yMaO-gk!HaATadzYlFDiy1PvZZeL81r-taqAVJrT5ZVs4euc40O73gOqOd910nVCLjV9y0m28ygLtwl68evidYtMDz5iektO$
).
* 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://urldefense.com/v3/__https://authors.ietf.org/rfcxml-vocabulary__;!!NEt6yMaO-gk!HaATadzYlFDiy1PvZZeL81r-taqAVJrT5ZVs4euc40O73gOqOd910nVCLjV9y0m28ygLtwl68evidYtMDxBIHBB0$
>.
* 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://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc__;!!NEt6yMaO-gk!HaATadzYlFDiy1PvZZeL81r-taqAVJrT5ZVs4euc40O73gOqOd910nVCLjV9y0m28ygLtwl68evidYtMD5yArK-_$
* The archive itself:
https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/auth48archive/__;!!NEt6yMaO-gk!HaATadzYlFDiy1PvZZeL81r-taqAVJrT5ZVs4euc40O73gOqOd910nVCLjV9y0m28ygLtwl68evidYtMD5POq1mx$
* 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://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9716.xml__;!!NEt6yMaO-gk!HaATadzYlFDiy1PvZZeL81r-taqAVJrT5ZVs4euc40O73gOqOd910nVCLjV9y0m28ygLtwl68evidYtMD-gMj3BM$
https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9716.html__;!!NEt6yMaO-gk!HaATadzYlFDiy1PvZZeL81r-taqAVJrT5ZVs4euc40O73gOqOd910nVCLjV9y0m28ygLtwl68evidYtMD0EICwtZ$
https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9716.pdf__;!!NEt6yMaO-gk!HaATadzYlFDiy1PvZZeL81r-taqAVJrT5ZVs4euc40O73gOqOd910nVCLjV9y0m28ygLtwl68evidYtMD6zBnDjK$
https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9716.txt__;!!NEt6yMaO-gk!HaATadzYlFDiy1PvZZeL81r-taqAVJrT5ZVs4euc40O73gOqOd910nVCLjV9y0m28ygLtwl68evidYtMDxxrD7Ab$
Diff file of the text:
https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9716-diff.html__;!!NEt6yMaO-gk!HaATadzYlFDiy1PvZZeL81r-taqAVJrT5ZVs4euc40O73gOqOd910nVCLjV9y0m28ygLtwl68evidYtMDxEigQtD$
https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9716-rfcdiff.html__;!!NEt6yMaO-gk!HaATadzYlFDiy1PvZZeL81r-taqAVJrT5ZVs4euc40O73gOqOd910nVCLjV9y0m28ygLtwl68evidYtMDykF9OTr$
(side by side)
Diff of the XML:
https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9716-xmldiff1.html__;!!NEt6yMaO-gk!HaATadzYlFDiy1PvZZeL81r-taqAVJrT5ZVs4euc40O73gOqOd910nVCLjV9y0m28ygLtwl68evidYtMD2WHfV2S$
Tracking progress
-----------------
The details of the AUTH48 status of your document are here:
https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9716__;!!NEt6yMaO-gk!HaATadzYlFDiy1PvZZeL81r-taqAVJrT5ZVs4euc40O73gOqOd910nVCLjV9y0m28ygLtwl68evidYtMD-j1uYHH$
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 -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
