[mpls] Re: Example of MPLS RLD with IOAM Trace in PSD

[Loa Andersson <[e-mail]>]

Joel,

Excuse a naive questions. What is the RLD for PSD?

/Loa

Den 2024-06-28 kl. 00:12, skrev Haoyu Song:
>
> No. I just acknowledge the implication of RLD and figure out the ways 
> to handle it. I don’t think it’s the obstacle forbidding us to develop 
> either ISD or PSD.
>
> Haoyu
>
> *From:* Joel Halpern <[e-mail]>
> *Sent:* Thursday, June 27, 2024 12:50 PM
> *To:* Haoyu Song <[e-mail]>
> *Cc:* mpls <[e-mail]>
> *Subject:* Re: [mpls] Re: Example of MPLS RLD with IOAM Trace in PSD
>
> Hmmm.
>
> If I read folks pushing PSD correctly, you were objecting to the RLD 
> implications of ISD.  But you don't care about the RLD implication of 
> PSD?
>
> Yours,
>
> Joel
>
> On 6/27/2024 2:44 PM, Haoyu Song wrote:
>
>      1. Even one can put ISD in any place, depending on the ISD size
>         and the RLD, it’s still possible that the ISD can’t be supported.
>      2. If exceeding the RLD limitation, there are two choices: skip
>         it on incapable nodes or don’t use it.
>
>     Haoyu
>
>     *From:* Joel Halpern <[e-mail]>
>     <mailto:[e-mail]>
>     *Sent:* Thursday, June 27, 2024 11:39 AM
>     *To:* Haoyu Song <[e-mail]>
>     <mailto:[e-mail]>
>     *Cc:* mpls <[e-mail]> <mailto:[e-mail]>
>     *Subject:* Re: [mpls] Re: Example of MPLS RLD with IOAM Trace in PSD
>
>     I am missing something in your analysis.  With ISD, using the
>     knowledge of the RLD, the head end can put duplicate substacks in
>     various places so as to ensure visibility of the actions within
>     the RLD.  With PSD, that is simply not possible.  Meaning that if
>     the PSD needs to be processed by intermediate nodes with RLD
>     limitations, I can not figure out what remediation the hed end can
>     undertake to make it work.
>
>     Yours,
>
>     Joel
>
>     On 6/27/2024 2:15 PM, Haoyu Song wrote:
>
>         When an MNA action is applied on a data path, whether it’s ISD
>         or PSD, the operator needs to ensure the network will not run
>         into the RLD issue through control plane mechanisms. That is,
>         all the nodes that participate in the MNA processing will have
>         RLD large enough to cover the ISD/PSD, and some nodes that
>         won’t participate in the MNA processing, if there’s any, can
>         safely forward the packet. In case all nodes must support an
>         action to work, there’ll be a Yes or No decision on applying
>         the action. With such provision, there’ll be no performance
>         issue since no slow path processing is allowed and possible.
>
>         The bottom line is: we can’t guarantee that every node on an
>         existing network can support a PSD action (this applies to ISD
>         action as well). One can argue the likelihood, but still
>         there’s no guarantee, so the control plane discovery and
>         negotiation are needed to ensure the performance.
>
>         Best,
>
>         Haoyu
>
>         *From:* Tony Li <[e-mail]>
>         <mailto:[e-mail]> *On Behalf Of *Tony Li
>         *Sent:* Thursday, June 27, 2024 10:37 AM
>         *To:* Rakesh Gandhi <[e-mail]>
>         <mailto:[e-mail]>
>         *Cc:* mpls <[e-mail]> <mailto:[e-mail]>
>         *Subject:* [mpls] Re: Example of MPLS RLD with IOAM Trace in PSD
>
>         [WG chair hat: off]
>
>         Hi Rakesh,
>
>         We know that MNA can contain actions that affect the
>         forwarding of the packet. If a node finds a packet that has
>         MNA actions (ISD or PSD) that are not wholly inside of RLD,
>         then full forwarding information would not be available to the
>         fast path.  I see no alternative but to punt the packet to the
>         slow path. This will result in a performance issue. As long as
>         the packet is on the slow path already, you might as well
>         perform the associated functions.  Note that this is not IOAM
>         specific.
>
>         For a given IOAM request and a given set of RLDs on the path,
>         things will either have this performance issue or they will
>         not. This seems binary. And it seems like one can always
>         construct examples that will have the problem (just make the
>         IOAM request larger).  And there are also cases where things
>         will work just fine (just make RLD larger).
>
>         So I’m still missing your point here. There are cases that
>         work, there are cases that don’t. Are you trying to say
>         something more?
>
>         We can’t change the RLD in a brownfield network, so the best
>         that we can do in our designs is to try to ensure that MNA
>         information fits within the existing RLDs.
>
>         Regards,
>
>         Tony
>
>
>
>
>
>             On Jun 27, 2024, at 9:16 AM, Rakesh Gandhi
>             <[e-mail]> wrote:
>
>             Hi Tony,
>
>             In your example, that midpoint would not have updated the
>             IOAM data (timestamp in this case) due to the RLD
>             reachability. This just means, IOAM data is missing from
>             the node that it is not capable of.
>
>             P.S. RLD would be much higher than 64-byte in reality, but
>             ok for the sake of discussion.
>
>             P.S. Nodes (or operators) enabling the IOAM encapsulation
>             would have some knowledge of RLDs and could enable IOAM
>             accordingly.
>
>             thanks,
>
>             Rakesh
>
>             On Thu, Jun 27, 2024 at 11:54 AM Tony Li <[e-mail]>
>             wrote:
>
>                 [WG chair hat: off]
>
>                 Hi Rakesh,
>
>                 I’m missing some point that I think you’re trying to make.
>
>                 Suppose that a node in this network only has an RLD of
>                 64 octets (i.e., 16 LSE equivalents). Won’t there be a
>                 perfomance issue?
>
>                 It seems to me that the further down we push data, the
>                 more likely we are to run into issues.
>
>                 T
>
>
>
>
>
>                     On Jun 27, 2024, at 8:35 AM, Rakesh Gandhi
>                     <[e-mail]> wrote:
>
>                     Hi WG,
>
>                     There were some comments regarding how MPLS
>                     Readable Label Depth (RLD) can affect
>                     pre-allocated IOAM trace data carried in MNA PSD.
>
>                     Using an example:
>
>                     For 10 hops with 10 LSEs (sub-total 40 bytes)
>
>                     + 2 LSEs for MNA in MPLS header (sub-total 48 bytes)
>
>                     + 2 words for PSD Headers (sub-total 56 bytes)
>
>                     + 10 words of pre-allocated IOAM space for
>                     recording 4-byte timestamp fraction (sub-total 96
>                     bytes)
>
>                     + adding 4-byte IOAM Namespace (sub-total 100
>                     bytes or 25 words)
>
>                     This means the _first midpoint_ will *need
>                     100-byte (or 25-word) RLD* to record 32-bit
>                     timestamp fraction in MNA IOAM PSD for 10-hop SR
>                     path, right?
>
>                     If a midpoint node supports *RLD of 128-byte*,
>                     MPLS can support per-hop delay measurement
>                     use-case for 10-hop SR-path using IOAM trace
>                     option (pre-allocated).
>
>                     Are we missing anything?
>
>                     Thanks,
>
>                     Rakesh
>
>                     P.S.
>
>                     Following MNA use-case draft lists IOAM
>                     Pre-allocated trace option use-case.
>
>                      1. https://www.ietf.org/archive/id/draft-ietf-mpls-mna-usecases-10.html#name-in-situ-oam
>                         <https://www.ietf.org/archive/id/draft-ietf-mpls-mna-usecases-10.html#name-in-situ-oam>
>
>                     Following MNA draft defines a PSD solution for
>                     this use-case.
>
>                      1. https://datatracker.ietf.org/doc/html/draft-gandhi-mpls-mna-ioam-dex-01
>                         <https://datatracker.ietf.org/doc/html/draft-gandhi-mpls-mna-ioam-dex-01>
>
>                     _______________________________________________
>                     mpls mailing list -- [e-mail]
>                     To unsubscribe send an email to [e-mail]
>
>
>
>
>         _______________________________________________
>
>         mpls mailing list [e-mail]
>
>         To unsubscribe send an email [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]