[mpls] Re: A list of technical concerns with draft-ietf-mpls-mna-hdr-12

[Rakesh Gandhi <[e-mail]>]

Hello WG,

Based on the feedback received regarding the bit for the Version, as there
is no support for it, it is removed from the work-in-progress copy, as
attached.

Please let us know your further review comments.

We can upload this revision on Sunday July 20, when the datatracker reopens.

Thanks,
Rakesh


On Fri, Jul 11, 2025 at 7:18 PM Rakesh Gandhi <[e-mail]>
wrote:

> Hello MPLS WG,
>
> Have gone through the list of issues raised below and the email threads
> discussing these issues.
>
>
> Based on the discussions on the mailing list, propose to address these
> issues as responses below.
>
>
>
> Welcome further feedback and suggestions from the WG group on these
> responses.
>
>
> P.S. attaching the work in progress document with the proposed changes as
> well as addressing remaining comments from Bruno and Loa.
>
>
>
> Thanks,
>
> Rakesh
>
>
> On Tue, Apr 15, 2025 at 10:33 PM Dongjie (Jimmy) <jie.dong=
> [e-mail]> wrote:
>
>> Dear WG,
>>
>> During IETF 122 meeting, a group of people gathered and discussed the
>> technical concerns with draft-ietf-mpls-mna-hdr-12. After the IETF meeting,
>> there was further discussion on these issues and Loa has agreed to help
>> sorting it out as an issue list. It has not been put into the form of an
>> internet draft, while that can be done if the WG thinks there is value.
>>
>> Loa is currently having problem in connecting to the internet, and today
>> is the deadline (April 15, 2025) for sending the relevant documents as
>> indicated by the chairs. As a participant of this discussion, I'm helping
>> with sending the issue list below to MPLS WG for review and discussion.
>>
>> It is suggested that this issue list and the resolutions being tracked by
>> the WG.
>>
>> --------------------------- the issue list ----------------------
>>
>> List of Technical Concerns on MNA
>>
>> 1.  MNA Versioning
>>
>>     It has been stated that MNA versioning is needed.
>>
>>     There are obviously more one than way to solve this.  It has been
>>     said that it would be possible to use a separate eSPL for each
>>     version, but other ways have been proposed.
>>
>>     Versioning can obviously be done with an bSPL, but we can't use
>>     multiple bSPL (one for each version), since that would risk to
>>     deplete the available bSPL quickly.
>>
>>     Two obvious ways to solve the "version with bSPL" that have been
>>     suggested are:
>>
>>     *  (1) insert a version field in the NAS
>>
>>     *  (2) use an OpCode to indicate the version
>>
>>     *  (3) using two bit in the flag field to create a small version
>>        field
>>
>>     (1) and (2) can be viewed as suboptimal since adding a field to the
>>     NAS would consume available data bits, and using an OpCode first
>>     decreases the available number of OpCodes and secondly because
>>     OpCodes are used for something they were not intended for. It should
>>     also be noted that opcode cannot be used to indicate the change to the
>>     fixed fields of MNA LSE formats (e.g. NSAL or NAL).
>>
>>     (3) is probably a trade-off between the number of flags and how many
>>     flags we need, but there is no available flag in the MNA LSE format
>> B.
>>
>>     If an unknown OpCode is encountered it is not certain that in general
>>     should trigger the same response as an unknown version number.
>>
>>     There has also been opinions raised that versioning is not needed.
>>     Currently the argument against using versioning seem to that it has
>>     never been done in MPLS before.
>>
>>     If we decide that versioning is required, we can also see that there
>>     ways of doing it, regardless if the MNA Label is a bSPL or an eSPL.
>>
>>     Anyhow, we should not progress the drafts before deciding on
>>     versioning.
>>
>
>
> <RG> We propose to add a bit for version to define a new encoding in
> future. Does that help?
>
>
>
>     0                   1                   2                   3
>
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>    |   Opcode    |        12-bit Data    |*V*|R|IHS|S|  NASL |*U*| NAL |
>
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>    |   Opcode    |        16-bit Data            |S|4b Data|*U*| NAL |
>
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>
>
>
>>
>> 2.  Size of the Label Stack
>>
>>     It has been said that MNA (ISD) makes the label stack too big, That
>>     begs further questions, e.g. "How big is too big?"
>>
>>     Is knowing the RLD enough?  What happens when an ingress want to send
>>     a packet with the n+1 LSEs and the network wide RLD is n?  Can TE
>>     functions be used to find a path that allows a path with an RLD of
>>     n+1 or better.
>>
>>     Is the answer simply "Don't do it"?
>>
>>     The issue of "label stack growing too big" in the strict sense is an
>>     ISD problem, since PSD by definition is outside the MPLS Label Stack.
>>     However, that argument is weak since the amount of data is roughly
>>     the same.  This will matter most if mutable data is transported, in
>>     this case PSD is more efficient than ISD.
>>
>
>
> <RG> We do not see the draft needs any updates for this.
>
> <RG> If there is anything specific to be added, please propose some text.
>
> <RG> In any case, the PSD solution draft has been adopted as a WG document.
>
>
>
>
>>
>> 3.  Byte alignment
>>
>>     Aligning information fields with the message byte structure simplify
>>     both HW and SW.  Byte alignment is not strictly necessary.  However,
>>     where there are an option to choose between byte-aligned and non-byte-
>>     aligned, the option to maximize byte alignment should be preferred.
>>
>>     Encoding Ancillary Data into the MPLS Label stack as ISD, does not
>>     make an attempt to make the encoding byte aligned (see for example
>>     [I-D.ietf-mpls-mna-hdr] and [I-D.ietf-mpls-mna-ioam]).
>>
>>     Encoding Ancillary Data as PSD on the other hand is inherently byte
>>     aligned, (see for example [I-D.jags-mpls-ps-mna-hdr] and
>>     [I-D.ietf-mpls-mna-ioam]).
>>
>
>
> <RG> We propose some very minor tweak in the encoding to group logical
> fields in a nibble alignment (by moving the *U* bit).
>
>
>
> <RG> But the MPLS header itself is not byte aligned, as well as the
> placement of the S bit in the middle of an LSE, there is not much more we
> can do.
>
>
> <RG> In any case, WG has now adopted both ISD and PSD solutions for IOAM.
>
>
> <RG> Also, if there are suggestions to further align nibbles, please
> propose them.
>
>
>
>
>>
>> 4.  bSPL vs. eSPL
>>
>>     There has been a discussion whether we should use a bSPL or an eSPL
>>     as the MNA Label.  There pros and cons with both approaches.
>>
>>     *  a bSPL is for example just one LSE, while an eSPL is two, a bSPL
>>        would be slightly more transport efficient
>>
>>     *  if we use an eSPL we could simply encode versions using as a new
>>        eSPL
>>
>>     *  it would be interesting to measure if there are real difference
>>        between using an bSPL or an eSPL from a performance perspective
>>
>>     *  using an eSPL would allow us to use the eSPLs set aside for
>>        "Experimental Use", while keeping the same encoding format.
>>
>>     *  if we use eSPLs we could have one for packets that has only ISD,
>>        another for packets that only have PSD, and yet another for
>>        packets that have both, thus simplifying processing.
>>
>>     *  this list is certainly not exhaustive it should be possible to
>>        come up with further testable uses of bSPLs and ESPLs.
>>        Regardless if we choose to use a bSPL or an eSPL, that decision
>>        should be well motivated and taken before WGLC.
>>
>>
>
> <RG> As in reply for #1, V flag will allow us to have new MNA encoding(s),
> without needing a new bSPL in near future.
>
>
>
>
>> 5.  Breaking time-honored MPLS Forwarding
>>
>>     When MPLS was initially specified forwarding were done on the top
>>     label only, labels were organised into a label stack.  Three simple
>>     operations were defined to operate on the label stack - POP, PUSH and
>>     SWAP.
>>
>>     The key MNA documents (Requirements, Framework and the Header drafts)
>>     all allows for forwarding decisions based on additional information,
>>     e.g., Ancillary Data.  There might be a lot of impact from this, for
>>     example if the forwarding decision taken on Ancillary Data is
>>     different from what it would have been if it were taken on the top
>>     label and "entropy", this may break load sharing or even cause
>>     forwarding loop.
>>
>>     There are currently no clear specification in
>>     [I-D.ietf-mpls-mna-requirements], [I-D.ietf-mpls-mna-fwk] or
>>     [I-D.ietf-mpls-mna-hdr] on whether whether MNA can or cannot impact
>>     the decision on next-hop.  However this is clearly implied in all
>>     three documents.
>>
>>     There might be several rules on how MNA information that take over
>>     how the forwarding decision is taken, may be inserted into the label
>>     stack.
>>
>>     For example if one packet in a stream includes a NA that impacts the
>>     forwarding decision, all other packets in that stream also need to
>>     have the same NAS.  No packets on another stream on the same LSP can
>>     have that same NAS.
>>
>
>
> <RG> We do not see the draft needs any updates for this.
>
> <RG> If there is anything specific to be added, please propose some text.
>
>
>
>
>>
>> 6.  The select scope problem
>>
>>     draft-ietf-mpls-mna-header is not completely aligned with the
>>     requirements and framework on the select scope.
>>
>>     Both documents (MNA requirements and framework) imply that multiple
>>     NA scopes are allowed in the same packet and multiple NAs of the
>>     same scope.  Select is no exception.
>>
>>     The MNA Framework says:
>>
>>     *  Select: Only specific nodes along the path will perform the
>>        action.
>>
>>     Thus a set of nodes might process a NA with select scope.
>>
>>     For this to be possible, with the current
>>     [I-D.ietf-mpls-mna-hdr], one select scope NA needs to be pushed by
>>     the ingress LER together with the correct incoming forwarding label
>>     under the incoming NAS.
>>
>>     This is because currently the MNA header solution pop the entire
>>     NAS, i.e. it is not forwarded.
>>
>>     However, it remains to define how the ingress LER know to put
>>     the correct forwarding label under the NAS, and how it pick the
>>     correct outgoing interface. The next select node need to have the
>>     label under the NAS mapped to outgoing interface and label, how is
>>     this done.
>>
>>     It can be understood how this could be reasonably simply done with
>>     SR-MPLS, and even easier with tLDP, but so far MNA has not done any
>>     control plane work. Today I don't think we can assume SR-MPLS in
>>     every MNA capable network.
>>
>>     And the problem is of course solvable by manual configuration.
>>
>>     For traditional MPLS LSPs, the forwarding label will not be popped
>>     on transit nodes, which means the select scope NAS can never be
>> exposed.
>>     It turns out that in the current situation packets that include a
>>     select NA are extremely similar to I2E, only that you define a
>>     separate LSP for the select NAS. Especially for OAM, which does
>>     require path sharing, this is not very useful.
>>
>
>
> <RG> We propose to update some text in Section 7 as follows. Welcome
> additional text from the WG.
>
>
>
>    “For an NAS with Select scope, it is processed by the node that brings
>
>    it to the top of stack (for example, in the case of using MPLS label
>
>    pop operation in Segment Routing) and then the NAS is removed from
>
>    the stack.  The select-scoped NAS needs to be inserted after the
>
>    forwarding label and before the next forwarding label.  It could be
>
>    inserted before or after a HBH NAS.  Note that the case of an NAS
>
>    with Select scope with MPLS label swap operation (for example, with
>
>    RSVP-TE LSPs) is for future study.”
>
>
>
>
>>
>> 7.  The coexistence of MNA with existing bSPLs in packet
>>
>>     Consider a legacy transit node which relies on the entropy label for
>> load
>>     balancing, and MNA is added by the ingress. In the coexistence of MNA
>> and entropy
>>     label, the order of their encapsulation is not specified in the
>> draft. If MNA
>>     label and the sub-stack is closer to the top of stack than the
>> ELI/EL, it is
>>     uncertain whether the legacy node can still reach the entropy label
>>     in its parsing (RLD). And if entropy label is within the RLD, it is
>>     uncertain what a legacy node would do if it finds an unknown
>> bSPL/eSPL (the MNA
>>     label) before finding the ELI/EL. If the ELI/EL is closer to
>>     the top of stack than the NAS, it may turns out the NAS cannot be
>> within the RLD
>>     for some nodes.
>>
>
>
> <RG> We propose to update the text in Section 7 as follows. Welcome
> additional text from the WG.
>
>
>
>    “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.”
>
>
>
> Thanks,
>
> Rakesh
>
>
>
>
>
>
>>
>> ------------------------------- end --------------------------------
>>
>> Best regards,
>> Jie (on behalf of the contributors of the list)
>>
>> _______________________________________________
>> mpls mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>