Re: [Teas] SFC and slicing

Igor Bryskin <i_bryskin@yahoo.com> Thu, 27 May 2021 14:05 UTC

Return-Path: <i_bryskin@yahoo.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 E534D3A0DB9 for <teas@ietfa.amsl.com>; Thu, 27 May 2021 07:05:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, RCVD_IN_MSPIKE_H2=-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=yahoo.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 2_3O-nUi79YR for <teas@ietfa.amsl.com>; Thu, 27 May 2021 07:05:32 -0700 (PDT)
Received: from sonic314-20.consmr.mail.ne1.yahoo.com (sonic314-20.consmr.mail.ne1.yahoo.com [66.163.189.146]) (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 773543A0DBC for <teas@ietf.org>; Thu, 27 May 2021 07:05:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1622124329; bh=6YjpOhrevp3pPKCFEQnX690nYTSu9HF6yN/MZh9q28Y=; h=Date:From:To:In-Reply-To:References:Subject:From:Subject:Reply-To; b=kcER2gl1lYlJwnW035HzSEjV7uzxHkuVRru+Ot9Mc5RpOFYBOoIaKapWntp8xY6TsqAxd2QV6n8oNZKf1hhiUp6lsf4MsTBoGTJ1fw39b5ke4eBkxVnPsLPaNNEfycTZ/41CFo9J/QOgiFIf8LLM1C42/sHosuaTRqOKWy6M+Vk1lOt6VKp3apQtRMmTqk0E++LABIJDsvWgu/81e0OZCs+1bbK3SP37h9FAhnMEzIoquFQn8nmkmmsh6ytk1HsjDr1hq5UxppApYFQlrq0EbCIzgal7Rvzn7fWDi2FOAMHgkRtjlw4bXHuqMQiq3awg5VVS5fZ5MHSYTn8ZcNKKhw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1622124329; bh=nQrZj5kJiDpf+BEUBk219yzo60qnDfC7nS8jjaOxF9a=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=r9+a5GQw10vg//D4yqI4Aa0w8y7gz9hV/R9T+bTyalE6gzK9ofUSisrJwdTtECPsWSMm/8FeJgcdvCiBl0y7Vy00syvL75EKTOTDQOAhHMXGjalclumyiE2yeUH/6sw2FdCb2mH4QWDwrijjdxHtzJdgKNXlbpWg7vQYQv4xQcZ3N045rF+5RmFfM4UaD1fxieBuJ6iXRmAY8klIf/HGVfdQUWoOdDLuL0XwKMdJX0gJuCJIe03GlgLDmAZA89/auwJTC78uuVurlcrlHF9WV8JtXq4JrYRqjUtfNU3u+mk0irhXfUd9YigSf/bVf4SebaFYO4o6kIywerOplr4vew==
X-YMail-OSG: EfS1JN8VM1ll3IGXb2JAT6BBIrWBwdNg9aH966s2ItYmKwlG1BZxz4D6TGXZ4d4 Yc8LRiBoRwaDJIPnxbrgEG.NU697U3BuyguK1fyXOBCmoHYSbc.a.1quu16DDTnNyc0RFN4uQB47 WHXk7nXa9xQGH9ydNDeZf0Ew.xdLG1_74bQYH0PxyZ2pBcIRwOCCtwAvP_s1EZomYZthKWFgrXvM hIR2G3ogCUXjunMTT7Ko5_jRWuAjmJkdAD69ZEKGEZeYD5XbUNXbURa3xCK14ZYa.7O7RTx2xyvu 9pigdhOGcIk_hy4ukXymNGMrzi1JPaVn5YvYYInPOZWZrvT18IDlagAlSiCUDKtIvDFcXHyWlq44 5Yhyxcn44I_QoVyKiZodl..vxCM39l3yfWuMUtPf5eoFu8mDOUwfi5.o.hHudBlr.Uj9Ll9ww9.H 5IKRGIHpNsydHF31o0vzKrZf_wPrqpC5t50f2HblKvoe5SyNDXx1JgphpUrrRkASR98qm_Jeow0r aRuXZirs3mZg8Y8.c479Zgfmow2upYSLw0xs5JJ3j19VfxjAOE9bsO1IL_Pc8p0542fHdhHwjQy1 5jBV8L59vEQEHzQ2Cz6XDEWnSPZocnRcmFj1IWf6Ix2ZRLQxC_4c9zJ154iX9mUrREC5DppzuRFa a_OEAPK79kkIWQMD9hExPMDtFe2m7zfJWNzYZt63Xu1aJSGBFstp1Q5an03eGDWoR8077S2vn8uW zg4iX8EZ8p.yY6MkHdwm.NdaZft8VmPLKsOd8xHk2zbmKv9gmCgwsl4cDtNDiAT7L34zvMo0OMtv NerK1jX6mQsvhLAm7rywCdRbCGg52CGsN5ETqgId0xgBjZsYQ11Jh5WEjjPoS.CwVPuKopCCPMn5 zxkJ.hA6F5PpvAy4FaBduRqAqySrwK8vuzkjS6uv3dNxDl0HqZ1b6kJEqJTYCe6LpXsZPJYZRpXR 7xE5Yte3HEEUcmpjN3sGjtWWZ20Tzyjq1GBsYfyeKIMcBCWjsdtbF0TfALGiCtEe611lfzP7EmLu LvbKzVgJE4p6hcJA2yIzKl5OBYnqQQNOcQynTYZa.SP5exK1yDyQ4LpC1yiosHthHSSsQdLkkeBq lHDhm_vgJqS71fZqS4NwXOAVi4J2ha3RQtJAhA3tykS6AtMiD9erojIyDPoLvKN7d4MFxkyUWTmN x2VEl_KyL9dhJKtJ0gtQDUbVmbZOm0ugzeBi3wpzCOiDg89U5u5f3RC0xLvfVbplvTufdte6TJRl RmxUiPj.xef0YJI3PG6HQmPsmGOygEWJNdZfFfPn.hpNAAw9Q4Unf7Zj4bYgBR5JdPWIDssSbZL1 R715etsEgo5ZOnmowUYvVUeUibZtc4yv5k7Qkx_DVZ.UbZy22gUhItT_7Dt0Xw6DL.pq9ynEH3PN kZHp6Tq9ajZIgUEsgskTaBPirM8oNtrpOLwOy.fsjEhSXU408gA79CFnj3xYRboblRv9b6XJ7R8t hhxBSt2leOHYJvRg6gv3NQlBQ5rqt2l0e_5ZdOauTwsWcTamceUii2VMhUbm68qNkZijk66c70hR BSCb0GTfc51A9bpni9aSsABmoHOs3pTs7Jg_EzEoQ0qYMTyHyXnR2.X7EC2c3_UKH4kkdbFlXvU0 Y08F2D40mEMWtSi1NAzZnZ4o9psYOkmyD4NBqNMfqPgb742UXbQyHbMXt3P.IbQ_ZybF5wzFnIju erJLswHoHsHEg6NWMkIWaYQLlDX2Ce.BQ9whNedQeyhvK7bIGyc8WAu.kodGNHsPA1S4ymSpnzSd x4c7RCRhU73ZQj37nfHcgQ7t01P6qqqcft0Zd11AUEYKCJ1lLo_FW5Lou4lVK2CKTsV3tHWeecaM C0M0hFy9NDQIzrpLN1CY5joEvg3hpnEln9SjdwBRyBtmxOkI1X_AG6rcTY0vPAwzlHIWrk87.DzQ xAYlHzS7V1fVUyeI5tdAiVi6ii34nudi3Zo9y99bIngIhtfgiA23_.evbpFiYFd4HjvWClTfIXNz 2vKBgkr.3F.T2_6QVx.F5OMR_xNBNxlQSubdiIJ2I7Mf37TWVzJg5EXnrCU_LYRhQcTbsQ3m0IBi ux7.Z7lPyrls_YPrEX1gJWIKsigsRjb3baSNe7iZ7cIgLOr1Ky6urBrO8jLLqFS55stI7oUPhIhY 2C4wk6H9qnu0wrl2FnuH2g7REvSXysz8qNLaOAZ3SyaWQbMaEVYmupdDUKb8sDS.z3ER4kFpb5Rl YTGxUY7nKa19Omxucuad2HP3ppIXoPKB7ixRiGX8D582xFUjfb3FVOyXsTOafkVSaAX5itUrYh9J CccrgOPv9eibQPY2q5Tbjb3lFH0TiD6CQn0CzAn9FtVJa0lKZKl4QFosRy224F7jaxTFLiMdbSS0 6W6pHGkX9gJjwGqdeZodeMbNfMNm0s8BUyGJnEL9u2THda42IrSB1cRJ93mbNcaD2dEDZtpj4pjj yjmSb3I_UbPLDkzIzk2kIY979Fs3.Tb2oZwEm76oGMIYI6WODfOA0c_95Ya.0QL4Yq9MNppsNnrR 4eSOZCN.DGGd049zeh_rXpkZVZ8JJlX7V2_v4a_8GF8YxAjSVMs9gjmGF4yiEMg9qhg--
X-Sonic-MF: <i_bryskin@yahoo.com>
Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.ne1.yahoo.com with HTTP; Thu, 27 May 2021 14:05:29 +0000
Date: Thu, 27 May 2021 14:05:27 +0000 (UTC)
From: Igor Bryskin <i_bryskin@yahoo.com>
To: Jeff Tantsura <jefftant.ietf@gmail.com>, "teas@ietf.org" <teas@ietf.org>, Adrian Farrel <adrian@olddog.co.uk>, Daniele Ceccarelli <daniele.ceccarelli=40ericsson.com@dmarc.ietf.org>
Message-ID: <874243557.744362.1622124327990@mail.yahoo.com>
In-Reply-To: <AM8PR07MB8295D70C8940502DBD9A6F84F0239@AM8PR07MB8295.eurprd07.prod.outlook.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> <e68912da-6c0a-4230-859a-fdae580bd485@Spark> <AM8PR07MB8295D70C8940502DBD9A6F84F0239@AM8PR07MB8295.eurprd07.prod.outlook.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_744361_1326438018.1622124327984"
X-Mailer: WebService/1.1.18368 YMailNorrin
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/yMdDH6hIEckqD9t3wLTe12p9SEM>
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: Thu, 27 May 2021 14:05:38 -0000

 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:  
 
 #yiv1283125335 #yiv1283125335 -- _filtered {} _filtered {} _filtered {} _filtered {}#yiv1283125335 #yiv1283125335 p.yiv1283125335MsoNormal, #yiv1283125335 li.yiv1283125335MsoNormal, #yiv1283125335 div.yiv1283125335MsoNormal {margin:0cm;font-size:12.0pt;font-family:New serif;}#yiv1283125335 a:link, #yiv1283125335 span.yiv1283125335MsoHyperlink {color:blue;text-decoration:underline;}#yiv1283125335 p.yiv1283125335msonormal, #yiv1283125335 li.yiv1283125335msonormal, #yiv1283125335 div.yiv1283125335msonormal {margin-right:0cm;margin-left:0cm;font-size:12.0pt;font-family:New serif;}#yiv1283125335 p.yiv1283125335msonormal3, #yiv1283125335 li.yiv1283125335msonormal3, #yiv1283125335 div.yiv1283125335msonormal3 {margin-right:0cm;margin-left:0cm;font-size:12.0pt;font-family:serif;}#yiv1283125335 span.yiv1283125335EmailStyle29 {font-family:sans-serif;color:windowtext;}#yiv1283125335 .yiv1283125335MsoChpDefault {font-size:10.0pt;} _filtered {}#yiv1283125335 div.yiv1283125335WordSection1 {}#yiv1283125335 
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>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
 
GetOutlook 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
 
_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas