Received: from smtp-out.orange.com (smtp-out.orange.com [80.12.126.239]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by mx.ietf.org (Postfix) with ESMTPS id ABE9142; Thu, 17 Sep 2026 16:49:35 +0000 (UTC) Authentication-Results: mx.ietf.org; dkim=pass header.d=orange.com header.s=orange002 header.b=n44Pv4CD; arc=reject ("signature check failed: fail, {[1] = sig:microsoft.com:reject}"); dmarc=pass (policy=none) header.from=orange.com; spf=pass (mx.ietf.org: domain of bruno.decraene@orange.com designates 80.12.126.239 as permitted sender) smtp.mailfrom=bruno.decraene@orange.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; i=@orange.com; q=dns/txt; s=orange002; t=1789663776; x=1821199776; h=to:cc:subject:date:message-id:references:in-reply-to: mime-version:from; bh=ceWdzPcREn6u3eQfdE1g+kdfaWbWMUT1wIUUcxlmy/c=; b=n44Pv4CDVTTCdhaN+8eHDO8RUH79IKV2cy1F4HmwrcOjukLEClqi5RAR 65ipo3YtYhu/4vCWMJmthVo4GEInDntjlVK7mqvZrhHG6lGfeEijryjxq gCccX897gDuQrWQJaOW4Lid2lI/FRWGJPsnecfyg6N5ZKe+nO09gyKbXG 1zkdF6daKVV2aE28CRjE77eQWHydwXqwLen3aIxrz1IMSYIrtsfEhaDUM 3Y+Lu+9/TSwSAltZUT+hROXAquSwnIKr7EMC8HmGKcRzlVe1VPy/PNDh9 zChxvKjZq1cGZaA+b7rf6h175WuSW7VQHEI1aL8emKlY5dbKwPo8Wrd8W Q==; X-CSE-ConnectionGUID: ZeJ3UZLoSXa0tqMMj05JFA== X-CSE-MsgGUID: WWuRcjwUSGqBFk7yqfG4jg== Received: from unknown (HELO opfedv3rlp0c.nor.fr.ftgroup) ([x.x.x.x]) by smtp-out.orange.com with ESMTP/TLS/TLS_AES_256_GCM_SHA384; 17 Sep 2026 18:49:28 +0200 Received: from unknown (HELO opzinddimail17.si.fr.intraorange) ([x.x.x.x]) by opfedv3rlp0c.nor.fr.ftgroup with ESMTP/TLS/TLS_AES_256_GCM_SHA384; 17 Sep 2026 18:49:27 +0200 Received: from opzinddimail17.si.fr.intraorange (unknown [127.0.0.1]) by DDEI (Postfix) with ESMTP id 34DC937522E; Thu, 17 Sep 2026 18:49:17 +0200 (CEST) Received: from opzinddimail17.si.fr.intraorange (unknown [127.0.0.1]) by DDEI (Postfix) with ESMTP id 2497136361B; Thu, 17 Sep 2026 18:49:17 +0200 (CEST) Received: from smtp-out365.orange.com (unknown [x.x.x.x]) by opzinddimail17.si.fr.intraorange (Postfix) with ESMTPS; Thu, 17 Sep 2026 18:49:17 +0200 (CEST) Received: from mail-francecentralazlp17010002.outbound.protection.outlook.com (HELO PA5P264CU001.outbound.protection.outlook.com) ([40.93.76.2]) by smtp-out365.orange.com with ESMTP/TLS/TLS_AES_256_GCM_SHA384; 17 Sep 2026 18:49:16 +0200 Received: from MR1P264MB4354.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:42::24) by MR1P264MB2801.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:36::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.12; Thu, 17 Sep 2026 16:49:13 +0000 Received: from MR1P264MB4354.FRAP264.PROD.OUTLOOK.COM ([fe80::b9fd:1035:779e:5aff]) by MR1P264MB4354.FRAP264.PROD.OUTLOOK.COM ([fe80::b9fd:1035:779e:5aff%4]) with mapi id 15.21.0428.011; Thu, 17 Sep 2026 16:49:13 +0000 From: bruno.decraene@orange.com X-CSE-ConnectionGUID: szhzAy+WS0++L8dJaMeebg== X-CSE-MsgGUID: 48+dSo/eTfCcUQWIYrp4Mg== X-TM-AS-ERS: 10.106.160.156-127.5.254.253 X-TM-AS-SMTP: 1.0 c210cC1vdXQzNjUub3JhbmdlLmNvbQ== YnJ1bm8uZGVjcmFlbmVAb3Jhb mdlLmNvbQ== X-DDEI-TLS-USAGE: Used X-CSE-ConnectionGUID: adKa3/wmS+WpxsVLCC/ciA== X-CSE-MsgGUID: /ZOYI+wSQ4amxNkPQIwlpA== IronPort-Data: A9a23:7cQtxKIDUfHiZjMzFE+RC5UlxSXFcZb7ZxGr2PjKsXjdYENS0TAOz 2AYC2jQO6rcMTf8f952a9yw/EsH7MWAm9MySVdorCE8RH908seUXt7xwmUcns+xwm8vaGo9s q3yv/GZdJhcokf0/0nrav676yAlj8lkf5KkYMbcICd9WAR4fykojBNnioYRj5Vh6TSDK1vlV eja/YuFZzdJ5xYuajhKs/Pa9Es11BjPkGhwUmIWNKkjUGD2xyF94KI3fcmZM3b+S49IKe+2L 86r5K255G7Q4yA2AdqjlLvhGmVSKlIFFVHT4pb+c/HKbilq/kTe4I5iXBYvQR4/ZwGyojxE4 I4lWapc6+seFvakdOw1C3G0GszlVEFM0OevzXOX6aR/w6BaGpfh660GMa04AWEX0u97ImgVs uMdE3MydgCYucad6/WwS8A506zPLOGzVG8ekklJkAmDU6oNfMibGuPN+MNS2yo2ioZWB/HCa sEFaD1pKhPdfxlIPVRRA5U79AuqriWnNWwD7g3L4/BfD2v7lGSd1JDnKsfTfZqGSM5Pl0ueq 0rB5W3/DRxcP9uaodaA2ivw2bSRxH6qBur+EpX/xNlboR6M/VVPARgGc1iDmNimjlaXDoc3x 0s8oXF08fdaGFaQZtn0WAyl5mWDuBE0VcdMDvc39wyMjKHT5m6xHHQLCzJAcvQnudM4Azsw2 TehmsvtHhRuvaGbD3WH+d+8oSm7NzRQLGIea2oBVQ8ept7l5Zk6khKKUttnHau4ksfkXD/0y j+irSUiifMUl8Fj6kmg1VXOgjbpqILASAU47QjRQnis6gprYJb8ONTxsQCDt7BHMZqTSUSHs D4cgc+C4esSDJaL0iuQXOEKG7Lv7PGAWNHBvbJxN5At1D32vGGmRsNv+CFlGmNCGYEPeBa8N Sc/pjhtCIlv0GyCQ5UfXm5cI8EjzKylG87sUPvZZddIfoJ4cAaV+Dk3OhbJhzi1yg4rjL01P oqdfYC0F3EGBK97zT2wAeAAzbsswSN4zmTWLXwa8/hF+eXADJJ2Ye5fWLdrUgzfxP7ZyOky2 4sEX/ZmMz0FDIXDjtD/qOb/12zm0kTX9bit8JYLKYZv0yJjGWo7DOTWz69pcIt/h8xoqws8x VnkAhUw4AOm2RXvd1/WAlg9M+mHdcgk8hoG0dkEZg/AN44LOtz3tP93mlpeVeVPydGPOtYtF 6ZcIJTbUq0np/au0211UKQRZbdKLHyD7T9i9QL8CNTjV/aMnzD0x+I= IronPort-HdrOrdr: A9a23:GzCfQKDK/zYtEv7lHeg/sceALOsnbusQ8zAXPh9KJCC9I/bzqy nxpp8mPHjP+UsssRAb6Kq90cy7LU80mqQFmbX5UY3SOjUOmVHYSL2KjrGSpAEIeReOitK1vJ 0IG8cReb6Ab2SWlfyb3ODfKadY/DDuytHXuQ8apE0dKD2CAJsQlDuRZDzrbXGfE2J9dOsE/C j23Lswm9OVQwVlUu2LQlU5ZIH41q32fd/dEFM771lN0nj4sRqYrJrBVzSI1BYXVD1ChZ8k7G j+igT8ooGuqeuyxBPw33Laq80+oqqv9vJzQOi3zuQFIDTljQilIKxnRr25pTgw5MWi8kwjnt Xgqwope+5z93TSVGeopgaF4Xit7B8er1vZjXOIi3rqpsL0ABo8Fsp6nIpcNiDU7kIx1esMmJ 6iiwii1qZ/PFflpmDQ9tLIXxZlmg6funw5i9MeiHRZTM83dKJRhZZ3xjIQLL4wWAbBrKw3Gu hnC8/RoNxMd0mBUnzftm5zhPSxQ3UIGAucSERqgL3R79FvpgE/86Ik/r1dop5AzuN8d3B83Z WEDk28rsANcicUBZgNTdvpD/HHTFAleii8RF56EW6XZp3vBEi93qIfwI9Fr91CK6Z4hqfa3q 6xHm9liQ== X-Talos-CUID: 9a23:YEOmpW9s2SkGplvZ7TqVv0cYOcl+NWLY9zTvO1+jN0JCY/qeSHbFrQ== X-Talos-MUID: =?us-ascii?q?9a23=3AHZCXOg2SzdEe6dpQQqx1CIBJUjUjpJaJOWFOjq4?= =?us-ascii?q?/58CBJQpzAw68kzCva9py?= X-IronPort-AV: E=Sophos;i="6.27,103,1787004000"; d="scan'208,217";a="147361596" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=KkKKRJ82pV12QpNIxOXiTEN9qac2FN7QOpW39fd/P40eTvwnxGONGT3td5nYcV6XlNPjrt3+m7v0e7vmXGgvt3YKkfdd5xqtKXMOcWM71zt8O2vVeuVgQGQ9RQBC8W4H1ISP9kN0NLsIXIUIv4e2bRIPxKIr0CCPTqFRyBQbQpbop+O70qisXnY3XQWOgt/RiA+lgd25WacrtmyiBqxDuBMUBc5ekhU66btdThUOtoN5gwIY8mFiZ+PEg1kdHsJpLYSxHGubmUyw3RQ/GM0uSWFhF//W2tpGMTcRTUjtGqoTNnOUySyXmdfUb0fbi23F9Wok/rhDWJ27A0lSnD7P4w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; 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=oAzlczTFhddV8mvwfgbusI/uxAPGlFm6qYmBhsMSuQc=; b=Po2FiGxF37JdEKdoFJIjOPTIKEbIPOzgoO7lxYtBJ7YLwj24RpaTpML9N4ZUDQ+nG9rtNGvLgcASRamNqw4KticvfPUz1OqhRSxmfZxAEeuYRhIHhQVCvwgnRF1bjup6E4n4aW0vvIzxlh3cV77/hAaMb25YM0HdwAlxiVH9YXz/pDtjbSUKt0DVph4YZfnHa0L24jotx2UtfLjTiuKuptdnreDRhtOk+CgJrxYUhNmFzDy94nUq4EQTnKC8cyG/OnbGiVPij79tB9mQS7oBROVBCU3UtREl/vEm3LHHg8dJBcnlZGYLtm9IRJYmXzZrROdFscum66MNTB+nBDpzvg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=orange.com; dmarc=pass action=none header.from=orange.com; dkim=pass header.d=orange.com; arc=none To: Haoyu Song Thread-Topic: draft-ietf-mpls-on-path-telemetry-flag early Rtgdir review Thread-Index: Ad0k6qXR2+E04w3aSSeaORlXmSzMCwAGOkTgCG8X3SA= Date: Thu, 17 Sep 2026 16:49:13 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ActionId=719f04d7-1e31-48c9-9940-2a1e20285684;MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ContentBits=0;MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Enabled=true;MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Method=Privileged;MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Name=unrestricted_parent.2;MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SetDate=2026-08-05T14:55:49Z;MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20;MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Tag=10, 0, 1, 1; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: MR1P264MB4354:EE_|MR1P264MB2801:EE_ x-ms-office365-filtering-correlation-id: d1cc7773-fc9e-4b51-6e01-08df14db9aab x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|366016|23010399003|376014|1800799024|13003099007|38070700021|6133799003|10067099003|4143699003|56012099006|11063799006|5023799004|22082099003|18002099003|8096899003; x-microsoft-antispam-message-info: AJ3Fm90AA2PyVWCiG6zF7D0w8xRJmJSX8YhTkSWjDCqK79zzehd3w1UNb+6uKvIJrrKniwiRCNM2dn9HRx9pSUf2SzkhCJbsvKyzdbQJHclFrF8x3ryiUwrYEchcurT5+C61eaf6IJC1/Xxqgu096X1zGHd2Nx5MckO++qRvbENN8O4+opxGnH07/Su23zkiRAqBAABebN2OdnY5y/MgPx9Zf8sa8//5ShzZ7ogpguxKRJvUVsG3QxUQJXAME5DZ+F0S16WwQ1+AdxmXsHm9zw3PvXV1ABgqdK+TCF+56ExPbgebbRyvR4JQr6P2SKSia+nvSVIX8lDUmY98btgj4ChiF4TMrf2id49g6tAbbVJpC3b2QxVL9T4p1wYozUV6XiWJy8dpRXCGO0SILdafiuNGl2Fsq9feF/Rm4c0kZ04ldFl3zIPnYfpSVfb7e3D7HXH2h10Y4Pn/f3tHN1qkN9ybDSJTrWBAdyFGMpsdL0lXR8GXUQ7q5CKE16KhdZZO5kJwq00ZYNs/rcqpcKWgDzckyCc9pbrTLcTxrGJV09CHzyQMbdatV1o5MSNVRLrJPkheFHq9hbJdG4RzOt8kz5a/MfWc3Pf3io8f8x3p0mwlmQrxA2OkVkuDDFqtB4A1FxQGusr0U3uoT75ijYi6VWCERaby1Zu4S3evofFUQtHKS8mC6LmkyPjdcGVBqrw83GzwM1S6sxk8uHUigGTukOUE9Ni6wMu2Y8HUMHFAL6o= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MR1P264MB4354.FRAP264.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(366016)(23010399003)(376014)(1800799024)(13003099007)(38070700021)(6133799003)(10067099003)(4143699003)(56012099006)(11063799006)(5023799004)(22082099003)(18002099003)(8096899003);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?FGPSJ8UN/RsZZnRHm8NslqrD+c96fmdAvO/Dt/f03sA70Ol3p8Dyfsr9uG?= =?iso-8859-1?Q?hN5RK7/ALIzBzO0fckh0xBQCq5sw2cejFQAEzv0hbF0nHNhUzP401wABxo?= =?iso-8859-1?Q?f6721bHs9oVOyfxWbT2eq7WkeHdnm+rtigbjOnImIvoq6VTYEv71vVKPp1?= =?iso-8859-1?Q?kGGBFiIPkMY+Kj58QKVAfgWtsxbdWmtyjEuapwldav0xucRPty3zDe2YeE?= =?iso-8859-1?Q?BnB5WAZCAfawrdH5q0V/+X3MdwszR1p7UCi78f4jD/6YiKBEC0XoqlhtVo?= =?iso-8859-1?Q?+kkcag/EaBiivhx1ZZeuGEoF8OEKu44a9xY5ev3cRmR4BmPYWj8bP9Tb85?= =?iso-8859-1?Q?EA4M3qP8aV+inapre5ykUyw98z7LsR5WTB1XaEubgMT1IUeP31C/8GQ2qf?= =?iso-8859-1?Q?SoW31UOOEEO/NNMBkOg+/1oI8ovCxNoVC65SGTYcsEeqjZYEHwUiKA7+8b?= =?iso-8859-1?Q?hsvWvbidOni9VUJ8zcAl9ib8xhFDZs8ZyJ1J9qWCfqhwQ1DbqsklWOBBSd?= =?iso-8859-1?Q?msBQkAhMkjyFWsKHHwhcHvzZSilgUWXxRWI7W0M6zMJ+mnK6ImvkFrXrk1?= =?iso-8859-1?Q?bNVpUslKvv4q1lmwtQ+zb4zES3opJaKclVr8fHqjeHZQwfhMkGhG/Q2ARB?= =?iso-8859-1?Q?5Bai2xKQgRjiKDrs/jwpqM4NMcPRcLS0dO4duDCBafnc1E8I2yx3cs3rDC?= =?iso-8859-1?Q?dbS0s+TSLDg5qFyHULkHkSoHrJNTxrtBDB301ZAbR43YfI8sBxDB94xnSn?= =?iso-8859-1?Q?JfHDzV36jDnyn+RoUtzHUGcunzwNfWwoAuZjftOyItBqsk1L/P2qspzL4M?= =?iso-8859-1?Q?6E8I92tuFoalqP06b6RV92/r1AilxNkjjjmMoKa8nDbRawN9oCiboV8qP5?= =?iso-8859-1?Q?qw+jXkrsadq8eiDhvsR9U/gW/VTa1mQ1afcXBOW9lNk17i5dM0lf41sxAM?= =?iso-8859-1?Q?dBHyENQ+mYqV3jV8R88qz46fZY7bPl7HMYb30e8cNZVchVjffqDEiu/ibb?= =?iso-8859-1?Q?zq3TDvJ7m/G8V0qUEo4rAJsbNMYzJdQhYIMJvjumrQ8ffaLRroSwUm24IB?= =?iso-8859-1?Q?roZGUW313v3ShZPSHAhhIRNaDf0oFImwD/qMWT5ARS5RSgn4zYKpaXp2gX?= =?iso-8859-1?Q?uma55MCm7OvHaGNHsDYU8JKZVoxLRQD+qG/OpnIiuJKPENREF2CMlAiojE?= =?iso-8859-1?Q?f95PSwa9VU58/JNAlr6LELa1uid9OYFfAdx0uo9FBwukQip8178uAAEfym?= =?iso-8859-1?Q?USOEqgIPWfff6gBqke+G0LVEBLV1gZGaG+dBXvbpAL6FgToYb1vlQ+ri56?= =?iso-8859-1?Q?Vxr4cpY15yqrfKA+qvdpA+0KDkZgR972A6WBgtPZByMvmUXxq9tM0hAmkA?= =?iso-8859-1?Q?MWLAwAJzpkBCSV0pTWMpUmtPvm3ekHuD2+QwTGItoq9Q/KKKjUSgYCcpEg?= =?iso-8859-1?Q?xTmHXcWnmQZywuGr/1Nja79YuF4Xk4N0+brkfbI1CxMaadBvbfIYKS44Oc?= =?iso-8859-1?Q?nPCLRVsXZglNvLuQIBk/A5L42VIZikYE+z1rExdIABLRw5uEzrWAjSnuwn?= =?iso-8859-1?Q?qtmKdTAjVkcVxAVgBbdVhBJLKDy/c7P8TwVgOLHn0FT8mO2/6M8uUnV5ZR?= =?iso-8859-1?Q?MrPb73JQEGjRWNwzSPW7Hd3Ywolf4WtUUe+GKM9XJPdVUxzFwtdIwJQxCg?= =?iso-8859-1?Q?Ymy7YVOQqlSTIsfmKtEaAgySujD1MdGFqJh+4nCBT/InVejuWX2AnO264i?= =?iso-8859-1?Q?dysOpZ6JoNCrvPFtR2U/ZCyJ+EVLD6Bui/EIQM8RM9k0uKJUDb90AUzzxF?= =?iso-8859-1?Q?8a+vNbNatA=3D=3D?= Content-Type: multipart/alternative; boundary="_000_MR1P264MB43540DB9CD943D36AB1384EFF0B82MR1P264MB4354FRAP_" MIME-Version: 1.0 X-Exchange-RoutingPolicyChecked: cg5jQiWqCw9p8dV4JpmwCXK+agOhDFXoON1ArhO98m+VhKezUmGCC07DYKfYwIKp1LwrwsXPYWjS/y118ozc0OS26ZRIAaM190+OyszMKiYRi1Wi4CnSmv62njJK/2j/WMU9HZlelhPgZo6AgFF+4EVKkNkq5J9A9gy6i51ObOCGxMg9w6cICe9oRuuTBHjL6wRDqlmJInYXZeBAdprbikrKtH+SbSUR322G7TuU0pMo126I3yx2Bg6meRcaLRl+BndMH3SEOcPHAAidpwcOvh+1SwiiKUWE6vVhOsUUk8tEWrPdVXhEHeOiUD7kSPdaimfWB6LDob4da2EmUmNePA== X-OriginatorOrg: orange.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MR1P264MB4354.FRAP264.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: d1cc7773-fc9e-4b51-6e01-08df14db9aab X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Sep 2026 16:49:13.4911 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 90c7a20a-f34b-40bf-bc48-b9253b6f5d20 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: hvJQATZ5JUso+Qk2B0lOJ1dmwlVpzrwI/kuka2w5mwJzv+YHScSBjY1ByFHRHPzWx6lf5CU2wWICs68LQFexq3QrQpiCrxu7egzQyeUhVwA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MR1P264MB2801 X-TM-AS-ERS: 10.106.160.156-127.5.254.253 X-TM-AS-SMTP: 1.0 c210cC1vdXQzNjUub3JhbmdlLmNvbQ== YnJ1bm8uZGVjcmFlbmVAb3Jhb mdlLmNvbQ== X-TMASE-Version: DDEI-5.1-9.2.1014-30204.000 X-TMASE-Result: 10--20.413000-10.000000 X-TMASE-MatchedRID: hFbMlnd2lLMWVkbx+DGqRjBbUbnUQiRuDH4m2ujwCtujiIJqRFExTYPz 3CQ/TRoslw8UOngKoKQkgTwH4xq1eCn/9UfqOhMD2SFQDtYqLcdpHZaVkrZX0jj61oDLR3dr38n f2+Jg4mD00UqsgheBfMYJtt7B4BmHJQT9L9A1+o4dQV2iBCW7CnOjEKYddvv6CsYnJzXwRorzE2 0Wsd7Z51vIwMJvUbYiwTrL3HnUernFQ6PV+kruFu5ON7OGn0URkeKjJDBQ5Do5NrjESsdl98SeH FOyS8SxtcFlFl6UeiQ/BISWw3jWTWPiJJEJGssUwQEav6jgEJfc4D3CuzQAPVyvUUUFWzOmv8Sv 4nJhO/dprUGJUYnbNkutLrNNBN/vWFs8ID1waZKMAV1kwTV1DCTufEFUWmNnWIPxjmaBIyHzuWW YYfNSFE/tnHz76F/jnwX2iD5gkbQoGMM8JBXibBoieCOyeM6oSYYjP/MmTQNPpwTx/+LANXgwJo 5QMsV9M9lIYWY5TSX6uw+qXj/W+XAX6WwSc6OQ7IZFogW9lYCH3SbWGNHUNTrkC+rMLPgzH9i9Y vcSbNEvP051SRxlT6wGefV7gbe9CI6S2pXNVTD1+5UdnQELS9mCr1ZHFEoRTTDWNi9ivw9IRrNd wYuL6naSjqeiFr2yemFY3yUtO6QzJJn1odE+33JHj/SKrHQQaG+BGJgDa5cVD+MNVApefqWXeo1 JBrZglnU/m80XrfkghX/JDeLVxJkMyfU6h3A+Se+PARiAyZIuvOeBC5O+9MoibnBMZsQApSTO6N phouLYSpKlnjz3PZfBXQ1x4BShhwQLRAK7pLhnO+ALb7hccBEuOqgkm3/1fC4IwOLvyufxf20B5 UzKObLFqdk+0XHiO50T9A74HCtz8GAVaYnd/S2/A1oqumZUeTKZayz4M/fNDl7GDk8JONWzRvO3 IegpKtNUkBB/FpsSEtKt4RNDJLCfFvCPa/6u X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,28:1,33:0,34:0,38:1,42:1-0 X-TMASE-INERTIA: 0-0;;;; X-TMASE-XGENCLOUD: NULL-NULL-7-0-1 X-Spamd-Bar: - Message-ID-Hash: RYP7KXRLETCI64ERTIWJT7UTDV74I5GA X-Message-ID-Hash: RYP7KXRLETCI64ERTIWJT7UTDV74I5GA X-MailFrom: bruno.decraene@orange.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; header-match-mpls.ietf.org-0; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: "rtg-dir@ietf.org" , mpls , "draft-ietf-mpls-on-path-telemetry-flag@ietf.org" X-Mailman-Version: 3.3.10 Precedence: list Subject: [mpls] Re: draft-ietf-mpls-on-path-telemetry-flag early Rtgdir review List-Id: Multi-Protocol Label Switching WG Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --_000_MR1P264MB43540DB9CD943D36AB1384EFF0B82MR1P264MB4354FRAP_ Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi Haoyu, Sorry for my late reply. Thank you for considering my comments, for your below reply, and for the up= dated draft version. Thank you especially for your good will and in-depth considerations of the = comments. Very much appreciated. -03 works for me. Best regards, --Bruno From: Haoyu Song Sent: Monday, August 10, 2026 8:26 PM To: DECRAENE Bruno INNOV/NET ; mpls ; draft-ietf-mpls-on-path-telemetry-flag@ietf.org Cc: rtg-dir@ietf.org Subject: RE: draft-ietf-mpls-on-path-telemetry-flag early Rtgdir review Hi Bruno, Thank you very much for the careful and detailed RTGDIR review! It's of gre= at help for us to improve the draft. We have addressed all the comments in = the -03 revision. Please see our inline response marked with [HS] for each = point on the specific change we made. Best regards, Haoyu From: bruno.decraene@orange.com > Sent: Wednesday, August 5, 2026 8:22 AM To: mpls >; draft-ietf-mpls-on-path-tel= emetry-flag@ietf.org Cc: rtg-dir@ietf.org Subject: draft-ietf-mpls-on-path-telemetry-flag early Rtgdir review Document: draft-ietf-mpls-on-path-telemetry-flag-02 Title: MPLS On-Path Telemetry Network Action Flag for OAM Reviewer: Bruno Decraene Review result: Has Issues Hello, I have been approached (but not formally selected due to misunderstanding o= n my side) to do a routing directorate "early" review of this draft. https://www.ietf.org/archive/id/draft-ietf-mpls-on-path-telemetry-flag-02.h= tml Having reviewed the draft, I'm sending the comments regardless of the forma= l selection. The routing directorate will, on request from the working group chair, perf= orm an "early" review of a draft before it is submitted for publication to the IESG. The early review can be performed at any time during the draft's life= time as a working group document. Document: draft-ietf-mpls-on-path-telemetry-flag-02 Reviewer: Bruno Decraene Review date: 2026-08-05 Summary ------- In general, the draft is clear and readable. Thank you. I have some comments, including a few major ones, that I think should be ad= dressed before proceeding. Major: ------- =A77 "This document requests IANA to allocate one bit position (TBA1, suggested = value 42)" Draft should not indicate a suggested value. cf https://datatracker.ietf.or= g/doc/html/rfc8126#section-3 This looks very close to squatting code points, which leads to interop issu= es. Please remove. [HS] Fixed. We remove (TBA1, suggested value 42) and now just request a sin= gle bit position as "TBD1" with no suggested value, and remove the sentenc= e asserting "Bit Position 42 falls in a Format D LSE...". We keep the alloc= ation constraint as guidance to IANA rather than suggesting a squatted valu= e. --- =A74.1 "The P-flag is therefore placed at Bit Position 42" This is codepoint squatting. Please remove from the spec (until IANA has allocated a code point) [HS] Fixed. We replace the hardcoded "Bit Position 42 as numbered in Sectio= n 13.2.1 of RFC 9994" with a normative placement requirement (the P-flag MU= ST be assigned a position outside the MS 20 and MS 23 bits, i.e. in Format = D word bits 24-31) and a "TBD1" placeholder pointing to the IANA section. F= igure 2 is now labelled "illustrative only" so the drawn position is not re= ad as an allocation. --- =A74.3 This section essentially states that the data correlation is unreliable. I don't think that this is good enough for important networks. (At minimum, this should be discussed in the operation consideration sectio= n.) [HS] Addressed. We rewrite Sec 4.3 to provide a deterministic correlation m= ode: at most one marked packet in flight per correlation key actually carri= ed, enforced at the ingress, and a deterministic failure rule: postcards th= at cannot be unambiguously correlated MUST be discarded rather than reporte= d as a path. A "Correlation Reliability" item was also added to the Operati= onal and Manageability Considerations (Sec 5.1), as you requested. --- The document does not specify the interaction with MSD. RFC 9491 says [MSD] "advertisements allow entities (e.g., centralized contr= ollers) to determine whether a particular Segment ID (SID) stack can be sup= ported in a given network." https://datatracker.ietf.org/doc/html/rfc8491 This document adds 3 LSE to the label stack. In some platforms, this may re= duce the MSD usable by SR-MPLS. MUST such node decrement their MSD signali= ng (by 3) to allow controller to perform correct computation? Such impact should probably be discussed in the ops consideration section, = as 3 may be relatively significant for some platform. [HS] Addressed. We add an "interaction with MSD" item in Sec. 5.1: a node = that enables PBT-M and whose usable SR-MPLS label depth is reduced by the 3= -LSE Sub-Stack MUST decrement its advertised (per RFC 8491) by the number o= f LSEs consumed (up to three) so controllers compute correct SID stacks; no= des unaffected by the imposition need not adjust. RFC8491 is added as an in= formative reference. Minor: ------- =A72 "1: PBT-M avoids augmenting user packets with new headers " Well, draft seems to do exactly that (augmenting user packet with a new hea= der). You may want to rephrase. (e.g. "large header") [HS] Fixed. Change "new headers" to "new large headers" -- "3: PBT-M can avoid interfering with the normal forwarding." pushing the MPLS MNA header seems to interfere with normal forwarding (by r= educing the available MSD on the Head Node, and the RLD on all transit node= s) [HS] Fixed. Our real meaning here is that PBT-M doesn't incur extra user pa= cket processing (e.g., modify or augment the user packets). We rephrase thi= s sentence to avoid ambiguity. The imposition cost is now also treated expl= icitly: MSD (decrement the advertised MSD) and RLD (the Sub-Stack MUST lie= within the Readable Label Depth of the on-path MNA-capable nodes, and a no= de whose RLD does not reach the Sub-Stack silently behaves as non-PBT-M-awa= re) in Sec 5.1. -- "4: For PBT-M, the types of data collected from each node can vary dependin= g on application requirements and node capability." I would assume that this would be true even without PBT-M, otherwise this w= ould seem difficult to deploy. [HS] Clarified. For the other on-path telemetry techniques (e.g., IOAM trac= e and DEX), the head node stipulates the data types to be collected, and ea= ch transit node must all be able to export the data exactly as requested. F= or PBT-M, the head node only provides a trigger without stipulating the dat= a types, and each transit node can export data based on its local configura= tion. -- =A73 "Req. 1 (Packet Marking Bit): A user packet needs to be marked to trigger t= he path-associated data collection. Since PBT-M aims to avoid the need to a= ugment user packets with new headers, it needs to reserve or reuse a single= bit from the existing header fields." Do you mean an existing header field in a specification or in the customer = packet? The former would still augment user packer. The latter would restrict the u= sage to MPLS packets already carrying MNA. Please clarify. [HS] Clarified. Rephrased as "A user packet needs to be marked to trigger t= he path-associated data collection. Therefore, PBT-M needs to reserve or re= use a single bit from existing header fields in a specification (e.g., the = MNA encoding)." -- "Req. 4 (Overhead and Security): Since each postcard packet has its header,= the overall network bandwidth overhead of PBT-M can be high. A large numbe= r of postcards could add processing pressure on data collecting servers. Th= at can be used as an attack vector for DoS." Also it add processing pressure on all transit nodes sending a postcard. (w= hich are likely more limited than a server) [HS] Good catch. We rephrase the sentence as "A large number of postcards = could add processing pressure on all transit nodes sending postcards as wel= l as data collecting servers." --- =A74.1 "Format D (labeled D) carries the P-flag." The P-flag has never been defined/introduced as this point. May be :s/P-fla= g/PBT-M indicator [HS] Fixed. --- "If the bit is set to '1', a node is triggered to collect and export the te= lemetry data as configured by the control plane." Since this flag is essentially the main part of the specification, could yo= u please specify what "a node" is? (in particular, according to Figure 1, this seems to include the Head Node,= which does not seem completely obvious) [HS] Fixed. Change to "when the bit is set, every PBT-M-aware node that rec= eive the packet is triggered - explicitly the head-end (originating) node, = every on-path transit node, and the egress node within the Hop-by-Hop scope= ." to rigidify the scope. --- =A74.3 " Once this is done, the TTL (or the timestamp, if the network time is sync= hronized) can be used to infer the flow forwarding path." In the general case, the MPLS packet carries a label _stack_. - The TTL may be set differently in each LSE. - And even if not, since only the TTL of the top label is decremented, TTL = will be different across LSE. Hence this does not seem to work as written. (e.g., after a POP, the TTL on= the top LSE is likely to _increase_) You may want to expand, e.g., by specifying the use of all TTL of all LSEs. [HS] Thank you for pointing this out. The bug is fixed. Sec. 4.3 now state= s plainly that TTL-based hop ordering can't rely on a single TTL because on= ly the top LSE's TTL is decremented and PUSH/POP make the top-of-stack TTL = non-monotonic (it can increase after a POP). A PBT-M node SHOULD report the= per-LSE TTL vector plus its node ID, and the collector reconstructs hop or= der from that vector, using IGP topology to resolve label operations. We al= so make Sec 4.2's basic export set consistent ("node ID and per-LSE TTL"). --- "The first possible approach includes the flow ID in the OAM packets. In ca= se of MPLS, the MPLS label stack can serve as the flow ID." I don't think that this is reliable enough. An MPLS LSP typically aggregate= s a very large number of flows, so is not good enough to identify a flow. [HS] Clarified. A flow could be an aggregated flow sharing the LSP/FEC. If = a 5-tuple flow needs to be identified, data beyond the label stack needs to= be collected. Text is updated to reflect this change. "If the packet marking interval is large enough, the flow ID is enough to i= dentify a user packet." Probably the "interval between two successive packet marking operation". Again, I disagree that this is enough and reliable enough. If you stand wit= h your statement, please provides data, the math and the resulting probabil= ities of collisions. [HS] Updated. Change "If the packet marking interval is large enough" to "I= f the interval between two successive packet marking operation is large eno= ugh". We admit that the original statement is not enough and reliable. We a= dd a paragraph to explain how to acquire guaranteed correlation: "If an app= lication requires guaranteed correlation, this can be achieved by spacing t= he marks so that at most one marked packet of a flow is in flight in the do= main at a time (i.e., the marking interval exceeds the maximum path travers= al plus postcard export delay). The flow ID then correlates the postcards u= nambiguously even under loss or reordering, at the cost of a lower marking = rate." "As a result, it can be assumed that all the exported postcard packets for = the same flow during a short time interval belong to the same user packet." No, it cannot. This seems overly simplified. We need deterministic behavior= , and networks/spec which works all the time. Especially for a troubleshoot= ing tool. [HS] Agreed. We now only state that those postcard packets likely belong to= the same user packet. The new paragraph mentioned above explains how to ac= hieve the guaranteed correlation. "Alternatively, if the network is synchronized, then the flow ID plus the t= imestamp at each node can also infer the postcard affiliation." What do you mean by "synchronized"? How much precision? Does the format of = the timestamp account for different timezone? [HS] Clarified. "synchronized" is now explained in new text: "This requires= the participating nodes to share a common time reference (e.g., using PTP = or NTP) with a synchronization accuracy that is small relative to the minim= um inter-hop latency along the path. Timestamps carried in postcards use a = single global epoch and a format that is independent of local time zones (e= .g., the PTP or NTP timestamp formats defined in RFC9197)." "In many cases, such a rare error has no catastrophic consequence. Therefor= e it is tolerable." Says who? This seems like a personal opinion. I, for one, do not share it. = I don't think that this is good enough for an IETF spec. Care to elaborate for the other cases which have catastrophic consequences? [HS] Agreed. The statement is now deleted and replaced with a deterministic= rule: uncorrelatable postcards MUST be discarded, not reported as a path. ---- =A74.4 Load Control "PBT-M should not be applied to all the packets all the time." So 99% works fine?? It seems to me that the sentence should be much more conservative. e.g., "P= BT-M MUST be applied to a very small subset of packets." Again, could be discussed in the ops consideration section. [HS] Updated to "PBT-M MUST be applied to a small subset of packets." "The RECOMMENDED default marks no more than 1 in 1000 packets (0.1%) of any= single flow, which keeps the added postcard traffic within roughly 0.1% of= the monitored flow rate." This may be seen as still a significant number for some platforms. I wish w= e had the same performance for IS-IS flooding, especially given its importa= nce relative for postcard. I'd like to see a discussion and recommendation for reduced impact on the r= outer. e.g., I would not want IS-IS flooding performance be reduced by post= card generation. Also, the math for the monitored flow rate is not much detailed. It seems t= o rely on assumptions such as the size of customer packets, the size of the= postcard, the number of nodes in transit (N nodes generates N packets for = a single customer packet)... Could you please detail your assumptions and m= ath? Especially since I expect a network operator to re-evaluate the number= s based on its own deployment) [HS] Addressed. We replace the number with an explicit model: variables m (= marking fraction), N (PBT-M-aware hops), R (flow rate), Sc (customer packet= size), Sp (postcard size), giving per-node rate m=B7R, network-wide m= =B7N=B7R, byte overhead m=B7(Sp/Sc) per link and m=B7N=B7(Sp/Sc) network-wi= de, plus a worked example and a note that operators should recompute for th= eir own deployment. [HS] We also add a normative control-plane-protection requirement in Sec. 4= .4: postcard generation MUST NOT degrade control-plane functions (IGP adjac= ency, link-state flooding), MUST run at strictly lower priority with CPU/qu= eue/punt-path subordinated to the control plane, MUST be throttled or skipp= ed (and counted) under contention, and operators SHOULD size the cap so wor= st-case marking leaves IS-IS flooding rate and convergence unaffected. --- "Marked packets in excess of these limits are forwarded normally but do not= trigger a postcard." probably :s/are/MUST be [HS] Fixed. --- "The postcard packets can be distributed to different collectors to balance= the processing load." Section 4.3 seems to say that correlation is already hard/unreliable with a= single collector. Introducing multiple collectors would probably significa= ntly increase the difficulty and section 4.3 would need to be updated to re= flect this. [HS] Sec. 4.3 has been updated to expose the challenges and potential solut= ions. If there are multiple collectors, different distribution algorithms a= nd correlation mechanisms can be applied. In Sec 4.3 now we state that all = postcards sharing a correlation key MUST be steered to the same collector (= e.g., by hashing the key) or to a common correlation function; otherwise th= e packet's postcards cannot be brought together. ---- "Because PBT-M sends telemetry data by dedicated postcard packets, it allow= s data aggregation and compression." not being familiar with postcard, it's not clear to me what type of data ag= gregation and compression you are referring to. A priori, the proposal seems to be willing to track a packet on all transit= nodes. I'm not sure to see what aggregation one may do. At minimum, please elaborate on which node is doing the data aggregation: c= ollector or transit node? [HS] Clarified. Postcard exporting nodes can do data aggregation and export= only aggregated data. For example, the node can be configured to export "the total packets received since the = last flag" or "the maximum buffer depth since the last flag". Such policies are out of the scope of this document. We just point out the = possibility. We update the text to eliminate the ambiguity as suggested: aggregation/com= pression is performed on the on-path node before export; the collector receives already-processed data. ----- =A76 Security Considerations "Only the ingress node is allowed to set these flag bits." You do mean "MPLS ingress node", not "LSP ingress" do you? If so, I'm not seeing this restriction in the specification. And this seems= to significantly reduce its usage. [HS] Clarified. The ingress node here is the LSP ingress node (or path head= node), complying with RFC9994. --- "The other on-path nodes can only react to the bit values. " What do you mean by "can only"? It seems to me that any node could modify the flag en route. If you don't want this to happen, you need measures to avoid this. (e.g., c= ryptographic signature). Since this specification do not propose any measur= e to propose any tampering of the flag, I find the sentence misleading. Esp= ecially in a security consideration section. [HS] Agreed. "can only react" describes only the authorized behavior, but = not an enforced property. We rephrase the text to state the threat model h= onestly: the P-flag is a mutable, unauthenticated bit, so any on-path node = could tamper with it. We do not add per-flag cryptographic integrity (impra= ctical for a single per-packet-mutable, hop-by-hop bit carried in-band, and= contrary to the low-overhead goal; the SRv6 O-bit and IOAM DEX marking tri= ggers share this property). Instead PBT-M relies on the MPLS/MNA domain tru= st model, enforced at the boundary by ingress filtering, bounded by the def= ault rate-limiting posture (so tampering cannot be amplified into DoS), and= made detectable by the counters/anomaly alarms. We'll make these limits ex= plicit rather than implying the flag cannot be modified. --- "Therefore, security measures MUST be taken to ensure the proper functionin= g of these actions." Right. Which are those security measures? And how effective are they? This is the kind of discussion I would expect in a security consideration s= ection. Especially for a specification which indicates that it can be used as an at= tack vector for DoS. [HS] Agreed. We expand the section to assess each measure rather than just = assert it, mapping the threats (external flag injection; on-path spoofing to DoS; on-path clearing/flippi= ng to falsified telemetry; attacks on the export channel) to the mitigations and stating effectiveness and residual risk explicitly, = including the residual risk that we cannot close. --- "Specifically, ingress filtering and the default rate-limiting posture MUST= be applied" What do you mean by the former? Please elaborate on the later (which postures, on which nodes). Any existin= g reference to this posture? Otherwise, please specify those in the body of= this specification. [HS] Good catch. The rate-limiting posture is now fully specified in Sectio= n 4.4 (the marking-rate limit at the head-end node and the postcard-generat= ion-rate cap at every PBT-M-aware node, both enabled by default), and we make the Security section cross-reference it explicitly rather than = referring to it loosely. "Ingress filtering" was indeed used without defini= tion. We add a normative domain-boundary rule to the body (Sec.4.4) and re= ference it here. ___________________________________________________________________________= _________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= _________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_MR1P264MB43540DB9CD943D36AB1384EFF0B82MR1P264MB4354FRAP_ Content-Type: text/html; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Hi Haoyu,

 

Sorry for my late reply.

Thank you for considering my co= mments, for your below reply, and for the updated draft version.=

Thank you especially for your g= ood will and in-depth considerations of the comments. Very much appreciated= .

 

-03 works for me.

 

Best regards,=

--Bruno

 

From: Haoyu Song <haoyu.song@futurewei.com>
Sent: Monday, August 10, 2026 8:26 PM
To: DECRAENE Bruno INNOV/NET <bruno.decraene@orange.com>; mpls= <mpls@ietf.org>; draft-ietf-mpls-on-path-telemetry-flag@ietf.org
Cc: rtg-dir@ietf.org
Subject: RE: draft-ietf-mpls-on-path-telemetry-flag early Rtgdir rev= iew

<= o:p> 

Hi Bruno,

 

Thank you very much for= the careful and detailed RTGDIR review! It’s of great help for us to= improve the draft. We have addressed all the comments in the -03 revision. Please see our inline response marked with [= HS] for each point on the specific change we made.

 

Best regards,

Haoyu=

 

 

Document: draft-ietf-mpls-on-path-telemetry-flag-02

Title: MPLS On-Path Telemetry Network Action Flag for OAM

Reviewer: Bruno Decraene

Review result: Has Issues

 

Hello,

 

I have been approached (but not formally selected due to misunderstanding = on my side) to do a routing directorate “early” review of this = draft.

https://www.ietf.org/archive/id/draft-ietf-mpls-on-path-te= lemetry-flag-02.html

Having reviewed the draft, I’m sending the comments regardless of th= e formal selection.

 

The routing directorate will, on request from the working group chair, per= form

an “early” review of a draft before it is submitted for public= ation to the

IESG. The early review can be performed at any time during the draft’= ;s lifetime

as a working group document.

 

Document: draft-ietf-mpls-on-path-telemetry-flag-02

Reviewer: Bruno Decraene

Review date: 2026-08-05

 

 

Summary

-------

In= general, the draft is clear and readable. Thank you.

I = have some comments, including a few major ones, that I think should be addr= essed before proceeding.

 

Ma= jor:

--= -----

= =A77

&q= uot;This document requests IANA to allocate one bit position (TBA1, suggest= ed value 42)"

Dr= aft should not indicate a suggested value. cf https:/= /datatracker.ietf.org/doc/html/rfc8126#section-3

Th= is looks very close to squatting code points, which leads to interop issues= . Please remove.

 

[H= S] Fixed. We remove (TBA1, suggested value 42) and now just request a singl= e bit position as “TBD1”  with no suggested value, and rem= ove the sentence asserting "Bit Position 42 falls in a Format D LSE...". We keep the allocation constraint as guidance to IA= NA rather than suggesting a squatted value.

 

--= -

 

= =A74.1

&q= uot;The P-flag is therefore placed at Bit Position 42"

Th= is is codepoint squatting.

Pl= ease remove from the spec (until IANA has allocated a code point)

 

[H= S] Fixed. We replace the hardcoded "Bit Position 42 as numbered in Sec= tion 13.2.1 of RFC 9994" with a normative placement requirement (the P-flag MUST be assigned a position outside the MS 2= 0 and MS 23 bits, i.e. in Format D word bits 24-31) and a “TBD1”= ; placeholder pointing to the IANA section. Figure 2 is now labelled "= illustrative only" so the drawn position is not read as an allocation.

 

--= -

= =A74.3

Th= is section essentially states that the data correlation is unreliable.=

I = don't think that this is good enough for important networks.

(A= t minimum, this should be discussed in the operation consideration section.= )

 

[H= S] Addressed. We rewrite Sec 4.3 to provide a deterministic correlation mod= e: at most one marked packet in flight per correlation key actually carried= , enforced at the ingress, and a deterministic failure rule: postcards that cannot be unambiguously correlated MUST be di= scarded rather than reported as a path. A "Correlation Reliability&quo= t; item was also added to the Operational and Manageability Considerations = (Sec 5.1), as you requested.

 

--= -

Th= e document does not specify the interaction with MSD.

 

RF= C 9491 says [MSD] "advertisements allow entities (e.g., centralized co= ntrollers) to determine whether a particular Segment ID (SID) stack can be = supported in a given network."

https://datatracker= .ietf.org/doc/html/rfc8491

 

Th= is document adds 3 LSE to the label stack. In some platforms, this may redu= ce the MSD usable by SR-MPLS.  MUST such node decrement their MSD sign= aling (by 3) to allow controller to perform correct computation?

Su= ch impact should probably be discussed in the ops consideration section, as= 3 may be relatively significant for some platform.

 

[H= S] Addressed. We add an “interaction with MSD”  item in Se= c. 5.1: a node that enables PBT-M and whose usable SR-MPLS label depth is r= educed by the 3-LSE Sub-Stack MUST decrement its advertised (per RFC 8491) by the number of LSEs consumed (up to three) so controllers= compute correct SID stacks; nodes unaffected by the imposition need not ad= just. RFC8491 is added as an informative reference.

 

Mi= nor:

--= -----

= =A72

&q= uot;1: PBT-M avoids augmenting user packets with new headers "

We= ll, draft seems to do exactly that (augmenting user packet with a new heade= r). You may want to rephrase. (e.g. "large header")

 

[H= S] Fixed. Change “new headers” to “new large headers̶= 1;

--=

 

&q= uot;3: PBT-M can avoid interfering with the normal forwarding."

pu= shing the MPLS MNA header seems to interfere with normal forwarding (by red= ucing the available MSD on the Head Node, and the RLD on all transit nodes)=

 

[H= S] Fixed. Our real meaning here is that PBT-M doesn’t incur extra use= r packet processing (e.g., modify or augment the user packets). We rephrase= this sentence to avoid ambiguity. The imposition cost is now also treated explicitly: MSD  (decrement the advertised M= SD) and RLD (the Sub-Stack MUST lie within the Readable Label Depth of the = on-path MNA-capable nodes, and a node whose RLD does not reach the Sub-Stac= k silently behaves as non-PBT-M-aware) in Sec 5.1.

 

--=

 

&q= uot;4: For PBT-M, the types of data collected from each node can vary depen= ding on application requirements and node capability."

I = would assume that this would be true even without PBT-M, otherwise this wou= ld seem difficult to deploy.

 

[H= S] Clarified. For the other on-path telemetry techniques (e.g., IOAM trace = and DEX), the head node stipulates the data types to be collected, and each= transit node must all be able to export the data exactly as requested. For PBT-M, the head node only provides a tr= igger without stipulating the data types, and each transit node can export = data based on its local configuration.  

--=

 

= =A73

&q= uot;Req. 1 (Packet Marking Bit): A user packet needs to be marked to trigge= r the path-associated data collection. Since PBT-M aims to avoid the need t= o augment user packets with new headers, it needs to reserve or reuse a single bit from the existing header fields.&qu= ot;

Do= you mean an existing header field in a specification or in the customer pa= cket?

Th= e former would still augment user packer. The latter would restrict the usa= ge to MPLS packets already carrying MNA.

Pl= ease clarify.

 

[H= S] Clarified. Rephrased as “A user packet needs to be marked to trigg= er the path-associated data collection. Therefore, PBT-M needs to reserve o= r reuse a single bit from existing header fields in a specification (e.g., the MNA encoding).”

--=

 

&q= uot;Req. 4 (Overhead and Security): Since each postcard packet has its head= er, the overall network bandwidth overhead of PBT-M can be high. A large nu= mber of postcards could add processing pressure on data collecting servers. That can be used as an attack vector for DoS.&= quot;

 

Al= so it add processing pressure on all transit nodes sending a postcard. (whi= ch are likely more limited than a server)

 

[H= S] Good catch. We rephrase the sentence as  “A large number of p= ostcards could add processing pressure on all transit nodes sending postcar= ds as well as data collecting servers.”

--= -

= =A74.1

&q= uot;Format D (labeled D) carries the P-flag."

 

Th= e P-flag has never been defined/introduced as this point. May be :s/P-flag/= PBT-M indicator

 

[H= S] Fixed.

 

--= -

 

&q= uot;If the bit is set to '1', a node is triggered to collect and export the= telemetry data as configured by the control plane."=

 

Si= nce this flag is essentially the main part of the specification, could you = please specify what "a node" is?

 

(i= n particular, according to Figure 1, this seems to include the Head Node, w= hich does not seem completely obvious)

 

[H= S] Fixed. Change to “when the bit is set, every PBT-M-aware node that= receive the packet is triggered — explicitly the head-end (originati= ng) node, every on-path transit node, and the egress node within the Hop-by-Hop scope.” to rigidify the scope.  

 

--= -

= =A74.3

&q= uot; Once this is done, the TTL (or the timestamp, if the network time is s= ynchronized) can be used to infer the flow forwarding path."

In= the general case, the MPLS packet carries a label _stack_.

- = The TTL may be set differently in each LSE.

- = And even if not, since only the TTL of the top label is decremented, TTL wi= ll be different across LSE.

 

He= nce this does not seem to work as written. (e.g., after a POP, the TTL on t= he top LSE is likely to _increase_)

Yo= u may want to expand, e.g., by specifying the use of all TTL of all LSEs.

 

[H= S] Thank you for pointing this out. The bug is fixed.  Sec. 4.3 now st= ates plainly that TTL-based hop ordering can't rely on a single TTL because= only the top LSE's TTL is decremented and PUSH/POP make the top-of-stack TTL non-monotonic (it can increase after a = POP). A PBT-M node SHOULD report the per-LSE TTL vector plus its node ID, a= nd the collector reconstructs hop order from that vector, using IGP topolog= y to resolve label operations. We also make Sec 4.2's basic export set consistent ("node ID and per-LSE= TTL").

--= -

 

&q= uot;The first possible approach includes the flow ID in the OAM packets. In= case of MPLS, the MPLS label stack can serve as the flow ID."

I = don't think that this is reliable enough. An MPLS LSP typically aggregates = a very large number of flows, so is not good enough to identify a flow.

 

[H= S] Clarified. A flow could be an aggregated flow sharing the LSP/FEC. If a = 5-tuple flow needs to be identified, data beyond the label stack needs to b= e collected. Text is updated to reflect this change.

 

&q= uot;If the packet marking interval is large enough, the flow ID is enough t= o identify a user packet."

Pr= obably the "interval between two successive packet marking operation&q= uot;.

Ag= ain, I disagree that this is enough and reliable enough. If you stand with = your statement, please provides data, the math and the resulting probabilit= ies of collisions.

 

[H= S] Updated. Change “If the packet marking interval is large enough= 221; to “If the interval between two successive packet marking operat= ion is large enough”. We admit that the original statement is not enough and reliable. We add a paragraph to explain how to acquire g= uaranteed correlation: “If an application requires guaranteed correla= tion, this can be achieved by spacing the marks so that at most one marked = packet of a flow is in flight in the domain at a time (i.e., the marking interval exceeds the maximum path traversal p= lus postcard export delay). The flow ID then correlates the postcards unamb= iguously even under loss or reordering, at the cost of a lower marking rate= .”

 

&q= uot;As a result, it can be assumed that all the exported postcard packets f= or the same flow during a short time interval belong to the same user packe= t."

No= , it cannot. This seems overly simplified. We need deterministic behavior, = and networks/spec which works all the time. Especially for a troubleshootin= g tool.

 

[H= S] Agreed. We now only state that those postcard packets likely belong to t= he same user packet. The new paragraph mentioned above explains how to achi= eve the guaranteed correlation.

 

&q= uot;Alternatively, if the network is synchronized, then the flow ID plus th= e timestamp at each node can also infer the postcard affiliation."

Wh= at do you mean by "synchronized"? How much precision? Does the fo= rmat of the timestamp account for different timezone?

 

[H= S] Clarified. “synchronized” is now explained in new text: R= 20;This requires the participating nodes to share a common time reference (= e.g., using PTP or NTP) with a synchronization accuracy that is small relative to the minimum inter-hop latency along the path. Ti= mestamps carried in postcards use a single global epoch and a format that i= s independent of local time zones (e.g., the PTP or NTP timestamp formats d= efined in RFC9197).”

 

&q= uot;In many cases, such a rare error has no catastrophic consequence. There= fore it is tolerable."

Sa= ys who? This seems like a personal opinion. I, for one, do not share it. I = don't think that this is good enough for an IETF spec.

Ca= re to elaborate for the other cases which have catastrophic consequences?

 

[H= S] Agreed. The statement is now deleted and replaced with a deterministic r= ule: uncorrelatable postcards MUST be discarded, not reported as a path.

 

--= --

= =A74.4 Load Control

&q= uot;PBT-M should not be applied to all the packets all the time."=

So= 99% works fine??

It= seems to me that the sentence should be much more conservative. e.g., &quo= t;PBT-M MUST be applied to a very small subset of packets."=

 

Ag= ain, could be discussed in the ops consideration section.=

 

[H= S] Updated to “PBT-M MUST be applied to a small subset of packets.&qu= ot;

 

 

&q= uot;The RECOMMENDED default marks no more than 1 in 1000 packets (0.1%) of = any single flow, which keeps the added postcard traffic within roughly 0.1%= of the monitored flow rate."

 

Th= is may be seen as still a significant number for some platforms. I wish we = had the same performance for IS-IS flooding, especially given its importanc= e relative for postcard.

I'= d like to see a discussion and recommendation for reduced impact on the rou= ter. e.g., I would not want IS-IS flooding performance be reduced by postca= rd generation.

 

Al= so, the math for the monitored flow rate is not much detailed. It seems to = rely on assumptions such as the size of customer packets, the size of the p= ostcard, the number of nodes in transit (N nodes generates N packets for a single customer packet)... Could you pl= ease detail your assumptions and math? Especially since I expect a network = operator to re-evaluate the numbers based on its own deployment)=

 

[H= S] Addressed. We replace the number with an explicit model: variables m (ma= rking fraction), N (PBT-M-aware hops), R (flow rate), Sc (customer packet s= ize), Sp (postcard size),  giving per-node rate  m=B7R, network-wide  m=B7N=B7R, byte overhead m=B7(Sp/Sc) = per link and m=B7N=B7(Sp/Sc) network-wide, plus a worked example and a note= that operators should recompute for their own deployment.

[H= S] We also add a normative control-plane-protection requirement in Sec. 4.4= : postcard generation MUST NOT degrade control-plane functions (IGP adjacen= cy, link-state flooding), MUST run at strictly lower priority with CPU/queue/punt-path subordinated to the contr= ol plane, MUST be throttled or skipped (and counted) under contention, and = operators SHOULD size the cap so worst-case marking leaves IS-IS flooding r= ate and convergence unaffected.

 

--= -

&q= uot;Marked packets in excess of these limits are forwarded normally but do = not trigger a postcard."

pr= obably :s/are/MUST be

 

[H= S] Fixed.

--= -

 

&q= uot;The postcard packets can be distributed to different collectors to bala= nce the processing load."

Se= ction 4.3 seems to say that correlation is already hard/unreliable with a s= ingle collector. Introducing multiple collectors would probably significant= ly increase the difficulty and section 4.3 would need to be updated to reflect this.

 

[H= S] Sec. 4.3 has been updated to expose the challenges and potential solutio= ns. If there are multiple collectors, different distribution algorithms and= correlation mechanisms can be applied. In Sec 4.3 now we state that all postcards sharing a correlation key MUST = be steered to the same collector (e.g., by hashing the key) or to a common = correlation function; otherwise the packet's postcards cannot be brought to= gether.

 

--= --

&q= uot;Because PBT-M sends telemetry data by dedicated postcard packets, it al= lows data aggregation and compression."

no= t being familiar with postcard, it's not clear to me what type of data aggr= egation and compression you are referring to.

A = priori, the proposal seems to be willing to track a packet on all transit n= odes. I'm not sure to see what aggregation one may do.

At= minimum, please elaborate on which node is doing the data aggregation: col= lector or transit node?

 

[H= S] Clarified. Postcard exporting nodes can do data aggregation and export o= nly aggregated data. For example,

th= e node can be configured to export “the total packets received since = the last flag” or “the maximum buffer depth since the last flag= ”.

Su= ch policies are out of the scope of this document. We just point out the po= ssibility.

We= update the text to eliminate the ambiguity as suggested: aggregation/compr= ession is performed on the on-path node before export;

th= e collector receives already-processed data.  

 

--= ---

= =A76  Security Considerations

 

&q= uot;Only the ingress node is allowed to set these flag bits."

 

Yo= u do mean "MPLS ingress node", not "LSP ingress" do you= ?

If= so, I'm not seeing this restriction in the specification. And this seems t= o significantly reduce its usage.

 

[H= S] Clarified. The ingress node here is the LSP ingress node (or path head n= ode), complying with RFC9994.

--= -

 

&q= uot;The other on-path nodes can only react to the bit values. "

Wh= at do you mean by "can only"?

It= seems to me that any node could modify the flag en route.

If= you don't want this to happen, you need measures to avoid this. (e.g., cry= ptographic signature). Since this specification do not propose any measure = to propose any tampering of the flag, I find the sentence misleading. Especially in a security consideration sec= tion.

 

[H= S] Agreed.  "can only react" describes only the authorized b= ehavior, but not an enforced property. We rephrase the text  to state = the threat model honestly: the P-flag is a mutable, unauthenticated bit, so any on-path node could tamper with it. We do not add per-flag cryp= tographic integrity (impractical for a single per-packet-mutable, hop-by-ho= p bit carried in-band, and contrary to the low-overhead goal; the SRv6 O-bi= t and IOAM DEX marking triggers share this property). Instead PBT-M relies on the MPLS/MNA domain trust mo= del, enforced at the boundary by ingress filtering, bounded by the default = rate-limiting posture (so tampering cannot be amplified into DoS), and made= detectable by the counters/anomaly alarms. We'll make these limits explicit rather than implying the flag can= not be modified.

 

--= -

 

&q= uot;Therefore, security measures MUST be taken to ensure the proper functio= ning of these actions."

Ri= ght. Which are those security measures? And how effective are they?

Th= is is the kind of discussion I would expect in a security consideration sec= tion.

Es= pecially for a specification which indicates that it can be used as an atta= ck vector for DoS.

 

[H= S] Agreed. We expand the section to assess each measure rather than just as= sert it, mapping the threats

(e= xternal flag injection; on-path spoofing to DoS;  on-path clearing/fli= pping to falsified telemetry; attacks on the export channel)

to= the mitigations and stating effectiveness and residual risk explicitly, &n= bsp;including the residual risk that we cannot close.

 

--= -

&q= uot;Specifically, ingress filtering and the default rate-limiting posture M= UST be applied"

Wh= at do you mean by the former?

Pl= ease elaborate on the later (which postures, on which nodes). Any existing = reference to this posture? Otherwise, please specify those in the body of t= his specification.

 

[H= S] Good catch. The rate-limiting posture is now fully specified in Section = 4.4 (the marking-rate limit at the head-end node and the postcard-generatio= n-rate cap at every PBT-M-aware node, both enabled by default),

an= d we make the Security section cross-reference it explicitly rather than re= ferring to it loosely. "Ingress filtering" was indeed used withou= t definition. We add a normative domain-boundary rule to the body (Sec.4.4)  and reference it here.<= /p>

 

_________________________________________=
___________________________________________________________________
Ce message et ses pieces jointes peuvent =
contenir des informations confidentielles ou privilegiees et ne doivent don=
c
pas etre diffuses, exploites ou copies sa=
ns autorisation. Si vous avez recu ce message par erreur, veuillez le signa=
ler
a l'expediteur et le detruire ainsi que l=
es pieces jointes. Les messages electroniques etant susceptibles d'alterati=
on,
Orange decline toute responsabilite si ce=
 message a ete altere, deforme ou falsifie. Merci.
 
This message and its=
 attachments may contain confidential or privileged information that may be=
 protected by law;
they should not be d=
istributed, used or copied without authorisation.
If you have received=
 this email in error, please notify the sender and delete this message and =
its attachments.
As emails may be alt=
ered, Orange is not liable for messages that have been modified, changed or=
 falsified.
Thank you.
____________________________________________________________=
________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_MR1P264MB43540DB9CD943D36AB1384EFF0B82MR1P264MB4354FRAP_--