[RTG-DIR]Re: Rtgdir last call review of draft-ietf-mpls-mna-usecases-11

bruno.decraene@orange.com Wed, 11 September 2024 14:27 UTC

Return-Path: <bruno.decraene@orange.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF4DC151524; Wed, 11 Sep 2024 07:27:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 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_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNx39HxEymad; Wed, 11 Sep 2024 07:27:00 -0700 (PDT)
Received: from smtp-out.orange.com (smtp-out.orange.com [80.12.126.238]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F37F2C1D4A9C; Wed, 11 Sep 2024 07:26:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; i=@orange.com; q=dns/txt; s=orange002; t=1726064819; x=1757600819; h=to:cc:subject:date:message-id:references:in-reply-to: mime-version:from; bh=olNpKWquSxed7zngcvQFM4UvbP7nGCnsMDz+kiqB4c0=; b=dnKIXHSxh32jwWKbtRGzxIz3bSJh06RHGkMI7t2o3K1xiecg1QkLUYDB zcP8+kMVJYIsVHeA/EvcOjvByIg6lldR+lbrmze12mgBrs1+2+GpHXw0/ Qy1l5gnAVAPBehLmaco81UD1RNuQXtdTZpR7Vv+gthQqJxG0QV6z0QWGe +XU87px57a3/UxHwsA0CA8+THquh5WVPn4F/BECgHhmV9R2PqUOwxBMq0 lSvbbCmO/NgVJGFX6BgAHTDT2oPBkU5DHjELbhhpReJDuQ+WcsOwKRGe0 SyyywZQvFT7HBaNLBw7U6/ZjukIni+6YgmwHJwSSya6F98BuuEahJU9mA Q==;
Received: from unknown (HELO opfedv1rlp0g.nor.fr.ftgroup) ([x.x.x.x]) by smtp-out.orange.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Sep 2024 16:26:57 +0200
Received: from unknown (HELO opzinddimail7.si.fr.intraorange) ([x.x.x.x]) by opfedv1rlp0g.nor.fr.ftgroup with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Sep 2024 16:26:57 +0200
Received: from opzinddimail7.si.fr.intraorange (unknown [127.0.0.1]) by DDEI (Postfix) with ESMTP id 2351C232A6C; Wed, 11 Sep 2024 16:26:56 +0200 (CEST)
Received: from opzinddimail7.si.fr.intraorange (unknown [127.0.0.1]) by DDEI (Postfix) with ESMTP id 10AD4232A52; Wed, 11 Sep 2024 16:26:56 +0200 (CEST)
Received: from smtp-out365.orange.com (unknown [x.x.x.x]) by opzinddimail7.si.fr.intraorange (Postfix) with ESMTPS; Wed, 11 Sep 2024 16:26:56 +0200 (CEST)
Received: from mail-westeuropeazlp17011024.outbound.protection.outlook.com (HELO AS8PR04CU009.outbound.protection.outlook.com) ([40.93.65.24]) by smtp-out365.orange.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Sep 2024 16:26:56 +0200
Received: from AS2PR02MB8839.eurprd02.prod.outlook.com (2603:10a6:20b:553::7) by VI2PR02MB10973.eurprd02.prod.outlook.com (2603:10a6:800:273::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7918.25; Wed, 11 Sep 2024 14:26:51 +0000
Received: from AS2PR02MB8839.eurprd02.prod.outlook.com ([fe80::3601:1575:5b20:1555]) by AS2PR02MB8839.eurprd02.prod.outlook.com ([fe80::3601:1575:5b20:1555%6]) with mapi id 15.20.7939.022; Wed, 11 Sep 2024 14:26:51 +0000
From: bruno.decraene@orange.com
X-TM-AS-ERS: 10.218.35.126-127.5.254.253
X-TM-AS-SMTP: 1.0 c210cC1vdXQzNjUub3JhbmdlLmNvbQ== YnJ1bm8uZGVjcmFlbmVAb3Jhb mdlLmNvbQ==
X-DDEI-TLS-USAGE: Used
Authentication-Results: smtp-out365.orange.com; dkim=none (message not signed) header.i=none; spf=Fail smtp.mailfrom=bruno.decraene@orange.com; spf=Pass smtp.helo=postmaster@AS8PR04CU009.outbound.protection.outlook.com
Received-SPF: Fail (smtp-in365b.orange.com: domain of bruno.decraene@orange.com does not designate 40.93.65.24 as permitted sender) identity=mailfrom; client-ip=40.93.65.24; receiver=smtp-in365b.orange.com; envelope-from="bruno.decraene@orange.com"; x-sender="bruno.decraene@orange.com"; x-conformance=spf_only; x-record-type="v=spf1"; x-record-text="v=spf1 include:spfa.orange.com include:spfb.orange.com include:spfc.orange.com include:spfd.orange.com include:spfe.orange.com include:spff.orange.com include:spf6a.orange.com include:spffed-ip.orange.com include:spffed-mm.orange.com -all"
Received-SPF: Pass (smtp-in365b.orange.com: domain of postmaster@AS8PR04CU009.outbound.protection.outlook.com designates 40.93.65.24 as permitted sender) identity=helo; client-ip=40.93.65.24; receiver=smtp-in365b.orange.com; envelope-from="bruno.decraene@orange.com"; x-sender="postmaster@AS8PR04CU009.outbound.protection.outlook.com"; x-conformance=spf_only; x-record-type="v=spf1"; x-record-text="v=spf1 ip4:40.92.0.0/15 ip4:40.107.0.0/16 ip4:52.100.0.0/15 ip4:52.102.0.0/16 ip4:52.103.0.0/17 ip4:104.47.0.0/17 ip6:2a01:111:f400::/48 ip6:2a01:111:f403::/49 ip6:2a01:111:f403:8000::/51 ip6:2a01:111:f403:c000::/51 ip6:2a01:111:f403:f000::/52 -all"
IronPort-Data: A9a23:hSYJPahKv/3Ec6/8rZenYSfzX161UBcKZh0ujC45NGQN5FlHY01je htvCmmCOPbZYTT2fN10OY229UwFuJDWyIVkT1Fs/iBmEnkW8JqUDtmndUqhZCn6wu8v7a5EA 2fyTvGacajYm1eF/k/F3oDJ9CU6j+fRLlbFILasEjhrQgN5QzsWhxtmmuoo6qZlmtHR7zml4 bsemOWBfgb9s9JIGjhMsf7b+Uo25K6aVA4w5TTSW9ga5TcyqFFFVPrzFYnpR1PkT49dGPKNR uqr5NlVKUuAon/Bovv8+lrKWhViroz6ZGBiuVIPM0SWuSWukwRpukoN2FjwXm8M49mBt4gZJ NygLvVcQy9xVkHHsLx1vxW1j0iSMIUekIIrL0RTvuTIk3D2fEbB+892VmYQB7Nb98JTJ0Jno KlwxDAlNnhvhsqf++KDcLEwrfl7dJitO54DsHZ9yz2fFewhXZ3IX6TN45lfwSs0gcdNW/3ZY qL1axIzNFKROFsRZxFNVPrSn8/w7pX7WzdCtVSS46Y66HLawQp8+L/3Odzad5qBQsA9ckOw+ zucpzyjU0ly2Nq35GWo+Hvr38r0pz7VZaBDSZqd2ONkqQjGroAUIEZNDwfkyRWjsWaxQd9QK kkV4DEtvIA98UWqSp/2WBjQiGSYsVsQWsB4EuAm5keK0KW8ywqDD2YYCz9MdNJjsdcyXnkv0 FbMgsjkDjV0vabTQHaZ3raZsT30PjIaRUcGbDQYCAAM593LoYwvgFTIVNkLOKutisbdGDzsz XaNtidWulkIpcsC1qH+4l3cnz+xvJ/RQwcn4h2OATr8t1sjOMiiepCi7kXd4bBYNoGFQ1Kdv X8C3c+D8OQJCpLLnyuIKAkQIF23z63ZDQ3TvHNXJYF70BKXxT2uWaR2wxgrcS+FLf04UTPuZ UbSvyZY65lSIGamYMdLj2SZWpxCIU/IRYSNaxzEUueidKSdYyeh2ElTiaO42mnslA0znLojN IqBdt6hBGQeEf04lGPvH71Bl7g22io52GXfA4jhyAiq2qafY3jTTqoZNFyJbaYy66bsTOTpH zR3aJHiJ/Z3CbeWjszrHWg7cA5iwZ8TWM2eliCvXrTfSjeK4Ul4YxMr/ZsvepZ+g4NenfrS8 3e2VydwkQWl2CyWclzXMiEyMNsDuKqTS1pqZUTA2n74ihAejXqHsvlBLvPbgJF7qrM/lq4sH 5Hphe3ZW6sTEmuek9jiUXUNhNc5Lkj07e5/Fy+kayI4ZJluW0TC/cX8FjYDBwFfZhdbQfAW+ uX6viuCGcRrb107UK7+Nqjzp3vv5iJ1sLwpACP1zix7IxiEHH5CcHCq0Zfa4qgkdX3++9dt/ 13OXkhE/LiR+NRdHRugrfnskrpF2tBWRiJyd1Q3J57vXcUG1gJPALOsUdpkuRj0bzPMwv3+T tgNl6C6N+AbllFXtYY6C6xs0a81+9roofld0xhgG3LIKV+sD9uM51GYiNJXuPQlKqBx4GOLt oCnorG2+oll/OviClcXKwdjZeOGvR3RsieH9uw7eS0W+wcrlIe6vZ1uAiSx
IronPort-HdrOrdr: A9a23:2uygYKGIWT4ffMIupLqFY5HXdLJyesId70hD6qkvc3Fom52j/f xGws5x6fatskdoZJkh8erhBEDyewKmyXcV2/hYAV7MZniDhILFFu9fBM7ZskTd8k7Fh6VgPM VbAs9D4bTLZDAX4voSojPIderIq+P3k5xA8N2uqkuFOjsaCZ2IgT0ZNi+rVmlNACVWD5swE5 SRouBdoSC7RHgRZsOnQlEYQunqvbTw5d/bSC9DIyRixBiFjDuu5rK/OQOfxA0iXzRGxqpn2X TZkjb++r6ov5iAu1PhPi7onttrcenau5p+7f+3+4gow/LX+0WVjbFaKvO/VfYO0aOSARgR4Z zxSlwbTr5OAjvqDxyISF3WqkPdOX8VmgDfIVP0uwqeneXpAD09EMZPnoRfb1/Q7Fchpsh11O ZR03uerIc/N2K2oM3R3am8a/hRrDvBnVMy1eoIy3BPW4oXb7Fc6YQZ4UNOCZ8FWCb38pouHu ViBNzVoK8+SyLSU1nJ+m10hNC8VHU6GRmLBkAEp8yOyjBT2HR01VERysATlmoJsJg9V55H7e LZNbkArsA5cuYGKaZmQOsRS8q+DWLABRrKLWKJOFziULoKPnrcwqSHkondJNvaC6Dg4KFC6K gpCmkoy1LaU3ieePGz4A==
X-Talos-CUID: 9a23:akpe5WqqqrBDxP/BN13DjPvmUZt5T03S8VroGVfiLkBTdv6YbXu224oxxg==
X-Talos-MUID: 9a23:MtYYhAppi27qd8RYFlMezxw9Gc1hpP2LM3oQv6gk6pSjEAJtNR7I2Q==
X-IronPort-AV: E=Sophos;i="6.10,220,1719871200"; d="scan'208,217";a="51200290"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=iGYsEEObyru73s/cgr1BPeNrofo6Xz/MNMF3uqFQx09+a3KAz2ZgjNvJhfB4iO4pdHB9a8rbzKngUuHjoOD931geI40YpmheHLRz1FjWQYLsmED3OrZE2jUSIgSXh+l4gxpqpvRMa94WQGHMvHzMERuoWji8KhdtcjMp5KXLtyY3lwyTUKpdh1FrTTR6PSCRqDBPWMGGtmeYLGbvko2j3PigPOuhQ1TTZefEjr+nLxWjfZQCa7f+QpvOEZxX1zF2+7ADNR/qTs9TEG/SfDky7q3gMDHXiU1qOBNXUYs8hw0SF4N+bBlM2EV9ikWJrco+mVmy5zV1aJKTWoDj+6ouXA==
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=322KPgh9Y3kH4D9yexCtZyMf0CCL58uizIxHl701LMw=; b=Rwqas4shfAQ7lSTO5h45pUgzKbR2fnFAkTAGZp07OHJnWpckI+Z8HhhEfQDJqnp/OjDO9Ieaqbo1PveU+kwQc753HVnPMd5JcqciBTT0pUwAE1JcBlYiBDrVw2mmA0T3Y2R8/XgWO1MBYyUQIR5vE/+7M9UxvHLsAZYn2+MFsTIG2i1694qptU5XtXmw368F7O+p2HbalZXuhSwhA+7M9bKuIhXrONvYw3OAkV9+XNfTMJG6xf14K/+g8f24nkB0tHEqrawi9n+A+TBp++iWFzqE7uryELiYcNVwJccxKqtn7D1syLgCOVHm77ZWo4YGra57zuMNbjXfTm1f72rtMw==
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: Greg Mirsky <gregimirsky@gmail.com>
Thread-Topic: Rtgdir last call review of draft-ietf-mpls-mna-usecases-11
Thread-Index: AQHa/+ptwA3tMBKdXEeBR0joSpjb0LJKevFQ
Date: Wed, 11 Sep 2024 14:26:51 +0000
Message-ID: <AS2PR02MB88399AAB010193C86A6C0A74F09B2@AS2PR02MB8839.eurprd02.prod.outlook.com>
References: <172527801349.1030992.2582167041505088105@dt-datatracker-68b7b78cf9-q8rsp> <CA+RyBmVsXpeNaNi3MO75NHWXLCUStw30cp_rP3RxDsEnonAG-Q@mail.gmail.com>
In-Reply-To: <CA+RyBmVsXpeNaNi3MO75NHWXLCUStw30cp_rP3RxDsEnonAG-Q@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Enabled=true;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: AS2PR02MB8839:EE_|VI2PR02MB10973:EE_
x-ms-office365-filtering-correlation-id: d3ae1bdd-f8c8-469f-b529-08dcd26dc742
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|1800799024|38070700018;
x-microsoft-antispam-message-info: RLJC9AwNWbhJRbSM1MHyRUk8JUu1jDL74S7+dbHz+TUx4wml2y5Jdu06WuuCctvNVLD8+PYnZq+SCRg11bkRubS9ls8WrOrCqqJBes+fHuzE5x4AdqEz8wrxXWU79puTEJcp7W8wXzeN5wASRkQaCu6lHVKIIcWNcZdVeJhCmPTJaxNBE3s2S1OOXUedD164gDBwezpF1tEo4itBwrzXGr+XhsnUBkVlSllM/jd+oUTD7pV7qrfbd+fTFU6q+x2pNdXFc09rMrzyo8xJejZzkUW2QFxj168j1iwJ8tThH7LAZ35auT3DJF3WaWTDpL/Y2ZQT9utSYdG8ouJrOBFodwVfVZ3v72Q2HrGlw+JNyUVZvzeSglG/j5CiJUZreqmCk06GaVWur4g9tDdsKVktsbnTvk6czsLjPjg8WobJ0pTwpu9ATQZIZ2cHtgdnbrRkW4Euc2H/OKI5SenUBmEs0KM614SW5ooGfoW09SrVVPTRrVTjzGMyddo0JexCX8v2DV2+ndVadR8uCJ/FFlyuT9GThihF/p3Z+eBly+sMlppEtvp9LvPABP1vbm0jsb/O6YOG6syXsW2v7E+HfumePvsa9kHy5kJ/oVALiUMO7QrcHGvIAemF2V5XGWKQ7q8hgevAY7pdLQKstCZg4BJhkRtcQ8LOyMn9OjDkR7FWVyumpiE4eHojKIXQWDo1W+2JrXbEkD80GENMKb81FTvOuDEctbzqHmNzDU+LRbGtNguVkPnG5rgLSZGLGJD6o7ZVQC40qD33HvnaB+hZo7lrj71sLEDFUlLxXXsuagVicZpFExGsI6lSlwtRMbJkoGJcBGUfTUyh9MN1gesTJCk0YM34kGWzQn2hofReTuyxTlfQ0a09+VtctdTuhVMpuN9K2se1W3jDjZyfvi4pZKjagqxgJafCN6dj2kPnKa9fArB/9DH3kPjYe0oi0G865hxHTKDFzYMN5nnoJxXbxn9FBxyUoOGL8DWMsf7lMWK+UrC8TOtittOBIKbOg+kiKntpXQrlIWbYZquICHmFkYqas26nQjOjNrvjODtjzZgOIKYPBpcuQD+Udp+6oHK1cgJrUQcpimdECB7ul9REpAmYOMAofcuydWxgZT4wdSE6V2Z9wGzCUiABehcsXASdx/1rUwmI0j2Y8SL3RViantPFqjcTIardEBoLBOiJHX9DudztYChGljgFVUKvJeQAXAiK/YJpAxyqF6XIqZ20hIw3vh9UIh/bb/cHDQX8va5Bx/F2Hkhtl/XaHt5v7VKvHje1deudLs3B2p/eayR/sAW1RotO3RJ7WWk4+WLZyB8o+Be5jELx+Wx781R5d4Hvy3jqUbQ94/FYSW1v4kroDx1Sjwr6C4fjNkCuy2/Pm4augXVMO+s0ZbDUkXSti7AHUYU3A7tWi4Nk6JWj5seE23VxXpw1r+MMm2rGs7gNRvM1yfI=
x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR02MB8839.eurprd02.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 3tkHJm07Up3zcvs55ywscBJF8Nau9D5APS79ofgOVAR3NbDHRwCz/zUnFeNDEu2mF+8xrFCE3XN0+o7iTqe/uubOvY617jAVjZzgYzVhiPSP1RFrb9edM3BZ17Rr9F8269kEyGumTnGd4Qu7deSJVTjp/T6P2fSuL0j68pLo4ctPr1IaHEhCHqi9mj3u5FX4gyoirL58jlcY6Y4rcwVBl/3IPO9aFehDhCto8WnRhEJAEMog05K4wODnMQmx7GFlxqb/pxdYC5hopHxscJdvxrWsC5l79WL0+9ZR2sUrUQ+qsUPDmaCjvtSFgUYgBEi7YPg4TlEsbbO3W3+qliOkT18wJGUcoBmUoWCqN+pPciJoGcVNcfSzOqcRiwCW3WCyVzz+ntcwnqUYQcbnPIknPJTx+afVoTUxmoCvZKrXFbTmM9pI8tcM07z38czt7++UhkQxHYHQ0D3dZU9Qos918hW8hYALsZZWo537+ZjU9yKAX739EDwS2mSYm8e1vqsC3Q8L/OqTkHJStHKzVGgjd+2sAoCL4UkHpiWxUzxYX37bK5hutcaGM/cgZQn+ql//jdmc1DlLXCPDdGnSUxf10w6AKtQ8jEML9KRW6amHP9nfxLSMku2RW5rs2u6wMM3Vyiea0526jdPLvjFrEZQWf7+mm4H5fGHXxuH2dK0EMPbHcb7EE3wYbQOGh+3hKMLc0U0WMWiquwVNC1UPYEA7l63eE+g6SCOwQ0gouU3T+Dt4tIlHr47wNuogh9/QXQQG86hbpj06nPKZjs0JuixaGDCT7I6ZI6fIVgbZZcS/cHVq43y3pdapMmOcM1Dycuj5bhZCZoNuTm07ca2bvcm0pDPJWbKYO9Z+hFGOF6gz4FLX5OKCYuyiOwJ0DIza0shZidrIbDMw8YL4+9hd4hn6r/xZxUVXStifI+nfnsO9Ue6k6dYsYXEzNCUE+Yjl1xLVVYvV3sJPr7fPsfLzvMGbzrh1RYdgPPNUA4+QEw2JyDi0qllH1TxKDEz+DZttO/fxUc64M3PRyBY+tjk2bYd3m3t0B299r61+mCJqD/pu06rm0RChhZTwQMOmdiRNP07pydJFYkPn//K/H1bBta17z6mX7AFRX4X/885+ykwVOkVnoTtQzlqNQdfvJol69qCW7Si+VC8w1InfuLwToD7p/Cmg7DAabhnOfG2SIEfk5SO+bbnJZJHQI5+4Y0Cf1bL5iCM5r39lzM1MzjXV+zUSHM0fdSEvImAknonhOsChbu22DMyhzGmlb+JJPLJLb6ZFViCDx9ujvIrm9lIFarGm5oDPQ6mCJP10fEtFZQPLitpkOYMQLJAf2DHmOeEfVZy9zsmKz2S7A883k7qj3B3g8MN1NTg9ayMMRlh6hctlDtBz+nHgqJi6w9w5cP912iSphtkwu3oowEci9yaJjRvk1LBDchAVQR+B0HN5MvBq92G6hvQMBkTDF4RT6eGWTErYSVJy5vwAUzKy4eEBTxGEpX26FRJLcakI2oLp7hdkxo9b2yz/Nhxk/moVaDw0YssUmSd/fZZiKnJwA3XoRS+OIDmO1cTYyErW0ZljDMkRI4MSK2CAu37r7Wg6jcEwZBVX
Content-Type: multipart/alternative; boundary="_000_AS2PR02MB88399AAB010193C86A6C0A74F09B2AS2PR02MB8839eurp_"
MIME-Version: 1.0
X-OriginatorOrg: orange.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AS2PR02MB8839.eurprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d3ae1bdd-f8c8-469f-b529-08dcd26dc742
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Sep 2024 14:26:51.6022 (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: QzWqkDMYo4hLHPPlYeAtfEbpBdgqpKj0conZeu0AWiknbpj4oBVINHB2o9Z+4HwlmQVR4zyVFENbcspK/KdiG1aVrMYIGHUVY8zJ+Qcpcnk=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI2PR02MB10973
X-TM-AS-ERS: 10.218.35.126-127.5.254.253
X-TM-AS-SMTP: 1.0 c210cC1vdXQzNjUub3JhbmdlLmNvbQ== YnJ1bm8uZGVjcmFlbmVAb3Jhb mdlLmNvbQ==
X-TMASE-Version: DDEI-5.1-9.1.1004-28658.000
X-TMASE-Result: 10--48.148900-10.000000
X-TMASE-MatchedRID: OoEa6u7Uk5/uYusHgJkgyqUfpvLQYumSpk75w2mTC9GU62zvc1Dlo1ep MMW3nEo146QqNWws7yvSl1fPYXV7QV/ZJ0h1vLl1S5PrXCkYtHpOaDdl7pggvYO3HyUMPRbHDZ3 7VGDSo5KJjrczdL7hAoIssIhD7WXBn6y0mNkW0aSUO3k9AyCPTaNEPBDikBVIbj6AD6L0PYOjRc Hp5s9iW4rorox+5fogKymcsu9pI+4Vv2zDIg6R4QKepbH0zN4ZWbfDoKaD7A2dYLpdSULGcbGPv J0fdHc75YQxJjDrBBtqAhDVexeCjQvBTB90+he+QR7lWMXPA1sfykVP5opq2ORZ+ls/484hO7Rv f3iB/7FPu95mRw4AQLkewDxr+fqIxkQABNmid9MoJgWvWZKR0BRknLTRTV6qaKYjNvWpvU8k17/ IvnxdZ7uuBIyRAIAC92GQiQFYZS0YBi3BcmOD6a7YaZ2V2aJQRLQWlsj7XhPetmz5H+sKyUOZ/T 6VMD86DAQJ2RqTO2RbKpVDsoU+TFlmFyC1cVYK6KjY+Ctcuzg/gf7afIrQU8y+hfhLvfrDhP/tH BlAnijuFC9g00HQc7oyTDhk04gyTNDKZy5/hvRwA58P7j2tWmiByEcpmkDHyfCmRXt6669SxTaX xnjZ4ui/gxjZZIQ/J8H7844WHI6VF2HD8EHNpxyzHcgfiyrc1nkLa3J3C337aNbzHVUcUU0DzKp CTNk+WS7LLyBpFOOEWG4fxKPlxe6bo2/Lq3c2NdMCT2HE6ChfO2spedWxdWhd0yzXqZEMnxc008 ELQTXqE+CfBImPD7TvRT9Z+42+pzmJJw2f0KF9LQinZ4QefLx5HT4ZzaY/IT3mlTBx7EzjCeE5v 4lH5OoKEDqVJEm+0u+wqOGzSV24UWwltDXjMCBuGJWwgxArFnn7zLfna4I=
X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0
X-TMASE-INERTIA: 0-0;;;;
Message-ID-Hash: MHEEOSNTGN3L7635ZEBLEIS7BOIX6FUY
X-Message-ID-Hash: MHEEOSNTGN3L7635ZEBLEIS7BOIX6FUY
X-MailFrom: bruno.decraene@orange.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-rtg-dir.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "draft-ietf-mpls-mna-usecases.all@ietf.org" <draft-ietf-mpls-mna-usecases.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [RTG-DIR]Re: Rtgdir last call review of draft-ietf-mpls-mna-usecases-11
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/v9NGSJcp5grBbYU95_4fdb-ZLbc>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Owner: <mailto:rtg-dir-owner@ietf.org>
List-Post: <mailto:rtg-dir@ietf.org>
List-Subscribe: <mailto:rtg-dir-join@ietf.org>
List-Unsubscribe: <mailto:rtg-dir-leave@ietf.org>

Hi Greg,

Thank you for your replay and constructive suggestion.
Please see inline [Bruno]

From: Greg Mirsky <gregimirsky@gmail.com>
Sent: Friday, September 6, 2024 1:19 AM
To: DECRAENE Bruno INNOV/NET <bruno.decraene@orange.com>
Cc: rtg-dir@ietf.org; draft-ietf-mpls-mna-usecases.all@ietf.org; last-call@ietf.org; mpls@ietf.org

Hi Bruno,
thank you for your thorough review, constructive comments, and helpful suggestions. Please find my notes below tagged by GIM>>. I attached the new working version of the draft and the diff that highlights all the updates.

Regards,
Greg

On Mon, Sep 2, 2024 at 4:53 AM Bruno Decraene via Datatracker <noreply@ietf.org<mailto:noreply@ietf.org>> wrote:
Reviewer: Bruno Decraene
Review result: Has Issues

Hello

I have been selected to do a routing directorate “early” review of this draft.
https://datatracker.ietf.org/doc/html/draft-ietf-mpls-mna-usecases-11

Document: draft-ietf-mpls-mna-usecases-11
Reviewer: Bruno Decraene
Review Date: 2024-09-02
Intended Status: Informational

Summary:
    I have some minor concerns about this document that I think should be
    resolved before it is submitted to the IESG.

Comments:

The document reads well and is interesting to read. Thank you.
GIM>> Thank you for your kind words, Bruno.

I think that the document and the abstract should better indicate how use cases
have been selected. In particular

- I think that the Abtract should better states how use cases have been
selected (and rejected). Abstract has two sentences about this while one should
be enough. And they differ ("community interest" vs "actively discussed").
GIM>> I think that "community interest" describes the attitude towards MNA work in general, while "actively discussed" is intended to reflect the situation with the use cases.

[Bruno] OK.

Especially since some uses cases have been moved to appendix,
GIM>> Indeed, over the course of the discussion, the feedback received from groups that work with the MPLS data plane indicated that theese groups have not yet reached consensus on the proposed solutions. The authors proposed moving these cases to the appendix rather than removing them altogether for the historical value. It appears that the WG agreed and supported that update.
and some of the
uses cases could be read as "motivating MNA" while some could be read as "could
(possibly) use MNA is MNA existed".
GIM>> I agree that some use cases, e.g., NOFRR, can be realized by using an assigned SPL. Some other use cases also can be supported by assigning a dedicated SPL. As the available number of bSPLs is limited, it is very likely that the respective solutions will use eSPL, i.e., two LSEs. In that regard, MNA improves utilization of SPL space.

-  Ideally, each use case could better indicate which category it falls into.
(e.g., it's difficult to assume that the Segment Routing use case (section 2.5)
which has probably not been discussed in the SPRING WG is one use case
motivating MNA work and implementation)
GIM>>  Yes, although the use case described in Section 2.5 seems useful, I also cannot find a document on that topic that have been submitted for the discussion by SPRING WG. Do you propose removing this section?

[Bruno] I was proposing that use cases be split between:

  1.  uses cases justifying the creation of MNA
  2.  uses cases that would use MNA once MNA was available.

Because probably network operator and vendors are primarily interested in uses cases strong enough to motivate the investment in a new technology. At least that’s what I was looking for and section 2.5 did not seem like a strong reason to me so the use case could even be read as counter productive by some people (“if this is the use case for MNA, then I don’t really need MNA).
But that’s just a feedback. I understand that different people may have different on each use case which make my comment difficult to address. So, up to you.
No, I was not suggesting to remove a use case.




§1 Introduction
" The current state of the art requires allocating a new special-purpose label
[RFC3032] or extended special-purpose label.  To conserve that limited
resource, an MPLS Network Action (MNA) approach was proposed to extend the MPLS
architecture." I don't feel that extended special-purpose label is such a
limited ressource. So you may want to rephase/split and indicate other reasons
for MNA (e.g., stack size when multiple MNA are used in the same packet, common
framework simplifying implementation...)
GIM>> Would the following updated text be clearer:
OLD TEXT:
   The current state
   of the art requires allocating a new special-purpose label [RFC3032]
   or extended special-purpose label.  To conserve that limited
   resource, an MPLS Network Action (MNA) approach was proposed to
   extend the MPLS architecture.  MNA is expected to enable functions
   that may require carrying additional ancillary data within the MPLS
   packets, as well as a means to indicate the ancillary data is present
   and a specific action needs to be performed on the packet.
NEW TEXT:
   The current state
   of the art requires allocating a new special-purpose label [RFC3032]
   or extended special-purpose label.  To conserve that limited
   resource, an MPLS Network Action (MNA) approach was proposed to
   extend the MPLS architecture.  MNA is expected to enable functions
   that may require carrying additional ancillary data within the MPLS
   packets, as well as a means to indicate the ancillary data is present
   and a specific action needs to be performed on the packet.

[Bruno] I couldn’t spot any difference between your above OLD and NEW. Looking at the diff you provided (thanks, much useful), new text seems better but it removes one technical argument/reason in favor of MNA.
Personally I had in mind the following change:

OLD: To conserve that limited or extended special-purpose label.  An MPLS Network Action (MNA)
NEW: SPL are a very limited resource while eSPL requires two extra label per Network Action which is expensive. Therefore an MPLS Network Action (MNA)



---
"This document lists various use cases that could benefit extensively from the
MNA framework [I-D.ietf-mpls-mna-fwk]."

This reads as a normative reference to me. So I'd rather move the reference to
normative. Alternative, you could rephrase to make the use case independent of
the framework.
GIM>> Thank you for the suggestion. I moved it to the Normative References list.

[Bruno] OK, thanks.


§1.1 Terminology

"The MPLS Ancillary Data (AD) is classified as:
residing within the MPLS label stack and referred to as In Stack Data (ISD), and
residing after the Bottom of Stack (BoS) and referred to as Post Stack Data
(PSD)."

I'd rather say :s/and/or
GIM>> I think that "and" is appropriate in characterizing two types of MPLS Ancillary Data. But I noticed hypen missing in ISD and PSD. Fixed these.

[Bruno] TBH, being non-native, I don’t really know, so totally up to you/RFC editor.
FYI, while it’s a very biased search 😉, I could find example with “or”. e.g., “Non-Standards Track RFCs may be classified as Informational or Experimental.“ https://www.ietf.org/process/informal/


§1.2.1. Acronyms and Abbreviations
Thanks for expanding the acronym. But someone not familiar with the accronym
may also not be familiar with the concept. So I think adding a refence to the
RFC defining it would help.
GIM>> I know that some documents provide references in Abbreviation section. I find that references in the body of the document is sufficiently useful to a reader.

[Bruno] OK. Anyway it’s an editorial choice so up to you.


Also GDF has been moved to appendix. Is is still necessary in this list?
GIM>> I agree; removed.

[Bruno] Ack.


§2.2.2. Alternate Marking Method

Given that the MPLS WG already provided a solution for the use case, it would
be good to indicate why this is still a use case to work on and why adding a
second solution would be helpful.
GIM>> As I understand it, the WG decided that the publication of draft-ietf-mpls-inband-pm-encapsulation<https://datatracker.ietf.org/doc/draft-ietf-mpls-inband-pm-encapsulation/> is to fix squatting of the code point and the MNA-based solution will be considered:
   Considering the MPLS performance measurement with the Alternate-
   Marking method can also be achieved by MNA encapsulation, it is
   agreed that this document will be made Historic once the MNA solution
   of performance measurement with the Alternate-Marking method is
   published as an RFC.

[Bruno] Thanks for clarifying to me. I feel that the above clarification would be useful in the draft and would better motivate the creation of MNA (rather than the current: “The MNA is an alternative mechanism that can be used to support AMM in the MPLS network.” which reads as creating a second solution for no extra benefit.)
But up to you.


§2.4. NSH-based Service Function Chaining
"This approach, however, can benefit from the framework introduced with MNA "
It's not crystal clear to me what "this" refers to. e.g., RFC8595 or
draft-ietf-mpls-mna-usecases? May be clarifying would help.
GIM>> I hope that the following update makes it clearer:
NEW TEXT:
   The approach in [RFC8595] introduces some limitations discussed in
   [I-D.lm-mpls-sfc-path-verification].  However, that approach can
   benefit from the framework introduced with MNA in
   [I-D.ietf-mpls-mna-fwk].

[Bruno] ok, thanks.


§2.5. Network Programming
Has this Segment Routing use case been discussed in the SPRING WG? I don't
recall so. This comes back to the question of how the use cases have been
selected.
GIM>> The work on MNA was first conducted by the Open DT chartered by MPLS, PALS, and DetNet WGs. Once fundamental MNA documents matured, they were adopted by the MPLS WG. After that MNA work, as I understand it, has been conducted as part of MPLS WG agenda.

[Bruno] OK, thanks for the clarification. I read your answer as a ‘No’ (this Segment Routing use case has not been discussed in the SPRING WG.)


§3. Existing MPLS Use cases
This section is not clear to me. Is this expected to be count as use cases for
MNA? Justifying MNA? Using MNA? (if so why would those existing MPLS use cases
be changed to use MNA) Could this be clarified. -- "It is expected that new use
cases described in this document will allow" by "new" do you mean "additional
uses case that will be descibed in the future" in which cases this seems
unlikely after RFC publication. Or do you mean the new use cases described in
this document. If so do you mean all use cases or a select number of use cases.
If so may be they could be referenced in the sentence.
GIM>> That section is intended as the reminder to the authors of drafts that propose MNA-based solutions for the use cases listed in this document as well as for any applications in the future. I agree that "new" is confusing in the sentence. I propose the following update:
NEW TEXT:
   MNA-based solutions for the use cases described in this document and
   proposed in the future are expected to allow for coexistence and
   backward compatibility with all existing MPLS services.

[Bruno] Thanks for the clarification. If that’s the intention I would not call that section a “use case”. At minimum I propose to change the title of this section
OLD: Existing MPLS Use cases
NEW: Co-existence with existing MPLS extensions

The above proposition tries to be aligned with the title of the next section. That being said, all the MPLS extensions defined in §3 seems to be classified as Post Stack Data (PSD) (as per §1.1). If so, I’d rather propose
NEW2: Co-existence with existing MPLS Post Stack extensions

(I tried to avoid using the term PSD... Obviously please feel free to reword)


§4. Co-existence of the MNA Use Cases

MPLS allows for hierarchy. e.g., with Carriers' carrier. It would be good for
this section to cover the co-existence of MNA at multiple level of the
hierarchy. e.g. how MNA can freely be used by the customer carrier without
interference with the supporting carrier use of MNA.
GIM>> I think that the the questions of MNA deployment are outside the scope of the document that is aimed at listing generic use cases that benefit from MNA. Deployment of MNA-based solutions should be discussed in respective drafts that define the solution for the particular case listed in this document.

[Bruno] Fair enough, I guess. But its seems that the point could at least be raised.
I still believe that MNA introduces security consideration including for existing network (in particular with Carrier’s Carrier deployment) if MNA is activated by default on equipments. I.e. there is no MNA deployment done but MNA is exploited by unauthorized person which previously where shielded through MPLS hierarchy


Cf  VPN security text “unless it is known that
         such packets will leave the backbone before the IP header or
         any labels lower in the stack will be inspected,”

https://datatracker.ietf.org/doc/html/rfc4364#section-13.1

with MNA the lower labels are inspected even if they will never appear at the top of stack.

Regards,
--Bruno


§6. Security Considerations

"This document introduces no new security considerations."

I think that the above point has security implications and that they should be
covered in this section.

§ Appendix A. Use Cases for Continued Discussion
Again, what are the considerations for moving some of the use cases to appendix?
If the only reason is ongoing discussion, shouldn't we wait for the conclusion
of those discussions before publishing this document?

Thanks,
Regards,
--Bruno

____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles 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 electroniques 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 information 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 delete 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.