From nobody Mon Jul 19 11:10:29 2021 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1B63A2C68; Mon, 19 Jul 2021 11:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8OhbzsOdMuv7; Mon, 19 Jul 2021 11:10:21 -0700 (PDT) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7426B3A2C42; Mon, 19 Jul 2021 11:10:21 -0700 (PDT) Received: from fraeml712-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4GT8mX3y1bz6FD1G; Tue, 20 Jul 2021 02:01:32 +0800 (CST) Received: from fraeml715-chm.china.huawei.com (10.206.15.34) by fraeml712-chm.china.huawei.com (10.206.15.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Mon, 19 Jul 2021 20:10:18 +0200 Received: from fraeml715-chm.china.huawei.com ([10.206.15.34]) by fraeml715-chm.china.huawei.com ([10.206.15.34]) with mapi id 15.01.2176.012; Mon, 19 Jul 2021 20:10:18 +0200 From: Italo Busi To: 'Deepti Rathi' CC: "draft-rathi-mpls-egress-tlv-for-nil-fec@ietf.org" , "mpls-chairs@ietf.org" , "mpls@ietf.org" Thread-Topic: MPLS-RT review for draft-rathi-mpls-egress-tlv-for-nil-fec Thread-Index: AddhI9L1yOOS4MxaRt24LmA/Qqe0iAAl+X+wAGq/JjAABL76EANyqPmgAuBg1mA= Date: Mon, 19 Jul 2021 18:10:18 +0000 Message-ID: <93cecf5e94e14269ac77127fdf7eee73@huawei.com> References: In-Reply-To: Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.80.177] Content-Type: multipart/alternative; boundary="_000_93cecf5e94e14269ac77127fdf7eee73huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [mpls] MPLS-RT review for draft-rathi-mpls-egress-tlv-for-nil-fec X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2021 18:10:27 -0000 --_000_93cecf5e94e14269ac77127fdf7eee73huaweicom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Deepti/co-authors, Thanks for having addressed my comment and my apologize for the late reply = (too busy with other topics in the last few weeks) It is now clear to me what is the problem you are trying to address and why= the existing solutions are not suitable, so the document is ready for WG a= doption I have a couple of comments which can be addressed as you prefer before or = after WG adoption and hopefully could help improving the clarify and the so= lution 1) I have been a bit confused by this text: > ... 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. I would propose the following rephrase: > ... When router in the label-stack path > receives MPLS ping/traceroute packets, there is no definite way to > decide on whether it is the intended egress router since Nil FEC does n= ot carry > any information. With a reference to your example, my understanding is that if the MPLS ping= /traceroute packet is mis-delivered to an incorrect destination (e.g., R8),= R8 will behave as R7 and set Best-return-code to 3. I do not think there is any issue if the packet arrives to an intermediate = node (e.g., R6) since R6 will set Best-return-code to 8. 2) With the current rules, the solution works if and only if all the e= gress routers are upgraded to support the EGRESS TLV. Otherwise, if the MPL= S ping/traceroute packet is mis-delivered to an incorrect destination that = does not support the EGRESS TLV, that egress router will behave as the inte= nded destination and set Best-return-code to 3. I am wondering whether a new return-code should be defined to report that t= he EGRESS TLV has been checked and validated. My 2 cents Italo From: Deepti Rathi [mailto:deeptir@juniper.net] Sent: luned=EC 5 luglio 2021 04:21 To: Deepti Rathi ; Italo Busi Cc: draft-rathi-mpls-egress-tlv-for-nil-fec@ietf.org; mpls-chairs@ietf.org;= mpls@ietf.org Subject: RE: MPLS-RT review for draft-rathi-mpls-egress-tlv-for-nil-fec Thanks Italo for the comments. I have posted the new version of draft taking care of all the review commen= ts. Regards, Deepti Juniper Business Use Only From: Deepti Rathi > Sent: Thursday, June 17, 2021 7:08 PM To: Italo Busi > Cc: draft-rathi-mpls-egress-tlv-for-nil-fec@ietf.org; mpls-chairs@ietf.org; mpls@ietf.org Subject: Re: MPLS-RT review for draft-rathi-mpls-egress-tlv-for-nil-fec Hi Italo, Please find my comments inline. I will update draft for: 1. why "NIL FEC + EGRESS TLV" and not Generic IPV4/IPV6 FEC. 2. Backward compatibility. Regards, Deepti Juniper Business Use Only From: mpls > On Behalf = Of Italo Busi Sent: Monday, June 14, 2021 7:26 PM To: 'mpls@ietf.org' > Subject: [mpls] MPLS-RT review for draft-rathi-mpls-egress-tlv-for-nil-fec [External Email. Be cautious of content] Hi all, I have been selected as one of the MPLS-RT reviewers of draft-rathi-mpls-e= gress-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 ad= dress and why existing solutions are not suitable [Deepti]: 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 (li= ke newer features, explicit-null, router-alert etc). But it is a very powerful tool to check any combination of segments on any = data path. Since it does not carry any information to identify the intended egress/des= tination, n Mis-forwarding of the packet is possible n Not possible to figure out mis-configuration of label stack But in any case it will always return success even though egress/destinatio= n is not the intended one which is not desired. To overcome this and to provide minimal validation, EGRESS TLV is added in = the packet. This will help to do egress/destination validation. NIL FEC processing will be same as defined in RFC 8029. This draft is for a= ddition of EGRESS TLV as extension to NIL FEC for path egress/destination v= alidation. >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 s= upport 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 seem= s 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 dra= ft, 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 inte= ntion 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 in= stead of the Nil FEC is not suitable. [Deepti]: The real intention is to reach the correct egress/destination nod= e. 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. Certain aspects of Segment Routing such as anycast SIDs required clear guid= eline 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, we went with new E= GRESS TLV in Nil FEC. Its an optional TLV so the procedures will work fine even if transit router= s 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, an= ycast-sids etc. EGRESS TLV prefix will be derived from path egress/destinat= ion and not based on labels used in the path to reach the destination. I will update introduction section of draft with this comparison. >>I also think that section 5 requires more details about how backward comp= atibility is achieved. What is the behavior of a node that does not support= this solution when it receives the EGRESS TLV? [Deepti]: Backward compatibility on egress-node: On egress/destination, it will ignore EGRESS TLV and use current NIL-FEC pr= ocedure with return code 3 but egress validation will not be done (same as = RFC 8029). So we wont know for sure if packet has reached the correct path = egress. Backward compatibility on transit-node: If the transit node doesn't support, it will use current NIL-FEC procedure = and send return code of 8. I will add section in draft for backward compatibility. Italo --_000_93cecf5e94e14269ac77127fdf7eee73huaweicom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Deepti/co-authors,<= o:p>

 

Thanks for having addr= essed my comment and my apologize for the late reply (too busy with other t= opics in the last few weeks)

 

It is now clear to me = what is the problem you are trying to address and why the existing solution= s are not suitable, so the document is ready for WG adoption

 

I have a couple of com= ments which can be addressed as you prefer before or after WG adoption and = hopefully could help improving the clarify and the solution

 

1)&= nbsp;     I have been a = bit confused by this text:

 

>   ... When router in the label= -stack path

>   receives MPLS ping/tracerout= e packets, there is no definite way to

>   decide on whether its egress= or transit since Nil FEC does not carry

>   any information.  =            

 

I would propose= the following rephrase:

 

>   ... When router in the label= -stack path

>   receives MPLS ping/tracerout= e packets, there is no definite way to

>   decide on whether it is the = intended egress router since Nil FEC does not carry

>   any information.

 

With a referenc= e to your example, my understanding is that if the MPLS ping/traceroute pac= ket is mis-delivered to an incorrect destination (e.g., R8), R8 will behave= as R7 and set Best-return-code to 3.

 

I do not think = there is any issue if the packet arrives to an intermediate node (e.g., R6)= since R6 will set Best-return-code to 8.

  &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;        

2)&= nbsp;     With the curre= nt rules, the solution works if and only if all the egress routers are upgr= aded to support the EGRESS TLV. Otherwise, if the MPLS ping/traceroute pack= et is mis-delivered to an incorrect destination that does not support the EGRESS TLV, that egress router will = behave as the intended destination and set Best-return-code to 3.

 

I am wondering = whether a new return-code should be defined to report that the  EGRESS= TLV has been checked and validated.

 

My 2 cents<= /span>

 

Italo

 

From: Deepti Rathi [mailto:deeptir@juniper.ne= t]
Sent: luned=EC 5 luglio 2021 04:21
To: Deepti Rathi <deeptir@juniper.net>; Italo Busi <Italo.B= usi@huawei.com>
Cc: draft-rathi-mpls-egress-tlv-for-nil-fec@ietf.org; mpls-chairs@ie= tf.org; mpls@ietf.org
Subject: RE: MPLS-RT review for draft-rathi-mpls-egress-tlv-for-nil-= fec

 

Thanks Italo for the comments.

I have posted the new version of draft taking car= e of all the review comments.

 

Regards,

Deepti

 

 

 

Juniper Business Use Only

From: Deepti Rathi <deeptir@juniper.net>
Sent: Thursday, June 17, 2021 7:08 PM
To: Italo Busi <Italo.Bu= si@huawei.com>
Cc: draft-rathi-mpls-egress-tlv-for-nil-fec@ietf.org; mpls-chairs@ietf.org; mpls@ietf.org
Subject: Re: MPLS-RT review for draft-rathi-mpls-egress-tlv-for-nil-= fec

 

 

Hi Italo,

Please find my comments inline.

I will update draft for:

  1. why “NIL FE= C + EGRESS TLV” and not Generic IPV4/IPV6 FEC.
    2. Backward compatibili= ty.

 

Regards,

Deepti

 

 

Juniper Business Use Only

From: mpls <mpls-bounces@ietf.org> On Behalf Of Italo Busi
Sent: Monday, June 14, 2021 7:26 PM
To: 'mpls@ietf.org' <mpls@ietf.o= rg>
Subject: [mpls] MPLS-RT review for draft-rathi-mpls-egress-tlv-for-n= il-fec

 

<= span style=3D"font-size:10.5pt;font-family:Lato;color:black">[External Emai= l. Be cautious of content]

 

Hi all,

 

I have been selected as one of the  MPLS-RT rev= iewers 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 make= s sense but I think that the draft requires more information about the prob= lem that >>it is trying to address and why existing solutions are not suitable

[Deepti]:

NIL FEC is used to traverse the path without validat= ion for cases where the FEC is not defined or routers are not upgraded to s= upport the new FECs (like newer features, explicit-null, router-alert etc).=

But it is a very powerful tool to check any combinat= ion of segments on any data path.

Since it does not carry any information to identify = the intended egress/destination,

n&nb= sp; Mis-forwarding of the packet is possible

n&nb= sp; Not possible to figure out mis-configuration= of label stack

But in any case it will always return success even t= hough egress/destination is not the intended one which is not desired.=

To overcome this and to provide minimal validation, = EGRESS TLV is added in the packet. This will help to do egress/destination = validation.

NIL FEC processing will be same as defined in RFC 80= 29. This draft is for addition of EGRESS TLV as extension to NIL FEC for pa= th egress/destination validation.

 

>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 th= e control plane state:

 

>  If the outermost FEC of the Target FEC st= ack is the Nil FEC, then the

> node MUST skip the Target FEC validation comple= tely.

 

>The draft mention some challenges with the curre= nt definition, but it seems describing only one potential issue:=

 

>   ... When router in the label-stack = path

>   receives MPLS ping/traceroute packe= ts, there is no definite way to

>   decide on whether its egress or tra= nsit 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 c= ode 3 while, in traceroute, the intermediate nodes will reply with code 8.<= o:p>

 

>Reading the procedure in section 4.2, I am wonde= ring whether the real intention is to be able to validate the prefix X in R= 7, 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.<= /p>

 

[Deepti]: The real intention is to reach the = correct egress/destination node.

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 m= otivation.

 

Certain aspects of Segment Routing such as anycast S= IDs 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, trac= eroute may fail.

So instead of adding such clarifications to generic = FEC, we went with new EGRESS TLV in Nil FEC.

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 tl= v so that all SR cases are well specified.

 

Since explicit path can be created using node-sid, a= dj-sid, binding-sid, anycast-sids etc. EGRESS TLV prefix will be derived fr= om path egress/destination and not based on labels used in the path to reac= h the destination.

 

I will update introduction section of draft with thi= s comparison.

 

>>I also think that section 5 requires more de= tails 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= ?

 

[Deepti]:

Backward compatibility on egress-node:

On egress/destination, it will ignore EGRESS TLV and= use current NIL-FEC procedure with return code 3 but egress validation wil= l not be done (same as RFC 8029). So we wont know for sure if packet has re= ached the correct path egress.

 

Backward compatibility on transit-node:

If the transit node doesn’t support, it will u= se current NIL-FEC procedure and send return code of 8.

 

I will add section in draft for backward compatibili= ty.

 

Italo

 

--_000_93cecf5e94e14269ac77127fdf7eee73huaweicom_--