[Teas] Network Slice vs. VPN(+) RE: network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00

mohamed.boucadair@orange.com Wed, 03 March 2021 13:27 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 D1E663A1138 for <teas@ietfa.amsl.com>; Wed, 3 Mar 2021 05:27:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.817
X-Spam-Level:
X-Spam-Status: No, score=-2.817 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 gqpHgFli67Ry for <teas@ietfa.amsl.com>; Wed, 3 Mar 2021 05:27:36 -0800 (PST)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.41]) (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 DBA863A113A for <teas@ietf.org>; Wed, 3 Mar 2021 05:27:35 -0800 (PST)
Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 4DrFD52h6Zz8tyx; Wed, 3 Mar 2021 14:27:33 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1614778053; bh=8h27SANfmkjtJ+LOrvjISMbhh0qCl+Ex40Q8+3SFMdI=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=pgL1mMZRKW7Y/u/h7o92T9cWLT5sJTCfwAbR5w2gP5Zh6SLMFdjhQTTB+QcBfCYl3 IPa0ER7JeFs4Gbhy2YPqCJJOxNzef0/Ff0QaOSZE6N3hEw7DktFoQd4nah1GJRajTo MWbob5+OISZRVm765m7TgZJcOiKF/trlGQoqdg1cQKlIfo2Y1PnlotMn99/d2x9PMZ ucaBMHPzCH2PYY9muKatsn6G1W9Y6htPARtfGgAJInOSzMSELNzr2CGe+d11u9gLE9 Fb/SZcKg/S98pHygfck2sWbjQNJabzgoqg6JDTpmZTMzrYbObvNo2gO/1M0DD2KQXT L8ncaFVXG6c9g==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.82]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id 4DrFD51kYPz2xCV; Wed, 3 Mar 2021 14:27:33 +0100 (CET)
From: mohamed.boucadair@orange.com
To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "teas@ietf.org" <teas@ietf.org>
Thread-Topic: Network Slice vs. VPN(+) RE: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00
Thread-Index: AdcQMPTS90mv3J8RTnOI6QotB2+JsA==
Date: Wed, 03 Mar 2021 13:27:33 +0000
Message-ID: <25785_1614778053_603F8EC5_25785_79_1_787AE7BB302AE849A7480A190F8B9330315E7F64@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.247]
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B9330315E7F64OPEXCAUBMA2corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/XKgkDJBvkISZw0VHDDH8_tL8SRA>
Subject: [Teas] Network Slice vs. VPN(+) RE: network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00
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, 03 Mar 2021 13:27:38 -0000

Hi Adrian, all,

Picking this item from the message below as I think this is a point that is worth to be clarified and discussed in the framework/definition document. We need to explain the differences between the two concepts. There are some “hints” in the framework I-D, but we need to be explicit.

VPN(+) is no more than an IETF technology to implement a network slice. As such, a network slice can be implemented without relying upon a VPN/VPN+. That’s deployment-specific. An example of possible implementations (with IETF technologies) would be to define PDBs + SFCs or running a dedicated MT-IGP instance (with optimized tweaking such as exclude links exposing long delays) + resource-based access, and so on.

Ah, let’s not forget that a network slice as defined in the definition I-D is not only about connectivity.

BTW, we do still have some inconsistencies between the documents:

·         The definition I-D acks that an IETF network slice is not only about connectivity.

·         The framework I-D seems to be more connectivity-centric.

We need to fix this as well.

Cheers,
Med

De : Teas [mailto:teas-bounces@ietf.org] De la part de Adrian Farrel
Envoyé : jeudi 25 février 2021 11:52
À : 'Young Lee' <younglee.tx@gmail.com>; 'Luis M. Contreras' <contreras.ietf@gmail.com>
Cc : 'Joel M. Halpern' <jmh@joelhalpern.com>; teas@ietf.org; 'Eric Gray' <ewgray2k@gmail.com>; 'John E Drake' <jdrake=40juniper.net@dmarc.ietf.org>; 'Rokui, Reza (Nokia - CA/Ottawa)' <reza.rokui@nokia.com>; BOUCADAIR Mohamed TGI/OLN <mohamed.boucadair@orange.com>
Objet : Re: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00

[...]

But my opinion of all of this is coloured by thinking about enhanced VPNs (VPN+) [3] and IETF network slices as the same thing.

[...]

[1] https://mailarchive.ietf.org/arch/msg/teas/ibycGzi5cxJUJSvRxm9OsQdDqn8/
[2] RFC 4026
[3] draft-ietf-teas-enhanced-vpn

_________________________________________________________________________________________________________________________

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.