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

[Joel Halpern <[e-mail]>]

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]> 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
>>>     [e-mail]
>>>     >>
>>>     >>
>>>     >>
>>>     >>
>>>     >> _______________________________________________
>>>     >>
>>>     >>         mpls mailing list [e-mail]
>>>     >>
>>>     >>         To unsubscribe send an [e-mail]
>>>     >>
>>>     >>
>>>     >> _______________________________________________
>>>     >> mpls mailing list [e-mail]
>>>     >> To unsubscribe send an email [e-mail]
>>>     >
>>>
>>>     _______________________________________________
>>>     mpls mailing list [e-mail]
>>>     To unsubscribe send an email [e-mail]
>>>
>> _______________________________________________
>> mpls mailing list [e-mail]
>> To unsubscribe send an email [e-mail]
>