[mpls] Re: Potential MNA technical issue

[Tianran Zhou <[e-mail]>]

Yes, I agree with Haoyu, PSD should not depend on ISD.
ISD is optional and really useless. Only to meet the old constrained and legacy devices, it introduces a lot of complexity, while loss the flexibility and extensibility.
I do not think ISD will ever be deployed.
So I would suggest to make ISD as an experimental solution, and PSD as standard track.

Tianran

From: Haoyu Song [mailto:[e-mail]]
Sent: Saturday, February 22, 2025 3:14 AM
To: Greg Mirsky <[e-mail]>; Dongjie (Jimmy) <jie.dong=[e-mail]>
Cc: mpls <[e-mail]>
Subject: [mpls] Re: Potential MNA technical issue

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:jie.dong=[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]>