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

From: <[email-masked]>
Date: Thu, 23 May 2019 17:55:05 +0800 (CST)

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

---

From: "Nagendra Kumar Nainar (naikumar)" <[email-masked]>
Date: Thu, 23 May 2019 15:24:28 +0000

Hi Peng,
Please see below..

4. Label Operation Check

***problem 1***

<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***

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

6. Egress FEC Validation

***problem 3***

<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

---

From: <[email-masked]>
Date: Fri, 24 May 2019 16:16:50 +0800 (CST)

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) <[email-masked]>
收件人：彭少富10053815;Carlos Pignataro(cpignata) <[email-masked]>;
抄送人：[email-masked] <[email-masked]>;
日 期 ：2019年05月23日 23:23
主 题 ：Re: [mpls] some problems of pseudo-code in RFC8029

Hi Peng,

Please see below..

4. Label Operation Check

***problem 1***

***problem 2***

6. Egress FEC Validation

***problem 3***

Thanks,

Nagendra