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

Uma Chunduri <umac.ietf@gmail.com> Mon, 18 January 2021 20:10 UTC

Return-Path: <umac.ietf@gmail.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 7B52B3A0AEE; Mon, 18 Jan 2021 12:10:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=gmail.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 dS__wKGIw4sV; Mon, 18 Jan 2021 12:10:44 -0800 (PST)
Received: from mail-yb1-xb29.google.com (mail-yb1-xb29.google.com [IPv6:2607:f8b0:4864:20::b29]) (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 5608A3A0ADB; Mon, 18 Jan 2021 12:10:44 -0800 (PST)
Received: by mail-yb1-xb29.google.com with SMTP id e67so5226836ybc.12; Mon, 18 Jan 2021 12:10:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=z4LhZfQ9NHchfFttGrNVUWafnuoLlJbOUUqiSxSPn+w=; b=penOEXTjHo3qbSdkARp55TCJCifg2Ml8rAcSPM5N/VuVr4Pg6tetzWDzpQvVR+qWuC YQRpNWGDlaYlvRjUr7MfDEk/AwuloQAHV2eo0FcRiYcq9uYiJCkh9UCbWSXNA2yQq0km 67dAGj2gyDv6AaSB+Q7ybvoAw0LrN15EQLbMUzf65pkVPXLOyMyaXcoLEWRhtpklI8EI QY9pH3CW4kwoCvtp7HIlpQ2AqqbxCCW6WPqiZI3aShz0rn+9qwjeNgvHdi5LsTYluYDa oRDHmCPDA0vPXI3ipDLA8n+TgcKLZstPwKjSPYWLbj6N2guD07V+tcQcaKNlDnAx93xk T0Sw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=z4LhZfQ9NHchfFttGrNVUWafnuoLlJbOUUqiSxSPn+w=; b=owTXctyUMTqAExS3Fe1zMF+/CkI3iCu3tId+Qn4DV999kZiz2UMZpihQv6Bs2+FXnm 3FC7K9nJDE4/hkxIwuamLdDfwsk+hMF5Wd0fpREHTy0Fe2uOKCk4+Oa1ClWpJVmVcbg2 4TiXsbziM3/2clF5jprtN0qDeoilB6nUwgJq7r1N+pb5fnY5l7hw4RXE6VEIvw9OIClD 61C0qt+4SKFnW8VbQ3pcAKvrFri7T6kR8TCYTyRWZA8JPMAXu0GEnFJyG69mbbg6Lb2V JjYjaMbzr48HtLpEwT+Hd/Pm5aIe+xbxw6kC0AAFEml/1Z7NGwPV53GwDYn33UBeuBsg pmcQ==
X-Gm-Message-State: AOAM5317OliEGbPSAv8tux6XBbP3PdEomW3i0D+Zs2UNK0cHS/dOzS9H F2lYf53I9wpkFoPuW4OjQWmIuYMOlfB6bJW0IlxUIoIo
X-Google-Smtp-Source: ABdhPJydoneKtxBtCjfgK5LhnizlywaT2mvxTIL/hvTDM2qgXmItv9xzpt3AVZ1LLv1+B9Jd5MLxAiOtQ07ut254+wM=
X-Received: by 2002:a25:3104:: with SMTP id x4mr1141609ybx.141.1611000643588; Mon, 18 Jan 2021 12:10:43 -0800 (PST)
MIME-Version: 1.0
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>
From: Uma Chunduri <umac.ietf@gmail.com>
Date: Mon, 18 Jan 2021 12:10:32 -0800
Message-ID: <CAF18ct5m203sEOw3PrvK2Pm-g4RsjYA+MRcinfVyNs3YzqJf5A@mail.gmail.com>
To: mohamed.boucadair@orange.com
Cc: "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" <teas-ns-dt@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001814e105b93251e7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/9OkDDr1y617o4Wd_HjTMFkJUgS8>
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: Mon, 18 Jan 2021 20:10:48 -0000

Thought late to the discussion here


+1 for the points raised by Med Below and to the name ( I know, it's
possible that the name won't be changed).


--
Uma C.

On Fri, Oct 2, 2020 at 12:42 AM <mohamed.boucadair@orange.com> wrote:

> 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>et>; TEAS WG <teas@ietf.org>rg>; Vishnu
> Pavan Beeram <vishnupavan@gmail.com>om>; BRUNGARD, DEBORAH A <db3546@att.com>om>;
> teas-ns-dt@ietf.org
> *Cc :* Rokui, Reza (Nokia - CA/Ottawa) <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.
>
> --
> Teas-ns-dt mailing list
> Teas-ns-dt@ietf.org
> https://www.ietf.org/mailman/listinfo/teas-ns-dt
>