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

[Joel Halpern <[e-mail]>]

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]>
> *Sent:* Monday, September 8, 2025 8:01 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
>
> 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]> 
> 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]> 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]> 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]
>                     <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]> 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 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]
>                         <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
>                         <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]
>
>
> _______________________________________________
> mpls mailing list [e-mail]
> To unsubscribe send an email [e-mail]