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

[Joel Halpern <[e-mail]>]

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]>
> *Sent:* Thursday, June 27, 2024 11:39 AM
> *To:* Haoyu Song <[e-mail]>
> *Cc:* mpls <[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]
>