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

[Greg Mirsky <[e-mail]>]

I think that what Tony points out is that the case when ISD with the
indication of PSD AD is within RLD boundary while that PSD AD is not
(whether all or only partially). Such situation is even more likely with
IOAM Preallocated Trace Option-Type. As a result, packets equipped with
PSD-based IOAM may cause forwarding delays and, possibly, re-ordering.
Hence a question How PSD solution mitigates that scenario? I've
read draft-jags-mpls-ps-mna-hdr but couldn't find any recommendation to
that matter.

Regards,
Greg

On Thu, Jun 27, 2024 at 11:15 AM Haoyu Song <[e-mail]>
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]> *On Behalf Of *Tony Li
> *Sent:* Thursday, June 27, 2024 10:37 AM
> *To:* Rakesh Gandhi <[e-mail]>
> *Cc:* mpls <[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.
>
>    -
>    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.
>
>    -
>    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 to [e-mail]
>