Re: [Teas] [Teas-ns-dt] Various terms for transport portion of a network slicing

Adrian Farrel <adrian@olddog.co.uk> Fri, 02 October 2020 10:28 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 9DF383A0F01; Fri, 2 Oct 2020 03:28:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level:
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 ZGjSwmbILoae; Fri, 2 Oct 2020 03:28:14 -0700 (PDT)
Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (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 1D3203A0EE9; Fri, 2 Oct 2020 03:28:12 -0700 (PDT)
Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta6.iomartmail.com (8.14.4/8.14.4) with ESMTP id 092AN5VJ011559; Fri, 2 Oct 2020 11:23:05 +0100
Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B8CAB22048; Fri, 2 Oct 2020 11:23:04 +0100 (BST)
Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs2.iomartmail.com (Postfix) with ESMTPS id A1FAA22044; Fri, 2 Oct 2020 11:23:04 +0100 (BST)
Received: from LAPTOPK7AS653V ([87.113.82.114]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id 092AN21G003809 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 2 Oct 2020 11:23:03 +0100
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: mohamed.boucadair@orange.com, "'Rokui, Reza (Nokia - CA/Ottawa)'" <reza.rokui@nokia.com>, 'Lou Berger' <lberger@labn.net>, 'TEAS WG' <teas@ietf.org>, 'Vishnu Pavan Beeram' <vishnupavan@gmail.com>, "'BRUNGARD, DEBORAH A'" <db3546@att.com>, teas-ns-dt@ietf.org
References: <3C917BB8-A27B-48E8-8AB5-4674B9892E60@nokia.com> <11017_1601624558_5F76D9EE_11017_69_1_787AE7BB302AE849A7480A190F8B93303154C282@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
In-Reply-To: <11017_1601624558_5F76D9EE_11017_69_1_787AE7BB302AE849A7480A190F8B93303154C282@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Date: Fri, 02 Oct 2020 11:23:01 +0100
Organization: Old Dog Consulting
Message-ID: <007101d698a6$0292da60$07b88f20$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0072_01D698AE.6459DA70"
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQFTMQYDAmIR0bbsn2IS3RI9NGBZdAGyA/fXqn06nWA=
X-Originating-IP: 87.113.82.114
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-25700.006
X-TM-AS-Result: No--32.054-10.0-31-10
X-imss-scan-details: No--32.054-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25700.006
X-TMASE-Result: 10--32.054200-10.000000
X-TMASE-MatchedRID: IeZYkn8zfFqyoI+bK8UPQnFPUrVDm6jtJdXjF5ArCFcW6M2A15L1QOmW pqKXmZL5E8+hTCLnkICZKLS7xMLJgu7Gghg9I/Xgmq+iLtFCY9K/Oyea3TSLpL+Z3Zp2Td1E3JW shmL/k78GlEyopPG/zTjtiHUzotNZDZ4p7Io2Wwy6C8mlSPMNlwvxMaV6x4s8I0YrtQLsSUxkvX lLXScTU3iVrFrVkm01xta3eM1SP4r+W4r7bDolOEOTmmhJhc2XZ30Fe2T1VshGMe+tDjQ3FubGU 8GB3wTO506bre7PTZrwR8oBAS7kXSaOvKjLoI2RuwdUMMznEA8ZskwWqoib3K9w4ltnXuYPpEJB 1tcHom/0qn1mAEDSpwRsyc7kcVIQUjeY/xoLQ8HjxJDUku2PNlm76ppjs/b0xgta/Sk1/OJ5D7B 91agfNwFb3jCi/cH1SkSTeTyVPBpeVY7HzpfYE07yqWc5cVLPPuMXQIJaY6CGy6+erFdQC92EH/ nGN9lH8ro3Cv/OOP0+IJsxz6/MGx1pRstOIPc+54eqweLWaL74uJ1REX4MHYVquVYFwXAmluDPT 9+fXDz2hOsskjMbeRxtvLYB7XTZWIJbtULKjWRvxoVWUhKm4gGZ/+APXW9kPSeoGnZSYhyLsV/e 63RfIHTCYWtu66AuujKSZWxviTcfK5d3ft8IkLU+IyHhkXf1frTt+hmA5bKPiMW+3YzkggpjGUM 5ccGUv8mPJW+yd6SiHK4/d1hf8p9vFrcDXJOnKZ73BulBsrlr9+Kgn2XgeDyC5ddG2JcglHXppc pLXlDIWhnqaeJJMdHv8kXlv4isNEWCshKSxvKeAiCmPx4NwGmRqNBHmBveGtkvK5L7RXERNAkdu 81AZV1FkXVL+ky7OMB0shqXhHpRNMp/1f5FSi9pvh8xHInIzpReeYvPKAjYC+o+oC437ST7YvNv L+s7
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/P63PFAD4sYX11DOb7YS0mBJ4tDI>
Subject: Re: [Teas] [Teas-ns-dt] Various terms for transport portion of a network slicing
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: Fri, 02 Oct 2020 10:28:18 -0000

Med makes a really valuable point, but I think I disagree about where it should take us.

 

If the current draft is focussed on “connectivity slices” (whatever they may be :-) then one of two things should happen:

1.	It should broaden its focus to “IETF network slices”
2.	It should be clear about its focus and use the right naming accordingly. AND a separate document may be needed to handle the broader scope of “IETF network slicing”

 

And Med’s question:

> are there any attributes that will be captured in the

> “favorite-ietf-slice-name” and which do not belong to connectivity?

 

I think slicing applies to all of the resources in a network. Those certainly include bandwidth and forwarding resources (buffers, cross-connections, etc.), but they also include storage, processing, virtual functions, and anything else that the sliced network may have available to provide services to the consumer.

 

Best,

Adrian

 

 

From: Teas-ns-dt <teas-ns-dt-bounces@ietf.org> On Behalf Of mohamed.boucadair@orange.com
Sent: 02 October 2020 08:43
To: Rokui, Reza (Nokia - CA/Ottawa) <reza.rokui@nokia.com>; Lou Berger <lberger@labn.net>; TEAS WG <teas@ietf.org>; Vishnu Pavan Beeram <vishnupavan@gmail.com>; BRUNGARD, DEBORAH A <db3546@att.com>; teas-ns-dt@ietf.org
Subject: Re: [Teas-ns-dt] Various terms for transport portion of a network slicing

 

Hi Reza, all, 

 

Thank you.

 

I do personally prefer « connectivity slice ».

 

Unless I’m mistaken, the current draft’s focus is the connectivity component of a slice (whatsoever a slice means). So, **renaming** the abstract notion while **maintaining the same scope and attributes definitions ** do not help clarity.

 

So, are there any attributes that will be captured in the “favorite-ietf-slice-name” and which do not belong to connectivity?

 

Cheers,

Med

 

De : Teas [mailto:teas-bounces@ietf.org] De la part de Rokui, Reza (Nokia - CA/Ottawa)
Envoyé : mardi 29 septembre 2020 20:42
À : Lou Berger <lberger@labn.net <mailto:lberger@labn.net> >; TEAS WG <teas@ietf.org <mailto:teas@ietf.org> >; Vishnu Pavan Beeram <vishnupavan@gmail.com <mailto:vishnupavan@gmail.com> >; BRUNGARD, DEBORAH A <db3546@att.com <mailto:db3546@att.com> >; teas-ns-dt@ietf.org <mailto:teas-ns-dt@ietf.org> 
Cc : Rokui, Reza (Nokia - CA/Ottawa) <reza.rokui@nokia.com <mailto:reza.rokui@nokia.com> >
Objet : [Teas] Various terms for transport portion of a network slicing

 

Hi Lou, Pavan, Deborah and all,

 

As per TEAS WG chairs request during the last week’s meeting on network slicing, the co-authors of the definition draft had a few meeting and compiled all the potential terms with their pros and cons in the following table.

We feel that we captured all the terms suggested by TEAS and NSDT members in mailing lists and during the various meetings. Please let us know if any terms is missing.

 

In summary, the co-authors of the draft believe the term “IETF Network Slice” is a golden middle where IETF provides the exact context of any Network slice.

 

Cheers,

Reza (on behalf of all co-authors)

 




Various options for transport connectivity term from IETF point of view (without any specific order)


 

Term

Suggested by 

Pros

Cons


1

IETF Network Slice

TEAS chairs

o It clearly elaborates the scope of technologies addressed with in the IETF leveraging the industry-wide term 'network slice.
o It is golden middle, where “IETF” provides the exact context to “Network Slice”
o Acceptable to TEAS WG chairs
o Acceptable to draft co-authors

labeling a piece of work with SDO name is not a good idea and IETF has always worked towards wider use, generic solutions, so the name may be restrictive.


2

Transport Slice

Draft Authors and NSDT

o ‘Transport network’ is an abstraction of connectivity between the (network) end-points which is technology agnostic.  Well covered by RFC5921.

o Aligned with other SDO (i.e. MEF)
See Figure 17 of following white paper
https://wiki.mef.net/display/CESG/Slicing+for+Shared+5G+Fronthaul+and+Backhaul+-+White+Paper

As per recent WG adoption poll, it is not accepted


3

Transport network slice

Draft Authors and some IETF members

‘Transport network’ is an abstraction of connectivity between the (network)end-points which is technology agnostic.  Well covered by RFC5921.

As per recent WG adoption poll, it is not accepted


4

Connectivity Slice

Draft Authors

o Since the transport slice is a set of distinct connections, term "Connectivity Slice" is selected

o Aligned with other SDO (i.e. 3GPP) 
See Figure 4.9.3.1 of TR 28.801 and  http://www.3gpp.org/NEWS-EVENTS/3GPP-NEWS/1951-SA5_5G

As per TEAS WG chair, connectivity has different meaning at IETF


5

Connectivity Network Slice

Luis

The term Network becomes now narrow downed to the reference to connectivity, which is subject of IETF

As per TEAS WG chair, connectivity has different meaning at IETF


6

Connection Slice

Luis

o The term associates the concept of slice to the connection enabling the data transmission among end-points participating of a communication
o Note – here we could then follow a similar approach to how the VPNs are classified as L2 or L3; I mean L3/L2/(L1?) Connection Slice; if we classify the Connection Slices in that manner, such classification of the Connection Slice types will also help to describe recursiveness or hierarchical (multi-layer) slicing

o A connection can be established at different levels, including protocols above Layer 3
o Connection slice can make the people understand that there is a single connection represent a slice (i.e., 1:1) while actually could not be the case (i.e., 1 slice being formed by N connections)


7

Slice Network

Stewart 

Stewart is coming with some background that a slice is combination of storage, compute and communications (or network). Slice network means an existing network is sliced to serve a particular user-case.

According to Lou, it has entirely different meaning.


8

Virtual Slice Network (VSN)

Luis

o Variant on top of Stewart’s suggestion to link with the evolution of the concept of legacy VPNs
o The term reminds the idea of logical network per customer focusing on connectivity
o As before, it could be possible to follow a similar approach to how the VPNs are classified as L2 or L3; I mean L3/L2/(L1?) VSN; also here, such classification of the VSNs can also help to describe recursiveness or hierarchical (multi-layer) slicing in transport

o There is no specific reference to transport or connectivity, apart of the generic idea of network (which we now is also an overloaded term)
o Differently from a VPN, which basically is a single instance including a number of locations, a VSN could refer to a set of individual VSNs (e.g., one per network segment). So can be probably confusing. Thus probably it would be needed to add additional terms such as sub-VSN, or VSN-segment, VSN-part, VSN-sub-slice, or alike


9

TE Network slice 

Some TEAS members

Aligns with same  rationale used for naming ACTN.

Since not all transport networks are TE enabled, the realization of connectivity might be in a non-TE network. So, this term seems not appropriate


10

Carrier network slice

Webex/Stewart

In a generic use of term 'carrier' a carrier slice network carries use-case specific network traffic.

it may be confusing because it is associated with the infrastructure of telecommunication service providers, i.e., FNO/MNO. Recently, some network operators  deploy COTS servers in their infrastructure for MEC usages, and some readers may expect control of compute and storage  resources is in scope


11

Network slice

Some IETF members

An adoption of industry-wide term. While each SDO may look at it differently based on its own set of capabilities, for an end user it is a network slice in a specific technology domain.

o Since multiple connections are part of a single "Network Slice", it is not a good idea to call each of these connections "Network slice".
o There is a lack of 'harmonized' definition of network slice. For end customers, message may be confusing on which SDO they should ask for what part. It may lead to duplication of orchestration or APIs, depending upon who is controlling end to end network slice  - is it 3GPP operator, MVNO, ISP, service-integrator, OTT etc... 


12

Data transmission network slice (DTNS)

Shunsuke 

Since the transport slice is a set of distinct connections, providing the data transmission, this term might be suitable.  

 


13

Transmission Network  Slice

Reza

Since the transport slice provides the data transmission across transport network, this term might be suitable.  

 


14

Transmission Slice

Reza

Same as "Transmission Network Slice"

 

 

 

 

_________________________________________________________________________________________________________________________
 
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.