Re: [Teas] ***フリーメール*** Re: Network slicing framework : Issue #2 : How many connectivity matrices in a slice?
Krzysztof Szarkowicz <kszarkowicz@gmail.com> Tue, 28 September 2021 12:44 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 8DAD83A2C46 for <teas@ietfa.amsl.com>; Tue, 28 Sep 2021 05:44:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=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 hhN5mavEv5Sr for <teas@ietfa.amsl.com>; Tue, 28 Sep 2021 05:44:38 -0700 (PDT)
Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) (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 7C9FC3A2C47 for <teas@ietf.org>; Tue, 28 Sep 2021 05:44:38 -0700 (PDT)
Received: by mail-oi1-x22c.google.com with SMTP id v10so29709677oic.12 for <teas@ietf.org>; Tue, 28 Sep 2021 05:44:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=qbHUEAxo1ISUujvJatbk7iVX+Ug2wA74LTQVvFQxY6k=; b=i38BTY6RHzuHtFgs4SNN4OfFPrD8i9lrKyDbho7/mbIDutCoD+Xo3GR5nCFVw3IonY 9WD9ObAxojaITSyRmqa/82YISp62p6QWbabJeCNfwlvsvUlNeeYPKCSpNUHvTxWekMvZ 0Q7gpiDRa0OwyFRW6v2SnPR9tLMlkl3TEewR6BnvWrqEiZ433XYQsLctSBOXfjBp3NMD rLk9GcYBpLsWhQ8xSHdQ+36eO1TIg/ZW9A5bZx1YvykgPMGvDiRunvDJ9BHv0aSX8KXW BtqsS4HqDTm+2V4al1X0c3QOtsGpaAzY0itu+Qg0Y6+O4hNCFh0pr7J/hTgqCTe2wwiq tOfQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=qbHUEAxo1ISUujvJatbk7iVX+Ug2wA74LTQVvFQxY6k=; b=QTZaxPKjm+w3fasU79x9yezkGvDao3+i0uleAFlURdU29Ukm5Zq3WnQBswrh6y1A6G 56THTDTjloglrmLuxTHFVFOL3pY7prvs0uqz0CBj8AsfSqbHnataDdiAGODnJ23b4osZ pbWn3vh8GJ7wI+tGItvZ3h+4Xx5070yXQywwiKDvl7MyvtUn3z0/ytvcRT1dJYb2UzV0 iR8n++wqCUsNb33bG2cTP5fWKi0MQt6ydprAaGL/ia7AWJxvpLSDl/3iiuFw86fpWz41 K+C27c9DrWUDlSl9Fi49FcHwLvrQFpYN+oxfksahVDh8ouyxDTsMBmkyeFO9F4ffKtOV ziNA==
X-Gm-Message-State: AOAM530EiVH9g17CqIiohbmiH8Lhzyidra7lDdBe2LiP+c6JbNzsaoHD d/64tcKCZ6KkQ0sE/v6CjQ0=
X-Google-Smtp-Source: ABdhPJwe7jOXwKtNFmGrB4R9FdRYf8eMrPdhELweNt3sBic95cJGWUUW4m0MsE3ckogRZCsK5dUEaw==
X-Received: by 2002:a05:6808:130b:: with SMTP id y11mr3349433oiv.55.1632833077477; Tue, 28 Sep 2021 05:44:37 -0700 (PDT)
Received: from smtpclient.apple (jpams-nat10.juniper.net. [193.110.49.10]) by smtp.gmail.com with ESMTPSA id u6sm2921846ooh.15.2021.09.28.05.44.35 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Sep 2021 05:44:36 -0700 (PDT)
From: Krzysztof Szarkowicz <kszarkowicz@gmail.com>
Message-Id: <A01D0B9B-91BC-450A-92D5-8862D4913892@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_E72682AC-D87D-45EB-A515-A157982F147E"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Date: Tue, 28 Sep 2021 14:44:33 +0200
In-Reply-To: <TY2PR01MB3562EE2C9533DB45B739E00F90A89@TY2PR01MB3562.jpnprd01.prod.outlook.com>
Cc: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, John E Drake <jdrake=40juniper.net@dmarc.ietf.org>, TEAS WG <teas@ietf.org>
To: "Ogaki, Kenichi" <ke-oogaki@kddi.com>
References: <050601d7b3bc$bd784b80$3868e280$@olddog.co.uk> <BY3PR05MB80810CD3A725AEDEE3DD1786C7A79@BY3PR05MB8081.namprd05.prod.outlook.com> <OSAPR01MB3554DFC0E78009FE66DA504090A89@OSAPR01MB3554.jpnprd01.prod.outlook.com> <726812DD-724E-4C1D-ACEE-E3A769DCA7F1@gmail.com> <TY2PR01MB3562EE2C9533DB45B739E00F90A89@TY2PR01MB3562.jpnprd01.prod.outlook.com>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/RIhstF6wXysQ3nvANZ5biPQtx68>
Subject: Re: [Teas] ***フリーメール*** Re: 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 12:44:44 -0000
Hi Kenichi, If the slice have flows from following three QCIs: 1: Conversational Voice, latency 100 ms, 10 Mbps 76: Live Uplink Streaming, latency 500 ms, 100 Mbps 80: Low latency eMBB applications (TCP/UDP-based); Augmented Reality, Latency 10 ms, 1 Gbps What SLO would you request for this slice? Thanks, Krzysztof > On 2021 -Sep-28, at 14:03, Ogaki, Kenichi <ke-oogaki@kddi.com <mailto:ke-oogaki@kddi.com>> wrote: > > Hi Krzysztof, > > Yes. A 3GPP slice supports multiple QoS, but this doesn't mean each QoS is necessarily associated with an SLO in my understanding. > A 3GPP slice is characterized with a slice NRM defined in TS28.541 Clause 6. Especially 6.3.3, "ServiceProfile" is corresponded to a set of SLOs/SLEs in ietf network slice. > We can map each QoS flow to a "SeriviceProfile", but this is not necessary. > > Thanks, > Kenichi > > Get Outlook for iOS <https://aka.ms/o0ukef> > From: Krzysztof Szarkowicz <kszarkowicz@gmail.com <mailto:kszarkowicz@gmail.com>> > Sent: Tuesday, September 28, 2021 8:39 PM > To: adrian@olddog.co.uk <mailto:adrian@olddog.co.uk> > Cc: John E Drake; TEAS WG; 大垣 健一 > Subject: ***フリーメール*** Re: [Teas] Network slicing framework : Issue #2 : How many connectivity matrices in a slice? > > 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 <mailto: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 <mailto:teas-bounces@ietf.org>> On Behalf Of John E Drake > > Sent: Tuesday, September 28, 2021 3:17 AM > > To: adrian@olddog.co.uk <mailto:adrian@olddog.co.uk>; 'TEAS WG' <teas@ietf.org <mailto: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 <mailto:teas-bounces@ietf.org>> On Behalf Of Adrian Farrel > >> Sent: Monday, September 27, 2021 12:29 PM > >> To: 'TEAS WG' <teas@ietf.org <mailto: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 <mailto:Teas@ietf.org> > >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas> > >> __;!!N > >> Et6yMaO- > >> gk!WDr1qyYuWTVcNfdWACFDBhpuWB09hOnRKbD4lEp5p3xxVzN2mQcQ2Ioh45 > >> z7At0$ > > _______________________________________________ > > Teas mailing list > > Teas@ietf.org <mailto:Teas@ietf.org> > > https://www.ietf.org/mailman/listinfo/teas <https://www.ietf.org/mailman/listinfo/teas> > > _______________________________________________ > > Teas mailing list > > Teas@ietf.org <mailto:Teas@ietf.org> > > https://www.ietf.org/mailman/listinfo/teas <https://www.ietf.org/mailman/listinfo/teas>
- [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