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

mohamed.boucadair@orange.com Tue, 18 May 2021 15:30 UTC

Return-Path: <mohamed.boucadair@orange.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 280303A1701 for <teas@ietfa.amsl.com>; Tue, 18 May 2021 08:30:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
X-Spam-Status: No, score=-2.094 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 B9azi0qLjMsN for <teas@ietfa.amsl.com>; Tue, 18 May 2021 08:30:12 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (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 CEFBF3A16FF for <teas@ietf.org>; Tue, 18 May 2021 08:30:11 -0700 (PDT)
Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 4Fl0LT1CCzz4xg9; Tue, 18 May 2021 17:30:09 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1621351809; bh=7bZsO/CTmTC0gUIuluIJ7MlZxnHtNdmoMuFS61XCyM8=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=Bd55EpQS1HPzIxKQp2a810XnoRIGaQ6MerAfxBNhV0QvaPv4WtHwOpnmAIZqS7auO a0Biqzw0ZsHCjkrC6oVr72kcyp5MY0jTOMONH4gWbCVOtaCiDZngsjCq34mKPpw2ma 8QR0e9Tfl1JVhkUhXF9Xv3ZIxQ+FgaT+c4Tw7EXLr+rFkmTyTAf8sbME1Fi75gTqwd +ShNJ6Uv8RP3Fr1e3aUiK3E/OWWQrzjzZozIRRbxRHmOrfcfuJvG2Eqqiu2PQiy/D+ 3nVROUvrekozMURyDltRMjxogt77kKQo7LdMe5sXz4NjhIsj+CyAeASxm+0yxDSAbs Eoa52a10q3YTg==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.64]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 4Fl0LS715kz8sYX; Tue, 18 May 2021 17:30:08 +0200 (CEST)
From: <mohamed.boucadair@orange.com>
To: Shunsuke Homma <shunsuke.homma.ietf@gmail.com>
CC: Loa Andersson <loa@pi.nu>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "teas@ietf.org" <teas@ietf.org>
Thread-Topic: [Teas] Moving forward with draft-ietf-teas-ietf-network-slices
Thread-Index: AQHXQu8D3IC4uv87EEaTxthPpP8Pa6rpadCA
Date: Tue, 18 May 2021 15:30:08 +0000
Message-ID: <18233_1621351809_60A3DD81_18233_274_7_787AE7BB302AE849A7480A190F8B93303538A68E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <037401d740c5$70a9cc30$51fd6490$@olddog.co.uk> <3ea262cf-e4c0-5ec0-9736-aedaf6d5d4d8@pi.nu> <009401d74195$41fd70a0$c5f851e0$@olddog.co.uk> <9933_1620212302_60927A4E_9933_344_1_787AE7BB302AE849A7480A190F8B933035376DFA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <00a001d7419e$99e5a040$cdb0e0c0$@olddog.co.uk> <03cf404d-59a7-0ec5-e18f-0a98bf638c0f@pi.nu> <PAXPR06MB7872B2DEF299B15988966A9DFD589@PAXPR06MB7872.eurprd06.prod.outlook.com> <CAKr2Fb9Krrqe7SWB4Zxyp8y8q1S1-jR2=Z3KkoF89cwhOEV4bg@mail.gmail.com>
In-Reply-To: <CAKr2Fb9Krrqe7SWB4Zxyp8y8q1S1-jR2=Z3KkoF89cwhOEV4bg@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.245]
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93303538A68EOPEXCAUBMA2corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/s-dbUm5hVeZvC_uu6XMiy-BeBgU>
Subject: Re: [Teas] Moving forward with draft-ietf-teas-ietf-network-slices
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: Tue, 18 May 2021 15:30:17 -0000

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:shunsuke.homma.ietf@gmail.com]
Envoyé : vendredi 7 mai 2021 04:53
À : Oscar González de Dios <oscar.gonzalezdedios@telefonica.com>
Cc : Loa Andersson <loa@pi.nu>nu>; adrian@olddog.co.uk; BOUCADAIR Mohamed TGI/OLN <mohamed.boucadair@orange.com>om>; teas@ietf.org
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.