Re: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization

mohamed.boucadair@orange.com Fri, 20 May 2022 06:40 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 60C27C14F6E7 for <teas@ietfa.amsl.com>; Thu, 19 May 2022 23:40:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7NSXNI5EbPDP for <teas@ietfa.amsl.com>; Thu, 19 May 2022 23:40:37 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38268C14F612 for <teas@ietf.org>; Thu, 19 May 2022 23:40:37 -0700 (PDT)
Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) (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 opfednr26.francetelecom.fr (ESMTP service) with ESMTPS id 4L4HD30sFfzyd0; Fri, 20 May 2022 08:40:35 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1653028835; bh=PFH7R0jhMdFN4bCotSeGc17O+4emh3EyBAJ5L5POxb8=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=BWDHaWoZUlYpsURiFLYmsHwTzbdDbg9oWYAzLigoZHElcMSJRbrGWlVmL5ujBU0Xe bvs0VhfxVNlixjTfz3BMk4d/MhVjFYq4QzH9/LO1BeDMXeWauNozYHfi2VT7uEOQq+ NBGcrkqrNQiT+1JYlUcHNaz6r6ubRz1ru3EvbmU2lav+4oDT5Dcp5EZRwP1gtNG5ik wvqkDPz3lG8aVEKHZZaO25o7U/PZMVuKzu3217Muuqdv6jVDoBU5DFytDwU0cnqy6z 5Y8nKsjc8mMX1GWMnnVGvVv2FPqeNrxSAJrt4o2JDmSMo37vnDPrFNwR/QUH49f0h2 VVE8tROQaRhSA==
From: mohamed.boucadair@orange.com
To: "Dongjie (Jimmy)" <jie.dong@huawei.com>, John E Drake <jdrake@juniper.net>, Krzysztof Szarkowicz <kszarkowicz@gmail.com>, adrian <adrian@olddog.co.uk>
CC: teas <teas@ietf.org>
Thread-Topic: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization
Thread-Index: AQHYQD6QX2A61i4xekOPDk0kRv8vKKzP3L0AgAA5TYCAA7s7gIAANVaAgAABdoCAAA3wAIAGKMcAgABROgCAAAFYAIAABTOAgBFQPACAAVkI0IAAMrUAgAGjRuD//+KRgIABdarg//+4mICABVEIEIAAASmAgAMf2AD///W0gAAxbgbAANW5loAAHQWkAP//vIoA//3BXjCABD1TAP/+rceAgALXd4D//1GA4AAbECSAAC4OGYADyMpPAAAek1fRAAY6EQD//18nUP//PSKA//0+UfD/+ixKsA==
Content-Class:
Date: Fri, 20 May 2022 06:40:34 +0000
Message-ID: <27948_1653028835_628737E3_27948_6_1_40684ce0704f49ccb6d587cdeaf59299@orange.com>
References: <921D62D1-CB07-49FC-BD46-E7E1A1DDD31D@gmail.com>, <F7E81387-F400-4680-9589-B81535723E59@gmail.com> 1D107E3D-307F-4473-9E0B-00E81E950498 <BY3PR05MB8081F5877450A2F76BB88199C7D09@BY3PR05MB8081.namprd05.prod.outlook.com> <5b725b68b16049e99e689c3be36cd6a0@huawei.com> <BY3PR05MB8081DFB88AF6D6A9EF64B3B8C7D09@BY3PR05MB8081.namprd05.prod.outlook.com> <4d81c9d54f384bb59cadaaaff1d7daa3@huawei.com>
In-Reply-To: <4d81c9d54f384bb59cadaaaff1d7daa3@huawei.com>
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=2022-05-20T06:31:06Z; 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=5a755cc9-96a6-4545-9e51-81ee4875536d; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ContentBits=0
x-originating-ip: [10.115.27.51]
Content-Type: multipart/alternative; boundary="_000_40684ce0704f49ccb6d587cdeaf59299orangecom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/l_JU74RgFvuFyw7ZURUN51vyXI4>
Subject: Re: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.34
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, 20 May 2022 06:40:41 -0000

Hi Jie,

We should not forgot network dynamics: the number of NRPs won’t be frozen, not the underlay networks themselves (think about network merging and splits that are happening while the above services are still offered to customers).

There is nothing wrong that a deployment starts with a single NRP to address a specific service case and then adjust the tweaking to address other vertical needs (if/when they come).

What actually matters is not whether one can call the whole physical underlay network an NRP, but how introducing the concept of NRP will allow to manage smoothly the dynamics mentioned above.

From a technical standpoint, I don’t think we can impose a minimum # of partitions to start make use of the NRP concept.

Cheers,
Med

De : Dongjie (Jimmy) <jie.dong@huawei.com>
Envoyé : vendredi 20 mai 2022 03:54
À : John E Drake <jdrake@juniper.net>; Krzysztof Szarkowicz <kszarkowicz@gmail.com>; adrian <adrian@olddog.co.uk>; BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com>
Cc : teas <teas@ietf.org>
Objet : RE: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization

Hi John,

Please see inline.

Best regards,
Jie


Juniper Business Use Only
From: Dongjie (Jimmy) <jie.dong@huawei.com<mailto:jie.dong@huawei.com>>
Sent: Wednesday, May 18, 2022 9:52 PM
To: Krzysztof Szarkowicz <kszarkowicz@gmail.com<mailto:kszarkowicz@gmail.com>>; John E Drake <jdrake@juniper.net<mailto:jdrake@juniper.net>>; adrian <adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>>; mohamed.boucadair <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>>
Cc: teas <teas@ietf.org<mailto:teas@ietf.org>>
Subject: RE: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization

[External Email. Be cautious of content]

Hi Krzysztof and all,

Most of this text looks good to me except the last sentence. "A single NRP with the resources of the entire underlay network" is the same as a network without network resource partition. I think we agreed that an NRP refers to a subset of the underlay network resources (e.g. a subset of the buffer/queueing/scheduling resources), thus it is different from the whole underlay network.

[JD]  A subset can consist of the entire set

[Jie] Maybe this is true in general, while I’m not sure such generalization is helpful in the context of network slicing. Do you consider the whole physical underlay network can be called an NRP?

[JD]  Absolutely

[Jie #2] Fine, then we could also generalize that network slicing is already supported in legacy networks for years☺


That said, an NRP may have the same topology as the underlay network.

IMO we need to keep in mind that resource and topology are two separate attributes of an NRP.

Best regards,
Jie


_________________________________________________________________________________________________________________________

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.