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

Kostas Pentikousis <k.pentikousis@travelping.com> Fri, 03 February 2017 16:16 UTC

Return-Path: <kpentikousis@tpip.net>
X-Original-To: nfvrg@ietfa.amsl.com
Delivered-To: nfvrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5F921295DC for <nfvrg@ietfa.amsl.com>; Fri, 3 Feb 2017 08:16:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.099
X-Spam-Level:
X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vdh0hk0UB9zy for <nfvrg@ietfa.amsl.com>; Fri, 3 Feb 2017 08:16:28 -0800 (PST)
Received: from mail.tpip.net (mail.tpip.net [92.43.49.48]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17E2812941C for <nfvrg@irtf.org>; Fri, 3 Feb 2017 08:16:27 -0800 (PST)
Received: from office.tpip.net (unknown [153.92.65.89]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.tpip.net (Postfix) with ESMTPS id DFEAD4F403; Fri, 3 Feb 2017 16:16:25 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by office.tpip.net (Postfix) with ESMTP id C1E9DA2CE1; Fri, 3 Feb 2017 17:16:25 +0100 (CET)
Received: from office.tpip.net ([127.0.0.1]) by localhost (office.tpip.net [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 06nOfepfeP5Q; Fri, 3 Feb 2017 17:16:25 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by office.tpip.net (Postfix) with ESMTP id 526EDA2CE2; Fri, 3 Feb 2017 17:16:25 +0100 (CET)
X-Virus-Scanned: amavisd-new at tpip.net
Received: from office.tpip.net ([127.0.0.1]) by localhost (office.tpip.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Lw_2YNF5aOMK; Fri, 3 Feb 2017 17:16:25 +0100 (CET)
Received: from office.tpip.net (office.tpip.net [153.92.65.89]) by office.tpip.net (Postfix) with ESMTP id 20DD9A2CE1; Fri, 3 Feb 2017 17:16:25 +0100 (CET)
Date: Fri, 3 Feb 2017 17:16:25 +0100 (CET)
From: Kostas Pentikousis <k.pentikousis@travelping.com>
To: draft-irtf-nfvrg-gaps-network-virtualization@ietf.org
Message-ID: <279467219.741330.1486138585009.JavaMail.zimbra@tpip.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Originating-IP: [153.92.65.89]
X-Mailer: Zimbra 8.7.0_GA_1659 (ZimbraWebClient - FF51 (Win)/8.7.0_GA_1659)
Thread-Index: fBbofRtyprgIEch73vDFYzvK8zrZlA==
Thread-Topic: Review of draft-irtf-nfvrg-gaps-network-virtualization-03
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfvrg/TXy8bPKTQn57jaS4n1gL1BgIXf0>
Cc: nfvrg <nfvrg@irtf.org>
Subject: [Nfvrg] Review of draft-irtf-nfvrg-gaps-network-virtualization-03
X-BeenThere: nfvrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: Kostas Pentikousis <k.pentikousis@travelping.com>
List-Id: "Network Function Virtualization Research Group \(NFVRG\) discussion list" <nfvrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/nfvrg>, <mailto:nfvrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfvrg/>
List-Post: <mailto:nfvrg@irtf.org>
List-Help: <mailto:nfvrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/nfvrg>, <mailto:nfvrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Feb 2017 16:16:31 -0000

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