Re: [Teas] Network slicing framework : Issue #7: Workflow

mohamed.boucadair@orange.com Wed, 29 September 2021 15:44 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 C17E53A1B23 for <teas@ietfa.amsl.com>; Wed, 29 Sep 2021 08:44:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, RCVD_IN_MSPIKE_H2=-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 Vu2ex4p1P_dM for <teas@ietfa.amsl.com>; Wed, 29 Sep 2021 08:44:34 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.35]) (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 531313A1B1E for <teas@ietf.org>; Wed, 29 Sep 2021 08:44:34 -0700 (PDT)
Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfednr21.francetelecom.fr (ESMTP service) with ESMTPS id 4HKLKD2fBBz5whQ; Wed, 29 Sep 2021 17:44:32 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1632930272; bh=SQj6amJvJ9hBUT3MyPpphOFQVVCj5Umb7L7GeSSYQOU=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=i7cP97ryKJRre2uMMXdpv9FaMAvPDOX64jsj0irrOCizKDDiZh+YkqAShil/6tgYK n7h48+9JSJctuNAJ7QoQrEIFFrqOt0pVHyOfe2/IuiOgGNmX6QVk8dRNTQlCSqsa6M UF2JRCwNDxZWYNt6COSGNi5dKPO6S68uDnrDjc8y4NdQ2f22kBvchknPaQui7NR5ex rgJGWWF4A1fUY1ovT3ZnuzG7JOzhJIBx6Mf4dIFGisvT2pbXd4mvjaU/g96WsmldF2 U9SHxKSuiNK/cGHW68VrbykRlbWXBYG7+3cgljcI7PrJ7DeQ6cR+hzGCywWZS/cK1P 2TS1Hv7kM1NVg==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfednr07.francetelecom.fr (ESMTP service) with ESMTPS id 4HKLKD1m7gzFpWj; Wed, 29 Sep 2021 17:44:32 +0200 (CEST)
From: mohamed.boucadair@orange.com
To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "teas@ietf.org" <teas@ietf.org>
Thread-Topic: [Teas] Network slicing framework : Issue #7: Workflow
Thread-Index: Adezy3Z20CHuNJR/TCK6n8h4jyhklABfCbLA
Content-Class:
Date: Wed, 29 Sep 2021 15:44:31 +0000
Message-ID: <6733_1632930272_615489E0_6733_151_7_787AE7BB302AE849A7480A190F8B93303540F420@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <055201d7b3cd$0b577eb0$22067c10$@olddog.co.uk>
In-Reply-To: <055201d7b3cd$0b577eb0$22067c10$@olddog.co.uk>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Enabled=true; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SetDate=2021-09-29T15:35:29Z; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Method=Privileged; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Name=unrestricted_parent.2; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ActionId=43022d03-dddc-44d5-bd57-f4e033d8b0fd; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ContentBits=0
x-originating-ip: [10.114.13.245]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/dUaIha-RtUIZCstl160BOSruJts>
Subject: Re: [Teas] Network slicing framework : Issue #7: Workflow
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: Wed, 29 Sep 2021 15:44:40 -0000

Hi Adrian, 

> For that reason, I think it would be wrong to document a workflow. (This
> is a change to my original opinion!)
> 
> Maybe add a sentence to explain that the order that the architectural
> networks are constructed is open for operational choice.

Seems reasonable. Internals to the NSC should be kep as such (especially, the second and third bullets of your list). 

Another approach would be to focus only on the visible external behavior, e.g.,: 

- The network exposes its (slice) capabilities
- The customer requests a slice
- The NSC maps the requests to the capabilities while applies provider policies (if any) and then creates the resource partition
- The NSC reports back to the customer as a function of the previous step

Cheers,
Med

> -----Message d'origine-----
> De : Teas <teas-bounces@ietf.org> De la part de Adrian Farrel
> Envoyé : lundi 27 septembre 2021 20:25
> À : teas@ietf.org
> Objet : [Teas] Network slicing framework : Issue #7: Workflow
> 
> Dependent slightly on the resolution of issue #6 (architecture and
> terminology), we could document a workflow.
> 
> For example,:
> - customer requests a slice
> - NSC maps slice to a slice group
> - NSC maps slice group to a resource partition
> - NSC allocates resources to the resource partition
> 
> But it seems to me that these steps could happen in pretty much any order
> depending to operational preferences and possibly the technology of the
> network.
> 
> For that reason, I think it would be wrong to document a workflow. (This
> is a change to my original opinion!)
> 
> Maybe add a sentence to explain that the order that the architectural
> networks are constructed is open for operational choice.
> 
> Cheers,
> Adrian
> 
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas

_________________________________________________________________________________________________________________________

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.