Re: [Teas] SFC and slicing

Jeff Tantsura <jefftant.ietf@gmail.com> Wed, 26 May 2021 18:50 UTC

Return-Path: <jefftant.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 B00563A0A1F for <teas@ietfa.amsl.com>; Wed, 26 May 2021 11:50:51 -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 w5cP94MhYqd4 for <teas@ietfa.amsl.com>; Wed, 26 May 2021 11:50:47 -0700 (PDT)
Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) (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 0F8903A0A16 for <teas@ietf.org>; Wed, 26 May 2021 11:50:46 -0700 (PDT)
Received: by mail-pl1-x62c.google.com with SMTP id v12so1075614plo.10 for <teas@ietf.org>; Wed, 26 May 2021 11:50:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version; bh=8FvTFmms1Of2+YyccpphosSLew7b6UKgTMONBeOhuQY=; b=LeXw+J+lCACR0v4wrRU+u0a99IwrQsgqKunSxAr5kebonKHp4FZKNe1IAPmZA+fdIX qWJpRXORLgF3e+gshxKjrYzSc/ExiccXrCDyN6An/ijk8+mm4keReYAbZ+C54uL4gTPt Qe/g3ON72acBf2wjUbrktRcsgyAGyskYTz3955ANnnY4TnpUQ4bZ9IB3VpfIVrtAwG8o dbczYg5bbVayDhmxjwMw8gdgtyt7UVp8LbI9/IgVRk8W4lBfTdDA7TlQZuD3WZ6RX3Tm vJEHiTliw/1tZsaJjRPlrL/gdNYY2r3zbS8CvxzB6vqZtK1XgURQF4x1gOOKLJoX/EQU sYCQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version; bh=8FvTFmms1Of2+YyccpphosSLew7b6UKgTMONBeOhuQY=; b=cJcs34r4W0Ul/jSbKIaB4E5mSrMgWgP4EzoIZ839ITY+TYyoMVvjlGngShBjqHw23U 9DcRDu/+9Gt5a2xxmVlV7W3OV8+k2rlfGJUdGrWfnKEoh8OaeelVnj+fUBnAIEvaHjkQ Kf7+wtJcZBdd8oFL2cun2lLbFIH16px3k0d9H+zus3NUkFTvvMX6d7H7gu4kqDVaZf1b maIP6w4wJ+OtEeLLbani4mZNjZXVjLK2F5ZlFmcSnFQg0sy0IPr9O9mDQv5ec3G6v77c BXuPDkda36IlCaccqcyzXCod9sexFDgeR9KB+s5HSH3Tb02QZlREnnWFmm0esQrDXmIh F+xA==
X-Gm-Message-State: AOAM533VYsQinL0Qsb6g+wGiusJaLLVXCUUMiJ33Z/iQ4/HcPQn/9E6I CBvvGME9kLK57S69eG7TjV4bEI7FlJs=
X-Google-Smtp-Source: ABdhPJw6B0eG2mhcIhz7e+BpJEuYDsMYDS5Hjz4uk4JH6ILeFnAAtmretclnnc31hco8X8q5NQBL5A==
X-Received: by 2002:a17:90a:dac1:: with SMTP id g1mr5275022pjx.199.1622055045803; Wed, 26 May 2021 11:50:45 -0700 (PDT)
Received: from [10.117.0.59] ([66.129.239.13]) by smtp.gmail.com with ESMTPSA id q23sm97040pgt.42.2021.05.26.11.50.44 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 May 2021 11:50:45 -0700 (PDT)
Date: Wed, 26 May 2021 11:50:38 -0700
From: Jeff Tantsura <jefftant.ietf@gmail.com>
To: "=?utf-8?Q?teas=40ietf.org?=" <teas@ietf.org>, Adrian Farrel <adrian@olddog.co.uk>, Daniele Ceccarelli <daniele.ceccarelli=40ericsson.com@dmarc.ietf.org>, Igor Bryskin <i_bryskin=40yahoo.com@dmarc.ietf.org>
Message-ID: <e68912da-6c0a-4230-859a-fdae580bd485@Spark>
In-Reply-To: <1349297989.395114.1622050325766@mail.yahoo.com>
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>
X-Readdle-Message-ID: e68912da-6c0a-4230-859a-fdae580bd485@Spark
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="60ae9883_2ae8944a_3c4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/UyQTVeLGqVxupuZriPUvrWeWCps>
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, 26 May 2021 18:50:52 -0000

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