Re: [Teas] draft-ietf-teas-ietf-network-slices: Network Slice vs. VPN(+)

Adrian Farrel <adrian@olddog.co.uk> Wed, 05 May 2021 13:00 UTC

Return-Path: <adrian@olddog.co.uk>
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 DD5873A1754 for <teas@ietfa.amsl.com>; Wed, 5 May 2021 06:00:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.785
X-Spam-Level:
X-Spam-Status: No, score=0.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MAY_BE_FORGED=2.7, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 9S67fWcWUDfK for <teas@ietfa.amsl.com>; Wed, 5 May 2021 06:00:30 -0700 (PDT)
Received: from mta5.iomartmail.com (mta5.iomartmail.com [62.128.193.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 002F93A1759 for <teas@ietf.org>; Wed, 5 May 2021 06:00:29 -0700 (PDT)
Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta5.iomartmail.com (8.14.4/8.14.4) with ESMTP id 145D0PQn019010; Wed, 5 May 2021 14:00:26 +0100
Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 17B092203D; Wed, 5 May 2021 14:00:26 +0100 (BST)
Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs1.iomartmail.com (Postfix) with ESMTPS id 0BC9622044; Wed, 5 May 2021 14:00:26 +0100 (BST)
Received: from LAPTOPK7AS653V (74.197.bbplus.pte-ag1.dyn.plus.net [81.174.197.74] (may be forged)) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id 145D0OfD031813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 5 May 2021 14:00:25 +0100
Reply-To: <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <mohamed.boucadair@orange.com>, <teas@ietf.org>
References: <12419_1620218338_609291E2_12419_14_1_787AE7BB302AE849A7480A190F8B933035376F08@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
In-Reply-To: <12419_1620218338_609291E2_12419_14_1_787AE7BB302AE849A7480A190F8B933035376F08@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Date: Wed, 5 May 2021 14:00:23 +0100
Organization: Old Dog Consulting
Message-ID: <00c801d741ae$9d3f5f50$d7be1df0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C9_01D741B6.FF04FFD0"
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQJuQMvxEqWR2+WD9JT4Yd2Nm/Io2amm2QZQ
X-Originating-IP: 81.174.197.74
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-26132.007
X-TM-AS-Result: No--32.577-10.0-31-10
X-imss-scan-details: No--32.577-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-26132.007
X-TMASE-Result: 10--32.577300-10.000000
X-TMASE-MatchedRID: jFqw+1pFnMyyoI+bK8UPQomfV7NNMGm+aMmm586o4gDLkl8e9W70i+bG U8GB3wTOFTo2vlU1NyObnoikv1ebIz3qUaC7D/bCUNaPigviKR+3Tv9y50YCew+kahHW2HeellO LygiW4eK1yM9bCD5oiThdtjRrqrTaoDVEvxCdva+DIpcBQ49iROIHwuSQU/r1LX3qyf3ewG+2xN wclkwT4nuUPCjcAPFZWrWZiuGLFx21Qh6WHjapUJVRzPxemJL0pQH4ogtVQP0Tz0lbMNUfmHMWf mr8UEU8CrycHYKMIPnWJbEjjmGDf63q0W95shdZGXGu0jdPFGS8xE2H2EuMWZ34cKC9q5Ue1FGZ A+8hUlLF1i5lZGaTYo3VQmLGOsmJ+KkAOA4P4SZT2G3xw+NXjs6gBdMBUo411y0aXF5eX+hUGfh qUN3t3eIuBLohLo6g/304ckbQATTIHUnF6aKmL/RuTPYDI6IvPG/nbj+YpTqFYUoGEe3iXmlrrh fytIG3k/6Yg3Hi4RZg62EFNWAoiIXSKdAME1CJwRTopFgZxh34qCLIu0mtILfiVDQ5MTOpTaAME FH51JxAid2kp2Th8E/UZRbvKC8tar70FkmypWTBNB2RMF+OfNjfNEL3Bey42e8n6mdjXsMhKJlo 7W31EUSgC0FOxoL/0Rl/2kc3ytkZnP0k5mQMLT5KMrAGYHEvEGWIW31OYIZHLqwBr3Ql/qdGplT dzC+OgMD4DNSa3dWsXEK66XfmvQ82vHIf00E6+s0+QZYAcN86En2bnefhoKShvRjfn4cUyR/Oai CiQKE22uoEm245fojjTDpHKwYmhzv5Bvz7TemeAiCmPx4NwGmRqNBHmBve1B0Hk1Q1KyI9euiYe 3o8eEprfkiB9+n/4kYXbobxJbLyU/oX+tpNmD7dy56DTrSQVYozIZuafYsSMnfm0glv/+hf9iwu FVQfD13NRvAmVgSwFMlIPaIBbQ==
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/b7eF-Lo_djEeBJUR_D64bCcPMLA>
Subject: Re: [Teas] draft-ietf-teas-ietf-network-slices: Network Slice vs. VPN(+)
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, 05 May 2021 13:00:35 -0000

Hi Med,

 

I’m currently working up some text to provide a definition of a network slice service and to clarify the endpoint definitions.

 

This text will be based on material that was on the list some while back.

 

I don’t think this document should dig too deep into VPN+ or ACTN. An enhanced VPN is not identical to a slice, and an CAN VN is not identical to a slice. However, ACTN and VPN+ both provide ways to realise/deliver network slices. I think that applicability statements should explain what can and can’t be done using those technologies, while this document should just note that they are possible architectural approaches.

 

There are, of course, very many ways to achieve network slicing dependent on the underlying technology. We need to be careful about this document:

*	Blessing any one approach
*	Trying to catalogue all possible approaches.

Other documents can try to establish consensus for particular approaches.

 

Best,

Adrian

 

From: mohamed.boucadair@orange.com <mohamed.boucadair@orange.com> 
Sent: 05 May 2021 13:39
To: adrian@olddog.co.uk; teas@ietf.org
Subject: draft-ietf-teas-ietf-network-slices: Network Slice vs. VPN(+) 

 

Adrian, 

 

I wonder whether you are planning to add some text to include the clarification discussed below. 

 

Thank you. 

 

Cheers,

Med

 

De : Teas [mailto:teas-bounces@ietf.org] De la part de mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com> 
Envoyé : mercredi 3 mars 2021 14:28
À : adrian@olddog.co.uk <mailto:adrian@olddog.co.uk> ; teas@ietf.org <mailto:teas@ietf.org> 
Objet : [Teas] Network Slice vs. VPN(+) RE: network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00

 

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 <mailto:younglee.tx@gmail.com> >; 'Luis M. Contreras' <contreras.ietf@gmail.com <mailto:contreras.ietf@gmail.com> >
Cc : 'Joel M. Halpern' <jmh@joelhalpern.com <mailto:jmh@joelhalpern.com> >; teas@ietf.org <mailto:teas@ietf.org> ; 'Eric Gray' <ewgray2k@gmail.com <mailto:ewgray2k@gmail.com> >; 'John E Drake' <jdrake=40juniper.net@dmarc.ietf.org <mailto:jdrake=40juniper.net@dmarc.ietf.org> >; 'Rokui, Reza (Nokia - CA/Ottawa)' <reza.rokui@nokia.com <mailto:reza.rokui@nokia.com> >; BOUCADAIR Mohamed TGI/OLN <mohamed.boucadair@orange.com <mailto: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.
_________________________________________________________________________________________________________________________
 
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.