[mpls] Re: PSD technical issues

[Haoyu Song <[e-mail]>]

I think we should only consider the existing cases one by one. For the pseudo wire control word example, if it's only accessed at egress node, then PSD can be located before it. For other cases, if the data needs to be accessed on intermediate nodes, they must be able to be identified. We just follow the normal sequential parsing until the PSD are found.
Another simple solution is to make these competing cases mutual exclusive, or obsolete the competing cases and unify them with PSD MNA.

Regards,
Haoyu

-----Original Message-----
From: Joel Halpern <[e-mail]>
Sent: Tuesday, April 29, 2025 10:07 PM
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

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