Re: [Teas] Network slicing framework : Issue #2 : How many connectivity matrices in a slice?
John E Drake <jdrake@juniper.net> Thu, 07 October 2021 20:56 UTC
Return-Path: <jdrake@juniper.net>
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 1E46D3A0E7E for <teas@ietfa.amsl.com>; Thu, 7 Oct 2021 13:56:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.549
X-Spam-Level: **
X-Spam-Status: No, score=2.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, GB_SUMOF=5, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=BAgxipYR; dkim=pass (1024-bit key) header.d=juniper.net header.b=Xuee0VUc
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0LQTVDiR3Dpu for <teas@ietfa.amsl.com>; Thu, 7 Oct 2021 13:56:18 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 2EA643A0E74 for <teas@ietf.org>; Thu, 7 Oct 2021 13:56:18 -0700 (PDT)
Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 197HNf0J014437; Thu, 7 Oct 2021 13:56:16 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=UuOwhEo3AD4Cp/MUq5bXn1546tI66G1Xe1u9PX402Kw=; b=BAgxipYRPXUuu/WFFAogkaf0ffGYDjp5G02zoouDrQvgyEzadA8OP/aw0DoWlgWh15FZ doETYv8sayp0qSGreptGndMefl9key4HXNRoWQuVoLdc5kPHurZgh+uc5OxAfHyeAydH iJk2lY747PpEnlKzCOvrTwoCHvlCAe5PX/KINBLyiNYHNM2T2rp1f3FPPDkLU1yUXxFX rSz8TbTq/fhWYHXBYPHchUsUX7Yf78LLu52iFBdg+RUwy1VoHNp5nJBzH9wc7vcdU790 5u7JdQ2Ps/6RPSfhEE3ANXm9oFg8L4b1GuDrNZcpV2XKEgE6lEePfh9Gk1mh9Pz16lwl Hg==
Received: from nam11-bn8-obe.outbound.protection.outlook.com (mail-bn8nam11lp2172.outbound.protection.outlook.com [104.47.58.172]) by mx0b-00273201.pphosted.com with ESMTP id 3bj58m0cry-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 07 Oct 2021 13:56:15 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=l2rqqdWfGfbN76OcdQkWTgfTFdBAgiHxREy0mLST93Ej9jb8EfnVS0vnOWdlmoZLZmK/QgLsWlMGc71ja2XoYfVatYmthyOq3X/aIbgWqqiZx4kRusKnHPEua/t3DwzmKlKSRLAb5gwYjvp5RadjjKRtdujomJ6101OKv+2L3jeQELODizI4QbG6eXoo4TrVEfeRMmk1FUzH3aUk56mPtDSlk1ZSj0Ad+8RSP+wwHyzec+M865duWgmxeui7bIdxIwr0Q1j0abhM2J7Q+fiRFrGBejr7stgj94PoaCQ2vQgyRDiTkHa9h3AaD2U5W5319+qCGP9O5QSMxfmzBEHAdQ==
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=UuOwhEo3AD4Cp/MUq5bXn1546tI66G1Xe1u9PX402Kw=; b=jUL5vwjgi70ubClZTQpfT4OczuZwrzgCtuL4wHyeOzHGgXhooRzA7yZNjGjdf3lRt35reiMf8wTjchf3uk1lOXaPPkEJbCSEYx6fR1mCd4RlnKb18JPoZgfK5zdMEnt8WpGtjitjmoC/tWIorOTNd+oeGRP/opPp6fShyLMgtpijuKFYLx+qgMROFPYPDedq1BuU4ZN3sVvKYdU/PaMvhWpBAg7sADHbXIJT9dVvsbP8jhNoFwi0+gi3hC5tNdPe0aavsRmUIkzcHgpu3s7Ictm+bvJBbLunzdJyp4b8BBgYRHAyIeCmqQVy1O6oIhyywZj+TkHd4Dyfy8nQqBZLJg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UuOwhEo3AD4Cp/MUq5bXn1546tI66G1Xe1u9PX402Kw=; b=Xuee0VUcr6hz4fICjvkuzCk73oXPBNOHScRYNcDu5KRUexp6z0jynp2SJrEbuQoZdUzbXnQHIcKyF9JessYKmNb4ZAVGQzZIhsMZfBcY66bWuEGpSBfUGgkAzu+WU21YUDp2TCjJUjpZMTnBjnXtv0F++mqEGxoKxdcb8PNWHco=
Received: from BY3PR05MB8081.namprd05.prod.outlook.com (2603:10b6:a03:366::15) by BYAPR05MB6326.namprd05.prod.outlook.com (2603:10b6:a03:e1::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.15; Thu, 7 Oct 2021 20:56:11 +0000
Received: from BY3PR05MB8081.namprd05.prod.outlook.com ([fe80::60d5:3d7c:49b5:cda0]) by BY3PR05MB8081.namprd05.prod.outlook.com ([fe80::60d5:3d7c:49b5:cda0%7]) with mapi id 15.20.4566.022; Thu, 7 Oct 2021 20:56:11 +0000
From: John E Drake <jdrake@juniper.net>
To: Xufeng Liu <xufeng.liu.ietf@gmail.com>, "Joel M. Halpern" <jmh@joelhalpern.com>
CC: TEAS WG <teas@ietf.org>
Thread-Topic: [Teas] Network slicing framework : Issue #2 : How many connectivity matrices in a slice?
Thread-Index: AdezuWNZaTsLJ1ePR5CrLNzkBvg16gAwUfxmAASBAAAByOaEgAAAR9OAAAKdXIAAAFPisA==
Date: Thu, 07 Oct 2021 20:56:11 +0000
Message-ID: <BY3PR05MB8081DFA7D20FA90BB136CE9AC7B19@BY3PR05MB8081.namprd05.prod.outlook.com>
References: <050601d7b3bc$bd784b80$3868e280$@olddog.co.uk> <DM5PR1901MB21500050DC76CB9EFFEB03A9FCA89@DM5PR1901MB2150.namprd19.prod.outlook.com> <06f701d7b48c$afe17b10$0fa47130$@olddog.co.uk> <CAEz6PPT2=D1qN+n+2RjR9NweUBnAefUBhX+XMOccoOwo+BtKVQ@mail.gmail.com> <45638550-4da8-ae0b-fb23-b9ac53569e67@joelhalpern.com> <CAEz6PPS-pupMa9YVCFZu1MfFkwnuCMj9bMcXTrQSbE4L8yP_hg@mail.gmail.com>
In-Reply-To: <CAEz6PPS-pupMa9YVCFZu1MfFkwnuCMj9bMcXTrQSbE4L8yP_hg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 11.6.100.41
dlp-reaction: no-action
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2021-10-07T20:56:09Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=d68b8305-c0fd-4187-b924-3150e30438d0; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=juniper.net;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 2a1ed6f1-ae85-4f98-29f3-08d989d4e4de
x-ms-traffictypediagnostic: BYAPR05MB6326:
x-microsoft-antispam-prvs: <BYAPR05MB63262AD7C127D8CC56937278C7B19@BYAPR05MB6326.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: obUD9wQCZs4KNRIgLHUNfeEBCyTNVqPz9/piy3hXHqHpVWzq+wSPfFxvTPTWsEZHMUS+rkYDJQXZw7oa6RrStZZqPzLyNNAaXVtgrv58NANjhbUP/5+m147NXxANpdRjW2T3WKdACSJ0NhTumHZvyQLY3I1Rj1ZIaJUZOVyc6A2SER9iUOdIbi0JdK9GPdHF6jAh5ZkIIvhWQJhirTBSvSTfEWEtTWtfisOt630NLrfRoK7DHsbpZHCpWbS1WfHdAkALYZJocfIe7Ef6w+eZt3cz8YY4ytnYHcI4e2wCLxsbTdMew2Nq1k3YM3GG9BJUn0h8Nvmu0b6WW5W2GAqP4QPdA5UFBFqIwwCYz/udWR7NCm0YdNKX5Q70wHf7mSfK9jFVAcW7Z4pr4C1KzHqRbhsSyVS1EHrICWllf6MZoPbQGZEQFzXZZZfTlNmcy83+tMOZloqC4VYoEMzQUIDTISW3t8YZQa2AKWwwoh/m+9u81vmK7DyKTC2e+DsUwlnyNdATOe45W+6eoYMC6SFLdJ6A2WRAmGDU9kt2Rr1iaJnwmVMjLz3pCoiRfr0TjhpIybFEO1f79s82+fpN8DfPb90x1QNrJ+FFDBvur4nJHcH8Rr+AQesn8tEN45BoQKjOHuVmAKSmit6x3WztLYHu3TZOcVbiXfcj0M08kwKDaRL08bYAVze0vvZfBz4xcQOIl15Hd8b0t7XcWtHwzFbRj8iQwKIFc6dU8OhOGuIdrrVDtqQpXedj9h+I10Ym9YqpOJPaQq2F+9T4jX9KEBnlsynNWL2DFAJzFl1mFgBqtu8=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY3PR05MB8081.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(26005)(9686003)(66946007)(186003)(30864003)(64756008)(66476007)(66556008)(66446008)(8676002)(8936002)(9326002)(83380400001)(122000001)(166002)(316002)(33656002)(110136005)(966005)(2906002)(53546011)(71200400001)(52536014)(38070700005)(38100700002)(4326008)(66574015)(86362001)(76116006)(55016002)(7696005)(6506007)(5660300002)(508600001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: tE7ss4lhbH7Mkt7zS/Tw6jmQs7jNPacKVZ0IG7bNJT1luS26j1oTIdTp5+pLwwyoRdxoIizrhXf0FDFvgEkyMBzuMMAMTthzrM+2KUiKVeP2FaWDswHqYA4X7lTCr62MeCyLZtqbAherWDleYKot53PPPCaN1m3PpwK69nCCKSv/5IUndYDgcR09NUwYw48imjVGDmZHD5zb1+rfqkLM6/l39u1X4F20i0HaTARs4Xj1U2/gY/9LwROiwGRp4vcqRJiumdlnP8bEg5x3Jpmz9Gnrx3BjyjHmyjFXCA4ln8RmoNoG/M7yeIjbJmgwJbRLM+CJGu9lGf72Tuooaepa96dckfUpzPD0++0+w2t1tcTkvcJpi6Sh9nDR2Xxm9Qm+UQsfNR6MiMOhT+9mwxmLaX+VfteumMy/PDTtIPB3w27mXdm8D+7Ow/7KZtKH7LG6YmlFc6Ku+RIeERlaZ1kQXrDo5xhC1hwhWu1fCSn2WD418OeUGA9V2rDJbOmCw0aSpvff0noNYh7n1jeFTzncU3GPs0iA0yzDC7diDQ6RQRtbQ/4jFWDFSFA1ar0EWyT4edousHsxQhRZYF6pHvrHbVwcad962yD+KpRjy6x4Ttt9JaQ/doynI1/WIH5GGa1uTSx6F2q4KlY3OWIKjpD0BhPYpjlAyawQ6Pyg+tcJme+VeM+iaVUF+t5/vdTI2PcDwsOT+3tu/onTLOkDbl6pzLEUn5gbVMDajR3dmgcBDctu4R04Nlmkz8Ut5/7f3VFS4NhVip3R5CpreRchWxRKkqrfgMX2RVTa3nluwoQc4z6lpD7izelOf3Q4FVYKQVsReN8hAJEIM25Lf92NTYaLvo7gqN/sfC2+t1AXHe3ooQKYzWa9EZ4IkbT6DqPdBXxmz8XkPaR/aFn7QHFabyGVboGPpPJAWy8bAdLFhfWg2OMxwqjcMNngwZrMMZKcpdaZFDK9kSyLO3uxLLm4i6WZaNEPo/LU9sRfQtu9EbnqMRAc49fR2mabWyka239TduIFY+yVkB8XXk4deQEP942DeIHixV0PoGAoQKY8GXaX05GFKzfccTW1Mawx6QbphWsk6c+SQp3/bcpMC/MCojenyKxBne/NYACNV14a2YihJvwXux+8oLwa9+rY/S0t7rYTXYBwdpFItf0BfiruHZHLpeQQnkZiJcnXwYbUcrqyUtrsbFb5FlwZqtEt2s9h2t3aelKxnSxLECZBia548vaE0zogN6X7c8xrw7yYyLwBnk4slY24FZ0R2BtY0Fb+OaVAD40bWN/5ptEmkdb4bcr74mHQVfLH/s/0joF+CGBf6XrXG35e+8gmpY0RBEmM3jl6
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BY3PR05MB8081DFA7D20FA90BB136CE9AC7B19BY3PR05MB8081namp_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BY3PR05MB8081.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2a1ed6f1-ae85-4f98-29f3-08d989d4e4de
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2021 20:56:11.4118 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: sVdIpCmMGCW/3Rc4Xj37C5Ex5sGyS7mpw6DIKhUQ1dZ0bDcWoaatYE0FGyn0KL1mYz4Zuk7Q6W8eP9FjjjPbdg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB6326
X-Proofpoint-ORIG-GUID: z7k_LdSRkRD2KTB3J3eMyINPxXfIkRw3
X-Proofpoint-GUID: z7k_LdSRkRD2KTB3J3eMyINPxXfIkRw3
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.391,FMLib:17.0.607.475 definitions=2021-10-07_04,2021-10-07_02,2020-04-07_01
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 impostorscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 suspectscore=0 malwarescore=0 bulkscore=0 spamscore=0 phishscore=0 clxscore=1015 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001 definitions=main-2110070132
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/Fdu4_c5WDHLki5BPXONfllxs_bs>
Subject: Re: [Teas] Network slicing framework : Issue #2 : How many connectivity matrices in a slice?
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Oct 2021 20:56:24 -0000
Hi, Comment inline Yours Irrespectively, John Juniper Business Use Only From: Teas <teas-bounces@ietf.org> On Behalf Of Xufeng Liu Sent: Thursday, October 7, 2021 4:43 PM To: Joel M. Halpern <jmh@joelhalpern.com> Cc: TEAS WG <teas@ietf.org> Subject: Re: [Teas] Network slicing framework : Issue #2 : How many connectivity matrices in a slice? [External Email. Be cautious of content] In this case, there is slice-a for traffic class A with slo-A, and slice-b for traffic class B with slo-B. There is another base slice-c under both slice-a and slice-b. The slo-C on slice-c limits the total traffic. Thanks, [JD] If you replace ‘slice-a’ with ‘connectivity matrix a’, ‘slice-b’ with ‘connectivity matrix b’, and ‘slice-c’ with ‘IETF network slice c’, you have the current architecture. - Xufeng On Thu, Oct 7, 2021 at 3:27 PM Joel M. Halpern <jmh@joelhalpern.com<mailto:jmh@joelhalpern.com>> wrote: Do you consider the use case where there is a ingress limit on the total traffic thata a consumer can send across a set of traffic classes, and there are separate SLOs for those separate classes, to be a case we need to address? It seems legitimate to me. And multiple connectivity matrices in a slice seems the natural way to address it. Yours, Joel On 10/7/2021 3:19 PM, Xufeng Liu wrote: > I would like to have: > - Support of one connectivity matrix per slice is mandatory > > But not have: > - Support of more than one connectivity matrix per slice is in the > architecture > but is optional to implement > > Allowing the second option would unnecessarily complicate the user > experience, without providing any additional capabilities, as commented > below in-line. > > Thanks, > - Xufeng > > On Tue, Sep 28, 2021 at 1:17 PM Adrian Farrel <adrian@olddog.co.uk<mailto:adrian@olddog.co.uk> > <mailto:adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>>> wrote: > > Hi Tarek, ____ > > __ __ > > You’ve called out some good cases for consideration.____ > > __ __ > > >> For example, a consumer may want a slice that is ultra-low latency, > and they may know that they want to send traffic from A to B, from A > to C and multicast from D to A, B, and C.____ > > [TS]: I agree that creating multiple matrices (per service type) to > address the above usecase makes sense and makes it simpler for the > IETF slice service consumer to reference a single ultra-low latency > slice. ____ > > * In such case, wouldn’t the service type (unicast/multicast) be > enough to differentiate what connectivity matrix the traffic > would pick – as opposed to requiring an additional ID (one for > identifying slice, and one for identifying the connectivity > matrix).____ > > [AF] There are two points to consider:____ > > * How the customer specifies the connectivity supported by the > slice____ > * How the implementation identifies the connectivity matrix and > places traffic on the matrix____ > > So, in this case, there is no traffic flow anticipated from A to D > or from B to C, etc. Thus, it is not good enough to specify the set > of endpoints, it is also important to specify the connectivity > between those endpoints so that the provider knows that there is no > need to provision resources for connectivity that will not be used.____ > > How the connectivity is actually implemented in the network (and > even how traffic is policed, and how SLIs are measured) is up to the > provider/implementer. If (this may be a big if) the traffic is > simply routed, then it would not be necessary for the provider to > match traffic to a connectivity matrix – they would simply route it, > and in this case the provider’s network is unaware of the > connectivity matrix. On the other hand, if some form of > connection-oriented approach is taken then while the traffic is > simply routed/classified at the ingress endpoint, there is some > relationship between connection matrix and reserved resources (think > of MPLS-TE). ____ > > If, in all this, there is no policing at the ingress endpoint, then > admission control or use of resources in the transit network may > need to be more carefully associated with the “flow” i.e. the > connectivity matrix.____ > > __ __ > > * Does it make sense to have two “same type” connectivity matrices > (for example, two p2p connectivity matrices for two connections > between A and B)? I can see two cases:____ > o If the two parallel connections (between A and B) have same > SLOs, then why not aggregate into 1 connection/connectivity > matrix?____ > > [AF] I think that if they have the same SLOs and the same > connectivity, then you would probably have them as a single matrix > (summing the bandwidth, but keeping the latency constant, for > example). But you would not be required to do that. Again, it might > depend on policing and how you want to manage the SLOs. For example, > two parallel connectivity matrices from A to B each with a required > throughput of X Mbps is not the same as one matrix from A to B with > throughput 2X – this is because A is not the traffic source: traffic > comes from upstream of the slice endpoint and may originate at > different applications, hosts, or sites.____ > > __ __ > > Again consider MPLS-TE LSPs. You might, for convenience and > scalability tunnel two parallel LSPs down one hierarchical LSP. The > capacity of the H-LSP is the sum of the children, but the children > have their own rights!____ > > __ __ > > Of course, in this case, the SLOs might only be identical today. > They might be available to change tomorrow, and in that case it is a > lot easier to have two separate (“parallel”) matrices.____ > > __ __ > > o If the two parallel connections (between A and B) have > different SLOs, then are they still same slice? wouldn’t it > be better to just have them in two different slices?____ > > [AF] This is the nub of the question. It is a multi-dimensional > problem (because of the many SLOs) with a hierarchy of ownership. > Customer àslice àmatrix. You end up with the same number of leaves > in the tree, but the branches are at different places. And, further, > you could hang the SLOs at any point in the tree (for example at the > matrix as currently proposed, or at the slice). > > [Xufeng]: If the slices can be organized hierarchically, the original > desired behavior can be achieved: in addition to the three separate > slices described earlier, we can have a base (underlay) slice that > supports all these three slices. The base slice can serve as a construct > containing all three connectivity matrices, without introducing > additional connectivity-matrix-id. > > ____ > > __ __ > > A part of this debate is: suppose two connectivity matrices have 98% > agreement on their SLOs, but one SLO is fractionally different. Does > that require two slices?____ > > __ __ > > But please be aware that describing the architecture is not > engineering the YANG model! With the current proposal, I would > probably still write a YANG model that had default SLOs per > customer, with variations per slice, with additional variations per > matrix.____ > > __ __ > > And also recall that how the network protocol implementations choose > to implement adherence to SLOs is open for discussion. If they need > some form of indicator/index to tell them what to do, this value > will be “mapped” from {customer, slice, matrix} and it is not > important (to the architecture) how that mapping is performed.____ > > __ __ > > o it is not clear in such case what creating two matrices “of > same type” is solving? Is it loadbalance, redundancy, ?____ > > [AF] It is not clear to me that anyone (except for you :-) has > raised the case of two parallel matrices with identical SLOs. I am > not convinced that they would be used (although my throughput > example, above) is a possible case. But equally important to me is > the question: why would we prevent this when it comes for free?____ > > __ __ > > Cheers,____ > > Adrian____ > > __ __ > > *From: *Teas <teas-bounces@ietf.org<mailto:teas-bounces@ietf.org> <mailto:teas-bounces@ietf.org<mailto:teas-bounces@ietf.org>>> > on behalf of Adrian Farrel <adrian@olddog.co.uk<mailto:adrian@olddog.co.uk> > <mailto:adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>>> > *Date: *Monday, September 27, 2021 at 12:29 PM > *To: *'TEAS WG' <teas@ietf.org<mailto:teas@ietf.org> <mailto:teas@ietf.org<mailto:teas@ietf.org>>> > *Subject: *[Teas] Network slicing framework : Issue #2 : How many > connectivity matrices in a slice?____ > > Hi, > > Igor raised this especially in the context of how traffic is > identified for association with a connectivity matrix that belongs > to a slice. > > Consider the definition of connectivity matrix in the current draft > and as discussed in issue #1. > > A consumer may want multiple connectivity matrices in their > "contract" with the provider. In the example with four edge nodes > (A, B, C, D), their may be traffic that flows between some edges, > but not between others. > > For example, a consumer may want a slice that is ultra-low latency, > and they may know that they want to send traffic from A to B, from A > to C and multicast from D to A, B, and C. > > It is, of course, possible to express this as three separate slices. > And this is perfectly acceptable. We must not make any definitions > that prevent this from being the case. > > However, it seems likely that the consumer (and the operator) would > prefer to talk about "the consumer's low latency slice". That is, to > bundle these three connections into one construct. However, they are > distinctly different connections and must be understood as such. > Indeed, they may have some different SLOs associated (for example, > A-B may require more bandwidth than A-C). > > By allowing (but not mandating) multiple connectivity matrices in a > single slice service, we facilitate this administrative group. > > One could also imagine (but I do not pre-judge the network slice > service YANG model definition) a default set of SLOs that apply to > all connectivity matrices in a slice, and specific modified SLOs per > connectivity matrix. > > Now, to Igor's point. This is about how traffic arriving at an edge > (say a PE) is mapped to the correct connection. I promised a Venn > diagram, but words are easier 😊 > > If we take the model of a port-based VPN, then one approach might be > to map the (virtual or physical) port number or VLAN ID to the > network slice. But clearly (and this was Igor's point) this doesn't > identify the connectivity matrix if there is more than one matric > per slice. > > A solution I offered is that the VLAN ID could identify {slice, > connectivity matrix}. At that PE, for a given AC to a CE, it is > necessary to expose with a separate VLAN ID for each {slice, > connectivity matrix}. That does not mean: > - we need a global unique identifier for each connectivity matrix > - we need a per-PE unique identifier for each connectivity matrix > > I am *very* cautious about discussing potential technology solutions > because they are just that. It is not the business of a framework to > direct solutions work. But I provide this example solution just to > show that it is possible. > > Consider also, how traffic is placed on LSPs or on SFCs. The answer > is that there is some form of classification performed at the head > end. In many cases, this is as simple as examination of the > destination address (traffic is "routed" onto the LSP). In other > cases there is deeper analysis of the 5-tuple and even other packet > parameters. Often this will be enough, but when there are multiple > "parallel" connections to the same destination, some form of choice > must be made: how that choice is made can be configured in an > implementation, and may include looking at additional information > (such as a VLAN ID) passed from the consumer. > > Note that the identity of the connectivity matrix is not needed > anywhere except at the ingress edge node. It may be that the > connectivity matrix is mapped to some internal network structure > (such as an LSP) and that that provides an implicit identification > of the connectivity matrix, and it may be that a solution technology > chooses to keep an identifier of the connectivity matrix with each > packet, but that is not a requirement of the architecture. > > I think what I have said is: > - Support of one connectivity matrix per slice is mandatory > - Support of more than one connectivity matrix per slice is in the > architecture > but is optional to implement > - There are ways that a protocol solution could achieve this function > - I have heard some voices asking for the association of multiple > connectivity > matrices with a single slice > - I have not heard anyone providing examples of harm this would cause > > Please discuss. > > Adrian > > > > > _______________________________________________ > Teas mailing list > Teas@ietf.org<mailto:Teas@ietf.org> <mailto:Teas@ietf.org<mailto:Teas@ietf.org>> > https://www.ietf.org/mailman/listinfo/teas<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!TwzRdRjvFWOycLSs_9NKxkcV9k_PJI1njuCJJjPQfYrLvBHpPFhKPhlbHROd2ts$> > <https://www.ietf.org/mailman/listinfo/teas<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!TwzRdRjvFWOycLSs_9NKxkcV9k_PJI1njuCJJjPQfYrLvBHpPFhKPhlbHROd2ts$>>____ > > _______________________________________________ > Teas mailing list > Teas@ietf.org<mailto:Teas@ietf.org> <mailto:Teas@ietf.org<mailto:Teas@ietf.org>> > https://www.ietf.org/mailman/listinfo/teas<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!TwzRdRjvFWOycLSs_9NKxkcV9k_PJI1njuCJJjPQfYrLvBHpPFhKPhlbHROd2ts$> > <https://www.ietf.org/mailman/listinfo/teas<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!TwzRdRjvFWOycLSs_9NKxkcV9k_PJI1njuCJJjPQfYrLvBHpPFhKPhlbHROd2ts$>> > > > _______________________________________________ > Teas mailing list > Teas@ietf.org<mailto:Teas@ietf.org> > https://www.ietf.org/mailman/listinfo/teas<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!TwzRdRjvFWOycLSs_9NKxkcV9k_PJI1njuCJJjPQfYrLvBHpPFhKPhlbHROd2ts$> >
- [Teas] Network slicing framework : Issue #2 : How… Adrian Farrel
- Re: [Teas] Network slicing framework : Issue #2 :… John E Drake
- Re: [Teas] Network slicing framework : Issue #2 :… Ogaki, Kenichi
- Re: [Teas] Network slicing framework : Issue #2 :… Krzysztof Szarkowicz
- Re: [Teas] ***フリーメール*** Re: Network slicing frame… Ogaki, Kenichi
- Re: [Teas] ***フリーメール*** Re: Network slicing frame… Krzysztof Szarkowicz
- Re: [Teas] ***フリーメール*** Re: Network slicing frame… Adrian Farrel
- Re: [Teas] ***フリーメール*** Re: Network slicing frame… Krzysztof Szarkowicz
- Re: [Teas] ***フリーメール*** Re: Network slicing frame… Adrian Farrel
- Re: [Teas] ***フリーメール*** Re: Network slicing frame… Ogaki, Kenichi
- Re: [Teas] ***フリーメール*** Re: Network slicing frame… Krzysztof Szarkowicz
- Re: [Teas] ***フリーメール*** Re: Network slicing frame… Krzysztof Szarkowicz
- Re: [Teas] ***フリーメール*** Re: Network slicing frame… John E Drake
- Re: [Teas] ***フリーメール*** Re: Network slicing frame… Ogaki, Kenichi
- Re: [Teas] Network slicing framework : Issue #2 :… Tarek Saad
- Re: [Teas] Network slicing framework : Issue #2 :… Tarek Saad
- Re: [Teas] Network slicing framework : Issue #2 :… Krzysztof Szarkowicz
- Re: [Teas] Network slicing framework : Issue #2 :… Adrian Farrel
- Re: [Teas] ***フリーメール*** Re: Network slicing frame… Krzysztof Szarkowicz
- Re: [Teas] Network slicing framework : Issue #2 :… Igor Bryskin
- Re: [Teas] Network slicing framework : Issue #2 :… Krzysztof Szarkowicz
- Re: [Teas] Network slicing framework : Issue #2 :… Jeff Tantsura
- Re: [Teas] ***フリーメール*** Re: ***フリーメール*** Re: Netw… Ogaki, Kenichi
- Re: [Teas] ***フリーメール*** Re: ***フリーメール*** Re: Netw… Krzysztof Szarkowicz
- Re: [Teas] Network slicing framework : Issue #2 :… mohamed.boucadair
- Re: [Teas] Network slicing framework : Issue #2 :… Dongjie (Jimmy)
- Re: [Teas] Network slicing framework : Issue #2 :… John E Drake
- Re: [Teas] Network slicing framework : Issue #2 :… Kiran Makhijani
- Re: [Teas] Network slicing framework : Issue #2 :… Xufeng Liu
- Re: [Teas] Network slicing framework : Issue #2 :… Joel M. Halpern
- Re: [Teas] Network slicing framework : Issue #2 :… John E Drake
- Re: [Teas] Network slicing framework : Issue #2 :… Xufeng Liu
- Re: [Teas] Network slicing framework : Issue #2 :… John E Drake
- Re: [Teas] Network slicing framework : Issue #2 :… jmh.direct
- Re: [Teas] Network slicing framework : Issue #2 :… Xufeng Liu
- Re: [Teas] Network slicing framework : Issue #2 :… Xufeng Liu
- Re: [Teas] Network slicing framework : Issue #2 :… John E Drake
- Re: [Teas] Network slicing framework : Issue #2 :… Xufeng Liu
- Re: [Teas] Network slicing framework : Issue #2 :… Xufeng Liu
- Re: [Teas] Network slicing framework : Issue #2 :… John E Drake
- Re: [Teas] Network slicing framework : Issue #2 :… t petch