[mpls] Re: Proposed changes: Potential MNA technical issue

[[e-mail]]

From: Greg Mirsky <[e-mail]>
Sent: Wednesday, February 26, 2025 2:31 PM
To: DECRAENE Bruno INNOV/NET <[e-mail]>
Cc: Adrian Farrel <[e-mail]>; [e-mail]; mpls <[e-mail]>
Subject: Re: [mpls] Re: Proposed changes: Potential MNA technical issue

Hi Bruno,
Thank you for the reference to RFC 6790. I interpret it as an encouragement to broaden the deployment of ELI/EL-based load-balancing. When ELI/EL is not available, or the implementation doesn't support it yet, it is recommended that the implementation use as much of the label stack as possible in making the load-balancing decision.

The text refers to the case where ELI is supported and used. Sorry for being unclear:

“If a transit LSR recognizes the ELI, it MAY choose to load balance
   solely on the following label (the EL); otherwise, it SHOULD use as
   much of the whole label stack as feasible as keys for the load-
   balancing function.”

So again, even assuming a full deployment of EL, we need the MPLS stack to be immutable.


  *   I interpret it as an encouragement to broaden the deployment of ELI/EL-based load-balancing.


We would first need implementations to support EL capability signaling for BGP NLRI/FEC (for inter-AS and inter-area using seamless MPLS). This is control plane only, that’s supposed to be easier than MNA.


Regards,
--Bruno

Regards,
Greg


On Wed, Feb 26, 2025 at 2:03 PM <[e-mail]<mailto:[e-mail]>> wrote:
Hi Greg, all

The use of ELI does not imply that only the EL will be used for load balancing. The whole MPLS stack may be used for hashing.

Actually, RFC2119 keywords even say that one MAY use only the EL, otherwise one SHOULD use (as much of) the whole label stack
https://datatracker.ietf.org/doc/html/rfc6790#section-4.3


> From: Adrian Farrel [e-mail]<mailto:[e-mail]>
> Sent: Monday, February 24, 2025 7:05 PM
[…]
>[Network Operators] probably also hope to be able to find out from their vendors a little bit about how ECMP works in each node. However, I think that tracking that is likely to be a challenge

+1. Definitely it’s a challenge.
And it’s not only a question of “node”. It’s also a question of line card and software version.
It can be quite complex, and even on the vendor sides, many persons do not know the details, which makes it hard to just collect reliable info.


Finally, since I did that effort a long time ago, I know of at least one vendor, in at least one software version did use the TC bits as part of the hash.
So probably the TC fields should also be declared immutable.


Regards,
--Bruno
From: Greg Mirsky <[e-mail]<mailto:[e-mail]>>
Sent: Sunday, February 23, 2025 6:55 PM
To: Adrian Farrel <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; mpls <[e-mail]<mailto:[e-mail]>>
Subject: [mpls] Re: Proposed changes: Potential MNA technical issue

Hi Adrian,
Thank you for the proposed changes. When I read them, it seemed somewhat restrictive to me. Consider networks where ELI is used to load-balance flows. Or DetNet domain where ECMP is not recommended. Making the proposed restrictions on the use of varianting ancillary data in ISD seems unnecessary to me. Perhaps it could be made conditional for implementors and operators that use label stack to load balance in ECMP environments. WDYT?

Regards,
Greg

On Fri, Feb 21, 2025, 17:25 Adrian Farrel <[e-mail]<mailto:[e-mail]>> wrote:
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]<mailto:[e-mail]>>
Sent: 20 February 2025 21:48
To: 'Tony Li' <[e-mail]<mailto:[e-mail]>>
Cc: 'mpls' <[e-mail]<mailto:[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]<mailto:[e-mail]>> On Behalf Of Tony Li
Sent: 20 February 2025 21:27
To: Adrian Farrel <[e-mail]<mailto:[e-mail]>>
Cc: mpls <[e-mail]<mailto:[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<http://olddog.co.uk/> <[e-mail]<mailto:[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]<mailto:[e-mail]>
> To unsubscribe send an email to [e-mail]<mailto:[e-mail]>

_______________________________________________
mpls mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>

_______________________________________________
mpls mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>

____________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.