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

Xufeng Liu <xufeng.liu.ietf@gmail.com> Thu, 07 October 2021 20:42 UTC

Return-Path: <xufeng.liu.ietf@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 02B9B3A0E3C for <teas@ietfa.amsl.com>; Thu, 7 Oct 2021 13:42:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.903
X-Spam-Level: **
X-Spam-Status: No, score=2.903 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, GB_SUMOF=5, HTML_MESSAGE=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=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 aYRX4UcMjJk7 for <teas@ietfa.amsl.com>; Thu, 7 Oct 2021 13:42:54 -0700 (PDT)
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (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 C37D23A08A5 for <teas@ietf.org>; Thu, 7 Oct 2021 13:42:53 -0700 (PDT)
Received: by mail-ed1-x52c.google.com with SMTP id i20so11834683edj.10 for <teas@ietf.org>; Thu, 07 Oct 2021 13:42:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2fWbZZsVK1UVZ/xJgKy7aT8ZqeuQWpF6UuvMO7FaKZo=; b=iFqUPsuwjdr/LO6Y5xRgBOO0Gcu9pLTkMy439SdrxsX0Z+ERbcZcR8t8xnTosMf4Ab M42uJBiIqdeJlUu+oFXxELAfGhs+SL0BaTHU/nyyEoU+w0jfJkhggk+HFQAuDDde9htO 7rvF1cMMGX+Zz1cyTrcwiPhOoJIj0KXiv8x8oumLYiZrUCUOeAsK52jRTgBO5rnghQPU ycdm56g4Zj/D0/UmppS+KusIAu3cpJrB3MaPKOeDN+Jdy4vUImrL8ds9VAO0VbdnSrqB m969QjKYEpb7jDSLQjq1ThIdWBXfsK/f4U23jMCgMvy2EaFVOyehqWft9Drsxsx2n+Y7 gUXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2fWbZZsVK1UVZ/xJgKy7aT8ZqeuQWpF6UuvMO7FaKZo=; b=giQLqIwjuOnO7wRFW/3wwaYdzxfP3xOAnGt0xSZRb887RX89nSfqo3M7c7VqyGmhgc gd6hqSZsRb0Wu1dpNkVfTfHkx35vRgrA/du+O4KuyBOHRAlUXyL5wsEyrK3/es5P1pX2 fdN/d6kMJq4GzsZe8DF/Q9u6WAz/bgg5LthOEXfsuB825atr2qsOIhhYMqfG+kstWiAv rLQFLscfMHv5vlt23l4gcrY4BoJJrePrXhXlURTMyT5wU1C9y2BZ53hB2AWwwm4/YrgR ncImyIJBkvxuAMB6p01tioBsRgei1v/uHltqbcJzQs+z1c2PvtHh+btS+EXo/jFLQNvK FRQg==
X-Gm-Message-State: AOAM532fdAXnHvES9iu+9TcJUzvOyY7NyBX0hYw8j0IVympawfkrtT5O Ulq23bf082/+oQsZjebV3B48DeGZ74TZv0Lmej3htDUn
X-Google-Smtp-Source: ABdhPJx4L2uRHg7DWvF101mR8wP1fNSI5du7qwHlxL0fPiU0GnxaWSke4hfNu3NEFoX/c9v44ahwvuXZDzwx+kUZBNE=
X-Received: by 2002:a17:907:784f:: with SMTP id lb15mr8059041ejc.260.1633639371208; Thu, 07 Oct 2021 13:42:51 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <45638550-4da8-ae0b-fb23-b9ac53569e67@joelhalpern.com>
From: Xufeng Liu <xufeng.liu.ietf@gmail.com>
Date: Thu, 07 Oct 2021 16:42:39 -0400
Message-ID: <CAEz6PPS-pupMa9YVCFZu1MfFkwnuCMj9bMcXTrQSbE4L8yP_hg@mail.gmail.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>
Cc: TEAS WG <teas@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000697e2505cdc94ef8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/sGsKOWCUwrfFihDZDVGST7jQfik>
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:42:59 -0000

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,
- Xufeng

On Thu, Oct 7, 2021 at 3:27 PM Joel M. Halpern <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>> 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
> >
>