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

[Rakesh Gandhi <[e-mail]>]

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]
>>>>
>>>