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, 5 Jun 2017 23:35:47 +0300

Greetings Carlos,

Nice job with the draft btw.

Please see responses inline.

Regards,
Evangelos.

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

[EH] Well, OpenFlow is an implementation choice mostly. There are a number of other solutions for SDN related that people have used. So, imho I don't think that it fits on the terminology section for such a type of document. 

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

[EH] ITU's initial view was this reference:
ITU, "Framework of software-defined networking", ITU Recommendation Y.3300, June 2014, <http://www.itu.int/rec/T-REC-Y.3300-201406-I/en>.
This is from 2014. I'm not sure if an updated or a new version exists.

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

[EH] Well, this is really very minor, but in section 3.6, you mention only Openstack for the open source cloud computing software. There are a couple more. You could make that bullet more generic and reference more open source activites like openstack, or add another bullet for an additional example. Just so that you're not limited to one example per area.

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

[EH] You don't need to be thorough. Just point to a couple of other research papers.
How about this one for a more generic reference to research challenges:
[1] Mijumbi, Rashid, Joan Serrat, Juan-Luis Gorricho, Niels Bouten, Filip De Turck, and Raouf Boutaba. "Network function virtualization: State-of-the-art and research challenges." IEEE Communications Surveys & Tutorials 18, no. 1 (2016): 236-262.

---

From: Angeles Vazquez-Castro <[email-masked]>
Date: Tue, 6 Jun 2017 02:18:04 +0200

Dear Carlos,

thanks for your efforts and so sorry for my late review. 
I have no much to add to previous good reviews, just perhaps three comments:

1) It is not clear what is the underlying reasoning for selecting the points within Section 3 of Background (except 3.1 and 3.2, clear background concepts). Therefore, maybe just a small introductory paragraph may be helpful here.

2)  Differently to other sections, Section 4.5 perhaps seems a bit inconclusive. It mostly describes facts instead of identifying concrete open issues related to virtualisation. Just to clarify what I mean, the following seems an assertion of capabilities rather than a description of an open issue:
"virtualization techniques can allow tailoring the network resources on separate slices, specifically for each radio
   access network and use case, in an efficient manner."

2) As already pointed out, there exist research studies from academia that might be relevant to be listed here. They provide complementary views to standardisation viewpoint and potential practical solutions.

Thanks, Ángeles

>>> reason for why the OpenFlow protocol is mentioned in
> _______________________________________________
> Nfvrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/nfvrg

---

From: Barbara Martini <[email-masked]>
Date: Tue, 6 Jun 2017 16:19:27 +0200

Dear Carlos,

I also react to the call for reviewing the document, even though a bit 
late. Thank you for the effort you put in preparing this thorough 
document. I also have no much to add to other previous reviews that have 
been already given. My few comments below:

1- I agree with the previous comment for the need of a higher focus to 
the "multi-domain" area. Other then the suggested topic 
"integration/harmonization of different management domains" I would also 
suggest the issue "orchestration in multi-domains". Indeed, with the 
existing frameworks including MANO, it is not possible to orchestrate 
service functions from different provider domains. In this regards, 
Service Oriented Architecture (SOA) indeed could provide a reference 
framework and guidelines. As for NFV deployments following SOA 
implementation frameworks, instead, differences between application 
services and VNFs should be taken into account due to the different way 
they are deployed and implemented.

2- As a further Open Source initiative I suggest SONA (Simplified 
Overlay Network Architecture) that is an extension to ONOS to have a 
almost full SDN network control in OpenStack for virtual tenant network 
provisioning. Basically, SONA is a SDN-based network vitualization 
solution for Cloud DC. See more detail in 
https://wiki.onosproject.org/display/ONOS/SONA%3A+DC+Network+Virtualization. 
SONA can be listed as a separate additional item in the section 3.6 or 
as further information under ONOS (or OpenStack) item.

3- In section 4.2 just before the list of potential gaps you report the 
actual work items. Does the (iv) item refer to the draft "Service 
Function Chaining (SFC) Control Plane Components & Requirements" (i.e., 
draft-ietf-sfc-control-plane-08). If not, it should be somehow 
mentioned. Indeed, it defines control functions and interface reference 
points regulating the set-up of service chaining as well as their 
lifecycle management. It also states the need to support various 
resiliency policies (i.e., bypass a node embedding an SF, use alternate 
node, use alternate chain, drop traffic, etc.), the need to report 
enhanced status information (e.g., operational status of service 
chain/service components), the need of load balancing to improve 
liveness and the need of failure detection and recovery. So the 
reliability is considered as requirements even though not fully addressed.

4- I support other comments suggesting the citation of academic works in 
the draft. To this purpose, I suggest:  Ahmed M. Medhat et al. "Service 
Function Chaining in Next Genearation Networks: State of the Art ad 
Research Challenge" that also deals with network virtualization. In 
particular as a gap, it state the need of traffic-engineering solutions 
to address the QoS requirements and network performance specification in 
virtual networks for SFC.

My two cents...

Best regards,

Barbara

Il 06/06/2017 02:18, Angeles Vazquez-Castro ha scritto:
> 1) It is not clear what is the underlying reasoning for selecting the 
> points within Section 3 of Background (except 3.1 and 3.2, clear 
> background concepts). Therefore, maybe just a small introductory 
> paragraph may be helpful here.
>
> 2)  Differently to other sections, Section 4.5 perhaps seems a bit 
> inconclusive. It mostly describes facts instead of identifying 
> concrete open issues related to virtualisation. Just to clarify what I 
> mean, the following seems an assertion of capabilities rather than a 
> description of an open issue:
> 2) As already pointed out, there exist research studies from academia 
> that might be relevant to be listed here. They provide complementary 
> views to standardisation viewpoint and potential practical solutions.
>
> Thanks, Ángeles
>
>
>> [EH] Well, OpenFlow is an implementation choice mostly. There are a 
>> number of other solutions for SDN related that people have used. So, 
>> imho I don't think that it fits on the terminology section for such a 
>> type of document.
>>
>>>>
>> ITU, "Framework of software-defined networking", ITU Recommendation 
>> Y.3300, June 2014, <http://www.itu.int/rec/T-REC-Y.3300-201406-I/en>.
>> [EH] Well, this is really very minor, but in section 3.6, you mention 
>> only Openstack for the open source cloud computing software. There 
>> are a couple more. You could make that bullet more generic and 
>> reference more open source activites like openstack, or add another 
>> bullet for an additional example. Just so that you're not limited to 
>> one example per area.
>>
>>>>
>> [1] Mijumbi, Rashid, Joan Serrat, Juan-Luis Gorricho, Niels Bouten, 
>> Filip De Turck, and Raouf Boutaba. "Network function virtualization: 
>> State-of-the-art and research challenges." IEEE Communications 
>> Surveys & Tutorials 18, no. 1 (2016): 236-262.
>>
>> [email-masked] <mailto:[email-masked]>
> ---
> Questa email Ã¨ stata esaminata alla ricerca di virus da AVG.
> http://www.avg.com

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Tue, 06 Jun 2017 16:47:38 +0200

Hi Evangelos,

> Please see responses inline.

Thanks! Please see additional comments inline below.

> imho I don't think that it fits on the terminology section for such a

[Carlos] OK, fair enough. We'll remove it in the next revision.

> This is from 2014. I'm not sure if an updated or a new version

[Carlos] OK, thanks for point it. We'll check it out and see how to
include ITU's view on the draft.

> bullet for an additional example. Just so that you're not limited to

[Carlos] OK, we'll do that.

> Surveys & Tutorials 18, no. 1 (2016): 236-262.

[Carlos] OK. I knew that paper. It is a very good one indeed to
reference. We'll add it and look for others that could fit.

Thanks again!

Carlos

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Tue, 06 Jun 2017 16:49:35 +0200

Dear Ángeles,

Thanks a lot for your review and comments. See inline below.

> paragraph may be helpful here.

[Carlos] OK, we'll add that intro.

> concrete open issues related to virtualisation. Just to clarify what
> I mean, the following seems an assertion of capabilities rather than
> a description of an open issue:
> "virtualization techniques can allow tailoring the network resources
> on separate slices, specifically for each radio

[Carlos] OK, we'll fix that.

> views to standardisation viewpoint and potential practical solutions.

[Carlos] As discussed with Evangelos, we'll add references to academic
papers as well.

Thanks,

Carlos

> > number of other solutions for SDN related that people have used.
> > So, imho I don't think that it fits on the terminology section for
> > such a type of document. 
> > 
> > Y.3300, June 2014, <http://www.itu.int/rec/T-REC-Y.3300-201406-I/en
> > >.
> > [EH] Well, this is really very minor, but in section 3.6, you
> > mention only Openstack for the open source cloud computing
> > software. There are a couple more. You could make that bullet more
> > generic and reference more open source activites like openstack, or
> > add another bullet for an additional example. Just so that you're
> > not limited to one example per area.
> > 
> > Filip De Turck, and Raouf Boutaba. "Network function
> > virtualization: State-of-the-art and research challenges." IEEE
> > Communications Surveys & Tutorials 18, no. 1 (2016): 236-262.
> >

---

From: <[email-masked]>
Date: Fri, 9 Jun 2017 12:04:10 +0000

Dear Carlos and Evangelos,
FWIW the ITU SDN framework document Y.3300 has not been updated but two further recommendations, one on requirements (Y.3301, 2016) and on architecture (Y.3302, 2017) have been published meanwhile to be found at http://www.itu.int/rec/T-REC-Y/recommendation.asp?lang=en&parent=T-REC-Y.3301 and http://www.itu.int/rec/T-REC-Y/recommendation.asp?lang=en&parent=T-REC-Y.3302, respectively.
From a first glance at them I think they differ in some aspects (e.g. SDN Layer Architecture positions Management not in parallel to Control as in Fig. 2, but to Application, Control, and Resources ... as ONF in Fig. 3) but IMO it would be enough to mention that other SDOs define slightly modified architectures etc. 

... just my 2 cents   

Best Regards
Dirk 

-----Original Message-----
From: Nfvrg [mailto:[email-masked]] On Behalf Of Carlos Jesús Bernardos Cano
Sent: Dienstag, 6. Juni 2017 16:48
To: Evangelos Haleplidis; [email-masked]
Subject: Re: [Nfvrg] Research Group Preparation (a.k.a. "Last Call") for draft-irtf-nfvrg-gaps-network-virtualization

Hi Evangelos,

> 
> Regards,
> Evangelos.
> 
> > > #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?
> > 
> 

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

[Carlos] OK, thanks for point it. We'll check it out and see how to include ITU's view on the draft.

> > [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.
> > 
> 
> only Openstack for the open source cloud computing software. There are 
> a couple more. You could make that bullet more generic and reference 
> more open source activites like openstack, or add another bullet for 
> an additional example. Just so that you're not limited to one example 
> per area.

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

Thanks again!

Carlos

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Fri, 09 Jun 2017 14:15:26 +0200

Thanks Dirk! we'll definitely take a look at them.

Carlos

On Fri, 2017-06-09 at 12:04 +0000, [email-masked] wrote:
> FWIW the ITU SDN framework document Y.3300 has not been updated but
> two further recommendations, one on requirements (Y.3301, 2016) and
> on architecture (Y.3302, 2017) have been published meanwhile to be
> found at http://www.itu.int/rec/T-REC-Y/recommendation.asp?lang=en&pa
> rent=T-REC-Y.3301 and http://www.itu.int/rec/T-REC-
> Y/recommendation.asp?lang=en&parent=T-REC-Y.3302, respectively.
> From a first glance at them I think they differ in some aspects (e.g.
> SDN Layer Architecture positions Management not in parallel to
> Control as in Fig. 2, but to Application, Control, and Resources ...
> as ONF in Fig. 3) but IMO it would be enough to mention that other
> SDOs define slightly modified architectures etc. 
> 
> ... just my 2 cents   
> 
> Best Regards
> Dirk 
> 
> Subject: Re: [Nfvrg] Research Group Preparation (a.k.a. "Last Call")
> for draft-irtf-nfvrg-gaps-network-virtualization
> 
> Hi Evangelos,
> 
> > So, 
> > mention 
> > are 
> > virtualization:

---

From: "Diego R. Lopez" <[email-masked]>
Date: Wed, 28 Jun 2017 08:44:06 +0000

Hi,

Since all opinions we have seen on the list have been positive, and all comments were focused on direct improvements to the document, we would like to ask the authors of draft-irtf-nfvrg-gaps-network-virtualization to prepare a new version of the document addressing those comments, so we can proceed and ask for IRSG review. Let me remark, as a final comment from the chairs, that we’d like to see the document to consider the coverage of the new focal points we agreed after Chicago.

It would be ideal if this new version would be ready for a short introduction at our next meeting in Prague. The chairs would be happy to help in any way you see fit to speed up the process.

Be goode,

> On 28 Apr 2017, at 18:14 , Diego R. Lopez <[email-masked]> wrote:
>
> 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

--
"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