Return-Path: X-Original-To: pce@mail2.ietf.org Delivered-To: pce@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id D63CEBDC11D6; Wed, 25 Feb 2026 01:15:40 -0800 (PST) X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.793 X-Spam-Level: X-Spam-Status: No, score=-2.793 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_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ag2lWagI1iGL; Wed, 25 Feb 2026 01:15:39 -0800 (PST) Received: from smtp-out.orange.com (smtp-out.orange.com [80.12.126.237]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 3E39FBDC11C4; Wed, 25 Feb 2026 01:15:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; i=@orange.com; q=dns/txt; s=orange002; t=1772010939; x=1803546939; h=to:cc:subject:date:message-id:references:in-reply-to: mime-version:from; bh=H9MIFCB4+1LCkDf2fK/KhNENJVMLAptaJ96WsEduyI8=; b=T3y44KMjZUB3F2cQv4Cj4QN6MfRjkc+p2UsE2RMhnaFTMOhbUaxgKFaB 3SzFqMlMNhJIOnbRmD+qMz+aHR+Cry0+LAfldEM6z4sQTRiMvVdUdmIoV /pHj4iAYN/pkbQlgL6JHePkcAKVvFlh+8SeacGusvj++UZQWXjTFc/ZgA 1mwu74Es4oT1UXp75Ek1xEudV+EEJLhEyCenY/dRbt/VhqZf583FDNfjS TKExOsKdtlkxf5bBT2ZWuCuCiliL9DDcPLv26jGxMD6/q0RHhO+63BCHd mUwQyn0RMVmwfKfp6WLKz7hnWOFith5aLDaeMhF2lBHTVVjdCBOTpsGu3 Q==; X-CSE-ConnectionGUID: 095jwtAcSom93dyQ7BM9bQ== X-CSE-MsgGUID: Y+4kbaY7TX6QbLLktUPapw== Received: from unknown (HELO opfedv1rlp0f.nor.fr.ftgroup) ([x.x.x.x]) by smtp-out.orange.com with ESMTP/TLS/TLS_AES_256_GCM_SHA384; 25 Feb 2026 10:15:38 +0100 Received: from unknown (HELO opzinddimail15.si.fr.intraorange) ([x.x.x.x]) by opfedv1rlp0f.nor.fr.ftgroup with ESMTP/TLS/TLS_AES_256_GCM_SHA384; 25 Feb 2026 10:15:38 +0100 Received: from opzinddimail15.si.fr.intraorange (unknown [127.0.0.1]) by DDEI (Postfix) with ESMTP id D1A3A1E820E0; Wed, 25 Feb 2026 10:15:37 +0100 (CET) Received: from opzinddimail15.si.fr.intraorange (unknown [127.0.0.1]) by DDEI (Postfix) with ESMTP id BEBB21E8206E; Wed, 25 Feb 2026 10:15:37 +0100 (CET) Received: from smtp-out365.orange.com (unknown [x.x.x.x]) by opzinddimail15.si.fr.intraorange (Postfix) with ESMTPS; Wed, 25 Feb 2026 10:15:37 +0100 (CET) Received: from mail-francesouthazlp17010019.outbound.protection.outlook.com (HELO MRZP264CU002.outbound.protection.outlook.com) ([40.93.69.19]) by smtp-out365.orange.com with ESMTP/TLS/TLS_AES_256_GCM_SHA384; 25 Feb 2026 10:15:38 +0100 Received: from PAUP264MB6756.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:52c::5) by MR1P264MB1842.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:12::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9632.24; Wed, 25 Feb 2026 09:15:33 +0000 Received: from PAUP264MB6756.FRAP264.PROD.OUTLOOK.COM ([fe80::8b83:578b:5221:8deb]) by PAUP264MB6756.FRAP264.PROD.OUTLOOK.COM ([fe80::8b83:578b:5221:8deb%3]) with mapi id 15.20.9632.017; Wed, 25 Feb 2026 09:15:33 +0000 From: mohamed.boucadair@orange.com X-CSE-ConnectionGUID: MaugpK04TfK/cogCKmtVfA== X-CSE-MsgGUID: qDfb/ivuQD2t7AVgA+PbcQ== X-TM-AS-ERS: 10.106.160.161-127.5.254.253 X-TM-AS-SMTP: 1.0 c210cC1vdXQzNjUub3JhbmdlLmNvbQ== bW9oYW1lZC5ib3VjYWRhaXJAb 3JhbmdlLmNvbQ== X-DDEI-TLS-USAGE: Used X-CSE-ConnectionGUID: X1pKHrt6Q36G5/w1YIrOUw== X-CSE-MsgGUID: v+s4WvTURTWJO4w7dhWYtQ== IronPort-Data: A9a23:SJTvTaxFPz2Sd58+5L16t+e1xirEfRIJ4+MujC+fZmUNrF6WrkUFz WJKXWqGMq2LNGDxf4glbIjg8BkHuZLRzd81QQc5pS00HyNBpPSeCIXCJC8cHc8zwu4v7q5Dx 59DAjUVBJlsFhcwnj/0bP656yM6jPjSLlbFILasEjhrQgN5QzsWhxtmmuoo6qZlmtHR7zml4 bsemOWBfgX8s9JIGjhMsf/a8kk25K+aVA4w5TTSW9ga5TcyqFFFVPrzFYnpR1PkT49dGPKNR uqr5NmR4mPD8h4xPcium7D9f1diaua60d+m0yc+twCK23CulwRqukoJHKN0hXR/0l1lq+tMJ OBl7vRcf+uL0prkw4zxWzEAe8130DYvFLXveRBTuuTLp6HKnueFL/hGVCkL0YMkFulfMThW1 twCNG40NU6s2qWpmYOaUM5RmZF2RCXrFNt3VnBI6AvrNax4Hbv+G/2Qo9hFwD03m8ZCW+7EY NYUYiZuaxKGZABTPlAQC9Q1m+LAanvXL2Ue+QnT+/txujm7IA9ZiNABNPLQfdyDQMhZ2Eyfu 2nP8234GDkdLtWZxjfD+XWp7gPKtXqiCdlCTOPlr5aGhnWNhXdPNwMqaGGHntue1lHhV9JgG lAtr39GQa8arxfxEoaVsweDiGWfvxIbQfJbEvYx70eGza+8yweUHWcsTzNdZpohrsBebTAm/ lOJhc73CTxovKzTQnWYnp+Ytzq8JW0UIHMMIDcPQE4O4sPovYAvywnTX9JuVba+g8WwFCHsz jaRrS84nJ0SgNIFkaKh8jjvmzmh45PJRw8v/S3WU36rqARja+aNf4elwVnW8fgGK5yWJmRtp 1ABksmaqe4UBJeGmTeKXfkNFaOt/6/aaGSE2Qc+WZ486z6q5nivO5hK5y1zL1toNcBCfiL1Z EjUukVa45o70GaWgbFfU9upKOQw0fbZTorKC7fLN+tveL9Ma1rSlM1xXnJ8yVwBh2ACq8kC1 XqzdM+tCTMUE61hxzetQPoB0bY5wjhnmjuKHciinlKgzKaUY2OTRfEdKlySY+sl7aSC5gLI7 9JYMMjMwBJaOAEfXsU12dBIRbzpBSFkbXwTlyCxXrXdSuaBMDpwY8I9OZt7J+RYc119z48kB E1RpXO0OHKk3iebdm1mm1hmabj1Wo14o25zNis2JT6V5pTXWq72tP13X8JuJdEPrbU/pdYqF aVtU5vbWJxnFG+YkwnxmLGh9uSOgjz331rWZ0JIoVEXI/ZdeuA+0oa5JlS0qXlfUnTfWAlXi +TI6z43iKErH2xKZPs6otr2p79tlRDxQN5PYnY= IronPort-HdrOrdr: A9a23:K/auS6i4Fj5VdzCtLmBz02JEXHBQX1F13DAbv31ZSRFFG/FwyP rCoB1L73XJYWgqM03IwerwQJVpQRvnlaKdkrNhRotKPTOW8FdAQ7sSibcKrwePJ8S6zJ8l6U 4CSdk0NDSTNykcsS+S2mDRf7kdKZu8gcaVbIzlvhRQpHRRGsRdBnBCe2Sm+yNNJTVuNN4cLt 6x98BHrz2vdTA8dcKgHEQIWODFupniiI/mSQRuPW9r1CC+yReTrJLqGRmR2RkTFxlVx605zG TDmwvloo2+rvCAzAPG3WO71eUbpDKh8KoNOCW/sLlVFtzesHfpWG2nYczAgNkBmpDg1L/tqq iPn/5vBbU315qbRBDOnfKk4Xic7N9p0Q6p9bbQuwqdnST0KQhKd/ZplMZXdADU5FEnu8w52K VX33iBv54SFh/Ymj/hjuK4IC2Cu3DE1EbKq9Rj+0B3QM8bcvtcvIYf9ERaHNMJGz/78pkuFK 1rANvH7PhbfFuGZzSB11MfieCETzA2BFOLU0ICssua33xfm2141VIRwIgakm0b/JwwRpFY76 DPM7hulrtJUsgKBJgNctspUI+yECjAUBjMOGWdLRDuE7wGIWvEr9rt7LA89IiRCe41JVsJ6e f8uX9jxB4PkhjVeLOzNbVwg2HwfFk= X-Talos-CUID: =?us-ascii?q?9a23=3ACdyRs2hEiEWzZqO37PS+V/xvIzJuQiTF71fKPxG?= =?us-ascii?q?BUjhGFfqKEG6x4oRZjJ87?= X-Talos-MUID: =?us-ascii?q?9a23=3AzA3eKgyD0iyDf0eLqHRijed/EBmaqLrtExwyj6k?= =?us-ascii?q?7gfW7FwssJGiRjAuGXrZyfw=3D=3D?= X-IronPort-AV: E=Sophos;i="6.21,167,1763420400"; d="scan'208,217";a="119380651" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=nhulQQaqvbtKMxDtbKVTrEGqImEuKbtRyoEJiiVv4wnlVDyjogH8+eFVkTu3MXbAgFx64Cd6/UErpN7Fn3IinapcbhnQCAwYYeOZ/IztB0GRUOaiSKjtKbTytZY91GVNWW3dbbD8sLWxuR2pwORO0hepZNU3uN6iLrna/K5rk4kxOxdYAAxeJyoNHZat0bBVC7NrAaHlGiccJWqqMVpNMdWf4LK3BVUwE6eTvwRY+R9KZTnBFXcxANks9IQBKWYiz5AmUDg7Z/kkoqDL63wzMHii4fcU93hRxqsdkJ16gPtp5SMMP9+Yq1yU7ZI2qnOdsD2IyAc3eMlOG27lGrYf0g== 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=mZsMeO3uSVQjP+npG+r0bQiF2YDU4jWkVIrgsTF5eWA=; b=KEc5P0JQKyLCPdVN/x6VJICdHkMQJCGB1oep8268KR0ODqmRe4+ADMwU4K3FAbwlwRPRMgz3+LJfhrf3AWz0MwDuIlh6VdamU8MlpVg65E+pNHYNCPr4OrZENfKl2qjZlb/o9wwqSRl5Iiq24x8GTjKGoLdaF3g0ZBpg86WzFjtdq6IE91Koms/uizr+ZVHhNK2lbmCZAG9u5ZqEJkCWaVe9f3iWO7ejNIcWXyQkIUjNTO1+2VvpZ8tL3fkMPEyXU9FmEC0kBUJ0BB+5yp7+k0XgMD+JVefy8mNkLL7eO8xwM7kS+4thswKCqW9OKbntVcvT+lBkqI2gxnLm2S+qVQ== 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: "Samuel Sidor (ssidor)" , The IESG Thread-Topic: Mohamed Boucadair's Discuss on draft-ietf-pce-circuit-style-pcep-extensions-13: (with DISCUSS and COMMENT) Thread-Index: AQHcpWtuRwgeRW8e+kCZHo1X/iftj7WR5bzcgAEzsNA= Date: Wed, 25 Feb 2026 09:15:33 +0000 Message-ID: References: <177192336461.2276858.16691692862770025212@dt-datatracker-6ff7c68975-7k42g> 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=979bb27c-10f2-47e4-84ca-2fc78971b7a8;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-02-25T08:38:42Z;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;MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_ContentBits=0;MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Enabled=true;MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Method=Standard; authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=orange.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: PAUP264MB6756:EE_|MR1P264MB1842:EE_ x-ms-office365-filtering-correlation-id: 32613ecc-5340-41c8-8eba-08de744e6dfb x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|1800799024|13003099007|38070700021|8096899003|7053199007; x-microsoft-antispam-message-info: iraWuS4OI7UIGIRfVUfkAEdaN8UzRVkMJsL8PjxOo+oxC39wVKUE7IHlL6PeyDoXr5YZRTnbTt7NgG5Rp44WNWUKR5UrDgrwEY3eKGhZS4uCK8RMsHcNUTcScMbrB3OEX1btkCZ4W3q0r2/2yWgBT0rTbpdqnoJ5F+caHsBW3gKO6VooaPwThfrFOo+I6WjS5CAAgAOnm3T0fg7zsdjk0C19773y3miI+UQX+H2wa2v8GjoRNIY2nZT5g9RNwUcbtKgP3WaVxQAdm3+T+oyvO4y9F89mb5PFYSZA+THSwLObrz+hu+s++aYF3gSq5+HXovB4o0mektk7QJkpSoxAGvbKC3GPLqL5JLb3bUPemurtI72KZbWCst3QUTxTEeMc3iIj9tE+SxEVs5PbHEv/CNaFuoSTz3mC8KfG4XBU+RJ6eQ9p/G+wzI0LziePgCGxtHrfLgsnsVwfrAFWNaldml2RtiyvAuKnqEsDK8cPXoQzj5sIq6mHmvu3NBFL/WNKICHVLl64vO3d9kTB0J5d6XZ9B30qSWUPvq3vywKTGRJMlQzSMe/KpPPxSGSLOycKpoWPfB7D18Z0ZuJoEbKZkyVeeNO2zBrW0w/AwVJaXPn0SPvyMVDFRTBBg9puGuWPv+HMv7JsC+NqUMWfcdgy37TpjUEwBadcM0MWZSvHSpN+mrUIHCz2GWMvt9yN9zv9azCCqQefvue04/jNypW4k9IypadRcQoNCzgQMVYNyUr9fq9XVQSHgRY8Mp5t69nt x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAUP264MB6756.FRAP264.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(13003099007)(38070700021)(8096899003)(7053199007);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?fAGSMnYb741DSdEOCLrwkQzsPaJ+AMfTjSGxlwjcAcGcbNVpw/JvAm7vcA?= =?iso-8859-1?Q?WPGt3ECzU2R0CrTAInTnOWbSuZyRxLrWBWQpx2myGi44l4ENsEd6TGEzmD?= =?iso-8859-1?Q?ga9qqEikcxlgpI8Pulnw7QoQV3Dfoh3axrgCbJe3pW3duRgCwrIK+HA/dS?= =?iso-8859-1?Q?jzFbIBs5uXgK01ArxAXSz7HuPRDifcli5FtNA6hYsRqdtrrDnKgeC+L/XZ?= =?iso-8859-1?Q?7H2py/LkU3ttXbka9KBfPIa+ehuuDVVj2qrIMfBIkHcfjx1sbVtMgykiqu?= =?iso-8859-1?Q?E+VDGJBJuoA1iqmNAb/kWniCKDWeu2V5g7yMdBPaPZN2T/RP/VNkWqF60B?= =?iso-8859-1?Q?H2KHQ4Sj2dQC1s7FhaaOULqq1E41J7iN4fMI/pHSIbY7D/buSUCBXAbCNq?= =?iso-8859-1?Q?brqbgHuuE8OljxZoesmgCokVcSIPL5bQRf5br+YRxRy5sKBjA4jXDCNKvT?= =?iso-8859-1?Q?gqrLaO1OJ20E0EOnBgh7+4oml+weru1iUKLXNRF7D+Lrz3W4oHIv4bEJ8E?= =?iso-8859-1?Q?BunItbLwvAiL1LAEpw+YMq2RdzlvThnv/J+TAUYuwG9PFUoPUUVBHRubJn?= =?iso-8859-1?Q?UJZ6S/7tqmumJvc97qe3UVxull8iZU6a8hOiI+jGByWm8DD0aPEOuopqOU?= =?iso-8859-1?Q?G+WpqSnhvRr0uVe68hb51X6IZXGMG7M8Z/cs7/usi7L+B+WxNy3TzTKQj2?= =?iso-8859-1?Q?CAGHdwSPcdeIzzr3x3V21ZLQRfKsczHpnaIEInaIQY2xD3X8rhGzHRjT0h?= =?iso-8859-1?Q?8KGkXD0ALYzf7Bwlv4zxceTCNFd+SkIo+ax/0rvt15f99PfEjouQVvRyS+?= =?iso-8859-1?Q?FSxulBMyldbYNp37LELsE1Eu0OzQfzIMj3wjfekUFfrMCpZo52mjLXShkq?= =?iso-8859-1?Q?AEr6yz7SzfsYhkAluqL/hfeb1cFDhqRGRfFTuzxjxkvxIZSK9uBsWqOYID?= =?iso-8859-1?Q?HKHvqzqatCxq3knuD/xlhbP8hXIHCpo1ytlxYlXbr04oJZAzHDUy86xaSu?= =?iso-8859-1?Q?YdIhxLYIhMBU7oTdQwYXtGwrgEFD1T49WgMv5PGz92uu2d1rSPu7YrGmRM?= =?iso-8859-1?Q?NviQGXe2I/WXpbFrYerkHz9zVF82Or4WsqOyMm89K03L1lWOzJpoIGSkU5?= =?iso-8859-1?Q?w6O3874P1yeS3LaBdGHaDL1VMO5NvFdI2ZvHbxQyZh0ObFmeDnOE1ho71D?= =?iso-8859-1?Q?+hqoyhfEN4YE5yxzOIOOApBNUpmUM2QupvyMYEVt6Yg+a5WCngxTonj7xn?= =?iso-8859-1?Q?P1IAjY5YDc9tKYRPCEi3W8UAg1s4xzCTaG7QmFsd/WzQOI9aTL5jkG4kPn?= =?iso-8859-1?Q?ZHJlCx8GXlfjoJH/4U76QWK8RrS/MMFERwDomGUnYm5VvLNEzt4VtmonhT?= =?iso-8859-1?Q?5ovz5rolGzaPtlKmf84l8CVDecXKTNBc+OEskIP5rvHCbuSEhHUo+sxs8U?= =?iso-8859-1?Q?yb84R5IyjcLFSZpnxwhVa3NArCqY8fqw92jNxKlMIOeIQc0N1E6qjYkpJj?= =?iso-8859-1?Q?t/r5wSvqVVRIc3PswMY5SFaRasbggje4l92Cys5V+MOL02BJ9FUWphNgKC?= =?iso-8859-1?Q?hDbeaAOAUFctnmgN50IJXSneq/ZIIylnrMTO4TyC+8kLRaRbqnBgj/hooE?= =?iso-8859-1?Q?ikSCfN0BP4nCLe0oc8PINHtWYgRn5iTqCe0g/+ZCUUliknAlAdJEj125yB?= =?iso-8859-1?Q?yt9oAkVh8sLGZ6308bXM955Gn06rnVlEZKLgnfFlFcsZOmcmUSR3AHtAN1?= =?iso-8859-1?Q?ZQRwbJ9tjezQF0Vfr0d7ZjLCcDgwbrKIyRjTFhF6WXoZCbN/i1BR3c1O36?= =?iso-8859-1?Q?T63ssBA5I/n/uTBx4hJPpOCI7Oretqk=3D?= Content-Type: multipart/alternative; boundary="_000_PAUP264MB675625B1FE8CFD92267FBBBB8875APAUP264MB6756FRAP_" MIME-Version: 1.0 X-OriginatorOrg: orange.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PAUP264MB6756.FRAP264.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 32613ecc-5340-41c8-8eba-08de744e6dfb X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Feb 2026 09:15:33.4049 (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: JvyEQ+CHrvo2LVqcWnR0xyz6wtG0xNc9zF9iBV5jEHwnOdmIl7EdcuZslh0ndyADfAV7/po7afGcfUuIk/xqq0oNwMPsF/mwrH2oq+uRMWg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MR1P264MB1842 X-TM-AS-ERS: 10.106.160.161-127.5.254.253 X-TM-AS-SMTP: 1.0 c210cC1vdXQzNjUub3JhbmdlLmNvbQ== bW9oYW1lZC5ib3VjYWRhaXJAb 3JhbmdlLmNvbQ== X-TMASE-Version: DDEI-5.1-9.1.1004-29782.006 X-TMASE-Result: 10--44.288700-10.000000 X-TMASE-MatchedRID: iKTMlETJ4pvyCZGzF+DOCQxvavcYV2dIvHKClHGjjr1vQ1w4VLB58jAD TOtbgClvTledWAKUpYrVSDZW9GFolbk8FmdX224cXxunv609SoVSAphtkUXoaD7JpnLen5simel O0IZKkZ6NRCPAFosOlN9LK56sfoMIFkUYwmSiUmS29CW3ILLb8s36paW7ZnFo+KgiyLtJrSBLpC LN4NR43gQ0R9JaFa4aK+NqKZMXQX7K+QFXYp+GtQHth38hX4u2L2H/baNa/M/QqMZkSLLjU1bQ7 XZbkG2hc4oHnhoiTKwMpd+A7BXtAPHVLSuAbWfAr4JCzA6K3s8vun/+8u/hsywJzaIVMjGtmbc4 hVJ/g/nynQxWKo+F0SdrKX/gwnicQ7XehYsr+VMxwpV6SC1VrKML2eLfzGFuYEpG2D2kcRqRfq3 Xua9z29BBeW0QNlfKg8QT+c7qUeSNMkq6FfSn6r+8m9tI8d44CtzGvPCy/m5vrcC8cqLKod+CFg PG/6Vdh+toLLKXwREUpKdP8O/HuO8EEeEKKEyuY3oSvrKk+Nf3Hev8a6G/J0+crEA4+nhZIf0Nf cM6bxtPCVNdGJmNwbC/PLGir1JpR/O10gLRq8W7tV1fX4pRsziEPRj9j9rvM9EkAUzyluH/z5X0 KzxduijEINafKEeOvdSctyGjnFfpeLvPyqEPfmWZ9CbZZf+b194/5X9VfCx4Xox68xVlQNxq159 FIVQpURWQU/uPczio6nQeBnr4CdJY3AuX0befofDSIGnaDB5rzsINdopFUithirXYhZk5JyF8Bo MrCNDv/72zC4hJFVhUDZOPhwqI54mbosKUuYdj1vXr7GCgWkbgTmf4sxQ0mkCGwliFomubKItl6 1J/yZUdXE/WGn0FAOtc250L4nSa0k2he5NwuCIWyOG3VFHjx/OaSH9EKluBJYlK/CZEP5RMZUCE HkRt X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0 X-TMASE-INERTIA: 0-0;;;; X-TMASE-XGENCLOUD: 4f7a28a2-c8ab-48fc-b774-c76aead90c23-0-0-200-0 Message-ID-Hash: 4DH3BS3Y7VPHE543C63XZZ5TAMR7NBFX X-Message-ID-Hash: 4DH3BS3Y7VPHE543C63XZZ5TAMR7NBFX X-MailFrom: mohamed.boucadair@orange.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-pce.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: "draft-ietf-pce-circuit-style-pcep-extensions@ietf.org" , "pce-chairs@ietf.org" , "pce@ietf.org" X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BPce=5D_Re=3A_Mohamed_Boucadair=27s_Discuss_on_draft-ietf-pce-ci?= =?utf-8?q?rcuit-style-pcep-extensions-13=3A_=28with_DISCUSS_and_COMMENT=29?= List-Id: Path Computation Element Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --_000_PAUP264MB675625B1FE8CFD92267FBBBB8875APAUP264MB6756FRAP_ Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi Samuel, Thank you for the follow-up. Please see inline. Cheers, Med De : Samuel Sidor (ssidor) Envoy=E9 : mardi 24 f=E9vrier 2026 15:55 =C0 : BOUCADAIR Mohamed INNOV/NET ; The IESG = Cc : dd@dhruvdhody.com; draft-ietf-pce-circuit-style-pcep-extensions@ietf.o= rg; pce-chairs@ietf.org; pce@ietf.org Objet : Re: Mohamed Boucadair's Discuss on draft-ietf-pce-circuit-style-pce= p-extensions-13: (with DISCUSS and COMMENT) Thanks a lot, Med for review. Please find inline responses marked with . Regards, Samuel From: Mohamed Boucadair via Datatracker > Date: Tuesday, 24 February 2026 at 09:56 To: The IESG > Cc: dd@dhruvdhody.com >, draft-ietf-pce-circuit-style-pcep-extensions@ietf.org >, pce-chairs@ietf.org >, pce@ietf.org > Subject: Mohamed Boucadair's Discuss on draft-ietf-pce-circuit-style-pcep-e= xtensions-13: (with DISCUSS and COMMENT) Mohamed Boucadair has entered the following ballot position for draft-ietf-pce-circuit-style-pcep-extensions-13: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-= ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pce-circuit-style-pcep-extensio= ns/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Hi Samuel, Praveen, Andy, Luay, and Shuping, Thank you for the effort put into this specification. The document is well-written, especially operational considerations are well-articulated. That's exemplar. Congrats for such a high quality document. Thanks to Luis Contreras for the detailed OPSDIR review. I appreciate that = the authors engaged and implemented the outcome of the discussion with Luis. Mu= ch appreciated. Thanks a lot, Med and thanks to those who contributed to the draft in a= ny way (discussions, reviews, proposed texts,...). Please find below one easy-to-fix point for DISCUSSion: # Circuit Style CURRENT: This document uses the following term described in [I-D.ietf-spring-cs-sr-policy]: * Circuit Style (CS) SR Policy ## That notion is important to digest as these extensions are defined for = that case. ## Unless you want to add this as normative, and as this is only one term, = you may mirror that definition here to avoid normative dependency. ## BTW, note that this term is not used as such Circuit Style SR Policy Even if mirroring that definition is not ideal, but I think that it is = stable enough and we can possibly still reference spring document like this: This document defines the following terms: * Circuit Style (CS) SR Policy: An SR Policy designed to satisfy requir= ements for connection-oriented transport services. CS SR Policies are chara= cterized by path persistency (where the path should remain stable unless ex= plicitly changed or becomes invalid) and may require strict hop-by-hop path= construction. Further details on CS SR Policies are described in . * Path Modification: Refers to the PCE instructing the PCC, via a PCUpd= message, to use a path whose set of traversed network hops differs from th= e current path. A PCUpd message that changes only the attributes or re-enco= des the same hop sequence (e.g., alternative SID representation) is not con= sidered a path modification. Would that work for you? [Med] Yes, it does. I see that I-D.ietf-spring-cs-sr-policy is scheduled fo= r this telechat as well. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Flags ## CURRENT: This document defines the following new flags in that TLV: Maybe better to point to https://www.iana.org/assignments/pcep/pcep.xhtml#stateful-pce-capability-tl= v-flag-field where the up to date set of flags are maintained. This is better than the s= ole RFC8231 pointer. That IANA registry is referenced in IANA section by registry name alrea= dy (instead of using direct link, which does not seem to be common practice= in other existing RFCs). What about just adding reference to section 8.1 a= nd indicate that has more details about IANA registry with existing values? [Med] The reflex I had when reading that part is whether we are tracking th= e flags and that guards are there to avoid flag conflicts, etc. I have to l= ook in the IANA registry for that check. I would save other readers like me= by providing the IANA registry near that text. That would maintain consistency and still at least partially simplify looku= p for those values without introducing any risk - e.g. if liveness of those= URLs is not guaranteed. ## CURRENT: This document specifies the new Strict-Path flag in the LSP-EXTENDED- FLAG TLV. Maybe point to https://www.iana.org/assignments/pcep/pcep.xhtml#lsp-extended-flag-tlv-flag= s as well. Same as above. [Med] Idem as well. # Section 3.3 I would make this change: OLD: When F is set to 1, the P flag value is ignored. NEW: When F is set to 1, the P flag value MUST be ignored. Ack, I'll change it. [Med] ACK # Avoid Geocoordinate interfaces OLD: or northbound Application Programming Interface (API) on the PCE). NEW: or a dedicated Application Programming Interface (API) on the PCE). It seems to be standard term used in other RFCs, e.g. https://datatracker.ietf.org/doc/html/rfc7426#section-4 But I can still change it (no harm). [Med] Putting aside that 7426 is not an IETF doc, the reason why I'm in fav= or for geocoordinate interfaces is that there are relative, confusing, brea= k when recursing is in place, etc. Anyway, thanks for accommodating and mak= ing the change. # Clarity of flag checks OLD: P flag set (P=3D1): NEW: P flag set (P=3D1) and F=3D0: Even if I agree with you that combination is the only one valid, but th= at paragraph is really describing P=3D1 with both cases - F=3D0 and F=3D1. = Originally we tracked all combinations of flags and we explicitly tried to = define each flag separately now to simplify extensibility in the future. [Med] The reason why I made this comments is that we do say under the descr= iption "When F is set to 1, the P flag value is ignored". So for me, P=3D1,= F=3D1 is still a valid (as this does not trigger any error message), but t= hat P is simply ignored. BTW, intuitively, I would put F before P in Figure 1, but I didn't made tha= t suggestion as I don't want to alter any implementation out there. # Section 5 I know the context of that naming in PCE, but the considerations are beyond management. Also, in order to be consistent with latest discussion in OPS, I suggest the following change: OLD: 8. Manageability Considerations NEW: 8. Operational Considerations I'm not sure if that would not create even more confusion, especially s= ince this draft is really not introducing any new considerations and just r= eferring to existing "Manageability Considerations" sections in existing RF= Cs. But I was not following discussion which you mentioned, can you please = point me that "latest discussion in OPS"? [Med] This is related to RFC5706bis mentioned in Luis review. I don't see a= ny issue out there. Please see the change proposed by Rakesh to address thi= s similar point at https://mailarchive.ietf.org/arch/msg/pce/4Sy0SrTXoeD4UC= Tf9946IsmRhlE/. Thanks. # nits ## paradigm Source routing was there before SR. Can we please consider this change thro= ugh the doc: OLD: source routing paradigm NEW: source routing ## One term OLD: This document uses the following terms defined in [RFC9256]: NEW: This document uses the following term defined in [RFC9256]: ## Section 3 OLD: * Indicate the requirement for strict hop-by-hop paths, * Signal path persistency by disabling path modification for specific paths, * Identify and control behavior specific to CS SR policies. NEW: * Indicate the requirement for strict hop-by-hop paths, * Signal path persistency by disabling path modification for specific paths, and * Identify and control behavior specific to CS SR policies. ## draft OLD: Circuit-Style Policy draft [I-D.ietf-spring-cs-sr-policy] NEW: Circuit-Style Policy [I-D.ietf-spring-cs-sr-policy] Ack, updated all of them. [Med] Thank you Samuel. Cheers, Med ___________________________________________________________________________= _________________________________ 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_PAUP264MB675625B1FE8CFD92267FBBBB8875APAUP264MB6756FRAP_ Content-Type: text/html; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Hi Samuel,

 

Thank you for th= e follow-up.

 

Please see inlin= e.

 

Cheers,

Med

 

De : Samuel Sidor (ssidor) <= ssidor@cisco.com>
Envoy=E9 : mardi 24 f=E9vrier 2026 15:55
=C0 : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.= com>; The IESG <iesg@ietf.org>
Cc : dd@dhruvdhody.com; draft-ietf-pce-circuit-style-pcep-exten= sions@ietf.org; pce-chairs@ietf.org; pce@ietf.org
Objet : Re: Mohamed Boucadair's Discuss on draft-ietf-pce-circu= it-style-pcep-extensions-13: (with DISCUSS and COMMENT)

 

 

Thanks a = lot, Med for review.

&nbs= p;

Please find inline respo= nses marked with <S>.

 =

Regards,

Samuel=

 =

From: Mohamed Boucadair via Datatracker &l= t;noreply@ietf.org>
Date: Tuesday, 24 February 2026 at 09:56
To: The IESG <iesg@ietf.org&= gt;
Cc: dd@dhruvdhody.com <<= a href=3D"mailto:dd@dhruvdhody.com">dd@dhruvdhody.com>, dr= aft-ietf-pce-circuit-style-pcep-extensions@ietf.org <draft-ietf-pce-ci= rcuit-style-pcep-extensions@ietf.org>, pce-chairs@ietf.org <pce-chairs@ietf.org>, pce@ietf.org <pce@ietf.org>
Subject: Mohamed Boucadair's Discuss on draft-ietf-pce-circuit-style= -pcep-extensions-13: (with DISCUSS and COMMENT)

Mohamed Boucadair h= as entered the following ballot position for
draft-ietf-pce-circuit-style-pcep-extensions-13: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions= /
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pce-circuit-sty= le-pcep-extensions/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Hi Samuel, Praveen, Andy, Luay, and Shuping,

Thank you for the effort put into this specification. The document is
well-written, especially operational considerations are well-articulated. That’s exemplar. Congrats for such a high quality document.

Thanks to Luis Contreras for the detailed OPSDIR review. I appreciate that = the
authors engaged and implemented the outcome of the discussion with Luis. Mu= ch
appreciated.

 

<S> Thanks a = lot, Med and thanks to those who contributed to the draft in any way (discu= ssions, reviews, proposed texts,...).

Please find below one easy-to-fix point for DISCUSSion:

# Circuit Style

CURRENT:
   This document uses the following term described in
   [I-D.ietf-spring-cs-sr-policy]:

   *  Circuit Style (CS) SR Policy

##  That notion is important to digest as these extensions are defined= for that
case.

## Unless you want to add this as normative, and as this is only one term, = you
may mirror that definition here to avoid normative dependency.

## BTW, note that this term is not used as such Circuit Style SR Policy

<S> Even if mirroring that definition is not ideal, but I think that = it is stable enough and we can possibly still reference spring document lik= e this:

 

This document defines the following terms:

  • Circuit Style (CS) SR= Policy: An SR Policy designed to satisfy requirements for connection-orien= ted transport services. CS SR Policies are characterized by path persistenc= y (where the path should remain stable unless explicitly changed or becomes invalid) and may require strict hop-b= y-hop path construction. Further details on CS SR Policies are described in= <xref target=3D"I-D.ietf-spring-cs-sr-policy"/>.
  • Path Modification: Re= fers to the PCE instructing the PCC, via a PCUpd message, to use a path who= se set of traversed network hops differs from the current path. A PCUpd mes= sage that changes only the attributes or re-encodes the same hop sequence (e.g., alternative SID representation)= is not considered a path modification.

 

Would t= hat work for you?

[Med] Yes, it does. I see that I-D.ie= tf-spring-cs-sr-policy is scheduled for this telechat as well.

&nbs= p;
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

# Flags

##

CURRENT:
   This document defines the following new flags in that
   TLV:

Maybe better to point to
https://www.iana.org/assignments/pcep/pcep.xhtml#stateful-pce-ca= pability-tlv-flag-field
where the up to date set of flags are maintained. This is better than the sole
RFC8231 pointer.

<S> That IANA registry is referenced in IANA section by registry name= already (instead of using direct link, which does not seem to be common pr= actice in other existing RFCs). What about just adding reference to section= 8.1 and indicate that has more details about IANA registry with existing values?

[Med] The reflex I had when reading t= hat part is whether we are tracking the flags and that guards are there to = avoid flag conflicts, etc. I have to look in the IANA registry for that check. I would save other readers like me by provid= ing the IANA registry near that text.

 

That would maintain= consistency and still at least partially simplify lookup for those values = without introducing any risk - e.g. if liveness of those URLs is not guaran= teed. 

##

CURRENT:
   This document specifies the new Strict-Path flag in the LSP-EX= TENDED-
   FLAG TLV.

Maybe point to
https://www.iana.org/assignments/pcep/pcep.xhtml#lsp-extended= -flag-tlv-flags as
well.

<S> Same as above.

[Med] Idem as well.



# Section 3.3

I would make this change:

OLD: When F is set to 1, the P flag value is ignored.

NEW: When F is set to 1, the P flag= value MUST be ignored.

<S> Ack, I'll change it.

[Med] ACK



# Avoid Geocoordinate interfaces

OLD:
    or northbound Application Programming Interface
   (API) on the PCE).

NEW:
   or a dedicated Application Programming Interface
   (API) on the PCE).

<S> It seems to be standard term used in other RFCs, e.g. <= /o:p>

But I can still change it (no harm).

[Med] = Putting aside that 7426 is not an IETF doc, the reason why I’m in fav= or for geocoordinate interfaces is that there are relative, confusing, break when recursing is in place, etc. Anyway, thanks for accom= modating and making the change.

# Clarity of flag checks

OLD:
  P flag set (P=3D1):

NEW:
  P flag set (P=3D1) and F=3D0:

<S> Even if I agree with you that combination is the only one valid, = but that paragraph is really describing P=3D1 with both cases - F=3D0 and F= =3D1. Originally we tracked all combinati= ons of flags and we explicitly tried to define each flag separately now to = simplify extensibility in the future.

[Med] = The reason why I made this comments is that we do say under the description= “When F is set to 1, the P flag value is ignored”. So for me, P=3D1, F=3D1 is still a valid (as this does not trigger any err= or message), but that P is simply ignored.

BTW, i= ntuitively, I would put F before P in Figure 1, but I didn’t made tha= t suggestion as I don’t want to alter any implementation out there.


# Section 5

I know the context of that naming in PCE, but the considerations are beyond=
management. Also, in order to be co= nsistent with latest discussion in OPS, I
suggest the following change:

OLD: 8.  Manageability Considerations

NEW: 8.  Operational Considerations

<S> I'm not sure if that would not create even more confusion, especi= ally since this draft is really not introducing any new considerations and = just referring to existing "Manageability = Considerations" sections in existing RFCs. But I was not following discussion which you mentioned, can you please poi= nt me that "latest discussion in OPS"?

[Med] = This is related to RFC5706bis mentioned in Luis review. I don’t see a= ny issue out there. Please see the change proposed by Rakesh to address this similar point at https://mailarchive.ietf.org/arch/msg/pce/4Sy0SrTXoeD4UCTf9946IsmRhlE/.= Thanks.


# nits

## paradigm

Source routing was there before SR. Can we please consider this change through
the doc:

OLD: source routing paradigm

NEW: source routing

## One term

OLD: This document uses the following terms defined in [RFC9256]:

NEW: This document uses the following term defined in [RFC9256]:

## Section 3

OLD:
   *  Indicate the requirement for strict hop-by-hop paths,<= br>
   *  Signal path persistency by disabling path modification= for
      specific paths,

   *  Identify and control behavior specific to CS SR polici= es.

NEW:
   *  Indicate the requirement for strict hop-by-hop paths,<= br>
   *  Signal path persistency by disabling path modification= for
      specific paths, and

   *  Identify and control behavior specific to CS SR polici= es.

## draft

OLD: Circuit-Style Policy draft [I-D.ietf-spring-cs-sr-policy]

NEW: Circuit-Style Policy [I-D.ietf-spring-cs-sr-policy]

<S> Ack, updated all of them.

[Med] = Thank you Samuel.


Cheers,
Med


____________________________________________________________=
________________________________________________
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_PAUP264MB675625B1FE8CFD92267FBBBB8875APAUP264MB6756FRAP_--