Re: [Teas] SFC and slicing

Kiran Makhijani <kiran.ietf@gmail.com> Wed, 02 June 2021 00:21 UTC

Return-Path: <kiran.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 D45BE3A2CFF for <teas@ietfa.amsl.com>; Tue, 1 Jun 2021 17:21:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.096
X-Spam-Level:
X-Spam-Status: No, score=-1.096 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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 mqzyoY9bk-CS for <teas@ietfa.amsl.com>; Tue, 1 Jun 2021 17:21:44 -0700 (PDT)
Received: from mail-pg1-x543.google.com (mail-pg1-x543.google.com [IPv6:2607:f8b0:4864:20::543]) (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 E8F4B3A2CFD for <teas@ietf.org>; Tue, 1 Jun 2021 17:21:43 -0700 (PDT)
Received: by mail-pg1-x543.google.com with SMTP id r1so769724pgk.8 for <teas@ietf.org>; Tue, 01 Jun 2021 17:21:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=THFxkx4OGcWblMZG9Tq0cJqRqGVa2qDAek+ygs929pA=; b=XdNDCbsxtpvccKBrzEJQCOCrGc14ldmFCRDHVmvqZdGerAuLng4/ZsxI7O292AaXip oLkxZ53/ZvztZLQf92aHi/K4qLHYFaK1IWT+eK/HkhZyWxD/WgAE4q6WWY8q7a8DplLF OgfstqU7jKCF4oAi8mJqrMFhPu7cQO//Osif6hWyLzlEaX9WxEmi2l1sd6IIF6WHJYIi GG1g/78bR1CK+LWKQmtfq1nhTxc7QiARLoTbwQbe8e544aFkYmBiQqJlFVNMLVdBn+7c ucF56ZcGxxBoZzhM98ywL91l9ezOLMtbFq8rC2VsF/i3ALSl/1sW4TScOxiKIsoB8FnO WF8g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=THFxkx4OGcWblMZG9Tq0cJqRqGVa2qDAek+ygs929pA=; b=J4KwH1qCuh5GtlvbL+Opyn6Hypw4zn+hoo4jays9aklja9SAqoUWauxVom3mia+ZrC YlkhzgRhb3GnFXaV3w2TR/w2MU1s9MOOryUimoegt5G84nLKkkxGTinjaNX9CyOrGfK8 14fHH3FXQJcyijPPlYZ3PnfLSKtAzMvXlWa6LmOhgTYUqsxeDEgCuPPaKVZlCy0iQUX5 wl3NJRbb/UvjQ0YlTNuIgBfnRb34HMOdl0dFpM787iN2BFoMbnB3/IwtsTPGqzZIwWpk WuGpiRteQf5CB2GpJ7Sh+7a1kbQgMQcA7BdvXzI8umN/3t2ELKyQZNx34JPze+w2eRIl ZL3Q==
X-Gm-Message-State: AOAM530DABzIjpzxh2CAeTQ7FwCK7vpMoGAmnLrkNMAPxXnboXOdISAI 9YvH93iN7rI7xcZPzXwt9jCLlgrTFbZJcDmi648=
X-Google-Smtp-Source: ABdhPJzd705GAhjROf871gnNhOuEvo7kxL2u0DE/cq5ONd+TIBxEfZ7gsyWbywuth8leehHODjbkrVD4RUj2dWb2/CY=
X-Received: by 2002:a63:4b5b:: with SMTP id k27mr31394970pgl.368.1622593302705; Tue, 01 Jun 2021 17:21:42 -0700 (PDT)
MIME-Version: 1.0
References: <006e01d74ffa$aec567b0$0c503710$@olddog.co.uk> <MN2PR15MB3454AF3E8DF6856B28F642F6A0269@MN2PR15MB3454.namprd15.prod.outlook.com> <011101d7509b$2fa58a90$8ef09fb0$@olddog.co.uk> <2071994812.1094145.1621867486287@mail.yahoo.com> <AM8PR07MB829560174D105F7E48CE3E12F0249@AM8PR07MB8295.eurprd07.prod.outlook.com> <1349297989.395114.1622050325766@mail.yahoo.com> <e68912da-6c0a-4230-859a-fdae580bd485@Spark> <AM8PR07MB8295D70C8940502DBD9A6F84F0239@AM8PR07MB8295.eurprd07.prod.outlook.com> <874243557.744362.1622124327990@mail.yahoo.com> <AM8PR07MB82956BFB8529B63AC54B0E8DF03F9@AM8PR07MB8295.eurprd07.prod.outlook.com>
In-Reply-To: <AM8PR07MB82956BFB8529B63AC54B0E8DF03F9@AM8PR07MB8295.eurprd07.prod.outlook.com>
From: Kiran Makhijani <kiran.ietf@gmail.com>
Date: Tue, 1 Jun 2021 17:21:31 -0700
Message-ID: <CAFV7YBpE2hOa57KmdeUz86CbXLguP713juNWexjJYaniL3kMhQ@mail.gmail.com>
To: Daniele Ceccarelli <daniele.ceccarelli=40ericsson.com@dmarc.ietf.org>
Cc: Igor Bryskin <i_bryskin=40yahoo.com@dmarc.ietf.org>, Jeff Tantsura <jefftant.ietf@gmail.com>, "teas@ietf.org" <teas@ietf.org>, Adrian Farrel <adrian@olddog.co.uk>
Content-Type: multipart/alternative; boundary="0000000000006c37a205c3bd71b8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/szvm1NkSxdtp2O0435LXrg1GL8Y>
Subject: Re: [Teas] SFC and slicing
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: Wed, 02 Jun 2021 00:21:49 -0000

Hi Daniele,
Apologies. I am asking a bit for a late clarification.  There are 2 ways to
read the figure you had attached earlier. I was not sure which one is
correct -

(a) A 5G-style E2E slice that has 3 parts (RAN, transport and core): In
this case cloud-orchestrator and transport-controller should be unrelated.
I mean the transport (-IETF) slice should not be concerned with SFs in
core-slice.
or,
(b) It has 2 parts (RAN and the rest): then the cloud orchestrator is
acting as a resource manager.  It could interact with the transport
controller directly or through the OSS. Both should be possible.

Ideally, SFs should be controlled from the NSC, since we consider it to be
both resource and connectivity aware. I would expect NSC to discover such
capabilities from underlying infrastructure and assign SFs appropriately.
This gives NSC better control & monitoring for service assurance. But then,
using NFV which has its own resource manager as an example, it is easier
for NSC to coordinate with a resource manager (maybe another type of SBI)
for SF changes. If  OSS control SFs, then they get pinned into the
infrastructure and there is no abstraction.

Just thinking out loud that there are several possibilities, and difficult
to capture everything in the current document.

-Kiran

On Mon, May 31, 2021 at 4:35 AM Daniele Ceccarelli <daniele.ceccarelli=
40ericsson.com@dmarc.ietf.org> wrote:

> Hi Igor,
>
>
>
> I don’t disagree with you on that. I agree on the fact that the access
> points are fixed and TE and SF can’t be solved separately, my point is that
> I think it could make more sense to retrieve information about TE from the
> SBI (from the network) and about SF from the NBI (i.e. from other
> components dealing with SFs, e.g. the cloud orchestrator)…and then used
> together in conjunction.
>
>
>
> I’m only questioning if it’s worth getting also the SF from the transport
> controller, forcing it to deal with a whole new set of information which is
> already available in the OSS.
>
>
>
> Cheers,
> Daniele
>
>
>
>
>
> *From:* Igor Bryskin <i_bryskin=40yahoo.com@dmarc.ietf.org>
> *Sent:* den 27 maj 2021 16:05
> *To:* Jeff Tantsura <jefftant.ietf@gmail.com>om>; teas@ietf.org; Adrian
> Farrel <adrian@olddog.co.uk>uk>; Daniele Ceccarelli <
> daniele.ceccarelli@ericsson.com>
> *Subject:* Re: [Teas] SFC and slicing
>
>
>
> Daniele,
>
>
>
> But location of  IETF slice access points is (likely to be) fixed, while
> location of SFs in required SFC may be not. My point is that you can not
> reduce SF-aware TE problem into two separate TE and SF awareness problems
> that could be solved separately in separate time frames with first
> addressing TE (connectivity) and some time later adding somehow selection
> of SF locations. As Jeff pointed out, this would work short term for
> pragmatic reasons (to show that something got done). Long term, I believe,
> SF aware TE should be addressed holistically.
>
>
>
> Cheers,
>
> Igor
>
>
>
> On Thursday, May 27, 2021, 05:13:02 AM EDT, Daniele Ceccarelli <
> daniele.ceccarelli=40ericsson.com@dmarc.ietf.org> wrote:
>
>
>
>
>
> That makes sense, an probably “awareness” is the key word here.
>
>
>
> In reply to Igor’s comment: I meant exactly the opposite, most of the
> network/service functions will be virtualized with the possibility to
> deploy them in a wide variety of sites (antenna site, hub site, central
> office, regional data centers etc.) and finding the best compromise between
> SF location and TE characteristics is absolutely a valid use case.
>
>
>
> The question I’m asking is whether it makes sense to add complexity to the
> transport orchestrator asking it to retrieve that information from the
> network or it is an info that can be passed to it as input.
>
> An example of request to the transport orchestrator could be:
>
> “I need to create a service with non fixed end points with these given
> SLO, the sites where I can place my workload are A, B, C and D”. When the
> optimal path is identified the chosen sites are returned to the cloud
> orchestrator to deploy the network functions. In this case the PCE has all
> the inputs to perform the dual optimization without duplicating into the
> transport orchestrator all the functionalities already present in other
> components of the solution.
>
>
>
> Both approaches would work from a technical perspective, it’s just a
> matter of understanding what makes more sense.
>
>
>
> Cheers,
> Daniele
>
>
>
>
>
> *From:* Jeff Tantsura <jefftant.ietf@gmail.com>
> *Sent:* den 26 maj 2021 20:51
> *To:* teas@ietf.org; Adrian Farrel <adrian@olddog.co.uk>uk>; Daniele
> Ceccarelli <daniele.ceccarelli@ericsson.com>om>; Igor Bryskin <
> i_bryskin@yahoo.com>
> *Subject:* Re: [Teas] SFC and slicing
>
>
>
> Daniele is correct wrt today’ deployments.
>
> I do think, similarly to Igor’ comments below,
> looking at further disaggregation (X-haul) and moving towards the edge,
> where location and proximity of SFs  becomes crucial to be able to provide
> optimized workload placement while still meeting the SLOs requested, common
> view of transport and service topologies would be needed and eventually
> would be interdependent.
>
> Pragmatically (and in line with Adrian proposal) - I think we should
> continue progressing connectivity centric work independently, while in
> parallel working on  SF awareness  and  end2end workflows/data-models.
>
>
>
> Cheers,
>
> Jeff
>
> On May 26, 2021, 10:43 AM -0700, Igor Bryskin <
> i_bryskin=40yahoo.com@dmarc.ietf.org>gt;, wrote:
>
> Hi Daniele,
>
>
>
> If I understood you correctly, you believe that SFs must be visible only
> to the orchestrator (entity responsable for the e2e service) and should not
> be considered in the IETF slices.
>
>
>
> I have two problems with this:
>
> 1) scalability: the number of slices that need to be stitched together
> would depend on number of SFs in the SFC;
>
> 2) The very choice of SF location could be optimized depending on SLOs
> between adjacent SFs. You seem to believe that SF location is always fixed.
> I heard people talking about duel optimization path computation algorithms
> selecting best possible compromise between SF location and TE
> characteristics of transport connecting them into chains.
>
>
>
> Cheers,
>
> Igor
>
>
>
> On Wednesday, May 26, 2021, 11:58:40 AM EDT, Daniele Ceccarelli <
> daniele.ceccarelli=40ericsson.com@dmarc.ietf.org> wrote:
>
>
>
>
>
> Hi Adrian, Igor,
>
>
>
> I was trying to think where this augmented (meaning: connectivity +
> service functions) model would be used.
>
>
>
> The architecture that seems to be the most widely adopted is the one shown
> in picture below. I would say that the NSC is a functionality of the
> transport orchestrator (pass me the term transport), but that component in
> many cases, if not all, will only be capable to see connectivity and not
> service functions, which most likely will be managed by the cloud
> orchestrator…hence I see it hardly applicable to interface B.
>
> At the same time I don’t think this model would be used over interface A,
> there I would see something more TMF like.
>
>
>
> What’s your opinion? Where do you think model would fit? A? B? Both?
>
>
>
> <image003.png>
>
>
>
> BR
> Daniele
>
>
>
> *From:* Teas <teas-bounces@ietf.org> *On Behalf Of* Igor Bryskin
> *Sent:* den 24 maj 2021 16:45
> *To:* teas@ietf.org; Adrian Farrel <adrian@olddog.co.uk>
> *Subject:* Re: [Teas] SFC and slicing
>
>
>
> Right. I suppose we need to hear from operators. Specifically, focusing on
> the delay SLO I'd like to ask:
>
> 1. Is it possible that requested SFs in an SFC need to be time
> synchronized in a client specific way?
>
> 2. If e2e delays D, how the network is supposed to spend the delay budget
> between SFs in the requested SFC:
>
> a) arbitrarily;
>
> b) evenly.
>
> c) in proportion specified by the client
>
>
>
>
>
> Cheers,
>
> Igor
>
>
>
>
>
> On Monday, May 24, 2021, 08:49:31 AM EDT, Adrian Farrel <
> adrian@olddog.co.uk> wrote:
>
>
>
>
>
> It’s an interesting question : “What would happen if the different parts
> of the SFC needed different SLOs?”  But that is an “if”. I wonder whether
> we can decide whether this is likely.
>
>
>
> Consider an end-to-end flow. We can easily decide on the end-to-end SLOs.
> For example, there may be an end-to-end latency requirement. But it seems
> unlikely that there is a special latency requirement between a pair of SFs.
> Is there an example, where the SF-to-SF SLO needs to be specific?
>
>
>
> Thanks,
>
> Adrian
>
>
>
> *From:* Igor Bryskin <i_bryskin@yahoo.com>
> *Sent:* 24 May 2021 13:22
> *To:* teas@ietf.org; adrian@olddog.co.uk
> *Subject:* Re: [Teas] SFC and slicing
>
>
>
> Hi Adrian,
>
> Thanks for giving to this some thoughts.
>
> I see a problem with the suggested plan if it turns out along the road
> that in a requested by a client SFC SF1-> SF2->...->SFn different sets  of
> SLOs  are required for each/some SFi->SFj links, as well as e2e across the
> slice. I suggested one way to address this by describing slices as SF aware
> abstract topologies.
>
> Cheers,
>
> Igor
>
> Get Outlook for Android
> <https://protect2.fireeye.com/v1/url?k=513a5706-0ea16fd4-513a179d-866132fe445e-e8d21cc567bd8f43&q=1&e=da75fd5d-9f07-47b6-96bf-3011c6879f6d&u=https%3A%2F%2Faka.ms%2Fghei36>
>
>
> ------------------------------
>
> *From:* Teas <teas-bounces@ietf.org> on behalf of Adrian Farrel <
> adrian@olddog.co.uk>
> *Sent:* Sunday, May 23, 2021 1:40:11 PM
> *To:* teas@ietf.org <teas@ietf.org>
> *Cc:* i_bryskin@yahoo.com <i_bryskin@yahoo.com>
> *Subject:* [Teas] SFC and slicing
>
>
>
> Hi,
>
> Igor raised the question of "reconciling" the IETF work on service function
> chaining and network slicing.
>
> Some of the early discussions on network slicing considered not just
> connectivity resources (buffers and bandwidth), but also other resources
> that might be found in the network (like storage and compute). I was one of
> the people suggesting this, and I know there were others. This would
> certainly go some way to bridge the gap to SFC.
>
> However, my understanding is that the design team (and others in the WG)
> wanted to push ahead with the definitions for the connectivity resources
> first, and consider adding other resources later.
>
> I think this is wise. We have taken quite a long time to get to this point
> (especially if you consider the early network slicing BoF), and it is
> certainly the case that the first deployment drive is for connectivity
> resources. Perhaps we should sort that out first.
>
> That said, I don't think that adding other service descriptions would be
> hard. It feels like the definition of further SLOs and SLEs.
>
> If we want to continue this discussion, we should probably involve the SFC
> working group to see how they feel about it. But anyone who is interested
> in
> this could certainly begin work on specifying the SLOs and SLEs that they
> will want to see added to the NBI.
>
> Best,
> Adrian
>
> _______________________________________________
> 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
>
> _______________________________________________
> 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
>
> _______________________________________________
> 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
>