Subject: [Teas] SFC and slicing

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 23 May 2021 18:40:11 +0100

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

---

From: Igor Bryskin <[email-masked]>
Date: Mon, 24 May 2021 12:22:05 +0000

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://aka.ms/ghei36>

________________________________
From: Teas <[email-masked]> on behalf of Adrian Farrel <[email-masked]>
Sent: Sunday, May 23, 2021 1:40:11 PM
To: [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: [Teas] SFC and slicing

Hi,

Best,
Adrian

_______________________________________________
Teas mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/teas

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 24 May 2021 13:49:06 +0100

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 <[email-masked]> 
Sent: 24 May 2021 13:22
To: [email-masked]; [email-masked]
Subject: Re: [Teas] SFC and slicing

Hi Adrian, 

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://aka.ms/ghei36> 

  _____  

From: Teas <[email-masked]> on behalf of Adrian Farrel
<[email-masked] <mailto:[email-masked]> >
Sent: Sunday, May 23, 2021 1:40:11 PM
To: [email-masked] <mailto:[email-masked]>  <[email-masked]
<mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]>  <[email-masked]
<mailto:[email-masked]> >
Subject: [Teas] SFC and slicing 

Hi,

Best,
Adrian

_______________________________________________
Teas mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/teas

---

From: Igor Bryskin <[email-masked]>
Date: Mon, 24 May 2021 14:44:46 +0000 (UTC)

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 <[email-masked]> wrote:  
 
 #yiv8485934124 #yiv8485934124 -- _filtered {} _filtered {}#yiv8485934124 #yiv8485934124 p.yiv8485934124MsoNormal, #yiv8485934124 li.yiv8485934124MsoNormal, #yiv8485934124 div.yiv8485934124MsoNormal {margin:0cm;font-size:11.0pt;font-family:sans-serif;}#yiv8485934124 a:link, #yiv8485934124 span.yiv8485934124MsoHyperlink {color:blue;text-decoration:underline;}#yiv8485934124 span.yiv8485934124EmailStyle19 {font-family:sans-serif;color:windowtext;}#yiv8485934124 .yiv8485934124MsoChpDefault {font-size:10.0pt;} _filtered {}#yiv8485934124 div.yiv8485934124WordSection1 {}#yiv8485934124 
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

Hi Adrian, 

Cheers, 

Igor 

Get Outlook for Android

Hi,

Best,
Adrian

---

From: Daniele Ceccarelli <[email-masked]>
Date: Wed, 26 May 2021 15:58:21 +0000

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 <[email-masked]> On Behalf Of Igor Bryskin
Sent: den 24 maj 2021 16:45
To: [email-masked]; Adrian Farrel <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,

Adrian

From: Igor Bryskin <[email-masked]<mailto:[email-masked]>>
Sent: 24 May 2021 13:22
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Teas] SFC and slicing

Hi Adrian,

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 <[email-masked]<mailto:[email-masked]>> on behalf of Adrian Farrel <[email-masked]<mailto:[email-masked]>>
Sent: Sunday, May 23, 2021 1:40:11 PM
To: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: [Teas] SFC and slicing

Hi,

Best,
Adrian

_______________________________________________
Teas mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas
_______________________________________________
Teas mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 26 May 2021 17:32:05 +0000 (UTC)

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=[email-masked]> 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,

 

 

  
 
BR
Daniele  

From: Teas <[email-masked]>On Behalf Of Igor Bryskin
Sent: den 24 maj 2021 16:45
To: [email-masked]; Adrian Farrel <[email-masked]>
Subject: Re: [Teas] SFC and slicing

 

a) arbitrarily;
 
b) evenly.

 

Cheers,
 
Igor

 

 

Thanks,
 
Adrian

 
Hi Adrian,

 
Cheers,
 
Igor
 
GetOutlook for Android

 
Hi,

Best,
Adrian

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 26 May 2021 11:50:38 -0700

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=[email-masked]>, wrote:
> 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
>

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 27 May 2021 09:12:44 +0000

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 <[email-masked]>
Sent: den 26 maj 2021 20:51
To: [email-masked]; Adrian Farrel <[email-masked]>; Daniele Ceccarelli <[email-masked]>; Igor Bryskin <[email-masked]>
Subject: Re: [Teas] SFC and slicing

Cheers,
Jeff
On May 26, 2021, 10:43 AM -0700, Igor Bryskin <i_bryskin=[email-masked]<mailto:i_bryskin=[email-masked]>>, wrote:

Hi Daniele,

Cheers,
Igor

On Wednesday, May 26, 2021, 11:58:40 AM EDT, Daniele Ceccarelli <daniele.ceccarelli=[email-masked]<mailto:daniele.ceccarelli=[email-masked]>> wrote:

Hi Adrian, Igor,

BR
Daniele

From: Teas <[email-masked]<mailto:[email-masked]>> On Behalf Of Igor Bryskin
Sent: den 24 maj 2021 16:45
To: [email-masked]<mailto:[email-masked]>; Adrian Farrel <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Teas] SFC and slicing

a) arbitrarily;

b) evenly.

Cheers,

Igor

Thanks,

Adrian

Hi Adrian,

Cheers,

Igor

Hi,

Best,
Adrian

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 27 May 2021 14:05:27 +0000 (UTC)

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=[email-masked]> 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.

 

 

Cheers,
Daniele  

 

 
Cheers, 
 
Jeff

 

Hi Daniele,

 

 
Cheers,
 
Igor

 

Hi Adrian, Igor,

 

 

 
BR
Daniele 

From:Teas <[email-masked]>On Behalf Of Igor Bryskin
Sent: den 24 maj 2021 16:45
To: [email-masked]; Adrian Farrel <[email-masked]>
Subject: Re: [Teas] SFC and slicing

 

a) arbitrarily;
 
b) evenly.

 

Cheers,
 
Igor

 

 

Thanks,
 
Adrian

From:Igor Bryskin <[email-masked]>
Sent: 24 May 2021 13:22
To: [email-masked]; [email-masked]
Subject: Re: [Teas] SFC and slicing

Hi Adrian,

 
Cheers,
 
Igor
 
GetOutlook for Android

From:Teas <[email-masked]> on behalf of Adrian Farrel <[email-masked]>

Hi,

Best,
Adrian

---

From: <[email-masked]>
Date: Mon, 31 May 2021 08:31:01 +0000

Hi Igor, all,

There are use cases for which distinguishing the overall slice service objectives (between CEs) vs. those involving SFs may make sense from a service standpoint:

·         Think about some SFs such DNS server. The placement of such as an SF is critical for some services. CE-SF service requirements have to be distinguished from the overall slice service requirements.

·         Some service chains may be used for traffic hooking within a slice. That is, the traffic won’t exist the slice but will be proceed by a set of SFs that are structured as service function chains. The traffic performance of the service chain can be captured in its own vs. the one between CEs.

Putting aside the endpoint discussion, these two points can be covered in the draft by making this changes:

OLD:
   The SLOs are defined for sets of
   two or more endpoints and apply to specific directions of traffic
               ^^^^^^^^
   flow.  That is, they apply to specific source endpoints and specific
          ^^^^^^^^
   connections between endpoints within the set of endpoints and
   connections in the IETF Network Slice.

NEW:

   The SLOs are defined for sets of

   two or more points and apply to specific directions of traffic

               ^^^^^^

   flow. For example, they apply to specific source endpoints and specific

         ^^^^^^^^^^

   connections between endpoints within the set of endpoints and

   connections in the IETF Network Slice. Likewise, they can apply

                                          ^^^^^^^^^^^^^^^^^^^^^^

   to specific flows that involve an endpoint and a service function or

   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

   a set of service functions.

   ^^^^^^^^^^^^^^^^^^^^^^^^^^

Cheers,
Med

De : Teas [mailto:[email-masked]] De la part de Igor Bryskin
Envoyé : lundi 24 mai 2021 16:45
À : [email-masked]; Adrian Farrel <[email-masked]>
Objet : Re: [Teas] SFC and slicing

Cheers,
Igor

Thanks,

Adrian

Hi Adrian,

Cheers,

Igor

Hi,

Best,
Adrian

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Daniele Ceccarelli <[email-masked]>
Date: Mon, 31 May 2021 11:35:26 +0000

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=[email-masked]>
Sent: den 27 maj 2021 16:05
To: Jeff Tantsura <[email-masked]>; [email-masked]; Adrian Farrel <[email-masked]>; Daniele Ceccarelli <[email-masked]>
Subject: Re: [Teas] SFC and slicing

Daniele,

Cheers,
Igor

On Thursday, May 27, 2021, 05:13:02 AM EDT, Daniele Ceccarelli <daniele.ceccarelli=[email-masked]<mailto:daniele.ceccarelli=[email-masked]>> wrote:

Cheers,
Daniele

From: Jeff Tantsura <[email-masked]<mailto:[email-masked]>>
Sent: den 26 maj 2021 20:51
To: [email-masked]<mailto:[email-masked]>; Adrian Farrel <[email-masked]<mailto:[email-masked]>>; Daniele Ceccarelli <[email-masked]<mailto:[email-masked]>>; Igor Bryskin <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Teas] SFC and slicing

Cheers,

Jeff

Hi Daniele,

Cheers,

Igor

Hi Adrian, Igor,

BR
Daniele

a) arbitrarily;

b) evenly.

Cheers,

Igor

Thanks,

Adrian

Hi Adrian,

Cheers,

Igor

Hi,

Best,
Adrian