Subject: Re: [Teas-ns-dt] issue discussion: NF resource

From: Kiran Makhijani <[email-masked]>
Date: Mon, 1 Jun 2020 19:30:05 +0000

Hi Greg,
In order to resolve the issue:
Since the section is “Minimum SLOs”, I agree to “move it outside the minimal”.

My actual reply would put us back in the loop: If an operator gave less cpu and firewall runs slow then the user is not happy. Shouldn’t they be able to provide some criteria to get their ideal performance? How do you meet that objective upfront?
-Kiran

From: Greg Mirsky <[email-masked]>
Sent: Thursday, May 28, 2020 6:37 PM
To: Kiran Makhijani <[email-masked]>
Cc: [email-masked]
Subject: Re: [Teas-ns-dt] issue discussion: NF resource

Hi Kiran,
thank you for your kind consideration of my comments. If we agree that a customer of a TS may specify a certain TS behavior that is externally observable on data packets, then I don't find where elements like "memory", "computing power" fit. I think that these are important to an operator when choosing the most economical and efficient method to realize the TS according to the specific LSO.
What do you think?

Regards,
Greg

On Thu, May 28, 2020 at 4:56 PM Kiran Makhijani <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,
You are right. I should not have used term ‘virtual’ – I was visualizing a NF container in NBI data model. A user of transport slice just asks for a NF and associated properties. Whether it’s V- or P- is a realization time decision.

I see NFs adding a lot of value from higher-layer perspective, without getting bogged down about network details users can attach app specific firewalls, IDS, and caching type of functions on the endpoints. These are all good examples for use of NFs in slices. Secondly you will be able to express your requirement from a single place instead of dealing with different interfaces.

<your quote>
the TS does not specify which NFs should compose the TS but only what is the functional behavior and performance provided by the TS.
^^^
I hope you agree that there’s a need for some “functional behavior”. If user can leverage provider network for that behavior, then why not?
-Kiran

From: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, May 28, 2020 3:15 PM
To: Kiran Makhijani <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Teas-ns-dt] issue discussion: NF resource

Hi Kiran,
I think that an NF can be realized as a physical device or a VM. Would you agree? If that is the case, then, in my opinion, we cannot consider only the VNF case but add the PNF case as well.
Also, I don't see the real benefit to have NF, in all their variety now and more in the future, as part of a TS. I think that NF is either part of the TS implementation and thus is selected by an operator based on the SLO. Or part of a service that uses the TS. In the model I have in mind, a client of the TS does not specify which NFs should compose the TS but only what is the functional behavior and performance provided by the TS.

On Thu, May 28, 2020 at 12:06 PM Kiran Makhijani <[email-masked]<mailto:[email-masked]>> wrote:
Hi All,
To kick off discussion on this topic.

During earlier discussions several of us asked for network functions should be part of the slices. For me the value of doing this is to be able to express different nuances of a service through single set of objectives. Then in NBI and implementation there is one controller to monitor the performance.

At the entry and exit of transport slices, these NF can be supplied to enforce access control, policies, etc. on transport slice traffic. It is also safe to assume that they will be virtual.

The objective is to apply those function on  traffic flows.
2 examples are  (1) use of firewall at entry point with the rules described by the user of transport slice. (2) Caching or DPI function on exit endpoints.

Regards
Kiran

--
Teas-ns-dt mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas-ns-dt<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas-ns-dt&data=02%7C01%7Ckiranm%40futurewei.com%7Cf693a0401cb94a59ee0708d80370c0f7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637263130100769061&sdata=ppr3yiBDq1%2BAZbFsYnhwGugLb27aVuEoBtBY45kXOdc%3D&reserved=0>

---

From: Eric Gray <[email-masked]>
Date: Mon, 1 Jun 2020 19:41:30 +0000

Kiran,

              This may not be sufficient justification for leaving NF Resources in the draft.

              I can see adding this to the list of “other (or additional) objectives, but I cannot see what value it adds if it is mostly intended as a placeholder for potential (as yet undefined) virtual network functions.

              I thought I had included my reasoning in earlier mail, but let me summarize now: without specifics, by explicitly including this in the definitions draft, we may leave people with a feeling of incompleteness if their own favorite VNF is not also included.  And there are arbitrarily many such VNFs.

--
Eric

From: Teas-ns-dt <[email-masked]> On Behalf Of Kiran Makhijani
Sent: Monday, June 1, 2020 3:30 PM
To: Greg Mirsky <[email-masked]>
Cc: [email-masked]
Subject: Re: [Teas-ns-dt] issue discussion: NF resource

Hi Greg,

Hi Kiran,

Regards,
Greg

<your quote>

Hi Kiran,

Regards
Kiran

--
Teas-ns-dt mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas-ns-dt<https://protect2.fireeye.com/v1/url?k=13f15f38-4d51bfa6-13f11fa3-86ee86bd5107-e37de12ef421e70c&q=1&e=455b015e-c726-49bd-8723-a05f5cb4535e&u=https%3A%2F%2Fnam11.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fwww.ietf.org%252Fmailman%252Flistinfo%252Fteas-ns-dt%26data%3D02%257C01%257Ckiranm%2540futurewei.com%257Cf693a0401cb94a59ee0708d80370c0f7%257C0fee8ff2a3b240189c753a1d5591fedc%257C1%257C0%257C637263130100769061%26sdata%3Dppr3yiBDq1%252BAZbFsYnhwGugLb27aVuEoBtBY45kXOdc%253D%26reserved%3D0>

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 1 Jun 2020 12:43:27 -0700

Hi Kiran,
I much appreciate your consideration of my comments.
As for your example, I think that we can expect an operator to be
knowledgeable and experienced in mapping customer intentions into a
particular technology the operator is using. That is where I'd leave space
for operators and vendors to innovate and differentiate their products.
What we can provide, in my view, is performance measurement
methodology(ies) that will help customers to have quantitative
representation of the TS service.

Regards,
Greg

On Mon, Jun 1, 2020 at 12:30 PM Kiran Makhijani <[email-masked]>
wrote:

> My actual reply would put us back in the loop: If an operator gave less
> cpu and firewall runs slow then the user is not happy. Shouldn’t they be
> able to provide some criteria to get their ideal performance? How do you
> meet that objective upfront?
>
> -Kiran
>
>
>
> *From:* Greg Mirsky <[email-masked]>
> *Sent:* Thursday, May 28, 2020 6:37 PM
> *To:* Kiran Makhijani <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [Teas-ns-dt] issue discussion: NF resource
>
>
>
> Hi Kiran,
>
> thank you for your kind consideration of my comments. If we agree that a
> customer of a TS may specify a certain TS behavior that is externally
> observable on data packets, then I don't find where elements like "memory",
> "computing power" fit. I think that these are important to an operator when
> choosing the most economical and efficient method to realize the TS
> according to the specific LSO.
>
> What do you think?
>
>
>
> Regards,
>
> Greg
>
>
>
> On Thu, May 28, 2020 at 4:56 PM Kiran Makhijani <[email-masked]>
> wrote:
>
> Hi Greg,
>
> You are right. I should not have used term ‘virtual’ – I was visualizing a
> NF container in NBI data model. A user of transport slice just asks for a
> NF and associated properties. Whether it’s V- or P- is a realization time
> decision.
>
>
>
> I see NFs adding a lot of value from higher-layer perspective, without
> getting bogged down about network details users can attach app specific
> firewalls, IDS, and caching type of functions on the endpoints. These are
> all good examples for use of NFs in slices. Secondly you will be able to
> express your requirement from a single place instead of dealing with
> different interfaces.
>
>
>
> <your quote>
>
> the TS does not specify which NFs should compose the TS but only what is
> the functional behavior and performance provided by the TS.
>
> *^^^*
>
> I hope you agree that there’s a need for some “functional behavior”. If
> user can leverage provider network for that behavior, then why not?
>
> -Kiran
>
>
>
>
>
> *From:* Greg Mirsky <[email-masked]>
> *Sent:* Thursday, May 28, 2020 3:15 PM
> *To:* Kiran Makhijani <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [Teas-ns-dt] issue discussion: NF resource
>
>
>
> Hi Kiran,
>
> I think that an NF can be realized as a physical device or a VM. Would you
> agree? If that is the case, then, in my opinion, we cannot consider only
> the VNF case but add the PNF case as well.
>
> Also, I don't see the real benefit to have NF, in all their variety now
> and more in the future, as part of a TS. I think that NF is either part of
> the TS implementation and thus is selected by an operator based on the SLO.
> Or part of a service that uses the TS. In the model I have in mind, a
> client of the TS does not specify which NFs should compose the TS but only
> what is the functional behavior and performance provided by the TS.
>
>
>
> On Thu, May 28, 2020 at 12:06 PM Kiran Makhijani <[email-masked]>
> wrote:
>
> Hi All,
>
> During earlier discussions several of us asked for network functions
> should be part of the slices. For me the value of doing this is to be able
> to express different nuances of a service through single set of objectives.
> Then in NBI and implementation there is one controller to monitor the
> performance.
>
>
>
> At the entry and exit of transport slices, these NF can be supplied to
> enforce access control, policies, etc. on transport slice traffic. It is
> also safe to assume that they will be virtual.
>
>
>
> 2 examples are  (1) use of firewall at entry point with the rules
> described by the user of transport slice. (2) Caching or DPI function on
> exit endpoints.
>
>
>
>
>
> Regards
>
> Kiran
>
>
>
> --
> Teas-ns-dt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas-ns-dt
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas-ns-dt&data=02%7C01%7Ckiranm%40futurewei.com%7Cf693a0401cb94a59ee0708d80370c0f7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637263130100769061&sdata=ppr3yiBDq1%2BAZbFsYnhwGugLb27aVuEoBtBY45kXOdc%3D&reserved=0>
>
>

---

From: Jeff Tantsura <[email-masked]>
Date: Mon, 1 Jun 2020 13:52:51 -0700

Non networking related metrics for networking services are difficult/impossible to normalize, if I want a FW with a particular performance matrix, it wouldn't  a number of CPU’s/memory but rather PPS/number of sessions/tunnels, and obviously availability.
I’m not sure I understand what  “Minimum SLOs” are? A SLO has its boundaries , as long as the service delivered is within these boundaries - SLO is met, otherwise it isn't.

I really like to following simple definitions:

	  SLI						SLO						SLA
X should be true     	Y proportion of the time		      or else

Define SLIs and SLOs for specific capabilities at service boundaries.
Each logical instance of a service gets its own SLO.
Combine SLIs for a given capability into a single SLO for that capability.

Cheers,
Jeff
On Jun 1, 2020, 12:44 PM -0700, Greg Mirsky <[email-masked]>, wrote:
> As for your example, I think that we can expect an operator to be knowledgeable and experienced in mapping customer intentions into a particular technology the operator is using. That is where I'd leave space for operators and vendors to innovate and differentiate their products. What we can provide, in my view, is performance measurement methodology(ies) that will help customers to have quantitative representation of the TS service.
>
> Regards,
> Greg
>
> > On Mon, Jun 1, 2020 at 12:30 PM Kiran Makhijani <[email-masked]> wrote:
> > > Hi Greg,
> > > thank you for your kind consideration of my comments.. If we agree that a customer of a TS may specify a certain TS behavior that is externally observable on data packets, then I don't find where elements like "memory", "computing power" fit. I think that these are important to an operator when choosing the most economical and efficient method to realize the TS according to the specific LSO.
> > > What do you think?
> > >
> > > Regards,
> > > Greg
> > >
> > > On Thu, May 28, 2020 at 4:56 PM Kiran Makhijani <[email-masked]> wrote:
> > > > Hi Greg,
> > > > On Thu, May 28, 2020 at 12:06 PM Kiran Makhijani <kiranm@futurewei..com> wrote:
> > > > > Hi All,

---

From: Kiran Makhijani <[email-masked]>
Date: Mon, 1 Jun 2020 21:18:52 +0000

Eric,
What you call ‘feeling of incompleteness’ is bringing clarity to ‘what transport slice could do’, so it helps to mention this.

If we don’t mention NFs here, how will NBI and subsequent work consider this an option? I have heard arguments that NF can be controlled from the outside. – But  for certain users may want one interface and offloading this request by integrating in the slice should be possible.
The success of this document relies on clear picture of what transport slice mean for IETF. By omitting such cases, we will find ourselves repeating at some point later.
-Kiran

From: Eric Gray <[email-masked]>
Sent: Monday, June 1, 2020 12:42 PM
To: Kiran Makhijani <[email-masked]>; Greg Mirsky <[email-masked]>
Cc: [email-masked]
Subject: RE: [Teas-ns-dt] issue discussion: NF resource

Kiran,

--
Eric

From: Teas-ns-dt <[email-masked]<mailto:[email-masked]>> On Behalf Of Kiran Makhijani
Sent: Monday, June 1, 2020 3:30 PM
To: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Teas-ns-dt] issue discussion: NF resource

Hi Greg,

Hi Kiran,

Regards,
Greg

<your quote>

Hi Kiran,

Regards
Kiran

--
Teas-ns-dt mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas-ns-dt<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D13f15f38-4d51bfa6-13f11fa3-86ee86bd5107-e37de12ef421e70c%26q%3D1%26e%3D455b015e-c726-49bd-8723-a05f5cb4535e%26u%3Dhttps%253A%252F%252Fnam11.safelinks.protection.outlook.com%252F%253Furl%253Dhttps%25253A%25252F%25252Fwww.ietf.org%25252Fmailman%25252Flistinfo%25252Fteas-ns-dt%2526data%253D02%25257C01%25257Ckiranm%252540futurewei.com%25257Cf693a0401cb94a59ee0708d80370c0f7%25257C0fee8ff2a3b240189c753a1d5591fedc%25257C1%25257C0%25257C637263130100769061%2526sdata%253Dppr3yiBDq1%25252BAZbFsYnhwGugLb27aVuEoBtBY45kXOdc%25253D%2526reserved%253D0&data=02%7C01%7Ckiranm%40futurewei.com%7C97289e404c9e41f9c0c008d80663ca4b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637266372968329805&sdata=nlZpE3zUjvPOHR42sHFpC3W7n%2BDT9GC85tIs516sHD8%3D&reserved=0>

---

From: Eric Gray <[email-masked]>
Date: Mon, 1 Jun 2020 21:37:50 +0000

Jeff,

I agree with your observations regarding not especially relevant resource listing applied to network-specific behavioral objectives.

I suspect that Kiran’s goal is not so much about things typically done by a network, as about things that could be done on a network.  This is somewhat weakly justifiable in her argument that one might expect these to be a part of a network service, hence potentially provided by the network service itself.

If someone were going to elaborate on this, rather than saying “X CPUs” and/or “Y (words?) of memory”, it should include total processing capability and/or storage, possibly along with storage characteristics (e.g. – persistence, etc.).  As I believe I have said a number of times, the difficulty in nailing this down should be sufficient evidence that maybe we are not quite ready to do that.

But Kiran seems to be agreeing that this particular objective could be lumped with others as potential “additional” objectives (possibly  even to be specified later).

Where Kiran refers to “minimum objectives” I am pretty sure that she means the objectives that the authors feel must be included, at least as examples, initially.

I think that the fact that the authors feel this way is an encumbrance to progress, because (as has been pointed out before) this is a definitions draft, not a specification.  What we should strive for instead is to provide a reasonable set of example objectives that we can all live with.  We can extend this list in WG review (once the draft is adopted by the WG) – iff there is rough consensus to do so.

If we cannot achieve rough consensus on the content of this draft within the DT, how can we hope to do so in the WG?

By the way, I like the elegance of your example SLI --> SLO --> SLA (assuming that SLI = Service Level Indicator) as analogous to (paraphrasing) “How do I know the service is available?”, “Additional aspects of the objectives” (I suspect that Availability is not the only one), and “What can I do about it if the SLI/SLO is not met?”

But I think it answers a question not asked, and we would need to add a definition for “SLI” – which would be difficult to find, given that about one in twenty words in this draft include the letter sequence “SLI” in them.  😊

--
Eric

From: Teas-ns-dt <[email-masked]> On Behalf Of Jeff Tantsura
Sent: Monday, June 1, 2020 4:53 PM
To: Kiran Makhijani <[email-masked]>; Greg Mirsky <[email-masked]>
Cc: [email-masked]
Subject: Re: [Teas-ns-dt] issue discussion: NF resource

                SLI                                                                               SLO                                                                                SLA

Define SLIs and SLOs for specific capabilities at service boundaries.
Each logical instance of a service gets its own SLO.
Combine SLIs for a given capability into a single SLO for that capability..

Cheers,
Jeff
On Jun 1, 2020, 12:44 PM -0700, Greg Mirsky <[email-masked]<mailto:[email-masked]>>, wrote:

Hi Kiran,

Regards,
Greg

On Mon, Jun 1, 2020 at 12:30 PM Kiran Makhijani <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,
In order to resolve the issue:
Since the section is “Minimum SLOs”, I agree to “move it outside the minimal”.

Hi Kiran,

Regards,
Greg

<your quote>

Hi Kiran,
I think that an NF can be realized as a physical device or a VM. Would you agree? If that is the case, then, in my opinion, we cannot consider only the VNF case but add the PNF case as well.
Also, I don't see the real benefit to have NF, in all their variety now and more in the future, as part of a TS.. I think that NF is either part of the TS implementation and thus is selected by an operator based on the SLO. Or part of a service that uses the TS. In the model I have in mind, a client of the TS does not specify which NFs should compose the TS but only what is the functional behavior and performance provided by the TS.

On Thu, May 28, 2020 at 12:06 PM Kiran Makhijani <kiranm@futurewei..com<mailto:[email-masked]>> wrote:
Hi All,
To kick off discussion on this topic.

Regards
Kiran

--
Teas-ns-dt mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas-ns-dt<https://protect2.fireeye.com/v1/url?k=8ff04d97-d150ad0e-8ff00d0c-8682aaa22bc0-aac48d61d3ba6d3a&q=1&e=cf342757-4515-40b1-8879-0f28d04b8b76&u=https%3A%2F%2Fnam11.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fwww.ietf.org%252Fmailman%252Flistinfo%252Fteas-ns-dt%26data%3D02%257C01%257Ckiranm%2540futurewei.com%257Cf693a0401cb94a59ee0708d80370c0f7%257C0fee8ff2a3b240189c753a1d5591fedc%257C1%257C0%257C637263130100769061%26sdata%3Dppr3yiBDq1%252BAZbFsYnhwGugLb27aVuEoBtBY45kXOdc%253D%26reserved%3D0>
--
Teas-ns-dt mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas-ns-dt

---

From: Eric Gray <[email-masked]>
Date: Mon, 1 Jun 2020 21:48:24 +0000

Kiran,

I don’t object to including VNF resources as an objective under “additional objectives.”

At the same time, I am fairly certain that initial models for the NBI may not include this – especially as this can be added to the initial model via simple augmentation.

This is an important point, by the way: if we insist that the model used by the NBI should be a superset of everything anyone may someday want, we will be fighting a battle than has been lost every time in the past.  The usual success case is that core definitions are a subset that represents a “least common denominator” of functionality that most people are willing to support and that what people actually implement and deploy will include extensions that make it possible to access and use the “special qualities” of their own implementation/deployment.

--
Eric

From: Kiran Makhijani <[email-masked]>
Sent: Monday, June 1, 2020 5:19 PM
To: Eric Gray <[email-masked]>; Greg Mirsky <[email-masked]>
Cc: [email-masked]
Subject: RE: [Teas-ns-dt] issue discussion: NF resource
Importance: High

Eric,

From: Eric Gray <[email-masked]<mailto:[email-masked]>>
Sent: Monday, June 1, 2020 12:42 PM
To: Kiran Makhijani <[email-masked]<mailto:[email-masked]>>; Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [Teas-ns-dt] issue discussion: NF resource

Kiran,

--
Eric

Hi Greg,

Hi Kiran,

Regards,
Greg

<your quote>

Hi Kiran,

Regards
Kiran

--
Teas-ns-dt mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas-ns-dt<https://protect2.fireeye.com/v1/url?k=94bb6b2a-ca1bd144-94bb2bb1-869a14f4b08c-fc39b9eef9901178&q=1&e=ad3c2190-0ab4-4c8b-83ff-cc0f6dccff3f&u=https%3A%2F%2Fnam11.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fprotect2.fireeye.com%252Fv1%252Furl%253Fk%253D13f15f38-4d51bfa6-13f11fa3-86ee86bd5107-e37de12ef421e70c%2526q%253D1%2526e%253D455b015e-c726-49bd-8723-a05f5cb4535e%2526u%253Dhttps%25253A%25252F%25252Fnam11.safelinks.protection.outlook.com%25252F%25253Furl%25253Dhttps%2525253A%2525252F%2525252Fwww.ietf.org%2525252Fmailman%2525252Flistinfo%2525252Fteas-ns-dt%252526data%25253D02%2525257C01%2525257Ckiranm%25252540futurewei.com%2525257Cf693a0401cb94a59ee0708d80370c0f7%2525257C0fee8ff2a3b240189c753a1d5591fedc%2525257C1%2525257C0%2525257C637263130100769061%252526sdata%25253Dppr3yiBDq1%2525252BAZbFsYnhwGugLb27aVuEoBtBY45kXOdc%2525253D%252526reserved%25253D0%26data%3D02%257C01%257Ckiranm%2540futurewei.com%257C97289e404c9e41f9c0c008d80663ca4b%257C0fee8ff2a3b240189c753a1d5591fedc%257C1%257C0%257C637266372968329805%26sdata%3DnlZpE3zUjvPOHR42sHFpC3W7n%252BDT9GC85tIs516sHD8%253D%26reserved%3D0>