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

Haoyu Song <haoyu.song@futurewei.com> Sat, 29 June 2024 00:51 UTC

Return-Path: <haoyu.song@futurewei.com>
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 6D27EC151539 for <mpls@ietfa.amsl.com>; Fri, 28 Jun 2024 17:51:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=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 (1024-bit key) header.d=futurewei.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 6ypxKt1YI1tQ for <mpls@ietfa.amsl.com>; Fri, 28 Jun 2024 17:51:01 -0700 (PDT)
Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2097.outbound.protection.outlook.com [40.107.223.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07BB6C14F712 for <mpls@ietf.org>; Fri, 28 Jun 2024 17:51:00 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IWmZM005llwKG4WvcKMnrOMNVUNXpEbwTZO0UiAIT8WgiaOHW3h6NDLplmJqPBwXtnoUiuFyG6c+DYyoDLO0r/U+cKFK2PHCuGLb6K78oUpVe3N6zWSAFOaOtzQo6FoB80MNdC7kKkGWSdjxuWHL+HihqRyAf2P9dw5tOd5O8nfHtKbOLu2uSKLisTiXGM0eUBRUtm4mGP9X4F3Iqg+DQuPaWb+IMyqf37OHvCTyqOtNYSDzbyjLSk6gdEb890DEAegh4W3agk75fZCbYcgcSoCTkPNLOT+DHq3cZ3NXdGm48aiiHzdiBnfnBeazjq8nmpkNdgxA99eTY8ZdkDyw+Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=bbQxcSFsYW0axkgnpsLLS3ReaaV0YenE9VqFbMsR2T0=; b=nrwkZQNXbCuepXbu3xHpDUFWtOA7h2obJPbIwyDhUzizsR/eNTEtkXvBvJZ9ROCfOeaw9ShG+wgC+YKaR/hhRoNvxV0z+CjWPQfT1JLUp3C/n9EYNLY+MkVFcLNXyaa7x0hh/aHPklhKSjTV6YsRu+ZImSrllsEZKV8OmGDxTwOILWYZ8eGu4ZC6+NCccsNSHSfP+1PKL5b5wT53s2sEDPvDS2ggG+zjzgWvfjFeuoQEXusVrZdUYTj8UBK7oUNijJRJwVdufQLu7qr4QC72AqMewoz+5Db+f3g5LFHJJLMqPrS5AYAvuXleqyhZFjgK7EgGOcl3sPIc9jhjEI9IbA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bbQxcSFsYW0axkgnpsLLS3ReaaV0YenE9VqFbMsR2T0=; b=NfRJ3vWSGNTXl7MlQb1U9POCHVqRHXayXcn454WIo1PCbAz6Ot58X1Yvl/Imbmp2PSi85hIsm5IH1EUNPEnqdNu9AjLRcuumOO8M2PnBZ3i1a/x/SXq5GYoq65WPnaYKSUr/HEa5Demog7LzfyCqK70ybIOC39rQZrjutuO75NM=
Received: from BY3PR13MB4787.namprd13.prod.outlook.com (2603:10b6:a03:357::13) by CH0PR13MB4668.namprd13.prod.outlook.com (2603:10b6:610:ca::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7719.28; Sat, 29 Jun 2024 00:50:56 +0000
Received: from BY3PR13MB4787.namprd13.prod.outlook.com ([fe80::cb14:3d5c:d948:207b]) by BY3PR13MB4787.namprd13.prod.outlook.com ([fe80::cb14:3d5c:d948:207b%4]) with mapi id 15.20.7698.025; Sat, 29 Jun 2024 00:50:56 +0000
From: Haoyu Song <haoyu.song@futurewei.com>
To: Greg Mirsky <gregimirsky@gmail.com>, Tony Li <tony.li@tony.li>
Thread-Topic: [mpls] Re: Example of MPLS RLD with IOAM Trace in PSD
Thread-Index: AQHayKpTj5hpIHjxlkyjIuuJpRKf5rHbyWEAgAAWa4CAAAWLwIAAC8kAgAAAP6CAABOSgIAAJ0SAgACtSICAAEdngIAALQkAgABO8wCAABVRAIAAE10AgAAeT4CAAATVgIAAAiCQ
Date: Sat, 29 Jun 2024 00:50:56 +0000
Message-ID: <BY3PR13MB4787775561259447275654C89AD12@BY3PR13MB4787.namprd13.prod.outlook.com>
References: <CAMZsk6cT-AZ8Dswd37Owu+Bhte=jR-3BmaA6JA7ftQmLgUQ5RQ@mail.gmail.com> <554BBF53-649A-4DB3-876A-8BC772813646@tony.li> <CAMZsk6esOb38twqWNAtLhtOoRSufqadhiYtGBLUFPC-dd-zrvg@mail.gmail.com> <E80AE688-87C3-423F-97E0-0832EB96275F@tony.li> <BY3PR13MB47871DDF8C9E53AA5F782AC59AD72@BY3PR13MB4787.namprd13.prod.outlook.com> <b5f4eef5-1bb1-4e02-bafc-70be70705bd5@joelhalpern.com> <BY3PR13MB4787B139A5D244002DB342BB9AD72@BY3PR13MB4787.namprd13.prod.outlook.com> <7cb5252c-a3c5-4420-95fd-25a3cc740cd3@joelhalpern.com> <BY3PR13MB47870E7FFECC993380CF54269AD72@BY3PR13MB4787.namprd13.prod.outlook.com> <dd5c3b8c-9e5e-4098-8dc3-5a3c9a255060@pi.nu> <c7fb6f16-fcb3-442d-8589-ccc711ed0b65@joelhalpern.com> <CAPOsKjFggj8yTTCf_PEcORispCs7c1wEegvVqBDLZDuV+nOF0w@mail.gmail.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> <CA+RyBmUx8kKJvL2=aNTj069kMymm4=oaghX-pYcATPEH=-wbJg@mail.gmail.com>
In-Reply-To: <CA+RyBmUx8kKJvL2=aNTj069kMymm4=oaghX-pYcATPEH=-wbJg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=futurewei.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BY3PR13MB4787:EE_|CH0PR13MB4668:EE_
x-ms-office365-filtering-correlation-id: 6a2ed932-eb8f-49dc-dab3-08dc97d5894b
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|4022899009|376014|1800799024|38070700018;
x-microsoft-antispam-message-info: gGL1EuuCBdVhedwy2MxU1dpVmdRRI/BqPN3CHV4v77pzUXH/HIxe262InKchBPD43fFNOSz4Z4Vg1YWwmoEInAisC77SztSULOwgRrYt2JOxXd+hvp3l/y48y+vf1NZfKArms5rCV/BcRmjeONy/ue1F0YmdbZC3XMmvItIx0utG4hcv9dVlD7uuE5o+tI2To1cXiqEHovN0fD1CIlOF13mdvwmFCpFhLCQaaoZRF2ewiu60nHTIPEcHNSBEgkpHHRpJeJqjM9V/BwC/ZWi9CQogZPn0cD1tX0hAkBk6bM7hM//ABXtokV1XaUsCFIA4OqkwJP35oJktVTWxSD9nVSUOi0U8Xf2A0S8KKIiQaedBfag/n+snGu+pTy27Ro3qhA1lHd6ppZKSkLQMus9au5KHxQQxh9/aEnPRzGtrUhkgijd+mPCZ6+kVfkJhyAL9PD4KrMo5Hc2KHARe2bG29VdYzg8a1f96HLNrCkQGO7lG5CNnwFZ6mrCs5o+vwe38ZMMPogsKxli1IAp5lpkISH/WVU2yH/9HtEGuOccdtdV3OTvRa58Wfbv4AUIm9uBmdxYzkFR339gYdUflX/d5bOnCleY2gwrN6GBYGS/KbkNA1Fgg8Td21A6fPnNgwVNA/3wLPH5dNX4hCE9b3yj4wC+6ke3HC3/rJP8x7zk9iRPbmHbrN74tgoV5hj2JorIXim0HNLQtBtLE+Tf9rwSwq1ruiiBCLAopdImPwFc4icAlEmVkvpiBlwxowEmV5ZUknnMLZN3MQ/VwVIhr+2uMPZo1HNarX1mgSHSoq+hRZz7sJqhLNh6OlrfG6OsuPSGBZnme0IRuRbjjDZWJcuDCZt+g+4QSrvC5iS9chBiNMwBctQFejBgwkbhjq+rCwoCMxiAjjI+uaranRYXL7vxQxXHwcO5t39vEdRo4xBNJnCAZJe3iphgp1/o0QApCeW/mxXnqjA8PGQxxDcJOGNNTWXICBjxhES3pz0cmDYDzi29WBnbE1na0VDFbfJlKEPC+C86l6W7ABUnhYTaSOaUeZPptcWa8dfqhJk4m8FTKtpN63k+9s/+nIqjEStMXr5DFijgbIoP6n3TzkiflAwTHyPbte7pFAdD0ctWqo6c3i78AcmFHM0gOp+0SN8/bTzQHtkiSpFbqzqBAXEngTL8tOxwHZa6fotwzkvY5NXJr3gvsb/bfaWS/2o8DKBG7WeleylI+KDeGKQNfRy81C5/fE/bm0thgAUu+zGDBF+0OW0aQHlPt28l6lAtCv1lbseb1yYJaGanDFEw7YfySapMT7C5pZWk5JoVAV85gHxavXP3f37bOzCre1NBwVR/n52OaF42oBBfwi7svHLj59zkZWdw4XDz3TdxcWH0ROeODfJY=
x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BY3PR13MB4787.namprd13.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(4022899009)(376014)(1800799024)(38070700018);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: y46DYXerFOAK0pcKoIpI5FXwxGo3s1VHHI+Gj1vM4VuuLsiwnmmtH5PLdAWDkiwcySpNzhDjcLuzosAZqWbXdWC/GizLAqs6K0gL/mvTjeEalXaietrPBmJcqj/ym77yu5uDB63IWcZzRz4cWbM4nXRAaKtADqTM8f0v8AG0vpN8+8j3qW3V0vh/AzZYLmcaTQTDcbpjIfO3rCZlNb3iNxMEj5p7S+XyXq+jUGiDFL4GSAZhB53KIczJeRf6bVifnjVsMA/MAUeOklflyCqQ7B1Te+HXQ8KcoKerXRZ0yWBgDKjG3n4rVQrmzM9ivfufpl6GCcVqqmOsiCdX90KBzTrtjb6fEcqClOzwqh4GjsdKOla88mmRNza7V1yH3ph5fKQoov1li7VoYae1iYvBsNGhFrEHgbGpJOTjT9qtqTHmKNauk0XZ/0/E5+GrIH1JyR1xZA1aLwYjLdht4urWrdLcraamROtpHemjdgGzvSranWJ5746uQ0GghWmWUlQZDJk8gdPOn/VbseLwTg46mBm0O+iMIV35TFDrzFzOfNxBeiM6jsU0DfAP+hybRKPZ4XdgHO2PKTMPid5FoRyzOwF5jbb1bgNYYQrMEWbIY8DSzawEgo2fJW5tndYsh/nvZaeZF+qkw9QhmB2aKVAFsFMGp/jIPKIg3wNuAIGJt9k3EHXvl9u7M2a7xT/D2rAvI339wrENeoBFXZMp/kKulvoSOqz1YPuDpAJRIm/INMG8N2PzmUk4WRqmei421Qok5ZJK9aXBC+meCh3oieT+R3JvmdsOZPn+XxvImkq51oCpVpExCQf69oaqq8cNOItSpzDymOA0ymVUfdSzkYTPj9QuAWOk8uW0+Y+eRZPiQVjp7Xf2ZLfWaaMpzR1RVupz2TjgY0Et84zEAXMs0Aph26BszAcon+nhWjhUmmT/kNTejRwWIgA2Ijk6G1S/ENjkuTU4+oJaukW1DkEgnqmMY9+tKwkj7oDKBq8nxJ6c2vfyJDZmYxZ3n9Cjh/HSph5ti0vAX3ZGJE92iKl/YOGQ2amvItOOEbyfTP6mlbyDG/7K7Vjco1yCdDvd1n7fkJYOoQinIXI3JfGrpD+6UjjPRt4nWWzA3ER0XmC8TCrybQpACw8D7Aciz+qpIAsh2UXGxQazJnveXZMvVP/ChatWPcE/zPczQkxX+ucPHOhOq/zrINCFtK5z3nml6GolgsGRWM+vCiljZ/+fnDU4U7CTgT44tpyKSC04VbUBKWvpaIEoBxaD6+LMwBeQfq4JFWcmol/BViiZbnkB6+OEeBH68mLszyo4r6pjLKqJhG2iCSPc4wPU5vUohRsgVOMEX59GIRbmtfaAd5MmG0Ax2+Wf7kffLbxWbHEllsuoUnhmhWnPQOtYPdYEpXHBlbcYrexb8XtAQgEegO8aNpfHgG+6DByszY4gfXrM4/LHG5tEKI/VYnxS+M5Or9kQfWITXqt8tLvZeEB3whnQ4jnqvd/+0LNkSU0Y9wv/h30kyaI4TfKX/MsHl1KfQ9JI3346oOeffrPtZcIUFez152t2yS6AT/H7NhBKugdRuR0eWxEaJ9CobnnUbL68CFVMinVxaxtq
Content-Type: multipart/alternative; boundary="_000_BY3PR13MB4787775561259447275654C89AD12BY3PR13MB4787namp_"
MIME-Version: 1.0
X-OriginatorOrg: Futurewei.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BY3PR13MB4787.namprd13.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6a2ed932-eb8f-49dc-dab3-08dc97d5894b
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jun 2024 00:50:56.7016 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: a3r2X9a9aRUlesjfEVQF++pN/bzgAp4DPXbv6fPY2pHq+YJEEYPkWOlRvuvS6aNUJ2+OYfI3K58JF4Co9iPkkw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH0PR13MB4668
Message-ID-Hash: P6JTVSHWESQNNP4QQYTZVOMSJIG2ANX2
X-Message-ID-Hash: P6JTVSHWESQNNP4QQYTZVOMSJIG2ANX2
X-MailFrom: haoyu.song@futurewei.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 <jmh.direct@joelhalpern.com>, mpls <mpls@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [mpls] Re: Example of MPLS RLD with IOAM Trace in PSD
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/OC8MO7EakxnrpFcoD2HWSKXIHx8>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Owner: <mailto:mpls-owner@ietf.org>
List-Post: <mailto:mpls@ietf.org>
List-Subscribe: <mailto:mpls-join@ietf.org>
List-Unsubscribe: <mailto:mpls-leave@ietf.org>

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 <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

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 <tony.li@tony.li<mailto:tony.li@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 PM, Joel Halpern <jmh.direct@joelhalpern.com<mailto:jmh.direct@joelhalpern.com>> 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 <jmh@joelhalpern.com><mailto: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 AM Joel Halpern <jmh@joelhalpern.com<mailto: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’t think it’s the obstacle forbidding us to
>> develop either ISD or PSD.
>>
>> Haoyu
>>
>> *From:* Joel Halpern <jmh@joelhalpern.com<mailto:jmh@joelhalpern.com>>
>> *Sent:* Thursday, June 27, 2024 12:50 PM
>> *To:* Haoyu Song <haoyu.song@futurewei.com<mailto:haoyu.song@futurewei.com>>
>> *Cc:* mpls <mpls@ietf.org<mailto: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’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 <jmh@joelhalpern.com<mailto:jmh@joelhalpern.com>>
>>     <mailto:jmh@joelhalpern.com<mailto:jmh@joelhalpern.com>>
>>     *Sent:* Thursday, June 27, 2024 11:39 AM
>>     *To:* Haoyu Song <haoyu.song@futurewei.com<mailto:haoyu.song@futurewei.com>>
>>     <mailto:haoyu.song@futurewei.com<mailto:haoyu.song@futurewei.com>>
>>     *Cc:* mpls <mpls@ietf.org<mailto:mpls@ietf.org>> <mailto: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’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 <tony1athome@gmail.com<mailto:tony1athome@gmail.com>>
>>         <mailto: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>>
>>         <mailto:rgandhi.ietf@gmail.com<mailto:rgandhi.ietf@gmail.com>>
>>         *Cc:* mpls <mpls@ietf.org<mailto:mpls@ietf.org>> <mailto: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’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
>>             <rgandhi.ietf@gmail.com<mailto: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 AM Tony Li <tony.li@tony.li<mailto:tony.li@tony.li>>
>>             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
>>                     <rgandhi.ietf@gmail.com<mailto:rgandhi.ietf@gmail.com>> 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 -- mpls@ietf.org<mailto:mpls@ietf.org>
>>                     To unsubscribe send an email to mpls-leave@ietf.org<mailto:mpls-leave@ietf.org>
>>
>>
>>
>>
>>         _______________________________________________
>>
>>         mpls mailing list --mpls@ietf.org<mailto:mpls@ietf.org>
>>
>>         To unsubscribe send an email tompls-leave@ietf.org<mailto:tompls-leave@ietf.org>
>>
>>
>> _______________________________________________
>> mpls mailing list -- mpls@ietf.org<mailto:mpls@ietf.org>
>> To unsubscribe send an email to mpls-leave@ietf.org<mailto:mpls-leave@ietf.org>
>

_______________________________________________
mpls mailing list -- mpls@ietf.org<mailto:mpls@ietf.org>
To unsubscribe send an email to mpls-leave@ietf.org<mailto:mpls-leave@ietf.org>
_______________________________________________
mpls mailing list -- mpls@ietf.org<mailto:mpls@ietf.org>
To unsubscribe send an email to mpls-leave@ietf.org<mailto:mpls-leave@ietf.org>


_______________________________________________
mpls mailing list -- mpls@ietf.org<mailto:mpls@ietf.org>
To unsubscribe send an email to mpls-leave@ietf.org<mailto:mpls-leave@ietf.org>