From nobody Mon Apr 7 05:24:52 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 94FBD1A06E8; Mon, 7 Apr 2014 04:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3] autolearn=unavailable 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 ekWOkuIG3IHx; Mon, 7 Apr 2014 04:31:32 -0700 (PDT) Received: from smtp7-outgoing.stejtech.net (smtp7.stejtech.net [83.140.31.163]) by ietfa.amsl.com (Postfix) with ESMTP id 758231A03A2; Mon, 7 Apr 2014 04:31:30 -0700 (PDT) X-Spam-STAY-ID: v=2.0 cv=MezuSuDf c=1 sm=0 a=fpfCo9GHTwTpwwPQDU8l2g==:17 a=Uhs6VmVbDOAA:10 a=O-HbT_8aKzwA:10 a=8nJEP1OIZ-IA:10 a=xqWC_Br6kY4A:10 a=0uK3lwuoAAAA:8 a=BGERU-rR9RC6Kdj9WCMA:9 a=wPNLvfGTeEIA:10 a=b0KEEVAwhZFadoE6:21 a=Qel7Evxxewn15ktV:21 Received: from mail.acreo.se (unknown [217.151.196.13]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp7.stejtech.net (Postfix) with ESMTPSA id 83944752147; Mon, 7 Apr 2014 13:31:18 +0200 (CEST) Received: from ACREOEXC02.ad.acreo.se ([::1]) by ACREOEXC02.ad.acreo.se ([::1]) with mapi id 14.03.0158.001; Mon, 7 Apr 2014 13:31:18 +0200 From: =?iso-8859-1?Q?Pontus_Sk=F6ldstr=F6m?= To: "sdn@irtf.org" , "sfc@ietf.org" , "vnfpool@ietf.org" Thread-Topic: European Workshop on SDN (EWSDN) Thread-Index: Ac9SVOSQ+wHtxs4USMSCN/D14qF9+Q== Date: Mon, 7 Apr 2014 11:31:18 +0000 Message-ID: <2D8B43480583CF47B78E7F01B983EF8033FAD9@ACREOEXC02.ad.acreo.se> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [217.151.207.19] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/jKSNa_IFas9YPosjJjkn46G1Xog X-Mailman-Approved-At: Mon, 07 Apr 2014 05:24:51 -0700 Subject: [vnfpool] CfP: European Workshop on SDN (EWSDN) 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: Mon, 07 Apr 2014 11:31:37 -0000 CALL FOR PAPERS - EWSDN 2014: 3rd European Workshop on Software Defined Net= works=0A= http://ewsdn.eu=0A= =0A= 1-3 September 2014 in Budapest, Hungary.=0A= =0A= IMPORTANT DATES=0A= * Paper registration: 5 May 2014=0A= * Paper submission: 10 May 2014=0A= * Notification of acceptance: 1 July 2014=0A= * Camera ready papers due: 1 August 2014=0A= * Conference dates: 1-3 September 2014=0A= =0A= SYNOPSIS AND GOAL=0A= =0A= Software Defined Networking is undoubtedly one of the chief trends in the I= CT area. In the past years we have seen all big players in the networking a= rena starting to ride the SDN. Standardization work is actively ongoing in = the Open Networking Forum (ONF), the Internet Engineering Task Force (IETF)= (e.g., I2RS, freshly formed Service Function Chaining (SFC) workgroup or r= ecent initiatives to form VNFPool), while the European Telecommunications S= tandards Institute (ETSI) just released several group specifications on Net= work Functions Virtualization (NFV). On top of the several existing open-so= urce SDN controllers, OpenDaylight reached significant momentum last year a= nd arrived to its first official release in February 2014.=0A= =0A= One goal of the workshop is to bring together industry and academia on the = topics of SDN; in particular the workshop will feature an "industry forum",= i.e., a session with presentations of key industrial players.=0A= =0A= CONTRIBUTIONS TO THE WORKSHOP=0A= =0A= We are interested in both papers showing consolidated results and in positi= on papers bringing up innovative ideas. Topics for contributions include, b= ut are not limited to, the following:=0A= - Virtualization architectures=0A= - Forwarding abstractions, APIs, object models=0A= - Network Function Virtualization and SDN, network virtualization technique= s=0A= - Optical extensions to OpenFlow, SDN=0A= - Wireless integration, characterization of wireless interfaces, flows, han= dover support=0A= - Evolved packet core, LTE support for OpenFlow=0A= - New controller architectures, APIs and northbound interfaces=0A= - Interoperation of cloud architectures and SDN=0A= - New switch architectures supporting SDN=0A= - New networking paradigms like Information Centric Networks (ICN) and rela= tion to SDN=0A= - Security implications of SDN and security enhancements to SDN, as well as= new security services enabled by SDN=0A= - Carrier-grade SDN architectures and equipment=0A= - Practical experiments on SDN/Cloud/OpenFlow=0A= - Testbeds=0A= - Identification of use cases for SDN, SDN related business models, strateg= ic role of SDN in network evolution=0A= - Regulatory aspects around network virtualization=0A= - SDN frameworks and tools, SDN based equipment: controllers, switches, int= egrated development environment, testing and debugging environment.=0A= =0A= =0A= SUBMISSION AND PUBLICATION=0A= =0A= Submission format is IEEE Conference Style, A4 format, of up to 6 pages.=0A= Please use standard IEEE conference proceedings templates.=0A= EWSDN submission will be managed using the EasyChair submission system, che= ck the web for the submission link.=0A= =0A= EWSDN Workshop Proceedings will be submitted for indexing and publication t= o IEEE Xplore.=0A= =0A= COMMITTEE AT A GLANCE=0A= =0A= General Chair: Hagen Woesner, BISDN, Berlin, Germany=0A= TPC Co-Chairs:=0A= Holger Karl,University Paderborn, Paderborn, Germany=0A= Robert Szabo, Ericsson, Hungary=0A= Publicity Chairs:=0A= Stefan Schmid, TU Berlin / Telekom Innovation Laboratories, Germany=0A= Pontus Sk=F6ldstr=F6m, Acreo Swedish ICT AB, Sweden=0A= Demo and Exhibition Chair: Balazs Sonkoly, BME, Hungary=0A= Workshop Operations Chair and Web Chair: Mario Druse, EICT, Germany= From nobody Wed Apr 9 20:22:06 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 E521F1A006F for ; Wed, 9 Apr 2014 20:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.472 X-Spam-Level: X-Spam-Status: No, score=-104.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 I6L_kdZye3A9 for ; Wed, 9 Apr 2014 20:22:01 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2C50C1A007E for ; Wed, 9 Apr 2014 20:22:00 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFL75924; Thu, 10 Apr 2014 03:21:58 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 10 Apr 2014 04:20:53 +0100 Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 10 Apr 2014 04:21:57 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.85]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Thu, 10 Apr 2014 11:21:53 +0800 From: Zongning To: "vnfpool@ietf.org" Thread-Topic: New revision of VNFPool Problem Statement posted Thread-Index: Ac9UbATHM7NhTJ8NTjunJ2NkO54O2g== Date: Thu, 10 Apr 2014 03:21:53 +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.22] Content-Type: multipart/alternative; boundary="_000_B0D29E0424F2DE47A0B36779EC6667796610DCEEnkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/GRzBpRsIReGmhRiZqKpz8R75VJc Subject: [vnfpool] New revision of VNFPool Problem Statement posted 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, 10 Apr 2014 03:22:03 -0000 --_000_B0D29E0424F2DE47A0B36779EC6667796610DCEEnkgeml501mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, folks, The new revision (-04) of VNFPool Problem Statement I-D is available on the= below page. https://datatracker.ietf.org/doc/draft-zong-vnfpool-problem-statement/ Here are the major changes: 1) Clarify VNFPool architecture and intended scope. 1. Add new section of VNF Pools before the section of Problem. This= new section is mainly to outline our scope based on high level description= of VNF Pools architecture. 2. Add text to clarify that we are specifically concerned with reli= ability (e.g. redundancy model, state sharing) that is managed inside the V= NF. We are only concerned with the whole VNF set (or forwarding graph) to t= he extent that it involves reliability impact on adjacent instances of diff= erent VNFs. 3. We focus on reliability mechanisms based on VNF pool. Other VNF = management aspects such as scaling, load balancing are out of scope. 2) Update terminologies to define Service Control Entity, and delete = Pool User as the pool will be internal to VNF only. 3) Re-arrange the text in section of Problems. 4) Update text of VNF instance performance degradation in section of = Problems. 5) Update text of Reliable Transport in section of Problems. 6) Add text to explain why service availability is not in scope in se= ction of Problems. 7) Re-write the section describing the relationship of VNFPool and SF= C. 8) Add text of transfer of security states in section of Security Con= sideration. We hope that the changes have addressed most of the comments, and reflected= most of the suggestions during London BoF. Please review this new revision. Your further comments and suggestions are = highly appreciated! Thanks. -Ning --_000_B0D29E0424F2DE47A0B36779EC6667796610DCEEnkgeml501mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, folks,

 

The new revision (-04) of VNFPo= ol Problem Statement I-D is available on the below page.<= /p>

https://datatracker.iet= f.org/doc/draft-zong-vnfpool-problem-statement/

 

Here are the major changes:

1= )   &= nbsp;   Clarify VNFPool archite= cture and intended scope.

1= .   &= nbsp;     Add new section of VNF = Pools before the section of Problem. This new section is mainly to outline = our scope based on high level description of VNF Pools architecture.

2= .   &= nbsp;     Add text to clarify tha= t we are specifically concerned with reliability (e.g. redundancy model, st= ate sharing) that is managed inside the VNF. We are only concerned with the= whole VNF set (or forwarding graph) to the extent that it involves reliability impact on adjacent instances of= different VNFs.

3= .   &= nbsp;     We focus on reliability= mechanisms based on VNF pool. Other VNF management aspects such as scaling= , load balancing are out of scope.

2= )   &= nbsp;   Update terminologies to= define Service Control Entity, and delete Pool User as the pool will be in= ternal to VNF only.

3= )   &= nbsp;   Re-arrange the text in = section of Problems.

4= )   &= nbsp;   Update text of VNF inst= ance performance degradation in section of Problems.

5= )   &= nbsp;   Update text of Reliable= Transport in section of Problems.

6= )   &= nbsp;   Add text to explain why= service availability is not in scope in section of Problems.

7= )   &= nbsp;   Re-write the section de= scribing the relationship of VNFPool and SFC.

8= )   &= nbsp;   Add text of transfer of= security states in section of Security Consideration.

 

We hope that the changes have a= ddressed most of the comments, and reflected most of the suggestions during= London BoF.

 

Please review this new revision= . Your further comments and suggestions are highly appreciated!<= /span>

 

Thanks.

 

-Ning

--_000_B0D29E0424F2DE47A0B36779EC6667796610DCEEnkgeml501mbschi_-- From nobody Thu Apr 10 01:14:01 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 357D71A0142 for ; Thu, 10 Apr 2014 01:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.773 X-Spam-Level: X-Spam-Status: No, score=-1.773 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 k5hASgodKoSk for ; Thu, 10 Apr 2014 01:13:52 -0700 (PDT) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 8E1B01A013B for ; Thu, 10 Apr 2014 01:13:50 -0700 (PDT) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0N3T00EIL2UYFA@tid.hi.inet> for vnfpool@ietf.org; Thu, 10 Apr 2014 10:13:46 +0200 (MEST) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id 3C.A8.05896.9B256435; Thu, 10 Apr 2014 10:13:46 +0200 (CEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0N3T00EIG2UXFA@tid.hi.inet> for vnfpool@ietf.org; Thu, 10 Apr 2014 10:13:45 +0200 (MEST) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.125]) by EX10-HTCAS7-MAD.hi.inet ([::1]) with mapi id 14.03.0158.001; Thu, 10 Apr 2014 10:13:45 +0200 Date: Thu, 10 Apr 2014 08:13:44 +0000 From: PEDRO ANDRES ARANDA GUTIERREZ X-Originating-IP: [10.95.64.115] To: Zongning , "vnfpool@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_euJhtjDjjrBvxjZYMdcZ0A)" Content-language: es-ES Accept-Language: es-ES, es-ES, en-US Thread-topic: [vnfpool] New revision of VNFPool Problem Statement posted Thread-index: AQHPVJTKkZ5bXq91S0+hBxadIQptzQ== user-agent: Microsoft-MacOutlook/14.3.9.131030 X-AuditID: 0a5f4e69-b7f778e000001708-92-534652b9f654 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGLMWRmVeSWpSXmKPExsXCFe9nqLsryC3YoPO0oMWMS/9ZHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVMX1ZK3PBh6KKxbdUGhivpnQxcnJICJhIbO2/ywJhi0lcuLee rYuRi0NIYDujxKXDW5kgnN+MEgfvHGGHcGYySvw4uZ4ZpIVFQFVi06tGRhCbTcBKYu7mv2C2 sIC7xKEln5kgxipI/Dn3GGgFB4eIgKfEzyWSICavgLrE4gt6IBW8AoISPybfAzuCGajiwf0p 7BC2uMScXxNZQcoZBVQkJuwvBgmLCHhIvNj7nAnC1pO4deUVK4gtCmTfezQX6hcBiSV7zjND 2KISLx//Y53AKDILybZZSLbNQrINwtaTuDF1ChuErS2xbOFrZghbV2LGv0NAvRxAtpnEqZeM yEoWMHKsYhQrTirKTM8oyU3MzEk3MNLLyNTLzEst2cQIiavMHYzLd6ocYhTgYFTi4b24xTVY iDWxrLgy9xCjBAezkgivgpBbsBBvSmJlVWpRfnxRaU5q8SFGJg5OqQbGlq3lxi/NNess4vb8 3WS/vWSrWaK+kfeOBY1GL7SKv5d4fI7cuTTUxuO2Vdm8i7XZz5ovKhbYOHWlFt96dO6f/bIZ fTWRh/Xk7pzrXRew7G5+RoRL/pWW1VvKg37o8vOtKw+x77neIK26vXHSHSbjJaLCq7x0mXp4 DnwKktKzXJah6ci7bIoSS3FGoqEWc1FxIgCux8N5iQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/Zbz0GvUuyDYJrfi_z0SWg-mgw3Y Subject: Re: [vnfpool] New revision of VNFPool Problem Statement posted 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, 10 Apr 2014 08:13:57 -0000 --Boundary_(ID_euJhtjDjjrBvxjZYMdcZ0A) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Reading through the ID, I have found some typos: s/How is the service states/How are the service states/g s/how do an adjacent VNF instance/how does an adjacent VNF instance/g s/For a VNF instance, it typically would not have built-in reliability/A VN= F instance would typically not have built-in reliability/g A mail with requests for clarification will follow. Thx, BR,/PA Dr. Pedro A. Aranda Guti=E9rrez Technology Exploration - Network Innovation & Virtualisation mailto:paag@tid.es Telef=F3nica, Investigaci=F3n y Desarrollo C/ D. Ram=F3n de la Cruz,84 28006 Madrid, Spain Fragen sind nicht da, um beantwortet zu werden. Fragen sind da, um gestellt zu werden. Georg Kreisler De: Zongning > Fecha: jueves, 10 de abril de 2014 05:21 Para: "vnfpool@ietf.org" > Asunto: [vnfpool] New revision of VNFPool Problem Statement posted Hi, folks, The new revision (-04) of VNFPool Problem Statement I-D is available on the= below page. https://datatracker.ietf.org/doc/draft-zong-vnfpool-problem-statement/ Here are the major changes: 1) Clarify VNFPool architecture and intended scope. 1. Add new section of VNF Pools before the section of Problem. This= new section is mainly to outline our scope based on high level description= of VNF Pools architecture. 2. Add text to clarify that we are specifically concerned with reli= ability (e.g. redundancy model, state sharing) that is managed inside the V= NF. We are only concerned with the whole VNF set (or forwarding graph) to t= he extent that it involves reliability impact on adjacent instances of diff= erent VNFs. 3. We focus on reliability mechanisms based on VNF pool. Other VNF = management aspects such as scaling, load balancing are out of scope. 2) Update terminologies to define Service Control Entity, and delete = Pool User as the pool will be internal to VNF only. 3) Re-arrange the text in section of Problems. 4) Update text of VNF instance performance degradation in section of = Problems. 5) Update text of Reliable Transport in section of Problems. 6) Add text to explain why service availability is not in scope in se= ction of Problems. 7) Re-write the section describing the relationship of VNFPool and SF= C. 8) Add text of transfer of security states in section of Security Con= sideration. We hope that the changes have addressed most of the comments, and reflected= most of the suggestions during London BoF. Please review this new revision. Your further comments and suggestions are = highly appreciated! Thanks. -Ning ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx --Boundary_(ID_euJhtjDjjrBvxjZYMdcZ0A) Content-id: <4E67F18445EADE428C689A55527A5B61@hi.inet> Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable
Reading through the ID, I have found some typos:

s/How is the service states/How are the service states/g
s/how do an adjacent VNF instance/how does an adjacent VNF instance/g<= /div>
s/For a VNF instance, it typically would not have built-in reliability= /A VNF instance would typically not have built-in reliability/g

A mail with requests for clarification will follow.

Thx,
BR,/PA
Dr. Pedro A. Aranda G= uti=E9rrez

Technology Exploratio= n -
Network Innovation &a= mp; Virtualisation

Telef=F3nica, Investi= gaci=F3n y Desarrollo
C/ D. Ram=F3n de la C= ruz,84
28006 Madrid, Spain

Fragen sind nicht da,= um beantwortet zu werden.
Fragen sind da, um ge= stellt zu werden.
Georg Kreisler

De: Zongning <zongning@huawei.com>
Fecha: jueves, 10 de abril de 2014 = 05:21
Para: "vnfpool@ietf.org" <vnfpool@ietf.org>
Asunto: [vnfpool] New revision of V= NFPool Problem Statement posted

Hi, folks,

 

The new revision (-04) of VNFPo= ol Problem Statement I-D is available on the below page.

https://datatracker.iet= f.org/doc/draft-zong-vnfpool-problem-statement/

 

Here are the major changes:

1)       Clarify VNFPool architecture and = intended scope.

1.      &nb= sp;  Add new section of VNF Pools befo= re the section of Problem. This new section is mainly to outline our scope = based on high level description of VNF Pools architecture.

2.      &nb= sp;  Add text to clarify that we are s= pecifically concerned with reliability (e.g. redundancy model, state sharin= g) that is managed inside the VNF. We are only concerned with the whole VNF= set (or forwarding graph) to the extent that it involves reliability impact on adjacent instances of differ= ent VNFs.

3.      &nb= sp;  We focus on reliability mechanism= s based on VNF pool. Other VNF management aspects such as scaling, load bal= ancing are out of scope.

2)       Update terminologies to define Se= rvice Control Entity, and delete Pool User as the pool will be internal to = VNF only.

3)       Re-arrange the text in section of= Problems.

4)       Update text of VNF instance perfo= rmance degradation in section of Problems.

5)       Update text of Reliable Transport= in section of Problems.

6)       Add text to explain why service a= vailability is not in scope in section of Problems.

7)       Re-write the section describing t= he relationship of VNFPool and SFC.

8)       Add text of transfer of security = states in section of Security Consideration.

 

We hope that the changes have a= ddressed most of the comments, and reflected most of the suggestions during= London BoF.

 

Please review this new revision= . Your further comments and suggestions are highly appreciated!

 

Thanks.

 

-Ning



Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo.
This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
 --Boundary_(ID_euJhtjDjjrBvxjZYMdcZ0A)-- From nobody Fri Apr 11 00:45:19 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 2290E1A03D9 for ; Fri, 11 Apr 2014 00:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.522 X-Spam-Level: X-Spam-Status: No, score=-98.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 2AS7twidEHow for ; Fri, 11 Apr 2014 00:45:13 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D09CC1A0411 for ; Fri, 11 Apr 2014 00:45:11 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFN05645; Fri, 11 Apr 2014 07:45:08 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 11 Apr 2014 08:43:59 +0100 Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 11 Apr 2014 08:45:05 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.85]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Fri, 11 Apr 2014 15:45:00 +0800 From: Zongning To: PEDRO ANDRES ARANDA GUTIERREZ , "vnfpool@ietf.org" Thread-Topic: [vnfpool] New revision of VNFPool Problem Statement posted Thread-Index: AQHPVJTKkZ5bXq91S0+hBxadIQptzZsMBfOQ Date: Fri, 11 Apr 2014 07:44:58 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.22] Content-Type: multipart/alternative; boundary="_000_B0D29E0424F2DE47A0B36779EC6667796611273Fnkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/O1qgHf7PrkVmd7jaAiNtMiQpC1A Subject: [vnfpool] =?gb2312?b?tPC4tDogIE5ldyByZXZpc2lvbiBvZiBWTkZQb29sIFBy?= =?gb2312?b?b2JsZW0gU3RhdGVtZW50IHBvc3RlZA==?= 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: Fri, 11 Apr 2014 07:45:18 -0000 --_000_B0D29E0424F2DE47A0B36779EC6667796611273Fnkgeml501mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIFBlZHJvLg0KDQpUaGFua3MgZm9yIHBvaW50aW5nIG91dCB0aGUgdHlwb3MuDQoNCkkgYXNz dW1lIHRoYXQgc29tZSBjby1hdXRob3JzIG9mIHVzZSBjYXNlcyAoaW5jbHVkaW5nIHlvdSA6KSkg YXJlIHdvcmtpbmcgb24gYSBuZXcgc2V0IG9mIFVzZSBDYXNlIEktRHMuIFNvIHBsZWFzZSBtYWtl IHN1cmUgdGhhdCB3ZSBrZWVwIGFsaWduZWQgd2l0aCBlYWNoIG90aGVyIHZlcnkgd2VsbC4gRm9y IGV4YW1wbGUsIGluIG5ldyBQUyBJLUQ6DQoNCjEpICAgICAgIFRlcm1pbm9sb2dpZXM6IE5GIC0+ ICh2aXJ0dWFsaXphdGlvbikgLT4gVk5GIC0+IChpbnN0YW50aWF0aW9uKS0+IFZORiBpbnN0YW5j ZSAtPiAoYSBncm91cCBvZiBWTkYgaW5zdGFuY2VzKSAtPiBWTkYgc2V0IC0+ICh1c2UgcG9vbGlu ZyBpZGVhKS0+IFZORiBQb29scyAoaW5jbHVkaW5nIFBvb2wgRWxlbWVudCwgUG9vbCBNYW5hZ2Vy KQ0KDQoyKSAgICAgICBTY29wZTogcGxlYXNlIHJlZmVyIHRvIG15IHByZXZpb3VzIGxpc3QgbWVz c2FnZSBvZiBuZXcgcmV2aXNpb24gbm90aWZpY2F0aW9uLg0KDQpIb3BlIHRoZXNlIHdvdWxkIGhl bHAhDQoNCi1OaW5nDQoNCg0Kt6K8/sjLOiBQRURSTyBBTkRSRVMgQVJBTkRBIEdVVElFUlJFWiBb bWFpbHRvOnBlZHJvYS5hcmFuZGFAdGlkLmVzXQ0Kt6LLzcqxvOQ6IDIwMTTE6jTUwjEwyNUgMTY6 MTQNCsrVvP7IyzogWm9uZ25pbmc7IHZuZnBvb2xAaWV0Zi5vcmcNCtb3zOI6IFJlOiBbdm5mcG9v bF0gTmV3IHJldmlzaW9uIG9mIFZORlBvb2wgUHJvYmxlbSBTdGF0ZW1lbnQgcG9zdGVkDQoNClJl YWRpbmcgdGhyb3VnaCB0aGUgSUQsIEkgaGF2ZSBmb3VuZCBzb21lIHR5cG9zOg0KDQpzL0hvdyBp cyB0aGUgc2VydmljZSBzdGF0ZXMvSG93IGFyZSB0aGUgc2VydmljZSBzdGF0ZXMvZw0Kcy9ob3cg ZG8gYW4gYWRqYWNlbnQgVk5GIGluc3RhbmNlL2hvdyBkb2VzIGFuIGFkamFjZW50IFZORiBpbnN0 YW5jZS9nDQpzL0ZvciBhIFZORiBpbnN0YW5jZSwgaXQgdHlwaWNhbGx5IHdvdWxkIG5vdCBoYXZl IGJ1aWx0LWluIHJlbGlhYmlsaXR5L0EgVk5GIGluc3RhbmNlIHdvdWxkIHR5cGljYWxseSBub3Qg aGF2ZSBidWlsdC1pbiByZWxpYWJpbGl0eS9nDQoNCkEgbWFpbCB3aXRoIHJlcXVlc3RzIGZvciBj bGFyaWZpY2F0aW9uIHdpbGwgZm9sbG93Lg0KDQpUaHgsDQpCUiwvUEENCkRyLiBQZWRybyBBLiBB cmFuZGEgR3V0aaimcnJleg0KDQpUZWNobm9sb2d5IEV4cGxvcmF0aW9uIC0NCk5ldHdvcmsgSW5u b3ZhdGlvbiAmIFZpcnR1YWxpc2F0aW9uDQoNCm1haWx0bzpwYWFnQHRpZC5lcw0KVGVsZWaorm5p Y2EsIEludmVzdGlnYWNpqK5uIHkgRGVzYXJyb2xsbw0KQy8gRC4gUmFtqK5uIGRlIGxhIENydXos ODQNCjI4MDA2IE1hZHJpZCwgU3BhaW4NCg0KRnJhZ2VuIHNpbmQgbmljaHQgZGEsIHVtIGJlYW50 d29ydGV0IHp1IHdlcmRlbi4NCkZyYWdlbiBzaW5kIGRhLCB1bSBnZXN0ZWxsdCB6dSB3ZXJkZW4u DQpHZW9yZyBLcmVpc2xlcg0KDQpEZTogWm9uZ25pbmcgPHpvbmduaW5nQGh1YXdlaS5jb208bWFp bHRvOnpvbmduaW5nQGh1YXdlaS5jb20+Pg0KRmVjaGE6IGp1ZXZlcywgMTAgZGUgYWJyaWwgZGUg MjAxNCAwNToyMQ0KUGFyYTogInZuZnBvb2xAaWV0Zi5vcmc8bWFpbHRvOnZuZnBvb2xAaWV0Zi5v cmc+IiA8dm5mcG9vbEBpZXRmLm9yZzxtYWlsdG86dm5mcG9vbEBpZXRmLm9yZz4+DQpBc3VudG86 IFt2bmZwb29sXSBOZXcgcmV2aXNpb24gb2YgVk5GUG9vbCBQcm9ibGVtIFN0YXRlbWVudCBwb3N0 ZWQNCg0KSGksIGZvbGtzLA0KDQpUaGUgbmV3IHJldmlzaW9uICgtMDQpIG9mIFZORlBvb2wgUHJv YmxlbSBTdGF0ZW1lbnQgSS1EIGlzIGF2YWlsYWJsZSBvbiB0aGUgYmVsb3cgcGFnZS4NCmh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXpvbmctdm5mcG9vbC1wcm9ibGVtLXN0 YXRlbWVudC8NCg0KSGVyZSBhcmUgdGhlIG1ham9yIGNoYW5nZXM6DQoNCjEpICAgICAgIENsYXJp ZnkgVk5GUG9vbCBhcmNoaXRlY3R1cmUgYW5kIGludGVuZGVkIHNjb3BlLg0KDQoxLiAgICAgICAg IEFkZCBuZXcgc2VjdGlvbiBvZiBWTkYgUG9vbHMgYmVmb3JlIHRoZSBzZWN0aW9uIG9mIFByb2Js ZW0uIFRoaXMgbmV3IHNlY3Rpb24gaXMgbWFpbmx5IHRvIG91dGxpbmUgb3VyIHNjb3BlIGJhc2Vk IG9uIGhpZ2ggbGV2ZWwgZGVzY3JpcHRpb24gb2YgVk5GIFBvb2xzIGFyY2hpdGVjdHVyZS4NCg0K Mi4gICAgICAgICBBZGQgdGV4dCB0byBjbGFyaWZ5IHRoYXQgd2UgYXJlIHNwZWNpZmljYWxseSBj b25jZXJuZWQgd2l0aCByZWxpYWJpbGl0eSAoZS5nLiByZWR1bmRhbmN5IG1vZGVsLCBzdGF0ZSBz aGFyaW5nKSB0aGF0IGlzIG1hbmFnZWQgaW5zaWRlIHRoZSBWTkYuIFdlIGFyZSBvbmx5IGNvbmNl cm5lZCB3aXRoIHRoZSB3aG9sZSBWTkYgc2V0IChvciBmb3J3YXJkaW5nIGdyYXBoKSB0byB0aGUg ZXh0ZW50IHRoYXQgaXQgaW52b2x2ZXMgcmVsaWFiaWxpdHkgaW1wYWN0IG9uIGFkamFjZW50IGlu c3RhbmNlcyBvZiBkaWZmZXJlbnQgVk5Gcy4NCg0KMy4gICAgICAgICBXZSBmb2N1cyBvbiByZWxp YWJpbGl0eSBtZWNoYW5pc21zIGJhc2VkIG9uIFZORiBwb29sLiBPdGhlciBWTkYgbWFuYWdlbWVu dCBhc3BlY3RzIHN1Y2ggYXMgc2NhbGluZywgbG9hZCBiYWxhbmNpbmcgYXJlIG91dCBvZiBzY29w ZS4NCg0KMikgICAgICAgVXBkYXRlIHRlcm1pbm9sb2dpZXMgdG8gZGVmaW5lIFNlcnZpY2UgQ29u dHJvbCBFbnRpdHksIGFuZCBkZWxldGUgUG9vbCBVc2VyIGFzIHRoZSBwb29sIHdpbGwgYmUgaW50 ZXJuYWwgdG8gVk5GIG9ubHkuDQoNCjMpICAgICAgIFJlLWFycmFuZ2UgdGhlIHRleHQgaW4gc2Vj dGlvbiBvZiBQcm9ibGVtcy4NCg0KNCkgICAgICAgVXBkYXRlIHRleHQgb2YgVk5GIGluc3RhbmNl IHBlcmZvcm1hbmNlIGRlZ3JhZGF0aW9uIGluIHNlY3Rpb24gb2YgUHJvYmxlbXMuDQoNCjUpICAg ICAgIFVwZGF0ZSB0ZXh0IG9mIFJlbGlhYmxlIFRyYW5zcG9ydCBpbiBzZWN0aW9uIG9mIFByb2Js ZW1zLg0KDQo2KSAgICAgICBBZGQgdGV4dCB0byBleHBsYWluIHdoeSBzZXJ2aWNlIGF2YWlsYWJp bGl0eSBpcyBub3QgaW4gc2NvcGUgaW4gc2VjdGlvbiBvZiBQcm9ibGVtcy4NCg0KNykgICAgICAg UmUtd3JpdGUgdGhlIHNlY3Rpb24gZGVzY3JpYmluZyB0aGUgcmVsYXRpb25zaGlwIG9mIFZORlBv b2wgYW5kIFNGQy4NCg0KOCkgICAgICAgQWRkIHRleHQgb2YgdHJhbnNmZXIgb2Ygc2VjdXJpdHkg c3RhdGVzIGluIHNlY3Rpb24gb2YgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbi4NCg0KV2UgaG9wZSB0 aGF0IHRoZSBjaGFuZ2VzIGhhdmUgYWRkcmVzc2VkIG1vc3Qgb2YgdGhlIGNvbW1lbnRzLCBhbmQg cmVmbGVjdGVkIG1vc3Qgb2YgdGhlIHN1Z2dlc3Rpb25zIGR1cmluZyBMb25kb24gQm9GLg0KDQpQ bGVhc2UgcmV2aWV3IHRoaXMgbmV3IHJldmlzaW9uLiBZb3VyIGZ1cnRoZXIgY29tbWVudHMgYW5k IHN1Z2dlc3Rpb25zIGFyZSBoaWdobHkgYXBwcmVjaWF0ZWQhDQoNClRoYW5rcy4NCg0KLU5pbmcN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KRXN0ZSBtZW5zYWplIHNlIGRp cmlnZSBleGNsdXNpdmFtZW50ZSBhIHN1IGRlc3RpbmF0YXJpby4gUHVlZGUgY29uc3VsdGFyIG51 ZXN0cmEgcG9sqKp0aWNhIGRlIGVudqiqbyB5IHJlY2VwY2morm4gZGUgY29ycmVvIGVsZWN0cqiu bmljbyBlbiBlbCBlbmxhY2Ugc2l0dWFkbyBtqKJzIGFiYWpvLg0KVGhpcyBtZXNzYWdlIGlzIGlu dGVuZGVkIGV4Y2x1c2l2ZWx5IGZvciBpdHMgYWRkcmVzc2VlLiBXZSBvbmx5IHNlbmQgYW5kIHJl Y2VpdmUgZW1haWwgb24gdGhlIGJhc2lzIG9mIHRoZSB0ZXJtcyBzZXQgb3V0IGF0Og0KaHR0cDov L3d3dy50aWQuZXMvRVMvUEFHSU5BUy9kaXNjbGFpbWVyLmFzcHgNCg== --_000_B0D29E0424F2DE47A0B36779EC6667796611273Fnkgeml501mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi, Ped= ro.

&n= bsp;

Thanks = for pointing out the typos.

&n= bsp;

I assum= e that some co-authors of use cases (including you J= ) are working on a new = set of Use Case I-Ds. So please make sure that we keep aligned with each ot= her very well. For example, in new PS I-D:

1)       Terminologies: NF -> (virtualization) -> VNF -> (instantiation)-&= gt; VNF instance -> (a group of VNF instances) -> VNF set -> (use = pooling idea)-> VNF Pools (including Pool Element, Pool Manager)

2)       Scope: please refer to my previous list message of new revision notificati= on.

&n= bsp;

Hope th= ese would help!

&n= bsp;

-Ning

&n= bsp;

&n= bsp;

=B7=A2=BC=FE=C8=CB: PEDRO ANDRES ARANDA GUTIERREZ [mailto:pedro= a.aranda@tid.es]
=B7=A2= =CB=CD=CA=B1=BC=E4: 2014=C4=EA4=D4=C210=C8=D5 16:14
=CA=D5=BC=FE=C8=CB: Zongning; vnfpool@ietf.org
=D6=F7=CC=E2: Re: [vnfpool] New revision of VNFPool Problem Statement posted=

 

Reading t= hrough the ID, I have found some typos:

&nbs= p;

s/How is = the service states/How are the service states/g

s/how do = an adjacent VNF instance/how does an adjacent VNF instance/g

s/For a V= NF instance, it typically would not have built-in reliability/A VNF instanc= e would typically not have built-in reliability/g

&nbs= p;

A mail wi= th requests for clarification will follow.

&nbs= p;

Thx,=

BR,/PA

Dr. Pedro A. Aranda Guti=A8=A6rrez<= /span>

 

Technology Exploration -

Network Innovation & Virtualisation

 

Telef=A8=AEnica, Investigaci=A8=AEn y Desarrol= lo

C/ D. Ram=A8=AEn de la Cruz,84

28006 Madrid, Spain

 

Fragen sind nicht da, um beantwortet zu werden= .

Fragen sind da, um gestellt zu werden.

Georg Kreisler

&nbs= p;

De: Zong= ning <zongning@huawei.com>=
Fecha: jueves, 10 de abril de 2014 05:21
Para: "vnfpool@ietf.org= " <vnfpool@ietf.org>
Asunto: [vnfpool] New revision of VNFPool Problem Statement posted

&nbs= p;

Hi, folks= ,

 

The new r= evision (-04) of VNFPool Problem Statement I-D is available on the below pa= ge.

https://datatracker.ietf.org/doc/draft-zong-vnfpool-problem-statement/=

 

Here are = the major changes:

1)       Clarify VNFPool architect= ure and intended scope.

1.         Add new section of VNF Po= ols before the section of Problem. This new section is mainly to outline ou= r scope based on high level description of VNF Pools architecture.

2.         Add text to clarify that = we are specifically concerned with reliability (e.g. redundancy model, stat= e sharing) that is managed inside the VNF. We are only concerned with the w= hole VNF set (or forwarding graph) to the extent that it involves reliability impact on adjacent instances of di= fferent VNFs.

3.         We focus on reliability m= echanisms based on VNF pool. Other VNF management aspects such as scaling, = load balancing are out of scope.

2)       Update terminologies to d= efine Service Control Entity, and delete Pool User as the pool will be inte= rnal to VNF only.

3)       Re-arrange the text in se= ction of Problems.

4)       Update text of VNF instan= ce performance degradation in section of Problems.

5)       Update text of Reliable T= ransport in section of Problems.

6)       Add text to explain why s= ervice availability is not in scope in section of Problems.

7)       Re-write the section desc= ribing the relationship of VNFPool and SFC.

8)       Add text of transfer of s= ecurity states in section of Security Consideration.

 

We hope t= hat the changes have addressed most of the comments, and reflected most of = the suggestions during London BoF.

 

Please re= view this new revision. Your further comments and suggestions are highly ap= preciated!

 

Thanks.

 

-Ning

 


Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=A8=AAtica de env=A8=AAo y recepci=A8=AEn de correo electr=A8=AEni= co en el enlace situado m=A8=A2s abajo.
This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at:
http://www.tid.es/= ES/PAGINAS/disclaimer.aspx

--_000_B0D29E0424F2DE47A0B36779EC6667796611273Fnkgeml501mbschi_-- From nobody Mon Apr 14 03:41:24 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 455401A03C2 for ; Mon, 14 Apr 2014 03:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.101 X-Spam-Level: X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 9-iNQlx_TndT for ; Mon, 14 Apr 2014 03:41:19 -0700 (PDT) Received: from out23-ams.mf.surf.net (out23-ams.mf.surf.net [145.0.1.23]) by ietfa.amsl.com (Postfix) with ESMTP id B4A601A03BF for ; Mon, 14 Apr 2014 03:41:13 -0700 (PDT) Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by outgoing1-ams.mf.surf.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id s3EAereh028737; Mon, 14 Apr 2014 12:40:53 +0200 Received: from EXHUB02.ad.utwente.nl (130.89.4.229) by EXEDGE01.ad.utwente.nl (130.89.5.48) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 14 Apr 2014 12:40:54 +0200 Received: from EXMBX23.ad.utwente.nl ([169.254.3.41]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.03.0181.006; Mon, 14 Apr 2014 12:40:53 +0200 From: To: Thread-Topic: Comments on draft-zong-vnfpool-problem-statement-04 Thread-Index: AQHPV84CA8VI2PcfvEGw8/ykUHjLdw== Date: Mon, 14 Apr 2014 10:40:53 +0000 Message-ID: Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [86.91.134.3] Content-Type: multipart/alternative; boundary="_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F44B51DEXMBX23adutwent_" MIME-Version: 1.0 X-Bayes-Prob: 0.0001 (Score 0, tokens from: utwente-out:default, base:default, @@RPTN) X-CanIt-Geo: ip=130.89.5.48; country=NL; region=Provincie Overijssel; city=Enschede; latitude=52.2195; longitude=6.8912; http://maps.google.com/maps?q=52.2195,6.8912&z=6 X-CanItPRO-Stream: utwente-out:default (inherits from utwente:default, base:default) X-Canit-Stats-ID: 0uLNKERQ5 - ae3c81167e0b - 20140414 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/-PEplXULCnEySNUVY8RC7h7cX2Y Cc: vnfpool@ietf.org Subject: [vnfpool] Comments on draft-zong-vnfpool-problem-statement-04 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: Mon, 14 Apr 2014 10:41:23 -0000 --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F44B51DEXMBX23adutwent_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ning, Please note that I have read the current version of the draft. This version clearer than the previous version of the draft, but IMHO it is= still not clear enough. The main comments that I have are: Comment_1: It is not clear what are the main differences between a VNF set = and a VNFpool. >From what I can assume is that the VNFpool is a group of VNF instances that= are providing the same network function and that the VNF set is a group of= VNF instances, each providing a different network function, which can be u= sed to build network services. Is this correct? In the Terminology section you provide the following definitions: VNF Pool: a group of VNF instances providing the same network function. VNF Set: a group of VNF instances that can be used to build network services. Maybe the following definitions might provide a clearer view: VNF Pool: a group of VNF instances providing the same network function. VNF Set: a group of VNF instances, each providing a different network funct= ion, which can be used to build network services. Comment_2: This comment is related to VNFpool and in particular what is mea= nt by: VNF instances providing the same network function? Are you referring= to identical VNF instances that are providing the same network function, i= .e., virtualized instances of the same network function, or does this defin= ition allow to use VNF instances that are not identical, but when they are = used together they form one virtualized network function. An example of the latter will be to virtualise a server, where the VNF of t= his server will be composed by a virtualized instance of the used protocol = stack, a second virtualized instance of the application running on the serv= er and a third virtualized instance of the data base used by the server. Ar= e you considering this composition of this VNF also a VNF pool? Comment_3: The problem statement is IMHO not clear. One of the reasons of t= his fact is that the definition of the VNF pool and the VNF set is not clea= r enough, see previous two comments. Other reasons are related to the fact= that the draft does not clearly explain: o) why is the reliability challenge mentioned in this draft different than = the reliability challenges and their solutions used for the physical device= s that are providing the same network function(s) as the mentioned VNF(s), = in this draft, are providing. o) why is the reliability challenge that needs to be solved by the VNFpool = (future) WG cannot be solved by the currently existing IETF WGs, such as SF= C. The reasons given in Section 6.3 are a bit contradictory. One of the rea= sons provided in that section is is that the reliability mechanisms in VNFp= ool are mostly internal to VNF, while another reason, given in the same sec= tion, is that the reliability mechanism deals with adjacencies in the VNF = set. The latter shows that the mechanisms are not internal to a VNFpool. Pl= ease clarify! Comment_4: Please clarify whether the scope of the reliability solution is = only limited within a VNF pool, or is it limited within a VNF set? If the s= cope is limited to a VNF set, then why are you emphasizing that the reliabi= lity mechanisms will not be visible to an SFC like control entity, since a = VNF set could form a service function chain, see Figure 2 of the draft. Comment_5: The draft needs to be more consistent on when the VNF set is use= d and when the VNF pool is used. Comment_6: There are also some editorial which need to be worked out in a n= ext version of the draft. Best regards, Georgios ________________________________ Van: vnfpool [vnfpool-bounces@ietf.org] namens Zongning [zongning@huawei.co= m] Verzonden: donderdag 10 april 2014 5:21 Aan: vnfpool@ietf.org Onderwerp: [vnfpool] New revision of VNFPool Problem Statement posted Hi, folks, The new revision (-04) of VNFPool Problem Statement I-D is available on the= below page. https://datatracker.ietf.org/doc/draft-zong-vnfpool-problem-statement/ Here are the major changes: 1) Clarify VNFPool architecture and intended scope. 1. Add new section of VNF Pools before the section of Problem. This= new section is mainly to outline our scope based on high level description= of VNF Pools architecture. 2. Add text to clarify that we are specifically concerned with reli= ability (e.g. redundancy model, state sharing) that is managed inside the V= NF. We are only concerned with the whole VNF set (or forwarding graph) to t= he extent that it involves reliability impact on adjacent instances of diff= erent VNFs. 3. We focus on reliability mechanisms based on VNF pool. Other VNF = management aspects such as scaling, load balancing are out of scope. 2) Update terminologies to define Service Control Entity, and delete = Pool User as the pool will be internal to VNF only. 3) Re-arrange the text in section of Problems. 4) Update text of VNF instance performance degradation in section of = Problems. 5) Update text of Reliable Transport in section of Problems. 6) Add text to explain why service availability is not in scope in se= ction of Problems. 7) Re-write the section describing the relationship of VNFPool and SF= C. 8) Add text of transfer of security states in section of Security Con= sideration. We hope that the changes have addressed most of the comments, and reflected= most of the suggestions during London BoF. Please review this new revision. Your further comments and suggestions are = highly appreciated! Thanks. -Ning --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F44B51DEXMBX23adutwent_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Ning,

 

Please note that I have read the cu= rrent version of the draft.

This version clearer than the previ= ous version of the draft, but IMHO it is still not clear enough.

 

The main comments that I have are:<= o:p>

 

Comment_1: It is not clear what are= the main differences between a VNF set and a VNFpool.

From what I can assume is that the = VNFpool is a group of VNF instances that are providing the same network function and that the VNF set is a group of VNF instances= , each providing a different network function, which can be used to build n= etwork services. Is this correct?

 

In the Terminology section you prov= ide the following definitions:

 

VNF Pool: a group of VNF instances = providing the same network

function.<= /span>

 

VNF Set: a group of VNF instances t= hat can be used to build network

services.<= /span>

 

Maybe the following definitions mig= ht provide a clearer view:

 

VNF Pool: a group of VNF instances = providing the same network

function.<= /span>

 

VNF Set: a group of VNF instances, = each providing a different network function,

which can be used to build network = services.

 

 

Comment_2: This comment is related = to VNFpool and in particular what is meant by: VNF instances providing the same network function? Are you referring to id= entical VNF instances that are providing the same network function, i.e., v= irtualized instances of the same network function, or does this definition = allow to use VNF instances that are not identical, but when they are used together they form one virtualiz= ed network function.

An example of the latter will be to= virtualise a server, where the VNF of this server will be composed by a virtualized instance of the used protocol stack, a s= econd virtualized instance of the application running on the server and a t= hird virtualized instance of the data base used by the server. Are you cons= idering this composition of this VNF also a VNF pool?

 

Comment_3: The problem statement is= IMHO not clear. One of the reasons of this fact is that the definition of the VNF pool and the VNF set is not clear enough= , see previous two comments. Other reasons  are related to the fact that the draft does not clearly explain:

o) why is the reliability challenge= mentioned in this draft different than the reliability challenges and their solutions used for the physical devices that are prov= iding the same network function(s) as the mentioned VNF(s), in this draft, = are providing.

o) why is the reliability challenge= that needs to be solved by the VNFpool (future) WG cannot be solved by the currently existing IETF WGs, such as SFC. The r= easons given in Section 6.3 are a bit contradictory. One of the reasons pro= vided in that section is is that the reliability mechanisms in VNFpool are = mostly internal to VNF, while another reason, given in the same section, = is that the reliability mechanism deals with adjacencies in the VNF= set. The latter shows that the mechanisms are not internal to a VNFpool. P= lease clarify!

 

Comment_4: Please clarify whether t= he scope of the reliability solution is only limited within a VNF pool, or is it limited within a VNF set? If the scope is limi= ted to a VNF set, then why are you emphasizing that the reliability mechani= sms will not be visible to an SFC like control entity, since a VNF set coul= d form a service function chain, see Figure 2 of the draft.

 

Comment_5: The draft needs to be mo= re consistent on when the VNF set is used and when the VNF pool is used.

 

Comment_6: There are also some edit= orial which need to be worked out in a next version of the draft.

 

Best regards,<= /p>

Georgios

&nb= sp;

 

 

 

Van: vnfpool [vnfpool-bounces@ietf.org] na= mens Zongning [zongning@huawei.com]
Verzonden: donderdag 10 april 2014 5:21
Aan: vnfpool@ietf.org
Onderwerp: [vnfpool] New revision of VNFPool Problem Statement poste= d

Hi, folks,

 

The new revision (-04) of VNFPo= ol Problem Statement I-D is available on the below page.

https= ://datatracker.ietf.org/doc/draft-zong-vnfpool-problem-statement/

 

Here are the major changes:

1)       Clarify VNFPool architecture and = intended scope.

1.         Add new section of VNF Pools befo= re the section of Problem. This new section is mainly to outline our scope = based on high level description of VNF Pools architecture.

2.         Add text to clarify that we are s= pecifically concerned with reliability (e.g. redundancy model, state sharin= g) that is managed inside the VNF. We are only concerned with the whole VNF= set (or forwarding graph) to the extent that it involves reliability impact on adjacent instances of differ= ent VNFs.

3.         We focus on reliability mechanism= s based on VNF pool. Other VNF management aspects such as scaling, load bal= ancing are out of scope.

2)       Update terminologies to define Se= rvice Control Entity, and delete Pool User as the pool will be internal to = VNF only.

3)       Re-arrange the text in section of= Problems.

4)       Update text of VNF instance perfo= rmance degradation in section of Problems.

5)       Update text of Reliable Transport= in section of Problems.

6)       Add text to explain why service a= vailability is not in scope in section of Problems.

7)       Re-write the section describing t= he relationship of VNFPool and SFC.

8)       Add text of transfer of security = states in section of Security Consideration.

 

We hope that the changes have a= ddressed most of the comments, and reflected most of the suggestions during= London BoF.

 

Please review this new revision= . Your further comments and suggestions are highly appreciated!

 

Thanks.

 

-Ning

--_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F44B51DEXMBX23adutwent_-- From nobody Mon Apr 14 08:39:49 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 2F25C1A048A for ; Mon, 14 Apr 2014 08:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 7qo-Q11VwxWr for ; Mon, 14 Apr 2014 08:39:41 -0700 (PDT) Received: from ignavia.lancs.ac.uk (ignavia.lancs.ac.uk [148.88.25.16]) by ietfa.amsl.com (Postfix) with ESMTP id 851A51A02CF for ; Mon, 14 Apr 2014 08:39:41 -0700 (PDT) Received: from ex-1-ht0.lancs.ac.uk ([10.42.18.57] helo=EX-1-HT0.lancs.local) by ignavia.lancs.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1WZiyw-0007bL-DK for vnfpool@ietf.org; Mon, 14 Apr 2014 16:39:38 +0100 Received: from EX-0-MB2.lancs.local ([fe80::9d98:936b:54d1:c531]) by EX-1-HT0.lancs.local ([fe80::d9e8:ad10:d075:a6b6%12]) with mapi id 14.03.0174.001; Mon, 14 Apr 2014 16:39:38 +0100 From: "King, Daniel" To: "vnfpool@ietf.org" Thread-Topic: Soliciting feedback for draft-king-vnfpool-mobile-use-case Thread-Index: Ac9X94oNLIEtgy21SgWfPOWL9bjMFw== Date: Mon, 14 Apr 2014 15:39:37 +0000 Message-ID: <65174429B5AF4C45BD0798810EC48E0A11A436@EX-0-MB2.lancs.local> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [88.97.23.122] x-iss-local-domain: 1 Content-Type: multipart/alternative; boundary="_000_65174429B5AF4C45BD0798810EC48E0A11A436EX0MB2lancslocal_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/vzOYOLVLmiOI5LRMGP6Os0Qo9FI Subject: [vnfpool] Soliciting feedback for draft-king-vnfpool-mobile-use-case 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: Mon, 14 Apr 2014 15:39:46 -0000 --_000_65174429B5AF4C45BD0798810EC48E0A11A436EX0MB2lancslocal_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, The mobile use case authors are currently working on a new version of the I= -D: https://github.com/danielkinguk/vnfpool/tree/master/mobile-use-case The repository contains two files: 1. "html diff 00 to 01.htm" - Well, the urm, diff from 00 version. 2. "draft-king-vnfpool-mobile-use-case-01.txt" - The current 01 versi= on includes: - Use of VNF Pool Definitions from Problem Statement I-D - Synched terminology from other VNF Pool I-Ds (VNF versus vNF, etc.) - Reduce Load Balancing discussion text, a bit of a contentious issue with = SFC working group right now so will let the Chairs resolve that one, and we= can update accordingly. - Added State Synchronization section - Various NIT ad grammar fixes Please feel free to contact us (authors) directly or via the list to discus= s the proposed changes, and any other updates you would like to see? Br, Dan. --_000_65174429B5AF4C45BD0798810EC48E0A11A436EX0MB2lancslocal_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

The mobile use case authors are currently working on= a new version of the I-D:

 

https://github.com/danielkinguk/vnfpool/tree/ma= ster/mobile-use-case

 

The repository contains two files:

 

1.     &= nbsp; “html diff 00 to 01.htm” – Well, = the urm, diff from 00 version.

2.     &= nbsp; “draft-king-vnfpool-mobile-use-case-01.txt= 221; – The current 01 version includes:

 

- Use of VNF Pool Definitions from Problem Statement= I-D

- Synched terminology from other VNF Pool I-Ds (VNF = versus vNF, etc.)

- Reduce Load Balancing discussion text, a bit of a = contentious issue with SFC working group right now so will let the Chairs r= esolve that one, and we can update accordingly.

- Added State Synchronization section

- Various NIT ad grammar fixes

 

Please feel free to contact us (authors) directly or= via the list to discuss the proposed changes, and any other updates you wo= uld like to see?

 

Br, Dan.

--_000_65174429B5AF4C45BD0798810EC48E0A11A436EX0MB2lancslocal_-- From nobody Mon Apr 14 11:29:24 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 CBF581A0262 for ; Mon, 14 Apr 2014 11:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 OD-6DhuAOQY5 for ; Mon, 14 Apr 2014 11:29:18 -0700 (PDT) Received: from lipwig.lancs.ac.uk (lipwig.lancs.ac.uk [148.88.25.19]) by ietfa.amsl.com (Postfix) with ESMTP id 60F661A0493 for ; Mon, 14 Apr 2014 11:29:18 -0700 (PDT) Received: from ex-0-ht0.lancs.ac.uk ([10.42.18.47] helo=EX-0-HT0.lancs.local) by lipwig.lancs.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1WZld5-0005dU-Dn for vnfpool@ietf.org; Mon, 14 Apr 2014 19:29:15 +0100 Received: from EX-0-MB2.lancs.local ([fe80::9d98:936b:54d1:c531]) by EX-0-HT0.lancs.local ([fe80::7d10:114a:53b0:7f2f%12]) with mapi id 14.03.0174.001; Mon, 14 Apr 2014 19:29:15 +0100 From: "King, Daniel" To: "vnfpool@ietf.org" Thread-Topic: Also soliciting feedback for draft-xia-vnfpool-use-cases Thread-Index: Ac9YD1+/btGK0cpSTMK0UF/6BqknpA== Date: Mon, 14 Apr 2014 18:29:14 +0000 Message-ID: <65174429B5AF4C45BD0798810EC48E0A11A484@EX-0-MB2.lancs.local> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [88.97.23.122] x-iss-local-domain: 1 Content-Type: multipart/alternative; boundary="_000_65174429B5AF4C45BD0798810EC48E0A11A484EX0MB2lancslocal_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/XzQRO5Fd04YIqO4eL3cspclL6os Subject: [vnfpool] Also soliciting feedback for draft-xia-vnfpool-use-cases 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: Mon, 14 Apr 2014 18:29:23 -0000 --_000_65174429B5AF4C45BD0798810EC48E0A11A484EX0MB2lancslocal_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All (Again), We are also updating the general Use Case I-D. Please find our latest versi= on on GitHub: https://github.com/danielkinguk/vnfpool/tree/master/general-use-case With the following updates: - Synchronization of terminology with other VNF Pool I-Ds - Using definitions from Problem Statement I-D - Removing some of the contentious items that overlap with SFC (tr= affic steering), at least until we resolve the situation - Discussion text for State Synchronization - Discussion text for VNF Set - Various Nits and grammar updates Br, Dan. --_000_65174429B5AF4C45BD0798810EC48E0A11A484EX0MB2lancslocal_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All (Again),

 

We are also updating the general Use Case I-D. Pleas= e find our latest version on GitHub:

 

https://github.com/danielkinguk/vnfpool/tree/m= aster/general-use-case

 

With the following updates:

 

-     &= nbsp;    Synchronization of terminology with other VNF Pool = I-Ds

-     &= nbsp;    Using definitions from Problem Statement I-D

-     &= nbsp;    Removing some of the contentious items that overlap= with SFC (traffic steering), at least until we resolve the situation<= /o:p>

-     &= nbsp;    Discussion text for State Synchronization

-     &= nbsp;    Discussion text for VNF Set

-     &= nbsp;    Various Nits and grammar updates

 

Br, Dan.

--_000_65174429B5AF4C45BD0798810EC48E0A11A484EX0MB2lancslocal_-- From nobody Mon Apr 14 20:56:29 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 57D0C1A0198 for ; Mon, 14 Apr 2014 20:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.623 X-Spam-Level: X-Spam-Status: No, score=-96.623 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 CQ-QUwhRbmKj for ; Mon, 14 Apr 2014 20:56:19 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7459F1A0751 for ; Mon, 14 Apr 2014 20:56:18 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDC47466; Tue, 15 Apr 2014 03:56:11 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 15 Apr 2014 04:54:38 +0100 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 15 Apr 2014 04:56:09 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.85]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Tue, 15 Apr 2014 11:56:06 +0800 From: Zongning To: "karagian@cs.utwente.nl" Thread-Topic: Comments on draft-zong-vnfpool-problem-statement-04 Thread-Index: AQHPV84CA8VI2PcfvEGw8/ykUHjLd5sR/mfQ Date: Tue, 15 Apr 2014 03:56:05 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.22] Content-Type: multipart/alternative; boundary="_000_B0D29E0424F2DE47A0B36779EC66677966113193nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/_2Ulg9rI0-2jZYr_Al2cXlaCf08 Cc: "vnfpool@ietf.org" Subject: [vnfpool] =?gb2312?b?tPC4tDogQ29tbWVudHMgb24gZHJhZnQtem9uZy12bmZw?= =?gb2312?b?b29sLXByb2JsZW0tc3RhdGVtZW50LTA0?= 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: Tue, 15 Apr 2014 03:56:24 -0000 --_000_B0D29E0424F2DE47A0B36779EC66677966113193nkgeml501mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIEdlb3JnaW9zLA0KDQpBcHByZWNpYXRlIHlvdXIgY29tbWVudHMhDQoNCkZpcnN0bHksIGxl dCBtZSB0cnkgdG8gY2xhcmlmeSB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIFZORiBzZXQgYW5kIFZO RiBwb29sLiBWTkYgc2V0IGlzIGp1c3QgYSBnZW5lcmFsIHNldCBvZiBhbGwgdGhlIFZORiBpbnN0 YW5jZXMuIEluIFZORiBQb29sIGFyY2hpdGVjdHVyZSwgYWxsIHRoZXNlIFZORiBpbnN0YW5jZXMg YXJlIGFjdHVhbGx5IGdyb3VwZWQgaW50byBtdWx0aXBsZSBwb29scywgYmFzZWQgb24gdGhlIGZ1 bmN0aW9ucyB0aGV5IHByb3ZpZGVkLiBGb3IgZXhhbXBsZSwgYSBWTkYgc2V0IHt2RlcjMSwgdkZX IzIsIHZMQiMxLCB2TEIjMiwgdkxCIzN9IGNhbiBiZSBncm91cGVkIGludG8gdHdvIFZORiBwb29s cyCoQyBvbmUgcG9vbCBpcyB7dkZXIzEsIHZGVyMyfSwgYW5vdGhlciBpcyB7dkxCIzEsIHZMQiMy LCB2TEIjM30uIFNvLCBtYXliZSB0aGUgZm9sbG93aW5nIGRlZmluaXRpb24gaXMgYmV0dGVyOg0K DQpWTkYgUG9vbDogYSBncm91cCBvZiBWTkYgaW5zdGFuY2VzIHByb3ZpZGluZyB0aGUgc2FtZSBu ZXR3b3JrIGZ1bmN0aW9uLg0KDQpWTkYgU2V0OiBhIGdlbmVyYWwgc2V0IG9mIFZORiBpbnN0YW5j ZXMgdGhhdCBjYW4gYmUgZ3JvdXBlZCBpbnRvIG11bHRpcGxlIFZORiBwb29scyB3aGVyZSBkaWZm ZXJlbnQgcG9vbHMgcHJvdmlkZSBkaWZmZXJlbnQgZnVuY3Rpb25zLg0KDQpDb21tZW50XzIgaXMg bW9yZSBpbnRlcmVzdGluZyAoaW5kZWVkISA6KSkgYW5kIHJlbGF0ZWQgdG8gVk5GIGluc3RhbmNl IGltcGxlbWVudGF0aW9uLiBBdCB0aGlzIHBvaW50IG9mIHRpbWUsIGhvdyBhYm91dCBqdXN0IGxp bWl0aW5nIG91cnNlbHZlcyB0byB5b3VyIGZvcm1lciBjYXNlLCBpLmUuLCBWTkYgaW5zdGFuY2Vz IGFyZSBpZGVudGljYWwgaW4gYSBwb29sLiBUaGUgbGF0dGVyIGNhc2UgaXMgYWN0dWFsbHkgYWJv dXQgZnVydGhlciBkZWNvbXBvc2l0aW9uIG9mIFZORiBpbnN0YW5jZSB0byBtb3JlIFZORiBjb21w b25lbnRzIChWTkZDcykuIEkgd291bGQgZ3Vlc3MgdGhpcyBpcyBtb3JlIGNvbXBsaWNhdGVkICho aWVyYXJjaGljYWwpIHBvb2xpbmcgYXJjaGl0ZWN0dXJlIHRvIGJlIHN0dWRpZWQgbGF0ZXIuDQoN CkNvbW1lbnRfMyAmIDQgaXMgYWJvdXQgb3VyIHNjb3BlLiBBcyBlbXBoYXNpemVkIGluIGRyYWZ0 LCB3ZSBtb3N0bHkgY29uc2lkZXIgdGhlIHJlbGlhYmlsaXR5IChvciBwb29saW5nKSBpbnNpZGUg YSBWTkYuIE91ciBzY29wZSBpcyBzdGlsbCBpbnRlbmRlZCBvbiBWTkYgc2V0LCBidXQgKm9ubHkq IHRvIHRoZSBleHRlbnQgdGhhdCBpdCBpbnZvbHZlcyByZWxpYWJpbGl0eSBpbXBhY3Qgb24gYWRq YWNlbnQgVk5GIGluc3RhbmNlcyBpbiBkaWZmZXJlbnQgVk5GIHBvb2xzLiBUaGUgY29vcmRpbmF0 aW9uIHRyYWZmaWMgYmV0d2VlbiBWTkZzIGRlYWxpbmcgd2l0aCByZWxpYWJpbGl0eSBjYW4gYmUg c3RpbGwgaW52aXNpYmxlIHRvIHRoZSBTZXJ2aWNlIENvbnRyb2wgRW50aXR5LCBpZiB0aGVzZSBt ZXNzYWdlcyBhcmUgZGlyZWN0bHkgdHJhbnNmZXJyZWQgYmV0d2VlbiBhZGphY2VudCBWTkYgcG9v bHMuIFNvbWUgdXNlIGNhc2VzIGluIG91ciBVc2UgQ2FzZSBJLURzIGhhdmUgc2hvd24gdGhlIGJl bmVmaXRzIG9mIGRpcmVjdCBjb21tdW5pY2F0aW9uIGJldHdlZW4gcG9vbHMuIFlvdSBhcmUgcmln aHQgaW4gdGhlIHNlbnNlIHRoYXQgaWYgc3VjaCBjb29yZGluYXRpb24gaXMgZXhwbGljaXRseSBt YW5hZ2VkIGJ5IHRoZSBTZXJ2aWNlIENvbnRyb2wgRW50aXR5LCBvdGhlciBXRyhzKSBjb3VsZCBi ZSBhYmxlIHRvIGhhbmRsZSBpdCAtIHRoaXMgd2lsbCBkZXBlbmQgb24gbW9yZSBjYXNlIHN0dWR5 Lg0KDQpTb3JyeSwgYnV0IEkgYW0gbm90IHN1cmUgSSBmdWxseSB1bmRlcnN0YW5kIHlvdXIgZmly c3QgYnVsbGV0IGluIENvbW1lbnRfMy4NCg0KQ29tbWVudF81ICYgNjogWWVzLCB3ZSB3aWxsIGlt cHJvdmUgYXMgbXVjaCBhcyB3ZSBjb3VsZCBpbiBmdXR1cmUgcmV2aXNpb24uDQoNCkhvcGUgbXkg cmVwbHkgaGVscHMgYSBsaXR0bGUgYml0LiA6KQ0KDQpQbGVhc2UgZG8gbGV0IG1lIGtub3cgeW91 ciBmdXJ0aGVyIHF1ZXN0aW9ucy9jb21tZW50cy4NCg0KLU5pbmcNCg0Kt6K8/sjLOiBrYXJhZ2lh bkBjcy51dHdlbnRlLm5sIFttYWlsdG86a2FyYWdpYW5AY3MudXR3ZW50ZS5ubF0NCreiy83Ksbzk OiAyMDE0xOo01MIxNMjVIDE4OjQxDQrK1bz+yMs6IFpvbmduaW5nDQqzrcvNOiB2bmZwb29sQGll dGYub3JnDQrW98ziOiBDb21tZW50cyBvbiBkcmFmdC16b25nLXZuZnBvb2wtcHJvYmxlbS1zdGF0 ZW1lbnQtMDQNCg0KSGkgTmluZywNCg0KUGxlYXNlIG5vdGUgdGhhdCBJIGhhdmUgcmVhZCB0aGUg Y3VycmVudCB2ZXJzaW9uIG9mIHRoZSBkcmFmdC4NClRoaXMgdmVyc2lvbiBjbGVhcmVyIHRoYW4g dGhlIHByZXZpb3VzIHZlcnNpb24gb2YgdGhlIGRyYWZ0LCBidXQgSU1ITyBpdCBpcyBzdGlsbCBu b3QgY2xlYXIgZW5vdWdoLg0KDQpUaGUgbWFpbiBjb21tZW50cyB0aGF0IEkgaGF2ZSBhcmU6DQoN CkNvbW1lbnRfMTogSXQgaXMgbm90IGNsZWFyIHdoYXQgYXJlIHRoZSBtYWluIGRpZmZlcmVuY2Vz IGJldHdlZW4gYSBWTkYgc2V0IGFuZCBhIFZORnBvb2wuDQpGcm9tIHdoYXQgSSBjYW4gYXNzdW1l IGlzIHRoYXQgdGhlIFZORnBvb2wgaXMgYSBncm91cCBvZiBWTkYgaW5zdGFuY2VzIHRoYXQgYXJl IHByb3ZpZGluZyB0aGUgc2FtZSBuZXR3b3JrIGZ1bmN0aW9uIGFuZCB0aGF0IHRoZSBWTkYgc2V0 IGlzIGEgZ3JvdXAgb2YgVk5GIGluc3RhbmNlcywgZWFjaCBwcm92aWRpbmcgYSBkaWZmZXJlbnQg bmV0d29yayBmdW5jdGlvbiwgd2hpY2ggY2FuIGJlIHVzZWQgdG8gYnVpbGQgbmV0d29yayBzZXJ2 aWNlcy4gSXMgdGhpcyBjb3JyZWN0Pw0KDQpJbiB0aGUgVGVybWlub2xvZ3kgc2VjdGlvbiB5b3Ug cHJvdmlkZSB0aGUgZm9sbG93aW5nIGRlZmluaXRpb25zOg0KDQpWTkYgUG9vbDogYSBncm91cCBv ZiBWTkYgaW5zdGFuY2VzIHByb3ZpZGluZyB0aGUgc2FtZSBuZXR3b3JrDQpmdW5jdGlvbi4NCg0K Vk5GIFNldDogYSBncm91cCBvZiBWTkYgaW5zdGFuY2VzIHRoYXQgY2FuIGJlIHVzZWQgdG8gYnVp bGQgbmV0d29yaw0Kc2VydmljZXMuDQoNCk1heWJlIHRoZSBmb2xsb3dpbmcgZGVmaW5pdGlvbnMg bWlnaHQgcHJvdmlkZSBhIGNsZWFyZXIgdmlldzoNCg0KVk5GIFBvb2w6IGEgZ3JvdXAgb2YgVk5G IGluc3RhbmNlcyBwcm92aWRpbmcgdGhlIHNhbWUgbmV0d29yaw0KZnVuY3Rpb24uDQoNClZORiBT ZXQ6IGEgZ3JvdXAgb2YgVk5GIGluc3RhbmNlcywgZWFjaCBwcm92aWRpbmcgYSBkaWZmZXJlbnQg bmV0d29yayBmdW5jdGlvbiwNCndoaWNoIGNhbiBiZSB1c2VkIHRvIGJ1aWxkIG5ldHdvcmsgc2Vy dmljZXMuDQoNCg0KQ29tbWVudF8yOiBUaGlzIGNvbW1lbnQgaXMgcmVsYXRlZCB0byBWTkZwb29s IGFuZCBpbiBwYXJ0aWN1bGFyIHdoYXQgaXMgbWVhbnQgYnk6IFZORiBpbnN0YW5jZXMgcHJvdmlk aW5nIHRoZSBzYW1lIG5ldHdvcmsgZnVuY3Rpb24/IEFyZSB5b3UgcmVmZXJyaW5nIHRvIGlkZW50 aWNhbCBWTkYgaW5zdGFuY2VzIHRoYXQgYXJlIHByb3ZpZGluZyB0aGUgc2FtZSBuZXR3b3JrIGZ1 bmN0aW9uLCBpLmUuLCB2aXJ0dWFsaXplZCBpbnN0YW5jZXMgb2YgdGhlIHNhbWUgbmV0d29yayBm dW5jdGlvbiwgb3IgZG9lcyB0aGlzIGRlZmluaXRpb24gYWxsb3cgdG8gdXNlIFZORiBpbnN0YW5j ZXMgdGhhdCBhcmUgbm90IGlkZW50aWNhbCwgYnV0IHdoZW4gdGhleSBhcmUgdXNlZCB0b2dldGhl ciB0aGV5IGZvcm0gb25lIHZpcnR1YWxpemVkIG5ldHdvcmsgZnVuY3Rpb24uDQpBbiBleGFtcGxl IG9mIHRoZSBsYXR0ZXIgd2lsbCBiZSB0byB2aXJ0dWFsaXNlIGEgc2VydmVyLCB3aGVyZSB0aGUg Vk5GIG9mIHRoaXMgc2VydmVyIHdpbGwgYmUgY29tcG9zZWQgYnkgYSB2aXJ0dWFsaXplZCBpbnN0 YW5jZSBvZiB0aGUgdXNlZCBwcm90b2NvbCBzdGFjaywgYSBzZWNvbmQgdmlydHVhbGl6ZWQgaW5z dGFuY2Ugb2YgdGhlIGFwcGxpY2F0aW9uIHJ1bm5pbmcgb24gdGhlIHNlcnZlciBhbmQgYSB0aGly ZCB2aXJ0dWFsaXplZCBpbnN0YW5jZSBvZiB0aGUgZGF0YSBiYXNlIHVzZWQgYnkgdGhlIHNlcnZl ci4gQXJlIHlvdSBjb25zaWRlcmluZyB0aGlzIGNvbXBvc2l0aW9uIG9mIHRoaXMgVk5GIGFsc28g YSBWTkYgcG9vbD8NCg0KQ29tbWVudF8zOiBUaGUgcHJvYmxlbSBzdGF0ZW1lbnQgaXMgSU1ITyBu b3QgY2xlYXIuIE9uZSBvZiB0aGUgcmVhc29ucyBvZiB0aGlzIGZhY3QgaXMgdGhhdCB0aGUgZGVm aW5pdGlvbiBvZiB0aGUgVk5GIHBvb2wgYW5kIHRoZSBWTkYgc2V0IGlzIG5vdCBjbGVhciBlbm91 Z2gsIHNlZSBwcmV2aW91cyB0d28gY29tbWVudHMuIE90aGVyIHJlYXNvbnMgIGFyZSByZWxhdGVk IHRvIHRoZSBmYWN0IHRoYXQgdGhlIGRyYWZ0IGRvZXMgbm90IGNsZWFybHkgZXhwbGFpbjoNCm8p IHdoeSBpcyB0aGUgcmVsaWFiaWxpdHkgY2hhbGxlbmdlIG1lbnRpb25lZCBpbiB0aGlzIGRyYWZ0 IGRpZmZlcmVudCB0aGFuIHRoZSByZWxpYWJpbGl0eSBjaGFsbGVuZ2VzIGFuZCB0aGVpciBzb2x1 dGlvbnMgdXNlZCBmb3IgdGhlIHBoeXNpY2FsIGRldmljZXMgdGhhdCBhcmUgcHJvdmlkaW5nIHRo ZSBzYW1lIG5ldHdvcmsgZnVuY3Rpb24ocykgYXMgdGhlIG1lbnRpb25lZCBWTkYocyksIGluIHRo aXMgZHJhZnQsIGFyZSBwcm92aWRpbmcuDQpvKSB3aHkgaXMgdGhlIHJlbGlhYmlsaXR5IGNoYWxs ZW5nZSB0aGF0IG5lZWRzIHRvIGJlIHNvbHZlZCBieSB0aGUgVk5GcG9vbCAoZnV0dXJlKSBXRyBj YW5ub3QgYmUgc29sdmVkIGJ5IHRoZSBjdXJyZW50bHkgZXhpc3RpbmcgSUVURiBXR3MsIHN1Y2gg YXMgU0ZDLiBUaGUgcmVhc29ucyBnaXZlbiBpbiBTZWN0aW9uIDYuMyBhcmUgYSBiaXQgY29udHJh ZGljdG9yeS4gT25lIG9mIHRoZSByZWFzb25zIHByb3ZpZGVkIGluIHRoYXQgc2VjdGlvbiBpcyBp cyB0aGF0IHRoZSByZWxpYWJpbGl0eSBtZWNoYW5pc21zIGluIFZORnBvb2wgYXJlIG1vc3RseSBp bnRlcm5hbCB0byBWTkYsIHdoaWxlIGFub3RoZXIgcmVhc29uLCBnaXZlbiBpbiB0aGUgc2FtZSBz ZWN0aW9uLCAgaXMgdGhhdCB0aGUgcmVsaWFiaWxpdHkgbWVjaGFuaXNtIGRlYWxzIHdpdGggYWRq YWNlbmNpZXMgaW4gdGhlIFZORiBzZXQuIFRoZSBsYXR0ZXIgc2hvd3MgdGhhdCB0aGUgbWVjaGFu aXNtcyBhcmUgbm90IGludGVybmFsIHRvIGEgVk5GcG9vbC4gUGxlYXNlIGNsYXJpZnkhDQoNCkNv bW1lbnRfNDogUGxlYXNlIGNsYXJpZnkgd2hldGhlciB0aGUgc2NvcGUgb2YgdGhlIHJlbGlhYmls aXR5IHNvbHV0aW9uIGlzIG9ubHkgbGltaXRlZCB3aXRoaW4gYSBWTkYgcG9vbCwgb3IgaXMgaXQg bGltaXRlZCB3aXRoaW4gYSBWTkYgc2V0PyBJZiB0aGUgc2NvcGUgaXMgbGltaXRlZCB0byBhIFZO RiBzZXQsIHRoZW4gd2h5IGFyZSB5b3UgZW1waGFzaXppbmcgdGhhdCB0aGUgcmVsaWFiaWxpdHkg bWVjaGFuaXNtcyB3aWxsIG5vdCBiZSB2aXNpYmxlIHRvIGFuIFNGQyBsaWtlIGNvbnRyb2wgZW50 aXR5LCBzaW5jZSBhIFZORiBzZXQgY291bGQgZm9ybSBhIHNlcnZpY2UgZnVuY3Rpb24gY2hhaW4s IHNlZSBGaWd1cmUgMiBvZiB0aGUgZHJhZnQuDQoNCkNvbW1lbnRfNTogVGhlIGRyYWZ0IG5lZWRz IHRvIGJlIG1vcmUgY29uc2lzdGVudCBvbiB3aGVuIHRoZSBWTkYgc2V0IGlzIHVzZWQgYW5kIHdo ZW4gdGhlIFZORiBwb29sIGlzIHVzZWQuDQoNCkNvbW1lbnRfNjogVGhlcmUgYXJlIGFsc28gc29t ZSBlZGl0b3JpYWwgd2hpY2ggbmVlZCB0byBiZSB3b3JrZWQgb3V0IGluIGEgbmV4dCB2ZXJzaW9u IG9mIHRoZSBkcmFmdC4NCg0KQmVzdCByZWdhcmRzLA0KR2Vvcmdpb3MNCg0KDQoNCg0KDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpWYW46IHZuZnBvb2wgW3ZuZnBvb2wtYm91 bmNlc0BpZXRmLm9yZ10gbmFtZW5zIFpvbmduaW5nIFt6b25nbmluZ0BodWF3ZWkuY29tXQ0KVmVy em9uZGVuOiBkb25kZXJkYWcgMTAgYXByaWwgMjAxNCA1OjIxDQpBYW46IHZuZnBvb2xAaWV0Zi5v cmc8bWFpbHRvOnZuZnBvb2xAaWV0Zi5vcmc+DQpPbmRlcndlcnA6IFt2bmZwb29sXSBOZXcgcmV2 aXNpb24gb2YgVk5GUG9vbCBQcm9ibGVtIFN0YXRlbWVudCBwb3N0ZWQNCkhpLCBmb2xrcywNCg0K VGhlIG5ldyByZXZpc2lvbiAoLTA0KSBvZiBWTkZQb29sIFByb2JsZW0gU3RhdGVtZW50IEktRCBp cyBhdmFpbGFibGUgb24gdGhlIGJlbG93IHBhZ2UuDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC16b25nLXZuZnBvb2wtcHJvYmxlbS1zdGF0ZW1lbnQvDQoNCkhlcmUgYXJl IHRoZSBtYWpvciBjaGFuZ2VzOg0KDQoxKSAgICAgICBDbGFyaWZ5IFZORlBvb2wgYXJjaGl0ZWN0 dXJlIGFuZCBpbnRlbmRlZCBzY29wZS4NCg0KMS4gICAgICAgICBBZGQgbmV3IHNlY3Rpb24gb2Yg Vk5GIFBvb2xzIGJlZm9yZSB0aGUgc2VjdGlvbiBvZiBQcm9ibGVtLiBUaGlzIG5ldyBzZWN0aW9u IGlzIG1haW5seSB0byBvdXRsaW5lIG91ciBzY29wZSBiYXNlZCBvbiBoaWdoIGxldmVsIGRlc2Ny aXB0aW9uIG9mIFZORiBQb29scyBhcmNoaXRlY3R1cmUuDQoNCjIuICAgICAgICAgQWRkIHRleHQg dG8gY2xhcmlmeSB0aGF0IHdlIGFyZSBzcGVjaWZpY2FsbHkgY29uY2VybmVkIHdpdGggcmVsaWFi aWxpdHkgKGUuZy4gcmVkdW5kYW5jeSBtb2RlbCwgc3RhdGUgc2hhcmluZykgdGhhdCBpcyBtYW5h Z2VkIGluc2lkZSB0aGUgVk5GLiBXZSBhcmUgb25seSBjb25jZXJuZWQgd2l0aCB0aGUgd2hvbGUg Vk5GIHNldCAob3IgZm9yd2FyZGluZyBncmFwaCkgdG8gdGhlIGV4dGVudCB0aGF0IGl0IGludm9s dmVzIHJlbGlhYmlsaXR5IGltcGFjdCBvbiBhZGphY2VudCBpbnN0YW5jZXMgb2YgZGlmZmVyZW50 IFZORnMuDQoNCjMuICAgICAgICAgV2UgZm9jdXMgb24gcmVsaWFiaWxpdHkgbWVjaGFuaXNtcyBi YXNlZCBvbiBWTkYgcG9vbC4gT3RoZXIgVk5GIG1hbmFnZW1lbnQgYXNwZWN0cyBzdWNoIGFzIHNj YWxpbmcsIGxvYWQgYmFsYW5jaW5nIGFyZSBvdXQgb2Ygc2NvcGUuDQoNCjIpICAgICAgIFVwZGF0 ZSB0ZXJtaW5vbG9naWVzIHRvIGRlZmluZSBTZXJ2aWNlIENvbnRyb2wgRW50aXR5LCBhbmQgZGVs ZXRlIFBvb2wgVXNlciBhcyB0aGUgcG9vbCB3aWxsIGJlIGludGVybmFsIHRvIFZORiBvbmx5Lg0K DQozKSAgICAgICBSZS1hcnJhbmdlIHRoZSB0ZXh0IGluIHNlY3Rpb24gb2YgUHJvYmxlbXMuDQoN CjQpICAgICAgIFVwZGF0ZSB0ZXh0IG9mIFZORiBpbnN0YW5jZSBwZXJmb3JtYW5jZSBkZWdyYWRh dGlvbiBpbiBzZWN0aW9uIG9mIFByb2JsZW1zLg0KDQo1KSAgICAgICBVcGRhdGUgdGV4dCBvZiBS ZWxpYWJsZSBUcmFuc3BvcnQgaW4gc2VjdGlvbiBvZiBQcm9ibGVtcy4NCg0KNikgICAgICAgQWRk IHRleHQgdG8gZXhwbGFpbiB3aHkgc2VydmljZSBhdmFpbGFiaWxpdHkgaXMgbm90IGluIHNjb3Bl IGluIHNlY3Rpb24gb2YgUHJvYmxlbXMuDQoNCjcpICAgICAgIFJlLXdyaXRlIHRoZSBzZWN0aW9u IGRlc2NyaWJpbmcgdGhlIHJlbGF0aW9uc2hpcCBvZiBWTkZQb29sIGFuZCBTRkMuDQoNCjgpICAg ICAgIEFkZCB0ZXh0IG9mIHRyYW5zZmVyIG9mIHNlY3VyaXR5IHN0YXRlcyBpbiBzZWN0aW9uIG9m IFNlY3VyaXR5IENvbnNpZGVyYXRpb24uDQoNCldlIGhvcGUgdGhhdCB0aGUgY2hhbmdlcyBoYXZl IGFkZHJlc3NlZCBtb3N0IG9mIHRoZSBjb21tZW50cywgYW5kIHJlZmxlY3RlZCBtb3N0IG9mIHRo ZSBzdWdnZXN0aW9ucyBkdXJpbmcgTG9uZG9uIEJvRi4NCg0KUGxlYXNlIHJldmlldyB0aGlzIG5l dyByZXZpc2lvbi4gWW91ciBmdXJ0aGVyIGNvbW1lbnRzIGFuZCBzdWdnZXN0aW9ucyBhcmUgaGln aGx5IGFwcHJlY2lhdGVkIQ0KDQpUaGFua3MuDQoNCi1OaW5nDQo= --_000_B0D29E0424F2DE47A0B36779EC66677966113193nkgeml501mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi, Geo= rgios,

&n= bsp;

Appreci= ate your comments!

&n= bsp;

Firstly= , let me try to clarify the difference between VNF set and VNF pool. VNF set is just a gener= al set of all the VNF instances. In VNF Pool architecture, all these VNF in= stances are actually grouped into multiple pools, based on the functions th= ey provided. For example, a VNF set {vFW#1, vFW#2, vLB#1, vLB#2, vLB#3} can be grouped into two VNF pools =A8C= one pool is {vFW#1, vFW#2}, another is {vLB#1, vLB#2, vLB#3}. So, maybe th= e following definition is better:

&n= bsp;

VNF Pool: a group of VNF instances providi= ng the same network function.

 

VNF Set: a general set of VNF instances th= at can be grouped into multiple VNF pools where different pools provide different functions.

 

Comment_2 is more interesting (indeed! J= ) and related to VNF in= stance implementation. At this point of time, how about just limiting ourse= lves to your former case, i.e., VNF instances are identical in a pool. The latter case is actually about further decompo= sition of VNF instance to more VNF components (VNFCs). I would guess this i= s more complicated (hierarchical) pooling architecture to be studied later.=

 

Comment_3 & 4 is about our scope. As= emphasized in draft, we mostly consider the reliability (or pooling) insid= e a VNF. Our scope is still intended on VNF set, but *only* to the extent that it involves reliability impact on adj= acent VNF instances in different VNF pools. The coordination traffic betwee= n VNFs dealing with reliability can be still invisible to the Service Contr= ol Entity, if these messages are directly transferred between adjacent VNF pools. Some use cases in our Use= Case I-Ds have shown the benefits of direct communication between pools. Y= ou are right in the sense that if such coordination is explicitly managed b= y the Service Control Entity, other WG(s) could be able to handle it - this will depend on more case study.

 

Sorry, but I am not sure I fully underst= and your first bullet in Comment_3.

 

Comment_5 & 6: Yes, we will improve = as much as we could in future revision.

 

Hope my reply helps a little bit. J=

 

Please do let me know your further quest= ions/comments.

 

-Ning

&n= bsp;

=B7=A2=BC=FE=C8=CB: karagian@cs.utwente.nl [mailto:karagian@cs.= utwente.nl]
=B7=A2= =CB=CD=CA=B1=BC=E4: 2014=C4=EA4=D4=C214=C8=D5 18:41
=CA=D5=BC=FE=C8=CB: Zongning
=B3=AD=CB=CD: vnfpool@ietf.org
=D6=F7=CC=E2: Comments on draft-zong-vnfpool-problem-statement-04

 

Hi Ning,

 

Please note that I have read the current v= ersion of the draft.

This version clearer than the previous ver= sion of the draft, but IMHO it is still not clear enough.=

 

The main comments that I have are:

 

Comment_1: It is not clear what are the ma= in differences between a VNF set and a VNFpool.

From what I can assume is that the VNFpool= is a group of VNF instances that are providing the same network function and that the VNF set is a group of VNF instances, each providing = a different network function, which can be used to build network services. = Is this correct?

 

In the Terminology section you provide the= following definitions:

 

VNF Pool: a group of VNF instances providi= ng the same network

function.

 

VNF Set: a group of VNF instances that can= be used to build network

services.

 

Maybe the following definitions might prov= ide a clearer view:

 

VNF Pool: a group of VNF instances providi= ng the same network

function.

 

VNF Set: a group of VNF instances, each pr= oviding a different network function,

which can be used to build network service= s.

 

 

Comment_2: This comment is related to VNFp= ool and in particular what is meant by: VNF instances providing the same network function? Are you referring to identical VNF instances th= at are providing the same network function, i.e., virtualized instances of = the same network function, or does this definition allow to use VNF instanc= es that are not identical, but when they are used together they form one virtualized network function.

An example of the latter will be to virtua= lise a server, where the VNF of this server will be composed by a virtualized instance of the used protocol stack, a second virtualized in= stance of the application running on the server and a third virtualized ins= tance of the data base used by the server. Are you considering this composi= tion of this VNF also a VNF pool?

 

Comment_3: The problem statement is IMHO n= ot clear. One of the reasons of this fact is that the definition of the VNF pool and the VNF set is not clear enough, see previous two comm= ents. Other reasons  are related to the fact that the draft does not c= learly explain:

o) why is the reliability challenge mentio= ned in this draft different than the reliability challenges and their solutions used for the physical devices that are providing the same = network function(s) as the mentioned VNF(s), in this draft, are providing.

o) why is the reliability challenge that n= eeds to be solved by the VNFpool (future) WG cannot be solved by the currently existing IETF WGs, such as SFC. The reasons given in Section= 6.3 are a bit contradictory. One of the reasons provided in that section i= s is that the reliability mechanisms in VNFpool are mostly internal to VNF,= while another reason, given in the same section,  is that the reliability mechanism deals with adjac= encies in the VNF set. The latter shows that the mechanisms are not interna= l to a VNFpool. Please clarify!

 

Comment_4: Please clarify whether the scop= e of the reliability solution is only limited within a VNF pool, or is it limited within a VNF set? If the scope is limited to a VNF set, t= hen why are you emphasizing that the reliability mechanisms will not be vis= ible to an SFC like control entity, since a VNF set could form a service fu= nction chain, see Figure 2 of the draft.

 

Comment_5: The draft needs to be more cons= istent on when the VNF set is used and when the VNF pool is used.

 

Comment_6: There are also some editorial w= hich need to be worked out in a next version of the draft.

 

Best regards,

Georgios

 

 

 

 

Van: vnfpool [vnfpool-bounces@ietf.org] namens Zongning [zongning@huawei.com] Verzonden: donderdag 10 april 2014 5:21
Aan: vnfpool@ietf.org
Onderwerp: [vnfpool] New revision of VNFPool Problem Statement poste= d

Hi, folks= ,

 

The new r= evision (-04) of VNFPool Problem Statement I-D is available on the below pa= ge.

https://datatracker.ietf.org/doc/draft-zong-vnfpool-prob= lem-statement/

 

Here are = the major changes:

1)       Clarify VNFPool architect= ure and intended scope.

1.         Add new section of VNF Po= ols before the section of Problem. This new section is mainly to outline ou= r scope based on high level description of VNF Pools architecture.

2.         Add text to clarify that = we are specifically concerned with reliability (e.g. redundancy model, stat= e sharing) that is managed inside the VNF. We are only concerned with the w= hole VNF set (or forwarding graph) to the extent that it involves reliability impact on adjacent instances of di= fferent VNFs.

3.         We focus on reliability m= echanisms based on VNF pool. Other VNF management aspects such as scaling, = load balancing are out of scope.

2)       Update terminologies to d= efine Service Control Entity, and delete Pool User as the pool will be inte= rnal to VNF only.

3)       Re-arrange the text in se= ction of Problems.

4)       Update text of VNF instan= ce performance degradation in section of Problems.

5)       Update text of Reliable T= ransport in section of Problems.

6)       Add text to explain why s= ervice availability is not in scope in section of Problems.

7)       Re-write the section desc= ribing the relationship of VNFPool and SFC.

8)       Add text of transfer of s= ecurity states in section of Security Consideration.

 

We hope t= hat the changes have addressed most of the comments, and reflected most of = the suggestions during London BoF.

 

Please re= view this new revision. Your further comments and suggestions are highly ap= preciated!

 

Thanks.

 

-Ning

--_000_B0D29E0424F2DE47A0B36779EC66677966113193nkgeml501mbschi_-- From nobody Wed Apr 16 11:13:04 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 A39181A01B7 for ; Wed, 16 Apr 2014 11:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 wt3FwkdaUtsi for ; Wed, 16 Apr 2014 11:12:59 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 63BCD1A0149 for ; Wed, 16 Apr 2014 11:12:59 -0700 (PDT) X-AuditID: c6180641-f79a26d000001830-17-534e774be562 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 46.03.06192.B477E435; Wed, 16 Apr 2014 14:27:56 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0174.001; Wed, 16 Apr 2014 14:12:55 -0400 From: Zu Qiang To: Zongning , "vnfpool@ietf.org" Thread-Topic: New revision of VNFPool Problem Statement posted Thread-Index: Ac9UbATHM7NhTJ8NTjunJ2NkO54O2gFMTj5A Date: Wed, 16 Apr 2014 18:12:54 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_A4288FE24C337B47BB634F1E76CBF2EC28B0E942eusaamb107erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyuXSPn65PuV+wwf+HHBYzLv1nsWi6fIrR gcmj5chbVo8lS34yBTBFcdmkpOZklqUW6dslcGXMeXqSseDRfMaK3TMXsTcwLu1h7GLk5JAQ MJGY0fuQBcIWk7hwbz1bFyMXh5DAUUaJuRs3sUA4yxklPmyYC5Th4GATUJO4eJgRxBQR8JT4 uUQSpFdYwFbi1pplzCC2iICdxMP5T5ggbCOJjc8fg+1iEVCVaN74B6yGV8BXonfDeVaQMUIC oRKnm3RBwpwCYRK/JqwBK2EUkJXYffY62BhmAXGJW0/mM0GcKSCxZM95ZghbVOLl43+sELaS xKSl51gh6vMlfny7yQqxSlDi5MwnLBMYRWYhGTULSdksJGUQcR2JBbs/sUHY2hLLFr5mhrHP HHjMhCy+gJF9FSNHaXFqWW66keEmRmD0HJNgc9zBuOCT5SFGAQ5GJR5erau+wUKsiWXFlbmH GKU5WJTEeb+8dQ4SEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwFjluDWpr+9oEjeLfUViPUvA ouPOH/wyNx16t3Ppz1Mp81S3iaadbemaFWr6t+H+pVsrnzDkN+Ux/97J9JcjbJVz3dlrxvOz H0zMPH45zFL6xJXfgWnh12q3H3bZInL4TYH3Ae2bfxxFl61x21sY6h7VWZocMrHl8Xqtg+f5 f81fpZZwaeG3qYZKLMUZiYZazEXFiQAoA0PLfwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/KjpGY4UMjrjExQLBmdmmbcgg_rY Subject: Re: [vnfpool] New revision of VNFPool Problem Statement posted 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, 16 Apr 2014 18:13:02 -0000 --_000_A4288FE24C337B47BB634F1E76CBF2EC28B0E942eusaamb107erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Zongning Thanks for updating the draft. I do see this version is muc= h better than the previous version. I have a few clarification questions be= low: - First, there are some existing HA solutions. Can you tell me wha= t is the extra functionalities provided by the VNF Pool? Or the VNF Pool is= only another alternative solution? Or are we going to use the existing HA = solutions as inputs only? - Second, in the early version, you have the interactions between = the Pool Managers of different pools and between the Pool Functions of diff= erent pools specified, which is removed in this version. Do you see that ty= pe of interactions are still needed? And why it is needed? - 3rd, the VNF set is a new concept. What is the linkage with the = proposed VNF Pool architecture? - 4th, RSerPool is referred by your draft. I assume that VNF Pool = will not reused the RSerPool unchanged. So which part of RSerPool can be r= eused by VNF Pool? Thanks. Have a nice day Zu Qiang From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of Zongning Sent: Wednesday, April 09, 2014 11:22 PM To: vnfpool@ietf.org Subject: [vnfpool] New revision of VNFPool Problem Statement posted Hi, folks, The new revision (-04) of VNFPool Problem Statement I-D is available on the= below page. https://datatracker.ietf.org/doc/draft-zong-vnfpool-problem-statement/ Here are the major changes: 1) Clarify VNFPool architecture and intended scope. 1. Add new section of VNF Pools before the section of Problem. This= new section is mainly to outline our scope based on high level description= of VNF Pools architecture. 2. Add text to clarify that we are specifically concerned with reli= ability (e.g. redundancy model, state sharing) that is managed inside the V= NF. We are only concerned with the whole VNF set (or forwarding graph) to t= he extent that it involves reliability impact on adjacent instances of diff= erent VNFs. 3. We focus on reliability mechanisms based on VNF pool. Other VNF = management aspects such as scaling, load balancing are out of scope. 2) Update terminologies to define Service Control Entity, and delete = Pool User as the pool will be internal to VNF only. 3) Re-arrange the text in section of Problems. 4) Update text of VNF instance performance degradation in section of = Problems. 5) Update text of Reliable Transport in section of Problems. 6) Add text to explain why service availability is not in scope in se= ction of Problems. 7) Re-write the section describing the relationship of VNFPool and SF= C. 8) Add text of transfer of security states in section of Security Con= sideration. We hope that the changes have addressed most of the comments, and reflected= most of the suggestions during London BoF. Please review this new revision. Your further comments and suggestions are = highly appreciated! Thanks. -Ning --_000_A4288FE24C337B47BB634F1E76CBF2EC28B0E942eusaamb107erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello= , Zongning

 = ;            &n= bsp;  Thanks for updating the draft. I do see this version is much bet= ter than the previous version. I have a few clarification questions below:<= o:p>

-          First, there are some existing HA solutions. Can you tell me what is the= extra functionalities provided by the VNF Pool? Or the VNF Pool is only an= other alternative solution? Or are we going to use the existing HA solutions as inputs only?

-          Second, in the early version, you have the interactions between the Pool= Managers of different pools and between the Pool Functions of different po= ols specified, which is removed in this version. Do you see that type of interactions are still needed? And w= hy it is needed?

-          3rd, the VNF set is a new concept. What is the linkage with t= he proposed VNF Pool architecture?

-          4th, RSerPool is referred by your draft. I assume that VNF Po= ol will not reused the RSerPool  unchanged. So which part of RSerPool = can be reused by VNF Pool?

Thanks.

Have a nice day

Zu Qiang=

=  

From: vnfpool [mai= lto:vnfpool-bounces@ietf.org] On Behalf Of Zongning
Sent: Wednesday, April 09, 2014 11:22 PM
To: vnfpool@ietf.org
Subject: [vnfpool] New revision of VNFPool Problem Statement posted<= o:p>

 =

Hi, folks,

 

The new revision (-04) of VNFPo= ol Problem Statement I-D is available on the below page.<= /p>

https://datatracker.iet= f.org/doc/draft-zong-vnfpool-problem-statement/

 

Here are the major changes:

1= )   &= nbsp;   Clarify VNFPool archite= cture and intended scope.

1= .   &= nbsp;     Add new section of VNF = Pools before the section of Problem. This new section is mainly to outline = our scope based on high level description of VNF Pools architecture.

2= .   &= nbsp;     Add text to clarify tha= t we are specifically concerned with reliability (e.g. redundancy model, st= ate sharing) that is managed inside the VNF. We are only concerned with the= whole VNF set (or forwarding graph) to the extent that it involves reliability impact on adjacent instances of= different VNFs.

3= .   &= nbsp;     We focus on reliability= mechanisms based on VNF pool. Other VNF management aspects such as scaling= , load balancing are out of scope.

2= )   &= nbsp;   Update terminologies to= define Service Control Entity, and delete Pool User as the pool will be in= ternal to VNF only.

3= )   &= nbsp;   Re-arrange the text in = section of Problems.

4= )   &= nbsp;   Update text of VNF inst= ance performance degradation in section of Problems.

5= )   &= nbsp;   Update text of Reliable= Transport in section of Problems.

6= )   &= nbsp;   Add text to explain why= service availability is not in scope in section of Problems.

7= )   &= nbsp;   Re-write the section de= scribing the relationship of VNFPool and SFC.

8= )   &= nbsp;   Add text of transfer of= security states in section of Security Consideration.

 

We hope that the changes have a= ddressed most of the comments, and reflected most of the suggestions during= London BoF.

 

Please review this new revision= . Your further comments and suggestions are highly appreciated!<= /span>

 

Thanks.

 

-Ning

--_000_A4288FE24C337B47BB634F1E76CBF2EC28B0E942eusaamb107erics_-- From nobody Wed Apr 16 20:45:01 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 D7C8D1A0433 for ; Wed, 16 Apr 2014 20:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.522 X-Spam-Level: X-Spam-Status: No, score=-98.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 a4f5DVdQh-Qn for ; Wed, 16 Apr 2014 20:44:55 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9B43D1A00CD for ; Wed, 16 Apr 2014 20:44:54 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFS67076; Thu, 17 Apr 2014 03:44:48 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 17 Apr 2014 04:43:09 +0100 Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 17 Apr 2014 04:44:46 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.85]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Thu, 17 Apr 2014 11:44:43 +0800 From: Zongning To: Zu Qiang , "vnfpool@ietf.org" Thread-Topic: New revision of VNFPool Problem Statement posted Thread-Index: Ac9UbATHM7NhTJ8NTjunJ2NkO54O2gFMTj5AABQFCQA= Date: Thu, 17 Apr 2014 03:44:43 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.96.170.152] Content-Type: multipart/alternative; boundary="_000_B0D29E0424F2DE47A0B36779EC66677966113AEAnkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/pSL1SMEHgaDNgY93wERraZ3LZro Subject: [vnfpool] =?gb2312?b?tPC4tDogTmV3IHJldmlzaW9uIG9mIFZORlBvb2wgUHJv?= =?gb2312?b?YmxlbSBTdGF0ZW1lbnQgcG9zdGVk?= 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, 17 Apr 2014 03:44:58 -0000 --_000_B0D29E0424F2DE47A0B36779EC66677966113AEAnkgeml501mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIFFpYW5nLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KDQq3orz+yMs6IFp1IFFpYW5nIFtt YWlsdG86enUucWlhbmdAZXJpY3Nzb24uY29tXQ0Kt6LLzcqxvOQ6IDIwMTTE6jTUwjE3yNUgMjox Mw0KytW8/sjLOiBab25nbmluZzsgdm5mcG9vbEBpZXRmLm9yZw0K1vfM4jogUkU6IE5ldyByZXZp c2lvbiBvZiBWTkZQb29sIFByb2JsZW0gU3RhdGVtZW50IHBvc3RlZA0KDQpIZWxsbywgWm9uZ25p bmcNCiAgICAgICAgICAgICAgICBUaGFua3MgZm9yIHVwZGF0aW5nIHRoZSBkcmFmdC4gSSBkbyBz ZWUgdGhpcyB2ZXJzaW9uIGlzIG11Y2ggYmV0dGVyIHRoYW4gdGhlIHByZXZpb3VzIHZlcnNpb24u IEkgaGF2ZSBhIGZldyBjbGFyaWZpY2F0aW9uIHF1ZXN0aW9ucyBiZWxvdzoNCg0KLSAgICAgICAg ICBGaXJzdCwgdGhlcmUgYXJlIHNvbWUgZXhpc3RpbmcgSEEgc29sdXRpb25zLiBDYW4geW91IHRl bGwgbWUgd2hhdCBpcyB0aGUgZXh0cmEgZnVuY3Rpb25hbGl0aWVzIHByb3ZpZGVkIGJ5IHRoZSBW TkYgUG9vbD8gT3IgdGhlIFZORiBQb29sIGlzIG9ubHkgYW5vdGhlciBhbHRlcm5hdGl2ZSBzb2x1 dGlvbj8gT3IgYXJlIHdlIGdvaW5nIHRvIHVzZSB0aGUgZXhpc3RpbmcgSEEgc29sdXRpb25zIGFz IGlucHV0cyBvbmx5Pw0KDQpbTmluZ10gRm9yIHN1cmUgdGhlcmUgYXJlIGV4aXN0aW5nIEhBIHNv bHV0aW9ucy4gRm9yIGV4YW1wbGUsIHRoZSBTQUYgaXMgYWJvdXQgU2VydmljZSBBdmFpbGFiaWxp dHkgbWVjaGFuaXNtcy4gSSBhZ3JlZSB0aGF0IHRoZXJlIGFyZSBkZWZpbml0ZWx5IG1hbnkgcGll Y2VzIG9mIGV4aXN0aW5nIHdvcmsgY2FuIGJlIGludmVzdGlnYXRlZCBhcyB0aGUgYmFzaXMgb2Yg Vk5GIFBvb2wsIGUuZy4gcmVkdW5kYW5jeSBtb2RlbCwgc3RhdGUgc2hhcmluZy4gSSB0aGluayB0 aGUgZXh0cmEgd29yayBuZWVkZWQgaW4gVk5GIFBvb2wgaXMgdG8gYWRkcmVzcyBzcGVjaWZpYyBy ZXF1aXJlbWVudHMgb24gVk5GIGZhaWxvdmVyIHByb2NlZHVyZSwgVk5GIHN0YXRlIHNoYXJpbmcs IGV0Yy4gVGhpcyB3aWxsIGRlcGVuZCBvbiBmdXJ0aGVyIHVzZSBjYXNlIGFuZCBnYXAgYW5hbHlz aXMuDQoNCg0KLSAgICAgICAgICBTZWNvbmQsIGluIHRoZSBlYXJseSB2ZXJzaW9uLCB5b3UgaGF2 ZSB0aGUgaW50ZXJhY3Rpb25zIGJldHdlZW4gdGhlIFBvb2wgTWFuYWdlcnMgb2YgZGlmZmVyZW50 IHBvb2xzIGFuZCBiZXR3ZWVuIHRoZSBQb29sIEZ1bmN0aW9ucyBvZiBkaWZmZXJlbnQgcG9vbHMg c3BlY2lmaWVkLCB3aGljaCBpcyByZW1vdmVkIGluIHRoaXMgdmVyc2lvbi4gRG8geW91IHNlZSB0 aGF0IHR5cGUgb2YgaW50ZXJhY3Rpb25zIGFyZSBzdGlsbCBuZWVkZWQ/IEFuZCB3aHkgaXQgaXMg bmVlZGVkPw0KDQpbTmluZ10gWWVzLCBJIGRvIHRoaW5rIHRob3NlIGludGVyYWN0aW9ucyBhcmUg c3RpbGwgbmVlZGVkLiBCdXQgSSBwcmVmZXIgYW4gVk5GIFBvb2wgYXJjaGl0ZWN0dXJlIGRvY3Vt ZW50IHRvIGRlc2NyaWJlIHRoZW0sIHJhdGhlciB0aGFuIFByb2JsZW0gU3RhdGVtZW50IGRyYWZ0 Lg0KDQoNCi0gICAgICAgICAgM3JkLCB0aGUgVk5GIHNldCBpcyBhIG5ldyBjb25jZXB0LiBXaGF0 IGlzIHRoZSBsaW5rYWdlIHdpdGggdGhlIHByb3Bvc2VkIFZORiBQb29sIGFyY2hpdGVjdHVyZT8N Cg0KW05pbmddIFZORiBzZXQgaXMganVzdCBhIGdlbmVyYWwgc2V0IG9mIGFsbCB0aGUgVk5GIGlu c3RhbmNlcy4gSW4gVk5GIFBvb2wgYXJjaGl0ZWN0dXJlLCB0aGVzZSBWTkYgaW5zdGFuY2VzIGFy ZSBhY3R1YWxseSBncm91cGVkIGludG8gbXVsdGlwbGUgcG9vbHMsIGJhc2VkIG9uIHRoZSBmdW5j dGlvbnMgdGhleSBwcm92aWRlZC4gRm9yIGV4YW1wbGUsIGEgVk5GIHNldCB7dkZXIzEsIHZGVyMy LCB2TEIjMSwgdkxCIzIsIHZMQiMzfSBjYW4gYmUgb3JnYW5pemVkIGFzIHR3byBWTkYgcG9vbHMg qEMgb25lIHBvb2wgaXMge3ZGVyMxLCB2RlcjMn0sIGFub3RoZXIgaXMge3ZMQiMxLCB2TEIjMiwg dkxCIzN9LiBJIHdpbGwgdHJ5IHRvIGVuaGFuY2UgdGhpcyBpbiB0aGUgZHJhZnQgbGF0ZXIgb24u DQoNCg0KLSAgICAgICAgICA0dGgsIFJTZXJQb29sIGlzIHJlZmVycmVkIGJ5IHlvdXIgZHJhZnQu IEkgYXNzdW1lIHRoYXQgVk5GIFBvb2wgd2lsbCBub3QgcmV1c2VkIHRoZSBSU2VyUG9vbCAgdW5j aGFuZ2VkLiBTbyB3aGljaCBwYXJ0IG9mIFJTZXJQb29sIGNhbiBiZSByZXVzZWQgYnkgVk5GIFBv b2w/DQoNCltOaW5nXSBZZXMsIHdlIGJlbGlldmUgc29tZSBtZWNoYW5pc21zIGludHJvZHVjZWQg YnkgUlNlclBvb2wgY2FuIGJlIGV4dGVuZGVkIGFuZCByZXVzZWQsIHN1Y2ggYXMgUEUgcmVnaXN0 cmF0aW9uLCBwb29sIGhhbmRsZSByZXNvbHV0aW9uIGFuZCByZXNwb25zZS4gV2UgaGF2ZSBhIFJT ZXJQb29sIGFwcGxpY2FiaWxpdHkgYW5kIGdhcCBhbmFseXNpcyBkcmFmdCBkZWRpY2F0ZWQgb24g dGhpcyBwZXJzcGVjdGl2ZS4NCg0KDQpUaGFua3MuDQpIYXZlIGEgbmljZSBkYXkNClp1IFFpYW5n DQoNCkZyb206IHZuZnBvb2wgW21haWx0bzp2bmZwb29sLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBab25nbmluZw0KU2VudDogV2VkbmVzZGF5LCBBcHJpbCAwOSwgMjAxNCAxMToyMiBQ TQ0KVG86IHZuZnBvb2xAaWV0Zi5vcmc8bWFpbHRvOnZuZnBvb2xAaWV0Zi5vcmc+DQpTdWJqZWN0 OiBbdm5mcG9vbF0gTmV3IHJldmlzaW9uIG9mIFZORlBvb2wgUHJvYmxlbSBTdGF0ZW1lbnQgcG9z dGVkDQoNCkhpLCBmb2xrcywNCg0KVGhlIG5ldyByZXZpc2lvbiAoLTA0KSBvZiBWTkZQb29sIFBy b2JsZW0gU3RhdGVtZW50IEktRCBpcyBhdmFpbGFibGUgb24gdGhlIGJlbG93IHBhZ2UuDQpodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC16b25nLXZuZnBvb2wtcHJvYmxlbS1z dGF0ZW1lbnQvDQoNCkhlcmUgYXJlIHRoZSBtYWpvciBjaGFuZ2VzOg0KDQoxKSAgICAgICBDbGFy aWZ5IFZORlBvb2wgYXJjaGl0ZWN0dXJlIGFuZCBpbnRlbmRlZCBzY29wZS4NCg0KMS4gICAgICAg ICBBZGQgbmV3IHNlY3Rpb24gb2YgVk5GIFBvb2xzIGJlZm9yZSB0aGUgc2VjdGlvbiBvZiBQcm9i bGVtLiBUaGlzIG5ldyBzZWN0aW9uIGlzIG1haW5seSB0byBvdXRsaW5lIG91ciBzY29wZSBiYXNl ZCBvbiBoaWdoIGxldmVsIGRlc2NyaXB0aW9uIG9mIFZORiBQb29scyBhcmNoaXRlY3R1cmUuDQoN CjIuICAgICAgICAgQWRkIHRleHQgdG8gY2xhcmlmeSB0aGF0IHdlIGFyZSBzcGVjaWZpY2FsbHkg Y29uY2VybmVkIHdpdGggcmVsaWFiaWxpdHkgKGUuZy4gcmVkdW5kYW5jeSBtb2RlbCwgc3RhdGUg c2hhcmluZykgdGhhdCBpcyBtYW5hZ2VkIGluc2lkZSB0aGUgVk5GLiBXZSBhcmUgb25seSBjb25j ZXJuZWQgd2l0aCB0aGUgd2hvbGUgVk5GIHNldCAob3IgZm9yd2FyZGluZyBncmFwaCkgdG8gdGhl IGV4dGVudCB0aGF0IGl0IGludm9sdmVzIHJlbGlhYmlsaXR5IGltcGFjdCBvbiBhZGphY2VudCBp bnN0YW5jZXMgb2YgZGlmZmVyZW50IFZORnMuDQoNCjMuICAgICAgICAgV2UgZm9jdXMgb24gcmVs aWFiaWxpdHkgbWVjaGFuaXNtcyBiYXNlZCBvbiBWTkYgcG9vbC4gT3RoZXIgVk5GIG1hbmFnZW1l bnQgYXNwZWN0cyBzdWNoIGFzIHNjYWxpbmcsIGxvYWQgYmFsYW5jaW5nIGFyZSBvdXQgb2Ygc2Nv cGUuDQoNCjIpICAgICAgIFVwZGF0ZSB0ZXJtaW5vbG9naWVzIHRvIGRlZmluZSBTZXJ2aWNlIENv bnRyb2wgRW50aXR5LCBhbmQgZGVsZXRlIFBvb2wgVXNlciBhcyB0aGUgcG9vbCB3aWxsIGJlIGlu dGVybmFsIHRvIFZORiBvbmx5Lg0KDQozKSAgICAgICBSZS1hcnJhbmdlIHRoZSB0ZXh0IGluIHNl Y3Rpb24gb2YgUHJvYmxlbXMuDQoNCjQpICAgICAgIFVwZGF0ZSB0ZXh0IG9mIFZORiBpbnN0YW5j ZSBwZXJmb3JtYW5jZSBkZWdyYWRhdGlvbiBpbiBzZWN0aW9uIG9mIFByb2JsZW1zLg0KDQo1KSAg ICAgICBVcGRhdGUgdGV4dCBvZiBSZWxpYWJsZSBUcmFuc3BvcnQgaW4gc2VjdGlvbiBvZiBQcm9i bGVtcy4NCg0KNikgICAgICAgQWRkIHRleHQgdG8gZXhwbGFpbiB3aHkgc2VydmljZSBhdmFpbGFi aWxpdHkgaXMgbm90IGluIHNjb3BlIGluIHNlY3Rpb24gb2YgUHJvYmxlbXMuDQoNCjcpICAgICAg IFJlLXdyaXRlIHRoZSBzZWN0aW9uIGRlc2NyaWJpbmcgdGhlIHJlbGF0aW9uc2hpcCBvZiBWTkZQ b29sIGFuZCBTRkMuDQoNCjgpICAgICAgIEFkZCB0ZXh0IG9mIHRyYW5zZmVyIG9mIHNlY3VyaXR5 IHN0YXRlcyBpbiBzZWN0aW9uIG9mIFNlY3VyaXR5IENvbnNpZGVyYXRpb24uDQoNCldlIGhvcGUg dGhhdCB0aGUgY2hhbmdlcyBoYXZlIGFkZHJlc3NlZCBtb3N0IG9mIHRoZSBjb21tZW50cywgYW5k IHJlZmxlY3RlZCBtb3N0IG9mIHRoZSBzdWdnZXN0aW9ucyBkdXJpbmcgTG9uZG9uIEJvRi4NCg0K UGxlYXNlIHJldmlldyB0aGlzIG5ldyByZXZpc2lvbi4gWW91ciBmdXJ0aGVyIGNvbW1lbnRzIGFu ZCBzdWdnZXN0aW9ucyBhcmUgaGlnaGx5IGFwcHJlY2lhdGVkIQ0KDQpUaGFua3MuDQoNCi1OaW5n DQo= --_000_B0D29E0424F2DE47A0B36779EC66677966113AEAnkgeml501mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi, Qia= ng,

&n= bsp;

Please = see inline.

&n= bsp;

&n= bsp;

=B7=A2=BC=FE=C8=CB: Zu Qiang [mailto:zu.qiang@ericsson.com]
=B7=A2= =CB=CD=CA=B1=BC=E4: 2014=C4=EA4=D4=C217=C8=D5 2:13
=CA=D5=BC=FE=C8=CB: Zongning; vnfpool@ietf.org
=D6=F7=CC=E2: RE: New revision of VNFPool Problem Statement posted

 

Hello, Zongning

           = ;     Thanks for updating the draft. I do see this vers= ion is much better than the previous version. I have a few clarification qu= estions below:

-          First, there are some existing HA solutions. Can you tell= me what is the extra functionalities provided by the VNF Pool? Or the VNF = Pool is only another alternative solution? Or are we going to use the existing HA solutions as inputs only?

&n= bsp;

[Ning] = For sure there are existing HA solutions. For example, the SAF is about Ser= vice Availability mechanisms. I agree that there are definitely many pieces= of existing work can be investigated as the basis of VNF Pool, e.g. redundancy model, state sharing. I think th= e extra work needed in VNF Pool is to address specific requirements on VNF = failover procedure, VNF state sharing, etc. This will depend on further use= case and gap analysis.=

&n= bsp;

-          Second, in the early version, you have the interactions b= etween the Pool Managers of different pools and between the Pool Functions = of different pools specified, which is removed in this version. Do you see that type of interactions are still= needed? And why it is needed?

&n= bsp;

[Ning] = Yes, I do think those interactions are still needed. But I prefer an VNF Po= ol architecture document to describe them, rather than Problem Statement dr= aft.

&n= bsp;

-          3rd, the VNF set is a new concept. What is the= linkage with the proposed VNF Pool architecture?

&n= bsp;

[Ning] = VNF set is just a general set of all the VNF instances. In VNF Pool archite= cture, these VNF instances are actually grouped into multiple pools, based = on the functions they provided. For example, a VNF set {vFW#1, vFW#2, vLB#1, vLB#2, vLB#3} can be organized as two VNF = pools =A8C one pool is {vFW#1, vFW#2}, another is {vLB#1, vLB#2, vLB#3}. I = will try to enhance this in the draft later on.

&n= bsp;

-          4th, RSerPool is referred by your draft. I ass= ume that VNF Pool will not reused the RSerPool  unchanged. So which pa= rt of RSerPool can be reused by VNF Pool?

&n= bsp;

[Ning] = Yes, we believe some mechanisms introduced by RSerPool can be extended and = reused, such as PE registration, pool handle resolution and response. We ha= ve a RSerPool applicability and gap analysis draft dedicated on this perspective.

&n= bsp;

&n= bsp;

Thanks.

Hav= e a nice day

Zu = Qiang

 

From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of Zongning
Sent: Wednesday, April 09, 2014 11:22 PM
To: vnfpool@ietf.org
Subject: [vnfpool] New revision of VNFPool Problem Statement posted<= o:p>

 

Hi, folks,

 

The new revision (-04) of VNFPo= ol Problem Statement I-D is available on the below page.<= /p>

https://datatracker.iet= f.org/doc/draft-zong-vnfpool-problem-statement/

 

Here are the major changes:

1= )   &= nbsp;   Clarify VNFPool archite= cture and intended scope.

1= .   &= nbsp;     Add new section of VNF = Pools before the section of Problem. This new section is mainly to outline = our scope based on high level description of VNF Pools architecture.

2= .   &= nbsp;     Add text to clarify tha= t we are specifically concerned with reliability (e.g. redundancy model, st= ate sharing) that is managed inside the VNF. We are only concerned with the= whole VNF set (or forwarding graph) to the extent that it involves reliability impact on adjacent instances of= different VNFs.

3= .   &= nbsp;     We focus on reliability= mechanisms based on VNF pool. Other VNF management aspects such as scaling= , load balancing are out of scope.

2= )   &= nbsp;   Update terminologies to= define Service Control Entity, and delete Pool User as the pool will be in= ternal to VNF only.

3= )   &= nbsp;   Re-arrange the text in = section of Problems.

4= )   &= nbsp;   Update text of VNF inst= ance performance degradation in section of Problems.

5= )   &= nbsp;   Update text of Reliable= Transport in section of Problems.

6= )   &= nbsp;   Add text to explain why= service availability is not in scope in section of Problems.

7= )   &= nbsp;   Re-write the section de= scribing the relationship of VNFPool and SFC.

8= )   &= nbsp;   Add text of transfer of= security states in section of Security Consideration.

 

We hope that the changes have a= ddressed most of the comments, and reflected most of the suggestions during= London BoF.

 

Please review this new revision= . Your further comments and suggestions are highly appreciated!<= /span>

 

Thanks.

 

-Ning

--_000_B0D29E0424F2DE47A0B36779EC66677966113AEAnkgeml501mbschi_-- From nobody Sun Apr 20 20:31:02 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 AC3D41A0194 for ; Sun, 20 Apr 2014 20:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.522 X-Spam-Level: X-Spam-Status: No, score=-98.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 y9nTSw3giobs for ; Sun, 20 Apr 2014 20:30:56 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E23FE1A0182 for ; Sun, 20 Apr 2014 20:30:55 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDH81978; Mon, 21 Apr 2014 03:30:50 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 21 Apr 2014 04:30:15 +0100 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 21 Apr 2014 04:30:48 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.85]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Mon, 21 Apr 2014 11:30:42 +0800 From: Zongning To: "King, Daniel" , "vnfpool@ietf.org" Thread-Topic: Also soliciting feedback for draft-xia-vnfpool-use-cases Thread-Index: Ac9YD1+/btGK0cpSTMK0UF/6BqknpAFAjiug Date: Mon, 21 Apr 2014 03:30:41 +0000 Message-ID: References: <65174429B5AF4C45BD0798810EC48E0A11A484@EX-0-MB2.lancs.local> In-Reply-To: <65174429B5AF4C45BD0798810EC48E0A11A484@EX-0-MB2.lancs.local> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.22] Content-Type: multipart/alternative; boundary="_000_B0D29E0424F2DE47A0B36779EC666779661142E0nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/AEqlQofl3ZbLB9-q0Byem_ElopI Subject: [vnfpool] =?gb2312?b?tPC4tDogQWxzbyBzb2xpY2l0aW5nIGZlZWRiYWNrIGZv?= =?gb2312?b?ciBkcmFmdC14aWEtdm5mcG9vbC11c2UtY2FzZXM=?= 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: Mon, 21 Apr 2014 03:31:00 -0000 --_000_B0D29E0424F2DE47A0B36779EC666779661142E0nkgeml501mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIERhbiBhbmQgY28tYXV0aG9ycywNCg0KQXBwcmVjaWF0ZSB5b3VyIHdvcmsgb24gbWFraW5n IHRoaXMgbmV3IHJldmlzaW9uIQ0KDQpDb3VsZCB5b3UgcGxlYXNlIGFsc28gdXBsb2FkIHRoaXMg ZHJhZnQgKGFuZCBhbm90aGVyIG9uZSkgdG8gSUVURiByZXBvc2l0b3J5LiBJIGFzc3VtZSBmb2xr cyBhcmUgbW9yZSBmYW1pbGlhciB3aXRoIElFVEYgZGF0YXRyYWNrZXIgcG9ydGFsIKGtIDopDQoN ClRoYW5rcy4NCg0KLU5pbmcNCg0Kt6K8/sjLOiB2bmZwb29sIFttYWlsdG86dm5mcG9vbC1ib3Vu Y2VzQGlldGYub3JnXSC0+rHtIEtpbmcsIERhbmllbA0Kt6LLzcqxvOQ6IDIwMTTE6jTUwjE1yNUg MjoyOQ0KytW8/sjLOiB2bmZwb29sQGlldGYub3JnDQrW98ziOiBbdm5mcG9vbF0gQWxzbyBzb2xp Y2l0aW5nIGZlZWRiYWNrIGZvciBkcmFmdC14aWEtdm5mcG9vbC11c2UtY2FzZXMNCg0KSGkgQWxs IChBZ2FpbiksDQoNCldlIGFyZSBhbHNvIHVwZGF0aW5nIHRoZSBnZW5lcmFsIFVzZSBDYXNlIEkt RC4gUGxlYXNlIGZpbmQgb3VyIGxhdGVzdCB2ZXJzaW9uIG9uIEdpdEh1YjoNCg0KaHR0cHM6Ly9n aXRodWIuY29tL2RhbmllbGtpbmd1ay92bmZwb29sL3RyZWUvbWFzdGVyL2dlbmVyYWwtdXNlLWNh c2UNCg0KV2l0aCB0aGUgZm9sbG93aW5nIHVwZGF0ZXM6DQoNCg0KLSAgICAgICAgICBTeW5jaHJv bml6YXRpb24gb2YgdGVybWlub2xvZ3kgd2l0aCBvdGhlciBWTkYgUG9vbCBJLURzDQoNCi0gICAg ICAgICAgVXNpbmcgZGVmaW5pdGlvbnMgZnJvbSBQcm9ibGVtIFN0YXRlbWVudCBJLUQNCg0KLSAg ICAgICAgICBSZW1vdmluZyBzb21lIG9mIHRoZSBjb250ZW50aW91cyBpdGVtcyB0aGF0IG92ZXJs YXAgd2l0aCBTRkMgKHRyYWZmaWMgc3RlZXJpbmcpLCBhdCBsZWFzdCB1bnRpbCB3ZSByZXNvbHZl IHRoZSBzaXR1YXRpb24NCg0KLSAgICAgICAgICBEaXNjdXNzaW9uIHRleHQgZm9yIFN0YXRlIFN5 bmNocm9uaXphdGlvbg0KDQotICAgICAgICAgIERpc2N1c3Npb24gdGV4dCBmb3IgVk5GIFNldA0K DQotICAgICAgICAgIFZhcmlvdXMgTml0cyBhbmQgZ3JhbW1hciB1cGRhdGVzDQoNCkJyLCBEYW4u DQo= --_000_B0D29E0424F2DE47A0B36779EC666779661142E0nkgeml501mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi, Dan and co-authors,

 

Appreciate your work on making this new revision!

 

Could you please also upload this draft (and another one) to IETF= repository. I assume folks are more familiar with IETF datatracker portal = =A1=AD J

 

Thanks.

 

-Ning

 

=B7=A2=BC=FE=C8=CB: vnfpool [mailto:vnfpo= ol-bounces@ietf.org] =B4=FA=B1=ED = King, Daniel
=B7=A2=CB=CD= =CA=B1=BC=E4: 2014=C4=EA4=D4=C2<= span lang=3D"EN-US">15=C8=D5 2:29
=CA=D5=BC=FE=C8=CB: vnfpool@ietf.org
=D6=F7=CC=E2: [vnfpool] Also soliciting feedback for draft-xia-vnfpool-use-cases

 

Hi All (Again),

 

We are also updating the genera= l Use Case I-D. Please find our latest version on GitHub:=

 

https://github.com/daniel= kinguk/vnfpool/tree/master/general-use-case

 

With the following updates:

 

-     &= nbsp;    Synchronization of terminology with other VNF P= ool I-Ds

-     &= nbsp;    Using definitions from Problem Statement I-D

-     &= nbsp;    Removing some of the contentious items that ove= rlap with SFC (traffic steering), at least until we resolve the situation

-     &= nbsp;    Discussion text for State Synchronization<= /o:p>

-     &= nbsp;    Discussion text for VNF Set <= /p>

-     &= nbsp;    Various Nits and grammar updates

 

Br, Dan.

--_000_B0D29E0424F2DE47A0B36779EC666779661142E0nkgeml501mbschi_-- From nobody Mon Apr 21 06:10:11 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 0A43B1A0212 for ; Mon, 21 Apr 2014 06:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.55 X-Spam-Level: X-Spam-Status: No, score=0.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, SPF_PASS=-0.001] 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 hU4oaggwG59F for ; Mon, 21 Apr 2014 06:09:58 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id BAD281A0210 for ; Mon, 21 Apr 2014 06:09:57 -0700 (PDT) X-AuditID: c618062d-f79f66d000001393-a3-5354ca2dbfe6 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 44.FF.05011.D2AC4535; Mon, 21 Apr 2014 09:35:09 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0174.001; Mon, 21 Apr 2014 09:09:50 -0400 From: Zu Qiang To: Zongning , "vnfpool@ietf.org" Thread-Topic: New revision of VNFPool Problem Statement posted Thread-Index: Ac9UbATHM7NhTJ8NTjunJ2NkO54O2gFMTj5AABQFCQAA3Vi7sA== Date: Mon, 21 Apr 2014 13:09:50 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_A4288FE24C337B47BB634F1E76CBF2EC28B11551eusaamb107erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyuXRPgq7uqZBggzlPdSxmXPrPYtF0+RSj A5NHy5G3rB5LlvxkCmCK4rJJSc3JLEst0rdL4Mpo+LeXtWDvf8aK5VMfsDcwfnnJ2MXIySEh YCJxftlbNghbTOLCvfVANheHkMBRRon765vAEkICyxklXvxJ6GLk4GATUJO4eJgRxBQR8JT4 uUQSpEJYwFbi1pplzCC2iICdxMP5T5ggbCeJX2uugNksAqoSWyf8ApvIK+Ar8ezvZBaIVU8Z JR71NLODJDgFwiSeTboOVsQoICux++x1sGZmAXGJW0/mM0HcKSCxZM95ZghbVOLl43+sELaS xKSl51gh6vMlNu1+xQSxTFDi5MwnLBMYRWYhGTULSdksJGUQcS2JeQ2/oWoUJaZ0P2SHsDUl rkw+BGVrSyxb+Jp5ASP7KkaO0uLUstx0I4NNjMD4OSbBpruDcc9Ly0OMAhyMSjy8U677Bgux JpYVV+YeYpTmYFES5/3y1jlISCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA+PGFbYnJgrddzpT cV2u9+6q56mcSbduLlhw5Iu6ZA6nULvLLp7ks1f+fDx9dEfIa5GIjXZTJPnuLzco7Pd3MVlp +lqk+0I2R+2V1tm9Ih3cBkz92vr9y5WcuWu2fC5l4khdnee/N4515RSnlf4cCqu8Bc0PmcxY YpqetM6HjbXjpbX/XRXpi0osxRmJhlrMRcWJAAOlAOqAAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/ySsZc644M0Gm48v3kYWT02vGul8 Subject: Re: [vnfpool] New revision of VNFPool Problem Statement posted 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: Mon, 21 Apr 2014 13:10:01 -0000 --_000_A4288FE24C337B47BB634F1E76CBF2EC28B11551eusaamb107erics_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGVsbG8sIFpvbmduaW5nDQogICAgICAgICAgICAgICAgVGhhbmtzIGZvciB5b3VyIHJlc3BvbnNl LiBDYW4geW91IGdpdmUgYSB1c2UgY2FzZSBvZiChsHRoZSBpbnRlcmFjdGlvbnMgYmV0d2VlbiB0 aGUgUG9vbCBNYW5hZ2VycyBvZiBkaWZmZXJlbnQgcG9vbHMgYW5kIGJldHdlZW4gdGhlIFBvb2wg RnVuY3Rpb25zIG9mIGRpZmZlcmVudKGxPyBhbmQgYSB1c2UgY2FzZSBvZiChsFZORiBzZXShsT8N Cg0KSGF2ZSBhIG5pY2UgZGF5DQpadSBRaWFuZw0KDQpGcm9tOiBab25nbmluZyBbbWFpbHRvOnpv bmduaW5nQGh1YXdlaS5jb21dDQpTZW50OiBXZWRuZXNkYXksIEFwcmlsIDE2LCAyMDE0IDExOjQ1 IFBNDQpUbzogWnUgUWlhbmc7IHZuZnBvb2xAaWV0Zi5vcmcNClN1YmplY3Q6ILTwuLQ6IE5ldyBy ZXZpc2lvbiBvZiBWTkZQb29sIFByb2JsZW0gU3RhdGVtZW50IHBvc3RlZA0KDQpIaSwgUWlhbmcs DQoNClBsZWFzZSBzZWUgaW5saW5lLg0KDQoNCreivP7IyzogWnUgUWlhbmcgW21haWx0bzp6dS5x aWFuZ0Blcmljc3Nvbi5jb21dDQq3osvNyrG85DogMjAxNMTqNNTCMTfI1SAyOjEzDQrK1bz+yMs6 IFpvbmduaW5nOyB2bmZwb29sQGlldGYub3JnPG1haWx0bzp2bmZwb29sQGlldGYub3JnPg0K1vfM 4jogUkU6IE5ldyByZXZpc2lvbiBvZiBWTkZQb29sIFByb2JsZW0gU3RhdGVtZW50IHBvc3RlZA0K DQpIZWxsbywgWm9uZ25pbmcNCiAgICAgICAgICAgICAgICBUaGFua3MgZm9yIHVwZGF0aW5nIHRo ZSBkcmFmdC4gSSBkbyBzZWUgdGhpcyB2ZXJzaW9uIGlzIG11Y2ggYmV0dGVyIHRoYW4gdGhlIHBy ZXZpb3VzIHZlcnNpb24uIEkgaGF2ZSBhIGZldyBjbGFyaWZpY2F0aW9uIHF1ZXN0aW9ucyBiZWxv dzoNCg0KLSAgICAgICAgICBGaXJzdCwgdGhlcmUgYXJlIHNvbWUgZXhpc3RpbmcgSEEgc29sdXRp b25zLiBDYW4geW91IHRlbGwgbWUgd2hhdCBpcyB0aGUgZXh0cmEgZnVuY3Rpb25hbGl0aWVzIHBy b3ZpZGVkIGJ5IHRoZSBWTkYgUG9vbD8gT3IgdGhlIFZORiBQb29sIGlzIG9ubHkgYW5vdGhlciBh bHRlcm5hdGl2ZSBzb2x1dGlvbj8gT3IgYXJlIHdlIGdvaW5nIHRvIHVzZSB0aGUgZXhpc3Rpbmcg SEEgc29sdXRpb25zIGFzIGlucHV0cyBvbmx5Pw0KDQpbTmluZ10gRm9yIHN1cmUgdGhlcmUgYXJl IGV4aXN0aW5nIEhBIHNvbHV0aW9ucy4gRm9yIGV4YW1wbGUsIHRoZSBTQUYgaXMgYWJvdXQgU2Vy dmljZSBBdmFpbGFiaWxpdHkgbWVjaGFuaXNtcy4gSSBhZ3JlZSB0aGF0IHRoZXJlIGFyZSBkZWZp bml0ZWx5IG1hbnkgcGllY2VzIG9mIGV4aXN0aW5nIHdvcmsgY2FuIGJlIGludmVzdGlnYXRlZCBh cyB0aGUgYmFzaXMgb2YgVk5GIFBvb2wsIGUuZy4gcmVkdW5kYW5jeSBtb2RlbCwgc3RhdGUgc2hh cmluZy4gSSB0aGluayB0aGUgZXh0cmEgd29yayBuZWVkZWQgaW4gVk5GIFBvb2wgaXMgdG8gYWRk cmVzcyBzcGVjaWZpYyByZXF1aXJlbWVudHMgb24gVk5GIGZhaWxvdmVyIHByb2NlZHVyZSwgVk5G IHN0YXRlIHNoYXJpbmcsIGV0Yy4gVGhpcyB3aWxsIGRlcGVuZCBvbiBmdXJ0aGVyIHVzZSBjYXNl IGFuZCBnYXAgYW5hbHlzaXMuDQoNCg0KLSAgICAgICAgICBTZWNvbmQsIGluIHRoZSBlYXJseSB2 ZXJzaW9uLCB5b3UgaGF2ZSB0aGUgaW50ZXJhY3Rpb25zIGJldHdlZW4gdGhlIFBvb2wgTWFuYWdl cnMgb2YgZGlmZmVyZW50IHBvb2xzIGFuZCBiZXR3ZWVuIHRoZSBQb29sIEZ1bmN0aW9ucyBvZiBk aWZmZXJlbnQgcG9vbHMgc3BlY2lmaWVkLCB3aGljaCBpcyByZW1vdmVkIGluIHRoaXMgdmVyc2lv bi4gRG8geW91IHNlZSB0aGF0IHR5cGUgb2YgaW50ZXJhY3Rpb25zIGFyZSBzdGlsbCBuZWVkZWQ/ IEFuZCB3aHkgaXQgaXMgbmVlZGVkPw0KDQpbTmluZ10gWWVzLCBJIGRvIHRoaW5rIHRob3NlIGlu dGVyYWN0aW9ucyBhcmUgc3RpbGwgbmVlZGVkLiBCdXQgSSBwcmVmZXIgYW4gVk5GIFBvb2wgYXJj aGl0ZWN0dXJlIGRvY3VtZW50IHRvIGRlc2NyaWJlIHRoZW0sIHJhdGhlciB0aGFuIFByb2JsZW0g U3RhdGVtZW50IGRyYWZ0Lg0KDQoNCi0gICAgICAgICAgM3JkLCB0aGUgVk5GIHNldCBpcyBhIG5l dyBjb25jZXB0LiBXaGF0IGlzIHRoZSBsaW5rYWdlIHdpdGggdGhlIHByb3Bvc2VkIFZORiBQb29s IGFyY2hpdGVjdHVyZT8NCg0KW05pbmddIFZORiBzZXQgaXMganVzdCBhIGdlbmVyYWwgc2V0IG9m IGFsbCB0aGUgVk5GIGluc3RhbmNlcy4gSW4gVk5GIFBvb2wgYXJjaGl0ZWN0dXJlLCB0aGVzZSBW TkYgaW5zdGFuY2VzIGFyZSBhY3R1YWxseSBncm91cGVkIGludG8gbXVsdGlwbGUgcG9vbHMsIGJh c2VkIG9uIHRoZSBmdW5jdGlvbnMgdGhleSBwcm92aWRlZC4gRm9yIGV4YW1wbGUsIGEgVk5GIHNl dCB7dkZXIzEsIHZGVyMyLCB2TEIjMSwgdkxCIzIsIHZMQiMzfSBjYW4gYmUgb3JnYW5pemVkIGFz IHR3byBWTkYgcG9vbHMgqEMgb25lIHBvb2wgaXMge3ZGVyMxLCB2RlcjMn0sIGFub3RoZXIgaXMg e3ZMQiMxLCB2TEIjMiwgdkxCIzN9LiBJIHdpbGwgdHJ5IHRvIGVuaGFuY2UgdGhpcyBpbiB0aGUg ZHJhZnQgbGF0ZXIgb24uDQoNCg0KLSAgICAgICAgICA0dGgsIFJTZXJQb29sIGlzIHJlZmVycmVk IGJ5IHlvdXIgZHJhZnQuIEkgYXNzdW1lIHRoYXQgVk5GIFBvb2wgd2lsbCBub3QgcmV1c2VkIHRo ZSBSU2VyUG9vbCAgdW5jaGFuZ2VkLiBTbyB3aGljaCBwYXJ0IG9mIFJTZXJQb29sIGNhbiBiZSBy ZXVzZWQgYnkgVk5GIFBvb2w/DQoNCltOaW5nXSBZZXMsIHdlIGJlbGlldmUgc29tZSBtZWNoYW5p c21zIGludHJvZHVjZWQgYnkgUlNlclBvb2wgY2FuIGJlIGV4dGVuZGVkIGFuZCByZXVzZWQsIHN1 Y2ggYXMgUEUgcmVnaXN0cmF0aW9uLCBwb29sIGhhbmRsZSByZXNvbHV0aW9uIGFuZCByZXNwb25z ZS4gV2UgaGF2ZSBhIFJTZXJQb29sIGFwcGxpY2FiaWxpdHkgYW5kIGdhcCBhbmFseXNpcyBkcmFm dCBkZWRpY2F0ZWQgb24gdGhpcyBwZXJzcGVjdGl2ZS4NCg0KDQpUaGFua3MuDQpIYXZlIGEgbmlj ZSBkYXkNClp1IFFpYW5nDQoNCkZyb206IHZuZnBvb2wgW21haWx0bzp2bmZwb29sLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBab25nbmluZw0KU2VudDogV2VkbmVzZGF5LCBBcHJpbCAw OSwgMjAxNCAxMToyMiBQTQ0KVG86IHZuZnBvb2xAaWV0Zi5vcmc8bWFpbHRvOnZuZnBvb2xAaWV0 Zi5vcmc+DQpTdWJqZWN0OiBbdm5mcG9vbF0gTmV3IHJldmlzaW9uIG9mIFZORlBvb2wgUHJvYmxl bSBTdGF0ZW1lbnQgcG9zdGVkDQoNCkhpLCBmb2xrcywNCg0KVGhlIG5ldyByZXZpc2lvbiAoLTA0 KSBvZiBWTkZQb29sIFByb2JsZW0gU3RhdGVtZW50IEktRCBpcyBhdmFpbGFibGUgb24gdGhlIGJl bG93IHBhZ2UuDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC16b25nLXZu ZnBvb2wtcHJvYmxlbS1zdGF0ZW1lbnQvDQoNCkhlcmUgYXJlIHRoZSBtYWpvciBjaGFuZ2VzOg0K DQoxKSAgICAgICBDbGFyaWZ5IFZORlBvb2wgYXJjaGl0ZWN0dXJlIGFuZCBpbnRlbmRlZCBzY29w ZS4NCg0KMS4gICAgICAgICBBZGQgbmV3IHNlY3Rpb24gb2YgVk5GIFBvb2xzIGJlZm9yZSB0aGUg c2VjdGlvbiBvZiBQcm9ibGVtLiBUaGlzIG5ldyBzZWN0aW9uIGlzIG1haW5seSB0byBvdXRsaW5l IG91ciBzY29wZSBiYXNlZCBvbiBoaWdoIGxldmVsIGRlc2NyaXB0aW9uIG9mIFZORiBQb29scyBh cmNoaXRlY3R1cmUuDQoNCjIuICAgICAgICAgQWRkIHRleHQgdG8gY2xhcmlmeSB0aGF0IHdlIGFy ZSBzcGVjaWZpY2FsbHkgY29uY2VybmVkIHdpdGggcmVsaWFiaWxpdHkgKGUuZy4gcmVkdW5kYW5j eSBtb2RlbCwgc3RhdGUgc2hhcmluZykgdGhhdCBpcyBtYW5hZ2VkIGluc2lkZSB0aGUgVk5GLiBX ZSBhcmUgb25seSBjb25jZXJuZWQgd2l0aCB0aGUgd2hvbGUgVk5GIHNldCAob3IgZm9yd2FyZGlu ZyBncmFwaCkgdG8gdGhlIGV4dGVudCB0aGF0IGl0IGludm9sdmVzIHJlbGlhYmlsaXR5IGltcGFj dCBvbiBhZGphY2VudCBpbnN0YW5jZXMgb2YgZGlmZmVyZW50IFZORnMuDQoNCjMuICAgICAgICAg V2UgZm9jdXMgb24gcmVsaWFiaWxpdHkgbWVjaGFuaXNtcyBiYXNlZCBvbiBWTkYgcG9vbC4gT3Ro ZXIgVk5GIG1hbmFnZW1lbnQgYXNwZWN0cyBzdWNoIGFzIHNjYWxpbmcsIGxvYWQgYmFsYW5jaW5n IGFyZSBvdXQgb2Ygc2NvcGUuDQoNCjIpICAgICAgIFVwZGF0ZSB0ZXJtaW5vbG9naWVzIHRvIGRl ZmluZSBTZXJ2aWNlIENvbnRyb2wgRW50aXR5LCBhbmQgZGVsZXRlIFBvb2wgVXNlciBhcyB0aGUg cG9vbCB3aWxsIGJlIGludGVybmFsIHRvIFZORiBvbmx5Lg0KDQozKSAgICAgICBSZS1hcnJhbmdl IHRoZSB0ZXh0IGluIHNlY3Rpb24gb2YgUHJvYmxlbXMuDQoNCjQpICAgICAgIFVwZGF0ZSB0ZXh0 IG9mIFZORiBpbnN0YW5jZSBwZXJmb3JtYW5jZSBkZWdyYWRhdGlvbiBpbiBzZWN0aW9uIG9mIFBy b2JsZW1zLg0KDQo1KSAgICAgICBVcGRhdGUgdGV4dCBvZiBSZWxpYWJsZSBUcmFuc3BvcnQgaW4g c2VjdGlvbiBvZiBQcm9ibGVtcy4NCg0KNikgICAgICAgQWRkIHRleHQgdG8gZXhwbGFpbiB3aHkg c2VydmljZSBhdmFpbGFiaWxpdHkgaXMgbm90IGluIHNjb3BlIGluIHNlY3Rpb24gb2YgUHJvYmxl bXMuDQoNCjcpICAgICAgIFJlLXdyaXRlIHRoZSBzZWN0aW9uIGRlc2NyaWJpbmcgdGhlIHJlbGF0 aW9uc2hpcCBvZiBWTkZQb29sIGFuZCBTRkMuDQoNCjgpICAgICAgIEFkZCB0ZXh0IG9mIHRyYW5z ZmVyIG9mIHNlY3VyaXR5IHN0YXRlcyBpbiBzZWN0aW9uIG9mIFNlY3VyaXR5IENvbnNpZGVyYXRp b24uDQoNCldlIGhvcGUgdGhhdCB0aGUgY2hhbmdlcyBoYXZlIGFkZHJlc3NlZCBtb3N0IG9mIHRo ZSBjb21tZW50cywgYW5kIHJlZmxlY3RlZCBtb3N0IG9mIHRoZSBzdWdnZXN0aW9ucyBkdXJpbmcg TG9uZG9uIEJvRi4NCg0KUGxlYXNlIHJldmlldyB0aGlzIG5ldyByZXZpc2lvbi4gWW91ciBmdXJ0 aGVyIGNvbW1lbnRzIGFuZCBzdWdnZXN0aW9ucyBhcmUgaGlnaGx5IGFwcHJlY2lhdGVkIQ0KDQpU aGFua3MuDQoNCi1OaW5nDQo= --_000_A4288FE24C337B47BB634F1E76CBF2EC28B11551eusaamb107erics_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hello= , Zongning

 = ;            &n= bsp;  Thanks for your response. Can you give a use case of =A1=B0the interactions between t= he Pool Managers of different pools and between the Pool Functions of different=A1=B1? and a use case of =A1=B0VNF set=A1=B1?

=  

Have a nice day

Zu Qiang=

=  

From: Zongning [ma= ilto:zongning@huawei.com]
Sent: Wednesday, April 16, 2014 11:45 PM
To: Zu Qiang; vnfpool@ietf.org
Subject: =B4=F0=B8=B4: New revision= of VNFPool Problem Statement posted

 =

Hi, Qia= ng,

&n= bsp;

Please = see inline.

&n= bsp;

&n= bsp;

=B7=A2=BC=FE=C8= =CB: Zu Qiang [mailto:zu.qiang@ericsso= n.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA4=D4=C217=C8=D5 2:13
=CA=D5=BC=FE=C8=CB: Zongning; vnfpool@ietf.org
=D6=F7=CC=E2: RE: New revision of VNFPool Problem Statement posted

 

Hello= , Zongning

 = ;            &n= bsp;  Thanks for updating the draft. I do see this version is much bet= ter than the previous version. I have a few clarification questions below:<= o:p>

-          First, there are some existing HA solutions. Can you tell me what is the= extra functionalities provided by the VNF Pool? Or the VNF Pool is only an= other alternative solution? Or are we going to use the existing HA solutions as inputs only?

 

[Ning] For sure there = are existing HA solutions. For example, the SAF is about Service Availabili= ty mechanisms. I agree that there are definitely many pieces of existing wo= rk can be investigated as the basis of VNF Pool, e.g. redundancy model, state sharing. I think the extra work = needed in VNF Pool is to address specific requirements on VNF failover proc= edure, VNF state sharing, etc. This will depend on further use case and gap= analysis.

 

-          Second, in the early version, you have the interactions between the Pool= Managers of different pools and between the Pool Functions of different po= ols specified, which is removed in this version. Do you see that type of interactions are still needed? And w= hy it is needed?

 

[Ning] Yes, I do think= those interactions are still needed. But I prefer an VNF Pool architecture= document to describe them, rather than Problem Statement draft.=

 

-          3rd, the VNF set is a new concept. What is the linkage with t= he proposed VNF Pool architecture?

 

[Ning] VNF set is just= a general set of all the VNF instances. In VNF Pool architecture, these VN= F instances are actually grouped into multiple pools, based on the function= s they provided. For example, a VNF set {vFW#1, vFW#2, vLB#1, vLB#2, vLB#3} can be organized as two VNF pools = =A8C one pool is {vFW#1, vFW#2}, another is {vLB#1, vLB#2, vLB#3}. I will t= ry to enhance this in the draft later on.

 

-          4th, RSerPool is referred by your draft. I assume that VNF Po= ol will not reused the RSerPool  unchanged. So which part of RSerPool = can be reused by VNF Pool?

 

[Ning] Yes, we believe= some mechanisms introduced by RSerPool can be extended and reused, such as= PE registration, pool handle resolution and response. We have a RSerPool a= pplicability and gap analysis draft dedicated on this perspective.

 

 

Thanks.

Have a nice day

Zu Qiang=

=  

From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of Zongning
Sent: Wednesday, April 09, 2014 11:22 PM
To: vnfpool@ietf.org
Subject: [vnfpool] New revision of VNFPool Problem Statement posted<= o:p>

 =

Hi, folks,

 

The new revision (-04) of VNFPo= ol Problem Statement I-D is available on the below page.<= /p>

https://datatracker.iet= f.org/doc/draft-zong-vnfpool-problem-statement/

 

Here are the major changes:

1= )   &= nbsp;   Clarify VNFPool archite= cture and intended scope.

1= .   &= nbsp;     Add new section of VNF = Pools before the section of Problem. This new section is mainly to outline = our scope based on high level description of VNF Pools architecture.

2= .   &= nbsp;     Add text to clarify tha= t we are specifically concerned with reliability (e.g. redundancy model, st= ate sharing) that is managed inside the VNF. We are only concerned with the= whole VNF set (or forwarding graph) to the extent that it involves reliability impact on adjacent instances of= different VNFs.

3= .   &= nbsp;     We focus on reliability= mechanisms based on VNF pool. Other VNF management aspects such as scaling= , load balancing are out of scope.

2= )   &= nbsp;   Update terminologies to= define Service Control Entity, and delete Pool User as the pool will be in= ternal to VNF only.

3= )   &= nbsp;   Re-arrange the text in = section of Problems.

4= )   &= nbsp;   Update text of VNF inst= ance performance degradation in section of Problems.

5= )   &= nbsp;   Update text of Reliable= Transport in section of Problems.

6= )   &= nbsp;   Add text to explain why= service availability is not in scope in section of Problems.

7= )   &= nbsp;   Re-write the section de= scribing the relationship of VNFPool and SFC.

8= )   &= nbsp;   Add text of transfer of= security states in section of Security Consideration.

 

We hope that the changes have a= ddressed most of the comments, and reflected most of the suggestions during= London BoF.

 

Please review this new revision= . Your further comments and suggestions are highly appreciated!<= /span>

 

Thanks.

 

-Ning

--_000_A4288FE24C337B47BB634F1E76CBF2EC28B11551eusaamb107erics_-- From nobody Mon Apr 21 13:29:02 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 D00C81A0295 for ; Mon, 21 Apr 2014 13:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 JEohTCouwiwL for ; Mon, 21 Apr 2014 13:28:56 -0700 (PDT) Received: from ignavia.lancs.ac.uk (ignavia.lancs.ac.uk [148.88.25.16]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8A91A024B for ; Mon, 21 Apr 2014 13:28:56 -0700 (PDT) Received: from ex-1-ht0.lancs.ac.uk ([10.42.18.57] helo=EX-1-HT0.lancs.local) by ignavia.lancs.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1WcKpd-0007Pv-56; Mon, 21 Apr 2014 21:28:49 +0100 Received: from EX-0-MB2.lancs.local ([fe80::9d98:936b:54d1:c531]) by EX-1-HT0.lancs.local ([fe80::d9e8:ad10:d075:a6b6%12]) with mapi id 14.03.0174.001; Mon, 21 Apr 2014 21:28:48 +0100 From: "King, Daniel" To: Zongning , "vnfpool@ietf.org" Thread-Topic: Also soliciting feedback for draft-xia-vnfpool-use-cases Thread-Index: Ac9YD1+/btGK0cpSTMK0UF/6BqknpAFAjiugACOao9A= Date: Mon, 21 Apr 2014 20:28:47 +0000 Message-ID: <65174429B5AF4C45BD0798810EC48E0A11B4E8@EX-0-MB2.lancs.local> References: <65174429B5AF4C45BD0798810EC48E0A11A484@EX-0-MB2.lancs.local> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [88.97.23.122] x-iss-local-domain: 1 Content-Type: multipart/alternative; boundary="_000_65174429B5AF4C45BD0798810EC48E0A11B4E8EX0MB2lancslocal_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/qiPPX3sj2ATjWnLaayDKsnTfzY4 Subject: Re: [vnfpool] Also soliciting feedback for draft-xia-vnfpool-use-cases 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: Mon, 21 Apr 2014 20:29:01 -0000 --_000_65174429B5AF4C45BD0798810EC48E0A11B4E8EX0MB2lancslocal_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgTmluZywNCg0KWWVzIGluZGVlZC4gVGhlIEdpdEh1YiByZXBvc2l0b3J5IHdhcyB0byBwcm92 aWRlIHRoZSBsYXRlc3QgdmVyc2lvbiBvZiB0aGUgSS1EIHByaW9yIHRvIGEgY29uZmVyZW5jZSBj YWxsIHdpdGggaGF2ZSB3aXRoIHRoZSB1c2UgY2FzZSBhdXRob3JzIG9uIFdlZG5lc2RheSAoQXBy aWwgMjMpLiBPbmNlIGFsbCB0aGUgYXV0aG9ycyBhcmUgaGFwcHkgd2l0aCB0aGUgdmVyc2lvbiB3 ZSB3aWxsIHN1Ym1pdCB0byB0aGUgSUVURiBhbmQgcG9zdCB0aGUgbmV3IHZlcnNpb25zIG9uIHRo ZSBsaXN0Lg0KDQpCciwgRGFuLg0KDQpGcm9tOiB2bmZwb29sIFttYWlsdG86dm5mcG9vbC1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgWm9uZ25pbmcNClNlbnQ6IDIxIEFwcmlsIDIwMTQg MDQ6MzENClRvOiBLaW5nLCBEYW5pZWw7IHZuZnBvb2xAaWV0Zi5vcmcNClN1YmplY3Q6IFt2bmZw b29sXSC08Li0OiBBbHNvIHNvbGljaXRpbmcgZmVlZGJhY2sgZm9yIGRyYWZ0LXhpYS12bmZwb29s LXVzZS1jYXNlcw0KDQpIaSwgRGFuIGFuZCBjby1hdXRob3JzLA0KDQpBcHByZWNpYXRlIHlvdXIg d29yayBvbiBtYWtpbmcgdGhpcyBuZXcgcmV2aXNpb24hDQoNCkNvdWxkIHlvdSBwbGVhc2UgYWxz byB1cGxvYWQgdGhpcyBkcmFmdCAoYW5kIGFub3RoZXIgb25lKSB0byBJRVRGIHJlcG9zaXRvcnku IEkgYXNzdW1lIGZvbGtzIGFyZSBtb3JlIGZhbWlsaWFyIHdpdGggSUVURiBkYXRhdHJhY2tlciBw b3J0YWwgoa0gOikNCg0KVGhhbmtzLg0KDQotTmluZw0KDQq3orz+yMs6IHZuZnBvb2wgW21haWx0 bzp2bmZwb29sLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gS2luZywgRGFuaWVsDQq3osvNyrG85Dog MjAxNMTqNNTCMTXI1SAyOjI5DQrK1bz+yMs6IHZuZnBvb2xAaWV0Zi5vcmc8bWFpbHRvOnZuZnBv b2xAaWV0Zi5vcmc+DQrW98ziOiBbdm5mcG9vbF0gQWxzbyBzb2xpY2l0aW5nIGZlZWRiYWNrIGZv ciBkcmFmdC14aWEtdm5mcG9vbC11c2UtY2FzZXMNCg0KSGkgQWxsIChBZ2FpbiksDQoNCldlIGFy ZSBhbHNvIHVwZGF0aW5nIHRoZSBnZW5lcmFsIFVzZSBDYXNlIEktRC4gUGxlYXNlIGZpbmQgb3Vy IGxhdGVzdCB2ZXJzaW9uIG9uIEdpdEh1YjoNCg0KaHR0cHM6Ly9naXRodWIuY29tL2RhbmllbGtp bmd1ay92bmZwb29sL3RyZWUvbWFzdGVyL2dlbmVyYWwtdXNlLWNhc2UNCg0KV2l0aCB0aGUgZm9s bG93aW5nIHVwZGF0ZXM6DQoNCg0KLSAgICAgICAgICBTeW5jaHJvbml6YXRpb24gb2YgdGVybWlu b2xvZ3kgd2l0aCBvdGhlciBWTkYgUG9vbCBJLURzDQoNCi0gICAgICAgICAgVXNpbmcgZGVmaW5p dGlvbnMgZnJvbSBQcm9ibGVtIFN0YXRlbWVudCBJLUQNCg0KLSAgICAgICAgICBSZW1vdmluZyBz b21lIG9mIHRoZSBjb250ZW50aW91cyBpdGVtcyB0aGF0IG92ZXJsYXAgd2l0aCBTRkMgKHRyYWZm aWMgc3RlZXJpbmcpLCBhdCBsZWFzdCB1bnRpbCB3ZSByZXNvbHZlIHRoZSBzaXR1YXRpb24NCg0K LSAgICAgICAgICBEaXNjdXNzaW9uIHRleHQgZm9yIFN0YXRlIFN5bmNocm9uaXphdGlvbg0KDQot ICAgICAgICAgIERpc2N1c3Npb24gdGV4dCBmb3IgVk5GIFNldA0KDQotICAgICAgICAgIFZhcmlv dXMgTml0cyBhbmQgZ3JhbW1hciB1cGRhdGVzDQoNCkJyLCBEYW4uDQo= --_000_65174429B5AF4C45BD0798810EC48E0A11B4E8EX0MB2lancslocal_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Ning,

 

Yes indeed. The GitHub repository was to provide the latest version of= the I-D prior to a conference call with have with the use case authors on = Wednesday (April 23). Once all the authors are happy with the version we will submit to the IETF and post the new ver= sions on the list.

 

Br, Dan.

 

From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of Zongning
Sent: 21 April 2014 04:31
To: King, Daniel; vnfpool@ietf.org
Subject: [vnfpool] =B4=F0=B8=B4: Also soliciting feedback = for draft-xia-vnfpool-use-cases

 

Hi, Dan and co-authors,

 

Appreciate your work on making this new revision!

 

Could you please also upload this draft (and another one) to IETF= repository. I assume folks are more familiar with IETF datatracker portal = =A1=AD J

 

Thanks.

 

-Ning

 

=B7=A2=BC=FE=C8=CB: vnfpool [mailto:vnfpool-bounces@ietf.org] =B4=FA=B1=ED King= , Daniel
=B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA4=D4=C215=C8=D5 2:29
=CA=D5=BC=FE=C8=CB: vnfpool@ietf.org
=D6=F7=CC=E2: [vnfpool] Also soliciting feedback for draft-xia-vnfpool-use-cases

 

Hi All (Again),

 

We are also updating the general Use Case I-D. Pleas= e find our latest version on GitHub:

 

https://github.com/danielkinguk/vnfpool/tree/m= aster/general-use-case

 

With the following updates:

 

-          Synchronization of terminology with other VNF Pool I-Ds

-          Using definitions from Problem Statement I-D

-          Removing some of the contentious items that overlap with SFC (traffi= c steering), at least until we resolve the situation

-          Discussion text for State Synchronization

-          Discussion text for VNF Set

-          Various Nits and grammar updates

 

Br, Dan.

--_000_65174429B5AF4C45BD0798810EC48E0A11B4E8EX0MB2lancslocal_-- From nobody Mon Apr 21 14:23:20 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 A2E521A0292 for ; Mon, 21 Apr 2014 14:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334] autolearn=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 gAidrq9wXAxz for ; Mon, 21 Apr 2014 14:23:14 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9ED1A02C1 for ; Mon, 21 Apr 2014 14:23:14 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id 2BEAE6B007E; Mon, 21 Apr 2014 14:23:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=nomountain.net; h= message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; s= nomountain.net; bh=BD8qdLAMwlnZaDKaZ1u5fa49Dow=; b=FBiaTviMUVwhi waGD+T30wHyrg1rgVCM0TTx9tOol/1X+1pmHfGIQLt9eQprSswtd1MLlmFda86dG WgKpEEGCW1DKoCju06ejBHu6386aXcQWVPzKnLmwoL0PuAa2K+YPnYVz/OmIpg36 tfkYd/ZLrvCL4DXThqv/JnkIGpp/JY= Received: from spandex.local (209-193-46-203-rb1.sol.dsl.dynamic.acsalaska.net [209.193.46.203]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: melinda.shore@nomountain.net) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPSA id 7D3FB6B007C; Mon, 21 Apr 2014 14:23:08 -0700 (PDT) Message-ID: <53558C3B.20402@nomountain.net> Date: Mon, 21 Apr 2014 13:23:07 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "King, Daniel" References: <65174429B5AF4C45BD0798810EC48E0A11A484@EX-0-MB2.lancs.local> <65174429B5AF4C45BD0798810EC48E0A11B4E8@EX-0-MB2.lancs.local> In-Reply-To: <65174429B5AF4C45BD0798810EC48E0A11B4E8@EX-0-MB2.lancs.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/lPdYFI5D9SpWBU2iL0H_PlNBeRY Cc: "vnfpool@ietf.org" , Zongning Subject: Re: [vnfpool] Also soliciting feedback for draft-xia-vnfpool-use-cases 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: Mon, 21 Apr 2014 21:23:18 -0000 On 4/21/14 12:28 PM, King, Daniel wrote: > Yes indeed. The GitHub repository was to provide the latest version of > the I-D prior to a conference call with have with the use case authors > on Wednesday (April 23). Once all the authors are happy with the version > we will submit to the IETF and post the new versions on the list. I've found github to be an extremely handy tool for collaborative document development and I use it myself. In working groups I chair I'm happy to have editors use whatever tools makes their lives easier (although I'd generally prefer folks to avoid proprietary document formats). But, IETF document submission is cheap (free!), there's plenty of space available, and in general draft review becomes easier when you can use the online diffs tool, etc. Basically I'm all for github but don't be shy about draft submissions! Melinda -- Melinda Shore No Mountain Software melinda.shore@nomountain.net "Software longa, hardware brevis." From nobody Mon Apr 21 18:38:40 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 8925D1A033C for ; Mon, 21 Apr 2014 18:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.522 X-Spam-Level: X-Spam-Status: No, score=-98.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 BVV-XWWOvKLW for ; Mon, 21 Apr 2014 18:38:33 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8202B1A00EC for ; Mon, 21 Apr 2014 18:38:32 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDI62593; Tue, 22 Apr 2014 01:38:26 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 22 Apr 2014 02:37:49 +0100 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 22 Apr 2014 02:38:24 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.85]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Tue, 22 Apr 2014 09:38:20 +0800 From: Zongning To: Zu Qiang , "vnfpool@ietf.org" Thread-Topic: New revision of VNFPool Problem Statement posted Thread-Index: Ac9UbATHM7NhTJ8NTjunJ2NkO54O2gFMTj5AABQFCQAA3Vi7sAAZ0IJA Date: Tue, 22 Apr 2014 01:38:19 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.22] Content-Type: multipart/alternative; boundary="_000_B0D29E0424F2DE47A0B36779EC66677966114597nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/lBWz9i4M5GWU_R7v_yjd7MxIVM0 Subject: [vnfpool] =?gb2312?b?tPC4tDogTmV3IHJldmlzaW9uIG9mIFZORlBvb2wgUHJv?= =?gb2312?b?YmxlbSBTdGF0ZW1lbnQgcG9zdGVk?= 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: Tue, 22 Apr 2014 01:38:37 -0000 --_000_B0D29E0424F2DE47A0B36779EC66677966114597nkgeml501mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIFFpYW5nLA0KDQpJoa9kIHByZWZlciB0byBsZWF2ZSB0aGVzZSBxdWVzdGlvbnMgdG8gdGhl IGNvLWF1dGhvcnMgb2YgVXNlIENhc2UgSS1Ecy4gOikNCkkgcmVtZW1iZXIgdGhhdCB3ZSBoYXZl IGEgY2FzZSBvZiBtdWx0aS10aWVyIHNlcnZpY2Ugd2hlcmUgZGF0YSBjb25uZWN0aW9ucyBhcmUg ZGlyZWN0bHkgYmV0d2VlbiBwb29sIGVsZW1lbnRzIG9mIGRpZmZlcmVudCBwb29scy4gQWxzbyBp biBSU2VyUG9vbCwgYSBwb29sIGVsZW1lbnQgY2FuIGFubm91bmNlIGl0cyBiYWNrdXAgZWxlbWVu dHMgdG8gdGhlIHBvb2wgdXNlcnMgdmlhIGJ1c2luZXNzIGNhcmQuIFRoZSBpbnRlcmFjdGlvbiBi ZXR3ZWVuIHBvb2wgbWFuYWdlcnMgY2FuIGJlIHVzZWQgZm9yIHBvb2xpbmcgaW5mb3JtYXRpb24g LyBzdGF0dXMgZW5xdWlyeSwgYW5kIHNvIG9uLiBBbnl3YXksIEkgdGhpbmsgdGhlIGRldGFpbHMg Y2FuIGJlIGluIHRoZSBVc2UgQ2FzZSBJLURzLg0KDQpUaGFua3MuDQoNCi1OaW5nDQoNCreivP7I yzogWnUgUWlhbmcgW21haWx0bzp6dS5xaWFuZ0Blcmljc3Nvbi5jb21dDQq3osvNyrG85DogMjAx NMTqNNTCMjHI1SAyMToxMA0KytW8/sjLOiBab25nbmluZzsgdm5mcG9vbEBpZXRmLm9yZw0K1vfM 4jogUkU6IE5ldyByZXZpc2lvbiBvZiBWTkZQb29sIFByb2JsZW0gU3RhdGVtZW50IHBvc3RlZA0K DQpIZWxsbywgWm9uZ25pbmcNCiAgICAgICAgICAgICAgICBUaGFua3MgZm9yIHlvdXIgcmVzcG9u c2UuIENhbiB5b3UgZ2l2ZSBhIHVzZSBjYXNlIG9mIKGwdGhlIGludGVyYWN0aW9ucyBiZXR3ZWVu IHRoZSBQb29sIE1hbmFnZXJzIG9mIGRpZmZlcmVudCBwb29scyBhbmQgYmV0d2VlbiB0aGUgUG9v bCBGdW5jdGlvbnMgb2YgZGlmZmVyZW50obE/IGFuZCBhIHVzZSBjYXNlIG9mIKGwVk5GIHNldKGx Pw0KDQpIYXZlIGEgbmljZSBkYXkNClp1IFFpYW5nDQoNCkZyb206IFpvbmduaW5nIFttYWlsdG86 em9uZ25pbmdAaHVhd2VpLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMTYsIDIwMTQgMTE6 NDUgUE0NClRvOiBadSBRaWFuZzsgdm5mcG9vbEBpZXRmLm9yZzxtYWlsdG86dm5mcG9vbEBpZXRm Lm9yZz4NClN1YmplY3Q6ILTwuLQ6IE5ldyByZXZpc2lvbiBvZiBWTkZQb29sIFByb2JsZW0gU3Rh dGVtZW50IHBvc3RlZA0KDQpIaSwgUWlhbmcsDQoNClBsZWFzZSBzZWUgaW5saW5lLg0KDQoNCrei vP7IyzogWnUgUWlhbmcgW21haWx0bzp6dS5xaWFuZ0Blcmljc3Nvbi5jb21dDQq3osvNyrG85Dog MjAxNMTqNNTCMTfI1SAyOjEzDQrK1bz+yMs6IFpvbmduaW5nOyB2bmZwb29sQGlldGYub3JnPG1h aWx0bzp2bmZwb29sQGlldGYub3JnPg0K1vfM4jogUkU6IE5ldyByZXZpc2lvbiBvZiBWTkZQb29s IFByb2JsZW0gU3RhdGVtZW50IHBvc3RlZA0KDQpIZWxsbywgWm9uZ25pbmcNCiAgICAgICAgICAg ICAgICBUaGFua3MgZm9yIHVwZGF0aW5nIHRoZSBkcmFmdC4gSSBkbyBzZWUgdGhpcyB2ZXJzaW9u IGlzIG11Y2ggYmV0dGVyIHRoYW4gdGhlIHByZXZpb3VzIHZlcnNpb24uIEkgaGF2ZSBhIGZldyBj bGFyaWZpY2F0aW9uIHF1ZXN0aW9ucyBiZWxvdzoNCg0KLSAgICAgICAgICBGaXJzdCwgdGhlcmUg YXJlIHNvbWUgZXhpc3RpbmcgSEEgc29sdXRpb25zLiBDYW4geW91IHRlbGwgbWUgd2hhdCBpcyB0 aGUgZXh0cmEgZnVuY3Rpb25hbGl0aWVzIHByb3ZpZGVkIGJ5IHRoZSBWTkYgUG9vbD8gT3IgdGhl IFZORiBQb29sIGlzIG9ubHkgYW5vdGhlciBhbHRlcm5hdGl2ZSBzb2x1dGlvbj8gT3IgYXJlIHdl IGdvaW5nIHRvIHVzZSB0aGUgZXhpc3RpbmcgSEEgc29sdXRpb25zIGFzIGlucHV0cyBvbmx5Pw0K DQpbTmluZ10gRm9yIHN1cmUgdGhlcmUgYXJlIGV4aXN0aW5nIEhBIHNvbHV0aW9ucy4gRm9yIGV4 YW1wbGUsIHRoZSBTQUYgaXMgYWJvdXQgU2VydmljZSBBdmFpbGFiaWxpdHkgbWVjaGFuaXNtcy4g SSBhZ3JlZSB0aGF0IHRoZXJlIGFyZSBkZWZpbml0ZWx5IG1hbnkgcGllY2VzIG9mIGV4aXN0aW5n IHdvcmsgY2FuIGJlIGludmVzdGlnYXRlZCBhcyB0aGUgYmFzaXMgb2YgVk5GIFBvb2wsIGUuZy4g cmVkdW5kYW5jeSBtb2RlbCwgc3RhdGUgc2hhcmluZy4gSSB0aGluayB0aGUgZXh0cmEgd29yayBu ZWVkZWQgaW4gVk5GIFBvb2wgaXMgdG8gYWRkcmVzcyBzcGVjaWZpYyByZXF1aXJlbWVudHMgb24g Vk5GIGZhaWxvdmVyIHByb2NlZHVyZSwgVk5GIHN0YXRlIHNoYXJpbmcsIGV0Yy4gVGhpcyB3aWxs IGRlcGVuZCBvbiBmdXJ0aGVyIHVzZSBjYXNlIGFuZCBnYXAgYW5hbHlzaXMuDQoNCg0KLSAgICAg ICAgICBTZWNvbmQsIGluIHRoZSBlYXJseSB2ZXJzaW9uLCB5b3UgaGF2ZSB0aGUgaW50ZXJhY3Rp b25zIGJldHdlZW4gdGhlIFBvb2wgTWFuYWdlcnMgb2YgZGlmZmVyZW50IHBvb2xzIGFuZCBiZXR3 ZWVuIHRoZSBQb29sIEZ1bmN0aW9ucyBvZiBkaWZmZXJlbnQgcG9vbHMgc3BlY2lmaWVkLCB3aGlj aCBpcyByZW1vdmVkIGluIHRoaXMgdmVyc2lvbi4gRG8geW91IHNlZSB0aGF0IHR5cGUgb2YgaW50 ZXJhY3Rpb25zIGFyZSBzdGlsbCBuZWVkZWQ/IEFuZCB3aHkgaXQgaXMgbmVlZGVkPw0KDQpbTmlu Z10gWWVzLCBJIGRvIHRoaW5rIHRob3NlIGludGVyYWN0aW9ucyBhcmUgc3RpbGwgbmVlZGVkLiBC dXQgSSBwcmVmZXIgYW4gVk5GIFBvb2wgYXJjaGl0ZWN0dXJlIGRvY3VtZW50IHRvIGRlc2NyaWJl IHRoZW0sIHJhdGhlciB0aGFuIFByb2JsZW0gU3RhdGVtZW50IGRyYWZ0Lg0KDQoNCi0gICAgICAg ICAgM3JkLCB0aGUgVk5GIHNldCBpcyBhIG5ldyBjb25jZXB0LiBXaGF0IGlzIHRoZSBsaW5rYWdl IHdpdGggdGhlIHByb3Bvc2VkIFZORiBQb29sIGFyY2hpdGVjdHVyZT8NCg0KW05pbmddIFZORiBz ZXQgaXMganVzdCBhIGdlbmVyYWwgc2V0IG9mIGFsbCB0aGUgVk5GIGluc3RhbmNlcy4gSW4gVk5G IFBvb2wgYXJjaGl0ZWN0dXJlLCB0aGVzZSBWTkYgaW5zdGFuY2VzIGFyZSBhY3R1YWxseSBncm91 cGVkIGludG8gbXVsdGlwbGUgcG9vbHMsIGJhc2VkIG9uIHRoZSBmdW5jdGlvbnMgdGhleSBwcm92 aWRlZC4gRm9yIGV4YW1wbGUsIGEgVk5GIHNldCB7dkZXIzEsIHZGVyMyLCB2TEIjMSwgdkxCIzIs IHZMQiMzfSBjYW4gYmUgb3JnYW5pemVkIGFzIHR3byBWTkYgcG9vbHMgqEMgb25lIHBvb2wgaXMg e3ZGVyMxLCB2RlcjMn0sIGFub3RoZXIgaXMge3ZMQiMxLCB2TEIjMiwgdkxCIzN9LiBJIHdpbGwg dHJ5IHRvIGVuaGFuY2UgdGhpcyBpbiB0aGUgZHJhZnQgbGF0ZXIgb24uDQoNCg0KLSAgICAgICAg ICA0dGgsIFJTZXJQb29sIGlzIHJlZmVycmVkIGJ5IHlvdXIgZHJhZnQuIEkgYXNzdW1lIHRoYXQg Vk5GIFBvb2wgd2lsbCBub3QgcmV1c2VkIHRoZSBSU2VyUG9vbCAgdW5jaGFuZ2VkLiBTbyB3aGlj aCBwYXJ0IG9mIFJTZXJQb29sIGNhbiBiZSByZXVzZWQgYnkgVk5GIFBvb2w/DQoNCltOaW5nXSBZ ZXMsIHdlIGJlbGlldmUgc29tZSBtZWNoYW5pc21zIGludHJvZHVjZWQgYnkgUlNlclBvb2wgY2Fu IGJlIGV4dGVuZGVkIGFuZCByZXVzZWQsIHN1Y2ggYXMgUEUgcmVnaXN0cmF0aW9uLCBwb29sIGhh bmRsZSByZXNvbHV0aW9uIGFuZCByZXNwb25zZS4gV2UgaGF2ZSBhIFJTZXJQb29sIGFwcGxpY2Fi aWxpdHkgYW5kIGdhcCBhbmFseXNpcyBkcmFmdCBkZWRpY2F0ZWQgb24gdGhpcyBwZXJzcGVjdGl2 ZS4NCg0KDQpUaGFua3MuDQpIYXZlIGEgbmljZSBkYXkNClp1IFFpYW5nDQoNCkZyb206IHZuZnBv b2wgW21haWx0bzp2bmZwb29sLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBab25nbmlu Zw0KU2VudDogV2VkbmVzZGF5LCBBcHJpbCAwOSwgMjAxNCAxMToyMiBQTQ0KVG86IHZuZnBvb2xA aWV0Zi5vcmc8bWFpbHRvOnZuZnBvb2xAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbdm5mcG9vbF0gTmV3 IHJldmlzaW9uIG9mIFZORlBvb2wgUHJvYmxlbSBTdGF0ZW1lbnQgcG9zdGVkDQoNCkhpLCBmb2xr cywNCg0KVGhlIG5ldyByZXZpc2lvbiAoLTA0KSBvZiBWTkZQb29sIFByb2JsZW0gU3RhdGVtZW50 IEktRCBpcyBhdmFpbGFibGUgb24gdGhlIGJlbG93IHBhZ2UuDQpodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC16b25nLXZuZnBvb2wtcHJvYmxlbS1zdGF0ZW1lbnQvDQoNCkhl cmUgYXJlIHRoZSBtYWpvciBjaGFuZ2VzOg0KDQoxKSAgICAgICBDbGFyaWZ5IFZORlBvb2wgYXJj aGl0ZWN0dXJlIGFuZCBpbnRlbmRlZCBzY29wZS4NCg0KMS4gICAgICAgICBBZGQgbmV3IHNlY3Rp b24gb2YgVk5GIFBvb2xzIGJlZm9yZSB0aGUgc2VjdGlvbiBvZiBQcm9ibGVtLiBUaGlzIG5ldyBz ZWN0aW9uIGlzIG1haW5seSB0byBvdXRsaW5lIG91ciBzY29wZSBiYXNlZCBvbiBoaWdoIGxldmVs IGRlc2NyaXB0aW9uIG9mIFZORiBQb29scyBhcmNoaXRlY3R1cmUuDQoNCjIuICAgICAgICAgQWRk IHRleHQgdG8gY2xhcmlmeSB0aGF0IHdlIGFyZSBzcGVjaWZpY2FsbHkgY29uY2VybmVkIHdpdGgg cmVsaWFiaWxpdHkgKGUuZy4gcmVkdW5kYW5jeSBtb2RlbCwgc3RhdGUgc2hhcmluZykgdGhhdCBp cyBtYW5hZ2VkIGluc2lkZSB0aGUgVk5GLiBXZSBhcmUgb25seSBjb25jZXJuZWQgd2l0aCB0aGUg d2hvbGUgVk5GIHNldCAob3IgZm9yd2FyZGluZyBncmFwaCkgdG8gdGhlIGV4dGVudCB0aGF0IGl0 IGludm9sdmVzIHJlbGlhYmlsaXR5IGltcGFjdCBvbiBhZGphY2VudCBpbnN0YW5jZXMgb2YgZGlm ZmVyZW50IFZORnMuDQoNCjMuICAgICAgICAgV2UgZm9jdXMgb24gcmVsaWFiaWxpdHkgbWVjaGFu aXNtcyBiYXNlZCBvbiBWTkYgcG9vbC4gT3RoZXIgVk5GIG1hbmFnZW1lbnQgYXNwZWN0cyBzdWNo IGFzIHNjYWxpbmcsIGxvYWQgYmFsYW5jaW5nIGFyZSBvdXQgb2Ygc2NvcGUuDQoNCjIpICAgICAg IFVwZGF0ZSB0ZXJtaW5vbG9naWVzIHRvIGRlZmluZSBTZXJ2aWNlIENvbnRyb2wgRW50aXR5LCBh bmQgZGVsZXRlIFBvb2wgVXNlciBhcyB0aGUgcG9vbCB3aWxsIGJlIGludGVybmFsIHRvIFZORiBv bmx5Lg0KDQozKSAgICAgICBSZS1hcnJhbmdlIHRoZSB0ZXh0IGluIHNlY3Rpb24gb2YgUHJvYmxl bXMuDQoNCjQpICAgICAgIFVwZGF0ZSB0ZXh0IG9mIFZORiBpbnN0YW5jZSBwZXJmb3JtYW5jZSBk ZWdyYWRhdGlvbiBpbiBzZWN0aW9uIG9mIFByb2JsZW1zLg0KDQo1KSAgICAgICBVcGRhdGUgdGV4 dCBvZiBSZWxpYWJsZSBUcmFuc3BvcnQgaW4gc2VjdGlvbiBvZiBQcm9ibGVtcy4NCg0KNikgICAg ICAgQWRkIHRleHQgdG8gZXhwbGFpbiB3aHkgc2VydmljZSBhdmFpbGFiaWxpdHkgaXMgbm90IGlu IHNjb3BlIGluIHNlY3Rpb24gb2YgUHJvYmxlbXMuDQoNCjcpICAgICAgIFJlLXdyaXRlIHRoZSBz ZWN0aW9uIGRlc2NyaWJpbmcgdGhlIHJlbGF0aW9uc2hpcCBvZiBWTkZQb29sIGFuZCBTRkMuDQoN CjgpICAgICAgIEFkZCB0ZXh0IG9mIHRyYW5zZmVyIG9mIHNlY3VyaXR5IHN0YXRlcyBpbiBzZWN0 aW9uIG9mIFNlY3VyaXR5IENvbnNpZGVyYXRpb24uDQoNCldlIGhvcGUgdGhhdCB0aGUgY2hhbmdl cyBoYXZlIGFkZHJlc3NlZCBtb3N0IG9mIHRoZSBjb21tZW50cywgYW5kIHJlZmxlY3RlZCBtb3N0 IG9mIHRoZSBzdWdnZXN0aW9ucyBkdXJpbmcgTG9uZG9uIEJvRi4NCg0KUGxlYXNlIHJldmlldyB0 aGlzIG5ldyByZXZpc2lvbi4gWW91ciBmdXJ0aGVyIGNvbW1lbnRzIGFuZCBzdWdnZXN0aW9ucyBh cmUgaGlnaGx5IGFwcHJlY2lhdGVkIQ0KDQpUaGFua3MuDQoNCi1OaW5nDQo= --_000_B0D29E0424F2DE47A0B36779EC66677966114597nkgeml501mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi, Qia= ng,

&n= bsp;

I=A1=AF= d prefer to leave these questions to the co-authors of Use Case I-Ds. J=

I remem= ber that we have a case of multi-tier service where data connections are di= rectly between pool elements of different pools. Also in RSerPool, a pool e= lement can announce its backup elements to the pool users via business card. The interaction between pool managers= can be used for pooling information / status enquiry, and so on. Anyway, I= think the details can be in the Use Case I-Ds.

&n= bsp;

Thanks.=

&n= bsp;

-Ning

&n= bsp;

=B7=A2=BC=FE=C8=CB: Zu Qiang [mailto:zu.qiang@ericsson.com]
=B7=A2= =CB=CD=CA=B1=BC=E4: 2014=C4=EA4=D4=C221=C8=D5 21:10
=CA=D5=BC=FE=C8=CB: Zongning; vnfpool@ietf.org
=D6=F7=CC=E2: RE: New revision of VNFPool Problem Statement posted

 

Hello, Zongning

           = ;     Thanks for your response. Can you give a use case= of =A1=B0the interactions between the Pool Managers of different pools and= between the Pool Functions of different=A1=B1? and a use case of =A1=B0VNF set=A1=B1?

 

Hav= e a nice day

Zu = Qiang

 

From: Zongning [mailto:zongning@huawei.com]
Sent: Wednesday, April 16, 2014 11:45 PM
To: Zu Qiang; vnfpool@ietf.org
Subject: =B4=F0=B8=B4: New revision of VNF= Pool Problem Statement posted

 

Hi, Qia= ng,

&n= bsp;

Please = see inline.

&n= bsp;

&n= bsp;

=B7=A2=BC=FE=C8=CB= : Zu Qiang [mailto:zu.qiang@ericsson.c= om]
=B7=A2= =CB=CD=CA=B1=BC=E4: 2014=C4=EA4=D4=C217=C8=D5 2:13
=CA=D5= =BC=FE=C8=CB: Zongning; vnfpool@ietf.org
=D6=F7= =CC=E2: RE: New revision of VNFPool Problem Statement = posted

 

Hello, Zongning

           = ;     Thanks for updating the draft. I do see this vers= ion is much better than the previous version. I have a few clarification qu= estions below:

-          First, there are some existing HA solutions. Can you tell= me what is the extra functionalities provided by the VNF Pool? Or the VNF = Pool is only another alternative solution? Or are we going to use the existing HA solutions as inputs only?

&n= bsp;

[Ning] = For sure there are existing HA solutions. For example, the SAF is about Ser= vice Availability mechanisms. I agree that there are definitely many pieces= of existing work can be investigated as the basis of VNF Pool, e.g. redundancy model, state sharing. I think th= e extra work needed in VNF Pool is to address specific requirements on VNF = failover procedure, VNF state sharing, etc. This will depend on further use= case and gap analysis.

&n= bsp;

-          Second, in the early version, you have the interactions b= etween the Pool Managers of different pools and between the Pool Functions = of different pools specified, which is removed in this version. Do you see that type of interactions are still= needed? And why it is needed?

&n= bsp;

[Ning] = Yes, I do think those interactions are still needed. But I prefer an VNF Po= ol architecture document to describe them, rather than Problem Statement dr= aft.

&n= bsp;

-          3rd, the VNF set is a new concept. What is the= linkage with the proposed VNF Pool architecture?

&n= bsp;

[Ning] = VNF set is just a general set of all the VNF instances. In VNF Pool archite= cture, these VNF instances are actually grouped into multiple pools, based = on the functions they provided. For example, a VNF set {vFW#1, vFW#2, vLB#1, vLB#2, vLB#3} can be organized as two VNF = pools =A8C one pool is {vFW#1, vFW#2}, another is {vLB#1, vLB#2, vLB#3}. I = will try to enhance this in the draft later on.

&n= bsp;

-          4th, RSerPool is referred by your draft. I ass= ume that VNF Pool will not reused the RSerPool  unchanged. So which pa= rt of RSerPool can be reused by VNF Pool?

&n= bsp;

[Ning] = Yes, we believe some mechanisms introduced by RSerPool can be extended and = reused, such as PE registration, pool handle resolution and response. We ha= ve a RSerPool applicability and gap analysis draft dedicated on this perspective.

&n= bsp;

&n= bsp;

Thanks.

Hav= e a nice day

Zu = Qiang

 

From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of Zongning
Sent: Wednesday, April 09, 2014 11:22 PM
To: vnfpool@ietf.org
Subject: [vnfpool] New revision of VNFPool Problem Statement posted<= o:p>

 

Hi, folks,

 

The new revision (-04) of VNFPo= ol Problem Statement I-D is available on the below page.<= /p>

https://datatracker.iet= f.org/doc/draft-zong-vnfpool-problem-statement/

 

Here are the major changes:

1= )   &= nbsp;   Clarify VNFPool archite= cture and intended scope.

1= .   &= nbsp;     Add new section of VNF = Pools before the section of Problem. This new section is mainly to outline = our scope based on high level description of VNF Pools architecture.

2= .   &= nbsp;     Add text to clarify tha= t we are specifically concerned with reliability (e.g. redundancy model, st= ate sharing) that is managed inside the VNF. We are only concerned with the= whole VNF set (or forwarding graph) to the extent that it involves reliability impact on adjacent instances of= different VNFs.

3= .   &= nbsp;     We focus on reliability= mechanisms based on VNF pool. Other VNF management aspects such as scaling= , load balancing are out of scope.

2= )   &= nbsp;   Update terminologies to= define Service Control Entity, and delete Pool User as the pool will be in= ternal to VNF only.

3= )   &= nbsp;   Re-arrange the text in = section of Problems.

4= )   &= nbsp;   Update text of VNF inst= ance performance degradation in section of Problems.

5= )   &= nbsp;   Update text of Reliable= Transport in section of Problems.

6= )   &= nbsp;   Add text to explain why= service availability is not in scope in section of Problems.

7= )   &= nbsp;   Re-write the section de= scribing the relationship of VNFPool and SFC.

8= )   &= nbsp;   Add text of transfer of= security states in section of Security Consideration.

 

We hope that the changes have a= ddressed most of the comments, and reflected most of the suggestions during= London BoF.

 

Please review this new revision= . Your further comments and suggestions are highly appreciated!<= /span>

 

Thanks.

 

-Ning

--_000_B0D29E0424F2DE47A0B36779EC66677966114597nkgeml501mbschi_-- From nobody Tue Apr 22 23:26:53 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 AE5FF1A0091 for ; Tue, 22 Apr 2014 23:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.551 X-Spam-Level: ** X-Spam-Status: No, score=2.551 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-0.7] 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 dsn1nrBjeDb7 for ; Tue, 22 Apr 2014 23:26:47 -0700 (PDT) Received: from out69-ams.mf.surf.net (out69-ams.mf.surf.net [145.0.1.69]) by ietfa.amsl.com (Postfix) with ESMTP id 6B8F31A008F for ; Tue, 22 Apr 2014 23:26:46 -0700 (PDT) Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by outgoing3-ams.mf.surf.net (8.14.4/8.14.4/Debian-4) with ESMTP id s3N6WEUB023070; Wed, 23 Apr 2014 08:32:14 +0200 Received: from EXHUB02.ad.utwente.nl (130.89.4.229) by EXEDGE01.ad.utwente.nl (130.89.5.48) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 23 Apr 2014 08:26:31 +0200 Received: from EXMBX23.ad.utwente.nl ([169.254.3.87]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.03.0181.006; Wed, 23 Apr 2014 08:26:27 +0200 From: To: Thread-Topic: Comments on draft-zong-vnfpool-problem-statement-04 Thread-Index: AQHPV84CA8VI2PcfvEGw8/ykUHjLd5sR/mfQgAzGgSI= Date: Wed, 23 Apr 2014 06:26:27 +0000 Message-ID: References: , In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [86.91.134.3] Content-Type: multipart/alternative; boundary="_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F459306EXMBX23adutwent_" MIME-Version: 1.0 X-Bayes-Prob: 0.5 (Score 0, tokens from: utwente-out:default, base:default, @@RPTN) X-CanIt-Geo: ip=130.89.5.48; country=NL; region=Provincie Overijssel; city=Enschede; latitude=52.2195; longitude=6.8912; http://maps.google.com/maps?q=52.2195,6.8912&z=6 X-CanItPRO-Stream: utwente-out:default (inherits from utwente:default, base:default) X-Canit-Stats-ID: 0bLRiwenc - 40bccda2ef1d - 20140423 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/qNPL-txXYLUUg-QQDVElJbcND1U Cc: vnfpool@ietf.org Subject: Re: [vnfpool] Comments on draft-zong-vnfpool-problem-statement-04 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, 23 Apr 2014 06:26:52 -0000 --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F459306EXMBX23adutwent_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgTmluZywNCg0KDQoNClRoYW5rcyBmb3IgeW91ciBhbnN3ZXJzIQ0KUGxlYXNlIHNlZSBpbiBs aW5lIQ0KDQoNCg0KDQoNCj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IFZh bjogWm9uZ25pbmcgW3pvbmduaW5nQGh1YXdlaS5jb21dDQo+IFZlcnpvbmRlbjogZGluc2RhZyAx NSBhcHJpbCAyMDE0IDU6NTYNCj4gQWFuOiBLYXJhZ2lhbm5pcywgRy4gKEVXSSkNCj4gQ0M6IHZu ZnBvb2xAaWV0Zi5vcmcNCj4gT25kZXJ3ZXJwOiC08Li0OiBDb21tZW50cyBvbiBkcmFmdC16b25n LXZuZnBvb2wtcHJvYmxlbS1zdGF0ZW1lbnQtMDQNCg0KPiBIaSwgR2Vvcmdpb3MsDQoNCj4gQXBw cmVjaWF0ZSB5b3VyIGNvbW1lbnRzIQ0KDQoNCj4gRmlyc3RseSwgbGV0IG1lIHRyeSB0byBjbGFy aWZ5IHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gVk5GIHNldCBhbmQgVk5GIHBvb2wuIFZORiBzZXQg aXMganVzdCBhIGdlbmVyYWwgc2V0IG9mIGFsbCB0aGUgVk5GIGluc3RhbmNlcy4gSW4gVk5GIFBv b2wgYXJjaGl0ZWN0dXJlLCBhbGwgdGhlc2UgVk5GIGluc3RhbmNlcyBhcmUgYWN0dWFsbHkgZ3Jv dXBlZCBpbnRvIG11bHRpcGxlIHBvb2xzLCBiYXNlZCBvbiB0aGUgZnVuY3Rpb25zIHRoZXkgcHJv dmlkZWQuIEZvciBleGFtcGxlLCBhIFZORiBzZXQge3ZGVyMxLCB2RlcjMiwgdkxCIzEsIHZMQiMy LCB2TEIjM30gY2FuIGJlIGdyb3VwZWQgaW50byB0d28gVk5GIHBvb2xzIKhDIG9uZSBwb29sIGlz IHt2RlcjMSwgdkZXIzJ9LCBhbm90aGVyIGlzIHt2TEIjMSwgdkxCIzIsIHZMQiMzfS4gU28sIG1h eWJlIHRoZSBmb2xsb3dpbmcgZGVmaW5pdGlvbiBpcyBiZXR0ZXI6DQoNCj4gVk5GIFBvb2w6IGEg Z3JvdXAgb2YgVk5GIGluc3RhbmNlcyBwcm92aWRpbmcgdGhlIHNhbWUgbmV0d29yayBmdW5jdGlv bi4NCg0KPiBWTkYgU2V0OiBhIGdlbmVyYWwgc2V0IG9mIFZORiBpbnN0YW5jZXMgdGhhdCBjYW4g YmUgZ3JvdXBlZCBpbnRvIG11bHRpcGxlIFZORiBwb29scyB3aGVyZSBkaWZmZXJlbnQgcG9vbHMg cHJvdmlkZSBkaWZmZXJlbnQgZnVuY3Rpb25zLg0KDQpHZW9yZ2lvczogT2theSwgSSB1bmRlcnN0 YW5kISBTbyB5b3UgbWVhbiB0aGF0IGEgVk5GIHNldCBpcyBhbHdheXMgY29tcG9zZWQgb2YgYSBn cm91cCBvZiBWTkYgcG9vbHMuIElzIGl0IHRoZW4gcG9zc2libGUgdG8gcHJvdmlkZSB0aGUgZm9s bG93aW5nIHNtYWxsIG1vZGlmaWN0YWlvbiB0byB0aGUgVk5GIHNldCBkZWZpbml0aW9uLiBQbGVh c2UgY2hhbmdlIHRvOg0KDQpWTkYgU2V0OiBhIGdlbmVyYWwgc2V0IG9mIFZORiBpbnN0YW5jZXMg dGhhdCBjYW4gYmUgZ3JvdXBlZCBpbnRvIG11bHRpcGxlIFZORiBwb29scywgd2hlcmUgZWFjaCBv ZiB0aGVzZSBwb29scyBwcm92aWRlIGEgZGlmZmVyZW50IG5ldHdvcmsgZnVuY3Rpb24uDQoNCg0K PiBDb21tZW50XzIgaXMgbW9yZSBpbnRlcmVzdGluZyAoaW5kZWVkISA6KSkgYW5kIHJlbGF0ZWQg dG8gVk5GIGluc3RhbmNlIGltcGxlbWVudGF0aW9uLiBBdCB0aGlzIHBvaW50IG9mIHRpbWUsIGhv dyBhYm91dCBqdXN0IGxpbWl0aW5nIG91cnNlbHZlcyB0byB5b3VyIGZvcm1lciBjYXNlLCBpLmUu LCBWTkYgaW5zdGFuY2VzIGFyZSBpZGVudGljYWwgaW4gYSBwb29sLiBUaGUgbGF0dGVyIGNhc2Ug aXMgYWN0dWFsbHkgYWJvdXQgZnVydGhlciBkZWNvbXBvc2l0aW9uIG9mIFZORiBpbnN0YW5jZSB0 byBtb3JlIFZORiBjb21wb25lbnRzIChWTkZDcykuIEkgd291bGQgZ3Vlc3MgdGhpcyBpcyBtb3Jl IGNvbXBsaWNhdGVkIChoaWVyYXJjaGljYWwpIHBvb2xpbmcgYXJjaGl0ZWN0dXJlIHRvIGJlIHN0 dWRpZWQgbGF0ZXIuDQoNCkdlb3JnaW9zOiBPa2F5LCBidXQgSSBhbSBpbiBmYXZvdXIgb2YgdGhl IGxhdHRlciBjYXNlLiBUaGUgcmVhc29uIG9mIHRoaXMgaXMgdGhhdCBpbiB0aGlzIHdheSB0aGUg cmVsaWFiaWxpdHkgbWVjaGFuaXNtcy9wcm90b2NvbHMgIHRoYXQgd2lsbCBiZSBzcGVjaWZpZWQg YnkgdGhpcyBXRyB3aWxsIGJlIGFwcGxpY2FibGUgdG8gYW55IHR5cGUgb2YgVk5GcG9vbC4NCg0K PiBDb21tZW50XzMgJiA0IGlzIGFib3V0IG91ciBzY29wZS4gQXMgZW1waGFzaXplZCBpbiBkcmFm dCwgd2UgbW9zdGx5IGNvbnNpZGVyIHRoZSByZWxpYWJpbGl0eSAob3IgcG9vbGluZykgaW5zaWRl IGEgVk5GLiBPdXIgc2NvcGUgaXMgc3RpbGwgaW50ZW5kZWQgb24gVk5GIHNldCwgYnV0ICpvbmx5 KiB0byB0aGUgZXh0ZW50IHRoYXQgaXQgaW52b2x2ZXMgcmVsaWFiaWxpdHkgaW1wYWN0IG9uIGFk amFjZW50IFZORiBpbnN0YW5jZXMgaW4gZGlmZmVyZW50IFZORiBwb29scy4gVGhlIGNvb3JkaW5h dGlvbiB0cmFmZmljIGJldHdlZW4gVk5GcyBkZWFsaW5nIHdpdGggcmVsaWFiaWxpdHkgY2FuIGJl IHN0aWxsIGludmlzaWJsZSB0byB0aGUgU2VydmljZSBDb250cm9sIEVudGl0eSwgaWYgdGhlc2Ug bWVzc2FnZXMgYXJlIGRpcmVjdGx5IHRyYW5zZmVycmVkIGJldHdlZW4gYWRqYWNlbnQgVk5GIHBv b2xzLiBTb21lIHVzZSBjYXNlcyBpbiBvdXIgVXNlIENhc2UgSS1EcyBoYXZlIHNob3duIHRoZSBi ZW5lZml0cyBvZiBkaXJlY3QgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIHBvb2xzLiBZb3UgYXJlIHJp Z2h0IGluIHRoZSBzZW5zZSB0aGF0IGlmIHN1Y2ggY29vcmRpbmF0aW9uIGlzIGV4cGxpY2l0bHkg bWFuYWdlZCBieSB0aGUgU2VydmljZSBDb250cm9sIEVudGl0eSwgb3RoZXIgV0cocykgY291bGQg YmUgYWJsZSB0byBoYW5kbGUgaXQgLSB0aGlzIHdpbGwgZGVwZW5kIG9uIG1vcmUgY2FzZSBzdHVk eS4NCg0KPiBTb3JyeSwgYnV0IEkgYW0gbm90IHN1cmUgSSBmdWxseSB1bmRlcnN0YW5kIHlvdXIg Zmlyc3QgYnVsbGV0IGluIENvbW1lbnRfMy4NCg0KR2Vvcmdpb3M6IE9rYXksIEkgdW5kZXJzdGFu ZCENCllvdSBtZWFuIHRoYXQgdGhlIHRoZSByZWxpYWJpbGl0eSBtZWNoYW5pbXMvcHJvdG9jb2xz IHNwZWNpZmllZCBpbiB0aGUgVk5GcG9vbCBXRyB3aWxsIG9ubHkgaGF2ZSBhbiBpbXBhY3QgaW5z aWRlIGEgVk5GcG9vbCBhbmQgc29tZXRpbWVzIG9uIHRoZSBhZGphY2VudCBWTkZwb29scy4gVGhp cyBpcyBhbHNvIHRoZSByZWFzb24gdGhhdCB0aGUgc29sdXRpb24gc2NvcGUgb2YgdGhpcyBXRyBp cyBkaWZmZXJlbnQgdGhhbiBvdGhlciBJRVRGIFdHcywgbGlrZSB0aGUgU0NGIFdHLg0KDQo+IENv bW1lbnRfNSAmIDY6IFllcywgd2Ugd2lsbCBpbXByb3ZlIGFzIG11Y2ggYXMgd2UgY291bGQgaW4g ZnV0dXJlIHJldmlzaW9uLg0KDQpHZW9yZ2lvczogVGhhbmsgeW91IQ0KDQpCZXN0IHJlZ2FyZHMs DQpHZW9yZ2lvcw0KDQoNCg0KPiBIb3BlIG15IHJlcGx5IGhlbHBzIGEgbGl0dGxlIGJpdC4gOikN Cg0KPiBQbGVhc2UgZG8gbGV0IG1lIGtub3cgeW91ciBmdXJ0aGVyIHF1ZXN0aW9ucy9jb21tZW50 cy4NCg0KPiAtTmluZw0KDQq3orz+yMs6IGthcmFnaWFuQGNzLnV0d2VudGUubmwgW21haWx0bzpr YXJhZ2lhbkBjcy51dHdlbnRlLm5sXQ0Kt6LLzcqxvOQ6IDIwMTTE6jTUwjE0yNUgMTg6NDENCsrV vP7IyzogWm9uZ25pbmcNCrOty806IHZuZnBvb2xAaWV0Zi5vcmcNCtb3zOI6IENvbW1lbnRzIG9u IGRyYWZ0LXpvbmctdm5mcG9vbC1wcm9ibGVtLXN0YXRlbWVudC0wNA0KDQpIaSBOaW5nLA0KDQpQ bGVhc2Ugbm90ZSB0aGF0IEkgaGF2ZSByZWFkIHRoZSBjdXJyZW50IHZlcnNpb24gb2YgdGhlIGRy YWZ0Lg0KVGhpcyB2ZXJzaW9uIGNsZWFyZXIgdGhhbiB0aGUgcHJldmlvdXMgdmVyc2lvbiBvZiB0 aGUgZHJhZnQsIGJ1dCBJTUhPIGl0IGlzIHN0aWxsIG5vdCBjbGVhciBlbm91Z2guDQoNClRoZSBt YWluIGNvbW1lbnRzIHRoYXQgSSBoYXZlIGFyZToNCg0KQ29tbWVudF8xOiBJdCBpcyBub3QgY2xl YXIgd2hhdCBhcmUgdGhlIG1haW4gZGlmZmVyZW5jZXMgYmV0d2VlbiBhIFZORiBzZXQgYW5kIGEg Vk5GcG9vbC4NCkZyb20gd2hhdCBJIGNhbiBhc3N1bWUgaXMgdGhhdCB0aGUgVk5GcG9vbCBpcyBh IGdyb3VwIG9mIFZORiBpbnN0YW5jZXMgdGhhdCBhcmUgcHJvdmlkaW5nIHRoZSBzYW1lIG5ldHdv cmsgZnVuY3Rpb24gYW5kIHRoYXQgdGhlIFZORiBzZXQgaXMgYSBncm91cCBvZiBWTkYgaW5zdGFu Y2VzLCBlYWNoIHByb3ZpZGluZyBhIGRpZmZlcmVudCBuZXR3b3JrIGZ1bmN0aW9uLCB3aGljaCBj YW4gYmUgdXNlZCB0byBidWlsZCBuZXR3b3JrIHNlcnZpY2VzLiBJcyB0aGlzIGNvcnJlY3Q/DQoN CkluIHRoZSBUZXJtaW5vbG9neSBzZWN0aW9uIHlvdSBwcm92aWRlIHRoZSBmb2xsb3dpbmcgZGVm aW5pdGlvbnM6DQoNClZORiBQb29sOiBhIGdyb3VwIG9mIFZORiBpbnN0YW5jZXMgcHJvdmlkaW5n IHRoZSBzYW1lIG5ldHdvcmsNCmZ1bmN0aW9uLg0KDQpWTkYgU2V0OiBhIGdyb3VwIG9mIFZORiBp bnN0YW5jZXMgdGhhdCBjYW4gYmUgdXNlZCB0byBidWlsZCBuZXR3b3JrDQpzZXJ2aWNlcy4NCg0K TWF5YmUgdGhlIGZvbGxvd2luZyBkZWZpbml0aW9ucyBtaWdodCBwcm92aWRlIGEgY2xlYXJlciB2 aWV3Og0KDQpWTkYgUG9vbDogYSBncm91cCBvZiBWTkYgaW5zdGFuY2VzIHByb3ZpZGluZyB0aGUg c2FtZSBuZXR3b3JrDQpmdW5jdGlvbi4NCg0KVk5GIFNldDogYSBncm91cCBvZiBWTkYgaW5zdGFu Y2VzLCBlYWNoIHByb3ZpZGluZyBhIGRpZmZlcmVudCBuZXR3b3JrIGZ1bmN0aW9uLA0Kd2hpY2gg Y2FuIGJlIHVzZWQgdG8gYnVpbGQgbmV0d29yayBzZXJ2aWNlcy4NCg0KDQpDb21tZW50XzI6IFRo aXMgY29tbWVudCBpcyByZWxhdGVkIHRvIFZORnBvb2wgYW5kIGluIHBhcnRpY3VsYXIgd2hhdCBp cyBtZWFudCBieTogVk5GIGluc3RhbmNlcyBwcm92aWRpbmcgdGhlIHNhbWUgbmV0d29yayBmdW5j dGlvbj8gQXJlIHlvdSByZWZlcnJpbmcgdG8gaWRlbnRpY2FsIFZORiBpbnN0YW5jZXMgdGhhdCBh cmUgcHJvdmlkaW5nIHRoZSBzYW1lIG5ldHdvcmsgZnVuY3Rpb24sIGkuZS4sIHZpcnR1YWxpemVk IGluc3RhbmNlcyBvZiB0aGUgc2FtZSBuZXR3b3JrIGZ1bmN0aW9uLCBvciBkb2VzIHRoaXMgZGVm aW5pdGlvbiBhbGxvdyB0byB1c2UgVk5GIGluc3RhbmNlcyB0aGF0IGFyZSBub3QgaWRlbnRpY2Fs LCBidXQgd2hlbiB0aGV5IGFyZSB1c2VkIHRvZ2V0aGVyIHRoZXkgZm9ybSBvbmUgdmlydHVhbGl6 ZWQgbmV0d29yayBmdW5jdGlvbi4NCkFuIGV4YW1wbGUgb2YgdGhlIGxhdHRlciB3aWxsIGJlIHRv IHZpcnR1YWxpc2UgYSBzZXJ2ZXIsIHdoZXJlIHRoZSBWTkYgb2YgdGhpcyBzZXJ2ZXIgd2lsbCBi ZSBjb21wb3NlZCBieSBhIHZpcnR1YWxpemVkIGluc3RhbmNlIG9mIHRoZSB1c2VkIHByb3RvY29s IHN0YWNrLCBhIHNlY29uZCB2aXJ0dWFsaXplZCBpbnN0YW5jZSBvZiB0aGUgYXBwbGljYXRpb24g cnVubmluZyBvbiB0aGUgc2VydmVyIGFuZCBhIHRoaXJkIHZpcnR1YWxpemVkIGluc3RhbmNlIG9m IHRoZSBkYXRhIGJhc2UgdXNlZCBieSB0aGUgc2VydmVyLiBBcmUgeW91IGNvbnNpZGVyaW5nIHRo aXMgY29tcG9zaXRpb24gb2YgdGhpcyBWTkYgYWxzbyBhIFZORiBwb29sPw0KDQpDb21tZW50XzM6 IFRoZSBwcm9ibGVtIHN0YXRlbWVudCBpcyBJTUhPIG5vdCBjbGVhci4gT25lIG9mIHRoZSByZWFz b25zIG9mIHRoaXMgZmFjdCBpcyB0aGF0IHRoZSBkZWZpbml0aW9uIG9mIHRoZSBWTkYgcG9vbCBh bmQgdGhlIFZORiBzZXQgaXMgbm90IGNsZWFyIGVub3VnaCwgc2VlIHByZXZpb3VzIHR3byBjb21t ZW50cy4gT3RoZXIgcmVhc29ucyAgYXJlIHJlbGF0ZWQgdG8gdGhlIGZhY3QgdGhhdCB0aGUgZHJh ZnQgZG9lcyBub3QgY2xlYXJseSBleHBsYWluOg0Kbykgd2h5IGlzIHRoZSByZWxpYWJpbGl0eSBj aGFsbGVuZ2UgbWVudGlvbmVkIGluIHRoaXMgZHJhZnQgZGlmZmVyZW50IHRoYW4gdGhlIHJlbGlh YmlsaXR5IGNoYWxsZW5nZXMgYW5kIHRoZWlyIHNvbHV0aW9ucyB1c2VkIGZvciB0aGUgcGh5c2lj YWwgZGV2aWNlcyB0aGF0IGFyZSBwcm92aWRpbmcgdGhlIHNhbWUgbmV0d29yayBmdW5jdGlvbihz KSBhcyB0aGUgbWVudGlvbmVkIFZORihzKSwgaW4gdGhpcyBkcmFmdCwgYXJlIHByb3ZpZGluZy4N Cm8pIHdoeSBpcyB0aGUgcmVsaWFiaWxpdHkgY2hhbGxlbmdlIHRoYXQgbmVlZHMgdG8gYmUgc29s dmVkIGJ5IHRoZSBWTkZwb29sIChmdXR1cmUpIFdHIGNhbm5vdCBiZSBzb2x2ZWQgYnkgdGhlIGN1 cnJlbnRseSBleGlzdGluZyBJRVRGIFdHcywgc3VjaCBhcyBTRkMuIFRoZSByZWFzb25zIGdpdmVu IGluIFNlY3Rpb24gNi4zIGFyZSBhIGJpdCBjb250cmFkaWN0b3J5LiBPbmUgb2YgdGhlIHJlYXNv bnMgcHJvdmlkZWQgaW4gdGhhdCBzZWN0aW9uIGlzIGlzIHRoYXQgdGhlIHJlbGlhYmlsaXR5IG1l Y2hhbmlzbXMgaW4gVk5GcG9vbCBhcmUgbW9zdGx5IGludGVybmFsIHRvIFZORiwgd2hpbGUgYW5v dGhlciByZWFzb24sIGdpdmVuIGluIHRoZSBzYW1lIHNlY3Rpb24sICBpcyB0aGF0IHRoZSByZWxp YWJpbGl0eSBtZWNoYW5pc20gZGVhbHMgd2l0aCBhZGphY2VuY2llcyBpbiB0aGUgVk5GIHNldC4g VGhlIGxhdHRlciBzaG93cyB0aGF0IHRoZSBtZWNoYW5pc21zIGFyZSBub3QgaW50ZXJuYWwgdG8g YSBWTkZwb29sLiBQbGVhc2UgY2xhcmlmeSENCg0KQ29tbWVudF80OiBQbGVhc2UgY2xhcmlmeSB3 aGV0aGVyIHRoZSBzY29wZSBvZiB0aGUgcmVsaWFiaWxpdHkgc29sdXRpb24gaXMgb25seSBsaW1p dGVkIHdpdGhpbiBhIFZORiBwb29sLCBvciBpcyBpdCBsaW1pdGVkIHdpdGhpbiBhIFZORiBzZXQ/ IElmIHRoZSBzY29wZSBpcyBsaW1pdGVkIHRvIGEgVk5GIHNldCwgdGhlbiB3aHkgYXJlIHlvdSBl bXBoYXNpemluZyB0aGF0IHRoZSByZWxpYWJpbGl0eSBtZWNoYW5pc21zIHdpbGwgbm90IGJlIHZp c2libGUgdG8gYW4gU0ZDIGxpa2UgY29udHJvbCBlbnRpdHksIHNpbmNlIGEgVk5GIHNldCBjb3Vs ZCBmb3JtIGEgc2VydmljZSBmdW5jdGlvbiBjaGFpbiwgc2VlIEZpZ3VyZSAyIG9mIHRoZSBkcmFm dC4NCg0KQ29tbWVudF81OiBUaGUgZHJhZnQgbmVlZHMgdG8gYmUgbW9yZSBjb25zaXN0ZW50IG9u IHdoZW4gdGhlIFZORiBzZXQgaXMgdXNlZCBhbmQgd2hlbiB0aGUgVk5GIHBvb2wgaXMgdXNlZC4N Cg0KQ29tbWVudF82OiBUaGVyZSBhcmUgYWxzbyBzb21lIGVkaXRvcmlhbCB3aGljaCBuZWVkIHRv IGJlIHdvcmtlZCBvdXQgaW4gYSBuZXh0IHZlcnNpb24gb2YgdGhlIGRyYWZ0Lg0KDQpCZXN0IHJl Z2FyZHMsDQpHZW9yZ2lvcw0KDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NClZhbjogdm5mcG9vbCBbdm5mcG9vbC1ib3VuY2VzQGlldGYub3JnXSBuYW1lbnMgWm9u Z25pbmcgW3pvbmduaW5nQGh1YXdlaS5jb21dDQpWZXJ6b25kZW46IGRvbmRlcmRhZyAxMCBhcHJp bCAyMDE0IDU6MjENCkFhbjogdm5mcG9vbEBpZXRmLm9yZzxtYWlsdG86dm5mcG9vbEBpZXRmLm9y Zz4NCk9uZGVyd2VycDogW3ZuZnBvb2xdIE5ldyByZXZpc2lvbiBvZiBWTkZQb29sIFByb2JsZW0g U3RhdGVtZW50IHBvc3RlZA0KSGksIGZvbGtzLA0KDQpUaGUgbmV3IHJldmlzaW9uICgtMDQpIG9m IFZORlBvb2wgUHJvYmxlbSBTdGF0ZW1lbnQgSS1EIGlzIGF2YWlsYWJsZSBvbiB0aGUgYmVsb3cg cGFnZS4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXpvbmctdm5mcG9v bC1wcm9ibGVtLXN0YXRlbWVudC8NCg0KSGVyZSBhcmUgdGhlIG1ham9yIGNoYW5nZXM6DQoNCjEp ICAgICAgIENsYXJpZnkgVk5GUG9vbCBhcmNoaXRlY3R1cmUgYW5kIGludGVuZGVkIHNjb3BlLg0K DQoxLiAgICAgICAgIEFkZCBuZXcgc2VjdGlvbiBvZiBWTkYgUG9vbHMgYmVmb3JlIHRoZSBzZWN0 aW9uIG9mIFByb2JsZW0uIFRoaXMgbmV3IHNlY3Rpb24gaXMgbWFpbmx5IHRvIG91dGxpbmUgb3Vy IHNjb3BlIGJhc2VkIG9uIGhpZ2ggbGV2ZWwgZGVzY3JpcHRpb24gb2YgVk5GIFBvb2xzIGFyY2hp dGVjdHVyZS4NCg0KMi4gICAgICAgICBBZGQgdGV4dCB0byBjbGFyaWZ5IHRoYXQgd2UgYXJlIHNw ZWNpZmljYWxseSBjb25jZXJuZWQgd2l0aCByZWxpYWJpbGl0eSAoZS5nLiByZWR1bmRhbmN5IG1v ZGVsLCBzdGF0ZSBzaGFyaW5nKSB0aGF0IGlzIG1hbmFnZWQgaW5zaWRlIHRoZSBWTkYuIFdlIGFy ZSBvbmx5IGNvbmNlcm5lZCB3aXRoIHRoZSB3aG9sZSBWTkYgc2V0IChvciBmb3J3YXJkaW5nIGdy YXBoKSB0byB0aGUgZXh0ZW50IHRoYXQgaXQgaW52b2x2ZXMgcmVsaWFiaWxpdHkgaW1wYWN0IG9u IGFkamFjZW50IGluc3RhbmNlcyBvZiBkaWZmZXJlbnQgVk5Gcy4NCg0KMy4gICAgICAgICBXZSBm b2N1cyBvbiByZWxpYWJpbGl0eSBtZWNoYW5pc21zIGJhc2VkIG9uIFZORiBwb29sLiBPdGhlciBW TkYgbWFuYWdlbWVudCBhc3BlY3RzIHN1Y2ggYXMgc2NhbGluZywgbG9hZCBiYWxhbmNpbmcgYXJl IG91dCBvZiBzY29wZS4NCg0KMikgICAgICAgVXBkYXRlIHRlcm1pbm9sb2dpZXMgdG8gZGVmaW5l IFNlcnZpY2UgQ29udHJvbCBFbnRpdHksIGFuZCBkZWxldGUgUG9vbCBVc2VyIGFzIHRoZSBwb29s IHdpbGwgYmUgaW50ZXJuYWwgdG8gVk5GIG9ubHkuDQoNCjMpICAgICAgIFJlLWFycmFuZ2UgdGhl IHRleHQgaW4gc2VjdGlvbiBvZiBQcm9ibGVtcy4NCg0KNCkgICAgICAgVXBkYXRlIHRleHQgb2Yg Vk5GIGluc3RhbmNlIHBlcmZvcm1hbmNlIGRlZ3JhZGF0aW9uIGluIHNlY3Rpb24gb2YgUHJvYmxl bXMuDQoNCjUpICAgICAgIFVwZGF0ZSB0ZXh0IG9mIFJlbGlhYmxlIFRyYW5zcG9ydCBpbiBzZWN0 aW9uIG9mIFByb2JsZW1zLg0KDQo2KSAgICAgICBBZGQgdGV4dCB0byBleHBsYWluIHdoeSBzZXJ2 aWNlIGF2YWlsYWJpbGl0eSBpcyBub3QgaW4gc2NvcGUgaW4gc2VjdGlvbiBvZiBQcm9ibGVtcy4N Cg0KNykgICAgICAgUmUtd3JpdGUgdGhlIHNlY3Rpb24gZGVzY3JpYmluZyB0aGUgcmVsYXRpb25z aGlwIG9mIFZORlBvb2wgYW5kIFNGQy4NCg0KOCkgICAgICAgQWRkIHRleHQgb2YgdHJhbnNmZXIg b2Ygc2VjdXJpdHkgc3RhdGVzIGluIHNlY3Rpb24gb2YgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbi4N Cg0KV2UgaG9wZSB0aGF0IHRoZSBjaGFuZ2VzIGhhdmUgYWRkcmVzc2VkIG1vc3Qgb2YgdGhlIGNv bW1lbnRzLCBhbmQgcmVmbGVjdGVkIG1vc3Qgb2YgdGhlIHN1Z2dlc3Rpb25zIGR1cmluZyBMb25k b24gQm9GLg0KDQpQbGVhc2UgcmV2aWV3IHRoaXMgbmV3IHJldmlzaW9uLiBZb3VyIGZ1cnRoZXIg Y29tbWVudHMgYW5kIHN1Z2dlc3Rpb25zIGFyZSBoaWdobHkgYXBwcmVjaWF0ZWQhDQoNClRoYW5r cy4NCg0KLU5pbmcNCg== --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F459306EXMBX23adutwent_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Ning,

 

Thanks for your answers!
Please see in line!

 

 

> Van: Zongning [zongning@huawei.com] > Verzonden: dinsdag 15 april 2014 5:56
> Aan: Karagiannis, G. (EWI)
> CC: vnfpool@ietf.org
> Onderwerp: =B4=F0=B8=B4: Comments on draft-zong-vnfpool-problem= -statement-04

> H= i, Georgios,

 

> A= ppreciate your comments!

 

 

> Firstly, let me try to clarify the difference between VNF set and VN= F pool. VNF set is just a gene= ral set of all the VNF instances. In VNF Pool architecture, all these VNF i= nstances are actually grouped into multiple pools, based on the functions t= hey provided. For example, a VNF set {vFW#1, vFW#2, vLB#1, vLB#2, vLB#3} can be grouped into two VNF pools =A8C= one pool is {vFW#1, vFW#2}, another is {vLB#1, vLB#2, vLB#3}. So, maybe th= e following definition is better:

 

> VNF Pool: a group of VNF instances providing the same network= function.

&nb= sp;

> VNF Set: a general set of VNF instances that can be grouped i= nto multiple VNF pools where different pools provide different functions.

 

Georgios: Okay, I understand! So you mean that a VNF set is= always composed of a group of VNF pools. Is it then possible to provide the following small modifictaion to th= e VNF set definition. Please change to:

 

VNF Set: a general set of VNF instances that can be grouped= into multiple VNF pools, where each of these pools provide a different network function.

 

 

> Comment_2 is more interesting (ind= eed! J) and related to VN= F instance implementation. At this point of time, how about just limiting o= urselves to your former case, i.e., VNF instances are identical in a pool. The latter case is actually about furth= er decomposition of VNF instance to more VNF components (VNFCs). I would gu= ess this is more complicated (hierarchical) pooling architecture to be stud= ied later.

 

Georgios: Okay,= but I am in favour of the latter case. The reason of this is that in this = way the reliability mechanisms/protocols  that will be specified by this WG will be applicable to any type of V= NFpool.

 

> Comment_3 & 4 is about our sco= pe. As emphasized in draft, we mostly consider the reliability (or pooling)= inside a VNF. Our scope is still intended on VNF set, but *only* to the extent that it involves reliability impact o= n adjacent VNF instances in different VNF pools. The coordination traffic b= etween VNFs dealing with reliability can be still invisible to the Service = Control Entity, if these messages are directly transferred between adjacent VNF pools. Some use cases in our= Use Case I-Ds have shown the benefits of direct communication between pool= s. You are right in the sense that if such coordination is explicitly manag= ed by the Service Control Entity, other WG(s) could be able to handle it - this will depend on more case stu= dy.

 

> Sorry, but I am not sure I fully u= nderstand your first bullet in Comment_3.

 

Georgios: Okay,= I understand!

You mean that t= he the reliability mechanims/protocols specified in the VNFpool WG will onl= y have an impact inside a VNFpool and sometimes on the adjacent VNFpools. This is also the reason that the solut= ion scope of this WG is different than other IETF WGs, like the SCF WG.

 

> Comment_5 & 6: Yes, we will im= prove as much as we could in future revision.

 

Georgios: Thank= you!

&= nbsp;

Best regards,

Georgios=

&= nbsp;

 

 

> Hope my reply helps a little bit. J

 

> Please do let me know your further= questions/comments.

 

> -Ning

 

=B7=A2=BC=FE=C8=CB: karagian@cs.utwente.nl [mailto:karagian@= cs.utwente.nl]
=B7=A2= =CB=CD=CA=B1=BC=E4: 2014=C4=EA4=D4=C214=C8=D5 18:41
=CA=D5=BC=FE=C8=CB: Zongning
=B3=AD=CB=CD: vnfpool@ietf.org
=D6=F7=CC=E2: Comments on draft-zong-vnfpool-problem-statement-04

 

Hi Ning,

 

Please note that I have read the current version of the dra= ft.

This version clearer than the previous version of the draft= , but IMHO it is still not clear enough.

 

The main comments that I have are:

 

Comment_1: It is not clear what are the main differences be= tween a VNF set and a VNFpool.

From what I can assume is that the VNFpool is a group of VN= F instances that are providing the same network function and that the VNF set is a group of VNF instances, each providing = a different network function, which can be used to build network services. = Is this correct?

 

In the Terminology section you provide the following defini= tions:

 

VNF Pool: a group of VNF instances providing the same netwo= rk

function.

 

VNF Set: a group of VNF instances that can be used to build= network

services.

 

Maybe the following definitions might provide a clearer vie= w:

 

VNF Pool: a group of VNF instances providing the same netwo= rk

function.

 

VNF Set: a group of VNF instances, each providing a differe= nt network function,

which can be used to build network services.

 

 

Comment_2: This comment is related to VNFpool and in partic= ular what is meant by: VNF instances providing the same network function? Are you referring to identical VNF instances th= at are providing the same network function, i.e., virtualized instances of = the same network function, or does this definition allow to use VNF instanc= es that are not identical, but when they are used together they form one virtualized network function.<= /p>

An example of the latter will be to virtualise a server, wh= ere the VNF of this server will be composed by a virtualized instance of the used protocol stack, a second virtualized= instance of the application running on the server and a third virtualized = instance of the data base used by the server. Are you considering this comp= osition of this VNF also a VNF pool?

 

Comment_3: The problem statement is IMHO not clear. One of = the reasons of this fact is that the definition of the VNF pool and the VNF set is not clear enough, see previous two comm= ents. Other reasons  are related to the fact that the draft does not c= learly explain:

o) why is the reliability challenge mentioned in this draft= different than the reliability challenges and their solutions used for the physical devices that are providing the s= ame network function(s) as the mentioned VNF(s), in this draft, are providi= ng.

o) why is the reliability challenge that needs to be solved= by the VNFpool (future) WG cannot be solved by the currently existing IETF WGs, such as SFC. The reasons given in Sect= ion 6.3 are a bit contradictory. One of the reasons provided in that sectio= n is is that the reliability mechanisms in VNFpool are mostly internal to V= NF, while another reason, given in the same section,  is that the reliability mechanism deals with ad= jacencies in the VNF set. The latter shows that the mechanisms are not inte= rnal to a VNFpool. Please clarify!

 

Comment_4: Please clarify whether the scope of the reliabil= ity solution is only limited within a VNF pool, or is it limited within a VNF set? If the scope is limited to a VNF = set, then why are you emphasizing that the reliability mechanisms will not = be visible to an SFC like control entity, since a VNF set could form a serv= ice function chain, see Figure 2 of the draft.

 

Comment_5: The draft needs to be more consistent on when th= e VNF set is used and when the VNF pool is used.

 

Comment_6: There are also some editorial which need to be w= orked out in a next version of the draft.

 

Best regards,

Georgios=

&= nbsp;

 

 

 

Van: vnfpool [vnfpool-bounces@ietf.org] namens Zongning [zongning@huawei.com] Verzonden: donderdag 10 april 2014 5:21
Aan: vnfpool@i= etf.org
Onderwerp: [vnfpool] New revision of VNFPool Problem Statement poste= d

Hi, folk= s,

&= nbsp;

The new = revision (-04) of VNFPool Problem Statement I-D is available on the below p= age.

https://datatracker.ietf.org/doc/draft-zong-vnfpool-prob= lem-statement/

&= nbsp;

Here are= the major changes:

1)       Clarify VNFPool architec= ture and intended scope.

1.         Add new section of VNF P= ools before the section of Problem. This new section is mainly to outline o= ur scope based on high level description of VNF Pools architecture.<= /p>

2.         Add text to clarify that= we are specifically concerned with reliability (e.g. redundancy model, sta= te sharing) that is managed inside the VNF. We are only concerned with the = whole VNF set (or forwarding graph) to the extent that it involves reliability impact on adjacent instances of= different VNFs.

3.         We focus on reliability = mechanisms based on VNF pool. Other VNF management aspects such as scaling,= load balancing are out of scope.

2)       Update terminologies to = define Service Control Entity, and delete Pool User as the pool will be int= ernal to VNF only.

3)       Re-arrange the text in s= ection of Problems.

4)       Update text of VNF insta= nce performance degradation in section of Problems.

5)       Update text of Reliable = Transport in section of Problems.

6)       Add text to explain why = service availability is not in scope in section of Problems.

7)       Re-write the section des= cribing the relationship of VNFPool and SFC.

8)       Add text of transfer of = security states in section of Security Consideration.

&= nbsp;

We hope = that the changes have addressed most of the comments, and reflected most of= the suggestions during London BoF.

&= nbsp;

Please r= eview this new revision. Your further comments and suggestions are highly a= ppreciated!

&= nbsp;

Thanks.<= /span>

&= nbsp;

-Ning

--_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F459306EXMBX23adutwent_-- From nobody Thu Apr 24 00:52:58 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 15E6B1A00CD for ; Thu, 24 Apr 2014 00:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.522 X-Spam-Level: X-Spam-Status: No, score=-98.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 k0JlswVU6aPn for ; Thu, 24 Apr 2014 00:52:49 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1C14F1A00BF for ; Thu, 24 Apr 2014 00:52:47 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGA41652; Thu, 24 Apr 2014 07:52:36 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 24 Apr 2014 08:51:38 +0100 Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 24 Apr 2014 08:52:35 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.85]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Thu, 24 Apr 2014 15:49:44 +0800 From: Zongning To: "karagian@cs.utwente.nl" Thread-Topic: Comments on draft-zong-vnfpool-problem-statement-04 Thread-Index: AQHPV84CA8VI2PcfvEGw8/ykUHjLd5sR/mfQgAzGgSKAAa1foA== Date: Thu, 24 Apr 2014 07:49:44 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.22] Content-Type: multipart/alternative; boundary="_000_B0D29E0424F2DE47A0B36779EC66677966114FBAnkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/93f0Gvyh7FpJ8BllqUmnakSvajs Cc: "vnfpool@ietf.org" Subject: [vnfpool] =?gb2312?b?tPC4tDogQ29tbWVudHMgb24gZHJhZnQtem9uZy12bmZw?= =?gb2312?b?b29sLXByb2JsZW0tc3RhdGVtZW50LTA0?= 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, 24 Apr 2014 07:52:55 -0000 --_000_B0D29E0424F2DE47A0B36779EC66677966114FBAnkgeml501mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIEdlb3JnaW9zLA0KDQo+PiBWTkYgU2V0OiBhIGdlbmVyYWwgc2V0IG9mIFZORiBpbnN0YW5j ZXMgdGhhdCBjYW4gYmUgZ3JvdXBlZCBpbnRvIG11bHRpcGxlIFZORiBwb29scywgd2hlcmUgZWFj aCBvZiB0aGVzZSBwb29scyBwcm92aWRlIGEgZGlmZmVyZW50IG5ldHdvcmsgZnVuY3Rpb24uDQoN CltOaW5nXTogWWVzLCB3ZSB3aWxsIHVwZGF0ZSBQUyBkcmFmdCBpbiBuZXh0IHJldmlzaW9uIQ0K DQo+PiBUaGUgcmVhc29uIG9mIHRoaXMgaXMgdGhhdCBpbiB0aGlzIHdheSB0aGUgcmVsaWFiaWxp dHkgbWVjaGFuaXNtcy9wcm90b2NvbHMgIHRoYXQgd2lsbCBiZSBzcGVjaWZpZWQgYnkgdGhpcyBX RyB3aWxsIGJlIGFwcGxpY2FibGUgdG8gYW55IHR5cGUgb2YgVk5GcG9vbC4NCg0KW05pbmddOiBX ZSB3aWxsIGNlcnRhaW5seSBjb25zaWRlciBnZW5lcmFsIG1lY2hhbmlzbXMvcHJvdG9jb2xzIHRv IGNvdmVyIG1vcmUgY2FzZXMgYW5kIHR5cGVzIG9mIFZORiBwb29sLiBXZSBjYW4gcmVmbGVjdCB0 aGlzIHBvaW50IGluIFBTIGRyYWZ0LCBidXQgbGVhdmUgdGhlIGRldGFpbHMgb2Ygc29sdXRpb24g dG8gbmV4dCBzdGVwIG9mIHdvcmssIGJhc2VkIG9uIHVzZSBjYXNlcyAmIHJlcXVpcmVtZW50cy4N Cg0KPj4gWW91IG1lYW4gdGhhdCB0aGUgdGhlIHJlbGlhYmlsaXR5IG1lY2hhbmltcy9wcm90b2Nv bHMgc3BlY2lmaWVkIGluIHRoZSBWTkZwb29sIFdHIHdpbGwgb25seSBoYXZlIGFuIGltcGFjdCBp bnNpZGUgYSBWTkZwb29sIGFuZCBzb21ldGltZXMgb24gdGhlIGFkamFjZW50IFZORnBvb2xzLiBU aGlzIGlzIGFsc28gdGhlIHJlYXNvbiB0aGF0IHRoZSBzb2x1dGlvbiBzY29wZSBvZiB0aGlzIFdH IGlzIGRpZmZlcmVudCB0aGFuIG90aGVyIElFVEYgV0dzLCBsaWtlIHRoZSBTQ0YgV0cuDQoNCltO aW5nXSBFeGFjdGx5IQ0KDQpUaGFua3MuDQoNCi1OaW5nDQoNCreivP7Iyzoga2FyYWdpYW5AY3Mu dXR3ZW50ZS5ubCBbbWFpbHRvOmthcmFnaWFuQGNzLnV0d2VudGUubmxdDQq3osvNyrG85DogMjAx NMTqNNTCMjPI1SAxNDoyNg0KytW8/sjLOiBab25nbmluZw0Ks63LzTogdm5mcG9vbEBpZXRmLm9y Zw0K1vfM4jogUkU6IENvbW1lbnRzIG9uIGRyYWZ0LXpvbmctdm5mcG9vbC1wcm9ibGVtLXN0YXRl bWVudC0wNA0KDQoNCkhpIE5pbmcsDQoNCg0KDQpUaGFua3MgZm9yIHlvdXIgYW5zd2VycyENClBs ZWFzZSBzZWUgaW4gbGluZSENCg0KDQoNCg0KPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gVmFuOiBab25nbmluZyBbem9uZ25pbmdAaHVhd2VpLmNvbV0NCj4gVmVyem9uZGVu OiBkaW5zZGFnIDE1IGFwcmlsIDIwMTQgNTo1Ng0KPiBBYW46IEthcmFnaWFubmlzLCBHLiAoRVdJ KQ0KPiBDQzogdm5mcG9vbEBpZXRmLm9yZzxtYWlsdG86dm5mcG9vbEBpZXRmLm9yZz4NCj4gT25k ZXJ3ZXJwOiC08Li0OiBDb21tZW50cyBvbiBkcmFmdC16b25nLXZuZnBvb2wtcHJvYmxlbS1zdGF0 ZW1lbnQtMDQNCj4gSGksIEdlb3JnaW9zLA0KDQo+IEFwcHJlY2lhdGUgeW91ciBjb21tZW50cyEN Cg0KDQo+IEZpcnN0bHksIGxldCBtZSB0cnkgdG8gY2xhcmlmeSB0aGUgZGlmZmVyZW5jZSBiZXR3 ZWVuIFZORiBzZXQgYW5kIFZORiBwb29sLiBWTkYgc2V0IGlzIGp1c3QgYSBnZW5lcmFsIHNldCBv ZiBhbGwgdGhlIFZORiBpbnN0YW5jZXMuIEluIFZORiBQb29sIGFyY2hpdGVjdHVyZSwgYWxsIHRo ZXNlIFZORiBpbnN0YW5jZXMgYXJlIGFjdHVhbGx5IGdyb3VwZWQgaW50byBtdWx0aXBsZSBwb29s cywgYmFzZWQgb24gdGhlIGZ1bmN0aW9ucyB0aGV5IHByb3ZpZGVkLiBGb3IgZXhhbXBsZSwgYSBW TkYgc2V0IHt2RlcjMSwgdkZXIzIsIHZMQiMxLCB2TEIjMiwgdkxCIzN9IGNhbiBiZSBncm91cGVk IGludG8gdHdvIFZORiBwb29scyCoQyBvbmUgcG9vbCBpcyB7dkZXIzEsIHZGVyMyfSwgYW5vdGhl ciBpcyB7dkxCIzEsIHZMQiMyLCB2TEIjM30uIFNvLCBtYXliZSB0aGUgZm9sbG93aW5nIGRlZmlu aXRpb24gaXMgYmV0dGVyOg0KDQo+IFZORiBQb29sOiBhIGdyb3VwIG9mIFZORiBpbnN0YW5jZXMg cHJvdmlkaW5nIHRoZSBzYW1lIG5ldHdvcmsgZnVuY3Rpb24uDQoNCj4gVk5GIFNldDogYSBnZW5l cmFsIHNldCBvZiBWTkYgaW5zdGFuY2VzIHRoYXQgY2FuIGJlIGdyb3VwZWQgaW50byBtdWx0aXBs ZSBWTkYgcG9vbHMgd2hlcmUgZGlmZmVyZW50IHBvb2xzIHByb3ZpZGUgZGlmZmVyZW50IGZ1bmN0 aW9ucy4NCg0KR2Vvcmdpb3M6IE9rYXksIEkgdW5kZXJzdGFuZCEgU28geW91IG1lYW4gdGhhdCBh IFZORiBzZXQgaXMgYWx3YXlzIGNvbXBvc2VkIG9mIGEgZ3JvdXAgb2YgVk5GIHBvb2xzLiBJcyBp dCB0aGVuIHBvc3NpYmxlIHRvIHByb3ZpZGUgdGhlIGZvbGxvd2luZyBzbWFsbCBtb2RpZmljdGFp b24gdG8gdGhlIFZORiBzZXQgZGVmaW5pdGlvbi4gUGxlYXNlIGNoYW5nZSB0bzoNCg0KVk5GIFNl dDogYSBnZW5lcmFsIHNldCBvZiBWTkYgaW5zdGFuY2VzIHRoYXQgY2FuIGJlIGdyb3VwZWQgaW50 byBtdWx0aXBsZSBWTkYgcG9vbHMsIHdoZXJlIGVhY2ggb2YgdGhlc2UgcG9vbHMgcHJvdmlkZSBh IGRpZmZlcmVudCBuZXR3b3JrIGZ1bmN0aW9uLg0KDQoNCj4gQ29tbWVudF8yIGlzIG1vcmUgaW50 ZXJlc3RpbmcgKGluZGVlZCEgOikpIGFuZCByZWxhdGVkIHRvIFZORiBpbnN0YW5jZSBpbXBsZW1l bnRhdGlvbi4gQXQgdGhpcyBwb2ludCBvZiB0aW1lLCBob3cgYWJvdXQganVzdCBsaW1pdGluZyBv dXJzZWx2ZXMgdG8geW91ciBmb3JtZXIgY2FzZSwgaS5lLiwgVk5GIGluc3RhbmNlcyBhcmUgaWRl bnRpY2FsIGluIGEgcG9vbC4gVGhlIGxhdHRlciBjYXNlIGlzIGFjdHVhbGx5IGFib3V0IGZ1cnRo ZXIgZGVjb21wb3NpdGlvbiBvZiBWTkYgaW5zdGFuY2UgdG8gbW9yZSBWTkYgY29tcG9uZW50cyAo Vk5GQ3MpLiBJIHdvdWxkIGd1ZXNzIHRoaXMgaXMgbW9yZSBjb21wbGljYXRlZCAoaGllcmFyY2hp Y2FsKSBwb29saW5nIGFyY2hpdGVjdHVyZSB0byBiZSBzdHVkaWVkIGxhdGVyLg0KDQpHZW9yZ2lv czogT2theSwgYnV0IEkgYW0gaW4gZmF2b3VyIG9mIHRoZSBsYXR0ZXIgY2FzZS4gVGhlIHJlYXNv biBvZiB0aGlzIGlzIHRoYXQgaW4gdGhpcyB3YXkgdGhlIHJlbGlhYmlsaXR5IG1lY2hhbmlzbXMv cHJvdG9jb2xzICB0aGF0IHdpbGwgYmUgc3BlY2lmaWVkIGJ5IHRoaXMgV0cgd2lsbCBiZSBhcHBs aWNhYmxlIHRvIGFueSB0eXBlIG9mIFZORnBvb2wuDQoNCj4gQ29tbWVudF8zICYgNCBpcyBhYm91 dCBvdXIgc2NvcGUuIEFzIGVtcGhhc2l6ZWQgaW4gZHJhZnQsIHdlIG1vc3RseSBjb25zaWRlciB0 aGUgcmVsaWFiaWxpdHkgKG9yIHBvb2xpbmcpIGluc2lkZSBhIFZORi4gT3VyIHNjb3BlIGlzIHN0 aWxsIGludGVuZGVkIG9uIFZORiBzZXQsIGJ1dCAqb25seSogdG8gdGhlIGV4dGVudCB0aGF0IGl0 IGludm9sdmVzIHJlbGlhYmlsaXR5IGltcGFjdCBvbiBhZGphY2VudCBWTkYgaW5zdGFuY2VzIGlu IGRpZmZlcmVudCBWTkYgcG9vbHMuIFRoZSBjb29yZGluYXRpb24gdHJhZmZpYyBiZXR3ZWVuIFZO RnMgZGVhbGluZyB3aXRoIHJlbGlhYmlsaXR5IGNhbiBiZSBzdGlsbCBpbnZpc2libGUgdG8gdGhl IFNlcnZpY2UgQ29udHJvbCBFbnRpdHksIGlmIHRoZXNlIG1lc3NhZ2VzIGFyZSBkaXJlY3RseSB0 cmFuc2ZlcnJlZCBiZXR3ZWVuIGFkamFjZW50IFZORiBwb29scy4gU29tZSB1c2UgY2FzZXMgaW4g b3VyIFVzZSBDYXNlIEktRHMgaGF2ZSBzaG93biB0aGUgYmVuZWZpdHMgb2YgZGlyZWN0IGNvbW11 bmljYXRpb24gYmV0d2VlbiBwb29scy4gWW91IGFyZSByaWdodCBpbiB0aGUgc2Vuc2UgdGhhdCBp ZiBzdWNoIGNvb3JkaW5hdGlvbiBpcyBleHBsaWNpdGx5IG1hbmFnZWQgYnkgdGhlIFNlcnZpY2Ug Q29udHJvbCBFbnRpdHksIG90aGVyIFdHKHMpIGNvdWxkIGJlIGFibGUgdG8gaGFuZGxlIGl0IC0g dGhpcyB3aWxsIGRlcGVuZCBvbiBtb3JlIGNhc2Ugc3R1ZHkuDQoNCj4gU29ycnksIGJ1dCBJIGFt IG5vdCBzdXJlIEkgZnVsbHkgdW5kZXJzdGFuZCB5b3VyIGZpcnN0IGJ1bGxldCBpbiBDb21tZW50 XzMuDQoNCkdlb3JnaW9zOiBPa2F5LCBJIHVuZGVyc3RhbmQhDQpZb3UgbWVhbiB0aGF0IHRoZSB0 aGUgcmVsaWFiaWxpdHkgbWVjaGFuaW1zL3Byb3RvY29scyBzcGVjaWZpZWQgaW4gdGhlIFZORnBv b2wgV0cgd2lsbCBvbmx5IGhhdmUgYW4gaW1wYWN0IGluc2lkZSBhIFZORnBvb2wgYW5kIHNvbWV0 aW1lcyBvbiB0aGUgYWRqYWNlbnQgVk5GcG9vbHMuIFRoaXMgaXMgYWxzbyB0aGUgcmVhc29uIHRo YXQgdGhlIHNvbHV0aW9uIHNjb3BlIG9mIHRoaXMgV0cgaXMgZGlmZmVyZW50IHRoYW4gb3RoZXIg SUVURiBXR3MsIGxpa2UgdGhlIFNDRiBXRy4NCg0KPiBDb21tZW50XzUgJiA2OiBZZXMsIHdlIHdp bGwgaW1wcm92ZSBhcyBtdWNoIGFzIHdlIGNvdWxkIGluIGZ1dHVyZSByZXZpc2lvbi4NCg0KR2Vv cmdpb3M6IFRoYW5rIHlvdSENCg0KQmVzdCByZWdhcmRzLA0KR2Vvcmdpb3MNCg0KDQoNCj4gSG9w ZSBteSByZXBseSBoZWxwcyBhIGxpdHRsZSBiaXQuIDopDQoNCj4gUGxlYXNlIGRvIGxldCBtZSBr bm93IHlvdXIgZnVydGhlciBxdWVzdGlvbnMvY29tbWVudHMuDQoNCj4gLU5pbmcNCg0Kt6K8/sjL OiBrYXJhZ2lhbkBjcy51dHdlbnRlLm5sPG1haWx0bzprYXJhZ2lhbkBjcy51dHdlbnRlLm5sPiBb bWFpbHRvOmthcmFnaWFuQGNzLnV0d2VudGUubmxdDQq3osvNyrG85DogMjAxNMTqNNTCMTTI1SAx ODo0MQ0KytW8/sjLOiBab25nbmluZw0Ks63LzTogdm5mcG9vbEBpZXRmLm9yZzxtYWlsdG86dm5m cG9vbEBpZXRmLm9yZz4NCtb3zOI6IENvbW1lbnRzIG9uIGRyYWZ0LXpvbmctdm5mcG9vbC1wcm9i bGVtLXN0YXRlbWVudC0wNA0KDQpIaSBOaW5nLA0KDQpQbGVhc2Ugbm90ZSB0aGF0IEkgaGF2ZSBy ZWFkIHRoZSBjdXJyZW50IHZlcnNpb24gb2YgdGhlIGRyYWZ0Lg0KVGhpcyB2ZXJzaW9uIGNsZWFy ZXIgdGhhbiB0aGUgcHJldmlvdXMgdmVyc2lvbiBvZiB0aGUgZHJhZnQsIGJ1dCBJTUhPIGl0IGlz IHN0aWxsIG5vdCBjbGVhciBlbm91Z2guDQoNClRoZSBtYWluIGNvbW1lbnRzIHRoYXQgSSBoYXZl IGFyZToNCg0KQ29tbWVudF8xOiBJdCBpcyBub3QgY2xlYXIgd2hhdCBhcmUgdGhlIG1haW4gZGlm ZmVyZW5jZXMgYmV0d2VlbiBhIFZORiBzZXQgYW5kIGEgVk5GcG9vbC4NCkZyb20gd2hhdCBJIGNh biBhc3N1bWUgaXMgdGhhdCB0aGUgVk5GcG9vbCBpcyBhIGdyb3VwIG9mIFZORiBpbnN0YW5jZXMg dGhhdCBhcmUgcHJvdmlkaW5nIHRoZSBzYW1lIG5ldHdvcmsgZnVuY3Rpb24gYW5kIHRoYXQgdGhl IFZORiBzZXQgaXMgYSBncm91cCBvZiBWTkYgaW5zdGFuY2VzLCBlYWNoIHByb3ZpZGluZyBhIGRp ZmZlcmVudCBuZXR3b3JrIGZ1bmN0aW9uLCB3aGljaCBjYW4gYmUgdXNlZCB0byBidWlsZCBuZXR3 b3JrIHNlcnZpY2VzLiBJcyB0aGlzIGNvcnJlY3Q/DQoNCkluIHRoZSBUZXJtaW5vbG9neSBzZWN0 aW9uIHlvdSBwcm92aWRlIHRoZSBmb2xsb3dpbmcgZGVmaW5pdGlvbnM6DQoNClZORiBQb29sOiBh IGdyb3VwIG9mIFZORiBpbnN0YW5jZXMgcHJvdmlkaW5nIHRoZSBzYW1lIG5ldHdvcmsNCmZ1bmN0 aW9uLg0KDQpWTkYgU2V0OiBhIGdyb3VwIG9mIFZORiBpbnN0YW5jZXMgdGhhdCBjYW4gYmUgdXNl ZCB0byBidWlsZCBuZXR3b3JrDQpzZXJ2aWNlcy4NCg0KTWF5YmUgdGhlIGZvbGxvd2luZyBkZWZp bml0aW9ucyBtaWdodCBwcm92aWRlIGEgY2xlYXJlciB2aWV3Og0KDQpWTkYgUG9vbDogYSBncm91 cCBvZiBWTkYgaW5zdGFuY2VzIHByb3ZpZGluZyB0aGUgc2FtZSBuZXR3b3JrDQpmdW5jdGlvbi4N Cg0KVk5GIFNldDogYSBncm91cCBvZiBWTkYgaW5zdGFuY2VzLCBlYWNoIHByb3ZpZGluZyBhIGRp ZmZlcmVudCBuZXR3b3JrIGZ1bmN0aW9uLA0Kd2hpY2ggY2FuIGJlIHVzZWQgdG8gYnVpbGQgbmV0 d29yayBzZXJ2aWNlcy4NCg0KDQpDb21tZW50XzI6IFRoaXMgY29tbWVudCBpcyByZWxhdGVkIHRv IFZORnBvb2wgYW5kIGluIHBhcnRpY3VsYXIgd2hhdCBpcyBtZWFudCBieTogVk5GIGluc3RhbmNl cyBwcm92aWRpbmcgdGhlIHNhbWUgbmV0d29yayBmdW5jdGlvbj8gQXJlIHlvdSByZWZlcnJpbmcg dG8gaWRlbnRpY2FsIFZORiBpbnN0YW5jZXMgdGhhdCBhcmUgcHJvdmlkaW5nIHRoZSBzYW1lIG5l dHdvcmsgZnVuY3Rpb24sIGkuZS4sIHZpcnR1YWxpemVkIGluc3RhbmNlcyBvZiB0aGUgc2FtZSBu ZXR3b3JrIGZ1bmN0aW9uLCBvciBkb2VzIHRoaXMgZGVmaW5pdGlvbiBhbGxvdyB0byB1c2UgVk5G IGluc3RhbmNlcyB0aGF0IGFyZSBub3QgaWRlbnRpY2FsLCBidXQgd2hlbiB0aGV5IGFyZSB1c2Vk IHRvZ2V0aGVyIHRoZXkgZm9ybSBvbmUgdmlydHVhbGl6ZWQgbmV0d29yayBmdW5jdGlvbi4NCkFu IGV4YW1wbGUgb2YgdGhlIGxhdHRlciB3aWxsIGJlIHRvIHZpcnR1YWxpc2UgYSBzZXJ2ZXIsIHdo ZXJlIHRoZSBWTkYgb2YgdGhpcyBzZXJ2ZXIgd2lsbCBiZSBjb21wb3NlZCBieSBhIHZpcnR1YWxp emVkIGluc3RhbmNlIG9mIHRoZSB1c2VkIHByb3RvY29sIHN0YWNrLCBhIHNlY29uZCB2aXJ0dWFs aXplZCBpbnN0YW5jZSBvZiB0aGUgYXBwbGljYXRpb24gcnVubmluZyBvbiB0aGUgc2VydmVyIGFu ZCBhIHRoaXJkIHZpcnR1YWxpemVkIGluc3RhbmNlIG9mIHRoZSBkYXRhIGJhc2UgdXNlZCBieSB0 aGUgc2VydmVyLiBBcmUgeW91IGNvbnNpZGVyaW5nIHRoaXMgY29tcG9zaXRpb24gb2YgdGhpcyBW TkYgYWxzbyBhIFZORiBwb29sPw0KDQpDb21tZW50XzM6IFRoZSBwcm9ibGVtIHN0YXRlbWVudCBp cyBJTUhPIG5vdCBjbGVhci4gT25lIG9mIHRoZSByZWFzb25zIG9mIHRoaXMgZmFjdCBpcyB0aGF0 IHRoZSBkZWZpbml0aW9uIG9mIHRoZSBWTkYgcG9vbCBhbmQgdGhlIFZORiBzZXQgaXMgbm90IGNs ZWFyIGVub3VnaCwgc2VlIHByZXZpb3VzIHR3byBjb21tZW50cy4gT3RoZXIgcmVhc29ucyAgYXJl IHJlbGF0ZWQgdG8gdGhlIGZhY3QgdGhhdCB0aGUgZHJhZnQgZG9lcyBub3QgY2xlYXJseSBleHBs YWluOg0Kbykgd2h5IGlzIHRoZSByZWxpYWJpbGl0eSBjaGFsbGVuZ2UgbWVudGlvbmVkIGluIHRo aXMgZHJhZnQgZGlmZmVyZW50IHRoYW4gdGhlIHJlbGlhYmlsaXR5IGNoYWxsZW5nZXMgYW5kIHRo ZWlyIHNvbHV0aW9ucyB1c2VkIGZvciB0aGUgcGh5c2ljYWwgZGV2aWNlcyB0aGF0IGFyZSBwcm92 aWRpbmcgdGhlIHNhbWUgbmV0d29yayBmdW5jdGlvbihzKSBhcyB0aGUgbWVudGlvbmVkIFZORihz KSwgaW4gdGhpcyBkcmFmdCwgYXJlIHByb3ZpZGluZy4NCm8pIHdoeSBpcyB0aGUgcmVsaWFiaWxp dHkgY2hhbGxlbmdlIHRoYXQgbmVlZHMgdG8gYmUgc29sdmVkIGJ5IHRoZSBWTkZwb29sIChmdXR1 cmUpIFdHIGNhbm5vdCBiZSBzb2x2ZWQgYnkgdGhlIGN1cnJlbnRseSBleGlzdGluZyBJRVRGIFdH cywgc3VjaCBhcyBTRkMuIFRoZSByZWFzb25zIGdpdmVuIGluIFNlY3Rpb24gNi4zIGFyZSBhIGJp dCBjb250cmFkaWN0b3J5LiBPbmUgb2YgdGhlIHJlYXNvbnMgcHJvdmlkZWQgaW4gdGhhdCBzZWN0 aW9uIGlzIGlzIHRoYXQgdGhlIHJlbGlhYmlsaXR5IG1lY2hhbmlzbXMgaW4gVk5GcG9vbCBhcmUg bW9zdGx5IGludGVybmFsIHRvIFZORiwgd2hpbGUgYW5vdGhlciByZWFzb24sIGdpdmVuIGluIHRo ZSBzYW1lIHNlY3Rpb24sICBpcyB0aGF0IHRoZSByZWxpYWJpbGl0eSBtZWNoYW5pc20gZGVhbHMg d2l0aCBhZGphY2VuY2llcyBpbiB0aGUgVk5GIHNldC4gVGhlIGxhdHRlciBzaG93cyB0aGF0IHRo ZSBtZWNoYW5pc21zIGFyZSBub3QgaW50ZXJuYWwgdG8gYSBWTkZwb29sLiBQbGVhc2UgY2xhcmlm eSENCg0KQ29tbWVudF80OiBQbGVhc2UgY2xhcmlmeSB3aGV0aGVyIHRoZSBzY29wZSBvZiB0aGUg cmVsaWFiaWxpdHkgc29sdXRpb24gaXMgb25seSBsaW1pdGVkIHdpdGhpbiBhIFZORiBwb29sLCBv ciBpcyBpdCBsaW1pdGVkIHdpdGhpbiBhIFZORiBzZXQ/IElmIHRoZSBzY29wZSBpcyBsaW1pdGVk IHRvIGEgVk5GIHNldCwgdGhlbiB3aHkgYXJlIHlvdSBlbXBoYXNpemluZyB0aGF0IHRoZSByZWxp YWJpbGl0eSBtZWNoYW5pc21zIHdpbGwgbm90IGJlIHZpc2libGUgdG8gYW4gU0ZDIGxpa2UgY29u dHJvbCBlbnRpdHksIHNpbmNlIGEgVk5GIHNldCBjb3VsZCBmb3JtIGEgc2VydmljZSBmdW5jdGlv biBjaGFpbiwgc2VlIEZpZ3VyZSAyIG9mIHRoZSBkcmFmdC4NCg0KQ29tbWVudF81OiBUaGUgZHJh ZnQgbmVlZHMgdG8gYmUgbW9yZSBjb25zaXN0ZW50IG9uIHdoZW4gdGhlIFZORiBzZXQgaXMgdXNl ZCBhbmQgd2hlbiB0aGUgVk5GIHBvb2wgaXMgdXNlZC4NCg0KQ29tbWVudF82OiBUaGVyZSBhcmUg YWxzbyBzb21lIGVkaXRvcmlhbCB3aGljaCBuZWVkIHRvIGJlIHdvcmtlZCBvdXQgaW4gYSBuZXh0 IHZlcnNpb24gb2YgdGhlIGRyYWZ0Lg0KDQpCZXN0IHJlZ2FyZHMsDQpHZW9yZ2lvcw0KDQoNCg0K DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClZhbjogdm5mcG9vbCBbdm5m cG9vbC1ib3VuY2VzQGlldGYub3JnXSBuYW1lbnMgWm9uZ25pbmcgW3pvbmduaW5nQGh1YXdlaS5j b21dDQpWZXJ6b25kZW46IGRvbmRlcmRhZyAxMCBhcHJpbCAyMDE0IDU6MjENCkFhbjogdm5mcG9v bEBpZXRmLm9yZzxtYWlsdG86dm5mcG9vbEBpZXRmLm9yZz4NCk9uZGVyd2VycDogW3ZuZnBvb2xd IE5ldyByZXZpc2lvbiBvZiBWTkZQb29sIFByb2JsZW0gU3RhdGVtZW50IHBvc3RlZA0KSGksIGZv bGtzLA0KDQpUaGUgbmV3IHJldmlzaW9uICgtMDQpIG9mIFZORlBvb2wgUHJvYmxlbSBTdGF0ZW1l bnQgSS1EIGlzIGF2YWlsYWJsZSBvbiB0aGUgYmVsb3cgcGFnZS4NCmh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXpvbmctdm5mcG9vbC1wcm9ibGVtLXN0YXRlbWVudC8NCg0K SGVyZSBhcmUgdGhlIG1ham9yIGNoYW5nZXM6DQoNCjEpICAgICAgIENsYXJpZnkgVk5GUG9vbCBh cmNoaXRlY3R1cmUgYW5kIGludGVuZGVkIHNjb3BlLg0KDQoxLiAgICAgICAgIEFkZCBuZXcgc2Vj dGlvbiBvZiBWTkYgUG9vbHMgYmVmb3JlIHRoZSBzZWN0aW9uIG9mIFByb2JsZW0uIFRoaXMgbmV3 IHNlY3Rpb24gaXMgbWFpbmx5IHRvIG91dGxpbmUgb3VyIHNjb3BlIGJhc2VkIG9uIGhpZ2ggbGV2 ZWwgZGVzY3JpcHRpb24gb2YgVk5GIFBvb2xzIGFyY2hpdGVjdHVyZS4NCg0KMi4gICAgICAgICBB ZGQgdGV4dCB0byBjbGFyaWZ5IHRoYXQgd2UgYXJlIHNwZWNpZmljYWxseSBjb25jZXJuZWQgd2l0 aCByZWxpYWJpbGl0eSAoZS5nLiByZWR1bmRhbmN5IG1vZGVsLCBzdGF0ZSBzaGFyaW5nKSB0aGF0 IGlzIG1hbmFnZWQgaW5zaWRlIHRoZSBWTkYuIFdlIGFyZSBvbmx5IGNvbmNlcm5lZCB3aXRoIHRo ZSB3aG9sZSBWTkYgc2V0IChvciBmb3J3YXJkaW5nIGdyYXBoKSB0byB0aGUgZXh0ZW50IHRoYXQg aXQgaW52b2x2ZXMgcmVsaWFiaWxpdHkgaW1wYWN0IG9uIGFkamFjZW50IGluc3RhbmNlcyBvZiBk aWZmZXJlbnQgVk5Gcy4NCg0KMy4gICAgICAgICBXZSBmb2N1cyBvbiByZWxpYWJpbGl0eSBtZWNo YW5pc21zIGJhc2VkIG9uIFZORiBwb29sLiBPdGhlciBWTkYgbWFuYWdlbWVudCBhc3BlY3RzIHN1 Y2ggYXMgc2NhbGluZywgbG9hZCBiYWxhbmNpbmcgYXJlIG91dCBvZiBzY29wZS4NCg0KMikgICAg ICAgVXBkYXRlIHRlcm1pbm9sb2dpZXMgdG8gZGVmaW5lIFNlcnZpY2UgQ29udHJvbCBFbnRpdHks IGFuZCBkZWxldGUgUG9vbCBVc2VyIGFzIHRoZSBwb29sIHdpbGwgYmUgaW50ZXJuYWwgdG8gVk5G IG9ubHkuDQoNCjMpICAgICAgIFJlLWFycmFuZ2UgdGhlIHRleHQgaW4gc2VjdGlvbiBvZiBQcm9i bGVtcy4NCg0KNCkgICAgICAgVXBkYXRlIHRleHQgb2YgVk5GIGluc3RhbmNlIHBlcmZvcm1hbmNl IGRlZ3JhZGF0aW9uIGluIHNlY3Rpb24gb2YgUHJvYmxlbXMuDQoNCjUpICAgICAgIFVwZGF0ZSB0 ZXh0IG9mIFJlbGlhYmxlIFRyYW5zcG9ydCBpbiBzZWN0aW9uIG9mIFByb2JsZW1zLg0KDQo2KSAg ICAgICBBZGQgdGV4dCB0byBleHBsYWluIHdoeSBzZXJ2aWNlIGF2YWlsYWJpbGl0eSBpcyBub3Qg aW4gc2NvcGUgaW4gc2VjdGlvbiBvZiBQcm9ibGVtcy4NCg0KNykgICAgICAgUmUtd3JpdGUgdGhl IHNlY3Rpb24gZGVzY3JpYmluZyB0aGUgcmVsYXRpb25zaGlwIG9mIFZORlBvb2wgYW5kIFNGQy4N Cg0KOCkgICAgICAgQWRkIHRleHQgb2YgdHJhbnNmZXIgb2Ygc2VjdXJpdHkgc3RhdGVzIGluIHNl Y3Rpb24gb2YgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbi4NCg0KV2UgaG9wZSB0aGF0IHRoZSBjaGFu Z2VzIGhhdmUgYWRkcmVzc2VkIG1vc3Qgb2YgdGhlIGNvbW1lbnRzLCBhbmQgcmVmbGVjdGVkIG1v c3Qgb2YgdGhlIHN1Z2dlc3Rpb25zIGR1cmluZyBMb25kb24gQm9GLg0KDQpQbGVhc2UgcmV2aWV3 IHRoaXMgbmV3IHJldmlzaW9uLiBZb3VyIGZ1cnRoZXIgY29tbWVudHMgYW5kIHN1Z2dlc3Rpb25z IGFyZSBoaWdobHkgYXBwcmVjaWF0ZWQhDQoNClRoYW5rcy4NCg0KLU5pbmcNCg== --_000_B0D29E0424F2DE47A0B36779EC66677966114FBAnkgeml501mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi, Geo= rgios,

&n= bsp;

>>= ; VNF Set: a general set of= VNF instances that can be grouped into multiple VNF pools, where each of t= hese pools provide a different network function.

&nbs= p;

[Ning]: Y= es, we will update PS draft in next revision!

&n= bsp;

>>= ; The reason of this is t= hat in this way the reliability mechanisms/protocols  that will b= e specified by this WG will be applicable to any type of VNFpool.=

&nbs= p;

[Ning]: W= e will certainly consider general mechanisms/protocols to cover more cases = and types of VNF pool. We can reflect this point in PS draft, but leave the= details of solution to next step of work, based on use cases & requirements.

&nbs= p;

>> = You mean that the the reliability mechanims/protocols specified in the VNFp= ool WG will only have an impact inside a VNFpool and sometimes on the adjac= ent VNFpools. This is also the reason that the solution scope of this WG is different than other IETF WGs, like the SCF WG.

&nbs= p;

[Ning] Ex= actly!

&nbs= p;

Thanks.

&nbs= p;

-Ning

&n= bsp;

=B7=A2=BC=FE=C8=CB: karagian@cs.utwente.nl [mailto:karagian@cs.= utwente.nl]
=B7=A2= =CB=CD=CA=B1=BC=E4: 2014=C4=EA4=D4=C223=C8=D5 14:26
=CA=D5=BC=FE=C8=CB: Zongning
=B3=AD=CB=CD: vnfpool@ietf.org
=D6=F7=CC=E2: RE: Comments on draft-zong-vnfpool-problem-statement-04=

 

Hi Ning,

 

Thanks for your answers!
Please see in line!

 

 

>

> Van: Zongning [zongning@huawei.com]
> Verzonden: dinsdag 15 april 2014 5:56
> Aan: Karagiannis, G. (EWI)
> CC: vnfpool@ietf.org > Onderwerp: =B4=F0=B8=B4: Comments on draft-zong-vnfpool-problem-statement-04

> Hi= , Georgios,

 

> Ap= preciate your comments!

 

 

> Fi= rstly, let me try to clarify the difference between VNF set and VNF pool. VNF set is just a gener= al set of all the VNF instances. In VNF Pool architecture, all these VNF in= stances are actually grouped into multiple pools, based on the functions th= ey provided. For example, a VNF set {vFW#1, vFW#2, vLB#1, vLB#2, vLB#3} can be grouped into two VNF pools =A8C= one pool is {vFW#1, vFW#2}, another is {vLB#1, vLB#2, vLB#3}. So, maybe th= e following definition is better:

 

> VNF Pool: a group of VNF i= nstances providing the same network function.

 

> VNF Set: a general set of = VNF instances that can be grouped into multiple VNF pools where different p= ools provide different functions.

 

Georgios: Okay, I understand! So you mean = that a VNF set is always composed of a group of VNF pools. Is it then possible to provide the following small modifictaion to the VNF = set definition. Please change to:

 

VNF Set: a general set of VNF instances th= at can be grouped into multiple VNF pools, where each of these pools provide a different network function.

 

 

> Comment_2 is more interesting (inde= ed! J= ) and related to VNF in= stance implementation. At this point of time, how about just limiting ourse= lves to your former case, i.e., VNF instances are identical in a pool. The latter case is actually about further decompo= sition of VNF instance to more VNF components (VNFCs). I would guess this i= s more complicated (hierarchical) pooling architecture to be studied later.=

 

Georgios: Okay, but I am in favour of the = latter case. The reason of this is that in this way the reliability me= chanisms/protocols  that will be specified by this WG will be applicable to any type of VNFpool.

 

> Comment_3 & 4 is about our scop= e. As emphasized in draft, we mostly consider the reliability (or pooling) = inside a VNF. Our scope is still intended on VNF set, but *only* to the extent that it involves reliability impact on adj= acent VNF instances in different VNF pools. The coordination traffic betwee= n VNFs dealing with reliability can be still invisible to the Service Contr= ol Entity, if these messages are directly transferred between adjacent VNF pools. Some use cases in our Use= Case I-Ds have shown the benefits of direct communication between pools. Y= ou are right in the sense that if such coordination is explicitly managed b= y the Service Control Entity, other WG(s) could be able to handle it - this will depend on more case study.

 

> Sorry, but I am not sure I fully un= derstand your first bullet in Comment_3.

 

Georgios: Okay, I understand!

You mean that the the reliability mechanim= s/protocols specified in the VNFpool WG will only have an impact inside a V= NFpool and sometimes on the adjacent VNFpools. This is also the reason that the solution scope of this WG is different th= an other IETF WGs, like the SCF WG.

 

> Comment_5 & 6: Yes, we will imp= rove as much as we could in future revision.

 

Georgios: Thank you!

 

Best regards,

Georgios

 

 

 

> Hope my reply helps a little bit. J=

 

> Please do let me know your further = questions/comments.<= /o:p>

 

> -Ning

 

=B7=A2=BC=FE= =C8=CB: karagian@cs.utwente.nl [mailto:karagian@cs.utwente.nl]
=B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA4=D4=C214= =C8=D5 18:41
=CA=D5=BC=FE=C8=CB: Zongning
=B3=AD=CB=CD: vnfpool@ietf.org
=D6=F7=CC=E2: Comments on draft-zong-vnfpool-problem-statement-04

 

Hi Ning,

 

Please note that I have read the current v= ersion of the draft.

This version clearer than the previous ver= sion of the draft, but IMHO it is still not clear enough.

 

The main comments that I have are:<= span lang=3D"EN-US" style=3D"color:black">

 

Comment_1: It is not clear what are the ma= in differences between a VNF set and a VNFpool.

From what I can assume is that the VNFpool= is a group of VNF instances that are providing the same network function and that the VNF set is a group of VNF instances, each providing = a different network function, which can be used to build network services. = Is this correct?

 

In the Terminology section you provide the= following definitions:

 

VNF Pool: a group of VNF instances providi= ng the same network<= /o:p>

function.

 

VNF Set: a group of VNF instances that can= be used to build network=

services.

 

Maybe the following definitions might prov= ide a clearer view:<= /o:p>

 

VNF Pool: a group of VNF instances providi= ng the same network<= /o:p>

function.

 

VNF Set: a group of VNF instances, each pr= oviding a different network function,

which can be used to build network service= s.

 

 

Comment_2: This comment is related to VNFp= ool and in particular what is meant by: VNF instances providing the same network function? Are you referring to identical VNF instances th= at are providing the same network function, i.e., virtualized instances of = the same network function, or does this definition allow to use VNF instanc= es that are not identical, but when they are used together they form one virtualized network function.<= span lang=3D"EN-US" style=3D"color:black">

An example of the latter will be to virtua= lise a server, where the VNF of this server will be composed by a virtualized instance of the used protocol stack, a second virtualized in= stance of the application running on the server and a third virtualized ins= tance of the data base used by the server. Are you considering this composi= tion of this VNF also a VNF pool?

 

Comment_3: The problem statement is IMHO n= ot clear. One of the reasons of this fact is that the definition of the VNF pool and the VNF set is not clear enough, see previous two comm= ents. Other reasons  are related to the fact that the draft does not c= learly explain:

o) why is the reliability challenge mentio= ned in this draft different than the reliability challenges and their solutions used for the physical devices that are providing the same = network function(s) as the mentioned VNF(s), in this draft, are providing.

o) why is the reliability challenge that n= eeds to be solved by the VNFpool (future) WG cannot be solved by the currently existing IETF WGs, such as SFC. The reasons given in Section= 6.3 are a bit contradictory. One of the reasons provided in that section i= s is that the reliability mechanisms in VNFpool are mostly internal to VNF,= while another reason, given in the same section,  is that the reliability mechanism deals with adjac= encies in the VNF set. The latter shows that the mechanisms are not interna= l to a VNFpool. Please clarify!

 

Comment_4: Please clarify whether the scop= e of the reliability solution is only limited within a VNF pool, or is it limited within a VNF set? If the scope is limited to a VNF set, t= hen why are you emphasizing that the reliability mechanisms will not be vis= ible to an SFC like control entity, since a VNF set could form a service fu= nction chain, see Figure 2 of the draft.=

 

Comment_5: The draft needs to be more cons= istent on when the VNF set is used and when the VNF pool is used.

 

Comment_6: There are also some editorial w= hich need to be worked out in a next version of the draft.

 

Best regards,

Georgios

 

 

 

 

Van: vnfpool [vnfpool-bounces@ietf.org] namens Zongning [zongning@huawei.com] Verzonden: donderdag 10 april 2014 5:21
Aan: vnfpool@i= etf.org
Onderwerp: [vnfpool] New revision of VNFPool Problem Statement poste= d

Hi, folks= ,

 

The new r= evision (-04) of VNFPool Problem Statement I-D is available on the below pa= ge.

https://datatracker.ietf.org/doc/draft-zong-vnfpool-prob= lem-statement/

 

Here are = the major changes:

1)       Clarify VNFPool architect= ure and intended scope.

1.         Add new section of VNF Po= ols before the section of Problem. This new section is mainly to outline ou= r scope based on high level description of VNF Pools architecture.

2.         Add text to clarify that = we are specifically concerned with reliability (e.g. redundancy model, stat= e sharing) that is managed inside the VNF. We are only concerned with the w= hole VNF set (or forwarding graph) to the extent that it involves reliability impact on adjacent instances of di= fferent VNFs.

3.         We focus on reliability m= echanisms based on VNF pool. Other VNF management aspects such as scaling, = load balancing are out of scope.

2)       Update terminologies to d= efine Service Control Entity, and delete Pool User as the pool will be inte= rnal to VNF only.

3)       Re-arrange the text in se= ction of Problems.

4)       Update text of VNF instan= ce performance degradation in section of Problems.

5)       Update text of Reliable T= ransport in section of Problems.

6)       Add text to explain why s= ervice availability is not in scope in section of Problems.

7)       Re-write the section desc= ribing the relationship of VNFPool and SFC.

8)       Add text of transfer of s= ecurity states in section of Security Consideration.

 

We hope t= hat the changes have addressed most of the comments, and reflected most of = the suggestions during London BoF.

 

Please re= view this new revision. Your further comments and suggestions are highly ap= preciated!

 

Thanks.

 

-Ning

--_000_B0D29E0424F2DE47A0B36779EC66677966114FBAnkgeml501mbschi_-- From nobody Thu Apr 24 02:54:46 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 437321A013C for ; Thu, 24 Apr 2014 02:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.173 X-Spam-Level: X-Spam-Status: No, score=-0.173 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 vsKxNFt8j9Cx for ; Thu, 24 Apr 2014 02:54:41 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 340A01A07F8 for ; Thu, 24 Apr 2014 02:54:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id AC29B1073A9 for ; Thu, 24 Apr 2014 11:54:34 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNghIotE7MAl for ; Thu, 24 Apr 2014 11:54:34 +0200 (CEST) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id 8E993FFCDF for ; Thu, 24 Apr 2014 11:54:29 +0200 (CEST) Received: from PALLENE.office.hd ([169.254.1.195]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Thu, 24 Apr 2014 11:54:29 +0200 From: Marco Liebsch To: "vnfpool@ietf.org" Thread-Topic: comment on draft-zong-vnfpool-problem-statement Thread-Index: Ac9fmDyzNcG0Cup+RbOtZ5jtaBTJgw== Date: Thu, 24 Apr 2014 09:54:29 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26D6987A833@PALLENE.office.hd> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.1] Content-Type: multipart/alternative; boundary="_000_69756203DDDDE64E987BC4F70B71A26D6987A833PALLENEofficehd_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/LZFQV9fwqq4gtIQKiYPzcehkTuc Subject: [vnfpool] comment on draft-zong-vnfpool-problem-statement 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, 24 Apr 2014 09:54:44 -0000 --_000_69756203DDDDE64E987BC4F70B71A26D6987A833PALLENEofficehd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ning, all, please find some more feedback to the 4th revision of the VNFPool PS draft = below. It's more about a clarification before I can send more detailed comments on the draft= . The draft clarifies about the technical scope, which I understand is limite= d to redundancy management and failover handling within a group of VNFs of the same type, the VNF set. To coordinate between functions of different pools, the draft introduces th= e Service Control Entity. Does the Service Control Entity play a role in building a single network fu= nction, e.g. a firewall, from function instances of different pools? It does not play a role if the complete firewall functionality is provided = by a single VNF of a single Pool. Is this the assumption for VNFPool? >From Fig. 1 of the draft I understand that the complete function (e.g. the = firewall), is provided by a single box above the Virtualization Platform layer. And each box seems to be a virtual= machine. This would mean that each VNFPool provides a self-contained function, e.g. = firewall, web-service, etc. There is no functional dependency between VNFs of different Pools. Is this = understanding correct? My understanding of how a virtualized network function vNF is built is that= it comprises multiple vNF Components (vNFC) of the same (for function-internal load balancing) an= d of different types. Each vNFC is instantiated in a separate virtual machine. I am still not sure how to reflect this in VNFPool: It may be details that = hide inside a VNF as e.g. depicted in Fig. 1. In such case, the function-internal architecture made from differen= t vNFCs is not visible to VNFPool. In case VNFPool is concerned with the function-internal architecture made f= rom different vNFCs, Section 3.2 may include such figure: +---------+ | VNF-C#z | | | +---------+ ^ | | | | | | v +---------+ +---------+ | VNF-A#x |<------| VNF-B#y | | |------>| | +---------+ +---------+ ^ | | | v +---------+ | Client | +---------+ Sorry that I come up with this request for clarification again. Best regards, marco --_000_69756203DDDDE64E987BC4F70B71A26D6987A833PALLENEofficehd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ning, all,

 

please find some more feedback to the 4th revisio= n of the VNFPool PS draft below. It's more
about a clarification before I can send more detailed comments on the draft= .

 

 

The draft clarifies about the technical scope, wh= ich I understand is limited to redundancy management
and failover handling within a group of VNFs of the same type, the VNF set.=
To coordinate between functions of different pools, the draft introduces th= e Service Control Entity.

Does the Service Control Entity play a role in bu= ilding a single network function, e.g. a firewall,
from function instances of different pools?

 

It does not play a role if the complete firewall = functionality is provided by a single VNF of a single Pool.

Is this the assumption for VNFPool?

 

From Fig. 1 of the draft I understand that the co= mplete function (e.g. the firewall), is provided by a single box
above the Virtualization Platform layer. And each box seems to be a virtual= machine.

This would mean that each VNFPool provides a self= -contained function, e.g. firewall, web-service, etc.

There is no functional dependency between VNFs of= different Pools. Is this understanding correct?

 

My understanding of how a virtualized network fun= ction vNF is built is that it comprises multiple

vNF Components (vNFC) of the same (for function-i= nternal load balancing) and of different types.

Each vNFC is instantiated in a separate virtual m= achine.

I am still not sure how to reflect this in VNFPoo= l: It may be details that hide inside a VNF as e.g. depicted in
Fig. 1. In such case, the function-internal architecture made from differen= t vNFCs is not visible to VNFPool.

 

In case VNFPool is concerned with the function-in= ternal architecture made from different vNFCs, Section 3.2
may include such figure:  

 

 

            =       +---------+

            =       | VNF-C#z |

            =       |       &= nbsp; |

            =       +---------+

            =           ^ |

            =           | |  

            =           | |<= /span>

            =           | v

+---------+       +---------&#= 43;

| VNF-A#x |<------| VNF-B#y |

|         |------>| &nbs= p;       |

+---------+       +---------&#= 43;

            =            ^

            =            |

            =            |

            =            |

            =            v

            =       +---------+

            =       | Client  |

            =       +---------+

 

 

Sorry that I come up with this request for clarif= ication again.

 

Best regards,

marco

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

--_000_69756203DDDDE64E987BC4F70B71A26D6987A833PALLENEofficehd_-- From nobody Thu Apr 24 05:15:56 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 3FB6D1A01AC for ; Thu, 24 Apr 2014 05:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 8om9QBrEtzyx for ; Thu, 24 Apr 2014 05:15:50 -0700 (PDT) Received: from mail-ee0-f51.google.com (mail-ee0-f51.google.com [74.125.83.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8EA8D1A0188 for ; Thu, 24 Apr 2014 05:15:50 -0700 (PDT) Received: by mail-ee0-f51.google.com with SMTP id c13so1778032eek.24 for ; Thu, 24 Apr 2014 05:15:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:user-agent :mime-version:content-type; bh=tXdDsU7CzQID3pm2Vb9LvxqASjlbyLikwj5wAZFL+D8=; b=NUtwx8Zt5uywzbQo6aPW0RPepx5FLR9SYap+j8u4RPULALd3gFzw8JseP6L4bpkENh PaPBFD1LLGYO13bt4VrHv1ZVbwh4/3PZ9cgdS6G4QfEDAqd4f8Z6kjfng5PL8fBmNWSk whQls/Vc7Bp5an8ydR9xaXTmprNceRkzZDUKzDj+nUldsIrjSf8DhuVn7mHvPon/DyBV iSgJ8TLaY/QMIY+iw4GRGFNDfJdHRuRDs15tUqiheI6nLMEJUMruJWR554YzPZtG5CbJ WgHVhZonmapv91V1T9Q8vYQP5vieCHR5fjo3uu2BKU2RA3BMFDi29XRmcV2RQkq1nH9e hg9A== X-Gm-Message-State: ALoCoQmxJDqs2YpQXBEF10ihEqt5B5oXMvQ4B78I9qTM5vqa+vefeJwi/Qq0FAUrUE6cnHorYjil X-Received: by 10.14.110.199 with SMTP id u47mr2063071eeg.74.1398341743538; Thu, 24 Apr 2014 05:15:43 -0700 (PDT) Received: from lupo.localnet ([128.65.70.134]) by mx.google.com with ESMTPSA id 48sm15282869eei.24.2014.04.24.05.15.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Apr 2014 05:15:42 -0700 (PDT) From: Thomas Dreibholz To: "vnfpool@ietf.org" Date: Thu, 24 Apr 2014 14:15:31 +0200 Message-ID: <2050178.iiQ32B9cLA@lupo> User-Agent: KMail/4.13 (Linux/3.13.0-24-generic; KDE/4.13.0; x86_64; ; ) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart7743349.rfnqzdppEx"; micalg="pgp-sha1"; protocol="application/pgp-signature" Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/R4vT8UBn0iGyx41QtNNi5luVslg Subject: [vnfpool] Update of I-D draft-dreibholz-vnfpool-rserpool-applic 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, 24 Apr 2014 12:15:53 -0000 --nextPart7743349.rfnqzdppEx Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Hi all, the I-D draft-dreibholz-vnfpool-rserpool-applic has been updated to ver= sion 01. Please find the new version here: https://tools.ietf.org/id/dr= aft-dreibholz-vnfpool-rserpool-applic-01.txt . Comments are welcome! =2D-=20 Best regards / Mit freundlichen Gr=FC=DFen / Med vennlig hilsen =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Thomas Dreibholz Simula Research Laboratory Simula Innovation AS, Network Systems Group Visiting address: Martin Linges vei 17, 1364 Fornebu, Norway Mailing address: P.O.Box 134, 1325 Lysaker, Norway =2D----------------------------------------------------------------------= E-Mail: dreibh@simula.no Homepage: http://simula.no/people/dreibh =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --nextPart7743349.rfnqzdppEx 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) iEYEABECAAYFAlNZAGMACgkQ32BbsHYPLWXFhACgz2+zY/57jQ2U+nJ7OA6KUEH5 /CkAoMFadTASZ85PXVOggiWDgXiZnIXv =aQpn -----END PGP SIGNATURE----- --nextPart7743349.rfnqzdppEx-- From nobody Thu Apr 24 23:31:37 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 B8C8D1A0458 for ; Thu, 24 Apr 2014 23:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.522 X-Spam-Level: X-Spam-Status: No, score=-98.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 k6S86b0JpgAV for ; Thu, 24 Apr 2014 23:31:27 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8C0B01A0441 for ; Thu, 24 Apr 2014 23:31:26 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDM05683; Fri, 25 Apr 2014 06:31:19 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 25 Apr 2014 07:30:18 +0100 Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 25 Apr 2014 07:31:18 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.85]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Fri, 25 Apr 2014 14:31:12 +0800 From: Zongning To: Marco Liebsch , "vnfpool@ietf.org" Thread-Topic: comment on draft-zong-vnfpool-problem-statement Thread-Index: Ac9fmDyzNcG0Cup+RbOtZ5jtaBTJgwAoStnw Date: Fri, 25 Apr 2014 06:31:12 +0000 Message-ID: References: <69756203DDDDE64E987BC4F70B71A26D6987A833@PALLENE.office.hd> In-Reply-To: <69756203DDDDE64E987BC4F70B71A26D6987A833@PALLENE.office.hd> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.22] Content-Type: multipart/alternative; boundary="_000_B0D29E0424F2DE47A0B36779EC66677966115363nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/1IMCZzjFa8gh6qgaXFifPeFnk58 Subject: [vnfpool] =?gb2312?b?tPC4tDogY29tbWVudCBvbiBkcmFmdC16b25nLXZuZnBv?= =?gb2312?b?b2wtcHJvYmxlbS1zdGF0ZW1lbnQ=?= 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: Fri, 25 Apr 2014 06:31:31 -0000 --_000_B0D29E0424F2DE47A0B36779EC66677966115363nkgeml501mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIE1hcmNvLA0KDQpQbGVhc2Ugc2VlIGlubGluZSBteSByZXBseS4NCkNvbnNpZGVyaW5nIHRo ZSBsaXN0IGZlZWRiYWNrLCBJIHdpbGwgdXBkYXRlIDR0aCB2ZXJzaW9uIHRvIDV0aCB2ZXJzaW9u ICh3aXRoIHRyaXZpYWwgY2hhbmdlcykgYnkgZWFybHkgbmV4dCB3ZWVrLCB0byBtYWtlIG91ciBz Y29wZSBtb3JlIGNsZWFyLg0KDQoNCg0KSGkgTmluZywgYWxsLA0KDQoNCg0KcGxlYXNlIGZpbmQg c29tZSBtb3JlIGZlZWRiYWNrIHRvIHRoZSA0dGggcmV2aXNpb24gb2YgdGhlIFZORlBvb2wgUFMg ZHJhZnQgYmVsb3cuIEl0J3MgbW9yZQ0KYWJvdXQgYSBjbGFyaWZpY2F0aW9uIGJlZm9yZSBJIGNh biBzZW5kIG1vcmUgZGV0YWlsZWQgY29tbWVudHMgb24gdGhlIGRyYWZ0Lg0KDQoNCg0KDQoNClRo ZSBkcmFmdCBjbGFyaWZpZXMgYWJvdXQgdGhlIHRlY2huaWNhbCBzY29wZSwgd2hpY2ggSSB1bmRl cnN0YW5kIGlzIGxpbWl0ZWQgdG8gcmVkdW5kYW5jeSBtYW5hZ2VtZW50DQphbmQgZmFpbG92ZXIg aGFuZGxpbmcgd2l0aGluIGEgZ3JvdXAgb2YgVk5GcyBvZiB0aGUgc2FtZSB0eXBlLCB0aGUgVk5G IHNldC4NCg0KDQoNCltOaW5nXSBZZXMsIG91ciBjdXJyZW50IHNjb3BlIGlzIGludGVuZGVkIHRv IGEgVk5GIHBvb2wgaW5jbHVkaW5nIGdyb3VwIG9mIFZORiBpbnN0YW5jZXMgb2YgdGhlIHNhbWUg dHlwZS4gVk5GIHNldCBpcyB0aGUgb3ZlcmFsbCBzZXQgb2YgVk5GIGluc3RhbmNlcyB0aGF0IGNh biBiZSBncm91cGVkIGludG8gbXVsdGlwbGUgVk5GIHBvb2xzLCB3aXRoIGVhY2ggVk5GIHBvb2wg cHJvdmlkaW5nIGEgZGlmZmVyZW50IG5ldHdvcmsgZnVuY3Rpb24uIEFub3RoZXIgd29yZCwgb3Vy IHNjb3BlIGlzIG1haW5seSBhIHBhcnQgb2YgVk5GIHNldCAoYSBWTkYgcG9vbCksIG5vdCB0aGUg d2hvbGUgVk5GIHNldC4NCg0KDQoNClRvIGNvb3JkaW5hdGUgYmV0d2VlbiBmdW5jdGlvbnMgb2Yg ZGlmZmVyZW50IHBvb2xzLCB0aGUgZHJhZnQgaW50cm9kdWNlcyB0aGUgU2VydmljZSBDb250cm9s IEVudGl0eS4NCg0KW05pbmddIENvcnJlY3QuDQoNCkRvZXMgdGhlIFNlcnZpY2UgQ29udHJvbCBF bnRpdHkgcGxheSBhIHJvbGUgaW4gYnVpbGRpbmcgYSBzaW5nbGUgbmV0d29yayBmdW5jdGlvbiwg ZS5nLiBhIGZpcmV3YWxsLA0KZnJvbSBmdW5jdGlvbiBpbnN0YW5jZXMgb2YgZGlmZmVyZW50IHBv b2xzPw0KDQoNCg0KW05pbmddIFdlIGFzc3VtZSB0aGF0IFNlcnZpY2UgQ29udHJvbCBFbnRpdHkg YnVpbGRzIGEgbmV0d29yayBzZXJ2aWNlIGNvbXBvc2VkIG9mIGRpZmZlcmVudCBuZXR3b3JrIGZ1 bmN0aW9ucyAoZS5nLiBmaXJld2FsbCwgRFBJLCBsb2FkIGJhbGFuY2VyKSBwcm92aWRlZCBieSBk aWZmZXJlbnQgcG9vbHMuIFNvLCBlYWNoIFZORiBwb29sIHByb3ZpZGVzIGRpZmZlcmVudCBuZXR3 b3JrIGZ1bmN0aW9uLiBOb3RlIHRoYXQgdGhpcyBhc3N1bXB0aW9uIGlzIG1haW5seSB0byBkcml2 ZSBnZW5lcmFsIHBvb2xpbmcgYXJjaGl0ZWN0dXJlIGFuZCBjaGFydGVyIHNjb3BlLiBXZSB3aWxs IGNvbnNpZGVyIGdlbmVyYWwgc29sdXRpb24gYnkgcmVsZWFzaW5nIHN1Y2ggYXNzdW1wdGlvbiBp ZiB3ZSBpZGVudGlmeSByZWFzb25hYmxlIHVzZSBjYXNlcy4gRm9yIGV4YW1wbGUsIHdlIG1heSBj b25zaWRlciBzb2x1dGlvbiB0aGF0IGNvdmVycyB0aGUgY2FzZSB0aGF0IGEgcG9vbCBjYW4gYWxz byBwcm92aWRlIFZORkNzoa0NCg0KDQoNCkl0IGRvZXMgbm90IHBsYXkgYSByb2xlIGlmIHRoZSBj b21wbGV0ZSBmaXJld2FsbCBmdW5jdGlvbmFsaXR5IGlzIHByb3ZpZGVkIGJ5IGEgc2luZ2xlIFZO RiBvZiBhIHNpbmdsZSBQb29sLg0KDQpJcyB0aGlzIHRoZSBhc3N1bXB0aW9uIGZvciBWTkZQb29s Pw0KDQoNCg0KW05pbmddIFBsZWFzZSBzZWUgYWJvdmUuDQoNCg0KDQpGcm9tIEZpZy4gMSBvZiB0 aGUgZHJhZnQgSSB1bmRlcnN0YW5kIHRoYXQgdGhlIGNvbXBsZXRlIGZ1bmN0aW9uIChlLmcuIHRo ZSBmaXJld2FsbCksIGlzIHByb3ZpZGVkIGJ5IGEgc2luZ2xlIGJveA0KYWJvdmUgdGhlIFZpcnR1 YWxpemF0aW9uIFBsYXRmb3JtIGxheWVyLiBBbmQgZWFjaCBib3ggc2VlbXMgdG8gYmUgYSB2aXJ0 dWFsIG1hY2hpbmUuDQoNCg0KDQpbTmluZ10gT25lIG9yIG1vcmUgVk5GIGluc3RhbmNlcyBjb3Vs ZCBiZSBob3N0ZWQgYnkgYSBzaW5nbGUgVk0uIFNvIHRoZSBib3ggaW4gRmlnLjEgaXMgbm90IG5l Y2Vzc2FyaWx5IGEgVk0sIGFsdGhvdWdoIGl0IGxpa2VseSB0byBiZSB0cnVlIGluIHByYWN0aWNl Lg0KDQoNCg0KVGhpcyB3b3VsZCBtZWFuIHRoYXQgZWFjaCBWTkZQb29sIHByb3ZpZGVzIGEgc2Vs Zi1jb250YWluZWQgZnVuY3Rpb24sIGUuZy4gZmlyZXdhbGwsIHdlYi1zZXJ2aWNlLCBldGMuDQoN ClRoZXJlIGlzIG5vIGZ1bmN0aW9uYWwgZGVwZW5kZW5jeSBiZXR3ZWVuIFZORnMgb2YgZGlmZmVy ZW50IFBvb2xzLiBJcyB0aGlzIHVuZGVyc3RhbmRpbmcgY29ycmVjdD8NCg0KDQoNCltOaW5nXSBJ dCBpcyBjb3JyZWN0IGFueXdheSB0aGF0IHRoZXJlIGlzIG5vIGZ1bmN0aW9uYWwgZGVwZW5kZW5j eSBiZXR3ZWVuIFZORnMgb2YgZGlmZmVyZW50IHBvb2xzLg0KDQoNCg0KTXkgdW5kZXJzdGFuZGlu ZyBvZiBob3cgYSB2aXJ0dWFsaXplZCBuZXR3b3JrIGZ1bmN0aW9uIHZORiBpcyBidWlsdCBpcyB0 aGF0IGl0IGNvbXByaXNlcyBtdWx0aXBsZQ0KDQp2TkYgQ29tcG9uZW50cyAodk5GQykgb2YgdGhl IHNhbWUgKGZvciBmdW5jdGlvbi1pbnRlcm5hbCBsb2FkIGJhbGFuY2luZykgYW5kIG9mIGRpZmZl cmVudCB0eXBlcy4NCg0KRWFjaCB2TkZDIGlzIGluc3RhbnRpYXRlZCBpbiBhIHNlcGFyYXRlIHZp cnR1YWwgbWFjaGluZS4NCg0KDQoNCltOaW5nXSBZZXMsIEkgYWdyZWUgd2l0aCB5b3VyIHZpZXcg b24gaG93IGEgVk5GIGlzIGJ1aWx0LiBBcyBzYWlkLCB3ZSBjdXJyZW50bHkgYXNzdW1lIHRoYXQg YSBWTkYgcG9vbCBjb250YWlucyBhIG51bWJlciBvZiBWTkYgaW5zdGFuY2VzIG9mIHNhbWUgZnVu Y3Rpb25hbCB0eXBlIChlLmcuIGZpcmV3YWxsKS4gV2UgZGVzY3JpYmUgZ2VuZXJhbCBwb29saW5n IGFyY2hpdGVjdHVyZSBhbmQgc2NvcGUgb3VyIHdvcmsgYmFzZWQgb24gdGhpcyBhc3N1bXB0aW9u Lg0KDQoNCg0KSSBhbSBzdGlsbCBub3Qgc3VyZSBob3cgdG8gcmVmbGVjdCB0aGlzIGluIFZORlBv b2w6IEl0IG1heSBiZSBkZXRhaWxzIHRoYXQgaGlkZSBpbnNpZGUgYSBWTkYgYXMgZS5nLiBkZXBp Y3RlZCBpbg0KRmlnLiAxLiBJbiBzdWNoIGNhc2UsIHRoZSBmdW5jdGlvbi1pbnRlcm5hbCBhcmNo aXRlY3R1cmUgbWFkZSBmcm9tIGRpZmZlcmVudCB2TkZDcyBpcyBub3QgdmlzaWJsZSB0byBWTkZQ b29sLg0KDQoNCg0KW05pbmddIFlvdSBhcmUgcmlnaHQgdGhhdCB0aGUgVk5GLWludGVybmFsIGFy Y2hpdGVjdHVyZSBhYm91dCBkaWZmZXJlbnQgVk5GQ3MgaXMgY3VycmVudGx5IGhpZGRlbiBpbnNp ZGUgYSBWTkYuIFdlIGNob29zZSB0byBzdGFydCBmcm9tIGEgc2luZ2xlIGxldmVsIChWTkYgbGV2 ZWwpLCByYXRoZXIgdGhhbiBhIGhpZXJhcmNoaWNhbCBsZXZlbCBpbmNsdWRpbmcgYm90aCBWTkYg YW5kIFZORkNzIGluc2lkZSBWTkYuIFdlIHdpbGwgZGV2ZWxvcCBnZW5lcmFsIHNvbHV0aW9uIHRv IGNvdmVyIGJvdGggYXMgbmV4dCBzdGVwIG9mIHdvcmssIGJhc2VkIG9uIGZ1cnRoZXIgdXNlIGNh c2Ugc3R1ZHkuIEkgaG9wZSB0aGlzIGlzIHJlYXNvbmFibGUuIDopDQoNCg0KDQoNCg0KDQoNCkkg aG9wZSBteSByZXBseSBoZWxwcyENCg0KDQoNClRoYW5rcy4NCg0KDQoNCi1OaW5nDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQo= --_000_B0D29E0424F2DE47A0B36779EC66677966115363nkgeml501mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi, Marco,

 

Please see inline my reply.

Considering the list feedback, I will update 4th versi= on to 5th version (with trivial changes) by early next week, to = make our scope more clear.

 

 

Hi Ning, all,

 

please find some more feedba= ck to the 4th revision of the VNFPool PS draft below. It's more
about a clarification before I can send more detailed comments on the draft= .

 

 

The draft clarifies about the technical scope, which I understand is lim= ited to redundancy management
and failover handling within a group of VNFs of the same type, the VNF set.=

 

[Ning] Yes, our current scope i= s intended to a VNF pool including group of VNF instances of the same type.= VNF set is the overall set of VNF instances that can be grouped into multiple VNF pools, with each VNF pool providing = a different network function. Another word, our scope is mainly a part= of VNF set (a VNF pool), not the whole VNF set.

 

To coordinate between functions of different pools, the draft introduces= the Service Control Entity.

[Ning] Correct.

Does the Service Control Ent= ity play a role in building a single network function, e.g. a firewall,
from function instances of different pools?

 

[Nin= g] We assume that Service Control Entity builds a network service composed = of different network functions (e.g. firewall, DPI, load balancer) provided= by different pools. So, each VNF pool provides different network function. Note that this assumption is mainly t= o drive general pooling architecture and charter scope. We will consider ge= neral solution by releasing such assumption if we identify reasonable use c= ases. For example, we may consider solution that covers the case that a pool can also provide VNFCs=A1=AD

 

It does not play a role if t= he complete firewall functionality is provided by a single VNF of a single = Pool.

Is this the assumption for V= NFPool?

 

[Nin= g] Please see above.

 

From Fig. 1 of the draft I u= nderstand that the complete function (e.g. the firewall), is provided by a = single box
above the Virtualization Platform layer. And each box seems to be a virtual= machine.

 

[Nin= g] One or more VNF instances could be hosted by a single VM. So the box in = Fig.1 is not necessarily a VM, although it likely to be true in practice.

 

This would mean that each VN= FPool provides a self-contained function, e.g. firewall, web-service, etc.<= o:p>

There is no functional depen= dency between VNFs of different Pools. Is this understanding correct?<= /o:p>

 

[Nin= g] It is correct anyway that there is no functional dependency between VNFs= of different pools.

 

My understanding of how a vi= rtualized network function vNF is built is that it comprises multiple<= /o:p>

vNF Components (vNFC) of the= same (for function-internal load balancing) and of different types.

Each vNFC is instantiated in= a separate virtual machine.

 

[Nin= g] Yes, I agree with your view on how a VNF is built. As said, we currently= assume that a VNF pool contains a number of VNF instances of same function= al type (e.g. firewall). We describe general pooling architecture and scope our work based on this assumption.

 

I am still not sure how to r= eflect this in VNFPool: It may be details that hide inside a VNF as e.g. de= picted in
Fig. 1. In such case, the function-internal architecture made from differen= t vNFCs is not visible to VNFPool.

 

[Nin= g] You are right that the VNF-internal architecture about different VNFCs i= s currently hidden inside a VNF. We choose to start from a single level (VN= F level), rather than a hierarchical level including both VNF and VNFCs inside VNF. We will develop general solution = to cover both as next step of work, based on further use case study. I hope= this is reasonable. J=

 

 

 

I ho= pe my reply helps!

 

Thanks.

 

-Ning

 

 

 

 

 

 

 

 

 

 

 

 

--_000_B0D29E0424F2DE47A0B36779EC66677966115363nkgeml501mbschi_-- From nobody Mon Apr 28 02:22:28 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 B7A0C1A0998 for ; Mon, 28 Apr 2014 02:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.097 X-Spam-Level: * X-Spam-Status: No, score=1.097 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 0cMiICF8xahE for ; Mon, 28 Apr 2014 02:22:23 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id CC1881A0762 for ; Mon, 28 Apr 2014 02:22:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id AA4B3107420; Mon, 28 Apr 2014 11:22:21 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W+7c8GgI-uhz; Mon, 28 Apr 2014 11:22:21 +0200 (CEST) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id 85DDE10713F; Mon, 28 Apr 2014 11:22:11 +0200 (CEST) Received: from PALLENE.office.hd ([169.254.1.195]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Mon, 28 Apr 2014 11:22:11 +0200 From: Marco Liebsch To: Zongning , "vnfpool@ietf.org" Thread-Topic: comment on draft-zong-vnfpool-problem-statement Thread-Index: Ac9fmDyzNcG0Cup+RbOtZ5jtaBTJgwAoStnwAKIJILA= Date: Mon, 28 Apr 2014 09:22:10 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26D6987EA5A@PALLENE.office.hd> References: <69756203DDDDE64E987BC4F70B71A26D6987A833@PALLENE.office.hd> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.1] Content-Type: multipart/alternative; boundary="_000_69756203DDDDE64E987BC4F70B71A26D6987EA5APALLENEofficehd_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/PhC6IET-qAZhEcMPF6InY4z47y4 Subject: Re: [vnfpool] comment on draft-zong-vnfpool-problem-statement 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: Mon, 28 Apr 2014 09:22:26 -0000 --_000_69756203DDDDE64E987BC4F70B71A26D6987EA5APALLENEofficehd_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgTmluZywNCg0KdGhhbmtzIGEgbG90IGZvciB5b3VyIGZhc3QgcmVzcG9uc2UuIFBsZWFzZSBz ZWUgaW5saW5lLg0KDQpGcm9tOiBab25nbmluZyBbbWFpbHRvOnpvbmduaW5nQGh1YXdlaS5jb21d DQpTZW50OiBGcmVpdGFnLCAyNS4gQXByaWwgMjAxNCAwODozMQ0KVG86IE1hcmNvIExpZWJzY2g7 IHZuZnBvb2xAaWV0Zi5vcmcNClN1YmplY3Q6ILTwuLQ6IGNvbW1lbnQgb24gZHJhZnQtem9uZy12 bmZwb29sLXByb2JsZW0tc3RhdGVtZW50DQoNCkhpLCBNYXJjbywNCg0KUGxlYXNlIHNlZSBpbmxp bmUgbXkgcmVwbHkuDQpDb25zaWRlcmluZyB0aGUgbGlzdCBmZWVkYmFjaywgSSB3aWxsIHVwZGF0 ZSA0dGggdmVyc2lvbiB0byA1dGggdmVyc2lvbiAod2l0aCB0cml2aWFsIGNoYW5nZXMpIGJ5IGVh cmx5IG5leHQgd2VlaywgdG8gbWFrZSBvdXIgc2NvcGUgbW9yZSBjbGVhci4NCg0KDQoNCkhpIE5p bmcsIGFsbCwNCg0KDQoNCnBsZWFzZSBmaW5kIHNvbWUgbW9yZSBmZWVkYmFjayB0byB0aGUgNHRo IHJldmlzaW9uIG9mIHRoZSBWTkZQb29sIFBTIGRyYWZ0IGJlbG93LiBJdCdzIG1vcmUNCmFib3V0 IGEgY2xhcmlmaWNhdGlvbiBiZWZvcmUgSSBjYW4gc2VuZCBtb3JlIGRldGFpbGVkIGNvbW1lbnRz IG9uIHRoZSBkcmFmdC4NCg0KDQoNCg0KDQpUaGUgZHJhZnQgY2xhcmlmaWVzIGFib3V0IHRoZSB0 ZWNobmljYWwgc2NvcGUsIHdoaWNoIEkgdW5kZXJzdGFuZCBpcyBsaW1pdGVkIHRvIHJlZHVuZGFu Y3kgbWFuYWdlbWVudA0KYW5kIGZhaWxvdmVyIGhhbmRsaW5nIHdpdGhpbiBhIGdyb3VwIG9mIFZO RnMgb2YgdGhlIHNhbWUgdHlwZSwgdGhlIFZORiBzZXQuDQoNCg0KDQpbTmluZ10gWWVzLCBvdXIg Y3VycmVudCBzY29wZSBpcyBpbnRlbmRlZCB0byBhIFZORiBwb29sIGluY2x1ZGluZyBncm91cCBv ZiBWTkYgaW5zdGFuY2VzIG9mIHRoZSBzYW1lIHR5cGUuIFZORiBzZXQgaXMgdGhlIG92ZXJhbGwg c2V0IG9mIFZORiBpbnN0YW5jZXMgdGhhdCBjYW4gYmUgZ3JvdXBlZCBpbnRvIG11bHRpcGxlIFZO RiBwb29scywgd2l0aCBlYWNoIFZORiBwb29sIHByb3ZpZGluZyBhIGRpZmZlcmVudCBuZXR3b3Jr IGZ1bmN0aW9uLiBBbm90aGVyIHdvcmQsIG91ciBzY29wZSBpcyBtYWlubHkgYSBwYXJ0IG9mIFZO RiBzZXQgKGEgVk5GIHBvb2wpLCBub3QgdGhlIHdob2xlIFZORiBzZXQuDQoNCg0KDQpUbyBjb29y ZGluYXRlIGJldHdlZW4gZnVuY3Rpb25zIG9mIGRpZmZlcmVudCBwb29scywgdGhlIGRyYWZ0IGlu dHJvZHVjZXMgdGhlIFNlcnZpY2UgQ29udHJvbCBFbnRpdHkuDQoNCltOaW5nXSBDb3JyZWN0Lg0K DQpEb2VzIHRoZSBTZXJ2aWNlIENvbnRyb2wgRW50aXR5IHBsYXkgYSByb2xlIGluIGJ1aWxkaW5n IGEgc2luZ2xlIG5ldHdvcmsgZnVuY3Rpb24sIGUuZy4gYSBmaXJld2FsbCwNCmZyb20gZnVuY3Rp b24gaW5zdGFuY2VzIG9mIGRpZmZlcmVudCBwb29scz8NCg0KDQoNCltOaW5nXSBXZSBhc3N1bWUg dGhhdCBTZXJ2aWNlIENvbnRyb2wgRW50aXR5IGJ1aWxkcyBhIG5ldHdvcmsgc2VydmljZSBjb21w b3NlZCBvZiBkaWZmZXJlbnQgbmV0d29yayBmdW5jdGlvbnMgKGUuZy4gZmlyZXdhbGwsIERQSSwg bG9hZCBiYWxhbmNlcikgcHJvdmlkZWQgYnkgZGlmZmVyZW50IHBvb2xzLiBTbywgZWFjaCBWTkYg cG9vbCBwcm92aWRlcyBkaWZmZXJlbnQgbmV0d29yayBmdW5jdGlvbi4gTm90ZSB0aGF0IHRoaXMg YXNzdW1wdGlvbiBpcyBtYWlubHkgdG8gZHJpdmUgZ2VuZXJhbCBwb29saW5nIGFyY2hpdGVjdHVy ZSBhbmQgY2hhcnRlciBzY29wZS4gV2Ugd2lsbCBjb25zaWRlciBnZW5lcmFsIHNvbHV0aW9uIGJ5 IHJlbGVhc2luZyBzdWNoIGFzc3VtcHRpb24gaWYgd2UgaWRlbnRpZnkgcmVhc29uYWJsZSB1c2Ug Y2FzZXMuIEZvciBleGFtcGxlLCB3ZSBtYXkgY29uc2lkZXIgc29sdXRpb24gdGhhdCBjb3ZlcnMg dGhlIGNhc2UgdGhhdCBhIHBvb2wgY2FuIGFsc28gcHJvdmlkZSBWTkZDc6GtDQoNCg0KDQpbbWFy Y29dIEkgdW5kZXJzdGFuZCBhbmQgYWdyZWUgdGhhdCBpdKGvcyBhIGdvb2QgYXBwcm9hY2ggdG8g c3RhcnQgd2l0aCBhIGxpbWl0ZWQgc2NvcGUgYW5kIGNvbnNpZGVyDQpWTkZQb29sIHRvIG9wZXJh dGUgc29sZWx5IGluc2lkZSBhIHBvb2wuIEJ1dCBJIGhhdmUgZGlmZmljdWx0aWVzIGluIHNlZWlu ZyBob3cgdGhlIGdlbmVyYWwgc29sdXRpb24NCmNhbiBiZSBicm9hZGVuZWQgYW5kIGFzc29jaWF0 ZWQgYXNzdW1wdGlvbnMgYXJlIHJlbGVhc2VkLCBhcyB5b3Ugd3JpdGUsIHRvIHN1cHBvcnQgYSBk ZXBsb3ltZW50LCB3aGljaA0KYnVpbGRzIGEgc2luZ2xlIGZ1bmN0aW9uIGZyb20gaW5zdGFuY2Vz IG9mIG11bHRpcGxlIHBvb2xzLiBUaGVyZSBhcmUgYXNzb2NpYXRlZCB1c2UgY2FzZXMsIGUuZy4g dGhlIEVQQyB2aXJ0dWFsaXphdGlvbi4NCg0KDQoNCg0KDQpJdCBkb2VzIG5vdCBwbGF5IGEgcm9s ZSBpZiB0aGUgY29tcGxldGUgZmlyZXdhbGwgZnVuY3Rpb25hbGl0eSBpcyBwcm92aWRlZCBieSBh IHNpbmdsZSBWTkYgb2YgYSBzaW5nbGUgUG9vbC4NCg0KSXMgdGhpcyB0aGUgYXNzdW1wdGlvbiBm b3IgVk5GUG9vbD8NCg0KDQoNCltOaW5nXSBQbGVhc2Ugc2VlIGFib3ZlLg0KDQoNCg0KW21hcmNv XSBTbywgSSBjb25jbHVkZSBmcm9tIGFib3ZlIGRlc2NyaXB0aW9uIGlzIGRvZXMgbm90LCBzaW5j ZSBpdCBvcmNoZXN0cmF0ZXMgbWFpbmx5IHN0YW5kYWxvbmUgZnVuY3Rpb25zDQpmcm9tIG11bHRp cGxlIHBvb2xzIGFuZCBidWlsZHMgYSBzZXJ2aWNlIHBhY2thZ2UgZnJvbSB0aGVzZSBmdW5jdGlv bnMuDQoNCg0KDQpGcm9tIEZpZy4gMSBvZiB0aGUgZHJhZnQgSSB1bmRlcnN0YW5kIHRoYXQgdGhl IGNvbXBsZXRlIGZ1bmN0aW9uIChlLmcuIHRoZSBmaXJld2FsbCksIGlzIHByb3ZpZGVkIGJ5IGEg c2luZ2xlIGJveA0KYWJvdmUgdGhlIFZpcnR1YWxpemF0aW9uIFBsYXRmb3JtIGxheWVyLiBBbmQg ZWFjaCBib3ggc2VlbXMgdG8gYmUgYSB2aXJ0dWFsIG1hY2hpbmUuDQoNCg0KDQpbTmluZ10gT25l IG9yIG1vcmUgVk5GIGluc3RhbmNlcyBjb3VsZCBiZSBob3N0ZWQgYnkgYSBzaW5nbGUgVk0uIFNv IHRoZSBib3ggaW4gRmlnLjEgaXMgbm90IG5lY2Vzc2FyaWx5IGEgVk0sIGFsdGhvdWdoIGl0IGxp a2VseSB0byBiZSB0cnVlIGluIHByYWN0aWNlLg0KDQoNCg0KVGhpcyB3b3VsZCBtZWFuIHRoYXQg ZWFjaCBWTkZQb29sIHByb3ZpZGVzIGEgc2VsZi1jb250YWluZWQgZnVuY3Rpb24sIGUuZy4gZmly ZXdhbGwsIHdlYi1zZXJ2aWNlLCBldGMuDQoNClRoZXJlIGlzIG5vIGZ1bmN0aW9uYWwgZGVwZW5k ZW5jeSBiZXR3ZWVuIFZORnMgb2YgZGlmZmVyZW50IFBvb2xzLiBJcyB0aGlzIHVuZGVyc3RhbmRp bmcgY29ycmVjdD8NCg0KDQoNCltOaW5nXSBJdCBpcyBjb3JyZWN0IGFueXdheSB0aGF0IHRoZXJl IGlzIG5vIGZ1bmN0aW9uYWwgZGVwZW5kZW5jeSBiZXR3ZWVuIFZORnMgb2YgZGlmZmVyZW50IHBv b2xzLg0KDQoNCg0KW21hcmNvXSBvaywgdW5kZXJzdG9vZC4NCg0KDQoNCk15IHVuZGVyc3RhbmRp bmcgb2YgaG93IGEgdmlydHVhbGl6ZWQgbmV0d29yayBmdW5jdGlvbiB2TkYgaXMgYnVpbHQgaXMg dGhhdCBpdCBjb21wcmlzZXMgbXVsdGlwbGUNCg0Kdk5GIENvbXBvbmVudHMgKHZORkMpIG9mIHRo ZSBzYW1lIChmb3IgZnVuY3Rpb24taW50ZXJuYWwgbG9hZCBiYWxhbmNpbmcpIGFuZCBvZiBkaWZm ZXJlbnQgdHlwZXMuDQoNCkVhY2ggdk5GQyBpcyBpbnN0YW50aWF0ZWQgaW4gYSBzZXBhcmF0ZSB2 aXJ0dWFsIG1hY2hpbmUuDQoNCg0KDQpbTmluZ10gWWVzLCBJIGFncmVlIHdpdGggeW91ciB2aWV3 IG9uIGhvdyBhIFZORiBpcyBidWlsdC4gQXMgc2FpZCwgd2UgY3VycmVudGx5IGFzc3VtZSB0aGF0 IGEgVk5GIHBvb2wgY29udGFpbnMgYSBudW1iZXIgb2YgVk5GIGluc3RhbmNlcyBvZiBzYW1lIGZ1 bmN0aW9uYWwgdHlwZSAoZS5nLiBmaXJld2FsbCkuIFdlIGRlc2NyaWJlIGdlbmVyYWwgcG9vbGlu ZyBhcmNoaXRlY3R1cmUgYW5kIHNjb3BlIG91ciB3b3JrIGJhc2VkIG9uIHRoaXMgYXNzdW1wdGlv bi4NCg0KDQoNCkkgYW0gc3RpbGwgbm90IHN1cmUgaG93IHRvIHJlZmxlY3QgdGhpcyBpbiBWTkZQ b29sOiBJdCBtYXkgYmUgZGV0YWlscyB0aGF0IGhpZGUgaW5zaWRlIGEgVk5GIGFzIGUuZy4gZGVw aWN0ZWQgaW4NCkZpZy4gMS4gSW4gc3VjaCBjYXNlLCB0aGUgZnVuY3Rpb24taW50ZXJuYWwgYXJj aGl0ZWN0dXJlIG1hZGUgZnJvbSBkaWZmZXJlbnQgdk5GQ3MgaXMgbm90IHZpc2libGUgdG8gVk5G UG9vbC4NCg0KDQoNCltOaW5nXSBZb3UgYXJlIHJpZ2h0IHRoYXQgdGhlIFZORi1pbnRlcm5hbCBh cmNoaXRlY3R1cmUgYWJvdXQgZGlmZmVyZW50IFZORkNzIGlzIGN1cnJlbnRseSBoaWRkZW4gaW5z aWRlIGEgVk5GLiBXZSBjaG9vc2UgdG8gc3RhcnQgZnJvbSBhIHNpbmdsZSBsZXZlbCAoVk5GIGxl dmVsKSwgcmF0aGVyIHRoYW4gYSBoaWVyYXJjaGljYWwgbGV2ZWwgaW5jbHVkaW5nIGJvdGggVk5G IGFuZCBWTkZDcyBpbnNpZGUgVk5GLiBXZSB3aWxsIGRldmVsb3AgZ2VuZXJhbCBzb2x1dGlvbiB0 byBjb3ZlciBib3RoIGFzIG5leHQgc3RlcCBvZiB3b3JrLCBiYXNlZCBvbiBmdXJ0aGVyIHVzZSBj YXNlIHN0dWR5LiBJIGhvcGUgdGhpcyBpcyByZWFzb25hYmxlLiA6KQ0KDQoNCg0KDQoNCg0KDQpJ IGhvcGUgbXkgcmVwbHkgaGVscHMhDQoNCg0KDQoNCg0KW21hcmNvXSB5ZXMsIHRoZXkgaGVscCA6 KSBUaGFua3MgYWdhaW4gZm9yIHlvdXIgZmVlZGJhY2suDQoNCg0KDQptYXJjbw0KDQoNCg0KVGhh bmtzLg0KDQoNCg0KLU5pbmcNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg== --_000_69756203DDDDE64E987BC4F70B71A26D6987EA5APALLENEofficehd_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Ning,

 

thanks a lot for your = fast response. Please see inline.

 

From: Zongning= [mailto:zongning@huawei.com]
Sent: Freitag, 25. April 2014 08:31
To: Marco Liebsch; vnfpool@ietf.org
Subject: =B4=F0=B8=B4: comment on draft-zong-vnfpo= ol-problem-statement

 

Hi, M= arco,

=  

Pleas= e see inline my reply.

Consi= dering the list feedback, I will update 4th version to 5th<= /sup> version (with trivial changes) by early next week, to make our scope = more clear.

=  

 

Hi Ning, all,

 

please find some more feedback to the 4th revisio= n of the VNFPool PS draft below. It's more
about a clarification before I can send more detailed comments on the draft= .

 

 

The draft clarifie= s about the technical scope, which I understand is limited to redundancy ma= nagement
and failover handling within a group of VNFs of the same type, the VNF set.=

 

[Ning] Yes, our current scope is intended to a= VNF pool including group of VNF instances of the same type. VNF set is the= overall set of VNF instances that can be grouped into multiple VNF pools, with each VNF pool providing a differe= nt network function. Another word, our scope is mainly a part of VNF s= et (a VNF pool), not the whole VNF set.

 

To coordinate betw= een functions of different pools, the draft introduces the Service Control = Entity.

[Ning] Correct.

Does the Service Control Entity play a role in bu= ilding a single network function, e.g. a firewall,
from function instances of different pools?

 

[Ning] We assume th= at Service Control Entity builds a network service composed of different ne= twork functions (e.g. firewall, DPI, load balancer) provided by different p= ools. So, each VNF pool provides different network function. Note that this assumption is mainly to drive general poo= ling architecture and charter scope. We will consider general solution by r= eleasing such assumption if we identify reasonable use cases. For example, = we may consider solution that covers the case that a pool can also provide VNFCs=A1=AD

 

[marco] I understan= d and agree that it=A1=AFs a good approach to start with a limited scope an= d consider
VNFPool to operate solely inside a pool. But I have difficulties in seeing = how the general solution
can be broadened and associated assumptions are released, as you write, to = support a deployment, which
builds a single function from instances of multiple pools. There are associ= ated use cases, e.g. the EPC virtualization.

 

 

It does not play a role if the complete firewall = functionality is provided by a single VNF of a single Pool.

Is this the assumption for VNFPool?

 

[Ning] Please see a= bove.

 

[marco] So, I concl= ude from above description is does not, since it orchestrates mainly standa= lone functions
from multiple pools and builds a service package from these functions.=

 

From Fig. 1 of the draft I understand that the co= mplete function (e.g. the firewall), is provided by a single box
above the Virtualization Platform layer. And each box seems to be a virtual= machine.

 

[Ning] One or more = VNF instances could be hosted by a single VM. So the box in Fig.1 is not ne= cessarily a VM, although it likely to be true in practice.

 

This would mean that each VNFPool provides a self= -contained function, e.g. firewall, web-service, etc.

There is no functional dependency between VNFs of= different Pools. Is this understanding correct?

 

[Ning] It is correc= t anyway that there is no functional dependency between VNFs of different p= ools.

 

[marco] ok, underst= ood.

 

My understanding of how a virtualized network fun= ction vNF is built is that it comprises multiple

vNF Components (vNFC) of the same (for function-i= nternal load balancing) and of different types.

Each vNFC is instantiated in a separate virtual m= achine.

 

[Ning] Yes, I agree= with your view on how a VNF is built. As said, we currently assume that a = VNF pool contains a number of VNF instances of same functional type (e.g. f= irewall). We describe general pooling architecture and scope our work based on this assumption.

 

I am still not sure how to reflect this in VNFPoo= l: It may be details that hide inside a VNF as e.g. depicted in
Fig. 1. In such case, the function-internal architecture made from differen= t vNFCs is not visible to VNFPool.

 

[Ning] You are righ= t that the VNF-internal architecture about different VNFCs is currently hid= den inside a VNF. We choose to start from a single level (VNF level), rathe= r than a hierarchical level including both VNF and VNFCs inside VNF. We will develop general solution to cover b= oth as next step of work, based on further use case study. I hope this is r= easonable. J

 

 

 

I hope my reply hel= ps!

 

 

[marco] yes, they h= elp J Thanks again for your feedback.

 

marco

 

Th= anks.

 

-N= ing

 

 

 

 

 

 

 

 

 

 

 

 

--_000_69756203DDDDE64E987BC4F70B71A26D6987EA5APALLENEofficehd_-- From nobody Tue Apr 29 17:50:53 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 4E50F1A08EB for ; Tue, 29 Apr 2014 17:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3] autolearn=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 nLnhPGP1GDV9 for ; Tue, 29 Apr 2014 17:31:14 -0700 (PDT) Received: from smtp202-outgoing.stejtech.net (smtp202.stejtech.net [IPv6:2001:9b0:1:704::5202]) by ietfa.amsl.com (Postfix) with ESMTP id CEA981A07A0 for ; Tue, 29 Apr 2014 17:31:13 -0700 (PDT) X-Spam-STAY-ID: v=2.0 cv=E7ZPVNhl c=1 sm=0 a=fpfCo9GHTwTpwwPQDU8l2g==:17 a=h_ib5y7FUt0A:10 a=o5cPJh8WGgMA:10 a=8nJEP1OIZ-IA:10 a=xqWC_Br6kY4A:10 a=0uK3lwuoAAAA:8 a=7-UKAb_1m06K1CDF0s4A:9 a=wPNLvfGTeEIA:10 a=b0KEEVAwhZFadoE6:21 a=Qel7Evxxewn15ktV:21 Received: from mail.acreo.se (unknown [217.151.196.13]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp202.stejtech.net (Postfix) with ESMTPSA id 0C01F10940EF for ; Wed, 30 Apr 2014 02:31:11 +0200 (CEST) Received: from ACREOEXC02.ad.acreo.se ([::1]) by ACREOEXC02.ad.acreo.se ([::1]) with mapi id 14.03.0158.001; Wed, 30 Apr 2014 02:31:10 +0200 From: =?iso-8859-1?Q?Pontus_Sk=F6ldstr=F6m?= To: "vnfpool@ietf.org" Thread-Topic: CfP EWSDN 2014: 3rd European Workshop on Software Defined Networks Thread-Index: Ac9kC3vbUQAoqUlIQwO5Dp25YRfPLA== Date: Wed, 30 Apr 2014 00:31:10 +0000 Message-ID: <2D8B43480583CF47B78E7F01B983EF803CA96A@ACREOEXC02.ad.acreo.se> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [188.83.212.10] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/vl3hqJLp-tNiV50NMtCFfs0LW1U X-Mailman-Approved-At: Tue, 29 Apr 2014 17:50:50 -0700 Subject: [vnfpool] CfP EWSDN 2014: 3rd European Workshop on Software Defined Networks 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, 30 Apr 2014 00:31:15 -0000 CALL FOR PAPERS=0A= =0A= EWSDN 2014: 3rd European Workshop on Software Defined Networks=0A= =0A= http://ewsdn.eu=0A= =0A= 1-3 September 2014 in Budapest, Hungary.=0A= =0A= =0A= =0A= IMPORTANT DATES=0A= =0A= . Paper registration: 5 May 2014=0A= . Paper submission: 10 May 2014=0A= . Notification of acceptance: 1 July 2014=0A= . Camera ready papers due: 1 August 2014=0A= . Conference dates: 1-3 September 2014=0A= =0A= =0A= =0A= SYNOPSIS AND GOAL=0A= =0A= Software Defined Networking is undoubtedly one of the chief trends in the I= CT area. In the past years we have seen all big players in the networking a= rena starting to ride the SDN. Standardization work is actively ongoing in = the Open Networking Forum (ONF), the Internet Engineering Task Force (IETF)= (e.g., I2RS, freshly formed Service Function Chaining (SFC) workgroup or r= ecent initiatives to form VNFPool), while the European Telecommunications S= tandards Institute (ETSI) just released several group specifications on Net= work Functions Virtualization (NFV). On top of the several existing open-so= urce SDN controllers, OpenDaylight reached significant momentum last year a= nd arrived to its first official release in February 2014.=0A= =0A= One goal of the workshop is to bring together industry and academia on the = topics of SDN; in particular the workshop will feature an "industry forum",= i.e., a session with presentations of key industrial players.=0A= =0A= =0A= =0A= CONTRIBUTIONS TO THE WORKSHOP=0A= =0A= We are interested in both papers showing consolidated results and in positi= on papers bringing up innovative ideas. Topics for contributions include, b= ut are not limited to, the following:=0A= - Virtualization architectures=0A= - Forwarding abstractions, APIs, object models=0A= - Network Function Virtualization and SDN, network virtualizat= ion techniques=0A= - Optical extensions to OpenFlow, SDN=0A= - Wireless integration, characterization of wireless interface= s, flows, handover support=0A= - Evolved packet core, LTE support for OpenFlow=0A= - New controller architectures, APIs and northbound interfaces= =0A= - Interoperation of cloud architectures and SDN=0A= - New switch architectures supporting SDN=0A= - New networking paradigms like Information Centric Networks (= ICN) and relation to SDN=0A= - Security implications of SDN and security enhancements to SD= N, as well as new security services enabled by SDN=0A= - Carrier-grade SDN architectures and equipment=0A= - Practical experiments on SDN/Cloud/OpenFlow=0A= - Testbeds=0A= - Identification of use cases for SDN, SDN related business mo= dels, strategic role of SDN in network evolution=0A= - Regulatory aspects around network virtualization=0A= - SDN frameworks and tools, SDN based equipment: controllers, = switches, integrated development environment, testing and debugging environ= ment.=0A= =0A= =0A= =0A= SUBMISSION AND PUBLICATION=0A= =0A= Submission format is IEEE Conference Style, A4 format, of up to 6 pages.=0A= Please use standard IEEE conference proceedings templates.=0A= EWSDN submission will be managed using the EasyChair submission system, che= ck the web for the submission link.=0A= =0A= EWSDN Workshop Proceedings will be submitted for indexing and publication t= o IEEE Xplore.=0A= =0A= =0A= =0A= COMMITTEE AT A GLANCE=0A= =0A= General Chair: Hagen Woesner, BISDN, Berlin, Germany=0A= =0A= TPC Co-Chairs:=0A= =0A= Holger Karl,University Paderborn, Paderborn, Germany=0A= =0A= Robert Szabo, Ericsson, Hungary=0A= =0A= Publicity Chairs:=0A= =0A= Stefan Schmid, TU Berlin / Telekom Innovation Laboratories, Germany=0A= =0A= Pontus Sk=F6ldstr=F6m, Acreo AB, Sweden=0A= =0A= Demo and Exhibition Chair: Balazs Sonkoly, BME, Hungary=0A= =0A= Workshop Operations Chair and Web Chair: Mario Druse, EICT, Germany=0A= From nobody Wed Apr 30 01:44:26 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 91CC31A6F1A for ; Wed, 30 Apr 2014 01:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.901 X-Spam-Level: X-Spam-Status: No, score=-98.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 dGQPQLvz67x4 for ; Wed, 30 Apr 2014 01:44:00 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0B6871A0764 for ; Wed, 30 Apr 2014 01:43:58 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDR10484; Wed, 30 Apr 2014 08:43:57 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 30 Apr 2014 09:42:45 +0100 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 30 Apr 2014 09:43:43 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.85]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Wed, 30 Apr 2014 16:43:35 +0800 From: Zongning To: Marco Liebsch , "vnfpool@ietf.org" Thread-Topic: comment on draft-zong-vnfpool-problem-statement Thread-Index: Ac9fmDyzNcG0Cup+RbOtZ5jtaBTJgwAoStnwAKIJILAAY06ooA== Date: Wed, 30 Apr 2014 08:43:35 +0000 Message-ID: References: <69756203DDDDE64E987BC4F70B71A26D6987A833@PALLENE.office.hd> <69756203DDDDE64E987BC4F70B71A26D6987EA5A@PALLENE.office.hd> In-Reply-To: <69756203DDDDE64E987BC4F70B71A26D6987EA5A@PALLENE.office.hd> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.144] Content-Type: multipart/alternative; boundary="_000_B0D29E0424F2DE47A0B36779EC6667796611628Fnkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/40oCEiCId2mvZJrHOYGf8XGnqmU Subject: [vnfpool] =?gb2312?b?tPC4tDogY29tbWVudCBvbiBkcmFmdC16b25nLXZuZnBv?= =?gb2312?b?b2wtcHJvYmxlbS1zdGF0ZW1lbnQ=?= 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, 30 Apr 2014 08:44:04 -0000 --_000_B0D29E0424F2DE47A0B36779EC6667796611628Fnkgeml501mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIE1hcmNvLA0KDQoNClttYXJjb10gQnV0IEkgaGF2ZSBkaWZmaWN1bHRpZXMgaW4gc2VlaW5n IGhvdyB0aGUgZ2VuZXJhbCBzb2x1dGlvbiBjYW4gYmUgYnJvYWRlbmVkIGFuZCBhc3NvY2lhdGVk IGFzc3VtcHRpb25zIGFyZSByZWxlYXNlZCwgYXMgeW91IHdyaXRlLCB0byBzdXBwb3J0IGEgZGVw bG95bWVudCwgd2hpY2ggYnVpbGRzIGEgc2luZ2xlIGZ1bmN0aW9uIGZyb20gaW5zdGFuY2VzIG9m IG11bHRpcGxlIHBvb2xzLiBUaGVyZSBhcmUgYXNzb2NpYXRlZCB1c2UgY2FzZXMsIGUuZy4gdGhl IEVQQyB2aXJ0dWFsaXphdGlvbi4NCg0KW05pbmddIEJ5IGxvb2tpbmcgYXQgdGhlIEVQQyBhcmNo aXRlY3R1cmUsIEkgZG9uoa90IHNlZSB3aHkgVk5GIHBvb2wgaW5jbHVkaW5nIGlkZW50aWNhbCBW TkYgaW5zdGFuY2VzIGNhbm5vdCBiZSBhcHBsaWVkLiBGb3IgZXhhbXBsZSwgd2UgY2FuIHVzZSBt dWx0aXBsZSBWTkYgcG9vbHMgqEMgc2F5LCBvbmUgcG9vbCBmb3IgdlAtR1cgaW5zdGFuY2VzLCBv bmUgcG9vbCBmb3IgdlMtR1cgaW5zdGFuY2VzLCBhbm90aGVyIHBvb2wgZm9yIHZNTUUgaW5zdGFu Y2VzLCBhbmQgc28gb24uIEFub3RoZXIgd29yZCwgdlAtR1csIHZTLUdXLCB2TU1FLCBldGMuIGNh biBiZSBWTkZzIHRvIGNvbXBvc2UgdGhlIHdob2xlIHNlcnZpY2Ugb2YgdkVQQy4gVGhlcmUgaXMg bm8gcmVzdHJpY3Rpb24gb24gaG93IHRoZSBORlYgb3BlcmF0b3IgZGVmaW5lcyBWTkZzLiBXZSB3 aWxsIG5vdCBhc3N1bWUgdGhhdCB2RVBDIGlzIGluIFZORi1sZXZlbCwgYW5kIFAtR1cvUy1HVy9N TUUgYXJlIGluIFZORkMtbGV2ZWwuIE9uIHRoZSBjb250cmFyeSwgYnkgcmVhZGluZyB0aGUgRVRT SSBORlYgU1dBIHNwZWNpZmljYXRpb24sIEkgYmVsaWV2ZSBWTkZDcyByZWZlciB0byB0aGUgdmFy aW91cyBzb2Z0d2FyZSBwYWNrYWdlcyBpbXBsZW1lbnRpbmcgKG9yIGluc2lkZSkgdlAtR1csIGlt cGxlbWVudGluZyAoaW5zaWRlKSB2TU1FLCBldGMuIFRoZXNlIFZORkNzIGFyZSB1c3VhbGx5IFZO RiB2ZW5kb3IvZGV2ZWxvcGVyIHNwZWNpZmljLCBhbmQgKHRvIG15IGJlc3Qga25vd2xlZGdlKSBl dmVuIEVUU0kgTkZWIFNXQSB3aWxsIE5PVCBzdHVkeSBkZXRhaWxzIG9mIFZORkNzIGFuZCB0aGUg aW50ZXJmYWNlcyBiZXR3ZWVuIFZORkNzLiA6KQ0KDQpNYXliZSB3ZSBzdGlsbCBoYXZlIHNvbWUg bWlzYWxpZ25tZW50IG9uIHRoZSBsZXZlbHMgb2YgVk5GLCBhbmQgVk5GQ6GtIDopDQoNCkJ1dCBh bnl3YXksIEkgZGVmaW5pdGVseSBlbmNvdXJhZ2UgeW91IGFuZCBvdGhlciBjby1hdXRob3JzIHRv IGJyaW5nIHZhcmlvdXMgTkZWIHVzZSBjYXNlcy4NCg0KVGhhbmtzLg0KDQotTmluZw0KDQq3orz+ yMs6IE1hcmNvIExpZWJzY2ggW21haWx0bzpNYXJjby5MaWVic2NoQG5lY2xhYi5ldV0NCreiy83K sbzkOiAyMDE0xOo01MIyOMjVIDE3OjIyDQrK1bz+yMs6IFpvbmduaW5nOyB2bmZwb29sQGlldGYu b3JnDQrW98ziOiBSRTogY29tbWVudCBvbiBkcmFmdC16b25nLXZuZnBvb2wtcHJvYmxlbS1zdGF0 ZW1lbnQNCg0KSGkgTmluZywNCg0KdGhhbmtzIGEgbG90IGZvciB5b3VyIGZhc3QgcmVzcG9uc2Uu IFBsZWFzZSBzZWUgaW5saW5lLg0KDQpGcm9tOiBab25nbmluZyBbbWFpbHRvOnpvbmduaW5nQGh1 YXdlaS5jb21dDQpTZW50OiBGcmVpdGFnLCAyNS4gQXByaWwgMjAxNCAwODozMQ0KVG86IE1hcmNv IExpZWJzY2g7IHZuZnBvb2xAaWV0Zi5vcmc8bWFpbHRvOnZuZnBvb2xAaWV0Zi5vcmc+DQpTdWJq ZWN0OiC08Li0OiBjb21tZW50IG9uIGRyYWZ0LXpvbmctdm5mcG9vbC1wcm9ibGVtLXN0YXRlbWVu dA0KDQpIaSwgTWFyY28sDQoNClBsZWFzZSBzZWUgaW5saW5lIG15IHJlcGx5Lg0KQ29uc2lkZXJp bmcgdGhlIGxpc3QgZmVlZGJhY2ssIEkgd2lsbCB1cGRhdGUgNHRoIHZlcnNpb24gdG8gNXRoIHZl cnNpb24gKHdpdGggdHJpdmlhbCBjaGFuZ2VzKSBieSBlYXJseSBuZXh0IHdlZWssIHRvIG1ha2Ug b3VyIHNjb3BlIG1vcmUgY2xlYXIuDQoNCg0KDQpIaSBOaW5nLCBhbGwsDQoNCg0KDQpwbGVhc2Ug ZmluZCBzb21lIG1vcmUgZmVlZGJhY2sgdG8gdGhlIDR0aCByZXZpc2lvbiBvZiB0aGUgVk5GUG9v bCBQUyBkcmFmdCBiZWxvdy4gSXQncyBtb3JlDQphYm91dCBhIGNsYXJpZmljYXRpb24gYmVmb3Jl IEkgY2FuIHNlbmQgbW9yZSBkZXRhaWxlZCBjb21tZW50cyBvbiB0aGUgZHJhZnQuDQoNCg0KDQoN Cg0KVGhlIGRyYWZ0IGNsYXJpZmllcyBhYm91dCB0aGUgdGVjaG5pY2FsIHNjb3BlLCB3aGljaCBJ IHVuZGVyc3RhbmQgaXMgbGltaXRlZCB0byByZWR1bmRhbmN5IG1hbmFnZW1lbnQNCmFuZCBmYWls b3ZlciBoYW5kbGluZyB3aXRoaW4gYSBncm91cCBvZiBWTkZzIG9mIHRoZSBzYW1lIHR5cGUsIHRo ZSBWTkYgc2V0Lg0KDQoNCg0KW05pbmddIFllcywgb3VyIGN1cnJlbnQgc2NvcGUgaXMgaW50ZW5k ZWQgdG8gYSBWTkYgcG9vbCBpbmNsdWRpbmcgZ3JvdXAgb2YgVk5GIGluc3RhbmNlcyBvZiB0aGUg c2FtZSB0eXBlLiBWTkYgc2V0IGlzIHRoZSBvdmVyYWxsIHNldCBvZiBWTkYgaW5zdGFuY2VzIHRo YXQgY2FuIGJlIGdyb3VwZWQgaW50byBtdWx0aXBsZSBWTkYgcG9vbHMsIHdpdGggZWFjaCBWTkYg cG9vbCBwcm92aWRpbmcgYSBkaWZmZXJlbnQgbmV0d29yayBmdW5jdGlvbi4gQW5vdGhlciB3b3Jk LCBvdXIgc2NvcGUgaXMgbWFpbmx5IGEgcGFydCBvZiBWTkYgc2V0IChhIFZORiBwb29sKSwgbm90 IHRoZSB3aG9sZSBWTkYgc2V0Lg0KDQoNCg0KVG8gY29vcmRpbmF0ZSBiZXR3ZWVuIGZ1bmN0aW9u cyBvZiBkaWZmZXJlbnQgcG9vbHMsIHRoZSBkcmFmdCBpbnRyb2R1Y2VzIHRoZSBTZXJ2aWNlIENv bnRyb2wgRW50aXR5Lg0KDQpbTmluZ10gQ29ycmVjdC4NCg0KRG9lcyB0aGUgU2VydmljZSBDb250 cm9sIEVudGl0eSBwbGF5IGEgcm9sZSBpbiBidWlsZGluZyBhIHNpbmdsZSBuZXR3b3JrIGZ1bmN0 aW9uLCBlLmcuIGEgZmlyZXdhbGwsDQpmcm9tIGZ1bmN0aW9uIGluc3RhbmNlcyBvZiBkaWZmZXJl bnQgcG9vbHM/DQoNCg0KDQpbTmluZ10gV2UgYXNzdW1lIHRoYXQgU2VydmljZSBDb250cm9sIEVu dGl0eSBidWlsZHMgYSBuZXR3b3JrIHNlcnZpY2UgY29tcG9zZWQgb2YgZGlmZmVyZW50IG5ldHdv cmsgZnVuY3Rpb25zIChlLmcuIGZpcmV3YWxsLCBEUEksIGxvYWQgYmFsYW5jZXIpIHByb3ZpZGVk IGJ5IGRpZmZlcmVudCBwb29scy4gU28sIGVhY2ggVk5GIHBvb2wgcHJvdmlkZXMgZGlmZmVyZW50 IG5ldHdvcmsgZnVuY3Rpb24uIE5vdGUgdGhhdCB0aGlzIGFzc3VtcHRpb24gaXMgbWFpbmx5IHRv IGRyaXZlIGdlbmVyYWwgcG9vbGluZyBhcmNoaXRlY3R1cmUgYW5kIGNoYXJ0ZXIgc2NvcGUuIFdl IHdpbGwgY29uc2lkZXIgZ2VuZXJhbCBzb2x1dGlvbiBieSByZWxlYXNpbmcgc3VjaCBhc3N1bXB0 aW9uIGlmIHdlIGlkZW50aWZ5IHJlYXNvbmFibGUgdXNlIGNhc2VzLiBGb3IgZXhhbXBsZSwgd2Ug bWF5IGNvbnNpZGVyIHNvbHV0aW9uIHRoYXQgY292ZXJzIHRoZSBjYXNlIHRoYXQgYSBwb29sIGNh biBhbHNvIHByb3ZpZGUgVk5GQ3OhrQ0KDQoNCg0KW21hcmNvXSBJIHVuZGVyc3RhbmQgYW5kIGFn cmVlIHRoYXQgaXShr3MgYSBnb29kIGFwcHJvYWNoIHRvIHN0YXJ0IHdpdGggYSBsaW1pdGVkIHNj b3BlIGFuZCBjb25zaWRlcg0KVk5GUG9vbCB0byBvcGVyYXRlIHNvbGVseSBpbnNpZGUgYSBwb29s LiBCdXQgSSBoYXZlIGRpZmZpY3VsdGllcyBpbiBzZWVpbmcgaG93IHRoZSBnZW5lcmFsIHNvbHV0 aW9uDQpjYW4gYmUgYnJvYWRlbmVkIGFuZCBhc3NvY2lhdGVkIGFzc3VtcHRpb25zIGFyZSByZWxl YXNlZCwgYXMgeW91IHdyaXRlLCB0byBzdXBwb3J0IGEgZGVwbG95bWVudCwgd2hpY2gNCmJ1aWxk cyBhIHNpbmdsZSBmdW5jdGlvbiBmcm9tIGluc3RhbmNlcyBvZiBtdWx0aXBsZSBwb29scy4gVGhl cmUgYXJlIGFzc29jaWF0ZWQgdXNlIGNhc2VzLCBlLmcuIHRoZSBFUEMgdmlydHVhbGl6YXRpb24u DQoNCg0KDQoNCg0KSXQgZG9lcyBub3QgcGxheSBhIHJvbGUgaWYgdGhlIGNvbXBsZXRlIGZpcmV3 YWxsIGZ1bmN0aW9uYWxpdHkgaXMgcHJvdmlkZWQgYnkgYSBzaW5nbGUgVk5GIG9mIGEgc2luZ2xl IFBvb2wuDQoNCklzIHRoaXMgdGhlIGFzc3VtcHRpb24gZm9yIFZORlBvb2w/DQoNCg0KDQpbTmlu Z10gUGxlYXNlIHNlZSBhYm92ZS4NCg0KDQoNClttYXJjb10gU28sIEkgY29uY2x1ZGUgZnJvbSBh Ym92ZSBkZXNjcmlwdGlvbiBpcyBkb2VzIG5vdCwgc2luY2UgaXQgb3JjaGVzdHJhdGVzIG1haW5s eSBzdGFuZGFsb25lIGZ1bmN0aW9ucw0KZnJvbSBtdWx0aXBsZSBwb29scyBhbmQgYnVpbGRzIGEg c2VydmljZSBwYWNrYWdlIGZyb20gdGhlc2UgZnVuY3Rpb25zLg0KDQoNCg0KRnJvbSBGaWcuIDEg b2YgdGhlIGRyYWZ0IEkgdW5kZXJzdGFuZCB0aGF0IHRoZSBjb21wbGV0ZSBmdW5jdGlvbiAoZS5n LiB0aGUgZmlyZXdhbGwpLCBpcyBwcm92aWRlZCBieSBhIHNpbmdsZSBib3gNCmFib3ZlIHRoZSBW aXJ0dWFsaXphdGlvbiBQbGF0Zm9ybSBsYXllci4gQW5kIGVhY2ggYm94IHNlZW1zIHRvIGJlIGEg dmlydHVhbCBtYWNoaW5lLg0KDQoNCg0KW05pbmddIE9uZSBvciBtb3JlIFZORiBpbnN0YW5jZXMg Y291bGQgYmUgaG9zdGVkIGJ5IGEgc2luZ2xlIFZNLiBTbyB0aGUgYm94IGluIEZpZy4xIGlzIG5v dCBuZWNlc3NhcmlseSBhIFZNLCBhbHRob3VnaCBpdCBsaWtlbHkgdG8gYmUgdHJ1ZSBpbiBwcmFj dGljZS4NCg0KDQoNClRoaXMgd291bGQgbWVhbiB0aGF0IGVhY2ggVk5GUG9vbCBwcm92aWRlcyBh IHNlbGYtY29udGFpbmVkIGZ1bmN0aW9uLCBlLmcuIGZpcmV3YWxsLCB3ZWItc2VydmljZSwgZXRj Lg0KDQpUaGVyZSBpcyBubyBmdW5jdGlvbmFsIGRlcGVuZGVuY3kgYmV0d2VlbiBWTkZzIG9mIGRp ZmZlcmVudCBQb29scy4gSXMgdGhpcyB1bmRlcnN0YW5kaW5nIGNvcnJlY3Q/DQoNCg0KDQpbTmlu Z10gSXQgaXMgY29ycmVjdCBhbnl3YXkgdGhhdCB0aGVyZSBpcyBubyBmdW5jdGlvbmFsIGRlcGVu ZGVuY3kgYmV0d2VlbiBWTkZzIG9mIGRpZmZlcmVudCBwb29scy4NCg0KDQoNClttYXJjb10gb2ss IHVuZGVyc3Rvb2QuDQoNCg0KDQpNeSB1bmRlcnN0YW5kaW5nIG9mIGhvdyBhIHZpcnR1YWxpemVk IG5ldHdvcmsgZnVuY3Rpb24gdk5GIGlzIGJ1aWx0IGlzIHRoYXQgaXQgY29tcHJpc2VzIG11bHRp cGxlDQoNCnZORiBDb21wb25lbnRzICh2TkZDKSBvZiB0aGUgc2FtZSAoZm9yIGZ1bmN0aW9uLWlu dGVybmFsIGxvYWQgYmFsYW5jaW5nKSBhbmQgb2YgZGlmZmVyZW50IHR5cGVzLg0KDQpFYWNoIHZO RkMgaXMgaW5zdGFudGlhdGVkIGluIGEgc2VwYXJhdGUgdmlydHVhbCBtYWNoaW5lLg0KDQoNCg0K W05pbmddIFllcywgSSBhZ3JlZSB3aXRoIHlvdXIgdmlldyBvbiBob3cgYSBWTkYgaXMgYnVpbHQu IEFzIHNhaWQsIHdlIGN1cnJlbnRseSBhc3N1bWUgdGhhdCBhIFZORiBwb29sIGNvbnRhaW5zIGEg bnVtYmVyIG9mIFZORiBpbnN0YW5jZXMgb2Ygc2FtZSBmdW5jdGlvbmFsIHR5cGUgKGUuZy4gZmly ZXdhbGwpLiBXZSBkZXNjcmliZSBnZW5lcmFsIHBvb2xpbmcgYXJjaGl0ZWN0dXJlIGFuZCBzY29w ZSBvdXIgd29yayBiYXNlZCBvbiB0aGlzIGFzc3VtcHRpb24uDQoNCg0KDQpJIGFtIHN0aWxsIG5v dCBzdXJlIGhvdyB0byByZWZsZWN0IHRoaXMgaW4gVk5GUG9vbDogSXQgbWF5IGJlIGRldGFpbHMg dGhhdCBoaWRlIGluc2lkZSBhIFZORiBhcyBlLmcuIGRlcGljdGVkIGluDQpGaWcuIDEuIEluIHN1 Y2ggY2FzZSwgdGhlIGZ1bmN0aW9uLWludGVybmFsIGFyY2hpdGVjdHVyZSBtYWRlIGZyb20gZGlm ZmVyZW50IHZORkNzIGlzIG5vdCB2aXNpYmxlIHRvIFZORlBvb2wuDQoNCg0KDQpbTmluZ10gWW91 IGFyZSByaWdodCB0aGF0IHRoZSBWTkYtaW50ZXJuYWwgYXJjaGl0ZWN0dXJlIGFib3V0IGRpZmZl cmVudCBWTkZDcyBpcyBjdXJyZW50bHkgaGlkZGVuIGluc2lkZSBhIFZORi4gV2UgY2hvb3NlIHRv IHN0YXJ0IGZyb20gYSBzaW5nbGUgbGV2ZWwgKFZORiBsZXZlbCksIHJhdGhlciB0aGFuIGEgaGll cmFyY2hpY2FsIGxldmVsIGluY2x1ZGluZyBib3RoIFZORiBhbmQgVk5GQ3MgaW5zaWRlIFZORi4g V2Ugd2lsbCBkZXZlbG9wIGdlbmVyYWwgc29sdXRpb24gdG8gY292ZXIgYm90aCBhcyBuZXh0IHN0 ZXAgb2Ygd29yaywgYmFzZWQgb24gZnVydGhlciB1c2UgY2FzZSBzdHVkeS4gSSBob3BlIHRoaXMg aXMgcmVhc29uYWJsZS4gOikNCg0KDQoNCg0KDQoNCg0KSSBob3BlIG15IHJlcGx5IGhlbHBzIQ0K DQoNCg0KDQoNClttYXJjb10geWVzLCB0aGV5IGhlbHAgOikgVGhhbmtzIGFnYWluIGZvciB5b3Vy IGZlZWRiYWNrLg0KDQoNCg0KbWFyY28NCg0KDQoNClRoYW5rcy4NCg0KDQoNCi1OaW5nDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQo= --_000_B0D29E0424F2DE47A0B36779EC6667796611628Fnkgeml501mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi, Marco,

 

[mar= co] But I have difficulties in seeing how the general solution can be broad= ened and associated assumptions are released, as you write, to support a de= ployment, which builds a single function from instances of multiple pools. There are associated use cases, e.g. the= EPC virtualization.

 

[Ning] By looking at the EPC architecture, I don=A1=AFt see why V= NF pool including identical VNF instances cannot be applied. For example, we can use= multiple VNF pools =A8C say, one pool for vP-GW instances, one pool for vS= -GW instances, another pool for vMME instances, and so on. Another word, vP= -GW, vS-GW, vMME, etc. can be VNFs to compose the whole service of vEPC. There is no restriction on how the NFV operator= defines VNFs. We will not assume that vEPC is in VNF-level, and P-GW/S-GW/= MME are in VNFC-level. On the contrary, by reading the ETSI NFV SWA specifi= cation, I believe VNFCs refer to the various software packages implementing (or inside) vP-GW, implementing= (inside) vMME, etc. These VNFCs are usually VNF vendor/developer specific,= and (to my best knowledge) even ETSI NFV SWA will NOT study details of VNF= Cs and the interfaces between VNFCs. J=

&n= bsp;

Maybe we still have some misalignment on the levels of VNF, and V= NFC=A1=AD J

 

But any= way, I definitely encourage you and other co-authors to bring various NFV u= se cases.

 

Thanks.

 

-Ning

 

=B7=A2=BC=FE=C8=CB: Marco L= iebsch [mailto:Marco.Liebsch@neclab.eu]
=B7=A2= =CB=CD=CA=B1=BC=E4: 2014=C4=EA4=D4=C228=C8=D5 17:22
=CA=D5=BC=FE=C8=CB: Zongning; vnfpool@ietf.org
=D6=F7=CC=E2: RE: comment on draft-zong-vnfpool-problem-statement

 

Hi Ning= ,

&n= bsp;

thanks = a lot for your fast response. Please see inline.

&n= bsp;

From: Zongning [mail= to:zongning@huawei.com]
Sent: Freitag, 25. April 2014 08:31
To: Marco Liebsch; vnfpool@ietf.= org
Subject: =B4=F0=B8=B4: comment on draft-zo= ng-vnfpool-problem-statement

 

Hi, Marco,

 

Please see inline my reply.

Considering the list feedback, I will update 4th versi= on to 5th version (with trivial changes) by early next week, to = make our scope more clear.

 

 

Hi Ning, all,

 

please find some more feedba= ck to the 4th revision of the VNFPool PS draft below. It's more
about a clarification before I can send more detailed comments on the draft= .

 

 

The draft clarifies about the technical scope, which I understand is lim= ited to redundancy management
and failover handling within a group of VNFs of the same type, the VNF set.=

 

[Ning] Yes, our current scope i= s intended to a VNF pool including group of VNF instances of the same type.= VNF set is the overall set of VNF instances that can be grouped into multiple VNF pools, with each VNF pool providing = a different network function. Another word, our scope is mainly a part= of VNF set (a VNF pool), not the whole VNF set.

 

To coordinate between functions of different pools, the draft introduces= the Service Control Entity.

[Ning] Correct.

Does the Service Control Ent= ity play a role in building a single network function, e.g. a firewall,
from function instances of different pools?

 

[Nin= g] We assume that Service Control Entity builds a network service composed = of different network functions (e.g. firewall, DPI, load balancer) provided= by different pools. So, each VNF pool provides different network function. Note that this assumption is mainly t= o drive general pooling architecture and charter scope. We will consider ge= neral solution by releasing such assumption if we identify reasonable use c= ases. For example, we may consider solution that covers the case that a pool can also provide VNFCs=A1=AD

 

[mar= co] I understand and agree that it=A1=AFs a good approach to start with a l= imited scope and consider
VNFPool to operate solely inside a pool. But I have difficulties in seeing = how the general solution
can be broadened and associated assumptions are released, as you write, to = support a deployment, which
builds a single function from instances of multiple pools. There are associ= ated use cases, e.g. the EPC virtualization.

 

 

It does not play a role if t= he complete firewall functionality is provided by a single VNF of a single = Pool.

Is this the assumption for V= NFPool?

 

[Nin= g] Please see above.

 

[mar= co] So, I conclude from above description is does not, since it orchestrate= s mainly standalone functions
from multiple pools and builds a service package from these functions.=

 

From Fig. 1 of the draft I u= nderstand that the complete function (e.g. the firewall), is provided by a = single box
above the Virtualization Platform layer. And each box seems to be a virtual= machine.

 

[Nin= g] One or more VNF instances could be hosted by a single VM. So the box in = Fig.1 is not necessarily a VM, although it likely to be true in practice.

 

This would mean that each VN= FPool provides a self-contained function, e.g. firewall, web-service, etc.<= o:p>

There is no functional depen= dency between VNFs of different Pools. Is this understanding correct?<= /o:p>

 

[Nin= g] It is correct anyway that there is no functional dependency between VNFs= of different pools.

 

[mar= co] ok, understood.

 

My understanding of how a vi= rtualized network function vNF is built is that it comprises multiple<= /o:p>

vNF Components (vNFC) of the= same (for function-internal load balancing) and of different types.

Each vNFC is instantiated in= a separate virtual machine.

 

[Nin= g] Yes, I agree with your view on how a VNF is built. As said, we currently= assume that a VNF pool contains a number of VNF instances of same function= al type (e.g. firewall). We describe general pooling architecture and scope our work based on this assumption.

 

I am still not sure how to r= eflect this in VNFPool: It may be details that hide inside a VNF as e.g. de= picted in
Fig. 1. In such case, the function-internal architecture made from differen= t vNFCs is not visible to VNFPool.

 

[Nin= g] You are right that the VNF-internal architecture about different VNFCs i= s currently hidden inside a VNF. We choose to start from a single level (VN= F level), rather than a hierarchical level including both VNF and VNFCs inside VNF. We will develop general solution = to cover both as next step of work, based on further use case study. I hope= this is reasonable. J=

 

 

 

I ho= pe my reply helps!

 

 

[mar= co] yes, they help J= Thanks again for your = feedback.

 

marc= o

 

Thanks.

 

-Ning

 

 

 

 

 

 

 

 

 

 

 

 

--_000_B0D29E0424F2DE47A0B36779EC6667796611628Fnkgeml501mbschi_--