Return-Path: 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 5A74DC180B63; Mon, 30 Sep 2024 05:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.804 X-Spam-Level: X-Spam-Status: No, score=-2.804 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=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_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 8PSfdfeuJxxU; Mon, 30 Sep 2024 05:48:42 -0700 (PDT) Received: from smtp-out.orange.com (smtp-out.orange.com [80.12.126.237]) (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 4D81FC14F749; Mon, 30 Sep 2024 05:48:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; i=@orange.com; q=dns/txt; s=orange002; t=1727700522; x=1759236522; h=to:cc:subject:date:message-id:references:in-reply-to: mime-version:from; bh=su8id2aG9uQwwa5E9oiT97cwAoLe+zLM2rIr0+qQBac=; b=Jf2p8r2ezqQNL9F07PPIw6va6tiGhlwgmtwzkUsBTjc7Qd6KvnDd8KH5 0PvFCqYeVG3/l1ZJeuZ8TGXAT6z9Kpd7EMERSSnYI06o72o2tzx9LNBTP VbKTGzoZsfwpOeBnryBni4IJ1V6Jr6gIntsm1pGEVUPx/J0QZWJa0qpJZ Ks+a9rBDq98IE+8m5js3DlPL3qMGO9omD3nYWon1FLM5VJ1RkI4pswB2m 8iQMbrxS/Aq6JyLjFlqpVNR0H+BZAPD5GiyGb89eMEPolzTy90lUQnvmS wBdqAtw42/esxEZMTWhq1h1feB6qqgUKPc0icZDHhHToSKOSrAWCeILFf g==; Received: from unknown (HELO opfedv3rlp0g.nor.fr.ftgroup) ([x.x.x.x]) by smtp-out.orange.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Sep 2024 14:48:40 +0200 Received: from unknown (HELO opzinddimail5.si.fr.intraorange) ([x.x.x.x]) by opfedv3rlp0g.nor.fr.ftgroup with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Sep 2024 14:48:39 +0200 Received: from opzinddimail5.si.fr.intraorange (unknown [127.0.0.1]) by DDEI (Postfix) with SMTP id F28E41063A70; Mon, 30 Sep 2024 14:48:38 +0200 (CEST) Received: from opzinddimail5.si.fr.intraorange (unknown [127.0.0.1]) by DDEI (Postfix) with ESMTP id B5D8F1067089; Mon, 30 Sep 2024 14:48:10 +0200 (CEST) Received: from smtp-out365.orange.com (unknown [x.x.x.x]) by opzinddimail5.si.fr.intraorange (Postfix) with ESMTPS; Mon, 30 Sep 2024 14:48:10 +0200 (CEST) Received: from mail-northeuropeazlp17012029.outbound.protection.outlook.com (HELO DU2PR03CU002.outbound.protection.outlook.com) ([40.93.64.29]) by smtp-out365.orange.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Sep 2024 14:48:09 +0200 Received: from DU2PR02MB10160.eurprd02.prod.outlook.com (2603:10a6:10:49b::6) by AS8PR02MB9649.eurprd02.prod.outlook.com (2603:10a6:20b:5a8::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8005.26; Mon, 30 Sep 2024 12:48:07 +0000 Received: from DU2PR02MB10160.eurprd02.prod.outlook.com ([fe80::c9a1:d43c:e7c6:dce1]) by DU2PR02MB10160.eurprd02.prod.outlook.com ([fe80::c9a1:d43c:e7c6:dce1%4]) with mapi id 15.20.8005.024; Mon, 30 Sep 2024 12:48:07 +0000 From: mohamed.boucadair@orange.com X-TM-AS-ERS: 10.106.160.156-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@DU2PR03CU002.outbound.protection.outlook.com Received-SPF: Fail (smtp-in365b.orange.com: domain of mohamed.boucadair@orange.com does not designate 40.93.64.29 as permitted sender) identity=mailfrom; client-ip=40.93.64.29; 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@DU2PR03CU002.outbound.protection.outlook.com designates 40.93.64.29 as permitted sender) identity=helo; client-ip=40.93.64.29; receiver=smtp-in365b.orange.com; envelope-from="mohamed.boucadair@orange.com"; x-sender="postmaster@DU2PR03CU002.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:XqtblaCdZAkErBVW/1fkw5YqxClBgxIJ4kV8jS/XYbTApDwh0mZWm 2JOCG2EPfbeMWSgc48gad60oEwHuJPdztBmTANkpHpgcSlH+JHPbTi7wuYcHM8wwunrFh8PA xA2M4GYRCwMZiaA4E3ra9ANlFEkvYmQXL3wFeXYDS54QA5gWU8JhAlq8wIDqtYAbeORXUXU4 Lsen+WFYAX5g28vajpPg06+gEgHUMra6WpwUmMWNagjUG/2zxE9EJ8ZLKetGHr0KqE88jmSH rurIBmRpws1zj91Yj+Xuu+Tnn4iG9Y+CTOzZk9+AMBOtPTgShsaic7XPNJEAateZq7gc9pZk L2hvrToIesl0zGldOk1C3Fl/y9C0aJu6aX3L3u6svWp3Q7LeDjowNpSCWg0MthNkgp3KTkmG f0wBA1XVirb3MmLmOrhDO5xms4kMc/nepsFvW1txi3YCvBgRo3fR6LN5plT2zJYasJmQa6YN pFfN2YpNkWojx5nYj/7DLo7m+ehg3TzNTdftVmcqaM2+UDU1gV337WrO93QEjCPbZgPzxfD/ D+fl4j/Kk0hCPfY7hPay3jy3MX2m3rQW5BKRZTto5aGh3XInTZPV3X6T2CTqPWji0e4c9VbJ 0AT9Wwlqu4v9ySDUtT0RDW5rWKK+BkGVLJ4D+Az80SGyqPV+R2xB2UYQHhGctNOiSMtbTkj1 1vMmdTzGTxiraeSUX+U5LOM9GzqYHJNdz5EYjIYRwwY5dWluJs0kh/EUtdkFuiyk8HxHjbzh TuNqUDSmon/k+YazZW1/lXEugi+5ZXCDQo2yTnSd2Cqu1YRiJGeW6Sk7l3S7PBlJYmfT0Wcs HVspyR4xLBTZX1qvHzcKNjhDI2UC+C53Cr0oHMHInXM3zGk+nrme4dK/DFzOV1uKssNazvxO RCL4FkJvs4VO2a2Z6hqZY73E94t0aXrCdXiULbTc8ZKZZ9yMgSA+UmChHJ8PUiyzSDAcolmY /93lPpA615HUMyLKxLrGY8gPUcDnHxW+I8qbcmTI+6b+bSffmWJbrwOLUGDaOs0hIvd/1+Kr Y0DaJLSlkoEOAEbXsUx2d5NRbztBShqba0aV+QJLb7ZSuabMD1/VKOKketxE2Cbt/kFxr+Sp hlRpXO0OHKk3iebdm1mm1hmabj1Wo14o25zNis2JT6VN4sLMO6SAFMkX8JvJ9EPrbU7pdYtF qVtU5vaXpxnFG+ckxxDNsaVkWCXXEny7e54F3D6PGFXkl8Jb1Ghx+IIiSOzqHhQV3Dp6JFWT n/J/lqzfKfvjj9KVK7+AM9DBXvo1ZTBsIqennckI+W/vG3AzdJSEXSqpcJve5tKLgjfzDyH0 QrQGQ0fueTGv44y9p/OmLyAqICqVeB5GyK22kHFuK2uO3CyEnWLmOd9vCSgJVgxl18YPI2lf +xTwPy6O/oC9LqPm5QpCK5llMrS+POzz4JnItxYIUj2 IronPort-HdrOrdr: A9a23:BFugM6M1/b5j3MBcT0r155DYdb4zR+YMi2TDiHoddfUFSKalfp 6V98jzjSWE8Ar4WBkb+exoS5PwOk80lKQFqbX5Uo3SODUO1FHHEGgm1/qa/9SCIVy0ygc+79 YGT0EWMrSZYTdHZITBkW+F+r0bsbq6GdWT9ILjJgBWPGNXgs9bjjtRO0K+KAlbVQNGDZ02GN 63/cxcvQetfnwRc4CSGmQFd/KrnayHqLvWJTo9QzI34giHij2lrJTgFQKD4xsYWzRThZ8/7G n+lRDj7KnLiYD29vac7R6d031loqqh9jJxPr3NtiHTEESutu+cXvUuZ1RFhkF2nAjg0idurD CGmWZbAy060QKtQojym2qm5+Co6kdQ15fvpGXo/UfLsIj3Qik3BNFGgp8cehzF61A4tNU5y6 5T2XmF3qAnei8osR6NkuQgbSsa4nacsD4ni6oennZfWYwRZPtYqpEe5lpcFNMFEDjh4I4qHe FyBIWEjcwmOG+yfjTcpC1i0dasVnM8ElOPRVUDoNWc13xTkGpix0UVycQDljML9Y47SZND++ PYW54Y4o1mX4sTd+ZwFe0BScy4BijERg/NKnubJRD9GKQOKxv22uzKCXUOlZKXkbAzvesPcc 76IS1lXEYJCjPTNfE= X-Talos-CUID: 9a23:4N/zjG1BVd1ZYOLIk9kbirxfC9oVfH7Yz07qMQy1AiVtS5KpTHaS9/Yx X-Talos-MUID: 9a23:JqbTgwa8XWBCSuBT6wTQr3ZFHZhR6fr0InkLyL4FqZHVHHkl X-IronPort-AV: E=Sophos;i="6.11,165,1725314400"; d="scan'208,217";a="52993251" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=AuhUIsFMmZEjtQylDU8ZPE/6sbyRMnGAdN0r6o3n9vpO1dspBDD1BtfSBHyz+uncb5dxGlp+eaQxovHyuy+jyp5JH0XFVXWj1EmMBhSEtPGaNlkP/J+oDFEj73F07kuRD9ngjbeBOaVLs6gy4BmvplF9sw7rD+tlZv7IUbFhxN80SNUphalKfJrUPConLPHnZ2M7I6GSbnUyVnTKph5U7p9SEcucYfIceYJzuZ01XsfxvyeasJ2q9Ra2B4G8wLdKTKpphbpGAdgI4t81qdegUjgGrT3bUfUyZKTRm6G2ZFnA73NYwZ0zJ2pZbqI/WmV3dBTCyKIDS4++HrBnI7hK9A== 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=kXZrZZuhC9vm+PSsR+QPj52iWrfFq+ZMvOZfI/TH54I=; b=M0b1qzr2CLrd1CGXejyGE3o6paELdwXTP69P/ooXinjKw6z+QEB2os2oI9IN7h89vcQ0I1fbtBvWFXcUZYfkM5pJNaMBzsxbpu4VgBRkr8wrK8tXpEKPRVebV2aNBivezxcTqbfhdQC1QJppxy4DW07RMxhoqADBZnQWFwX0XdRHJz/nzt7R2mOo+jlur+TtJHAXlm86YSrn2WT9KP27HyEm8bmlSkaBFuh9DXuPHUfwqQLE6zwO5fZkoTC5WVmYMJ+D+bvBUbwKjQFhKzOQ6blIMBaP3VCB79fV7145KBvhPbgBuDjRsPAiuuP2f3eaGQmiQQRFR9Fe9p4jxgB8gQ== 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" , 'TEAS WG' Thread-Topic: Last-gasp review of draft-ietf-teas-5g-ns-ip-mpls-11 Thread-Index: AdsRE3o1jfC8jLYsRYKw1pX5vQN/ywCFwivQ Date: Mon, 30 Sep 2024 12:48:07 +0000 Message-ID: References: <762136658.2244950.1727166111240@www.getmymail.co.uk> <01fb01db1113$8304c3e0$890e4ba0$@olddog.co.uk> In-Reply-To: <01fb01db1113$8304c3e0$890e4ba0$@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=d2f44bdb-3ff2-4d60-937c-7519feafe4ec;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-09-30T12:47:19Z;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_|AS8PR02MB9649:EE_ x-ms-office365-filtering-correlation-id: d144dde2-8b22-41be-4969-08dce14e21e9 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|366016|4022899009|376014|1800799024|38070700018; x-microsoft-antispam-message-info: =?iso-8859-1?Q?iXUpMRKfx7CbFfZxpov6P4hAYU7Z6xL7XDzv/vqnf8I8GEo0THlZpb44+s?= =?iso-8859-1?Q?SqQ/ZaxMZCKD4OT59+4eCk++FjxsKfXZlzIZmWlXU1N+pzV617RM37uvqo?= =?iso-8859-1?Q?6smKsBQ7b7nX2SiRSe23/8ZtFvbVKDO2t+1tMtUHh5n71+vahomcMHg/mb?= =?iso-8859-1?Q?h5Sgfy857mW6xKVN3sjAnrmusD/jfKVyuFmyPvyh3ou2mCK7rWZZb5BNau?= =?iso-8859-1?Q?ENY48sjJuz/vqvgWTPyhkTX5TwgCEHvoEFqqMrZuJuW+Kt44Ry4oloucVj?= =?iso-8859-1?Q?PYMsvme/8DrzCnSL0Cy9wMZLUVth7xdrY9WaetzzqSO+ofmOpvRTieg6x+?= =?iso-8859-1?Q?o7e8coh9+sr1u5ub+v1cAs87QwQ4slBjnHJbjX6gIdRuTM52barrR7IffE?= =?iso-8859-1?Q?PGQp6jiZs3OGOa3v8+yjuWfUbanksSJ0p4St9uXm4z/Qvf9OvVGcpZ42nA?= =?iso-8859-1?Q?i0ryNuWoYwa5TnJNsdiAwWr7wm/ffZGo0G0HO6aKrGIRjiJByZQaBvFy3e?= =?iso-8859-1?Q?8BC0MGstBcVEPPRWpEuKJzOz9fmHgPE6+qUWV4WXeZwvy/NFwrqugqCxn0?= =?iso-8859-1?Q?s8uOn1X96JriXHL55rtg5pPeMitMlgHQrcSaVePazMnE3EKhwoUgBhjaYl?= =?iso-8859-1?Q?0rmTjy31MmPz++/J5Cgll61o9gfiCzNlPSqpUDrd6/bD0h0MPvICaVLY3G?= =?iso-8859-1?Q?x33wThp1tishC70w7P18phYA54YRYxHz3eQrTZVN73iqQZHlpDfjMPGq+d?= =?iso-8859-1?Q?h8jvIvuxRZy/Gwdq/l+HXd1oCDmebZk+RUBZBXP79yk+8CBSJlpGo29Rn5?= =?iso-8859-1?Q?bhU/Lp1uUkWK2vNFpIrg0M2LFrEIOBLOX9jxqWwVyHoxOA0YwX9kDK2E+G?= =?iso-8859-1?Q?NSuKhowhbCvTrD2yiZm9MkpTswzsAbAdxx9xj7MhuGezBzsCaInDQbu5P+?= =?iso-8859-1?Q?JGuNRj3LXrCzSlr3CkH1fFNArmy50IWyE/+p1rRwbeobMFl/1SolpwrUAE?= =?iso-8859-1?Q?f+saSA9dEyeTKTIw6Sf6e5ANX8Sk/dmRHmEkuP6hVsHrcQM9uURhQsPpz9?= =?iso-8859-1?Q?G4x7AsCPqMEQqTz+sj/CrQDh82/UX/LXi+XpqgO2q7uuYSeMkZTzKEDHF0?= =?iso-8859-1?Q?nBLHmLxsQ9nWrSp7W8NNnGc1ozPVMNIRmtngcLmZav6dpIWs5/2w+4XrB7?= =?iso-8859-1?Q?BgJpKS0SmyHU4b4nAqbQlxy9WyXmxL1zRKqJ5DU0Jkk96C2dQ7jwtcrqTC?= =?iso-8859-1?Q?tgfsvcIP1rh3GVPWvcOZhnmhNc7roYehAQYrw+JllUV9GUQK1NZSW1PReY?= =?iso-8859-1?Q?CFq4Rj39A2OGB8nS/LGx084aF4WV3h+SefeqMU7lCwkUNG8kjGF0YRuy7i?= =?iso-8859-1?Q?5YNVtus2gPKJGftlUlLFxO39w0VRQlUCJj5utP4927gL/jmrlNcbc=3D?= 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:(13230040)(366016)(4022899009)(376014)(1800799024)(38070700018);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?TDV5u0zXrqrFF8VQvCpAruXRCXg3k+t1IVoJLU9EBhJfe4Cff3KwJz3T0a?= =?iso-8859-1?Q?cqnqWwSPfANUp7bz1PYJXyHoeomjZJTutkJVXuD0C4XKy+iCw1ZkBaHDU6?= =?iso-8859-1?Q?dvEt0pwq38pbcYHoPhdYbCs5hVC7zpHlmCZ+BWZu15LgMjkFuGzqlS/07U?= =?iso-8859-1?Q?jGkrYykdSuKjBIbYeC6SA/EzCPPpTotwpUtqiy4BvULc2/i04kHfota2o+?= =?iso-8859-1?Q?Qh++umZpv2FjbEgH2Lbtplku8txUfcLvXgocYT36miJ9FNY6Rcnbj/2O3G?= =?iso-8859-1?Q?RwRa7XiafxGKJPmzVLlAYZzcgzbG02z3pVkgDIUl0DYJtzpcCK3Og5pKSR?= =?iso-8859-1?Q?hlLKch7GwGH2F6lL9II2AziNDGq5w4xvcG2B7KmrePao0/lIBKbTXuhMVC?= =?iso-8859-1?Q?sjkfdVHOtrlrauwA9uq+zJ9uYFHhvmwmEauNPtQVluoXCfmQZt2VWTb2L8?= =?iso-8859-1?Q?xo6PAa+pbIuDZcbumwZUpeAfmNEmj98JYAdbLT8qB5CR98mSEvTsVSqFbj?= =?iso-8859-1?Q?H9Al9eYdCjAkHFuMvnxt49SpB+abieZBy9NUc8uKzNU6D+YU8Ehi4pUPK5?= =?iso-8859-1?Q?K3I3DzvXFW5bC49KycPINXO3L2BhkSwCpOrNFqn/KrgWWvpB1yQMQbh5J4?= =?iso-8859-1?Q?HaxzAPFxUP4CmFfucOO8pctOThMXyEJNn8m+wzA+k+VfiSRn69+i8o8PQy?= =?iso-8859-1?Q?Mis83bEMaD6hmN8mWT0ISQuZjpnoft2aFas7O1YNVuE9PKxxX7g2/8HknG?= =?iso-8859-1?Q?9GEmzECIjB5iDdlO22nVRzgk5TEBZJaFeyMCNCoji7t85PcpWlvtcujG2s?= =?iso-8859-1?Q?DP94AH2YiMvwWLJ+1FxRtB3yv8FYH912JWBAX1rq1+Xh9RtBGjgOeDJ+CH?= =?iso-8859-1?Q?qNfjSZC9gv8d12iEeaGsIDZDkIxQBxd32/F+PQM9INsYg961g8Zb+1WqnR?= =?iso-8859-1?Q?GdZ+rCHfSPmow6MMsYXpI0wYlsATZbaktahOCzt7X7Bhb0lpV0xrBw7vi8?= =?iso-8859-1?Q?mjIoTcB7Xe9GG7r0DuTD+Wbga276S9iCE+x/owwk9XWg0IEvhNbvpoL4Jr?= =?iso-8859-1?Q?PfUUU5NKiKXKT4AlEzLGfkSzKTNxj22Y7t59ynNw12eAeDYrDQV1vZlHmr?= =?iso-8859-1?Q?e4BNv4kEzHkQ9f7xg9qF+piUVOp3MU6GwGDD9fpMRizgL9R8Z60/lrw5Vi?= =?iso-8859-1?Q?0lmpqUb6tFLJ1a7uq+WCqVpuAQuL4fCCxc/8B1INaoGIqnUA1mJJCWt/U8?= =?iso-8859-1?Q?/EaJH6BYsA2Ip0SLSvpXph+DLtsGtrEgjSjB0bFEMSEM00gNeYuqCylhzc?= =?iso-8859-1?Q?bPKhHgWZUOfJ/k5D3rksoYrMw0ytJEQZiPgdT8v+x7SYke0YIm57r/Nwy+?= =?iso-8859-1?Q?zIgTgrB0HljWpmMRtoXroTvQ8cx9tFIiVZqn8Xlbq6iJQPWhSFFLVC4/Yp?= =?iso-8859-1?Q?ZuNrKNUDaMJ1xzApOsYqoXzVabMxCkj8KZ5UJG1VbZ7Qdh0LkjfiFLk0kY?= =?iso-8859-1?Q?e3buQ9FeNa1eW7ItjYwq+L8NWrWjSXue2Apnh+jqaZAvwrAjJJTz5qWVV0?= =?iso-8859-1?Q?N7s5F6qXZR+z6JWGPq28NvY8H8IBux12PYZUIAWLvKari8YxmLV1tPZx1c?= =?iso-8859-1?Q?ydFG4VZI+XVnyTJgGnWX7/gPQTY+ZbyzTb?= Content-Type: multipart/alternative; boundary="_000_DU2PR02MB10160A2A5E534936FF8058E8688762DU2PR02MB10160eu_" 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: d144dde2-8b22-41be-4969-08dce14e21e9 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Sep 2024 12:48:07.2329 (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: y3w7J/Mw5+WBj4UC9z4IzcLVPPAIXlhqRUY2JnwKrNMSnESO8mva1bPfLfGLLlAAv9du8FuS1btDbgPMGUb4NsROH5djwnO1XzxGFjq6BXY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR02MB9649 X-TM-AS-ERS: 10.106.160.156-127.5.254.253 X-TM-AS-SMTP: 1.0 c210cC1vdXQzNjUub3JhbmdlLmNvbQ== bW9oYW1lZC5ib3VjYWRhaXJAb 3JhbmdlLmNvbQ== X-TMASE-Version: DDEI-5.1-9.1.1004-28696.007 X-TMASE-Result: 10--36.291300-10.000000 X-TMASE-MatchedRID: Xm7QFS8qA6HuYusHgJkgytDU27zito43DSG7dmYh9bp2GEtCHQRZOwQH 2LJn+s4Vd5faCK0bsuZh44VlLBLudJ1U1lojafr/C8LXg/kJ8lD3BP7K61/1O5TrbO9zUOWjwue oFTy9Eepa4fTB5ncLxCsZmX5ai46JK0+leiJxLle0ST8SlWWay282zvsXichaSZv++M/7CuHxej c0penKFy8YkquNwmMVpQQPE715bCp9v8t4yaa1EJGAt645FF0S1EZ/lznv4UULHGEtxwjZ/7Qsz BevfBjD0nz07SeMUn7/R1NSMc2qCeLdprnA5EQRSOZtBHQ3LLy15eNIExieaVxUx6Nc3kkv84H0 QJCUuBvlZK+3BWyIvdbrDrhTWGHO7LuOEAY9BqTZobCTg4s1LJnpTtCGSpGeS2yxGRKp+k1k+mJ MoefoMAiPMvT9S9ITNbRcxKRsTiBrzsINdopFUkRteKKUSTHxVI7KaIl9NhdhHPAhgPubT10EtL M2oIeD1XjzVVuNMkTGeamlItyGaGN5V59dR3bU2FA7wK9mP9eBAXl9LkPp6V4GGHdq7rdY826zz bAxDy80qKRIx55mieWQ0Aaj99laBAFJPqqEKzeOQOsE4nDCdG1/OiWPM9c7wdI6SjRoEivrnq9c C5+YG7ARVFU/gJWsjw3U5Sr2Lsg3aaCJEqlvK3hKwaDYNA5iIiqlmO0FgHuqB2Ej9kXDtO1RrY7 vFdg3D11IV/+bi3bKUTgRuW9R6ScK0wQEhQduj8dEujPr2myj93WwqxIooKm7Ppyf7RSRCmvini liH8ro6Lh9xw9gS9Zx0BKWTuVW0e7jfBjhB8dKHhaQPPG6/o5hyiW8kJaQiJtHLSORchni8zVgX oAltl1qiWE8TdgDXzAzb4Z7JOsURSScn+QSXmNn8XPiALIbRTPcgmZKtSDHcBriiJvLGd934/rD AK3zGjFMngtLLWhJFQD69E10vA== X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0 X-TMASE-INERTIA: 0-0;;;; X-TMASE-XGENCLOUD: 8b4ad738-59c2-4c42-885b-17fb87d2d19e-0-0-200-0 Message-ID-Hash: CISNYCKGTUDTGPTCGE6VH5DYTBYCXCOU X-Message-ID-Hash: CISNYCKGTUDTGPTCGE6VH5DYTBYCXCOU 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 Chairs' X-Mailman-Version: 3.3.9rc4 Precedence: list Subject: =?utf-8?q?=5BTeas=5D_Re=3A_Last-gasp_review_of_draft-ietf-teas-5g-ns-ip-mpls?= =?utf-8?q?-11?= List-Id: Traffic Engineering Architecture and Signaling working group discussion list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --_000_DU2PR02MB10160A2A5E534936FF8058E8688762DU2PR02MB10160eu_ Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi Adrian, Thank you for the careful review. A diff to track the changes made so far can be seen here: https://author-to= ols.ietf.org/api/iddiff?doc_1=3Ddraft-ietf-teas-5g-ns-ip-mpls&url_2=3Dhttps= ://boucadair.github.io/5g-slice-realization/draft-ietf-teas-5g-ns-ip-mpls.t= xt. Please see inline. Cheers, Med De : Adrian Farrel Envoy=E9 : vendredi 27 septembre 2024 21:29 =C0 : BOUCADAIR Mohamed INNOV/NET ; 'TEAS WG'= Cc : 'TEAS WG Chairs' Objet : Last-gasp review of draft-ietf-teas-5g-ns-ip-mpls-11 Hi, Here (finally) is my additional review of this draft. Sorry to have taken a few additional days. Other than the comments (arising from Jie's review), I have only found a small points and a couple of nits. Not sure whether I should have spotted these in previous reviews. If so, sorry. Thanks for all the work. Cheers, Adrian =3D=3D=3D idnits shows " Unused Reference: 'TR-GSTR-TN5G' " [Med] Argh. Fixed. Thanks. --- Section 2, having said the document makes use of the terms defined in RFC 9543, proceeds to provide a new definition of "customer" and "provider". I wonder whether those new definitions are necessary, and if they are I think great care is needed to achieve disambiguation. [Med] Section 2 also says right after the ref to 9543: "See Section 3.3 for= the contextualization of some of these terms." We used to have "customer" and "provider" entries be part of 3.3 but we mov= ed them here because we received a comment to group all defs. --- In Section 3.1, piping ("|") is used to indicated quoted text from 3GGPP documents. That's good. But: - It is probably de trop to use quotation marks as well. [Med] "" were used to ease demux the quotation from the source. - It appears as though the reference is part of the quote. [Med] moved the source refs to be positioned before the citation and remove= d the redundant "". --- 3.2.1 Ditto the use of | and " [Med] Fixed. --- 3.2.2 I don't object to one word of the text in 3.2.2. I do find it peculiar that, while 3.2.1 is nicely quoted from 3GPP documentation, the text in this section is longer and un-cited. I should imagine that the paragraph... The objective of Transport Network Slicing is ...should be founded in a 3GPP definition. [Med] We can't formally cite any reference here where the exact words are u= sed. The definition inspires from 3GPP docs, especially from the following: "When providing an end to end communication service, the network may use no= n-3GPP parts (e.g. Data centre network (DCN), Transport network (TN)) in ad= dition to the network components defined in 3GPP. Therefore, in order to en= sure the performance of a communication service according to the business r= equirements, the 3GPP management system has to coordinate with the manageme= nt systems of the non-3GPP parts (e.g., MANO system) when preparing a netwo= rk slice for this service. This coordination may include obtaining capabili= ties of the non-3GPP parts and providing the slice specific requirements an= d other requirements on the non-3GPP parts. Figure 4.7.1 illustrates an exa= mple for the coordination with management of TN part (e.g., directly or via= MANO system)." + (extract of TN specific objectives) "The network slice related requirements include requirements such as: area = traffic capacity, charging, coverage area, degree of isolation, end-to-end = latency, mobility, overall user density, priority, service availability, se= rvice reliability, UE speed." While the first half of the paragraph... Transport Network Slicing provides various degrees of sharing of resources between slices ...presumably stems from 9543 [Med] We can cite Section 8 of 9543. The rest of the text is explanatory in the context of this document (and maybe should say so). [Med] Added the following NEW: "The following further elaborates on how Transport Network Slicing is defined in the context of this document." --- Slice scopes and SDP locations. It is all really confusing to me, and I do not arrive at anything other than contradictions from the text :-( Figure 1 shows the TN slice and also shows the type 3 and type 4 SDP locations. [Med] These SDPs for "RFC 9543 Network Slice", not the full TN slice. We ha= ve the following in the introduction: Specifically, this document describes an approach to how RFC 9543 Network Slices are realized within provider networks and how such slices are stitched to Transport Network resources in a customer site in the context of Transport Network Slices (Figure 1). Concretely, the realization of an RFC 9543 Network Slice (i.e., connectivity with performance commitments) involves the provider network and partially the AC (the PE-side of the AC). This document assumes that the customer site infrastructure is over-provisioned and involves short distances (low latency) where basic QoS/scheduling logic is sufficient to comply with the Service Level Objectives (SLOs). But, an SDP is the point at which the slice service begins or ends. It is the edge of the slice. Either: - You are saying that a transport slice does not map perfectly to an IETF slice Or: - There is something wrong with this and the text in 3.4.2. I don't think any of this changes any of the technical details or practicalities of the solutions described. It just that the description seems plain wrong. For example, where you talk about mapping service parameters: where is that mapping performed? The question, I suppose is, are you constructing a TN slice that encompasses network resources that are both IETF and non-IETF. In that case, the service parameters are mapped at the edge of the TN slice, and then they are mapped again at the network boundary at the start of the IETF technology. If your intention is that the TN slice is constructed from elements of the customer domain (possibly non-IETF) and the provider domain (IETF), that would be fine, but I think the TN slice end points are still the SDPs. If, conversely, you are saying that the TN slice is a composite of customer domain slice and IETF slice, then you have the SDPs correctly placed, but you have not made this composite clear. [Med] 3.4.1 says: A TN slice relies upon resources that can involve both the provider and customer TN domains. More details are provided in Section 3.4.2. A TN slice might be considered as a variant of horizontal composition of Network Slices mentioned in Appendix A.6 of [RFC9543]. [Med] Updated 3.4.2 to remind that this is about 9543 network slice deploym= ents. It does not help that 3.4.2 goes on to say: The concept of distributed PE (Section 3.3.4) assimilates CE-based SDPs defined in Section 5.2 of [RFC9543] (i.e., Types 1 and 2) as SDP Type 3 or 4 in this document. The problem is not with the text, but with the fact that your Figure 6 shows the TN slice extending to the CEs in a model where the CEs are distinct from the PEs. (To me it seems that you are doing types 1 and 2 in this document with the case of distributed PE assimilating types 3 and 4.) I start to run into some of this again in Section 4. For example, in 4.1 In this option, the RFC 9543 Network Slice, fulfilling connectivity requirements between NFs that belong to a 5G slice, is represented at an SDP by a VLAN ID (or double VLAN IDs, commonly known as QinQ), as depicted in Figure 12. That suggests to me that the model in your head is that the VLAN ID is indicative of either: - onto which IETF slice the SDP should place the traffic (the traffic is at that stage not yet sliced only marked for slicing) or: - on which IETF slice the traffic is flowing (the traffic has already been sliced and the SDP is actually at the end of the TN slice). To complete my whining about this, 4.2 shows the "tunnels representing slices" as extending all the way to the NFs (CEs not marked). Surely, in that case, the SDP is at the end of the tunnel? I'd be quite happy with either or any approach. I just want the description to match. --- 3.6 At the time of writing (2024), Section 6.1.2 of [NG.113] specifies Well... NG.113 is a dated reference. Doesn't that mean that you can simply say Section 6.1.2 of [NG.113] specifies While it is true that 3GGP's "5GS Roaming Guidelines" may change over time. The referenced Version 4 dated 2021 will not change. [Med] Fixed. --- 3.7 s/of [RFC9522])./of [RFC9522]./ [Med] Fixed. Thanks. --- Figure 11 Is there an arrow head missing from the left hand end of the line within the right hand P node? [Med] Thanks for catching this. There was a missing +. From: mohamed.boucadair@orange.com > Sent: 24 September 2024 09:47 To: Adrian Farrel >; Vishnu= Pavan Beeram >; TEAS W= G > Cc: TEAS WG Chairs > Subject: [Teas] Re: Responses for LS on "Realization of Network Slices for = 5G Networks Using Current IP/MPLS Technologies" Hi Adrian, Deal! Thank you for your efforts. I also hope that Jie can check and let us know if we missed any of his comm= ents. Cheers, Med De : Adrian Farrel > Envoy=E9 : mardi 24 septembre 2024 10:22 =C0 : BOUCADAIR Mohamed INNOV/NET >; Vishnu Pavan Beeram >; TEAS WG > Cc : TEAS WG Chairs > Objet : [Teas] Re: Responses for LS on "Realization of Network Slices for 5= G Networks Using Current IP/MPLS Technologies" Thanks to all for the hard work on this document. It is definitely getting = much better (and shorter) which is a good thing for all of us. There does seem to have been a lot of changes sine the first last call, and= even since the second one. It also looks (to me) that there are a few of J= ie's comments still unresolved. I plan to scan the doc tonight and I'll try to suggest resolutions for the = points that look to be still open. A On 24/09/2024 10:05 CEST mohamed.boucadair@orange.com wrote: Hi Pavan, all, FWIW, the changes are now implemented in the public version together with a= dditional follow-up comments from Jie: https://datatracker.ietf.org/doc/dra= ft-ietf-teas-5g-ns-ip-mpls/11/. Cheers, Med De : BOUCADAIR Mohamed INNOV/NET Envoy=E9 : lundi 9 septembre 2024 15:34 =C0 : 'Vishnu Pavan Beeram' >; TEAS WG > Cc : TEAS WG Chairs > Objet : RE: [Teas] Responses for LS on "Realization of Network Slices for 5= G Networks Using Current IP/MPLS Technologies" Hi Pavan, all, Thanks for sharing your conclusions. Looks good to me. Fixed right now the ref nits: https://github.com/boucadai= r/5g-slice-realization/commit/3c11d6e6baa2f50a10a95904c8abb29753e91034. The= se nits can be queues for a next iteration when we will have more comments,= but we can release a new version if you prefer so. Thanks. Cheers, Med De : Vishnu Pavan Beeram > Envoy=E9 : lundi 9 septembre 2024 10:04 =C0 : TEAS WG > Cc : TEAS WG Chairs > Objet : [Teas] Responses for LS on "Realization of Network Slices for 5G Ne= tworks Using Current IP/MPLS Technologies" WG, We sent a liaison statement [1] in June to multiple 3GPP groups seeking fee= dback on our WG draft that discusses "Realization of Network Slices for 5G = Networks Using Current IP/MPLS Technologies" [2]. We have received replies from 3GPP-TSGSA-SA2 [3], 3GPP-TSG-SA-WG5 [4] and O= 3GPPTSGRAN3 [5]. We request the WG to review the feedback and chime in with= your thoughts/opinions. The following is our (chairs') interpretation of the feedback that was rece= ived. * 3GPP-TSGSA-SA2: * Remove Appendices B.1 and B.2 and just have a reference to TS-23.5= 01 * No endorsement of the "Hand-off" options discussed in Section 4 an= d the QoS Mapping Realization Models in Section 5 * This need not warrant any changes to Sections 4 and 5. We need = to ensure that the language used in these two sections doesn't imply any en= dorsement by 3GPP. * 3GPP-TSG-SA-WG5: * Fix the reference to 3GPP TS 28.530 * O3GPPTSGRAN3: * Inaccuracies exist in Appendix B.3. Suggest adding references to T= S-38.300 and TS-38.401 * In other words, this is a recommendation to remove Appendix B.3. Based on the above, our recommendation is to remove Appendix B (including t= he Transport Network specific sub-section) and add the suggested references= in the Introduction. The authors have published a new revision (rev 10) wi= th Appendix B removed. Please review the latest changes and let us know if = there are any comments/concerns. Regards, -Pavan and Oscar [1] https://datatracker.ietf.org/liaison/1931/ [2] https://datatracker.ietf.org/doc/html/draft-ietf-teas-5g-ns-ip-mpls [3] https://datatracker.ietf.org/liaison/1955/ [4] https://datatracker.ietf.org/liaison/1956/ [5] https://datatracker.ietf.org/liaison/1957/ ___________________________________________________________________________= _________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ Teas mailing list -- teas@ietf.org To unsubscribe send an email to teas-leave@ietf.org ___________________________________________________________________________= _________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= _________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_DU2PR02MB10160A2A5E534936FF8058E8688762DU2PR02MB10160eu_ Content-Type: text/html; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Hi Adrian,

 

Thank you for the careful review.

 

A diff to track the changes made = so far can be seen here: https://author-tools.ietf.org/api/iddiff?doc_1=3Ddraft-ietf-teas-5g-ns-ip-m= pls&url_2=3Dhttps://boucadair.github.io/5g-slice-realization/draft-ietf= -teas-5g-ns-ip-mpls.txt.

 

Please see inline.

 

Cheers,

Med

 

De : Adrian Farrel <adrian@olddog.co.= uk>
Envoy=E9 : vendredi 27 septembre 2024 21:29
=C0 : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.= com>; 'TEAS WG' <teas@ietf.org>
Cc : 'TEAS WG Chairs' <teas-chairs@ietf.org>
Objet : Last-gasp review of draft-ietf-teas-5g-ns-ip-mpls-11

 

Hi,

 

Here (finally) is my additional review of this draft. Sorry to have

taken a few additional days.

 

Other than the comments (arising from Jie's review), I have only

found a small points and a couple of nits.

 

Not sure whether I should have spotted these in previous reviews. If = so,

sorry.

 

Thanks for all the work.

 

Cheers,

Adrian

 

=3D=3D=3D

 

idnits shows " Unused Reference: 'TR-GSTR-TN5G' "

 

[Med] Argh. Fixed. Thanks.<= o:p>

 

---

 

Section 2, having said the document makes use of the terms defined in=

RFC 9543, proceeds to provide a new definition of "customer"= ; and

"provider". I wonder whether those new definitions are nece= ssary, and

if they are I think great care is needed to achieve disambiguation.

 

[Med] Section 2 also says r= ight after the ref to 9543: “= See Section 3.3 for the contextualization of some of these terms.”<= /o:p>

 

We used to have “customer” and “provider” entries = be part of 3.3 but we moved them here because we received a comment to group all defs.

 

---

 

In Section 3.1, piping ("|") is used to indicated quoted te= xt from 3GGPP

documents. That's good.

But:

- It is probably de trop to use quotation marks as well.

[Med] “” were u= sed to ease demux the quotation from the source.

- It appears as though the reference is part of the quote.=

 

[Med] moved the source refs= to be positioned before the citation and removed the redundant “R= 21;.

---

 

3.2.1

 

Ditto the use of | and "

[Med] Fixed.=

 

---

 

3.2.2

 

I don't object to one word of the text in 3.2.2. I do find it peculia= r

that, while 3.2.1 is nicely quoted from 3GPP documentation, the text = in

this section is longer and un-cited.

 

I should imagine that the paragraph...

    The objective of Transport Network Slicing is=

...should be founded in a 3GPP definition.

 

[Med] We can’t formal= ly cite any reference here where the exact words are used. The definition i= nspires from 3GPP docs, especially from the following:

 

“When providing an en= d to end communication service, the network may use non-3GPP parts (e.g. Da= ta centre network (DCN), Transport network (TN)) in addition to the network components defined in 3GPP. Therefore, in order to ensure t= he performance of a communication service according to the business require= ments, the 3GPP management system has to coordinate with the management sys= tems of the non-3GPP parts (e.g., MANO system) when preparing a network slice for this service. This coordin= ation may include obtaining capabilities of the non-3GPP parts and providin= g the slice specific requirements and other requirements on the non-3GPP pa= rts. Figure 4.7.1 illustrates an example for the coordination with management of TN part (e.g., directly or= via MANO system).”

 

+ (extract of TN specific o= bjectives)

 

“The network slice re= lated requirements include requirements such as: area traffic capacity, cha= rging, coverage area, degree of isolation, end-to-end latency, mobility, overall user density, priority, service availability, s= ervice reliability, UE speed.”

 

 

While the first half of the paragraph...

   Transport Network Slicing provides various degrees of sh= aring of

   resources between slices

...presumably stems from 9543

 

[Med] We can cite Section 8= of 9543.

 

The rest of the text is explanatory in the context of this document (= and

maybe should say so).

 

[Med] Added the following N= EW:

 

&#= 8220;The following further elaborates on how Transport Network Slicing is

defined in the context of this= document.”

 

---

 

Slice scopes and SDP locations.

 

It is all really confusing to me, and I do not arrive at anything oth= er

than contradictions from the text :-(

 

Figure 1 shows the TN slice and also shows the type 3 and type 4 SDP<= o:p>

locations.

[Med] These SDPs for “= ;RFC 9543 Network Slice”, not the full TN slice. We have the followin= g in the introduction:

 

 = ;  Specifically, this document describes an approach to

 = ;  how RFC 9543 Network Slices are realized within provider networks a= nd

 = ;  how such slices are stitched to Transport Network resources in a

 = ;  customer site in the context of Transport Network Slices (Figure 1)= .

 = ;  Concretely, the realization of an RFC 9543 Network Slice (i.e.,

 = ;  connectivity with performance commitments) involves the provider

 = ;  network and partially the AC (the PE-side of the AC).  This do= cument

 = ;  assumes that the customer site infrastructure is over-provisioned a= nd

 = ;  involves short distances (low latency) where basic QoS/scheduling

 = ;  logic is sufficient to comply with the Service Level Objectives

   (SLOs).

 

But, an SDP is the point at which the slice service begins or ends. I= t

is the edge of the slice.

 

Either:

- You are saying that a transport slice does not map perfectly to an<= o:p>

  IETF slice

Or:

- There is something wrong with this and the text in 3.4.2.

 

I don't think any of this changes any of the technical details or

practicalities of the solutions described. It just that the descripti= on

seems plain wrong.

 

For example, where you talk about mapping service parameters: where

is that mapping performed? The question, I suppose is, are you

constructing a TN slice that encompasses network resources that are

both IETF and non-IETF. In that case, the service parameters are=

mapped at the edge of the TN slice, and then they are mapped again

at the network boundary at the start of the IETF technology.

 

If your intention is that the TN slice is constructed from elements o= f

the customer domain (possibly non-IETF) and the provider domain (IETF= ),

that would be fine, but I think the TN slice end points are still the

SDPs.

 

If, conversely, you are saying that the TN slice is a composite of

customer domain slice and IETF slice, then you have the SDPs correctl= y

placed, but you have not made this composite clear.=

 

[Med] 3.4.1 says:

 

 = ;  A TN slice relies upon resources that can involve both the provider=

 = ;  and customer TN domains.  More details are provided in Section= 3.4.2.

=  

 = ;  A TN slice might be considered as a variant of horizontal compositi= on

    of Network Sli= ces mentioned in Appendix A.6 of [RFC9543].

 

[Med] Updated 3.4.2 to remi= nd that this is about 9543 network slice deployments.=

 

It does not help that 3.4.2 goes on to say:

   The concept of distributed PE (Section 3.3.4) assimilate= s CE-based

   SDPs defined in Section 5.2 of [RFC9543] (i.e., Types 1 = and 2) as SDP

   Type 3 or 4 in this document.

 

The problem is not with the text, but with the fact that your Figure = 6

shows the TN slice extending to the CEs in a model where the CEs are<= o:p>

distinct from the PEs. (To me it seems that you are doing types 1 and= 2

in this document with the case of distributed PE assimilating types 3=

and 4.)

 

I start to run into some of this again in Section 4. For example, in = 4.1

   In this option, the RFC 9543 Network Slice, fulfilling c= onnectivity

   requirements between NFs that belong to a 5G slice, is r= epresented at

   an SDP by a VLAN ID (or double VLAN IDs, commonly known = as QinQ), as

   depicted in Figure 12.

That suggests to me that the model in your head is that the VLAN ID is

indicative of either:

- onto which IETF slice the SDP should place the traffic (the traffic

  is at that stage not yet sliced only marked for slicing)<= o:p>

or:

- on which IETF slice the traffic is flowing (the traffic has already=

  been sliced and the SDP is actually at the end of the TN slice= ).

 

To complete my whining about this, 4.2 shows the "tunnels repres= enting

slices" as extending all the way to the NFs (CEs not marked). Su= rely,

in that case, the SDP is at the end of the tunnel?<= /p>

 

 

I'd be quite happy with either or any approach. I just want the

description to match.

 

---

 

3.6

 

   At the time of writing (2024), Section 6.1.2 of [NG.113]= specifies

 

Well...

NG.113 is a dated reference. Doesn't that mean that you can simply sa= y

 

   Section 6.1.2 of [NG.113] specifies

 

While it is true that 3GGP's "5GS Roaming Guidelines" may c= hange over

time. The referenced Version 4 dated 2021 will not change.=

 

[Med] Fixed.

---

 

3.7

 

s/of [RFC9522])./of [RFC9522]./

[Med] Fixed. Thanks.=

 

---

 

Figure 11

 

Is there an arrow head missing from the left hand end of the line wit= hin

the right hand P node?

[Med] Thanks for catching t= his. There was a missing +.

 

From: mohamed.boucadair@orange.com <mohamed.boucadair@orange.com>
Sent: 24 September 2024 09:47
To: Adrian Farrel <adrian@= olddog.co.uk>; Vishnu Pavan Beeram <vishnupavan@gmail.com>; TEAS WG <teas@ietf.org>
Cc: TEAS WG Chairs <teas-= chairs@ietf.org>
Subject: [Teas] Re: Responses for LS on "Realization of Network= Slices for 5G Networks Using Current IP/MPLS Technologies"=

 

Hi Adrian,

 

Deal! Thank you for your efforts.

 

I also hope that Jie can check an= d let us know if we missed any of his comments.

 

Cheers,

Med

 

De : Adrian Farrel <adrian@olddog.co.uk>
Envoy=E9 : mardi 24 septembre 2024 10:22
=C0 : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com>; Vishnu Pavan B= eeram <vishnupavan@gmail.com>; TEAS WG <teas@ietf.org> Cc : TEAS WG Chairs <teas-chairs@ietf.org>
Objet : [Teas] Re: Responses for LS on "Realization of Net= work Slices for 5G Networks Using Current IP/MPLS Technologies"

 

Thanks to all for the hard work= on this document. It is definitely getting much better (and shorter) which is a good t= hing for all of us.

 

There does seem to have been a lot of changes sine t= he first last call, and even since the second one. It also looks (to me) th= at there are a few of Jie's comments still unresolved.

 

I plan to scan the doc tonight and I'll try to sugge= st resolutions for the points that look to be still open.

 

A

On 24/09/2024 10:05 CEST mohamed.boucadair@orange.com wrote:

 

 

Hi Pavan, all,

 

FWIW, the changes are now implemented in the public version to= gether with additional follow-up comments from Jie: https://datatracker.ietf.org/doc/draft-ietf-teas-5g-ns-ip-mpls/11/.

 

Cheers,

Med

 

De : BOUCADAIR Mohamed INNOV/NET
Envoy=E9=  : lundi 9 septembre 2024 15:34
=C0 = ;: 'Vishnu Pavan Beeram' <vishnupavan@gmail.com>; TEAS WG <teas@ietf.org>
Cc = : TEAS WG Chairs <teas-chairs@ietf.org>
Objet&nb= sp;: RE: [Teas] Responses for LS on "Realization of Ne= twork Slices for 5G Networks Using Current IP/MPLS Technologies"<= /o:p>

 

Hi Pavan, all,

 

Thanks for sharing your conclusions.

 

Looks good to me. Fixed right now the ref nits: https://github.com/boucadair/5g-slice-realization/commit/3c11d6e6baa2f50a10= a95904c8abb29753e91034. These nits can be queues for a next iteration w= hen we will have more comments, but we can release a new version if you pre= fer so. Thanks.

 

Cheers,

Med

 

De : Vishnu Pavan Beeram <vishnupavan@gmail.com>
Envoy=E9=  : lundi 9 septembre 2024 10:04
=C0 = ;: TEAS WG <teas@ietf.o= rg>
Cc = : TEAS WG Chairs <teas-chairs@ietf.org>
Objet&nb= sp;: [Teas] Responses for LS on "Realization of Networ= k Slices for 5G Networks Using Current IP/MPLS Technologies"

 

WG,

 

We sent a liaison statement [1] in June to multiple 3GPP groups seekin= g feedback on our WG draft that discusses “Realization of Network Slices for 5G Networks Using Current IP/MPLS Technologies”= ; [2]. =

We have received replies from 3GPP-TSGSA-SA2 [3], 3GPP-TSG-SA-WG5 [4] and O3GPPTSGRAN3 [5]. We request the WG to review the feedback and chime i= n with your thoughts/opinions.

 

The following is our (chairs’) interpretation of the feedback th= at was received.

 

  • 3GPP-TSGSA-SA2:
    • Remove Appendices = B.1 and B.2 and just have a reference to TS-23.501
      • No endorsement of = the “Hand-off” options discussed in Section 4 and the QoS Mappi= ng Realization Models in Section 5
      • This need not warr= ant any changes to Sections 4 and 5. We need to ensure that the language us= ed in these two sections doesn’t imply any endorsement by 3GPP.
  • 3GPP-TSG-SA-WG5:
    • Fix the reference = to 3GPP TS 28.530
  • O3GPPTSGRAN3:
    • Inaccuracies exist= in Appendix B.3. Suggest adding references to TS-38.300 and TS-38.401
      • In other words, th= is is a recommendation to remove Appendix B.3.

 

Based on the above, our recommendation is to remove Appendix B (includ= ing the Transport Network specific sub-section) and add the suggested references in the Introduction. The authors have pub= lished a new revision (rev 10) with Appendix B removed. Please review the l= atest changes and let us know if there are any comments/concerns.

 

Regards,

-Pavan and Oscar 

 

[1] = https://datatracker.ietf.org/liaison/1931/

[2] https://datatracker.ietf.org/doc/html/draft-ietf-t= eas-5g-ns-ip-mpls

[3] = https://datatracker.ietf.org/liaison/1955/

[4] = https://datatracker.ietf.org/liaison/1956/

[5] = https://datatracker.ietf.org/liaison/1957/

 

______________________________________________________________________=
______________________________________
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
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
To unsubscribe send an email to teas= -leave@ietf.org 

______________________________________________________________________=
______________________________________
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
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.
____________________________________________________________=
________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_DU2PR02MB10160A2A5E534936FF8058E8688762DU2PR02MB10160eu_--