Re: [Teas] Network slicing framework : Issue #2 : How many connectivity matrices in a slice?

Krzysztof Szarkowicz <kszarkowicz@gmail.com> Tue, 28 September 2021 11:39 UTC

Return-Path: <kszarkowicz@gmail.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 E849F3A2A25 for <teas@ietfa.amsl.com>; Tue, 28 Sep 2021 04:39:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 iNZRUtEzxVma for <teas@ietfa.amsl.com>; Tue, 28 Sep 2021 04:39:14 -0700 (PDT)
Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F423A3A2A19 for <teas@ietf.org>; Tue, 28 Sep 2021 04:39:13 -0700 (PDT)
Received: by mail-ot1-x329.google.com with SMTP id d12-20020a05683025cc00b0054d8486c6b8so6498566otu.0 for <teas@ietf.org>; Tue, 28 Sep 2021 04:39:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=d+IA1t1+QiE3koSo2xjGj5XmW9fXTdasqM71EREjqqc=; b=j/dtr3GU8LlKUDEgbhVYRwBBkQUp9JnyAbNpptrqfiiJwySJmMg2M+f5+/krPo9ie5 rpiXuormnxtbCI/SjzmD1pU5DcCeIcyg6g01wCLi9RzmVX5gKzjtnB3nrXKzy/hygn+2 mxF3NF1aGLpjX9c9MZeEAsF4fB4Tw5TwBxSfUz7HjhwxROFqimcX9na8MjnOjqs7+8Va EY32FcCcz35m9aTu2r+lK07lbSPLTvJPML+2KSYlhaJ5da4sEfLCAD9M35c5F/cUBK/C RxshaVmjY60A6lZajaxFvIs4nF8jzqiHlABJ+p46vNYm7mWxo+Qls33qzY5pqIvcpvtd ujGA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=d+IA1t1+QiE3koSo2xjGj5XmW9fXTdasqM71EREjqqc=; b=r4cUe+mTkp27vjYyaTGC38wgaOOrcLVgW5NPBnb+mzdR7NV4tt/98BgC1bdhoqC5dP GLfFM8eoWCkQ4Fbjy5rPzwXVeDVIkbQ4q9pLzkH1cQGoyD1BvBqXQ8m9hxRK0Oer+Xlu XN/NDSmSOV52McX4DESan7cximU8lfarkO2WYHIgd+32MqgEYl6ggWAJn9KU2cnhOXCQ ZAGce2gqc5K3+DdQ2R0xzuTsFvXGdV9kPClDVHS0ywqp33+9aOTJDBMWsLh1/qSxdcoJ F4Z2XDo+JM6zijJRsbHtTFUHVXR01/Rtywz+Dbz1wwi/zrxfQFhP+OuyP1KhtJurfB29 /0AQ==
X-Gm-Message-State: AOAM533vTNml3/S8UZVrguHmcbh6Xlhg96j9/p6aewzZ5I5gMwDH+9M2 +Uy/0IpAz4UPZctdQpWLji+xhAYc2HGZ0IhrJPQ=
X-Google-Smtp-Source: ABdhPJxhHV4fZHRAnJ/KJqfhhLo/6g50J3JriGGt+LMOgkXv7Tovz63g1bHN2y8Ij1bHLS10fgyFJg==
X-Received: by 2002:a9d:4a84:: with SMTP id i4mr4707827otf.247.1632829153066; Tue, 28 Sep 2021 04:39:13 -0700 (PDT)
Received: from smtpclient.apple (jpams-nat10.juniper.net. [193.110.49.10]) by smtp.gmail.com with ESMTPSA id i12sm4467733oik.50.2021.09.28.04.39.11 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Sep 2021 04:39:12 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: Krzysztof Szarkowicz <kszarkowicz@gmail.com>
In-Reply-To: <OSAPR01MB3554DFC0E78009FE66DA504090A89@OSAPR01MB3554.jpnprd01.prod.outlook.com>
Date: Tue, 28 Sep 2021 13:39:09 +0200
Cc: John E Drake <jdrake=40juniper.net@dmarc.ietf.org>, TEAS WG <teas@ietf.org>, "Ogaki, Kenichi" <ke-oogaki@kddi.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <726812DD-724E-4C1D-ACEE-E3A769DCA7F1@gmail.com>
References: <050601d7b3bc$bd784b80$3868e280$@olddog.co.uk> <BY3PR05MB80810CD3A725AEDEE3DD1786C7A79@BY3PR05MB8081.namprd05.prod.outlook.com> <OSAPR01MB3554DFC0E78009FE66DA504090A89@OSAPR01MB3554.jpnprd01.prod.outlook.com>
To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/7hgFevdpZj-FIeisbUiTtgd6RWU>
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: Tue, 28 Sep 2021 11:39:19 -0000

My 2 cents:

Slice might have multiple QoS flows (i.e 3GPP TS 38.300, Section 16.3.1), and obviously these different QoS flows will have different SLO characteristics (even, if the set of end-points is the same for all QoS flows).

So, if the support for mapping 3GPP slices to IETF slices is desired, certainly allowing multiple connectivity matrixes per slice would be welcomed.

Best regards,
Krzysztof


> On 2021 -Sep-28, at 10:47, Ogaki, Kenichi <ke-oogaki@kddi.com> wrote:
> 
> Hi Adrian,
> 
> This is just how we define a slice. We are concerned that we should allow multiple SLO/SLEs inside a slice?
> We prefer not doing so since other SDOs define that their slice is determined with a SLO/SLE in my understanding.
> Inside a slice with a common SLO/SLE, we don't mind multiple connectivity matrices, but we're not sure the necessity.
> 
> Thanks,
> Kenichi
> 
> -----Original Message-----
> From: Teas <teas-bounces@ietf.org> On Behalf Of John E Drake
> Sent: Tuesday, September 28, 2021 3:17 AM
> To: adrian@olddog.co.uk; 'TEAS WG' <teas@ietf.org>
> Subject: Re: [Teas] Network slicing framework : Issue #2 : How many connectivity matrices in a slice?
> 
> Adrian,
> 
> In the latest version of the to-be-published Framework draft, we have the following definition:
> 
> Attachment Circuit (AC):  A channel connecting a CE and a PE over which packets are exchanged.  The customer and provider agree on which values in which combination of L2 and L3 fields within a packet identify a given connectivity matrix within a given IETF Network Slice Service.
> 
> Yours Irrespectively,
> 
> John
> 
> 
> Juniper Business Use Only
> 
>> -----Original Message-----
>> From: Teas <teas-bounces@ietf.org> On Behalf Of Adrian Farrel
>> Sent: Monday, September 27, 2021 12:29 PM
>> To: 'TEAS WG' <teas@ietf.org>
>> Subject: [Teas] Network slicing framework : Issue #2 : How many 
>> connectivity matrices in a slice?
>> 
>> [External Email. Be cautious of content]
>> 
>> 
>> 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
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas
>> __;!!N
>> Et6yMaO-
>> gk!WDr1qyYuWTVcNfdWACFDBhpuWB09hOnRKbD4lEp5p3xxVzN2mQcQ2Ioh45
>> z7At0$
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas