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

Shunsuke Homma <shunsuke.homma.ietf@gmail.com> Fri, 21 May 2021 15:05 UTC

Return-Path: <shunsuke.homma.ietf@gmail.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 1145E3A13EC for <teas@ietfa.amsl.com>; Fri, 21 May 2021 08:05:32 -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, 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, SPF_HELO_NONE=0.001, SPF_PASS=-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=gmail.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 33rppPeTr5qz for <teas@ietfa.amsl.com>; Fri, 21 May 2021 08:05:27 -0700 (PDT)
Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 ED1CC3A13EB for <teas@ietf.org>; Fri, 21 May 2021 08:05:26 -0700 (PDT)
Received: by mail-lf1-x133.google.com with SMTP id v8so25186921lft.8 for <teas@ietf.org>; Fri, 21 May 2021 08:05:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=82eys1TWIUAygQzGI1P9Bq5oWPHQQqHaeuFj5Z9VwXQ=; b=JXgTQhjGEpZX6UAVNlSbtl7Fdr8VBwvIpVMSDjtt3fV4+GYBfHiW8kZuIXd+YNi7vT CAhyuwOgcDhE6xjsq6iGUTeADsTdozVTE8VsqZq2Lh9dbrEzrZjTkG3AbRlLDNhKczdi nSiqijStR3v2+lPzfinl1t74j46HcPtLSWOXejboL9LbTt+NjTxsXF/oZeuILkgwEhB8 o/mWY3lsjazfCwmS2s6XmoLwGlyIs+CF0BsewjPWZrM1UGoOJ8WN2A06Aqx6gq+47m/6 b4FIv1X+VpPdZimutA5tMmAA8eWZ/9c6GOZV1BvQmbQIiHv3iyXicuNHm3STIun2boWc iaVg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=82eys1TWIUAygQzGI1P9Bq5oWPHQQqHaeuFj5Z9VwXQ=; b=s29mjEY6mP4c36f6PbJEFeOCdyZY3GYp67wbJFW4VaHi/Fb7Qg9jm2LvgBNMxjVKph zzo0uthyU9erGhpc4fsqxBO5Nn8xHWSg3Tpi26+2DlfsPXJVpZWdk+nnB2zyAPqK2fk1 IwlZHDFoxgA0eK+B0yoyfDIrfBhryA80inCGKJ4d4obrXkcs3pSgkutSf8N5QaXrkM5E 2TrFjuYjilD8xUv12URZ+iH5YLVaMuVRE/VcBc5h2E+JW9864iDgyyKHVk0tNG286hjI lPrDR0yH8Y6buh1QN3VjN4LICDAqmIVHqasYVXdKKR2AWxUWsoz4yo0eZS8IIN7EMfve /PEg==
X-Gm-Message-State: AOAM5306Q2Fr7ru2E/aATFpQP3J1+PNtFgIq5QuSTTQFqaEHQUwCOmTC zQ6JINWvl6b7n1QzNBmW5T5I744iyH5OjKRevkw=
X-Google-Smtp-Source: ABdhPJyDt1sEMJp4KygwtCZgscUW6UCtWTWZ5R4mNWiJnbiULomJgZum4WVVyiaKx+TcWHLPjoO06bcnGAvpWtqsq7Y=
X-Received: by 2002:a05:6512:3b10:: with SMTP id f16mr2488901lfv.393.1621609524566; Fri, 21 May 2021 08:05:24 -0700 (PDT)
MIME-Version: 1.0
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> <18233_1621351809_60A3DD81_18233_274_7_787AE7BB302AE849A7480A190F8B93303538A68E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
In-Reply-To: <18233_1621351809_60A3DD81_18233_274_7_787AE7BB302AE849A7480A190F8B93303538A68E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
From: Shunsuke Homma <shunsuke.homma.ietf@gmail.com>
Date: Sat, 22 May 2021 00:05:13 +0900
Message-ID: <CAKr2Fb97R07k8zRGPF9rQu5QC-uaTxuH_6ukXZ1kAp+=7u72BA@mail.gmail.com>
To: mohamed.boucadair@orange.com
Cc: Loa Andersson <loa@pi.nu>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "teas@ietf.org" <teas@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ad1e2005c2d86352"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/dDjO7qZidPNhuzOGgrE8yD8EDdk>
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: Fri, 21 May 2021 15:05:32 -0000

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 <mohamed.boucadair@orange.com> 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: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.
>
>