Authors,
While reviewing this document during AUTH48, please resolve (as necessary) the
following questions, which are also in the XML file.
1) <!--[rfced] We updated "MPLS Data Plane" to "MPLS Data Planes" in the
document title. If that is not correct and it should be singular,
please let us know. We also added a hyphen to "EPE SIDs" in the
abbreviated title that spans the PDF to match the running text.
Original:
(title)
Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR)
Egress Peer Engineering (EPE) Segment Identifiers (SIDs) with MPLS
Data Plane
(short title)
LSP for SR EPE SIDs with MPLS
Current:
(title)
Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR)
Egress Peer Engineering (EPE) Segment Identifiers (SIDs) with MPLS
Data Planes
(short title)
LSP for SR EPE-SIDs with MPLS
-->
2) <!-- [rfced] FYI - In Figure 1, we updated "AS 2", "AS 3", and "AS 4"
to have no spaces in order to match "AS1" in the diagram and
"AS2" and "AS3" in the subsequent text. Please let us know if
there is any objection.
AS 2 > AS2
AS 3 > AS3
AS 4 > AS4
-->
3) <!--[rfced] Please clarify this sentence. Are SR paths built using either
EPE-SIDs or PCEP extensions? Please let us know which option is preferred.
Original:
These EPE-SIDs may be used to build Segment Routing paths as described
in [I-D.ietf-idr-segment-routing-te-policy] or using Path Computation
Element Protocol (PCEP) extensions as defined in [RFC8664].
Perhaps A:
These EPE-SIDs may be used to build SR paths as described
in [SR-TE-POLICY]], or Path Computation Element Protocol (PCEP)
extensions as defined in [RFC8664] may be used.
or
Perhaps B:
SR paths are built using these EPE-SIDs as described in [SR-TE-POLICY]
or Path Computation Element Protocol (PCEP) extensions as defined in
[RFC8664].
-->
4) <!--[rfced] Would it be correct to say that the extensions do not
define how to "acquire" or "acquire and carry" the details of the
SID, or is the intension to only mention "carry"? We ask because
the next few sentences discuss how the node can "acquire the
details".
Original:
The extensions in [I-D.ietf-idr-segment-routing-te-policy] and
[RFC8664] do not define how to carry the details of the SID
that can be used to construct the FEC.
Perhaps:
The extensions in [SR-TE-POLICY] and [RFC8664] do not define how
to acquire and carry the details of the SID that can be used to
construct the FEC.
-->
5) <!--[rfced] It appears that Table 1 (Section 4) and Table 2 (Section 6)
are the same. Would you like to remove Table 1 and add a link to
Table 2 (which would then become Table 1) as shown below?
Current:
In this document, three new sub-TLVs are defined for the Target FEC
Stack TLV (Type 1), the Reverse-Path Target FEC Stack TLV (Type 16),
and the Reply Path TLV (Type 21).
- Table 1 -
Perhaps:
In this document, three new sub-TLVs are defined for the Target FEC
Stack TLV (Type 1), the Reverse-Path Target FEC Stack TLV (Type 16),
and the Reply Path TLV (Type 21); see Table 1.
-->
6) <!--[rfced] Is "the OAM packet will be sent out" an example of what is
specified? We updated this sentence as reflected below; if that
is not correct, please let us know.
Original:
As per [RFC8029], the node advertising the EPE SIDs will send
Downstream Detailed Mapping (DDMAP TLV) specifying the details
of nexthop interfaces, the OAM packet will be sent out.
Current:
As per [RFC8029], the node advertising the EPE-SIDs will send a
Downstream Detailed Mapping (DDMAP) TLV specifying the details
of the next-hop interfaces, e.g., when the OAM packet will be
sent out.
-->
7) <!--[rfced] We believe that the slash indicates "or" in these
instances, so we updated accordingly for clarity. If that is not
correct or desired, please let us know.
Original:
Local Interface Address :4 octets/16 octets
Remote Interface Address :4 octets/16 octets
Current:
Local Interface Address: 4 octets or 16 octets
Remote Interface Address: 4 octets or 16 octets
-->
8) <!-- [rfced] FYI - For conciseness, we updated this sentence as
follows. Please let us know if there is any objection.
Original:
[RFC9086] allows optional link descriptors of local and
remote interface addresses as described in section 4.2.
Current:
Optional link descriptors of local and remote interface
addresses are allowed as described in Section 4.2 of [RFC9086].
-->
9) <!-- [rfced] FYI - Since "RECOMMENDED", not "RECOMMENDS", is a BCP 14
key word, we rephrased the text as shown below.
Original:
This document RECOMMENDs sending these optional descriptors and using
them to validate incoming interface.
Current:
In this document, it is RECOMMENDED to send these optional descriptors
and use them to validate incoming interfaces.
-->
10) <!--[rfced] Is it intentional that instances of "No.of" do not contain
a space? Please let us know if this should remain as is or if a
space can be added (e.g., "No. of"). Note that there are seven
occurrences.
Two examples (see the text for more):
Original:
No.of elements in set
Length = (20 + No.of IPv4 interface pairs * 8
Perhaps:
No. of elements in set
Length = (20 + No. of IPv4 interface pairs * 8
-->
11) <!--[rfced] Should "variable" be singular (option A) or plural
(option B) in the following sentence?
Original:
Value: Expressed in octets and variable based on the number of
elements in the set.
Perhaps A:
Value: Expressed in octets and a variable based on the number of
elements in the set.
or
Perhaps B:
Value: Expressed in octets and variables based on the number of
elements in the set.
-->
12) <!-- [rfced] We notice that the titles of Sections 5 and 5.1 are the
same. How may we update these to avoid confusion? Is Section 5.1
perhaps the example validation, e.g., "EPE-SID FEC Validation
Examples" (option A) or "Segment Routing IGP-Prefix, IGP-Adjacency
SID, and EPE-SID Validation Examples (option B)?
Original:
5. EPE-SID FEC validation
5.1. EPE-SID FEC validation
Perhaps A:
5. EPE-SID FEC Validation
5.1. EPE-SID FEC Validation Examples
or
Perhaps B:
5. EPE-SID FEC Validation
5.1. Segment Routing IGP-Prefix, IGP-Adjacency SID,
and EPE-SID Validation Examples
-->
13) <!--[rfced] Section 5.1.
a) Please let us know how we may clarify the first sentence
in this section. Are Segment Routing IGP-Prefix, IGP-Adjacency
SID, and EPE-SID being validated, and is the term "receiving node"
implying that the node received the OAM message as shown below?
Original:
Segment Routing IGP-Prefix, IGP-Adjacency SID and EPE-SID Validation:
Receiving node term used in this section implies the node that
receives OAM message with the FEC stack TLV.
Perhaps:
This is an example of Segment Routing IGP-Prefix, IGP-Adjacency SID, and
EPE-SID validations. Note that the term "receiving node" in this section
implies that the node receives the OAM message with the FEC stack TLV.
b) For clarity, may we update "If any below conditions fail" to "Check if any
conditions below fail" (note that there are 4 instances)?
Original:
If any below conditions fail:
- Validate that the receiving node's BGP...
Perhaps:
Check if any conditions below fail:
- Validate that the receiving node's BGP...
c) Should the text reflect "the receiving node's BGP" or
"the Receiving Node BGP" for consistency (note that there
are multiple instances)?
d) Should "the remote AS field" or "one of the remote AS
fields" be used for consistency?
Original:
- Validate that the receiving node's BGP Local AS matches
with the remote AS field in the received PeerNode SID
FEC sub-TLV.
- Validate that the Receiving Node BGP Local AS matches
with one of the remote AS field in the received
PeerSet SID FEC sub-TLV.
e) Should citations be included for return codes 3 and 10? Should
"<RSC>" be added to the descriptions to match how they appear in
RFC 8029?
Original:
Set the Best-return-code to 10, "Mapping for this FEC is not
the given label at stack-depth". If any below conditions fail:
If all above validations have passed, set the return code to 3,
"Replying router is an egress for the FEC at stack-depth".
Perhaps:
Set the Best-return-code to 10, "Mapping for this FEC is not
the given label at stack-depth <RSC>" [RFC8029]. If any below
conditions fail:
If all above validations have passed, set the return code to 3,
"Replying router is an egress for the FEC at stack-depth <RSC>"
[RFC8029].
-->
14) <!-- [rfced] We have included some specific questions about the IANA
text below. In addition to responding to those questions, please
review all of the IANA-related updates carefully and let us know
if any further updates are needed.
a) It appears that the "IANA Considerations" section references the
"Sub-TLVs for TLV Types 1, 16, and 21" registry in the "Multiprotocol
Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters"
registry group, but it does not include a citation for this registry
here or in the references section.
May we add the following citation as a normative or informative
reference as shown below?
Original:
IANA is requested to allocate three new Target FEC stack sub-TLVs
from the "Sub-TLVs for TLV types 1,16 and 21" subregistry in the
"TLVs" registry of the "Multi-Protocol Label switching (MPLS) Label
Switched Paths (LSPs) Ping parameters" namespace.
Perhaps:
IANA has allocated three new Target FEC stack sub-TLVs in the
"Sub-TLVs for TLV Types 1, 16, and 21" registry
[IANA-MPLS-LSP-PING-Parameters] within the "TLVs" registry of the
"Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs)
Ping Parameters" registry group.
Reference:
[IANA-MPLS-LSP-PING-Parameters]
IANA, "Sub-TLVs for TLV Types 1, 16, and 21",
<https://www.iana.org/assignments/mpls-lsp-ping-parameters>.
b) We have removed "Sub-TLV" from the entries in Tables 1 and 2 per
IANA's note. Please let us know if "Sub-TLV" should be
removed from any other instances in the running text for consistency.
We note the following variations:
PeerAdj SID
PeerAdj SID FEC
PeerAdj SID FEC sub-TLV
PeerAdj SID Sub-TLV
PeerAdj SID sub-TLV
PeerSet SID sub-TLV
PeerNode SID sub-TLV
-->
15) <!-- [rfced] Since 'draft-ietf-idr-segment-routing-te-policy'
is expired and has been replaced by
'draft-ietf-idr-bgp-sr-segtypes-ext' and
'draft-ietf-idr-sr-policy-safi', may we replace the current
reference entry with the entries for these two drafts?
Note that this would include adding two reference tags to the
text in Section 2.
Original:
[SR-TE-POLICY]
Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., and
D. Jain, "Advertising Segment Routing Policies in BGP",
Work in Progress, Internet-Draft, draft-ietf-idr-segment-
routing-te-policy-26, 23 October 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-idr-
segment-routing-te-policy-26>.
Perhaps:
[BGP-SR-SEGTYPES-EXT]
Talaulikar, K., Filsfils, C., Previdi, S., Mattes, P., and
D. Jain, "Segment Routing Segment Types Extensions for BGP
SR Policy", Work in Progress, Internet-Draft, draft-ietf-
idr-bgp-sr-segtypes-ext-06, 7 November 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-
sr-segtypes-ext-06>.
[SR-BGP-POLICY]
Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., and
D. Jain, "Advertising Segment Routing Policies in BGP",
Work in Progress, Internet-Draft, draft-ietf-idr-sr-
policy-safi-10, 7 November 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-
policy-safi-10>.
-->
16) <!-- [rfced] May we update the title of the appendix to avoid the
repetition of "Appendix A: Appendix"? Perhaps "Examples of
Correctly and Incorrectly Programmed States" or "Examples of
Programmed States?
Current:
Appendix A. Appendix
Perhaps:
Appendix A. Examples of Programmed States
-->
17) <!-- [rfced] Terminology and Abbreviations
a) Throughout the text, the following terminology appears to be capitalized
inconsistently. Please review these occurrences and let us know if/how they
may be made consistent.
Adj-Type vs. Adj type
Integer vs. integer
Local AS number vs. local AS number
Local interface vs. local interface
Link Descriptors vs. link descriptors
Remote interface vs. remote interface
b) How may we make these terms consistent? For the case, we suggest
capitalizing "Target" and "Stack" to match use in RFC 8287 and
other past RFCs.
Target FEC Stack TLV vs.
Target FEC stack TLV vs.
target FEC stack TLV vs.
target FEC stack
[Note: should the last instance contain "TLV"?]
FEC stack TLV vs.
FEC stack
[Note: should "Target" be added to these instances? And
should the last instance contain "TLV"?]
Target FEC Stack sub-TLV vs.
Target FEC stack sub-TLV vs.
Target FEC sub-TLV
[Note: should "Stack" be added to the last instance?]
c) In the text, "Type 1" appears to have two different names. Are these meant
to be the same or different? We see "Target FEC Stack TLV (Type 1)" in RFC 8287.
Please let us know how/if we may update. Note that we recommend making "stack"
uppercase for consistency.
Abstract:
MPLS Target stack TLV (Type 1)
Section 4:
Target FEC Stack TLV (Type 1)
d) It appears that in past RFCs, the term "FEC stack-depth" is used instead of
"FEC-stack-depth". Should we update to only one hyphen?
e) We see "MPLS Ping and Traceroute procedures" and "ping or traceroute
packets"
in the running text. Should 1 instance of "MPLS traceroute procedure" perhaps
be
"MPLS Ping and Traceroute procedures" for consistency?
Original:
The data plane validation of the SID will be done during the
MPLS traceroute procedure.
Perhaps:
The data plane validation of the SID will be done during the
MPLS Ping and Traceroute procedures.
f) FYI - We added expansions for the following abbreviations in the text.
Please review for accuracy.
ASN: Access Service Network
BGP-LS: Border Gateway Protocol - Link State
EBGP: External BGP
OAM: Operations, Administration, and Maintenance
-->
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 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/st/kc
On Dec 13, 2024, at 4:14 PM, [email protected] wrote:
*****IMPORTANT*****
Updated 2024/12/13
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/rfc9703.xml
https://www.rfc-editor.org/authors/rfc9703.html
https://www.rfc-editor.org/authors/rfc9703.pdf
https://www.rfc-editor.org/authors/rfc9703.txt
Diff file of the text:
https://www.rfc-editor.org/authors/rfc9703-diff.html
https://www.rfc-editor.org/authors/rfc9703-rfcdiff.html (side by side)
Diff of the XML:
https://www.rfc-editor.org/authors/rfc9703-xmldiff1.html
Tracking progress
-----------------
The details of the AUTH48 status of your document are here:
https://www.rfc-editor.org/auth48/rfc9703
Please let us know if you have any questions.
Thank you for your cooperation,
RFC Editor
--------------------------------------
RFC9703 (draft-ietf-mpls-sr-epe-oam-19)
Title : Label Switched Path (LSP) Ping/Traceroute for Segment
Routing (SR) Egress Peer Engineering Segment Identifiers (SIDs) with MPLS Data
Plane
Author(s) : S. Hegde, M. Srivastava, K. Arora, S. Ninan, X. Xu
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]
