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

[John Drake <[e-mail]>]

 This is a well-reasoned response.  I don't think Jie's list of issues contains anything that we haven't heard before.
    On Wednesday, April 16, 2025 at 10:35:15 AM PDT, Joel Halpern <[e-mail]> wrote:  
 
 Topposting responses, and the length of each comment would make finding 
my responses difficult.

1) You express concern about MNA versioning.

Response 1) There is no problem with MNA versioning.  First, we actually 
are reasonably confident that this approach can address the need, 
without needing to change the base header.  The ability to add flags and 
opcodes gives us a tremendous amount of flexibility for evolution.  
Second, if we find it is completely wrong we can indeed assign a new 
special label with a new initial structure.  Whether we use the 
half-empty bSPL space or decide at that point that uncertainty suggests 
the use of eSPL can be determined at that time.

2) You ask if ISD makes the label stack too big.

Response 2) This seems, if I am reading the rest of your exposition 
properly, to be a comparison with PSD.  There are, as far as I can tell, 
two cases.  Case 1) RLD matters:  If that is true we need ISD to be able 
to cope with RLD limitations.  Case 2) RLD doesn't matter:  In which 
case one needs only one copy of each of the ISD hop-by-hop and 
end-to-end substacks.  So the size of the ISD is the same or better than 
the PSD.

3) You express some concern about byte alignment.

Response 3) For protocols to be processed by general purpose CPUs, byte 
alignment is sometimes an issue.  But even then, as long as the labels, 
which they are, are 32 bit aligned performing field extractions in 
software is very efficient.  And for other cases, it is a non-issue 
entirely.  I do not see a problem.

4) You then come back to the bSPL vs eSPL topic.

Response 4) Your primary concern here seems to be that we might need 
eSPL for versioning.  And that therefore if we need a version we will 
waste one of the half-empty set of bSPLs.  See response 1 for a 
discussion of versioning.

5) You object to what you term breaking the MPLS forwarding paradigm.

Response 5) If we are going to add additional behaviors at anything 
other than the end of the label stack (e.g. OAM) then we are going to 
change the processing structure.  The WG agreed that we need to do this 
in the Requirements and Framework efforts.   Is there something 
different about using ISD?  I don't see it.

6) You seem to see a problem with handling select scope.

Response 6) As far as I can tell, the ISD select scope handling 
precisely matches the need.   Yes, the entity constructing the stack 
needs to know which nodes need the instructions, and needs to include 
labels for directing the packet to that node and the associated 
instructions.   No matter how you encode the packet, you need that 
information if the packet is going to reflect the control.  The 
alternative would seem to be to declare Select to be out of scope, which 
would seem to be a violation of the agreed requirements.

7) You have some concern about coexistence of bSPLs and MNA.

Response 7) I think you are concerned about a label stack with Entropy 
labels not encoded in MNA and MNA substacks.  i am not at all sure there 
is a problem here.   But if there is, the place to resolve it would be 
the draft that defines the entropy opcode for use with MNA ISD, not the 
general ISD draft.

Yours,

Joel

On 4/15/2025 10:32 PM, Dongjie (Jimmy) 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.
>
> 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.
>
> 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]).
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> ------------------------------- 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]

_______________________________________________
mpls mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]