Subject: [Teas] TS and VPN (was RE: FW: The word "transport")

From: Italo Busi <[email-masked]>
Date: Mon, 4 May 2020 16:36:22 +0000

I think that Adrian has spotted another area of confusion in the current work:

Actually, I think you would do well to distinguish between VPN as a service and the technologies used to realise a VPN.

I agree with Adrian’s point and I think the documents needs more clarity about this distinction

For example, section 1 of draft-nsdt-teas-transport-slice-definition-02 mentions “VPNs with specific characteristics” as an example of a service which could benefit from TS, while in section 5 VPN is mentioned as a technology-specific realization of a TS …

My understanding is that the former use of the term VPN is meant as “VPN as a service” while the latter is meant as “the technologies used to realise a VPN”

If my understanding is correct, it is not clear why at the TS NBI the L2SM/L3SM YANG models, which are defined to request a “VPN as a service”, are considered instead of the L2NM/L3NM YANG models, which are defined to configure “the technologies used to realise a VPN” …

Could you please clarify?

Thanks, Italo

From: Adrian Farrel [mailto:[email-masked]]
Sent: giovedì 30 aprile 2020 21:32
To: 'Rokui, Reza (Nokia - CA/Ottawa)' <[email-masked]>
Cc: [email-masked]
Subject: [Teas] FW: The word "transport"

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

    ==

    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

---

From: Italo Busi <[email-masked]>
Date: Mon, 4 May 2020 16:50:40 +0000

Ops, sorry, there was  a typo in my previous mail:

If my understanding is correct, it is not clear why at the TS SBI the L2SM/L3SM YANG models, which are defined to request a “VPN as a service”, are considered instead of the L2NM/L3NM YANG models, which are defined to configure “the technologies used to realise a VPN” …

Thanks, Italo

From: Italo Busi [mailto:[email-masked]]
Sent: lunedì 4 maggio 2020 18:36
To: [email-masked]
Cc: [email-masked]; 'Rokui, Reza (Nokia - CA/Ottawa)' <[email-masked]>
Subject: [Teas] TS and VPN (was RE: FW: The word "transport")

Thanks, Italo

From: Adrian Farrel [mailto:[email-masked]]
Sent: giovedì 30 aprile 2020 21:32
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,

    ==

] 

    ==

    More inline..

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

    Thanks!

    Dhruv

---

From: Kiran Makhijani <[email-masked]>
Date: Mon, 4 May 2020 17:17:39 +0000

Hi Italo,

My understanding is that the former use of the term VPN is meant as “VPN as a service” while the latter is meant as “the technologies used to realize a VPN”
^^^^
That’s right. In the beginning, we consider ‘VPN+ some resource guarantees’ as a use case. In section 1 we aren’t concerned how that VPN will be realized (L2 or L3 way). In section 5, we are actually saying that well-known models for L2VPN, L3VPN (whether service or underlay specific) are means to realize transport slice. By associating L2- or L3- usage becomes technology-specific. In section 5, we don’t use VPN generically.
-Kiran

From: Teas <[email-masked]> On Behalf Of Italo Busi
Sent: Monday, May 4, 2020 9:36 AM
To: [email-masked]
Cc: [email-masked]; 'Rokui, Reza (Nokia - CA/Ottawa)' <[email-masked]>
Subject: [Teas] TS and VPN (was RE: FW: The word "transport")

Thanks, Italo

Reza,

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

    ==

] 

    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%7C8f6662522d2245d355b608d7f049fbf4%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637242072876400040&sdata=XnErhWSbnxSLOg5TrgDcai8mqVjXDV6LUu6KiorGMSk%3D&reserved=0>

    ==

    More inline..

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

    Thanks!

    Dhruv

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 4 May 2020 20:57:00 +0100

That’s good progress, thanks Kiran.

It’s funny, however, that when looking at *services* the NS work considers VPN+ as a use case of network slicing, but the VPN+ work considers network slicing to be an example of VPN+. I wonder if that might tell us something.

Possibly, if A is a subset of B, and B is a subset of A, then A is equal to B.

Best,

Adrian

From: Kiran Makhijani <[email-masked]> 
Sent: 04 May 2020 18:18
To: Italo Busi <[email-masked]>; [email-masked]
Cc: [email-masked]; 'Rokui, Reza (Nokia - CA/Ottawa)' <[email-masked]>
Subject: RE: [Teas] TS and VPN (was RE: FW: The word "transport")

Hi Italo, 

^^^^

-Kiran

From: Teas <[email-masked] <mailto:[email-masked]> > On Behalf Of Italo Busi
Sent: Monday, May 4, 2020 9:36 AM
To: [email-masked] <mailto:[email-masked]> 
Cc: [email-masked] <mailto:[email-masked]> ; 'Rokui, Reza (Nokia - CA/Ottawa)' <[email-masked] <mailto:[email-masked]> >
Subject: [Teas] TS and VPN (was RE: FW: The word "transport")

 

Thanks, Italo

From: Adrian Farrel [mailto:[email-masked]] 
Sent: giovedì 30 aprile 2020 21:32
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

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,

    ==

 

] 

 

    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%7C8f6662522d2245d355b608d7f049fbf4%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637242072876400040&sdata=XnErhWSbnxSLOg5TrgDcai8mqVjXDV6LUu6KiorGMSk%3D&reserved=0> 

    ==

    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: Italo Busi <[email-masked]>
Date: Mon, 4 May 2020 20:53:58 +0000

Hi Kiran,

Thanks for your explanation

I am still confused by the service versus underlay versus technology specific

A service defined from the viewpoint of the customer is usually not underlay specific since it is possible to implement the same service using different underlay technologies

However, how is it possible to define a service without specifying the type the traffic (e.g., Ethernet or IP) that is exchanged at the UNI and over the VPN?

Italo

From: Kiran Makhijani [mailto:[email-masked]]
Sent: lunedì 4 maggio 2020 19:18
To: Italo Busi <[email-masked]>; [email-masked]
Cc: [email-masked]; 'Rokui, Reza (Nokia - CA/Ottawa)' <[email-masked]>
Subject: RE: [Teas] TS and VPN (was RE: FW: The word "transport")

Hi Italo,

From: Teas <[email-masked]<mailto:[email-masked]>> On Behalf Of Italo Busi
Sent: Monday, May 4, 2020 9:36 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; 'Rokui, Reza (Nokia - CA/Ottawa)' <[email-masked]<mailto:[email-masked]>>
Subject: [Teas] TS and VPN (was RE: FW: The word "transport")

Thanks, Italo

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: Kiran Makhijani <[email-masked]>
Date: Mon, 4 May 2020 22:29:48 +0000

Hi Adrian,
Maybe not.:-( . my “+” was “plus”, I meant to say – VPN + “some guarantees of resources”. The use case we had in mind was an enterprise asking a transport slice to connect multiple sites with certain low latency or specified bandwidth.

In the definitions document, we wish to establish transport slice as an independent construct.  The commonalities and overlap between enhanced VPN and transport slices are covered in the TS framework.
I see realization of transport slices could be done with VPN+ and if Realization of A != A , then A != B.

-Kiran

From: Adrian Farrel <[email-masked]>
Sent: Monday, May 4, 2020 12:57 PM
To: Kiran Makhijani <[email-masked]>; 'Italo Busi' <[email-masked]>; [email-masked]
Cc: 'Rokui, Reza (Nokia - CA/Ottawa)' <[email-masked]>
Subject: RE: [Teas] TS and VPN (was RE: FW: The word "transport")

Best,
Adrian

From: Kiran Makhijani <[email-masked]<mailto:[email-masked]>>
Sent: 04 May 2020 18:18
To: Italo Busi <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; 'Rokui, Reza (Nokia - CA/Ottawa)' <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Teas] TS and VPN (was RE: FW: The word "transport")

Hi Italo,

Thanks, Italo

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://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%7Cb5b3bcb0834146da054b08d7f065559d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637242190357214354&sdata=2KYedhq3K7qd9ikvN2XrlrENzKM4yCshmDXHQ6wu15Q%3D&reserved=0>

    ==

    More inline..

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

    Thanks!

    Dhruv

---

From: Kiran Makhijani <[email-masked]>
Date: Tue, 5 May 2020 00:48:45 +0000

Hi Italo,
Please note that the definitions document  wants to develop an independent concept of transport slices. It says nothing about either of the 2 – that transport slice is a service or is a technology.

However, how is it possible to define a service without specifying the type the traffic (e.g., Ethernet or IP) that is exchanged at the UNI and over the VPN?
^^^^
Short answer is - this will happen through mappings when actual realization of TS happens, the SBI will use which ever technology specific data model is provided by the operator (L3VPN or L3SM).  This will become clearer in NBI data model.

-Kiran

From: Italo Busi <[email-masked]>
Sent: Monday, May 4, 2020 1:54 PM
To: Kiran Makhijani <[email-masked]>; [email-masked]
Cc: [email-masked]; 'Rokui, Reza (Nokia - CA/Ottawa)' <[email-masked]>
Subject: RE: [Teas] TS and VPN (was RE: FW: The word "transport")

Hi Kiran,

Italo

Hi Italo,

Thanks, Italo

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://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%7Cbd054d2c1d4147fed07108d7f06d45e4%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637242224461249705&sdata=Lz1kTX4f8wqPNMpX5bQ5NILa5A0%2B%2Bs5N57Gm6fazzkg%3D&reserved=0>

    ==

    More inline..

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

    Thanks!

    Dhruv

---

From: Italo Busi <[email-masked]>
Date: Tue, 5 May 2020 07:10:37 +0000

I am sorry but I am still very confused

Please consider the following text from RFC8309:

                                                    Except where
         specific technology details are directly pertinent to the
         customer (such as encapsulations or mechanisms applied on
         access links), customer service models are technology agnostic
         so that the customer does not have influence over or knowledge
         of how the network operator engineers the service.

Why this is not applicable to TS as well?

Italo

Sent: martedì 5 maggio 2020 02:49

Hi Italo,

-Kiran

From: Italo Busi <[email-masked]<mailto:[email-masked]>>
Sent: Monday, May 4, 2020 1:54 PM
To: Kiran Makhijani <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; 'Rokui, Reza (Nokia - CA/Ottawa)' <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Teas] TS and VPN (was RE: FW: The word "transport")

Hi Kiran,

Italo

Hi Italo,

Thanks, Italo

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: "Belotti, Sergio (Nokia - IT/Vimercate)" <[email-masked]>
Date: Tue, 5 May 2020 08:31:29 +0000

@Italo Busi<mailto:[email-masked]>  Hi Italo , many thanks to point out this text from RFC 8309. More in session 7.1 , RFC 8309 try again to clarify the agnostic characteristic of a customer service model as LxSM vs. what could technology specific (e.g. encapsulation) from customer prospective.

@Kiran Makhijani<mailto:[email-masked]> Hi Kiran, I think your explanation does not provide the clarity required : “the SBI will use which ever technology specific data model is provided by the operator (L3VPN or L3SM)”

L3VPN or L3SM are not the same thing so the “or” is creating confusion.
I think we need to clarify better what is required at NBI of TSC and what at SBI, taking into account in my view  that models being considered as “customer service model” like e.g. LxSM should not be at SBI .
Moreover, clarifying the context of SBI and NBI interfaces would also help to describe more specifically the real functionality of TSC.

Thanks
Sergio

From: Teas <[email-masked]> On Behalf Of Italo Busi
Sent: Tuesday, May 5, 2020 9:11 AM
To: Kiran Makhijani <[email-masked]>; [email-masked]
Cc: [email-masked]; Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
Subject: Re: [Teas] TS and VPN (was RE: FW: The word "transport")

                                                    Except where

Italo

Hi Italo,

-Kiran

Hi Kiran,

Italo

Hi Italo,

Thanks, Italo

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: Kiran Makhijani <[email-masked]>
Date: Tue, 5 May 2020 15:05:00 +0000

Hi Italo, Sergio,
Your explanation helped. If “customer service models” should not be at SBI is a sufficient explanation then it makes sense to maintain that separation.
Are there any other side-effects of this on NBI or framework? Lets check in nsdt, if no one disagrees, we can exclude LxSMs with 8309 reference.
Thanks
Kiran

From: Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]>
Sent: Tuesday, May 5, 2020 1:31 AM
To: Italo Busi <[email-masked]>; Kiran Makhijani <[email-masked]>; [email-masked]
Cc: [email-masked]; Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
Subject: RE: [Teas] TS and VPN (was RE: FW: The word "transport")

Thanks
Sergio

Cc: [email-masked]<mailto:[email-masked]>; Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>

                                                    Except where

Italo

Hi Italo,

-Kiran

Hi Kiran,

Italo

Hi Italo,

Thanks, Italo

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://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%7Cfb3ff222be214d1be9b808d7f0ceb7bb%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637242642968275741&sdata=7xnTpsT1IY833RRzHnovscncirjXW6E3UG51lH%2F2C9o%3D&reserved=0>

    ==

    More inline..

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

    Thanks!

    Dhruv

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Tue, 5 May 2020 17:27:26 +0000

HI all,

According to the mapping in the framework document between TSC and ACTN (section 4 of draft-nsdt-teas-ns-framework-02) the TSC SBI could be mapped to the CMI in ACTN architecture. Thus customer service models such as L3SM would fit in the SBI of TSC.

If that is not the case, then the mapping is not correct or at least inconsistent.

Best regards

Luis

De: Teas <[email-masked]> En nombre de Kiran Makhijani
Enviado el: martes, 5 de mayo de 2020 17:05
Para: Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]>; Italo Busi <[email-masked]>; [email-masked]
CC: [email-masked]; Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
Asunto: Re: [Teas] TS and VPN (was RE: FW: The word "transport")

Hi Italo, Sergio,

From: Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, May 5, 2020 1:31 AM
To: Italo Busi <[email-masked]<mailto:[email-masked]>>; Kiran Makhijani <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Teas] TS and VPN (was RE: FW: The word "transport")

Thanks
Sergio

                                                    Except where

Italo

Hi Italo,

-Kiran

Hi Kiran,

Italo

Hi Italo,

Thanks, Italo

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

________________________________

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: "Belotti, Sergio (Nokia - IT/Vimercate)" <[email-masked]>
Date: Tue, 5 May 2020 17:45:13 +0000

Hi Luis,
yes correct but I think here it’s like the chicken and the egg: based on what was written about the usage of LxSM at SBI, obviously, Dhruv made, correctly,  the mapping of ACTN starting from CMI at the level of SBI in slicing context.

Thanks
Sergio

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Sent: Tuesday, May 5, 2020 7:27 PM
To: Kiran Makhijani <[email-masked]>; Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]>; Italo Busi <[email-masked]>; [email-masked]
Cc: [email-masked]; Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
Subject: RE: [Teas] TS and VPN (was RE: FW: The word "transport")

HI all,

Best regards

Luis

De: Teas <[email-masked]<mailto:[email-masked]>> En nombre de Kiran Makhijani
Enviado el: martes, 5 de mayo de 2020 17:05
Para: Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]<mailto:[email-masked]>>; Italo Busi <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
CC: [email-masked]<mailto:[email-masked]>; Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>
Asunto: Re: [Teas] TS and VPN (was RE: FW: The word "transport")

Hi Italo, Sergio,

Thanks
Sergio

                                                    Except where

Italo

Hi Italo,

-Kiran

Hi Kiran,

Italo

Hi Italo,

Thanks, Italo

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: "Luis M. Contreras" <[email-masked]>
Date: Tue, 5 May 2020 20:02:32 +0200

Ok, understood.

By the way, according to the figure (left hand side) TSC would instruct
some network controllers, so L3/L2 service models could be expected at that
level, right?

This is something to clarify to properly defining the SBI as you commented.

Thanks

Luis

El mar., 5 may. 2020 a las 19:45, Belotti, Sergio (Nokia - IT/Vimercate) (<
[email-masked]>) escribió:

> Hi Luis,
>
> yes correct but I think here it’s like the chicken and the egg: based on
> what was written about the usage of LxSM at SBI, obviously, Dhruv made,
> correctly,  the mapping of ACTN starting from CMI at the level of SBI in
> slicing context.
>
>
>
> Thanks
>
> Sergio
>
>
>
> *From:* LUIS MIGUEL CONTRERAS MURILLO <
> [email-masked]>
> *Sent:* Tuesday, May 5, 2020 7:27 PM
> *To:* Kiran Makhijani <[email-masked]>; Belotti, Sergio (Nokia -
> IT/Vimercate) <[email-masked]>; Italo Busi <
> [email-masked]>; [email-masked]
> *Cc:* [email-masked]; Rokui, Reza (Nokia - CA/Ottawa) <
> [email-masked]>
> *Subject:* RE: [Teas] TS and VPN (was RE: FW: The word "transport")
>
>
>
> HI all,
>
>
>
> According to the mapping in the framework document between TSC and ACTN
> (section 4 of draft-nsdt-teas-ns-framework-02) the TSC SBI could be mapped
> to the CMI in ACTN architecture. Thus customer service models such as L3SM
> would fit in the SBI of TSC.
>
>
>
> *De:* Teas <[email-masked]> *En nombre de *Kiran Makhijani
> *Enviado el:* martes, 5 de mayo de 2020 17:05
> *Para:* Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]>;
> Italo Busi <[email-masked]>; [email-masked]
> *CC:* [email-masked]; Rokui, Reza (Nokia - CA/Ottawa) <
> [email-masked]>
> *Asunto:* Re: [Teas] TS and VPN (was RE: FW: The word "transport")
>
>
>
> Hi Italo, Sergio,
>
> Your explanation helped. If “customer service models” should not be at SBI
> is a sufficient explanation then it makes sense to maintain that
> separation.
>
> Are there any other side-effects of this on NBI or framework? Lets check
> in nsdt, if no one disagrees, we can exclude LxSMs with 8309 reference.
>
> Thanks
>
> Kiran
>
>
>
> *From:* Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]>
> *Sent:* Tuesday, May 5, 2020 1:31 AM
> *To:* Italo Busi <[email-masked]>; Kiran Makhijani <
> [email-masked]>; [email-masked]
> *Cc:* [email-masked]; Rokui, Reza (Nokia - CA/Ottawa) <
> [email-masked]>
> *Subject:* RE: [Teas] TS and VPN (was RE: FW: The word "transport")
>
>
>
> @Italo Busi <[email-masked]>  Hi Italo , many thanks to point out
> this text from RFC 8309. More in session 7.1 , RFC 8309 try again to
> clarify the agnostic characteristic of a customer service model as LxSM vs.
> what could technology specific (e.g. encapsulation) from customer
> prospective.
>
>
>
> @Kiran Makhijani <[email-masked]> Hi Kiran, I think your
> explanation does not provide the clarity required : “the SBI will use which
> ever technology specific data model is provided by the operator (L3VPN or
> L3SM)”
>
>
>
> I think we need to clarify better what is required at NBI of TSC and what
> at SBI, taking into account in my view  that models being considered as
> “customer service model” like e.g. LxSM should not be at SBI .
>
> Moreover, clarifying the context of SBI and NBI interfaces would also help
> to describe more specifically the real functionality of TSC.
>
>
>
> Thanks
>
> Sergio
>
>
>
>
>
>
>
> *From:* Teas <[email-masked]> *On Behalf Of *Italo Busi
> *Sent:* Tuesday, May 5, 2020 9:11 AM
> *To:* Kiran Makhijani <[email-masked]>; [email-masked]
> *Cc:* [email-masked]; Rokui, Reza (Nokia - CA/Ottawa) <
> [email-masked]>
> *Subject:* Re: [Teas] TS and VPN (was RE: FW: The word "transport")
>
>
>
> *From:* Kiran Makhijani [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* martedì 5 maggio 2020 02:49
> *To:* Italo Busi <[email-masked]>; [email-masked]
> *Cc:* [email-masked]; 'Rokui, Reza (Nokia - CA/Ottawa)' <
> [email-masked]>
> *Subject:* RE: [Teas] TS and VPN (was RE: FW: The word "transport")
>
>
>
> Hi Italo,
>
> Please note that the definitions document  wants to develop an independent
> concept of transport slices. It says nothing about either of the 2 – that
> transport slice is a service or is a technology.
>
>
>
> However, how is it possible to define a service without specifying the
> type the traffic (e.g., Ethernet or IP) that is exchanged at the UNI and
> over the VPN?
>
> ^^^^
>
> Short answer is - this will happen through mappings when actual
> realization of TS happens, the SBI will use which ever technology specific
> data model is provided by the operator (L3VPN or L3SM).  This will become
> clearer in NBI data model.
>
>
>
> -Kiran
>
>
>
> *From:* Italo Busi <[email-masked]>
> *Sent:* Monday, May 4, 2020 1:54 PM
> *To:* Kiran Makhijani <[email-masked]>; [email-masked]
> *Cc:* [email-masked]; 'Rokui, Reza (Nokia - CA/Ottawa)' <
> [email-masked]>
> *Subject:* RE: [Teas] TS and VPN (was RE: FW: The word "transport")
>
>
>
> Hi Kiran,
>
>
>
> A service defined from the viewpoint of the customer is usually not
> underlay specific since it is possible to implement the same service using
> different underlay technologies
>
>
>
> However, how is it possible to define a service without specifying the
> type the traffic (e.g., Ethernet or IP) that is exchanged at the UNI and
> over the VPN?
>
>
>
> Italo
>
>
>
> *From:* Kiran Makhijani [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* lunedì 4 maggio 2020 19:18
> *To:* Italo Busi <[email-masked]>; [email-masked]
> *Cc:* [email-masked]; 'Rokui, Reza (Nokia - CA/Ottawa)' <
> [email-masked]>
> *Subject:* RE: [Teas] TS and VPN (was RE: FW: The word "transport")
>
>
>
> Hi Italo,
>
> That’s right. In the beginning, we consider ‘VPN+ some resource
> guarantees’ as a use case. In section 1 we aren’t concerned how that VPN
> will be realized (L2 or L3 way). In section 5, we are actually saying that
> well-known models for L2VPN, L3VPN (whether service or underlay specific)
> are means to realize transport slice. By associating L2- or L3- usage
> becomes technology-specific. In section 5, we don’t use VPN generically.
>
> -Kiran
>
>
>
>
>
> *From:* Teas <[email-masked]> *On Behalf Of *Italo Busi
> *Sent:* Monday, May 4, 2020 9:36 AM
> *To:* [email-masked]
> *Cc:* [email-masked]; 'Rokui, Reza (Nokia - CA/Ottawa)' <
> [email-masked]>
> *Subject:* [Teas] TS and VPN (was RE: FW: The word "transport")
>
>
>
> Actually, I think you would do well to distinguish between VPN as a
> service and the technologies used to realise a VPN.
>
>
>
> *From:* Adrian Farrel [mailto:[email-masked] <[email-masked]>]
> *Sent:* giovedì 30 aprile 2020 21:32
> *To:* 'Rokui, Reza (Nokia - CA/Ottawa)' <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* [Teas] 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:
>
>    - 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
> 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…
>
> …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...
>
> …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]> *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,
>
>
>
> On 2020-04-24, 1:31 AM, "Dhruv Dhody" <[email-masked]> wrote:
>
>
>
>     Hi Reza,
>
>
>
> 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.
>
>
>
> Transport slices in RAN for midhaul and fronthaul, in 5G Core or for
> application. All these transport slices are shown below.
>
>
>
> ]
>
>
>
> [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).
>
> 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.
>
>
>
>
>
> 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.
>
> 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.
>
>
>
> <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%7Cfb3ff222be214d1be9b808d7f0ceb7bb%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637242642968275741&sdata=7xnTpsT1IY833RRzHnovscncirjXW6E3UG51lH%2F2C9o%3D&reserved=0>
>
>
>
>     ==
>
>
>
>     More inline..
>
>
>
>     <[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.
>
>     >
>
>
>
>     > On 2020-04-23, 12:35 PM, "Dhruv Dhody" <[email-masked]> wrote:
>
>     >
>
>     >     Hi,
>
>     >
>
> ------------------------------
>
>
> 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
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas
>

-- 
___________________________________________
Luis M. Contreras
[email-masked]
[email-masked]
Global CTIO unit / Telefonica

---

From: Italo Busi <[email-masked]>
Date: Tue, 5 May 2020 21:38:15 +0000

Luis,

I think that the TS SBI should use the L2NM or L3NM to request the network controllers to setup the L2VPN and L3VPN realizing the TS

Italo

From: Luis M. Contreras [mailto:[email-masked]]
Sent: martedì 5 maggio 2020 20:03
To: Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]>
Cc: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>; Kiran Makhijani <[email-masked]>; Italo Busi <[email-masked]>; [email-masked]; [email-masked]; Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
Subject: Re: [Teas] TS and VPN (was RE: FW: The word "transport")

Ok, understood.

By the way, according to the figure (left hand side) TSC would instruct some network controllers, so L3/L2 service models could be expected at that level, right?

Thanks

Luis

El mar., 5 may. 2020 a las 19:45, Belotti, Sergio (Nokia - IT/Vimercate) (<[email-masked]<mailto:[email-masked]>>) escribió:
Hi Luis,
yes correct but I think here it’s like the chicken and the egg: based on what was written about the usage of LxSM at SBI, obviously, Dhruv made, correctly,  the mapping of ACTN starting from CMI at the level of SBI in slicing context.

Thanks
Sergio

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, May 5, 2020 7:27 PM
To: Kiran Makhijani <[email-masked]<mailto:[email-masked]>>; Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]<mailto:[email-masked]>>; Italo Busi <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Teas] TS and VPN (was RE: FW: The word "transport")

HI all,

Best regards

Luis

Hi Italo, Sergio,

Thanks
Sergio

                                                    Except where

Italo

Hi Italo,

-Kiran

Hi Kiran,

Italo

Hi Italo,

Thanks, Italo

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

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
_______________________________________________
Teas mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas

--
___________________________________________
Luis M. Contreras
[email-masked]<mailto:[email-masked]>
[email-masked]<mailto:[email-masked]>
Global CTIO unit / Telefonica

---

From: "Luis M. Contreras" <[email-masked]>
Date: Wed, 6 May 2020 13:34:03 +0200

Hi Italo,

understood your point.

Thanks

Luis

El mar., 5 may. 2020 a las 23:38, Italo Busi (<[email-masked]>)
escribió:

> Luis,
>
>
>
> I think that the TS SBI should use the L2NM or L3NM to request the network
> controllers to setup the L2VPN and L3VPN realizing the TS
>
>
>
> Italo
>
>
>
> *From:* Luis M. Contreras [mailto:[email-masked]]
> *Sent:* martedì 5 maggio 2020 20:03
> *To:* Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]>
> *Cc:* LUIS MIGUEL CONTRERAS MURILLO <
> [email-masked]>; Kiran Makhijani <
> [email-masked]>; Italo Busi <[email-masked]>; [email-masked];
> [email-masked]; Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]
> >

---

From: Gert Grammel <[email-masked]>
Date: Fri, 8 May 2020 11:55:15 +0000

Kiran, Adrian,

I was trying to understand the logic behind the different arguments and ran a thought experiment that I found useful to wrap my brain  around the definition and may help to straighten things out:

Trying to interpret Kieran’s arguments first:
It appears to me that with “transport” Kieran means a switchable entity EXCLUDING adaptation. If we take VPLS (rfc4761) as a case in point, the mapping of Ethernet in a PW (rfc4448) would be considered a “service” while carrying the PDUs over an MPLS network (i.e. the LSP) is considered Transport. IOW for the VPLS case, a “Transport slice” would be the LSP, while the “service” would be the Ethernet INCLUDING adaptation and association of PW to a LSP. Obviously, a “transport slice” is a technology independent term, so an LSP is just one technology to implement it.

With that understanding, a classical VPLS/VPN is a service and an LSP (or set of LSPs) is one incarnation of a “transport slice”. When running run the example above against draft-nsdt-teas-transport-slice-definition-02, I didn’t find a glaring mismatch. Perhaps Kieran can comment if there is something missing.

Ignoring VPN+ definitions for now I also tested if an IP-subnet would fall in the definition of a transport slice. After all such subnet is a slice of the IPv4/v6 Address space. My findings were:
4.1.  Service Level Objectives on Transport Slice

   A transport slice is defined in terms of several quantifiable
   objectives or SLOs.  These objectives define a set of network
   resource parameters or values necessary to provide a service a given
   transport slice.
>>>             Quantifiable objective is reachability between hosts in the subnet and constitute a “set of network
            resource parameters or values necessary to provide a service”

NF resources: The endpoints in Section 4.2 performance depend on
      resource allocated to those functions and can be specified in
      terms of compute, memory and access control objectives points.
      See [NFVGST].
>>>         Memory size of the routing table to perform routing in the subnet can be reduced compared to a full table.

So yes, an IP-subnet is a slice

Obviously definitions are never perfect, but If the interpretation is valid, then I would urge to tighten the definition of a “transport-slice” by a bit. Putting addressing and LSPs under the same broad umbrella name “transport-slice” doesn’t strike me as particularly useful in a technical discussion.

My 2c

Gert

From: Teas <[email-masked]> on behalf of Adrian Farrel <[email-masked]>
Organization: Old Dog Consulting
Reply-To: Adrian Farrel <[email-masked]>
Date: Monday, May 4, 2020 at 21:58
To: 'Kiran Makhijani' <[email-masked]>, 'Italo Busi' <[email-masked]>, TEAS WG <[email-masked]>
Cc: "'Rokui, Reza (Nokia - CA/Ottawa)'" <[email-masked]>
Subject: Re: [Teas] TS and VPN (was RE: FW: The word "transport")

[External Email. Be cautious of content]

Best,
Adrian

Hi Italo,

Thanks, Italo

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:/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*7C8f6662522d2245d355b608d7f049fbf4*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637242072876400040&sdata=XnErhWSbnxSLOg5TrgDcai8mqVjXDV6LUu6KiorGMSk*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!UelC3Hodpo9uh9QIORC_-7I7iGvnDhDA1fBvLNqE6QiK-Caz8l4aKExFHncaU93y$>

    ==

    More inline..

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

    Thanks!

    Dhruv