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

["Nagendra Kumar Nainar (naikumar)" <[e-mail]>]

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