Re: [Teas] FW: The word "transport"

Adrian Farrel <adrian@olddog.co.uk> Fri, 01 May 2020 16:34 UTC

Return-Path: <adrian@olddog.co.uk>
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 93F323A1732 for <teas@ietfa.amsl.com>; Fri, 1 May 2020 09:34:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.793
X-Spam-Level:
X-Spam-Status: No, score=-1.793 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, MAY_BE_FORGED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 OkNyweudedco for <teas@ietfa.amsl.com>; Fri, 1 May 2020 09:34:14 -0700 (PDT)
Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (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 36DF23A1723 for <teas@ietf.org>; Fri, 1 May 2020 09:34:11 -0700 (PDT)
Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta6.iomartmail.com (8.14.4/8.14.4) with ESMTP id 041GY985007618 for <teas@ietf.org>; Fri, 1 May 2020 17:34:09 +0100
Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6E9B22203B for <teas@ietf.org>; Fri, 1 May 2020 17:34:09 +0100 (BST)
Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs1.iomartmail.com (Postfix) with ESMTPS id 59A682203A for <teas@ietf.org>; Fri, 1 May 2020 17:34:09 +0100 (BST)
Received: from LAPTOPK7AS653V (81-174-202-163.bbplus.pte-ag2.dyn.plus.net [81.174.202.163] (may be forged)) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id 041GXri5029506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for <teas@ietf.org>; Fri, 1 May 2020 17:33:54 +0100
Reply-To: <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <teas@ietf.org>
References: <036501d61f26$01756f20$04604d60$@olddog.co.uk> <DM5PR05MB33881A76688021C9B05EA556C7AA0@DM5PR05MB3388.namprd05.prod.outlook.com> <03ef01d61f9a$2f5850f0$8e08f2d0$@olddog.co.uk> <A02167A2-4AA6-4522-A6E8-8D9157BEB3F4@nokia.com> <044101d61fc5$1656bd50$430437f0$@olddog.co.uk> <C974BCBC-BDD7-4A01-AED7-30926BC72987@nokia.com> <MN2PR15MB3103FCC7BCA3C126C1F11C8797AB0@MN2PR15MB3103.namprd15.prod.outlook.com> <0A0B7870-40F7-43B2-964B-E0A408D0B844@nokia.com> <DM5PR05MB33883A5B6547F2297BDF6EFDC7AB0@DM5PR05MB3388.namprd05.prod.outlook.com> <MN2PR15MB31037067B573704B56B2159D97AB0@MN2PR15MB3103.namprd15.prod.outlook.com>
In-Reply-To: <MN2PR15MB31037067B573704B56B2159D97AB0@MN2PR15MB3103.namprd15.prod.outlook.com>
Date: Fri, 1 May 2020 17:33:52 +0100
Organization: Old Dog Consulting
Message-ID: <050301d61fd6$4d446a40$e7cd3ec0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/related; boundary="----=_NextPart_000_0504_01D61FDE.AF0D8D30"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQIMCNRaZu8YlTaDCQfeAjf3ZILbpAFlZRhPAfoMhc0CDDG86QGGDXihAkWx32gBoZaScwIMuVP9Ag7z+e8BiPr366ejrC0g
Content-Language: en-gb
X-Originating-IP: 81.174.202.163
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-25390.001
X-TM-AS-Result: No--16.034-10.0-31-10
X-imss-scan-details: No--16.034-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25390.001
X-TMASE-Result: 10--16.034300-10.000000
X-TMASE-MatchedRID: JQSF04SbSlS+AWaOCXs78kNkUF3WMuv+cU9StUObqO1z2nCg6F9Lz9Bw uupkEag/tzBkuk8VO0DhLF4ZUIRtJgniPOlQLgv5c2R9nMlozoEJRKZB9eITIs1RN4EE8pAqT7z qZowzdpI4vQF6EYVHLamL7N3jEPJbU71X33iML0MViuoeP4Hm0G5o4nRYHGzSGbJMFqqIm9zDOS 0FhcAXSmPrLV4TqYTF6Ia3fTWdkQvNCkjFaQnJzPT6y4pbHfOI4tu9fANDPbmDwntrnEWhGbCI2 s1l37imQbNTsIpfWx0NPKTf7/hn3/UetO2kEh//77DVjCN3x4gsIMJqMNlaneBefETzWLKxnX3b 9D4jFbaLt63p7uWNMMxbTuKp520bARcoY27CKZEr5O/jiCnGGLdHEv7sR/OwQWEGv3gaUmd0+P0 tQGP+S6JLb5wAaQ/MDODZrCVSmo2Dlsl7c5Ms3BCYbXwfekHnox5cBdU3pAfrr41gyMH269ctGl xeXl/o/n7nuxYUlb3CEqUCZFLXWupCUb4J9hmCZw88sE7YDRu8coKUcaOOvTa6AaQm7fhmBthzL 1hCXp4ph6TsDjuCmb5BByRmGoS02OwaJG98IRHalI1BgRCxyRHuQ9dDJbS2TJDl9FKHbrlZxWTX 4+l5ti2xRktmmCFYkOKRdfUdaLPktri/zigrm4ETCzf7bgpWzLo88rvlvYECC8zqHvcG2m82zvs XichaxjfJ+i+nbHScSjxxwLziCZWmfTcTyE/WeASYyytjzKTm/8o/yf2EHIfGLZ++QpQzYZW5+v 55ji/RIpuIE0b9EpZPHsCmNrHmMkBeceJe9CiEaz0c2E6sLjl/1fD/GopdyJ1gFgOMhOlXhqN9H 2OPZ2F5X5yuwTohDBbGvtcMofw3EaROYXLhHEV12sQq30yQhCDicoVqmw6Ku6k9D+0F1D4t2Otn HX5B
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/cMjAwX-rUENSzn_JLTYDCm9H0Qk>
Subject: Re: [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: Fri, 01 May 2020 16:34:19 -0000

That's a very subtle distinction, Eric.

"Transport slice" versus "Transport network slice".

Not sure I spotted that.

 

But we're not getting very far except to establish that the terms are
delicate.

 

And, yes, the solution (I may have said this before) is to clarify the
terminology (not just pick different terms, or defend the terms in use) so
that everyone knows what each term means.

 

Hopefully we can make some progress on that.

 

Best,

Adrian

 

From: Teas <teas-bounces@ietf.org> On Behalf Of Eric Gray
Sent: 01 May 2020 17:24
To: John E Drake <jdrake@juniper.net>et>; Rokui, Reza (Nokia - CA/Ottawa)
<reza.rokui@nokia.com>om>; adrian@olddog.co.uk; 'John E Drake'
<jdrake=40juniper.net@dmarc.ietf.org>rg>; teas@ietf.org; teas-ns-dt@ietf.org
Subject: Re: [Teas] FW: The word "transport"

 

John,

 

              Actually, "Transport Slice" was "coined" by us on the design
team.  I am not sure who actually 1st used this expression, but the design
team agreed to use it in defining terminology to be used in this effort.

 

              The expression used in 5G/3GPP, for instance, is "transport
network slice."  The expression I've seen used in DCN is just "network
slice."

 

              I believe that we coined the expression "transport slice"
explicitly to avoid tying it too closely to either 5G/3GPP (if we used
"transport network slice") or DCN (if we used "network slice").

 

              As a design team, I believe we should have the ability to make
decision like this.  Where we have likely failed is in making the intent and
usage of this expression very clear.

 

--

Eric

 

--

Eric

 

 

From: John E Drake <jdrake@juniper.net <mailto:jdrake@juniper.net> > 
Sent: Friday, May 1, 2020 11:53 AM
To: Rokui, Reza (Nokia - CA/Ottawa) <reza.rokui@nokia.com
<mailto:reza.rokui@nokia.com> >; Eric Gray <eric.gray@ericsson.com
<mailto:eric.gray@ericsson.com> >; adrian@olddog.co.uk
<mailto:adrian@olddog.co.uk> ; 'John E Drake'
<jdrake=40juniper.net@dmarc.ietf.org
<mailto:jdrake=40juniper.net@dmarc.ietf.org> >; teas@ietf.org
<mailto:teas@ietf.org> ; teas-ns-dt@ietf.org <mailto:teas-ns-dt@ietf.org> 
Subject: RE: [Teas] FW: The word "transport"
Importance: High

 

Hi,

 

Comment inline

 

Yours Irrespectively,

 

John

 

 

Juniper Business Use Only

From: Teas-ns-dt <teas-ns-dt-bounces@ietf.org
<mailto:teas-ns-dt-bounces@ietf.org> > On Behalf Of Rokui, Reza (Nokia -
CA/Ottawa)
Sent: Friday, May 1, 2020 11:49 AM
To: Eric Gray <eric.gray@ericsson.com <mailto:eric.gray@ericsson.com> >;
adrian@olddog.co.uk <mailto:adrian@olddog.co.uk> ; 'John E Drake'
<jdrake=40juniper.net@dmarc.ietf.org
<mailto:jdrake=40juniper.net@dmarc.ietf.org> >; teas@ietf.org
<mailto:teas@ietf.org> ; teas-ns-dt@ietf.org <mailto:teas-ns-dt@ietf.org> 
Cc: Rokui, Reza (Nokia - CA/Ottawa) <reza.rokui@nokia.com
<mailto:reza.rokui@nokia.com> >
Subject: Re: [Teas-ns-dt] [Teas] FW: The word "transport"

 

[External Email. Be cautious of content]

 

>>>>>>>> Possibly it would be better to clarify this in terms of what the
IETF does deal with?

 

I meant that IETF does not address the other aspects of an e2e network slice
like RAN and Core slice (aka Other Slices).

A transport slice is just a piece of an e2e network slice. Any reference to
"network slice" is not correct since IETF does not deal with Other Slices.

 

[JD]  This is back to Adrian's original point, viz, 'transport slice' is a
term coined by another standards body.

 

Reza Rokui, Ph.D.

Director, NSP Product Management

Nokia Canada

IP/Optical Network Automation 

T:  +1-613-784-1762

M: +1-613-979-6986

600 March Road, Kanata, Ontario, K2K 2E6

Reza.Rokui@Nokia.com <mailto:Reza.Rokui@Nokia.com> 

 

 

From: Eric Gray <eric.gray@ericsson.com <mailto:eric.gray@ericsson.com> >
Date: Friday, May 1, 2020 at 11:45 AM
To: Reza Rokui <reza.rokui@nokia.com <mailto:reza.rokui@nokia.com> >,
"adrian@olddog.co.uk <mailto:adrian@olddog.co.uk> " <adrian@olddog.co.uk
<mailto:adrian@olddog.co.uk> >, 'John E Drake'
<jdrake=40juniper.net@dmarc.ietf.org
<mailto:jdrake=40juniper.net@dmarc.ietf.org> >, "teas@ietf.org
<mailto:teas@ietf.org> " <teas@ietf.org <mailto:teas@ietf.org> >,
"teas-ns-dt@ietf.org <mailto:teas-ns-dt@ietf.org> " <teas-ns-dt@ietf.org
<mailto:teas-ns-dt@ietf.org> >
Subject: RE: [Teas] FW: The word "transport"

 

Possibly it would be better to clarify this in terms of what the IETF does
deal with?

 

The IETF deals with "packetized" (more specifically, where packetization
uses IETF defined packet formats) transport of otherwise arbitrary data.

 

Here you can replace transport with "carrying" - but this is essentially the
standard English meaning of transport.

 

From: Teas-ns-dt <teas-ns-dt-bounces@ietf.org
<mailto:teas-ns-dt-bounces@ietf.org> > On Behalf Of Rokui, Reza (Nokia -
CA/Ottawa)
Sent: Friday, May 1, 2020 11:38 AM
To: adrian@olddog.co.uk <mailto:adrian@olddog.co.uk> ; 'John E Drake'
<jdrake=40juniper.net@dmarc.ietf.org
<mailto:jdrake=40juniper.net@dmarc.ietf.org> >; teas@ietf.org
<mailto:teas@ietf.org> ; teas-ns-dt@ietf.org
Cc: Rokui, Reza (Nokia - CA/Ottawa) <reza.rokui@nokia.com
<mailto:reza.rokui@nokia.com> >
Subject: Re: [Teas-ns-dt] [Teas] FW: The word "transport"

 

Adrian,

 

>>>>>> I don't understand "we (IETF) do not deal with network slice".

 

Please refer to Figure 4 of the draft.

In summary, an E2E network slice is the logical network from End user X to
End use Y and comprises of:

*	One or more Transport slices (TS)
*	One or more Other Slices (OS)

 

Just as an example for "Other Slices", in 5G these slices are RAN slices and
5G Core Slices.

Referring  this Figure, it is clear that IETF deals with Transport slice
which is part of an E2E network slice and "Other slices" are outside scope
of IETF.

Please make a clear distinction between Transport Slices and e2e network
slices. They are different.

IMHO, any reference to "Network Slice" in IETF drafts means "Transport
slice" . 

 

>>>>>>.  Why do we have a "TEAS Network Slicing Design Team"?

Good question. The correct name can be "TEAS Transport Slicing Design Team"

 



 

Reza 

 

 

From: Adrian Farrel <adrian@olddog.co.uk <mailto:adrian@olddog.co.uk> >
Organization: Old Dog Consulting
Reply-To: "adrian@olddog..co.uk <mailto:adrian@olddog.co.uk> "
<adrian@olddog.co.uk <mailto:adrian@olddog.co.uk> >
Date: Friday, May 1, 2020 at 10:30 AM
To: Reza Rokui <reza.rokui@nokia.com <mailto:reza.rokui@nokia.com> >, 'John
E Drake' <jdrake=40juniper.net@dmarc.ietf.org
<mailto:jdrake=40juniper.net@dmarc.ietf.org> >, "teas@ietf.org
<mailto:teas@ietf.org> " <teas@ietf.org <mailto:teas@ietf.org> >,
"teas-ns-dt@ietf.org <mailto:teas-ns-dt@ietf.org> " <teas-ns-dt@ietf.org
<mailto:teas-ns-dt@ietf.org> >
Subject: RE: [Teas] FW: The word "transport"

 

Hi Reza,

 

I don't understand "we (IETF) do not deal with network slice".

Why do we have a "TEAS Network Slicing Design Team"?

 

Cheers,

Adrian

 

From: Rokui, Reza (Nokia - CA/Ottawa) <reza.rokui@nokia.com
<mailto:reza.rokui@nokia.com> > 
Sent: 01 May 2020 15:13
To: adrian@olddog.co.uk <mailto:adrian@olddog.co.uk> ; 'John E Drake'
<jdrake=40juniper.net@dmarc.ietf.org
<mailto:jdrake=40juniper.net@dmarc.ietf.org> >; teas@ietf.org
<mailto:teas@ietf.org> ; teas-ns-dt@ietf.org <mailto:teas-ns-dt@ietf.org> 
Cc: Rokui, Reza (Nokia - CA/Ottawa) <reza.rokui@nokia.com
<mailto:reza.rokui@nokia.com> >
Subject: Re: [Teas] FW: The word "transport"

 

John and all,

 

This is where I disagree with term "Underlay Network Slice". It brings lots
of other questions since we (IETF) do not deal with network slice as clearly
described in our draft.

 

As I send in another email thread, as per Adrian's suggestion, we define the
term "Transport" as follows and would like to keep the term "Transport
Slice"

 

*	Definition of term Transport: This term embraces various
technologies such as IP, Optical, Ethernet, TDM, etc  that carry packets and
traffic and might span multiple administrative domains.

 

Please provide your suggestion to refine this definition.

 

Cheers,

Reza

 

From: Adrian Farrel <adrian@olddog.co.uk <mailto:adrian@olddog.co.uk> >
Organization: Old Dog Consulting
Reply-To: "adrian@olddog..co.uk <mailto:adrian@olddog.co.uk> "
<adrian@olddog.co.uk <mailto:adrian@olddog.co.uk> >
Date: Friday, May 1, 2020 at 5:23 AM
To: 'John E Drake' <jdrake=40juniper.net@dmarc.ietf.org
<mailto:jdrake=40juniper.net@dmarc.ietf.org> >, Reza Rokui
<reza.rokui@nokia.com <mailto:reza.rokui@nokia.com> >
Cc: "teas@ietf.org <mailto:teas@ietf.org> " <teas@ietf.org
<mailto:teas@ietf.org> >
Subject: RE: [Teas] FW: The word "transport"

 

Yeah, 'underlay' seems good because it is a relative term and usefully
recursive.

 

A

 

From: Teas <teas-bounces@ietf.org <mailto:teas-bounces@ietf.org> > On Behalf
Of John E Drake
Sent: 30 April 2020 20:59
To: adrian@olddog.co.uk <mailto:adrian@olddog.co.uk> ; 'Rokui, Reza (Nokia -
CA/Ottawa)' <reza.rokui@nokia.com <mailto:reza.rokui@nokia.com> >
Cc: teas@ietf.org <mailto:teas@ietf.org> 
Subject: Re: [Teas] FW: The word "transport"

 

Hi,

 

How about 'underlay network slice'?  It's describing exactly what we are
doing and is congruent with the Enhanced VPN draft.

 

Yours Irrespectively,

 

John

 

 

Juniper Business Use Only

From: Teas <teas-bounces@ietf.org <mailto:teas-bounces@ietf.org> > On Behalf
Of Adrian Farrel
Sent: Thursday, April 30, 2020 3:32 PM
To: 'Rokui, Reza (Nokia - CA/Ottawa)' <reza.rokui@nokia.com
<mailto:reza.rokui@nokia.com> >
Cc: teas@ietf.org <mailto:teas@ietf.org> 
Subject: [Teas] FW: The word "transport"

 

[External Email. Be cautious of content]

 

Reza,

 

Thanks for forwarding this email.

 

I appreciate and understand the way that 3GPP use the term "transport". It
makes a lot of sense in the 3GPP context: they are talking about
connectivity in their realm, and anything that provides that connectivity
(such as an IP network) counts as "transport".

 

But we are not the 3GPP and our terminology needs to be consistent. As I
noted, we already have multiple meanings of transport:

*	The transport layer (traditional from the OSI model) that includes
TCP, UDP, etc.
*	Transport networks (a term also used in the ITU-T) that embraces
Ethernet, TDM, and optical technologies that carry packets for us. This term
is most often seen in CCAMP, TEAS, and PCE.
*	MPLS-TP (possibly deriving from the ITU-T's T-MPLS) that refers to
the use of MPLS as a technology to build transport networks as described in
the previous bullet
*	Transport as a verb (such as in HTTP) meaning simply 'to carry'

In the ACTN work, we moved from 'transport' to 'TE' recognising that ACTN
was applicable to any network type where paths could be computed and
imposed, and resource partitioned and reserved.

 

Now, you say Transport networks (which are technology specific) are used to
realized "Transport Slices" which would appear to imply that IP cannot be
used to realise a transport slice. I don't know if that is your intention.

 

You also say They [3GPP] did not define anything related to Transport but
you say that immediately under a figure you have copied from 3GPP TS 28.530
that clearly shows transport slices, so that leaves me more than a little
confused.

 

Additionally, you say.

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

.which is fine by me since I am not (here) talking about solutions but
services. Actually, I think you would do well to distinguish between VPN as
a service and the technologies used to realise a VPN.

 

Then.

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)

. This is pretty meaningless the way you have worded it. You have said "the
idea of a transport slice is to all a request for transport slices...

across  IP, Optics, PON, Microwave or any combination of these networks. We
shall not limit ourselves to IP VPN.

.Yes, indeed. I wonder where the idea of such a limitation came from.

Note that the definition of the Transport slice is technology agnostic.

.I know. It comes from draft-ietf-teas-enhanced-vpn. That originated in
draft-king-teas-applicability-actn-slicing. I believe I drafted it.

[snip]

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.

.which is fine except that you have moved the problem to the definition of
"transport network". The IETF will struggle, I think, with the idea that an
IP network is a transport network unless, in the context of these documents,
you give a very clear explanation of what these documents mean by that term.

 

But perhaps we can cut through all of this with some simple clarity. Text to
describe the context and meaning of 'transport'. Since the terminology
document has so cheerfully plundered the enhanced VPN framework draft for
some text, you might look there (in the Introduction) for suitable
context-setting text.

 

That, of course, leads me to a separate question that I have, which is why
the design team is reproducing and/or copying material from an existing WG
document rather than working with that document to refine it and/or split it
into multiple documents. A different question, but one the chairs might like
to comment on.

 

Best,

Adrian

 

From: Teas-ns-dt <teas-ns-dt-bounces@ietf.org
<mailto:teas-ns-dt-bounces@ietf.org> > On Behalf Of Rokui, Reza (Nokia -
CA/Ottawa)
Sent: 30 April 2020 16:23
To: teas@ietf.org <mailto:teas@ietf.org> ; teas-ns-dt@ietf.org
<mailto:teas-ns-dt@ietf.org> 
Cc: Rokui, Reza (Nokia - CA/Ottawa) <reza.rokui@nokia.com
<mailto:reza.rokui@nokia.com> >
Subject: [Teas-ns-dt] FW: The word "transport"

 

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 <mailto:reza.rokui@nokia.com> >
Date: Saturday, April 25, 2020 at 11:37 PM
To: Dhruv Dhody <dhruv.ietf@gmail.com <mailto:dhruv.ietf@gmail.com> >, Jari
Arkko <jari.arkko@piuha.net <mailto:jari.arkko@piuha.net> >,
"draft-nsdt-teas-transport-slice-definition@ietf.org
<mailto:draft-nsdt-teas-transport-slice-definition@ietf.org> "
<draft-nsdt-teas-transport-slice-definition@ietf.org
<mailto:draft-nsdt-teas-transport-slice-definition@ietf.org> >
Cc: Reza Rokui <reza.rokui@nokia.com <mailto: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
<mailto: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.

 



 

 

 

    [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.

 

] 

 

    [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 <mailto: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
<mailto: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

    >

 

Juniper Business Use Only

 

Juniper Business Use Only