Re: [Teas] Network slicing framework : Issue #2 : How many connectivity matrices in a slice?
"Joel M. Halpern" <jmh@joelhalpern.com> Thu, 07 October 2021 19:27 UTC
Return-Path: <jmh@joelhalpern.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 441623A0DDC for <teas@ietfa.amsl.com>; Thu, 7 Oct 2021 12:27:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.901
X-Spam-Level: **
X-Spam-Status: No, score=2.901 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, GB_SUMOF=5, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 e-lqjhkQhg3u for <teas@ietfa.amsl.com>; Thu, 7 Oct 2021 12:27:47 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 A83903A0DDA for <teas@ietf.org>; Thu, 7 Oct 2021 12:27:47 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4HQLv73VJhz1nvgh; Thu, 7 Oct 2021 12:27:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1633634867; bh=+HfbGqHKJRaf8Gl2Q8GIq22eP+Uqd4o44aP1cwI0VrM=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=TBQgh3BSLJIKAAiOuIC8CDCz0v14qLyj+f0gVWYeJg5/TN1jUQ2CLKA/0sZ4iy7KS lpbGMuF7MzH50TkyikZNz7j5dhmi0Tnx5h4HKtgrzDCnfhz1oD2hxMVr4Kjh0fhTqt Tmu0XJfUaO8dife5/qMHCFO3bRzcNRaMItYrETBg=
X-Quarantine-ID: <GPuf-NYr4yFX>
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [192.168.22.111] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4HQLv66jKNz1nsr0; Thu, 7 Oct 2021 12:27:46 -0700 (PDT)
Message-ID: <45638550-4da8-ae0b-fb23-b9ac53569e67@joelhalpern.com>
Date: Thu, 07 Oct 2021 15:27:47 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.1.2
Content-Language: en-US
To: Xufeng Liu <xufeng.liu.ietf@gmail.com>
Cc: TEAS WG <teas@ietf.org>
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>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
In-Reply-To: <CAEz6PPT2=D1qN+n+2RjR9NweUBnAefUBhX+XMOccoOwo+BtKVQ@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/v7b40J-2wNeNQj3Yx_W3tSBKPTA>
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 19:27:53 -0000
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>> 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>> > on behalf of Adrian Farrel <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>> > *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> > 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 mailing list > Teas@ietf.org > 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