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

[<[e-mail]>]

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) <[e-mail]>
收件人：彭少富10053815;Carlos Pignataro(cpignata) <[e-mail]>;
抄送人：[e-mail] <[e-mail]>;
日 期 ：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