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

[Greg Mirsky <[e-mail]>]

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.


   - 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).

   - I think we care about the stability of the networks and services, not
      the implementations.
      - 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 ...

   - 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]>
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]> 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]>
>> 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]>
>>> 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]>
>>>> 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]>
>>>>> 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]> 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-
>>>>>>> >> 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]>
>>>>>>> >>>     *Sent:* 22 February 2025 11:18
>>>>>>> >>>     *To:* [e-mail]; Rakesh Gandhi (rgandhi) <
>>>>>>> [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/
>>>>>>> >>>     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]> 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]>
>>>>>>> >>>             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 <http://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]
>>>>>>> >>>
>>>>>>> >>>             _______________________________________________
>>>>>>> >>>             mpls mailing list -- [e-mail]
>>>>>>> >>>             To unsubscribe send an email to [e-mail]
>>>>>>> >>>
>>>>>>> >>>
>>>>>>> >>>
>>>>>>> >>>         _______________________________________________
>>>>>>> >>>
>>>>>>> >>>         mpls mailing list [e-mail]
>>>>>>> >>>
>>>>>>> >>>         To unsubscribe send an email [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>
>>>>>>>
>>>>>>> >>>
>>>>>>> >>>     Raum: B303
>>>>>>> >>>     Telefonnr.: [phone]
>>>>>>> >>>     E-Mail:[e-mail]
>>>>>>> >>>     Internet: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>
>>>>>>>
>>>>>>> >>
>>>>>>> >>     Raum: B303
>>>>>>> >>     Telefonnr.: [phone]
>>>>>>> >>     E-Mail:[e-mail]
>>>>>>> >>     Internet:uni-tuebingen.de <http://uni-tuebingen.de>
>>>>>>> >>
>>>>>>> >>     _______________________________________________
>>>>>>> >>     mpls mailing list -- [e-mail]
>>>>>>> >>     To unsubscribe send an email to [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]
>>>>>>> > Internet: uni-tuebingen.de
>>>>>>> >
>>>>>>> >
>>>>>>> > _______________________________________________
>>>>>>> > 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]
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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]
>>>>>>
>>>>>> _______________________________________________
>>>>> mpls mailing list -- [e-mail]
>>>>> To unsubscribe send an email to [e-mail]
>>>>>
>>>>