Re: [Teas] Why term transport slice? WG adoption - draft-nsdt-teas-transport-slice-definition

John E Drake <jdrake@juniper.net> Fri, 04 September 2020 15:15 UTC

Return-Path: <jdrake@juniper.net>
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 F0B473A0D4B; Fri, 4 Sep 2020 08:15:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=XlRiffu1; dkim=pass (1024-bit key) header.d=juniper.net header.b=JrfQ8Y/4
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 kiU3c5ByXhIB; Fri, 4 Sep 2020 08:15:01 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AFF83A0D4E; Fri, 4 Sep 2020 08:14:59 -0700 (PDT)
Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 084F7IMA027503; Fri, 4 Sep 2020 08:14:52 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=K0EvYbb8CCnn0S+5jYifpVwRkzIj15EHJFLmJcgBqgI=; b=XlRiffu1mGoyfpcSPelJUMVzgxO2gRizd0I7X6PdeB1JIzR6liMPPLjgZ+wEcDgDPO8S 2SrneMxGm3H8WgTFxk/wM853xms2RsOfIXQdRRf7nvUsLbva9kWfZZaFZnfiYg+vHQTc 79uICtG8FpMLj+w3XRscU49vLoiisWJmF8UcxiiMWrAwytDDkkJMcH0r2wbizHmFwQdv fkv4yyA1g+/8FB5V/RCWRP3Yks+8X1IG8r1XIld+jFNd8YB9IZjdbsSBoEGFj9cSkvYP d5H2hIrLI0N8vzcchIe4cwgQw+mpXYY51Tv8ANm/o1ENWx0EGJ3T8lKm/RLUsQYgGMPt IQ==
Received: from nam11-dm6-obe.outbound.protection.outlook.com (mail-dm6nam11lp2173.outbound.protection.outlook.com [104.47.57.173]) by mx0b-00273201.pphosted.com with ESMTP id 33bh4wrkg7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 04 Sep 2020 08:14:51 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RwZaQLySxLVIcpqQ0+tPI27BQDcwXTY6SVZJBA31W2AMRb4/OJjAi+CdRqT2mG/+sUYekkIVmTy40ua2Na0dPcrRG/RUsXN8sOA0fVbp8tf7qZgUulKa/dpm019TTt2js8sR+dH94JWkXeVpZj3ym2VvLz/eAuEPX4cuHJo0ZTYARSFfP8fIOMTnekk8snJUqfX5gg4a9rHawvGCaZBVbsl9rd4L5OimYbYTCmjyYJluLXkW48Ny6Bta5RMlZzTIZzPu15XrCUZXHHVmh6E/rYZiPwuy88VKOPvIXW9v656+td+5jg5aAeTWmW/1aLIcUc8hl9e5fjCNWF4uvolwmg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=K0EvYbb8CCnn0S+5jYifpVwRkzIj15EHJFLmJcgBqgI=; b=ijvbIfC/ZwCS/T2mGlBB+VvBZ9PQGNbKeQYG5cJP8IY9DsMvpcv4IKpePw1GsCcG2nj1cuy6/TpIznjgRy7cPi+5JlsjR+hhvAiig5rZ2lVPGtJwgcI3CGanNuhlVMHMoi340jJafxoM2OQhx1XXV9iK7kFXnBBirIPUh3PkGVMJu644kIPICjzNMR9xFgC+vQR+NKP2UbD8dwvzzQdr29wlYZylttRSzzz31mVa21fmKRmMWBrunyBgfbWIudBZaaGsw2p+p8d2Kd0SNcoTAxfg6l6paiY2OfkR4bPiF5MHJd523lhbtgTys6u0fuyF2I/TGKIU1ih66BwGNPRupg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=K0EvYbb8CCnn0S+5jYifpVwRkzIj15EHJFLmJcgBqgI=; b=JrfQ8Y/4i56NKqYwWrWFss4AS/8G4yyGm6LYOQMo/9H+7/1z2/xJkcWYtY1YKh1nu5KGVGMbDPzUWzyuLYvgtjYxyWlZoQr0+NjdhEmPyEkaxwA17z/13bzqdkwkehQ6uDE19Xsb+lPcPJoy0/JBdHAvBQSe2LE6/Ql7ZHYa7D4=
Received: from DM5PR05MB3388.namprd05.prod.outlook.com (2603:10b6:4:40::18) by DS7PR05MB7430.namprd05.prod.outlook.com (2603:10b6:5:2c5::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3370.7; Fri, 4 Sep 2020 15:14:49 +0000
Received: from DM5PR05MB3388.namprd05.prod.outlook.com ([fe80::8592:5354:e6a8:8932]) by DM5PR05MB3388.namprd05.prod.outlook.com ([fe80::8592:5354:e6a8:8932%7]) with mapi id 15.20.3370.009; Fri, 4 Sep 2020 15:14:49 +0000
From: John E Drake <jdrake@juniper.net>
To: "Rokui, Reza (Nokia - CA/Ottawa)" <reza.rokui@nokia.com>, Kiran Makhijani <kiranm@futurewei.com>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, 'Eric Gray' <ewgray2k@gmail.com>, 'Igor Bryskin' <i_bryskin=40yahoo.com@dmarc.ietf.org>, 'TEAS WG Chairs' <teas-chairs@ietf.org>, "EXT-vishnupavan@gmail.com" <vishnupavan@gmail.com>, 'TEAS WG' <teas@ietf.org>, "'BRUNGARD, DEBORAH A'" <db3546@att.com>
Thread-Topic: [Teas] Why term transport slice? WG adoption - draft-nsdt-teas-transport-slice-definition
Thread-Index: AQHWgsX63GErIr9JAECVKqmtq/XJj6lYjNjQ
Date: Fri, 4 Sep 2020 15:14:49 +0000
Message-ID: <DM5PR05MB33881A3CE266B2B38A6D29C0C72D0@DM5PR05MB3388.namprd05.prod.outlook.com>
References: <EBB5115F-1EF4-4F07-88FB-C5598A640D74@nokia.com>
In-Reply-To: <EBB5115F-1EF4-4F07-88FB-C5598A640D74@nokia.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-09-04T15:14:44Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=de38d3ed-84f5-4776-b5bd-8bccdcedef2c; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2
authentication-results: nokia.com; dkim=none (message not signed) header.d=none;nokia.com; dmarc=none action=none header.from=juniper.net;
x-originating-ip: [66.129.241.13]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 0f944196-b01e-4138-b268-08d850e5441c
x-ms-traffictypediagnostic: DS7PR05MB7430:
x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr
x-microsoft-antispam-prvs: <DS7PR05MB74301086648442F28AF9F842C72D0@DS7PR05MB7430.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: +8fxf7F3A1WWhg/mNquL8x+f7oVbAz3rcYwtrTBbymHmlebBF6PBS6m9CBimsfhg2ag97aWQstHQJv74hc5cnrV+rCSQ20xuh5DfKp/86es1J0TXe+ebwdNVwhNu/H3yv7uP0mE+JDhDsil4OXiVNVWgtif0djIKIcXiiVK4fMuo6ntel2ctXL11pMsXjLEKKwCR02kqLNpsQNdgWIEYnJeaKrdzHygYIwqu8BplHBbpuFMQ1++xyh0ZkETgMD2BgQt1PKCRzeNa+HwcIyT66BG8HQaainlZnoSaq4SRzMHsxM3eWISTWcYF4SIpNwwOT3LHZYZYis9gveUbLkVo10iHYFZFJ+z875vvI7J9o/rX7kX7RaTwShLCV6Spl+RYKFc1tfl0FA3kiFYtiM5mdjVgX3xtA5zJyoDriSx9x1CeQLFn3UZV3tkA4/bVwswYnHzY8E206gkOHSGDqNQYkw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR05MB3388.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(136003)(366004)(376002)(346002)(39860400002)(26005)(55016002)(296002)(186003)(7696005)(316002)(53546011)(9326002)(71200400001)(6506007)(99936003)(966005)(166002)(66476007)(86362001)(52536014)(5660300002)(66946007)(66446008)(478600001)(2906002)(33656002)(8936002)(64756008)(66556008)(83380400001)(8676002)(9686003)(76116006)(66576008)(110136005)(921003)(491001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: XQx/8zG4be7ryakiH+cj+8Y2jGKIzCe/ygSC5t40td/SNaMQsOnm1wQ0hF8vwztccSsiIDffQlbgeuhAgV+5P563yKt/mkR0TGuNQgILkbGA7P41738hwEeM3tef/uHTVw0gTUzPYfw44LwtrH/OzZUkR33vcIQdZhKR/9QyXuMv++KvNdCGjKH23OhC1fPWtMtyT9W7mKXL7wWWV/OIZkGeW+jkSN3f+Uln14gj2GYIPTg2czm9gBO20OtvQhveiAauF4mjjwpQpnfIQiO3nPVbHYDZcA2lYVj8L5Cf3iilzon3/i5DyF6PaggEE9aMvkz47TaDwJy2+EWyFLL0Bq6s8bkmw+KqyohxGN1cC00L/nO7pJU3wqmHSQcwp3FBEg3G7NOtzgbPQiKPTRVEL0K7CQVee6vusQZ5Jz6BuRpxRcDFcRqscgRTg9WMEoOo3i+hr1843yzgSY4IVB091U86tTucFBrzNs6NkMJDpGSnLw8JRt/9gfXSozTk6a9T+K+F7LPZ3Bi4kQ/5eG9fBxgcf6pXddXV8DZ2dC+EtBpqil7fs8AAp3L5r1/S+2J/tX7pIwGOSOxaHVYVZ6Cg2U72VyD3uv3nof3UYKSstbWVv9DkNhESBX6BCjM9qs1E7GQzzxVlKY1jGvxTIDDzsw==
x-ms-exchange-transport-forked: True
Content-Type: multipart/related; boundary="_005_DM5PR05MB33881A3CE266B2B38A6D29C0C72D0DM5PR05MB3388namp_"; type="multipart/alternative"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM5PR05MB3388.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0f944196-b01e-4138-b268-08d850e5441c
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Sep 2020 15:14:49.2130 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: d8fP2Pnc3T38f03jX+RfqWHfXkvmH+x0G0vr3E8LvgaZZImQFnGOHhQ4YFM9bQRgVLTogNqlDPczkozurEwzcQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR05MB7430
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-09-04_08:2020-09-04, 2020-09-04 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 mlxlogscore=999 impostorscore=0 bulkscore=0 spamscore=0 lowpriorityscore=0 malwarescore=0 adultscore=0 priorityscore=1501 mlxscore=0 phishscore=0 suspectscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2009040133
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/vliXNjN4OeP5DN7NWjdUreT4omc>
Subject: Re: [Teas] Why term transport slice? WG adoption - draft-nsdt-teas-transport-slice-definition
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: Fri, 04 Sep 2020 15:15:04 -0000

Hi,

'Network slice'.  As Adrian points out, this is the term that has been used in the IETF for quite some;  it is used in RFCs 8453, 8568, and 8578, as well as the preponderance of I-Ds on this topic.  Even if another term was correct, and I don't think that, trying to use a term other than 'network slice' will continue to cause tremendous confusion.  I.e., changing terms is akin to closing the barn door after the horse has bolted.

As I noted yesterday, and throughout the *Network Slicing* design team meetings, I think it is up to an application that uses IETF network slices as components to indicate where in its design these IETF network slices fit.  I.e., IETF network slices are being designed for use by a multiplicity of applications and trying to make our terminology congruent with this one application is problematic.

Yours Irrespectively,

John



Juniper Business Use Only
From: Teas <teas-bounces@ietf.org> On Behalf Of Rokui, Reza (Nokia - CA/Ottawa)
Sent: Friday, September 4, 2020 10:16 AM
To: Kiran Makhijani <kiranm@futurewei.com>om>; adrian@olddog.co.uk; 'Eric Gray' <ewgray2k@gmail.com>om>; 'Igor Bryskin' <i_bryskin=40yahoo.com@dmarc.ietf.org>rg>; 'TEAS WG Chairs' <teas-chairs@ietf.org>rg>; EXT-vishnupavan@gmail.com <vishnupavan@gmail.com>om>; 'TEAS WG' <teas@ietf.org>rg>; 'BRUNGARD, DEBORAH A' <db3546@att.com>
Cc: Rokui, Reza (Nokia - CA/Ottawa) <reza.rokui@nokia.com>
Subject: [Teas] Why term transport slice? WG adoption - draft-nsdt-teas-transport-slice-definition

[External Email. Be cautious of content]

All,

Thanks for all feedbacks.

Let's step back and address these questions: How and why the authors' of the draft chose the term "Transport Slice"?

Before formation of the TEAS WG NSDT, there were lots of discussions and drafts to address the role of IETF for network slicing. Those discussion and drafts tried to address the network slicing  from different perspectives but in most cases they had one thing in common, they started by discussion the network slicing but at the end they really meant the Transports portion of the network slice. In other words, although the name of the draft and discussion was network slicing, but they just talked about Transport portion.  In other hand, the term network slice and Transport portion of a network slice were used interchangeably.

After creation of the NSDT, we collectively thoughts that the first order of business is to clarify this. So, the "draft definition" started. The following are the reasons:

Reason 1)
The first reason for this draft is to make very clear distinction between a network slice (defined for example by 3GPP) and transport portion of a network slice.
In our opinion it is essential to make a clear distinction between network slice and transport portion of a network slice. They are NOT the same since a network slice contain the transport portion.
The picture below was outcome of that discussion. In summary, a network slice is an end-to-end context and depends on the used case (i.e 5G, DCI, etc), it might contain a few other components (i.e. RAN, Transport, Core etc.)

[cid:image001.png@01D682AC.977C9B80]

Reason 2)
We just established the fact that an end-to-end network slice is different from transport portion of the network slice. The next question is that what the definition of the Transport portion of a network slice is.
This is fully discussed in draft but in summary the transport portion of a network slice describes the CONNECTIVITY between various endpoints. Our definition is aligned with MEF and 3GPP.

  *   MEF uses the same definition for Transport portion of the network slice". See Section 5.3 of following white paper

     *   https://wiki.mef.net/display/CESG/Slicing+for+Shared+5G+Fronthaul+and+Backhaul+-+White+Paper<https://urldefense.com/v3/__https:/wiki.mef.net/display/CESG/Slicing*for*Shared*5G*Fronthaul*and*Backhaul*-*White*Paper__;KysrKysrKysr!!NEt6yMaO-gk!RwBHv_fQ5XdrftEX2118w7OUiQg2mu-eHcRobC4KGZ-EPaqW2EcKPWfQ_6Dp7hs$>



  *   This is aligned with 3GPP. See Figure 4.9.3.1 of TR 28.801 and  http://www.3gpp.org/NEWS-EVENTS/3GPP-NEWS/1951-SA5_5G<https://urldefense.com/v3/__http:/www.3gpp.org/NEWS-EVENTS/3GPP-NEWS/1951-SA5_5G__;!!NEt6yMaO-gk!RwBHv_fQ5XdrftEX2118w7OUiQg2mu-eHcRobC4KGZ-EPaqW2EcKPWfQECxLoTI$>

According to the picture below,  the reference of transport portion of a network slice  is referred by "Transport network supporting connectivity'

[cidimage001.png@01D6806A.8E70BC90]




Reason 3)
The next question is that which term shall be used for 'Transport portion of an end-to-end network slice"?


  *   MEF uses the term "Transport Slice". See Figure 17 of following white paper

     *   https://wiki.mef.net/display/CESG/Slicing+for+Shared+5G+Fronthaul+and+Backhaul+-+White+Paper<https://urldefense.com/v3/__https:/wiki.mef.net/display/CESG/Slicing*for*Shared*5G*Fronthaul*and*Backhaul*-*White*Paper__;KysrKysrKysr!!NEt6yMaO-gk!RwBHv_fQ5XdrftEX2118w7OUiQg2mu-eHcRobC4KGZ-EPaqW2EcKPWfQ_6Dp7hs$>



  *   3GPP: See Figure 4.9.3.1 of TR 28.801 and  http://www.3gpp.org/NEWS-EVENTS/3GPP-NEWS/1951-SA5_5G<https://urldefense.com/v3/__http:/www.3gpp.org/NEWS-EVENTS/3GPP-NEWS/1951-SA5_5G__;!!NEt6yMaO-gk!RwBHv_fQ5XdrftEX2118w7OUiQg2mu-eHcRobC4KGZ-EPaqW2EcKPWfQECxLoTI$>

They do not directly address the transport portion of a network slice. They do not have a term for this. They mainly address the 5G RAN and 5G Core. As shown in the picture above, the reference of transport is phrase "Transport network supporting connectivity".



  *   From IETF point of view, these are potential choices for Transport portion of a network slice:

  *   Network slice: This for sure is NO. Reason 1) clearly shows that we shall not use term "Network slice" for transport portion. This is not correct.
  *   Use 3GPP phrase: "Transport network supporting connectivity"
  *   Use the phrase "Transport portion of the Network Slice"
  *   Use term "Transport Network Slice"
  *   Use term "Transport Slice"
  *   Adrian, Igor, Deborah and others, is there any other suggestion? If so, please add

>From the above choices, the draft authors uses the term "Transport Slice" but not the "Transport Network Slice" to make sure we implicitly stating that Network Slice and Transport part are different.
Having said that, authors are open to suggestion. Please suggest your term.


Reza