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

[Greg Mirsky <[e-mail]>]

Hi Haoyu,
I don't think such a line of questioning is appropriate. As I understand
it, in IETF everyone speaks out only for himself/herself, unless when
acting in the capacity of the Liaison Officer.

Regards,
Greg

On Fri, Jun 28, 2024 at 5:51 PM Haoyu Song <[e-mail]> wrote:

> Hi Greg,
>
> Do you make the statement on behalf of yourself or your customers or the
> operators at large?
>
> Best regards,
>
> Haoyu
>
>
>
> *From:* Greg Mirsky <[e-mail]>
> *Sent:* Friday, June 28, 2024 5:41 PM
> *To:* Tony Li <[e-mail]>
> *Cc:* Joel Halpern Direct <[e-mail]>; mpls <
> [e-mail]>
> *Subject:* [mpls] Re: Example of MPLS RLD with IOAM Trace in PSD
>
>
>
> Hi Tony,
>
> As I understand it, the interest is in the IOAM-DEX, not any of the
> options that collect telemetry information in the data packet equipped with
> the IOAM header, e.g., IOAM Preallocated Trace or Incremental Trace. Also,
> the Proof-of-Transit is out of scope.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Fri, Jun 28, 2024 at 5:24 PM Tony Li <[e-mail]> wrote:
>
>
>
> Can they be more specific about the types of IOAM that they care about?
>
>
>
> T
>
>
>
>
>
> On Jun 28, 2024, at 3:35 PM, Joel Halpern <[e-mail]>
> wrote:
>
>
>
> Yes, talking to my colleagues who deal with OAM aspects,they tell me we
> have use for IOAM.
>
> Yours,
>
> Joel
>
> On 6/28/2024 5:25 PM, Tony Li wrote:
>
>
>
> Hi Joel,
>
>
>
> I agree completely.  In fact, RLD suggests that it is stronger to encode
> things in ISD whenver possible.
>
>
>
> That said, do you agree that we need to support IOAM?
>
>
>
> T
>
>
>
>
>
> On Jun 28, 2024, at 1:09 PM, Joel Halpern <[e-mail]>
> <[e-mail]> wrote:
>
>
>
> 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]
>
> _______________________________________________
> 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]
>
>