Re: [Teas] Network Slicing in multiple sites - was: Review of draft-ietf-teas-ietf-network-slices-09

[[e-mail]]

Re-,

This is only my option but I think that we have the adequate level of details in the framework to support these cases.

That’s BTW the same reasoning why we don’t include details such as those in https://mailarchive.ietf.org/arch/msg/teas/-jAZQ0GenSstYh4n1VYNMZF4QKw/

Thank you.

Cheers,
Med

De : Daniele Ceccarelli <[e-mail]>
Envoyé : mardi 29 mars 2022 13:43
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>; [e-mail]; 'TEAS WG' <[e-mail]>
Objet : RE: Network Slicing in multiple sites - was: Review of draft-ietf-teas-ietf-network-slices-09

Hi Med,
…

[Med] I’m afraid this is deployment specific, but the scenario (e.g., ingress SDP) you mentioned can be mapped to this part in the framework:

   “Also, the customer can specify the service
   objectives to be met by the underly network (e.g., one-way delay to
   cross a service function path, one-way delay to reach a specific SF).”
[DC] I guess your’re right.

…

The questions are:

  *   Should we support these scenarios?
  *   Should we pose some requirements so that they are addressed by the solution drafts?

[Med] I do personally see these as good scenarios to exercise the service data model.

[DC] Agree. I don’t have a strong preference on whether to have them as requirements stated in the framework or added as “use cases” to the service data model, but if I could choose I would prefer to have them in the framework.

Cheers
Daniele



From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Sent: den 29 mars 2022 13:34
To: Daniele Ceccarelli <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; 'TEAS WG' <[e-mail]<mailto:[e-mail]>>
Subject: RE: Network Slicing in multiple sites - was: Review of draft-ietf-teas-ietf-network-slices-09

Hi Daniele, all,

Please see inline.

Cheers,
Med

De : Daniele Ceccarelli <[e-mail]<mailto:[e-mail]>>
Envoyé : lundi 28 mars 2022 17:14
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; 'TEAS WG' <[e-mail]<mailto:[e-mail]>>
Objet : RE: Network Slicing in multiple sites - was: Review of draft-ietf-teas-ietf-network-slices-09

Hi Med, Adrian, all,

Let me try to merge the replies on multiple sites (NFC and ancillary SDPs)

Hi Daniele, All,

(focusing on the SFC part)

The current SFC text does not make an assumption about where the functions will be provided (same or distinct sites). The exact location will be decides as per the following step in Section 6.6 of the framework:

==
   *  Execute an SF placement algorithm to decide where to locate the
      ancillary SDPs in order to fulfil the service objectives.
===

[DC] That’s fine. SF can be easily covered by the ancillary SDPs.

[snip]

> With Cloud RAN it will be very likely to have an IETF network slice
> being used for a 5G Slice where the RU is at the antenna site, the
> DU/vDU in a different site and CU/vCU and Core functions yet at
> different sites. I wonder how the network slice would be built in
> this scenario, maybe in a sort of “drop and continue” with multiple
> intermediate SDP? Maybe the concept of sequential composition
> applies?
>
> Cloud RAN is just an example and the scenario applies to many
> other types of applications.

I think it might depend a lot on whether the service functions (RU, DU, CU) are at well-known places or whether these is some flexibility of choice.
[DC] both need to be foreseen. In the simplest scenarios the site at which the network function must be deployed (or already exists) is an input to the request, in the more advanced ones it is selected by the NSC.
We could argue whether it’s the NSC or something sitting above it. This could be a very complex question because finding the best places to deploy a network function requires a deep knowledge of the transport network AND of the sites/data centers.

[Med] Agree that both can be envisaged. How the “complexity” is hidden/managed at the provider side is not specific to this case. The framework spec does not have to dive into much internal details, though.

You could, for example, have a slice with three P2P connectivity constructs as shown in your figure (marked NW).

> It would be something like.
>
> SDP(antenna site) ---NW---SDP(site where the DU is deployed)---NW---SDP (site there the CU is deployed)---NW---SDP (core network)

Or you might take an SFC approach if, for example, the DU is a vDU that could be present in several places. Then you would use an ancillary SDP to indicate that *a* vDU must be found, and you would specify the P2P connectivity construct from antenna to vDU, and another from vDU to CU.

> Actually at each site there could be a pair of SDPs, one being the receiving SDP
> from the previous site and the other being the sending SDP towards the next
> site.

Well, you *could* do this. Or you could use a single SDP at each service function.

It might depend on how you realize the SDPs for receive and send.
[DC] this will probably depend from how the ancillary SDP will be defined, but yes, in theory you can do both ways.

> How would the slice be built here? A single e2e slice? Multiple
> sequentially composed slices?

Recall that we are not in the business of delivering what 3GPP calls e2e slices. In their scope, we are delivering transport slices.

But whether you decide to have one slice with multiple connectivity constructs, or a set of slices is entirely your choice.
[DC] correct, but I would expect the request to the NSC to be to build a transport slice between SDP ingress (likely router at the antenna site) and SDP egress (likely the DC gateway where the CN is or the UPF itself) plus a number of ancillary SDPs for vDU and vCU (either to be automatically selected OR exactly site X and Y).
In addition to that (here I’m speculating) I guess it should be possible to specify just the ingress SDP and not the egress one as a customer might only own the RAN but not the core and hence also the core network would be an ancillary SDP.

[Med] I’m afraid this is deployment specific, but the scenario (e.g., ingress SDP) you mentioned can be mapped to this part in the framework:

   “Also, the customer can specify the service
   objectives to be met by the underly network (e.g., one-way delay to
   cross a service function path, one-way delay to reach a specific SF).”

The questions are:

  *   Should we support these scenarios?
  *   Should we pose some requirements so that they are addressed by the solution drafts?

[Med] I do personally see these as good scenarios to exercise the service data model.

Cheers
Daniele


From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Sent: den 28 mars 2022 09:36
To: [e-mail]<mailto:[e-mail]>; Daniele Ceccarelli <[e-mail]<mailto:[e-mail]>>; 'TEAS WG' <[e-mail]<mailto:[e-mail]>>
Subject: RE: [Teas] Review of draft-ietf-teas-ietf-network-slices-09

Hi Daniele, All,

(focusing on the SFC part)

The current SFC text does not make an assumption about where the functions will be provided (same or distinct sites). The exact location will be decides as per the following step in Section 6.6 of the framework:

==
   *  Execute an SF placement algorithm to decide where to locate the
      ancillary SDPs in order to fulfil the service objectives.
===

Cheers,
Med

De : Teas <[e-mail]<mailto:[e-mail]>> De la part de Adrian Farrel
Envoyé : vendredi 25 mars 2022 22:22
À : 'Daniele Ceccarelli' <daniele.ceccarelli=[e-mail]<mailto:daniele.ceccarelli=[e-mail]>>; 'TEAS WG' <[e-mail]<mailto:[e-mail]>>
Objet : Re: [Teas] Review of draft-ietf-teas-ietf-network-slices-09

Hi Daniele,

> I reviewed the draft once again like if it was an early routing area
> directorate review…and here are some more comments suggestions,
> some of which just editorial (picky mode on).

Very many thanks for these comments.

> Before going into the details I also have a general comment.
>
> I was hoping that the SFC text was covering services spanning multiple
> sites, but indeed I guess it shouldn’t. This leaves the distributed sites
> scenario uncovered.

I’m puzzled by your comment. SFC is practically useless if the services are not found at different sites. That is, in essence the whole point of RFC 7665.

_________________________________________________________________________________________________________________________

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.