<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>Following last week IRC, please find below a suggestion to improve the description and the messaging to the wider community about NFV.</div>
<div><br>
</div>
<div>I think this group is a great initiative and very important to explain NFV to the wider developers community of OpenStack.</div>
<div>While NFV is becoming a more known term for the community (a new and good thing!) I feel there is still a gap in explaining why it needs special care. Or maybe more precise, do we want to claim it needs special care?</div>
<div>I would claim we shouldn’t think about it as “special” but as a great use case for OS with some fine tune needs that are relevant (in most) to other cases too.</div>
<div><br>
</div>
<div>So in our wiki we have few great starts.</div>
<ul>
<li>We have the HL description of ETSI NFV use case</li><li>We have the workloads types definition</li><li>We have the great section by Calum about two specific apps</li></ul>
<div>What we might consider as missing?</div>
<div>Answering questions like</div>
<ul>
<li>Why (it) is special ?</li><li>Why we need it now?</li><li>Who will use it and why it can’t be achieve otherwise?</li></ul>
<div>My feeling is that in order to explain the reasoning we need to emphasise the workloads types piece. </div>
<div>We want to avoid using special and specific NFV terms, because they are frightening and not relevant for the majority of the community.</div>
<div><br>
</div>
<div>So I would suggest to enrich the workload type section. Maybe add more options to explain availability schemes needs and other common cases like storing large files in burst or any other example.</div>
<div>In addition I would add a section for “transition” time needs just because of the state of the apps. A good example for it is the “VLAN” trunking BP. It feels more like a transition need (apps today are sending traffic with VLANs) rather than a long term
real need. In comparison to state or performance needs that have a better justification for the long term. My app owners friends, please don’t “jump” on the VLANs example, I assume we can argue about it…. I hope the point I am is clear though</div>
<div><br>
</div>
<div>Then for each section (type) answer the questions above and link the BPs to each of those “types”. </div>
<div><br>
</div>
<div>What we will achieve?</div>
<ul>
<li>Not having special NFV terms as part of the discussion with the community</li><li>Clear reasoning for the needs</li><li>Not position NFV as not “cloudy”</li></ul>
<div>If make sense, we can start and working on it.</div>
<div><br>
</div>
<div>Itai</div>
</body>
</html>