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

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 1 May 2020 10:23:32 +0100

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

A

From: Teas <[email-masked]> On Behalf Of John E Drake
Sent: 30 April 2020 20:59
To: [email-masked]; 'Rokui, Reza (Nokia - CA/Ottawa)'
<[email-masked]>
Cc: [email-masked]
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 <[email-masked]> On Behalf Of Adrian Farrel
Sent: Thursday, April 30, 2020 3:32 PM
To: 'Rokui, Reza (Nokia - CA/Ottawa)' <[email-masked]>
Cc: [email-masked]
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 <[email-masked]
<mailto:[email-masked]> > On Behalf Of Rokui, Reza (Nokia -
CA/Ottawa)
Sent: 30 April 2020 16:23
To: [email-masked] <mailto:[email-masked]> ; [email-masked]
<mailto:[email-masked]> 
Cc: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]
<mailto:[email-masked]> >
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 <[email-masked] <mailto:[email-masked]> >
Date: Saturday, April 25, 2020 at 11:37 PM
To: Dhruv Dhody <[email-masked] <mailto:[email-masked]> >, Jari
Arkko <[email-masked] <mailto:[email-masked]> >,
"[email-masked]
<mailto:[email-masked]> "
<[email-masked]
<mailto:[email-masked]> >
Cc: Reza Rokui <[email-masked] <mailto:[email-masked]> >
Subject: Re: The word "transport"

Hi all,

Please see inline for some clarifications.

Reza

On 2020-04-24, 1:31 AM, "Dhruv Dhody" <[email-masked]
<mailto:[email-masked]> > 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
<https://urldefense.com/v3/__https:/www.ietf.org/jabber/logs/teas/2020-04-23
.html__;!!NEt6yMaO-gk!WrvQt2QtERG2EFnE6CPHr8TzNjoFggUjNzUFGwWmlw2KiRSR42MiO2
N4YtwhZJI$> 

    ==

    More inline..

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

    <[email-masked] <mailto:[email-masked]> > 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" <[email-masked]
<mailto:[email-masked]> > 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

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 1 May 2020 11:39:56 +0100

Hi Gyan,

> I agree with the confusion of just the word “VPN” by itself

> can mean many different things.  

Good, we start from a point of agreement 😊

> VPN by itself usually means the “vpn technology” client to

> net various flavors of a VPN tunnel such as IPSEC or SSL.

> Also could be net to net router to router IPSEC tunnel P2P

> or P2MP MGRE DMVPN with the many flavors as well.

> Usually when VPN is mentioned in the context of “service”

> it’s mentioned as Layer 3 vpn service overlay, which could

> be over any underlay MPLS, SR flavors SRv6 or SR-MPLS or

> MPLS-In-GRE or MPLS-in-UDP.

I think this is where I disagree. It seems to me that you are coming at this from the perspective of an equipment engineer that makes boxes and protocols to enable network operators to deliver VPN services, or from the perspective of a network engineer tasked with building a network and delivering a service. And why shouldn’t you have that perspective? It’s where you’re standing, and perfectly fine.

But imagine that you are a customer (perhaps an enterprise) commissioning a VPN service. You are interested in the end points that are connected, and you care about the SLA/SLO. But when you say “VPN” you don’t mean SRv6 or MPLS-TE or whatever (unless you are one of those annoying customers that network operators really hate).

And, obviously, the network operator sitting in the middle. For them a VPN is both the service sold and the technology used.

So (clearly?), the use of the term “VPN” is context specific and somewhat fragile. I think “transport” falls into this class as well.

The solution is to either avoid using the terms, or to be really careful to provide sufficient and clear context.

> From the subject heading my take on the definition of “transport”

> in the context of VPN+ or Enhanced VPN transport slicing is as follows.

> When I think of transport I think of the physical underlying resource

> and hardware that makes up the physical infrastructure as a whole.

Well, I understand that interpretation. It’s a common interpretation and the one typically seen in CCAMP.

I don’t think that the VPN+ work uses that definition, and I think it is (attempts to be) clear on that point.

> When I think of the word “transports”  in the context of RSVP TE

> I think of SRLG definition below of links that share common fate

> - “ fate sharing” in the context of FRR n:1 facility protection or

> node protection.

> The term “slice” I think of a slice of a pie where the sum of the

> parts equal the whole.  

> In the context of slicing I think 3D dimensionally as if cutting a pie

> which could be a cross section of the networks if you look at in a

> 3D logical construct.

> So you can think of the network as multi dimensional and take

> multiple cross sections of the network from which you get the

> layers construct that make up the physical topology.

That may all be a bit complex, but I understand what you are saying.

> So from a layer perspective just about every topology that

> involves some kind of tunneling of traffic has the concept of

> overlay and underlay.

Like John says, this may be a more useful terminology.

> In the MPLS or SR world you can think of a 2 level deep label

> stack where the topmost transport label is the “underlay” and

> the service label bottom of stack being the overlay.

> So then going full circle looking at VPN+ or Enhanced VPN (EVPN)

> framework sits in the overlay.  

> I would not call it transport overlay as the underlay is the topmost

> label underpinnings of resources isolation that you are trying to 

> pin the EVPN overlay service to.

> I think however since we are cutting the network so cross sectionally

> and not horizontally it is more like a transport slice of the network pie. 

That’s probably a circular thing because that’s your definition of a transport slice.

> I think if it was just a regular L3 VPN it would be an overlay would be

> the right description but since we are carving our underlying resources

> for this VPN service I agree it’s more like a transport slice.

Well, playing with terminology a bit, yes, an L3VPN is an overlay when seen from outside. But when seen in the underlay, a L3VPN that is realised using TE tunnels that have resource reservations and follow specific paths (possibly avoiding other traffic, and possibly providing resilience) is using a “slice” of the underlay network.

> There was a long thread on this similar topic with Xie on using

> Isis MT for transport slicing.

> https://tools.ietf.org/html/draft-xie-lsr-isis-sr-vtn-mt-00

Thanks for that pointer. I think this further serves to indicate that we need to clean up the terminology.

> So now how would the isolation work with this EVPN or VPN+

> transport slice that has its own dedication resources.

Well, now we are firmly in solution space and not talking about terminology or architecture.

Isolation is well described in draft-ietf-teas-enhanced-vpn and it is technology-dependent. For example, if the underlay is WDM, isolation might involve using different lambdas for different slices. OTOH, if the underlay is packet, isolation might require selection of non-overlapping paths (i.e., physical resources), of the reservation of different pools of buffers, or simply using different identifiers (such as labels).

I do suggest reading the document.

> Most vendors and modern routers have the Virtual router 

> concept vPE or vP, similar to NFV like VNF containers for

> network functions.  So let’s say on a MPLS or SR core where

> you are have a white box solution on merchant silicon and

> have virtualization containers built.  So for each P and PE

> router you have a dedicated container with dedicated

> resources memory for the EVPN as it needs special

> treatment for 5G RAN front and back hauls.  The remaining

> L3 VPNs on the core boxes sit in a BAU container with

> shared resources.  So there maybe cases where you might

> have multiple EVPNs that need dedicated resources and for

> those you have virtual router carved up enough resources to

> meet the applications requirement.  So with the draft

> mentioned each EVPN would sit isolated in its own Isis mt

> instance providing complete control plane isolation on top of

> the above router virtualization container based isolation.

This is a fine way to deliver an enhanced VPN service or a network slice service. I would say it is only one way of doing it out of many ways.

Best,

Adrian

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 1 May 2020 09:31:02 -0400

Agreed on most all your points in-line 😀

On Fri, May 1, 2020 at 6:40 AM Adrian Farrel <[email-masked]> wrote:

> I think this is where I disagree. It seems to me that you are coming at
> this from the perspective of an equipment engineer that makes boxes and
> protocols to enable network operators to deliver VPN services, or from the
> perspective of a network engineer tasked with building a network and
> delivering a service. And why shouldn’t you have that perspective? It’s
> where you’re standing, and perfectly fine.
>

But imagine that you are a customer (perhaps an enterprise) commissioning a
> VPN service. You are interested in the end points that are connected, and
> you care about the SLA/SLO. But when you say “VPN” you don’t mean SRv6 or
> MPLS-TE or whatever (unless you are one of those annoying customers that
> network operators really hate).
>
>
>
> And, obviously, the network operator sitting in the middle. For them a VPN
> is both the service sold and the technology used.
>
>   Good points as I took the term “VPN” placing in the technology context
and then also placing in the service context, but depending on the point of
view from where you are looking at it - as you state it could be seen as
both service and technology as well, adding to the confusion of use of the
word.

>
>
> So (clearly?), the use of the term “VPN” is context specific and somewhat
> fragile. I think “transport” falls into this class as well.
>
>  Agreed
>
> Completely agree
>  Agreed
>  Agreed
> Well, playing with terminology a bit, yes, an L3VPN is an overlay when
> seen from outside. But when seen in the underlay, a L3VPN that is realised
> using TE tunnels that have resource reservations and follow specific paths
> (possibly avoiding other traffic, and possibly providing resilience) is
> using a “slice” of the underlay network.
>
> Understood.  Such as per VRF TE or SR-TE coloring or Flex Algo using a
> slice of the underlay with static ERO or cSPF dynamic with TE weights and
> included and excluded nodes in the path to meet underlay resource
> requirements for EVPN. We also today have DS TE CBTS and PBTS for flow
> based QOS SLA via RDM/MAM. Agreed.
>
> Isolation is well described in draft-ietf-teas-enhanced-vpn and it is
> technology-dependent. For example, if the underlay is WDM, isolation might
> involve using different lambdas for different slices. OTOH, if the underlay
> is packet, isolation might require selection of non-overlapping paths
> (i.e., physical resources), of the reservation of different pools of
> buffers, or simply using different identifiers (such as labels).
>
>
>
>  Will do
> This is a fine way to deliver an enhanced VPN service or a network slice
> service. I would say it is only one way of doing it out of many ways.
>
> Agreed.  I know we are not delving I into solution space yet but sometimes
> imagining the solution and how it would work in theory in my mind sometimes
> helps me understand the benefits of the technology  *and it’s feasibility
> in the real world.*
>
Best,
-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: [email-masked]

---

From: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>
Date: Fri, 1 May 2020 13:52:44 +0000

Adrian,
Thanks for your response. Please see inline.

In summary, as you pointed out at the end of your email, I will include the definition of the Transport. I looked at VPN+ draft as well as you suggested
              >>>>  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.

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

With this definition, the Term “Transport Slice” should make more sense.

Cheers,
Reza

From: Adrian Farrel <[email-masked]>
Organization: Old Dog Consulting
Reply-To: "[email-masked]" <[email-masked]>
Date: Thursday, April 30, 2020 at 3:31 PM
To: Reza Rokui <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: FW: The word "transport"

Reza,

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.

[Reza] Reference to 3GPP was just an example since you and Joel explicitly asked about it.
I agree that we at IETF should be consistent. Your summary is clear.

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.
[Reza] Not sure how you came up with this conclusion but IP will be part of technology to realize Transport Slices.

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.
[Reza] Let me clarify. 3GPP TS 28.530 refers to transport slice as “Connectivity within Transport Network” as shown below.
They did not use term “Transport Slice”

Additionally, you say…

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

[Reza] My reference was VPN as a technology to realize the transport slice, e.g. L3 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…

…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.
[Reza] Good point Adrian. I have included my definition of Transport above

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 <[email-masked]> On Behalf Of Rokui, Reza (Nokia - CA/Ottawa)
Sent: 30 April 2020 16:23
To: [email-masked]; [email-masked]
Cc: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>>
Date: Saturday, April 25, 2020 at 11:37 PM
To: Dhruv Dhody <[email-masked]<mailto:[email-masked]>>, Jari Arkko <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Reza Rokui <[email-masked]<mailto:[email-masked]>>
Subject: Re: The word "transport"

Hi all,

Reza

On 2020-04-24, 1:31 AM, "Dhruv Dhody" <[email-masked]<mailto:[email-masked]>> wrote:

    Hi Reza,

    ==

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

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

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

] 

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

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

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

    ==

    More inline..

    <[email-masked]<mailto:[email-masked]>> wrote:

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

    Thanks!

    Dhruv

    > On 2020-04-23, 12:35 PM, "Dhruv Dhody" <[email-masked]<mailto:[email-masked]>> wrote:

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

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

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

---

From: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>
Date: Fri, 1 May 2020 14:01:52 +0000

Adrian and all,

As suggested, this is the definition of term “Transport” :

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

With this definition, the Term “Transport Slice” should make more sense.
Please provide your suggestion to refine this definition.

Cheers,
Reza

From: Adrian Farrel <[email-masked]>
Organization: Old Dog Consulting
Reply-To: "[email-masked]" <[email-masked]>
Date: Thursday, April 30, 2020 at 5:50 PM
To: 'Kiran Makhijani' <[email-masked]>, Reza Rokui <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: [Teas] FW: The word "transport"

Hey,

Not sure if you mean “the relationship to the existing document” or “the relationship to VPN+”.

The relationship to VPN+ is really about how you view a service that is network slice: i.e., a collection of end-points, the connectivity between them, the level of service. Enhanced VPN is simply another way of thinking about a network slice.

Probably, as I said to Reza, there is confusion between “VPN as a service” and “VPN as a set of technologies for delivering a service.” As engineers we often get confused between the two concepts, but we shouldn’t.

Yes, you’re right: if we describe ‘transport’ in our context this will help avoid confusion. That’s what I was trying to suggest in my email. I was also suggesting that suitable text can be found in the enhanced VPN draft, just the way that suitable text for describing a slice was found there.

The relationship to the existing document is a different question. I would like to understand how we resolve that so that we can put our efforts into the right documents.

Best,
Adrian

From: Kiran Makhijani <[email-masked]>
Sent: 30 April 2020 21:58
To: [email-masked]; 'Rokui, Reza (Nokia - CA/Ottawa)' <[email-masked]>
Cc: [email-masked]
Subject: RE: [Teas] FW: The word "transport"

Hello Adrian,
Thanks for many interesting points below.
If we describe what ‘transport’ is in the context of the slices, (use hyphenated  transport-slice 😊) perhaps it’s ok?  (The enhanced VPN relationship is a lengthier discussion).
-Kiran

From: Teas <[email-masked]<mailto:[email-masked]>> On Behalf Of Adrian Farrel
Sent: Thursday, April 30, 2020 12:32 PM
To: 'Rokui, Reza (Nokia - CA/Ottawa)' <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [Teas] FW: The word "transport"

Reza,

Additionally, you say…

Then…

[snip]

Best,
Adrian

From: Teas-ns-dt <[email-masked]<mailto:[email-masked]>> On Behalf Of Rokui, Reza (Nokia - CA/Ottawa)
Sent: 30 April 2020 16:23
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>
Subject: [Teas-ns-dt] FW: The word "transport"

All,

Cheers,
Reza

Hi all,

Reza

    Hi Reza,

    ==

] 

    Full logs - https://www.ietf.org/jabber/logs/teas/2020-04-23.html<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fjabber%2Flogs%2Fteas%2F2020-04-23.html&data=02%7C01%7Ckiranm%40futurewei.com%7C5fb387d7a551444584ca08d7ed3d5097%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637238719923636105&sdata=%2FZXF3AwTmx4qHpY3PzQURpylcyZ2CnMYAKMRm9F8%2FEA%3D&reserved=0>

    ==

    More inline..

    <[email-masked]<mailto:[email-masked]>> wrote:

    Thanks!

    Dhruv

---

From: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>
Date: Fri, 1 May 2020 14:13:05 +0000

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”

Cheers,
Reza

From: Adrian Farrel <[email-masked]>
Organization: Old Dog Consulting
Reply-To: "[email-masked]" <[email-masked]>
Date: Friday, May 1, 2020 at 5:23 AM
To: 'John E Drake' <jdrake=[email-masked]>, Reza Rokui <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: [Teas] FW: The word "transport"

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

A

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

Reza,

Additionally, you say…

Then…

[snip]

Best,
Adrian

All,

Cheers,
Reza

Hi all,

Reza

    Hi Reza,

    ==

] 

    Full logs - https://www.ietf.org/jabber/logs/teas/2020-04-23.html<https://urldefense.com/v3/__https:/www.ietf.org/jabber/logs/teas/2020-04-23.html__;!!NEt6yMaO-gk!WrvQt2QtERG2EFnE6CPHr8TzNjoFggUjNzUFGwWmlw2KiRSR42MiO2N4YtwhZJI$>

    ==

    More inline..

    <[email-masked]<mailto:[email-masked]>> wrote:

    Thanks!

    Dhruv

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 1 May 2020 15:30:38 +0100

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) <[email-masked]> 
Sent: 01 May 2020 15:13
To: [email-masked]; 'John E Drake' <jdrake=[email-masked]>; [email-masked]; [email-masked]
Cc: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
Subject: Re: [Teas] FW: The word "transport"

John and all,

Cheers,

Reza

From: Adrian Farrel <[email-masked] <mailto:[email-masked]> >
Organization: Old Dog Consulting
Reply-To: "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >
Date: Friday, May 1, 2020 at 5:23 AM
To: 'John E Drake' <jdrake=[email-masked] <mailto:jdrake=[email-masked]> >, Reza Rokui <[email-masked] <mailto:[email-masked]> >
Cc: "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >
Subject: RE: [Teas] FW: The word "transport"

A

From: Teas <[email-masked] <mailto:[email-masked]> > On Behalf Of John E Drake
Sent: 30 April 2020 20:59
To: [email-masked] <mailto:[email-masked]> ; 'Rokui, Reza (Nokia - CA/Ottawa)' <[email-masked] <mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> 
Subject: Re: [Teas] FW: The word "transport"

Hi,

Yours Irrespectively,

John

From: Teas <[email-masked] <mailto:[email-masked]> > On Behalf Of Adrian Farrel
Sent: Thursday, April 30, 2020 3:32 PM
To: 'Rokui, Reza (Nokia - CA/Ottawa)' <[email-masked] <mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> 
Subject: [Teas] FW: The word "transport"

Reza,

Additionally, you say…

Then…

[snip]

Best,

Adrian

From: Teas-ns-dt <[email-masked] <mailto:[email-masked]> > On Behalf Of Rokui, Reza (Nokia - CA/Ottawa)
Sent: 30 April 2020 16:23
To: [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> 
Cc: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked] <mailto:[email-masked]> >
Subject: [Teas-ns-dt] FW: The word "transport"

All,

Cheers,

Reza

To: Dhruv Dhody <[email-masked] <mailto:[email-masked]> >, Jari Arkko <[email-masked] <mailto:[email-masked]> >, "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >

Hi all,

Reza

On 2020-04-24, 1:31 AM, "Dhruv Dhody" <[email-masked] <mailto:[email-masked]> > wrote:

    Hi Reza,

    ==

 

] 

 

    Full logs - https://www.ietf.org/jabber/logs/teas/2020-04-23.html <https://urldefense.com/v3/__https:/www.ietf.org/jabber/logs/teas/2020-04-23.html__;!!NEt6yMaO-gk!WrvQt2QtERG2EFnE6CPHr8TzNjoFggUjNzUFGwWmlw2KiRSR42MiO2N4YtwhZJI$> 

    ==

    More inline..

    <[email-masked] <mailto:[email-masked]> > wrote:

    Thanks!

    Dhruv

    > On 2020-04-23, 12:35 PM, "Dhruv Dhody" <[email-masked] <mailto:[email-masked]> > wrote:

---

From: John E Drake <[email-masked]>
Date: Fri, 1 May 2020 15:08:19 +0000

Hi,

Comments inline.

Yours Irrespectively,

John

Juniper Business Use Only
From: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
Sent: Friday, May 1, 2020 10:13 AM
To: [email-masked]; John E Drake <[email-masked]>; [email-masked]; [email-masked]
Cc: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
Subject: Re: [Teas] FW: The word "transport"

John and all,

This is where I disagree with term "Underlay Network Slice".

[JD]  The terms 'underlay network' and 'overlay network' are pretty well understood in the IETF, and other work in this area over the past several years has typically defined a slice as a specific subset of shared or dedicated resources in the underlay network.  As Adrian correctly points out, the term 'transport network'  has a lot of baggage and is mainly used outside the IETF.

It brings lots of other questions

[JD]  What exactly doe this mean?

since we (IETF) do not deal with network slice as clearly described in our draft.

[JD]  This is demonstrably incorrect.  E.g., what is the topic of your 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"

Cheers,
Reza

From: Adrian Farrel <[email-masked]<mailto:[email-masked]>>
Organization: Old Dog Consulting
Reply-To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Friday, May 1, 2020 at 5:23 AM
To: 'John E Drake' <jdrake=[email-masked]<mailto:jdrake=[email-masked]>>, Reza Rokui <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Teas] FW: The word "transport"

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

A

From: Teas <[email-masked]<mailto:[email-masked]>> On Behalf Of John E Drake
Sent: 30 April 2020 20:59
To: [email-masked]<mailto:[email-masked]>; 'Rokui, Reza (Nokia - CA/Ottawa)' <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
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

Reza,

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

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

Additionally, you say...

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

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

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

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

Best,
Adrian

All,

Cheers,
Reza

Hi all,

Reza

    Hi Reza,

    ==

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

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.

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

[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

] 

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

    ==

    More inline..

    <[email-masked]<mailto:[email-masked]>> wrote:

    Thanks!

    Dhruv

---

From: Kiran Makhijani <[email-masked]>
Date: Fri, 1 May 2020 15:17:07 +0000

John,
We have defined transport slice as an independent construct. There's a high level description of it, the way a customer or user of a transport slice will see it and then there's the realization part. The 'underlay' for me only covers the realization.
To answer your second question, Chapter 6 has "transport slices" and "other slices". They are short for "transport network slice" (our scope) and "other network slices"(ran, core etc.).
Hth,
Kiran

From: Teas-ns-dt <[email-masked]> On Behalf Of John E Drake
Sent: Friday, May 1, 2020 8:08 AM
To: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Teas-ns-dt] [Teas] FW: The word "transport"

Hi,

Comments inline.

Yours Irrespectively,

John

Juniper Business Use Only
From: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>
Sent: Friday, May 1, 2020 10:13 AM
To: [email-masked]<mailto:[email-masked]>; John E Drake <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Teas] FW: The word "transport"

John and all,

Cheers,
Reza

Reply-To: "adrian@olddog..co.uk<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

A

Hi,

Yours Irrespectively,

John

Reza,

Additionally, you say...

Then...

[snip]

Best,
Adrian

All,

Cheers,
Reza

Hi all,

Reza

    Hi Reza,

    ==

] 

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

    Full logs - https://www.ietf.org/jabber/logs/teas/2020-04-23.html<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fjabber%2Flogs%2Fteas%2F2020-04-23.html__%3B!!NEt6yMaO-gk!WrvQt2QtERG2EFnE6CPHr8TzNjoFggUjNzUFGwWmlw2KiRSR42MiO2N4YtwhZJI%24&data=02%7C01%7Ckiranm%40futurewei.com%7C2da97b2bd71e492743c608d7ede18524%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637239425181165830&sdata=X1Vq52rJ2cudS1V5e%2BydfBJ4judunst%2FTt5INZHU9zA%3D&reserved=0>

    ==

    More inline..

    <[email-masked]<mailto:[email-masked]>> wrote:

    Thanks!

    Dhruv

---

From: John E Drake <[email-masked]>
Date: Fri, 1 May 2020 15:30:47 +0000

Hi,

Comments inline.

Yours Irrespectively,

John

Juniper Business Use Only
From: Kiran Makhijani <[email-masked]>
Sent: Friday, May 1, 2020 11:17 AM
To: John E Drake <[email-masked]>; Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Teas] FW: The word "transport"

John,

[JD] I don't agree.  The high level description is simply a way for the customer to specify the underlay network resources they want their slice to provide them without having to know underlay network's details.

To answer your second question, Chapter 6 has "transport slices" and "other slices". They are short for "transport network slice" (our scope)

[JD]  Using your logic, the term 'transport network slice'  also a describes a realization.

and "other network slices"(ran, core etc.).
Hth,
Kiran

From: Teas-ns-dt <[email-masked]<mailto:[email-masked]>> On Behalf Of John E Drake
Sent: Friday, May 1, 2020 8:08 AM
To: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Teas-ns-dt] [Teas] FW: The word "transport"

Hi,

Comments inline.

Yours Irrespectively,

John

John and all,

Cheers,
Reza

Reply-To: "adrian@olddog...co.uk<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

A

Hi,

Yours Irrespectively,

John

Reza,

Additionally, you say...

Then...

[snip]

Best,
Adrian

All,

Cheers,
Reza

Hi all,

Reza

    Hi Reza,

    ==

] 

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

    Full logs - https://www.ietf.org/jabber/logs/teas/2020-04-23.html<https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fwww.ietf.org*2Fjabber*2Flogs*2Fteas*2F2020-04-23.html__*3B!!NEt6yMaO-gk!WrvQt2QtERG2EFnE6CPHr8TzNjoFggUjNzUFGwWmlw2KiRSR42MiO2N4YtwhZJI*24&data=02*7C01*7Ckiranm*40futurewei.com*7C2da97b2bd71e492743c608d7ede18524*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637239425181165830&sdata=X1Vq52rJ2cudS1V5e*2BydfBJ4judunst*2FTt5INZHU9zA*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!NEt6yMaO-gk!UAWs2L6xk_N_UrJ26uhBCAj0u1g8P6CLLksUuGrZ1lmYbn1vG6UVNzZvIzKRsvs$>

    ==

    More inline..

    <[email-masked]<mailto:[email-masked]>> wrote:

    Thanks!

    Dhruv

---

From: Eric Gray <[email-masked]>
Date: Fri, 1 May 2020 15:34:53 +0000

Reza,

              Your definition mostly looks good, but I have some questions about the part that says “… packets and traffic and …”

              1st, from a strictly grammatical perspective, having “and X and” is problematic.  The sentence meaning does not appear to change if you replace the second “and” with “that.”  But this change is not needed if the bigger issue is addressed as suggested below.

              The bigger issue is with the phrase “packets and traffic” – which is strange since the relationship between “packets and traffic” can be summed up as:

  *   Not all traffic is in the form of “packets.”
  *   Most, if not all, packets are some form of “traffic.”

              I believe that this might be what you are trying to say by including both, but there other constructions that are not as strange.  For example, we could say:

Transport: This term embraces various technologies (such as IP, Optical, Ethernet, TDM, etc.) that carry data and might span multiple administrative domains.

From: Teas-ns-dt <[email-masked]> On Behalf Of Rokui, Reza (Nokia - CA/Ottawa)
Sent: Friday, May 1, 2020 9:53 AM
To: [email-masked]; [email-masked]; [email-masked]
Cc: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
Subject: Re: [Teas-ns-dt] The word "transport"

Adrian,

Cheers,
Reza

To: Reza Rokui <[email-masked]<mailto:[email-masked]>>

Reza,

Additionally, you say…

Then…

[snip]

Best,
Adrian

All,

Cheers,
Reza

Hi all,

Reza

    Hi Reza,

    ==

] 

    ==

    More inline..

    <[email-masked]<mailto:[email-masked]>> wrote:

    Thanks!

    Dhruv

---

From: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>
Date: Fri, 1 May 2020 15:37:49 +0000

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 <[email-masked]>
Organization: Old Dog Consulting
Reply-To: "[email-masked]" <[email-masked]>
Date: Friday, May 1, 2020 at 10:30 AM
To: Reza Rokui <[email-masked]>, 'John E Drake' <jdrake=[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [Teas] FW: The word "transport"

Hi Reza,

Cheers,
Adrian

John and all,

Cheers,
Reza

A

Hi,

Yours Irrespectively,

John

Reza,

Additionally, you say…

Then…

[snip]

Best,
Adrian

All,

Cheers,
Reza

Hi all,

Reza

    Hi Reza,

    ==

] 

    ==

    More inline..

    <[email-masked]<mailto:[email-masked]>> wrote:

    Thanks!

    Dhruv

---

From: Eric Gray <[email-masked]>
Date: Fri, 1 May 2020 15:45:45 +0000

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.

Sent: Friday, May 1, 2020 11:38 AM

Adrian,

Reza

To: Reza Rokui <[email-masked]<mailto:[email-masked]>>, 'John E Drake' <jdrake=[email-masked]<mailto:jdrake=[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

Hi Reza,

Cheers,
Adrian

From: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>
Sent: 01 May 2020 15:13
To: [email-masked]<mailto:[email-masked]>; 'John E Drake' <jdrake=[email-masked]<mailto:jdrake=[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Teas] FW: The word "transport"

John and all,

Cheers,
Reza

A

Hi,

Yours Irrespectively,

John

Reza,

Additionally, you say…

Then…

[snip]

Best,
Adrian

All,

Cheers,
Reza

Hi all,

Reza

    Hi Reza,

    ==

] 

    Full logs - https://www.ietf.org/jabber/logs/teas/2020-04-23.html<https://protect2.fireeye.com/v1/url?k=d4f6bc46-8a560628-d4f6fcdd-86b1886cfa64-dd8e4ff74c5dda87&q=1&e=b15230b3-e6dc-4732-83e3-00354fdc75ae&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fjabber%2Flogs%2Fteas%2F2020-04-23.html__%3B%21%21NEt6yMaO-gk%21WrvQt2QtERG2EFnE6CPHr8TzNjoFggUjNzUFGwWmlw2KiRSR42MiO2N4YtwhZJI%24>

    ==

    More inline..

    <[email-masked]<mailto:[email-masked]>> wrote:

    Thanks!

    Dhruv

---

From: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>
Date: Fri, 1 May 2020 15:49:20 +0000

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

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
[email-masked]<mailto:[email-masked]>

From: Eric Gray <[email-masked]>
Date: Friday, May 1, 2020 at 11:45 AM
To: Reza Rokui <[email-masked]>, "[email-masked]" <[email-masked]>, 'John E Drake' <jdrake=[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [Teas] FW: The word "transport"

Adrian,

Reza

Hi Reza,

Cheers,
Adrian

John and all,

Cheers,
Reza

A

Hi,

Yours Irrespectively,

John

Reza,

Additionally, you say…

Then…

[snip]

Best,
Adrian

All,

Cheers,
Reza

Hi all,

Reza

    Hi Reza,

    ==

] 

    ==

    More inline..

    <[email-masked]<mailto:[email-masked]>> wrote:

    Thanks!

    Dhruv

---

From: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>
Date: Fri, 1 May 2020 15:52:36 +0000

John,
Please see inline.

Cheers,
Reza

From: John E Drake <[email-masked]>
Date: Friday, May 1, 2020 at 11:08 AM
To: Reza Rokui <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [Teas] FW: The word "transport"

Hi,

Comments inline.

Yours Irrespectively,

John

John and all,

This is where I disagree with term “Underlay Network Slice”.

[JD]  The terms ‘underlay network’ and ‘overlay network’ are pretty well understood in the IETF, and other work in this area over the past several years has typically defined a slice as a specific subset of shared or dedicated resources in the underlay network.  As Adrian correctly points out, the term ‘transport network’  has a lot of baggage and is mainly used outside the IETF.

[Reza] The question is not overlay vs. underlay. My argument was that this term “Underlay network slice” is confusing. I just responded to Adrian in other email thread but this is the summary. Please refer to that thread for more info.
IETF does not deal with e2e network slice because 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)
Since Other slices are not in IETF scope, we should refrain from using “network slice” at IETF. IETF is part of the e2e network slice solution.

Cheers,
Reza

A

Hi,

Yours Irrespectively,

John

Reza,

Additionally, you say…

Then…

[snip]

Best,
Adrian

All,

Cheers,
Reza

Hi all,

Reza

    Hi Reza,

    ==

] 

    ==

    More inline..

    <[email-masked]<mailto:[email-masked]>> wrote:

    Thanks!

    Dhruv

---

From: John E Drake <[email-masked]>
Date: Fri, 1 May 2020 15:52:41 +0000

Hi,

Comment inline

Yours Irrespectively,

John

Juniper Business Use Only
From: Teas-ns-dt <[email-masked]> On Behalf Of Rokui, Reza (Nokia - CA/Ottawa)
Sent: Friday, May 1, 2020 11:49 AM
To: Eric Gray <[email-masked]>; [email-masked]; 'John E Drake' <jdrake=[email-masked]>; [email-masked]; [email-masked]
Cc: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
Subject: Re: [Teas-ns-dt] [Teas] FW: The word "transport"

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.

From: Eric Gray <[email-masked]<mailto:[email-masked]>>
Date: Friday, May 1, 2020 at 11:45 AM
To: Reza Rokui <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, 'John E Drake' <jdrake=[email-masked]<mailto:jdrake=[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Teas] FW: The word "transport"

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.

Adrian,

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

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

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

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.

Cheers,
Reza

A

Hi,

Yours Irrespectively,

John

Reza,

Additionally, you say...

Then...

[snip]

Best,
Adrian

All,

Cheers,
Reza

Hi all,

Reza

    Hi Reza,

    ==

] 

    Full logs - https://www.ietf.org/jabber/logs/teas/2020-04-23.html<https://urldefense.com/v3/__https:/protect2.fireeye.com/v1/url?k=d4f6bc46-8a560628-d4f6fcdd-86b1886cfa64-dd8e4ff74c5dda87&q=1&e=b15230b3-e6dc-4732-83e3-00354fdc75ae&u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fwww.ietf.org*2Fjabber*2Flogs*2Fteas*2F2020-04-23.html__*3B*21*21NEt6yMaO-gk*21WrvQt2QtERG2EFnE6CPHr8TzNjoFggUjNzUFGwWmlw2KiRSR42MiO2N4YtwhZJI*24__;JSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!Ss83mQtEVqDRzJaflsjI0IuUspo1qru8LEP6d7EHAVACW_rPFMRhTgGzcd8fvSc$>

    ==

    More inline..

    <[email-masked]<mailto:[email-masked]>> wrote:

    Thanks!

    Dhruv

---

From: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>
Date: Fri, 1 May 2020 15:56:24 +0000

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

As far as I know there is not any SDO which defines “Transport slice” at least at the time that we wrote the draft. If not so, please provide the reference.
We at IETF started using this term.

Reza

From: John E Drake <[email-masked]>
Date: Friday, May 1, 2020 at 11:52 AM
To: Reza Rokui <[email-masked]>, Eric Gray <[email-masked]>, "[email-masked]" <[email-masked]>, 'John E Drake' <jdrake=[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [Teas] FW: The word "transport"

Hi,

Comment inline

Yours Irrespectively,

John

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

Reza Rokui, Ph.D.

Adrian,

Reza

Hi Reza,

Cheers,
Adrian

John and all,

Cheers,
Reza

A

Hi,

Yours Irrespectively,

John

Reza,

Additionally, you say…

Then…

[snip]

Best,
Adrian

All,

Cheers,
Reza

Hi all,

Reza

    Hi Reza,

    ==

] 

    ==

    More inline..

    <[email-masked]<mailto:[email-masked]>> wrote:

    Thanks!

    Dhruv

---

From: Eric Gray <[email-masked]>
Date: Fri, 1 May 2020 15:57:11 +0000

Reza,

This is where you will likely get us into some trouble.

I mostly agree about the RAN slices part of your argument, but I am highly suspicious of your assertion relative to Packet Core.

That is why I suggested that we stick to a definition with a focus on the part about generic slicing (network slicing, transport network slicing, etc.) that requires “packetization” and forwarding as defined in IETF specifications.

--
Eric

Importance: High

Reza Rokui, Ph.D.

Adrian,

Reza

Hi Reza,

Cheers,
Adrian

John and all,

Cheers,
Reza

A

Hi,

Yours Irrespectively,

John

Reza,

Additionally, you say…

Then…

[snip]

Best,
Adrian

All,

Cheers,
Reza

Hi all,

Reza

    Hi Reza,

    ==

] 

    ==

    More inline..

    <[email-masked]<mailto:[email-masked]>> wrote:

    Thanks!

    Dhruv

---

From: John E Drake <[email-masked]>
Date: Fri, 1 May 2020 15:58:32 +0000

Hi,

Comment inline

Yours Irrespectively,

John

Juniper Business Use Only
From: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
Sent: Friday, May 1, 2020 11:53 AM
To: John E Drake <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Cc: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
Subject: Re: [Teas] FW: The word "transport"

John,
Please see inline.

Cheers,
Reza

From: John E Drake <[email-masked]<mailto:[email-masked]>>
Date: Friday, May 1, 2020 at 11:08 AM
To: Reza Rokui <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Teas] FW: The word "transport"

Hi,

Comments inline.

Yours Irrespectively,

John

John and all,

[Reza] The question is not overlay vs. underlay. My argument was that this term "Underlay network slice" is confusing. I just responded to Adrian in other email thread but this is the summary. Please refer to that thread for more info.
IETF does not deal with e2e network slice because 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)
Since Other slices are not in IETF scope, we should refrain from using "network slice" at IETF. IETF is part of the e2e network slice solution.

[JD]  'Transport Slice' is a term coined outside the IETF and if we use it we will have to explain what we mean by it in the context of the IETF.

Cheers,
Reza

A

Hi,

Yours Irrespectively,

John

Reza,

Additionally, you say...

Then...

[snip]

Best,
Adrian

All,

Cheers,
Reza

Hi all,

Reza

    Hi Reza,

    ==

] 

    ==

    More inline..

    <[email-masked]<mailto:[email-masked]>> wrote:

    Thanks!

    Dhruv

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 1 May 2020 17:02:52 +0100

Well yes. I can read the drafts. That’s why I don’t understand your comment that the IETF does not deal with network slice.

You mean that you are saying that the scope of the IETF is limited to a subset of network slices that you call transport slices. But that is to say that the IETF works on some network slices, so I think we’re clear that the IETF does deal with network slices.

I have read the 3GPP work. Yes, they are different. Although, I think it is a terrible shame to limit ourselves to this use case. Slicing is an abstract function and we should be able to use it to support many different types of service. And I think it is important that it should be a recursive concept. So, when a transport slice is enabled by slicing a lower layer network, you (presumably) call the slice of the lower layer network a transport slice, and the transport slice that is enabled by the transport slice is called a transport slice. Not confusing at all 😊

Wow, well, maybe you need to check that with the authors of those drafts and (of course) set it in the context of the definition of “transport”.

Well, here I am going to be a little snarky, I fear.

No!

The name of the DT and it’s charter were clearly set out. It is what it is, and it’s work scope is clear. 

Enjoy,

Adrian

---

From: John E Drake <[email-masked]>
Date: Fri, 1 May 2020 16:12:17 +0000

Hi,

That was not my understanding but if that's true then we are responsible for developing a rather bad term.  As Adrian detailed in his original email, 'transport' is a term typically used by other standards bodies and that within the IETF it carries a lot of baggage.

Yours Irrespectively,

John

Juniper Business Use Only
From: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
Sent: Friday, May 1, 2020 11:56 AM
To: John E Drake <[email-masked]>; Eric Gray <[email-masked]>; [email-masked]; 'John E Drake' <jdrake=[email-masked]>; [email-masked]; [email-masked]
Cc: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
Subject: Re: [Teas] FW: The word "transport"

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

As far as I know there is not any SDO which defines "Transport slice" at least at the time that we wrote the draft. If not so, please provide the reference.
We at IETF started using this term.

Reza

From: John E Drake <[email-masked]<mailto:[email-masked]>>
Date: Friday, May 1, 2020 at 11:52 AM
To: Reza Rokui <[email-masked]<mailto:[email-masked]>>, Eric Gray <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, 'John E Drake' <jdrake=[email-masked]<mailto:jdrake=[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Teas] FW: The word "transport"

Hi,

Comment inline

Yours Irrespectively,

John

To: Eric Gray <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; 'John E Drake' <jdrake=[email-masked]<mailto:jdrake=[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Reza Rokui, Ph.D.

Adrian,

Reza

Hi Reza,

Cheers,
Adrian

John and all,

Cheers,
Reza

A

Hi,

Yours Irrespectively,

John

Reza,

Additionally, you say...

Then...

[snip]

Best,
Adrian

All,

Cheers,
Reza

Hi all,

Reza

    Hi Reza,

    ==

] 

    ==

    More inline..

    <[email-masked]<mailto:[email-masked]>> wrote:

    Thanks!

    Dhruv

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 1 May 2020 17:12:36 +0100

Eric,

I appreciate your attempt here, but I see know reason why we would not slice a sub-IP network utilising the technology that we have developed in the IETF for control and management of sub-IP networks.

In fact, maybe we should not try to use this thread to define the purpose and scope of the IETF 😊 The creation of CCAMP was an old argument and results in the IP-based control of non-packet networks being in scope.

Best,

Adrian

From: Eric Gray <[email-masked]> 
Sent: 01 May 2020 16:46
To: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>; [email-masked]; 'John E Drake' <jdrake=[email-masked]>; [email-masked]; [email-masked]
Subject: RE: [Teas] FW: The word "transport"

To: [email-masked] <mailto:[email-masked]> ; 'John E Drake' <jdrake=[email-masked] <mailto:jdrake=[email-masked]> >; [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> 

Adrian,

 

Reza 

To: Reza Rokui <[email-masked] <mailto:[email-masked]> >, 'John E Drake' <jdrake=[email-masked] <mailto:jdrake=[email-masked]> >, "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >, "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >

Hi Reza,

Cheers,

Adrian

From: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked] <mailto:[email-masked]> > 
Sent: 01 May 2020 15:13
To: [email-masked] <mailto:[email-masked]> ; 'John E Drake' <jdrake=[email-masked] <mailto:jdrake=[email-masked]> >; [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> 
Cc: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Teas] FW: The word "transport"

John and all,

Cheers,

Reza

A

Hi,

Yours Irrespectively,

John

Reza,

Additionally, you say…

Then…

[snip]

Best,

Adrian

All,

Cheers,

Reza

Hi all,

Reza

    Hi Reza,

    ==

 

] 

 

    Full logs - https://www.ietf.org/jabber/logs/teas/2020-04-23.html <https://protect2.fireeye.com/v1/url?k=d4f6bc46-8a560628-d4f6fcdd-86b1886cfa64-dd8e4ff74c5dda87&q=1&e=b15230b3-e6dc-4732-83e3-00354fdc75ae&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fjabber%2Flogs%2Fteas%2F2020-04-23.html__%3B%21%21NEt6yMaO-gk%21WrvQt2QtERG2EFnE6CPHr8TzNjoFggUjNzUFGwWmlw2KiRSR42MiO2N4YtwhZJI%24> 

    ==

    More inline..

    <[email-masked] <mailto:[email-masked]> > wrote:

    Thanks!

    Dhruv

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 1 May 2020 17:20:36 +0100

John,

Despite what Reza says, I believe the term "transport slice" is used in 3GPP
documents. In fact, we see that he quoted Figure 4.7.1 from 3GPP TS 28.530
that uses the term.

Of course, it is possible that 3GPP used the term without defining it.

But you, John at least, will recall the "fun" we have when we try to share
terminology across SDOs where understanding is different, but no one notices
until we are a long way down the path. In the end we had to make RFC 4397 to
sort things out. Let's please not go there again. 

A

From: John E Drake <[email-masked]> 
Sent: 01 May 2020 17:12
To: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>; Eric Gray
<[email-masked]>; [email-masked]; 'John E Drake'
<jdrake=[email-masked]>; [email-masked]; [email-masked]
Subject: RE: [Teas] FW: The word "transport"

Hi,

That was not my understanding but if that's true then we are responsible for
developing a rather bad term.  As Adrian detailed in his original email,
'transport' is a term typically used by other standards bodies and that
within the IETF it carries a lot of baggage. 

Yours Irrespectively,

John

From: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]> 
Sent: Friday, May 1, 2020 11:56 AM
To: John E Drake <[email-masked]>; Eric Gray <[email-masked]>;
[email-masked]; 'John E Drake' <jdrake=[email-masked]>;
[email-masked]; [email-masked]
Cc: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
Subject: Re: [Teas] FW: The word "transport"

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

As far as I know there is not any SDO which defines "Transport slice" at
least at the time that we wrote the draft. If not so, please provide the
reference.

Reza

From: John E Drake <[email-masked] <mailto:[email-masked]> >
Date: Friday, May 1, 2020 at 11:52 AM
To: Reza Rokui <[email-masked] <mailto:[email-masked]> >, Eric
Gray <[email-masked] <mailto:[email-masked]> >,
"[email-masked] <mailto:[email-masked]> " <[email-masked]
<mailto:[email-masked]> >, 'John E Drake'
<jdrake=[email-masked]
<mailto:jdrake=[email-masked]> >, "[email-masked]
<mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >,
"[email-masked] <mailto:[email-masked]> " <[email-masked]
<mailto:[email-masked]> >
Subject: RE: [Teas] FW: The word "transport"

Hi,

Comment inline

Yours Irrespectively,

John

From: Teas-ns-dt <[email-masked]
<mailto:[email-masked]> > On Behalf Of Rokui, Reza (Nokia -
CA/Ottawa)
Sent: Friday, May 1, 2020 11:49 AM
To: Eric Gray <[email-masked] <mailto:[email-masked]> >;
[email-masked] <mailto:[email-masked]> ; 'John E Drake'
<jdrake=[email-masked]
<mailto:jdrake=[email-masked]> >; [email-masked]
<mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> 
Cc: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]
<mailto:[email-masked]> >
Subject: Re: [Teas-ns-dt] [Teas] FW: The word "transport"

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

Nokia Canada

T:  +1-613-784-1762

M: +1-613-979-6986

[email-masked] <mailto:[email-masked]> 

From: Eric Gray <[email-masked] <mailto:[email-masked]> >
Date: Friday, May 1, 2020 at 11:45 AM
To: Reza Rokui <[email-masked] <mailto:[email-masked]> >,
"[email-masked] <mailto:[email-masked]> " <[email-masked]
<mailto:[email-masked]> >, 'John E Drake'
<jdrake=[email-masked]
<mailto:jdrake=[email-masked]> >, "[email-masked]
<mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >,
"[email-masked] <mailto:[email-masked]> " <[email-masked]
<mailto:[email-masked]> >
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 <[email-masked]
<mailto:[email-masked]> > On Behalf Of Rokui, Reza (Nokia -
CA/Ottawa)
Sent: Friday, May 1, 2020 11:38 AM
To: [email-masked] <mailto:[email-masked]> ; 'John E Drake'
<jdrake=[email-masked]
<mailto:jdrake=[email-masked]> >; [email-masked]
<mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> 
Cc: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]
<mailto:[email-masked]> >
Subject: Re: [Teas-ns-dt] [Teas] FW: The word "transport"

Adrian,

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

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

 

Reza 

From: Adrian Farrel <[email-masked] <mailto:[email-masked]> >
Organization: Old Dog Consulting
Reply-To: "[email-masked] <mailto:[email-masked]> "
<[email-masked] <mailto:[email-masked]> >
Date: Friday, May 1, 2020 at 10:30 AM
To: Reza Rokui <[email-masked] <mailto:[email-masked]> >, 'John
E Drake' <jdrake=[email-masked]
<mailto:jdrake=[email-masked]> >, "[email-masked]
<mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >,
"[email-masked] <mailto:[email-masked]> " <[email-masked]
<mailto:[email-masked]> >
Subject: RE: [Teas] FW: The word "transport"

Hi Reza,

Cheers,

Adrian

From: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]
<mailto:[email-masked]> > 
Sent: 01 May 2020 15:13
To: [email-masked] <mailto:[email-masked]> ; 'John E Drake'
<jdrake=[email-masked]
<mailto:jdrake=[email-masked]> >; [email-masked]
<mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> 
Cc: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]
<mailto:[email-masked]> >
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.

Cheers,

Reza

From: Adrian Farrel <[email-masked] <mailto:[email-masked]> >
Organization: Old Dog Consulting
Reply-To: "[email-masked] <mailto:[email-masked]> "
<[email-masked] <mailto:[email-masked]> >
Date: Friday, May 1, 2020 at 5:23 AM
To: 'John E Drake' <jdrake=[email-masked]
<mailto:jdrake=[email-masked]> >, Reza Rokui
<[email-masked] <mailto:[email-masked]> >
Cc: "[email-masked] <mailto:[email-masked]> " <[email-masked]
<mailto:[email-masked]> >
Subject: RE: [Teas] FW: The word "transport"

A

From: Teas <[email-masked] <mailto:[email-masked]> > On Behalf
Of John E Drake
Sent: 30 April 2020 20:59
To: [email-masked] <mailto:[email-masked]> ; 'Rokui, Reza (Nokia -
CA/Ottawa)' <[email-masked] <mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> 
Subject: Re: [Teas] FW: The word "transport"

Hi,

Yours Irrespectively,

John

From: Teas <[email-masked] <mailto:[email-masked]> > On Behalf
Of Adrian Farrel
Sent: Thursday, April 30, 2020 3:32 PM
To: 'Rokui, Reza (Nokia - CA/Ottawa)' <[email-masked]
<mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> 
Subject: [Teas] FW: The word "transport"

Reza,

Additionally, you say.

Then.

[snip]

Best,

Adrian

All,

Cheers,

Reza

Hi all,

Reza

    Hi Reza,

    ==

 

] 

 

    Full logs - https://www.ietf.org/jabber/logs/teas/2020-04-23.html
<https://urldefense.com/v3/__https:/protect2.fireeye.com/v1/url?k=d4f6bc46-8
a560628-d4f6fcdd-86b1886cfa64-dd8e4ff74c5dda87&q=1&e=b15230b3-e6dc-4732-83e3
-00354fdc75ae&u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fwww.ietf.or
g*2Fjabber*2Flogs*2Fteas*2F2020-04-23.html__*3B*21*21NEt6yMaO-gk*21WrvQt2QtE
RG2EFnE6CPHr8TzNjoFggUjNzUFGwWmlw2KiRSR42MiO2N4YtwhZJI*24__;JSUlJSUlJSUlJSUl
JSUlJQ!!NEt6yMaO-gk!Ss83mQtEVqDRzJaflsjI0IuUspo1qru8LEP6d7EHAVACW_rPFMRhTgGz
cd8fvSc$> 

    ==

    More inline..

    <[email-masked] <mailto:[email-masked]> > wrote:

    Thanks!

    Dhruv

<mailto:[email-masked]> > wrote:

"transport".

transport

describe

---

From: Eric Gray <[email-masked]>
Date: Fri, 1 May 2020 16:23:39 +0000

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 <[email-masked]>
Sent: Friday, May 1, 2020 11:53 AM
To: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>; Eric Gray <[email-masked]>; [email-masked]; 'John E Drake' <jdrake=[email-masked]>; [email-masked]; [email-masked]
Subject: RE: [Teas] FW: The word "transport"
Importance: High

Hi,

Comment inline

Yours Irrespectively,

John

Reza Rokui, Ph.D.

Adrian,

Reza

Hi Reza,

Cheers,
Adrian

John and all,

Cheers,
Reza

A

Hi,

Yours Irrespectively,

John

Reza,

Additionally, you say...

Then...

[snip]

Best,
Adrian

All,

Cheers,
Reza

Hi all,

Reza

    Hi Reza,

    ==

] 

    Full logs - https://www.ietf.org/jabber/logs/teas/2020-04-23.html<https://protect2.fireeye.com/v1/url?k=ec407f85-b2e0c5eb-ec403f1e-86b1886cfa64-0a240ff7f16b3c02&q=1&e=3c877a55-7b82-4a55-844d-d1981954de61&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3Dd4f6bc46-8a560628-d4f6fcdd-86b1886cfa64-dd8e4ff74c5dda87%26q%3D1%26e%3Db15230b3-e6dc-4732-83e3-00354fdc75ae%26u%3Dhttps%2A3A%2A2F%2A2Furldefense.com%2A2Fv3%2A2F__https%2A3A%2A2Fwww.ietf.org%2A2Fjabber%2A2Flogs%2A2Fteas%2A2F2020-04-23.html__%2A3B%2A21%2A21NEt6yMaO-gk%2A21WrvQt2QtERG2EFnE6CPHr8TzNjoFggUjNzUFGwWmlw2KiRSR42MiO2N4YtwhZJI%2A24__%3BJSUlJSUlJSUlJSUlJSUlJQ%21%21NEt6yMaO-gk%21Ss83mQtEVqDRzJaflsjI0IuUspo1qru8LEP6d7EHAVACW_rPFMRhTgGzcd8fvSc%24>

    ==

    More inline..

    <[email-masked]<mailto:[email-masked]>> wrote:

    Thanks!

    Dhruv

---

From: Eric Gray <[email-masked]>
Date: Fri, 1 May 2020 16:29:48 +0000

Reza,

              This pretty much sums up why we have no business even mentioning “other slices” or – for that matter – any context in which someone would like to include some arbitrary definition of what end-to-end means outside of that which is in scope for the IETF.

--
Eric

John,
Please see inline.

Cheers,
Reza

Hi,

Comments inline.

Yours Irrespectively,

John

John and all,

Cheers,
Reza

A

Hi,

Yours Irrespectively,

John

Reza,

Additionally, you say…

Then…

[snip]

Best,
Adrian

All,

Cheers,
Reza

Hi all,

Reza

    Hi Reza,

    ==

] 

    Full logs - https://www.ietf.org/jabber/logs/teas/2020-04-23.html<https://protect2.fireeye.com/v1/url?k=76b30006-2813ba68-76b3409d-86b1886cfa64-400c255c349a4e99&q=1&e=cb08a6b8-65af-4861-b991-81c8c25d39e0&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fjabber%2Flogs%2Fteas%2F2020-04-23.html__%3B%21%21NEt6yMaO-gk%21WrvQt2QtERG2EFnE6CPHr8TzNjoFggUjNzUFGwWmlw2KiRSR42MiO2N4YtwhZJI%24>

    ==

    More inline..

    <[email-masked]<mailto:[email-masked]>> wrote:

    Thanks!

    Dhruv

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 1 May 2020 17:33:52 +0100

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 <[email-masked]> On Behalf Of Eric Gray
Sent: 01 May 2020 17:24
To: John E Drake <[email-masked]>; Rokui, Reza (Nokia - CA/Ottawa)
<[email-masked]>; [email-masked]; 'John E Drake'
<jdrake=[email-masked]>; [email-masked]; [email-masked]
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 <[email-masked] <mailto:[email-masked]> > 
Sent: Friday, May 1, 2020 11:53 AM
To: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]
<mailto:[email-masked]> >; Eric Gray <[email-masked]
<mailto:[email-masked]> >; [email-masked]
<mailto:[email-masked]> ; 'John E Drake'
<jdrake=[email-masked]
<mailto:jdrake=[email-masked]> >; [email-masked]
<mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> 
Subject: RE: [Teas] FW: The word "transport"
Importance: High

Hi,

Comment inline

Yours Irrespectively,

John

Reza Rokui, Ph.D.

Nokia Canada

T:  +1-613-784-1762

M: +1-613-979-6986

 

<mailto:[email-masked]> ; [email-masked]

Adrian,

 

Reza 

Reply-To: "adrian@olddog..co.uk <mailto:[email-masked]> "

Hi Reza,

Cheers,

Adrian

John and all,

Cheers,

Reza

Reply-To: "adrian@olddog..co.uk <mailto:[email-masked]> "

A

Hi,

Yours Irrespectively,

John

Reza,

Additionally, you say.

Then.

[snip]

Best,

Adrian

All,

Cheers,

Reza

Hi all,

Reza

    Hi Reza,

    ==

 

] 

 

    ==

    More inline..

    <[email-masked] <mailto:[email-masked]> > wrote:

    Thanks!

    Dhruv

<mailto:[email-masked]> > wrote:

"transport".

transport

describe

---

From: Eric Gray <[email-masked]>
Date: Fri, 1 May 2020 17:53:46 +0000

Yes, the word “Transport” does carry a lot of baggage – here in the IETF and elsewhere.  Think of it as “baggage transport.” 😊

But that has not stopped us before.  You no doubt know what the “TP” stands for in MPLS-TP.

We cannot rule out use of terms that are pretty much in line with their English language interpretation, just because they are used ambiguously in another context, or in a general context.

I think that – if we were just calling it “Transport” – this would be a serious problem.  But we do not (AFAIK) use this in any context where we do not combine it with “Slicing” and we define “Transport Slicing.” Which should be enough to avoid issues with the fact that the separate terms are ambiguous.

Provided, of course, that it is sufficiently clear what we mean by “Transport Slicing.”

Quite frankly, I find it surprising that we are debating the terminology choices that were made by a design team at the working group level.  It is one thing if it can be argued that the choices are counter-intuitive – though I can think of numerous cases where that has not carried much weight.

What makes sense to discuss at the WG level is whether we define the terminology with sufficient clarity, and then use the terminology as we defined it.

--
Eric

From: John E Drake <[email-masked]>
Sent: Friday, May 1, 2020 12:12 PM
To: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>; Eric Gray <[email-masked]>; [email-masked]; 'John E Drake' <jdrake=[email-masked]>; [email-masked]; [email-masked]
Subject: RE: [Teas] FW: The word "transport"
Importance: High

Hi,

That was not my understanding but if that’s true then we are responsible for developing a rather bad term.  As Adrian detailed in his original email, ‘transport’ is a term typically used by other standards bodies and that within the IETF it carries a lot of baggage.

Yours Irrespectively,

John

To: John E Drake <[email-masked]<mailto:[email-masked]>>; Eric Gray <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; 'John E Drake' <jdrake=[email-masked]<mailto:jdrake=[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Reza

Hi,

Comment inline

Yours Irrespectively,

John

Reza Rokui, Ph.D.

Adrian,

Reza

Hi Reza,

Cheers,
Adrian

John and all,

Cheers,
Reza

A

Hi,

Yours Irrespectively,

John

Reza,

Additionally, you say…

Then…

[snip]

Best,
Adrian

All,

Cheers,
Reza

Hi all,

Reza

    Hi Reza,

    ==

] 

    Full logs - https://www.ietf.org/jabber/logs/teas/2020-04-23.html<https://protect2.fireeye.com/v1/url?k=d85f249f-86ff9ef1-d85f6404-866038973a15-79480ef04dd7bd36&q=1&e=3885d79e-3893-4913-8634-bfacad730074&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3Dd4f6bc46-8a560628-d4f6fcdd-86b1886cfa64-dd8e4ff74c5dda87%26q%3D1%26e%3Db15230b3-e6dc-4732-83e3-00354fdc75ae%26u%3Dhttps%2A3A%2A2F%2A2Furldefense.com%2A2Fv3%2A2F__https%2A3A%2A2Fwww.ietf.org%2A2Fjabber%2A2Flogs%2A2Fteas%2A2F2020-04-23.html__%2A3B%2A21%2A21NEt6yMaO-gk%2A21WrvQt2QtERG2EFnE6CPHr8TzNjoFggUjNzUFGwWmlw2KiRSR42MiO2N4YtwhZJI%2A24__%3BJSUlJSUlJSUlJSUlJSUlJQ%21%21NEt6yMaO-gk%21Ss83mQtEVqDRzJaflsjI0IuUspo1qru8LEP6d7EHAVACW_rPFMRhTgGzcd8fvSc%24>

    ==

    More inline..

    <[email-masked]<mailto:[email-masked]>> wrote:

    Thanks!

    Dhruv

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Fri, 1 May 2020 18:13:12 +0000

Fully agree

De: Teas-ns-dt <[email-masked]> En nombre de Eric Gray
Enviado el: viernes, 1 de mayo de 2020 19:54
Para: John E Drake <[email-masked]>; Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>; [email-masked]; 'John E Drake' <jdrake=[email-masked]>; [email-masked]; [email-masked]
Asunto: Re: [Teas-ns-dt] [Teas] FW: The word "transport"

--
Eric

From: John E Drake <[email-masked]<mailto:[email-masked]>>
Sent: Friday, May 1, 2020 12:12 PM
To: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>; Eric Gray <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; 'John E Drake' <jdrake=[email-masked]<mailto:jdrake=[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Teas] FW: The word "transport"
Importance: High

Hi,

Yours Irrespectively,

John

Reza

Hi,

Comment inline

Yours Irrespectively,

John

Reza Rokui, Ph.D.

Adrian,

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)

Reza

Hi Reza,

Cheers,
Adrian

John and all,

Cheers,
Reza

A

Hi,

Yours Irrespectively,

John

Reza,

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.

Additionally, you say…

Then…

[snip]

Best,
Adrian

All,

Cheers,
Reza

Hi all,

Reza

    Hi Reza,

    ==

] 

    ==

    More inline..

    <[email-masked]<mailto:[email-masked]>> wrote:

    Thanks!

    Dhruv

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: Jeff Tantsura <[email-masked]>
Date: Sat, 2 May 2020 12:18:26 -0700

+1

Regards,
Jeff

> On May 1, 2020, at 11:13, LUIS MIGUEL CONTRERAS MURILLO <[email-masked]> wrote:
> 
> 
> Fully agree
>  
> [email-masked]
> 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.
>  
> From: Reza Rokui <[email-masked]>
> To: Dhruv Dhody <[email-masked]>, Jari Arkko <[email-masked]>, "[email-masked]" <[email-masked]>
> Cc: Reza Rokui <[email-masked]>
> On 2020-04-24, 1:31 AM, "Dhruv Dhody" <[email-masked]> wrote:
>  
>     Hi Reza,
>  
>     <[email-masked]> wrote:
>     >
>     > Hi Dhruv,
>     >
>     > On 2020-04-23, 12:35 PM, "Dhruv Dhody" <[email-masked]> wrote:
>     >
>     >     Hi,
>     >
> Teas-ns-dt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas-ns-dt

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 2 May 2020 21:10:04 +0100

Eric,

> Quite frankly, I find it surprising that we are debating the

> terminology choices that were made by a design team at

> the working group level.  It is one thing if it can be argued

> that the choices are counter-intuitive – though I can think

> of numerous cases where that has not carried much weight.

Sorry. Did you hope that the WG would say, “Thanks DT, here is your rubber stamp”?

Or maybe you are saying that the DT hasn’t completed its work and the discussion in the WG is premature.

But I thought that the docs had been brought to the WG for discussion. Pardon me if I got that wrong.

Adrian

---

From: Eric Gray <[email-masked]>
Date: Mon, 4 May 2020 13:05:48 +0000

Hi, Adrian.

Of course I don’t expect the WG to blindly accept what we propose.

But the tone of the discussion about terminology – particularly in this thread – has become not so much “what do you mean” or “why did you choose that” and more along the lines of “I don’t like that choice, make another.”

When we try to answer the question we expect – i.e. – why choose this particular word (“transport”), it’s as if we’re talking to the wind.

--
Eric

From: Adrian Farrel <[email-masked]>
Sent: Saturday, May 2, 2020 4:10 PM
To: Eric Gray <[email-masked]>; [email-masked]
Subject: RE: [Teas] FW: The word "transport"
Importance: High

Eric,

Adrian

---

From: Eric Gray <[email-masked]>
Date: Tue, 5 May 2020 18:58:54 +0000

Adrian,

This is an obvious segue, quite possibly into an equally obvious rat-hole.

Nobody is (as far as I am aware) arguing that we cannot use existing IETF technology to “slice” IP networks using existing technology, for carrying arbitrary data (including control and management data) in packetized form.

Some folks have stated that current technology may not be enough.  That remains to be seen.  We need to get a much better understanding of exactly what is required in order to make a decision on this, both in the short and long term.

Another group (probably containing a subset of the same people) are arguing that we will likely need a high-level model for creating, maintaining, monitoring, modifying, and removing a “service” as defined at that level.  The intent is that this work would take place at a level of abstraction where it is independent of specific technologies that may be used within the service, to deliver a requested service at that same level of abstraction.

Actual work to define this model was not an objective (at least initially – and I believe – so far) for the design team, although some individual work has begun.

We call this “service abstraction” a “transport slice service.”

Implicit in this argument is a requirement for a function or component that can accept the information in this model and translate it into specific control and management instructions required to make the underlying network behave in the ways requested for the services to be provided.

We call this function/component a “transport slice controller (TSC).”

As part of this controller (or control function) an interface is a need to define how these abstract service requests are handled.

We call this interface the TSC’s Northbound Interface (NBI).

There is no current intent (at least on the part of most of the design team) to standardize this entity or it’s interactions with other entities in any network application, other than via this NBI.

Other terminology is included to allow for logical descriptions of the required interaction between an arbitrary implementation of a TSC and the underlying network (which it is used to control) in providing any arbitrary set of transport slice services.

Example of this include the Southbound Interface (SBI), and the Network Controller – which may or may not exist in every instance, especially if the TSC itself is not to be standardized, or if specific network controllers are not needed in some instances.

This is really not the sort of rocket surgery that warrants this much confusion, uncertainty and doubt.

--
Eric

From: Adrian Farrel <[email-masked]>
Sent: Friday, May 1, 2020 12:13 PM
To: Eric Gray <[email-masked]>; 'Rokui, Reza (Nokia - CA/Ottawa)' <[email-masked]>; 'John E Drake' <jdrake=[email-masked]>; [email-masked]
Subject: RE: [Teas] FW: The word "transport"
Importance: High

Eric,

Best,
Adrian

From: Eric Gray <[email-masked]<mailto:[email-masked]>>
Sent: 01 May 2020 16:46
To: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; 'John E Drake' <jdrake=[email-masked]<mailto:jdrake=[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Teas] FW: The word "transport"

Adrian,

Reza

Hi Reza,

Cheers,
Adrian

John and all,

Cheers,
Reza

A

Hi,

Yours Irrespectively,

John

Reza,

Additionally, you say…

Then…

[snip]

Best,
Adrian

All,

Cheers,
Reza

Hi all,

Reza

    Hi Reza,

    ==

] 

    ==

    More inline..

    <[email-masked]<mailto:[email-masked]>> wrote:

    Thanks!

    Dhruv

---

From: Young Lee <[email-masked]>
Date: Wed, 6 May 2020 14:35:48 +0900

Hi Eric,

RFC 8453 has defined Virtual Network Service (VNS) Model which seems to be
similar or identical to what you are describing as "service abstract" or
"transport service slice".

RFC 8453 has the following defintlition:

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.

The above definition of TE network slicing does not necessarily preclude IP
technology as potential transport underlay. I believe IP technology can
realize TE network slicing with some enhancement/support.

Thanks.
Young (waking up after a long hibernation)

2020년 5월 6일 (수) 오전 3:59, Eric Gray <eric.gray=[email-masked]>님이
작성:

> Nobody is (as far as I am aware) arguing that we cannot use existing IETF
> technology to “slice” IP networks using existing technology, for carrying
> arbitrary data (including control and management data) in packetized form.
>
>
>
> Some folks have stated that current technology may not be enough.  That
> remains to be seen.  We need to get a much better understanding of exactly
> what is required in order to make a decision on this, both in the short and
> long term.
>
>
>
> Another group (probably containing a subset of the same people) are
> arguing that we will likely need a high-level model for creating,
> maintaining, monitoring, modifying, and removing a “service” as defined at
> that level.  The intent is that this work would take place at a level of
> abstraction where it is independent of specific technologies that may be
> used within the service, to deliver a requested service at that same level
> of abstraction.
>
>
>
> Actual work to define this model was not an objective (at least initially
> – and I believe – so far) for the design team, although some individual
> work has begun.
>
>
>
> Implicit in this argument is a requirement for a function or component
> that can accept the information in this model and translate it into
> specific control and management instructions required to make the
> underlying network behave in the ways requested for the services to be
> provided.
>
>
>
> As part of this controller (or control function) an interface is a need to
> define how these abstract service requests are handled.
>
>
>
> There is no current intent (at least on the part of most of the design
> team) to standardize this entity or it’s interactions with other entities
> in any network application, other than via this NBI.
>
>
>
> Other terminology is included to allow for logical descriptions of the
> required interaction between an arbitrary implementation of a TSC and the
> underlying network (which it is used to control) in providing any arbitrary
> set of transport slice services.
>
>
>
> Example of this include the Southbound Interface (SBI), and the Network
> Controller – which may or may not exist in every instance, especially if
> the TSC itself is not to be standardized, or if specific network
> controllers are not needed in some instances.
>
>
>
> *From:* Adrian Farrel <[email-masked]>
> *Sent:* Friday, May 1, 2020 12:13 PM
> *To:* Eric Gray <[email-masked]>; 'Rokui, Reza (Nokia -
> CA/Ottawa)' <[email-masked]>; 'John E Drake' <jdrake=
> [email-masked]>; [email-masked]
> *Subject:* RE: [Teas] FW: The word "transport"
> *Importance:* High
>
>
>
> Eric,
>
>
>
> I appreciate your attempt here, but I see know reason why we would not
> slice a sub-IP network utilising the technology that we have developed in
> the IETF for control and management of sub-IP networks.
>
>
>
> In fact, maybe we should not try to use this thread to define the purpose
> and scope of the IETF 😊 The creation of CCAMP was an old argument and
> results in the IP-based control of non-packet networks being in scope.
>
>
>
> Best,
>
> Adrian
>
>
>
> *From:* Eric Gray <[email-masked]>
> *Sent:* 01 May 2020 16:46
> *To:* Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>;
> *Subject:* RE: [Teas] FW: The word "transport"
>
>
>
> The IETF deals with “packetized” (more specifically, where packetization
> Here you can replace transport with “carrying” – but this is essentially
> the standard English meaning of transport.
>
>
>
> *From:* Teas-ns-dt <[email-masked]> *On Behalf Of *Rokui,
> Reza (Nokia - CA/Ottawa)
> *Sent:* Friday, May 1, 2020 11:38 AM
> *To:* [email-masked]; 'John E Drake' <
> jdrake=[email-masked]>; [email-masked]; [email-masked]
> *Cc:* Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
> *Subject:* Re: [Teas-ns-dt] [Teas] FW: The word "transport"
>
>
>
> Adrian,
>
>
>
> which is part of an E2E network slice and “Other slices” are outside scope
> of IETF.
>
> *Reza *
> *From: *Adrian Farrel <[email-masked]>
> *Organization: *Old Dog Consulting
> *Reply-To: *"[email-masked]" <[email-masked]>
> *Date: *Friday, May 1, 2020 at 10:30 AM
> *To: *Reza Rokui <[email-masked]>, 'John E Drake' <
> jdrake=[email-masked]>, "[email-masked]" <[email-masked]>, "
> [email-masked]" <[email-masked]>
> *Subject: *RE: [Teas] FW: The word "transport"
>
>
>
> Hi Reza,
>
>
>
> *From:* Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
> *Sent:* 01 May 2020 15:13
> *To:* [email-masked]; 'John E Drake' <
> jdrake=[email-masked]>; [email-masked]; [email-masked]
> *Cc:* Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
> *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.*
>
>
>
> *From: *Adrian Farrel <[email-masked]>
> *Organization: *Old Dog Consulting
> *Reply-To: *"[email-masked]" <[email-masked]>
> *Date: *Friday, May 1, 2020 at 5:23 AM
> *To: *'John E Drake' <jdrake=[email-masked]>, Reza Rokui <
> [email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *RE: [Teas] FW: The word "transport"
>
>
>
> *From:* Teas <[email-masked]> *On Behalf Of *John E Drake
> *Sent:* 30 April 2020 20:59
> *To:* [email-masked]; 'Rokui, Reza (Nokia - CA/Ottawa)' <
> [email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [Teas] FW: The word "transport"
>
>
>
> Hi,
>
>
>
> How about ‘underlay network slice’?  It’s describing exactly what we are
> *From:* Teas <[email-masked]> *On Behalf Of *Adrian Farrel
> *Sent:* Thursday, April 30, 2020 3:32 PM
> *To:* 'Rokui, Reza (Nokia - CA/Ottawa)' <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* [Teas] FW: The word "transport"
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Reza,
>
>
>
> I appreciate and understand the way that 3GPP use the term “transport”. It
> (such as an IP network) counts as “transport”.
>
>
>
>    - 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
> In the ACTN work, we moved from ‘transport’ to ‘TE’ recognising that ACTN
> 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 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…
>
> …which is fine by me since I am not (here) talking about solutions but
> … 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...
>
> …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]
>
> …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 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 <[email-masked]> *On Behalf Of *Rokui,
> Reza (Nokia - CA/Ottawa)
> *Sent:* 30 April 2020 16:23
> *To:* [email-masked]; [email-masked]
> *Cc:* Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
> *Subject:* [Teas-ns-dt] FW: The word "transport"
>
>
>
> All,
>
>
>
> *From: *Reza Rokui <[email-masked]>
> *Date: *Saturday, April 25, 2020 at 11:37 PM
> *To: *Dhruv Dhody <[email-masked]>, Jari Arkko <[email-masked]>,
> "[email-masked]" <
> [email-masked]>
> *Cc: *Reza Rokui <[email-masked]>
> *Subject: *Re: The word "transport"
>
>
>
> Hi all,
>
>
>
> 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.
>
> realized “Transport Slices”. Please see draft for more info.
>
>
>
> various “Transport slices”.
>
> [Reza]  Note that 3GPP used the term “slice subnet” when describing it in
> definition and using term “Transport Subnet” is completely misleading. So,
> 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.
>
> <https://protect2.fireeye.com/v1/url?k=d4f6bc46-8a560628-d4f6fcdd-86b1886cfa64-dd8e4ff74c5dda87&q=1&e=b15230b3-e6dc-4732-83e3-00354fdc75ae&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fjabber%2Flogs%2Fteas%2F2020-04-23.html__%3B%21%21NEt6yMaO-gk%21WrvQt2QtERG2EFnE6CPHr8TzNjoFggUjNzUFGwWmlw2KiRSR42MiO2N4YtwhZJI%24>
>
>
>
>     ==
>
>
>
>     More inline..
>
>
>
> "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.
>
>     >
>
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 6 May 2020 23:35:52 +0100

> This is an obvious segue, quite possibly into an equally obvious rat-hole.

So, I should resist the lure of your rat-hole?

But it smells of such wonderful cheese.

> Nobody is (as far as I am aware) arguing that we cannot use existing

> IETF technology to “slice” IP networks using existing technology, for

> carrying arbitrary data (including control and management data) in

> packetized form.

Indeed.

And the point I was making is that we can also use IETF technologies to slice networks that carry arbitrary data that t not in a packetized form (as far as we are aware).

> Some folks have stated that current technology may not be enough.

> That remains to be seen.  We need to get a much better understanding

> of exactly what is required in order to make a decision on this, both in

> the short and long term.

Yes. I would hope we can focus on the service characteristics before working on protocol solutions.

> Another group (probably containing a subset of the same people) 

> are arguing that we will likely need a high-level model for creating,

> maintaining, monitoring, modifying, and removing a “service” as

> defined at that level.  The intent is that this work would take place

> at a level of abstraction where it is independent of specific

> technologies that may be used within the service, to deliver a

> requested service at that same level of abstraction. 

Sounds good to me. But then I have a history of working with “service level YANG models.”

> Actual work to define this model was not an objective (at least

> initially – and I believe – so far) for the design team, although

> some individual work has begun.

Sure. The DT’s scope and charter are quite clear. But, of course, anyone is free to work on anything and post any draft.

> We call this “service abstraction” a “transport slice service.” 

Well, why not?

Except, of course, for thinking that we should simply call this a “network slice service” because, after all, we are slicing the network.

> Implicit in this argument is a requirement for a function or

> component that can accept the information in this model

> and translate it into specific control and management

> instructions required to make the underlying network

> behave in the ways requested for the services to be

> We call this function/component a “transport slice controller

> (TSC).”  

Is that an abstract function? I like abstract functions. Architectures should have lots of them.

Of course, you can realise an abstract function by making an implementation. 

> As part of this controller (or control function) an interface is a

> need to define how these abstract service requests are handled.  

> There is no current intent (at least on the part of most of the

> design team) to standardize this entity or it’s interactions with

> other entities in any network application, other than via this NBI.

So, this is both an abstract interface and a protocol specification. That’s OK.

And if other protocols are specified to satisfy the abstract interface that would also be fine (although we tend to like to have just one solution for any one problem).

> Other terminology is included to allow for logical descriptions of

> the required interaction between an arbitrary implementation

> of a TSC and the underlying network (which it is used to control)

> in providing any arbitrary set of transport slice services.

s/which it is used to control/which it controls/

> Example of this include the Southbound Interface (SBI), and

> the Network Controller – which may or may not exist in 

> every instance, especially if the TSC itself is not to be

> standardized, or if specific network controllers are not

> needed in some instances.

The TSC would never be standardised in the IETF, I think. We don’t standardize components beyond architectural work. 

> This is really not the sort of rocket surgery that warrants

> this much confusion, uncertainty and doubt.

Nevertheless, I am always grateful to have my doubts assuaged, my uncertainty clarified, my confusion swept away, and my rockets surged.

But wait! How did we get here?

Best,

Adrian

From: Adrian Farrel <[email-masked] <mailto:[email-masked]> > 
Sent: Friday, May 1, 2020 12:13 PM
To: Eric Gray <[email-masked] <mailto:[email-masked]> >; 'Rokui, Reza (Nokia - CA/Ottawa)' <[email-masked] <mailto:[email-masked]> >; 'John E Drake' <jdrake=[email-masked] <mailto:jdrake=[email-masked]> >; [email-masked] <mailto:[email-masked]> 
Subject: RE: [Teas] FW: The word "transport"
Importance: High

Eric,

I appreciate your attempt here, but I see no reason why we would not slice a sub-IP network utilising the technology that we have developed in the IETF for control and management of sub-IP networks.

Best,

Adrian

From: Eric Gray <[email-masked] <mailto:[email-masked]> > 
Sent: 01 May 2020 16:46
To: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> ; 'John E Drake' <jdrake=[email-masked] <mailto:jdrake=[email-masked]> >; [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> 
Subject: RE: [Teas] FW: The word "transport"

Adrian,

 

Reza 

Hi Reza,

Cheers,

Adrian

John and all,

Cheers,

Reza

A

Hi,

Yours Irrespectively,

John

Reza,

Additionally, you say…

Then…

[snip]

Best,

Adrian

All,

Cheers,

Reza

Hi all,

Reza

    Hi Reza,

    ==

 

] 

 

    ==

    More inline..

    <[email-masked] <mailto:[email-masked]> > wrote:

    Thanks!

    Dhruv

---

From: Eric Gray <[email-masked]>
Date: Tue, 12 May 2020 21:52:51 +0000

Adrian,

Not _my_ rat hole.

--
Eric

From: Adrian Farrel <[email-masked]>
Sent: Wednesday, May 6, 2020 6:36 PM
To: Eric Gray <[email-masked]>
Cc: 'Rokui, Reza (Nokia - CA/Ottawa)' <[email-masked]>; 'John E Drake' <jdrake=[email-masked]>; [email-masked]
Subject: RE: [Teas] FW: The word "transport"
Importance: High

Indeed.

Well, why not?

Best,
Adrian

From: Adrian Farrel <[email-masked]<mailto:[email-masked]>>
Sent: Friday, May 1, 2020 12:13 PM
To: Eric Gray <[email-masked]<mailto:[email-masked]>>; 'Rokui, Reza (Nokia - CA/Ottawa)' <[email-masked]<mailto:[email-masked]>>; 'John E Drake' <jdrake=[email-masked]<mailto:jdrake=[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Teas] FW: The word "transport"
Importance: High

Eric,

Best,
Adrian

Adrian,

Reza

Hi Reza,

Cheers,
Adrian

John and all,

Cheers,
Reza

A

Hi,

Yours Irrespectively,

John

Reza,

Additionally, you say…

Then…

[snip]

Best,
Adrian

All,

Cheers,
Reza

Hi all,

Reza

    Hi Reza,

    ==

] 

    ==

    More inline..

    <[email-masked]<mailto:[email-masked]>> wrote:

    Thanks!

    Dhruv