[vnfpool] BoF minutes

Zongning <zongning@huawei.com> Thu, 14 August 2014 02:42 UTC

Return-Path: <zongning@huawei.com>
X-Original-To: vnfpool@ietfa.amsl.com
Delivered-To: vnfpool@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 443921A0689 for <vnfpool@ietfa.amsl.com>; Wed, 13 Aug 2014 19:42:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.468
X-Spam-Status: No, score=-103.468 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id KTk9HRH8W8jF for <vnfpool@ietfa.amsl.com>; Wed, 13 Aug 2014 19:42:04 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB8F21A0741 for <vnfpool@ietf.org>; Wed, 13 Aug 2014 19:42:03 -0700 (PDT)
Received: from (EHLO lhreml403-hub.china.huawei.com) ([]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIF54071; Thu, 14 Aug 2014 02:42:02 +0000 (GMT)
Received: from NKGEML404-HUB.china.huawei.com ( by lhreml403-hub.china.huawei.com ( with Microsoft SMTP Server (TLS) id; Thu, 14 Aug 2014 03:42:01 +0100
Received: from NKGEML501-MBS.china.huawei.com ([]) by nkgeml404-hub.china.huawei.com ([]) with mapi id 14.03.0158.001; Thu, 14 Aug 2014 10:41:58 +0800
From: Zongning <zongning@huawei.com>
To: "vnfpool@ietf.org" <vnfpool@ietf.org>
Thread-Topic: BoF minutes
Thread-Index: Ac+3aVCe7DNQrlKFQg2ButsrBahCRg==
Date: Thu, 14 Aug 2014 02:41:57 +0000
Message-ID: <B0D29E0424F2DE47A0B36779EC66677966198233@nkgeml501-mbs.china.huawei.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_B0D29E0424F2DE47A0B36779EC66677966198233nkgeml501mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/j_IBeSUIMU7HBlCtnJM6Wl8a2Gk
Subject: [vnfpool] BoF minutes
X-BeenThere: vnfpool@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion list for virtual network function resource pooling." <vnfpool.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/vnfpool>, <mailto:vnfpool-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vnfpool/>
List-Post: <mailto:vnfpool@ietf.org>
List-Help: <mailto:vnfpool-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vnfpool>, <mailto:vnfpool-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Aug 2014 02:42:08 -0000

Hi, all,

Please see below minutes of Toronto BoF. Thanks to Jon Hudson for taking notes. :)


Goal of Today is to achieve Rough Consensus on VNFPool Charter

Sue Hares - VNFPool Use Cases

Based on a personal experience deploying  VNFPools

Question -> No

Problem Statement - Melinda Shore Speaking

Main Changes since 89 reviewed. Main focus has been on clarification.

There seems to be a significant concern to the VNF

Challenges and Open Issues

Redundancy Management

Interaction Between a VNF and a Service Control Entity

Reliable Transport


(TBD_Human_01) Is there accounting for stateful flows?

Melinda: Currently we are not, and it may be handled in a different layer. But please if anyone has ideas on how to solve any of the stateful issues please submit them. This is a very challenging problem.

Generic Use Case (Masaki Fukushima)

(TBD_Human_02 Will Physical and Virtual devices be considered?

Masaki: No we are currently only looking at virtual devices.

F5 Guy: I think this is a great goal, but I don't see how you can provide any real redundancy without stateful capabilities?

Melinda: For now this is out of scope, but does not need to be in the future.

vEPC Use Case (Marco Liebsch)

 Questions-> No

vCDN Use Case (Oscar Gonzalez De Dios)

TBD_Human_03: (missed the question)

Yes we have the load balancing today using different cacheing and different ways of moving and providing resources.

TBD_Human_03: Do you see this being a CND solution.

Oscar: It's not application specific, I  think it's more general. Daniel do you have an opinion?

Daniel King: The load balances has been a contentious issue. We really need to nail this down, perhaps even address it in the Charter. But there are many options being discussed. I will gather the options and send them all on the mail list for discussion.

On to the Charter:

(New Guy) Is there any redundancy planed for the manager?

(New Guy) I would like to add my view that

Nichan, Huawei - Why don't we use TCP/IP? Why are you trying to invent a new transport protocol


TBD_Human_04: At the end of this working group are we expecting one single protocol produced? Or would this be more a framework allowing multiple solutions.

David Allen: Do you plan to alining this architecture with the ETSI NVF

David Allen: What will you do if your gab analysis results in no gaps?

Melinda: We don't expect to have any lack of gaps.

David Allen: Well I think you may be surprised once you look at what is available in the open source market

Ericcson_Guy: Are you trying to standardized a hypervisor or trying o change anything on the host side.

AD: We do protocols, we don't influence hypervisors or host operating systems.

Ericcson_Guy: I just don't see the value being added, when you look at what is in the market

Kevin Riverbed: Is there any consideration for different performance characteristics and how selection is done and if so can you document it?

Melinda: Yes, we don't have much on that yet. As always we need text. So please volunteer what you have.

TBD_Human_05 - Missed all of it.


Melinda: Point taken I think that is essentially correct.

TBD_Human_06: Is discovery of VNFs or VNFpools being included in the charter?

Melinda: Yes, that is something being looked at elsewhere and we'll need to look at it and see what we can actually deploy.

TBD_Human_06: Missed the comment.

Daniel King : Just following up on Dave's comments about ETSI NFV. Have we look at a formal liaison to help make that happen?

Christopher: I have a concern that just because we are grouping existing objects in a new way that a new protocol is needed.  Pool Capabilities vary quite a lot between Containers and Orchestrators and it's all over the place and coordinating that with our work is a big worry.

Francois Cisco: I want to restate my concern about interoperability and also my interest in finding a generic solution, or something more specific. Both methods have good and bad but have serious impact.

Please let us know anything you would like to correct, or comment. Co-chairs will work out some action items (under the supervision of responsible AD) as BoF follow-up shortly.


-Melinda & Ning