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

[Deepti Rathi <[e-mail]>]

Thanks Shaofu.
I have posted the new version of draft taking care of all the review comments.

Regards,
Deepti

Juniper Business Use Only

-----Original Message-----
From: [e-mail] <[e-mail]> 
Sent: Monday, June 28, 2021 4:46 PM
To: Deepti Rathi <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re:MPLS-RT review for draft-rathi-mpls-egress-tlv-for-nil-fec

[External Email. Be cautious of content]


Hi Deepti,

Thanks for your reply. I have no more questions.

Regards,
PSF


------------------原始邮件------------------
发件人：DeeptiRathi
收件人：彭少富10053815;
抄送人：[e-mail];[e-mail];[e-mail];[e-mail];
日 期 ：2021年06月28日 17:58
主 题 ：RE: Re:MPLS-RT review for draft-rathi-mpls-egress-tlv-for-nil-fec
Hi Shaofu,
Please see inline with tag "[[Deepti]]".
Soon will update the draft with all these needed info.
Regards,
Deepti
Juniper Business Use Only
-----Original Message-----
From: [e-mail] <[e-mail]>
Sent: Thursday, June 24, 2021 2:29 PM
To: Deepti Rathi <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re:MPLS-RT review for draft-rathi-mpls-egress-tlv-for-nil-fec
[External Email. Be cautious of content] Hi Deepti, Sorry that not reply in time due to other delays.
Please see inline [PSF]
Regards,
PSF
------------------原始邮件------------------
发件人：DeeptiRathi
收件人：彭少富10053815;
抄送人：[e-mail];[e-mail];[e-mail];[e-mail];
日 期 ：2021年06月17日 22:19
主 题 ：Re: MPLS-RT review for draft-rathi-mpls-egress-tlv-for-nil-fec
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.
[PSF] Thanks, the clarification is benefit for developers to implement this function. For the clarification itself, however, I may have different understanding of section 4.4.1 of RFC8029 from yours. IMO, section 4.4.1 of RFC8029 is a sub-function called by transit processing (see 4.  Label Operation Check) or egress processing (see 5.  Egress Processing). For example, during egress processing, this sub-function may be called multiple times. The annotation "If the outermost FEC of the Target FEC stack is the Nil FEC, then the node MUST skip the Target FEC validation completely." in this sub-function may means, if I understand correctly, just skip FEC checking for current Label-L and the FEC at FEC-stack-depth, but not break the parent processing and stop to check the next label and FEC element (if they all exist). So that if we use a single Nil FEC for complete label stack, no validation will be performed on any transit node just because of no FEC element in FEC-stack-depth,
  but not because of the above annotation. Right ?
[[Deepti]] Yes.
>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.
[PSF] Agree. Nil FEC has a little more scenarios than generic IP prefix FEC can apply, even though they are all designed for incomplete scenes. For example, if the last label is adj-sid, we can still use Nil FEC but not generic IP prefix FEC.
>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, otherwi
se 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.
[PSF]  My doubts are the same as above, i.e., the above annotation may be to say that FEC checking for the current Label-L and the FEC at FEC-stack-depth is skipped completely, but not the entire FEC stack. And, according to 4.5.1 or 4.5.2 of RFC8029, it seems that FEC stack change is enclosed in echo reply message without dependency on FEC validation skipped or successfully checked. If that is true, for traceroute mode, a single Nil FEC may bring risks. Hope to see the updated version to give readers more information for this risk.
[[Deepti]] This single NIL FEC based traceroute is being proposed mostly for SR-TE paths especially when labels such as static/LSP label, Binding-SID, EPE-SID etc are used in label stack.
It may not be possible to derive the FEC of these labels (non-IGP labels) on the headend of the router when the SR-TE path is created by the controller.
In such situations, Nil FEC based traceroute will help to trace the path.
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