Re: [Teas] Moving forward with draft-ietf-teas-ietf-network-slices

[Shunsuke Homma <[e-mail]>]

Thanks, Med. I got that "customer" can be used for both cases, and I'm ok
to use it.

Regards,

Shunsuke

On Wed, May 19, 2021 at 12:30 AM <[e-mail]> wrote:

> Hi Shunsuke,
>
>
>
> “As far as I read other comments on the terms, most of people seem to
> focuses on use cases where IETF network slices are provided as a type of
> network services (i.g., case1), and I’d like to confirm if case2 is also in
> our scope and “customer” can cover both cases. (I personally want to avoid
> using different terms depending on assumed use cases).”
>
>
>
> I agree with you that both should be in scope. I don’t see slicing
> different compared to other network services. The “customer” can be used
> for both internal and external cases.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Shunsuke Homma [mailto:[e-mail]]
> *Envoyé :* vendredi 7 mai 2021 04:53
> *À :* Oscar González de Dios <[e-mail]>
> *Cc :* Loa Andersson <[e-mail]>; [e-mail]; BOUCADAIR Mohamed
> TGI/OLN <[e-mail]>; [e-mail]
> *Objet :* Re: [Teas] Moving forward with
> draft-ietf-teas-ietf-network-slices
>
>
>
> Hi,
>
>
>
> Firstly, I also follow the WG consensus, and I’m ok to use “customer” if
> WG prefers it.
>
>
>
> I assume there are mainly two types of use cases on (IETF) network slices:
>
> 1. Providing slices to externals(customers) as a network service
>
> 2. Operating some internal network resources with the same slice system
> with case1
>
>
>
> As far as I read other comments on the terms, most of people seem to
> focuses on use cases where IETF network slices are provided as a type of
> network services (i.g., case1), and I’d like to confirm if case2 is also in
> our scope and “customer” can cover both cases. (I personally want to avoid
> using different terms depending on assumed use cases).
>
>
>
>
>
> Btw, I agree with that slice management would be important, and we’ll need
> to clarify what “customers” and “providers” can do on slice managements. In
> my memory, the NS-DT’s study was started with an assumption that resources
> should be abstracted from several reasons, such as usability, scalability,
> security, etc. In this assumption, in my understanding, who controls
> network resources will be always slice provider (i.e., the owner of NSC).
> In other words, customers never manage resources structuring a slice
> directly, and a customer will send a service request to a slice
> provider/NSC when he/she wants to create/change/delete a slice. (I think
> this is fit to operation models considered in other SDOs such as TMF.)
>
>
>
> What can be done via service request will depend on design of slice
> service, and the current definition part provides just minimal sets of
> selectable parameters as SLOs. More details are provided in NBI drafts.
>
>
>
> Regards,
>
>
>
> Shunsuke
>
>
>
> _________________________________________________________________________________________________________________________
>
> 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.
>
>