Last Call Review of draft-ietf-mpls-egress-tlv-for-nil-fec-13
review-ietf-mpls-egress-tlv-for-nil-fec-13-opsdir-lc-qu-2024-05-20-00

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in the last call may be
included in AD reviews during the IESG review.  Document editors and WG chairs
should treat these comments just like any other last-call comments.

The document is almost ready for publication. However I believe that some
refinement in the language will significantly enhance the document's
readability.

For example, I tried some editorial work with the Abstract, and I'll leave this
to the authors and RFC editor.
"
The MPLS ping and traceroute mechanism outlined in RFC 8029, along with
associated extensions for Segment Routing (SR) as detailed in RFC 8287, serve
as valuable tools for verifying control plane and data plane synchronization.
However, in certain environments, not all intermediate or transit nodes support
these validation procedures. A straightforward MPLS ping and traceroute
mechanism enables traversal of any path without validating the control plane
state. RFC 8029 facilitates this mechanism through Nil Forwarding Equivalence
Class (FEC). However, challenges arise when all labels in the label stack
utilize Nil FEC.

This document presents a novel Type-Length-Value (TLV) as an extension to the
existing Nil FEC. It outlines MPLS ping and traceroute procedures utilizing Nil
FEC with this extension to effectively overcome these challenges. "

There are a few nits that should be fixed:

32         extension to exisiting Nil FEC.  It describes MPLS ping and
nits: s/exisiting/existing

122        Mutiple Paths (ECMP) and validate each of the ECMP paths.  The use of
s/Mutiple/Multiple

188        used for Egress TLV is from the range 32768-65535 and can can be
nits: duplicate "can"

189        silently dropped if not recognised as per [RFC8029] and as per
s/recognised/recognized