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

mohamed.boucadair@orange.com Thu, 19 May 2022 13:06 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 85EA8C15E6D3 for <teas@ietfa.amsl.com>; Thu, 19 May 2022 06:06:45 -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_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 MNptzOvA_UC8 for <teas@ietfa.amsl.com>; Thu, 19 May 2022 06:06:41 -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 1F8B6C159487 for <teas@ietf.org>; Thu, 19 May 2022 06:06:41 -0700 (PDT)
Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) (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 opfednr20.francetelecom.fr (ESMTP service) with ESMTPS id 4L3qqz1pjxz1y4K; Thu, 19 May 2022 15:06:39 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1652965599; bh=SKFkOH6Op+/9j1fzj+Y6UGxv7gc9AyGDTwMr93+psvU=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=CpBQjQAqm0hVFShs8YpTaQDrYaYtGL5OulIvQL9raXilZgp+geTdOZoaH00M8qXLn AI9ylCtEjtta8JORARPk3iNw1hyLTys4pc/WWyBk3arkTJfh2WAdSLVJOlwJ27D9g1 HxHYs1X+DIpbeqHpd8YDpol+FJ2Fxk5lNZX3gCrosGPEU4zuwDvWt+hwPpfjqEDMPc txPVeP7x3BEamALSaIdsWSjmxulfsqU76oVX0x99EomibzorsRV56D1nkJsZyzzg5S Va43KYkoGITabWWxI1xxyhqSBDm/4/SnAEYd14z4629hD6QBFJNQAjxyN4yGvxIMxH QNy36p9wMt5MQ==
From: mohamed.boucadair@orange.com
To: John E Drake <jdrake@juniper.net>, "Dongjie (Jimmy)" <jie.dong@huawei.com>, 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: AQHYQD5mX2A61i4xekOPDk0kRv8vKKzQYtoAgAA5TICAA7s7gIAANVaAgAABd4CAAA3wAIAGKMYAgABROwCAAAFXAIAABTSAgBFQPACAARjAgIAAcBmAgAEls4CAAGMHgIABDJ+AgAAhpICABO31AIAAZDuAgAKiw4CAAHLKgIABEYyAgAcnsICAAGp/gIAAOjkAgAHF6wCAADaWIIABCPYAgAB95nCAACoQAIAAAG3ggAFwhoCAHkZSAIAAbn4AgAC3gMCAAAEeIA==
Content-Class:
Date: Thu, 19 May 2022 13:06:38 +0000
Message-ID: <749_1652965599_628640DF_749_248_1_6a06a3a83e9245a9ab8cb7576e7d30ef@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>
In-Reply-To: <BY3PR05MB8081F5877450A2F76BB88199C7D09@BY3PR05MB8081.namprd05.prod.outlook.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-19T12:53:02Z; 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=0f11de96-ec80-4ecb-a0d7-4ee995923b11; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ContentBits=0
x-originating-ip: [10.115.26.52]
Content-Type: multipart/alternative; boundary="_000_6a06a3a83e9245a9ab8cb7576e7d30eforangecom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/I6FVxfPPmrs6zrH_07vHyW_jln0>
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: Thu, 19 May 2022 13:06:45 -0000

Hi all,

Fully agree with John.

The text proposed by Krzysztof looks good to me.

Queuing aspects mentioned by Joel fall under “a collection of resources” in the proposed text. More generally, queuing management falls under differentiated forwarding while topology customization is an aspect of differentiated routing that can be tweaked to put into effect an NRP. Other differentiated behaviors can be a result of traffic management considerations (admission control, ratio of reserved-provisioned/allowed traffic, etc.).

Cheers,
Med

De : John E Drake <jdrake@juniper.net>
Envoyé : jeudi 19 mai 2022 14:50
À : Dongjie (Jimmy) <jie.dong@huawei.com>; 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,

Comment inline.

Yours Irrespectively,

John



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

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
发件人:Krzysztof Szarkowicz <kszarkowicz@gmail.com<mailto:kszarkowicz@gmail.com>>
收件人:Dongjie (Jimmy) <jie.dong@huawei.com<mailto:jie.dong@huawei.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>>
抄 送:teas <teas@ietf.org<mailto:teas@ietf.org>>
时 间:2022-05-19 03:16:57
主 题:Re: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization

Hi,

So, do we have agreement for following change:


          An NRP is simply a collection of resources identified in the underlay network. The amount and granularity of resources allocated in different portions of an NRP can be flexible. Depends on the operator’s policy and the service requirements, some NRP realizations may build the NRPs with dedicated topologies, while some other realizations may allow shared topology for multiple NRPs, one possible case is that the entire underlay network topology is used by all the NRPs. Some realization might as well use single NRP only with the resources of the entire underlay network topology.

Best regards,
Krzysztof

_________________________________________________________________________________________________________________________

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.