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

mohamed.boucadair@orange.com Sat, 01 June 2024 09:09 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 26C5EC14F713; Sat, 1 Jun 2024 02:09:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.093
X-Spam-Level:
X-Spam-Status: No, score=-7.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_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=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 dkHlr7zhpQQ9; Sat, 1 Jun 2024 02:08:56 -0700 (PDT)
Received: from smtp-out.orange.com (smtp-out.orange.com [80.12.126.237]) (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 7A8E0C14F70C; Sat, 1 Jun 2024 02:08:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; i=@orange.com; q=dns/txt; s=orange002; t=1717232936; x=1748768936; h=to:cc:subject:date:message-id:references:in-reply-to: mime-version:from; bh=IKOt+NT2XdabxG67aTQKBfDaZjlcrKKmb6SNnG2aoLk=; b=pJFCeksKOsORHccFeUcpIMjLGEZFtDfARBha2aQ5hw8+WjZ/xNaaEzyn IgXYUlLHdcEDiyadACTDi1G4PhhFDwy7ga+AoAYLjdVNsOmwZdiSIkCua Cb74oIKbTzlL2DrzvJlfzE76IGqjpsLrHQSRci6E/5ESfHDkylwUv9PC0 rEhnGU+LB0hKmQGQKENFcYBES264zTU3sDobEe5XcDCbbZQeBUv9U5OG7 vPdNOl0NN+kZpYiuptn8gN88enHnxmAPMdCOUEj/hu5m+E4mi5xNocbX7 g02AeCGF0WTPbktDMnXz6RHSmx83hQwdevVnQ0btBc0HUmY3u0js6bvZX 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; 01 Jun 2024 11:08:53 +0200
Received: from unknown (HELO opzinddimail3.si.francetelecom.fr) ([x.x.x.x]) by opfedv1rlp0f.nor.fr.ftgroup with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Jun 2024 11:08:53 +0200
Received: from opzinddimail3.si.francetelecom.fr (unknown [127.0.0.1]) by DDEI (Postfix) with ESMTP id 0E6245206E24; Sat, 1 Jun 2024 11:08:53 +0200 (CEST)
Received: from opzinddimail3.si.francetelecom.fr (unknown [127.0.0.1]) by DDEI (Postfix) with ESMTP id EAA3E5206E23; Sat, 1 Jun 2024 11:08:52 +0200 (CEST)
Received: from smtp-out365.orange.com (unknown [x.x.x.x]) by opzinddimail3.si.francetelecom.fr (Postfix) with ESMTPS; Sat, 1 Jun 2024 11:08:52 +0200 (CEST)
Received: from mail-vi1eur05lp2169.outbound.protection.outlook.com (HELO EUR05-VI1-obe.outbound.protection.outlook.com) ([104.47.17.169]) by smtp-out365.orange.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Jun 2024 11:08:43 +0200
Received: from DU2PR02MB10160.eurprd02.prod.outlook.com (2603:10a6:10:49b::6) by DB9PR02MB6777.eurprd02.prod.outlook.com (2603:10a6:10:213::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7611.27; Sat, 1 Jun 2024 09:08:42 +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; Sat, 1 Jun 2024 09:08:41 +0000
From: mohamed.boucadair@orange.com
X-TM-AS-ERS: 10.106.160.157-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@EUR05-VI1-obe.outbound.protection.outlook.com
Received-SPF: Fail (smtp-in365b.orange.com: domain of mohamed.boucadair@orange.com does not designate 104.47.17.169 as permitted sender) identity=mailfrom; client-ip=104.47.17.169; 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@EUR05-VI1-obe.outbound.protection.outlook.com designates 104.47.17.169 as permitted sender) identity=helo; client-ip=104.47.17.169; receiver=smtp-in365b.orange.com; envelope-from="mohamed.boucadair@orange.com"; x-sender="postmaster@EUR05-VI1-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:ihpMlqI7noo3lzXtFE+RApIlxSXFcZb7ZxGr2PjKsXjdYENSgmYEz mceUGGEOvfZN2X2KtknPNng9ksFsMDTxoRqSAdorCE8RH908seUXt7xwmUcns+xwm8vaGo9s q3yv/GZdJhcokf0/0vraP64xZVF/fngbqLmD+LZMTxGSwZhSSMw4TpugOdRbrRA2bBVOCvT/ 4uiyyHjEAX9gWIsbDpNs/jrRC5H55wehhtJ5zTSWtgb5Dcyp1FNZLoDKKe4KWfPQ4U8NoZWk M6akdlVVkuAl/scIovNfoTTKyXmcZaLVeS6sUe6boD56vR0So7e5Y5gXBYUQR8/ZzxkBLmdw v0V3XC7YV9B0qEhBI3xXjEAexySM5Gq95fDDyOCq++W6XHbYibo/copEGc0IasXr7Mf7WFmr ZT0KRggUyrb2qeI4ev+TeNhwMM+MMPsIYUT/Gl6yi3UBuonRpaFRLjW4dhf33E7gcUm8fT2P pJFL2YwKk2fJUQRaz/7C7pm9Ausrnz4czRdpV7Tr60q6GHfxQ1r+L/3Odzad5qBQsA9ckOw/ TKfojWnXkpy2Nq38jWI7njxmOb1xBzAf51PMrPjyKVTjwjGroAUIEZNDwfkyRWjsWa3V8heI ko8/S4ioa89skesCMT+NzW0qiXZ4kA0UsZMVeY97Wml1KvP4wCEHmEaRzhpZ9kvtctwTjsvv neKhMHgHz9or7yeW1qf67GVtT6ofy4YMQcqeSINViME7sXt5oYpgXrnUttqC+u+jtT0AyrYw j2Wom45nbp7pcIR3qunuFHKnzzpupXAVUto6UDRRSek9kZ8fIq+T42l9Vad6uxPRLt1VXGEt XkA3tafte0TF8nQkDTXGbtcWra0+/yCLTvQx0Z1GIUs/Cis/Hjlep1M5DZ5JwFiNcNslSLVj FH7vS0K2YVwOV2WcL4qZ7yOTNgMz7TGGoGwPhzLVeZmbp90fQ6B2ShhY0+Mwmzg+HTAd4lva P93lu78XB4n5bRb8dagewsK+ZYXrh3SKEvWTJH/igqmiLeDfibITa9faQXfKOck8KmDvQPZt c5FMNeHwAleV+u4ZTTL9YkULhYBKn1T6XHKRy5/J7XrzulOQTpJ5xrtLVUJJdcNc0N9yLqgw 51FchUEoGcTfFWeQelwVlhtaan0QbF0pm8hMConMD6Agid6Pt/wtfxGJsBuLdHLEdCPK9YlF 5HpnO3QU5xypsjvp2pENvERUaQ+Kkv33lLWb0JJnhBmIMI9FlOhFiDYkvvHr3JUUnXfWToWp ryrzATARpQfDw9lFt6+VR5c5wLZgJTpo8orBxGgCoALJi3EqdE2QwSv1KNfC59Xcn3rmGDFv zt69D9D+YEhVadurYGV7U1Fxq/1e9ZD8r1yRjCBs+rsZXeKrgJOA+ZoCY61QNwUb0uskI3KW Amf56iU3CEv9LqLj2Z9L1qv5Y8D3YOy4oF7l0FjFniNaEm3ALR9JHXAxdNIqqBG2r5ev02xR 16L/d5Zf76OPasJ1XYPcRE9YL3rOe48w1HvATYdeC0WJxObOJKAS0xUMBTKgytYRFewGJ1w2 v8v4ab69CTj4icX3g66sx1p
IronPort-HdrOrdr: A9a23:/8jiZqid6vB81Ss/FsJuCNITk3BQX1F13DAbv31ZSRFFG/FwyP rCoB1L73XJYWgqM03IwerwQJVpQRvnlaKdkrNhRotKPTOW8FdAQ7sSibcKrwePJ8S6zJ8l6U 4CSdk0NDSTNykcsS+S2mDRf7kdKZu8gcaVbIzlvhRQpHRRGsRdBnBCe2Sm+yNNJTVuNN4cLt 6x98BHrz2vdTA8dcKgHEQIWODFupniiI/mSQRuPW9r1CC+yReTrJLqGRmR2RkTFxlVx605zG TDmwvloo2+rvCAzAPG3WO71eUbpDKh8KoNOCW/sLlVFtzesHfpWG2nYczAgNkBmpDg1L/tqq iPn/5vBbU315qbRBDOnfKk4Xic7N9p0Q6p9bbQuwqdnST0KQhKd/ZplMZXdADU5FEnu8w52K VX33iBv54SFh/Ymj/hjuK4IC2Cu3DE1EbKq9Rj+0B3QM8bcvtcvIYf9ERaHNMJGz/78pkuFK 1rANvH7PhbfFuGZzSB11MfieCETzA2BFOLU0ICssua33xfm2141VIRwIgakm0b/JwwRpFY76 DPM7hulrtJUsgKBJgNctspUI+yECjAUBjMOGWdLRDuE7wGIWvEr9rt7LA89IiRCe41JVsJ6e f8uX9jxB4PkhjVeLOzNbVwg2HwfFk=
X-Talos-CUID: 9a23:aq+2jGFdvtAFEqVEqmJj2hUpAOMgVEHA3SrUHXD/FUBrVJuaHAo=
X-Talos-MUID: 9a23:auxuVwWb6LjRWXHq/ATjiS1oadlh2f2RM2cSzLMI4PffDCMlbg==
X-IronPort-AV: E=Sophos;i="6.08,207,1712613600"; d="scan'208,217";a="38159643"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PGAx8kBONgRJEO+D/EAeDvne4e7IF5F7oxmOpwReHBagaJVBRXVVL4SkwyaLAE/X1CaBN9r2MX7xAbXJgUTofm3RNjs0HTs9d06tsk8Z9gIieJlarsdOZsJuUJUFvkNreZnMHisaRmvFvv2HldI1P28c24Q3bRaH5wCRv95U4YKF3PBvRJaCZSNawR7ISO2SMkfwkEd4l2cHQmZulZKaYB/KF+vF+AyF0SKCtlyJNky9SLx773eP7A5TOon96CLemTRJH1SKTa0SqYuDOVUNZCF2qQsSXx0cbcMXDipNPq/pWD5hyAk+7I1eFFN91T10X/T8y2WQaFe0SQC8DInpyg==
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=Lkq66xFVfkecwslwZUJneAyEU5LbUQww0KcscppvXuk=; b=k6QQl3buaerQdxK8nKiggJu2zJixclNb+S/zKGJgdqfZdqymgQw2L6q9UyDCFxke7TOrmvmD3yq66LdyBciBXN2UiVV8YSxleJZAm4jjrs7xXFBzRHQLm8lcqbpWJQWgvjgMLH5QFL5EDl6DjGJJF9ty5PvLwdtLWSZCrIlpp6eRYFSldnax8x4AXpTu4iOUeoIrOnUcDVALtblrVOqa8WJOD+/iKZPpO1Ku1iep09gTdc2XA4aifdXKZApfAimm2uHvNE+eIYcrniJehBUzJkepOV0wILBNw4r0oIDeNVNAA4OsKSMIC6lfC6pE3xN8+HCCiYqgU2+fShEiZUMerg==
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>, "'BRUNGARD, DEBORAH A'" <db3546@att.com>, 'Vishnu Pavan Beeram' <vishnupavan@gmail.com>
Thread-Topic: [Teas] Re: Late WGLC review of draft-ietf-teas-5g-ns-ip-mpls
Thread-Index: AQHasU0L0XOvXwCtTUK8zWT6gjnak7GyomHg
Date: Sat, 01 Jun 2024 09:08:41 +0000
Message-ID: <DU2PR02MB101604441DA3034C20A0AB09188FD2@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>
In-Reply-To: <048901dab14d$0c6bf210$2543d630$@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_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Enabled=true;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DU2PR02MB10160:EE_|DB9PR02MB6777:EE_
x-ms-office365-filtering-correlation-id: fddd4f98-b5d0-41df-3852-08dc821a6ec3
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230031|366007|1800799015|376005|38070700009;
x-microsoft-antispam-message-info: UfSc6/LSY+n2pRj6jtjJQh0wPV0L1cK7dAqTDr87RQvwnuHibZEdK3jbTQpNmrc+u3JLAB09WFoAdbIuDtbcN8NKPnTp1Ccf3NfsVih+XvUHK+/hZi0BuZrG80Jlnq90yxXxe5+TulXAMZPxFL8WsEajeWFSj9NsgTksjZg6Yvg96CQ2cPmjGl+QiWN1xIp9Mmdaf4ArOL2KO/8hD0i3ZtVs2flEvDkOKAc75f3EJu6EhABSwR6MvCPDOKmLKLD/I+fyxdbo8VMS5//Etkkh/mMIILt0F2MVBFM4704ScKlK3UluKXG7v2RkszzrC2XiVA+tqaookejUvz11ZRV3sEy0kI/Snv9i/98dpcDCwtm98z65U8YYdpo4y8F79TwnHPU4B79RvEkDIM5i51gjC0+lMgzAn2qLDdXgKaL4RNeDeFc/YLv7j+DNWVkNr52Teym0j7+y8tTK3V4AJ4p7PZXqcAIGGknDy6E89HRyi8vfz+2Eb3oyVn/eD2RG9fPsIs/xHiZB7x8qO6STfE78Fv4jtGtS1AvJO4JQmz+H66f48FL1bCK/ByVXLQ0GNppmPeDwTKLLPm1Isagp0eJL/XOaNaPiFqVsGNL8oUGNkz7JMfMS/Hrdw5xyoo9DorJ7g5tPEplwsi7uJI8B1+alaia5x4nzbjY6521GtyD6jWJpQbP+R7DASSvPmOS1j2cIZUJajVct35/fiwwQcq+NzLtRUlA2ZTotukwAx/z1bUpqgDjB8FkQK8diIOu+nd2bufS8to/ElydwWNFYiD0gT+IE8aD2O5xpq8+TxrW53wg9eSlmWnPwTQpnRPhboOTnT/dAtvArbYvq+rO3F+C/7DK1VOPs56c841bHBmmTy9X+eXFT/a2JECk0JytkdE2X862NUt2hTBeSoaS43evLRsqjBW+NxjYwEezw26a2aLqbo/csvPhdhZAUGGGB+urERw48dAux0g/lDsMopwwal4Z5PSGjhA4cPlZ1sgtLmqudHr8IhH9sH7JswvWMEHl59s+PwDCsFY/FWTIwhIsGHJgNG9mL5kWwAj7CS8LvUUHJ4mklCItAzhA3+ShltXU5xZjwCuTPLECL5icrGW7uVzb4rqND2n48NIuzAx3eeyAgnZOVuTfYOIPqws5DuzEcHOB9Vrqz/kFBL1LJcxc3quPVnMQ8YUdrYJu/Me0QEkxuz5Izd2pGZUVQJs1GGNnWC7LacUSoDvwJaxsIiGIaKy/x4ATGVZ/WUHnb+Jc3/q9u4GwW0p8UhCtV0/scEuN0ajtelpTTL0wq09dw3U7UG6A+reuZMmL29JbqjPZNoUyBlsRnnT4nXmrdiGIO4KNEKVBk0Isscds0Ug3Bh5/Uwg==
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)(366007)(1800799015)(376005)(38070700009);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: PP/RDobiw0hPCKAiGotsNCgbzFdDTsLEU8ni0TAm7aeHwKm/Y4RBkHpnMwwwr3q+cAVzFZbPlXggUP4DvjUVndfGp1WpUmCw0ZLBs1Xd9p63wXfq2FiiKM/Kzv9pu/hq1QCjgAH9hFIA32HE1QCYNPbOjbOU+mj//8n6kkUYmhRq9eKAvaHFVIef0zYehrIbGJGdNrRC1Acx3Y/nF4pl1LhippMCNq54ff56MJZYl+MSypFgLMk1fAqXomz3s9nyMnsA2UcqGqkJPEUc+hztVsaBVe4Jk8vUDAkQEwRXAfehEMvbOxHhK/e84ViPuXVVrEu5uIs/VsE8SCYh5KyZxDFMs4pZKbpMuHvP6G7Co1ZbbuGChYys7/Yx7CGVmk4Wka8fPDrejuo98N2twKHeNjtf9E9MzLoRK38vkCzeUzWiWmHFdTxXlEHAqa69ZMYq5IKjBsNQchPDglri5pWO8iIm/nFI+whTSqrtnSn2WBVGMFVxTve1S0dQ/suphm10b5vBgK+pFWn2SLee26YVIjcQMHTXG8sqIKiA4RQeT5P5HdNj7Jhf/Gyuu+VKjs6yDwMl2x9gkmyGJBkL1zrZRhNdTaODfc50O1whh0QOmKeoBcDYQ0CO1R8uwI1Vnn6nAGjbFcLHykpII3H5BzLPY8h+Oxc37Z7b649qq9SpXZxpzllfu9kf8ffGRYn5nKxk/L1JF+PF5glpwBYMW0hqOjW2GzhJh/3Qw3mTeawn7rc+D9O0KE/it8m7cD4JVW+soeWOUAxPNLoVOY81oyk8gE4k0TYIbk5uHhfcRimeZjKaKbAQdYf3vgDMI460Gd+QabR0m5Hz6dnyBRiiwM2bxV5ccBLg184shr3U5Zn37FH09CVczFceAsb/MSanWUA/yntKlIxHjzV2sj6cgzCJIhL5hgYFE2lFr4F289i/BJxkMWE6r9+CREOsWQRtTLW/0YoQ9wLGldjnCMrMweXHfiiRitdoAQPJSmHy+uuSJaQd0wPa5uVs43p8xNCblrbHNErFHeMlVsL2zINENTP1r+MrHQhjwFoAJqOkIzVaX2AK+1xaF+gJaxYEM3HlWIyaiTChVWThwSig0Bs7TXy7q0W/FYPXjEGLecFwZiUxePxeEmv4Jy33fas+Hi3r3AykNFCtQHmX8N4Ul+/FsvgzHKsJ3PTDgox+ccarzfzHFmdTHJzuo8NjZEZzXsyZxK3+eOb6GMhkk+OqGZTBdhA0UjoaJtTqv5uIwFLJG7NoH927AsJzeCzjlg5hwPjiyE7MoW8+MWfzGbOmRfpQB7tuF4vurc5Z01Nymokrnjmj5c3+PggzWdIf2QMBcBPnYjKaCBKgioqRWKZRATpF7t4byOBlgsYdaMXS2c9YG0/jeUq1QV88zFc2USIqzumcL57W7quFFoYL/sYEucHtwIVAYQ0fHcjOR+9Ctmhhq9wX5IBQkpb8qjwgL6Yms5/SzfPyrjVRfvBdUe55mLTq0avVqzjtqMt/17rfUXl2KSgspLMGvVC+V8e8ZpuqAbNrawdNbo3Q5dEcRYD5MM83+UmYSRpyZ7+buSMj2FCtZE2N1JmN8d6dvvOotjS3NQuIQfZvX8l+3YjtU790XWBFOb0Isg==
Content-Type: multipart/alternative; boundary="_000_DU2PR02MB101604441DA3034C20A0AB09188FD2DU2PR02MB10160eu_"
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: fddd4f98-b5d0-41df-3852-08dc821a6ec3
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jun 2024 09:08:41.8753 (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: VSiqFdS6IjQLJdvmbnOieBVvaiCs/Hn1S30vSHMC+Pkp6Dzc4jtuX7ZZ/uFZnTWtVuIVFmk9GQ+gNqmCSu3ubNiffEybdPKLZ1uSvcqqv5Y=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR02MB6777
X-TM-AS-ERS: 10.106.160.157-127.5.254.253
X-TM-AS-SMTP: 1.0 c210cC1vdXQzNjUub3JhbmdlLmNvbQ== bW9oYW1lZC5ib3VjYWRhaXJAb 3JhbmdlLmNvbQ==
X-TMASE-Version: DDEI-5.1-9.1.1004-28422.006
X-TMASE-Result: 10--27.371300-10.000000
X-TMASE-MatchedRID: MZa17WpznP2N/VCJeShKRinzXaIxFTM0IBYc5Hfv4BM2LwvzxRX0gDXS EULATMS5W1RFmDf+CHag5Q2VG3/2WW793anBBL+UzgKfR9SIm4LcgUVP3Cp+vV/d6ediod7YotW BuRnEzk/csW7KpRHwbKiOPqwaeyvpiJK2aPCF0yLhrOTaYpdZr05GBIYERk6jNOj61NGLnAS3CL dtdG1oCKQxA9genngP+vzk1TUiYYCyhULMnkO9t0VJQsZtdu5E+ScJ/ljmM9jcAmu1xqeethS1r 4tCARkwJltTQcLEkIftre/B3twRSfYIg98oGEX0FieXZM/KiAPXA3LnlKuVLIuRyFOzTWE71D7m CyxRilypuz6cn+0UkRiZsVhauLEnL1TPc5DmUyUowuP6OxDI7+zeg/MzrtVRQ/2UjISFQXD0dP0 XTSpbgC1sQGcqD7Ut8+iALoPLzwW1C6HiJK7eCKML3v3DWTsMC8FMH3T6F76W0X7Fb7OFSMGx/m q3jiNnEANTSZ3u3Xj5JJqpHpLxNJu1qFd33lXE8dwmOgekSc9f2SdIdby5dTM2xdYG8ZUGMwzrs NAhWRJQCsmfAegbdLK0kaZj7gujWFNXQvEi/t6jomB1PQ7kfThk1eHxQ+sgPQ6XWceR2mWiQV26 LvNlR9nfJrUSEbFDpvoY426cSIvDdsHhOxgJmR6I6ugYAnp0lu85dvadcXUlHt1HverPrtM4cBk OddRu9K75ct/rW8d5W3eKNoJwKmsi8HNARoQ1tbbcVZH5JvaoxQNkk1aPuFIeMHlj6jlk592Swr d60UmjKxc+OwTS6iSD5cp688JB8pGH6AokuO9vpjpelqMuR3QFOo7t77YIfS0Ip2eEHny8eR0+G c2mPyE95pUwcexM4wnhOb+JR+TqChA6lSRJvtLvsKjhs0ldAwbp95MuMCBjZH4Wf5mJvasQd9qP XhnJ/4rWvpj9UcgD/dHyT/Xh7Q==
X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0
X-TMASE-INERTIA: 0-0;;;;
X-TMASE-XGENCLOUD: 3124bb11-43ab-4858-8ea5-b3a68dd3e1f6-0-0-200-0
Message-ID-Hash: X7K7G4KADGNW7WJ5WUIGXFIBRETNZ737
X-Message-ID-Hash: X7K7G4KADGNW7WJ5WUIGXFIBRETNZ737
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: 'Krzysztof Szarkowicz' <kszarkowicz@juniper.net>, 'TEAS WG' <teas@ietf.org>, 'TEAS WG Chairs' <teas-chairs@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: 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/Nw4GFRyDdTplZrCV5hozr7kPgdU>
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,

==

[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…
==

Many change are made in -08 with this comment in mind. Also, merged some section and moved some details to other parts of the text, group scalability in one single place, etc.

Aaah, also changed almost all the figures as idnits was not happy despite we were using unicode (900 warnings!!). Managed to have all these fixed but idnits still show two warnings, but we can’t change Éric and Rüdiger names :-)

Your feedback on the content organization is appreciated. Thanks.

Cheers,
Med

De : Adrian Farrel <adrian@olddog.co.uk>
Envoyé : mercredi 29 mai 2024 00:19
À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com>; 'BRUNGARD, DEBORAH A' <db3546@att.com>; 'Vishnu Pavan Beeram' <vishnupavan@gmail.com>
Cc : 'Krzysztof Szarkowicz' <kszarkowicz@juniper.net>; 'TEAS WG' <teas@ietf.org>; 'TEAS WG Chairs' <teas-chairs@ietf.org>; 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.