IETF Logo Mail Archive

[mpls] some problems of pseudo-code in RFC8029

<peng.shaofu@zte.com.cn> Thu, 23 May 2019 09:55 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 2F5701200D6 for <mpls@ietfa.amsl.com>; Thu, 23 May 2019 02:55:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 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] 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 7gsshF0kvmQx for <mpls@ietfa.amsl.com>; Thu, 23 May 2019 02:55:26 -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 20A3012008B for <mpls@ietf.org>; Thu, 23 May 2019 02:55:25 -0700 (PDT)
Received: from mxct.zte.com.cn (unknown [192.168.164.215]) by Forcepoint Email with ESMTPS id B0C9E3B7303AED51B287 for <mpls@ietf.org>; Thu, 23 May 2019 17:55:23 +0800 (CST)
Received: from mse-fl2.zte.com.cn (unknown [10.30.14.239]) by Forcepoint Email with ESMTPS id 9C61E8A3B0A2A843E165; Thu, 23 May 2019 17:55:23 +0800 (CST)
Received: from njxapp05.zte.com.cn ([10.41.132.204]) by mse-fl2.zte.com.cn with SMTP id x4N9t54M013388; Thu, 23 May 2019 17:55:05 +0800 (GMT-8) (envelope-from peng.shaofu@zte.com.cn)
Received: from mapi (njxapp01[null]) by mapi (Zmail) with MAPI id mid201; Thu, 23 May 2019 17:55:05 +0800 (CST)
Date: Thu, 23 May 2019 17:55:05 +0800
X-Zmail-TransId: 2af95ce66df981192392
X-Mailer: Zmail v1.0
Message-ID: <201905231755051639122@zte.com.cn>
Mime-Version: 1.0
From: peng.shaofu@zte.com.cn
To: cpignata@cisco.com
Cc: mpls@ietf.org
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl2.zte.com.cn x4N9t54M013388
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/IPZHpuiGf1j-YKQBgdLVv6-7pfA>
Subject: [mpls] 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: Thu, 23 May 2019 09:55:28 -0000

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.






***problem 2***


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






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.






Thanks

v2.23.0 | Report a Bug | By Email