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

[Uma Chunduri <[e-mail]>]

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 <[e-mail]> 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:[e-mail]] *De la part de* Rokui, Reza
> (Nokia - CA/Ottawa)
> *Envoyé :* mardi 29 septembre 2020 20:42
> *À :* Lou Berger <[e-mail]>; TEAS WG <[e-mail]>; Vishnu
> Pavan Beeram <[e-mail]>; BRUNGARD, DEBORAH A <[e-mail]>;
> [e-mail]
> *Cc :* Rokui, Reza (Nokia - CA/Ottawa) <[e-mail]>
> *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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas-ns-dt
>