Re: [Teas] Various terms for transport portion of a network slicing
Adrian Farrel <adrian@olddog.co.uk> Tue, 29 September 2020 21:21 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 777553A0CA4; Tue, 29 Sep 2020 14:21:49 -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 fr04oq0qOZof; Tue, 29 Sep 2020 14:21:46 -0700 (PDT)
Received: from mta8.iomartmail.com (mta8.iomartmail.com [62.128.193.158]) (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 1C13F3A0B45; Tue, 29 Sep 2020 14:21:44 -0700 (PDT)
Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta8.iomartmail.com (8.14.4/8.14.4) with ESMTP id 08TLLWvX008606; Tue, 29 Sep 2020 22:21:32 +0100
Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id BB0CF2203B; Tue, 29 Sep 2020 22:21:32 +0100 (BST)
Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs1.iomartmail.com (Postfix) with ESMTPS id A4FB02203A; Tue, 29 Sep 2020 22:21:32 +0100 (BST)
Received: from LAPTOPK7AS653V ([84.93.44.153]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id 08TLLVFo003250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 29 Sep 2020 22:21:31 +0100
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
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
References: <3C917BB8-A27B-48E8-8AB5-4674B9892E60@nokia.com>
In-Reply-To: <3C917BB8-A27B-48E8-8AB5-4674B9892E60@nokia.com>
Date: Tue, 29 Sep 2020 22:21:29 +0100
Organization: Old Dog Consulting
Message-ID: <030901d696a6$8013b100$803b1300$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_030A_01D696AE.E1D9EDC0"
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQFTMQYDAmIR0bbsn2IS3RI9NGBZdKqG6bUA
X-Originating-IP: 84.93.44.153
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-25696.003
X-TM-AS-Result: No--26.360-10.0-31-10
X-imss-scan-details: No--26.360-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25696.003
X-TMASE-Result: 10--26.359700-10.000000
X-TMASE-MatchedRID: IeZYkn8zfFqyoI+bK8UPQnFPUrVDm6jtQygdlfAHFNaZvRtF5rjVr9sb V356Z7V+ug5dqPci2q7Wf4Ype+Ztj958X09S0k2shL9NX2TqmkBzKWE0ih8hCHye9SiPR8RQ8rE 5KFrebpWj6UK/VYvOqnso3Kvs6qV+Jo68qMugjZG7B1QwzOcQD6ccEhvIyMIUF2PoDU7mzkDsh1 csNX6njBMbIiVA+EZDKGGXMHX1++pN3GWDKhOOSENUNKW1ETXB4PzAP29VwAGiPu/PEGvbM7JnP h8w+R5o2XPd2cfJMchjXCg35ruzVonAbcBPggf1i3qFkVLH3UC8xE2H2EuMWWxM7ZY294egByyV imjmJJPtIxNT28Vqmb6iNRPDDqvmJUUxzOv92rOWsa/6SdAOX2QBrQiRNt2IzulpDGRdyOY7q9O TQ3QUtYprQMEol3TLdHpJDMbJDvHg7jbg3Rf0oBbwCXv1ucAPcaDaLyypNNoqaaDLXDhC+HpsJ0 EUw+XtHY2ojv84IFKcHQU7eLchq+z+fPF883E7sp7Uow62+uH5bNUY+JJjyMuSXx71bvSLKK+9h MFqpxDrcFn67wIg3RE0W5I8HGkWO5sXKty63LO9NsL2xEmLyxmyTBaqiJvcWfjPRPx8eijtsP47 XwHOog6DTD2m0HNBTG35/Sgpu3q+ie7KTaq4mc24dvoEygEP9/plKg1lCsjmQJUUegCCe7MlgDf usiEislVouE/7acLJJaEievVvIXwBfEipFU56dPM8veyrICYCn5QffvZFlfQkrXkUDmL13CuR4n zeLi6xQhSFSHmxbvwpg1at1OTUojetVtTnysGeAiCmPx4NwGmRqNBHmBve1B0Hk1Q1KyKbBVa1r lvjNwaIkv313qJpOwBXM346/+x2wPiScrVbst6zMc1Da0ulDhsmnapNYP5OYCk57lRQHX7A0Igx 55kR
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/QWPSg3wukg7Dr_vFHWNa_SBcE78>
Subject: Re: [Teas] 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: Tue, 29 Sep 2020 21:21:50 -0000
I think this is good progress, Reza. Thanks for working on it and reporting it. I could live with “IETF Network Slice”. In your table for the entry on “Network Slice” you say: > Since multiple connections are part of a single "Network Slice", it is not a good > idea to call each of these connections "Network slice". I find this text to be very important because I think it underpins very much of the confusion in the discussions. For my part, I don’t want to apply a name to any single “connection” but want a term that describes the partitioning of underlay network resources for use by one or more overlay connections. Cheers, Adrian From: Teas <teas-bounces@ietf.org> On Behalf Of Rokui, Reza (Nokia - CA/Ottawa) Sent: 29 September 2020 19:42 To: 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 Cc: Rokui, Reza (Nokia - CA/Ottawa) <reza.rokui@nokia.com> Subject: [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"
- [Teas] Various terms for transport portion of a n… Rokui, Reza (Nokia - CA/Ottawa)
- Re: [Teas] Various terms for transport portion of… Eric Gray
- Re: [Teas] Various terms for transport portion of… Rokui, Reza (Nokia - CA/Ottawa)
- Re: [Teas] Various terms for transport portion of… Eric Gray
- Re: [Teas] [Teas-ns-dt] Various terms for transpo… Kiran Makhijani
- Re: [Teas] Various terms for transport portion of… Adrian Farrel
- Re: [Teas] Various terms for transport portion of… BRUNGARD, DEBORAH A
- Re: [Teas] Various terms for transport portion of… Dongjie (Jimmy)
- Re: [Teas] [Teas-ns-dt] Various terms for transpo… Eric Gray
- Re: [Teas] [Teas-ns-dt] Various terms for transpo… Kiran Makhijani
- Re: [Teas] Various terms for transport portion of… mohamed.boucadair
- Re: [Teas] [Teas-ns-dt] Various terms for transpo… Adrian Farrel
- Re: [Teas] [Teas-ns-dt] Various terms for transpo… mohamed.boucadair
- Re: [Teas] [Teas-ns-dt] Various terms for transpo… Uma Chunduri