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

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

Hi Kostas,

Thanks a lot for providing very good comments. We'll are working on
them and come back with an updated version (and responses to your
comments) soon.

Thanks!

Carlos

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.
> 
> 
> 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.
> 
> 
> 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.
> 
> "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?
> 
> 
> Section 3:
> 
> "Within this area of work, the ONF is actively..." -- are there
> recent developments in this direction? Should/could be cited?
> 
> I find that the summary of RFC 7426 is quite, let's say, terse.
> Perhaps 1-2 paragraphs can be contributed here.
> 
> Are section 3.4 and 3.5 a bit dated, or are there (new) research
> challenges in these directions?
> 
> 
> 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?
> 
> '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?
> 
> There is also work in BMWG regarding methodology and metrics for NFV,
> e.g. see draft-ietf-bmwg-virtual-net and references therein.
> 
> "Portability" is not actually defined in sec. 4.2.4. Can you please
> elaborate?
> 
> 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.
> 
> 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.
> 
> Sec. 4.6 is entitled "Service Composition". How's that different from
> what is defined in RFC 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.
> 
> 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.
> 
> In sec. 4.9, I guess s/two possible levels of SDN control/two
> possible levels of control.
> 
> 
> Section 5:
> 
> As SDNRG has been recently closed, Table 1 will need updating.
> 
> 
> Best regards,
> 
> Kostas