[mpls] Re: Potential MNA technical issue

[Toerless Eckert <[e-mail]>]

I've tried to answer the question here:

https://mailarchive.ietf.org/arch/msg/mpls/PmUGhC7rLBNRyL-30jbGBSWbZ0w/

Aka: Likely "No" if we ONLY want to strictly follow the rules of rfc8296,
but likely "easy to build an extension in the MNA architecture", so it
looks like clean rfc8296 - even though we've stuffed PSD in.

Cheers
    Toerless

On Fri, Feb 21, 2025 at 09:21:44PM +0100, Loa Andersson wrote:
> Greg,
> 
> The question if MNA can occupy the slot immediately after the LSE with the
> BoS has been discussed before. I have heard different answers.
> 
> Let us ask the PALS and BIER chairs.
> 
> BIER and PALS chairs,
> 
> Can we occupy that slot? Do you have specifications that MUST be in that
> slot?
> 
> /Loa
> 
> Den 21/02/2025 kl. 20:50, skrev Greg Mirsky:
> > Hi Haoyu,
> > if you refer to PW and BIER technologies, then their respective headers
> > must immediately follow the BoS LSE. Now the proponents of PSD MNA, in
> > my opinion, have a choice - make PSD applicable to PW and BIER signaling
> > relative location of PSD, or explicitly exclude use of PSD from PW and
> > BIER. But even then, RLD concern remains for PSD.
> > 
> > Regards,
> > Greg
> > 
> > On Fri, Feb 21, 2025 at 11:43 AM Haoyu Song <[e-mail]
> > <mailto:[e-mail]>> wrote:
> > 
> >     Let’s consider these facts:____
> > 
> >      1. There have been several use cases that defines certain header
> >         structure after the MPLS label stack. ____
> >      2. There have been more than one use cases which claim to use the
> >         location for their header after the MPLS label stack. ____
> > 
> >     __ __
> > 
> >     Do they use any offset to indicate their location? No. the use case
> >     and potential conflicts can be resolved through control plane
> >     provisions. ____
> > 
> >     __ __
> > 
> >     If we truly want to support PSD, at least we should follow the same
> >     track. Anyway, PSD also has the potential to consolidate other use
> >     cases which need any data out side of the MPLS label stack. I think
> >     it’s very reasonable to keep the mechanism simple and practical. ____
> > 
> >     __ __
> > 
> >     Best regards,____
> > 
> >     Haoyu____
> > 
> >     __ __
> > 
> >     *From:*Haoyu Song <[e-mail]
> >     <mailto:[e-mail]>>
> >     *Sent:* Friday, February 21, 2025 11:35 AM
> >     *To:* Greg Mirsky <[e-mail] <mailto:[e-mail]>>
> >     *Cc:* Dongjie (Jimmy) <jie.dong=[e-mail]
> >     <mailto:[e-mail]>>; mpls <[e-mail]
> >     <mailto:[e-mail]>>
> >     *Subject:* [mpls] Re: Potential MNA technical issue____
> > 
> >     __ __
> > 
> >     It’s unprecedented to have any header structure to define the
> >     location of another header. Such complexity could only kill the use
> >     case. ____
> > 
> >     The RLD limitation can easily be taken into consideration through
> >     control plane means. ____
> > 
> >     (If you insist this, the ISD has the same concern)____
> > 
> >     But the complex data plane mechanism is a true killer to the PSD.____
> > 
> >     __ __
> > 
> >     Best regards,____
> > 
> >     Haoyu____
> > 
> >     __ __
> > 
> >     *From:*Greg Mirsky <[e-mail]
> >     <mailto:[e-mail]>>
> >     *Sent:* Friday, February 21, 2025 11:26 AM
> >     *To:* Haoyu Song <[e-mail]
> >     <mailto:[e-mail]>>
> >     *Cc:* Dongjie (Jimmy) <jie.dong=[e-mail]
> >     <mailto:jie.dong=[e-mail]>>; mpls <[e-mail]
> >     <mailto:[e-mail]>>
> >     *Subject:* Re: [mpls] Re: Potential MNA technical issue____
> > 
> >     __ __
> > 
> >     Hi Haoyu,____
> > 
> >     I cannot agree that "PSD and ISD are entangled here because the PSD
> >     indicator needs to be specified in ISD header. " As was
> >     demonstrated, to signal the presence and location of a PSD block
> >     safely, a flag in MNA HDR is not sufficient. MPLS networks include
> >     nodes that might have different RLD capability, and the mechanism
> >     that used to signal PSD must take that into consideration. AFAICS,
> >     that can be solved using ISD opcode, not MNA Header. Defining a new
> >     ISD opcode that signals presence and location of the PSD block would
> >     be logical in PSD-related draft.____
> > 
> >     __ __
> > 
> >     Regards,____
> > 
> >     Greg____
> > 
> >     __ __
> > 
> >     On Fri, Feb 21, 2025 at 11:14 AM Haoyu Song
> >     <[e-mail] <mailto:[e-mail]>> wrote:____
> > 
> >         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]
> >         <mailto:[e-mail]>>
> >         *Sent:* Friday, February 21, 2025 9:04 AM
> >         *To:* Dongjie (Jimmy) <jie.dong=[e-mail]
> >         <mailto:[e-mail]>>
> >         *Cc:* mpls <[e-mail] <mailto:[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:[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]
> 
> _______________________________________________
> mpls mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

-- 
---
[e-mail]