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

[[e-mail]]

Dear authors, chairs and secretary,

I was selected to review this document. The following are my comments, which are only based on my current understanding. If there are any mistakes, please forgive and correct me.

1) I agree with the problem background described in section "2. Problem with nil FEC", the challenges and risks brought by using Nil FEC in some scenarios. For example, when SR policy is manually configured (or distributed by BGP) and segment type is specified as label type, the headend does not know the detailed FEC information for each segment. At this time, we can choose to include Nil FEC in the FEC stack of echo request. IMO, No matter which layer of FEC stack a Nil FEC is placed, it means that we lose the FEC Validation for this layer, that is, we can not determine whether the node to which an echo request packet arrives is the expected transit node or egress node of MPLS LSP.

2) Therefore, I think the egress TLV introduced in this document only has positive significance for PING mode, but has little significance for TRACEROUTE mode. According to RFC8029, PING mode is used to detect that the packets reache the expected egress node, while TRACEROUTE mode is in addition used to detect that the packets reache the expected transit node. It seems that, in the last sentence of section 2, the expression is inaccurate. In fact, there is no benefit to the processing of transit nodes.

3) If we focus on the benefits of egress TLV for PING mode, it seems that we can achieve the same effect by using the existing generic IP prefix FEC, which can be used to determine whether the PING packets have reached the desired destination node. This may be the necessary to consider the introduction of egress TLV in this document, that is, "Nil FEC + egress TLV" compared with "generic IP prefix FEC", provides the ability that the latter can not provide? Of course, these two options can coexist. If Nil FEC is selected, then the egress TLV is very useful.

4) According to RFC8287, PING mode can only contain a single Nil FEC corresponding to last segment, while TRACEROUTE mode must contain Nil FEC corresponding to each segment. Therefore, I am a little confused that the TRACEROUTE mode described in section "4.1.  Sending Egress TLV in MPLS Echo Request" in this document only contains a single Nil FEC. Can authors indicate me which document you refer to? Although, the number of elements in FEC stack (for example, only a single Nil FEC) may be inconsistent with the number of elements in DDMAP label stack (for example, including the whole outgoing label stack corresponding to SID list), the traceroute processing described in  RFC8029 does support this situation. My worry is that it will bring risks related with the transit node's reply of FEC change. In this case, it seems that FEC change can not be replied from the transit node, or the FEC change replies from the transit node needs to be ignored on the initiator node, otherwise th
 e subsequent FEC validation will be wrong. This need to supplement and further clarify the processing. 
For example, according to RFC8287, when the transit segment node replies the FEC change POP prefix-SID, how does the initiator handle it? Will the single Nil FEC be removed from the FEC stack? When the transit node replies to FEC change PUSH (for example, prefix SID enters the outer RSVP-TE forwarding adjacency), how does the initiator handle it? Will RSVP FEC be added to the FEC stack? This issue seems to also exist in non segment routing case, such as traceroute a BGP LU LSP, assuming LU over LDP, but the initiator only inserts a single BGP-LU FEC in the FEC stack. When the echo request packet arrives at a transit node of LDP LSP, it found that it need to enter an outer uniform RSVP-TE LSP. At this time, if the transit node replys FEC change PUSH RSVP FEC, it will bring risk, because the FEC stack of the next echo request is <BGP, RSVP>, while the label stack of DDMAP is < BGP, LDP, RSVP >, I doubt whether the subsequent reply of "IS egress" of TE LSP can successfully remov
 e the RSVP FEC element from the FEC stack.

5) Others:
    There is a spelling error in the example, egress router R3 should be changed to R7.

My conclusion: In Ping mode, egress TLV is useful to be combined with Nil FEC. It offers an alternative to generic IP prefix FEC.

Regards,
PSF