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

[Joel Halpern <[e-mail]>]

I agreed that the RLD issue affects both ISD and PSD.  So RLD is not a 
basis for deciding that we need PSD.

Yours,

Joel

On 6/28/2024 11:27 AM, Jaganbabu Rajamanickam wrote:
> The RLD issue is common to both ISD and PSD.
>
> There was an argument that, in the case of ISD, duplicating the NAS is 
> an option. However, if the intermediate node cannot read the NAS, even 
> when duplicated, it results in the same predicament.
>
> In my opinion, it is imperative that the node which inserts the NAS 
> (ISD or PSD) MUST ensure that the intermediate node is capable of 
> processing the necessary Network Actions.
>
> Thanx,
> Jags
>
> On Fri, Jun 28, 2024 at 8:46 AM Joel Halpern <[e-mail]> wrote:
>
>     Readable Label Depth is as far as I know the amount of header that
>     the
>     device can process in the fast path.  In the PSD case, that needs to
>     include data that is part the bottom of stack indication.  It is
>     still
>     subject to the fast path data length limitation, even if it is PSD.
>     (Yes, PSD is don't technically "labels".  But it still needs to be
>     read
>     and processed, as Tony Li as been pointing out.)
>
>     Yours,
>
>     Joel
>
>     On 6/28/2024 4:30 AM, Loa Andersson wrote:
>     > 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]
>     >
>
>     _______________________________________________
>     mpls mailing list -- [e-mail]
>     To unsubscribe send an email to [e-mail]
>