Re: [Nfvrg] Research Group Preparation (a.k.a. "Last Call") for draft-irtf-nfvrg-gaps-network-virtualization

[<[e-mail]>]

Dear Pierre,
Thanks for your clarification. If I would have read it more attentively from the beginning I may have not been misled. Perhaps in the first sentence something could be added as: ‘here – in comparison to other situations, as e.g. PNF testing - dedicated effort has to be spent for controlling the test environment (NFVI and MANO) to remain unchanged during the whole test’ ?
The second issue now is also clear. I simply missed the word ‚type‘ … ;-(

Thanks for your helping work!
Best Regards
Dirk

From: Pierre Lynch [mailto:[e-mail]]
Sent: Dienstag, 27. Juni 2017 12:08
To: von Hugo, Dirk
Cc: [e-mail]; [e-mail]
Subject: Re: [Nfvrg] Research Group Preparation (a.k.a. "Last Call") for draft-irtf-nfvrg-gaps-network-virtualization

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, [e-mail]<mailto:[e-mail]> 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:[e-mail]<mailto:[e-mail]>] On Behalf Of Diego R. Lopez
Sent: 28 April 2017 18:14
To: [e-mail]<mailto:[e-mail]>
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>)mp;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: [e-mail]<mailto:[e-mail]>
Tel:    [phone]<tel:+34%20913%2012%2090%2041>
Mobile: [phone]<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
[e-mail]<mailto:[e-mail]>
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