No you got it right – I didn’t do that good of job of putting it together so
you did great.
One thing I completely missed is that a “implementation use case” consider
the system an “actor” so we have to identify the frameworks in the actor as
part of the use case.
i.e. – we have to identify the underlying management framework as I put in the
prior message.
It probably would have been nice if I started off with that ☺ - my
apologies for the choppy response.
Best regards,
Mike
From: "Kunzmann, Gerald" <[email protected]>
Date: Friday, October 7, 2016 at 8:53 AM
To: "Bugenhagen, Michael K" <[email protected]>, "Kashyap,
Madhu" <[email protected]>, "Gangur, Hrushikesh"
<[email protected]>, Arturo Martin De Nicolas
<[email protected]>, "[email protected]"
<[email protected]>
Cc: "Souville, Bertrand" <[email protected]>, "Thulasi, Arun"
<[email protected]>
Subject: RE: [opnfv-tech-discuss] [Promise]Capacity Management User Story
Hi Mike,
Your thoughts are highly valuable and appreciated.
Isn’t the current OpenStack already the platform / environment that we are
talking about? I agree that the platform providers’ interest is to create a
common framework that fits as many users as possible. Isn’t it then now the
stage to write down our specific Telco use cases and based on that identify the
gaps and let the “innovative program coders” expand the(ir) platform to meet
our use cases?
Also, the PWG has already defined this kind of template/approach and somehow if
we want to bring our use cases/requirements through the PWG we should follow
it. It would be a different story and we would need to include the PWG folks if
we want to fundamentally question/change their approach proposing a different
value path.
Or did I mis-read your message?
Best regards,
Gerald
From: Bugenhagen, Michael K [mailto:[email protected]]
Sent: Freitag, 7. Oktober 2016 15:32
To: Kunzmann, Gerald <[email protected]>; Kashyap, Madhu
<[email protected]>; Gangur, Hrushikesh <[email protected]>; Arturo
Martin De Nicolas <[email protected]>;
[email protected]
Cc: Souville, Bertrand <[email protected]>; Thulasi, Arun
<[email protected]>
Subject: Re: [opnfv-tech-discuss] [Promise]Capacity Management User Story
Gerald,
I’m going to suggest a slightly different “value” path -
First establish what the framework for delivering capacity is - THEN see if
one can use it to satisfy the use cases, and identify the gaps.
In compute, and Cloud when one makes a platform / Environment, you don’t do a
use case on every application that can be made, you document the platform, and
how it functions and then you let the innovative program coders expand how to
use it.
i.e. – you expose a framework, they utilize it.
The role of the platform provider is to evolve and maintain a common
framework that works for all the users… vs. trying to build every single user
story
In a closed system dev. View one does create all the system use, cases – in
Open platforms / OS efforts we’re really more focused enabling the environment
/ platform vs. depicting all the users stories.
So – I would recommend identifying the “frameworks” for “resource
management” and “use management” in both the Telecom bearer path, and the Cloud
service platforms “first” and then use those frameworks to describe what can be
done, and what gaps exist.
Example
a) What are the “components” (resource levels) or entities we are
applying use control (CAC) to
b) Identify what “utilization frameworks” do those components use
c) Identify the “load sharing / dedicated” resource schema those
components use (what are the algorithms used across the resource entity for
weighted, dedicated, or shared use).
Providers “do this” when designing our platform design.
Aka - QoS marking built for QoE goals.. in our forwarding plane q’s.
We need to do the same exercise here. What are the QoS
mechanisms in Cloud, and how are they applied to reach what you are describing.
I think the framework itself is going to be a tricky thing because different
NFVI hosts have different resource and use algorithms…
Anyway – just sharing my thoughts.
Thanks,
Mike
From:
<[email protected]<mailto:[email protected]>>
on behalf of "Kunzmann, Gerald"
<[email protected]<mailto:[email protected]>>
Date: Friday, October 7, 2016 at 5:38 AM
To: "Kashyap, Madhu" <[email protected]<mailto:[email protected]>>,
"Gangur, Hrushikesh"
<[email protected]<mailto:[email protected]>>, Arturo Martin De
Nicolas
<[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>
Cc: "Souville, Bertrand"
<[email protected]<mailto:[email protected]>>, "Thulasi,
Arun" <[email protected]<mailto:[email protected]>>
Subject: Re: [opnfv-tech-discuss] [Promise]Capacity Management User Story
Hi Madhu,
I agree with the increase of complexity. Looking at the other use cases, they
are much more simply/short.
In order not to confuse others and to get the important use cases agreed soon,
I propose to limit the changes and consider to add some details –if needed- at
a later stage.
Detailed comments:
- Existing text introduces cloud service providers (CSP). The new
proposed text adds the same abbreviation for Communication Service Providers.
This should be avoided.
- Proposal to shorten/simplify the new paragraph on VNFs and VNFDs?
- What you call generic reservation is already an agreed use case, so
we should keep this level of granularity and also IMHO we should not
touch/change other use cases as we haven’t talked to the contributor of those
use cases and may not know their intention behind.
- The proposed part on “minimal set of parameters” could be
misleading as we would like to have the option to specify those parameters, but
we don’t want to enforce those parameters to all use cases, i.e. the parameter
shall be available but its usage is optional.
What about changing this part to use cases that require those parameters?
· Start time: is already there in the existing use cases: future start
time in 1+2; immediate start time in 3 (to be more explicit on this we could
add a “from now”, but IMHO no strong need).
· Expiry time: I had a proposal in my first draft of this (see email
August 25th):
* As a CSP, I want to be able to cancel a RUR if the user has not started using
the requested capacity in a given time window after the planned start time of
the RUR. Note, this is similar to a "no-show" rule for hotel and restaurant
bookings.
We could also hold back this item for the time being and add it in a later
revision once the main part on the reservation of instances is approved.
· Compute (vCPU, RAM), network and storage volume are already covered
by other use cases.
“Future items” can be added in a later revision.
See also the attached revision of the document.
Best regards,
Gerald
From: Kashyap, Madhu [mailto:[email protected]]
Sent: Donnerstag, 6. Oktober 2016 00:48
To: Kunzmann, Gerald
<[email protected]<mailto:[email protected]>>; Gangur,
Hrushikesh <[email protected]<mailto:[email protected]>>;
Arturo Martin De Nicolas
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>
Cc: Souville, Bertrand
<[email protected]<mailto:[email protected]>>; Thulasi,
Arun <[email protected]<mailto:[email protected]>>; Ashiq Khan
<[email protected]<mailto:[email protected]>>
Subject: RE: [Promise]Capacity Management User Story
Perhaps this is getting a little complicated with different reservation
requests (discrete or aggregate) and confidence levels (guaranteed or best
effort).
Here’s another proposal – we have reservations either against specific VNFs or
we have generic reservations.
In the case of reservations for specific VNFs we know the exact requirements
from a virtual machine perspective which is based on VNFD. The granularity of
the reservation is a virtual machine.
The other kind of reservation is a generic reservation, similar to “I want 60
vCPUs, 240 gig ram and 600 Gig disk”. Here the granularity is more fine-grained.
In both cases the reservations, specific or generic, would be guaranteed if
the resources are available. In the generic reservation we don’t know how the
resources would be used. It is possible that the resources are spread across
many hosts. Let’s take an extreme case based on a request for 60 vCPUs. These
could be spread across 60 hosts. So even though these were requested and
reserved it is possible that when you go to deploy a VM it could fail. This is
because we don’t know how these resources are going to be used even though it
has been reserved.
Again in both requests (specific or generic) we guarantee the resources but for
the generic request it is up to the operator on how they use the resources.
Welcome any thoughts and comments.
-Madhu
From: Kunzmann, Gerald [mailto:[email protected]]
Sent: Thursday, September 29, 2016 3:24 AM
To: Kashyap, Madhu <[email protected]<mailto:[email protected]>>;
Gangur, Hrushikesh
<[email protected]<mailto:[email protected]>>; Arturo Martin De
Nicolas
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>
Cc: Souville, Bertrand
<[email protected]<mailto:[email protected]>>; Thulasi,
Arun <[email protected]<mailto:[email protected]>>; Ashiq Khan
<[email protected]<mailto:[email protected]>>
Subject: RE: [Promise]Capacity Management User Story
Hi Madhu, all,
Thanks for the updated version based on the PWG discussions.
My comments:
- I would not use the term “best-effort” for the reservation requests
as we also would like to get a guarantee on the requested aggregated resources.
o What about the terms “discrete” and “aggregate”?
o Alternatively, introduce two levels of granularity “discrete” /
“aggregate” and in addition introduce two levels of “confidence”, i.e.
“guaranteed” vs “planned (best-effort)”, where you can indicate a) that you
want to do a reservation to have a guaranteed access to the resources or b)
you inform the CSP about the planned usage of resources such that the CSP can
improve his capacity mgmt..
§ Should we distinguish between a resource reservation request (RRR) and a
planned resource usage notification (RUN)?
o
- I am not sure about the term “prescribed”; would you use it when
talking about the VNFD or did you mean s/prescribed/described/ ?
Best regards,
Gerald
From: Kashyap, Madhu [mailto:[email protected]]
Sent: Mittwoch, 28. September 2016 20:37
To: Kunzmann, Gerald
<[email protected]<mailto:[email protected]>>; Gangur,
Hrushikesh <[email protected]<mailto:[email protected]>>;
Arturo Martin De Nicolas
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>
Cc: Souville, Bertrand
<[email protected]<mailto:[email protected]>>; Thulasi,
Arun <[email protected]<mailto:[email protected]>>; Ashiq Khan
<[email protected]<mailto:[email protected]>>
Subject: RE: [Promise]Capacity Management User Story
Hi Gerald and all,
Based on the call from a couple weeks ago, I have made some changes to reflect
what we discussed.
The main point is that there are two kinds of reservation requests:
1. Guaranteed – this is based on discrete, specific requests as described
in the VNFD
2. Best-effort – these are requests based on aggregate resources such as
“give me 60 vCPUs, 240 Gig RAM, 600 GIG disk etc.”
Please review the attached doc in detail and provide feedback.
Let’s try to close on this soon so we can provide the reviews back to PWG.
Best regards
-Madhu
From: Kunzmann, Gerald [mailto:[email protected]]
Sent: Thursday, September 22, 2016 2:47 AM
To: Gangur, Hrushikesh
<[email protected]<mailto:[email protected]>>; Kashyap, Madhu
<[email protected]<mailto:[email protected]>>; Arturo Martin De Nicolas
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>
Cc: Souville, Bertrand
<[email protected]<mailto:[email protected]>>; Thulasi,
Arun <[email protected]<mailto:[email protected]>>; Ashiq Khan
<[email protected]<mailto:[email protected]>>
Subject: RE: [Promise]Capacity Management User Story
Dear all,
I have had the chance to discuss this document with Arturo in today’s Promise
call and I have updated the document based on his comments – see attachment.
Best regards,
Gerald
From: Kunzmann, Gerald
Sent: Dienstag, 20. September 2016 17:51
To: 'Gangur, Hrushikesh'
<[email protected]<mailto:[email protected]>>; Kashyap, Madhu
<[email protected]<mailto:[email protected]>>; Arturo Martin De Nicolas
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>
Cc: Souville, Bertrand
<[email protected]<mailto:[email protected]>>; Thulasi,
Arun <[email protected]<mailto:[email protected]>>; Ashiq Khan
<[email protected]<mailto:[email protected]>>
Subject: RE: [Promise]Capacity Management User Story
Dear all,
Sorry for the delay, I had been on a 2 week vacation.
Attached a new version addressing, amongst others, Arturo’s comments.
@Madhu: Can you try to finalize the document and input it to the next meeting
of the PWG?
Best regards,
Gerald
From: Gangur, Hrushikesh [mailto:[email protected]]
Sent: Dienstag, 13. September 2016 20:37
To: Kashyap, Madhu <[email protected]<mailto:[email protected]>>;
Arturo Martin De Nicolas
<[email protected]<mailto:[email protected]>>;
Kunzmann, Gerald
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>
Cc: Souville, Bertrand
<[email protected]<mailto:[email protected]>>; Thulasi,
Arun <[email protected]<mailto:[email protected]>>
Subject: RE: [Promise]Capacity Management User Story
Madhu – looks good and see my comments with emphasis on VNFD being a primary
source of RUR elements.
From: Kashyap, Madhu
Sent: Tuesday, September 13, 2016 11:01 AM
To: Arturo Martin De Nicolas
<[email protected]<mailto:[email protected]>>;
Kunzmann, Gerald
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>
Cc: Souville, Bertrand
<[email protected]<mailto:[email protected]>>; Thulasi,
Arun <[email protected]<mailto:[email protected]>>; Gangur, Hrushikesh
<[email protected]<mailto:[email protected]>>
Subject: RE: [Promise]Capacity Management User Story
Hi,
I have edited the document to reflect the scope of the RUR. Please review and
comment. Also added a few comments.
Arturo, I have not addressed your comments. Perhaps Gerald can shed some light
on your comments.
Best Regards
-Madhu
From: Arturo Martin De Nicolas [mailto:[email protected]]
Sent: Thursday, September 08, 2016 1:14 AM
To: Kunzmann, Gerald
<[email protected]<mailto:[email protected]>>; Kashyap,
Madhu <[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>
Cc: Souville, Bertrand
<[email protected]<mailto:[email protected]>>; Thulasi,
Arun <[email protected]<mailto:[email protected]>>; Gangur, Hrushikesh
<[email protected]<mailto:[email protected]>>
Subject: RE: [Promise]Capacity Management User Story
Hi Madhu, Gerald, all.
Please, see some comments from my side.
Best regards,
Arturo
From:
[email protected]<mailto:[email protected]>
[mailto:[email protected]] On Behalf Of Kunzmann,
Gerald
Sent: Friday, September 02, 2016 12:06 PM
To: Kashyap, Madhu;
[email protected]<mailto:[email protected]>
Cc: Souville, Bertrand; Thulasi, Arun; Gangur, Hrushikesh
Subject: Re: [opnfv-tech-discuss] [Promise]Capacity Management User Story
Hi Madhu, all,
Find attached a commented version of the user story. I believe we need to do
further changes to make it read more like a user story instead of specific
detailed requirements. I am not sure defining requirements would be accepted by
the PWG.
Looking forward to your feedback.
Best regards,
Gerald
From:
[email protected]<mailto:[email protected]>
[mailto:[email protected]] On Behalf Of Kashyap, Madhu
Sent: Donnerstag, 1. September 2016 20:19
To:
[email protected]<mailto:[email protected]>
Cc: Gangur, Hrushikesh
<[email protected]<mailto:[email protected]>>; Thulasi, Arun
<[email protected]<mailto:[email protected]>>
Subject: [opnfv-tech-discuss] [Promise]Capacity Management User Story
Hi,
As discussed during the call, attached is the capacity management user story
with my edits. Please review and provide comments. Also think about the
granularity of the scope the reservation request.
Thanks
-Madhu
This communication is the property of CenturyLink and may contain confidential
or privileged information. Unauthorized use of this communication is strictly
prohibited and may be unlawful. If you have received this communication in
error, please immediately notify the sender by reply e-mail and destroy all
copies of the communication and any attachments.
This communication is the property of CenturyLink and may contain confidential
or privileged information. Unauthorized use of this communication is strictly
prohibited and may be unlawful. If you have received this communication in
error, please immediately notify the sender by reply e-mail and destroy all
copies of the communication and any attachments.
_______________________________________________
opnfv-tech-discuss mailing list
[email protected]
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
