[mpls] Proposed changes: Potential MNA technical issue

[Adrian Farrel <[e-mail]>]

Hi, I think we have some agreement on the text changes necessary.

Since 5.2 is such a short section, it is probably easiest if I supply the changed text for the whole section.

OLD
5.2.  Data

   The data field carries opcode specific data.  This is ancillary data
   for a network action.  In the case of opcode 1, data field carries
   Flag-Based Network Action Indicators without ancillary data.

   To preserve backward compatibility, if a network action encodes data
   that will change during packet forwarding, then that data MUST be in
   the least significant 4 bits in the data field of a Format C LSE
   (Section 4.3) or the least significant 8 bits of a Format D LSE
   (Section 4.4).  Some legacy implementations may use the label field
   in all LSEs when computing ECMP decisions and modifying the label
   field might disrupt that packet's flow.

   This is also applicable to opcode 1 Flag-Based Network Action
   Indicators those need to be changed in flight.
NEW
5.2.  Data

   The data field carries opcode specific data.  This is ancillary data
   for a network action.  In the case of opcode 1, the data field carries
   Flag-Based Network Action Indicators without ancillary data.

   Some legacy implementations may use the label field in all LSEs
   when computing ECMP decisions and modifying the label field
   might disrupt that packet's flow.  To preserve backward
   compatibility, if a network action encodes data that may be
   different on different packets in the same flow or might change
   during packet forwarding, then that data MUST NOT be in the
   most significant 20 bits of a Format B LSE (Section 4.2), a 
   Format C LSE (Section 4.3), or a Format D LSE (Section 4.4).  Thus,
   this is also applicable to opcode 1 Flag-Based Network Action
   Indicators that need to be changed in flight.

   The available mitigations for this are to use additional Format D
   LSEs to carry the data, or to place the data in Post-Stack Data as
   described in [draft-ietf-mpls-mna-fwk].
END

Cheers,
Adrian

-----Original Message-----
From: Adrian Farrel <[e-mail]> 
Sent: 20 February 2025 21:48
To: 'Tony Li' <[e-mail]>
Cc: 'mpls' <[e-mail]>
Subject: [mpls] Re: Potential MNA technical issue

No, I personally don't have a problem with that solution.
Others may have, I don't know.

The text could, perhaps, be a little clearer in 5.2 to direct applications to use PSD. Yeah, I know one could possibly work out that having a lot of LSEs is not very wise (especially as we have a limit to the number of LSEs we can support because of the size of the NASL). Just a few words of advice: nothing heavy.

And the fixes for points 1 and 2.

A

-----Original Message-----
From: Tony Li <[e-mail]> On Behalf Of Tony Li
Sent: 20 February 2025 21:27
To: Adrian Farrel <[e-mail]>
Cc: mpls <[e-mail]>
Subject: Re: [mpls] Potential MNA technical issue

[WG chair hat: off]

Hi Adrian,

I recall that we discussed this before and we reached the conclusion that actions that needed
more variable data should go the post-stack route. Do you have a problem with that?

Regards,
Tony


> On Feb 20, 2025, at 12:58 PM, Adrian Farrel - adrian at olddog.co.uk <[e-mail]> wrote:
> 
> Hi all,
> 
> I thought the virtual interim was useful in airing some opinions.
> 
> I exchanged a few emails with Jie to try to better understand his concerns,
> and then Stewart and I sat down for a couple of hours to work through all of
> the possibilities.
> 
> This is mainly thinking aloud.
> 
> A big question surrounds how the NAS might be parsed by a non-MNA node.
> 
> The first part of the question is "What happens if a non-MNA node encounters
> the MNA label?" Well, it shouldn't! The MNA label should only rise to the
> top of stack at nodes known to be MNA capable. But, if it does, the MNA
> label is an SPL, and processing unknown SPLs at the top of stack is well
> defined.
> 
> The next part of this question is "What if part of the NSA looks like an
> SPL?" The most concerning case we have at the moment is if it looks like an
> ELI to a non-MNA node that searches ahead for an entropy label.
> This question is covered in the draft in two places:
> 6.1 tells us that Opcode 0 is not to be used. That means that LSE formats B
> and C can never be mistaken for bSPLs because they don't start with eight 0
> bits.
> 4.4 tells us that format D LSEs must always start with a 1 so they can never
> be mistaken for bSPLs.
> So all good here.
> 
> The last part of the question is "Suppose a (legacy) node does ECMP hashing
> by reading the first n labels on the stack?"
> Since it doesn't know about MNA, it will find Opcodes and ISD and treat them
> as labels.
> This is not a problem in itself, but if the ISD can vary from packet to
> packet in a flow, it can lead to packets taking different paths.
> This question is covered in section 5.2 which tells us to be careful which
> ISD bits are allowed to vary.
> 
> But it was in re-reading 5.2 that Stewart and I had some worries.
> 
> 1. The text says:
>       if a network action encodes data
>       that will change during packet forwarding
>    While this may be interesting for OAM, what is more interesting is when
> the
>    data is different on different packets in the same flow. So probably
> change 
>    this to:
>       if a network action encodes data
>       that may be different on different packets in the same flow
> 
> 2. s/Indicators those need/Indicators that need/
> 
> 3. There are not many bits that are allowed to contain variable data.
>     This is a bit grim. We reckon that:
>     - No bits in a type B LSE can be variable
>     - Only 7 bits in a type C LSE can be variable
>     - Just 11 bits in a type D LSE can be variable
>     If you wanted to carry something like a time stamp (RFC 8877) you need
> 32 bits
>     or even 64 bits. That would need 4 or 7 LSEs (BDDD or BDDDDDD/BCDDDDD) 
>     instead of 2 or 3 (BD or BDD/BCD).
>     There are some possible mitigations:
>     - Use an entropy label. This allows any implementation that supports
> entropy
>        labels to not hash. But:
>         * it costs two additional LSEs
>         * it doesn't help with implementations that don't support entropy
> labels
>     - Stop hashing when you reach an SPL. 
>       This advice would work for new implementations, but it doesn't help
> with
>       existing implementations which will hash their way through into the
> NAS.
>     - Follow the draft and restrict where variable data is placed.
>         * Use lots of LSEs. Not a very good answer.
>         * Don't send much variable data. A bit of an unfortunate
> limitation.
>         * Put variable data post-stack. 
>     - Decide that we don't care about legacy nodes. This is not ideal, but
> an
>       operator might know about the nodes in their network. If this is the
>       choice, then the document would need to be clear.
>     - Choose a behaviour based on knowledge of the nodes in the network
>       and the (potential) path of the LSP. This approach would require 
>       capabilities to be advertised (perhaps alongside the RLD ).
> 
> Cheers,
> Adrian
> 
> _______________________________________________
> 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]