From nobody Wed Aug 13 19:42:10 2014 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 443921A0689 for ; 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-Level: 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTk9HRH8W8jF for ; Wed, 13 Aug 2014 19:42:04 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB8F21A0741 for ; Wed, 13 Aug 2014 19:42:03 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) 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 (10.98.56.35) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 14 Aug 2014 03:42:01 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.209]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Thu, 14 Aug 2014 10:41:58 +0800 From: Zongning To: "vnfpool@ietf.org" Thread-Topic: BoF minutes Thread-Index: Ac+3aVCe7DNQrlKFQg2ButsrBahCRg== Date: Thu, 14 Aug 2014 02:41:57 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.54] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 02:42:08 -0000 --_000_B0D29E0424F2DE47A0B36779EC66677966198233nkgeml501mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, all, Please see below minutes of Toronto BoF. Thanks to Jon Hudson for taking no= tes. :) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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 Questions-> (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 p= lease 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 a= ny real redundancy without stateful capabilities? Melinda: For now this is out of scope, but does not need to be in the futur= e. 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 m= any 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 ne= w transport protocol Melinda: 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 solu= tions. 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 ava= ilable in the open source market Ericcson_Guy: Are you trying to standardized a hypervisor or trying o chang= e anything on the host side. AD: We do protocols, we don't influence hypervisors or host operating syste= ms. 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 charac= teristics 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 pl= ease volunteer what you have. TBD_Human_05 - Missed all of it. Oracle_Guy: Melinda: Point taken I think that is essentially correct. TBD_Human_06: Is discovery of VNFs or VNFpools being included in the charte= r? 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 ob= jects in a new way that a new protocol is needed. Pool Capabilities vary q= uite 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 als= o my interest in finding a generic solution, or something more specific. Bo= th methods have good and bad but have serious impact. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Please let us know anything you would like to correct, or comment. Co-chair= s will work out some action items (under the supervision of responsible AD)= as BoF follow-up shortly. Thanks. -Melinda & Ning --_000_B0D29E0424F2DE47A0B36779EC66677966198233nkgeml501mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, all,

 

Please see below minutes of Tor= onto BoF. Thanks to Jon Hudson for taking notes. J

 

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /o:p>

Goal of= Today is to achieve Rough Consensus on VNFPool Charter 

 

Sue Har= es - VNFPool Use Cases

 

Based o= n a personal experience deploying  VNFPools 

 

Questio= n -> No

 

Problem= Statement - Melinda Shore Speaking  

 

Main Ch= anges since 89 reviewed. Main focus has been on clarification. 

 

There s= eems to be a significant concern to the VNF 

 

Challen= ges and Open Issues

Redunda= ncy Management 

Interac= tion Between a VNF and a Service Control Entity 

Reliabl= e Transport 

 

Questio= ns->

 

(TBD_Hu= man_01) Is there accounting for stateful flows?

 

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

 

Generi= c Use Case (Masaki Fukushima)

 

(TBD_Hu= man_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 an= y real redundancy without stateful capabilities?

 

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

 

vEPC U= se Case (Marco Liebsch)

 

 Q= uestions-> No

 

vCDN U= se Case (Oscar Gonzalez De Dios)

 

TBD_Hu= man_03: (missed the question)

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

 

TBD_Hu= man_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 na= il 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 G= uy) Is there any redundancy planed for the manager?

(New G= uy) I would like to add my view that 

 

Nichan= , Huawei - Why don’t we use TCP/IP? Why are you trying to invent a ne= w transport protocol

Melind= a: 

TBD_Hu= man_04: At the end of this working group are we expecting one single protoc= ol 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?=

Melind= a: We don’t expect to have any lack of gaps. <= /p>

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

 

Ericcs= on_Guy: Are you trying to standardized a hypervisor or trying o change anyt= hing on the host side.

AD: We= do protocols, we don’t influence hypervisors or host operating syste= ms. 

Ericcs= on_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 characterist= ics and how selection is done and if so can you document it?

Melind= a: Yes, we don’t have much on that yet. As always we need text. So pl= ease volunteer what you have. 

 

TBD_Hu= man_05 - Missed all of it.

 

Oracle= _Guy: 

Melind= a: Point taken I think that is essentially correct. =

 

TBD_Hu= man_06: Is discovery of VNFs or VNFpools being included in the charter?

Melind= a: Yes, that is something being looked at elsewhere and we’ll need to= look at it and see what we can actually deploy.

TBD_Hu= man_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? <= /p>

 

Christ= opher: 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 o= ver the place and coordinating that with our work is a big worry. 

 

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

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

 

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

 

Thanks.

 

-Melinda & Ning<= /span>

--_000_B0D29E0424F2DE47A0B36779EC66677966198233nkgeml501mbschi_-- From nobody Wed Aug 27 00:48:14 2014 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC0371A0266; Wed, 27 Aug 2014 00:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] autolearn=ham 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 dIEp-u5wa2QG; Wed, 27 Aug 2014 00:48:09 -0700 (PDT) Received: from mailout.uni-due.de (mailout.uni-due.de [132.252.185.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 450141A0473; Wed, 27 Aug 2014 00:48:09 -0700 (PDT) Received: from lupo.localnet ([77.88.71.157]) (authenticated bits=0) by mailout.uni-due.de (8.13.1/8.13.1) with ESMTP id s7R7m6Ai020584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 27 Aug 2014 09:48:07 +0200 From: Thomas Dreibholz To: rserpool@ietf.org, vnfpool@ietf.org Date: Wed, 27 Aug 2014 09:48:06 +0200 Message-ID: <3226871.QTsgfm13fC@lupo> User-Agent: KMail/4.13.3 (Linux/3.13.0-34-generic; KDE/4.13.3; x86_64; ; ) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1681858.aqtduyhlP5"; micalg="pgp-sha1"; protocol="application/pgp-signature" X-Virus-Scanned: Clam Anti Virus - http://www.clamav.net X-Spam-Scanned: SpamAssassin: 3.002004 - http://www.spamassassin.org X-Scanned-By: MIMEDefang 2.57 on 132.252.185.19 Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/TR683WmVi7-T6-TdEFLYPmNzcWs Subject: [vnfpool] Call for Papers of the PAMS 2015 X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for virtual network function resource pooling." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 07:48:11 -0000 --nextPart1681858.aqtduyhlP5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" We apologize if you receive multiple copies of this CFP. CALL FOR PAPERS The 5th International Workshop on Protocols and Applications with Multi= =2DHoming Support (PAMS 2015) In conjunction with the 29th IEEE International Conference on Advanced = Information Networking and Applications (AINA 2015) March 24-27, 2015 in Gwangju/South Korea https://simula.no/pams-2015 The intent of our workshop is to bring together people from research an= d industry, in order to provide a discussion forum for state-of-the-art t= opics related to multi-homing on Network, Transport, Session and Application = Layers. The PAMS workshop will include full-paper sessions as well as a poster = session (with short presentations) to introduce preliminary ideas as well as wo= rk in progress. Workshops proceedings will be published by the IEEE CS Conference Publi= shing Service and will be included in the Digital Library. The main topics to be addressed include (but are not limited to): * Network Resilience by Multi-Homing * Network Architectures for Multi-Homed Systems * Performance Evaluation of Multi-Homed Systems * Deployment of Multi-Homed Protocols in Existing Networks with Middleboxes * Design and Implementation of Multi-Homed Systems * Testbeds for Multi-Homed Systems * Load Sharing and Load Balancing for Multi-Homed Systems * Mobility for Multi-Homed Systems * Protocols with Multi-Homing Support * Congestion and Flow Control of Multi-Homed Systems * Quality of Service for Multi-Homed Systems * Multi-Homing for Interconnection Networks * Security of Multi-Homed Systems * Application Deployment and Support for Legacy Applications * Cross-Layer Optimisation for Multi-Homed Systems * Multi-Homing in the Context of the Future Internet GENERAL CHAIRS: * Thomas Dreibholz, Simula Research Laboratory, Norway * Hakim Adhari, University of Duisburg-Essen, Germany PUBLICITY CHAIRS: * Glenford Mapp, Middlesex University, United Kingdom * Xing Zhou, Hainan University, China PROGRAM COMMITTEE * Hakim Adhari, University of Duisburg-Essen, Germany * Nicola Altan, ista International, Germany * =C4=B0lknur Ayd=C4=B1n, Farmingdale State College, U.S.A. * =C5=81ukasz Budzisz, Technische Universit=C3=A4t Berlin, Germany * Martin Becke, University of Duisburg-Essen, Germany * Anna Brunstr=C3=B6m, Karlstad University, Sweden * Ahmed Elmokashfi, Simula Research Laboratory, Norway * Kristian Evensen, Simula Research Laboratory, Norway * Simone Ferlin, Simula Research Laboratory, Norway * Ernst Gunnar Gran, Simula Research Laboratory, Norway * Michio Honda, Keio University, Japan * Seok Joo Koh, Kyungpook National University, South Korea * Amund Kvalbein, Simula Research Laboratory, Norway * Glenford Mapp, Middlesex University, United Kingdom * Michael Menth, University of T=C3=BCbingen, Germany * Samuel Rodrigo Mocholi, Oracle, Norway * Preethi Natarajan, Cisco, U.S.A. * Jes=C3=BAs Escudero Sahuquillo, Oracle, Norway * Francisco Trivi=C3=B1o-Garc=C3=ADa, Oracle, Norway * Esbold Unurkhaan, Mongolian University of Science and Technology,= Mongolia * Alan Wagner, University of British Columbia, Canada * Thomas Volkert, Ilmenau University of Technology, Germany * Michael Welzl, University of Oslo, Norway * Xing Zhou, Hainan University, China IMPORTANT DATES * Paper Submission Deadline: October 1, 2014 * Author Notification: December 15, 2014 * Author Registration: January 15, 2015 * Camera-Ready Paper Submission: January 15, 2015 CONTACT For further information, please contact: * Thomas Dreibholz (dreibh@simula.no) * Hakim Adhari (hakim.adhari@uni-due.de) WEBSITE https://simula.no/pams-2015 --nextPart1681858.aqtduyhlP5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEABECAAYFAlP9jTYACgkQ32BbsHYPLWXgoQCeJ4bb2v+xub27COm//nysYwjw DCMAoMrnee1Hlt0Aw6d55FJlDafHcxoz =/A/o -----END PGP SIGNATURE----- --nextPart1681858.aqtduyhlP5--