Is there any reference (sub-ms, 10s ms, ...)=A0on the requirement of l= atency=A0

for a backup device (e.g.,=A0firewal) to take over? Wha= t is the persistency requirement

regarding NF state recovery: no = loss because master state is=A0not recoverable=A0

or the state is reconstructable and fast recovery is just an optimizat= ion?

Richard

=A0

To me it looks
more like a network configuration platform.

Melinda
_______________________________________________
vnfpool mailing list
vnfpool@ietf.org
https://www.ietf.org/mailman/listinfo/vnfpool

--f46d043c80ea3a2f8804e6a0ac98-- From zongning@huawei.com Wed Sep 18 02:21:38 2013 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D6F211E81CF for ; Wed, 18 Sep 2013 02:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5XP4rmcW+U6 for ; Wed, 18 Sep 2013 02:21:34 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D8BFC11E820B for ; Wed, 18 Sep 2013 02:21:24 -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.5-GA FastPath queued) with ESMTP id AVP36459; Wed, 18 Sep 2013 09:21:23 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 18 Sep 2013 10:20:54 +0100 Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 18 Sep 2013 10:21:21 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.141]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0146.000; Wed, 18 Sep 2013 17:21:16 +0800 From: Zongning To: "Y. Richard Yang" Thread-Topic: [vnfpool] Great effort Thread-Index: AQHOskjULKJLxUdgkkalv7iBn20X+JnHpQVAgAKvugCAAN2ycA== Date: Wed, 18 Sep 2013 09:21:15 +0000 Message-ID: References: <003601ceb0d9$717507d0$545f1770$@ndzh.com>

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.48] Content-Type: multipart/alternative; boundary="_000_B0D29E0424F2DE47A0B36779EC666779257FE96Enkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "vnfpool@ietf.org" , "N:" Subject: Re: [vnfpool] Great effort X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.12 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, 18 Sep 2013 09:21:38 -0000 --_000_B0D29E0424F2DE47A0B36779EC666779257FE96Enkgeml501mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Richard, From: yang.r.yang@gmail.com [mailto:yang.r.yang@gmail.com] On Behalf Of Y. = Richard Yang Sent: Wednesday, September 18, 2013 11:33 AM To: Zongning Cc: Y. Richard Yang; N:; vnfpool@ietf.org Subject: Re: [vnfpool] Great effort Hi Ning, On Sunday, September 15, 2013, Zongning wrote: Hi, Richard, Thank you for your interest and information! Pointer to Zookeeper: http://zookeeper.apache.org/ Some useful slides: https://cwiki.apache.org/confluence/display/ZOOKEEPER/ZooKeeperPresentation= s I also see some similarity of design goal between Zookeeper service and Ser= ver Pool, both consist of multiple servers including leader and followers t= o provide client reliable service. However, as you also mentioned, there ar= e difference in details such as name space - Zookeeper is based on file sys= tem APIs, whilst RSerPool utilizes flat handle space (e.g. SIP, Web, etc). = Another gap between Zookeeper and Reliable VNF may be that Zookeeper basica= lly targets on client-server mode zookeeper may not be limited to client-server. It is a service for a pool o= f other servers to coordinate, for example, to elect the next meta server. [Ning] Yes, you are right. Zookeeper service is for coordinating a set of s= ervers which implement single application or multiple applications. But I a= m not sure if Zookeeper service also includes selecting appropriate server(= s) for any specific application? Considering the model of VNF pools, there = are multiple, distributed pools where each pool contains a set of servers o= f a specific application. We probably need coordination service that synchr= onizes the status of the servers within pool, across different pools, as we= ll as selecting/replacing servers for further chaining them together... but Reliable VNF is actually in a mode of directly connected servers with d= ifferent functionalities. Not clear about the meaning of different functionalities. Here is a dummy l= ogical model using which I am trying to make sense of the problem setting: - the system consists of a set of deployed service chains, sc1, sc2, sc3, .= .., scN, where sci is a directed graph in the general case, and a sequence = in a typical case; this set can be dynamic; - there are modes, constraints, and policies placed on each service chain, = such as there should be x active instances of sc_ij, which is the j-th elem= ent of the service chain sc_i; sc_ij runs in single master + x-1 backup mod= e; sc_ij and sc_ik masters must be on the same subnet, ... The parameters c= an be dynamic as applications scale; The goal is to monitor the preceding, the reserves, start/stop/migrate to e= nforce the policies? [Ning] The model is basically correct. The parameters need to reflect the p= olicies. When I say servers with different functionalities, I mean FW serve= r, DPI server, etc... So I am not sure "sc_ij and sc_ik must be on the same= subnet" is correct statement? Richard Please correct me if I am wrong. :) I am think of documenting these implementations as well as the gaps to Reli= able VNF in a draft... -Ning From: yang.r.yang@gmail.com [mailto:yang.r.yang@gmail.com] On Behalf Of Y. Richard Yang Sent: Monday, September 16, 2013 3:22 AM To: N: Cc: vnfpool@ietf.org; Zongning Subject: Re: [vnfpool] Great effort Dear all, Very interesting work indeed. Sue made a good point of using a standardized= approach, which makes a lot of sense. As I am getting to become familiar with RServPool, when I first tried to th= ink about the problem of reliable server pool, a system such as Zookeeper c= omes to mind, as it appears to be more publicized in academia. Is there a t= echnical comparison between the two designs? At an entity level, I see simi= lar entities. But the detailed designs appear to be different, e.g., hierar= chical name space. It will be a good study to look into such differences in= the context of vnf, given the interest. Does anyone have a pointer or this= is a space that has not been explored. Thanks. Richard On Sep 13, 2013 7:32 PM, "Susan Hares" > wrote: Thomas: The work in Reliable Server Pooling (RSerPool) may be quite interesting in = the context of Virtualized Network Function (VNF) is quite interesting. My company (ADARA) uses reliable server pools in a product that provides Nf= V functions. We had demoed this product at ONS 2012, and have deployed por= tions of this product line in Enterprise customers. We really would prefer= to have a standardize reliable pool. Thank you for starting this effort. Sue Hares _______________________________________________ vnfpool mailing list vnfpool@ietf.org https://www.ietf.org/mailman/listinfo/vnfpool --_000_B0D29E0424F2DE47A0B36779EC666779257FE96Enkgeml501mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, Richar= d,

= ;

From: yang.r.yang@gmail.com [mailto:yang.r.yang@gmail.com] On Behalf Of Y. Richard Yang
Sent: Wednesday, September 18, 2013 11:33 AM
To: Zongning
Cc: Y. Richard Yang; N:; vnfpool@ietf.org
Subject: Re: [vnfpool] Great effort

Hi Ning,

On Sunday, September 15, 2013, Zongning wrote:

Hi, Richard,

Thank you for your inter= est and information!

Pointer to Zookeeper:

http://zookeeper.apache.org/<= span lang=3D"EN-US">

Some useful slides:

https://cwiki.apache.org/confluence/display/ZOOKEEPER/ZooKeeperPres= entations

I also see some similari= ty of design goal between Zookeeper service and Server Pool, both consist of multiple servers including leader and followers to provide= client reliable service. However, as you also mentioned, there are differe= nce in details such as name space – Zookeeper is based on file system= APIs, whilst RSerPool utilizes flat handle space (e.g. SIP, Web, etc). Another gap between Zookeeper and Reliable VNF= may be that Zookeeper basically targets on client-server mode =

zookeeper may not be limited to= client-server. It is a service for a pool of other servers to coordinate, = for example, to elect the next meta server.

= ;

[Ning] Yes= , you are right. Zookeeper service is for coordinating a set of servers whi= ch implement single application or multiple applications. But I am not sure if Zookeeper service also includes selecting appropriate= server(s) for any specific application? Considering the model of VNF pools= , there are multiple, distributed pools where each pool contains a set of s= ervers of a specific application. We probably need coordination service that synchronizes the status of the = servers within pool, across different pools, as well as selecting/replacing= servers for further chaining them together…

but Reliable VNF is actu= ally in a mode of directly connected servers with different functionalities.

Not clear about the meaning of&= nbsp;different functionalities. Here is a dummy logical model using wh= ich I am trying to make sense of the problem setting:

- the system consists of a set = of deployed service chains, sc1, sc2, sc3, ..., scN, where sci is a di= rected graph in the general case, and a sequence in a typical case; th= is set can be dynamic;

- there are modes, constra= ints, and policies placed on each service chain, such as there sh= ould be x active instances of sc_ij, which is the j-th element of the = service chain sc_i; sc_ij runs in single master + x-1 backup mode; sc_ij and sc_ik masters must be on the same subnet, ... Th= e parameters can be dynamic as applications scale;

The goal is to monitor the prec= eding, the reserves, start/stop/migrate to enforce the policies?<= /o:p>

= ;

[Ning] The= model is basically correct. The parameters need to reflect the policies. W= hen I say servers with different functionalities, I mean FW server, DPI server, etc… So I am not sure “sc_ij and sc_ik mus= t be on the same subnet” is correct statement?

Richard

Please correct me if I a= m wrong. J

I am think of documentin= g these implementations as well as the gaps to Reliable VNF in a draft…

-Ning

From: yang.r.yang@gmail.com [mailto:yang.r.yang@gmail.com] On Behalf Of Y. Richard Yang
Sent: Monday, September 16, 2013 3:22 AM
To: N:
Cc: vnfpool@ietf.org; Zongning
Subject: Re: [vnfpool] Great effort=

Dear all,

Very interesting work indeed. Sue made a good point= of using a standardized approach, which makes a lot of sense.

As I am getting to become familiar with RServPool, = when I first tried to think about the problem of reliable server pool, a sy= stem such as Zookeeper comes to mind, as it appears to be more publicized i= n academia. Is there a technical comparison between the two designs? At an entity level, I see similar entities. But t= he detailed designs appear to be different, e.g., hierarchical name space. = It will be a good study to look into such differences in the context of vnf= , given the interest. Does anyone have a pointer or this is a space that has not been explored.

Thanks.

Richard

On Sep 13, 2013 7:32 PM, "Susan Hares&qu= ot; <shares@ndzh.com> wrote:

Thomas:

The work in Reliab= le Server Pooling (RSerPool) may be quite interesting in the context of Vir= tualized Network Function (VNF) is quite interesting.

My company (ADARA)= uses reliable server pools in a product that provides NfV functions. = ;We had demoed this product at ONS 2012, and have deployed portions of this product line in Enterprise customers. = ;We really would prefer to have a standardize reliable pool.

Thank you for star= ting this effort.

Sue Hares

_______________________________________________
vnfpool mailing list
vnfpool@ietf.org
https://www.ietf.org/mailman/listinfo/vnfpool

--_000_B0D29E0424F2DE47A0B36779EC666779257FE96Enkgeml501mbschi_-- From narten@us.ibm.com Wed Sep 18 04:18:45 2013 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C2CE21F9C1D for ; Wed, 18 Sep 2013 04:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.49 X-Spam-Level: X-Spam-Status: No, score=-109.49 tagged_above=-999 required=5 tests=[AWL=1.109, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MqwFq6CR7Cc5 for ; Wed, 18 Sep 2013 04:18:38 -0700 (PDT) Received: from e39.co.us.ibm.com (e39.co.us.ibm.com [32.97.110.160]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC9111E8200 for ; Wed, 18 Sep 2013 04:18:38 -0700 (PDT) Received: from /spool/local by e39.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 18 Sep 2013 05:18:37 -0600 Received: from d03dlp01.boulder.ibm.com (9.17.202.177) by e39.co.us.ibm.com (192.168.1.139) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 18 Sep 2013 05:18:34 -0600 Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by d03dlp01.boulder.ibm.com (Postfix) with ESMTP id E08661FF001C for ; Wed, 18 Sep 2013 05:18:29 -0600 (MDT) Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r8IBIXJ8358116 for ; Wed, 18 Sep 2013 05:18:33 -0600 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r8IBLYRk027722 for ; Wed, 18 Sep 2013 05:21:34 -0600 Received: from cichlid.raleigh.ibm.com ([9.49.222.68]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r8IBLWMG027700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Sep 2013 05:21:33 -0600 Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id r8IBIVob026909; Wed, 18 Sep 2013 07:18:31 -0400 Message-Id: <201309181118.r8IBIVob026909@cichlid.raleigh.ibm.com> To: Linda Dunbar In-reply-to: <4A95BA014132FF49AE685FAB4B9F17F645BC97C5@dfweml509-mbx.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F645BC82F3@dfweml509-mbx.china.huawei.com> <201309172012.r8HKC3xZ016121@cichlid.raleigh.ibm.com> <4A95BA014132FF49AE685FAB4B9F17F645BC97C5@dfweml509-mbx.china.huawei.com> Comments: In-reply-to Linda Dunbar message dated "Tue, 17 Sep 2013 22:52:41 -0000." Date: Wed, 18 Sep 2013 07:18:31 -0400 From: Thomas Narten X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13091811-9332-0000-0000-00000174B303 Cc: "vnfpool@ietf.org" Subject: Re: [vnfpool] Will mutliple instances for one Network function be physically located together? X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.12 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, 18 Sep 2013 11:18:45 -0000 Linda, > > -----Original Message----- > > > > So, when we talk about services instance, I do not think we want > > assume or require that they be on the same subnet. > [Linda] With NVO3, instances of one subnet don't have to be > collocated. The scenario that I am thinking of is multiple > instances for the same function. For example, there are 100 FireWall > (FW) instances in the network. May be 2~4 FW instances are > designated for Client #i. Could those 2~4 instances for one client > be in one subnet? Sure they could. But we shouldn't assume they MUST be (or even will be). If folk want to put them into the same subnet (for whatever reason), that should be allowed. But we shouldn't assume this will always be done and then bake such an assumption into the architecture or protocols. > The same client could also have 3~4 instances of Web > Optimization. Are those 3~4 instances in one subnet. Maybe, maybe not. (Same argument as above.) Thomas From dreibh@iem.uni-due.de Wed Sep 18 14:50:38 2013 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4787511E8213 for ; Wed, 18 Sep 2013 14:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJ8A-RodGVaL for ; Wed, 18 Sep 2013 14:50:33 -0700 (PDT) Received: from mailout.uni-due.de (mailout.uni-due.de [132.252.185.19]) by ietfa.amsl.com (Postfix) with ESMTP id E938711E81AB for ; Wed, 18 Sep 2013 14:50:32 -0700 (PDT) Received: from lupo.localnet (cm-84.215.18.138.getinternet.no [84.215.18.138]) (authenticated bits=0) by mailout.uni-due.de (8.13.1/8.13.1) with ESMTP id r8ILoReT005143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 18 Sep 2013 23:50:29 +0200 From: Thomas Dreibholz To: "vnfpool@ietf.org" Date: Wed, 18 Sep 2013 23:50:27 +0200 Message-ID: <3010023.EW897T9yna@lupo> Organization: University of Duisburg-Essen, Institute for Experimental Mathematics User-Agent: KMail/4.11.1 (Linux/3.8.0-30-generic; KDE/4.11.1; x86_64; ; ) In-Reply-To: References: <1783683.ptHy5NI9HW@nordmarka.simula.nornet> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2658892.tkyeSYlfUU"; micalg="pgp-sha1"; protocol="application/pgp-signature" X-Virus-Scanned: Clam Anti Virus - http://www.clamav.net X-Spam-Scanned: SpamAssassin: 3.002004 - http://www.spamassassin.org X-Scanned-By: MIMEDefang 2.57 on 132.252.185.19 Subject: Re: [vnfpool] Information on Reliable Server Pooling (RSerPool) X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.12 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, 18 Sep 2013 21:50:38 -0000 --nextPart2658892.tkyeSYlfUU Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Torsdag 12. september 2013 03.58.06 skrev Zongning: > Hi, Thomas, >=20 > Thank you very much for sharing such useful information with us. I ha= ve > briefly browsed your website and found it is really impressive! I agree > that Server Pooling idea is quite interesting in the context of VNF. = We > will definitely look at its applicability to NFV. It is also great th= at you > have Open Source LIB for your implementation. =E2=98=BA I noticed tha= t you have > actually maintained several IETF drafts on the applicability & extens= ion of > Server Pooling to various use cases like distributed computing, mobil= ity. > Maybe now it is time to writing-up a draft on applicability to NFV? =E2= =98=BA Yes, this is a good idea. I will do that. It can, however, take a few d= ays.=20 But I will definitely do that. Does anybody want to join as a co-author? --=20 Best regards / Mit freundlichen Gr=C3=BC=C3=9Fen / 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 -----------------------------------------------------------------------= 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 --nextPart2658892.tkyeSYlfUU 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 v1.4.12 (GNU/Linux) iEYEABECAAYFAlI6ICMACgkQ32BbsHYPLWWf4ACgtLvcylMY1iu8oo+/mj5vyaKS Jv4AoLJJm7XKAvw+JXSBDMszuP65aopY =+XC0 -----END PGP SIGNATURE----- --nextPart2658892.tkyeSYlfUU-- From Michael.Tuexen@lurchi.franken.de Wed Sep 18 15:04:39 2013 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 024CB11E82D8 for ; Wed, 18 Sep 2013 15:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IAyrGaNU3XMt for ; Wed, 18 Sep 2013 15:04:38 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 06AB611E81CD for ; Wed, 18 Sep 2013 15:04:37 -0700 (PDT) Received: from [192.168.1.6] (p5481A442.dip0.t-ipconnect.de [84.129.164.66]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 2F74D1C0C069F; Thu, 19 Sep 2013 00:04:35 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.6 $1510$) From: Michael Tuexen In-Reply-To: <3010023.EW897T9yna@lupo> Date: Thu, 19 Sep 2013 00:04:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <58390E26-085F-4F93-8E4C-21645D32A128@lurchi.franken.de> References: <1783683.ptHy5NI9HW@nordmarka.simula.nornet> <3010023.EW897T9yna@lupo> To: Thomas Dreibholz X-Mailer: Apple Mail (2.1510) Cc: "vnfpool@ietf.org" Subject: Re: [vnfpool] Information on Reliable Server Pooling (RSerPool) X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.12 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, 18 Sep 2013 22:04:39 -0000 On Sep 18, 2013, at 11:50 PM, Thomas Dreibholz = wrote: > Torsdag 12. september 2013 03.58.06 skrev Zongning: >> Hi, Thomas, >>=20 >> Thank you very much for sharing such useful information with us. I = have >> briefly browsed your website and found it is really impressive! > I agree >> that Server Pooling idea is quite interesting in the context of VNF. = We >> will definitely look at its applicability to NFV. It is also great = that you >> have Open Source LIB for your implementation. =E2=98=BA I noticed = that you have >> actually maintained several IETF drafts on the applicability & = extension of >> Server Pooling to various use cases like distributed computing, = mobility. >> Maybe now it is time to writing-up a draft on applicability to NFV? = =E2=98=BA >=20 > Yes, this is a good idea. I will do that. It can, however, take a few = days.=20 > But I will definitely do that. >=20 > Does anybody want to join as a co-author? I can help if you want... Being pretty busy right now, but we should be able to have an ID ready before the Vancouver time frame. Best regards Michael >=20 > --=20 > Best regards / Mit freundlichen Gr=C3=BC=C3=9Fen / Med vennlig hilsen >=20 > = =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 >=20 > 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 > = ----------------------------------------------------------------------- > 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___________= ____________________________________ > vnfpool mailing list > vnfpool@ietf.org > https://www.ietf.org/mailman/listinfo/vnfpool From dreibh@simula.no Wed Sep 18 14:46:21 2013 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE9CD11E81BC for ; Wed, 18 Sep 2013 14:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.185 X-Spam-Level: X-Spam-Status: No, score=-1.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJ75lXVK79yl for ; Wed, 18 Sep 2013 14:45:59 -0700 (PDT) Received: from mail-la0-f49.google.com (mail-la0-f49.google.com [209.85.215.49]) by ietfa.amsl.com (Postfix) with ESMTP id 9878011E81AD for ; Wed, 18 Sep 2013 14:45:57 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id ev20so6132655lab.22 for ; Wed, 18 Sep 2013 14:45:56 -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:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version:content-type; bh=yVGRtyKTi0wlE8dBfkaG2HDiQVszWGRAwRXBUmVR9YM=; b=ScmJtCGtSXRvTHid0lSVBrtOKGrgo7SddvPN9dRedEJ2Yupc3T2lx9E58OV1WPs8Ti T0cqoh9idTcL2Aq58s4rNhew29+K89GHPDwCoU/hCcnK25cHhFu4NG8K7HSpWv7tmDpw sB+mY+pFLTJbfOY8BW+YAZyp7iymJxa/YPMMcqkTshQCJVhKI7071lusoaUJlUxFjlCc zgiF2+wcbTUKT7XD8iGXuAHdp4bCtMJSmx91cAC5jAFdP4oAYhlbBxKi/ymGLnUmNaAU Q8cxBZwXd7UStWyqyetXeNEXVAa8nqw/CIjRQxZxhKA9jSwtVZhS1LJeG1K3hyknyubY Y3Qw== X-Gm-Message-State: ALoCoQkHzzyuD1G95Hh6os6Ha6WH1efFZtMzYYFEf162T9uZhREwRgjIQCf2tq+lXs1EAUWAMFSc X-Received: by 10.112.53.130 with SMTP id b2mr7464635lbp.6.1379540756641; Wed, 18 Sep 2013 14:45:56 -0700 (PDT) Received: from lupo.localnet (cm-84.215.18.138.getinternet.no. [84.215.18.138]) by mx.google.com with ESMTPSA id ao4sm1979398lac.1.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 18 Sep 2013 14:45:54 -0700 (PDT) From: Thomas Dreibholz To: Zongning Date: Wed, 18 Sep 2013 23:45:50 +0200 Message-ID: <1449541.2kI6LaBuB0@lupo> Organization: Simula Research Laboratory User-Agent: KMail/4.11.1 (Linux/3.8.0-30-generic; KDE/4.11.1; x86_64; ; ) In-Reply-To: References: <1783683.ptHy5NI9HW@nordmarka.simula.nornet> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3295641.nyavIQRjCd"; micalg="pgp-sha1"; protocol="application/pgp-signature" X-Mailman-Approved-At: Wed, 18 Sep 2013 17:47:46 -0700 Cc: "vnfpool@ietf.org" , "hakim.adhari@uni-due.de" , "tuexen@fh-muenster.de" , "ferlin@simula.no" , "martin.becke@uni-due.de" , "amundk@simula.no" Subject: Re: [vnfpool] Information on Reliable Server Pooling (RSerPool) X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.12 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, 18 Sep 2013 21:46:21 -0000 --nextPart3295641.nyavIQRjCd Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Torsdag 12. september 2013 03.58.06 skrev Zongning: > Hi, Thomas, >=20 > Thank you very much for sharing such useful information with us. I ha= ve > briefly browsed your website and found it is really impressive! I agree > that Server Pooling idea is quite interesting in the context of VNF. = We > will definitely look at its applicability to NFV. It is also great th= at you > have Open Source LIB for your implementation. =E2=98=BA I noticed tha= t you have > actually maintained several IETF drafts on the applicability & extens= ion of > Server Pooling to various use cases like distributed computing, mobil= ity. > Maybe now it is time to writing-up a draft on applicability to NFV? =E2= =98=BA Yes, this is a good idea. I will do that. It can, however, take a few d= ays.=20 But I will definitely do that. Does anybody want to join as a co-author? --=20 Best regards / Mit freundlichen Gr=C3=BC=C3=9Fen / 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 -----------------------------------------------------------------------= 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 --nextPart3295641.nyavIQRjCd 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 v1.4.12 (GNU/Linux) iEYEABECAAYFAlI6Hw4ACgkQ32BbsHYPLWWoFwCgl6DdrBtU1Z3Yxe4BL2W1GBSb a/wAoN+rH7we32mlijXKcBg7lc2vf1HB =o4CD -----END PGP SIGNATURE----- --nextPart3295641.nyavIQRjCd-- From zongning@huawei.com Wed Sep 18 19:36:54 2013 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 460E311E8187 for ; Wed, 18 Sep 2013 19:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.373 X-Spam-Level: X-Spam-Status: No, score=-106.373 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5LvVqUHORnM for ; Wed, 18 Sep 2013 19:36:50 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id CF7C511E817F for ; Wed, 18 Sep 2013 19:36:49 -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 AXZ54144; Thu, 19 Sep 2013 02:36:41 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 19 Sep 2013 03:36:06 +0100 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 19 Sep 2013 03:36:38 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.141]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0146.000; Thu, 19 Sep 2013 10:36:31 +0800 From: Zongning To: Michael Tuexen , Thomas Dreibholz Thread-Topic: [vnfpool] Information on Reliable Server Pooling (RSerPool) Thread-Index: AQHOr1E1LAkKdV+qJEe3Y5CnJC6IXpnBbchQgAofpYCAAAPxAIAA0Eig Date: Thu, 19 Sep 2013 02:36:30 +0000 Message-ID: References: <1783683.ptHy5NI9HW@nordmarka.simula.nornet> <3010023.EW897T9yna@lupo> <58390E26-085F-4F93-8E4C-21645D32A128@lurchi.franken.de> In-Reply-To: <58390E26-085F-4F93-8E4C-21645D32A128@lurchi.franken.de> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.99.192.41] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "vnfpool@ietf.org" Subject: [vnfpool] =?utf-8?b?562U5aSNOiAgSW5mb3JtYXRpb24gb24gUmVsaWFibGUg?= =?utf-8?q?Server_Pooling_=28RSerPool=29?= X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.12 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, 19 Sep 2013 02:36:54 -0000 SGksIE1pY2hhZWwgYW5kIFRob21hcywNCg0KVGhhbmsgeW91IHNvIG11Y2ggZm9yIHRha2luZyBs ZWFkIG9mIHRoZSBkcmFmdCBhYm91dCBhcHBsaWNhYmlsaXR5IG9mIFJTZXJQb29sIHRvIFZORiBQ b29scy4gVGhpcyBpcyBpbXBvcnRhbnQgdG8gcmVsaWFibGUgVk5GIGlzc3Vlcy4NCkkgYW0gYWxz byBwbGVhc2VkIHRvIGdpdmUgYW55IGhlbHAgeW91IHdhbnQgZnJvbSBteSBzaWRlLg0KDQotTmlu Zw0KDQotLS0tLemCruS7tuWOn+S7ti0tLS0tDQrlj5Hku7bkuro6IHZuZnBvb2wtYm91bmNlc0Bp ZXRmLm9yZyBbbWFpbHRvOnZuZnBvb2wtYm91bmNlc0BpZXRmLm9yZ10g5Luj6KGoIE1pY2hhZWwg VHVleGVuDQrlj5HpgIHml7bpl7Q6IDIwMTPlubQ55pyIMTnml6UgNjowNQ0K5pS25Lu25Lq6OiBU aG9tYXMgRHJlaWJob2x6DQrmioTpgIE6IHZuZnBvb2xAaWV0Zi5vcmcNCuS4u+mimDogUmU6IFt2 bmZwb29sXSBJbmZvcm1hdGlvbiBvbiBSZWxpYWJsZSBTZXJ2ZXIgUG9vbGluZyAoUlNlclBvb2wp DQoNCk9uIFNlcCAxOCwgMjAxMywgYXQgMTE6NTAgUE0sIFRob21hcyBEcmVpYmhvbHogPGRyZWli aEBpZW0udW5pLWR1ZS5kZT4gd3JvdGU6DQoNCj4gVG9yc2RhZyAxMi4gc2VwdGVtYmVyIDIwMTMg MDMuNTguMDYgc2tyZXYgWm9uZ25pbmc6DQo+PiBIaSwgVGhvbWFzLA0KPj4gDQo+PiBUaGFuayB5 b3UgdmVyeSBtdWNoIGZvciBzaGFyaW5nIHN1Y2ggdXNlZnVsIGluZm9ybWF0aW9uIHdpdGggdXMu IEkgDQo+PiBoYXZlIGJyaWVmbHkgYnJvd3NlZCB5b3VyIHdlYnNpdGUgYW5kIGZvdW5kIGl0IGlz IHJlYWxseSBpbXByZXNzaXZlIQ0KPiBJIGFncmVlDQo+PiB0aGF0IFNlcnZlciBQb29saW5nIGlk ZWEgaXMgcXVpdGUgaW50ZXJlc3RpbmcgaW4gdGhlIGNvbnRleHQgb2YgVk5GLiANCj4+IFdlIHdp bGwgZGVmaW5pdGVseSBsb29rIGF0IGl0cyBhcHBsaWNhYmlsaXR5IHRvIE5GVi4gSXQgaXMgYWxz byBncmVhdCANCj4+IHRoYXQgeW91IGhhdmUgT3BlbiBTb3VyY2UgTElCIGZvciB5b3VyIGltcGxl bWVudGF0aW9uLiDimLogSSBub3RpY2VkIA0KPj4gdGhhdCB5b3UgaGF2ZSBhY3R1YWxseSBtYWlu dGFpbmVkIHNldmVyYWwgSUVURiBkcmFmdHMgb24gdGhlIA0KPj4gYXBwbGljYWJpbGl0eSAmIGV4 dGVuc2lvbiBvZiBTZXJ2ZXIgUG9vbGluZyB0byB2YXJpb3VzIHVzZSBjYXNlcyBsaWtlIGRpc3Ry aWJ1dGVkIGNvbXB1dGluZywgbW9iaWxpdHkuDQo+PiBNYXliZSBub3cgaXQgaXMgdGltZSB0byB3 cml0aW5nLXVwIGEgZHJhZnQgb24gYXBwbGljYWJpbGl0eSB0byBORlY/IOKYug0KPiANCj4gWWVz LCB0aGlzIGlzIGEgZ29vZCBpZGVhLiBJIHdpbGwgZG8gdGhhdC4gSXQgY2FuLCBob3dldmVyLCB0 YWtlIGEgZmV3IGRheXMuIA0KPiBCdXQgSSB3aWxsIGRlZmluaXRlbHkgZG8gdGhhdC4NCj4gDQo+ IERvZXMgYW55Ym9keSB3YW50IHRvIGpvaW4gYXMgYSBjby1hdXRob3I/DQpJIGNhbiBoZWxwIGlm IHlvdSB3YW50Li4uIEJlaW5nIHByZXR0eSBidXN5IHJpZ2h0IG5vdywgYnV0IHdlIHNob3VsZCBi ZSBhYmxlIHRvIGhhdmUgYW4gSUQgcmVhZHkgYmVmb3JlIHRoZSBWYW5jb3V2ZXIgdGltZSBmcmFt ZS4NCg0KQmVzdCByZWdhcmRzDQpNaWNoYWVsDQo+IA0KPiAtLQ0KPiBCZXN0IHJlZ2FyZHMgLyBN aXQgZnJldW5kbGljaGVuIEdyw7zDn2VuIC8gTWVkIHZlbm5saWcgaGlsc2VuDQo+IA0KPiA9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09DQo+ID0NCj4gVGhvbWFzIERyZWliaG9seg0KPiANCj4gU2ltdWxhIFJlc2VhcmNo IExhYm9yYXRvcnkNCj4gU2ltdWxhIElubm92YXRpb24gQVMsIE5ldHdvcmsgU3lzdGVtcyBHcm91 cCBWaXNpdGluZyBhZGRyZXNzOiBNYXJ0aW4gDQo+IExpbmdlcyB2ZWkgMTcsIDEzNjQgRm9ybmVi dSwgTm9yd2F5IE1haWxpbmcgYWRkcmVzczogIFAuTy5Cb3ggMTM0LCANCj4gMTMyNSBMeXNha2Vy LCBOb3J3YXkNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gRS1NYWlsOiAgICAgZHJlaWJoQHNpbXVsYS5u bw0KPiBIb21lcGFnZTogICBodHRwOi8vc2ltdWxhLm5vL3Blb3BsZS9kcmVpYmgNCj4gPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQ0KPiA9X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gdm5mcG9vbCBtYWlsaW5nIGxpc3QNCj4gdm5mcG9vbEBpZXRmLm9yZw0KPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3ZuZnBvb2wNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnZuZnBvb2wgbWFpbGluZyBsaXN0DQp2 bmZwb29sQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Zu ZnBvb2wNCg== From zongning@huawei.com Sun Sep 22 20:57:31 2013 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8559221F9C9B for ; Sun, 22 Sep 2013 20:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.578 X-Spam-Level: X-Spam-Status: No, score=-106.578 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Q+7jNRxVpOG for ; Sun, 22 Sep 2013 20:57:26 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 88DE821F9CA4 for ; Sun, 22 Sep 2013 20:57:25 -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 AYD24880; Mon, 23 Sep 2013 03:57:21 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 23 Sep 2013 04:56:36 +0100 Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 23 Sep 2013 04:57:21 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.141]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0146.000; Mon, 23 Sep 2013 11:57:16 +0800 From: Zongning To: "vnfpool@ietf.org" Thread-Topic: Manage PE list in RSerPool Thread-Index: Ac64EP03+QgWZuqPQA+Els5sBoKssA== Date: Mon, 23 Sep 2013 03:57:15 +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.48] Content-Type: multipart/alternative; boundary="_000_B0D29E0424F2DE47A0B36779EC666779257FF653nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [vnfpool] Manage PE list in RSerPool X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.12 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, 23 Sep 2013 03:57:31 -0000 --_000_B0D29E0424F2DE47A0B36779EC666779257FF653nkgeml501mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, When reading some RSerPool documents, I noticed there are several mechanism= s proposed to manage pool element (PE) list. One is that a pool user (PU) fetches a PE list from pool registrar (PR) to = store the list locally, then selects and connects to a PE. When the selecte= d PE fails, PU will connect to another PE from the list to continue the ser= vice. Another is that the PE can tell the PU backup PEs via business card message= when they are communicating. In this way, when the PE fails, PU will conne= ct to a backup PE obtained from the business card message. I am not sure about the relation between these two PE lists. Are they neces= sarily consistent? I.e. if the PR needs to tell exactly the same list (as t= he one returned to the PU) to the PE for constructing business card message= ? Or they actually serve totally different purpose, but still related? Moreover, considering the dynamic situation of VNF instances, the PE list s= tored in PU could be more dynamic than before. In such case, I suppose an "= active push" mechanism maybe useful to be adopted by both PR and PE when te= lling PU some updates happened to PE list. How do you think? Thanks. -Ning --_000_B0D29E0424F2DE47A0B36779EC666779257FF653nkgeml501mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

When reading some RSerPool docu= ments, I noticed there are several mechanisms proposed to manage pool eleme= nt (PE) list.

One is that a pool user (PU) fe= tches a PE list from pool registrar (PR) to store the list locally, then se= lects and connects to a PE. When the selected PE fails, PU will connect to = another PE from the list to continue the service.

Another is that the PE can tell= the PU backup PEs via business card message when they are communicating. I= n this way, when the PE fails, PU will connect to a backup PE obtained from= the business card message.

I am not sure about the relatio= n between these two PE lists. Are they necessarily consistent? I.e. if the = PR needs to tell exactly the same list (as the one returned to the PU) to t= he PE for constructing business card message? Or they actually serve totally different purpose, but still relat= ed?

Moreover, considering the dynam= ic situation of VNF instances, the PE list stored in PU could be more dynam= ic than before. In such case, I suppose an “active push” mechan= ism maybe useful to be adopted by both PR and PE when telling PU some updates happened to PE list. How do you think?

Thanks.

-Ning

--_000_B0D29E0424F2DE47A0B36779EC666779257FF653nkgeml501mbschi_-- From zongning@huawei.com Thu Sep 26 00:09:45 2013 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7A0121F92B5 for ; Thu, 26 Sep 2013 00:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.574 X-Spam-Level: X-Spam-Status: No, score=-106.574 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mo-fKJvb0S5N for ; Thu, 26 Sep 2013 00:09:40 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 94C2E11E8163 for ; Thu, 26 Sep 2013 00:09:37 -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 AYH17902; Thu, 26 Sep 2013 07:09:30 +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.146.0; Thu, 26 Sep 2013 08:08:33 +0100 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 26 Sep 2013 08:09:26 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.141]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0146.000; Thu, 26 Sep 2013 15:09:20 +0800 From: Zongning To: "vnfpool@ietf.org" , "dreibh@iem.uni-due.de" , Michael Tuexen , Melinda Shore Thread-Topic: pool manager for state sync? Thread-Index: Ac66h1HMX7pbFCVaTZ+baY7io23gIQ== Date: Thu, 26 Sep 2013 07:09:20 +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.48] Content-Type: multipart/alternative; boundary="_000_B0D29E0424F2DE47A0B36779EC66677925800111nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [vnfpool] pool manager for state sync? X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.12 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, 26 Sep 2013 07:09:45 -0000 --_000_B0D29E0424F2DE47A0B36779EC66677925800111nkgeml501mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, all, In current RSerPool mechanism, the service states (for stateful service lik= e FW) are synchronized between active and backup servers via the relay of p= ool user. This approach works fine assuming that pool user is stable. Consi= der the VNF pools model where a pool user (i.e. user of downstream pool acc= ording to service chain) is normally a VNF instance in its own pool, and po= ol user and even its backup instances are likely less stable. As such, stor= ing critical service states information in VNF instances would be a problem= . I'd think a feasible approach would be to use pool manager for service st= ates synchronization, e.g. retrieving, storing, distributing service states= amongst VNF instances? Comments are highly appreciated! -Ning --_000_B0D29E0424F2DE47A0B36779EC66677925800111nkgeml501mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, all,

In current RSerPool mechanism, = the service states (for stateful service like FW) are synchronized between = active and backup servers via the relay of pool user. This approach works f= ine assuming that pool user is stable. Consider the VNF pools model where a pool user (i.e. user of downstream po= ol according to service chain) is normally a VNF instance in its own pool, = and pool user and even its backup instances are likely less stable. As such= , storing critical service states information in VNF instances would be a problem. I’d think a feasibl= e approach would be to use pool manager for service states synchronization,= e.g. retrieving, storing, distributing service states amongst VNF instance= s?

Comments are highly appreciated= !

-Ning

--_000_B0D29E0424F2DE47A0B36779EC66677925800111nkgeml501mbschi_-- From dreibh@iem.uni-due.de Mon Sep 30 00:35:00 2013 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3053621F8793 for ; Mon, 30 Sep 2013 00:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.949 X-Spam-Level: X-Spam-Status: No, score=-0.949 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sCtXMHtWFr-9 for ; Mon, 30 Sep 2013 00:34:55 -0700 (PDT) Received: from mailout.uni-due.de (mailout.uni-due.de [132.252.185.19]) by ietfa.amsl.com (Postfix) with ESMTP id D105221F87B7 for ; Mon, 30 Sep 2013 00:34:54 -0700 (PDT) Received: from nordmarka.simula.nornet ([158.39.4.2]) (authenticated bits=0) by mailout.uni-due.de (8.13.1/8.13.1) with ESMTP id r8U7YpNu014244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 30 Sep 2013 09:34:52 +0200 From: Thomas Dreibholz To: Michael Tuexen Date: Mon, 30 Sep 2013 09:34:50 +0200 Message-ID: <2975598.eeKVXPZDzc@nordmarka.simula.nornet> User-Agent: KMail/4.11.1 (Linux/3.8.0-30-generic; KDE/4.11.1; x86_64; ; ) In-Reply-To: <58390E26-085F-4F93-8E4C-21645D32A128@lurchi.franken.de> References: <1783683.ptHy5NI9HW@nordmarka.simula.nornet> <3010023.EW897T9yna@lupo> <58390E26-085F-4F93-8E4C-21645D32A128@lurchi.franken.de> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4067096.R6dNZ2Tv9R"; micalg="pgp-sha1"; protocol="application/pgp-signature" X-Virus-Scanned: Clam Anti Virus - http://www.clamav.net X-Spam-Scanned: SpamAssassin: 3.002004 - http://www.spamassassin.org X-Scanned-By: MIMEDefang 2.57 on 132.252.185.19 Cc: "vnfpool@ietf.org" Subject: Re: [vnfpool] Information on Reliable Server Pooling (RSerPool) X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.12 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, 30 Sep 2013 07:35:00 -0000 --nextPart4067096.R6dNZ2Tv9R Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Hi, we should have an SVN server to manage the draft XML file. Michael, cou= ld we=20 use your server for that purpose? I could then check in a template docu= ment=20 and we can discuss on the document structure. Torsdag 19. september 2013 00.04.34 skrev Michael Tuexen: > On Sep 18, 2013, at 11:50 PM, Thomas Dreibholz =20 wrote: > > Torsdag 12. september 2013 03.58.06 skrev Zongning: > >> Hi, Thomas, > >>=20 > >> Thank you very much for sharing such useful information with us. I= have > >> briefly browsed your website and found it is really impressive! > >=20 > > I agree > >=20 > >> that Server Pooling idea is quite interesting in the context of VN= F. We > >> will definitely look at its applicability to NFV. It is also great= that > >> you > >> have Open Source LIB for your implementation. =E2=98=BA I noticed = that you have > >> actually maintained several IETF drafts on the applicability & ext= ension > >> of > >> Server Pooling to various use cases like distributed computing, mo= bility. > >> Maybe now it is time to writing-up a draft on applicability to NFV= ? =E2=98=BA > >=20 > > Yes, this is a good idea. I will do that. It can, however, take a f= ew > > days. > > But I will definitely do that. > >=20 > > Does anybody want to join as a co-author? >=20 > I can help if you want... Being pretty busy right now, but we should > be able to have an ID ready before the Vancouver time frame. >=20 > Best regards > Michael --=20 Best regards / Mit freundlichen Gr=C3=BC=C3=9Fen / 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 -----------------------------------------------------------------------= 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 --nextPart4067096.R6dNZ2Tv9R 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 v1.4.12 (GNU/Linux) iEYEABECAAYFAlJJKZoACgkQ32BbsHYPLWXHbgCfVDfIcOlueZ1k+gD0VCQzqODV cXAAn3S2U3VpDfSTuExZk5utgsfei57D =GEpn -----END PGP SIGNATURE----- --nextPart4067096.R6dNZ2Tv9R-- From melinda.shore@gmail.com Mon Sep 30 00:41:12 2013 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE0B21F9991 for ; Mon, 30 Sep 2013 00:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a6u6OMTwAj+h for ; Mon, 30 Sep 2013 00:41:11 -0700 (PDT) Received: from mail-pb0-x232.google.com (mail-pb0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 9588921F91BF for ; Mon, 30 Sep 2013 00:41:11 -0700 (PDT) Received: by mail-pb0-f50.google.com with SMTP id uo5so5188444pbc.23 for ; Mon, 30 Sep 2013 00:41:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=XRvIowDEuVIBNKolA9F+wobyI6lXi9wng9WgfZuJ18o=; b=o0KKh/3uOeqlc//FHuWgL7beOwu1/jM05c1ybbRMZc3uLRDOS8py9uRF1KqKggDV5d d4yjHrhCwcjXcmAo8Q4z2sygaUGfEuuwCpWsZDLrk/R/M8OKzrGTlSmCn251KwH7pnTQ FRTVwUalE6lgGxLrIY8Z9US8wrYa8AHQnWmZ+jJRpmBxFrrV6+oqNtktJbmCIhMRG86Z Z49IYA5IAWiDATSn9MFooIDLHrKMjCS095R+5UDOkoSVV1ToqORAQq3xgh88Ffr/w20+ kTglDqywAhAx7UGgo0RxgEjjAb0sKj0ya8uBrfWkm+qRzMIgXrrGP3gBGR84lBPgDYao Qvbg== X-Received: by 10.68.252.106 with SMTP id zr10mr22541582pbc.63.1380526871321; Mon, 30 Sep 2013 00:41:11 -0700 (PDT) Received: from spandex.local (63-140-92-59.dynamic.dsl.acsalaska.net. [63.140.92.59]) by mx.google.com with ESMTPSA id vz4sm31212385pab.11.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 30 Sep 2013 00:41:09 -0700 (PDT) Message-ID: <52492B13.9060103@gmail.com> Date: Sun, 29 Sep 2013 23:41: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: vnfpool@ietf.org References: <1783683.ptHy5NI9HW@nordmarka.simula.nornet> <3010023.EW897T9yna@lupo> <58390E26-085F-4F93-8E4C-21645D32A128@lurchi.franken.de> <2975598.eeKVXPZDzc@nordmarka.simula.nornet> In-Reply-To: <2975598.eeKVXPZDzc@nordmarka.simula.nornet> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [vnfpool] Information on Reliable Server Pooling (RSerPool) X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.12 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, 30 Sep 2013 07:41:12 -0000 On 9/29/13 11:34 PM, Thomas Dreibholz wrote: > we should have an SVN server to manage the draft XML file. Michael, could we > use your server for that purpose? I could then check in a template document > and we can discuss on the document structure. I've used github for several documents and it's been good. I'd like to encourage people to double-check that whatever server they use for this sort of thing is accessible from China. Melinda From dreibh@simula.no Mon Sep 30 00:45:16 2013 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57BAE21F9BC1 for ; Mon, 30 Sep 2013 00:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p3PlX1HA8dCG for ; Mon, 30 Sep 2013 00:45:11 -0700 (PDT) Received: from mail-bk0-f49.google.com (mail-bk0-f49.google.com [209.85.214.49]) by ietfa.amsl.com (Postfix) with ESMTP id D0F0821F9B65 for ; Mon, 30 Sep 2013 00:45:10 -0700 (PDT) Received: by mail-bk0-f49.google.com with SMTP id r7so1832827bkg.36 for ; Mon, 30 Sep 2013 00:45:08 -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:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version:content-type; bh=XMairfijmCmPgn4g+UL+wI8+72CakELFOEND3/8elqE=; b=LErzvpRfqPgp4TToEvU9aTJB3YR6rUG9AsnGWLju3dS9t5d4w8wZwp7OGZFgygMkvJ j5lH2WhzieEZJuK1erDRpNJFteULmuoR2KdJ8TeAvmZ4Ia78+ni2tHYFO7YmvyIgUUyp T1iXiD/Vmf5qYWJwFvo9ESbTMjLS3GbPkjPyhUgZ3TKzh2XNTIXMJFtvkxXOYe+ANrQ+ NQyALh2drWuaHI95PX5FIks1Ok5AtsquFwM3PI0rbzf/cHC/9XNfqQYtfhdcigL2XMOA vIRPgJIXo4Tt1Mn/HcSXL7GrhuHWNwTfcpvHOgIVDDAF5Qh2ddyVRz9rA6d1siLjCBpr EFYg== X-Gm-Message-State: ALoCoQmfqIIqR2+VPvyah+fDnhM7ZPfePFncYHCOJpeyRr6nPtmJYyQx0b9AU7lFyZ9NUaBVs3Q0 X-Received: by 10.204.121.201 with SMTP id i9mr18035923bkr.13.1380527108387; Mon, 30 Sep 2013 00:45:08 -0700 (PDT) Received: from nordmarka.simula.nornet ([2001:700:4100:201::33]) by mx.google.com with ESMTPSA id z6sm11433509bkn.8.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 30 Sep 2013 00:45:07 -0700 (PDT) From: Thomas Dreibholz To: vnfpool@ietf.org Date: Mon, 30 Sep 2013 09:45:05 +0200 Message-ID: <1781180.CsCHZbxtHu@nordmarka.simula.nornet> Organization: Simula Research Laboratory User-Agent: KMail/4.11.1 (Linux/3.8.0-30-generic; KDE/4.11.1; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart21577460.A89CLh1CBP"; micalg="pgp-sha1"; protocol="application/pgp-signature" Cc: Zongning Subject: Re: [vnfpool] Manage PE list in RSerPool X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.12 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, 30 Sep 2013 07:45:16 -0000 --nextPart21577460.A89CLh1CBP Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Mandag 23. september 2013 03.57.15 skrev Zongning: > Hi, >=20 > When reading some RSerPool documents, I noticed there are several mec= hanisms > proposed to manage pool element (PE) list. One is that a pool user (P= U) > fetches a PE list from pool registrar (PR) to store the list locally,= then > selects and connects to a PE. When the selected PE fails, PU will con= nect > to another PE from the list to continue the service. Another is that = the PE > can tell the PU backup PEs via business card message when they are > communicating. In this way, when the PE fails, PU will connect to a b= ackup > PE obtained from the business card message. I am not sure about the > relation between these two PE lists. Are they necessarily consistent?= I.e. No, the PE can decide on what to send in the ASAP Business Card to the = PU.=20 That is, it is independent of the information stored by the PRs. > if the PR needs to tell exactly the same list (as the one returned to= the > PU) to the PE for constructing business card message? Or they actuall= y > serve totally different purpose, but still related?=20 The content of the ASAP Business Card may be specific for a certain ses= sion.=20 That is, depending on the redundancy configuration, the PE may tell the= PU=20 certain other PEs to fail over to in case of its own failure. This info= rmation=20 may only be valid for the session (for which the Business Card is sent)= =20 itself. > Moreover, considering > the dynamic situation of VNF instances, the PE list stored in PU coul= d be > more dynamic than before. In such case, I suppose an "active push" > mechanism maybe useful to be adopted by both PR and PE when telling P= U some > updates happened to PE list. How do you think? Thanks. An ASAP Business Card may be sent at any time the PE decides. Therefore= , a new=20 one can be sent as soon as information needs to be updated. The ASAP Handle Resolution also provides the possibility to register fo= r=20 active pushes from a PR. That is, once the information for a pool chang= es, a=20 PU will receive an update. --=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 -----------------------------------------------------------------------= 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 --nextPart21577460.A89CLh1CBP 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 v1.4.12 (GNU/Linux) iEYEABECAAYFAlJJLAEACgkQ32BbsHYPLWXQPQCfTi2foiViHxyS0/KKkDKAb1d2 FEgAn1hgzxFWvbjxQH4KNwAxTww2DaC6 =OG+h -----END PGP SIGNATURE----- --nextPart21577460.A89CLh1CBP-- From dreibh@simula.no Mon Sep 30 00:47:42 2013 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1ED021F9BC2 for ; Mon, 30 Sep 2013 00:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Gj641A-XNi9 for ; Mon, 30 Sep 2013 00:47:37 -0700 (PDT) Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com [209.85.214.43]) by ietfa.amsl.com (Postfix) with ESMTP id 6826121F84DB for ; Mon, 30 Sep 2013 00:47:37 -0700 (PDT) Received: by mail-bk0-f43.google.com with SMTP id mz13so1916493bkb.30 for ; Mon, 30 Sep 2013 00:47:36 -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:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version:content-type; bh=5ITzOZ6dobEkDJ6H+P1aNKr2bpsgaZ0otEEXUwzTID4=; b=MalUYt1EUjBIUIVyBAK/NcOoY71xI5G7tkX8sI4J3AgJA4VJy/AUPEXfUbGlcO9pn9 4C+UHF0xZ1IQZfGnybeRIt8NuxRt8M1531vWnYEaOFN+blCUGvIO0LRCY6sFY338Wemh O8YZuy06nHUArwboMNKkqvNlbSSOGa0JNwFY6/TKDJzen8vMVLpI9Z5k5zRazd7n55Ca X2+2HxJYNe0zmiRJSWkTGItsXwYTypEeQHt9mRGHTqWAc7QlM51iS9gb8VdcCZuEL2U0 GwdoEgWAH+27EL5DX1DU62352XfHIMw1lQ2WlORdOOKgHCV/XxFe++3AdUOYCRnNDty6 bVcQ== X-Gm-Message-State: ALoCoQmPCoP8u3xp8s1w2prSghI37LEzxPlwajFK52B681Q+6XgudLuDUOw1lNKrRpHSGs0ovJUI X-Received: by 10.205.87.12 with SMTP id au12mr415859bkc.34.1380527256383; Mon, 30 Sep 2013 00:47:36 -0700 (PDT) Received: from nordmarka.simula.nornet ([2001:700:4100:201::33]) by mx.google.com with ESMTPSA id qg7sm11441426bkb.6.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 30 Sep 2013 00:47:35 -0700 (PDT) From: Thomas Dreibholz To: vnfpool@ietf.org Date: Mon, 30 Sep 2013 09:47:34 +0200 Message-ID: <15874853.GtDRjEN4kM@nordmarka.simula.nornet> Organization: Simula Research Laboratory User-Agent: KMail/4.11.1 (Linux/3.8.0-30-generic; KDE/4.11.1; x86_64; ; ) In-Reply-To: <52492B13.9060103@gmail.com> References: <1783683.ptHy5NI9HW@nordmarka.simula.nornet> <2975598.eeKVXPZDzc@nordmarka.simula.nornet> <52492B13.9060103@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1444773.l7FGHObWhE"; micalg="pgp-sha1"; protocol="application/pgp-signature" Cc: Melinda Shore Subject: Re: [vnfpool] Information on Reliable Server Pooling (RSerPool) X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.12 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, 30 Sep 2013 07:47:43 -0000 --nextPart1444773.l7FGHObWhE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Hi, S=F8ndag 29. september 2013 23.41.07 skrev Melinda Shore: > On 9/29/13 11:34 PM, Thomas Dreibholz wrote: > > we should have an SVN server to manage the draft XML file. Michael,= could > > we use your server for that purpose? I could then check in a templa= te > > document and we can discuss on the document structure. >=20 > I've used github for several documents and it's been good. > I'd like to encourage people to double-check that whatever > server they use for this sort of thing is accessible from > China. GitHub is fine for me, too. Do you already have a repository there? Oth= erwise,=20 I would create one. --=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 -----------------------------------------------------------------------= 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 --nextPart1444773.l7FGHObWhE 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 v1.4.12 (GNU/Linux) iEYEABECAAYFAlJJLJYACgkQ32BbsHYPLWXGcACdHF5n/j9YYAz6+QbR3SWiUPSA 09YAnRPdzf4TEf2lbEJdQ+NNJLG3VOZN =iExk -----END PGP SIGNATURE----- --nextPart1444773.l7FGHObWhE-- From dreibh@iem.uni-due.de Mon Sep 30 00:53:47 2013 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D32321F9B8D for ; Mon, 30 Sep 2013 00:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWB2ebCyBcKw for ; Mon, 30 Sep 2013 00:53:42 -0700 (PDT) Received: from mailout.uni-due.de (mailout.uni-due.de [132.252.185.19]) by ietfa.amsl.com (Postfix) with ESMTP id C4E5D21F9A78 for ; Mon, 30 Sep 2013 00:53:41 -0700 (PDT) Received: from nordmarka.simula.nornet ([158.39.4.2]) (authenticated bits=0) by mailout.uni-due.de (8.13.1/8.13.1) with ESMTP id r8U7rdnn017913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 30 Sep 2013 09:53:40 +0200 From: Thomas Dreibholz To: vnfpool@ietf.org Date: Mon, 30 Sep 2013 09:53:39 +0200 Message-ID: <2303774.GLXDkMk2hk@nordmarka.simula.nornet> User-Agent: KMail/4.11.1 (Linux/3.8.0-30-generic; KDE/4.11.1; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1728080.Ej824K5anC"; micalg="pgp-sha1"; protocol="application/pgp-signature" X-Virus-Scanned: Clam Anti Virus - http://www.clamav.net X-Spam-Scanned: SpamAssassin: 3.002004 - http://www.spamassassin.org X-Scanned-By: MIMEDefang 2.57 on 132.252.185.19 Subject: Re: [vnfpool] Manage PE list in RSerPool X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.12 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, 30 Sep 2013 07:53:47 -0000 --nextPart1728080.Ej824K5anC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Mandag 23. september 2013 03.57.15 skrev Zongning: > Hi, >=20 > When reading some RSerPool documents, I noticed there are several mec= hanisms > proposed to manage pool element (PE) list. One is that a pool user (P= U) > fetches a PE list from pool registrar (PR) to store the list locally,= then > selects and connects to a PE. When the selected PE fails, PU will con= nect > to another PE from the list to continue the service. Another is that = the PE > can tell the PU backup PEs via business card message when they are > communicating. In this way, when the PE fails, PU will connect to a b= ackup > PE obtained from the business card message. I am not sure about the > relation between these two PE lists. Are they necessarily consistent?= I.e. No, the PE can decide on what to send in the ASAP Business Card to the = PU.=20 That is, it is independent of the information stored by the PRs. > if the PR needs to tell exactly the same list (as the one returned to= the > PU) to the PE for constructing business card message? Or they actuall= y > serve totally different purpose, but still related?=20 The content of the ASAP Business Card may be specific for a certain ses= sion.=20 That is, depending on the redundancy configuration, the PE may tell the= PU=20 certain other PEs to fail over to in case of its own failure. This info= rmation=20 may only be valid for the session (for which the Business Card is sent)= =20 itself. > Moreover, considering > the dynamic situation of VNF instances, the PE list stored in PU coul= d be > more dynamic than before. In such case, I suppose an "active push" > mechanism maybe useful to be adopted by both PR and PE when telling P= U some > updates happened to PE list. How do you think? Thanks. An ASAP Business Card may be sent at any time the PE decides. Therefore= , a new=20 one can be sent as soon as information needs to be updated. The ASAP Handle Resolution also provides the possibility to register fo= r=20 active pushes from a PR. That is, once the information for a pool chang= es, a=20 PU will receive an update. --=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 -----------------------------------------------------------------------= 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 --nextPart1728080.Ej824K5anC 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 v1.4.12 (GNU/Linux) iEYEABECAAYFAlJJLgMACgkQ32BbsHYPLWXLOACfZNqeknoIs3SSc1y0i/TawURK XSYAnA0L74GFXYkSpeoWRz6+wUvwZtFJ =lJsI -----END PGP SIGNATURE----- --nextPart1728080.Ej824K5anC-- From dreibh@iem.uni-due.de Mon Sep 30 01:01:09 2013 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFCE921F92B5 for ; Mon, 30 Sep 2013 01:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.816 X-Spam-Level: X-Spam-Status: No, score=-1.816 tagged_above=-999 required=5 tests=[AWL=0.434, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJ5MblsVNPQk for ; Mon, 30 Sep 2013 01:01:04 -0700 (PDT) Received: from mailout.uni-due.de (mailout.uni-due.de [132.252.185.19]) by ietfa.amsl.com (Postfix) with ESMTP id 18FAE21F9BEF for ; Mon, 30 Sep 2013 01:01:03 -0700 (PDT) Received: from nordmarka.simula.nornet ([158.39.4.2]) (authenticated bits=0) by mailout.uni-due.de (8.13.1/8.13.1) with ESMTP id r8U80tRU019154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 30 Sep 2013 10:00:57 +0200 From: Thomas Dreibholz To: Zongning Date: Mon, 30 Sep 2013 10:00:54 +0200 Message-ID: <8273359.HSCiJkfoIv@nordmarka.simula.nornet> User-Agent: KMail/4.11.1 (Linux/3.8.0-30-generic; KDE/4.11.1; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart7159719.7RJDmFLgej"; micalg="pgp-sha1"; protocol="application/pgp-signature" X-Virus-Scanned: Clam Anti Virus - http://www.clamav.net X-Spam-Scanned: SpamAssassin: 3.002004 - http://www.spamassassin.org X-Scanned-By: MIMEDefang 2.57 on 132.252.185.19 Cc: "vnfpool@ietf.org" , Michael Tuexen , Melinda Shore Subject: Re: [vnfpool] pool manager for state sync? X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.12 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, 30 Sep 2013 08:01:10 -0000 --nextPart7159719.7RJDmFLgej Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Hi, Torsdag 26. september 2013 07.09.20 skrev Zongning: > Hi, all, >=20 > In current RSerPool mechanism, the service states (for stateful servi= ce like > FW) are synchronized between active and backup servers via the relay = of > pool user. This approach works fine assuming that pool user is stable= . > Consider the VNF pools model where a pool user (i.e. user of downstre= am > pool according to service chain) is normally a VNF instance in its ow= n > pool, and pool user and even its backup instances are likely less sta= ble. > As such, storing critical service states information in VNF instances= would > be a problem. I'd think a feasible approach would be to use pool mana= ger > for service states synchronization, e.g. retrieving, storing, distrib= uting > service states amongst VNF instances? Comments are highly appreciated= ! This sounds useful. Originally, RSerPool did not intend to define any state synchronisation= . But=20 ASAP has the ASAP Cookie/ASAP Cookie Echo mechanism built in, because i= t is=20 very simple and therefore easy to implement and may be useful for a num= ber of=20 applications. It is, however, somewhat limited: the cookie size is < 64= KiB,=20 the state should not change too often to avoid network overhead, and se= curity=20 has to be ensured so that a malicious PU does not use the same cookie f= or=20 resumption on multiple PEs. Since VNF is a specific application, it makes sense to define a specifi= c state=20 synchronisation approach. May be, "state synchronisation for VNF" could= be=20 another service on top of RSerPool? That is, RSerPool would not be modi= fied to=20 add state synchronisation but a service that realises it could be reali= sed=20 based on RSerPool? This would separate the application-specific task fr= om the=20 pool management task. Of course, pool management (i.e. the PR) and stat= e=20 synchronisation management could be deployed on the same machines. --=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 -----------------------------------------------------------------------= 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 --nextPart7159719.7RJDmFLgej 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 v1.4.12 (GNU/Linux) iEYEABECAAYFAlJJL7YACgkQ32BbsHYPLWV36gCdG4l9S2FrE/zs/OWE2fsdbkqL C14AoNYFH4YEs3h1ireP7Cow/HNDTiVW =F8X/ -----END PGP SIGNATURE----- --nextPart7159719.7RJDmFLgej-- From zongning@huawei.com Mon Sep 30 01:41:09 2013 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3BF421F9B60 for ; Mon, 30 Sep 2013 01:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.576 X-Spam-Level: X-Spam-Status: No, score=-106.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cwunNLqNBLZT for ; Mon, 30 Sep 2013 01:41:04 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B205B21F8EA8 for ; Mon, 30 Sep 2013 01:41:01 -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 AYK61471; Mon, 30 Sep 2013 08:40:54 +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.146.0; Mon, 30 Sep 2013 09:40:41 +0100 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 30 Sep 2013 09:40:46 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.141]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0146.000; Mon, 30 Sep 2013 16:40:37 +0800 From: Zongning To: Thomas Dreibholz , "vnfpool@ietf.org" Thread-Topic: [vnfpool] Manage PE list in RSerPool Thread-Index: Ac64EP03+QgWZuqPQA+Els5sBoKssAFXO7aAABJ/h0A= Date: Mon, 30 Sep 2013 08:40:35 +0000 Message-ID: References: <1781180.CsCHZbxtHu@nordmarka.simula.nornet> In-Reply-To: <1781180.CsCHZbxtHu@nordmarka.simula.nornet> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.48] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [vnfpool] Manage PE list in RSerPool X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.12 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, 30 Sep 2013 08:41:09 -0000 Thanks, Thomas for your clarification. Please see one more question inline. :) -Ning > -----Original Message----- > From: Thomas Dreibholz [mailto:dreibh@simula.no] > Sent: Monday, September 30, 2013 3:45 PM > To: vnfpool@ietf.org > Cc: Zongning > Subject: Re: [vnfpool] Manage PE list in RSerPool >=20 > Mandag 23. september 2013 03.57.15 skrev Zongning: > > Hi, > > > > When reading some RSerPool documents, I noticed there are several > > mechanisms proposed to manage pool element (PE) list. One is that a > > pool user (PU) fetches a PE list from pool registrar (PR) to store the > > list locally, then selects and connects to a PE. When the selected PE > > fails, PU will connect to another PE from the list to continue the > > service. Another is that the PE can tell the PU backup PEs via > > business card message when they are communicating. In this way, when > > the PE fails, PU will connect to a backup PE obtained from the > > business card message. I am not sure about the relation between these t= wo > PE lists. Are they necessarily consistent? I.e. >=20 > No, the PE can decide on what to send in the ASAP Business Card to the PU= . > That is, it is independent of the information stored by the PRs. >=20 >=20 > > if the PR needs to tell exactly the same list (as the one returned to > > the > > PU) to the PE for constructing business card message? Or they actually > > serve totally different purpose, but still related? >=20 > The content of the ASAP Business Card may be specific for a certain sessi= on. > That is, depending on the redundancy configuration, the PE may tell the P= U > certain other PEs to fail over to in case of its own failure. This inform= ation may > only be valid for the session (for which the Business Card is sent) itsel= f. >=20 [Ning]: If the backup PEs are configured in PE before the session start? Or= dynamically collected in runtime, e.g. by receiving registration messages = from available PEs, like PR does? >=20 > > Moreover, considering > > the dynamic situation of VNF instances, the PE list stored in PU could > > be more dynamic than before. In such case, I suppose an "active push" > > mechanism maybe useful to be adopted by both PR and PE when telling PU > > some updates happened to PE list. How do you think? Thanks. >=20 > An ASAP Business Card may be sent at any time the PE decides. Therefore, = a > new one can be sent as soon as information needs to be updated. >=20 > The ASAP Handle Resolution also provides the possibility to register for = active > pushes from a PR. That is, once the information for a pool changes, a PU = will > receive an update. [Ning]: This sounds reasonable. >=20 > -- > Best regards / Mit freundlichen Gr=FC=DFen / Med vennlig hilsen >=20 > =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 >=20 > 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 > ----------------------------------------------------------------------- > 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 From dreibh@iem.uni-due.de Mon Sep 30 02:10:01 2013 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7002E21F9C46 for ; Mon, 30 Sep 2013 02:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.924 X-Spam-Level: X-Spam-Status: No, score=-1.924 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ol3qHzw1NPjf for ; Mon, 30 Sep 2013 02:09:54 -0700 (PDT) Received: from mailout.uni-due.de (mailout.uni-due.de [132.252.185.19]) by ietfa.amsl.com (Postfix) with ESMTP id 6538721F8F07 for ; Mon, 30 Sep 2013 02:09:51 -0700 (PDT) Received: from nordmarka.simula.nornet ([158.39.4.2]) (authenticated bits=0) by mailout.uni-due.de (8.13.1/8.13.1) with ESMTP id r8U99i1P002236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 30 Sep 2013 11:09:45 +0200 From: Thomas Dreibholz To: Zongning Date: Mon, 30 Sep 2013 11:09:44 +0200 Message-ID: <2795677.2lnJ31n4hs@nordmarka.simula.nornet> User-Agent: KMail/4.11.1 (Linux/3.8.0-30-generic; KDE/4.11.1; x86_64; ; ) In-Reply-To: References: <1781180.CsCHZbxtHu@nordmarka.simula.nornet> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2281076.ZZqX7v3Isi"; micalg="pgp-sha1"; protocol="application/pgp-signature" X-Virus-Scanned: Clam Anti Virus - http://www.clamav.net X-Spam-Scanned: SpamAssassin: 3.002004 - http://www.spamassassin.org X-Scanned-By: MIMEDefang 2.57 on 132.252.185.19 Cc: "vnfpool@ietf.org" Subject: Re: [vnfpool] Manage PE list in RSerPool X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.12 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, 30 Sep 2013 09:10:01 -0000 --nextPart2281076.ZZqX7v3Isi Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Hi, Mandag 30. september 2013 08.40.35 skrev Zongning: > > The content of the ASAP Business Card may be specific for a certain= > > session. That is, depending on the redundancy configuration, the PE= may > > tell the PU certain other PEs to fail over to in case of its own fa= ilure. > > This information may only be valid for the session (for which the > > Business Card is sent) itself. > [Ning]: If the backup PEs are configured in PE before the session sta= rt? Or > dynamically collected in runtime, e.g. by receiving registration mess= ages > from available PEs, like PR does? The backup PEs can be configured at any time you like. Also, this confi= guration=20 can be updated at any time you like. Once there is an update, you just = need to=20 send a new ASAP Business Card with the updated information. Particularly, this means that the ASAP Business Card mechanism allows t= o=20 dynamically change the configuration. For example, additional backup PE= s could=20 be configured to improve redundancy, some backup PEs could be removed, = or=20 different (e.g. nearer, cheaper, etc.) PEs could be chosen as backup PE= s. --=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 -----------------------------------------------------------------------= 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 --nextPart2281076.ZZqX7v3Isi 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 v1.4.12 (GNU/Linux) iEYEABECAAYFAlJJP9gACgkQ32BbsHYPLWVApwCdE817vJm28hQxk1oLMto6on00 J2oAnA1dajbk9o3zRDcXSnDn48rqkW8d =8UMj -----END PGP SIGNATURE----- --nextPart2281076.ZZqX7v3Isi-- From Michael.Tuexen@lurchi.franken.de Mon Sep 30 05:53:01 2013 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5308621F9AF0 for ; Mon, 30 Sep 2013 05:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1h0-tRojEn5 for ; Mon, 30 Sep 2013 05:53:00 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id D383421F9BF7 for ; Mon, 30 Sep 2013 05:52:59 -0700 (PDT) Received: from [192.168.1.101] (p508F0C7B.dip0.t-ipconnect.de [80.143.12.123]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 81AAE1C0E97FE; Mon, 30 Sep 2013 14:52:57 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 $1510$) From: Michael Tuexen In-Reply-To: <15874853.GtDRjEN4kM@nordmarka.simula.nornet> Date: Mon, 30 Sep 2013 14:52:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3DB4A8D6-4AF7-49EC-8453-914406755E8A@lurchi.franken.de> References: <1783683.ptHy5NI9HW@nordmarka.simula.nornet> <2975598.eeKVXPZDzc@nordmarka.simula.nornet> <52492B13.9060103@gmail.com> <15874853.GtDRjEN4kM@nordmarka.simula.nornet> To: Thomas Dreibholz X-Mailer: Apple Mail (2.1510) Cc: vnfpool@ietf.org, Melinda Shore Subject: Re: [vnfpool] Information on Reliable Server Pooling (RSerPool) X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.12 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, 30 Sep 2013 12:53:01 -0000 On Sep 30, 2013, at 9:47 AM, Thomas Dreibholz wrote: > Hi, >=20 > S=F8ndag 29. september 2013 23.41.07 skrev Melinda Shore: >> On 9/29/13 11:34 PM, Thomas Dreibholz wrote: >>> we should have an SVN server to manage the draft XML file. Michael, = could >>> we use your server for that purpose? I could then check in a = template >>> document and we can discuss on the document structure. >>=20 >> I've used github for several documents and it's been good. >> I'd like to encourage people to double-check that whatever >> server they use for this sort of thing is accessible from >> China. I'm fine with using the server in my lab, but using GitHub might be easier... >=20 > GitHub is fine for me, too. Do you already have a repository there? = Otherwise,=20 > I would create one. I think you might want to create one... Best regards Michael >=20 > --=20 > Best regards / Mit freundlichen Gr=FC=DFen / Med vennlig hilsen >=20 > = =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 >=20 > 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 > = ----------------------------------------------------------------------- > 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 > _______________________________________________ > vnfpool mailing list > vnfpool@ietf.org > https://www.ietf.org/mailman/listinfo/vnfpool