Re: [Teas] SFC and slicing

Igor Bryskin <i_bryskin@yahoo.com> Wed, 26 May 2021 17:42 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 789CD3A11FE for <teas@ietfa.amsl.com>; Wed, 26 May 2021 10:42:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, 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_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 dF00sRNYemj5 for <teas@ietfa.amsl.com>; Wed, 26 May 2021 10:42:10 -0700 (PDT)
Received: from sonic306-21.consmr.mail.ne1.yahoo.com (sonic306-21.consmr.mail.ne1.yahoo.com [66.163.189.83]) (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 DE77F3A11ED for <teas@ietf.org>; Wed, 26 May 2021 10:42:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1622050929; bh=zJPOQjbBUBAMF2EtRHXM+2DJOXHzQf1CwA0CdQ2EkwU=; h=Date:From:To:In-Reply-To:References:Subject:From:Subject:Reply-To; b=D667UXTQAcwrPkqqsNrzI1SXH8wj24R3si8RsDtkl5nmUlfaoAj6iKhOIaNBvAPWcorVGtN9vXow1skNGI47xFcfwKoos2a73Oak9zUdol46tu9mzL0p0b6//xTmOI89SOFNR+WU8i/TqJAyHQcRMa9LccoMsiOflP1bFjnP4yIOV+uIQt9soCUtmXqJGzsGkew2aIkmFIAVL0yPPCjPn7ESBFoO8N9ZkZf30LHh6iUPXvijEdNl04498FizHNiEOrAQCD0OT4sa+mhR53EkbWcGYZ9MGgaKJXqE9CPdDs1uDi7ooq/7+B4LxxtbOPeO8TWTGwxpF9PGVpj/I6kaSg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1622050929; bh=nRB8BxnWhRW5yw3fevndQ0MjPq6c8Q7orx4QOQiWIny=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=Ck6vCnC2kdFs+f8ONfcahOQWkzpQWoPEvISczAQhL5xTm6W1zxWAyiULecTv29rdj+qq6nLn3vEMFnfDggVPJ3xK47mYupjtTLm4m9Ai0ybPz4O6dUc6/IFDLdOdF40ZGVPlSIdlIIEElHYFNXMp7dFk5DSS3jlCojbEE9rHYyrmv9xogNHoOmwnrI77AIev2xZZfwa8PpBo7JZ4rx+J1WtNVXEYt1xXumXAPId2rGFKcVOmXzKQzfSghFCHuTth8P43e6ya0psxQjto3kL0Clyr/XdeGu14SLliDcMLFC6gJYp2uF+MLf0bDKoPUiT/y0vYCH5sHIYeo/9NqCxXmg==
X-YMail-OSG: LiKIhtoVM1k5sjZ497_k3wPy8ulj7x9B.963V4lxToapJJpqMkFOZb_efCgmzBt 4DmAD.1LaieDHqRN7m7JPuoY.g.yRsd_KZSVlipEq4ajIhDOjm0_RQ5m7gQzd3ppGCJ2MP0g4_HG tMJU7R_uyfdUg0K_XS8ILPwohKKv6KiUvWfIaZxdpTS7pa_.T54oCvhbxYbrfO24RDCySVMgQhN9 a.7eURiSSEwKHaF1WMXK4KrM1.ZSzy2vuUcmkL5CopF1mhW3FTXmUb.CaszNWRYPj2.A8yYodK0E xarrDYen8gBzIzxmqpoKBb0Lz_ssccsAwTrL0TQUMJAbvcixlZNm8AXawXEnHaeURvlY087aBJhm kBJMgNOrq3CxrdnaDVbXzj9XDrRCM03M9KHlqKTK7D9agz_xn.lgG1HCE0FxfjTPKxnbJqApDL8p 2BRUVzK9WqxSPvWAxs_n_2pNfrtgpm0WoD9w6wbUqbl0H6wAUZ2CkKXYOLZ6GiaZBbpjH7p1jjNJ ftJQ7xi_KhOykhFkYaDTaVuA.y7sYg27tGnhH6rM.ov.yGJBfdGyq7xfcqNa_tgkz2wd4FRLkC7b YE8NSXUOk6sXP9OtjHFCopuEM35TB3A0TAJ5Fg91oqAF0qNPvWiDztBAQWsa78CTwlCzqsH748ly q2z5Gj1RONpIvcNSr02yGwPeY3kbAumOoQJjZYKupQsLbxVn6Yxst1HPmiu4x8tEJ9PM2IA6F7ba BRCGZzRq20JNrihiFlt_2YC6MlDVeaJPl7BPrsHHstl563KD_FKWs7ofEHVPpgwzR4bSeH4tvMkj YgwMxw2IB6s5ZFHKzHBPI_AgzA8M9FWZfu5IiK6JvAeVMxczZycdpv_Lrmi1Sp_sLWcHCULeUh4j SV_sI.Tt4dAlbkDOOd5tRsG_3BByI8QWluV8vcQI.q22NqQLbndQSmokaXepErrrsfSAT1s6B15G 1UI1a6U3Yfitfm_INOG.YUvCQkSZ_CD875jJq9bzWcQlRlh0OVTLRvcKajNvbRppvCXG0Ck87s83 2ggZWPSAYiEAUBWxF4uN9c8th46JU477nafYxLS9.SMSMOpAg4LRVa..dau1IY3A_sQskvslzcne 3prHeun.29.0k5ZNnmwgSX144UJWNL9YpAjkJGfBDcMd1CuqYj9IHUVR.9lu.TieJ3LuB4vpw8oQ V9EsGEkNDplJnWMwajTKhksPVzQgv5X8BpsYHjOE4UkPwhSgkJO2f_BvGDQ2P2GUXhGxvCsdwgzi uWjXDDdUpaQdLfjJ0JaONxNoA0QZNdnEDomhmlBH2bjOmWITz4zd6kUYDNjN0JVwng95dd.mACnj mGQwkd5faJI7wJlqtzpSloOC6uTC3OqwB7gB_0ZV72DnkhrQ9Cx7wewSxM4DU2WVOOLwvagVZQQp luJMSNmRST.nTmFO.Iv0K02N.V8uRp9WGbGIibn3n2iNCXzVEBeJmzziKZYPsHYcn2cc7re.oYu1 jC3eGFoc1m5sm3VxsnhPtXi4ellzbo9cigm6k6UGNU1LaiUxOWEteK3IjuHE2LPnGa..VPyMB5Ud BBBdrcU55.t0Z6VIGk5XosXo1D_0Qs5Efzri9fxlbvSoKSSxgxh5iSPW_5Uo3rcHKmLuQY330Sfg GyMSY2tbPMmke9enH38jAang5Za_eSlHHBkguCPv4yWsYZ0mtXIyhC3_j5bvC8Xw8n0diP.Py6Tl 3ybm9NgfOysaTYsAjNreng6uFICzyg.lc7uq6choH.yX5D5B774CVFdKtlYmsWczoMroZyrFwgGU 7JeLHuDtSpktXN0GP6c67sCWiq.A.siOO7t4OYwNExpePlKEKMHzYmBjD.VbEIN43X3BuQagTOFg o2q3AfSt58Hxh7J2PdUZORPRhyc5QeS.rsGAOTzOxCxhYi_w2dCm2rmAGalEwxbJSdqokLJsouyN H15.9AAi6dO7wjCI2CUusd7UfTW60sL0tJd6rlif8Tl6IfpHkbOt0KEJHGsa19tOxDjf1wbrgg9I o2HjzNhvWF753MjAX2maNDrZmHPaFfovAFRLE_P_odFJ3YrY6mdPUmZVchbZ3FOS5QbAnjcTMbkh DR7y.OIR2jqu4SBgXiJn0ROkKI68Vli0BCdVcFu.Z1vnHIvHIlTpZ2pGnnPp5w1oXK4I5jOLo5Jr zHKQjCVlCXEvl2KNvu0RYJ0E2T6pFqDj1e3GluXpBcU0GkKXcyp5QcXxb9V_n9U0oM1gJAEeNgNg qfgJv8MtocHYCS5iicb6kM0VKsAoVn1wu7N7yPK.v4m8s7LT1v34nWsshxAjbOsZgUQOcmNiaPKf OpQsAjNK.ufDrv.2hY8h5RXYNWPhFzqavcO7KBkYIRZpVwzMlsPK2_aIWYINbATbCOnOMAulueFS osWMn_D3HtV8BGkK0ZEqhikeP61IBiPqIfKGqoU6dzkOxqdP_T6ikmM2KGunELp7ZsCSKsToZsqd 80asFuUiiR14xyjpu06i4d32wuIN6dX9iu3By4gJQxkifm9pYmg2iS0OOohAlnF_wIuXgG0PclU0 pmrVgP215okyStcQeH1v1JqqqtHQA1hBDXUEozv0r3qSRlyPb_Q8nVeUl_zDf_i.qH4UClt9YgqG qmP.jOa2BlWBnJjM-
X-Sonic-MF: <i_bryskin@yahoo.com>
Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.ne1.yahoo.com with HTTP; Wed, 26 May 2021 17:42:09 +0000
Date: Wed, 26 May 2021 17:32:05 +0000 (UTC)
From: Igor Bryskin <i_bryskin@yahoo.com>
To: Igor Bryskin <i_bryskin=40yahoo.com@dmarc.ietf.org>, "teas@ietf.org" <teas@ietf.org>, Adrian Farrel <adrian@olddog.co.uk>, Daniele Ceccarelli <daniele.ceccarelli=40ericsson.com@dmarc.ietf.org>
Message-ID: <1349297989.395114.1622050325766@mail.yahoo.com>
In-Reply-To: <AM8PR07MB829560174D105F7E48CE3E12F0249@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>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_Part_395113_1007670075.1622050325766"
X-Mailer: WebService/1.1.18368 YMailNorrin
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/U0vM4EtRS-mwj5RnwndEuqWKA28>
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 17:42:21 -0000

 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:  
 
 #yiv8543116016 #yiv8543116016 -- _filtered {} _filtered {} _filtered {}#yiv8543116016 #yiv8543116016 p.yiv8543116016MsoNormal, #yiv8543116016 li.yiv8543116016MsoNormal, #yiv8543116016 div.yiv8543116016MsoNormal {margin:0cm;font-size:12.0pt;font-family:New serif;}#yiv8543116016 a:link, #yiv8543116016 span.yiv8543116016MsoHyperlink {color:blue;text-decoration:underline;}#yiv8543116016 p.yiv8543116016msonormal, #yiv8543116016 li.yiv8543116016msonormal, #yiv8543116016 div.yiv8543116016msonormal {margin-right:0cm;margin-left:0cm;font-size:12.0pt;font-family:New serif;}#yiv8543116016 span.yiv8543116016EmailStyle28 {font-family:sans-serif;color:windowtext;}#yiv8543116016 .yiv8543116016MsoChpDefault {font-size:10.0pt;} _filtered {}#yiv8543116016 div.yiv8543116016WordSection1 {}#yiv8543116016 
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?
 
  
 

 
  
 
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