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

<> Fri, 24 May 2019 08:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 09CB11202BE for <>; Fri, 24 May 2019 01:17:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.198
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Pnvc2ax3wEcz for <>; Fri, 24 May 2019 01:17:07 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 044CE1202BC for <>; Fri, 24 May 2019 01:17:05 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTPS id A07F132E22532B231765 for <>; Fri, 24 May 2019 16:17:03 +0800 (CST)
Received: from (unknown []) by Forcepoint Email with ESMTPS id 983B3346D20022EC38E5; Fri, 24 May 2019 16:17:03 +0800 (CST)
Received: from ([]) by with SMTP id x4O8Gplg027939; Fri, 24 May 2019 16:16:51 +0800 (GMT-8) (envelope-from
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
X-Zmail-TransId: 2af95ce7a8723a047b6f
X-Mailer: Zmail v1.0
Message-ID: <>
In-Reply-To: <>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: x4O8Gplg027939
Archived-At: <>
Subject: Re: [mpls] some problems of pseudo-code in RFC8029
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: 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. 



发件人:NagendraKumarNainar(naikumar) <>
收件人:彭少富10053815;Carlos Pignataro(cpignata) <>;
抄送人 <>;
日 期 :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.