[mpls] Re: PSD technical issues

[Haoyu Song <[e-mail]>]

Jie,

I think what you proposed is clean and ensure the long term evolution and protocol simplicity.
Fortunately we don't have many existing cases now (3 as far as I know) to deal with and two of them are still at the infancy stage. So it's not too late to do this.

Regards,
Haoyu

-----Original Message-----
From: Dongjie (Jimmy) <[e-mail]>
Sent: Wednesday, April 30, 2025 10:52 AM
To: Joel Halpern <[e-mail]>; Haoyu Song <[e-mail]>; Loa Andersson <[e-mail]>; Greg Mirsky <[e-mail]>
Cc: mpls <[e-mail]>
Subject: RE: [mpls] Re: PSD technical issues

Hi Joel and Haoyu,

Regarding the discussion on whether offset is needed or not, I used to make one comment to the list: https://mailarchive.ietf.org/arch/msg/mpls/zm3srJh01eKZaCXkpuDQmHcSiBI/

If we really want to make MNA a unified enhancement to MPLS data plane, we may want to consider making PSD a generalized approach for all post stack information, then PSD always follows the bottom of stack directly, and there would be no need of offset.

Best regards,
Jie

> -----Original Message-----
> From: Joel Halpern <[e-mail]>
> Sent: Wednesday, April 30, 2025 10:07 AM
> To: Haoyu Song <[e-mail]>; Loa Andersson <[e-mail]>;
> Greg Mirsky <[e-mail]>; Dongjie (Jimmy)
> <[e-mail]>
> Cc: mpls <[e-mail]>
> Subject: Re: [mpls] Re: PSD technical issues
>
> I am not sure I am properly understanding your questions.  I wil try
> to provide answers to what I think you are asking in line, marked
> <jmh></jmh>
>
> Yours,
>
> Joel
>
> On 4/29/2025 9:54 PM, Haoyu Song wrote:
> > We have discussed this before. There should be some ways but using
> > offset is
> a bad one.
> > Can anybody give me an example that any existing header uses the
> > offset
> mechanism? Typically for packet processing, all the header data are
> sequentially read up to a point and the data will be used to
> reassemble the packet at the egress. Skipping some part of the header may cause data loss.
> And existing hardware parser can't support parsing headers using
> offset. Okay, a software solution may be able to handle the offset,
> but in the MNA case, there are some other implications:
> <jmh>It is nice to say you don't like offset, but we need some means,
> and you have not offered an alternative suggestion.  Unless you want
> us to give up on PSD, the offset seems needed for multiple cases.
> </jmh>
> > The offset is mutable in at least three possible cases:
> > 1. New ISD substack needs to be replicated due to newly pushed
> > labels. The
> offset needs to be recalculated.
> <jmh>The offset is from the bottom of the stack.  I had wanted the
> offset to be from the opcode itself, but the problems of stack
> manipulation were pointed out, and we agreed that offset from the BoS
> would work, and is stable.  I know of no case in what that needs ajustment.
> > 2. An existing ISD substack needs to be reinserted into the label
> > stack
> because it's exposed at the top. The offset needs to be recalculated.
> <jmh> When an ISD hop-by-hop option is exposed and removed, there is
> no need to reinsert it.  There is already another copy lower down in
> the stack.  That is part of the rules for constructing a label stack
> with hop-by-hop ISD when the combination exceeds the RLD.  And even if
> one needed to reinsert for some as-yet-unforseen reason, sinc ethe
> offset is from the BoS, there is no need to adjust it. </jmh>
> > 3. If some data are allowed between the label stack and PSD, then
> > any data
> length change there will also cause the change of offset.
> > Maintaining the offset is an extra burden and any mistake will have
> disastrous consequence.
> <jmh>There are no known cases where the data after the bottom of not
> defined by the PSD draft changes length in flight. </jmh>
> >
> > Also, I asked a question before, but nobody answered me. We know
> > there are
> 1+ use cases that all claim the location immediately after the label
> 1+ stack. Have
> they considered the issue you asked about?
> > If not, why? If yes, how it's resolved? Perhaps we can gain some
> > experience
> here for our problem.
> <jmh>The existing solutions recognize the overlap cases, and each deal
> with them in their own fashion.  They have certain advantages we do
> not.  For example, the pseudowire control word only needs to be
> understood by the egress node.  But we are not free to redesign other
> protocols to suit our desires. </jmh>
> >
> > Best regards,
> > Haoyu
> >
> > -----Original Message-----
> > From: Joel Halpern <[e-mail]>
> > Sent: Tuesday, April 29, 2025 11:30 AM
> > To: Haoyu Song <[e-mail]>; Loa Andersson
> > <[e-mail]>; Greg Mirsky <[e-mail]>; Dongjie (Jimmy)
> > <jie.dong=[e-mail]>
> > Cc: mpls <[e-mail]>
> > Subject: Re: [mpls] Re: PSD technical issues
> >
> > If you do not allow for an offset, how will intermediate nodes find
> > the PSD in
> the case that there is other information between the bottom of the
> stack and the MNA PSD?
> >
> > Yours,
> >
> > Joel
> >
> > On 4/29/2025 11:05 AM, Haoyu Song wrote:
> >> Hi Loa,
> >>
> >> I don't know why we need two PSD blocks with two headers. I think
> >> if we
> have two MNAs using PSD, they should be put together.
> >>
> >> Again, I object the idea of using offset at all. Such unprecedented
> >> header
> encoding approach introduces non-linear behavior to the packet parser
> and processing which will be difficult to support.
> >>
> >> Regards,
> >> Haoyu
> >>
> >> -----Original Message-----
> >> From: Loa Andersson <[e-mail]>
> >> Sent: Sunday, April 27, 2025 12:24 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 - late follow
> >> up
> >>
> >> Haoyu,
> >>
> >> A question on the second paragraph below.
> >>
> >> Den 22/02/2025 kl. 03: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.
> >> Let us assume that two PSD blocks, each with a PS-HDR of its own.
> >>
> >> By setting the P-flag you''ll find the first nice and easy.
> >>
> >> Don't you need OpCode + Offset to find the second.
> >>
> >> /Loa
> >>> 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]
> >>
> >> _______________________________________________
> >> mpls mailing list -- [e-mail]
> >> To unsubscribe send an email to [e-mail]