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

Eric Gray <> Tue, 29 September 2020 19:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1E0C03A110A; Tue, 29 Sep 2020 12:41:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1lGmqnQOmWDp; Tue, 29 Sep 2020 12:41:39 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::f2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 044563A1106; Tue, 29 Sep 2020 12:41:39 -0700 (PDT)
Received: by with SMTP id db4so2914892qvb.4; Tue, 29 Sep 2020 12:41:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=m7fL4NP8V48fL1CmwoQBHlm8focpQwzRGrh2g1iILyY=; b=tuzIInDeT4r5cz78yWOICVo8LBrwYiY6x30oK6x8uAjaf+gVLjGpp0w02N2Y+rapbc z+bez6Andgx4DVyrBqvXmRoSfu+NaphRKrN6ZnrNDaTnQxicHZjt9/fj4eYJ5eJYcDt/ h6h3+0fgX98qZAF0x7WU7UVCLPxEsG0u02lvPUIM7mp+SWXjmEBtPdKhal+ix0ZzPqof N0TzZ73oaZ0aE0s3Lok6rXMOUX73cf1SqIRdjqY8i+QbQuw4f+ekIWlj0lQ9F7iuFLb8 16GD08qppglTJzMezw7C/vz2WSWKJ2eJECGJtaiwYpwd/OzIs4E0+d1+rhaQcZQJrC2r LOqA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=m7fL4NP8V48fL1CmwoQBHlm8focpQwzRGrh2g1iILyY=; b=PM45jB+jbRL7d5LfAag+rB5pUlcyFjDbwj6c6DqFbXtDQAvpo2WBtsyfhXQRnR0ZTd DQ5/pQGrZaNoevMNnwohoNrfkeQsa3XD7a/3OBKHx0ZdFpwjATVhWcPtiaR4X6axeP5h GIzOLpi5KvP9COLsJScAiR7WJueyL4xRNW867gaLrVaKUMLeN6o1knVf90DyEzO6N8s6 2TOVbnvcR8qZwiyF1F5ZHvQnn8qRAC2oP20TxgImdnuLIONEuosEjkJO0BpSGiHIB/qk 3OR+oZCO+oB0L41x26HibyYh4JjEUnXXGjqwHCPByUpLi2HNg/kja2zDtsrpm3uvpBnO edrg==
X-Gm-Message-State: AOAM5333pSBqzkxeGV7QNS5XTV2aZAfnxaRanzzXqGEPkqhwkF/dQ3dd KPtUzVhI9Ra3tZgyIADRWEY=
X-Google-Smtp-Source: ABdhPJyVAom3jRXtyITb0ah/W4b23Qfg9UCcClf7gssCftRpY/sga/2yQdxLd+ItG7PqKph9UHECEg==
X-Received: by 2002:a0c:a203:: with SMTP id f3mr6040685qva.33.1601408497946; Tue, 29 Sep 2020 12:41:37 -0700 (PDT)
Received: from ?IPv6:2601:85:4680:3329:49e7:f672:f431:32a0? ([2601:85:4680:3329:49e7:f672:f431:32a0]) by with ESMTPSA id g12sm6021491qke.90.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Sep 2020 12:41:36 -0700 (PDT)
From: Eric Gray <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_F62F6B98-8C56-47C5-8193-C1E1BB1A04FD"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 29 Sep 2020 15:41:34 -0400
In-Reply-To: <>
Cc: Lou Berger <>, TEAS WG <>, Vishnu Pavan Beeram <>, "BRUNGARD, DEBORAH A" <>, "" <>
To: "Rokui, Reza (Nokia - CA/Ottawa)" <>
References: <> <> <>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <>
Subject: Re: [Teas] Various terms for transport portion of a network slicing
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 29 Sep 2020 19:41:42 -0000



	So this makes the TSC become an “IETF Network Slice controller” - or “IETF NSC” and we should be able to just call that a network slice controller (for brevity) in our documents, once we have stated the intention to do so.

	In terms of applicability, a 3GPP “transport network slice” consumer would be an “IETF network slice” consumer, unambiguously, when using a service model or NBI defined for that purpose by the IETF.

	It remains unclear if there would need to be a different matching of names for other applications of an IETF network slice, but that would be an issue to be resolved by whoever wishes to describe applicability of IETF network slices for that (or those) other application(s).  

	Are there other trickle down name changes to be made?


> On Sep 29, 2020, at 3:27 PM, Rokui, Reza (Nokia - CA/Ottawa) <> wrote:
> Eric and all,
> Yes. The term “IETF Network Slice” is acceptable to co-authors.
> Reza
> From: Eric Gray < <>>
> Date: Tuesday, September 29, 2020 at 3:10 PM
> To: Reza Rokui < <>>
> Cc: Lou Berger < <>>, TEAS WG < <>>, Vishnu Pavan Beeram < <>>, "BRUNGARD, DEBORAH A" < <>>, " <>" < <>>
> Subject: Re: [Teas] Various terms for transport portion of a network slicing
> Reza,
> Not exactly sure what your mail is concluding.
> Is a “golden middle” the same as an acceptable compromise?  If so, it sounds like we’re saying that we find this term acceptable.
> That would be a good thing.
> —
> Eric
>> On Sep 29, 2020, at 2:41 PM, Rokui, Reza (Nokia - CA/Ottawa) < <>> wrote:
>> 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
>> <>	
>> 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 of TR 28.801 and <>	
>> 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 mailing list
>> <>
>> <>