Hello Dirk,

I am helping Carlos deal with the comments with the section that I wrote (4.10 
testing). I’d like to try to understand the comment you made below for page 25. 
I’ll try to explain what I am trying to say, and maybe we can converge.



p.25:
IMO most of the text is true in any test case and very general (not VNF 
specific) as “The only variables in the testing should be those controlling the 
SUT itself”
… the workload type the expected VNF will be => … the workload type the 
expected VNF will be characterized by [?]


“The only variables in the testing should be those controlling the SUT itself”

The whole point here is that the SUT (VNF in the discussion in the document) is 
not isolated from an environment in the case of NFV. The environment, that I 
call “test environment” in the document, in the case of a VNF under test, is 
the NVFI and MANO. You can’t test the VNF without those components being 
present, so the only thing you can do is to control the test environment (MANO 
+ NFVI) such that it is constant. You should only modify configurations related 
to the SUT (VNF in this case). This is a major difference with PNF testing, and 
that’s been acknowledged in other bodies as well (ETSI NFV for example)

the workload type the expected VNF will be => … the workload type the expected 
VNF will be characterized by [?]

A VNF will have a certain workload type. It will be control plane, or packet 
forwarding, or encryption, for example. The point is to identify the nature of 
the workload, in order to determine the metrics that should be measured in a 
performance test of the NFVI. That will become the characterization metrics. 
That’s the thought process. That will become the metrics used for NFVI 
characterization

Thanks,

Pierre




On Jun 9, 2017, at 9:41 AM, 
dirk.von-h...@telekom.de<mailto:dirk.von-h...@telekom.de> wrote:

Dear authors, all
I have read the 05 version and think the document is nearly ready for 
publication – provided some nits are corrected and clarifications addressed. In 
the following I tried to not repeat what has already been said earlier – sorry 
in case I didn’t succeed ;-/

p.3:
load- aware => load-aware

p.7:
requires of complex => requires complex

p.10:
In addition to the these interactions => In addition to these interactions
with each oter? etc. => with each other? etc.

p.15:
SR-IOV, NUMA, DPDK, etc : Should the acronyms be explained?

p.18:
looked as well. => looked at as well.

p.19:

a battery life thousands of times longer compared to => a battery life time 
exceeding by a factor of thousands that of
if this new market provides performance that are adequate with => if the new 
business model enables performance that meets  [?]
The widespread of system and network virtualization technologies => The 
widespread use/discussion/practice of system and network virtualization 
technologies
is responsible of the reliability => is responsible for the reliability

p.20:
situations in which an VNO requires => situations in which a VNO requires
protocol proposed by the WEBPUSH WG => add reference here: [RFC8030] ?
to rely on specific adatpation mechanisms => to rely on specific adaptation 
mechanisms
An specific example can be => A specific example can be

p.21:
network, not necessary on the direct data path => network, not necessarily on 
the direct data path

p.23:
administrative domain controlled by an operator => administrative domain 
controlled by (exactly) one operator
Especially, if each data center is protected => This holds true/this is the 
case in particular, if each data center is protected [no complete sentence 
otherwise IMO]

p.25:
IMO most of the text is true in any test case and very general (not VNF 
specific) as “The only variables in the testing should be those controlling the 
SUT itself”
… the workload type the expected VNF will be => … the workload type the 
expected VNF will be characterized by [?]

p.26:
collection of new functionality / set of functionality => collection of new 
functionalities / set of functionalities [?]

Thanks and Best Regards
Dirk
From: Nfvrg [mailto:nfvrg-boun...@irtf.org<mailto:nfvrg-boun...@irtf.org>] On 
Behalf Of Diego R. Lopez
Sent: 28 April 2017 18:14
To: nfvrg@irtf.org<mailto:nfvrg@irtf.org>
Subject: [Nfvrg] Research Group Preparation (a.k.a. "Last Call") for 
draft-irtf-nfvrg-gaps-network-virtualization

Hi,

As discussed and agreed in our meeting in Chicago, this message is to open the 
equivalent of a last-call for our draft on NFV research challenges 
(https://datatracker.ietf.org/doc/draft-irtf-nfvrg-gaps-network-virtualization/<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-irtf-nfvrg-gaps-network-virtualization%2F&data=02%7C01%7Cplynch%40ixiacom.com%7C5581fbf76d1b46fa785608d4af3d4f83%7C069fd614e3f843728e18cd06724a9b23%7C0%7C0%7C636326125245796125&sdata=eF1jz8quEahMoOz7ximuQNUnyijVV5e3OTXsxUVeqxI%3D&reserved=0>).
 Note I use the term “equivalent to last-call”, as the IRTF process described 
in RFC 5743 uses the term “Research Group Preparation”. Let me remind you the 
summarized IRTF process as described in RFC 5743:

   o  The Research Group (RG) performs a thorough technical and

      editorial review of the document and agrees it should be

      published.



   o  The Internet Research Steering Group (IRSG) reviews the document

      and approves it for publication.

   o  The Internet Engineering Steering Group (IESG) reviews the

      document to assure that there are no conflicts with current or

      expected standardization activities.



   o  The document is submitted to the RFC Editor for publication.

So we are starting the first step above, and all of you are encouraged to 
review the document and share your comments and opinions about moving it 
forward towards publication. Since it is advisable to put a deadline for this 
kind of process, let’s go for a one month period, that is until the 28th May.

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpeople.tid.es%2Fdiego.lopez%2F&data=02%7C01%7Cplynch%40ixiacom.com%7C5581fbf76d1b46fa785608d4af3d4f83%7C069fd614e3f843728e18cd06724a9b23%7C0%7C0%7C636326125245796125&sdata=xsx%2FvnNmakAKBz8ZLkjxDZH8KrUbeyx5SMOvVeFm0jg%3D&reserved=0>

e-mail: diego.r.lo...@telefonica.com<mailto:diego.r.lo...@telefonica.com>
Tel:    +34 913 129 041<tel:+34%20913%2012%2090%2041>
Mobile: +34 682 051 091<tel:+34%20682%2005%2010%2091>
----------------------------------

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede 
contener información privilegiada o confidencial y es para uso exclusivo de la 
persona o entidad de destino. Si no es usted. el destinatario indicado, queda 
notificado de que la lectura, utilización, divulgación y/o copia sin 
autorización puede estar prohibida en virtud de la legislación vigente. Si ha 
recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente 
por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential 
information intended only for the use of the individual or entity named above. 
If the reader of this message is not the intended recipient, you are hereby 
notified that any dissemination, distribution or copying of this communication 
is strictly prohibited. If you have received this transmission in error, do not 
read it. Please immediately reply to the sender that you have received this 
communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode 
conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa 
ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica 
notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização 
pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem 
por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e 
proceda a sua destruição

_______________________________________________
Nfvrg mailing list
Nfvrg@irtf.org<mailto:Nfvrg@irtf.org>
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.irtf.org%2Fmailman%2Flistinfo%2Fnfvrg&data=02%7C01%7Cplynch%40ixiacom.com%7C5581fbf76d1b46fa785608d4af3d4f83%7C069fd614e3f843728e18cd06724a9b23%7C0%7C0%7C636326125245796125&sdata=jyCuF53c6tAQ868ykzif6HZNEascCJgUfQSQ2S6wmHs%3D&reserved=0

_______________________________________________
Nfvrg mailing list
Nfvrg@irtf.org
https://www.irtf.org/mailman/listinfo/nfvrg

Reply via email to