[Teas] FW: The word "transport"

"Rokui, Reza (Nokia - CA/Ottawa)" <reza.rokui@nokia.com> Thu, 30 April 2020 15:24 UTC

Return-Path: <reza.rokui@nokia.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 163E83A0CDF; Thu, 30 Apr 2020 08:24:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.72
X-Spam-Level:
X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.82, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 HuT02hAngvgD; Thu, 30 Apr 2020 08:24:31 -0700 (PDT)
Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2104.outbound.protection.outlook.com [40.107.243.104]) (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 CF17D3A0ED3; Thu, 30 Apr 2020 08:23:17 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WqZ0SQjvgb5w1CK8tPhQQqHyT5/vOwjedjf7lPU50eBiCxkYwcqe9Mhripqkxdo5fBTs2KV4lk5IYI0SrLkLBvkuXmWUgdKbpHf7Hm4QVoBYfeDMstiB7EROZQweqD/pHuCieoV5uoyDdhUqW0+jNtlA09s12DpfLKJXhWlpRvFvgy1opmH4lB9qxGJUEJkGT1pdWyjM57etW9bYmwmeHA6QLodJAI36vnJg3h84mzkjBVvk4qitRlUz9/GXVbKHFjl7XgAGPfhEZ894SgH0G6/JtPveFxcsE7X2kF7JNVuM0s+10tZ/qGC+XZVSODuSCrl3A/XGLjob8KSnkH/Dqg==
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=+lHXsgfS6X/d/kZxUh9ZwuOtPM/V4meTmQ3sQsSB/IY=; b=H0PHcBt2IqWpteVWD4zRFx3nssgsMPGX6CLfCcUXjUueuoFAMOkyKjyxujiJ4PBkwgiYs7TtBQ/5BHe2ZFKGYeEU3IiQB4itx7q304f00cywUn0UU3OKuxi6fgZnOCcShXo2uc1nkUEvzw+uFBEH2wZeWBFBhqhMjRzEfQslg7WkSU+6GwirYGMovvwpQsR4Wkn9tHs4w6b1n5OEb0F1BNNNHURfozyMBJ3/YqXBpxoY9VR+rdNuYz/PfiNbDki0cwSjx54jTPyDaq+/Kyv/UikxC9AHit6v1Jo/CqiXGwTl6psV1nq9HcS8xbpqgkLkEtokz+gqBjreZoqEOWL5xA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+lHXsgfS6X/d/kZxUh9ZwuOtPM/V4meTmQ3sQsSB/IY=; b=skAz5ghiyAdgpYBwK6ZKii9FvpoBJYNuUqi9SX2osYIqfC4zj5KcVgEAZEgvy2KITzk9tIEz5RsH+i3AJa6On0AQNDhaF89wvLk2YDNhA29hxp8ipLTUrX6w6l/u+tPKjdvNg59jGVr/J9klgn5O6OmOf83kFEqtXVNgyd3SWLE=
Received: from DM6PR08MB6331.namprd08.prod.outlook.com (2603:10b6:5:1ee::8) by DM6PR08MB4476.namprd08.prod.outlook.com (2603:10b6:5:a6::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.20; Thu, 30 Apr 2020 15:23:15 +0000
Received: from DM6PR08MB6331.namprd08.prod.outlook.com ([fe80::a08d:e849:dfe7:41b2]) by DM6PR08MB6331.namprd08.prod.outlook.com ([fe80::a08d:e849:dfe7:41b2%3]) with mapi id 15.20.2958.020; Thu, 30 Apr 2020 15:23:15 +0000
From: "Rokui, Reza (Nokia - CA/Ottawa)" <reza.rokui@nokia.com>
To: "teas@ietf.org" <teas@ietf.org>, "teas-ns-dt@ietf.org" <teas-ns-dt@ietf.org>
CC: "Rokui, Reza (Nokia - CA/Ottawa)" <reza.rokui@nokia.com>
Thread-Topic: The word "transport"
Thread-Index: AQHWHwNETixY1e0ugU6p9BukKymSiw==
Date: Thu, 30 Apr 2020 15:23:15 +0000
Message-ID: <A976D672-FD4D-4BCA-8C0F-A9DBE15521E4@nokia.com>
References: <CAB75xn60ft6-Xqy_+zwAj0Gc9EE3j6qJ+nu=-S1MazPTJwz9Xw@mail.gmail.com> <A2FF9B40-4177-46F4-8EC6-590235C26281@nokia.com> <CAB75xn64ve_HoMkjbkADBsexsuUeVnrB_fga-2baq-QOMHTHoA@mail.gmail.com> <485BE8C7-3323-424C-9667-C68B50C21AAA@nokia.com>
In-Reply-To: <485BE8C7-3323-424C-9667-C68B50C21AAA@nokia.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.36.20041300
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com;
x-originating-ip: [24.246.4.36]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 168129a9-0f01-4c99-5e6d-08d7ed1a675d
x-ms-traffictypediagnostic: DM6PR08MB4476:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <DM6PR08MB44763046C8F9A454CB745BFD9FAA0@DM6PR08MB4476.namprd08.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0389EDA07F
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: TIyFJ0zHVELy5pETeNjnvPlu7MVXBO+aQaitQMWM2aoubw2s9ipI7Pyx9oggfGHs0NtmmdZzwBpxP8LWDUuAhPtfkflMq8UPvwxo+ifZNAQtYpMSrCoGHfiTiJBJl9VcRLPrkKWspSHq4lYCbItoq7BQVGpIv5eP2sGhDUoQg2ukJOUehC5Lr1ywC02FBHBy/CKHFs6gVFiBDdQqa6IFrkm41PYEISLGp5N97VX4V+ZGleELsUHEscptehMMK5Iwnv5r7QeZfhMBb8HRTRK5aGUcibVkIFOVlJfVFSVowYfyY1YjsHbhQWFrfemJd5QUZV0ozQhzwymhTsPlhDQfCuPONo7QVeivoSHQPWqd0VgTD8jLk5HCcGk46GqqUH4Wbgy0tzur829+lDGBWQiIyb9sENyaX0TdjJB0Tz/v5tsTGp/7yAIRKx3M9PMGBpCZNZ328m0ykuc3+IY7yKg6hilXW/5174q0s/4bJqgu+KWWRZPWePg35W0hi60CXYXlJaAklz06xMlNH/yrUwVmqw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR08MB6331.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(376002)(366004)(396003)(346002)(136003)(36756003)(316002)(478600001)(66446008)(86362001)(91956017)(2906002)(6506007)(110136005)(53546011)(76116006)(71200400001)(66556008)(966005)(64756008)(4326008)(33656002)(450100002)(66576008)(66946007)(66476007)(2616005)(66574012)(99936003)(8676002)(8936002)(186003)(5660300002)(26005)(107886003)(6512007)(6486002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: xZBU7LhxztSl8kWirR4jbIdivyWqcODbvCrtVDZxQoQlRWbzM9siVQpk4o6ioUyB20aN27pksPWpHcMTWziZcoTF33Y8wwrhEzKY91eg3cBtUXHfSCetzWtJ9R/bCDXyPyE5DhZPBQPZQNiOZIeHKBXl3/q3ELB+xTdVp2uRr1fULX1guj0TqFW+CwvoGTT7ch+Bq2Z847hg4l63ln8LLCLr2m3yJ0SEpTCOsJXzYYIkNcDPDOREKNzXeONaAjrqd3AUJjI9+oBYTiyZyj8AsGsVBkHLunpoHsHTGFcHFjrtgE22dv7doQ3GREmBA44ARDbJZho/Ajw4gSUHrM8Uvj+bTVMAOsiMXMlaWzCCjYGvTcZS1saXMWgKoAYXszBOf0rKg+3ZuyMhGkiwmxg6KHpko7F1Yg19VrOzIzoT5VFmyX8PGepDemiO2fdB2Sf8xGHexkvMpjJCGcrD4jNy6qy6wVvbyyRbJt/ymVFY/b0mhDBgncuX8wUcMpzTcGj+x5Plap6DhMRHP9dIv2j/8beX/4JgiN5hjRHR2SaDI0svkP/ckEyf6hlbDj/zHgyk1WbNdb1hHYsQ1Z5NYgD0PxqZCpCqn5+hioeG4uHgPXFEYg/vN44tgjEIxQvph3px1MxxIyP4B20Yk62ZMsgdwNrz3GhyNz3o+kp/U178tVCZGArLg/VVdfWKAMbQSQKlDBq+/8rUlMcmPfBg2WQ4563SUc05z4yL/5egMTA2/noQPp9hDr5EP9mVIJ19mTWARaJzWmYmeTCn+lNtkOyeBA/xSHuWUbodjsJz+qYWA7Y=
Content-Type: multipart/related; boundary="_005_A976D672FD4D4BCA8C0FA9DBE15521E4nokiacom_"; type="multipart/alternative"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 168129a9-0f01-4c99-5e6d-08d7ed1a675d
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Apr 2020 15:23:15.3945 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: YiOdfe5/mvjjWZHN/z0WQt8ShZ3+dnBHPgaWH3CFbfl+VdF7Jeg8bIQHe6cSr3kvJrV7DpJlf32cOkhc022cuA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR08MB4476
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/HgZOU69VWXK40ap1XilPlV6o7Cw>
Subject: [Teas] FW: The word "transport"
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: Thu, 30 Apr 2020 15:24:39 -0000

All,

I thought I sent this to TEAS and TEAS-NS-DT team before. Forwarding the response to everyone.

Cheers,
Reza



From: Reza Rokui <reza.rokui@nokia.com>
Date: Saturday, April 25, 2020 at 11:37 PM
To: Dhruv Dhody <dhruv.ietf@gmail.com>om>, Jari Arkko <jari.arkko@piuha.net>et>, "draft-nsdt-teas-transport-slice-definition@ietf.org" <draft-nsdt-teas-transport-slice-definition@ietf.org>
Cc: Reza Rokui <reza.rokui@nokia.com>
Subject: Re: The word "transport"


Hi all,



Please see inline for some clarifications.



Reza





On 2020-04-24, 1:31 AM, "Dhruv Dhody" <dhruv.ietf@gmail.com> wrote:



    Hi Reza,



    I am putting the relevant text here -



    ==



    [14:28:42] <adrianfarrel> I'm getting very confused by everyone

    talking about "transport networks" and "transport slices". Is this

    something coming out of 3GPP?



[Reza] Please note that the “Transport Slice” from IETF point of view is not only limited to 5G network slicing.

5G network slicing is just one use-case of transport slicing as described in Transport Slice definition draft.



Regarding 5G use-case, the following figure is taken from 3GPP TS 28.530 where the “Transport slice” is described as “Connectivity” across transport network.

This is the reason that what has been described in our draft for “Transport Slices” is a set of Connections between various endpoints with certain SLOs.

Note that 3GPP did not define the Transport slice explicitly.



[cid:image001.png@01D61EE1.BAB53140]







    [14:29:06] <adrianfarrel> Seems to me that we (for example, ACTN) went

    through a lot to clarify that "transport network" was sub-IP

    [14:29:17] <adrianfarrel> ...maybe even sub-MPLS

[Reza] Transport networks (which are technology specific) are used to realized “Transport Slices”. Please see draft for more info.



    [14:31:39] <Joel Halpern> "Transport Network" is the industry

    terminology for the network that connects the radio (and related gear)

    to the packet core (and related gear).

    [14:32:03] <Joel Halpern> It is indeed a different usage.  I wish it

    were not overloading.  But they didn't ask me.

    [14:32:47] <Joel Halpern> Which part it refers to in a fixed access

    network is even less clear.



[Reza] The following figure is taken from 3GPP TS 28.530 where it shows various “Transport slices”.

Note that the “Transport Slices” are not only used for RAN to Core. Depends on the deployment, we can have

Transport slices in RAN for midhaul and fronthaul, in 5G Core or for application. All these transport slices are shown below.



] [cid:image002.png@01D61EE1.BAB53140]



    [14:39:54] <adrianfarrel> I understand why 3GPP uses the term. I don't

    understand why we use the term. We could talk about 'Foobar slices'

    and add one line that says "In the 3GPP, the term 'Transport Slice' is

    used for what we call a 'Foobar Slice'."

[Reza]  Note that 3GPP used the term “slice subnet” when describing it in context of 5G Core and RAN (i.e Core Slice Subnet and RAN Slice Subnet).

They did not define anything related to Transport. As indicated above, 3GPP refer it to “Connectivity”.

We did not want to use Subnet because in IP,  subnet has a very clear definition and using term “Transport Subnet” is completely misleading. So, we chose Transport Slice.

Also since the connectivity between various endpoints are across transport network (i.e. IP, Optics, PON, Microware etc.), it is logical to assume the Connections are called Transport Slice.





    [14:40:18] <adrianfarrel> We *already* have two definitions of

    "transport" in the IETF. We really don't need three

[Reza] Please provide links to these two definition.



    [14:59:00] <adrianfarrel> Well, I picked "foobar' in order to not jump

    immediately to a strawman solution. I think we are talking about

    providing slices as a service across the Internet. Same level of entry

    as a VPN: that is, the consumer provides a packet stream to the

    service entry point, and expects the packets to be delivered to the

    service exit point. Obviously, the consumer of the service may see the

    service as a transport (cf. pseudowires), but we would be 'alarmed' to

    hear a L3VPN described as a 'transport VPN.'

[Reza] VPN is one of the  solutions to realize the transport slices in IP networks.

However, The idea of Transport Slice is to allow a high-level system (or consumer or an Orchestrator) to ask for a various connections (i.e. Transport slices) across  IP, Optics, PON, Microwave or any combination of these networks. We shall not limit ourselves to IP VPN.

Note that the definition of the Transport slice is technology agnostic. For example in 5G you can realize a transpot slice in midhaul (please refer to picture above) which is a set of connections between 5G RAN nodes using PON or Optical connection. In this case there is no IP VPN.

In summary, since the connectivity between various endpoints are across transport network (i.e. IP, Optics, PON, Microware etc.), it is logical to assume the Connections are called Transport Slice.



    Full logs - https://www.ietf.org/jabber/logs/teas/2020-04-23.html



    ==



    More inline..



    On Thu, Apr 23, 2020 at 10:27 PM Rokui, Reza (Nokia - CA/Ottawa)

    <reza.rokui@nokia.com> wrote:

    >

    > Hi Dhruv,

    >

    > As far as I remember, we did not have any argument about term "transport". It was agreed that the term "Transport" is suited in context of network slicing.

    > The initial discussion was "Transport network slicing" which later we agreed to remove "network" since it causes confusion since IETF do not cover the e2e network slicing but rather the transport part.

    >

    > I was not clear about Adrian's comment regarding term "transport". IMHO, this term is well suited since it convers any underlying technology for L0 to L3.

    >



    In CCAMP/TEAS circles, the transport network term might not be used

    for L3 (and thus the confusion). And then there are the Transport

    Protocols! Definition draft should include some clarity on what do we

    mean when we say transport network at the least!



    It would be good to get this resolved sooner as we develop multiple

    documents that uses the same terminology!



    Thanks!

    Dhruv



    > Reza

    >

    >

    > On 2020-04-23, 12:35 PM, "Dhruv Dhody" <dhruv.ietf@gmail.com> wrote:

    >

    >     Hi,

    >

    >     Adrian gave some comments on jabber about using the word "transport".

    >

    >     During RFC8453 devolpment, this came up where TN in ACTN was transport

    >     networks and it was changed to TE networks to avoid using the

    >     overloaded term "transport".

    >

    >     We need to find a way to justify using this term and maybe describe

    >     this more in the definition draft - and just saying that 3GPP uses

    >     that term may not work I guess!

    >

    >     Was this discussed in the design team earlier, i joined the effort

    >     much later.

    >

    >     Thanks!

    >     Dhruv

    >