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

[Loa Andersson <[e-mail]>]

All,

Inline plz.

Den 03/03/2025 kl. 17:06, skrev Adrian Farrel:
> Hi,
> 
> Thanks for the continued work on this.
> 
> I can get behind it, but I suggest a couple of language tweaks in line.
> 
> Cheers,
> 
> Adrian
> 
> *From:*Greg Mirsky <[e-mail]>
> *Sent:* 03 March 2025 12:10
> *To:* Rakesh Gandhi <[e-mail]>
> *Cc:* [e-mail]
> *Subject:* [mpls] Re: Proposed changes: Potential MNA technical issue
> 
> Hi Rakesh,
> 
> thank you for the updates. I gave priority to reviewing Section 5.2. 
> Below are my notes and nits:
> 
>   * Proposed re-wording:
> 
> OLD TEXT:
> 
>     The data field carries opcode specific data.  This is ancillary data
> 
>     for a network action.
> 
> NEW TEXT:
> 
>     The data field carries opcode-specific data that is ancillary data
> 
>     for a network action.
> 
>   * On the following text:
> 
>     The legacy implementations may use the label field (most significant
> 
>     20 bits) in all LSEs when computing ECMP decisions and modifying the
> 
>     label field might disrupt that packet's flow and result in out-of-
> 
>     order delivery of packets.
> 
>     I imagine that some implementations are limited in the number of
>     LSEs used to calculate entropy for load-balancing data flows. Also,
>     "flow disruption" sounds a bit overdramatic. Considering these
>     notes, the proposal follows:
> 
> NEW TEXT:
> 
>     The legacy implementations may use the label field (most significant
> 
>     20 bits) in several consecutive LSEs when load-balancing data flows in
> 
>     ECMP environment. Modifying the
> 
>     label field might alter that packet's path and result in out-of- 
> order delivery of packets.
> 
> Adrian NEW:
> 
>  Legacy implementations might use the label field (most significant
>  20 bits) in one or more consecutive LSEs when load-balancing data 
>  flows in An ECMP environment. Modifying the first 20 bits in an 
 >  LSE might alter that packet's path and result in out-of-order
 >  delivery of packets.

The term RFC 3032 uses is "Label Value" not "Label Field".

  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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label
|                Label                  | Exp |S|       TTL     | Stack
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry

                     Label:  Label Value, 20 bits
                     Exp:    Experimental Use, 3 bits
                     S:      Bottom of Stack, 1 bit
                     TTL:    Time to Live, 8 bits

/Loa

> 
>   * s/backward/the backward/
>   * Some notes on the following text:
> 
>     To preserve backward compatibility of
> 
>     these implementations, if a network action encodes data that may be
> 
>     different on different packets in the same flow or might change
> 
>     differently during packet forwarding, then that data MUST NOT be
> 
>     carried 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, the available bits for data that can change by
> 
>     a transit node in Format A and Format B LSEs are 0, Format C LSE is 7
> 
>     (bits 20-22 and 25-28) and Format D LSE is 11 (bits 20-22 and 25-31).
> 
>       o I think we care about the stability of the networks and
>         services, not the implementations.
>       o In the concluding sentence, the case of data changing among
>         packets in the same flow is missing.
> 
> I propose the following editorial update of that text:
> 
> NEW TEXT:
> 
>     To preserve the stability of the deployed services in ECMP environments
> 
>     that use information in the Label field to load-balance data flows,
> 
>     if a network action encodes data in the given LSE that may be
> 
>     different among packets in the same flow or might change
> 
>     during packet forwarding across the MPLS network, then that data 
> MUST NOT be
> 
>     carried 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, the available bits for data that can change by
> 
>     a transit node or differ among packets of the same flow
> 
>     in Format A and Format B LSEs are 0, Format C LSE is 7
> 
>     (bits 20-22 and 25-28) and Format D LSE is 11 (bits 20-22 and 25-31).
> 
>   * In the next paragraph s/backward compatibility/service stability/
>   * In the next-to-last paragraph, I propose the following editorial update:
> 
> OLD TEXT:
> 
> The available mitigations for this ...
> 
> NEW TEXT:
> 
> The available mitigations for these use cases ...
> 
> Adrian SAYS:
> 
> You don’t mitigate use cases, you mitigate problems.
> 
>   * For the last paragraph, the following updates are proposed:
> 
> OLD TEXT:
> 
>     In implementation where it is known that only the entropy label-based
> 
>     mechanism is used for load-balancing data flows, and it is certain
> 
>     that ECMP hashing will not be computed based on the label field of
> 
>     the LSEs, then the data in the label field of the LSEs in ISD can
> 
>     vary within a data flow without disrupting the flow.
> 
> NEW TEXT:
> 
>     In network deployments where it is known that a load-balancing of 
> data flows is not used,
> 
>     or, otherwise, if only the explicitly signaled entropy value is 
> used, and it is certain
> 
>     that the load-balancing path selection will not be based on the 
> Label field of
> 
>     the LSEs, then the data in the Label field of the LSEs in ISD MAY be
> 
>     mutable within the data flow without causing the out-of-order 
> delivery of packets.
> 
> Regards,
> 
> Greg
> 
> On Fri, Feb 28, 2025 at 10:30 PM Rakesh Gandhi <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
>     Thanks Greg for the review.
> 
>     Have shared the updated text in the work in progress document in a
>     separate email sent to the WG list.
> 
>     Regards,
> 
>     Rakesh
> 
>     On Fri, Feb 28, 2025 at 3:44 AM Greg Mirsky <[e-mail]
>     <mailto:[e-mail]>> wrote:
> 
>         Hi Rakesh,
> 
>         Thank you for highlighting this text for me. It is very close to
>         what I was looking for. However, the text has no normative
>         language, while the passage about immutability does. Can you
>         help me and share the working version of the draft so I can read
>         the discussion related to the mutability/immutability of ISD MNA
>         ancillary data in its entirety?
> 
>         Regards,
> 
>         Greg
> 
>         On Thu, Feb 27, 2025 at 7:21 PM Rakesh Gandhi
>         <[e-mail] <mailto:[e-mail]>> wrote:
> 
>             Hi Greg,
> 
>             I believe this point is covered in the proposed text, no?
> 
>             "
> 
>                 In networks where it is known that only the entropy
>             label-based mechanism is used for load-balancing data flows,
> 
>                 and it is certain that ECMP hashing will not be computed
>             based on the label field of the LSEs,
> 
>                 then the data in the label field of the LSEs in ISD can
>             be modified by the transit nodes without
> 
>                 disrupting the data flows.
> 
>             "
> 
>             Regards,
> 
>             Rakesh
> 
>             On Wed, Feb 26, 2025 at 3:03 AM Greg Mirsky
>             <[e-mail] <mailto:[e-mail]>> wrote:
> 
>                 Hi, Rakesh et al.,
> 
>                 I believe that discussing this passage is very important
>                 for future-proofing MNA ISD. In my opinion, as I've
>                 noted on the thread earlier, some technologies, e.g.,
>                 DetNet, do not recommend load-balancing of data to
>                 maintain predictability of performance characteristics
>                 (packet loss, packet delay, and delay variation) of the
>                 path. Furthermore, some MPLS networks use or may be
>                 using explicitly signaled entropy information for load-
>                 balancing data flows. For these cases, AFAICS, all space
>                 of ISD MNA ancillary data must be allowed to be
>                 muttable. To reflect that, I propose the following:
> 
>                 NEW TEXT:
> 
>                 To preserve backward compatibility with networks that
>                 use label information in load-balancing, if a network
>                 action encodes data such that packets in the same flow
>                 may be originated or modified by intermediate routers in
>                 such a way that different packets in the same flow are
>                 emitted with different data, that data SHOULD NOT be
>                 carried in the most significant 20 bits. In networks
>                 that use explicit entropy value in load-balancing data
>                 flows or do not load-balance them, the entire space of
>                 ancillary data MAY be mutable.
> 
>                 With this modification, we acknowledge the existing
>                 state of MPLS networks while ensuring that the ISD MNA
>                 solution is future-proof.
> 
>                 Regards,
> 
>                 Greg
> 
>                 On Tue, Feb 25, 2025 at 6:53 PM Rakesh Gandhi
>                 <[e-mail] <mailto:[e-mail]>>
>                 wrote:
> 
>                     Hi Joel,
> 
>                     Thank you for the comment.
> 
>                     I think it is the second case in your example that
>                     can be an issue for out of order delivery.
> 
>                     The proposed text is:
> 
>                     "
> 
>                        To preserve backward compatibility, if
>                         a network action encodes data that may be
>                     different on different
>                         packets in the same flow or might change
>                     *differently* during packet forwarding,
>                         then that data MUST NOT be carried in the most
>                     significant 20 bits
> 
>                       "
> 
>                     Do you have suggestions to improve the proposed text
>                     below?
> 
>                     Thanks,
> 
>                     Rakesh
> 
>                     On Mon, Feb 24, 2025 at 4:33 PM Joel Halpern
>                     <[e-mail] <mailto:[e-mail]>>
>                     wrote:
> 
>                         Minor question:  Can someone explain how having
>                         those bits change in packet processing (if they
>                         change the same way for every packet in the
>                         flow) would break ECMP?  It would cause
>                         different routers to get different answers, but
>                         they already do that.  ( understand why having
>                         different packets in the flow show up at the
>                         same rotuer with different bits that are used in
>                         ECMP causes problems.)
> 
>                         Yours,
> 
>                         Joel
> 
>                         On 2/24/2025 3:47 PM, Rakesh Gandhi wrote:
> 
>                             Thanks Adrian, Loa, Fabian, and Greg for the
>                             comments.
> 
>                             How about revising the proposed text in
>                             section 5.2 as follows:
> 
>                             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 (most significant
>                                 20 bits) in all LSEs when computing ECMP
>                             decisions and modifying the
>                                 label field might disrupt that packet's
>                             flow and might result in out-
>                                 of-order delivery of packets.  To
>                             preserve backward compatibility, if
>                                 a network action encodes data that may
>                             be different on different
>                                 packets in the same flow or might change
>                             *differently* during packet forwarding,
>                                 then that data MUST NOT be carried 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, the
>                             available bits for data that
>                                 can change by a transit node in Format A
>                             and Format B LSEs are 0,
>                                 Format C LSE is 7 (bits 20-22 and 25-28)
>                             and Format D LSE is 11 (bits
>                                 20-22 and 25-31).
> 
>                                 Similarly, to preserve backward
>                             compatibility, such data also MUST
>                                 NOT be carried in the most significant
>                             23 bits of these LSEs when the
>                                 legacy implementation also uses the TC
>                             field, in addition to the
>                                 label field, in all LSEs when computing
>                             ECMP decisions.
> 
>                                 Note that 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 [I-D.ietf-mpls-mna-fwk].
> 
>                                 In networks where it is known that only
>                             the entropy label-based mechanism
>                                 is used for load-balancing data flows,
>                             and it is certain that ECMP
>                                 hashing will not be computed based on
>                             the label field of the LSEs,
>                                 then the data in the label field of the
>                             LSEs in ISD can be modified
>                                 by the transit nodes without disrupting
>                             the data flows.
> 
>                             Thanks,
> 
>                             Rakesh
> 
>                             On Mon, Feb 24, 2025 at 9:21 AM Loa
>                             Andersson <[e-mail] <mailto:[e-mail]>> wrote:
> 
>                                 All,
> 
>                                 After counting on my fingers and toes a
>                                 couple of time, I conclude that
>                                 Fabian is right. It should be:
> 
>                                 (*  0 in format A)
>                                    *  0 in Format B
>                                    *  7 in Format C (bit 20-22 and 25-28)
>                                    * 11 in Format D (bit 20-22 and 24-31)
> 
>                                 I'm not sure that Format A need to be in
>                                 the list, but since ...
> 
>                                 /Loa
> 
> 
>                                 Den 24/02/2025 kl. 14:21, skrev Fabian Ihle:
>                                  > Hi Loa,
>                                  >
>                                  > I think you're off by one, Format A
>                                 is the NAS indicator (bSPL or eSPL)
>                                  > and does not hold ancillary data, but
>                                 having the bit indices explicitly
>                                  > in the draft is a good idea.
>                                  >
>                                  > Best,
>                                  >
>                                  > Fabian
>                                  >
>                                  > On 24.02.25 13:33, Loa Andersson wrote:
>                                  >> Fabian, Adrian,
>                                  >>
>                                  >> If are clarifying, let us go all the
>                                 way.
>                                  >>
>                                  >> - 0 for LSE format A
>                                  >> - 7 for LSE format B (bit 20-22 and
>                                 25-28)
>                                  >> - 11 for LSE format C (bit 20-22 and
>                                  >>     24-31)
>                                  >>
>                                  >> /Loa
>                                  >>
>                                  >>
>                                  >> On Mon, 24 Feb 2025 at 13:14, Fabian
>                                 Ihle <fabian.ihle@uni-
>                                 <mailto:fabian.ihle@uni-%20%0b>>>
>                                 tuebingen.de <http://tuebingen.de>> wrote:
>                                  >>
>                                  >>     Hi Adrian,
>                                  >>
>                                  >>     I agree that "data found in the
>                                 last 12 bits" may sound a bit
>                                  >>     misleading regarding the S bit.
>                                 People may think that there are 12
>                                  >>     bits available. Maybe something
>                                 along:
>                                  >>
>                                  >>        "The transit node MUST NOT
>                                 modify the first 20 bits of any LSE
>                                  >>     in the label stack when the ECMP
>                                 technique in the network is using
>                                  >>     the hashing of the labels on the
>                                 label stack.
>                                  >>
>                                  >>              A transit node MAY
>                                 change the Ancillary Data found in
>                                  >>     the/remaining bits of/ an LSE."
>                                  >>
>                                  >>     We could also list the number of
>                                 available bits per Format below
>                                  >>     this point:
>                                  >>
>                                  >>       * 0 in Format B
>                                  >>       * 7 in Format C
>                                  >>       * 11 in Format D
>                                  >>
>                                  >>     Further, I checked the
>                                 documentation of multiple devices from
>                                  >>     various vendors and they all
>                                 state to hash only up to the first 20
>                                  >>     bits and not the TC field.
>                                 However, maybe someone can confirm this.
>                                  >>
>                                  >>     Best,
>                                  >>
>                                  >>     Fabian
>                                  >>
>                                  >>     On 22.02.25 12:38, Adrian Farrel
>                                 wrote:
>                                  >>>
>                                  >>>     Good catch, Fabian.
>                                  >>>
>                                  >>>     5.2 which I modified, also used
>                                 to say “least significant 8 bits”
>                                  >>>
>                                  >>>     Of course, this represents the
>                                 bits after the S bit. But there
>                                  >>>     are 3 bits before the S bit
>                                 than can also be safely varied as
>                                  >>>     they are out of the overlap
>                                 with a label.
>                                  >>>
>                                  >>>     However, it occurs to me now
>                                 that some implementations may be
>                                  >>>     hashing on the TC as well as
>                                 the label.
>                                  >>>
>                                  >>>     So we have to jump to 11 (my
>                                 text) or 8 (original text).
>                                  >>>
>                                  >>>     I’d prefer to not say “data
>                                 found in the last 12 bits” in case
>                                  >>>     that confuses people around the
>                                 S bit.
>                                  >>>
>                                  >>>     Adrian
>                                  >>>
>                                  >>>     *From:*Fabian Ihle
>                                 <[e-mail]
>                                 <mailto:[e-mail]>>
>                                  >>>     <mailto:fabian.ihle@uni-
>                                 tuebingen.de <mailto:fabian.ihle@uni-
>                                 tuebingen.de>>
>                                  >>>     *Sent:* 22 February 2025 11:18
>                                  >>>     *To:* [e-mail]
>                                 <mailto:[e-mail]>; Rakesh Gandhi
>                                 (rgandhi) <[e-mail]
>                                 <mailto:[e-mail]>>
>                                  >>>     <mailto:[e-mail]
>                                 <mailto:[e-mail]>>
>                                  >>>     *Subject:* [mpls] Re: Proposed
>                                 changes: Potential MNA technical issue
>                                  >>>
>                                  >>>     Hi Rakesh,
>                                  >>>
>                                  >>>     Section 5.2 says:
>                                  >>>
>                                  >>>        " [...] 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* [...]"
>                                  >>>
>                                  >>>     whereas Section 9.2 says:
>                                  >>>
>                                  >>>        "A transit node MAY change
>                                 the Ancillary Data found in the least
>                                  >>>        significant *8 bits* of an LSE."
>                                  >>>
>                                  >>>     This ignores the remaining 4
>                                 bits in the middle. I think this
>                                  >>>     should be changed to
>                                  >>>
>                                  >>>        "A transit node MAY change
>                                 the Ancillary Data found in the least
>                                  >>>        significant *12 bits* of an
>                                 LSE." (excluding the BoS bit of
>                                  >>>     course)
>                                  >>>
>                                  >>>     Here is an image from our paper
>                                 (https://arxiv.org/ <https://arxiv.org/>
>                                  >>>     pdf/2410.20400) illustrating
>                                 the bits that are available for
>                                  >>>     variable bits (hatched).
>                                 Currently the draft only considers bit
>                                  >>>     24 - 31 in Section 9.2.
>                                  >>>
>                                  >>>     Best,
>                                  >>>
>                                  >>>     Fabian
>                                  >>>
>                                  >>>     On 21.02.25 19:02, Rakesh
>                                 Gandhi wrote:
>                                  >>>
>                                  >>>         Hi Adrian,
>                                  >>>
>                                  >>>         Thanks for suggesting the text.
>                                  >>>
>                                  >>>         Attaching the work-in-
>                                 progress draft for review before posting.
>                                  >>>
>                                  >>>         Hi WG,
>                                  >>>
>                                  >>>         Please advise if there are
>                                 any pending comments to address.
>                                  >>>
>                                  >>>         Regards,
>                                  >>>
>                                  >>>         Rakesh (for authors)
>                                  >>>
>                                  >>>         On Fri, Feb 21, 2025 at
>                                 11:24 AM 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>
>                                 <http://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]>
>                                  >>>
>                                  >>>
>                                  >>>
>                                  >>>       
>                                   _______________________________________________
>                                  >>>
>                                  >>>         mpls mailing list --
>                                 [e-mail] <mailto:[e-mail]>
>                                  >>>
>                                  >>>         To unsubscribe send an
>                                 email [e-mail]
>                                 <mailto:[e-mail]>
>                                  >>>
>                                  >>>     --
>                                  >>>     Fabian Ihle
>                                  >>>     Universität Tübingen
>                                  >>>     Fachbereich Informatik
>                                 Lehrstuhl Kommunikationsnetze
>                                  >>>     Wilhelm-Schickard-Institut für
>                                 Informatik
>                                  >>>     Sand 13, 72076 Tübingen
>                                 <https://www.google.com/maps/search/
>                                 Sand+13,+72076+T%C3%BCbingen?
>                                 entry=gmail&source=g <https://
>                                 www.google.com/maps/search/Sand+13,
>                                 +72076+T%C3%BCbingen?entry=gmail&source=g>>
>                                  >>>
>                                  >>>     Raum: B303
>                                  >>>     Telefonnr.: [phone]
>                                  >>> E-Mail:[e-mail]
>                                 <mailto:E-Mail%3Afabian.ihle@uni-
>                                 tuebingen.de>
>                                  >>>     Internet:uni-tuebingen.de
>                                 <http://uni-tuebingen.de> <http://uni-
>                                 tuebingen.de <http://uni-tuebingen.de>>
>                                  >>
>                                  >>     --
>                                  >>     Fabian Ihle
>                                  >>     Universität Tübingen
>                                  >>     Fachbereich Informatik Lehrstuhl
>                                 Kommunikationsnetze
>                                  >>     Wilhelm-Schickard-Institut für
>                                 Informatik
>                                  >>     Sand 13, 72076 Tübingen
>                                 <https://www.google.com/maps/search/
>                                 Sand+13,+72076+T%C3%BCbingen?
>                                 entry=gmail&source=g <https://
>                                 www.google.com/maps/search/Sand+13,
>                                 +72076+T%C3%BCbingen?entry=gmail&source=g>>
>                                  >>
>                                  >>     Raum: B303
>                                  >>     Telefonnr.: [phone]
>                                  >> E-Mail:[e-mail]
>                                 <mailto:E-Mail%3Afabian.ihle@uni-
>                                 tuebingen.de>
>                                  >>     Internet:uni-tuebingen.de
>                                 <http://uni-tuebingen.de> <http://uni-
>                                 tuebingen.de <http://uni-tuebingen.de>>
>                                  >>
>                                  >>   
>                                   _______________________________________________
>                                  >>     mpls mailing list --
>                                 [e-mail] <mailto:[e-mail]>
>                                  >>     To unsubscribe send an email to
>                                 [e-mail] <mailto:mpls-
>                                 [e-mail]>
>                                  >>
>                                  > --
>                                  > Fabian Ihle
>                                  > Universität Tübingen
>                                  > Fachbereich Informatik Lehrstuhl
>                                 Kommunikationsnetze
>                                  > Wilhelm-Schickard-Institut für Informatik
>                                  > Sand 13, 72076 Tübingen
>                                  >
>                                  > Raum: B303
>                                  > Telefonnr.: [phone]
>                                  > E-Mail:[e-mail]
>                                 <mailto:E-Mail%3Afabian.ihle@uni-
>                                 tuebingen.de>
>                                  > Internet: uni-tuebingen.de <http://
>                                 uni-tuebingen.de>
>                                  >
>                                  >
>                                  >
>                                 _______________________________________________
>                                  > mpls mailing list -- [e-mail]
>                                 <mailto:[e-mail]>
>                                  > To unsubscribe send an email to mpls-
>                                 [e-mail] <mailto:[e-mail]>
> 
>                                 -- 
>                                 Loa Andersson
>                                 Senior MPLS Expert
>                                 Bronze Dragon Consulting
>                                 [e-mail] <mailto:[e-mail]>
>                                 [e-mail]
>                                 <mailto:[e-mail]>
> 
>                                 _______________________________________________
>                                 mpls mailing list -- [e-mail]
>                                 <mailto:[e-mail]>
>                                 To unsubscribe send an email to mpls-
>                                 [e-mail] <mailto:[e-mail]>
> 
>                             _______________________________________________
> 
>                             mpls mailing list [e-mail] <mailto:[e-mail]>
> 
>                             To unsubscribe send an email [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]
> To unsubscribe send an email to [e-mail]

-- 
Loa Andersson
Senior MPLS Expert
Bronze Dragon Consulting
[e-mail]
[e-mail]