[mpls] Re: Working Group Last Call for draft-ietf-mpls-mna-hdr

["Dongjie (Jimmy)" <[e-mail]>]

Hi Rakesh,

Thanks for your effort on updating the text.

While IMO the proposed text does not reflect the reality that the behavior in this case is unspecified in existing documents, and it would depend on the implementation of vendors.

Maybe a survey could help us to understand whether this is a problem or not?

At the same time, as there are multiple mechanisms (entropy, flow-id, MNA) which require the parsing of label stack for specific SPL, it would be helpful to have their interaction (including the interaction with XXX-incapable nodes) documented somewhere.

Best regards,
Jie

From: Rakesh Gandhi <[e-mail]>
Sent: Wednesday, September 10, 2025 7:58 PM
To: Joel Halpern <[e-mail]>
Cc: Dongjie (Jimmy) <[e-mail]>; mpls <[e-mail]>; MPLS Working Chairs <[e-mail]>; draft-ietf-mpls-mna-hdr <[e-mail]>
Subject: Re: [mpls] Re: Working Group Last Call for draft-ietf-mpls-mna-hdr

Thanks Joel and Jie for the discussions.

For my own understanding, in this case, the proposed text would be more like the following, right?

“Note that the behavior of an MNA-incapable
   transit LSR, that scans the label stack for ELI and EL, but
   encountering a different reserved label first that it does not recognize, is not modified by this document.”

P.S. Attached work in progress files for review.
Thanks,
Rakesh



On Tue, Sep 9, 2025 at 10:25 PM Joel Halpern <[e-mail]<mailto:[e-mail]>> wrote:

And suppose a packet with MNA and no ELI at all is processed by a node that looks for ELI.  By this logic, it would find the MNA, and discard the packet.  Since that would also mean it would discard the packet if it had any other unkown bSPL or eSPL, either there is no problem or this text doesn't help.

Personally, I am of the opinion that there is no problem.

Yours,

Joel
On 9/9/2025 10:03 PM, Dongjie (Jimmy) wrote:
Hi Rakesh,

Thanks for the proposed text, please find below a few changes to it:

“However, as the behaviour of an MNA-incapable
   transit LSR, that scans the label stack for ELI and EL,  but
   encountering the MNA reserved label first,  is not specified, it is
   RECOMMENDED that ELI/EL be placed before any MNA NAS (towards the top
   of the label stack) to avoid undesired behaviour.”

And

“However, as the
   behaviour of an MNA-incapable transit LSR, that scans the label stack
   for FLI (including the extension label 15) and FL, but encountering
   the MNA reserved label first, is not specified, it is RECOMMENDED
   that the FLI and FL be placed before any MNA NAS (towards the top of
   the label stack) to avoid undesired behaviour.”

Hope this helps.

Best regards,
Jie

From: Rakesh Gandhi <[e-mail]><mailto:[e-mail]>
Sent: Monday, September 8, 2025 8:01 PM
To: Dongjie (Jimmy) <[e-mail]><mailto:[e-mail]>
Cc: Greg Mirsky <[e-mail]><mailto:[e-mail]>; mpls <[e-mail]><mailto:[e-mail]>; MPLS Working Chairs <[e-mail]><mailto:[e-mail]>; draft-ietf-mpls-mna-hdr <[e-mail]><mailto:[e-mail]>
Subject: Re: [mpls] Re: Working Group Last Call for draft-ietf-mpls-mna-hdr

Thanks Jie for the discussions.

So that I understand correctly, you are suggesting adding text in the document, something like the following, right?

“However, as the behaviour of an MNA-incapable
   transit LSR, that scans the label stack for ELI and EL, is not
   specified, they can be placed before an MNA NAS (towards the top of
   the label stack) to avoid undesired behaviour.”

P.S. Attached work in progress files for review.
Thanks,
Rakesh




On Sat, Sep 6, 2025 at 12:12 AM Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>> wrote:
Hi Rakesh,

Thanks for the reply.

Let’s focus on the remaining item, please see my replies inline with [Jie-2]






  "If a transit LSR chooses to use as much of the whole
   label stack as feasible as keys for the load-balancing function, the
   MNA reserved label MUST NOT be used as a key for the load-balancing
   function, as specified in Section 4.3 of [RFC6790]."
-------------------------

[Jie] As specified in RFC 6790, the transit node may choose to use the whole label stack for load-balancing, alternatively it may choose to parse the label stack to find the ELI and only use the following EL for load balancing. Both of these two approaches need to be considered here.
And the potential problem I mentioned is with the second approach, as the behavior of a MNA-incapable transit node on encountering the MNA reserved label during the label stack parsing is unknown, and may cause the packet either sent to CPU or be discarded according to RFC 7325.


<RG> I think you are referring to the following text, right?

https://datatracker.ietf.org/doc/html/rfc7325#section-4.5

   "Unknown special-purpose labels and unknown extended special-purpose

   labels are handled the same.  When an unknown special-purpose label

   is encountered or a special purpose label not directly handled in

   forwarding hardware is encountered, the packet should be sent to a

   general-purpose CPU by default."

<RG> My understanding is that this behaviour is defined for the LSR where SPL or eSPL labels are exposed at the top of the stack.


[Jie-2] I hope so, while I cannot be sure, as the text is not clear about this. Section 2.4.4 of RFC 7325 says:

“The MPLS Entropy Label is capable of avoiding full label stack and
   payload inspection within the core where performance levels are most
   difficult to achieve (see Section 2.3<https://datatracker.ietf.org/doc/html/rfc7325#section-2.3>)  The label stack inspection
   can be terminated as soon as the first Entropy Label is encountered,
   which is generally after a small number of labels are inspected.”

[Jie-2] This specifies the behavior when the entropy label within the label stack is encountered. Thus other special purpose label can also be encountered in the label stack inspection.

[Jie-2] Section 2.4.5.1 provides the guidelines for use of MPLS fields in multipath load balancing, and the bullet 3 says:

3.  Special-purpose labels (label values 0-15) MUST NOT be used.
       Extended special-purpose labels (any label following label 15)
       MUST NOT be used.  In particular, GAL and RA MUST NOT be used so
       that OAM traffic follows the same path as payload packets with
       the same label stack.

[Jie-2] This indicates the bSPLs and eSPLs are not used for load balancing. While it does not mention when encountering the SPLs, whether their associated actions need to be performed or not.


<RG> If not true, none of the extensions using the SPL or eSPL, including the one recently defined in RFC 9714, can ever be deployed when a non-capable node on the path parses the entire stack, where SPL or eSPL labels are not exposed at the top of the stack on that node.

[Jie-2] So far only the entropy label processing optionally require the parsing of the label stack, and most of the existing SPLs are positioned at the bottom of stack, which means they will not be encountered before the ELI.

For SPLs which can be at other position in the label stack, their interaction with entropy label needs to be considered. As MNA introduces a new SPL which can be at any position in the label stack and also requires the parsing of the label stack,  it is important to specify the interaction with entropy label in the draft. As for backward compatibility, my suggestion is to have ELI/EL always closer to the top of stack than any NAS.


<RG> Here is an example from a recent RFC 9714 where a similar label stack with eSPL can be seen but no such behaviour is described.
https://www.rfc-editor.org/rfc/rfc9714.txt

                +----------------------+

                |          LSP         |

                |         Label        |

                +----------------------+ <--+

                |       Extension      |    |

                |         Label        |    |

                +----------------------+    |--- cSPL

                |     Flow-ID Label    |    |

                |       Indicator      |    |

                +----------------------+ <--+

                |        Flow-ID       |

                |         Label        |

                +----------------------+

                |      Application     |

                |         Label        |

                +----------------------+ <= Bottom of stack

                |                      |

                |        Payload       |

                |                      |

                +----------------------+



                Figure 2: Applying Flow-ID to MPLS Transport

[Jie-2]  Thanks for pointing to this example. As it requires to parse the label stack to find this eSPL/FLI, IMO the interaction between this eSPL/FLI, the entropy label and MNA also needs to be considered.



Thanks,

Rakesh


Best regards,
Jie


Attaching the work in progress diff file and draft.

Thanks,
Rakesh



On Sat, Aug 30, 2025 at 5:48 AM Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>> wrote:
Hi Rakesh,

Thanks for the update of the draft.

Please check my follow-up comments sent to the chairs in this thread, and let me know whether you will make further changes to this document.

As for the updates to section 11 Backward Compatibility, as discussed in my previous mail, an MNA-incapable node may parse the label stack to find the ELI/EL for load-balancing. What it will do when the MNA bSPL in the label stack is found before it reaches the ELI is unclear. Thus IMO the backward compatibility considerations need to cover this and not limit to the case where a packet with NAS at the top of stack reaches an MNA-incapable node.

Best regards,
Jie

From: Rakesh Gandhi <[e-mail]<mailto:[e-mail]>>
Sent: Friday, August 29, 2025 6:38 AM
To: Greg Mirsky <[e-mail]<mailto:[e-mail]>>
Cc: Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>; mpls <[e-mail]<mailto:[e-mail]>>; MPLS Working Chairs <[e-mail]<mailto:[e-mail]>>; draft-ietf-mpls-mna-hdr <[e-mail]<mailto:[e-mail]>>
Subject: Re: [mpls] Re: Working Group Last Call for draft-ietf-mpls-mna-hdr

Thank you Jie and Greg for the comments and discussions.

I am attaching a diff file with some minor text suggestions to improve the clarity (for the first two points).

At the sametime, fixing the neat suggested by Greg and updating the reference for LSP acronym for Adrian's comments.

Please review and advise your comments on these changes.

Thanks,
Rakesh (for authors)



On Thu, Aug 28, 2025 at 12:12 AM Greg Mirsky <[e-mail]<mailto:[e-mail]>> wrote:
Hi Jie,
thank you for your quick response. Please find my notes below tagged GIM2>>.

Regards,
Greg

On Wed, Aug 27, 2025 at 8:06 PM Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>> wrote:
Hi Greg,

Thanks for your reply, please find further inline:


From: Greg Mirsky <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, August 28, 2025 4:21 AM
To: Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>
Cc: Tarek Saad <[e-mail]<mailto:[e-mail]>>; mpls <[e-mail]<mailto:[e-mail]>>; MPLS Working Chairs <[e-mail]<mailto:[e-mail]>>; draft-ietf-mpls-mna-hdr <[e-mail]<mailto:[e-mail]>>
Subject: Re: [mpls] Re: Working Group Last Call for draft-ietf-mpls-mna-hdr

Hi Jie,
thank you for sharing your questions. Please find my thoughts below tagged GIM>>.

Regards,
Greg

On Tue, Aug 26, 2025 at 7:54 PM Dongjie (Jimmy) <jie.dong=[e-mail]<mailto:[e-mail]>> wrote:
Hi Tarek,

Sorry for the late response, I was out of office for a few days.

I’ve read the latest version of this document, and think there are a few remaining issues which need to be addressed before the document progresses further to the next step.


1.      Section 7 firstly says “the NAS MUST NOT appear at the top of the stack at any MNA incapable node on the path”, but then it says “A node performing Penultimate Hop Popping (PHP) that pops the forwarding label with only the NAS(es) remaining on the stack MUST NOT remove the NAS(es).”  If the penultimate node is MNA incapable, it seems these two sentences would conflict with each other?
GIM>> I read Section 7 and find it clear. The distinction between MNA-capable and MNA-incapable (nit, s/MNA incapable/MNA-incapable) LSRs in regard to processing NAS at the top of the MPLS label stack is called out. In my opinion, all cases when a node must dispose of or must not do that apply to MNA-capable LSR. If the penultimate node is MNA-incapable, the packet with NAS at the top will be dropped.

[Jie] The penultimate node can be either MNA-capable or MNA-incapable. According to the text in section 7, the penultimate node pops the forwarding label will find only NAS on the label stack. Do you mean if the penultimate node is MNA-incapable, it will always drop the packet? Is this the expected behavior?
GIM2>> A system that constructs the label stack, whether controller or the ingress LER, must have sufficient information about topology and capability of the path to the intended destination. The data plane cannot compensate for cases when there is no sufficient information in the control or management planes. So to answer your last question, yes, dropping a packet with the unknown label at the top of the label stack is the expected behavior.


 Secondly, if the penultimate node is MNA capable, is there any case that the penultimate node is required to remove the NAS on behalf of the egress node (for example, when the egress node is MNA incapable) ?
GIM>> If the MNA-incapable egress node receives a packet with NAS at the top, that packet must be dropped.

[Jie] Again packet drop may not be the expected behavior for packet forwarding. What I mean is, should we consider the case where an MNA-capable penultimate node pops both the forwarding label and the NAS on behalf of an MNA-incapable egress node?
GIM2>> The document is explicitly clear that NAS MUST NOT appear at the top of the label stack for an MNA-incapable node. If that requirement is violated, then dropping such a packet is the correct and expected behavior.




2.      Section 7 adds some description about the coexistence of ELI/EL and NAS, however it doesn’t specify the relative position of ELI/EL and NAS. If ELI/EL is closer to the top of stack than the NAS, they may cause the NAS too deep to be parsed by some nodes with smaller RLD.
GIM>> I believe that the following text in Section 7 sufficiently covers scenario you describe:
   When
   adding the Entropy Label Identifier (bSPL label 7) and Entropy Label
   as defined in [RFC6790], along with an NAS, the RLD MUST be
   considered for the placement of both.

[Jie] From the current text, it is not clear about the relative position of ELI/EL and NAS. Which one should be closer to the top of stack?
GIM2>> If NAS and EL/ELI are within RLD, why does the order matter? In my opinion, an intelligent implementation would handle such a situation.


While if the ELI/EL is below the NAS, a legacy node parsing the label stack for ELI/EL would find the MNA bSPL first and consider it as an unknown bSPL, then its behavior could be either sent the packet to control plane, drop or rate limit the packets according to RFC 7325.
GIM>> Could you please point to a specification where dropping a packet with unknown label not on top of the label stack is mandated?

[Jie] For the processing of entropy label, a transit LSR may parse the label stack for the ELI. What it would do when an unknown bSPL is found before the ELI is not fully specified in RFC 6790.

While RFC 7325 says:

“Unknown special-purpose labels and unknown extended special-purpose
   labels are handled the same.  When an unknown special-purpose label
   is encountered or a special purpose label not directly handled in
   forwarding hardware is encountered, the packet should be sent to a
   general-purpose CPU by default.  If this capability is supported,
   there must be an option to either drop or rate limit such packets
   based on the value of each special-purpose label.”

Thus the behavior is uncertain and can be anything of the above.
GIM2>> Thank you for the quote. I sense that we have different interpretations of "encountered". In my opinion, the text applies to when the bSPL or eSPL are at the top of the stack. Perhaps others will share their thoughts about that matter.



3.      The impact of MNA on MPLS label stack operation and packet forwarding needs to be analyzed, and some general rules on the operation need to be specified. For example, is it allowed to change the order of existing LSEs in a received MPLS packet? or it only allows to insert/prepend information to specific position in the label stack? Any new manipulation of label stack requires hardware support thus will not come for free. More importantly, some operation may have risk in causing forwarding loop or violating the intent of the ingress node. This concern is partially caused by the new actions introduced in draft-ihle-mpls-mna-stack-management-00, and it seems necessary for the MNA header draft to provide some general rules to guide the design of ISD/label stack related actions.
GIM>> I think that these are good questions for implementers and operators. AFAICS, they are outside the scope of the specification that defines apparatus and its basic operations.

[Jie] The actions described in draft-ihle-mpls-mna-stack-management can be seen as an example, and it indicates that the MNA header draft needs to be clear about the allowed label stack operations, or at least provide some rules or guidelines for the label stack related new actions.
GIM2>> Personally, I cannot see any dependency of this draft on draft-ihle-mpls-mna-stack-management. I find that 11 references to RLD in requirements or recommendations throughout the draft are sufficient to develop a future-proof implementation.

Best regards,
Jie


Best regards,
Jie

From: Tarek Saad <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, August 12, 2025 7:20 PM
To: mpls <[e-mail]<mailto:[e-mail]>>
Cc: MPLS Working Chairs <[e-mail]<mailto:[e-mail]>>; draft-ietf-mpls-mna-hdr <[e-mail]<mailto:[e-mail]>>
Subject: [mpls] Working Group Last Call for draft-ietf-mpls-mna-hdr

Dear WG,

This email starts a two-week Working Group last call for draft-ietf-mpls-mna-hdr<https://datatracker.ietf.org/doc/draft-ietf-mpls-mna-hdr/>. This is the 3rd WG last call for this document.

Please indicate your support or concern for this draft. If you are opposed to the progression of the draft to RFC, please articulate your concern. If you support it, please indicate that you have read the latest version, and it is ready for publication in your opinion. As always, review comments and nits are most welcome.

Please send your comments to the mpls WG mailing list ([e-mail]<mailto:[e-mail]>)
If necessary, comments may be unicasted to the WG chairs.

Note, currently there are 5 IPR disclosures against this document at https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-mpls-mna-hdr

This poll runs until August 26, 2025.

Thank you,
Tarek (as MPLS WG co-chair)
_______________________________________________
mpls mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
_______________________________________________
mpls mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>


_______________________________________________

mpls mailing list -- [e-mail]<mailto:[e-mail]>

To unsubscribe send an email to [e-mail]<mailto:[e-mail]>