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

[Carlos Jesús Bernardos Cano <[e-mail]>]

Hi Evangelos,

Thanks a lot for your comments. Please see inline below.

On Mon, 2017-05-29 at 00:52 +0300, Evangelos Haleplidis wrote:
> Greetings,
>  
> Just a few, mostly editorial, comments on the draft.
>  
> #1. Is there a reason for why the OpenFlow protocol is mentioned in
> the terminology section of the draft? It is used only in the SDN
> section and expanded there as well.

[Carlos] We just wanted to expand/explain on all the terms used in the
document, but there is no additional reason. Do you think we should
skip mentioning it the terminology section?

>  
> #2. Since you mention both ONF’s and IETF’s architectural view on
> SDN, do you think it makes sense to include ITU’s view on it as well?

[Carlos] That's a godo point. I personally don't know well the details
about ITU's view. Is there any public available document that I can
check?

>  
> #3. Would it make sense in section 3.6 to elaborate which open source
> initiatives deal with NFV or SDN issues and how they interact or
> address some of the network virtualization research issues?

[Carlos] That's a good point (also related to a comment made by
Kostas). We'll try to do so in the next revision.

>  
> #4. Section 4.2.1 “NFV poses very strict requirements posed in terms
> of performance, stability and consistency”. How about: “NFV has very
> strict requirements posed …” or something similar?

[Carlos] OK. We'll fix it.

>  
> #5. In section 4.5.2, you have “FOG” with capital letters. I guess
> you mean fog infrastructures, but if you meant FOG as acronym please
> expand.

[Carlos] Yes, we mean "fog" as the extension of the cloud beyond the
edge to the very access and even the end-user devices. We'll clarify
this point.

>  
> #6. Section 4.9 “…taking profit of the programmability brought by
> SDN…”, how about “…taking advantage of the programmability brought by
> SDN…”

[Carlos] OK. We'll fix it.

>  
> #7. Same section: “Clear mechanisms for such interaction are needed
> in order to avoid mal-functioning or interference among concerns”.
> Malfunction should not have a “-“ and I didn’t understand the “among
> concerns”. Do you mean that malfunctioning and interference are some
> implementation concerns?

[Carlos] OK, I see that this sentence needs to be fixed (I think
"among" has to be simply removed). We'll do that.

> 
> #8. The section name of 4.10.3. “Opportunities” doesn’t actually
> specifies a meaningful category. How about “Test softwarization” or
> something more appropriate?

[Carlos] OK, we'll fix that.

>  
> Also, three general comments:
> #A. I do agree with Kostas’s earlier mail about a few places where
> the document is a bit gratuitous.

[Carlos] We'll try to fix that. If you have additional parts where you
think we should revise the text in that respect, please let us know.

> 
> #B. While this document includes a lot of references from the
> standards’ bodies, it is very lacking in references from the
> academia. In truth you have only two. While I agree that this draft
> shouldn’t any exhaustive literacy review, I feel that the document
> would greatly be improved by the inclusion of references to active
> research on the challenge items you have enumerated.

[Carlos] That is a good, but tricky point. We'll evaluate adding more
research references in the next revision.

>  
> #C. In section 4, I think that you may need to include the “Network
> Function placement”. Imho, this is a very important challenge which
> has much impact on the efficiency and performance of any virtualized
> network. Yaakov Stein had a great presentation a few IETF’s ago with
> a nice approach to that problem.

[Carlos] Fully agree. We'll do that.

Thanks a lot for your very good and constructive comments.

Carlos

>  
> Regards,
> Evangelos.
>                                                                      
>                                        
> From: Nfvrg [mailto:[e-mail]] On Behalf Of Diego R.
> Lopez
> Sent: Friday, April 28, 2017 19:14
> To: [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-ne
> twork-virtualization/). 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/
> 
> e-mail: [e-mail]
> Tel:    [phone]
> Mobile: [phone]
> ----------------------------------
>  
> 
> 
> 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]
> https://www.irtf.org/mailman/listinfo/nfvrg