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

[Rakesh Gandhi <[e-mail]>]

Thanks Jie for your review comments.

Please see replies with <RG>...


On Thu, Sep 4, 2025 at 2:34 AM Dongjie (Jimmy) <[e-mail]> wrote:

> Hi Rakesh,
>
>
>
> Thanks for your response and the proposed changes.
>
>
>
> Please find further replies inline:
>
>
>
>
>
> *From:* Rakesh Gandhi <[e-mail]>
> *Sent:* Tuesday, September 2, 2025 8:05 PM
> *To:* Dongjie (Jimmy) <[e-mail]>
> *Cc:* Greg Mirsky <[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
>
>
>
> Hi Jie,
>
>
>
> Thanks for your review comments.
>
>
>
> I looked at the email thread, and RFC 6790 and we could add the following
> clarifications for the two points. Does this help?
>
>
>
> -------------------------
>   "The node behaviour, where an NAS with I2E and HBH scopes is also
>    removed along with popping the forwarding label on a PHP node, is
>    outside the scope of this document."
>
> -------------------------
>
>
>
> [Jie] This is fine, then it requires that for I2E and HBH scoped NAS, the
> egress node MUST be MNA capable. It also leaves this behavior to be defined
> in a future document.
>

<RG> Great, thanks!



>
>
>
>
>   "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.

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

<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


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]>
> 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]>
> *Sent:* Friday, August 29, 2025 6:38 AM
> *To:* Greg Mirsky <[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
>
>
>
> 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]>
> 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]>
> wrote:
>
> Hi Greg,
>
>
>
> Thanks for your reply, please find further inline:
>
>
>
>
>
> *From:* Greg Mirsky <[e-mail]>
> *Sent:* Thursday, August 28, 2025 4:21 AM
> *To:* Dongjie (Jimmy) <[e-mail]>
> *Cc:* Tarek Saad <[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
>
>
>
> 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]> 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]>
> *Sent:* Tuesday, August 12, 2025 7:20 PM
> *To:* mpls <[e-mail]>
> *Cc:* MPLS Working Chairs <[e-mail]>; draft-ietf-mpls-mna-hdr
> <[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 3
> rd 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])
>
> 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]
> To unsubscribe send an email to [e-mail]
>
> _______________________________________________
> mpls mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
>