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

[Zhenghaomian <[e-mail]>]

Hi Kiran, All,

I saw experts from different technologies in the design team, so I assume we have already agreed that the slice is a technology-agnostic term, just to make sure on the alignment. The definition draft mentioned this conclusion so we expect to use it as principle for info/data model design.

It would be great if we can emphasize as well in the definition, how about “A transport network slice is an abstract network topology with a set of shared or dedicated network resources, which are technology-agnostic and used to provide the required connectivity with expected objectives specified through a specific Service Level Objective (SLO).”

Sorry for the late jump in, and apology if this has already been covered somewhere else.  Thanks.

My 2 cents,
Haomian

发件人: Teas-ns-dt [mailto:[e-mail]] 代表 Kiran Makhijani
发送时间: 2020年2月27日 5:13
收件人: Belotti, Sergio (Nokia - IT/Vimercate) <[e-mail]>om>; Jari Arkko <jari.arkko=[e-mail]>rg>; [e-mail]; Rokui, Reza (Nokia - CA/Ottawa) <[e-mail]>
主题: [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]
  2.  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]
  3.  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".
  4.  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].
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://nam03.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%7C7326accfb91c4e02883208d7ba1f7aef%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637182516692349007&sdata=nBmaVlWmfzQY4Oax1GII4HoXx4Yevmjuf%2Bzv2Lbk1Jw%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://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fteas-wg%2Fteas-ns-dt%2Fissues%2F3&data=02%7C01%7Ckiranm%40futurewei.com%7C7326accfb91c4e02883208d7ba1f7aef%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637182516692359010&sdata=8I7EX%2FtMJ7FT2Pb78A8vrx8gsf4yusl1gtkJb8O2%2FXY%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://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fteas-wg%2Fteas-ns-dt%2Fpull%2F4&data=02%7C01%7Ckiranm%40futurewei.com%7C7326accfb91c4e02883208d7ba1f7aef%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637182516692368998&sdata=hlMh0vr1V8k9ERr2Ydk2pZma0yADU0UPB5TR%2BmZWs5c%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://nam03.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%7C7326accfb91c4e02883208d7ba1f7aef%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637182516692368998&sdata=KEjMh%2FQEQrq2OL%2FQloOgVNJvhGC%2BvHeExADuFsNxyWw%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://nam03.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%7C7326accfb91c4e02883208d7ba1f7aef%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637182516692378994&sdata=NcPrlFyX7xaSJoF6rN4Ev1a1GBUdi%2FyMVrY1g8nmm%2Fk%3D&reserved=0>
  https://github.com/teas-wg/teas-ns-dt/blob/master/framework/draft-ejj-teas-ns-framework-00.txt<https://nam03.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%7C7326accfb91c4e02883208d7ba1f7aef%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637182516692388988&sdata=kNpTIN3KIdJmD%2FWMJzbHowDjJ1MUn0a%2B%2BNRG2%2BrqoJM%3D&reserved=0>

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

Jari