[mpls] Re: Potential MNA technical issue - late follow up

[Haoyu Song <[e-mail]>]

Hi Greg,

You didn’t answer my question. What you ask is independent of PSD. It deals with the other two existing cases. If you have an answer for that, that’s exactly how it also applies to PSD.

Regards,
Haoyu

From: Greg Mirsky <[e-mail]>
Sent: Wednesday, April 30, 2025 1:19 PM
To: Haoyu Song <[e-mail]>
Cc: Loa Andersson <[e-mail]>; Dongjie (Jimmy) <jie.dong=[e-mail]>; mpls <[e-mail]>
Subject: Re: [mpls] Re: Potential MNA technical issue - late follow up

Hi Haoyu,
As I've stated several times, the ISD opcode with the offset from the BoS to the PSD header is the most general and flexible solution for handling all the cases at hand.

Regards,
Greg

On Wed, Apr 30, 2025 at 10:15 AM Haoyu Song <[e-mail]<mailto:[e-mail]>> wrote:
Greg,

You question seems to be unrelated and independent to PSD. While I’m not an expert on these use cases, I’m also curious if you are pointing out a real problem and if so how it is resolved.
If there’s no solution, then we have a stronger case to just use PSD to unify all these use cases.

Regards,
Haoyu
From: Greg Mirsky <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, April 30, 2025 12:58 PM
To: Haoyu Song <[e-mail]<mailto:[e-mail]>>
Cc: Loa Andersson <[e-mail]<mailto:[e-mail]>>; Dongjie (Jimmy) <jie.dong=[e-mail]<mailto:[e-mail]>>; mpls <[e-mail]<mailto:[e-mail]>>
Subject: Re: [mpls] Re: Potential MNA technical issue - late follow up

Hi Haoyu,
as I noted in the response to Loa, how do you propose that parsing operates on a P node if the PFN value is 0b01? Is it PW ACH or DetNet's d-ACH?

Regards,
Greg

On Wed, Apr 30, 2025 at 9:51 AM Haoyu Song <[e-mail]<mailto:[e-mail]>> wrote:
Greg,

As long as the headers are within the parsing window, it’s straightforward to read and parse them sequentially. But offset is not supported by many hardware parser.

Regards,
Haoyu
From: Greg Mirsky <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, April 29, 2025 10:08 PM
To: Haoyu Song <[e-mail]<mailto:[e-mail]>>
Cc: Loa Andersson <[e-mail]<mailto:[e-mail]>>; Dongjie (Jimmy) <jie.dong=[e-mail]<mailto:[e-mail]>>; mpls <[e-mail]<mailto:[e-mail]>>
Subject: Re: [mpls] Re: Potential MNA technical issue - late follow up

Hi Haoyu,
Thank you for your prompt response. Please find my follow-up notes below tagged GIM2>>.

Regards,
Greg


On Tue, Apr 29, 2025 at 6:59 PM Haoyu Song <[e-mail]<mailto:[e-mail]>> wrote:
Greg,

Please see inline.

Regards,
Haoyu

From: Greg Mirsky <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, April 29, 2025 12:04 PM
To: Haoyu Song <[e-mail]<mailto:[e-mail]>>
Cc: Loa Andersson <[e-mail]<mailto:[e-mail]>>; Dongjie (Jimmy) <jie.dong=[e-mail]<mailto:[e-mail]>>; mpls <[e-mail]<mailto:[e-mail]>>
Subject: Re: [mpls] Re: Potential MNA technical issue - late follow up

Hi Haoyu,
I have several questions below tagged GIM>>.

Regards
Greg

On Tue, Apr 29, 2025 at 8:05 AM Haoyu Song <[e-mail]<mailto:[e-mail]>> 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.
GIM>> As I understand it, PSD may have any of the scopes defined in Section 2.1 of draft-ietf-mpls-mna-fwk<https://datatracker.ietf.org/doc/draft-ietf-mpls-mna-fwk/>. Do you foresee a case when there are two MNA with different scopes?
HS>> IPv6 EH also have different scopes, but they can be listed sequentially back to back. I don’t think we need to indicate the scope of each PSD using ISD. The scope of PSD should be included or implied in the PSD itself.
GIM2>> Yes, that is possible, but, in my opinion, sub-optimal, as it results in parsing the whole PSD at each transient node if there's a single HBH PS AD mixed with several I2E ADs.


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.
GIM>> Do you have another mechanism that enables HBH and Select scopes for PSD for MPLS technologies that use their Post-Stack Header?
HS>> Simply read PSD and determine if it needs to be processed at each node.
GIM2>> As I noted above, that leads to excessive and unnecessary parsing of PSD. I believe that using Opcode with an explicit offset value provides a superior solution.

Regards,
Haoyu

-----Original Message-----
From: Loa Andersson <[e-mail]<mailto:[e-mail]>>
Sent: Sunday, April 27, 2025 12:24 AM
To: Haoyu Song <[e-mail]<mailto:[e-mail]>>; Greg Mirsky <[e-mail]<mailto:[e-mail]>>; Dongjie (Jimmy) <jie.dong=[e-mail]<mailto:[e-mail]>>
Cc: mpls <[e-mail]<mailto:[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]<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]>
> <mailto:[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]>
>     <mailto:[e-mail]<mailto:[e-mail]>>>
>      > Sent: Friday, February 21, 2025 5:48 AM
>      > To: 'Tony Li' <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>>
>      > Cc: 'mpls' <[e-mail]<mailto:[e-mail]> <mailto:[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]>
>     <mailto:[e-mail]<mailto:[e-mail]>>> On Behalf Of Tony Li
>      > Sent: 20 February 2025 21:27
>      > To: Adrian Farrel <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>>
>      > Cc: mpls <[e-mail]<mailto:[e-mail]> <mailto:[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/> <http://olddog.co.uk/>
>      > <[e-mail]<mailto:[e-mail]>
>     <mailto:[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]> <mailto:[e-mail]<mailto:[e-mail]>>
>      > > To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
>     <mailto:[e-mail]<mailto:[e-mail]>>
>      >
>      > _______________________________________________
>      > mpls mailing list -- [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>
>      > To unsubscribe send an email to [e-mail]<mailto:[e-mail]> <mailto:mpls-<mailto:mpls->
>     [e-mail]<mailto:[e-mail]>>
>     _______________________________________________
>     mpls mailing list -- [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>
>     To unsubscribe send an email to [e-mail]<mailto:[e-mail]> <mailto:mpls-<mailto:mpls->
>     [e-mail]<mailto:[e-mail]>>
>
>
> _______________________________________________
> mpls mailing list -- [e-mail]<mailto:[e-mail]>
> To unsubscribe send an email to [e-mail]<mailto:[e-mail]>

--
Loa Andersson
Senior MPLS Expert
Bronze Dragon Consulting
[e-mail]<mailto:[e-mail]>
[e-mail]<mailto:[e-mail]>