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

[Barbara Martini <[e-mail]>]

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:
> 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
>>>> 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.
>>
>> _______________________________________________
>> Nfvrg mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.irtf.org/mailman/listinfo/nfvrg
>
>
>
> _______________________________________________
> Nfvrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/nfvrg
>
>
> ---
> Questa email è stata esaminata alla ricerca di virus da AVG.
> http://www.avg.com