Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66AE9C1D5C49 for ; Fri, 28 Jun 2024 14:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.754 X-Spam-Level: X-Spam-Status: No, score=-1.754 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aTzjW3URdQ04 for ; Fri, 28 Jun 2024 14:26:09 -0700 (PDT) Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9508EC18DBBF for ; Fri, 28 Jun 2024 14:26:09 -0700 (PDT) Received: by mail-pl1-x62c.google.com with SMTP id d9443c01a7336-1f480624d10so7591935ad.1 for ; Fri, 28 Jun 2024 14:26:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719609968; x=1720214768; darn=ietf.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:sender:from:to:cc:subject:date:message-id:reply-to; bh=25UeKPRxu/vjOW86Mq5hGl3Kxjk2ksBeK/kbN7DN8rw=; b=WpaxOnA8GqpVpu7UZHKVsDu+J+te7eEI0pXS0K7eaY4Uj7iG9HWncKxHif2tSwRmFJ 1MnZvc0e0juWqw6lIAdMwTz1zWl9nfSqWRubtvncmoussWdxqhD6Bfgd+71IpusZ6akb SdORyZVSQOvFtMF2LKeJfEqLouvoiqqJdwDx+da6KZjpI3Gh8LCqiSyJg5cF34D2PiEx zRtwcyiMkSRl2LhSoxtMCqbOY0pw0hBDzaX0zmZVk4FSxrzfYw73UYaAtNipmZjJHug1 dXrioWMNCOk9kE3tMbBhKGmYux5c/Iz1qzEUqSgsbWcA00gSmjOgaknH1WIE6n7K7d3m CTyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719609968; x=1720214768; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=25UeKPRxu/vjOW86Mq5hGl3Kxjk2ksBeK/kbN7DN8rw=; b=UafnoWb7AKFpO8wDbNmh6eJ2KMZKGseKDltHQ4y3XhwCNYLeJAR93drN2EP3nYvV9c Jp9qxf3kQYMsoXfLWHef4v908YWks1zHH1Vy60OCmhCLiPHM+P4XFT9aIUnyciDX+tIW ucjsb3vsWy+RdbRZsSC6s0/oDmz/EDc7/A1d2Vv0zo/8k/iBHH2sJPiCYSx327GJJS1N OgiGzP9VPKxhQ9nNkhF6oAvt73uW56amQxiD2VrvQGwxeLSOWVpfbyYtiJVhdlYNYJqf DXv3NEOD6g+uUF89xux4vAtSRsQ1/ZWuavKj2iAEl/ua9KUALRtP5dxZH25pLB+Areaw Cq+g== X-Forwarded-Encrypted: i=1; AJvYcCW3R5Wyb7bhY7VujMfaM8HecWmvW4h38aQiUGRZxVxjCMqOtTSFJt1qivTKM3zRVyAXhja9kz6v/mU9gPoy X-Gm-Message-State: AOJu0YwMHsX7fQDH3DL4X9bsgy0j/q+JiCSwZAOisjfSeSO8MMMdVDwV KuveIp7qmEXCZPyHbxl9wjKd15HIxDi2rhVty+9jkOyerEmORVuD X-Google-Smtp-Source: AGHT+IFC+nFOtY7qa3PL1Hr6+wSHgZy7FpMum+XYPdX2f4gvfH/mS22Ps8/u6cQ6JMQui+hF8wZXdg== X-Received: by 2002:a17:902:e5cf:b0:1f6:fe0d:ad47 with SMTP id d9443c01a7336-1fa1d68be52mr202060745ad.62.1719609968045; Fri, 28 Jun 2024 14:26:08 -0700 (PDT) Received: from smtpclient.apple (c-73-93-167-4.hsd1.ca.comcast.net. [73.93.167.4]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-1fad304311csm9000415ad.31.2024.06.28.14.26.07 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Jun 2024 14:26:07 -0700 (PDT) Sender: Tony Li From: Tony Li Message-Id: <4567FBB8-CF23-4CA5-B4C1-8396BC83F81E@tony.li> Content-Type: multipart/alternative; boundary="Apple-Mail=_356B1B2B-2F23-4CDF-A7CD-7AE846F10E01" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Date: Fri, 28 Jun 2024 14:25:56 -0700 In-Reply-To: <23d95f69-355e-4b07-965e-618c2ac6effb@joelhalpern.com> To: Joel Halpern References: <554BBF53-649A-4DB3-876A-8BC772813646@tony.li> <7cb5252c-a3c5-4420-95fd-25a3cc740cd3@joelhalpern.com> <23d95f69-355e-4b07-965e-618c2ac6effb@joelhalpern.com> X-Mailer: Apple Mail (2.3774.600.62) Message-ID-Hash: TQSQOQIRTH66ZHFY6AVTLYQPMSAUVOCJ X-Message-ID-Hash: TQSQOQIRTH66ZHFY6AVTLYQPMSAUVOCJ X-MailFrom: tony1athome@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-mpls.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: mpls X-Mailman-Version: 3.3.9rc4 Precedence: list Subject: =?utf-8?q?=5Bmpls=5D_Re=3A_Example_of_MPLS_RLD_with_IOAM_Trace_in_PSD?= List-Id: Multi-Protocol Label Switching WG Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --Apple-Mail=_356B1B2B-2F23-4CDF-A7CD-7AE846F10E01 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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=E2=80=AFPM, Joel Halpern = wrote: >=20 > I agreed that the RLD issue affects both ISD and PSD. So RLD is not a = basis for deciding that we need PSD. >=20 > Yours, >=20 > Joel >=20 > On 6/28/2024 11:27 AM, Jaganbabu Rajamanickam wrote: >> The RLD issue is common to both ISD and PSD. >>=20 >> 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. >>=20 >> 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. >>=20 >> Thanx, >> Jags=20 >>=20 >> On Fri, Jun 28, 2024 at 8:46=E2=80=AFAM Joel Halpern = > 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=20= >>> include data that is part the bottom of stack indication. It is = still=20 >>> subject to the fast path data length limitation, even if it is PSD. =20= >>> (Yes, PSD is don't technically "labels". But it still needs to be = read=20 >>> and processed, as Tony Li as been pointing out.) >>>=20 >>> Yours, >>>=20 >>> Joel >>>=20 >>> 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=20 >>> >> to handle it. I don=E2=80=99t think it=E2=80=99s the obstacle = forbidding us to=20 >>> >> develop either ISD or PSD. >>> >> >>> >> Haoyu >>> >> >>> >> *From:* Joel Halpern > >>> >> *Sent:* Thursday, June 27, 2024 12:50 PM >>> >> *To:* Haoyu Song > >>> >> *Cc:* mpls > >>> >> *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=20 >>> >> implications of ISD. But you don't care about the RLD = implication of=20 >>> >> 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=E2=80=99s still possible that the ISD = can=E2=80=99t be=20 >>> >> supported. >>> >> 2. If exceeding the RLD limitation, there are two choices: = skip >>> >> it on incapable nodes or don=E2=80=99t use it. >>> >> >>> >> Haoyu >>> >> >>> >> *From:* Joel Halpern > >>> >> > >>> >> *Sent:* Thursday, June 27, 2024 11:39 AM >>> >> *To:* Haoyu Song > >>> >> > >>> >> *Cc:* mpls > = > >>> >> *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=E2=80=99s 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=E2=80=99t participate in the MNA processing, if = there=E2=80=99s any, can >>> >> safely forward the packet. In case all nodes must support = an >>> >> action to work, there=E2=80=99ll be a Yes or No decision = on applying >>> >> the action. With such provision, there=E2=80=99ll be no = performance >>> >> issue since no slow path processing is allowed and = possible. >>> >> >>> >> The bottom line is: we can=E2=80=99t 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=E2=80=99s no guarantee, so the control plane = discovery and >>> >> negotiation are needed to ensure the performance. >>> >> >>> >> Best, >>> >> >>> >> Haoyu >>> >> >>> >> *From:* Tony Li > >>> >> > *On Behalf Of *Tony Li >>> >> *Sent:* Thursday, June 27, 2024 10:37 AM >>> >> *To:* Rakesh Gandhi > >>> >> > >>> >> *Cc:* mpls > = > >>> >> *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=E2=80=99m still missing your point here. There are = cases that >>> >> work, there are cases that don=E2=80=99t. Are you trying = to say >>> >> something more? >>> >> >>> >> We can=E2=80=99t 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=E2=80=AFAM, Rakesh Gandhi >>> >> > 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=E2=80=AFAM Tony Li = > >>> >> wrote: >>> >> >>> >> [WG chair hat: off] >>> >> >>> >> Hi Rakesh, >>> >> >>> >> I=E2=80=99m missing some point that I think = you=E2=80=99re trying to=20 >>> >> make. >>> >> >>> >> Suppose that a node in this network only has an = RLD of >>> >> 64 octets (i.e., 16 LSE equivalents). Won=E2=80=99t= 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=E2=80=AFAM, Rakesh = Gandhi >>> >> > 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.=20 >>> >> = 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.=20 >>> >> = https://datatracker.ietf.org/doc/html/draft-gandhi-mpls-mna-ioam-dex-01 >>> >> = >>> >> >>> >> _______________________________________________ >>> >> mpls mailing list -- mpls@ietf.org = >>> >> To unsubscribe send an email to = mpls-leave@ietf.org >>> >> >>> >> >>> >> >>> >> >>> >> _______________________________________________ >>> >> >>> >> mpls mailing list --mpls@ietf.org >>> >> >>> >> To unsubscribe send an email tompls-leave@ietf.org = >>> >> >>> >> >>> >> _______________________________________________ >>> >> mpls mailing list -- mpls@ietf.org >>> >> To unsubscribe send an email to mpls-leave@ietf.org = >>> > >>>=20 >>> _______________________________________________ >>> mpls mailing list -- mpls@ietf.org >>> To unsubscribe send an email to mpls-leave@ietf.org = > _______________________________________________ > mpls mailing list -- mpls@ietf.org > To unsubscribe send an email to mpls-leave@ietf.org = --Apple-Mail=_356B1B2B-2F23-4CDF-A7CD-7AE846F10E01 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

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=E2=80=AFPM, Joel Halpern = <jmh@joelhalpern.com> 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=E2=80=AFAM Joel Halpern <jmh@joelhalpern.com> = 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=E2=80=99t think it=E2=80=99s the obstacle forbidding us to 
>> develop either = ISD or PSD.
>>
>> Haoyu
>>
>> = *From:* Joel Halpern <jmh@joelhalpern.com>
>> = *Sent:* Thursday, June 27, 2024 12:50 PM
>> *To:* Haoyu Song = <haoyu.song@futurewei.com>
>&g= t; *Cc:* mpls <mpls@ietf.org>
>> = *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=E2=80=99s = still possible that the ISD can=E2=80=99t be 
>> = supported.
>>      2. If exceeding the RLD = limitation, there are two choices: skip
>> =         it on incapable nodes or = don=E2=80=99t use it.
>>
>>     = Haoyu
>>
>>     *From:* Joel Halpern = <jmh@joelhalpern.com>
>> =     <mailto:jmh@joelhalpern.com>
>> =     *Sent:* Thursday, June 27, 2024 11:39 AM
>> =     *To:* Haoyu Song <haoyu.song@futurewei.com>
>&g= t;     <mailto:haoyu.song@futurewei.com>
>&g= t;     *Cc:* mpls <mpls@ietf.org> <mailto:mpls@ietf.org>
>> =     *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=E2=80=99s 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=E2=80=99t participate in = the MNA processing, if there=E2=80=99s any, can
>> =         safely forward the packet. In = case all nodes must support an
>> =         action to work, there=E2=80=99l= l be a Yes or No decision on applying
>> =         the action. With such = provision, there=E2=80=99ll be no performance
>> =         issue since no slow path = processing is allowed and possible.
>>
>> =         The bottom line is: we = can=E2=80=99t 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=E2=80=99s no guarantee, = so the control plane discovery and
>> =         negotiation are needed to = ensure the performance.
>>
>> =         Best,
>>
>> =         Haoyu
>>
>> =         *From:* Tony Li <tony1athome@gmail.com>
>> =         <mailto:tony1athome@gmail.com> *On Behalf = Of *Tony Li
>>         = *Sent:* Thursday, June 27, 2024 10:37 AM
>> =         *To:* Rakesh Gandhi <rgandhi.ietf@gmail.com>
>>=         <mailto:rgandhi.ietf@gmail.com>
>>=         *Cc:* mpls <mpls@ietf.org> <mailto:mpls@ietf.org>
>> =         *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=E2=80=99m still missing = your point here. There are cases that
>> =         work, there are cases that = don=E2=80=99t. Are you trying to say
>> =         something = more?
>>
>>         = We can=E2=80=99t 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
>>
>>
>>
>>
>>
>&g= t;             On = Jun 27, 2024, at 9:16=E2=80=AFAM, Rakesh Gandhi
>> =             = <rgandhi.ietf@gmail.com> = 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=E2=80=AFAM Tony Li <tony.li@tony.li>
>> =             = wrote:
>>
>> =             &n= bsp;   [WG chair hat: off]
>>
>> =             &n= bsp;   Hi Rakesh,
>>
>> =             &n= bsp;   I=E2=80=99m missing some point that I think you=E2=80=99r= e trying to 
>>= make.
>>
>> =             &n= bsp;   Suppose that a node in this network only has an RLD = of
>> =             &n= bsp;   64 octets (i.e., 16 LSE equivalents). Won=E2=80=99t = there be a
>> =             &n= bsp;   perfomance issue?
>>
>> =             &n= bsp;   It seems to me that the further down we push data, = the
>> =             &n= bsp;   more likely we are to run into = issues.
>>
>> =             &n= bsp;   = T
>>
>>
>>
>>
>>
>> =             &n= bsp;       On Jun 27, 2024, at 8:35=E2=80=AF= AM, Rakesh Gandhi
>> =             &n= bsp;       <rgandhi.ietf@gmail.com> = wrote:
>>
>> =             &n= bsp;       Hi WG,
>>
>> =             &n= bsp;       There were some comments = regarding how MPLS
>> =             &n= bsp;       Readable Label Depth (RLD) can = affect
>> =             &n= bsp;       pre-allocated IOAM trace data = carried in MNA PSD.
>>
>> =             &n= bsp;       Using an = example:
>>
>> =             &n= bsp;       For 10 hops with 10 LSEs = (sub-total 40 bytes)
>>
>> =             &n= bsp;       + 2 LSEs for MNA in MPLS header = (sub-total 48 bytes)
>>
>> =             &n= bsp;       + 2 words for PSD Headers = (sub-total 56 bytes)
>>
>> =             &n= bsp;       + 10 words of pre-allocated = IOAM space for
>> =             &n= bsp;       recording 4-byte timestamp = fraction (sub-total 96
>> =             &n= bsp;       bytes)
>>
>> =             &n= bsp;       + adding 4-byte IOAM Namespace = (sub-total 100
>> =             &n= bsp;       bytes or 25 = words)
>>
>> =             &n= bsp;       This means the _first midpoint_ = will *need
>> =             &n= bsp;       100-byte (or 25-word) RLD* to = record 32-bit
>> =             &n= bsp;       timestamp fraction in MNA IOAM = PSD for 10-hop SR
>> =             &n= bsp;       path, = right?
>>
>> =             &n= bsp;       If a midpoint node supports = *RLD of 128-byte*,
>> =             &n= bsp;       MPLS can support per-hop delay = measurement
>> =             &n= bsp;       use-case for 10-hop SR-path = using IOAM trace
>> =             &n= bsp;       option = (pre-allocated).
>>
>> =             &n= bsp;       Are we missing = anything?
>>
>> =             &n= bsp;       Thanks,
>>
>> =             &n= bsp;       Rakesh
>>
>> =             &n= bsp;       P.S.
>>
>> =             &n= bsp;       Following MNA use-case draft = lists IOAM
>> =             &n= bsp;       Pre-allocated trace option = use-case.
>>
>> =             &n= bsp;        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>
>>
>>= ; =             &n= bsp;       Following MNA draft defines a = PSD solution for
>> =             &n= bsp;       this = use-case.
>>
>> =             &n= bsp;        1. 
>> https://datatracker.ietf.org/doc/html/draf= t-gandhi-mpls-mna-ioam-dex-01
>> <https://datatracker.ietf.org/doc/html/draf= t-gandhi-mpls-mna-ioam-dex-01>
>>
>> = _______________________________________________
>> =             &n= bsp;       mpls mailing list -- mpls@ietf.org
>> =             &n= bsp;       To unsubscribe send an email = to mpls-leave@ietf.org
>>
>= ;>
>>
>>
>> =         = _______________________________________________
>>
>> =         mpls mailing list --mpls@ietf.org
>>
>> =         To unsubscribe send an = email tompls-leave@ietf.org
>>
&= gt;>
>> = _______________________________________________
>> mpls mailing = list -- mpls@ietf.org
>> To = unsubscribe send an email to mpls-leave@ietf.org
>

___= ____________________________________________
mpls mailing list = -- mpls@ietf.org
To unsubscribe send = an email to mpls-leave@ietf.org
_______________________________________________
mpls mailing list -- mpls@ietf.org
To = unsubscribe send an email to mpls-leave@ietf.org

= --Apple-Mail=_356B1B2B-2F23-4CDF-A7CD-7AE846F10E01--