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

[Ballot comment]
# 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?

[Ballot comment]
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?

[Ballot comment]
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)

[Ballot comment]
Thank you for writing this document.

Also, much 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 nits.
(Gunter has also provided an option)

[Ballot discuss]
# 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 four blocking DISCUSS points and a series of non-blocking COMMENTS, which I hope the authors can use to enhance the document.

#DISCUSS items
#=============
##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?

##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?

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

##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?

[Ballot comment]
#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?

[Ballot discuss]
# 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 four blocking DISCUSS points and a series of non-blocking COMMENTS, which I hope the authors can use to enhance the document.

#DISCUSS items
#=============
##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 from consistently with formal procedure?

##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?

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

##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?

[Ballot comment]
#DETAILED COMMENTS
#=================
##classified as [minor] and [major]

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 indicatin that his is MPLS dataplane 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

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 trasit 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

Previouly 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?

[Ballot comment]
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.

[Ballot comment]

# É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/

[Ballot comment]

# É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 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/

[Ballot comment]

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)?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-mpls-egress-tlv-for-nil-fec-13. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are two actions which we must complete.

First, in the TLVs registry in the Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters registry group located at:

https://www.iana.org/assignments/mpls-lsp-ping-parameters/

a single early allocation is to be made permanent and its reference changed to [ RFC-to-be ] as follows:

Type: 32771
TLV Name: EGRESS TLV
Reference: [ RFC-to-be; Section 3 ]
Sub-TLV Registry: No Sub-TLVs

Second, in the Return Codes registry in the Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters registry group located at:

https://www.iana.org/assignments/mpls-lsp-ping-parameters/

a single early allocation is to be made permanent and its reference changed to [ RFC-to-be ] as follows:

Value: 36
Meaning: Replying router is an egress for the prefix in EGRESS-TLV
Reference: [ RFC-to-be; Section 4.2 ]

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2024-05-17):

From: The IESG
To: IETF-Announce
CC: draft-ietf-mpls-egress-tlv-for-nil-fec@ietf.org, james.n.guichard@futurewei.com, mpls-chairs@ietf.org, mpls@ietf.org, tsaad.net@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Egress Validation in Label Switched Path Ping and Traceroute Mechanisms) to Proposed Standard


The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document: - 'Egress Validation in Label
Switched Path Ping and Traceroute
  Mechanisms'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2024-05-17. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  The MPLS ping and traceroute mechanism as described in RFC 8029 and
  related extensions for Segment Routing(SR) as defined in RFC 8287 is
  very useful to validate the control plane and data plane
  synchronization.  In some environments, only some intermediate or
  transit nodes may have been upgraded to support these validation
  procedures.  A simple MPLS ping and traceroute mechanism allows
  traversing any path without validating the control plane state.  RFC
  8029 supports this mechanism with Nil Forwarding Equivalence Class
  (FEC).  The procedures described in RFC 8029 mostly apply when the
  Nil FEC is used as an intermediate FEC in the label stack.  When all
  labels in the label stack are represented using Nil FEC, it poses
  some challenges.

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





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-mpls-egress-tlv-for-nil-fec/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/5656/

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?
[Ans]: The WG consensus represents broad agreement.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?
[Ans]: No.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)
[Ans]: No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?
[Ans]:An Implementations Status was added in Section 8 of the document.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.
[Ans]: no, the contents propose extensions to procedures of Nil FEC described in RFC8029.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
[Ans]: Yes, MPLS review team members reviewed before adoption by the WG.
Further early reviews by the RTGDIR members and all comments have been addressed.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?
[Ans]: Document does not contain a YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.
[Ans]: not applicable.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?
[Ans]: The document has useful extensions to procedures described in RFC8029 when using Nil FEC.
It proposes the addition of a new Egress TLV that contains the egress information along
with the FEC Stack TLV with the Nil FEC to help in validating the Nil-FEC on the receiving
router.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?
[Ans]: The RTG-DIR was engaged to perform early review.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?
[Ans]: Proposed Standard.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.
[Ans]: A first IPR poll was done before adoption of the document. A second IPR
poll was done before WGLC. There following IPR is disclosed against this document:
https://datatracker.ietf.org/ipr/5656/

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.
[Ans]: Currently, the document has 5 authors at the front page.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)
[Ans]: No Nits warnings or errors exist in the current state.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
[Ans]: None identified.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?
[Ans]: None.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.
[Ans]: None.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?
[Ans]: None.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.
[Ans]: No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).
[Ans]:

The IANA considerations section of the document contains a request for two allocations as
follows (see also
https://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-parameters.txt):

1. [IANA] has assigned an early allocation from the TLVs Sub-Registry of optional TLVs range
(range of TLVs that can be silently dropped if not recognized) on 2023-10-05:

    Value Description Reference
    32771 Egress TLV Section 3 of this document

A prior allocation for the same  above TLV was deprecated as it came from the range of
non-optional TLVs (range for TLVs that require an error message if not recognized]).
The prior allocation is currently marked as DEPRECATED in IANA's table.

    28      EGRESS TLV  [draft-ietf-mpls-egress-tlv-for-nil-fec-01] No Sub-TLVs
            (DEPRECATED)

2.  [IANA] has assigned an early allocation for the Return Code for
"Replying router is an egress for the prefix in Egress TLV" in the "Multi-Protocol Label
Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" in "Return Codes"
sub-registry.


  Value Description Reference
  36     Replying router is an egress for the prefix in Egress TLV for the FEC
            at stack depth RSC


21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.
[Ans]: None.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]:
https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?
[Ans]: The WG consensus represents broad agreement.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?
[Ans]: No.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)
[Ans]: No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?
[Ans]:An Implementations Status was added in Section 8 of the document.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.
[Ans]: no, the contents propose extensions to procedures of Nil FEC described in RFC8029.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
[Ans]: Yes, MPLS review team members reviewed before adoption by the WG.
Further early reviews by the RTGDIR members and all comments have been addressed.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?
[Ans]: Document does not contain a YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.
[Ans]: not applicable.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?
[Ans]: The document has useful extensions to procedures described in RFC8029 when using Nil FEC.
It proposes the addition of a new Egress TLV that contains the egress information along
with the FEC Stack TLV with the Nil FEC to help in validating the Nil-FEC on the receiving
router.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?
[Ans]: The RTG-DIR was engaged to perform early review.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?
[Ans]: Proposed Standard.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.
[Ans]: A first IPR poll was done before adoption of the document. A second IPR
poll was done before WGLC. There following IPR is disclosed against this document:
https://datatracker.ietf.org/ipr/5656/

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.
[Ans]: Currently, the document has 5 authors at the front page.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)
[Ans]: No Nits warnings or errors exist in the current state.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
[Ans]: None identified.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?
[Ans]: None.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.
[Ans]: None.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?
[Ans]: None.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.
[Ans]: No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).
[Ans]:

The IANA considerations section of the document contains a request for two allocations as
follows (see also
https://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-parameters.txt):

1. [IANA] has assigned an early allocation from the TLVs Sub-Registry of optional TLVs range
(range of TLVs that can be silently dropped if not recognized) on 2023-10-05:

    Value Description Reference
    32771 Egress TLV Section 3 of this document

A prior allocation for the same  above TLV was deprecated as it came from the range of
non-optional TLVs (range for TLVs that require an error message if not recognized]).
The prior allocation is currently marked as DEPRECATED in IANA's table.

    28      EGRESS TLV  [draft-ietf-mpls-egress-tlv-for-nil-fec-01] No Sub-TLVs
            (DEPRECATED)

2.  [IANA] has assigned an early allocation for the Return Code for
"Replying router is an egress for the prefix in Egress TLV" in the "Multi-Protocol Label
Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" in "Return Codes"
sub-registry.


  Value Description Reference
  36     Replying router is an egress for the prefix in Egress TLV for the FEC
            at stack depth RSC


21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.
[Ans]: None.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]:
https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/