[Teas] Re: NRP RE: Re: Late WGLC review of draft-ietf-teas-5g-ns-ip-mpls

mohamed.boucadair@orange.com Fri, 31 May 2024 05:36 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07053C1840C1; Thu, 30 May 2024 22:36:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.093
X-Spam-Level:
X-Spam-Status: No, score=-2.093 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, 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 V1BGufz4GYzx; Thu, 30 May 2024 22:36:47 -0700 (PDT)
Received: from smtp-out.orange.com (smtp-out.orange.com [80.12.210.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFBFFC1840FF; Thu, 30 May 2024 22:36:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; i=@orange.com; q=dns/txt; s=orange002; t=1717133807; x=1748669807; h=to:cc:subject:date:message-id:references:in-reply-to: mime-version:from; bh=xmV6kVSBHJC6voqL2vGQtprEfI68/yZt2dHE+Gt4j04=; b=mOhhKVg+5gGnA20P2+014t3PqVGZSlPn4hX6JsN+e8gUNAH+W4ci45aO 0+iOQQDfkfznwlgTlyGBqIvwvFS7LZrL4HC8KGX78J9iUqksK52KLtECo +OHvuMeVt9GLJjHnLVwiSLXrAgwqwnqarh3wibF/2OEChIEtjshLBsSVT XpjUmc9PCzY41bDjFTVNfXqoaOipiHmF8sVh+yyDmkIexvYWL80DJP9o7 oNaUdh16mPYkTFk44o6gs/agpNepAtyenJb0bjgHD0AMXCfinh7j8Ec9q wnxl7rWWXXjg49e3TMmhbdE8LeTieY+ii0UvIYLX9B0c7R51YaDI4drLa g==;
Received: from unknown (HELO opfedv1rlp0f.nor.fr.ftgroup) ([x.x.x.x]) by smtp-out.orange.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 31 May 2024 07:36:44 +0200
Received: from unknown (HELO opzinddimail1.si.francetelecom.fr) ([x.x.x.x]) by opfedv1rlp0f.nor.fr.ftgroup with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 31 May 2024 07:36:43 +0200
Received: from opzinddimail1.si.francetelecom.fr (unknown [127.0.0.1]) by DDEI (Postfix) with ESMTP id 9A3C6DE84A1F; Fri, 31 May 2024 07:36:42 +0200 (CEST)
Received: from opzinddimail1.si.francetelecom.fr (unknown [127.0.0.1]) by DDEI (Postfix) with ESMTP id 80A1EDE8496B; Fri, 31 May 2024 07:36:42 +0200 (CEST)
Received: from smtp-out365.orange.com (unknown [x.x.x.x]) by opzinddimail1.si.francetelecom.fr (Postfix) with ESMTPS; Fri, 31 May 2024 07:36:42 +0200 (CEST)
Received: from mail-am7eur03lp2232.outbound.protection.outlook.com (HELO EUR03-AM7-obe.outbound.protection.outlook.com) ([104.47.51.232]) by smtp-out365.orange.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 31 May 2024 07:36:42 +0200
Received: from DU2PR02MB10160.eurprd02.prod.outlook.com (2603:10a6:10:49b::6) by AM0PR02MB5859.eurprd02.prod.outlook.com (2603:10a6:208:18a::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7633.23; Fri, 31 May 2024 05:36:39 +0000
Received: from DU2PR02MB10160.eurprd02.prod.outlook.com ([fe80::c9a1:d43c:e7c6:dce1]) by DU2PR02MB10160.eurprd02.prod.outlook.com ([fe80::c9a1:d43c:e7c6:dce1%6]) with mapi id 15.20.7633.021; Fri, 31 May 2024 05:36:39 +0000
From: mohamed.boucadair@orange.com
X-TM-AS-ERS: 10.106.160.162-127.5.254.253
X-TM-AS-SMTP: 1.0 c210cC1vdXQzNjUub3JhbmdlLmNvbQ== bW9oYW1lZC5ib3VjYWRhaXJAb 3JhbmdlLmNvbQ==
X-DDEI-TLS-USAGE: Used
Authentication-Results: smtp-out365.orange.com; dkim=none (message not signed) header.i=none; spf=Fail smtp.mailfrom=mohamed.boucadair@orange.com; spf=Pass smtp.helo=postmaster@EUR03-AM7-obe.outbound.protection.outlook.com
Received-SPF: Fail (smtp-in365b.orange.com: domain of mohamed.boucadair@orange.com does not designate 104.47.51.232 as permitted sender) identity=mailfrom; client-ip=104.47.51.232; receiver=smtp-in365b.orange.com; envelope-from="mohamed.boucadair@orange.com"; x-sender="mohamed.boucadair@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@EUR03-AM7-obe.outbound.protection.outlook.com designates 104.47.51.232 as permitted sender) identity=helo; client-ip=104.47.51.232; receiver=smtp-in365b.orange.com; envelope-from="mohamed.boucadair@orange.com"; x-sender="postmaster@EUR03-AM7-obe.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/14 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:iUdhR62KU5FOmkgrH/bD5c52kn2cJEfYwER7XKvMYLTBsI5bpzYDx jZMCGuGM/2LM2D8L9x1bY6+8xwF78LXytc1HQRoqSg9HnlHl5HIVI+TRqvS04J+DSFhoGZPt Zh2hgzodZhsJpPkjk7xdOKn9BGQ7InQLpLkEunIJyttcgFtTSYlmHpLlvUw6mJSqYDR7zil5 5Wq86UzBHf/g2Qoaj9PsvrZwP9SlK+aVA0w7wVWic9j7Ae2e0k9VPo3Oay3Jn3kdYhYdsbSq zHrlezREsvxpn/BO/v9+lrJWhRiro36ZGBivkFrt52K2XCukMCQPpETb5LwYW8P49mAcksYJ N9l7fRcQi9xVkHAdXh0vxRwS0lD0aN6FLDvcXiYj9ehlRH9WGLq39h3S2MqYNdB07MiaY1O3 aRwxDElQy2537nz6ZfkD+5mi4IkMdXhO54Ztjd41zbFAP06QJfFBaLX+dtf2zR2jcdLdRrcT 5NBNXwzM1KdOlsVYQ1/5JEWxI9EglH6dD1RrV+Z46Aw/mPawAVwypDqKtPTddHMTsJQ9qqdj jmZrjSmXU1BXDCZ4R+V7F6Qlu/voQL6Q58eS5q6yN9WpXTGkwT/DzVNDgHn/pFVkHWWUt5FK kUS0i0qoaQ1+wqgSZ/gXHWQo2WWtwQfXMVRGP8S6hyLy7LZ+UCfC3RsZiJMYccOtcIqS3otz FDht9/zDDJz9byYVXzY6rqdtnbvNm0TNioDfWoBVQ8ey9juvI91iQjAJuuPC4awh9zxXDj1n D2XtnBlg61J15VRkaKm4VrAnjSg4IDTSRI47RnWWWTj6R5lYImiZMqj7l2zAet8wJixHlmmg mM2wZSlx/kIEbyU0w6RHb9UNeT8jxqaCwH0jVlqFpgn0j2i/X+/YIxdiA2Swm85Y67onhe5M SfuVRNt2XNFAJe9RYlTC79d5uwvxKnkUN3gCf3JdIIVZoArLlTduiZzeUSXwmbh1lA2lr0yM ouadsDqCmsGDaNgz3y9QOJ1PV4XKsIWlDq7qXPTlk/PPV+iiJi9FOZt3LymMLtR0U98iF+Jm +uzzuPTo/mlbMXwYzPM7akYJk0QIH4wCPje8pMOKbbSfFY8RjB5UJc9JI/NnaQ1zsy5cc+Yr xmAtrNwlASg1RUr1C3WNC8/M+O3Df6TU1piYn1yYQ3AN4cfjXaHt/xFK8RfkUgP8e1o1/lvS PcZM86HGOwnd9g002V1UHUJl6Q7LE7DrVvWYUKNOWFjF7Y+HVCh0oG/JWPHqnJRZhdbQONl/ 9VMICuAHMJfL+mjZe6KAM+SI6SZ4iNCw70rAxKWSjSREW21mLVXx+XKpqdfC6kxxd/rn1N2C y7+7dYkSejxT0sd3eTz3fvBhqL2Vux0EwxdAnXR6quwOW/C5G2/zIRcUeGOOzfASGfz/6bkb uJQpx05GONSh05E6uKQDJ4ypZ/SJfO3z1OZ8uigNHLRZlKkB/VrJXzuMQxnqPhW3rEA0eepc h7nx+S24Ym0Bf4=
IronPort-HdrOrdr: A9a23:ik+D8KH/Udekg1G1pLqEjceALOsnbusQ8zAXPo5KJiC9E/bo9P xG8M5w6faWslYssRMb9+xoUZPoKRjhHPhOjLX5Vo3CYOCJggeVEL0=
X-Talos-CUID: 9a23:jHX5v2Ptge3EfO5DCClAylUmQJweWWTb0FrJZG2kVDwwYejA
X-Talos-MUID: 9a23:fWf53AlMBelnDo1+ehtzdnpHJNlE37SuKHwskI4bt5ajNxJRBxK02WE=
X-IronPort-AV: E=Sophos;i="6.08,203,1712613600"; d="scan'208,217";a="37987743"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XPL94txW7jqltUyjFaiIwZ9QMt9prwFrY1Ku2qFzY60ooZC27fEALmeHZswLoMaqgoEP1sGitOWL1sgmTQqnP3nx69L76wgZYfK/nhVyiGWpa6i7dHbfV9429KQM0sFFJ6h+ih4Jsu2sukfQ2V7JmV5JBF8IR19gdyilCeetOZPM5iuW7yxxinKZWYcz6UaeNSweTVIv96A4WqO4odBpK3zbmLk7NADhg6WY6gmlbWXxoJ6uHRBGoE0EuAKTQ/egGFKJ18E1tBBaptv5dq4dATc06hhb18R8nlrs/KXR5e7ZQr1hMxcvLE+7VSrv7rFVFUplczvia7yVqh4uUxKywg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=kHY/oLB6LfhcDbQ9frEwRA9kkqnoHEdJDTLSE9eV8cA=; b=FV2vzmQsADSgxj4cXdKZds58BVnbAXemixIEWHQUqOglQQkciwXoX7ThKSnqf8hFmnTkH39ojxL646OYJz23XoRZCbpwohDsO7HBuJY6H8O8HN6yFbTD3KL4GvEBGO5/AE7bIg56786HRJ1LLVuy5rrTBtZtCHVmcaCPGifYi/+5GyodYVfBUeFlTxUxLh63H2C+3Xe5+EGYzT4sgBMrKRivii11EZSTI6JJiTZIrx07BRG1JvbAwLYrUmlt6Mzb4GjFhPYxK9wNtzd5GKeg5XESJSKP2i2jeMbB8Akxs7coq4IPHbYnZ50MywsKxrVfBRjlV7b1Y2/tNj3i4arN8g==
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: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, 'Krzysztof Szarkowicz' <kszarkowicz@juniper.net>
Thread-Topic: [Teas] Re: NRP RE: Re: Late WGLC review of draft-ietf-teas-5g-ns-ip-mpls
Thread-Index: AQLHliSljbawIy4lxVnAqlLnnZszjQEd7Dm0Ad6XJmkBhHXI/AJbm13MAYfnfv8B/3pWIAG5bV+FAhyUDagBBPMAzAHCB723Af0CiEABnFIERQIpjk2UAgDK9+OvDprxEIACRCuw
Date: Fri, 31 May 2024 05:36:38 +0000
Message-ID: <DU2PR02MB10160BD56F735F47E688D2FBD88FC2@DU2PR02MB10160.eurprd02.prod.outlook.com>
References: <0ac301da99b1$d7bc8b90$8735a2b0$@olddog.co.uk> <DU2PR02MB10160A2D5721B11043AB1FDA488E42@DU2PR02MB10160.eurprd02.prod.outlook.com> <75715215-BB21-435F-B046-9B1ACE84A3A4@juniper.net> <172301daa1f2$b69beac0$23d3c040$@olddog.co.uk> <DU2PR02MB10160150AAE536CDBB4BAE73D88E32@DU2PR02MB10160.eurprd02.prod.outlook.com> <CA+YzgTvViqQWUf+UE44L7FMqouLdaMn9-3k-ss2tqkBUf_tTcA@mail.gmail.com> <1edf01daa69a$d11b90b0$7352b210$@olddog.co.uk> <CH0PR02MB829175F67760F0FBAAA91700D6EC2@CH0PR02MB8291.namprd02.prod.outlook.com> <DU2PR02MB10160E11FBAD36E01EAA7D69388ED2@DU2PR02MB10160.eurprd02.prod.outlook.com> <DU2PR02MB10160598E6F883F2F44B8819388ED2@DU2PR02MB10160.eurprd02.prod.outlook.com> <048901dab14d$0c6bf210$2543d630$@olddog.co.uk> <DU2PR02MB10160866061672B4BC4CE267988F22@DU2PR02MB10160.eurprd02.prod.outlook.com> <D4BBE978-0CE0-4E16-A958-128B8FA060E9@juniper.net> <056201dab1cc$24472ce0$6cd586a0$@olddog.co.uk> <ADBA037E-4C9C-4FE8-BE5C-B603E93BDA21@juniper.net> <070901dab2d4$13d380d0$3b7a8270$@olddog.co.uk>
In-Reply-To: <070901dab2d4$13d380d0$3b7a8270$@olddog.co.uk>
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=f33781da-8d41-407a-b3e0-2edc2b11ab39;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=2024-05-31T05:19:29Z;MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20;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;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DU2PR02MB10160:EE_|AM0PR02MB5859:EE_
x-ms-office365-filtering-correlation-id: 081b2322-4135-4ab1-9060-08dc8133a4ef
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230031|1800799015|376005|366007|38070700009;
x-microsoft-antispam-message-info: KdksVSWy+Z8RkyUIBFkFfl04uPxFpxYKl49Fr5OeVcbD+9Qvk9OP8f7b04ZQDaYZkXVv4MixA8FO5Zq/p6I01ND4IXX6Qfj+KoJVnGhvcvyIuWHHmuWjWw8wFS67F4MrBuuxP4kumD4l0H3dUGW4ZLYJJqVCn/lS9C53bkw9dmBINKAWM861/IEwCrnXs8lX+5ZPFYpZgME+GBFvHJzvVEQEi5hEz7Qj5g/lmky5NlMlgEU7tILZA5H128Xu/0bjaqSnC8GvtRn4nlBRBE7v4UXbORetW/cnd5xkoKYWC2KzkYKDhS5MznaTQ162DXBZTHyhTxmhLg0jmJYHB9g7JkvLdAEwyhmPgtI01qiAApGu/UkQfUn0l9fMUDNWL2rLiF5e2hssyXJXoR4umgYE5qlTXrJSD4QkUyeR+0O0Tng7iDSWOBPao7s1Sw5p2mOmtM4S+8IF2MkzBTL13Xg07od/HYGMjWn8FwB/ebszaOUQvWjPv8BFjIAjxtGE86134ETIEaJXWQ64rf0gv/VO2cOPep27xK5tU0WpZKkpgqCHQJ9e9yOJinRdGpRqd/8tDZM6tOBVsB4EBXlgLREqtvtf9Q1CFXlJlr5cde9Q8ZXAiogDpF17U9mjbcVAVbGJgy58ymKHwLIRgzo5Jkbx6RH7SVAfbVsMq8l4yOzJVAktdggRt98SoG8rsdl+vB8W/XO+Ce+QQ/eboAzEIVcMghaiw9c6LgUSqI94u63oTMEpSIRwMZXeVKRgRwYXuDMpjoWNQbFRvxgjnBiREWLYj/+rGGa4MToo5Cw/2lF5PRt0enRIOK4BEBm0dzWNPZ8mAvIaV3DNvVeBkJhnYnKihGHfFmPQW2bAOmYws+9Ifxd7h6m6fuLRF8rTXpEYYwgRacoz9G0LFUPjpWPU/8wOmyLvsGCTUeo3cfFUX2CFWE6IcmJfx9Wlyv8D9QW/mjIM7TA5p1lASA9t0Jwh+xJAV6AqybR9Mmqz9WsBKxOnUh6q7Oe4FaBBoCXMc9oeo+WEAAkWr1rPgWS/3kXt+PoyIeEB6L9hpYkEfNbzBOdGg3+q65DWVNm8b/fQQ32SLGWFPyJQHA3oktbN/uJImJ0VpILiRTTpJ4OVe2KCcDLxlVpFm8JXC7C+X+uZDPnD2OYAGS+aQDSYxGAueObpR+HH7eWA+eI6sIlKd3gUHB8/i9Bio3gTlNkHTNyRjeHi4x2huyXrpSkDm0OlpCVQVwDhhvryWR4VMMth9SfRacbb2bgPmV9PM7g1TAUZ/f9RWYEDdm/WLnV96NbzwsB3UfIyboFpNuL/u/7CK9U/6d8soBE=
x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DU2PR02MB10160.eurprd02.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(1800799015)(376005)(366007)(38070700009);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: Vawc6CVmPBPCx7SvSP3tHWhcyoggqI5Idxip5lTBf+YCFTbrrdnnNF5n42WVddiCxRjs+7clVDY8l8v388zlJHq+9cTctXSCtaWmpfGPtMTCTB7+HDK/JO6DeZr2ipFI24+XuW+QqaKRSWHPc82cJjft668m4537DF5JpVNsyUZU3iy4C0gi4O4uUKPWTq1WHbceL7lotcyfR2rAGp9b1Y0o33yyIbECo/zzCj0JI38LihcmEhhpjnrKLF/MJAzt85KEPeO7efV2vGQI6fm8kHUuJh0Y/W3TqpHsCAAtdeN5kldq9l3FNqngrIMDffuQ9xk1auPTG+tP6Vp4zNtIGdxRyFNuPvVGLv+lCGHn3FIotgY1x0RDAJuZGc6YKYovIGhKFOXz0v71c0ynxVzIcflND4FhCfoJ1oo3z1KgKBcQdHe0O77IErZ7qFa3N3dMXHl2dncHZRFzfQjEDGCqbxwf4NCgGe4v2/ZD6srju7vsEFfnn/7QpmUVdpacF7zDcXss+4kCjVgFUCMJaWJY2pSoc6GNr+1q6OWTzEHKAh9EYK805F7/2C83fCVyrPS8Uqf4R8zQBVH7dtT3jYEQh16NeT54ugBjZzVgEbxZw79w3j8s+BKgdhVJ1fEaYdd06Apw1thk1gk4WWpnwZOsIROwGUauFTQGIy9//GIBTj2+y+LKrlsr0zMPeYeFmJTSfKNZ/p4zres2aw5kCQPqUq8oNCRh74cmT3CnuyQQ7rqEo+tl/glah5dX2G+uEA4s/FeK1WuYeTb2za0NU7SdKH9Qy+zuXJNzIgXdHFrVGM7/Fx0KZRtqsvfjk1zgrURiIDQHB98WwfloluValGLBLmfqJryVJhaSl41cj684MDCzw+Giv6T3cBfATByrmXKFeiDcIi3fsDK7jfMCNWohb1iQ0EaVv6ECSeoO0dYFDgcWL7V/0+OZZhf5M/8ZNJkNdWwzqFrAPg7EVsGhNW27H8qtiQMWiqUfcF+5BbKADEaEZVNf9IHkSXDxZOcvUd+XFYWqHuhll3z4MI0wUpR3U/KQ7cIGupOUUGhnjqFiPghrkKvhuTiZ16guDV9fDYh6FgzrtPgoJNSyz3kvUEnBsX3es9KaWDexfexHhTMyGuu7wC2Lhx0vIQ867ez6UOGgt/15R00nUixdWy+kSa2f9a54YGvU2t+RHcfk3GrZjqFDNAXuB9dEmaoznF33WGmr0/IJOhb76Qbozu7mnmzW1jpW6NPAqvoNP55K9lASJjKuZkikxpUNJdZgeL77+ghKdzMRqR8V0jPRtvLrpEq6aEcEmrKRNG0sfMFoVpR623Fpeq25dQWKP+1TBfO7pnDaBKhlSRHsfFhbAXwziJL+aZvTSVUsHD8vKvKmZF/9yRKulep2B0o9zxJWm5D2FBkX2AsLxcGgeQxlygRshEKYC9Tb3V78GTgQpz4e6/wIJ4stujqmyQPMN9sM9qfVaJE5tcVmw+PYzq/ZyEKJoEDFJBwo1XKTELv2n1RuF3ioZYeXxcExZDEYIo6ksJYfrS1jtu0tJd2nmGJf/E/9cWAUziHPy+pJ7uV9lIYbOTTPbDYh0anFUoSrmU6uo+6AFNuRMWLLDJNm60rbW0A38nV71Q==
Content-Type: multipart/alternative; boundary="_000_DU2PR02MB10160BD56F735F47E688D2FBD88FC2DU2PR02MB10160eu_"
MIME-Version: 1.0
X-OriginatorOrg: orange.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DU2PR02MB10160.eurprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 081b2322-4135-4ab1-9060-08dc8133a4ef
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 May 2024 05:36:38.9614 (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: skLSLxUxuLN4R889/XD41mdODMepe+Y2e401vCIBfELMXn5yvQlHuWHduxsdlxM0Wm9+10KSxkVx9V8BtnK1HJKx4mJlMv3QLbrAIyy/stc=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR02MB5859
X-TM-AS-ERS: 10.106.160.162-127.5.254.253
X-TM-AS-SMTP: 1.0 c210cC1vdXQzNjUub3JhbmdlLmNvbQ== bW9oYW1lZC5ib3VjYWRhaXJAb 3JhbmdlLmNvbQ==
X-TMASE-Version: DDEI-5.1-9.1.1004-28420.005
X-TMASE-Result: 10--45.854400-10.000000
X-TMASE-MatchedRID: 1uttSxkBlaXuYusHgJkgysBlSCU9v/XYevFaYkHe0BiOPqa3WX8UZvri j4SA+glQeL+ISMsgRmFwyAmzxb7Z05qnULil5JqLHo5fF1EYvHzVjNsehGf0vThbuaUQKXpsz4t u7OlRHUZKxf5lRFSjCYjVyszGrwWGuLt50vtxBA6009crc0KdpDb+WPFOeKNM5wMPMqdPNSxeeQ R8Yh2XN+Vkr7cFbIi9PXdZx1sZHpBH4a2iJdV4MRKvFacTVVSJ5sJMjFHY0e4OC+cCmTEEBVbLC qFrdjtBZidiiEoOZ/5+fOZykHM6u1qQSiefpm7hHFZ70WvsP0ZEthoo7CRHt4fFM47qD9Fe3tCV NwQ7yJ723jc+gV6AAMfdkIlEiI2kyi9lIVuTrxtMQXZwH0qMvs5GBlilKvLtpDED2B6eeA89PA3 DB9UvmHUOuLROmXRE7DQeAa/IxAX5Jwn+WOYz2NwCa7XGp562Pw28fbEwa7EAwlwc7PMO49o6dS Kh+1r/275BbjTDINjotOADvmQoriIuZ/6CFMb/NUSduuqYHDvMtotGtpF5VrXip9G5gJewKQDLv M3kh06KQfHzsMI7ddXPs/Fr8i7AdlZIDouX4NA+wYb6RCy8qAdapmdpCjnMjhAvPdL0MNjPwtzH jYTJmCmWgmxpdpWGtcdHWrX35xQEClJgjzpjqD0Ol1nHkdplL6ujXxxUURFV/jw7v14uaomqFO2 zmhlJxDduOe0iotIAFW6I4JCZDeXYI0z4MDj0fkuZtv/FS5rN/524wIksTKXjQe8TtIi3Owp2jM Jf09xZiIfog8nNB09dh3PRYVY1LCOlrnWhfGsNsuQOB7UFW0kpgPVaEY4Jo8WMkQWv6iUojzu/j hRWTQKLL4Z+HVHJdR/G8OvKIg8TNCcUsR4xSdJHoSpWytSpKNlNPSGTsIjYmC0C5U0cHq0hbOeG OMG1/nnwJ52QYi+pygCGKFPC+BeYl5uS2QAg
X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0
X-TMASE-INERTIA: 0-0;;;;
X-TMASE-XGENCLOUD: 76ab0b0f-ce8f-4d5e-af73-4b217f6703f8-0-0-200-0
Message-ID-Hash: A2SSEV7RMM3VPTR4ERI6FD5NWERMPX5B
X-Message-ID-Hash: A2SSEV7RMM3VPTR4ERI6FD5NWERMPX5B
X-MailFrom: mohamed.boucadair@orange.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-teas.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: 'TEAS WG' <teas@ietf.org>, "draft-ietf-teas-5g-ns-ip-mpls@ietf.org" <draft-ietf-teas-5g-ns-ip-mpls@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Teas] Re: NRP RE: Re: Late WGLC review of draft-ietf-teas-5g-ns-ip-mpls
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/XCkIhownB-4ZkBRL_jChZcmf4gY>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Owner: <mailto:teas-owner@ietf.org>
List-Post: <mailto:teas@ietf.org>
List-Subscribe: <mailto:teas-join@ietf.org>
List-Unsubscribe: <mailto:teas-leave@ietf.org>

Hi Adrian, all,

(1)

>From where I sit, I note your positive feedback that the proposed changes make things better. I will implement these for now.

Also added this NEW to make the correlation between the various pieces explicit:

"These protocols can be controlled, e.g., by tuning the protocol list under the "underlay-transport" data node defined in the L3VPN Network Model (L3NM) {{?RFC9182}} and the L2VPN Network Model (L3NM) {{?RFC9291}}."

Will be monitoring if any further change is needed. Thanks.

(2)

I also think that you are completely right that there is a disconnect in interpreting the various words.

The WG had a lengthy discussion on this same topic: whether tunnels with or without TE is an NRP or not. See for example Re: [Teas] Default NRP definition [Was: Repeated call for last call on draft-ietf-teas-ietf-network-slices]<https://mailarchive.ietf.org/arch/msg/teas/RiBg6GgO1DaxI-UnZsZL0AiOGwI/> and other messages in that thread.

==
1. Taking into consideration typical SP network today, where we have:

a) differentiated services realized via mapping of DCSP and/or MPLS TC values to buffers, and deploying some differentiated scheduling
b) running services (L3VPN, L2VPN, ...) over such network
c) possibly (but not necessarily) deploying some TE

Do we refere to typical current SP deployment as using 'single NRP' or not using NRP at all?

[JD]  A single NRP

..

2. If I have in my network two set of tunnels between PE nodes, using different link metric types (e.g. one set of tunnels uses IGP link metric to determine the path through the network, another set of tunnels using TE link metric to determine the path through the network), and these two sets of tunnels use exactly the same resources: entire topology, i.e. all links and nodes in the network, and the PHB is exactly the same (i.e., packet with QoS marking 'X' get exactly the same treatment in terms of buffering/scheduling, regardless if forwarded over tunnel from 1st tunnel set, or tunnel from 2nd tunnel set) are we talking about one NRP or two NRPs?

[JD]  A single NRP.  You are using different path computations on the same NRP
==

Please note that we have this text which I think is key for the discussion. This text is now moved early in Section 6:

   It is worth noting that TN QoS Classes and Transport Planes are
   orthogonal.  The TN domain can be operated with e.g., 8 TN QoS
   Classes (representing 8 hardware queues in the routers), and 2
   Transport Planes (e.g., latency optimized transport plane using link
   latency metrics for path calculation, and transport plane following
   Interior Gateway Protocol (IGP) metrics).  TN QoS Class determines
   the per-hop behavior when the packets are transiting through the
   provider network, while transport plane determines the paths for
   packets through provider network based on operator's business model
   (operator's requirement).  This path can be optimized or constrained.

Cheers,
Med

De : Adrian Farrel <adrian@olddog.co.uk>
Envoyé : jeudi 30 mai 2024 22:58
À : 'Krzysztof Szarkowicz' <kszarkowicz@juniper.net>
Cc : 'TEAS WG' <teas@ietf.org>; draft-ietf-teas-5g-ns-ip-mpls@ietf.org
Objet : [Teas] Re: NRP RE: Re: Late WGLC review of draft-ietf-teas-5g-ns-ip-mpls

OK, sorry, let me try this again without being snippy. I'm really sorry about that.

9345 has a stack of concepts:
Slice
NRP
Filtered network
Physical network

There is a 1:n relationship between each pair as you move up the stack. (There has been some discussion about an m:n relationship, but that is left for future study.)

If I understand your draft correctly, you have the following hierarchy.
Slice
Transport plane
NRP (just one of these)
Filtered network
Physical network

With a 1:n relationship of NRP to Transport plane, and Transport plane to Slice. (You also suggest that there might be a more complex m:n relationship between NRP and Transport plane, but that is left for future study.)

Med's suggested text changes make these relationships clear, and it is worth making them.
Med's other suggestion to use "transfer plane" instead of "transport plane" might help reduce re-use of terminology. I'd be OK with that change for this reason. But in the rest of this email, I'll stick with "transport plane" for clarity.

Now, to my debate as whether a Transport plane is the equivalent of a Slice or an NRP. I'd still like to dig at this because I have a disconnect that I don't understand.
You have the definition...
   A transport plane refers to a specific forwarding behavior between
   PEs in order to provide packet delivery that is consistent with the
   corresponding SLOs.
And you go on to list a few possible realisations:
   * A mesh of RSVP-TE [RFC3209] or SR-TE [RFC9256] tunnels created
      with specific optimization criteria and constraints.
   * A Flex-Algorithm [RFC9350] with a particular metric-type, or one
      that only uses links with particular properties, or excludes links
      that are within a particular geography.

I think that this definition, and particularly the example realisations are what cause the confusion for me.

You correctly quoted the 9543 definition of an NRP:
   An NRP is a subset of the buffer/queuing/scheduling resources and
   associated policies on each of a connected set of links in the
   underlay network
But, while you say this precludes a Transport plane being considered an NRP, I find it a good match. How are we seeing this so differently?
In my view, the definition says "Take the pool of all the buffer resources, queuing resources, scheduling resources, and all the policies associated with each resource. Then take some subset of this pool."
That subset could be, "All the resources, and some of the policies." Or it could be, "Some of the resources, and all of the policies on those resources." Or anything else.

Now, you said...
Different sets of tunnels (established using some of available technologies, like RSVP, Flex-Algo, SR-TE), using different metric for path optimization (e.g. one set optimized based on link delay metric, another set optimized based on IGP metric derived from link bandwidth) do not create different NRPs.
I struggle with this, because in my head as I wrote the words was a set of RSVP-TE tunnels with resource reservation and associated forwarding policies. We quickly got into a discussion of a whole set of tunnel-based approaches, with policy-based SRv6 getting a lot of attention. So rather than list an incomplete set of possible approaches, 9543 abdicated responsibility with:
   Realizations of an NRP may
   be built on a range of existing or new technologies, and this
   document does not constrain solution technologies.
I guess abdication is something we're all good at because you have:
   Detailed realization of transport planes is out of the scope of this
   document.

So, really, I am trying to understand why the 9543 definition of NRP doesn't square with your definition of transport plane.

Med also referred me to RFC 9182, saying...
o. I heard other comments that this is similar to NRP. We prefer to use a term that is close to what is currently used in deployments. For example, this is consistent with RFC9182 and several RFCs out there which include the following:

  'underlay-transport':  Describes the preference for the transport
     technology to carry the traffic of the VPN service.  This
     preference is especially useful in networks with multiple domains
     and Network-to-Network Interface (NNI) types.  The underlay
     transport can be expressed as an abstract transport instance
     (e.g., an identifier of a VPN+ instance, a virtual network
     identifier, or a network slice name) or as an ordered list of the
     actual protocols to be enabled in the network.

     A rich set of protocol identifiers that can be used to refer to an
     underlay transport are defined in [RFC9181].

Curiously, this definition suggests that the "underlay transport" might be expressed as a network slice name. Which did make me think that the concept was consistent with a network slice. Of course, a network slice is a hierarchical concept, so it would be possible to slip this definition in within that concept.

On this topic, you said:

I am not describing network slices.  RFC 9543 definition of network slice:
IETF Network Slice:
The realization of the service in the provider's network achieved by partitioning network resources and by applying certain tools and techniques within the network.
Using different metric types for path calculation doesn't partition network resources.

(An aside would be to ask why it is necessary to use a new term (transport plane or transfer plane) rather than using the 9182 term. But let's not go there!)

Finally, Med also said:

I heard other comments that this is similar to NRP. We prefer to use a term that is close to what is currently used in deployments.

...and maybe, at the end of this lengthy ramble, this sums it all up. It's just another name for an NRP. If the document were to say that, I guess I'd be happy, although I would wonder why it needs two terms.
And this just runs us up against the problem that the draft is adamant that there is only one NRP, so it is necessary to use a different term and construct to achieve the same partition of the network.

Well, I'm no closer to an answer. Sorry. It just isn't clear to me what's going on here.

Cheers,
Adrian


From: Krzysztof Szarkowicz <kszarkowicz@juniper.net<mailto:kszarkowicz@juniper.net>>
Sent: 29 May 2024 14:45
To: Adrian Farrel <adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>>
Cc: BRUNGARD, DEBORAH A <db3546@att.com<mailto:db3546@att.com>>; EXT-vishnupavan@gmail.com<mailto:EXT-vishnupavan@gmail.com> <vishnupavan@gmail.com<mailto:vishnupavan@gmail.com>>; TEAS WG <teas@ietf.org<mailto:teas@ietf.org>>; TEAS WG Chairs <teas-chairs@ietf.org<mailto:teas-chairs@ietf.org>>; draft-ietf-teas-5g-ns-ip-mpls@ietf.org<mailto:draft-ietf-teas-5g-ns-ip-mpls@ietf.org>; Mr. Mohamed Boucadair <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>>
Subject: Re: [Teas] NRP RE: Re: Late WGLC review of draft-ietf-teas-5g-ns-ip-mpls

Adrian,

I am not describing network slices.  RFC 9543 definition of network slice:


IETF Network Slice:
The realization of the service in the provider's network achieved by partitioning network resources and by applying certain tools and techniques within the network (see Sections 4.1<https://datatracker.ietf.org/doc/html/rfc9543#defns> and 7<https://datatracker.ietf.org/doc/html/rfc9543#realize>)


Using different metric types for path calculation doesn't partition network resources.

Cheers,
Krzysztof

On May 29, 2024, at 15:28, Adrian Farrel <adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>> wrote:

I agree, Krzysztof,
You are describing network slices.
Adrian

From: Krzysztof Szarkowicz <kszarkowicz@juniper.net<mailto:kszarkowicz@juniper.net>>
Sent: 29 May 2024 10:54
To: Adrian Farrel <adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>>
Cc: BRUNGARD, DEBORAH A <db3546@att.com<mailto:db3546@att.com>>; EXT-vishnupavan@gmail.com<mailto:EXT-vishnupavan@gmail.com> <vishnupavan@gmail.com<mailto:vishnupavan@gmail.com>>; TEAS WG <teas@ietf.org<mailto:teas@ietf.org>>; TEAS WG Chairs <teas-chairs@ietf.org<mailto:teas-chairs@ietf.org>>; draft-ietf-teas-5g-ns-ip-mpls@ietf.org<mailto:draft-ietf-teas-5g-ns-ip-mpls@ietf.org>; Mr. Mohamed Boucadair <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>>
Subject: Re: NRP RE: [Teas] Re: Late WGLC review of draft-ietf-teas-5g-ns-ip-mpls

Hi Adrian,

Taking the definition of NRP from RFC 9543, different sets of tunnels (established using some of available technologies, like RSVP, Flex-Algo, SR-TE), using different metric for path optimization (e.g. one set optimized based on link delay metric, another set optimized based on IGP metric derived from link bandwidth) do not create different NRPs. Therefore, they are different transport planes within the default NRP.

Cheers,
Krzysztof

On May 29, 2024, at 09:34, mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com> wrote:


[External Email. Be cautious of content]


Hi Adrian,

Thank your for the follow-up and for your effort on track pending issues. Much appreciated.

I see two main open discussion points to which I will reply in separate threads to ease your review.

Let's start with the last point in your list below: link transport planes to 9543 terms.

==Adrian===
But the document is pretty adamant that "The realization model described in this document uses a single Network Resource Partition (NRP) (Section 7.1 of [RFC9543]).  The applicability to multiple NRPs is out of scope." So why talk about multiple transport planes?
============

RFC9543 says the following:

   An NRP is a subset of the buffer/queuing/scheduling resources and
   associated policies on each of a connected set of links in the
   underlay network (for example, as achieved in
   [RESOURCE-AWARE-SEGMENTS]).  The connected set of links could be the
   entire set of links with all of their buffer/queuing/scheduling
   resources and behaviors in the underlay network, and in this case,
  there would be just one NRP supported in the underlay network.

We are not aware of any existing implementation that allow to provide a "subset of the buffer/queuing/etc.". Support of multiple NRPs is thus not considered in the document: because that's not something we can fairly claim that we support with existing technologies. Hence, the single NRP mention.

Assuming a single NRP (called, based NRP in the doc), and putting QoS matters aside, different forwarding behaviors are still needed within that single NRP. Multiple transport planes is used to refer to that.

Now back to the text, I suggest to make the following changes:

(1)

OLD: A network operator can define multiple transport planes.
NEW: A network operator can define multiple transport planes within a single NRP.

(2)

NEW:
Also, transport planes may be realized using separate NRPs. However, such an approach is left out of the scope given the current state of the technology (2024).

These changes can also be tracked here: Diff: draft-ietf-teas-5g-ns-ip-mpls.txt - draft-ietf-teas-5g-ns-ip-mpls.txt<https://urldefense.com/v3/__https:/author-tools.ietf.org/api/iddiff?url_1=https:**Aboucadair.github.io*5g-slice-realization*draft-ietf-teas-5g-ns-ip-mpls.txt&url_2=https:**Aboucadair.github.io*5g-slice-realization*NRP-or-not-NRP*draft-ietf-teas-5g-ns-ip-mpls.txt__;Ly8vLy8vLy8v!!NEt6yMaO-gk!AvFSa2NUSvWb_RcuojobP59MrIH50WAD-UQf2HwPTMSyGCWwL8RKqC8uPq67QScehr0YL005kYX2jS6NvY5A54oTeIQLbuIb$>.

Does this make sense? Thank you.

Cheers,
Med

De : Adrian Farrel <adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>>
Envoyé : mercredi 29 mai 2024 00:19
À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>>; 'BRUNGARD, DEBORAH A' <db3546@att.com<mailto:db3546@att.com>>; 'Vishnu Pavan Beeram' <vishnupavan@gmail.com<mailto:vishnupavan@gmail.com>>
Cc : 'Krzysztof Szarkowicz' <kszarkowicz@juniper.net<mailto:kszarkowicz@juniper.net>>; 'TEAS WG' <teas@ietf.org<mailto:teas@ietf.org>>; 'TEAS WG Chairs' <teas-chairs@ietf.org<mailto:teas-chairs@ietf.org>>; draft-ietf-teas-5g-ns-ip-mpls@ietf.org<mailto:draft-ietf-teas-5g-ns-ip-mpls@ietf.org>
Objet : RE: [Teas] Re: Late WGLC review of draft-ietf-teas-5g-ns-ip-mpls


Hi Med,

Sorry for the delay. Thanks for posting the updates.

I looked at the diff between -05 (which I reviewed) and -07 (that you just posted).

A lot of really good changes. Many thanks.

I hope the colour coding works. Please shout if it doesn't and I'll do something else.

Cheers,
Adrian

[Deborah] I agree with Adrian - it is not helpful for good SDO relationships to include in an IETF document (even as an appendix) a description of another SDO's technology without requesting a review. While it may appear to be "process", in the past, when another, unnamed, SDO made assumptions on an IETF technology, IETF was not happy. It became a very contentious technical argument. Recommend, either send a liaison (can be done in parallel with IESG review/request for publication) or remove (can enhance the current figures/terms if needed). While some have commented they found this Appendix helpful, I find it too detailed. With all the on-going architectural discussion in ORAN and 3GPP on these interfaces and components (and resulting presumptions on implementation), if want to keep, it should be scoped only to what is relevant to IETF.

I don't know how we're going to resolve this. Obviously, Deborah and I are unconvinced about including the Appendix, certainly in its current form. The chairs have called "consensus" to include the appendix. I'm a little disappointed with that call as I didn't see the arguments in favour except "We find it helpful."

[Deborah] Looking at the updated document on Adrian's comments, I also find what Adrian commented as still not being clear in 3.3.3. To say in this document, that another TEAS working group document has shortcomings, is not a fair statement.
[Med] That's not the intent of the text. We only explain why we don't mention PBR or relying on source port numbers for slice identification purposes. There is nothing against the app I-D.
[Deborah] If don't want to include the proposals of the other document, suggest simply delete this paragraph. The paragraph above already says this document lists a few (lists few/s/lists a few).
[Med] Let's try that and avoid spending more cycles on this.

I'm happy with that solution.

The document could really benefit from the addition of a section
called "Scalability Considerations."

draft-ietf-teas-nrp-scalability says...

[snip]
[Med] I hear the comment even if the NRP advice does not directly apply here. We added a new section about scalability implications and added new text to remind that we inherit scalability properties of current technologies. We added pointers for readers interested in such scalability assessment.
[AF] Even your choice to have just one NRP is still an NRP, and thinking about scalability is important especially as the chosen approach does have some scaling limits. So thanks for the section.
[Med] ACK.

Your new section is nice. Thanks.

3.1

  The term "Transport Network" is used for disambiguation with
  5G network (e.g., IP, packet-based forwarding vs RAN and CN).
  Consequently, the disambiguation applies to Transport Network
  Slicing vs. 5G End-to-End Network Slicing (Section 3.2) as well the
  management domains: RAN, CN, and TN domains.

I thought I understood what was meant by TN in this document
until I reached this paragraph. The previous text in 3.1 (and in
the references) seems clear as to what a TN is. This text,
however, confuses me and I can't extract anything useful from it.
After all, haven't you just explained that:

  Appendix B provides an overview of 5G network building blocks:
  the Radio Access Network (RAN), Core Network (CN), and
  Transport Network (TN).  The Transport Network is defined by
 the 3GPP as the "part supporting connectivity within and between
 CN and RAN parts" (Section 1 of [TS-28.530]).

[Med] This is still under discussion among authors.
[Med] With the updated Intro, we do think that this text is not needed anymore. So, deleted it.

Yup. OK.

Figure 5 finally makes it clear that you are trying to
distinguish a "network slice" from a "TN slice".

[Med] Bingo, but it is unfortunate to see that readers may find that mention too late. Updated the intro to call that out early in the doc.
[AF] Excellent, but still dangling is...

In practice, I think you are trying to say that the slices of the different
domains may be combined to form an end-to-end slice in the
IP/MPLS technology. This is certainly supported by 3.4.2 and is
consistent with draft-li-teas-composite- network-slices, but you
need to work out which way you are slicing (sic)
this:

[snip]

[Med] I hope this is now better articulated with the changes.

Yes, the new mini-paragraph just before Figure 6 is good.

In 3.4.2 and with reference to Figure 5, it appears that your
realisation is based on RFC 9543 Figure 1 Type 3. That's great,
could you say so somewhere early in the document? It would help.
[Med] Added a statement that the realization is based on types 3/4.

Good.

By the time we get to Figure 6, you are talking about "slice
segments" and that is really helping because now we can
consider stitching those segments together.

[Med] Moved that figure to the introduction.

Yeah, that is a good call. Makes the reader pay attention to the architecture.

3.4.2

  In other words, the main
  focus for the enforcement of end-to-end SLOs is managed at the
  Network Slice between PE interfaces connected to the AC.

Would that be more clearly stated with reference to the SDP?
[Med] I think this is covered by the note about types 3/4.

OK

3.5

There seems to be a difference between the title of the
section...
     Mapping Schemes Between 5G Network Slices and Transport
    Network Slices
...and the first line of text
  There are multiple options for mapping 5G Network Slices to TN
  slices:
That is, the text talks about a unidirectional mapping (5G to TN)
while the title says "between".
[Med] Updated to "Mapping 5G Network Slices to Transport Network Slices" for consistency.

So far, so good...

But I think I object to the word "mapping".
While, in one
direction, the word is fine and clearly describes how one type of
slice is projected onto another type of slice, the problem is
more complicated because in the other direction (at the receiving
end of the data flow) we need to "un-map".
[Med] Why should we be concerned with that? Isn't that part of the non-TN job?

This depends on whether you are simply tunnelling ("map" means which 5G slices will be carried by which TN slice) or if you are aggregating ("map" means that a set of 5G slices "become" a TN slice). As you exit the TN slice, you need to go back to processing the individual 5G slices, and that is easy in the tunnelling case. But it is more complicated to demux when the mapping does not preserve the identity of the 5G slice.

[snip]

Section 4 is pretty clear and helpful. Thanks. I think it is
where the real work of the draft begins (23 pages in). I wonder
whether we can do something to get here more quickly.
[AF] Seems like you're not rising to this :-)
I wonder whether the introduction can steal a few lines from this section to set the document up a bit better.
[Med] Good suggestion. Moved some text around.

Thanks. Good.

In Section 6, have you invented the Filter Topology when you use
the term "transport plane"? I think you have, and it would be
helpful
either:
- to say "when we say transport plane, this is equivalent to the
   term Filter Topology defined in RFC 9542"
- to replace all mentions of "transport plane"

I prefer the second of these.
[Med] I'm not sure filtered topology is exactly identical to. I heard other comments that this is similar to NRP. We prefer to use a term that is close to what is currently used in deployments. For example, this is consistent with RFC9182 and several RFCs out there which include the following:

  'underlay-transport':  Describes the preference for the transport
     technology to carry the traffic of the VPN service.  This
     preference is especially useful in networks with multiple domains
     and Network-to-Network Interface (NNI) types.  The underlay
     transport can be expressed as an abstract transport instance
     (e.g., an identifier of a VPN+ instance, a virtual network
     identifier, or a network slice name) or as an ordered list of the
     actual protocols to be enabled in the network.

     A rich set of protocol identifiers that can be used to refer to an
     underlay transport are defined in [RFC9181].
[AF] Two points here:
1.       If this sounds like NRPs, then you are acknowledging multiple NRPs, which is OK but is counter to your assertion that there is a single NRP in all aspects of this document.
[Med] I wasn't saying that I agree with that NRP comment.
2.       The quoted text from 9182 sounds exactly like filtered topology to me
[Med] Still this can be done using the same topology. We updated the text with a new text to explain the notion of "transport plane":

NEW:
A transport plane refers to a specific forwarding behavior between PEs in order to provide packet delivery that is consistent with the corresponding SLOs.

Well, I don't think we are converging :-(
This is a document about IETF network slices, so it should link back to the terminology in RFC 9543. It doesn't have to use that terminology, but it should link to it.
So, keep all your text about "transport plane" if you like (noting that ITU-T people may find this a little confusing), but let's still try to understand where this fits in the architecture and in this document.

You have: "A network operator can define multiple transport planes."
So, does a transport plane map to:

·         A TN slice

·         An NRP

·         A filtered topology
Re-reading, I see that the transport plane could be a collection of tunnels. That certainly sounds like an NRP. It is partitioning the links that might be selected by a filtered topology, so it isn't a filtered topology. But it is providing connectivity mechanisms that could be used by multiple TN slices, so it isn't a TN slice. Hence, NRP.
But the document is pretty adamant that "The realization model described in this document uses a single Network Resource Partition (NRP) (Section 7.1 of [RFC9543]).  The applicability to multiple NRPs is out of scope." So why talk about multiple transport planes?

[snip]

____________________________________________________________________________________________________________

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.

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

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