Re: [mpls] some problems of pseudo-code in RFC8029

<peng.shaofu@zte.com.cn> Fri, 24 May 2019 08:17 UTC

Return-Path: <peng.shaofu@zte.com.cn>
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 09CB11202BE for <mpls@ietfa.amsl.com>; Fri, 24 May 2019 01:17:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 Pnvc2ax3wEcz for <mpls@ietfa.amsl.com>; Fri, 24 May 2019 01:17:07 -0700 (PDT)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 044CE1202BC for <mpls@ietf.org>; Fri, 24 May 2019 01:17:05 -0700 (PDT)
Received: from mxct.zte.com.cn (unknown [192.168.164.217]) by Forcepoint Email with ESMTPS id A07F132E22532B231765 for <mpls@ietf.org>; Fri, 24 May 2019 16:17:03 +0800 (CST)
Received: from mse-fl2.zte.com.cn (unknown [10.30.14.239]) by Forcepoint Email with ESMTPS id 983B3346D20022EC38E5; Fri, 24 May 2019 16:17:03 +0800 (CST)
Received: from njxapp05.zte.com.cn ([10.41.132.204]) by mse-fl2.zte.com.cn with SMTP id x4O8Gplg027939; Fri, 24 May 2019 16:16:51 +0800 (GMT-8) (envelope-from peng.shaofu@zte.com.cn)
Received: from mapi (njxapp01[null]) by mapi (Zmail) with MAPI id mid201; Fri, 24 May 2019 16:16:50 +0800 (CST)
Date: Fri, 24 May 2019 16:16:50 +0800 (CST)
X-Zmail-TransId: 2af95ce7a8723a047b6f
X-Mailer: Zmail v1.0
Message-ID: <201905241616506657718@zte.com.cn>
In-Reply-To: <CE1A1804-DC7B-461D-A06B-D3B73B578161@cisco.com>
References: 201905231755051639122@zte.com.cn, CE1A1804-DC7B-461D-A06B-D3B73B578161@cisco.com
Mime-Version: 1.0
From: <peng.shaofu@zte.com.cn>
To: <naikumar@cisco.com>
Cc: <cpignata@cisco.com>, <mpls@ietf.org>
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl2.zte.com.cn x4O8Gplg027939
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/IEbOm6dKyRT2May7RQeRDXH_CPQ>
Subject: Re: [mpls] =?utf-8?q?some_problems_of_pseudo-code_in_RFC8029?=
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 May 2019 08:17:10 -0000

Hi Nagendra






Thanks for your response.






For the problem 1,  the machinery is exactly OK when MPLS PHP enabled, however implementions have to consider non-PHP case and supplement related executions because PHP is just optional. Of couse the pseudo-code is a good guidline and direction for implemention, it is trivial and unreasonable to cover any detailed cases. In short, I have no doubt again under PHP precondition.


IMO, SR-MPLS segment list would be an non-PHP example, it is higher probability for each prefix segment without PHP set than traditional MPLS, especially other type segment such as path segment. However this concerns would be discussed in RFC8287[SR-PING] or other document. In RFC8287 there are no discussion about this, it also focus on PHP condition in keeping with RFC8029. 






Thanks







原始邮件



发件人:NagendraKumarNainar(naikumar) <naikumar@cisco.com>
收件人:彭少富10053815;Carlos Pignataro(cpignata) <cpignata@cisco.com>om>;
抄送人:mpls@ietf.org <mpls@ietf.org>rg>;
日 期 :2019年05月23日 23:23
主 题 :Re: [mpls] some problems of pseudo-code in RFC8029




Hi Peng,


Please see below..

Hi, Carlos and other authors

 

I found there are some problems of pseudo-code given in section 4.4, such as:

 

4. Label Operation Check

***problem 1***

see the first case: If the label operation is "Pop and Continue Processing" 

the excecution of this case will ignore Egress FEC Validation of any new added tunnel.

<Nagendra> “Pop and Continue” is used for RA-Label or exp-null labels. When there is a transit tunnel (stitching or hierarchical), the egress of the transit tunnel normally uses imp-null (or exp-null).  AFAIK non reserved label will be used only when there is a need for context identifier (like P2MP cases). When imp-null or exp-null is used, I think the current machinery takes care of the validation. If it is a different case, can you help explain the problem  with an example?.

 

***problem 2***

Please search "If the Return Code is 1", would it need to be changed to "If FEC-status is 1" ?

<Nagendra> Yes, it should be “FEC-Status”.

 

6. Egress FEC Validation

***problem 3***

Why not worry about the Label_L and FEC maybe extracted from inconsistent layer here? That is, why not use stack-D to ensure consistent layer, as stack-D include complete labels but stack-R not.

<Nagendra> DDMAP is optional and is not included normally in a ping. Relying on stack-D alone may break or have backward compatible issues.

 

Thanks,

Nagendra