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

[Greg Mirsky <[e-mail]>]

Hi Tony,
wholeheartedly agree with you, that would be invaluable. Do I hear someone
say "Poll"?

Regards,
Greg

On Fri, Jun 28, 2024 at 5:45 PM Tony Li <[e-mail]> wrote:

>
> Hi Greg,
>
> That’s exactly what I’m trying to ascertain, preferably with direct input
> from impartial operators.
>
> T
>
>
> On Jun 28, 2024, at 5:41 PM, Greg Mirsky <[e-mail]> wrote:
>
> 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]
>>
>
>