Re: [Teas-ns-dt] On definition// Re: Notes from Feb 24th call & deadline

[Kiran Makhijani <[e-mail]>]

Jie, Sergio,
Thank you for helping to converge.

On (4): If you look outside ACTN, the term ‘abstract’ is used quite generically. I am not convinced that when transport slice is needed, a user is asking for a ‘virtual network’ per se. They simply ask for connectivity between endpoints with certain SLOs.
On (3)  Similarly, I read the argument from Jie on point (3), but it was not convincing enough to me why ‘consumer’ it necessary in definition? Can we not describe transport slice as a stand-alone entity?

Some issues with your proposal:
*There is also an issue with use of both together “virtual network” and “particular topology”. Should use one of them.
*In your definition who is network slice consumer? You are making transport slice definition dependent on the meaning of ‘network slice’.

On a non-technical note.
*The proposed definition is still too verbose and may be recursive (a soup of words – connectivity, virtual network, topology, network slice … - there is no cohesion between these words). A Definition does not have to capture the entire “Description” of a concept.
*Yes, NS-DT has to leverage existing of work – but I hope it should be allowed to diverge or ‘simplify’ if it’s justified.
-Kiran

From: "Belotti, Sergio (Nokia - IT/Vimercate)" <[e-mail]>
Date: Thursday, February 27, 2020 at 1:11 AM
To: "Dongjie (Jimmy)" <[e-mail]>om>, Kiran Makhijani <[e-mail]>om>, Jari Arkko <jari.arkko=[e-mail]>rg>, "[e-mail]" <[e-mail]>rg>, "Rokui, Reza (Nokia - CA/Ottawa)" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: On definition// Re: Notes from Feb 24th call & deadline

Hi Jie, Kiran
I share most of Jie’s comments.
Point 1 and point 2 from Kiran’s proposal are fine with me.
Point 3 about “network slice consumer” I also think this is not directly linked just to instantiation , and so the usage of term “network slice consumer” is enough generic but providing the hook to the process of “demand” for the service required in transport slice request.
For the point 4 on virtual network, the usage of “abstract network topology” is simply wrong , you provide a virtual network when you are asking for transport slice, and the abstraction is the process botton-up form which you can obtain VN, exploiting underlying network resources.
So my proposal would be this one :

“ A transport network slice is a virtual network with a particular
   network topology and a set of shared or dedicated network resources, which are used to provide the network slice consumer with the required connectivity, with expected objectives specified through a specific Service Level Objective (SLO). “

The objectives that are part of SLO will be defined separately (no more isolation in the definition) as Kiran is proposing.

Thanks
Sergio

From: Dongjie (Jimmy) <[e-mail]>
Sent: Thursday, February 27, 2020 4:23 AM
To: Kiran Makhijani <[e-mail]>om>; Belotti, Sergio (Nokia - IT/Vimercate) <[e-mail]>om>; Jari Arkko <jari.arkko=[e-mail]>rg>; [e-mail]; Rokui, Reza (Nokia - CA/Ottawa) <[e-mail]>
Subject: RE: On definition// Re: Notes from Feb 24th call & deadline

Hi Kiran,

Thanks for initiating the discussion. Please see some comments inline with [Jie].

Best regards,
Jie

From: Teas-ns-dt [mailto:[e-mail]] On Behalf Of Kiran Makhijani
Sent: Thursday, February 27, 2020 5:13 AM
To: Belotti, Sergio (Nokia - IT/Vimercate) <[e-mail]<mailto:[e-mail]>>; Jari Arkko <jari.arkko=[e-mail]<mailto:jari.arkko=[e-mail]>>; [e-mail]<mailto:[e-mail]>; Rokui, Reza (Nokia - CA/Ottawa) <[e-mail]<mailto:[e-mail]>>
Subject: [Teas-ns-dt] On definition// Re: Notes from Feb 24th call & deadline

In order to initiate discussion: My proposal is to refine the definition as follows:

"A transport network slice is an abstract network topology with a set of shared or dedicated network resources, which are used to provide the required connectivity with expected objectives specified through a specific Service Level Objective (SLO). "

We “augment” the definition in [I-D.ietf-teas-enhanced-vpn] is due to the following considerations:

  1.  Service Level Agreements (SLAs) do not clearly define measurable parameters where as SLOs do. So SLA is dropped from the definition. [discussed and agreed at 106]

[Jie] As we discussed, SLA is the agreement between customer and provider about the service to be provided, and SLO represents the measurable characteristics of SLA. Thus SLO is included as part of SLA. I agree SLO is more suitable for the definition here. While since SLA is widely used in other places, the relationship between SLA and SLO could be further explained in the document. Some useful descriptions quoting from Wikipedia: https://en.wikipedia.org/wiki/Service-level_objective<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FService-level_objective&data=02%7C01%7Ckiranm%40futurewei.com%7Cd39709f2ce9f45d3c8c808d7bb64f7f1%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637183914663873246&sdata=wrwyIK15QLkwfRpJ7Cocs134ZzXIomZ5out0Zg9Oa7s%3D&reserved=0>

“A service-level objective (SLO) is a key element of a service-level agreement (SLA) between a service provider and a customer. SLOs are agreed upon as a means of measuring the performance of the Service Provider and are outlined as a way of avoiding disputes between the two parties based on misunderstanding.”

“SLOs provide a quantitative means to define the level of service a customer can expect from a provider.”

“The SLA is the entire agreement that specifies what service is to be provided, how it is supported, times, locations, costs, performance, and responsibilities of the parties involved.  SLOs are specific measurable characteristics of the SLA such as availability, throughput, frequency, response time, or quality.”


  1.  Isolation should be seen/expressed as one of the objective of transport slices, therefore, is not included in the definition. It complicates the definition, because we observed that isolation could mean different things, so the term ‘isolation’ will require  further explanation.[has been discussed and converged on in e-meetings]

[Jie] It is OK to list isolation as one characteristics in the SLO. While we need to admit that isolation is one of the characteristics to differentiate network slice and traditional virtual networks. Removing isolation from the definition could make it more generic, while may lose its specialty.


  1.  Drop term "network slice consumer" in slice definition: Considering a broader top-down view of transport slice here, “ consumer" binds  a transport slice to its realization. The thing we are working on,  it is possible to create/define a slice without actually instantiating it (then there will be no consumer). So it is better to drop "network slice consumer".

[Jie] It is not clear to me how “consumer” is related to realization or instantiation. As specified in 3.2 of the framework draft, the requirement of a transport slice is expressed by a consumer via the NBI to transport slice controller, this is done before the instantiation and not bind to any realization. Actually in current definition, the text “provide the required connectivity and… ” seems incomplete in terms of to such service is provided. Thus I’d suggest to include the “transport slice consumer” in the definition.


  1.  The meaning of term abstract (layer) network is defined in rfc7926. But I am failing to understand the preference between virtual vs abstract network. For me, virtual network is an end to end single tunnel, but slices can be a composition of more than one tunnels. So abstract is a better term. [also been discussed and narrowed down to the current choice].

[Jie] Depends on service requirement, a virtual network could represent a point-to-point connection, or MP2MP connection. Its realization can be either one or multiple tunnels, or a subset of the underlying network. Thus virtual network can also meet your requirement. As for “abstract” and “virtual”, my preference is virtual, as “abstract” is mainly from the view of the slice consumer, while in the definition we may want to cover the characteristics of the transport slice itself.

My another concern about the term “abstract topology” is that “topology” is just one attribute of a network (no matter abstract, virtual or physical) , if we say a transport slice is a “topology”,  it will exclude other attributes of a network. This problem could be resolved if we use “virtual network” instead. Another possible alternative is it could say “a transport slice has an abstract topology and a set of shared or dedicated network resources…”

This was discussed in early January on the mail list with Shunsuke, and some more feedback from the team would be appreciated.

We will certainly give reference and credit to [I-D.ietf-teas-enhanced-vpn] and RFC7926. But we shouldn’t have to explain as above in the document (in my opinion).

I will request others chime in now.
Cheers!
Kiran

From: Kiran Makhijani <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, February 25, 2020 at 11:05 AM
To: "Belotti, Sergio (Nokia - IT/Vimercate)" <[e-mail]<mailto:[e-mail]>>, Jari Arkko <jari.arkko=[e-mail]<mailto:jari.arkko=[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "Rokui, Reza (Nokia - CA/Ottawa)" <[e-mail]<mailto:[e-mail]>>
Subject: Re: Notes from Feb 24th call & deadline

Sergio,
to keep discussion simple, is your main problem right now about abstract vs logical/virtual network?
-Kiran

From: "Belotti, Sergio (Nokia - IT/Vimercate)" <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, February 25, 2020 at 10:21 AM
To: Kiran Makhijani <[e-mail]<mailto:[e-mail]>>, Jari Arkko <jari.arkko=[e-mail]<mailto:jari.arkko=[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "Rokui, Reza (Nokia - CA/Ottawa)" <[e-mail]<mailto:[e-mail]>>
Subject: RE: Notes from Feb 24th call & deadline

Hi Kiran,
Please see in line.
I disagree on your comments and I’d like a general discussion on the topic instead of just your opinion.
As reported below my proposal exactly is following the request from Jari.

Regards
Sergio

From: Kiran Makhijani <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, February 25, 2020 5:45 PM
To: Belotti, Sergio (Nokia - IT/Vimercate) <[e-mail]<mailto:[e-mail]>>; Jari Arkko <jari.arkko=[e-mail]<mailto:jari.arkko=[e-mail]>>; [e-mail]<mailto:[e-mail]>; Rokui, Reza (Nokia - CA/Ottawa) <[e-mail]<mailto:[e-mail]>>
Subject: Re: Notes from Feb 24th call & deadline

Hello Sergio,
It is my bad! I assumed through conversations in meetings it was clear not to change the definition.

SB> It would be interesting to understand form what you perceived this.
This is an extract of the discussion held on January https://github.com/teas-wg/teas-ns-dt/blob/master/notes/notes-2020-01-27.md<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fteas-wg%2Fteas-ns-dt%2Fblob%2Fmaster%2Fnotes%2Fnotes-2020-01-27.md&data=02%7C01%7Ckiranm%40futurewei.com%7Cd39709f2ce9f45d3c8c808d7bb64f7f1%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637183914663883237&sdata=Td%2B3lpJZEQvI8mibV6LwMJBIvIW0qvgCjWRx4z%2Bc7l4%3D&reserved=0>
“The discussion converged on referring to existing RFCs (and aligning both enhanced-vpn and design team documents). There was strong support for reusing existing definitions.
But then it was somewhat unclear what specific definition exists for instance in Section 4 (abstractions) of RFC 7926. Or in RFC 8453. And Jari commented that while he is happy with the definition in the Enhanced VPN draft in general, in his opinion in one way it has an issue, as it picks up dedicated resources and isolation, and does not consider the full set of characteristics like the design team definitions draft version does. This might be fixable of course.
This discussion did not finish during the call. We decided to:

  *   Have the different proponents (at least Sergio, Jeff, Jari, Shunsuke, and definitions draft authors) each look at RFC 7926, 8453, Enhanced VPN draft and other sources and suggest specific replacement definition that uses a reference to earlier work. “

SB> There is nothing in the discussion than can conclude any acceptance of the present definition , while what I did is to report a definition strictly related to both ACTN (and the text Dhruv proposed for framework) and RFC 7926 , in which it is clearly define the difference between virtual network and abstract network , motivating why in the ACTN we use the term VN in accordance as slice.

I’ve already put in the issue https://github.com/teas-wg/teas-ns-dt/issues/3<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fteas-wg%2Fteas-ns-dt%2Fissues%2F3&data=02%7C01%7Ckiranm%40futurewei.com%7Cd39709f2ce9f45d3c8c808d7bb64f7f1%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637183914663883237&sdata=5qUJV7eZJr7GT5DEtPDq2G7CZtUVZsEYGkVnWPmZpX0%3D&reserved=0> my comments and why your definition is not good.


  *   The current definition has a wide consensus from the group. I am afraid we might undo what we agreed upon 5-6 months ago.
SB> I haven’t seen any agreement on that a shown by extract above. And I’d like to have real discussion not just your opinion on my proposal, since no comments also on my issue was raised.


  *   We also had discussions on why we would not use the term virtual network (to not to exclude physical/dedicated network, resources – abstract was the best term). I highlight my concerns in your proposed definition, please see below (essentially, it is too verbose- we tried to keep it to the point).
SB> VN definition does exclude nothing of you’re saying , RFC 8453 is explaining very well the concept and usage of VN.



“A transport network slice is a virtual network with a particular

   network topology and a set of shared or dedicated network resources,



[KM] We capture this essence in SLOs. See discussion on SLO section

   which are used to provide the network slice consumer with the

   required connectivity, appropriate isolation and





[KM] We use “topology connecting…”, therefore, no point repeating this.

   specific Service Level Agreement (SLA) or Service Level Objective (SLO).”

^^^^

[KM] in IETF 106, we decided to distinguish between SLA and SLO. SLO are more accurate. If we use both SLA and SLO – the definition is vague.

How about we make it sound like below?

"A transport slice is an abstract network topology connecting a
   number of endpoints and a set of shared or dedicated network resources, with expected objectives specified through a set
   of service level objectives (SLO)".

If you would like to propose some text outside the definition which you think could help, please suggest.
HTH,
Kiran

From: "Belotti, Sergio (Nokia - IT/Vimercate)" <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, February 25, 2020 at 12:19 AM
To: Jari Arkko <jari.arkko=[e-mail]<mailto:jari.arkko=[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "Rokui, Reza (Nokia - CA/Ottawa)" <[e-mail]<mailto:[e-mail]>>
Cc: Kiran Makhijani <[e-mail]<mailto:[e-mail]>>
Subject: RE: Notes from Feb 24th call & deadline

Hi Jari, Reza as co-author of definition draft, all,
I read again draft definition and in the new version is still missing the proposed new definition of transport slice as for my pull request sent 25 days ago.
Is there any objection to the adoption of my proposed text? If not, I suggest editor to provide a new version including the text contained in
https://github.com/teas-wg/teas-ns-dt/pull/4<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fteas-wg%2Fteas-ns-dt%2Fpull%2F4&data=02%7C01%7Ckiranm%40futurewei.com%7Cd39709f2ce9f45d3c8c808d7bb64f7f1%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637183914663893231&sdata=tIl4De4oa8n%2FzU%2Bn2WlbEU6ks59LYe%2B174DCE2n6PZk%3D&reserved=0>amp;reserved=0>.

Thanks
Sergio

Sergio Belotti
Senior System Engineer and Standardization Architect
IP/Optical Networks, Optics BU
Nokia
M: [phone]
Via Energy Park, 20871 Vimercate (MB) , Italy
[e-mail]<mailto:[e-mail]>



From: Teas-ns-dt <[e-mail]<mailto:[e-mail]>> On Behalf Of Jari Arkko
Sent: Tuesday, February 25, 2020 8:26 AM
To: [e-mail]<mailto:[e-mail]>
Subject: [Teas-ns-dt] Notes from Feb 24th call & deadline

The notes are now available here: https://github.com/teas-wg/teas-ns-dt/blob/master/notes/notes-2020-02-20.md<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fteas-wg%2Fteas-ns-dt%2Fblob%2Fmaster%2Fnotes%2Fnotes-2020-02-20.md&data=02%7C01%7Ckiranm%40futurewei.com%7Cd39709f2ce9f45d3c8c808d7bb64f7f1%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637183914663893231&sdata=ewZaoNIqRMQa9DYZcxn74%2BSCrf390sM5V3%2FyuEkzJDA%3D&reserved=0> Let me know if there are any changes needed.

I would also like to underline the importance of working on the two documents and their issues now on the mailing list. It feels like we are now making rapid progress. However, we only have 13 days left. It is important that we check the discussion daily so that we have enough email roundtrips to finish the issues we’re discussing. And contributions on both documents are also needed. You can suggest changes by sending mail to the list.

The drafts in their current form are at

  https://github.com/teas-wg/teas-ns-dt/blob/master/definitions/draft-rokui-teas-transport-slice-definition-00.txt<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fteas-wg%2Fteas-ns-dt%2Fblob%2Fmaster%2Fdefinitions%2Fdraft-rokui-teas-transport-slice-definition-00.txt&data=02%7C01%7Ckiranm%40futurewei.com%7Cd39709f2ce9f45d3c8c808d7bb64f7f1%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637183914663903226&sdata=nZipmy4ougxecFYEqDQXiLzKmvGH%2FXwmoZNiPVzI8wg%3D&reserved=0>
  https://github.com/teas-wg/teas-ns-dt/blob/master/framework/draft-ejj-teas-ns-framework-00.txt<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fteas-wg%2Fteas-ns-dt%2Fblob%2Fmaster%2Fframework%2Fdraft-ejj-teas-ns-framework-00.txt&data=02%7C01%7Ckiranm%40futurewei.com%7Cd39709f2ce9f45d3c8c808d7bb64f7f1%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637183914663903226&sdata=NKiMexZi5qWz9Gp1xGcJ7wZ0dmPg1REDBNepkf5owzQ%3D&reserved=0>

But there are also a number of big contributions discussed, see the notes for pointers.

Jari