Re: [Teas] Network Slicing design team definitions- transport slice

Young Lee <younglee.tx@gmail.com> Tue, 01 September 2020 14:57 UTC

Return-Path: <younglee.tx@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 199913A0B2F for <teas@ietfa.amsl.com>; Tue, 1 Sep 2020 07:57:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
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: 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 GmCOI765sKdU for <teas@ietfa.amsl.com>; Tue, 1 Sep 2020 07:57:03 -0700 (PDT)
Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 417033A0B25 for <teas@ietf.org>; Tue, 1 Sep 2020 07:57:03 -0700 (PDT)
Received: by mail-il1-x133.google.com with SMTP id e14so1427076ile.6 for <teas@ietf.org>; Tue, 01 Sep 2020 07:57:03 -0700 (PDT)
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=peMU5jWZfvsWVTdAX57rzllK+yXZLbKCmwAyniPNO2A=; b=thGh6Lwdqa8CgGmdA+hkI7B0zOtBHDV6TD1prP8VUdiEFELMgtxPmvLoArzrprsTMQ HP6pPBhrOc/17MyqVijH9boNrXI03SKqvm7b3BxhWfg3E3oPQMiclqXHeetjJXCtIeRm Pa9Cpj5RNDzUQ6qs245vFetT3VScjhg30w5ZYESY7Ka3q9D9nLxqMMD/jonHo9haVjKJ Gkq9HSbDJcskwKiINPSzOa8u9TStEwHnV9aX5/Sbe4Z7DE063SRUlFoNNtEHRkZ5mxeD YffHrdFzahyQUKCwhQpcccDg6ZoZP0rqjtSygxFU69vx1d/HtQDm0QAODfhW3OG6ywLo XZug==
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=peMU5jWZfvsWVTdAX57rzllK+yXZLbKCmwAyniPNO2A=; b=m2SWI0kwbn6Pf32Wp8uezngO9GoclPKi4e4SlBm+QnVVD7vFKv1tMrUL89hdNDwMVE 8xnXKqRkEWYqGEIgEzi5bkETv30cX7XXYCdTZu3uOZRf51oEyeo6VfZVH7heUs3dvr3s bMgbGHLb6vJir9WkWbquqXtDiWTfm7odTAhj2mX+/X6Fxsk+yjlKX88UfePrZXnQXMot h8uK9gI79n2ZuRFaru2c619Lc8a/yfJ+uIsmgDsjveF+11iV2X2fFus7TlgEZCz0rOh/ NzlA6zXb53NUQQulUF/A1ejONF3XhE4L3xtbE83CHvkeN4+KHtEpRW5xbI94lpXzDCmd miJA==
X-Gm-Message-State: AOAM532JWxghR/S/a+TUE2a+yNfeZZb7OqhrANCUFfrIXW5dCd66vFth PwePIe4YW4YBRZCDGDsq0GbrYuV+UzNZMUCP3Xs=
X-Google-Smtp-Source: ABdhPJyd8ANWPqmWCKvj+uwQ6hZ+T6W76WR3Ij/ZnpOBTq+KJWZR4aznca1FGwOyiSklIq9W5KoWUvDJSpcNHTbxCOo=
X-Received: by 2002:a92:9986:: with SMTP id t6mr1592885ilk.28.1598972222282; Tue, 01 Sep 2020 07:57:02 -0700 (PDT)
MIME-Version: 1.0
References: <70af45b0bdf54f418ad83fcb65906f4a@att.com>
In-Reply-To: <70af45b0bdf54f418ad83fcb65906f4a@att.com>
From: Young Lee <younglee.tx@gmail.com>
Date: Tue, 1 Sep 2020 23:56:49 +0900
Message-ID: <CAGHSPWM0mnm_ky2wPVS4fFKpe91nNCBJvWbHtoZVm=-cDA79jg@mail.gmail.com>
To: "BRUNGARD, DEBORAH A" <db3546@att.com>
Cc: TEAS WG <teas@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000050a1bb05ae41bbeb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/DMUh1ZFLfLHeblLW98bC9Ed4LWI>
Subject: Re: [Teas] Network Slicing design team definitions- transport slice
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, 01 Sep 2020 14:57:05 -0000

Hi Deborah,

I also am wondering where ' transport slicing' came from. 3GPP uses network
slicing in the following three subnets: RAN, CN, and TN; and accordingly it
uses RAN slicng, CN slicing  and TN slicing.

There is always prefix "Network" is associated with slicing whether it is
RAN, CN, or TN.

As you pointed out, when RFC 8453 was developed in TEAS WG, we originally
used the term Transport Network Slicing, but later this term was replaced
with Traffic Engineered (TE) Network slicing.

Transport slicing is a bit orphanish. It should be either TE network
slicing or Transport network slicing. In TEAS WG, TE network slicing might
be more consistent with RFC 8453. Just for your reference, the following
terminology has been defined in RFC 8453:

TE Network Slicing:  In the context of ACTN, a TE network slice is a
      collection of resources that is used to establish a logically
      dedicated virtual network over one or more TE networks.  TE
      network slicing allows a network operator to provide dedicated
      virtual networks for applications/customers over a common network
      infrastructure.  The logically dedicated resources are a part of
      the larger common network infrastructures that are shared among
      various TE network slice instances, which are the end-to-end
      realization of TE network slicing, consisting of the combination
      of physically or logically dedicated resources.


Thanks.
Young




2020년 9월 1일 (화) 오후 11:31, BRUNGARD, DEBORAH A <db3546@att.com>님이 작성:

> Hi,
>
> (speaking as an individual)
>
>
>
> Picking up on Jari’s comment “sometimes people want to use labels that are
> a bit more imprecise, but I think we should strive to avoid such labels as
> much as we can”, can you give more background on the choice of the term
> “transport slice”?
>
>
>
> I noted while you have text on the use of “transport” by 3GPP as
> specifying a very specific sub-network in the radio network (which excludes
> the handoff to the rest of the network), you referenced RFC5921 (MPLS-TP)
> for the term “transport”.
>
>
>
> There was a long thread of mail on ACTN, RFC8453, to move away from the
> term “transport” to “TE networks” which was agreed to be more
> specific/appropriate for TEAS. Considering IETF is already using the term
> “network slicing” (including TEAS RFC8453) and 3GPP use of the term, I
> don’t understand the use of “transport” in this document.
>
>
>
> Considering IETF already uses the term “network slice” and 3GPP uses the
> term (and all the industry SDOs), I am concerned we will be confusing the
> industry, especially as “transport” is an imprecise term for TEAS work. Is
> this work a subset and scoped only to the 3GPP “transport” cloud (and
> implied use of MPLS-TP)? Or is it planned to be generic (for all TE
> networks)?
>
>
>
> Deborah
>
> (speaking as individual)
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
>