[mpls] MPLS-RT review for draft-rathi-mpls-egress-tlv-for-nil-fec

[Italo Busi <[e-mail]>]

Hi all,
I have been selected as one of the  MPLS-RT reviewers of draft-rathi-mpls-egress-tlv-for-nil-fec-04

IMHO, being able to use LSP Ping/Traceroute perform to validate only the data path and not the control plane state makes sense but I think that the draft requires more information about the problem that it is trying to address and why existing solutions are not suitable

Let me try to clarify my confusion after having read the draft
Unless I am missing something, section 4.4.1 of RFC8029 already provides support for checking only the data path and not the control plane state:

   If the outermost FEC of the Target FEC stack is the Nil FEC, then the
   node MUST skip the Target FEC validation completely.

The draft mention some challenges with the current definition, but it seems describing only one potential issue:

   ... When router in the label-stack path
   receives MPLS ping/traceroute packets, there is no definite way to
   decide on whether its egress or transit since Nil FEC does not carry
   any information.

However, I am not sure about this issue: looking at the example in the draft, my understanding is that R7 will reply with code 3 while, in traceroute, the intermediate nodes will reply with code 8.

Reading the procedure in section 4.2, I am wondering whether the real intention is to be able to validate the prefix X in R7, rather than the SR path toward R7.

However, in this case, it is not clear why using a FEC for the prefix X instead of the Nil FEC is not suitable.

I also think that section 5 requires more details about how backward compatibility is achieved. What is the behavior of a node that does not support this solution when it receives the EGRESS TLV?

Italo