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

Jeff Tantsura <jefftant.ietf@gmail.com> Wed, 02 September 2020 18:27 UTC

Return-Path: <jefftant.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 5F8AA3A0C8B for <teas@ietfa.amsl.com>; Wed, 2 Sep 2020 11:27:20 -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 d-gIOVV6a9OV for <teas@ietfa.amsl.com>; Wed, 2 Sep 2020 11:27:17 -0700 (PDT)
Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) (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 D79413A0C57 for <teas@ietf.org>; Wed, 2 Sep 2020 11:27:17 -0700 (PDT)
Received: by mail-pj1-x1032.google.com with SMTP id mw10so205895pjb.2 for <teas@ietf.org>; Wed, 02 Sep 2020 11:27:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=X5lCa0vYll42K+zlu7PfVUk9FHpm5nJ6Fv7vPAXt7w4=; b=N84dvcWMPuD3QsqhoXPQTzyy9QssFJDZg8dPZj2DVGx7Ju4ETXwM4h+RbxITDADmNr xCuhIxKoVba02gJiG6fjY+73YwgdI5X0sWVga5MnJvOJ8VH1ox5I9HvqyfBCJR9AbA4Z VWQrcwK45XvjojUBbqNaE3b1BCQ3DQF5fltGoS60S/0+i74BP/yOwaK/vx57qb/QZSF9 OjGtCwT6ebh1CGHEvLg+Lj3hET0mhJJ9vxpliF7CogOFw+dAzNIJxJnUxizXxN9Ma40c VhwfVA0EUnjf4CrM6A0kImpEA6S6x8t+oIcsJOUtBwtgqCvygHB6csn/oBVTibtdWrTG VdaA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=X5lCa0vYll42K+zlu7PfVUk9FHpm5nJ6Fv7vPAXt7w4=; b=K0nLrL757RrfR9d4xJJQcXLtg23tp8Zbvm595bWWjgKYrdO1fuu8JRBlfdwYWUKKkJ nry2nNS0Igt2RJiZaQGyrj495ygONkPzBpQqpvUJweoO8a1/IUG2xzi8ZgqDnKMgOJFA LNmlGThv4uGrhnVsVoEKlOmJ5u5H1GrQYlT2lPyYHeSmwfRw0tPAnsGaUumDmZm8ZuPX X93ahYNIPdj97SwEH25dfkGlPLGqJGpipzQJj/58lWEeS+Mk7khn5/JksUrwoy/r13j+ TyI4rUrEGGHrRAbyco6/nf0Y0yOLU3EiX7q5edllAYDfpykHglk2kr/Hlu/4/cBquJYW zRqw==
X-Gm-Message-State: AOAM532CKqU2VekHBUvElQ1Evesorxx+qhBk5iYmSHnH4jGOj7nYAxt7 yQGEBXHlFQun5O8EpPiEpF0=
X-Google-Smtp-Source: ABdhPJxb3CkrFLzn9q0h0HpvSz84VNfmn0yFRF/8/hqNfZ6q4i6Cy5nZ7yHBfc1l4ioSM5V1chhQ5g==
X-Received: by 2002:a17:90a:5295:: with SMTP id w21mr1668442pjh.45.1599071237320; Wed, 02 Sep 2020 11:27:17 -0700 (PDT)
Received: from [192.168.1.3] (c-73-63-232-212.hsd1.ca.comcast.net. [73.63.232.212]) by smtp.gmail.com with ESMTPSA id h65sm174492pfb.210.2020.09.02.11.27.15 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Sep 2020 11:27:16 -0700 (PDT)
Date: Wed, 2 Sep 2020 11:27:10 -0700
From: Jeff Tantsura <jefftant.ietf@gmail.com>
To: "=?utf-8?Q?Rokui=2C_Reza_(Nokia_-_CA/Ottawa)?=" <reza.rokui@nokia.com>, John E Drake <jdrake@juniper.net>
Cc: Kiran Makhijani <kiranm@futurewei.com>, TEAS WG <teas@ietf.org>, =?utf-8?Q?BRUNGARD=2C_DEBORAH_A?= <db3546@att.com>
Message-ID: <6bc48de7-6744-4689-91a2-0b97b9d1b6ec@Spark>
In-Reply-To: <BN6PR05MB3377C8E2BDA2136C616C2600C72F0@BN6PR05MB3377.namprd05.prod.outlook.com>
References: <E7F41401-6B79-4CCD-B625-DBBB5D068416@nokia.com> <0FAD08FA-53EB-4C80-89BD-AE5CF6219330@gmail.com> <BN6PR05MB3377C8E2BDA2136C616C2600C72F0@BN6PR05MB3377.namprd05.prod.outlook.com>
X-Readdle-Message-ID: 6bc48de7-6744-4689-91a2-0b97b9d1b6ec@Spark
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="5f4fe403_140e0f76_14be6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/stT1LpI4zOfuzkGh-Mb58kvfL4g>
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: Wed, 02 Sep 2020 18:27:20 -0000

John,

I’m not implying anything, just stating the facts.
As for the WG adoption - every member of the wg is entailed to their position.

Cheers,
Jeff
On Sep 2, 2020, 5:29 AM -0700, John E Drake <jdrake@juniper.net>et>, wrote:
> Hi,
>
> Jeff’s note, below, seems to imply that the members of the design team implicitly support adoption of this draft.  This is not the case - I don’t support its adoption.
>
> Yours Irrespectively,
>
> John
>
>
> Juniper Business Use Only
> From: Teas <teas-bounces@ietf.org> On Behalf Of Jeff Tantsura
> Sent: Wednesday, September 2, 2020 2:14 AM
> To: Rokui, Reza (Nokia - CA/Ottawa) <reza.rokui@nokia.com>
> Cc: Kiran Makhijani <kiranm@futurewei.com>om>; TEAS WG <teas@ietf.org>rg>; BRUNGARD, DEBORAH A <db3546@att.com>
> Subject: Re: [Teas] Network Slicing design team definitions- transport slice
>
> [External Email. Be cautious of content]
>
> +1
>
> To add to Reza’ points - the term has been thoroughly  discussed and agreed upon by the design team.
> Regards,
> Jeff
>
> > On Sep 1, 2020, at 10:57, Rokui, Reza (Nokia - CA/Ottawa) <reza.rokui@nokia.com> wrote:
> > All,
> >
> > Thanks Kiran. As the co-author of the draft, I agree with Kiran’s response.
> >
> > In summary, the main reason was to differentiate between “Network Slice” and its components which depends on the use case might be “RAN Slice”, “Core Slice” or “Transport Slice”.
> > As pointed out in email below, we on purpose removed “Network” from the name to make sure “Network Slice” and “Transport Slice” are clearly differentiated.
> >
> > Please note that the 5G is one example of  network slicing. So, in the context of “ 5G Network Slice” we will have all of the three (i.e RAN, Core and Transport Slices).
> > If for example the use case is DCI, there is no RAN and Core slices and the “DCI Network Slice” will contain only “Transport  slices”.
> >
> > Since the concept of “Transport slice” discuss at IETF is general and not just for 5G, the authors of the draft tried to generalize the idea and as a result the name “Transport Slice” was used.
> >
> > Cheers,
> >
> > Reza
> >
> > From: Teas <teas-bounces@ietf.org> on behalf of Kiran Makhijani <kiranm@futurewei.com>
> > Date: Tuesday, September 1, 2020 at 11:35 AM
> > To: "BRUNGARD, DEBORAH A" <db3546@att.com>om>, TEAS WG <teas@ietf.org>
> > Subject: Re: [Teas] Network Slicing design team definitions- transport slice
> >
> > Hi Deborah,
> > It was a deliberate effort to avoid using term network slice – which is a broader concept of “End-to-end network slice” and everything is not IETF specific. By use of term transport, we are able to  (quite precisely) scope our work in the context of IP/MPLS technologies – things IETF concern with. Another advantage is clarity from the network slice concept in 3GPP which has already been defined and described in a particular way. I will find it confusing if we had to always explain that 3gpp-network slices are different than ietf-network slices. Because they are going to be different in functionality.
> >
> > Transport slices capture only the connectivity specific details for things we refer to as transport networks. So far it has aligned will with ACTN, enhance VPN and other TE related work. We will not know how to specify, mange or onboard a RAN, Wireless or a vertical-centric functionality, so there is no point in making assumptions about them in our design and terminology.
> >
> > -Kiran
> >
> > From: Teas <teas-bounces@ietf.org> On Behalf Of BRUNGARD, DEBORAH A
> > Sent: Tuesday, September 1, 2020 7:31 AM
> > To: TEAS WG <teas@ietf.org>
> > Subject: [Teas] Network Slicing design team definitions- transport slice
> >
> > 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