[mpls] Re: Potential MNA technical issue

[Loa Andersson <[e-mail]>]

Haoyu,

I have argued that before, at that I got no traction, but I agree.

So we have these potential PSD indicators:

P-flag, can be used whenever there are ISD in the packet and the PSD is 
immediately after the LSE with the BoS bit set.

If there are PSD with an offset and ISD in the Label Stack then then I 
that an OpCode + offset we could be, ugly but would work.

There is also another mechanism we at could discuss before we throw it 
away. If ther is PSD only in the packetm the we could use an eSPL and 
encode the offset in the 11 bits available (TTL and TC):

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          XL = 15                      | TC  |S|    TTL        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |               MNA eSPL                | Off |S|     set       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I'd claim

- P-flag, is more efficient if there is ISD + non-offset PSD
- OpCode + OSD with offset is ugly, but will work for ISD + PSD
   with ossset
- PSD will be most efficient if there is only PSD

And, yes I understand that an argument that having more than one method 
could be problematic, But I'd like to hear the arguments, not the statement.

/Loa





Den 21/02/2025 kl. 20:29, skrev Haoyu Song:
> Hi Loa,
> 
> Yes, to be clear.
> 
> Haoyu
> 
> -----Original Message-----
> From: Loa Andersson <[e-mail]>
> Sent: Friday, February 21, 2025 11:26 AM
> To: Haoyu Song <[e-mail]>; Greg Mirsky <[e-mail]>; Dongjie (Jimmy) <jie.dong=[e-mail]>
> Cc: mpls <[e-mail]>
> Subject: Re: [mpls] Re: Potential MNA technical issue
> 
> Haoyu,
> 
> Are you saying that the PSD indicator should be specified in draft-ietf-mpls-mna-hdr?
> 
> /Loa
> 
> Den 21/02/2025 kl. 20:14, skrev Haoyu Song:
>> PSD and ISD are entangled here because the PSD indicator needs to be
>> specified in ISD header. I think it’s crucial to have a well-specified
>> PSD indicator in the MNA header draft. If it’s left unattended, we
>> won’t know the implications which might make the whole MNA fail. To
>> me, PSD is more extensible, flexible, and useful so I’d like to ensure
>> it will work fine with an enabling mechanism well defined ahead rather
>> than leaving it as an afterthought which might render PSD unusable.
>>
>> I also insist that a P-flag is sufficient, simple and straightforward.
>> Trying to use offset is a very bad idea which will introduce
>> unnecessary complexity to the parser and render many chips unusable
>> because they can’t support parsing this kind of header at all. We can
>> simply require that no other data can be inserted between BoS label
>> and PSD. If we really want to support PSD, we shouldn’t try to add any
>> artificial mechanism to the design.
>>
>> Best regards,
>>
>> Haoyu
>>
>> *From:*Greg Mirsky <[e-mail]>
>> *Sent:* Friday, February 21, 2025 9:04 AM
>> *To:* Dongjie (Jimmy) <jie.dong=[e-mail]>
>> *Cc:* mpls <[e-mail]>
>> *Subject:* [mpls] Re: Potential MNA technical issue
>>
>> Hi Jie,
>>
>> AFAICS, PSD is an optional mechanism to realize MNA functions.
>> Furthermore, it was sufficiently demonstrated that the proposed P-flag
>> in MNA Header is not sufficient to signal the presence of PSD in the
>> packet. Considering that, I believe that a note to optional use of PSD
>> in draft-ietf-mpls-mna-hdr and that detailed discussion of the
>> mechanism to signal its presence and format of a PSD are outside of
>> the scope of draft-ietf-mpls-mna-hdr would suffice.
>>
>> Regards,
>>
>> Greg
>>
>> On Thu, Feb 20, 2025 at 10:49 PM Dongjie (Jimmy)
>> <jie.dong=[e-mail]
>> <mailto:[e-mail]>> wrote:
>>
>>      Hi Adrian and Tony,
>>
>>      Since PSD has been acknowledged as needed for some types of MNA data
>>      and use cases, I'd agree with Adrian on making this explicit in
>>      section 5.2 of the MNA header draft.
>>
>>      Another open issue is where should the PSD indication mechanism be
>>      specified. To my understanding PSD indication is part of the general
>>      MNA solution and is orthogonal to the encoding of Post-stack data,
>>      thus it is more suitable to be covered in the MNA header draft.
>>
>>      During the interim this week we didn't get chance to discuss the
>>      possible PSD indication mechanisms. This may be considered as a
>>      remaining open technical issue for further discussion.
>>
>>      Best regards,
>>      Jie
>>
>>       > -----Original Message-----
>>       > From: Adrian Farrel <[e-mail]
>>      <mailto:[e-mail]>>
>>       > Sent: Friday, February 21, 2025 5:48 AM
>>       > To: 'Tony Li' <[e-mail] <mailto:[e-mail]>>
>>       > Cc: 'mpls' <[e-mail] <mailto:[e-mail]>>
>>       > Subject: [mpls] Re: Potential MNA technical issue
>>       >
>>       > No, I personally don't have a problem with that solution.
>>       > Others may have, I don't know.
>>       >
>>       > The text could, perhaps, be a little clearer in 5.2 to direct
>>      applications to use
>>       > PSD. Yeah, I know one could possibly work out that having a lot
>>      of LSEs is not
>>       > very wise (especially as we have a limit to the number of LSEs we
>>      can support
>>       > because of the size of the NASL). Just a few words of advice:
>>      nothing heavy.
>>       >
>>       > And the fixes for points 1 and 2.
>>       >
>>       > A
>>       >
>>       > -----Original Message-----
>>       > From: Tony Li <[e-mail]
>>      <mailto:[e-mail]>> On Behalf Of Tony Li
>>       > Sent: 20 February 2025 21:27
>>       > To: Adrian Farrel <[e-mail] <mailto:[e-mail]>>
>>       > Cc: mpls <[e-mail] <mailto:[e-mail]>>
>>       > Subject: Re: [mpls] Potential MNA technical issue
>>       >
>>       > [WG chair hat: off]
>>       >
>>       > Hi Adrian,
>>       >
>>       > I recall that we discussed this before and we reached the
>>      conclusion that
>>       > actions that needed more variable data should go the post-stack
>>      route. Do you
>>       > have a problem with that?
>>       >
>>       > Regards,
>>       > Tony
>>       >
>>       >
>>       > > On Feb 20, 2025, at 12:58 PM, Adrian Farrel - adrian at
>>      olddog.co.uk <http://olddog.co.uk/>
>>       > <[e-mail]
>>      <mailto:[e-mail]>> wrote:
>>       > >
>>       > > Hi all,
>>       > >
>>       > > I thought the virtual interim was useful in airing some opinions.
>>       > >
>>       > > I exchanged a few emails with Jie to try to better understand his
>>       > > concerns, and then Stewart and I sat down for a couple of hours to
>>       > > work through all of the possibilities.
>>       > >
>>       > > This is mainly thinking aloud.
>>       > >
>>       > > A big question surrounds how the NAS might be parsed by a non-
>>      MNA node.
>>       > >
>>       > > The first part of the question is "What happens if a non-MNA node
>>       > > encounters the MNA label?" Well, it shouldn't! The MNA label should
>>       > > only rise to the top of stack at nodes known to be MNA capable.
>>      But,
>>       > > if it does, the MNA label is an SPL, and processing unknown SPLs at
>>       > > the top of stack is well defined.
>>       > >
>>       > > The next part of this question is "What if part of the NSA
>>      looks like
>>       > > an SPL?" The most concerning case we have at the moment is if
>>      it looks
>>       > > like an ELI to a non-MNA node that searches ahead for an
>>      entropy label.
>>       > > This question is covered in the draft in two places:
>>       > > 6.1 tells us that Opcode 0 is not to be used. That means that LSE
>>       > > formats B and C can never be mistaken for bSPLs because they don't
>>       > > start with eight 0 bits.
>>       > > 4.4 tells us that format D LSEs must always start with a 1 so
>>      they can
>>       > > never be mistaken for bSPLs.
>>       > > So all good here.
>>       > >
>>       > > The last part of the question is "Suppose a (legacy) node does ECMP
>>       > > hashing by reading the first n labels on the stack?"
>>       > > Since it doesn't know about MNA, it will find Opcodes and ISD and
>>       > > treat them as labels.
>>       > > This is not a problem in itself, but if the ISD can vary from
>>      packet
>>       > > to packet in a flow, it can lead to packets taking different paths.
>>       > > This question is covered in section 5.2 which tells us to be
>>      careful
>>       > > which ISD bits are allowed to vary.
>>       > >
>>       > > But it was in re-reading 5.2 that Stewart and I had some worries.
>>       > >
>>       > > 1. The text says:
>>       > >       if a network action encodes data
>>       > >       that will change during packet forwarding
>>       > >    While this may be interesting for OAM, what is more
>>      interesting is
>>       > > when the
>>       > >    data is different on different packets in the same flow. So
>>       > > probably change
>>       > >    this to:
>>       > >       if a network action encodes data
>>       > >       that may be different on different packets in the same flow
>>       > >
>>       > > 2. s/Indicators those need/Indicators that need/
>>       > >
>>       > > 3. There are not many bits that are allowed to contain variable
>>      data.
>>       > >     This is a bit grim. We reckon that:
>>       > >     - No bits in a type B LSE can be variable
>>       > >     - Only 7 bits in a type C LSE can be variable
>>       > >     - Just 11 bits in a type D LSE can be variable
>>       > >     If you wanted to carry something like a time stamp (RFC
>>      8877) you
>>       > > need
>>       > > 32 bits
>>       > >     or even 64 bits. That would need 4 or 7 LSEs (BDDD or
>>       > BDDDDDD/BCDDDDD)
>>       > >     instead of 2 or 3 (BD or BDD/BCD).
>>       > >     There are some possible mitigations:
>>       > >     - Use an entropy label. This allows any implementation that
>>       > > supports entropy
>>       > >        labels to not hash. But:
>>       > >         * it costs two additional LSEs
>>       > >         * it doesn't help with implementations that don't support
>>       > > entropy labels
>>       > >     - Stop hashing when you reach an SPL.
>>       > >       This advice would work for new implementations, but it
>>      doesn't
>>       > > help with
>>       > >       existing implementations which will hash their way
>>      through into
>>       > > the NAS.
>>       > >     - Follow the draft and restrict where variable data is placed.
>>       > >         * Use lots of LSEs. Not a very good answer.
>>       > >         * Don't send much variable data. A bit of an unfortunate
>>       > > limitation.
>>       > >         * Put variable data post-stack.
>>       > >     - Decide that we don't care about legacy nodes. This is not
>>      ideal,
>>       > > but an
>>       > >       operator might know about the nodes in their network. If
>>      this is the
>>       > >       choice, then the document would need to be clear.
>>       > >     - Choose a behaviour based on knowledge of the nodes in the
>>      network
>>       > >       and the (potential) path of the LSP. This approach would
>>      require
>>       > >       capabilities to be advertised (perhaps alongside the RLD ).
>>       > >
>>       > > Cheers,
>>       > > Adrian
>>       > >
>>       > > _______________________________________________
>>       > > mpls mailing list -- [e-mail] <mailto:[e-mail]>
>>       > > To unsubscribe send an email to [e-mail]
>>      <mailto:[e-mail]>
>>       >
>>       > _______________________________________________
>>       > mpls mailing list -- [e-mail] <mailto:[e-mail]>
>>       > To unsubscribe send an email to [e-mail] <mailto:mpls-
>>      [e-mail]>
>>      _______________________________________________
>>      mpls mailing list -- [e-mail] <mailto:[e-mail]>
>>      To unsubscribe send an email to [e-mail] <mailto:mpls-
>>      [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]
> 

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