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

[Deepti Rathi <[e-mail]>]

Hi Shaofu,
Please find my comments inline.
I will update draft accordingly.

Regards,
Deepti


Juniper Business Use Only

-----Original Message-----
From: [e-mail] <[e-mail]>
Sent: Friday, June 11, 2021 6:02 PM
To: [e-mail]; [e-mail]; [e-mail]
Cc: [e-mail]
Subject: MPLS-RT review for draft-rathi-mpls-egress-tlv-for-nil-fec

[External Email. Be cautious of content]


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.
[Deepti]:Yes, its as describe in section 4.4.1 of RFC8029 :
...
  If the outermost FEC of the Target FEC stack is the Nil FEC, then the
  node MUST skip the Target FEC validation completely.
...

In RFC 8029 assumes there are other FECs along with NIL-FEC in the target FEC-stack. This draft uses single NIL FEC for complete label stack. So no validation will be performed on any transit node and adding EGRESS TLV a minimal validation is provided at egress. Thus it can be used to check any combination of segments on any path without upgrading transit nodes.

I will update abstract and introduction to make it clear that document uses single NIL FEC for complete label stack.

>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.
[Deepti] RFC 8029 traceroute procedure validates the FEC on each transit node.
Procedure describe in this draft using NIL FEC + EGRESS TLV, does not validate the transit path.
Every visited transit node in the path gets  reported on ingress node. This information can be used by offline application to validate the traceroute path.


>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.
[Deepti]: Yes, both FEC can co-exists.
The generic IPv4 and IPv6 prefix sub-TLVs are used when the protocol that is advertising the label is unknown. For these sub-TLVs the information that is carried is the IPv4 or IPv6 prefix and prefix length. Thus Generic FEC types perform an additional control plane validation. The details of generic FEC and validation procedures are not very detailed in the RFC 8029.The use-case mostly specifies inter-AS VPNs as the motivation.
NIL FEC is used to traverse the path without validation for cases where the FEC is not defined or routers are not upgraded to support the new FECs (like newer features, explicit-null, router-alert etc).
Thus it can be used to check any combination of segments on any data path which cant be said for generic FEC.
Certain aspects of Segment Routing such as anycast SIDs required clear guideline on how the validation procedure should work.
Also Generic FEC may not be widely supported and if transit routers are not upgraded to support validation of generic FEC, traceroute may fail.
So instead of adding such clarifications to generic FEC, adding new EGRESS TLV in Nil FEC was better option with minimal Its an optional TLV so the procedures will work fine even if transit routers are not upgraded.
While we clearly specify the processing of egress tlv so that all SR cases are well specified.
Since explicit Path can be created using node-sid, adj-sid, binding-sid, anycast-sids etc. EGRESS TLV prefix will be derived from path egress/destination and not based on labels used in the path to reach the destination.

I will update same in draft.

>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.
[Deepti]
As describe in section 4.4.1 of RFC8029 :
...
  If the outermost FEC of the Target FEC stack is the Nil FEC, then the
  node MUST skip the Target FEC validation completely.
...

In RFC 8029 assumes there are other FECs along with NIL-FEC in the target FEC-stack.
This draft uses single NIL FEC for complete label stack which will get removed only at egress and hence FEC validation will be skipped over complete path.
So ingress/initiator will never get FEC-stack change.

I will update draft with this information to make it clear.

5) Others:
    There is a spelling error in the example, egress router R3 should be changed to R7.
[Deepti] I will update the draft for all these errors.

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