Re: [Nfvrg] Review of draft-irtf-nfvrg-gaps-network-virtualization-03

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

Hi Kostas,

Thanks again for your very useful comments. Please, find below some
answers inline on how we have incorporated/considerated your comments
in the -04 version (just posted).

On Fri, 2017-02-03 at 17:16 +0100, Kostas Pentikousis wrote:
> Dear authors, all,
> 
> I read draft-irtf-nfvrg-gaps-network-virtualization-03 and I have a
> few comments and suggestions, which could be incorporated in an
> upcoming revision of the document. Overall, the draft attempts to
> cover a very wide area of topics. I think it would be good to add in
> the introductory part some text making the goal and scope of the
> document more specific. In addition, I think that the draft does not
> provide a sufficient set of references to recent/relevant literature
> in this area, so that the reader can follow up with a more detailed
> investigation re: the research challenges in this area. Further, some
> of the text appears a bit dated, so a thorough editorial pass would
> be beneficial. Section-specific comments follow.
> 

[Authors] Thanks for the comments. Since you provide section-specific
comments on all these points, we provide our feedback on each of them
below.

> 
> Section 1:
> 
> I find the intro a bit too general and lacking focus. It also does
> not squarely deliver the goal and scope of this document. Perhaps it
> could be reworked to include a summary of the key points that this
> draft delivers.
> 

[Authors] We have reworked this in -04, trying to more clearly
summarize the goal and scope of the document.

> 
> Section 2:
> 
> "are defined by the ETSI NVF ISG, the ONF and the IETF" -- along the
> lines above, it's probably better to cite the respective documents so
> that the reader can easily locate them and delve into the details.
> 

[Authors] OK, we've added the references.


> "vEPC ... as defined by [I-D.matsushima-stateless-uplane-vepc] --
> This actually refers to an expired draft. Perhaps it should be
> replaced by an archival publication instead? Ditto for the other
> expired drafts cited later in the text. More to the point, the cited
> draft advocates explicitly a solution based on BGP. Is this what you
> have in mind for vEPC? Why is vEPC a key term for this draft, esp. as
> it is not really used in the remainder of the draft?
> 

[Authors] We have removed vEPC from the terminology section (it was a
leftover from previous versions).

> 
> Section 3:
> 
> "Within this area of work, the ONF is actively..." -- are there
> recent developments in this direction? Should/could be cited?

[Authors] There is ongoing work, but it has not finalized yet and
therefore there is no public available document that we can use as a
reference at this stage. As soon as it is released, we can add it.

> 
> I find that the summary of RFC 7426 is quite, let's say, terse.
> Perhaps 1-2 paragraphs can be contributed here.

[Authors] I see :). We have extended and improved the text there.

> 
> Are section 3.4 and 3.5 a bit dated, or are there (new) research
> challenges in these directions?

[Authors] IEEE 802.1CF OmniRAN is surely quite alive and the work is
advancing. We have added a reference to the latest version of the draft
specification (released last month). Regarding DMTF, we still need to
check.

> 
> 
> Section 4:
> 
> In sec. 4.2, "For example, ensuring a guaranteed and stable
> forwarding data rate has proven not to be straightforward when the
> forwarding function is virtualized and runs on top of COTS server
> hardware." -- Can you please provide some references?

[Authors] We have added 3 references: a draft, a presentation that
Diego made in IETF92 and also the ETSI White Paper 3, where this is
also explained.

> 
> 'The issue of guaranteeing a network quality-of-service is less of an
> issue for "traditional cloud computing".' -- I'm not sure what does
> this refer to wrt "QoS". Perhaps elaborate a bit/add references?

[Authors] We have improved the text, elaborating a bit more and added
one reference.

> 
> There is also work in BMWG regarding methodology and metrics for NFV,
> e.g. see draft-ietf-bmwg-virtual-net and references therein.

[Authors] Thanks for the pointer. We have added new text and references
on this, also referencing to the work done at ETSI NFV.

> 
> "Portability" is not actually defined in sec. 4.2.4. Can you please
> elaborate?

[Authors] We have defined it at the beginning of the section, as well
as extended the text based on a ETSI NFV reference that we have also
added.

> 
> In sec. 4.3.1 "enablers for this that are often mentioned" and "such
> as enhanced hypervisor technologies" most certainly need some
> literature pointers, as is "(e.g., Google example)" in sec. 4.3.2.
> 
[Authors] We have added some pointers (academic papers) there.

> In sec. 4.5, 5G pops out of nowhere. I think network slicing (and the
> associated challenges) is more generic than what is described in this
> section.
> 

[Authors] We have included 5G in the title of the section. We have also
  added some text to also clarify that the definition of network
slicing is a sensitive issue (it is not the goal of the draft to reach
an agreed definition. Given the all the activity lately in netslices,
we have also added references.

We have also added a section on virtual network operators contributed
by Pedro Martinez-Julia.
 
> Sec. 4.6 is entitled "Service Composition". How's that different from
> what is defined in RFC 7498 and 7665?
> 
[Authors] It is not. It is about that and the challenges SFC WG are
addressing. We have added explicit references to 7498 and 7665.

> Under "End-user device virtualization" in sec. 4.7 I was not
> expecting to see "smartphones". Is that a major research direction
> besides the referenced project? Some references would be great here
> too.

[Authors] There are several ongoing efforts in this direction. We have
added one more reference about this.

> 
> In sec. 4.8, the sentence "NFV will allow better defense against
> Denial of Service (DoS) attacks because of the distributed nature of
> the network (i.e. no single point of failure) and the ability to
> steer (undesirable) traffic quickly." most certainly needs some
> backing references.

[Authors] Added.

> 
> In sec. 4.9, I guess s/two possible levels of SDN control/two
> possible levels of control.

[Authors] I think the text is actually right. What we mean is that SDN
can be used in conjunction with NFV at two different levels.

> 
> 
> Section 5:
> 
> As SDNRG has been recently closed, Table 1 will need updating.

[Authors] Fixed, thanks.

Thanks a lot again for all the good and useful comments,

Carlos

> 
> 
> Best regards,
> 
> Kostas