[mpls] Re: Potential MNA technical issue

[Greg Mirsky <[e-mail]>]

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]> 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]>
> > Sent: Friday, February 21, 2025 5:48 AM
> > 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
> > <[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]
>