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 C1708C151995 for ; Fri, 28 Jun 2024 18:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.105 X-Spam-Level: X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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=ham 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 PIigEeWlm4zN for ; Fri, 28 Jun 2024 18:02:29 -0700 (PDT) Received: from mail-yw1-x1134.google.com (mail-yw1-x1134.google.com [IPv6:2607:f8b0:4864:20::1134]) (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 7A346C14F73E for ; Fri, 28 Jun 2024 18:02:29 -0700 (PDT) Received: by mail-yw1-x1134.google.com with SMTP id 00721157ae682-64789495923so11089187b3.0 for ; Fri, 28 Jun 2024 18:02:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719622948; x=1720227748; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=c7OKXYDre3IVTj77/Y95pJYoKvIQgOZbXKZZ3L7Cy6g=; b=LfcU5w1q+OepTdb11kP6nkZfTo4VQxvuIjAgk75qhXobd8TnMtBnXqR/xqrid4IDNp qquollUw+4QPUJsq1VhyfGors0IcrP1wUgH+OB6P2FXIlZ4+DSIO62X5bnyynIP7VFat S+QEEUgNEw3gyhhStXULcAYmzZRUJL5/dXr/KrEK28r1f25NwOuSN2rm2qNGTYf8ppL3 lwcrFUfSJ2jrKHOJyhQWdzsMlMIyMHzygNTXHimVNwkZ7a+zcBKOCTnrpFRXfwjCACyS rdzmAAw9k+wAO514FQsxg4JpAGuVLI9VinP5+fUZiJBAjuFAJb3cvLxKC9ukZou3X+Rz MrOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719622948; x=1720227748; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=c7OKXYDre3IVTj77/Y95pJYoKvIQgOZbXKZZ3L7Cy6g=; b=mU/dLKp0gQK13/+bH5nUU3ViJOoO0MVYHu7yYPh0gXcS6ug5t8/sykagOLOV3MYN3t MbDV/Niwizq1BkAaLGKzVuzuSqbpZTWf6ME5qS6P52NgA7HMga2ff7nPu1I3TesH66kz 646+loSUWQ+GWMXpGo7hgKTnNdiF9oYgphBND8iE6/bRiO+jcOQPUtvpa5qMH+D+mdij A59cHc+7OuEsqLD0Q1hQEfrNFlLLk7Qn/HoUznmyoQJnOjmQxeVElJVmL8xB4bu2JLfQ /mqElKVH8PdEblnkx8nUCslvEOFpinxXwaksiU2UGceK2E6t4uuOfkKjsYos2oo2F4ZK 2knA== X-Forwarded-Encrypted: i=1; AJvYcCWMhtiOQ+fj+80fJ+RHiOVLIgdGmDs9zbQTu13P77jTrZkYXwVblYk/fdRP0Vi8TEkS9iAybaxNSJYN8tmi X-Gm-Message-State: AOJu0Yw3bE+FWMWnehfXnEkuITO5a11Q4+YG+by9mYEbChOnwHpcc2gZ o/+mJQdXMAFuJZXgN0TNFE3quk/EsUi8Cxv1/AmwfTpD+Ij8K+wO7ly7kQrHDIW/ppD9YT91DUm AJJ+mPR9g+RBoAGkKWaAELr0Wl8rM5w== X-Google-Smtp-Source: AGHT+IEoy2rvr7EOBXwBMRO/l8HsQn/7/liJSx+3SJr/b0B5OGx5AxWEAI4ComVhm+0kg7u9Y0MjLwuJzLjLvmZ35cg= X-Received: by 2002:a81:b64d:0:b0:643:d92c:697a with SMTP id 00721157ae682-643d92c6ccdmr184359977b3.33.1719622948284; Fri, 28 Jun 2024 18:02:28 -0700 (PDT) MIME-Version: 1.0 References: <554BBF53-649A-4DB3-876A-8BC772813646@tony.li> <7cb5252c-a3c5-4420-95fd-25a3cc740cd3@joelhalpern.com> <23d95f69-355e-4b07-965e-618c2ac6effb@joelhalpern.com> <4567FBB8-CF23-4CA5-B4C1-8396BC83F81E@tony.li> <8589af53-81cf-4187-be54-73673f468e1f@joelhalpern.com> <526B1E1D-A9F2-4254-9793-BA49229088DE@tony.li> In-Reply-To: From: Greg Mirsky Date: Fri, 28 Jun 2024 18:02:18 -0700 Message-ID: To: Haoyu Song Content-Type: multipart/alternative; boundary="000000000000faf413061bfcea75" Message-ID-Hash: 372YZBIYDZVF2G3BUYWC7KQSYNUTECVK X-Message-ID-Hash: 372YZBIYDZVF2G3BUYWC7KQSYNUTECVK X-MailFrom: gregimirsky@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: Joel Halpern Direct , 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: --000000000000faf413061bfcea75 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFPM Haoyu Song 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 > *Sent:* Friday, June 28, 2024 5:41 PM > *To:* Tony Li > *Cc:* Joel Halpern Direct ; mpls < > mpls@ietf.org> > *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 wi= th > 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=E2=80=AFPM Tony Li wrote: > > > > Can they be more specific about the types of IOAM that they care about? > > > > T > > > > > > On Jun 28, 2024, at 3:35=E2=80=AFPM, Joel Halpern > 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=E2=80=AFPM, Joel Halpern > 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 t= he > necessary Network Actions. > > > > Thanx, > > Jags > > > > 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 > 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 forbiddi= ng us to > >> 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 > >> 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 > >> > >> *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 P= SD > >> > >> 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 ap= plying > >> the action. With such provision, there=E2=80=99ll be no perfor= mance > >> 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 a= nd > >> 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 P= SD > >> > >> [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 sa= y > >> something more? > >> > >> We can=E2=80=99t change the RLD in a brownfield network, so th= e 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 > >> make. > >> > >> Suppose that a node in this network only has an RLD of > >> 64 octets (i.e., 16 LSE equivalents). Won=E2=80=99t th= ere 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 byte= s) > >> > >> + 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-0= 1 > >> < > 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.or= g > >> > >> > >> > >> > >> _______________________________________________ > >> > >> 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 > > > > _______________________________________________ > 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 > > --000000000000faf413061bfcea75 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Haoyu,
I don't think such a line of questi= oning is appropriate. As I understand it, in IETF everyone speaks out only = for himself/herself, unless when acting in the capacity of the Liaison Offi= cer.

Regards,
Greg

On Fri, Jun 28, = 2024 at 5:51=E2=80=AFPM Haoyu Song <haoyu.song@futurewei.com> wrote:

Hi Greg,

Do you make the statement on behalf of yourself or y= our customers or the operators at large?

Best regards,

Haoyu

=C2=A0

From: Greg Mirsky <gregimirsky@gmail.com>
Sent: Friday, June 28, 2024 5:41 PM
To: Tony Li <tony.li@tony.li>
Cc: Joel Halpern Direct <jmh.direct@joelhalpern.com>; mpls <mpls@ietf.org>
Subject: [mpls] Re: Example of MPLS RLD with IOAM Trace in PSD

=C2=A0

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 pack= et equipped with the IOAM header, e.g., IOAM Preallocated Trace or Incremen= tal Trace. Also, the Proof-of-Transit is out of scope.

=C2=A0

Regards,

Greg

=C2=A0

On Fri, Jun 28, 2024 at 5:24=E2=80=AFPM Tony Li <= tony.li@tony.li>= ; wrote:

=C2=A0

Can they be more specific about the types of IOAM th= at they care about?

=C2=A0

T

=C2=A0



On Jun 28, 2024, at 3:35=E2=80=AFPM, Joel Halpern &l= t;jmh.direc= t@joelhalpern.com> wrote:

=C2=A0

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:

=C2=A0

Hi Joel,

=C2=A0

I agree completely.=C2=A0 In fact, RLD suggests that= it is stronger to encode things in ISD whenver possible.

=C2=A0

That said, do you agree that we need to support IOAM= ?

=C2=A0

T

=C2=A0



On Jun 28, 2024, at 1:09=E2=80=AFPM, Joel Halpern <jmh@joelhalpern.com> wrote:

=C2=A0

I agreed tha= t the RLD issue affects both ISD and PSD.=C2=A0 So RLD is not a basis for d= eciding that we need PSD.

Yours,

Joel<= u>

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 o= ption. However, if the intermediate node cannot read the NAS, even when dup= licated, 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 n= ecessary Network Actions.

=C2=A0

Thanx,

Jags=C2=A0

=C2=A0

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.=C2=A0 In the PSD case, that needs to= =C2=A0
include data that is part the bottom of stack indication.=C2=A0 It is still= =C2=A0
subject to the fast path data length limitation, even if it is PSD.=C2=A0= =C2=A0
(Yes, PSD is don't technically "labels".=C2=A0 But it still n= eeds to be read=C2=A0
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 w= ays=C2=A0
>> to handle it. I don=E2=80=99t think it=E2=80=99s the obstacle forb= idding us to=C2=A0
>> 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>
>> *Cc:* mpls <= mpls@ietf.org>
>> *Subject:* Re: [mpls] Re: Example of MPLS RLD with IOAM Trace in P= SD
>>
>> Hmmm.
>>
>> If I read folks pushing PSD correctly, you were objecting to the R= LD=C2=A0
>> implications of ISD.=C2=A0 But you don't care about the RLD im= plication of=C2=A0
>> PSD?
>>
>> Yours,
>>
>> Joel
>>
>> On 6/27/2024 2:44 PM, Haoyu Song wrote:
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0 1. Even one can put ISD in any place, dep= ending on the ISD size
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 and the RLD, it=E2=80= =99s still possible that the ISD can=E2=80=99t be=C2=A0
>> supported.
>> =C2=A0=C2=A0=C2=A0=C2=A0 2. If exceeding the RLD limitation, there= are two choices: skip
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 it on incapable nodes o= r don=E2=80=99t use it.
>>
>> =C2=A0=C2=A0=C2=A0 Haoyu
>>
>> =C2=A0=C2=A0=C2=A0 *From:* Joel Halpern <jmh@joelhalpern.com>
>> =C2=A0=C2=A0=C2=A0 <mailto:jmh@joelhalpern.com>
>> =C2=A0=C2=A0=C2=A0 *Sent:* Thursday, June 27, 2024 11:39 AM
>> =C2=A0=C2=A0=C2=A0 *To:* Haoyu Song <haoyu.song@futurewei.com>
>> =C2=A0=C2=A0=C2=A0 <mailto:haoyu.song@futurewei.com>
>> =C2=A0=C2=A0=C2=A0 *Cc:* mpls <mpls@ietf.org> <mailto:mpls@ietf.org>
>> =C2=A0=C2=A0=C2=A0 *Subject:* Re: [mpls] Re: Example of MPLS RLD w= ith IOAM Trace in PSD
>>
>> =C2=A0=C2=A0=C2=A0 I am missing something in your analysis.=C2=A0 = With ISD, using the
>> =C2=A0=C2=A0=C2=A0 knowledge of the RLD, the head end can put dupl= icate substacks in
>> =C2=A0=C2=A0=C2=A0 various places so as to ensure visibility of th= e actions within
>> =C2=A0=C2=A0=C2=A0 the RLD.=C2=A0 With PSD, that is simply not pos= sible.=C2=A0 Meaning that if
>> =C2=A0=C2=A0=C2=A0 the PSD needs to be processed by intermediate n= odes with RLD
>> =C2=A0=C2=A0=C2=A0 limitations, I can not figure out what remediat= ion the hed end can
>> =C2=A0=C2=A0=C2=A0 undertake to make it work.
>>
>> =C2=A0=C2=A0=C2=A0 Yours,
>>
>> =C2=A0=C2=A0=C2=A0 Joel
>>
>> =C2=A0=C2=A0=C2=A0 On 6/27/2024 2:15 PM, Haoyu Song wrote:
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 When an MNA action is a= pplied on a data path, whether it=E2=80=99s ISD
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 or PSD, the operator ne= eds to ensure the network will not run
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 into the RLD issue thro= ugh control plane mechanisms. That is,
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 all the nodes that part= icipate in the MNA processing will have
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RLD large enough to cov= er the ISD/PSD, and some nodes that
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 won=E2=80=99t participa= te in the MNA processing, if there=E2=80=99s any, can
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 safely forward the pack= et. In case all nodes must support an
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 action to work, there= =E2=80=99ll be a Yes or No decision on applying
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the action. With such p= rovision, there=E2=80=99ll be no performance
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 issue since no slow pat= h processing is allowed and possible.
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The bottom line is: we = can=E2=80=99t guarantee that every node on an
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 existing network can su= pport a PSD action (this applies to ISD
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 action as well). One ca= n argue the likelihood, but still
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 there=E2=80=99s no guar= antee, so the control plane discovery and
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 negotiation are needed = to ensure the performance.
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Best,
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Haoyu
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *From:* Tony Li <tony1athome@gmail.c= om>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:tony1athome@gmail.com>= ; *On Behalf Of *Tony Li
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *Sent:* Thursday, June = 27, 2024 10:37 AM
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *To:* Rakesh Gandhi <= ;rgandhi.ietf@g= mail.com>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:rgandhi.ietf@gmail.com&= gt;
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *Cc:* mpls <mpls@ietf.org> <mailt= o:mpls@ietf.org><= br> >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *Subject:* [mpls] Re: E= xample of MPLS RLD with IOAM Trace in PSD
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [WG chair hat: off]
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Hi Rakesh,
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 We know that MNA can co= ntain actions that affect the
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 forwarding of the packe= t. If a node finds a packet that has
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 MNA actions (ISD or PSD= ) that are not wholly inside of RLD,
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 then full forwarding in= formation would not be available to the
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 fast path.=C2=A0 I see = no alternative but to punt the packet to the
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 slow path. This will re= sult in a performance issue. As long as
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the packet is on the sl= ow path already, you might as well
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 perform the associated = functions.=C2=A0 Note that this is not IOAM
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 specific.
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 For a given IOAM reques= t and a given set of RLDs on the path,
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 things will either have= this performance issue or they will
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 not. This seems binary.= And it seems like one can always
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 construct examples that= will have the problem (just make the
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 IOAM request larger).= =C2=A0 And there are also cases where things
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 will work just fine (ju= st make RLD larger).
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 So I=E2=80=99m still mi= ssing your point here. There are cases that
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 work, there are cases t= hat don=E2=80=99t. Are you trying to say
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 something more?
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 We can=E2=80=99t change= the RLD in a brownfield network, so the best
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 that we can do in our d= esigns is to try to ensure that MNA
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 information fits within= the existing RLDs.
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Regards,
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Tony
>>
>>
>>
>>
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= On Jun 27, 2024, at 9:16=E2=80=AFAM, Rakesh Gandhi
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= <rgandhi.ie= tf@gmail.com> wrote:
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= Hi Tony,
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= In your example, that midpoint would not have updated the
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= IOAM data (timestamp in this case) due to the RLD
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= reachability. This just means, IOAM data is missing from
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= the node that it is not capable of.
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= P.S. RLD would be much higher than 64-byte in reality, but
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= ok for the sake of discussion.
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= P.S. Nodes (or operators) enabling the IOAM encapsulation
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= would have some knowledge of RLDs and could enable IOAM
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= accordingly.
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= thanks,
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= Rakesh
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= On Thu, Jun 27, 2024 at 11:54=E2=80=AFAM Tony Li <tony.li@tony.li>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= wrote:
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 [WG chair hat: off]
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Hi Rakesh,
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 I=E2=80=99m missing some point that I think you=E2= =80=99re trying to=C2=A0
>> make.
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Suppose that a node in this network only has an RL= D of
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 64 octets (i.e., 16 LSE equivalents). Won=E2=80=99= t there be a
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 perfomance issue?
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 It seems to me that the further down we push data,= the
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 more likely we are to run into issues.
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 T
>>
>>
>>
>>
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 On Jun 27, 2024, at 8:35= =E2=80=AFAM, Rakesh Gandhi
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <rgandhi.ietf@gmail.com> wrote:=
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Hi WG,
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 There were some comments r= egarding how MPLS
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Readable Label Depth (RLD)= can affect
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 pre-allocated IOAM trace d= ata carried in MNA PSD.
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Using an example:
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 For 10 hops with 10 LSEs (= sub-total 40 bytes)
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 + 2 LSEs for MNA in MPLS h= eader (sub-total 48 bytes)
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 + 2 words for PSD Headers = (sub-total 56 bytes)
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 + 10 words of pre-allocate= d IOAM space for
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 recording 4-byte timestamp= fraction (sub-total 96
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 bytes)
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 + adding 4-byte IOAM Names= pace (sub-total 100
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 bytes or 25 words)
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 This means the _first midp= oint_ will *need
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 100-byte (or 25-word) RLD*= to record 32-bit
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 timestamp fraction in MNA = IOAM PSD for 10-hop SR
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 path, right?
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If a midpoint node support= s *RLD of 128-byte*,
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 MPLS can support per-hop d= elay measurement
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 use-case for 10-hop SR-pat= h using IOAM trace
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 option (pre-allocated). >>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Are we missing anything? >>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Thanks,
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Rakesh
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 P.S.
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Following MNA use-case dra= ft lists IOAM
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Pre-allocated trace option= use-case.
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1.=C2=A0
>>=C2=A0https://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> >>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Following MNA draft define= s a PSD solution for
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 this use-case.
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1.=C2=A0
>>=C2=A0https://datatracker.ietf.org/doc/h= tml/draft-gandhi-mpls-mna-ioam-dex-01
>> <https://datatracker.ietf.org/doc/ht= ml/draft-gandhi-mpls-mna-ioam-dex-01>
>>
>> _______________________________________________
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 mpls mailing list --=C2=A0= mpls@ietf.org
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 To unsubscribe send an ema= il to=C2=A0mpls-le= ave@ietf.org
>>
>>
>>
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 _______________________= ________________________
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 mpls mailing list --mpls@ietf.org
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 To unsubscribe send an = email=C2=A0tompl= s-leave@ietf.org
>>
>>
>> _______________________________________________
>> mpls mailing list --=C2=A0mpls@ietf.org
>> To unsubscribe send an email to=C2=A0mpls-leave@ietf.org
>

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

_______________________________________________
mpls mailing list --=C2=A0= mpls@ietf.org
To unsubscribe send an email to=C2=A0mpls-leave@ietf.org

=C2=A0

=C2=A0

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

--000000000000faf413061bfcea75--