Egress Validation in Label Switched Path Ping and Traceroute Mechanisms
draft-ietf-mpls-egress-tlv-for-nil-fec-15

This is a Nit:  Section 7 states:  "This document defines additional MPLS LSP ping TLVs and follows the mechanisms defined in [RFC8029]. All the security considerations defined in [RFC8287] will be applicable for this document..." When one looks at RFC 8287, it states that the Security Considerations are the same as RFC 8029.  It would be my recommendation to just reference RFC 8029 directly.

# Gunter Van de Velde, RTG AD, comments for draft-ietf-mpls-egress-tlv-for-nil-fec-13

Please find https://www.ietf.org/blog/handling-iesg-ballot-positions/ documenting the handling of ballots.

I would like to extend my gratitude to Stewart Bryant, Sasha Vainshtein, and He Jia for their RTG-DIR reviews.

The document still contains an inconsistent mixture of "NiL" and "Nil," despite this issue being flagged in earlier RTG-DIR reviews.

The text can be challenging to read due to grammatical constructs. While I have attempted to address some of these issues in my detailed review, there are areas where improvements are still needed.

Below, you will find no remaining blocking DISCUSS points and a series of non-blocking COMMENTS, which I hope the authors can use to enhance the document.

#DISCUSS items
#=============
##[resolved] DISCUSS1
The last paragraph of section 2 describes:

187	   segments on any path without upgrading transit nodes.  The code point
188	   used for Egress TLV is from the range 32768-65535 and can can be
189	   silently dropped if not recognised as per [RFC8029] and as per
190	   clarifications from [RFC9041]

However RFC9041 instructs the following:

"   *  All TLVs and sub-TLVs in the range 32768-65535 can be silently
      dropped if they are not recognized.  Alternatively, the receiver
      may step over the unrecognized TLV or send an error message.
"

What if the receiver send an error message instead of silently dropping it? 
How to handle this consistent with formal procedure?

##[resolved] DISCUSS2
In section 3 is written:

196	   FEC-stack TLV in the MPLS Echo Request packet.  This TLV can only be
197	   used in LSP ping/traceroute requests generated by the head-end node
198	   of an LSP or SR policy for which verification is performed.  In case

What if it is used in something else as LSP ping/traceroute? what happens?
How will an intermediate node react?

##[resolved] DISCUSS3
Section 4 details that RFC8029 is extended. Should then this document not update RFC8029 accordingly?

##[resolved] DISCUSS4
Section "4.2.  Receiving Egress TLV in MPLS Echo Request" provides input about additional processing for the Egress TLV on the receiver node. 

a) It is unclear what can be considered as a received node. Is it a node that receives a packet with Egress TLV or is it the final node intended as target for the flow?

b) step 1, 2, 2a and 2b have no normative RFC2119 language. Is none of this required or is all best effort for an implementation to be compliant?

#DETAILED COMMENTS
#=================

16	Abstract
17
18	   The MPLS ping and traceroute mechanism as described in RFC 8029 and
19	   related extensions for Segment Routing(SR) as defined in RFC 8287 is
20	   very useful to validate the control plane and data plane
21	   synchronization.  In some environments, only some intermediate or
22	   transit nodes may have been upgraded to support these validation
23	   procedures.  A simple MPLS ping and traceroute mechanism allows
24	   traversing any path without validating the control plane state.  RFC
25	   8029 supports this mechanism with Nil Forwarding Equivalence Class
26	   (FEC).  The procedures described in RFC 8029 mostly apply when the
27	   Nil FEC is used as an intermediate FEC in the label stack.  When all
28	   labels in the label stack are represented using Nil FEC, it poses
29	   some challenges.
30
31	   This document introduces a new Type-Length-Value (TLV) as an
32	   extension to exisiting Nil FEC.  It describes MPLS ping and
33	   traceroute procedures using Nil FEC with this extension to overcome
34	   these challenges.

The abstract can be improved for better readability flow and fixing typos. What about this proposal:

"The MPLS ping and traceroute mechanisms, as described in RFC 8029 and the related extensions for Segment Routing (SR) defined in RFC 8287, are highly valuable for validating control plane and data plane synchronization. In certain environments, only some intermediate or transit nodes may have been upgraded to support these validation procedures. A straightforward MPLS ping and traceroute mechanism allows traversing any path without validating the control plane state. RFC 8029 supports this mechanism with the Nil Forwarding Equivalence Class (FEC). The procedures outlined in RFC 8029 are primarily applicable when the Nil FEC is used as an intermediate FEC in the label stack. However, challenges arise when all labels in the label stack are represented using the Nil FEC.

This document introduces a new Type-Length-Value (TLV) as an extension to the existing Nil FEC. It describes MPLS ping and traceroute procedures using the Nil FEC with this extension to address and overcome these challenges.
"

102	   Segment routing supports the creation of explicit paths using Adj-
103	   SIDs, Node-SIDs, and Anycast-SIDs defined in [RFC8402].  In certain

These are documented (with a slightly different name) in RFC8402 as "Link-State IGP Segments". Any reason why BGP segments are not mentioned? Maybe the text should explicit indicate that this document is for IGP domains if it was intentional?

103	   SIDs, Node-SIDs, and Anycast-SIDs defined in [RFC8402].  In certain
104	   usecases, the TE paths are built using mechanisms described in
105	   [RFC9256] by stacking the labels that represent the nodes and links
106	   in the explicit path.  Controllers are often deployed to construct

RFC9256 speaks about ordered lists of segments. A segment is not necessary a label according RFC9256. This document is however about MPLS Nil fec. Maybe introduction should provide indicating that his is MPLS data plane only and not IPv6 SRv6.

"The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy."

107	   paths across multi-domain networks.  In such deployments, the head-
108	   end routers may have a database of its own domain and may not be
109	   aware of the FEC associated with labels that are used by the
110	   controller to build paths across multiple domains.  A very useful

What is 'a database'. What information is the router to expect to find in such database?

119	   [RFC8287].  [RFC8029] provides mechanisms to primarily validate the
120	   data plane and secondarily to verify the data plane against the
121	   control plane.  It also provides the ability to traverse Equal cost

What about following rewrite proposal:

"[RFC8029] primarily provides mechanisms to validate the data plane and, secondarily, to verify the consistency of the data plane with the control plane.
"

122	   Mutiple Paths (ECMP) and validate each of the ECMP paths.  The use of
123	   Target FEC requires all nodes in the network to have implemented the
124	   validation procedures.  All intermediate nodes may not have been

s/Mutiple/Multiple/

Not being very well experienced with LSP ping i had to look up Target FEC in RFC8029. Maybe add reference to the description or add a Terminology section for easier readability

132	   Generic IPv4 and IPv6 FECs are used when the protocol that is
133	   advertising the label is unknown.  The information that is carried in

RFC8029 talks about Target FEC Stack is a list of sub-TLVs where some have subtype "Generic IPv4 prefix" and "Generic IPv6 prefix". The text should align with the wording used in RFC8029.

132	   Generic IPv4 and IPv6 FECs are used when the protocol that is
133	   advertising the label is unknown.  The information that is carried in
134	   Generic FEC is the IPv4 or IPv6 prefix and prefix length.  Thus
135	   Generic FEC types perform an additional control plane validation.
136	   However, the details of Generic FEC and validation procedures are not
137	   very detailed in the [RFC8029].  The use-case mostly specifies inter-
138	   AS VPNs as the motivation.  Certain aspects of SR such as anycast
139	   SIDs require clear guidelines on how the validation procedure should
140	   work.  Also, Generic FEC may not be widely supported and if transit
141	   routers are not upgraded to support validation of Generic FEC,
142	   traceroute may fail.  On other hand, Nil FEC consists of the label
143	   and there is no other associated FEC information.  Nil FEC is used to
144	   traverse the path without validation for cases where the FEC is not
145	   defined or routers are not upgraded to support the FECs.  Thus, it
146	   can be used to check any combination of segments on any data path.
147	   The procedures described in [RFC8029] are mostly applicable when the
148	   Nil FEC is used where the Nil FEC is an intermediate FEC in the label
149	   stack.  When all labels in the label-stack are represented using Nil
150	   FEC, it poses some challenges.

To me this complete section needs a rewrite. Its a very dense read touching many technologies and constraints and operational complications. This draft handles about Nil FEC, and hence the text about Generic IPv4/IPv6 prefix seems slightly confusing. Why is this even discussed here?

175	   To avoid this problem, there is a need to add additional information
176	   in the MPLS Echo Request message in ping and treaceroute mode along
177	   with Nil FEC to do minimal validation on the egress/destination
178	   router and send proper information on success and failure to the
179	   ingress router.  This additional information should help to report
180	   transit router information to the ingress/initiator router that can
181	   be used by an offline application to validate the traceroute path.

With this formal procedure, would it not be needed to indicate that this draft updates RFC8029 because it fixes a bug/bad-behavior?

175	   To avoid this problem, there is a need to add additional information
176	   in the MPLS Echo Request message in ping and treaceroute mode along
177	   with Nil FEC to do minimal validation on the egress/destination
178	   router and send proper information on success and failure to the
179	   ingress router.  This additional information should help to report
180	   transit router information to the ingress/initiator router that can
181	   be used by an offline application to validate the traceroute path.

183	   Thus the addition of egress information in the MPLS Echo Request
184	   message in ping and traceroute mode will help in validating Nil-FEC
185	   on each receiving router on the label-stack path to ensure the
186	   correct destination.  It can be used to check any combination of
187	   segments on any path without upgrading transit nodes.  The code point
188	   used for Egress TLV is from the range 32768-65535 and can can be
189	   silently dropped if not recognised as per [RFC8029] and as per
190	   clarifications from [RFC9041]

What about the following rephrasing of this text:

"To mitigate this issue, it is necessary to include additional information in the MPLS Echo Request message in both ping and traceroute modes, along with the Nil FEC, to perform minimal validation on the egress/destination router. This will enable the router to send appropriate success and failure information to the ingress router. This supplementary information should assist in reporting transit router details to the ingress/initiator router, which can be utilized by an offline application to validate the traceroute path.

Consequently, the inclusion of egress information in the MPLS Echo Request message in ping and traceroute modes will facilitate the validation of Nil FEC on each receiving router along the label stack path, ensuring the correct destination. It can be employed to verify any combination of segments on any path without requiring upgrades to transit nodes. The code point used for the Egress TLV falls within the range 32768-65535 and can be silently discarded if not recognized, in accordance with [RFC8029] and the clarifications provided in [RFC9041].
"

187	   segments on any path without upgrading transit nodes.  The code point
188	   used for Egress TLV is from the range 32768-65535 and can can be
189	   silently dropped if not recognised as per [RFC8029] and as per
190	   clarifications from [RFC9041]

RFC9041 instructs the following:

"   *  All TLVs and sub-TLVs in the range 32768-65535 can be silently
      dropped if they are not recognized.  Alternatively, the receiver
      may step over the unrecognized TLV or send an error message.
"

WHat if the received send an error message instead of silently dropping it?

194	   The Egress TLV MAY be included in an MPLS Echo Request message.  It
195	   is an optional TLV and if it is present it MUST appear before the
196	   FEC-stack TLV in the MPLS Echo Request packet.  This TLV can only be
197	   used in LSP ping/traceroute requests generated by the head-end node
198	   of an LSP or SR policy for which verification is performed.  In case
199	   multiple Nil FECs are present in Target FEC Stack TLV, Egress TLV
200	   MUST be added corresponding to the ultimate egress of the label-
201	   stack.  It can be used for any kind of path with Egress TLV added
202	   corresponding to the endpoint of the path.  Explicit Path can be
203	   created using Node-SID, Adj-SID, Binding-SID etc.  Prefix field of
204	   Egress TLV MUST be derived from path egress/destination.  The format
205	   is as specified below

This section is hard to follow. May i suggest following rewrite:

"The Egress TLV MAY be included in an MPLS Echo Request message. It is an optional TLV and, if present, MUST appear before the FEC-stack TLV in the MPLS Echo Request packet. This TLV can only be used in LSP ping/traceroute requests generated by the head-end node of an LSP or SR policy for which verification is performed. In cases where multiple Nil FECs are present in the Target FEC Stack TLV, the Egress TLV must be added corresponding to the ultimate egress of the label stack. It can be used for any type of path with the Egress TLV added corresponding to the endpoint of the path. Explicit paths can be created using Node-SID, Adj-SID, Binding-SID, etc. The prefix field of the Egress TLV must be derived from the path egress/destination. The format is as specified below:
"

235	   As stated earlier, when the sender node builds an Echo Request with
236	   target FEC Stack TLV, Egress TLV when present, MUST appear before
237	   Target FEC-stack TLV in the MPLS Echo Request packet.

Suggested rewrite:
As previously mentioned, when the sender node constructs an Echo Request with a Target FEC Stack TLV, the Egress TLV, if present, MUST appear before the Target FEC Stack TLV in the MPLS Echo Request packet.

241	   When sender node builds an Echo Request with target FEC Stack TLV
242	   that contains a single NiL FEC corresponding to the last segment of

s/NiL/Nil/

241	   When sender node builds an Echo Request with target FEC Stack TLV
242	   that contains a single NiL FEC corresponding to the last segment of
243	   the SR Policy path, the sender node MUST add an Egress TLV with the
244	   prefix obtained from SR policy endpoint field

Previously it was mentioned that the prefix could be obtained :
"from the egress of Nil FEC corresponding to the last label in the label-stack or SR policy endpoint field [I.D-ietf-idr-sr-policy-safi]." 

This seems inconsistent with the text blob here. similar is with next few lines of the paragraph. IS SRTE the only ue-case for this?

257	      b.  If the last SID in the policy is a Binding SID, the prefix
258	      represents the last node of the path represented by the Binding
259	      SID.

Could this not lead to situation where on a transit node there is absolutely no awareness where this last node is located outside the scope of the local domain? (intern=mediate node may not have a full routing table)

263	   When sender node builds an Echo Request with target FEC Stack TLV
264	   that contains NiL FEC corresponding to last segment of the segment-

s/buids/constructs/
s/NiL/Nil/

270	   Although there is no requirement to do so, an implementation MAY send
271	   multiple Nil FEC if that makes the it easier for the implementation.
272	   In case the headend sends multiple Nil FECs the last one MUST
273	   correspond to the Egress TLV.  The Label value in the Nil FEC MAY be

Please add more info hat is intended with "headend". I assume it is the SRTE headend, but maybe it refers to some other hierarchical tunnel constructs or technologies.

273	   correspond to the Egress TLV.  The Label value in the Nil FEC MAY be
274	   set to zero for the last Nil FEC.  In case the endpoint is not

What happens, or should happen, if the Nil FEC is not set to zero? 

274	   set to zero for the last Nil FEC.  In case the endpoint is not
275	   specified or is equal to 0 ( as in case of color-only SR Policy),the
276	   sender MUST use the the prefix corresponding to the last segment
277	   endpoint of the SR Policy path i.e. ultimate egress as the prefix for
278	   Egress TLV.

is this color-only SR Policy suggesting "8.8.1.  Color-Only BGP Destination Steering" from RFC9256? Maybe add reference.

317	   Additional processing is done for the Egress TLV on the receiver node
318	   as follows:

Is a receiver node the final node in the path or is it a transit node that receives a packet enriched with an Egress TLV? Please clarify.

330	   2a.  If the Egress TLV prefix lookup succeeds, set Best-return-code
331	   to 36 ("Replying router is an egress for the prefix in Egress TLV for
332	   the FEC at stack depth RSC") (Section 6.2) egress ok in MPLS Echo
333	   Reply message.

This does not very well resonate with me. When removing the brackets () then the remainder of the text reads: 

   2a.  If the Egress TLV prefix lookup succeeds, set Best-return-code
   to 36 egress ok in MPLS Echo Reply message.

339	   3.In cases where multiple Nil FECs are sent from ingress, one each
340	   corresponding to the labels in the label stack along with Egress
341	   TLV,when the packet reaches egress, the number of labels in the

Previously the term headend was used, and now it is ingress. Maybe consistent terminology should be used for best formal procedure

348	   The extensions defined in this document is backward compatible with
349	   procedures described in [RFC8029].  A Router that does not support
350	   Egress TLV, will ignore it and use current the Nil-FEC procedures
351	   described in [RFC8029].

RFC9041 indicate that an implementation could send a error message instead of silently ignoring. How would this impact the solution?

Thanks for this document. I have two comments.

### Section 3 and following, prefix

The field you call prefix here, is really an address, not a prefix, since you constrain the value to be either an IPv4 /32 or an IPv6 /128, but nothing else. I suggest that you s/prefix/address/ in this section and all the following sections. (The occurrences in Section 1 appear to be correct as written.)

I notice that Éric Vyncke raised a similar concern.

### Section 4.2, egress ok

   2a.  If the Egress TLV prefix lookup succeeds, set Best-return-code
   to 36 ("Replying router is an egress for the prefix in Egress TLV for
   the FEC at stack depth RSC") (Section 6.2) egress ok in MPLS Echo
   Reply message.

What does "egress ok" in that paragraph mean? Is it an editing error, and should it be removed?

Paragraph 2

Although the document is short, it is hard to read in parts and could have done with some editing before being sent for publication.

Section 4.1.2, paragraph 7
>    In ping Echo Request, with target FEC Stack TLV that contains a
>    single NiL FEC corresponding to 1007, should add Egress TLV for
>    endpoint/destination prefix X with type as Egress TLV, length depends
>    on if X is IPv4 or IPv6 address and prefix as X.
> 
>    In traceroute Echo Request, with target FEC Stack TLV that contains a
>    single NiL FEC corresponding to the complete label-stack (1002, 1004,
>    1007) or multiple Nil-FEC corresponding to each label in the label-
>    stack, should add single Egress TLV for endpoint/destination prefix X
>    with type as Egress TLV, length depends on if X is IPv4 or IPv6
>    address and prefix as X.  In case X is not present or is set to 0 (
>    as in the case of color-only SR Policy), sender should use the
>    endpoint of segment 1007 as a prefix for Egress TLV.

These two paragraphs were particularly hard to read with long sentences, and articles & prepositions missing. Can it be rewritten?

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 4.1, paragraph 1
>    As stated earlier, when the sender node builds an Echo Request with
>    target FEC Stack TLV, Egress TLV when present, MUST appear before
>    Target FEC-stack TLV in the MPLS Echo Request packet.


Inconsistent use of the term Target FEC Stack TLV. Sometimes, Target is with a small t, sometimes there is a -, etc.

Section 1, paragraph 2
> 4 or IPv6 prefix and prefix length. Thus Generic FEC types perform an additio
>                                     ^^^^
A comma may be missing after the conjunctive/linking adverb "Thus".

Section 2, paragraph 2
> on to validate the traceroute path. Thus the addition of egress information i
>                                     ^^^^
A comma may be missing after the conjunctive/linking adverb "Thus".

Section 4.1.1, paragraph 1
> end multiple Nil FEC if that makes the it easier for the implementation. In 
>                                    ^^^^^^
Please verify. Did you mean "it" or "the IT" (= information technology)?

The document shepherd's answer to question #11 is incomplete.

Thank you to Linda Dunbar for the GENART review.

I have no GEN Area feedback.

Thank you for writing this document.

Also, *much* thanks to Yingzhen Qu for the OpsDir review -- https://datatracker.ietf.org/doc/review-ietf-mpls-egress-tlv-for-nil-fec-13-opsdir-lc-qu-2024-05-20/
I strongly suggest that the authors review this - Yingzhen has provided a much improved Abstract, in addition to some helpful nit fixes.
(Gunter has also provided an option)

Thanks for working on this specification. I have no issues here from transport protocol point of view.

# Éric Vyncke, INT AD, comments for draft-ietf-mpls-egress-tlv-for-nil-fec-13

Thank you for the work put into this document. The text is sometimes convoluted (e.g., section 2).

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Tarek Saad for the shepherd's detailed write-up including the WG consensus *BUT* it lacks the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric


# COMMENTS (non-blocking)

## Section 1

"domain" is used several times in this section, but is not qualified. Suggest to use "operator domain" or "controller domain" or...

The same section also uses "nodes", should it rather be "routers" ?

## Section 3

Suggest to mention that the length is measured in octets.

Possibly due to my ignorance of the use case but can the prefix be a multicast prefix ? can the prefix be shorter than 128 or 32 ? E.g., 2001:db8:cafe::/48 ?

## Section 4.1.1

Should [I.D-ietf-idr-sr-policy-safi] be a normative reference rather than an informative one ?

## Section 4.2

What is the expected behavior when receiving a Target FEC TLV whose length if neither 4 or 16 ?



# NITS (non-blocking / cosmetic)

## Section 2

s/treaceroute/traceroute/