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 0B7E4103624E4; Thu, 18 Jun 2026 06:13:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1781788438; bh=VpZ39OOzw/J6qwjC1Erf6GFyRG8mEWKiqaj/hAqWhQg=; h=From:To:CC:Subject:Date:References:In-Reply-To; b=KXvJ7cbu1IaHnEguoZ8W3NuUcQNRdPPAWvvraC4dL7MO/R9Hq7Xj8lJTjrKfm74xd dg+cPYvVrVyC6jrQOXIBfRXbTuIjaQz93y8SMieR3Z4Ifn2nzyFTHjIZ48vls1w7+W LDhKd9hKHMiNyiDxzmlkniDoa0BRlrJ3tAWsWQvg= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=nokia.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 cfYVSrmqS_rz; Thu, 18 Jun 2026 06:13:56 -0700 (PDT) Received: from OSPPR02CU001.outbound.protection.outlook.com (mail-norwayeastazon11013057.outbound.protection.outlook.com [40.107.159.57]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 8177310362413; Thu, 18 Jun 2026 06:13:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=VIxSzpJ3SCkZ/kPHD4MH5sD5608JSULqOoZz6lQidmH0vVaknARpUngkH5ueMfQC10kitMl+3N3RgRDYRyeb6N+9YXMwY9YdD+BjMcSrRMuh5+BDSAhRpXApFeZ4LqlypJKzM/GSC+zX1kRUqH645jOMaAuDF8p0Ut53+s0HHbgYwmS5zAnUX82oqgHsuJv72fru/VpokzU3jNkXO492k6kPI7lOMcKUOoUW7Rybczfv3/rxR/7nEx9UC0+zwR9D5QXnrSfHg//ThaNCGPXj1QwoSKelIn+wQi2vHXpEIHPvHIRk5FMSSjEcY2rERJvZJIcooipTWuna86F1RW/9Hw== 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=I34wMpu96rK/dSWpRc/XOAaj00vEIijLd+aW1w8IXiw=; b=tQZ2z8uaDVIY/5Msz2bfr9RwyCxxNzNa49lLi56DNnSKyCutyC7dOp3xkrvfYIA+UdumB0xn2mW6kQP/Lve4iWoTzHYq6IzXczJTixjZJS5m3qLmB7Zriqb7YO4UVov/jcHzRSvjooGOrrKaq7xoUR36Tt8zpcLoAqUwqJPPJA/Tm0fHTmiYF11JOPp38s4yrNVlxUjOezepi3rGI1BXJ89zLRfChoJ/XJhXpZnPwMRH4D6zjnSaMnN/4BJhTNjQaoDEOSQwvirD1XUAJNdiA4ohurbZtMSpYTpfAMLwQCjqSNET0rk/ZaXIOCrVkKG2W1Y09Ux9yRuj6uayjC4bXg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=I34wMpu96rK/dSWpRc/XOAaj00vEIijLd+aW1w8IXiw=; b=mgyAcoe94LtoSUMwBUlfUodX2kdpgAaVS4UZqtiPNU+y7mFDFw3iq/Ecg+b029CMR3qD5O/RdOt+2Fkpdlrr5hf9nIdMQOE03tS1U1GdXE/F1YfuW1O1PnrccqTMyZNA5svXnJzvYG+Z9V3oTbrTgmVOOH+0a7lubMH/UynZOj2KTNTanzGzL/NCa7PVS9VL8MpqrxBk8f2jhAU4lKx+zzD0NZ4UfSjj2Hv71SViHMTZPJJ957dWKsVzsrB3W4mPbyatsWiTzfht5c/eGrximUlfUw4ptHrw/3uLvMGwpM3xBTKAJtOfQT73K3DLEfTqaACl90lEKhXwPG3GAylKqQ== Received: from AS1PR07MB8589.eurprd07.prod.outlook.com (2603:10a6:20b:470::16) by AS2PR07MB9028.eurprd07.prod.outlook.com (2603:10a6:20b:558::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.139.11; Thu, 18 Jun 2026 13:13:42 +0000 Received: from AS1PR07MB8589.eurprd07.prod.outlook.com ([fe80::97cf:fb0c:32ff:86c6]) by AS1PR07MB8589.eurprd07.prod.outlook.com ([fe80::97cf:fb0c:32ff:86c6%6]) with mapi id 15.21.0139.009; Thu, 18 Jun 2026 13:13:42 +0000 From: "Gunter van de Velde (Nokia)" To: "Samuel Sidor (ssidor)" , The IESG Thread-Topic: Gunter Van de Velde's Discuss on draft-ietf-pce-multipath-27: (with DISCUSS and COMMENT) Thread-Index: AQHc/xEbkvMFD66KAEGO5ZnRA0khdrZENk/dgAALCQCAAAiKAQ== Date: Thu, 18 Jun 2026 13:13:42 +0000 Message-ID: References: <178162172471.510189.863108485873657885@dt-datatracker-f9b87776f-xzl65> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nokia.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: AS1PR07MB8589:EE_|AS2PR07MB9028:EE_ x-ms-office365-filtering-correlation-id: 539ef104-dc50-4bd5-6773-08decd3b6b57 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|23010399003|366016|376014|1800799024|11063799006|56012099006|6133799003|18002099003|22082099003|4143699003|8096899003|38070700021|13003099007; x-microsoft-antispam-message-info: bLpdlLGF/maNUAIvpZmBqcYMlXWEuGboQePJzqfTzZIi0ZFisUad9XCNo8aihvOAsszwXyHUkoh42vbpqIsd4b3XBxLiOf7O81igxtHvnJXaAkLP10edY/xmK/a7XH7wRkgsaAuD9WVXH13T0kM+XNY/iubhCdfixTJWQKSAJIUhYXQYiFMRmwkZHRDt2TKsm6s7mZkl3bf/9OtRpSsiI3T8umE6xdBv/+vZbivhUnXfMLxaUYEUUk7EtAMkDiuaiin08XFRuEdYjgqX2O9t12OupqctQLwl0WY0ErKdCXEzi3w/2S45xUR20rXg9adRwDW9ikiL4APXylvFzZ3rtu0EZbEm7hmVfEKM/xk3NAVt4/+wej5wAdaChI/lbn1AZxNM/wbXwbmvfM4Oqwvm/CVpApOUEn5EinDOLpc7jXf8kN063Hu8dZleKV9zNprzW+lDOgiuJ95KnBuLnh149ntGzi07eOm1/i3eY0rskugB2x2TTBhhd0Wcam3kRUcjtj58fbAymMbTTXKa+sOVvz5EF0Fa66RobqWiEtHW+J1KnscG30OxyiW50ZYPYaKw6vGsBs1oTwnEje5NI9TW6r9BGi+lJXoCc7PYukH+PD3g5xFJTXdmNqLP/weu0w44cI4l8ILbqzIpST0/O9Q4IXeVp9FDmHuDtiZm9emh/vPLSvt5DLW1Pj1NTFa46mIlBoF82KNzEeJFvUgi5AlabQ== x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS1PR07MB8589.eurprd07.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(366016)(376014)(1800799024)(11063799006)(56012099006)(6133799003)(18002099003)(22082099003)(4143699003)(8096899003)(38070700021)(13003099007);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?35eh18hmoBZP0jyjkg+HHmuwEnZXFYktaQqphPBuYj2djhH4zyPr8uY0?= =?Windows-1252?Q?2Cco7ZWw7PcGhmG/i5GiZjzsDNuyHbKQlKIPAuPCE8a/r+HYK2WMgHLt?= =?Windows-1252?Q?Vurgub8ir2B5/DqXa9q9iYW57dJP0olN0pnYQYUWVJTuJB3HZd0kX6lb?= =?Windows-1252?Q?Vup3PmmlOWtDpAjo3j5da6K+W2huoSjPwqHfT/mNYxuDG3MrvVFVRKax?= =?Windows-1252?Q?k96rytgo1a56aSUZCA/LX5n3wVjfoLM6tCQ4XyiS+BAEorsgLTa+eHjy?= =?Windows-1252?Q?pUb5sIulnYAIXqb2b17abib1ZErdEX06QzKtTSRShfZrcuuXbmq4H9dq?= =?Windows-1252?Q?copot9YiPsWEVYWlQo+VMr1upkCBfZV2c29sQr4TczT5ozLMFOLoU9vZ?= =?Windows-1252?Q?LeNXOvzBbi+lOlnWMh2hhsq0aM5Klity0AKUIzennSDNmScAjLMliKpn?= =?Windows-1252?Q?EPbk3Z5fGcYEYZsEoENG4/YVcaKdG+JXK/LHm8jdBA+YNhrZjXCO6K5c?= =?Windows-1252?Q?DRnOcAP0jIln6+ZwPxAanoWwfSPY0gq4qy5fVNCBwh1Cv25EvfgC6J9y?= =?Windows-1252?Q?62TDIVguA/t76moJSP36uVwWmNrRKco7r8Z/Yn+oVgnrX3Ng1ykOBW4f?= =?Windows-1252?Q?MojPLH4IsFkJKQTUCh/4cC8hUUFXB2N7oHBjuZzGMm0JaZ90vkE/TBwK?= =?Windows-1252?Q?n9BRcSLzT8Ckd3aSgDH5Z1iy5j01G/L6oKED2c6PaumXcphI6SYGIxVM?= =?Windows-1252?Q?CrOzFkEpYK5xWlfr6oCNWrp/guRGuQU+tapVk4TsuKfusqdPynWoCI03?= =?Windows-1252?Q?y89Mv2+9BwkE/yzyK4sRucj4c3phY2O/uHfy8ZAXUiEW0WP2p6Veu7Z7?= =?Windows-1252?Q?zpvLlYvArTT7ZTrS1PuP3JbJ2Q1T604Hu/6NX3ucGZ8f44f4C4i3e3z9?= =?Windows-1252?Q?+3iU1gpEoz+rUXVqnGivgDerI/srUWpg+xatoIBWWDcoushMSPfIWZ/g?= =?Windows-1252?Q?LiDbu1J27wrWZjlAJFBWSKWXc2s1uYONfh9EKnkuX7hd/Q9lm1REhioz?= =?Windows-1252?Q?QR1VC/2VUJeZjmbJrJFaPrDDXzjgyEKsTi6jhOPIkEy9Q2ZKSR2fV860?= =?Windows-1252?Q?5vdS4UHzk7WDBMBkt0vCBWqmGN/YLn78hx0XmyHfDXPnh+aSUfECkuEt?= =?Windows-1252?Q?mNjmjqAnUYCAeZD6H2K2JSDJouUTUednK5O2yp3zg4brdGY8Q7ctlo+x?= =?Windows-1252?Q?AbnlZ+zjIs8CuzDwFHaDD/OAU7qe3u7N+ATljRN9537GqLY4ckSKbCRi?= =?Windows-1252?Q?tKCemC/BNqqYEW6lsb0KIa/C3uEwlTfjo/wgGR6061w6YQztsPFBtXX6?= =?Windows-1252?Q?5HTGOQgKeL+Bk+XKGpcK63mUiBizpQca30TcbzK20UjshnOCg5owffiU?= =?Windows-1252?Q?Dqr21tPBCXHwpAukjllIk7yR9WQRKos5MbszHVDGO2huvQxiSoKtkvlr?= =?Windows-1252?Q?Y2DFQpUFPHxiYPFXNH48/xRsP+Yo35satPg0AK54ou8YWcShAoVDsE7P?= =?Windows-1252?Q?+//kBbPiPp+MAxNiSeJWAyJ2LFhoRstXBJO3e0p6Olu4DjqcjaGX8uQ8?= =?Windows-1252?Q?y8yb1ZDanFhZlW6whs6Tk3bn+rzqQYneAp3o1JESEU0k6RrgszWLt1Ck?= =?Windows-1252?Q?ub2JsDA1o5fKeIieal6Gps/hM6qi60O8hZzK5TBmXXhUvMX19yRIRMKL?= =?Windows-1252?Q?//aaTgmFH8F6pgdvgmzigr41mkoZ+DSzZS5/jDXo9zSWpdusGNqv9mfq?= =?Windows-1252?Q?PMQPWY2cdqJ1kPEnnFQJhkh3DjFiteuK23Vqbh/cvbQBytyO4ATFgq8Z?= =?Windows-1252?Q?d79wCJn0QjbU11C3gDSooXuSCqbo5UEGZbo=3D?= Content-Type: multipart/alternative; boundary="_000_AS1PR07MB8589E6055DC97A974E549AA3E0E32AS1PR07MB8589eurp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AS1PR07MB8589.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 539ef104-dc50-4bd5-6773-08decd3b6b57 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jun 2026 13:13:42.0503 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: kvPeGEIxRbdDKPx3CJK7jePm0Lfhc476qvQ6pMUmbsaJECsZgWcmeFkC7nlAYN/BkA59XjW3FKo2lOrNHW3yq0NNEDLG7I5iWZ5ERFC4RfE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR07MB9028 Message-ID-Hash: E36ITEHKIVBHAU2KXFTCIO4Z6FMMMAA6 X-Message-ID-Hash: E36ITEHKIVBHAU2KXFTCIO4Z6FMMMAA6 X-MailFrom: gunter.van_de_velde@nokia.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-multipath@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_Gunter_Van_de_Velde=27s_Discuss_on_draft-ietf-pce-?= =?utf-8?q?multipath-27=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_AS1PR07MB8589E6055DC97A974E549AA3E0E32AS1PR07MB8589eurp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I think we converged. (changed my ballot NoObjection and is no longer block= ing) See GV3> ________________________________ From: Samuel Sidor (ssidor) Sent: Thursday, June 18, 2026 2:41 PM To: Gunter van de Velde (Nokia) ; The IESG <= iesg@ietf.org> Cc: adrian@olddog.co.uk ; draft-ietf-pce-multipath@iet= f.org ; pce-chairs@ietf.org ; pce@ietf.org Subject: Re: Gunter Van de Velde's Discuss on draft-ietf-pce-multipath-27: = (with DISCUSS and COMMENT) CAUTION: This is an external email. Please be very careful when clicking li= nks or opening attachments. See the URL nok.it/ext for additional informati= on. Thanks Gunter, Please see inline Regards, Samuel From: Gunter van de Velde (Nokia) Date: Thursday, 18 June 2026 at 14:07 To: Samuel Sidor (ssidor) ; The IESG Cc: adrian@olddog.co.uk ; draft-ietf-pce-multipath@iet= f.org ; pce-chairs@ietf.org ; pce@ietf.org Subject: Re: Gunter Van de Velde's Discuss on draft-ietf-pce-multipath-27: = (with DISCUSS and COMMENT) Hi Samuel, Many thanks for sharing these thoughts. Answering to your responses on the DISCUSS's. See GV2> ________________________________ From: Samuel Sidor (ssidor) Sent: Thursday, June 18, 2026 12:56 PM To: Gunter van de Velde (Nokia) ; The IESG <= iesg@ietf.org> Cc: adrian@olddog.co.uk ; draft-ietf-pce-multipath@iet= f.org ; pce-chairs@ietf.org ; pce@ietf.org Subject: Re: Gunter Van de Velde's Discuss on draft-ietf-pce-multipath-27: = (with DISCUSS and COMMENT) CAUTION: This is an external email. Please be very careful when clicking li= nks or opening attachments. See the URL nok.it/ext for additional informati= on. Hi Gunter, Thanks a lot for your review and comments. I=92ll go over those but respond= ing for now at least to DISCUSS part - please see inline . Also note that there will be version v28 submitted today, which is handling= comments from other mail threads, but not yet rest of your comments (even = if some of them may be handled if raised already in other reviews. Regards, Samuel From: Gunter Van de Velde via Datatracker Date: Tuesday, 16 June 2026 at 16:58 To: The IESG Cc: adrian@olddog.co.uk ; draft-ietf-pce-multipath@iet= f.org ; pce-chairs@ietf.org ; pce@ietf.org Subject: Gunter Van de Velde's Discuss on draft-ietf-pce-multipath-27: (wit= h DISCUSS and COMMENT) Gunter Van de Velde has entered the following ballot position for draft-ietf-pce-multipath-27: 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-multipath/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- # Gunter Van de Velde, RTG AD, comments for draft-ietf-pce-multipath-27 # The line numbers used are rendered from IETF idnits tool: https://author-tools.ietf.org/api/idnits?url=3Dhttps://www.ietf.org/archive= /id/draft-ietf-pce-multipath-27.txt # Many thanks for this write-up. I found it well written and was an interes= ting read. # Many thanks to Cheng Li for the RTGDIR review and Adrian Farrel for the Shepherd write-up # in my review there are two items that i wanted to discuss more about. The remainder are a set of comments i made when delving through the document. # DISCUSS # =3D=3D=3D=3D=3D=3D=3D # [DISCUSS#1] The document mentions the word Link, but is not providing det= ails if this is referencing a L3 or L2 path, as segment routing could have Adj S= IDs associated with either one of these, or a single port may have multiple L2 channels to a single remote system. Does then Link apply to the L3 port or = the L2 channels? The document is saying that path in forward and reverse direction is su= pposed to use same link from PCE topology. Whether it is L2 or L3 is not im= portant (depends on topology view on PCE), it is out of scope of this draft= same way like it was out of scope of RFC8800, which defined link diversity= path-computation constraint for example. GV2> This answer works for me it this is more explicitly clarified within t= he document to avoid others from reading to have similar confusion. I trust= your experience to weave this aspect in the document at the most convenien= t location. Agreed. Is following text good enough? Note that I=92m explicitly tryi= ng to do not go into details about L2/L3 and just specifying that it depend= s on topology view and it must be consistent in both (forward and reverse) = directions. The terms "link" and "node" used by the N-flag and L-flag refer to the links and nodes as represented in the topology that the PCE uses for path computation. The exact nature of a link is determined by the PCE's topology view and is out of scope of this document. The same notion of "link" and "node" MUST be used consistently for both the forward and the opposite-direction path when evaluating co-routing; a path and its opposite-direction path are represented in the same topology view. GV3> works for me. # [DISCUSS#2] The QoS in Per-FLow Candidate Path does not seem to consider = SRv6 QoS and only discusses sr-mpls traffic class. Is that intentional? The terminology section explains that LSP used in this document is equally vali= d for SRv6 paths It is intentional. This document is mostly trying to define PCEP extens= ions required for SR policy architecture (RFC9256). The FC field mirrors th= e 3-bit MPLS TC from RFC 9256 Section 8.6. TLV is prepared for future exten= sions using T flag with 0 value. Those can be added in the future in separa= te documents. GV2> Makes sense. Could future extension potential be hinted within the doc= ument? That=92s exactly what we are intentionally trying to avoid (trying not= to speculate on how SRv6 field will look like while was not concluded). Or= are you just proposing to specify that specifically SRv6 QoS is out of sco= pe as well? In such case, I can add something like: Forwarding-class classification for non-MPLS dataplanes (e.g., SRv6) is out= side the scope of this document and may be addressed by future extensions u= sing T=3D0. Would that work for you? GV3> That works for me. Thank you. GV2> I'll clear my DISCUSS on this document accordingly. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # COMMENTS # =3D=3D=3D=3D=3D=3D=3D=3D 125 signaling of multipath information via PCEP. Although these 126 extensions are motivated by the SR Policy use case, they are als= o 127 applicable to other technologies. For SR Policy, support for GV> Are there examples of other technologies that could be mentioned here f= or clarity? 265 0 1 2 3 266 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0= 1 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+ 268 | Flags |R| O= | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+ ... 277 Flags (32 bits): GV> The diagram seems off with the length of Flags described later. I understand that the R and '0' are part of the 32bit Flags field, it seems t= hat it could be misunderstood. Is there a way to make within the diagram 32 bit= and then have a 2nd diagram to visualize the flag field? it would be less confu= sing to read. It would in addition allow to identify the exact bit used (R =3D b= it 28) and bits 29/30/31 are set to zero 300 Optional TLVs: Variable length field that can contain one or mor= e 301 TLVs that carry additional per-path information. The specific T= LVs 302 that can be included are defined in subsequent sections of this 303 document. GV> Would it be correct to state that optional TLVs could contain zero or m= ore TLVs? It are optional TLVs and as such there may be no TLV that is advertis= ed. This would make the description inaccurate 349 A new MULTIPATH-OPPDIR-PATH TLV is optional in the PATH-ATTRIB 350 object. Multiple instances of the TLV are allowed in the same P= ATH- GV> The field for TLVs in PATH-ATTRIB object is called 'Optional TLVs', doe= s that not automatically imply it is optional? 380 Flags (16 bits): GV> same observation as earlier. In the diagram the Flags field is 14 bits while the description talks about 16 bits GV> It is unclear to me if the N and L flag are only indicative and are not prescribing a mandatory behavior? If for example i set the L bit but the Opposite Direction Path ID is not going over the same links, what happens i= n that situation? GV> Are there any considerations when the normal opposite path would follow= the setting of N and L flags, but the path is re-routed due to tactical local policy or LFA somewhere within the network? 389 * L (Link co-routed): If set, indicates this path is link co-ro= uted 390 with its opposite direction path, specified in this TLV. Two 391 opposite direction paths are link co-routed if they traverse = the 392 same links (but in opposite directions). Link co-routing imp= lies 393 node co-routing; therefore, it is not necessary to set the N = flag 394 when the L flag is set. GV> [DISCUSS#1] The concept of 'Link' feels slightly underspecified. What d= oes Link exactly mean in the context of this document. Is it a fiber, a channel= of a fiber, sub-interface, port, etc... For example, what if there is one fibe= r with three L2 channels to the same remote device. Does this allow L2 interf= aces within a single L3 interface 424 identified by its constituent Colors. To achieve W-ECMP, the 425 MULTIPATH-WEIGHT TLV (Section 3.3) is included alongside the COL= OR 426 TLV in each PATH-ATTRIB object. If multiple COLOR TLVs are cont= ained 427 in the PATH-ATTRIB object, the first one is processed and the ot= hers 428 MUST be ignored. GV> When reading the above, i was slightly confused. does this mean that on= ly a single color TLV is allowed, or multiple color TLVs each pointing to a sing= le color? Can this be clarified? (maybe i was overthinking this section) 467 T (1 bit): MPLS TC type. When set, indicates that the FC value = is 468 derived from the MPLS Traffic Class (TC) bits as described in 469 Section 8.6 of [RFC9256]. When not set, the interpretation of t= he FC 470 value is reserved for future use. GV> [DISCUSS#2] in terminology section 2 the concept of SRv6 is introduced = for LSP and mentioned that and candidate path may be an SRv6 path. In that case= t here is no MPLS TC type. Should SRv6 QoS not be considered with a flag? 472 FC (3 bits): Forwarding class value. When the T flag is set, th= is 473 carries the MPLS TC-based forwarding class value as defined in 474 Section 8.6 of [RFC9256]. This value is given by the QoS classi= fier 475 to traffic entering the given Candidate Path. Different classes= of 476 traffic that enter the given Candidate Path can be differentiall= y 477 steered into different Colors. The FC field allows up to 8 diff= erent 478 forwarding classes (values 0-7). The semantics of specific FC v= alues 479 are significant at the headend node (PCC) that implements the SR 480 Policy and are determined by that node's local QoS policy or 481 configuration. Coordination of FC value meanings between PCEP p= eers 482 (e.g., through out-of-band configuration management or operation= al 483 procedures) is outside the scope of this document. GV> IPv6 has 8 bits traffic class (6 bits DS Field and 2 bits ECN). Is this relevant for the story here? 521 Flags (16 bits): GV> Here is documented which 'optional TLVs' (W-flag, O-flag, etc) are supported by a PCC or PCE. Having only 16 potential functionalities support= ed seems rather limited, especially with 4 of them already specified in this document. Would signaling the supported functionalities using sub-TLVs not = be the more future proof and scalable architecture? 694 4. The N-flag and L-flag in the MULTIPATH-OPPDIR-PATH TLV MAY b= e set 695 to indicate node co-routing or link co-routing respectively. 696 These flags inform the receiver about the relationship betwe= en 697 the forward and reverse paths. GV> Is this only informational signaling? it does not mandate that the bit = is actually true or if for example, it makes the PCC believe it is for example= a link congruent opposite path, but in reality it is not. Many thanks for this document, Kind Regards, Gunter Van de Velde Routing AD --_000_AS1PR07MB8589E6055DC97A974E549AA3E0E32AS1PR07MB8589eurp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
I think we converged. (changed my ballot NoObjection and is no longer block= ing) See GV3>


From: Samuel Sidor (ssidor) <ssidor@cisco.com>
Sent: Thursday, June 18, 2026 2:41 PM
To: Gunter van de Velde (Nokia) <gunter.van_de_velde@nokia.c= om>; The IESG <iesg@ietf.org>
Cc: adrian@olddog.co.uk <adrian@olddog.co.uk>; draft-ietf= -pce-multipath@ietf.org <draft-ietf-pce-multipath@ietf.org>; pce-chai= rs@ietf.org <pce-chairs@ietf.org>; pce@ietf.org <pce@ietf.org><= br> Subject: Re: Gunter Van de Velde's Discuss on draft-ietf-pce-mu= ltipath-27: (with DISCUSS and COMMENT)

 
CAUTION:&nbs= p;This is an external email. Please be very careful when clicking links or = opening attachments. See the URL nok.it/ext for additional information.

 

Thanks Gunter,

Please see inline <S2>

Regards,
Samuel

From: Gunter van de Velde (Nokia) <gunter.van_de_velde@nokia.com&= gt;
Date: Thursday, 18 June 2026 at 14:07
To: Samuel Sidor (ssidor) <ssidor@cisco.com>; The IESG <ies= g@ietf.org>
Cc: adrian@olddog.co.uk <adrian@olddog.co.uk>; draft-ietf-pce-= multipath@ietf.org <draft-ietf-pce-multipath@ietf.org>; pce-chairs@ie= tf.org <pce-chairs@ietf.org>; pce@ietf.org <pce@ietf.org>
Subject: Re: Gunter Van de Velde's Discuss on draft-ietf-pce-multipa= th-27: (with DISCUSS and COMMENT)

Hi Samuel,

Many thanks for sharing these thoughts.

Answering to your responses on the DISCUSS's. See GV2>


From: Samuel Sidor (ssidor) <ssidor@cisco.com>
Sent: Thursday, June 18, 2026 12:56 PM
To: Gunter van de Velde (Nokia) <gunter.van_de_velde@nokia.c= om>; The IESG <iesg@ietf.org>
Cc: adrian@olddog.co.uk <adrian@olddog.co.uk>; draft-ietf= -pce-multipath@ietf.org <draft-ietf-pce-multipath@ietf.org>; pce-chai= rs@ietf.org <pce-chairs@ietf.org>; pce@ietf.org <pce@ietf.org><= br> Subject: Re: Gunter Van de Velde's Discuss on draft-ietf-pce-mu= ltipath-27: (with DISCUSS and COMMENT)

 
CAUTION:&nbs= p;This is an external email. Please be very careful when clicking links or = opening attachments. See the URL nok.it/ext for additional information.

 

Hi Gunter,

Thanks a lot for your review and comments. I=92ll go over those but respond= ing for now at least to DISCUSS part - please see inline <S>.

Also note that there will be version v28 submitted today, which is handling= comments from other mail threads, but not yet rest of your comments (even = if some of them may be handled if raised already in other reviews.

Regards,
Samuel

From: Gunter Van de Velde via Datatracker <noreply@ietf.org> Date: Tuesday, 16 June 2026 at 16:58
To: The IESG <iesg@ietf.org>
Cc: adrian@olddog.co.uk <adrian@olddog.co.uk>; draft-ietf-pce-= multipath@ietf.org <draft-ietf-pce-multipath@ietf.org>; pce-chairs@ie= tf.org <pce-chairs@ietf.org>; pce@ietf.org <pce@ietf.org>
Subject: Gunter Van de Velde's Discuss on draft-ietf-pce-multipath-2= 7: (with DISCUSS and COMMENT)

Gunter Van de Velde has entered the followi= ng ballot position for
draft-ietf-pce-multipath-27: 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-multipath/



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

# Gunter Van de Velde, RTG AD, comments for draft-ietf-pce-multipath-27

# The line numbers used are rendered from IETF idnits tool:
https://author-tools.= ietf.org/api/idnits?url=3Dhttps://www.ietf.org/archive/id/draft-ietf-pce-mu= ltipath-27.txt

# Many thanks for this write-up. I found it well written and was an interes= ting
read.

# Many thanks to Cheng Li for the RTGDIR review and Adrian Farrel for the Shepherd write-up

# in my review there are two items that i wanted to discuss more about. The=
remainder are a set of comments i made when delving through the document.
# DISCUSS
# =3D=3D=3D=3D=3D=3D=3D

# [DISCUSS#1] The document mentions the word Link, but is not providing det= ails
if this is referencing a L3 or L2 path, as segment routing could have Adj S= IDs
associated with either one of these, or a single port may have multiple L2<= br> channels to a single remote system. Does then Link apply to the L3 port or = the
L2 channels?

<S> The document is saying that path = in forward and reverse direction is supposed to use same link from PCE topo= logy. Whether it is L2 or L3 is not important (depends on topology view on = PCE), it is out of scope of this draft same way like it was out of scope of RFC8800, which defined link diversity path= -computation constraint for example.

GV2> This answer wo= rks for me it this is more explicitly clarified within the document to avoi= d others from reading to have similar confusion. I trust your experience to= weave this aspect in the document at the most convenient location. 

<S2= > Agreed. Is following text good enough? Note that I=92m explicitly tryi= ng to do not go into details about L2/L3 and just specifying that it depend= s on topology view and it must be consistent in both (forward and reverse) directions.

The terms "link" and "node" used by the N-flag and L-fl= ag refer to the
links and nodes as represented in the topology that the PCE uses for path
computation. The exact nature of a link is determined by the PCE's
topology view and is out of scope of this document. The same notion of
"link" and "node" MUST be used consistently for both th= e forward and the
opposite-direction path when evaluating co-routing; a path and its
opposite-direction path are represented in the same topology view.

GV3> works for me.

# [DISCUSS#2] The QoS in Per-FLow Candidate Path does not seem to consider = SRv6
QoS and only discusses sr-mpls traffic class. Is that intentional? The
terminology section explains that LSP used in this document is equally vali= d
for SRv6 paths

<S> It is intentional. This document = is mostly trying to define PCEP extensions required for SR policy arch= itecture (RFC9256). The FC field mirrors the 3-bit MPLS TC from RFC 9256 Se= ction 8.6. TLV is prepared for future extensions using T flag with 0 value. Those can be added in the future in separate do= cuments. 

GV2> Makes sense. Could future extension potential be hinted within the = document?

<S2> That=92s exactly what we are intentionally trying to avoid (tryi= ng not to speculate on how SRv6 field will look like while was not conclude= d). Or are you just proposing to specify that specifically SRv6 QoS is out = of scope as well? In such case, I can add something like:

Forwarding-class classification for non-MPLS dataplanes (e.g., SRv6) is out= side the scope of this document and may be addressed by future extensions u= sing T=3D0.

Would that work for you?

GV3> That works for me. Thank you. 

GV2> I'll clear my DISCUSS on this document accordingly.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

# COMMENTS
# =3D=3D=3D=3D=3D=3D=3D=3D

125        signaling of multipath inform= ation via PCEP.  Although these
126        extensions are motivated by t= he SR Policy use case, they are also
127        applicable to other technolog= ies.  For SR Policy, support for

GV> Are there examples of other technologies that could be mentioned her= e for
clarity?

265           0 &nbs= p;            &= nbsp;    1        &n= bsp;          2  &nb= sp;            =     3
266           0 1 2 3 4 5= 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
267          +-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
268          |  &nbs= p;            &= nbsp;         Flags  &nbs= p;            &= nbsp;         |R|  O  | 269          +-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
277        Flags (32 bits):

GV> The diagram seems off with the length of Flags described later. I understand that the R and '0' are part of the 32bit Flags field, it seems t= hat
it could be misunderstood. Is there a way to make within the diagram 32 bit= and
then have a 2nd diagram to visualize the flag field? it would be less confu= sing
to read. It would in addition allow to identify the exact bit used (R =3D b= it 28)
and bits 29/30/31 are set to zero

300        Optional TLVs: Variable lengt= h field that can contain one or more
301        TLVs that carry additional pe= r-path information.  The specific TLVs
302        that can be included are defi= ned in subsequent sections of this
303        document.

GV> Would it be correct to state that optional TLVs could contain zero o= r more
TLVs? It are optional TLVs and as such there may be no TLV that is advertis= ed.
This would make the description inaccurate

349        A new MULTIPATH-OPPDIR-PATH T= LV is optional in the PATH-ATTRIB
350        object.  Multiple instan= ces of the TLV are allowed in the same PATH-

GV> The field for TLVs in PATH-ATTRIB object is called 'Optional TLVs', = does
that not automatically imply it is optional?

380        Flags (16 bits):

GV> same observation as earlier. In the diagram the Flags field is 14 bi= ts
while the description talks about 16 bits

GV> It is unclear to me if the N and L flag are only indicative and are = not
prescribing a mandatory behavior? If for example i set the L bit but the Opposite Direction Path ID is not going over the same links, what happens i= n
that situation?

GV> Are there any considerations when the normal opposite path would fol= low the
setting of N and L flags, but the path is re-routed due to tactical local policy or LFA somewhere within the network?

389        *  L (Link co-routed): I= f set, indicates this path is link co-routed
390           with its op= posite direction path, specified in this TLV.  Two
391           opposite di= rection paths are link co-routed if they traverse the
392           same links = (but in opposite directions).  Link co-routing implies
393           node co-rou= ting; therefore, it is not necessary to set the N flag
394           when the L = flag is set.

GV> [DISCUSS#1] The concept of 'Link' feels slightly underspecified. Wha= t does
Link exactly mean in the context of this document. Is it a fiber, a channel= of
a fiber, sub-interface, port, etc... For example, what if there is one fibe= r
with three L2 channels to the same remote device. Does this allow L2 interf= aces
within a single L3 interface

424        identified by its constituent= Colors.  To achieve W-ECMP, the
425        MULTIPATH-WEIGHT TLV (Section= 3.3) is included alongside the COLOR
426        TLV in each PATH-ATTRIB objec= t.  If multiple COLOR TLVs are contained
427        in the PATH-ATTRIB object, th= e first one is processed and the others
428        MUST be ignored.

GV> When reading the above, i was slightly confused. does this mean that= only a
single color TLV is allowed, or multiple color TLVs each pointing to a sing= le
color? Can this be clarified? (maybe i was overthinking this section)

467        T (1 bit): MPLS TC type. = ; When set, indicates that the FC value is
468        derived from the MPLS Traffic= Class (TC) bits as described in
469        Section 8.6 of [RFC9256].&nbs= p; When not set, the interpretation of the FC
470        value is reserved for future = use.

GV> [DISCUSS#2] in terminology section 2 the concept of SRv6 is introduc= ed for
LSP and mentioned that and candidate path may be an SRv6 path. In that case= t
here is no MPLS TC type. Should SRv6 QoS not be considered with a flag?

472        FC (3 bits): Forwarding class= value.  When the T flag is set, this
473        carries the MPLS TC-based for= warding class value as defined in
474        Section 8.6 of [RFC9256].&nbs= p; This value is given by the QoS classifier
475        to traffic entering the given= Candidate Path.  Different classes of
476        traffic that enter the given = Candidate Path can be differentially
477        steered into different Colors= .  The FC field allows up to 8 different
478        forwarding classes (values 0-= 7).  The semantics of specific FC values
479        are significant at the headen= d node (PCC) that implements the SR
480        Policy and are determined by = that node's local QoS policy or
481        configuration.  Coordina= tion of FC value meanings between PCEP peers
482        (e.g., through out-of-band co= nfiguration management or operational
483        procedures) is outside the sc= ope of this document.

GV> IPv6 has 8 bits traffic class (6 bits DS Field and 2 bits ECN). Is t= his
relevant for the story here?

521        Flags (16 bits):

GV> Here is documented which 'optional TLVs' (W-flag, O-flag, etc) are supported by a PCC or PCE. Having only 16 potential functionalities support= ed
seems rather limited, especially with 4 of them already specified in this document. Would signaling the supported functionalities using sub-TLVs not = be
the more future proof and scalable architecture?

694        4.  The N-flag and L-fla= g in the MULTIPATH-OPPDIR-PATH TLV MAY be set
695            to in= dicate node co-routing or link co-routing respectively.
696            These= flags inform the receiver about the relationship between
697            the f= orward and reverse paths.

GV> Is this only informational signaling? it does not mandate that the b= it is
actually true or if for example, it makes the PCC believe it is for example= a
link congruent opposite path, but in reality it is not.

Many thanks for this document,

Kind Regards,
Gunter Van de Velde
Routing AD



--_000_AS1PR07MB8589E6055DC97A974E549AA3E0E32AS1PR07MB8589eurp_--