Subject: Re: [Nfvrg] Comments on draft-irtf-nfvrg-gaps-network-virtualization

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Tue, 27 Sep 2016 12:38:05 +0200

Hi Nicolas,

first of all, my apologies for the belated reply. I was on vacation
when you sent this e-mail and then I preferred to wait until we started
working on the new revision of the draft.

Thanks a lot for your comments. Please see comments in-line below.

On Fri, 2016-08-12 at 08:31 +0000, Kuhn Nicolas wrote:
> Dear all,
>  
> Thank you for providing this document. IMHO, the state-of-the art is
> clear and provides the necessary information
> to fully understand the document.

[Carlos] Thanks!

>  
> I have some minor comments (mostly related to the presentation) and a
> suggestion for a supplementary open research challenge.
>  
> - Section 4.2 : I am not a native speaker, but Service Guarantees
> does not ring a bell.
> I would propose something like "Guaranteeing quality-of-service"
> I would be worth providing a definition or examples at the beginning
> of this section.

[Carlos] OK, we'll change it to "Guaranteeing quality-of-service". We
will also add some examples.
>  
> "
>    An important difference between NFV and traditional Cloud
> computing
>    comes from the very strict requirements posed by NFV in terms of
>    performance, stability and consistency.  Although there are some
>    tools and mechanisms to improve this, such as Enhanced Performance
>    Awareness (EPA), SR-IOV, NUMA, DPDK, etc, these are still unsolved
>    challenges.  [I-D.natarajan-nfvrg-containers-for-nfv] analyzes
>    different virtualization technologies that could be used, instead
> of
>    just using VMs.
> "
> The objective of this paragraph is unclear to me and should be said
> more explicitly.
> The issue is guaranteeing a network quality-of-service, which is less
> of an issue for
> "traditional cloud computing". One open research issue is finding out
> technologies
> that are different from VM and more suitable for dealing with network
> functionalities.

[Carlos] OK, thanks. We'll adapt the text to clarify it.

>  
> " 
>    While the IPPM WG is a long running WG
>    that started in 1997 it does not have a charter item or active
> drafts
>    related to the topic of network virtualization.
> "
> Should the IPPM WG provide tools to evaluate enable metrics
> evaluation whatever the
> use case?
> The network virtualization is a technology and the NFVRG WG could use
> IPPM metrics to evaluate the quality-of-service.

[Carlos] Not sure I fully got your comment here. The point is that in
addition to using IPPM metrics as defined to evaluate quality-of-
service, there is also the need of metrics that evaluate the
performance of the network virtualization technology as such (e.g., if
chaining VNFs or VNFCs, latencies introduced by that, etc). Do you
think that can be tackled somehow also using IPPM work?

>  
> "
>    Related to the need of diagnostics tools, there is also a need in
>    terms of predictive analysis allowing for reaction before an
>    operation anomaly takes place.
> "
> This sentence is not clear to me.

[Carlos] The idea here was to mention that in order to promptly react
upon an anomaly (e.g., a server malfunction), it is required to have
monitoring and analytics tools in place that could identify signs of an
imminent problem. Do you think it'd help to add some text around those
lines in the document?

>  
> People usually "jump around" in RFCs, so providing a high level view
> of this section
> would help, such as:
> 4.2.1 Virtualization technologies
> 4.2.2 Metrics for NFV charaterization
> 4.2.3 Predictive analysis
> 4.2.4 Portability

[Carlos] OK, it's a good idea to add that structure to help identifying
the topics.

>  
> - Section 4.3 :
> I am not sure whether "energy efficiency" is the only performance
> related challenge
> for the network virtualization.
> There are many things that can be improved with network
> virtualization.
> We could imagine "latency reduction", "improved link usage", etc.
> I would propose to have a more general section:
> "Performance improvement", and this section could speak about energy
> efficiency as
> one of the things that can be improved.
> In short, section 4.2 could speak about "guaranteeing the same
> performance", while
> section 4.3 could be on "improving them". In this view, the
> discussion on the performance
> evaluation in section 4.2 could be done in a dedicated section, or
> 4.3 merged into 4.2.

[Carlos] Again, very good point. We'll follow your proposed approach.
>  
> - section 4.5 :
> What is "tactile Internet" ?

[Carlos] It a term now used to refer to a network with ultra low
latency requirements (like in the order of 1 ms or less for end-to-end
communications)

> You could also mention that network slicing is a key for introducing
> new actors in existing
> market at low cost - by letting new players rent "blocks" of
> capacity, if this new market
> provides performance that are adequate with the application needs.
> E.g. broadcasting updates to many sensors with satellite broadcasting
> capabilities.

[Carlos] OK, we'll add that text. Thanks.

>  
> - section 4.X :
> I think that one other research challenge for the NFV is to be a key
> driver in hybriding
> networks for better benefits from the various radios technologies. By
> deploying the VNF with
> the adequate parameterization, it could be easier to assess the
> mobile(LTE)/fix(WiFi)
> or the broadband/broadcast paradigms. This induces discussions on
> aggregation networks in
> which the VNF would be deployed. This efficient usage of the
> available radio access
> technologies, such as WiFi, LTE and satellite, is also one of the
> objectives of the 5G. 
> This discussion may be worth putting in the "network slicing" section
> ?

[Carlos] I tend to agree but not yet grasp all your point. Can you
suggest some specific text that you feel could be added to the section
on "network slicing"?

> I hope that this helps.

[Carlos] It does indeed. Thanks a lot!

Carlos

>  
> Kind regards,
>  
> Nico
> _______________________________________________
> Nfvrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/nfvrg