Hi Sarah,
Thank you for the edits.
I think I misunderstood the sub-TLV replacement.
I see some places where the PeerAdj SID is replaced with PeerAdj Sid sub-TLV
which is not correct.
The node advertising PeerAdj SID is different from the node that generates the
PeerAdj Sid sub-TLV.
In some places the sub-TLV need to be removed
Pls see below.
1. Introduction
For example, on C, a PeerAdj SID sub-TLV could be
advertised to indicate it is for the link C->D. Due to some software
anomaly, the actual data forwarding on this PeerAdj SID sub-TLV could
be happening over the C->E link.
Change to
For example, on C, a PeerAdj SID could be
advertised to indicate it is for the link C->D. Due to some software
anomaly, the actual data forwarding on this PeerAdj SID could
be happening over the C->E link.
2.Sec 4.2:
Local AS Number: 4 octets. The unsigned integer representing the AS
number [RFC6793] of the AS to which the PeerAdj SID sub-TLV
advertising node belongs. If Confederations [RFC5065] are in use,
and if the remote node is a member of a different Member-AS within
the local Confederation, this is the Member-AS Number inside the
Confederation and not the Confederation Identifier.
Remote AS Number: 4 octets. The unsigned integer representing the
AS number [RFC6793] of the remote node's AS for which the PeerAdj
SID sub-TLV is advertised. If Confederations [RFC5065] are in
use, and if the remote node is a member of a different Member-AS
within the local Confederation, this is the Member-AS Number
inside the Confederation and not the Confederation Identifier.
Local BGP Router ID: 4 octets. The unsigned integer representing
the BGP Identifier of the PeerAdj SID sub-TLV advertising node as
defined in [RFC4271] and [RFC6286].
Remote BGP Router ID: 4 octets. Unsigned The unsigned integer representing
the BGP Identifier of the remote node as defined in [RFC4271] and
[RFC6286].
Local Interface Address: 4 octets or 16 octets. In the case of
PeerAdj SID, SID sub-TLV, the Local local interface address corresponding
to
the PeerAdj SID sub-TLV should be specified in this field. For
IPv4, this field is 4 octets; for IPv6, this field is 16 octets.
Link-local IPv6 addresses are not in the scope of this document.
Remote Interface Address: 4 octets or 16 octets. In the case of
PeerAdj SID, SID sub-TLV, the Remote remote interface address
corresponding to
the PeerAdj SID sub-TLV should be specified in this field. For
IPv4, this field is 4 octets; for IPv6, this field is 16 octets.
Link-local IPv6 addresses are not in the scope of this document.
Remove sub-TLV change as below
Local AS Number: 4 octets. The unsigned integer representing the AS
number [RFC6793] of the AS to which the PeerAdj SID
advertising node belongs. If Confederations [RFC5065] are in use,
and if the remote node is a member of a different Member-AS within
the local Confederation, this is the Member-AS Number inside the
Confederation and not the Confederation Identifier.
Remote AS Number: 4 octets. The unsigned integer representing the
AS number [RFC6793] of the remote node's AS for which the PeerAdj
SID is advertised. If Confederations [RFC5065] are in
use, and if the remote node is a member of a different Member-AS
within the local Confederation, this is the Member-AS Number
inside the Confederation and not the Confederation Identifier.
Local BGP Router ID: 4 octets. The unsigned integer representing
the BGP Identifier of the PeerAdj SID advertising node as
defined in [RFC4271] and [RFC6286].
Remote BGP Router ID: 4 octets. Unsigned The unsigned integer representing
the BGP Identifier of the remote node as defined in [RFC4271] and
[RFC6286].
Local Interface Address: 4 octets or 16 octets. In the case of
PeerAdj SID, the Local local interface address corresponding to
the PeerAdj SID, should be specified in this field. For
IPv4, this field is 4 octets; for IPv6, this field is 16 octets.
Link-local IPv6 addresses are not in the scope of this document.
Remote Interface Address: 4 octets or 16 octets. In the case of
PeerAdj SID, the Remote remote interface address corresponding to
the PeerAdj SID, should be specified in this field. For
IPv4, this field is 4 octets; for IPv6, this field is 16 octets.
Link-local IPv6 addresses are not in the scope of this document.
3. sec 4.3
PeerSet SID may be associated with a number of PeerNode SIDs and
PeerAdj SIDs. SID sub-TLVs. The remote AS number and the Router ID of each
of these PeerNode SIDs and PeerAdj SIDs SID sub-TLVs MUST be included in
the FEC.
Change to
PeerSet SID may be associated with a number of PeerNode SIDs and
PeerAdj SIDs. The remote AS number and the Router ID of each
of these PeerNode SIDs and PeerAdj SIDs MUST be included in
the FEC.
4. sec 5 EPE-SID FEC Validation
Add sub-TLV to Peer NodeSId as well as Peer set SID
Existing
PeerAdj SID sub-TLV
-----------
If Adj type = 1, Length should be 28 octets
If Adj type = 2, Length should be 52 octets
PeerNode SID
-------------
Length = (20 + No.of No. of IPv4 interface pairs * 8 +
No. of IPv6 interface pairs * 32) octets
PeerSet SID
-----------
Length = (9 + No.of No. of elements in the set *
(8 + No.of No. of IPv4 interface pairs * 8 +
No. of IPv6 interface pairs * 32) octets
Change to
PeerAdj SID sub-TLV
-----------
If Adj type = 1, Length should be 28 octets
If Adj type = 2, Length should be 52 octets
PeerNode SID sub-TLV
-------------
Length = (20 + No.of No. of IPv4 interface pairs * 8 +
No.of
No. of IPv6 interface pairs * 32) octets
PeerSet SID sub-TLV
-----------
Length = (9 + No.of No. of elements in the set *
(8 + No.of No. of IPv4 interface pairs * 8 +
No.of
No. of IPv6 interface pairs * 32) octets
5. Sec 5.1
This is an example of Segment Routing IGP-Prefix, IGP-Adjacency SID,
and EPE-SID
Validation: Receiving node validations.
Change to
This is an example of Segment Routing IGP-Prefix, IGP-Adjacency SID,
and EPE-SID
Validations:
Pls note that this section is an addition 4a of Section 7.4 of [RFC8287].
It is not an example and also the heading need to look exactly same as 4a of
Section 7.4 of 8287 otherwise it will be confusing for the reader.
5. appendix.
Below places sub-TLV need to be removed
The controller learns that PeerAdj SID sub-TLV label 16001 is
bound to adjacency C->E (e.g., via BGP-LS) -- this could be a
software bug on C or on the controller
Change to
The controller learns that PeerAdj SID label 16001 is
bound to adjacency C->E (e.g., via BGP-LS) -- this could be a
software bug on C or on the controller
Rgds
Shraddha
Juniper Business Use Only
-----Original Message-----
From: Sarah Tarrant <starr...@amsl.com>
Sent: 19 December 2024 20:55
To: Shraddha Hegde <shrad...@juniper.net>; kapil arora <kapil...@gmail.com>
Cc: Samson <samson....@gmail.com>; Mukul Srivastava <m...@juniper.net>; RFC
Editor <rfc-edi...@rfc-editor.org>; Tiger Xu <xuxiaohu_i...@hotmail.com>;
mpls-...@ietf.org; MPLS Working Chairs <mpls-cha...@ietf.org>; Tarek Saad
<tsaad....@gmail.com>; James Guichard <james.n.guich...@futurewei.com>;
auth48archive@rfc-ed <auth48archive@rfc-editor.org>
Subject: Re: AUTH48: RFC-to-be 9703 <draft-ietf-mpls-sr-epe-oam-19> for your
review
[External Email. Be cautious of content]
Hi Shraddha and Kapil,
Kapil - Thank you for your reply. We have marked your approval on the AUTH48
status page for this document (see
https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9703__;!!NEt6yMaO-gk!FnTKII88Ma0kIOqYBqAnoSvW1QATR8NDfKMGNRt69_uIoanipWUvj85Sxo6oJpM5lRn2yB-Rb9Bzvrtd$
).
Shraddha - Thank you for your reply. We have updated the document accordingly.
Please review the document carefully to ensure satisfaction as we do not make
changes once it has been published as an RFC. Contact us with any further
updates or with your approval of the document in its current form. We will
await approvals from each author prior to moving forward in the publication
process.
The updated files have been posted here (please refresh):
https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9703.txt__;!!NEt6yMaO-gk!FnTKII88Ma0kIOqYBqAnoSvW1QATR8NDfKMGNRt69_uIoanipWUvj85Sxo6oJpM5lRn2yB-Rb8whdHdD$
https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9703.pdf__;!!NEt6yMaO-gk!FnTKII88Ma0kIOqYBqAnoSvW1QATR8NDfKMGNRt69_uIoanipWUvj85Sxo6oJpM5lRn2yB-Rb0FIug0w$
https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9703.html__;!!NEt6yMaO-gk!FnTKII88Ma0kIOqYBqAnoSvW1QATR8NDfKMGNRt69_uIoanipWUvj85Sxo6oJpM5lRn2yB-Rbxh4Bd3i$
https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9703.xml__;!!NEt6yMaO-gk!FnTKII88Ma0kIOqYBqAnoSvW1QATR8NDfKMGNRt69_uIoanipWUvj85Sxo6oJpM5lRn2yB-Rb_kXXnSm$
The relevant diff files have been posted here (please refresh):
https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9703-diff.html__;!!NEt6yMaO-gk!FnTKII88Ma0kIOqYBqAnoSvW1QATR8NDfKMGNRt69_uIoanipWUvj85Sxo6oJpM5lRn2yB-RbxcpwVYQ$
(comprehensive diff)
https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9703-auth48diff.html__;!!NEt6yMaO-gk!FnTKII88Ma0kIOqYBqAnoSvW1QATR8NDfKMGNRt69_uIoanipWUvj85Sxo6oJpM5lRn2yB-RbzC0ZDJU$
(AUTH48 changes only)
Note that it may be necessary for you to refresh your browser to view the most
recent version.
For the AUTH48 status of this document, please see:
https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9703__;!!NEt6yMaO-gk!FnTKII88Ma0kIOqYBqAnoSvW1QATR8NDfKMGNRt69_uIoanipWUvj85Sxo6oJpM5lRn2yB-Rb9Bzvrtd$
Thank you,
RFC Editor/st
> On Dec 19, 2024, at 6:30 AM, kapil arora <kapil...@gmail.com> wrote:
>
> Hi,
> No comments from my side as well. Approved from my side as well.
>
> Thanks
> Kapil Arora
>
> On Wed, 18 Dec 2024, 22:12 Samson, <samson....@gmail.com> wrote:
> I also don't have any other comments and it's approved from my side.
> Thank you,
> Samson
>
> On Wed, Dec 18, 2024, 21:45 Mukul Srivastava <m...@juniper.net> wrote:
> I have no further comments.
> Approved from my side.
> Thanks
> Mukul
>
> Juniper Business Use Only
> From: Shraddha Hegde <shrad...@juniper.net>
> Date: Wednesday, December 18, 2024 at 6:40 AM
> To: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>, Mukul
> Srivastava <m...@juniper.net>, kapil...@gmail.com
> <kapil...@gmail.com>, samson....@gmail.com <samson....@gmail.com>,
> xuxiaohu_i...@hotmail.com <xuxiaohu_i...@hotmail.com>
> Cc: mpls-...@ietf.org <mpls-...@ietf.org>, mpls-cha...@ietf.org
> <mpls-cha...@ietf.org>, tsaad....@gmail.com <tsaad....@gmail.com>,
> james.n.guich...@futurewei.com <james.n.guich...@futurewei.com>,
> auth48archive@rfc-editor.org <auth48archive@rfc-editor.org>
> Subject: RE: AUTH48: RFC-to-be 9703 <draft-ietf-mpls-sr-epe-oam-19>
> for your review Hi,
>
>
> Thanks for the edits. Pls see inline for response tagged by <SH>
>
> Rgds
> Shraddha
>
>
> Juniper Business Use Only
> -----Original Message-----
> From: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>
> Sent: 14 December 2024 05:46
> To: Shraddha Hegde <shrad...@juniper.net>; Mukul Srivastava
> <m...@juniper.net>; kapil...@gmail.com; samson....@gmail.com;
> xuxiaohu_i...@hotmail.com
> Cc: rfc-edi...@rfc-editor.org; mpls-...@ietf.org;
> mpls-cha...@ietf.org; tsaad....@gmail.com;
> james.n.guich...@futurewei.com; auth48archive@rfc-editor.org
> Subject: Re: AUTH48: RFC-to-be 9703 <draft-ietf-mpls-sr-epe-oam-19>
> 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] 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
> -->
> <SH> I think that MPLS data plane should be singular. Also not sure what you
> mean by short title.
> Is this the title that would appear on the document?
> I would prefer below short title
> LSP Ping/Traceroute 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
> -->
>
> <SH> This is ok
> 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].
> -->
> <SH> The previous sentence is misleading. I would propose below modification
>
> These EPE-SIDs may be used to build SR paths and communicated using
> extensions described
> in [SR-TE-POLICY-IDR]] or Path Computation Element Protocol (PCEP)
> extensions as defined in [RFC8664].
>
> Pls note the change in shorthand for SR-TE-POLICY. Its important to
> indicate its and IDR extension
>
> 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.
> --><SH> This is ok
>
>
> 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.
> -->
> <SH> ok
>
> 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.
> -->
> Suggest as below remov the OAM packet will be sent out
>
> New:
> As per [RFC8029], the node advertising the EPE SIDs will send
> Downstream Detailed Mapping (DDMAP TLV) specifying the details
> of nexthop interfaces.
>
>
>
> 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
> -->
> <SH> This is ok
>
> 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].
> --><SH> ok
>
>
> 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.
> --><SH> ok
>
>
> 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
> --> <SH> Pls edit as needed. The absence of space is not intended
>
>
> 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.
> -->
> Suggest below
>
> Value: Expressed in octets and is a variable 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
> -->
> <SH> Suggest below
> 5. EPE-SID FEC Validation
> 5.1. EPE-SID FEC Validation Rules
>
> 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.
> <SH> suggested as below
> 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
> Corresponds to the node that 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...
> <SH>ok
>
> c) Should the text reflect "the receiving node's BGP" or "the Receiving Node
> BGP" for consistency (note that there are multiple instances)?
> <SH> I think "the receiving node's BGP" is correct. BGP is a protocol that
> runs on the node.
>
> 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.
>
> <SH> PeerNode SID steps cant be replaced by Peer Set SID procedures.
>
>
> 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].
> --><SH> ok
>
>
> 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://urldefense.com/v3/__https://www.iana.org/assignments/mpls-lsp-ping-parameters__;!!NEt6yMaO-gk!FQ0xv4n_uks3qfMaOruoB-6ugBXHCZ51YQAZyGId0xJdMf4K3cPb6WVvy3YeR8aM1-heH_8JtjxSBm-chTV9e9Lv$
> >.
>
> <SH> OK
>
> 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
> --><SH> Pls keep the sub-TLV and remove FEC " PeerAdj SID Sub-TLV"
> consistently in all the text.
> The IANA table can follow IANA's Note
>
>
>
> 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://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-idr-__;!!NEt6yMaO-gk!FQ0xv4n_uks3qfMaOruoB-6ugBXHCZ51YQAZyGId0xJdMf4K3cPb6WVvy3YeR8aM1-heH_8JtjxSBm-chcINvc0-$
> 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://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-__;!!NEt6yMaO-gk!FQ0xv4n_uks3qfMaOruoB-6ugBXHCZ51YQAZyGId0xJdMf4K3cPb6WVvy3YeR8aM1-heH_8JtjxSBm-chfFJ8uqL$
> 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://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-__;!!NEt6yMaO-gk!FQ0xv4n_uks3qfMaOruoB-6ugBXHCZ51YQAZyGId0xJdMf4K3cPb6WVvy3YeR8aM1-heH_8JtjxSBm-chaYNd1Mw$
> policy-safi-10>.
> --><SH> OK
>
>
> 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
> --><SH>ok
>
>
> 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 <SH> yes. They should be
> consistent
>
> 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"?] <SH> "Target FEC
> Stack TLV" is the right usage Change the last instance as well
>
> FEC stack TLV vs.
> FEC stack
> [Note: should "Target" be added to these instances? And
> should the last instance contain "TLV"?] <SH>
> Original:
> As described in Section 1, this document defines FEC stack TLVs for
> EPE-SIDs,
>
> Change to
> As described in Section 1, this document defines sub-TLVs of the Target FEC
> Stack TLV for
> EPE-SIDs
>
>
> 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?]
>
> <SH> Pls change to "Target FEC Stack sub-TLV" for all instances
>
> 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)
> <SH> change to" Target FEC Stack TLV(Type 1)"
>
> Section 4:
> Target FEC Stack TLV (Type 1)
> <SH> This one looks fine
>
> 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?
> <SH>ok
>
>
> 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.
> <SH> No. The validation applicable to traceroute only. Pls keep
> original text
>
> f) FYI - We added expansions for the following abbreviations in the text.
> Please review for accuracy.
>
> ASN: Access Service Network
> <SH> Pls change ASN to AS Number
>
> BGP-LS: Border Gateway Protocol - Link State
> EBGP: External BGP
> OAM: Operations, Administration, and Maintenance <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!FQ0xv4n_uks3qfMaOruoB-6ugBXHCZ51YQAZyGId0xJdMf4K3cPb6WVvy3YeR8aM1-heH_8JtjxSBm-chaUIxJYx$
> > 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.
> -->
> <sH> ok
>
> Thank you.
>
> RFC Editor/st/kc
>
>
> On Dec 13, 2024, at 4:14 PM, rfc-edi...@rfc-editor.org 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://urldefense.com/v3/__https://www.rfc-editor.org/faq/__;!!NEt6yMaO-gk!FQ0xv4n_uks3qfMaOruoB-6ugBXHCZ51YQAZyGId0xJdMf4K3cPb6WVvy3YeR8aM1-heH_8JtjxSBm-chftkYTRQ$
> ).
>
> 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!FQ0xv4n_uks3qfMaOruoB-6ugBXHCZ51YQAZyGId0xJdMf4K3cPb6WVvy3YeR8aM1-heH_8JtjxSBm-chYaCgDkH$
> ).
>
> * 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!FQ0xv4n_uks3qfMaOruoB-6ugBXHCZ51YQAZyGId0xJdMf4K3cPb6WVvy3YeR8aM1-heH_8JtjxSBm-chUj2pAgn$
> >.
>
> * 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!FQ0xv4n_uks3qfMaOruoB-6ugBXHCZ51YQAZyGId0xJdMf4K3cPb6WVvy3YeR8aM1-heH_8JtjxSBm-chdiPGFLb$
>
> * The archive itself:
>
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/auth48archive/__;!!NEt6yMaO-gk!FQ0xv4n_uks3qfMaOruoB-6ugBXHCZ51YQAZyGId0xJdMf4K3cPb6WVvy3YeR8aM1-heH_8JtjxSBm-chWbVSeVB$
>
> * 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/rfc9703.xml__;!!NEt6yMaO-gk!FQ0xv4n_uks3qfMaOruoB-6ugBXHCZ51YQAZyGId0xJdMf4K3cPb6WVvy3YeR8aM1-heH_8JtjxSBm-chfOrRqCw$
>
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9703.html__;!!NEt6yMaO-gk!FQ0xv4n_uks3qfMaOruoB-6ugBXHCZ51YQAZyGId0xJdMf4K3cPb6WVvy3YeR8aM1-heH_8JtjxSBm-chdWgWwU-$
>
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9703.pdf__;!!NEt6yMaO-gk!FQ0xv4n_uks3qfMaOruoB-6ugBXHCZ51YQAZyGId0xJdMf4K3cPb6WVvy3YeR8aM1-heH_8JtjxSBm-chUiabt79$
>
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9703.txt__;!!NEt6yMaO-gk!FQ0xv4n_uks3qfMaOruoB-6ugBXHCZ51YQAZyGId0xJdMf4K3cPb6WVvy3YeR8aM1-heH_8JtjxSBm-chYcSJ6_w$
>
> Diff file of the text:
>
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9703-diff.html__;!!NEt6yMaO-gk!FQ0xv4n_uks3qfMaOruoB-6ugBXHCZ51YQAZyGId0xJdMf4K3cPb6WVvy3YeR8aM1-heH_8JtjxSBm-chRs2yfwd$
>
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9703-rfcdiff.html__;!!NEt6yMaO-gk!FQ0xv4n_uks3qfMaOruoB-6ugBXHCZ51YQAZyGId0xJdMf4K3cPb6WVvy3YeR8aM1-heH_8JtjxSBm-chZfCnyBt$
> (side by side)
>
> Diff of the XML:
>
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9703-xmldiff1.html__;!!NEt6yMaO-gk!FQ0xv4n_uks3qfMaOruoB-6ugBXHCZ51YQAZyGId0xJdMf4K3cPb6WVvy3YeR8aM1-heH_8JtjxSBm-chQNcNkqZ$
>
>
> Tracking progress
> -----------------
>
> The details of the AUTH48 status of your document are here:
>
> https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9703__;!!NEt6yMaO-gk!FQ0xv4n_uks3qfMaOruoB-6ugBXHCZ51YQAZyGId0xJdMf4K3cPb6WVvy3YeR8aM1-heH_8JtjxSBm-chbYoLjPh$
>
> 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 -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
