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

From: "Evangelos Haleplidis" <[email-masked]>
Date: Mon, 29 May 2017 00:52:38 +0300

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.

#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?

#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?

#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? 

#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.

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

#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?

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

Also, three general comments:

#A. I do agree with Kostas’s earlier mail about a few places where the document is a bit gratuitous.

#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. 

#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.

Regards,

Evangelos.

From: Nfvrg [mailto:[email-masked]] On Behalf Of Diego R. Lopez
Sent: Friday, April 28, 2017 19:14
To: [email-masked]
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/). 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: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

  _____  

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

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Mon, 29 May 2017 19:53:05 +0200

Hi Evangelos,

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

On Mon, 2017-05-29 at 00:52 +0300, Evangelos Haleplidis wrote:
> #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.

> 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

> 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:
> 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,
>  
> --
> 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
> [email-masked]
> https://www.irtf.org/mailman/listinfo/nfvrg