From diego@tid.es Sun Dec 1 10:19:49 2013 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 052BA1AE024 for ; Sun, 1 Dec 2013 10:19:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.502 X-Spam-Level: X-Spam-Status: No, score=-1.502 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 YZMkXqJJD3kV for ; Sun, 1 Dec 2013 10:18:47 -0800 (PST) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 0829E1ADFD2 for ; Sun, 1 Dec 2013 10:18:46 -0800 (PST) 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 <0MX500GY1474A7@tid.hi.inet> for vnfpool@ietf.org; Sun, 01 Dec 2013 19:18:40 +0100 (MET) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id A2.3C.02810.08D7B925; Sun, 01 Dec 2013 19:18:40 +0100 (CET) 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 <0MX500GXU474A7@tid.hi.inet> for vnfpool@ietf.org; Sun, 01 Dec 2013 19:18:40 +0100 (MET) Received: from EX10-MB1-MAD.hi.inet ([169.254.1.96]) by EX10-HTCAS7-MAD.hi.inet ([::1]) with mapi id 14.03.0158.001; Sun, 01 Dec 2013 19:18:40 +0100 Date: Sun, 01 Dec 2013 18:18:38 +0000 From: "Diego R. Lopez" In-reply-to: X-Originating-IP: [10.95.64.115] To: "Y. Richard Yang" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_SqdQUSgBZlwANDwp1+bOoQ)" Content-language: en-US Accept-Language: en-US, es-ES Thread-topic: [vnfpool] VNF Pool Problem Statement Thread-index: Ac7mmacuBQUiFtBEQ2CEYoAlHpu1YwBTDboAAGjuxYAA1Rp+AAAA8UCAAACAc4AAWv0MAAAZLCgA X-AuditID: 0a5f4e69-b7f9b8e000000afa-59-529b7d8037d0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsXCFe9nqNtQOzvIYMkzHYsZl/6zODB6LFny kymAMYrLJiU1J7MstUjfLoEr4/nlXuaCi/YV2xYlNDDOM+ti5OSQEDCRuPxzCwuELSZx4d56 ti5GLg4hgW2MEpObFzBCOL+AnG2vmECqhASmMUq8OZQPYrMIqEpsO7QeLM4GZD9q/s3excjB ISxgKDHrdgpImFMgWOLQ2QtMEAsUJP6ce8wCUiIioC7x8q8/yHhmgamMEgtXP2YFqeEVsJS4 9+YIG4QtKPFj8j2w45gFoiV6vh5ggrDFJZpbb4LFGQVkJd7Nnw/WKyJgJDFz0Ss2CDtG4u2v E8wQewUkluw5D2WLSrx8/I8V4q/XzBJvN/1jmcAoNgvJvllI9s1Csg/CNpB4f24+M4StLbFs 4WsoW19i45ezjBC2mcSTh48ZkdUsYORYxShWnFSUmZ5RkpuYmZNuYKSXkamXmZdasokREo2Z OxiX71Q5xCjAwajEw5shOjNIiDWxrLgy9xCjBAezkgivxddZQUK8KYmVValF+fFFpTmpxYcY mTg4pRoY+av010hzhzx/JnM0bea7gn3MR4MlbZwmNGldCpOwfuG4cZuX6JZpx2d86fJjYYjK K3tSyb7S3/6j5iSjqdevP1nyd4bvWosc6ftXIie/D9du5N0wm/3or1lybG9CYhPvXPnN8vym 615VBd+b3T5HBbNrVslurSy4IdWr7nInQu22WtrBC/tqlFiKMxINtZiLihMBT/OPFqQCAAA= References: Cc: "" , "Cao, Zhen" , Mukhtiar Shaikh , Zongning Subject: Re: [vnfpool] VNF Pool 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: Sun, 01 Dec 2013 18:19:49 -0000 X-List-Received-Date: Sun, 01 Dec 2013 18:19:49 -0000 --Boundary_(ID_SqdQUSgBZlwANDwp1+bOoQ) Content-type: text/plain; charset=Windows-1252 Content-transfer-encoding: quoted-printable Hi, Fully agree with Richard here: The VNF pools could be used to construct the= service chains defined in SFC or whatever other network function supported= by the resource pools supported by the VNFPOOL constructs. Be goode, On 1 Dec 2013, at 06:42 , Y. Richard Yang wrote: The discussion regarding FSC is a good one. Overall, I like the Problem Sta= tement. Two concepts stand out: VNF and Service Chain, both are large conce= pts. The nice drawing by Linda helps, but I believe that this is a simplifi= ed illustration, as during the meeting Diego showed that the model can be m= ore complex, if I understand him correctly. Does the intended WG want to bu= ild on top of these two specific concepts, or build a more general and henc= e reusable, modular solution? I see the more general solution approach as o= ne possible way to decouple from the Service Chain definitions WG. To be co= ncrete, the concepts from Chabby and rservpool appear to be general. > During the Vancouver bar BoF, we also discussed the relation between VNF > pool and FSC. Sorry I was not there physically. > We agreed that VNF pool will address different problem space. > Assuming that some chaining mechanism has been defined in FSC regarding h= ow > to connect/chain the VNF instances, we focus on signaling related to > resiliency, e.g. backup announcement, status notification, etc. So I=92d = see > these two groups as complementary. Ok, then we need to specify in the charter that the discussion in this working group is orthogonal to the detail chaining header used or chosen by the SFC group, and the way the two potential groups works together. > > You are absolutely right that these two groups are related with each othe= r. > I can put some text in our proposed working scope to clarify this issue. > _______________________________________________ vnfpool mailing list vnfpool@ietf.org https://www.ietf.org/mailman/listinfo/vnfpool _______________________________________________ vnfpool mailing list vnfpool@ietf.org https://www.ietf.org/mailman/listinfo/vnfpool -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego@tid.es Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------------- ________________________________ 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_SqdQUSgBZlwANDwp1+bOoQ) Content-id: <63C127E2AE3DCD499B67CE4FDA03EE2A@hi.inet> Content-type: text/html; charset=Windows-1252 Content-transfer-encoding: quoted-printable Hi,

Fully agree with Richard here: The VNF pools could be used to construc= t the service chains defined in SFC or whatever other network function supp= orted by the resource pools supported by the VNFPOOL constructs.

Be goode,

On 1 Dec 2013, at 06:42 , Y. Richard Yang wrote:

The discussion regarding FSC is a good one. Overall, I like = the Problem Statement. Two concepts stand out: VNF and Service Chain, both = are large concepts. The nice drawing by Linda helps, but I believe that thi= s is a simplified illustration, as during the meeting Diego showed that the model can be more complex, if I u= nderstand him correctly. Does the intended WG want to build on top of these= two specific concepts, or build a more general and hence reusable, modular= solution? I see the more general solution approach as one possible way to decouple from the Service Chain d= efinitions WG. To be concrete, the concepts from Chabby and rservpool appea= r to be general.

> During the Vancouver bar BoF, we also discussed the relation between V= NF
> pool and FSC.

Sorry I was not there physically.

> We agreed that VNF pool will address different problem space.
> Assuming that some chaining mechanism has been defined in FSC regardin= g how
> to connect/chain the VNF instances, we focus on signaling related to > resiliency, e.g. backup announcement, status notification, etc. So I= =92d see
> these two groups as complementary.

Ok, then we need to specify in the charter that the discussion in this
working group is orthogonal to the detail chaining header used or
chosen by the SFC group, and the way the two potential groups works
together.

>
> You are absolutely right that these two groups are related with each o= ther.
> I can put some text in our proposed working scope to clarify this issu= e.
>
_______________________________________________
vnfpool mailing list
vnfpool@ietf.org
https://www.ietf.org/mailman/listinfo/vnfpool
_______________________________________________
vnfpool mailing list
vnfpool@ietf.org
https://www.ietf.org/mailman/listinfo/vnfpool


--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: diego@tid.es
Tel:    +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------



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_SqdQUSgBZlwANDwp1+bOoQ)-- From zongning@huawei.com Sun Dec 1 18:34:06 2013 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 B2A781AE238 for ; Sun, 1 Dec 2013 18:34:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 UTdSeD0Cs50a for ; Sun, 1 Dec 2013 18:34:03 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 50B0B1AE071 for ; Sun, 1 Dec 2013 18:34:02 -0800 (PST) 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 BAX23777; Mon, 02 Dec 2013 02:33:59 +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; Mon, 2 Dec 2013 02:31:22 +0000 Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 2 Dec 2013 02:32:06 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Mon, 2 Dec 2013 10:32:01 +0800 From: Zongning To: "Diego R. Lopez" , "Y. Richard Yang" Thread-Topic: [vnfpool] VNF Pool Problem Statement Thread-Index: Ac7mmacuBQUiFtBEQ2CEYoAlHpu1YwBEYqIAAHh0j3AAxZS1AAARbS0w//+AJICAAtfoAIAA00MA//7zNTA= Date: Mon, 2 Dec 2013 02:32:00 +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.28] Content-Type: multipart/alternative; boundary="_000_B0D29E0424F2DE47A0B36779EC66677925856C8Enkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "" , "Cao,Zhen" Subject: Re: [vnfpool] VNF Pool 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, 02 Dec 2013 02:34:06 -0000 --_000_B0D29E0424F2DE47A0B36779EC66677925856C8Enkgeml501mbschi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Richard and Diego, Thanks for your comments. Generally I agree with both of you. We develop general multi-pool mechanism= on reliability perspective, hence decouple ourselves from any specific Ser= vice Chaining approach. As I replied to Zhen, the signaling to be developed= in our group will be complementary to SFC. But, I don't want the intended = solution to be too general to be done (or boiling the ocean). So, let's foc= us on problems based on a limited set of cases like VNF chain could be good= starting point. -Ning From: Diego R. Lopez [mailto:diego@tid.es] Sent: Monday, December 02, 2013 2:19 AM To: Y. Richard Yang Cc: Cao,Zhen; ; Mukhtiar Shaikh; Zongning Subject: Re: [vnfpool] VNF Pool Problem Statement Hi, Fully agree with Richard here: The VNF pools could be used to construct the= service chains defined in SFC or whatever other network function supported= by the resource pools supported by the VNFPOOL constructs. Be goode, On 1 Dec 2013, at 06:42 , Y. Richard Yang wrote: The discussion regarding FSC is a good one. Overall, I like the Problem Sta= tement. Two concepts stand out: VNF and Service Chain, both are large conce= pts. The nice drawing by Linda helps, but I believe that this is a simplifi= ed illustration, as during the meeting Diego showed that the model can be m= ore complex, if I understand him correctly. Does the intended WG want to bu= ild on top of these two specific concepts, or build a more general and henc= e reusable, modular solution? I see the more general solution approach as o= ne possible way to decouple from the Service Chain definitions WG. To be co= ncrete, the concepts from Chabby and rservpool appear to be general. > During the Vancouver bar BoF, we also discussed the relation between VNF > pool and FSC. Sorry I was not there physically. > We agreed that VNF pool will address different problem space. > Assuming that some chaining mechanism has been defined in FSC regarding h= ow > to connect/chain the VNF instances, we focus on signaling related to > resiliency, e.g. backup announcement, status notification, etc. So I'd se= e > these two groups as complementary. Ok, then we need to specify in the charter that the discussion in this working group is orthogonal to the detail chaining header used or chosen by the SFC group, and the way the two potential groups works together. > > You are absolutely right that these two groups are related with each othe= r. > I can put some text in our proposed working scope to clarify this issue. > _______________________________________________ vnfpool mailing list vnfpool@ietf.org https://www.ietf.org/mailman/listinfo/vnfpool _______________________________________________ vnfpool mailing list vnfpool@ietf.org https://www.ietf.org/mailman/listinfo/vnfpool -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego@tid.es Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------------- ________________________________ 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 --_000_B0D29E0424F2DE47A0B36779EC66677925856C8Enkgeml501mbschi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi, Richar= d and Diego,

 = ;

Thanks for= your comments.

Generally = I agree with both of you. We develop general multi-pool mechanism on reliab= ility perspective, hence decouple ourselves from any specific Service Chaining approach. As I replied to Zhen, the signaling to be devel= oped in our group will be complementary to SFC. But, I don’t want the= intended solution to be too general to be done (or boiling the ocean). So,= let’s focus on problems based on a limited set of cases like VNF chain could be good starting point.

 = ;

-Ning=

 = ;

 = ;

From: Diego R. Lopez [mailto:diego@tid.es]
Sent: Monday, December 02, 2013 2:19 AM
To: Y. Richard Yang
Cc: Cao,Zhen; <vnfpool@ietf.org>; Mukhtiar Shaikh; Zongning Subject: Re: [vnfpool] VNF Pool Problem Statement<= /p>

 

Hi,

 

Fully agree with Richard here: = The VNF pools could be used to construct the service chains defined in SFC = or whatever other network function supported by the resource pools supporte= d by the VNFPOOL constructs.

 

Be goode,

 

On 1 Dec 2013, at 06:42 , Y. Ri= chard Yang wrote:



The discussion regarding FSC is a good one. Overall= , I like the Problem Statement. Two concepts stand out: VNF and Service Cha= in, both are large concepts. The nice drawing by Linda helps, but I believe= that this is a simplified illustration, as during the meeting Diego showed that the model can be more complex, if = I understand him correctly. Does the intended WG want to build on top of th= ese two specific concepts, or build a more general and hence reusable, modu= lar solution? I see the more general solution approach as one possible way to decouple from the Service Chain d= efinitions WG. To be concrete, the concepts from Chabby and rservpool appea= r to be general.

> During the Vancouver bar B= oF, we also discussed the relation between VNF
> pool and FSC.

Sorry I was not there physically.

> We agreed that VNF pool will address different problem space.
> Assuming that some chaining mechanism has been defined in FSC regardin= g how
> to connect/chain the VNF instances, we focus on signaling related to > resiliency, e.g. backup announcement, status notification, etc. So I&#= 8217;d see
> these two groups as complementary.

Ok, then we need to specify in the charter that the discussion in this
working group is orthogonal to the detail chaining header used or
chosen by the SFC group, and the way the two potential groups works
together.

>
> You are absolutely right that these two groups are related with each o= ther.
> I can put some text in our proposed working scope to clarify this issu= e.
>
_______________________________________________
vnfpool mailing list
vnfpool@ietf.org
https://www.ietf.org/mailman/listinfo/vnfpool

_______________________________= ________________
vnfpool mailing list
vnfpool@ietf.org
https://www.ietf.org/mailman/listinfo/vnfpool

 


--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D

http://people.tid.es/diego.lopez/
e-mail: diego@tid.es
Tel:    +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------

 

 


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

--_000_B0D29E0424F2DE47A0B36779EC66677925856C8Enkgeml501mbschi_-- From yang.r.yang@gmail.com Sun Dec 1 19:06:38 2013 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 4B0EF1AE2C1 for ; Sun, 1 Dec 2013 19:06:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 MSpIZwW-Cgg1 for ; Sun, 1 Dec 2013 19:06:35 -0800 (PST) Received: from mail-pb0-x234.google.com (mail-pb0-x234.google.com [IPv6:2607:f8b0:400e:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 4C71F1AE339 for ; Sun, 1 Dec 2013 19:06:05 -0800 (PST) Received: by mail-pb0-f52.google.com with SMTP id uo5so17941975pbc.11 for ; Sun, 01 Dec 2013 19:06:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=0hgdeszwodPLmE/S/ndUWhGf38fWVP4dn5+XMSp2iVE=; b=L0dpC5iHID79cvHBaF3Pgty3jW7mVLS0DSTvGl7npnCj4l938tdmOai6fjzjeSmH3d DiWRAgcN24FBwkAzJazQCJDi2dJyKViwUXB6Fm4q8MEpNWk926ZDlkS0uKUD6tpBmL17 TcNi8bzywLWL6zb1fTTl0noFgtzy4D+dZylz7UHSZ4qZt6+0BCwSd4X55vsYFYPzOXrs Put2JIOXS/oKTHK4QclRRJUXtFwGHm1MmZ89K2w9K414qfpHAZIYLFmc/gjQj+cfmU58 bd5LkiFS/FlW/re7kXj1jZprt4s9Ps5KfufXbikL7ZetCYX6Hqt037f7yUXyTM1Iavwp nARQ== MIME-Version: 1.0 X-Received: by 10.66.216.162 with SMTP id or2mr6359pac.179.1385953563279; Sun, 01 Dec 2013 19:06:03 -0800 (PST) Sender: yang.r.yang@gmail.com Received: by 10.68.15.41 with HTTP; Sun, 1 Dec 2013 19:06:03 -0800 (PST) In-Reply-To: References: Date: Sun, 1 Dec 2013 22:06:03 -0500 X-Google-Sender-Auth: yBXa0-lnCUgVGxHlK6bLRfgNM5U Message-ID: From: "Y. Richard Yang" To: Zongning Content-Type: multipart/alternative; boundary=047d7b5d9501d0872004ec8475b9 Cc: "" , "Cao, Zhen" , "Diego R. Lopez" Subject: Re: [vnfpool] VNF Pool 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, 02 Dec 2013 03:06:38 -0000 --047d7b5d9501d0872004ec8475b9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Ning, Being focused definitely makes sense. Here is one question that the proposed WG will need to resolve: - What is an VNF? There are multiple types of VNFs and vnfpool will depend on a "base class" of these multiple types of VNFs, in the context of vnfpool. What does this base class, in the context of vnfpool, define? There are three approaches: (1) this is outside the scope of this WG, but is a prerequisite for the WG to get started, or (2) this is a WG item? I feel that it is (2) in this stage. Or it could be (1), and then who defines it? Richard On Sun, Dec 1, 2013 at 9:32 PM, Zongning wrote: > Hi, Richard and Diego, > > > > Thanks for your comments. > > Generally I agree with both of you. We develop general multi-pool > mechanism on reliability perspective, hence decouple ourselves from any > specific Service Chaining approach. As I replied to Zhen, the signaling t= o > be developed in our group will be complementary to SFC. But, I don=92t wa= nt > the intended solution to be too general to be done (or boiling the ocean)= . > So, let=92s focus on problems based on a limited set of cases like VNF ch= ain > could be good starting point. > > > > -Ning > > > > > > *From:* Diego R. Lopez [mailto:diego@tid.es] > *Sent:* Monday, December 02, 2013 2:19 AM > *To:* Y. Richard Yang > *Cc:* Cao,Zhen; ; Mukhtiar Shaikh; Zongning > > *Subject:* Re: [vnfpool] VNF Pool Problem Statement > > > > Hi, > > > > Fully agree with Richard here: The VNF pools could be used to construct > the service chains defined in SFC or whatever other network function > supported by the resource pools supported by the VNFPOOL constructs. > > > > Be goode, > > > > On 1 Dec 2013, at 06:42 , Y. Richard Yang wrote: > > > > The discussion regarding FSC is a good one. Overall, I like the Problem > Statement. Two concepts stand out: VNF and Service Chain, both are large > concepts. The nice drawing by Linda helps, but I believe that this is a > simplified illustration, as during the meeting Diego showed that the mode= l > can be more complex, if I understand him correctly. Does the intended WG > want to build on top of these two specific concepts, or build a more > general and hence reusable, modular solution? I see the more general > solution approach as one possible way to decouple from the Service Chain > definitions WG. To be concrete, the concepts from Chabby and rservpool > appear to be general. > > > During the Vancouver bar BoF, we also discussed the relation between VN= F > > pool and FSC. > > Sorry I was not there physically. > > > We agreed that VNF pool will address different problem space. > > Assuming that some chaining mechanism has been defined in FSC regarding > how > > to connect/chain the VNF instances, we focus on signaling related to > > resiliency, e.g. backup announcement, status notification, etc. So I=92= d > see > > these two groups as complementary. > > Ok, then we need to specify in the charter that the discussion in this > working group is orthogonal to the detail chaining header used or > chosen by the SFC group, and the way the two potential groups works > together. > > > > > You are absolutely right that these two groups are related with each > other. > > I can put some text in our proposed working scope to clarify this issue= . > > > _______________________________________________ > vnfpool mailing list > vnfpool@ietf.org > https://www.ietf.org/mailman/listinfo/vnfpool > > _______________________________________________ > vnfpool mailing list > vnfpool@ietf.org > https://www.ietf.org/mailman/listinfo/vnfpool > > > > > -- > "Esta vez no fallaremos, Doctor Infierno" > > Dr Diego R. Lopez > Telefonica I+D > > http://people.tid.es/diego.lopez/ > > e-mail: diego@tid.es > Tel: +34 913 129 041 > Mobile: +34 682 051 091 > ----------------------------------------- > > > > > ------------------------------ > > > Este mensaje se dirige exclusivamente a su destinatario. Puede consultar > nuestra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el= enlace > situado m=E1s abajo. > This message is intended exclusively for its addressee. We only send and > receive email on the basis of the terms set out at: > http://www.tid.es/ES/PAGINAS/disclaimer.aspx > --=20 --=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 | Y. Richard Yang | | Professor of Computer Science | | http://www.cs.yale.edu/~yry/ | =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --047d7b5d9501d0872004ec8475b9 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Ning,

Being focused definitely makes= sense. Here is one question that the proposed WG will need to resolve:

- What is an VNF?

There are = multiple types of VNFs and vnfpool will depend on a "base class" = of these multiple types of VNFs, in the context of vnfpool. What does this = base class, in the context of vnfpool, define? There are three approaches: = (1) this is outside the scope of this WG, but is a prerequisite for the WG = to get started, or (2) this is a WG item? I feel that it is (2) in this sta= ge. Or it could be (1), and then who defines it?

Richard


On Sun, Dec 1, 2013 at 9:32 PM, Zongning <zongning@h= uawei.com> wrote:

Hi, Richar= d and Diego,

=A0=

Thanks for= your comments.

Generally = I agree with both of you. We develop general multi-pool mechanism on reliab= ility perspective, hence decouple ourselves from any specific Service Chaining approach. As I replied to Zhen, the signaling to be devel= oped in our group will be complementary to SFC. But, I don=92t want the int= ended solution to be too general to be done (or boiling the ocean). So, let= =92s focus on problems based on a limited set of cases like VNF chain could be good starting point.

=A0=

-Ning

=A0=

=A0=

From: Diego R. Lopez [mailto:diego@tid.es]
Sent: Monday, December 02, 2013 2:19 AM
To: Y. Richard Yang
Cc: Cao,Zhen; <vnfpool@ietf.org>; Mukhtiar Shaikh; Zongning


Subject: Re: [vnfpool] VNF Pool Problem Statement

=A0

Hi,

=A0

Fully agree with Richard here: = The VNF pools could be used to construct the service chains defined in SFC = or whatever other network function supported by the resource pools supporte= d by the VNFPOOL constructs.

=A0

Be goode,<= /p>

=A0

On 1 Dec 2013, at 06:42 , Y. Ri= chard Yang wrote:



The discussion regarding FSC is a good one. Overall= , I like the Problem Statement. Two concepts stand out: VNF and Service Cha= in, both are large concepts. The nice drawing by Linda helps, but I believe= that this is a simplified illustration, as during the meeting Diego showed that the model can be more complex, if = I understand him correctly. Does the intended WG want to build on top of th= ese two specific concepts, or build a more general and hence reusable, modu= lar solution? I see the more general solution approach as one possible way to decouple from the Service Chain d= efinitions WG. To be concrete, the concepts from Chabby and rservpool appea= r to be general.

> During the Vancouver bar B= oF, we also discussed the relation between VNF
> pool and FSC.

Sorry I was not there physically.

> We agreed that VNF pool will address different problem space.
> Assuming that some chaining mechanism has been defined in FSC regardin= g how
> to connect/chain the VNF instances, we focus on signaling related to > resiliency, e.g. backup announcement, status notification, etc. So I= =92d see
> these two groups as complementary.

Ok, then we need to specify in the charter that the discussion in this
working group is orthogonal to the detail chaining header used or
chosen by the SFC group, and the way the two potential groups works
together.

>
> You are absolutely right that these two groups are related with each o= ther.
> I can put some text in our proposed working scope to clarify this issu= e.
>
_______________________________________________
vnfpool mailing list
vnfpool@ietf.org<= br> https://www.ietf.org/mailman/listinfo/vnfpool

_______________________________= ________________
vnfpool mailing list
vnfpool@ietf.org<= br> https://www.ietf.org/mailman/listinfo/vnfpool

=A0


--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D

http://people.tid.es/diego.lopez/=

e-mail: diego@tid.es<= br> Tel: =A0 =A0+34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------

=A0

=A0


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




--
--=A0
=A0=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
| Y. Richard Yang <yry@cs.yale.edu> =A0 |
| Professor of Compute= r Science =A0 =A0 =A0 |
| http://www.cs.yale.edu/~yry/ =A0 =A0 =A0 = =A0|
=A0=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
--047d7b5d9501d0872004ec8475b9-- From zehn.cao@gmail.com Sun Dec 1 23:22:01 2013 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 CAA921AE34C for ; Sun, 1 Dec 2013 23:22:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 jkMDuC-pnoFU for ; Sun, 1 Dec 2013 23:21:59 -0800 (PST) Received: from mail-qe0-x230.google.com (mail-qe0-x230.google.com [IPv6:2607:f8b0:400d:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id E13CC1AE44F for ; Sun, 1 Dec 2013 23:21:58 -0800 (PST) Received: by mail-qe0-f48.google.com with SMTP id gc15so12620863qeb.21 for ; Sun, 01 Dec 2013 23:21:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=4k3SPaGxjvueW6w8Gp1KULcOYbgyQouN/rKfnhgJmSU=; b=eZrVnRRX1m18/wFMYcW1zVTTOJeZimBrR4i5Ea8krfA0UcV5iUxn6yxuVjiivGOiQm 48odlSOoBmVRBnBrrgQsfyKF/RRWUl/F/vGR83oxRRy0Zwkt6U6j3S/BCAoN4s8G2daw GjdFy5D0VRz/1T8CXhS3Uzt9Xzsd4PF2fUDS6gHPoqC05bH0/gXvN6NNK2pKnJbnUYhS co12x2+M3J5/z2mXEL/CWWdoeSOAztPOwAX36IAtOnrB7IHwsF1AzrITyX32KRNt96qi tKOPnp4FCFhJw8ZQFcHwozZ0i2B9xi8jSYhuMP/demUWQijBuYzF4TH+KyQNjCIwx6DJ NIdA== MIME-Version: 1.0 X-Received: by 10.229.194.1 with SMTP id dw1mr69502866qcb.20.1385968916591; Sun, 01 Dec 2013 23:21:56 -0800 (PST) Received: by 10.96.63.234 with HTTP; Sun, 1 Dec 2013 23:21:56 -0800 (PST) In-Reply-To: References: <52940EB0.6040601@kddilabs.jp> Date: Mon, 2 Dec 2013 15:21:56 +0800 Message-ID: From: "Cao,Zhen" To: "Diego R. Lopez" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "" , Hidetoshi Yokota Subject: Re: [vnfpool] VNF Pool 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, 02 Dec 2013 07:22:02 -0000 Good point, Diego. I checked out the NFV ISG released documents of requirements and terminology, where i could not find 'reliability' but 'resilience'. -cz On Wed, Nov 27, 2013 at 2:06 AM, Diego R. Lopez wrote: > Hi, > > When it comes to the reliability/availability issue I guess providing som= e > (condensed) definition from the NFV REL group would help... > > Be goode, > > On 26 Nov 2013, at 04:00 , Hidetoshi Yokota wrote: > > Hi Ning and all, > > The proposed PS is a very good starting point covering major issues for t= he > goal of VNF pool. One thing that I could add is the synchronization betwe= en > the vNF migration/replacement and routing to make the relevant flows > forwarded to the new location. The challenge is that the VMs/severs in a > pool could be deployed over topologically different networks (in the > physical world) and VNF migration could involve topologically independent > routing. There are multiple ways to do it, but we should first generalize > this issue and specify a common mechanism that may leverage existing ones= . > > If this is already covered, that's fine. If some additional text is usefu= l, > the following could be a summary: > > o Synchronization between vNF migration and flow forwarding, which may > require topologically independent routing in the physical transport netwo= rk; > > There is a discussion about "reliability" and "availability" in another > thread and I think this is also an issue in ETSI NFV. We need to define t= hem > either in this group or NFV to share the same view. > > Regards, > > -- > Hidetoshi Yokota > > KDDI R&D Laboratories, Inc. > e-mail:yokota@kddilabs.jp > > > (2013/11/21 18:11), Zongning wrote: > > Hi, > > > > Please review the below brief version of VNF Pool Problem Statement, and > feedback with your comments. I hope this text can serve as a base of VNF > Pool Charter, by carving out real problems and work items. > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > A virtualized network function (VNF) (e.g. vFW, vLB) provides the same > function as the equivalent network function (e.g. FW, LB), but is usually > instantiated as a cluster of software instances running on general purpos= e > servers via virtualization platform. In an environment based on VNFs, a > network service is typically realized by a chain of VNFs where the instan= ces > of adjacent VNFs are preferably directly connected. > > > > A VNF chain introduces additional points of failure beyond those inherent= in > a single dedicated server, and therefore additional challenges on > reliability. By reliability, we mean the ability of a VNF chain to contin= ue > function when having transition or failure within the chain. For example, > there are more factors such as software failure, server over-utilization, > instance migration that potentially cause VNF instance transition or > failure. Although a general pooling mechanism can be applied to address t= he > reliability of a single VNF, there are still problems when addressing the > reliability of a VNF chain, i.e. multiple pools for multiple VNFs. For > example, how does an instance of VNF#1 know which instance in the pool of > VNF#2 will replace the instance of VNF#2 it connects to? How does an > instance of VNF#1 know the state of instance of VNF#2 that it connects to= in > order to enforce policy for reliability like load sharing, switch before > break? How is the service state of an instance held and accessed for > efficient synchronization with backup instances? > > > > The overall problem space can be further breakdown to the following study > items: > > - Signalling to handle reliability and instance transition > requirements > > o Signalling between VNF pools for transition (e.g. state change, scali= ng, > moving) notification, backup announcement; > > o Service state management (e.g. synchronizing method, state data forma= t, > location and mechanism to access state data) within VNF pool; > > o Obtaining underlying network information (e.g. ALTO, I2RS); > > o Signalling to CMS for instance deployment reflecting reliability > requirements (e.g. distribution of instances on different VMs or > hypervisors); > > - Transport characteristics > > o Identify and analyze reliable transport characteristics for control > plane traffic; > > o Analysis of transport security characteristics to provide protection > against known threats, and identification of an appropriate trust model; > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > Thanks. > > > > -Ning > > > > _______________________________________________ > vnfpool mailing list > vnfpool@ietf.org > https://www.ietf.org/mailman/listinfo/vnfpool > > > _______________________________________________ > vnfpool mailing list > vnfpool@ietf.org > https://www.ietf.org/mailman/listinfo/vnfpool > > > > -- > "Esta vez no fallaremos, Doctor Infierno" > > Dr Diego R. Lopez > Telefonica I+D > http://people.tid.es/diego.lopez/ > > e-mail: diego@tid.es > Tel: +34 913 129 041 > Mobile: +34 682 051 091 > ----------------------------------------- > > > ________________________________ > > Este mensaje se dirige exclusivamente a su destinatario. Puede consultar > nuestra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el= enlace > situado m=E1s abajo. > This message is intended exclusively for its addressee. We only send and > receive email on the basis of the terms set out at: > http://www.tid.es/ES/PAGINAS/disclaimer.aspx > > _______________________________________________ > vnfpool mailing list > vnfpool@ietf.org > https://www.ietf.org/mailman/listinfo/vnfpool > From zehn.cao@gmail.com Mon Dec 2 00:13:51 2013 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 DEEE71AE3A2 for ; Mon, 2 Dec 2013 00:13:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 WxY46nzDDhre for ; Mon, 2 Dec 2013 00:13:50 -0800 (PST) Received: from mail-qe0-x22f.google.com (mail-qe0-x22f.google.com [IPv6:2607:f8b0:400d:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 071291AE36E for ; Mon, 2 Dec 2013 00:13:49 -0800 (PST) Received: by mail-qe0-f47.google.com with SMTP id t7so12664686qeb.6 for ; Mon, 02 Dec 2013 00:13:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=MdHXWOjlY0SNMABeNlzcwd3b8k5eYHFGGibr3hmmrac=; b=gyjc/nY3HmpqVkAxcduh6fLM85a/S7dHp2BaEll9kI0sOih3tR6DH8031wwWrrRrhx 5UTFX3MaLIfVjcZM2f4VNx7iVH9YGw5tBg2kU4PkyW68Dj7uItWHq6J3baNTzBTy+Elp osmFzNol1/q74uZ3Jjd71VbXwW5bfF227NYO4+kgAwY6gkbf0tSvuYoTCQr9LMVQpA2f t/jIkZb0hzwFQoOKIzeCxEDyTdWdPJ71nBOZbLHSTaEDz258Syr89Ve4wymVnxLAPmk+ ZmEc2si15OKvmHYZe0DCCTqqMVYzINnPSH3PORzOX4hngNvFu2XzXpFjoNcmQ1W1c2sw 8FjQ== MIME-Version: 1.0 X-Received: by 10.224.72.15 with SMTP id k15mr112173024qaj.58.1385972027723; Mon, 02 Dec 2013 00:13:47 -0800 (PST) Received: by 10.96.63.234 with HTTP; Mon, 2 Dec 2013 00:13:47 -0800 (PST) In-Reply-To: References: Date: Mon, 2 Dec 2013 16:13:47 +0800 Message-ID: From: "Cao,Zhen" To: "Y. Richard Yang" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "vnfpool@ietf.org" , Mukhtiar Shaikh , Zongning Subject: Re: [vnfpool] VNF Pool 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, 02 Dec 2013 08:13:52 -0000 I agree the discussion is one of good ones. but two more questions to discuss: a) Resilience of vnf pool is independent of the service chaining. Even without service chain, the problem still exist. I do not know if you agree. b) The description in the text now seems not highly relevant to the NFV context. Some description seems valid even without virtualisation basis. Anyway service chain is not only a problem originating from virtualisation but more general. Do we need to find more vnf related text, e.g., what's the difference between vnf reliability and none virtualized system reliability. Regards, cz On Sun, Dec 1, 2013 at 1:42 PM, Y. Richard Yang wrote: > The discussion regarding FSC is a good one. Overall, I like the Problem > Statement. Two concepts stand out: VNF and Service Chain, both are large > concepts. The nice drawing by Linda helps, but I believe that this is a > simplified illustration, as during the meeting Diego showed that the mode= l > can be more complex, if I understand him correctly. Does the intended WG > want to build on top of these two specific concepts, or build a more gene= ral > and hence reusable, modular solution? I see the more general solution > approach as one possible way to decouple from the Service Chain definitio= ns > WG. To be concrete, the concepts from Chabby and rservpool appear to be > general. > >> During the Vancouver bar BoF, we also discussed the relation between VNF >> pool and FSC. > > Sorry I was not there physically. > >> We agreed that VNF pool will address different problem space. >> Assuming that some chaining mechanism has been defined in FSC regarding >> how >> to connect/chain the VNF instances, we focus on signaling related to >> resiliency, e.g. backup announcement, status notification, etc. So I=92d= see >> these two groups as complementary. > > Ok, then we need to specify in the charter that the discussion in this > working group is orthogonal to the detail chaining header used or > chosen by the SFC group, and the way the two potential groups works > together. > >> >> You are absolutely right that these two groups are related with each >> other. >> I can put some text in our proposed working scope to clarify this issue. >> > _______________________________________________ > vnfpool mailing list > vnfpool@ietf.org > https://www.ietf.org/mailman/listinfo/vnfpool From zongning@huawei.com Mon Dec 2 01:17:38 2013 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 8FC7F1AE392 for ; Mon, 2 Dec 2013 01:17:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.602 X-Spam-Level: X-Spam-Status: No, score=-103.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 6yj9PUpuRSgn for ; Mon, 2 Dec 2013 01:17:36 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5B4EE1AE38A for ; Mon, 2 Dec 2013 01:17:35 -0800 (PST) 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 BAX57029; Mon, 02 Dec 2013 09:17:32 +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; Mon, 2 Dec 2013 09:16:45 +0000 Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 2 Dec 2013 09:17:30 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Mon, 2 Dec 2013 17:17:23 +0800 From: Zongning To: "Cao,Zhen" , "Y. Richard Yang" Thread-Topic: [vnfpool] VNF Pool Problem Statement Thread-Index: Ac7mmacuBQUiFtBEQ2CEYoAlHpu1YwBEYqIAAHh0j3AAxZS1AAARbS0w//+AJICAAtfoAIABvJqA//91TdA= Date: Mon, 2 Dec 2013 09:17:23 +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.28] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "vnfpool@ietf.org" , Mukhtiar Shaikh Subject: Re: [vnfpool] VNF Pool 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, 02 Dec 2013 09:17:38 -0000 Hi, Zhen and Richard, Thanks for the comments. Please allow me to combine your comments to a single one - "we need more de= scriptive text about VNF, as well as how it would impact reliability?" :-)) I plan to add more sentences as below (or similar) into the problem stateme= nt. A virtualized network function (VNF) provides network functions (e.g. firew= alling, load balancing), but typically can be modularized and decomposed as= instance running on general server via virtualization layer. This is disti= nct from monolithic network devices, where a number of different services a= re provided in the same device... I think ETSI NFV has definitions on VNF, = VNFC, etc. which VNF pool can follow upon and use as starting point. In the context of NFV, network services are typically implemented by a set = of sequentially connected VNF instances deployed at different points in the= network... The challenges to reliability would then include: 1) for a single virtual i= nstance, it normally doesn't assume built-in high reliability mechanism imp= lemented by dedicated device on its host (i.e. general server). Therefore r= edundancy model where the role of active, standby instance are more dynamic= ...; 2) Virtual instance migration would require standard based, efficient = stateful failover especially in the case of multi-vendor VNF deployment...;= 3) the topology nature of VNF chain may require additional reliability sup= ports, e.g. failure/status notification between node within the chain...; <= we can add more later> -Ning > -----Original Message----- > From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of Cao,Zhen > Sent: Monday, December 02, 2013 4:14 PM > To: Y. Richard Yang > Cc: vnfpool@ietf.org; Mukhtiar Shaikh; Zongning > Subject: Re: [vnfpool] VNF Pool Problem Statement >=20 > I agree the discussion is one of good ones. >=20 > but two more questions to discuss: >=20 > a) Resilience of vnf pool is independent of the service chaining. Even > without service chain, the problem still exist. I do not know if you > agree. >=20 > b) The description in the text now seems not highly relevant to the > NFV context. Some description seems valid even without virtualisation > basis. Anyway service chain is not only a problem originating from > virtualisation but more general. Do we need to find more vnf related > text, e.g., what's the difference between vnf reliability and none > virtualized system reliability. >=20 > Regards, > cz >=20 > On Sun, Dec 1, 2013 at 1:42 PM, Y. Richard Yang wrote: > > The discussion regarding FSC is a good one. Overall, I like the Problem > > Statement. Two concepts stand out: VNF and Service Chain, both are larg= e > > concepts. The nice drawing by Linda helps, but I believe that this is a > > simplified illustration, as during the meeting Diego showed that the mo= del > > can be more complex, if I understand him correctly. Does the intended W= G > > want to build on top of these two specific concepts, or build a more ge= neral > > and hence reusable, modular solution? I see the more general solution > > approach as one possible way to decouple from the Service Chain definit= ions > > WG. To be concrete, the concepts from Chabby and rservpool appear to be > > general. > > > >> During the Vancouver bar BoF, we also discussed the relation between V= NF > >> pool and FSC. > > > > Sorry I was not there physically. > > > >> We agreed that VNF pool will address different problem space. > >> Assuming that some chaining mechanism has been defined in FSC regardin= g > >> how > >> to connect/chain the VNF instances, we focus on signaling related to > >> resiliency, e.g. backup announcement, status notification, etc. So I'd= see > >> these two groups as complementary. > > > > Ok, then we need to specify in the charter that the discussion in this > > working group is orthogonal to the detail chaining header used or > > chosen by the SFC group, and the way the two potential groups works > > together. > > > >> > >> You are absolutely right that these two groups are related with each > >> other. > >> I can put some text in our proposed working scope to clarify this issu= e. > >> > > _______________________________________________ > > vnfpool mailing list > > vnfpool@ietf.org > > https://www.ietf.org/mailman/listinfo/vnfpool > _______________________________________________ > vnfpool mailing list > vnfpool@ietf.org > https://www.ietf.org/mailman/listinfo/vnfpool From diego@tid.es Mon Dec 2 01:32:25 2013 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 4B7CC1AE082 for ; Mon, 2 Dec 2013 01:32:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.203 X-Spam-Level: X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 eP8M76JEfLHE for ; Mon, 2 Dec 2013 01:32:22 -0800 (PST) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 598DA1AE07D for ; Mon, 2 Dec 2013 01:32:21 -0800 (PST) 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 <0MX600M9HAHUCE@tid.hi.inet> for vnfpool@ietf.org; Mon, 02 Dec 2013 10:32:18 +0100 (MET) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id A4.63.02810.2A35C925; Mon, 02 Dec 2013 10:32:18 +0100 (CET) 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 <0MX600M9DAHUCE@tid.hi.inet> for vnfpool@ietf.org; Mon, 02 Dec 2013 10:32:18 +0100 (MET) Received: from EX10-MB1-MAD.hi.inet ([169.254.1.96]) by EX10-HTCAS8-MAD.hi.inet ([fe80::41c8:e965:8a6:de67%11]) with mapi id 14.03.0158.001; Mon, 02 Dec 2013 10:32:18 +0100 Date: Mon, 02 Dec 2013 09:32:17 +0000 From: "Diego R. Lopez" In-reply-to: <529912BF.4010307@nomountain.net> X-Originating-IP: [10.95.64.115] To: Melinda Shore Message-id: <701E4DC3-754C-4308-B507-D85BCAB9B2D6@tid.es> Content-id: <1E055DA703F2834B84631529A97EF25C@hi.inet> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US, es-ES Thread-topic: [vnfpool] Question about addressing in pools Thread-index: AQHO7VD7HzaG9PBs5kizKdK8S0i3SppAg0MA X-AuditID: 0a5f4e69-b7f9b8e000000afa-b4-529c53a2e24e X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42Lhivcz1F0UPCfI4MhpA4sZl/6zODB6LFny kymAMYrLJiU1J7MstUjfLoErY9bNDewFx8QqFh+eydTA+Ee0i5GTQ0LAROLg5hPsELaYxIV7 69lAbCGBbYwSe5ZZdDFyAdm/GCXunLnOCuFsYJS4uuU4UxcjBweLgKrE1kfcIA1sQOaj5t9g g4QFLCWePV0BZnMK6En8WNvDDLFAQeLPuccsILaIgIHEpyfNYDXMApoSnb+PgC3mBer9vuIS G0TcTGLN6VdMEHFBiR+T77GArGUWUJeYMiUXokRcorn1JguErSgxbVEDI4jNKCAr8W7+fFaI VVYSXxfMYgNpFREwkriyQAbiGgGJJXvOQ10mKvHy8T9WiNd1JbpntjJOYJSYheSIWUiOmIVw xCwkR8xCcsQCRtZVjGLFSUWZ6RkluYmZOekGRnoZmXqZeaklmxgh8Za5g3H5TpVDjAIcjEo8 vBXHZgcJsSaWFVfmHmKU4GBWEuH18JkTJMSbklhZlVqUH19UmpNafIiRiYNTqoGx5oR7hlOX 48w62/mvo0RZ9jYvbz6kHCHz+PkBuSNriv6tsLc4qKqrHPSvplfb4NHSju3BZr8P7JyzhuPy 7qd1a848kVj8a6/SZM2eom+n+pdZn9lx5H7tfN68A1EsNWZfLARetyqu7mbu3bB8aqJj7az4 s8qOPq82GVV+uW7veHmGe/Es62pVJZbijERDLeai4kQAb6Ml6ZUCAAA= References: <529912BF.4010307@nomountain.net> Cc: "vnfpool@ietf.org" Subject: Re: [vnfpool] Question about addressing in pools 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, 02 Dec 2013 09:32:25 -0000 SGkgTWVsaW5kYSwNCg0KSSBhZ3JlZSB5b3UgaGF2ZSBhIHBvaW50IGhlcmUuIEFuZCBvbmUgb2Yg dGhlIHJlYXNvbnMgZm9yIHVzaW5nIHJzZXJwb29sIG9yIHNpbWlsYXIgbWVjaGFuaXNtcyB3b3Vs ZCBiZSBwcmVjaXNlbHkgdG8gaGF2ZSB0aG9zZSBhZGRyZXNzIG1hbmFnZW1lbnQgaW4gcGxhY2Uu IE1heSBiZSBhIGJldHRlciB3b3JkaW5nIHdvdWxkIGJlIHNvbWV0aGluZyBsaWtlICJBbnkgaW5z dGFuY2Ugb2YgVk5GIzEgY2FuIGJlIHN1cmUgaXQgd2lsbCBiZSB0YWxraW5nIHdpdGggYW4gYXBw cm9wcmlhdGUgaW5zdGFuY2Ugb2YgVk5GIzIiDQoNCkJlIGdvb2RlLA0KDQpPbiAyOSBOb3YgMjAx MywgYXQgMjM6MTggLCBNZWxpbmRhIFNob3JlIHdyb3RlOg0KDQo+IEl0J3MgdHlwaWNhbGx5IHRo ZSBjYXNlIGluIGEgc3RhdGVmdWwgZmFpbG92ZXIgc2NlbmFyaW8gdGhhdA0KPiB3aGVuIGEgZGV2 aWNlIGhhcyBhIGdpdmVuIGFkZHJlc3MgKG9yIHNldCBvZiBhZGRyZXNzZXMpLCBhZnRlcg0KPiBh IGZhaWxvdmVyIHRoZSBuZXcgaW5zdGFuY2UgaGFzIHRoZSBzYW1lIGFkZHJlc3MuICBUaGUgY3Vy cmVudA0KPiB2ZXJzaW9uIG9mIHRoZSBwcm9ibGVtIHN0YXRlbWVudCBpbmNsdWRlcyB0aGUgZm9s bG93aW5nIHRleHQ6DQo+ICJGb3IgZXhhbXBsZSwgaG93IGRvZXMgYW4gaW5zdGFuY2Ugb2YgVk5G IzEga25vdyB3aGljaCBpbnN0YW5jZQ0KPiBpbiB0aGUgcG9vbCBvZiBWTkYjMiI/DQo+DQo+IEl0 IHNlZW1zIHRvIG1lIHRoYXQgdW5sZXNzIHdlJ3JlIGFzc3VtaW5nIHRoZSB1c2Ugb2YgaGFyZHdh cmUNCj4gYWRkcmVzc2luZyB3ZSBzaG91bGQgcHJvYmFibHkgZXhwbGFpbiB3aHkgdGhpcyBpcyBh biBpc3N1ZS4NCj4gSWYgd2UgZ28gd2l0aCByc2VycG9vbCBvciBhIHNpbWlsYXIgbWVjaGFuaXNt LCBhZGRyZXNzZXMgYXJlDQo+IG5vdCBzaGFyZWQgYnV0IGluc3RlYWQgYSBwb29sIG1hbmFnZXIg KHN1Y2ggYXMgYW4gRU5SUCBzZXJ2ZXIpDQo+IGlzIHVzZWQgdG8gc2VsZWN0ICJsaXZlIiBpbnN0 YW5jZXMgYW5kIGFkZHJlc3NpbmcgaXMgbWVkaWF0ZWQNCj4gdGhyb3VnaCB0aGUgcG9vbGluZyBt ZWNoYW5pc20uDQo+DQo+IEl0IHNlZW1zIHRvIG1lIHRoYXQgd2Ugc2hvdWxkIHByb2JhYmx5IGJl IHByZXBhcmVkIHRvIGRpc2N1c3MNCj4gdGhlIHRyYWRlb2ZmcyBiZXR3ZWVuIHRoZSB0d28gYXBw cm9hY2hlcy4NCj4NCj4gTWVsaW5kYQ0KPiAtLQ0KPiBNZWxpbmRhIFNob3JlDQo+IE5vIE1vdW50 YWluIFNvZnR3YXJlDQo+IG1lbGluZGEuc2hvcmVAbm9tb3VudGFpbi5uZXQNCj4NCj4gIlNvZnR3 YXJlIGxvbmdhLCBoYXJkd2FyZSBicmV2aXMuIg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiB2bmZwb29sIG1haWxpbmcgbGlzdA0KPiB2bmZwb29s QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdm5mcG9v bA0KDQoNCi0tDQoiRXN0YSB2ZXogbm8gZmFsbGFyZW1vcywgRG9jdG9yIEluZmllcm5vIg0KDQpE ciBEaWVnbyBSLiBMb3Bleg0KVGVsZWZvbmljYSBJK0QNCmh0dHA6Ly9wZW9wbGUudGlkLmVzL2Rp ZWdvLmxvcGV6Lw0KDQplLW1haWw6IGRpZWdvQHRpZC5lcw0KVGVsOiAgICArMzQgOTEzIDEyOSAw NDENCk1vYmlsZTogKzM0IDY4MiAwNTEgMDkxDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkVz dGUgbWVuc2FqZSBzZSBkaXJpZ2UgZXhjbHVzaXZhbWVudGUgYSBzdSBkZXN0aW5hdGFyaW8uIFB1 ZWRlIGNvbnN1bHRhciBudWVzdHJhIHBvbMOtdGljYSBkZSBlbnbDrW8geSByZWNlcGNpw7NuIGRl IGNvcnJlbyBlbGVjdHLDs25pY28gZW4gZWwgZW5sYWNlIHNpdHVhZG8gbcOhcyBhYmFqby4NClRo aXMgbWVzc2FnZSBpcyBpbnRlbmRlZCBleGNsdXNpdmVseSBmb3IgaXRzIGFkZHJlc3NlZS4gV2Ug b25seSBzZW5kIGFuZCByZWNlaXZlIGVtYWlsIG9uIHRoZSBiYXNpcyBvZiB0aGUgdGVybXMgc2V0 IG91dCBhdDoNCmh0dHA6Ly93d3cudGlkLmVzL0VTL1BBR0lOQVMvZGlzY2xhaW1lci5hc3B4DQo= From chidung.lac@orange.com Mon Dec 2 02:01:38 2013 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 85F071AE02E for ; Mon, 2 Dec 2013 02:01:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.284 X-Spam-Level: X-Spam-Status: No, score=-0.284 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665] 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 AbJEs0656TU8 for ; Mon, 2 Dec 2013 02:01:35 -0800 (PST) Received: from r-mail1.rd.orange.com (r-mail1.rd.orange.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id 110011A8026 for ; Mon, 2 Dec 2013 02:01:22 -0800 (PST) Received: from r-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 2A46EDE4003 for ; Mon, 2 Dec 2013 11:03:03 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.orange.com (Postfix) with ESMTP id 1BD38DE4001 for ; Mon, 2 Dec 2013 11:03:03 +0100 (CET) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Dec 2013 11:01:18 +0100 Received: from [10.193.5.32] ([10.193.5.32]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Dec 2013 11:01:18 +0100 Message-ID: <529C5A30.3070000@orange.com> Date: Mon, 02 Dec 2013 11:00:16 +0100 From: LAC Chidung User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: vnfpool@ietf.org References: <52940EB0.6040601@kddilabs.jp> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030002010808080508000506" X-OriginalArrivalTime: 02 Dec 2013 10:01:18.0396 (UTC) FILETIME=[71F497C0:01CEEF45] Subject: Re: [vnfpool] VNF Pool 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, 02 Dec 2013 10:01:38 -0000 This is a multi-part message in MIME format. --------------030002010808080508000506 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi all, /Reliability is the ability of an item to perform a required function under stated conditions for a stated period of time/, while/Availability is a measure of the degree to which an item is in an operable state when called upon to perform./ (D.J. Klinger, Y. Nakada, and M.A. Menedez (Eds.), "AT&T Reliability Manual", Van Nostrand Reinhold, 1990) Applied to the PSTN, the former includes "My call is not dropped during a conversation", while the latter asks for "The phone service is ready, i.e., a tone is present, whenever I lift the handset". For years, /Dependability /has encompassed these concepts (together with others such as /Maintainability) /to characterize the good behavior (robustness) of a system when facing *accidental *events (design faults, operations errors, hardware failures, natural disasters, etc.) , while /Security, /which includes all *intentional *actions (attacks, ...), is kept apart. This explains the presence, up to now, of two communities working in these two separated subjects. As (i) unavailability may the consequence of, e.g., software/hardware failures OR (D)DoS attacks (ii) /Resilience/ is a fashionable expression* (iii) etc., resilience is used since the last few years to encompass both dependability and security. Best, Chidung _______ *: see, e.g., Obama's praise for the resilience of the Indian people (http://articles.latimes.com/2010/nov/06/world/la-fgw-obama-mumbai-20101107) Le 02/12/2013 08:21, Cao,Zhen a écrit : > Good point, Diego. > I checked out the NFV ISG released documents of requirements and > terminology, where i could not find 'reliability' but 'resilience'. > -cz > > On Wed, Nov 27, 2013 at 2:06 AM, Diego R. Lopez wrote: >> Hi, >> When it comes to the reliability/availability issue I guess providing some >> (condensed) definition from the NFV REL group would help... >> Be goode, >> >> On 26 Nov 2013, at 04:00 , Hidetoshi Yokota wrote: >> >> Hi Ning and all, >> The proposed PS is a very good starting point covering major issues for the >> goal of VNF pool. One thing that I could add is the synchronization between >> the vNF migration/replacement and routing to make the relevant flows >> forwarded to the new location. The challenge is that the VMs/severs in a >> pool could be deployed over topologically different networks (in the >> physical world) and VNF migration could involve topologically independent >> routing. There are multiple ways to do it, but we should first generalize >> this issue and specify a common mechanism that may leverage existing ones. >> If this is already covered, that's fine. If some additional text is useful, >> the following could be a summary: >> o Synchronization between vNF migration and flow forwarding, which may >> require topologically independent routing in the physical transport network; >> There is a discussion about "reliability" and "availability" in another >> thread and I think this is also an issue in ETSI NFV. We need to define them >> either in this group or NFV to share the same view. >> Regards, >> -- >> Hidetoshi Yokota >> >> KDDI R&D Laboratories, Inc. >> e-mail:yokota@kddilabs.jp >> >> (2013/11/21 18:11), Zongning wrote: >> >> Hi, >> Please review the below brief version of VNF Pool Problem Statement, and >> feedback with your comments. I hope this text can serve as a base of VNF >> Pool Charter, by carving out real problems and work items. >> =========================================================================================== >> A virtualized network function (VNF) (e.g. vFW, vLB) provides the same >> function as the equivalent network function (e.g. FW, LB), but is usually >> instantiated as a cluster of software instances running on general purpose >> servers via virtualization platform. In an environment based on VNFs, a >> network service is typically realized by a chain of VNFs where the instances >> of adjacent VNFs are preferably directly connected. >> A VNF chain introduces additional points of failure beyond those inherent in >> a single dedicated server, and therefore additional challenges on >> reliability. By reliability, we mean the ability of a VNF chain to continue >> function when having transition or failure within the chain. For example, >> there are more factors such as software failure, server over-utilization, >> instance migration that potentially cause VNF instance transition or >> failure. Although a general pooling mechanism can be applied to address the >> reliability of a single VNF, there are still problems when addressing the >> reliability of a VNF chain, i.e. multiple pools for multiple VNFs. For >> example, how does an instance of VNF#1 know which instance in the pool of >> VNF#2 will replace the instance of VNF#2 it connects to? How does an >> instance of VNF#1 know the state of instance of VNF#2 that it connects to in >> order to enforce policy for reliability like load sharing, switch before >> break? How is the service state of an instance held and accessed for >> efficient synchronization with backup instances? >> The overall problem space can be further breakdown to the following study >> items: >> - Signalling to handle reliability and instance transition >> requirements >> o Signalling between VNF pools for transition (e.g. state change, scaling, >> moving) notification, backup announcement; >> o Service state management (e.g. synchronizing method, state data format, >> location and mechanism to access state data) within VNF pool; >> o Obtaining underlying network information (e.g. ALTO, I2RS); >> o Signalling to CMS for instance deployment reflecting reliability >> requirements (e.g. distribution of instances on different VMs or >> hypervisors); >> - Transport characteristics >> o Identify and analyze reliable transport characteristics for control >> plane traffic; >> o Analysis of transport security characteristics to provide protection >> against known threats, and identification of an appropriate trust model; >> =========================================================================================== >> Thanks. >> -Ning >> >> -- >> "Esta vez no fallaremos, Doctor Infierno" >> >> Dr Diego R. Lopez >> Telefonica I+D >> http://people.tid.es/diego.lopez/ >> >> e-mail: diego@tid.es >> Tel: +34 913 129 041 >> Mobile: +34 682 051 091 >> ----------------------------------------- >> >> ________________________________ >> >> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar >> nuestra política de envío y recepción de correo electrónico en el enlace >> situado más abajo. >> This message is intended exclusively for its addressee. We only send and >> receive email on the basis of the terms set out at: >> http://www.tid.es/ES/PAGINAS/disclaimer.aspx >> >> _______________________________________________ >> vnfpool mailing list >> vnfpool@ietf.org >> https://www.ietf.org/mailman/listinfo/vnfpool --------------030002010808080508000506 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi all,
Reliability is the ability of an item to perform a required function under stated conditions for a stated period of time, while Availability is a measure of the degree to which an item is in an operable state when called upon to perform. (D.J. Klinger, Y. Nakada, and M.A. Menedez (Eds.), "AT&T Reliability Manual", Van Nostrand Reinhold, 1990)
Applied to the PSTN, the former includes "My call is not dropped during a conversation", while the latter asks for "The phone service is ready, i.e., a tone is present, whenever I lift the handset".
For years, Dependability has encompassed these concepts (together with others such as Maintainability) to characterize the good behavior (robustness) of a system when facing accidental events (design faults, operations errors, hardware failures, natural disasters, etc.) , while Security, which includes all intentional actions (attacks, ...), is kept apart. This explains the presence, up to now, of two communities working in these two separated subjects.
As (i) unavailability may the consequence of, e.g., software/hardware failures OR (D)DoS attacks (ii) Resilience is a fashionable expression* (iii) etc., resilience is used since the last few years to encompass both dependability and security.
Best,
Chidung
_______
*: see, e.g., Obama's praise for the resilience of the Indian people (http://articles.latimes.com/2010/nov/06/world/la-fgw-obama-mumbai-20101107)

Le 02/12/2013 08:21, Cao,Zhen a écrit :
Good point, Diego.
I checked out the NFV ISG released documents of requirements and
terminology, where i could not find 'reliability' but 'resilience'.
-cz

On Wed, Nov 27, 2013 at 2:06 AM, Diego R. Lopez <diego@tid.es> wrote:

Hi,
When it comes to the reliability/availability issue I guess providing some
(condensed) definition from the NFV REL group would help...
Be goode,

On 26 Nov 2013, at 04:00 , Hidetoshi Yokota wrote:

Hi Ning and all,
The proposed PS is a very good starting point covering major issues for the
goal of VNF pool. One thing that I could add is the synchronization between
the vNF migration/replacement and routing to make the relevant flows
forwarded to the new location. The challenge is that the VMs/severs in a
pool could be deployed over topologically different networks (in the
physical world) and VNF migration could involve topologically independent
routing. There are multiple ways to do it, but we should first generalize
this issue and specify a common mechanism that may leverage existing ones.
If this is already covered, that's fine. If some additional text is useful,
the following could be a summary:
o Synchronization between vNF migration and flow forwarding, which may
require topologically independent routing in the physical transport network;
There is a discussion about "reliability" and "availability" in another
thread and I think this is also an issue in ETSI NFV. We need to define them
either in this group or NFV to share the same view.
Regards,
--
Hidetoshi Yokota

KDDI R&D Laboratories, Inc.
e-mail:yokota@kddilabs.jp

(2013/11/21 18:11), Zongning wrote:

Hi,
Please review the below brief version of VNF Pool Problem Statement, and
feedback with your comments. I hope this text can serve as a base of VNF
Pool Charter, by carving out real problems and work items.
===========================================================================================
A virtualized network function (VNF) (e.g. vFW, vLB) provides the same
function as the equivalent network function (e.g. FW, LB), but is usually
instantiated as a cluster of software instances running on general purpose
servers via virtualization platform. In an environment based on VNFs, a
network service is typically realized by a chain of VNFs where the instances
of adjacent VNFs are preferably directly connected.
A VNF chain introduces additional points of failure beyond those inherent in
a single dedicated server, and therefore additional challenges on
reliability. By reliability, we mean the ability of a VNF chain to continue
function when having transition or failure within the chain. For example,
there are more factors such as software failure, server over-utilization,
instance migration that potentially cause VNF instance transition or
failure. Although a general pooling mechanism can be applied to address the
reliability of a single VNF, there are still problems when addressing the
reliability of a VNF chain, i.e. multiple pools for multiple VNFs. For
example, how does an instance of VNF#1 know which instance in the pool of
VNF#2 will replace the instance of VNF#2 it connects to? How does an
instance of VNF#1 know the state of instance of VNF#2 that it connects to in
order to enforce policy for reliability like load sharing, switch before
break? How is the service state of an instance held and accessed for
efficient synchronization with backup instances?
The overall problem space can be further breakdown to the following study
items:
-          Signalling to handle reliability and instance transition
requirements
o   Signalling between VNF pools for transition (e.g. state change, scaling,
moving) notification, backup announcement;
o   Service state management (e.g. synchronizing method, state data format,
location and mechanism to access state data) within VNF pool;
o   Obtaining underlying network information (e.g. ALTO, I2RS);
o   Signalling to CMS for instance deployment reflecting reliability
requirements (e.g. distribution of instances on different VMs or
hypervisors);
-          Transport characteristics
o   Identify and analyze reliable transport characteristics for control
plane traffic;
o   Analysis of transport security characteristics to provide protection
against known threats, and identification of an appropriate trust model;
===========================================================================================
Thanks.
-Ning

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: diego@tid.es
Tel:    +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar
nuestra política de envío y recepción de correo electrónico en el enlace
situado más abajo.
This message is intended exclusively for its addressee. We only send and
receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

_______________________________________________
vnfpool mailing list
vnfpool@ietf.org
https://www.ietf.org/mailman/listinfo/vnfpool
--------------030002010808080508000506-- From bill.wu@huawei.com Mon Dec 2 17:19:35 2013 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 860D61AE009 for ; Mon, 2 Dec 2013 17:19:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 6rK7UdwWiP3c for ; Mon, 2 Dec 2013 17:19:30 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5372D1AE005 for ; Mon, 2 Dec 2013 17:19:29 -0800 (PST) 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 BAY25520; Tue, 03 Dec 2013 01:19:26 +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; Tue, 3 Dec 2013 01:18:36 +0000 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 3 Dec 2013 01:19:22 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Tue, 3 Dec 2013 09:19:16 +0800 From: Qin Wu To: LAC Chidung , "vnfpool@ietf.org" Thread-Topic: [vnfpool] VNF Pool Problem Statement Thread-Index: Ac7mmacuBQUiFtBEQ2CEYoAlHpu1YwDduMMAAB+kuIABF0DFAAAFh5wAADCzs/A= Date: Tue, 3 Dec 2013 01:19:15 +0000 Message-ID: References: <52940EB0.6040601@kddilabs.jp> <529C5A30.3070000@orange.com> In-Reply-To: <529C5A30.3070000@orange.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.149] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA43C67027nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [vnfpool] VNF Pool 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: Tue, 03 Dec 2013 01:19:35 -0000 --_000_B8F9A780D330094D99AF023C5877DABA43C67027nkgeml501mbschi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In my understanding, availability is more about "don't loss connection to t= he network at any time anywhere using any device" or ubiquity. The resilien= ce should be used to support high availability as well. If resilience doesn't mean high availability then resilience can be redefin= ed to support high availability. My 2 cents. Regards! -Qin From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of LAC Chidung Sent: Monday, December 02, 2013 6:00 PM To: vnfpool@ietf.org Subject: Re: [vnfpool] VNF Pool Problem Statement Hi all, Reliability is the ability of an item to perform a required function under = stated conditions for a stated period of time, while Availability is a meas= ure of the degree to which an item is in an operable state when called upon= to perform. (D.J. Klinger, Y. Nakada, and M.A. Menedez (Eds.), "AT&T Relia= bility Manual", Van Nostrand Reinhold, 1990) Applied to the PSTN, the former includes "My call is not dropped during a c= onversation", while the latter asks for "The phone service is ready, i.e., = a tone is present, whenever I lift the handset". For years, Dependability has encompassed these concepts (together with othe= rs such as Maintainability) to characterize the good behavior (robustness) = of a system when facing accidental events (design faults, operations errors= , hardware failures, natural disasters, etc.) , while Security, which inclu= des all intentional actions (attacks, ...), is kept apart. This explains th= e presence, up to now, of two communities working in these two separated su= bjects. As (i) unavailability may the consequence of, e.g., software/hardware failu= res OR (D)DoS attacks (ii) Resilience is a fashionable expression* (iii) et= c., resilience is used since the last few years to encompass both dependabi= lity and security. Best, Chidung _______ *: see, e.g., Obama's praise for the resilience of the Indian people (http:= //articles.latimes.com/2010/nov/06/world/la-fgw-obama-mumbai-20101107) Le 02/12/2013 08:21, Cao,Zhen a =E9crit : Good point, Diego. I checked out the NFV ISG released documents of requirements and terminology, where i could not find 'reliability' but 'resilience'. -cz On Wed, Nov 27, 2013 at 2:06 AM, Diego R. Lopez wrote: Hi, When it comes to the reliability/availability issue I guess providing some (condensed) definition from the NFV REL group would help... Be goode, On 26 Nov 2013, at 04:00 , Hidetoshi Yokota wrote: Hi Ning and all, The proposed PS is a very good starting point covering major issues for the goal of VNF pool. One thing that I could add is the synchronization between the vNF migration/replacement and routing to make the relevant flows forwarded to the new location. The challenge is that the VMs/severs in a pool could be deployed over topologically different networks (in the physical world) and VNF migration could involve topologically independent routing. There are multiple ways to do it, but we should first generalize this issue and specify a common mechanism that may leverage existing ones. If this is already covered, that's fine. If some additional text is useful, the following could be a summary: o Synchronization between vNF migration and flow forwarding, which may require topologically independent routing in the physical transport network= ; There is a discussion about "reliability" and "availability" in another thread and I think this is also an issue in ETSI NFV. We need to define the= m either in this group or NFV to share the same view. Regards, -- Hidetoshi Yokota KDDI R&D Laboratories, Inc. e-mail:yokota@kddilabs.jp (2013/11/21 18:11), Zongning wrote: Hi, Please review the below brief version of VNF Pool Problem Statement, and feedback with your comments. I hope this text can serve as a base of VNF Pool Charter, by carving out real problems and work items. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D A virtualized network function (VNF) (e.g. vFW, vLB) provides the same function as the equivalent network function (e.g. FW, LB), but is usually instantiated as a cluster of software instances running on general purpose servers via virtualization platform. In an environment based on VNFs, a network service is typically realized by a chain of VNFs where the instance= s of adjacent VNFs are preferably directly connected. A VNF chain introduces additional points of failure beyond those inherent i= n a single dedicated server, and therefore additional challenges on reliability. By reliability, we mean the ability of a VNF chain to continue function when having transition or failure within the chain. For example, there are more factors such as software failure, server over-utilization, instance migration that potentially cause VNF instance transition or failure. Although a general pooling mechanism can be applied to address the reliability of a single VNF, there are still problems when addressing the reliability of a VNF chain, i.e. multiple pools for multiple VNFs. For example, how does an instance of VNF#1 know which instance in the pool of VNF#2 will replace the instance of VNF#2 it connects to? How does an instance of VNF#1 know the state of instance of VNF#2 that it connects to i= n order to enforce policy for reliability like load sharing, switch before break? How is the service state of an instance held and accessed for efficient synchronization with backup instances? The overall problem space can be further breakdown to the following study items: - Signalling to handle reliability and instance transition requirements o Signalling between VNF pools for transition (e.g. state change, scaling= , moving) notification, backup announcement; o Service state management (e.g. synchronizing method, state data format, location and mechanism to access state data) within VNF pool; o Obtaining underlying network information (e.g. ALTO, I2RS); o Signalling to CMS for instance deployment reflecting reliability requirements (e.g. distribution of instances on different VMs or hypervisors); - Transport characteristics o Identify and analyze reliable transport characteristics for control plane traffic; o Analysis of transport security characteristics to provide protection against known threats, and identification of an appropriate trust model; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Thanks. -Ning -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego@tid.es Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------------- ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el e= nlace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx _______________________________________________ vnfpool mailing list vnfpool@ietf.org https://www.ietf.org/mailman/listinfo/vnfpool --_000_B8F9A780D330094D99AF023C5877DABA43C67027nkgeml501mbschi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

In my understanding, avai= lability is more about “don’t loss connection to the network at= any time anywhere using any device” or ubiquity. The resilience shou= ld be used to support high availability as well.

 <= /p>

If resilience doesn’= ;t mean high availability then resilience can be redefined to support high = availability.

 <= /p>

My 2 cents.

 <= /p>

Regards!

-Qin

From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of LAC Chidung
Sent: Monday, December 02, 2013 6:00 PM
To: vnfpool@ietf.org
Subject: Re: [vnfpool] VNF Pool Problem Statement<= /p>

 

Hi all,
Reliability is the ability of an item to perform a required function und= er stated conditions for a stated period of time, while Availability= is a measure of the degree to which an item is in an operable state when c= alled upon to perform. (D.J. Klinger, Y. Nakada, and M.A. Menedez (Eds.), "AT&T Reliability Ma= nual", Van Nostrand Reinhold, 1990)
Applied to the PSTN, the former includes "My call is not dropped durin= g a conversation", while the latter asks for "The phone service i= s ready, i.e., a tone is present, whenever I lift the handset".
For years, Dependability has encompassed these concepts (together wi= th others such as Maintainability) to characterize the good behavior (robustness) of a= system when facing accidental events (design faults, operations errors, hardware failur= es, natural disasters, etc.) , while Security, which includes all intentional actions (attacks, ..= .), is kept apart. This explains the presence, up to now, of two communitie= s working in these two separated subjects.
As (i) unavailability may the consequence of, e.g., software/hardware failu= res OR (D)DoS attacks (ii) Resilience is a fashionable expression* (iii) etc., resilience is us= ed since the last few years to encompass both dependability and security. Best,
Chidung
_______
*: see, e.g., Obama's praise for the resilience of the Indian people (http://articles.latimes.com/2010/nov/06/world/la-fgw-obama-mumbai-20= 101107)

Le 02/12/2013 08:21= , Cao,Zhen a =E9crit :

Good point, Diego.
I checked out the NFV ISG released documents of requirements and<=
/o:p>
terminology, where i could not find 'reliability' but 'resilience'.
-cz
 
On Wed, Nov 27, 2013 at 2:06 AM, Diego R. Lopez <diego@tid.es> wrote:
Hi,
When it comes to the reliability/availability issue I guess providing =
some
(condensed) definition from the NFV REL group would help...=

Be goode,
 
On 26 Nov 2013, at 04:00 , Hidetoshi Yokota wrote:
 
Hi Ning and all,
The proposed PS is a very good starting point covering major issues fo=
r the
goal of VNF pool. One thing that I could add is the synchronization be=
tween
the vNF migration/replacement and routing to make the relevant flows
forwarded to the new location. The challenge is that the VMs/severs in=
 a
pool could be deployed over topologically different networks (in the
physical world) and VNF migration could involve topologically independ=
ent
routing. There are multiple ways to do it, but we should first general=
ize
this issue and specify a common mechanism that may leverage existing o=
nes.
If this is already covered, that's fine. If some additional text is us=
eful,
the following could be a summary:
o Synchronization between vNF migration and flow forwarding, which may=

require topologically independent routing in the physical transport ne=
twork;
There is a discussion about "reliability" and "availabi=
lity" in another
thread and I think this is also an issue in ETSI NFV. We need to defin=
e them
either in this group or NFV to share the same view.
Regards,
--
Hidetoshi Yokota
 
KDDI R&D Laboratories, Inc.
e-mail:yokota@kddilabs.jp=

 
(2013/11/21 18:11), Zongning wrote:
 
Hi,
Please review the below brief version of VNF Pool Problem Statement, a=
nd
feedback with your comments. I hope this text can serve as a base of V=
NF
Pool Charter, by carving out real problems and work items.<=
/pre>

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


A virtualized network function (VNF) (e.g. vFW, vLB) provides the same=



function as the equivalent network function (e.g. FW, LB), but is usua=
lly


instantiated as a cluster of software instances running on general pur=
pose


servers via virtualization platform. In an environment based on VNFs, =
a


network service is typically realized by a chain of VNFs where the ins=
tances


of adjacent VNFs are preferably directly connected.


A VNF chain introduces additional points of failure beyond those inher=
ent in


a single dedicated server, and therefore additional challenges on=



reliability. By reliability, we mean the ability of a VNF chain to con=
tinue


function when having transition or failure within the chain. For examp=
le,


there are more factors such as software failure, server over-utilizati=
on,


instance migration that potentially cause VNF instance transition or


failure. Although a general pooling mechanism can be applied to addres=
s the


reliability of a single VNF, there are still problems when addressing =
the


reliability of a VNF chain, i.e. multiple pools for multiple VNFs. For=



example, how does an instance of VNF#1 know which instance in the pool=
 of


VNF#2 will replace the instance of VNF#2 it connects to? How does an


instance of VNF#1 know the state of instance of VNF#2 that it connects=
 to in


order to enforce policy for reliability like load sharing, switch befo=
re


break? How is the service state of an instance held and accessed for


efficient synchronization with backup instances?


The overall problem space can be further breakdown to the following st=
udy


items:


-          Signalling to =
handle reliability and instance transition


requirements


o   Signalling between VNF pools for transition (e.g. state =
change, scaling,


moving) notification, backup announcement;


o   Service state management (e.g. synchronizing method, sta=
te data format,


location and mechanism to access state data) within VNF pool;


o   Obtaining underlying network information (e.g. ALTO, I2R=
S);


o   Signalling to CMS for instance deployment reflecting rel=
iability


requirements (e.g. distribution of instances on different VMs or<=
/o:p>


hypervisors);


-          Transport char=
acteristics


o   Identify and analyze reliable transport characteristics =
for control


plane traffic;


o   Analysis of transport security characteristics to provid=
e protection


against known threats, and identification of an appropriate trust mode=
l;


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


Thanks.


-Ning


 


--


"Esta vez no fallaremos, Doctor Infierno"


 


Dr Diego R. Lopez


Telefonica I+D


http://people.tid.es/die=
go.lopez/


 


e-mail: diego@tid.es

Tel:    +34 913 129 041


Mobile: +34 682 051 091


-----------------------------------------


 


________________________________


 


Este mensaje se dirige exclusivamente a su destinatario. Puede consult=
ar


nuestra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en=
 el enlace


situado m=E1s abajo.


This message is intended exclusively for its addressee. We only send a=
nd


receive email on the basis of the terms set out at:


http://www.ti=
d.es/ES/PAGINAS/disclaimer.aspx


 


_______________________________________________


vnfpool mailing list


vnfpool@ietf.org

https://www.=
ietf.org/mailman/listinfo/vnfpool
--_000_B8F9A780D330094D99AF023C5877DABA43C67027nkgeml501mbschi_-- From bill.wu@huawei.com Mon Dec 2 17:36:09 2013 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 166251AE009 for ; Mon, 2 Dec 2013 17:36:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 AviIFPGoICD4 for ; Mon, 2 Dec 2013 17:36:07 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5672D1AE00B for ; Mon, 2 Dec 2013 17:36:07 -0800 (PST) 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 BAY26308; Tue, 03 Dec 2013 01:36:04 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 3 Dec 2013 01:35:20 +0000 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.158.1; Tue, 3 Dec 2013 01:36:03 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Tue, 3 Dec 2013 09:35:55 +0800 From: Qin Wu To: "Cao,Zhen" , "Y. Richard Yang" Thread-Topic: [vnfpool] VNF Pool Problem Statement Thread-Index: Ac7mmacuBQUiFtBEQ2CEYoAlHpu1YwBEYqIAAHh0j3AAxZS1AAASOyhGAEozlwAAN5MugAA0t9Og Date: Tue, 3 Dec 2013 01:35:54 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "vnfpool@ietf.org" , Mukhtiar Shaikh , Zongning Subject: Re: [vnfpool] VNF Pool 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: Tue, 03 Dec 2013 01:36:09 -0000 b) The description in the text now seems not highly relevant to the NFV context. Some description seems valid even without virtualisation basis. Anyway service chain is not only a problem originating from virtualisation but more general. Do we need to find more vnf related text, e.g., what's the difference between vnf reliability and none virtualized system reliability. [Qin]: Do we really care the difference between the system that is virtuali= zed and the system that is Not virtualized? It looks service chaining don't care. Regarding the difference between vnf reliability and none virtualized syste= m reliability, I can see They share a lot of similarities. However vnf can be located anywhere, can = be relocated anywhere, Can follow some specific order in service chaining case and may need to dea= l with large number of=20 requests from subscribers due to multi-tenancy, may need more dynamic confi= gurations or provisions. I doubt the performance of the system that is virtualized is far less than = one of the system that is Not virtualized.=20 From zehn.cao@gmail.com Tue Dec 3 01:39:29 2013 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 9234D1AE074 for ; Tue, 3 Dec 2013 01:39:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 RTGYaP6sfFZt for ; Tue, 3 Dec 2013 01:39:28 -0800 (PST) Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 6C6761AE067 for ; Tue, 3 Dec 2013 01:39:28 -0800 (PST) Received: by mail-qa0-f52.google.com with SMTP id k4so5423626qaq.4 for ; Tue, 03 Dec 2013 01:39:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zupyO1scqN9S/cZYsLaJw+BGMFJNgLxylGtC6cRGSqE=; b=0l22RMAHMN+6JOzR0gelOVt9wNYeJdt5NXplCO39qfH+uikzpipdGCcmHN0KDu2yEu TdnXA1Ebj9tDG5ffWuk1lUQEYbGoKr9ifTrQsRrfDy/zWMGaRg8+8SpbmOx4YrHcyhZs W9RnjJ8YuQy8Lr9hFQaAaYLDqtMixSlUUwf2IHU/FpN41JBIHTWb7ebJPli8+IayDJJp xOmQni774WRWxp62epkVtMcEI3bEmCTf/S7U761aIFuKsEgUr6VijwMN8H48rPQyWxGt 3GwfeRdGpbo8N3fhnysOmk+2FaHBVIzOx/dHl0xilc1FkHeklFtw4ejr//qaoBGTDWzF WLZg== MIME-Version: 1.0 X-Received: by 10.224.57.68 with SMTP id b4mr124295354qah.63.1386063565763; Tue, 03 Dec 2013 01:39:25 -0800 (PST) Received: by 10.96.63.234 with HTTP; Tue, 3 Dec 2013 01:39:25 -0800 (PST) In-Reply-To: References: Date: Tue, 3 Dec 2013 17:39:25 +0800 Message-ID: From: "Cao,Zhen" To: Qin Wu Content-Type: text/plain; charset=ISO-8859-1 Cc: "vnfpool@ietf.org" , Mukhtiar Shaikh , "Y. Richard Yang" , Zongning Subject: Re: [vnfpool] VNF Pool 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: Tue, 03 Dec 2013 09:39:29 -0000 On Tue, Dec 3, 2013 at 9:35 AM, Qin Wu wrote: > b) The description in the text now seems not highly relevant to the > NFV context. Some description seems valid even without virtualisation > basis. Anyway service chain is not only a problem originating from > virtualisation but more general. Do we need to find more vnf related > text, e.g., what's the difference between vnf reliability and none > virtualized system reliability. > > [Qin]: Do we really care the difference between the system that is virtualized and the system that is > Not virtualized? It looks service chaining don't care. [cz] If you do not care, nor do I. Because in the text, it starts with 'vnf'. I thought we are discussing the issues and problems caused by virtualisation. And the list is vnf-pool, anyway. > > Regarding the difference between vnf reliability and none virtualized system reliability, I can see > They share a lot of similarities. However vnf can be located anywhere, can be relocated anywhere, [cz] I am just concerned if we are going to talk about reliability generally here. > Can follow some specific order in service chaining case and may need to deal with large number of > requests from subscribers due to multi-tenancy, may need more dynamic configurations or provisions. > I doubt the performance of the system that is virtualized is far less than one of the system that is > Not virtualized. From bill.wu@huawei.com Tue Dec 3 02:04:03 2013 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 094171AE093 for ; Tue, 3 Dec 2013 02:04:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.602 X-Spam-Level: X-Spam-Status: No, score=-3.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 9fUnZOMTKwt3 for ; Tue, 3 Dec 2013 02:04:00 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 757741AE061 for ; Tue, 3 Dec 2013 02:03:59 -0800 (PST) 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 AYO54499; Tue, 03 Dec 2013 10:03:55 +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.158.1; Tue, 3 Dec 2013 10:03:00 +0000 Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 3 Dec 2013 10:03:47 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Tue, 3 Dec 2013 18:03:35 +0800 From: Qin Wu To: "Cao,Zhen" Thread-Topic: [vnfpool] VNF Pool Problem Statement Thread-Index: Ac7mmacuBQUiFtBEQ2CEYoAlHpu1YwBEYqIAAHh0j3AAxZS1AAASOyhGAEozlwAAN5MugAA0t9OgAACQZ4AAEUFcAA== Date: Tue, 3 Dec 2013 10:03:34 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "vnfpool@ietf.org" , Mukhtiar Shaikh , "Y. Richard Yang" , Zongning Subject: Re: [vnfpool] VNF Pool 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: Tue, 03 Dec 2013 10:04:03 -0000 Hi, Zhen: -----Original Message----- From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of Cao,Zhen Sent: Tuesday, December 03, 2013 5:39 PM To: Qin Wu Cc: vnfpool@ietf.org; Mukhtiar Shaikh; Y. Richard Yang; Zongning Subject: Re: [vnfpool] VNF Pool Problem Statement On Tue, Dec 3, 2013 at 9:35 AM, Qin Wu wrote: > b) The description in the text now seems not highly relevant to the > NFV context. Some description seems valid even without virtualisation > basis. Anyway service chain is not only a problem originating from > virtualisation but more general. Do we need to find more vnf related > text, e.g., what's the difference between vnf reliability and none > virtualized system reliability. > > [Qin]: Do we really care the difference between the system that is virtua= lized and the system that is > Not virtualized? It looks service chaining don't care. [cz] If you do not care, nor do I. Because in the text, it starts with 'vnf'. I thought we are discussing the issues and problems caused by virtualisation. And the list is vnf-pool, anyway. [Qin]: You misunderstand what I said above. I am just asking question. I want to know if people care the difference between virtualized system and= physical system. In service chain discussion, I fail to see they care or any discussion abou= t distinguishing one from another. > > Regarding the difference between vnf reliability and none virtualized sys= tem reliability, I can see > They share a lot of similarities. However vnf can be located anywhere, ca= n be relocated anywhere, [cz] I am just concerned if we are going to talk about reliability generally here. [Qin]: Again, here I am just explaining what the difference is. I am wonder= ing whether these difference has any Impact on the VNF performance. I guess many of us assume VNF can achieve th= e same performance as the physical system that has The same functionality. E.g., physical firewall can be replaced by vFirewal= l in case of failure.=20 Please correct me if I am wrong. > Can follow some specific order in service chaining case and may need to d= eal with large number of > requests from subscribers due to multi-tenancy, may need more dynamic con= figurations or provisions. > I doubt the performance of the system that is virtualized is far less tha= n one of the system that is > Not virtualized. _______________________________________________ vnfpool mailing list vnfpool@ietf.org https://www.ietf.org/mailman/listinfo/vnfpool From chidung.lac@orange.com Tue Dec 3 04:54:44 2013 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 EFA9F1AE139 for ; Tue, 3 Dec 2013 04:54:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.016 X-Spam-Level: ** X-Spam-Status: No, score=2.016 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, MANGLED_RVLUTN=2.3, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665] 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 YOMDZPotrO0C for ; Tue, 3 Dec 2013 04:54:38 -0800 (PST) Received: from r-mail2.rd.orange.com (r-mail2.rd.orange.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id DDEB31AE13E for ; Tue, 3 Dec 2013 04:54:37 -0800 (PST) Received: from r-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 852C45D8B7A; Tue, 3 Dec 2013 13:54:34 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.orange.com (Postfix) with ESMTP id 7220B5D8B12; Tue, 3 Dec 2013 13:54:34 +0100 (CET) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Dec 2013 13:54:34 +0100 Received: from [10.193.5.32] ([10.193.5.32]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Dec 2013 13:54:32 +0100 Message-ID: <529DD489.8050008@orange.com> Date: Tue, 03 Dec 2013 13:54:33 +0100 From: LAC Chidung User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Qin Wu , "vnfpool@ietf.org" References: <52940EB0.6040601@kddilabs.jp> <529C5A30.3070000@orange.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030109000202060006070803" X-OriginalArrivalTime: 03 Dec 2013 12:54:32.0296 (UTC) FILETIME=[CF9D9E80:01CEF026] Subject: Re: [vnfpool] VNF Pool 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: Tue, 03 Dec 2013 12:54:44 -0000 This is a multi-part message in MIME format. --------------030109000202060006070803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi Qin, 1- Your understanding of availability is perfectly aligned with my sentence "/The phone service is ready/ ...": it is just an update of the context, i.e., * "/a tone is present/" => "/don't loss connection to the network at any time/" ('I get the connection whenever I ask for it') * "/anywhere/" : from the POTS (PSTN) standpoint, it only happened at home, at work, or in phone booths - but with the mobile (r)evolution, it is practically anywhere (except during some situations like scubadiving, etc.) * "/using any device/" : nowadays, the plethora of apparatus (desktop, laptop, smartphone, tablet, ...) has replaced the traditional (phone) receiver 2- HA: this highly requested criteria in the communications field is supported, of course, by resilience. It is just a subset of the field of values taken by the "availability" metric, which spans from 0 to 1. HA is usually characterized by the mean value 0.99999 (five "9" or 5 min of unavailabilty per year). Best, Chidung PS: in the ETSI NFV ISG, besides the "Reliability & Availability Working Group", there is a "Security Expert Group", i.e., when the word 'resilience' is employed in the R&A WG, security is not included - in other words, "resilience" is used in this WG as "dependability", and not as an expression encompassing both dependability and security. Le 03/12/2013 02:19, Qin Wu a écrit : > > In my understanding, availability is more about "don't loss connection > to the network at any time anywhere using any device" or ubiquity. The > resilience should be used to support high availability as well. > > If resilience doesn't mean high availability then resilience can be > redefined to support high availability. > > My 2 cents. > > Regards! > > -Qin > > *From:*vnfpool [mailto:vnfpool-bounces@ietf.org] *On Behalf Of *LAC > Chidung > *Sent:* Monday, December 02, 2013 6:00 PM > *To:* vnfpool@ietf.org > *Subject:* Re: [vnfpool] VNF Pool Problem Statement > > Hi all, > /Reliability is the ability of an item to perform a required function > under stated conditions for a stated period of time/, > while/Availability is a measure of the degree to which an item is in > an operable state when called upon to perform./ (D.J. Klinger, Y. > Nakada, and M.A. Menedez (Eds.), "AT&T Reliability Manual", Van > Nostrand Reinhold, 1990) > Applied to the PSTN, the former includes "My call is not dropped > during a conversation", while the latter asks for "The phone service > is ready, i.e., a tone is present, whenever I lift the handset". > For years, /Dependability /has encompassed these concepts (together > with others such as /Maintainability) /to characterize the good > behavior (robustness) of a system when facing *accidental *events > (design faults, operations errors, hardware failures, natural > disasters, etc.) , while /Security, /which includes all *intentional > *actions (attacks, ...), is kept apart. This explains the presence, up > to now, of two communities working in these two separated subjects. > As (i) unavailability may the consequence of, e.g., software/hardware > failures OR (D)DoS attacks (ii) /Resilience/ is a fashionable > expression* (iii) etc., resilience is used since the last few years to > encompass both dependability and security. > Best, > Chidung > _______ > *: see, e.g., Obama's praise for the resilience of the Indian people > (http://articles.latimes.com/2010/nov/06/world/la-fgw-obama-mumbai-20101107) > > Le 02/12/2013 08:21, Cao,Zhen a écrit : > > Good point, Diego. > > I checked out the NFV ISG released documents of requirements and > > terminology, where i could not find 'reliability' but 'resilience'. > > -cz > > > > On Wed, Nov 27, 2013 at 2:06 AM, Diego R. Lopez wrote: > > Hi, > > When it comes to the reliability/availability issue I guess providing some > > (condensed) definition from the NFV REL group would help... > > Be goode, > > > > On 26 Nov 2013, at 04:00 , Hidetoshi Yokota wrote: > > > > Hi Ning and all, > > The proposed PS is a very good starting point covering major issues for the > > goal of VNF pool. One thing that I could add is the synchronization between > > the vNF migration/replacement and routing to make the relevant flows > > forwarded to the new location. The challenge is that the VMs/severs in a > > pool could be deployed over topologically different networks (in the > > physical world) and VNF migration could involve topologically independent > > routing. There are multiple ways to do it, but we should first generalize > > this issue and specify a common mechanism that may leverage existing ones. > > If this is already covered, that's fine. If some additional text is useful, > > the following could be a summary: > > o Synchronization between vNF migration and flow forwarding, which may > > require topologically independent routing in the physical transport network; > > There is a discussion about "reliability" and "availability" in another > > thread and I think this is also an issue in ETSI NFV. We need to define them > > either in this group or NFV to share the same view. > > Regards, > > -- > > Hidetoshi Yokota > > > > KDDI R&D Laboratories, Inc. > > e-mail:yokota@kddilabs.jp > > > > (2013/11/21 18:11), Zongning wrote: > > > > Hi, > > Please review the below brief version of VNF Pool Problem Statement, and > > feedback with your comments. I hope this text can serve as a base of VNF > > Pool Charter, by carving out real problems and work items. > > =========================================================================================== > > A virtualized network function (VNF) (e.g. vFW, vLB) provides the same > > function as the equivalent network function (e.g. FW, LB), but is usually > > instantiated as a cluster of software instances running on general purpose > > servers via virtualization platform. In an environment based on VNFs, a > > network service is typically realized by a chain of VNFs where the instances > > of adjacent VNFs are preferably directly connected. > > A VNF chain introduces additional points of failure beyond those inherent in > > a single dedicated server, and therefore additional challenges on > > reliability. By reliability, we mean the ability of a VNF chain to continue > > function when having transition or failure within the chain. For example, > > there are more factors such as software failure, server over-utilization, > > instance migration that potentially cause VNF instance transition or > > failure. Although a general pooling mechanism can be applied to address the > > reliability of a single VNF, there are still problems when addressing the > > reliability of a VNF chain, i.e. multiple pools for multiple VNFs. For > > example, how does an instance of VNF#1 know which instance in the pool of > > VNF#2 will replace the instance of VNF#2 it connects to? How does an > > instance of VNF#1 know the state of instance of VNF#2 that it connects to in > > order to enforce policy for reliability like load sharing, switch before > > break? How is the service state of an instance held and accessed for > > efficient synchronization with backup instances? > > The overall problem space can be further breakdown to the following study > > items: > > - Signalling to handle reliability and instance transition > > requirements > > o Signalling between VNF pools for transition (e.g. state change, scaling, > > moving) notification, backup announcement; > > o Service state management (e.g. synchronizing method, state data format, > > location and mechanism to access state data) within VNF pool; > > o Obtaining underlying network information (e.g. ALTO, I2RS); > > o Signalling to CMS for instance deployment reflecting reliability > > requirements (e.g. distribution of instances on different VMs or > > hypervisors); > > - Transport characteristics > > o Identify and analyze reliable transport characteristics for control > > plane traffic; > > o Analysis of transport security characteristics to provide protection > > against known threats, and identification of an appropriate trust model; > > =========================================================================================== > > Thanks. > > -Ning > > > > -- > > "Esta vez no fallaremos, Doctor Infierno" > > > > Dr Diego R. Lopez > > Telefonica I+D > > http://people.tid.es/diego.lopez/ > > > > e-mail:diego@tid.es > > Tel: +34 913 129 041 > > Mobile: +34 682 051 091 > > ----------------------------------------- > > ________________________________ > > > > Este mensaje se dirige exclusivamente a su destinatario. Puede consultar > > nuestra política de envío y recepción de correo electrónico en el enlace > > situado más abajo. > > This message is intended exclusively for its addressee. We only send and > > receive email on the basis of the terms set out at: > > http://www.tid.es/ES/PAGINAS/disclaimer.aspx > > > > _______________________________________________ > > vnfpool mailing list > > vnfpool@ietf.org > > https://www.ietf.org/mailman/listinfo/vnfpool > --------------030109000202060006070803 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Qin,
1- Your understanding of availability is perfectly aligned with my sentence "The phone service is ready ...": it is just an update of the context, i.e.,
* "a tone is present" => "don't loss connection to the network at any time" ('I get the connection whenever I ask for it')
* "anywhere" : from the POTS (PSTN) standpoint, it only happened at home, at work, or in phone booths - but with the mobile (r)evolution, it is practically anywhere (except during some situations like scubadiving, etc.)
* "using any device" : nowadays, the plethora of apparatus (desktop, laptop, smartphone, tablet, ...) has replaced the traditional (phone) receiver
2- HA: this highly requested criteria in the communications field is supported, of course, by resilience. It is just a subset of the field of values taken by the "availability" metric, which spans from 0 to 1. HA is usually characterized by the mean value 0.99999 (five "9" or 5 min of unavailabilty per year).
Best,
Chidung
PS: in the ETSI NFV ISG, besides the "Reliability & Availability Working Group", there is a "Security Expert Group", i.e., when the word 'resilience' is employed in the R&A WG, security is not included - in other words, "resilience" is used in this WG as "dependability", and not as an expression encompassing both dependability and security.
Le 03/12/2013 02:19, Qin Wu a écrit :

In my understanding, availability is more about “don’t loss connection to the network at any time anywhere using any device” or ubiquity. The resilience should be used to support high availability as well.

If resilience doesn’t mean high availability then resilience can be redefined to support high availability.

My 2 cents.

Regards!

-Qin

From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of LAC Chidung
Sent: Monday, December 02, 2013 6:00 PM
To: vnfpool@ietf.org
Subject: Re: [vnfpool] VNF Pool Problem Statement

 

Hi all,
Reliability is the ability of an item to perform a required function under stated conditions for a stated period of time, while Availability is a measure of the degree to which an item is in an operable state when called upon to perform. (D.J. Klinger, Y. Nakada, and M.A. Menedez (Eds.), "AT&T Reliability Manual", Van Nostrand Reinhold, 1990)
Applied to the PSTN, the former includes "My call is not dropped during a conversation", while the latter asks for "The phone service is ready, i.e., a tone is present, whenever I lift the handset".
For years, Dependability has encompassed these concepts (together with others such as Maintainability) to characterize the good behavior (robustness) of a system when facing accidental events (design faults, operations errors, hardware failures, natural disasters, etc.) , while Security, which includes all intentional actions (attacks, ...), is kept apart. This explains the presence, up to now, of two communities working in these two separated subjects.
As (i) unavailability may the consequence of, e.g., software/hardware failures OR (D)DoS attacks (ii) Resilience is a fashionable expression* (iii) etc., resilience is used since the last few years to encompass both dependability and security.
Best,
Chidung
_______
*: see, e.g., Obama's praise for the resilience of the Indian people (http://articles.latimes.com/2010/nov/06/world/la-fgw-obama-mumbai-20101107)

Le 02/12/2013 08:21, Cao,Zhen a écrit :

Good point, Diego.
I checked out the NFV ISG released documents of requirements and
terminology, where i could not find 'reliability' but 'resilience'.
-cz
 
On Wed, Nov 27, 2013 at 2:06 AM, Diego R. Lopez <diego@tid.es> wrote:
Hi,
When it comes to the reliability/availability issue I guess providing some
(condensed) definition from the NFV REL group would help...
Be goode,
 
On 26 Nov 2013, at 04:00 , Hidetoshi Yokota wrote:
 
Hi Ning and all,
The proposed PS is a very good starting point covering major issues for the
goal of VNF pool. One thing that I could add is the synchronization between
the vNF migration/replacement and routing to make the relevant flows
forwarded to the new location. The challenge is that the VMs/severs in a
pool could be deployed over topologically different networks (in the
physical world) and VNF migration could involve topologically independent
routing. There are multiple ways to do it, but we should first generalize
this issue and specify a common mechanism that may leverage existing ones.
If this is already covered, that's fine. If some additional text is useful,
the following could be a summary:
o Synchronization between vNF migration and flow forwarding, which may
require topologically independent routing in the physical transport network;
There is a discussion about "reliability" and "availability" in another
thread and I think this is also an issue in ETSI NFV. We need to define them
either in this group or NFV to share the same view.
Regards,
--
Hidetoshi Yokota
 
KDDI R&D Laboratories, Inc.
e-mail:yokota@kddilabs.jp
 
(2013/11/21 18:11), Zongning wrote:
 
Hi,
Please review the below brief version of VNF Pool Problem Statement, and
feedback with your comments. I hope this text can serve as a base of VNF
Pool Charter, by carving out real problems and work items.
===========================================================================================
A virtualized network function (VNF) (e.g. vFW, vLB) provides the same
function as the equivalent network function (e.g. FW, LB), but is usually
instantiated as a cluster of software instances running on general purpose
servers via virtualization platform. In an environment based on VNFs, a
network service is typically realized by a chain of VNFs where the instances
of adjacent VNFs are preferably directly connected.
A VNF chain introduces additional points of failure beyond those inherent in
a single dedicated server, and therefore additional challenges on
reliability. By reliability, we mean the ability of a VNF chain to continue
function when having transition or failure within the chain. For example,
there are more factors such as software failure, server over-utilization,
instance migration that potentially cause VNF instance transition or
failure. Although a general pooling mechanism can be applied to address the
reliability of a single VNF, there are still problems when addressing the
reliability of a VNF chain, i.e. multiple pools for multiple VNFs. For
example, how does an instance of VNF#1 know which instance in the pool of
VNF#2 will replace the instance of VNF#2 it connects to? How does an
instance of VNF#1 know the state of instance of VNF#2 that it connects to in
order to enforce policy for reliability like load sharing, switch before
break? How is the service state of an instance held and accessed for
efficient synchronization with backup instances?
The overall problem space can be further breakdown to the following study
items:
-          Signalling to handle reliability and instance transition
requirements
o   Signalling between VNF pools for transition (e.g. state change, scaling,
moving) notification, backup announcement;
o   Service state management (e.g. synchronizing method, state data format,
location and mechanism to access state data) within VNF pool;
o   Obtaining underlying network information (e.g. ALTO, I2RS);
o   Signalling to CMS for instance deployment reflecting reliability
requirements (e.g. distribution of instances on different VMs or
hypervisors);
-          Transport characteristics
o   Identify and analyze reliable transport characteristics for control
plane traffic;
o   Analysis of transport security characteristics to provide protection
against known threats, and identification of an appropriate trust model;
===========================================================================================
Thanks.
-Ning
 
--
"Esta vez no fallaremos, Doctor Infierno"
 
Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/
 
e-mail: diego@tid.es
Tel:    +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------
________________________________
 
Este mensaje se dirige exclusivamente a su destinatario. Puede consultar
nuestra política de envío y recepción de correo electrónico en el enlace
situado más abajo.
This message is intended exclusively for its addressee. We only send and
receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
 
_______________________________________________
vnfpool mailing list
vnfpool@ietf.org
https://www.ietf.org/mailman/listinfo/vnfpool
--------------030109000202060006070803-- From linda.dunbar@huawei.com Tue Dec 3 11:26:11 2013 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 8C0FA1AE17E for ; Tue, 3 Dec 2013 11:26:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 CArUtjQrUaCY for ; Tue, 3 Dec 2013 11:26:09 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 589F21AD8EC for ; Tue, 3 Dec 2013 11:26:08 -0800 (PST) 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 AYP00334; Tue, 03 Dec 2013 19:26:04 +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, 3 Dec 2013 19:25:16 +0000 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 3 Dec 2013 19:26:02 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.24]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.03.0158.001; Tue, 3 Dec 2013 11:25:59 -0800 From: Linda Dunbar To: "Diego R. Lopez" , Melinda Shore Thread-Topic: [vnfpool] Question about addressing in pools Thread-Index: AQHO7VD+jTbOOdlTZEWSSl1+dWxSzJpBLkKAgAGw5GA= Date: Tue, 3 Dec 2013 19:25:58 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645C2936D@dfweml509-mbx.china.huawei.com> References: <529912BF.4010307@nomountain.net> <701E4DC3-754C-4308-B507-D85BCAB9B2D6@tid.es> In-Reply-To: <701E4DC3-754C-4308-B507-D85BCAB9B2D6@tid.es> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.158.96] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "vnfpool@ietf.org" Subject: Re: [vnfpool] Question about addressing in pools 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, 03 Dec 2013 19:26:11 -0000 SSB0aGluayB0aGF0IGl0IGlzIHRoZSAiVk5GIzIgcG9vbCBtYW5hZ2VyIiB0aGF0IHdpbGwgZGV0 ZXJtaW5lIHdoaWNoIGluc3RhbmNlIGluIFZORiMyIHdpbGwgYmUgZmFpbC1vdmVyIG9uZSwgYW5k IGlzIHJlc3BvbnNpYmxlIGZvciBwYXNzaW5nIHRoaXMgVk5GIzIncyBmYWlsb3ZlciBpbnN0YW5j ZSBhZGRyZXNzIHRvICJWTkYjMSBwb29sIG1hbmFnZXIiLiANCg0KTGluZGENCg0KDQo+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHZuZnBvb2wgW21haWx0bzp2bmZwb29sLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBEaWVnbyBSLg0KPiBMb3Bleg0KPiBTZW50OiBN b25kYXksIERlY2VtYmVyIDAyLCAyMDEzIDM6MzIgQU0NCj4gVG86IE1lbGluZGEgU2hvcmUNCj4g Q2M6IHZuZnBvb2xAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFt2bmZwb29sXSBRdWVzdGlvbiBh Ym91dCBhZGRyZXNzaW5nIGluIHBvb2xzDQo+IA0KPiBIaSBNZWxpbmRhLA0KPiANCj4gSSBhZ3Jl ZSB5b3UgaGF2ZSBhIHBvaW50IGhlcmUuIEFuZCBvbmUgb2YgdGhlIHJlYXNvbnMgZm9yIHVzaW5n DQo+IHJzZXJwb29sIG9yIHNpbWlsYXIgbWVjaGFuaXNtcyB3b3VsZCBiZSBwcmVjaXNlbHkgdG8g aGF2ZSB0aG9zZSBhZGRyZXNzDQo+IG1hbmFnZW1lbnQgaW4gcGxhY2UuIE1heSBiZSBhIGJldHRl ciB3b3JkaW5nIHdvdWxkIGJlIHNvbWV0aGluZyBsaWtlDQo+ICJBbnkgaW5zdGFuY2Ugb2YgVk5G IzEgY2FuIGJlIHN1cmUgaXQgd2lsbCBiZSB0YWxraW5nIHdpdGggYW4NCj4gYXBwcm9wcmlhdGUg aW5zdGFuY2Ugb2YgVk5GIzIiDQo+IA0KPiBCZSBnb29kZSwNCj4gDQo+IE9uIDI5IE5vdiAyMDEz LCBhdCAyMzoxOCAsIE1lbGluZGEgU2hvcmUgd3JvdGU6DQo+IA0KPiA+IEl0J3MgdHlwaWNhbGx5 IHRoZSBjYXNlIGluIGEgc3RhdGVmdWwgZmFpbG92ZXIgc2NlbmFyaW8gdGhhdA0KPiA+IHdoZW4g YSBkZXZpY2UgaGFzIGEgZ2l2ZW4gYWRkcmVzcyAob3Igc2V0IG9mIGFkZHJlc3NlcyksIGFmdGVy DQo+ID4gYSBmYWlsb3ZlciB0aGUgbmV3IGluc3RhbmNlIGhhcyB0aGUgc2FtZSBhZGRyZXNzLiAg VGhlIGN1cnJlbnQNCj4gPiB2ZXJzaW9uIG9mIHRoZSBwcm9ibGVtIHN0YXRlbWVudCBpbmNsdWRl cyB0aGUgZm9sbG93aW5nIHRleHQ6DQo+ID4gIkZvciBleGFtcGxlLCBob3cgZG9lcyBhbiBpbnN0 YW5jZSBvZiBWTkYjMSBrbm93IHdoaWNoIGluc3RhbmNlDQo+ID4gaW4gdGhlIHBvb2wgb2YgVk5G IzIiPw0KPiA+DQo+ID4gSXQgc2VlbXMgdG8gbWUgdGhhdCB1bmxlc3Mgd2UncmUgYXNzdW1pbmcg dGhlIHVzZSBvZiBoYXJkd2FyZQ0KPiA+IGFkZHJlc3Npbmcgd2Ugc2hvdWxkIHByb2JhYmx5IGV4 cGxhaW4gd2h5IHRoaXMgaXMgYW4gaXNzdWUuDQo+ID4gSWYgd2UgZ28gd2l0aCByc2VycG9vbCBv ciBhIHNpbWlsYXIgbWVjaGFuaXNtLCBhZGRyZXNzZXMgYXJlDQo+ID4gbm90IHNoYXJlZCBidXQg aW5zdGVhZCBhIHBvb2wgbWFuYWdlciAoc3VjaCBhcyBhbiBFTlJQIHNlcnZlcikNCj4gPiBpcyB1 c2VkIHRvIHNlbGVjdCAibGl2ZSIgaW5zdGFuY2VzIGFuZCBhZGRyZXNzaW5nIGlzIG1lZGlhdGVk DQo+ID4gdGhyb3VnaCB0aGUgcG9vbGluZyBtZWNoYW5pc20uDQo+ID4NCj4gPiBJdCBzZWVtcyB0 byBtZSB0aGF0IHdlIHNob3VsZCBwcm9iYWJseSBiZSBwcmVwYXJlZCB0byBkaXNjdXNzDQo+ID4g dGhlIHRyYWRlb2ZmcyBiZXR3ZWVuIHRoZSB0d28gYXBwcm9hY2hlcy4NCj4gPg0KPiA+IE1lbGlu ZGENCj4gPiAtLQ0KPiA+IE1lbGluZGEgU2hvcmUNCj4gPiBObyBNb3VudGFpbiBTb2Z0d2FyZQ0K PiA+IG1lbGluZGEuc2hvcmVAbm9tb3VudGFpbi5uZXQNCj4gPg0KPiA+ICJTb2Z0d2FyZSBsb25n YSwgaGFyZHdhcmUgYnJldmlzLiINCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiA+IHZuZnBvb2wgbWFpbGluZyBsaXN0DQo+ID4gdm5mcG9vbEBp ZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdm5mcG9v bA0KPiANCj4gDQo+IC0tDQo+ICJFc3RhIHZleiBubyBmYWxsYXJlbW9zLCBEb2N0b3IgSW5maWVy bm8iDQo+IA0KPiBEciBEaWVnbyBSLiBMb3Bleg0KPiBUZWxlZm9uaWNhIEkrRA0KPiBodHRwOi8v cGVvcGxlLnRpZC5lcy9kaWVnby5sb3Blei8NCj4gDQo+IGUtbWFpbDogZGllZ29AdGlkLmVzDQo+ IFRlbDogICAgKzM0IDkxMyAxMjkgMDQxDQo+IE1vYmlsZTogKzM0IDY4MiAwNTEgMDkxDQo+IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiANCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gDQo+IEVzdGUgbWVuc2FqZSBzZSBkaXJpZ2Ug ZXhjbHVzaXZhbWVudGUgYSBzdSBkZXN0aW5hdGFyaW8uIFB1ZWRlDQo+IGNvbnN1bHRhciBudWVz dHJhIHBvbMOtdGljYSBkZSBlbnbDrW8geSByZWNlcGNpw7NuIGRlIGNvcnJlbyBlbGVjdHLDs25p Y28NCj4gZW4gZWwgZW5sYWNlIHNpdHVhZG8gbcOhcyBhYmFqby4NCj4gVGhpcyBtZXNzYWdlIGlz IGludGVuZGVkIGV4Y2x1c2l2ZWx5IGZvciBpdHMgYWRkcmVzc2VlLiBXZSBvbmx5IHNlbmQNCj4g YW5kIHJlY2VpdmUgZW1haWwgb24gdGhlIGJhc2lzIG9mIHRoZSB0ZXJtcyBzZXQgb3V0IGF0Og0K PiBodHRwOi8vd3d3LnRpZC5lcy9FUy9QQUdJTkFTL2Rpc2NsYWltZXIuYXNweA0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiB2bmZwb29sIG1haWxp bmcgbGlzdA0KPiB2bmZwb29sQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vdm5mcG9vbA0K From melinda.shore@gmail.com Tue Dec 3 11:40:55 2013 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 184101AE1AD for ; Tue, 3 Dec 2013 11:40:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 YgN2O5RBj-6W for ; Tue, 3 Dec 2013 11:40:53 -0800 (PST) Received: from mail-pb0-x22c.google.com (mail-pb0-x22c.google.com [IPv6:2607:f8b0:400e:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 99C311AE1B2 for ; Tue, 3 Dec 2013 11:40:53 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id rq2so21724485pbb.31 for ; Tue, 03 Dec 2013 11:40:51 -0800 (PST) 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=5UbmrEd09rmLdQUpccCbELnnul7pYHWyrD64/biSDl0=; b=WNi5tSKrSsw6N7CBbjTZe96s7rUGrVsWaAqrTxRcvGI6q+9GLgXdfytzCKUyBJNBM9 ewco+aSasGg8rr62+sLTV6xEjc2pLdUf7Ghp30MuYhlw17rx/HbruvEQifDPhXLC5Zpj iIiytbk3ezkID236kyeDLnKWhgvuSnKmZelP2HRzcWzegJc95MI8M88ulyoBlbDN0DvD oEMpa/jqVJY8W9VGyTYNnSjhwu830+vokaw+ckINxjI8bvuuV62ZY5u/FXsYlOB38XOv BM+kz0UPPZ9L1h5lpgRf0P0Dbq3yHGhT/OdlWKjSvX3Ggwma2GyojHLL+StVzngv+t4f YrAg== X-Received: by 10.66.142.233 with SMTP id rz9mr30628513pab.71.1386099650959; Tue, 03 Dec 2013 11:40:50 -0800 (PST) Received: from spandex.local (216-67-50-85-rb3.nwc.dsl.dynamic.acsalaska.net. [216.67.50.85]) by mx.google.com with ESMTPSA id ef10sm149932687pac.1.2013.12.03.11.40.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Dec 2013 11:40:50 -0800 (PST) Message-ID: <529E33BF.50002@gmail.com> Date: Tue, 03 Dec 2013 10:40:47 -0900 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: <529912BF.4010307@nomountain.net> <701E4DC3-754C-4308-B507-D85BCAB9B2D6@tid.es> <4A95BA014132FF49AE685FAB4B9F17F645C2936D@dfweml509-mbx.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645C2936D@dfweml509-mbx.china.huawei.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [vnfpool] Question about addressing in pools 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, 03 Dec 2013 19:40:55 -0000 On 12/3/13 10:25 AM, Linda Dunbar wrote: > I think that it is the "VNF#2 pool manager" that will determine which > instance in VNF#2 will be fail-over one, and is responsible for > passing this VNF#2's failover instance address to "VNF#1 pool > manager". I think it might be a little early to assume that. It's generally the case in HA scenarios that when there's a failover clients/endpoints do not know that they are talking to what a different box (or virtual box). In rserpool endpoints find and access services through ENRP - that is to say, unmodified clients can't take advantage of the pooling mechanism. I think we need to be clear about that. Melinda From linda.dunbar@huawei.com Tue Dec 3 11:46:11 2013 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 9EC971AD8ED for ; Tue, 3 Dec 2013 11:46:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 FA_cw-FKRD5d for ; Tue, 3 Dec 2013 11:46:09 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 070E11ACC88 for ; Tue, 3 Dec 2013 11:46:08 -0800 (PST) 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 AYP01232; Tue, 03 Dec 2013 19:46:05 +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, 3 Dec 2013 19:45:19 +0000 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 3 Dec 2013 19:46:05 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.24]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.03.0158.001; Tue, 3 Dec 2013 11:46:01 -0800 From: Linda Dunbar To: Melinda Shore , "vnfpool@ietf.org" Thread-Topic: [vnfpool] Question about addressing in pools Thread-Index: AQHO7VD+jTbOOdlTZEWSSl1+dWxSzJpBLkKAgAGw5GCAAIt0gP//et1w Date: Tue, 3 Dec 2013 19:46:00 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645C293C2@dfweml509-mbx.china.huawei.com> References: <529912BF.4010307@nomountain.net> <701E4DC3-754C-4308-B507-D85BCAB9B2D6@tid.es> <4A95BA014132FF49AE685FAB4B9F17F645C2936D@dfweml509-mbx.china.huawei.com> <529E33BF.50002@gmail.com> In-Reply-To: <529E33BF.50002@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.158.96] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [vnfpool] Question about addressing in pools 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, 03 Dec 2013 19:46:11 -0000 Melinda,=20 Agree what you said there.=20 But I think it is too messy for the instances in VNF#1 to be aware of diffe= rent addresses of other instances. Maybe virtual address for VNF#2 can be u= sed? Linda > -----Original Message----- > From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of Melinda > Shore > Sent: Tuesday, December 03, 2013 1:41 PM > To: vnfpool@ietf.org > Subject: Re: [vnfpool] Question about addressing in pools >=20 > On 12/3/13 10:25 AM, Linda Dunbar wrote: > > I think that it is the "VNF#2 pool manager" that will determine which > > instance in VNF#2 will be fail-over one, and is responsible for > > passing this VNF#2's failover instance address to "VNF#1 pool > > manager". >=20 > I think it might be a little early to assume that. It's generally > the case in HA scenarios that when there's a failover clients/endpoints > do not know that they are talking to what a different box (or virtual > box). In rserpool endpoints find and access services through > ENRP - that is to say, unmodified clients can't take advantage > of the pooling mechanism. I think we need to be clear about > that. >=20 > Melinda > _______________________________________________ > vnfpool mailing list > vnfpool@ietf.org > https://www.ietf.org/mailman/listinfo/vnfpool From melinda.shore@gmail.com Tue Dec 3 11:54:19 2013 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 10E161A1F79 for ; Tue, 3 Dec 2013 11:54:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 DCYfqsdYO3YE for ; Tue, 3 Dec 2013 11:54:17 -0800 (PST) Received: from mail-pb0-x230.google.com (mail-pb0-x230.google.com [IPv6:2607:f8b0:400e:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id F1FC01ACCDC for ; Tue, 3 Dec 2013 11:54:16 -0800 (PST) Received: by mail-pb0-f48.google.com with SMTP id md12so21768595pbc.35 for ; Tue, 03 Dec 2013 11:54:14 -0800 (PST) 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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=OQwrQ8+Dw4zEq+4n0hHBWvM5yjafgMlHiUg8E5VpSxM=; b=KTE+SV0zp1gNlLvvikrBe1Z8hsd4EoTEsJPpVgQtj3GjGwZ4ooY1ppBvct2eETLtoQ k7KidJdIx5zs+tU+lC7Vs2Q6Vzaxg+9txas4HzbEYeqOpA0knE2ALA4chfibRRYWppnv BHwc7ZIPqSIHwjhCEPPHrsRNBFo8IENXBJH8Knyiq0QO+lhHc5a5lU0g34L8Bcxs/kft FOpoYA6JPvlx0PsdqWvSIU9IOAiXvP/oorZS2vSgl4/chqYbZ/u/HA2a0sucJtm6vR53 4e/Zr2XtTHuALhndl5QHsIQRP8tlh2aRHVEigYF9MSwiqSbGq8JByvkkwA8lBJMkJ5lD dJ5A== X-Received: by 10.66.216.129 with SMTP id oq1mr77973211pac.75.1386100454414; Tue, 03 Dec 2013 11:54:14 -0800 (PST) Received: from spandex.local (216-67-50-85-rb3.nwc.dsl.dynamic.acsalaska.net. [216.67.50.85]) by mx.google.com with ESMTPSA id ug2sm21440676pac.21.2013.12.03.11.54.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Dec 2013 11:54:13 -0800 (PST) Message-ID: <529E36E3.40206@gmail.com> Date: Tue, 03 Dec 2013 10:54:11 -0900 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: Linda Dunbar References: <529912BF.4010307@nomountain.net> <701E4DC3-754C-4308-B507-D85BCAB9B2D6@tid.es> <4A95BA014132FF49AE685FAB4B9F17F645C2936D@dfweml509-mbx.china.huawei.com> <529E33BF.50002@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F645C293C2@dfweml509-mbx.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645C293C2@dfweml509-mbx.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "vnfpool@ietf.org" Subject: Re: [vnfpool] Question about addressing in pools 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, 03 Dec 2013 19:54:19 -0000 On 12/3/13 10:46 AM, Linda Dunbar wrote: > Agree what you said there. But I think it is too messy for the > instances in VNF#1 to be aware of different addresses of other > instances. Maybe virtual address for VNF#2 can be used? I think this is one of the issues we need to sort out as we move towards a mature problem statement. Or to put it another way, do we expect clients to be modified or unmodified? Melinda From linda.dunbar@huawei.com Tue Dec 3 12:06:57 2013 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 47F291AD9B8 for ; Tue, 3 Dec 2013 12:06:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 zYVzaE_vT0K9 for ; Tue, 3 Dec 2013 12:06:50 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C3A891AC3DA for ; Tue, 3 Dec 2013 12:06:49 -0800 (PST) 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 AYP02128; Tue, 03 Dec 2013 20:06:46 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 3 Dec 2013 20:05:56 +0000 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 3 Dec 2013 20:06:45 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.24]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.03.0158.001; Tue, 3 Dec 2013 12:06:42 -0800 From: Linda Dunbar To: LAC Chidung , "vnfpool@ietf.org" Thread-Topic: [vnfpool] VNF Pool Problem Statement Thread-Index: Ac7mmacuBQUiFtBEQ2CEYoAlHpu1YwD/P9UAAB+kuIABF0DFAAAFh5wAADY6ElA= Date: Tue, 3 Dec 2013 20:06:41 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645C293E9@dfweml509-mbx.china.huawei.com> References: <52940EB0.6040601@kddilabs.jp> <529C5A30.3070000@orange.com> In-Reply-To: <529C5A30.3070000@orange.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.158.96] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645C293E9dfweml509mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [vnfpool] VNF Pool 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: Tue, 03 Dec 2013 20:06:57 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645C293E9dfweml509mbxchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Chidung, Thanks for the quote. Based on your quote, the goal of "vnfpool" should be about to achieve "high= availability" of service function chaining while individual service functi= on instances are NOT reliable. As stated in the problem statement, the vir= tualized network functions have higher chance to fail due to lack of built-= in redundancy, server failure, server over-utilized, or software failure, e= tc. Linda From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of LAC Chidung Sent: Monday, December 02, 2013 4:00 AM To: vnfpool@ietf.org Subject: Re: [vnfpool] VNF Pool Problem Statement Hi all, Reliability is the ability of an item to perform a required function under = stated conditions for a stated period of time, while Availability is a meas= ure of the degree to which an item is in an operable state when called upon= to perform. (D.J. Klinger, Y. Nakada, and M.A. Menedez (Eds.), "AT&T Relia= bility Manual", Van Nostrand Reinhold, 1990) Applied to the PSTN, the former includes "My call is not dropped during a c= onversation", while the latter asks for "The phone service is ready, i.e., = a tone is present, whenever I lift the handset". For years, Dependability has encompassed these concepts (together with othe= rs such as Maintainability) to characterize the good behavior (robustness) = of a system when facing accidental events (design faults, operations errors= , hardware failures, natural disasters, etc.) , while Security, which inclu= des all intentional actions (attacks, ...), is kept apart. This explains th= e presence, up to now, of two communities working in these two separated su= bjects. As (i) unavailability may the consequence of, e.g., software/hardware failu= res OR (D)DoS attacks (ii) Resilience is a fashionable expression* (iii) et= c., resilience is used since the last few years to encompass both dependabi= lity and security. Best, Chidung _______ *: see, e.g., Obama's praise for the resilience of the Indian people (http:= //articles.latimes.com/2010/nov/06/world/la-fgw-obama-mumbai-20101107) Le 02/12/2013 08:21, Cao,Zhen a =E9crit : Good point, Diego. I checked out the NFV ISG released documents of requirements and terminology, where i could not find 'reliability' but 'resilience'. -cz On Wed, Nov 27, 2013 at 2:06 AM, Diego R. Lopez wrote: Hi, When it comes to the reliability/availability issue I guess providing some (condensed) definition from the NFV REL group would help... Be goode, On 26 Nov 2013, at 04:00 , Hidetoshi Yokota wrote: Hi Ning and all, The proposed PS is a very good starting point covering major issues for the goal of VNF pool. One thing that I could add is the synchronization between the vNF migration/replacement and routing to make the relevant flows forwarded to the new location. The challenge is that the VMs/severs in a pool could be deployed over topologically different networks (in the physical world) and VNF migration could involve topologically independent routing. There are multiple ways to do it, but we should first generalize this issue and specify a common mechanism that may leverage existing ones. If this is already covered, that's fine. If some additional text is useful, the following could be a summary: o Synchronization between vNF migration and flow forwarding, which may require topologically independent routing in the physical transport network= ; There is a discussion about "reliability" and "availability" in another thread and I think this is also an issue in ETSI NFV. We need to define the= m either in this group or NFV to share the same view. Regards, -- Hidetoshi Yokota KDDI R&D Laboratories, Inc. e-mail:yokota@kddilabs.jp (2013/11/21 18:11), Zongning wrote: Hi, Please review the below brief version of VNF Pool Problem Statement, and feedback with your comments. I hope this text can serve as a base of VNF Pool Charter, by carving out real problems and work items. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D A virtualized network function (VNF) (e.g. vFW, vLB) provides the same function as the equivalent network function (e.g. FW, LB), but is usually instantiated as a cluster of software instances running on general purpose servers via virtualization platform. In an environment based on VNFs, a network service is typically realized by a chain of VNFs where the instance= s of adjacent VNFs are preferably directly connected. A VNF chain introduces additional points of failure beyond those inherent i= n a single dedicated server, and therefore additional challenges on reliability. By reliability, we mean the ability of a VNF chain to continue function when having transition or failure within the chain. For example, there are more factors such as software failure, server over-utilization, instance migration that potentially cause VNF instance transition or failure. Although a general pooling mechanism can be applied to address the reliability of a single VNF, there are still problems when addressing the reliability of a VNF chain, i.e. multiple pools for multiple VNFs. For example, how does an instance of VNF#1 know which instance in the pool of VNF#2 will replace the instance of VNF#2 it connects to? How does an instance of VNF#1 know the state of instance of VNF#2 that it connects to i= n order to enforce policy for reliability like load sharing, switch before break? How is the service state of an instance held and accessed for efficient synchronization with backup instances? The overall problem space can be further breakdown to the following study items: - Signalling to handle reliability and instance transition requirements o Signalling between VNF pools for transition (e.g. state change, scaling= , moving) notification, backup announcement; o Service state management (e.g. synchronizing method, state data format, location and mechanism to access state data) within VNF pool; o Obtaining underlying network information (e.g. ALTO, I2RS); o Signalling to CMS for instance deployment reflecting reliability requirements (e.g. distribution of instances on different VMs or hypervisors); - Transport characteristics o Identify and analyze reliable transport characteristics for control plane traffic; o Analysis of transport security characteristics to provide protection against known threats, and identification of an appropriate trust model; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Thanks. -Ning -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego@tid.es Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------------- ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el e= nlace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx _______________________________________________ vnfpool mailing list vnfpool@ietf.org https://www.ietf.org/mailman/listinfo/vnfpool --_000_4A95BA014132FF49AE685FAB4B9F17F645C293E9dfweml509mbxchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Chidung,

 <= /p>

Thanks for the quote.

 <= /p>

Based on your quote, the = goal of “vnfpool” should be about to achieve “high availa= bility” of service function chaining while individual service functio= n instances are NOT reliable.  As stated in the problem statement, the virtualize= d network functions have higher chance to fail due to lack of built-in redu= ndancy, server failure, server over-utilized, or software failure, etc.

 <= /p>

Linda

 <= /p>

From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of LAC Chidung
Sent: Monday, December 02, 2013 4:00 AM
To: vnfpool@ietf.org
Subject: Re: [vnfpool] VNF Pool Problem Statement<= /p>

 

Hi all,
Reliability is the ability of an item to perform a required function und= er stated conditions for a stated period of time, while Availability= is a measure of the degree to which an item is in an operable state when c= alled upon to perform. (D.J. Klinger, Y. Nakada, and M.A. Menedez (Eds.), "AT&T Reliability Ma= nual", Van Nostrand Reinhold, 1990)
Applied to the PSTN, the former includes "My call is not dropped durin= g a conversation", while the latter asks for "The phone service i= s ready, i.e., a tone is present, whenever I lift the handset".
For years, Dependability has encompassed these concepts (together wi= th others such as Maintainability) to characterize the good behavior (robustness) of a= system when facing accidental events (design faults, operations errors, hardware failur= es, natural disasters, etc.) , while Security, which includes all intentional actions (attacks, ..= .), is kept apart. This explains the presence, up to now, of two communitie= s working in these two separated subjects.
As (i) unavailability may the consequence of, e.g., software/hardware failu= res OR (D)DoS attacks (ii) Resilience is a fashionable expression* (iii) etc., resilience is us= ed since the last few years to encompass both dependability and security. Best,
Chidung
_______
*: see, e.g., Obama's praise for the resilience of the Indian people (http://articles.latimes.com/2010/nov/06/world/la-fgw-obama-mumbai-20= 101107)

Le 02/12/2013 08:21= , Cao,Zhen a =E9crit :

Good point, Diego.
I checked out the NFV ISG released documents of requirements and<=
/o:p>
terminology, where i could not find 'reliability' but 'resilience'.
-cz
 
On Wed, Nov 27, 2013 at 2:06 AM, Diego R. Lopez <diego@tid.es> wrote:
Hi,
When it comes to the reliability/availability issue I guess providing =
some
(condensed) definition from the NFV REL group would help...=

Be goode,
 
On 26 Nov 2013, at 04:00 , Hidetoshi Yokota wrote:
 
Hi Ning and all,
The proposed PS is a very good starting point covering major issues fo=
r the
goal of VNF pool. One thing that I could add is the synchronization be=
tween
the vNF migration/replacement and routing to make the relevant flows
forwarded to the new location. The challenge is that the VMs/severs in=
 a
pool could be deployed over topologically different networks (in the
physical world) and VNF migration could involve topologically independ=
ent
routing. There are multiple ways to do it, but we should first general=
ize
this issue and specify a common mechanism that may leverage existing o=
nes.
If this is already covered, that's fine. If some additional text is us=
eful,
the following could be a summary:
o Synchronization between vNF migration and flow forwarding, which may=

require topologically independent routing in the physical transport ne=
twork;
There is a discussion about "reliability" and "availabi=
lity" in another
thread and I think this is also an issue in ETSI NFV. We need to defin=
e them
either in this group or NFV to share the same view.
Regards,
--
Hidetoshi Yokota
 
KDDI R&D Laboratories, Inc.
e-mail:yokota@kddilabs.jp=

 
(2013/11/21 18:11), Zongning wrote:
 
Hi,
Please review the below brief version of VNF Pool Problem Statement, a=
nd
feedback with your comments. I hope this text can serve as a base of V=
NF
Pool Charter, by carving out real problems and work items.<=
/pre>

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


A virtualized network function (VNF) (e.g. vFW, vLB) provides the same=



function as the equivalent network function (e.g. FW, LB), but is usua=
lly


instantiated as a cluster of software instances running on general pur=
pose


servers via virtualization platform. In an environment based on VNFs, =
a


network service is typically realized by a chain of VNFs where the ins=
tances


of adjacent VNFs are preferably directly connected.


A VNF chain introduces additional points of failure beyond those inher=
ent in


a single dedicated server, and therefore additional challenges on=



reliability. By reliability, we mean the ability of a VNF chain to con=
tinue


function when having transition or failure within the chain. For examp=
le,


there are more factors such as software failure, server over-utilizati=
on,


instance migration that potentially cause VNF instance transition or


failure. Although a general pooling mechanism can be applied to addres=
s the


reliability of a single VNF, there are still problems when addressing =
the


reliability of a VNF chain, i.e. multiple pools for multiple VNFs. For=



example, how does an instance of VNF#1 know which instance in the pool=
 of


VNF#2 will replace the instance of VNF#2 it connects to? How does an


instance of VNF#1 know the state of instance of VNF#2 that it connects=
 to in


order to enforce policy for reliability like load sharing, switch befo=
re


break? How is the service state of an instance held and accessed for


efficient synchronization with backup instances?


The overall problem space can be further breakdown to the following st=
udy


items:


-          Signalling to =
handle reliability and instance transition


requirements


o   Signalling between VNF pools for transition (e.g. state =
change, scaling,


moving) notification, backup announcement;


o   Service state management (e.g. synchronizing method, sta=
te data format,


location and mechanism to access state data) within VNF pool;


o   Obtaining underlying network information (e.g. ALTO, I2R=
S);


o   Signalling to CMS for instance deployment reflecting rel=
iability


requirements (e.g. distribution of instances on different VMs or<=
/o:p>


hypervisors);


-          Transport char=
acteristics


o   Identify and analyze reliable transport characteristics =
for control


plane traffic;


o   Analysis of transport security characteristics to provid=
e protection


against known threats, and identification of an appropriate trust mode=
l;


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


Thanks.


-Ning


 


--


"Esta vez no fallaremos, Doctor Infierno"


 


Dr Diego R. Lopez


Telefonica I+D


http://people.tid.es/die=
go.lopez/


 


e-mail: diego@tid.es

Tel:    +34 913 129 041


Mobile: +34 682 051 091


-----------------------------------------


 


________________________________


 


Este mensaje se dirige exclusivamente a su destinatario. Puede consult=
ar


nuestra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en=
 el enlace


situado m=E1s abajo.


This message is intended exclusively for its addressee. We only send a=
nd


receive email on the basis of the terms set out at:


http://www.ti=
d.es/ES/PAGINAS/disclaimer.aspx


 


_______________________________________________


vnfpool mailing list


vnfpool@ietf.org

https://www.=
ietf.org/mailman/listinfo/vnfpool
--_000_4A95BA014132FF49AE685FAB4B9F17F645C293E9dfweml509mbxchi_-- From bill.wu@huawei.com Tue Dec 3 16:55:36 2013 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 EDA971ADFC8 for ; Tue, 3 Dec 2013 16:55:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, MANGLED_RVLUTN=2.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 azkWx41TKR79 for ; Tue, 3 Dec 2013 16:55:31 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id BDEF91ADF9A for ; Tue, 3 Dec 2013 16:55:30 -0800 (PST) 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 BAZ29220; Wed, 04 Dec 2013 00:55:27 +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; Wed, 4 Dec 2013 00:54:35 +0000 Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 4 Dec 2013 00:55:25 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Wed, 4 Dec 2013 08:55:21 +0800 From: Qin Wu To: LAC Chidung , "vnfpool@ietf.org" Thread-Topic: [vnfpool] VNF Pool Problem Statement Thread-Index: Ac7mmacuBQUiFtBEQ2CEYoAlHpu1YwDduMMAAB+kuIABF0DFAAAFh5wAADCzs/AAB60egAAp2SDA Date: Wed, 4 Dec 2013 00:55:20 +0000 Message-ID: References: <52940EB0.6040601@kddilabs.jp> <529C5A30.3070000@orange.com> <529DD489.8050008@orange.com> In-Reply-To: <529DD489.8050008@orange.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.149] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA43C686C4nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [vnfpool] VNF Pool 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: Wed, 04 Dec 2013 00:55:36 -0000 --_000_B8F9A780D330094D99AF023C5877DABA43C686C4nkgeml501mbschi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes, agree, we are on the page, thank for your good clarification on these = definitions. Regards! -Qin From: LAC Chidung [mailto:chidung.lac@orange.com] Sent: Tuesday, December 03, 2013 8:55 PM To: Qin Wu; vnfpool@ietf.org Subject: Re: [vnfpool] VNF Pool Problem Statement Hi Qin, 1- Your understanding of availability is perfectly aligned with my sentence= "The phone service is ready ...": it is just an update of the context, i.e= ., * "a tone is present" =3D> "don't loss connection to the network at any tim= e" ('I get the connection whenever I ask for it') * "anywhere" : from the POTS (PSTN) standpoint, it only happened at home, a= t work, or in phone booths - but with the mobile (r)evolution, it is practi= cally anywhere (except during some situations like scubadiving, etc.) * "using any device" : nowadays, the plethora of apparatus (desktop, laptop= , smartphone, tablet, ...) has replaced the traditional (phone) receiver 2- HA: this highly requested criteria in the communications field is suppor= ted, of course, by resilience. It is just a subset of the field of values t= aken by the "availability" metric, which spans from 0 to 1. HA is usually c= haracterized by the mean value 0.99999 (five "9" or 5 min of unavailabilty = per year). Best, Chidung PS: in the ETSI NFV ISG, besides the "Reliability & Availability Working Gr= oup", there is a "Security Expert Group", i.e., when the word 'resilience' = is employed in the R&A WG, security is not included - in other words, "resi= lience" is used in this WG as "dependability", and not as an expression enc= ompassing both dependability and security. Le 03/12/2013 02:19, Qin Wu a =E9crit : In my understanding, availability is more about "don't loss connection to t= he network at any time anywhere using any device" or ubiquity. The resilien= ce should be used to support high availability as well. If resilience doesn't mean high availability then resilience can be redefin= ed to support high availability. My 2 cents. Regards! -Qin From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of LAC Chidung Sent: Monday, December 02, 2013 6:00 PM To: vnfpool@ietf.org Subject: Re: [vnfpool] VNF Pool Problem Statement Hi all, Reliability is the ability of an item to perform a required function under = stated conditions for a stated period of time, while Availability is a meas= ure of the degree to which an item is in an operable state when called upon= to perform. (D.J. Klinger, Y. Nakada, and M.A. Menedez (Eds.), "AT&T Relia= bility Manual", Van Nostrand Reinhold, 1990) Applied to the PSTN, the former includes "My call is not dropped during a c= onversation", while the latter asks for "The phone service is ready, i.e., = a tone is present, whenever I lift the handset". For years, Dependability has encompassed these concepts (together with othe= rs such as Maintainability) to characterize the good behavior (robustness) = of a system when facing accidental events (design faults, operations errors= , hardware failures, natural disasters, etc.) , while Security, which inclu= des all intentional actions (attacks, ...), is kept apart. This explains th= e presence, up to now, of two communities working in these two separated su= bjects. As (i) unavailability may the consequence of, e.g., software/hardware failu= res OR (D)DoS attacks (ii) Resilience is a fashionable expression* (iii) et= c., resilience is used since the last few years to encompass both dependabi= lity and security. Best, Chidung _______ *: see, e.g., Obama's praise for the resilience of the Indian people (http:= //articles.latimes.com/2010/nov/06/world/la-fgw-obama-mumbai-20101107) Le 02/12/2013 08:21, Cao,Zhen a =E9crit : Good point, Diego. I checked out the NFV ISG released documents of requirements and terminology, where i could not find 'reliability' but 'resilience'. -cz On Wed, Nov 27, 2013 at 2:06 AM, Diego R. Lopez wrote: Hi, When it comes to the reliability/availability issue I guess providing some (condensed) definition from the NFV REL group would help... Be goode, On 26 Nov 2013, at 04:00 , Hidetoshi Yokota wrote: Hi Ning and all, The proposed PS is a very good starting point covering major issues for the goal of VNF pool. One thing that I could add is the synchronization between the vNF migration/replacement and routing to make the relevant flows forwarded to the new location. The challenge is that the VMs/severs in a pool could be deployed over topologically different networks (in the physical world) and VNF migration could involve topologically independent routing. There are multiple ways to do it, but we should first generalize this issue and specify a common mechanism that may leverage existing ones. If this is already covered, that's fine. If some additional text is useful, the following could be a summary: o Synchronization between vNF migration and flow forwarding, which may require topologically independent routing in the physical transport network= ; There is a discussion about "reliability" and "availability" in another thread and I think this is also an issue in ETSI NFV. We need to define the= m either in this group or NFV to share the same view. Regards, -- Hidetoshi Yokota KDDI R&D Laboratories, Inc. e-mail:yokota@kddilabs.jp (2013/11/21 18:11), Zongning wrote: Hi, Please review the below brief version of VNF Pool Problem Statement, and feedback with your comments. I hope this text can serve as a base of VNF Pool Charter, by carving out real problems and work items. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D A virtualized network function (VNF) (e.g. vFW, vLB) provides the same function as the equivalent network function (e.g. FW, LB), but is usually instantiated as a cluster of software instances running on general purpose servers via virtualization platform. In an environment based on VNFs, a network service is typically realized by a chain of VNFs where the instance= s of adjacent VNFs are preferably directly connected. A VNF chain introduces additional points of failure beyond those inherent i= n a single dedicated server, and therefore additional challenges on reliability. By reliability, we mean the ability of a VNF chain to continue function when having transition or failure within the chain. For example, there are more factors such as software failure, server over-utilization, instance migration that potentially cause VNF instance transition or failure. Although a general pooling mechanism can be applied to address the reliability of a single VNF, there are still problems when addressing the reliability of a VNF chain, i.e. multiple pools for multiple VNFs. For example, how does an instance of VNF#1 know which instance in the pool of VNF#2 will replace the instance of VNF#2 it connects to? How does an instance of VNF#1 know the state of instance of VNF#2 that it connects to i= n order to enforce policy for reliability like load sharing, switch before break? How is the service state of an instance held and accessed for efficient synchronization with backup instances? The overall problem space can be further breakdown to the following study items: - Signalling to handle reliability and instance transition requirements o Signalling between VNF pools for transition (e.g. state change, scaling= , moving) notification, backup announcement; o Service state management (e.g. synchronizing method, state data format, location and mechanism to access state data) within VNF pool; o Obtaining underlying network information (e.g. ALTO, I2RS); o Signalling to CMS for instance deployment reflecting reliability requirements (e.g. distribution of instances on different VMs or hypervisors); - Transport characteristics o Identify and analyze reliable transport characteristics for control plane traffic; o Analysis of transport security characteristics to provide protection against known threats, and identification of an appropriate trust model; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Thanks. -Ning -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego@tid.es Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------------- ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el e= nlace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx _______________________________________________ vnfpool mailing list vnfpool@ietf.org https://www.ietf.org/mailman/listinfo/vnfpool --_000_B8F9A780D330094D99AF023C5877DABA43C686C4nkgeml501mbschi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Yes, agree, we are on the= page, thank for your good clarification on these definitions.

 <= /p>

Regards!

-Qin

From: LAC Chidung [mailto:chidung.lac@orange.com]
Sent: Tuesday, December 03, 2013 8:55 PM
To: Qin Wu; vnfpool@ietf.org
Subject: Re: [vnfpool] VNF Pool Problem Statement<= /p>

 

Hi Qin,
1- Your understanding of availability is perfectly aligned with my sentence= "The phone service is ready ...": it is just an update of= the context, i.e.,
* "a tone is present" =3D> "don't loss connecti= on to the network at any time" ('I get the connection whenever I a= sk for it')
* "anywhere" : from the POTS (PSTN) standpoint, it only ha= ppened at home, at work, or in phone booths - but with the mobile (r)evolut= ion, it is practically anywhere (except during some situations like scubadi= ving, etc.)
* "using any device" : nowadays, the plethora of apparatus= (desktop, laptop, smartphone, tablet, ...) has replaced the traditional (p= hone) receiver
2- HA: this highly requested criteria in the communications field is suppor= ted, of course, by resilience. It is just a subset of the field of values t= aken by the "availability" metric, which spans from 0 to 1. HA is= usually characterized by the mean value 0.99999 (five "9" or 5 min of unavailabilty per year).
Best,
Chidung
PS: in the ETSI NFV ISG, besides the "Reliability & Availability W= orking Group", there is a "Security Expert Group", i.e., whe= n the word 'resilience' is employed in the R&A WG, security is not incl= uded - in other words, "resilience" is used in this WG as "d= ependability", and not as an expression encompassing both dependability and security.

Le 03/12/2013 02:19= , Qin Wu a =E9crit :

In my understanding, avai= lability is more about “don’t loss connection to the network at= any time anywhere using any device” or ubiquity. The resilience shou= ld be used to support high availability as well.

If resilience doesn’= ;t mean high availability then resilience can be redefined to support high = availability.

My 2 cents.

Regards!

-Qin


From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of LAC Chidung
Sent: Monday, December 02, 2013 6:00 PM
To: vnfpool@ietf.org
Subject: Re: [vnfpool] VNF Pool Problem Statement<= /p>

 

Hi all,
Reliability is the ability of an item to perform a required function und= er stated conditions for a stated period of time, while Availability= is a measure of the degree to which an item is in an operable state when c= alled upon to perform. (D.J. Klinger, Y. Nakada, and M.A. Menedez (Eds.), "AT&T Reliability Ma= nual", Van Nostrand Reinhold, 1990)
Applied to the PSTN, the former includes "My call is not dropped durin= g a conversation", while the latter asks for "The phone service i= s ready, i.e., a tone is present, whenever I lift the handset".
For years, Dependability has encompassed these concepts (together wi= th others such as Maintainability) to characterize the good behavior (robustness) of a= system when facing accidental events (design faults, operations errors, hardware failur= es, natural disasters, etc.) , while Security, which includes all intentional actions (attacks, ..= .), is kept apart. This explains the presence, up to now, of two communitie= s working in these two separated subjects.
As (i) unavailability may the consequence of, e.g., software/hardware failu= res OR (D)DoS attacks (ii) Resilience is a fashionable expression* (iii) etc., resilience is us= ed since the last few years to encompass both dependability and security. Best,
Chidung
_______
*: see, e.g., Obama's praise for the resilience of the Indian people (http://articles.latimes.com/2010/nov/06/world/la-fgw-obama-mumbai-20= 101107)

Le 02/12/2013 08:21= , Cao,Zhen a =E9crit :

Good point, Diego.
I checked out the NFV ISG released documents of requirements and<=
/o:p>
terminology, where i could not find 'reliability' but 'resilience'.
-cz
 
On Wed, Nov 27, 2013 at 2:06 AM, Diego R. Lopez <diego@tid.es> wrote:
Hi,
When it comes to the reliability/availability issue I guess providing =
some
(condensed) definition from the NFV REL group would help...=

Be goode,
 
On 26 Nov 2013, at 04:00 , Hidetoshi Yokota wrote:
 
Hi Ning and all,
The proposed PS is a very good starting point covering major issues fo=
r the
goal of VNF pool. One thing that I could add is the synchronization be=
tween
the vNF migration/replacement and routing to make the relevant flows
forwarded to the new location. The challenge is that the VMs/severs in=
 a
pool could be deployed over topologically different networks (in the
physical world) and VNF migration could involve topologically independ=
ent
routing. There are multiple ways to do it, but we should first general=
ize
this issue and specify a common mechanism that may leverage existing o=
nes.
If this is already covered, that's fine. If some additional text is us=
eful,
the following could be a summary:
o Synchronization between vNF migration and flow forwarding, which may=

require topologically independent routing in the physical transport ne=
twork;
There is a discussion about "reliability" and "availabi=
lity" in another
thread and I think this is also an issue in ETSI NFV. We need to defin=
e them
either in this group or NFV to share the same view.
Regards,
--
Hidetoshi Yokota
 
KDDI R&D Laboratories, Inc.
e-mail:yokota@kddilabs.jp=

 
(2013/11/21 18:11), Zongning wrote:
 
Hi,
Please review the below brief version of VNF Pool Problem Statement, a=
nd
feedback with your comments. I hope this text can serve as a base of V=
NF
Pool Charter, by carving out real problems and work items.<=
/pre>

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


A virtualized network function (VNF) (e.g. vFW, vLB) provides the same=



function as the equivalent network function (e.g. FW, LB), but is usua=
lly


instantiated as a cluster of software instances running on general pur=
pose


servers via virtualization platform. In an environment based on VNFs, =
a


network service is typically realized by a chain of VNFs where the ins=
tances


of adjacent VNFs are preferably directly connected.


A VNF chain introduces additional points of failure beyond those inher=
ent in


a single dedicated server, and therefore additional challenges on=



reliability. By reliability, we mean the ability of a VNF chain to con=
tinue


function when having transition or failure within the chain. For examp=
le,


there are more factors such as software failure, server over-utilizati=
on,


instance migration that potentially cause VNF instance transition or


failure. Although a general pooling mechanism can be applied to addres=
s the


reliability of a single VNF, there are still problems when addressing =
the


reliability of a VNF chain, i.e. multiple pools for multiple VNFs. For=



example, how does an instance of VNF#1 know which instance in the pool=
 of


VNF#2 will replace the instance of VNF#2 it connects to? How does an


instance of VNF#1 know the state of instance of VNF#2 that it connects=
 to in


order to enforce policy for reliability like load sharing, switch befo=
re


break? How is the service state of an instance held and accessed for


efficient synchronization with backup instances?


The overall problem space can be further breakdown to the following st=
udy


items:


-          Signalling to =
handle reliability and instance transition


requirements


o   Signalling between VNF pools for transition (e.g. state =
change, scaling,


moving) notification, backup announcement;


o   Service state management (e.g. synchronizing method, sta=
te data format,


location and mechanism to access state data) within VNF pool;


o   Obtaining underlying network information (e.g. ALTO, I2R=
S);


o   Signalling to CMS for instance deployment reflecting rel=
iability


requirements (e.g. distribution of instances on different VMs or<=
/o:p>


hypervisors);


-          Transport char=
acteristics


o   Identify and analyze reliable transport characteristics =
for control


plane traffic;


o   Analysis of transport security characteristics to provid=
e protection


against known threats, and identification of an appropriate trust mode=
l;


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


Thanks.


-Ning


 


--


"Esta vez no fallaremos, Doctor Infierno"


 


Dr Diego R. Lopez


Telefonica I+D


http://people.tid.es/die=
go.lopez/


 


e-mail: diego@tid.es

Tel:    +34 913 129 041


Mobile: +34 682 051 091


-----------------------------------------


________________________________


 


Este mensaje se dirige exclusivamente a su destinatario. Puede consult=
ar


nuestra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en=
 el enlace


situado m=E1s abajo.


This message is intended exclusively for its addressee. We only send a=
nd


receive email on the basis of the terms set out at:


http://www.ti=
d.es/ES/PAGINAS/disclaimer.aspx


 


_______________________________________________


vnfpool mailing list


vnfpool@ietf.org

https://www.=
ietf.org/mailman/listinfo/vnfpool
--_000_B8F9A780D330094D99AF023C5877DABA43C686C4nkgeml501mbschi_-- From zehn.cao@gmail.com Tue Dec 3 17:26:02 2013 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 1758C1ADFFD for ; Tue, 3 Dec 2013 17:26:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 PGAd7D87_0mq for ; Tue, 3 Dec 2013 17:26:00 -0800 (PST) Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 369781ADFC8 for ; Tue, 3 Dec 2013 17:26:00 -0800 (PST) Received: by mail-qc0-f180.google.com with SMTP id w7so2890881qcr.11 for ; Tue, 03 Dec 2013 17:25:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=A/HzTHdYhCu6ABW7WKHIXaaeVp0E/Fr+vbHgCwChEMA=; b=nFvF+I8Iv6zrKJ5QGTGiG3UQkQtP47vNZ+luE1EHhVy/QnYqkkAMH1nLPMuZz5vQe8 0uCYOP/0wsxBfDscqPkVfI4kHYPJR7EKUSFRQ9eh8HwgjYgcFFftM1QFRGoUOcWKS0Ru a3kM3hp9fQkfwx72sz9NaFNG3XhRTkvdgTqnj4BvSWdsCQ+E/NDE37xvPGyQQ9hatHrD weUZEXaJt69g57bINYwkfJqezrN/Rjd93l5qR5O+E1DKhX9UWUs3lLsvUqs7d3JmWIUF VA06TMgSuTisKHzmhwqpYiba0jTepkZAx4EoOAXHkx+wEqmPmns099a3c9hsEGd2iOWA Qokw== MIME-Version: 1.0 X-Received: by 10.49.2.132 with SMTP id 4mr86335603qeu.15.1386120357243; Tue, 03 Dec 2013 17:25:57 -0800 (PST) Received: by 10.96.63.234 with HTTP; Tue, 3 Dec 2013 17:25:57 -0800 (PST) In-Reply-To: References: Date: Wed, 4 Dec 2013 09:25:57 +0800 Message-ID: From: "Cao,Zhen" To: Qin Wu Content-Type: text/plain; charset=ISO-8859-1 Cc: "vnfpool@ietf.org" , Mukhtiar Shaikh , "Y. Richard Yang" , Zongning Subject: Re: [vnfpool] VNF Pool 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: Wed, 04 Dec 2013 01:26:02 -0000 Hi Qin, > On Tue, Dec 3, 2013 at 9:35 AM, Qin Wu wrote: >> b) The description in the text now seems not highly relevant to the >> NFV context. Some description seems valid even without virtualisation >> basis. Anyway service chain is not only a problem originating from >> virtualisation but more general. Do we need to find more vnf related >> text, e.g., what's the difference between vnf reliability and none >> virtualized system reliability. >> >> [Qin]: Do we really care the difference between the system that is virtualized and the system that is >> Not virtualized? It looks service chaining don't care. > > [cz] If you do not care, nor do I. Because in the text, it starts with > 'vnf'. I thought we are discussing the issues and problems caused by > virtualisation. And the list is vnf-pool, anyway. > > [Qin]: You misunderstand what I said above. I am just asking question. > I want to know if people care the difference between virtualized system and physical system. > In service chain discussion, I fail to see they care or any discussion about distinguishing one from another. [cz] glad to know we two are align with each other. thanks for clarification. > [Qin]: Again, here I am just explaining what the difference is. I am wondering whether these difference has any > Impact on the VNF performance. I guess many of us assume VNF can achieve the same performance as the physical system that has > The same functionality. E.g., physical firewall can be replaced by vFirewall in case of failure. > Please correct me if I am wrong. If the VNF has to achieved comparable performance to the physical infrastructure, the pool size is normally bigger and hence more difficult to manage. Physical fail-over process is normally achieved via hot standby, but in VNF, could be achieved by state transfer. From bill.wu@huawei.com Tue Dec 3 17:37:05 2013 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 3B54F1ADFFC for ; Tue, 3 Dec 2013 17:37:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 PT2xVjvooooh for ; Tue, 3 Dec 2013 17:37:03 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 78B2F1ADFD8 for ; Tue, 3 Dec 2013 17:37:02 -0800 (PST) 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 BAZ31392; Wed, 04 Dec 2013 01:36:59 +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, 4 Dec 2013 01:36:12 +0000 Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 4 Dec 2013 01:36:58 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Wed, 4 Dec 2013 09:36:51 +0800 From: Qin Wu To: Melinda Shore , "vnfpool@ietf.org" Thread-Topic: [vnfpool] Question about addressing in pools Thread-Index: AQHO7VD7cSDSc5yINUOiHv7ulkjXlZpAIgmAgAI4NQCAAAQjgIAA38tQ Date: Wed, 4 Dec 2013 01:36:50 +0000 Message-ID: References: <529912BF.4010307@nomountain.net> <701E4DC3-754C-4308-B507-D85BCAB9B2D6@tid.es> <4A95BA014132FF49AE685FAB4B9F17F645C2936D@dfweml509-mbx.china.huawei.com> <529E33BF.50002@gmail.com> In-Reply-To: <529E33BF.50002@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [vnfpool] Question about addressing in pools 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, 04 Dec 2013 01:37:05 -0000 I think vNF#2 failover and replaced by VNF#1 means vNF#1 and vNF#2 has the = same functionality. If it is this case, why vNF#2 and vNF#1 with the same functionality should = be managed by two different pool managers rather than One common pool manager? Even vNF#2 and vNF#1 has different functionality or provide different servi= ce, can vNF#2 and vNF#1 be managed by the common pool manager? If we place the pool manger in NFV architecture specified by ETSI NFV? What= the position of pool manager in such NFV architecture? Who manage vNF? Hyp= ervisor, controller or orchestrator, or just hosted system? I agree with Melinda the endpoint doesn't need to know whether he is talkin= g to vNF#1 or vNF#2. What he needs to do is Using something like name/address resolution mechanism to get the new addre= ss of backup vNF#2 when vNF#2 is down. Regards! -Qin -----Original Message----- From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of Melinda Shore Sent: Wednesday, December 04, 2013 3:41 AM To: vnfpool@ietf.org Subject: Re: [vnfpool] Question about addressing in pools On 12/3/13 10:25 AM, Linda Dunbar wrote: > I think that it is the "VNF#2 pool manager" that will determine which > instance in VNF#2 will be fail-over one, and is responsible for > passing this VNF#2's failover instance address to "VNF#1 pool > manager". I think it might be a little early to assume that. It's generally the case in HA scenarios that when there's a failover clients/endpoints do not know that they are talking to what a different box (or virtual box). In rserpool endpoints find and access services through ENRP - that is to say, unmodified clients can't take advantage of the pooling mechanism. I think we need to be clear about that. Melinda _______________________________________________ vnfpool mailing list vnfpool@ietf.org https://www.ietf.org/mailman/listinfo/vnfpool From melinda.shore@gmail.com Tue Dec 3 17:51:28 2013 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 416931ADF7E for ; Tue, 3 Dec 2013 17:51:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 wpb0f9M7bsOV for ; Tue, 3 Dec 2013 17:51:26 -0800 (PST) Received: from mail-pb0-x235.google.com (mail-pb0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 5148F1ADF92 for ; Tue, 3 Dec 2013 17:51:26 -0800 (PST) Received: by mail-pb0-f53.google.com with SMTP id ma3so22175467pbc.26 for ; Tue, 03 Dec 2013 17:51:23 -0800 (PST) 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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=51ryH7i98G/uwNI4q4VgZ0rqu2TbZLNUbQmXPk3oiAg=; b=Z6R2yjS/IZal9smBmkgiaZPBc6a9hJPdUoozKbWrrWH0GmJWef1eHHeCBFMNi9aZ90 SE11PZpUJcsnbz7eqjSAx2pfqE0SbjLnbSZ+sw1/gZ89yTG0lzrevrVO61sQ9lQHP0S/ gCWyszxVCRZOQCJbzRGgxAc9lVvcH9xUMopuiAki1bPPpq4KGxZ1pduDgBXtI7XvW9hf /CXJF2dIjzClHxJ+6lvgerBXYcpG98DW9vWORvj/Tgx6owDdwZuGSSd2Wwh+gE8vkf1Y bSarJHFi3KUNQwYvVsS8Lb6jRbql2tw5giq+dwM4KpjTp2KKm8GwgHLoPgVNwKGDd2A4 NJlQ== X-Received: by 10.66.144.227 with SMTP id sp3mr38725426pab.100.1386121883583; Tue, 03 Dec 2013 17:51:23 -0800 (PST) Received: from spandex.local (216-67-50-85-rb3.nwc.dsl.dynamic.acsalaska.net. [216.67.50.85]) by mx.google.com with ESMTPSA id ye1sm14905052pab.19.2013.12.03.17.51.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Dec 2013 17:51:22 -0800 (PST) Message-ID: <529E8A97.9010502@gmail.com> Date: Tue, 03 Dec 2013 16:51:19 -0900 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: Qin Wu References: <529912BF.4010307@nomountain.net> <701E4DC3-754C-4308-B507-D85BCAB9B2D6@tid.es> <4A95BA014132FF49AE685FAB4B9F17F645C2936D@dfweml509-mbx.china.huawei.com> <529E33BF.50002@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "vnfpool@ietf.org" Subject: Re: [vnfpool] Question about addressing in pools 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, 04 Dec 2013 01:51:28 -0000 On 12/3/13 4:36 PM, Qin Wu wrote: > I agree with Melinda the endpoint doesn't need to know whether he is > talking to vNF#1 or vNF#2. What he needs to do is Using something > like name/address resolution mechanism to get the new address of > backup vNF#2 when vNF#2 is down. I'm not sure. My real question is whether or not the endpoint needs to be modified. Melinda From bill.wu@huawei.com Tue Dec 3 17:53:55 2013 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 09EE41ADFE1 for ; Tue, 3 Dec 2013 17:53:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 ay4UVqXkrFhs for ; Tue, 3 Dec 2013 17:53:53 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 962011ADF92 for ; Tue, 3 Dec 2013 17:53:52 -0800 (PST) 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 AYP17088; Wed, 04 Dec 2013 01:53:48 +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; Wed, 4 Dec 2013 01:53:01 +0000 Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 4 Dec 2013 01:53:46 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Wed, 4 Dec 2013 09:53:36 +0800 From: Qin Wu To: "Cao,Zhen" Thread-Topic: [vnfpool] VNF Pool Problem Statement Thread-Index: Ac7mmacuBQUiFtBEQ2CEYoAlHpu1YwBEYqIAAHh0j3AAxZS1AAASOyhGAEozlwAAN5MugAA0t9OgAACQZ4AAEUFcAAAPzU+AABGZAbA= Date: Wed, 4 Dec 2013 01:53:36 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "vnfpool@ietf.org" , Mukhtiar Shaikh , "Y. Richard Yang" , Zongning Subject: Re: [vnfpool] VNF Pool 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: Wed, 04 Dec 2013 01:53:55 -0000 > [Qin]: Again, here I am just explaining what the difference is. I am wond= ering whether these difference has any > Impact on the VNF performance. I guess many of us assume VNF can achieve = the same performance as the physical system that has > The same functionality. E.g., physical firewall can be replaced by vFirew= all in case of failure. > Please correct me if I am wrong. If the VNF has to achieved comparable performance to the physical infrastructure, the pool size is normally bigger and hence more difficult to manage. Physical fail-over process is normally achieved via hot standby, but in VNF, could be achieved by state transfer. [Qin]: For physical fail-over, you still need state synchronization between= active system and standby one. VNF can also use such active-standby fail-over mechanism. Therefore I fail to see the difference. But you are right, if we have a lar= ge number active vNFs working, you=20 Also need the same amount of standby or backup vNF for fail-over processing= ,which is very expensive. _______________________________________________ vnfpool mailing list vnfpool@ietf.org https://www.ietf.org/mailman/listinfo/vnfpool From bill.wu@huawei.com Tue Dec 3 18:01:14 2013 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 830CB1AE010 for ; Tue, 3 Dec 2013 18:01:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 W1o54um4nuTL for ; Tue, 3 Dec 2013 18:01:13 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 14FC61AE00E for ; Tue, 3 Dec 2013 18:01:12 -0800 (PST) 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 AYP17482; Wed, 04 Dec 2013 02:01:09 +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.158.1; Wed, 4 Dec 2013 02:00:22 +0000 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.158.1; Wed, 4 Dec 2013 02:01:08 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Wed, 4 Dec 2013 10:01:01 +0800 From: Qin Wu To: Melinda Shore Thread-Topic: [vnfpool] Question about addressing in pools Thread-Index: AQHO7VD7cSDSc5yINUOiHv7ulkjXlZpAIgmAgAI4NQCAAAQjgIAA38tQ//+HvICAAIdswA== Date: Wed, 4 Dec 2013 02:01:01 +0000 Message-ID: References: <529912BF.4010307@nomountain.net> <701E4DC3-754C-4308-B507-D85BCAB9B2D6@tid.es> <4A95BA014132FF49AE685FAB4B9F17F645C2936D@dfweml509-mbx.china.huawei.com> <529E33BF.50002@gmail.com> <529E8A97.9010502@gmail.com> In-Reply-To: <529E8A97.9010502@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "vnfpool@ietf.org" Subject: Re: [vnfpool] Question about addressing in pools 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, 04 Dec 2013 02:01:14 -0000 What you said is endpoint relies on pooling mechanism and access service th= rough ENRP while what I am saying is endpoint relies on name/address resolu= tion mechanism to talk with pool manager and get the right vNF# instance. Suppose one instance 1 fails, pool manger can provide another vNF instance = 2 to the endpoint. Two instances share the same name and provide the same s= ervice. I see no difference. Please correct me if I am wrong. Regards! -Qin -----Original Message----- From: Melinda Shore [mailto:melinda.shore@gmail.com]=20 Sent: Wednesday, December 04, 2013 9:51 AM To: Qin Wu Cc: vnfpool@ietf.org Subject: Re: [vnfpool] Question about addressing in pools On 12/3/13 4:36 PM, Qin Wu wrote: > I agree with Melinda the endpoint doesn't need to know whether he is > talking to vNF#1 or vNF#2. What he needs to do is Using something > like name/address resolution mechanism to get the new address of > backup vNF#2 when vNF#2 is down. I'm not sure. My real question is whether or not the endpoint needs to be modified. Melinda From melinda.shore@gmail.com Tue Dec 3 18:06:34 2013 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 466451ADFE1 for ; Tue, 3 Dec 2013 18:06:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 8kiIDXg0eOXl for ; Tue, 3 Dec 2013 18:06:33 -0800 (PST) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 0C22A1ADEAE for ; Tue, 3 Dec 2013 18:06:33 -0800 (PST) Received: by mail-pd0-f171.google.com with SMTP id z10so21332360pdj.16 for ; Tue, 03 Dec 2013 18:06:30 -0800 (PST) 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=vYMr46YUBBQXPSrS60LLY/szTkwXF9mByFEvKe7uN40=; b=NJJQiBNqyl520VSr1QYeePOcZMw4LYfpQgXndFo0meKCp6WbAisRstlOdj98v1NXPa F22ucgJ/tDKbdcffXsPdAUl8XEEBss2WAhHN/3wqcqzWPFZ+K+QOqeCC0X3vYvU7j9Be nndub8+ECq4lvMJIsPZ1iX0JY5zuhjJbXpffz2nilEQdZ9IF19bCHhEmCyj0XrXH4mTn 4TyKR7TOiNerXr5M0qx5Z8qGiOUlxiZRf8eU3S3P0Lacb81ovjYI3QLcVFQr3ZQwZyOR ckjUBl86KfmQOIxSlC3id9nvVlobvm2InHvSmlLGGef6nM+QQmVHmEu+/9yp3t+Ausfs fu7w== X-Received: by 10.68.50.226 with SMTP id f2mr41992117pbo.76.1386122790301; Tue, 03 Dec 2013 18:06:30 -0800 (PST) Received: from spandex.local (216-67-50-85-rb3.nwc.dsl.dynamic.acsalaska.net. [216.67.50.85]) by mx.google.com with ESMTPSA id bp5sm133315625pbb.18.2013.12.03.18.06.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Dec 2013 18:06:29 -0800 (PST) Message-ID: <529E8E21.8080203@gmail.com> Date: Tue, 03 Dec 2013 17:06:25 -0900 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: <529912BF.4010307@nomountain.net> <701E4DC3-754C-4308-B507-D85BCAB9B2D6@tid.es> <4A95BA014132FF49AE685FAB4B9F17F645C2936D@dfweml509-mbx.china.huawei.com> <529E33BF.50002@gmail.com> <529E8A97.9010502@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [vnfpool] Question about addressing in pools 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, 04 Dec 2013 02:06:34 -0000 On 12/3/13 5:01 PM, Qin Wu wrote: > What you said is endpoint relies on pooling mechanism and access > service through ENRP while what I am saying is endpoint relies on > name/address resolution mechanism to talk with pool manager and get > the right vNF# instance. Suppose one instance 1 fails, pool manger > can provide another vNF instance 2 to the endpoint. Two instances > share the same name and provide the same service. Conventional HA deployments are transparent to endpoints, requiring no additional software. The IP address (not really a fan of layering discussions but for the sake of this discussion let's say layer 3) remains the same. The endpoint may see a very brief interruption but that's it. In a pooling deployment the endpoint must have additional software providing both name/directory services for a pooled service plus session layer management. I believe that we're talking about a pooled scenario but we really do need to be thorough as we move towards a mature problem statement, if for no other reason than wanting to encounter fewer surprises as chartering discussions get underway. Melinda From bill.wu@huawei.com Tue Dec 3 18:23:40 2013 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 363FA1AE00F for ; Tue, 3 Dec 2013 18:23:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 VWpnWSCjLk1B for ; Tue, 3 Dec 2013 18:23:38 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id F0D681ADF33 for ; Tue, 3 Dec 2013 18:23:37 -0800 (PST) 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 BAZ34067; Wed, 04 Dec 2013 02:23:34 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 4 Dec 2013 02:22:43 +0000 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 4 Dec 2013 02:23:33 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Wed, 4 Dec 2013 10:23:25 +0800 From: Qin Wu To: Melinda Shore , "vnfpool@ietf.org" Thread-Topic: [vnfpool] Question about addressing in pools Thread-Index: AQHO7VD7cSDSc5yINUOiHv7ulkjXlZpAIgmAgAI4NQCAAAQjgIAA38tQ//+HvICAAIdswP//fMyAgACIhPA= Date: Wed, 4 Dec 2013 02:23:24 +0000 Message-ID: References: <529912BF.4010307@nomountain.net> <701E4DC3-754C-4308-B507-D85BCAB9B2D6@tid.es> <4A95BA014132FF49AE685FAB4B9F17F645C2936D@dfweml509-mbx.china.huawei.com> <529E33BF.50002@gmail.com> <529E8A97.9010502@gmail.com> <529E8E21.8080203@gmail.com> In-Reply-To: <529E8E21.8080203@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [vnfpool] Question about addressing in pools 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, 04 Dec 2013 02:23:40 -0000 You are right, I am talking about tradition pooling technology, i.e.,rserpo= ol.=20 I am not familiar with other pooling technology(maybe zookeeper). I agree the session will be interrupted if the address for VNF is not kept = the=20 same. The endpoint will know if the address for VNF changes. So I am wondering if you are going to recommend to add service/session cont= inuity as a requirement during VNF failover. Regards! -Qin -----Original Message----- From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of Melinda Shore Sent: Wednesday, December 04, 2013 10:06 AM To: vnfpool@ietf.org Subject: Re: [vnfpool] Question about addressing in pools On 12/3/13 5:01 PM, Qin Wu wrote: > What you said is endpoint relies on pooling mechanism and access > service through ENRP while what I am saying is endpoint relies on > name/address resolution mechanism to talk with pool manager and get > the right vNF# instance. Suppose one instance 1 fails, pool manger > can provide another vNF instance 2 to the endpoint. Two instances > share the same name and provide the same service. Conventional HA deployments are transparent to endpoints, requiring no additional software. The IP address (not really a fan of layering discussions but for the sake of this discussion let's say layer 3) remains the same. The endpoint may see a very brief interruption but that's it. In a pooling deployment the endpoint must have additional software providing both name/directory services for a pooled service plus session layer management. I believe that we're talking about a pooled scenario but we really do need to be thorough as we move towards a mature problem statement, if for no other reason than wanting to encounter fewer surprises as chartering discussions get underway. Melinda _______________________________________________ vnfpool mailing list vnfpool@ietf.org https://www.ietf.org/mailman/listinfo/vnfpool From zongning@huawei.com Tue Dec 3 21:53:23 2013 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 CD9AD1AE202 for ; Tue, 3 Dec 2013 21:53:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.202 X-Spam-Level: X-Spam-Status: No, score=-104.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 h9YiUul63k4D for ; Tue, 3 Dec 2013 21:53:21 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 581D41AE201 for ; Tue, 3 Dec 2013 21:53:21 -0800 (PST) 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 AYP32551; Wed, 04 Dec 2013 05:53:17 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 4 Dec 2013 05:52:28 +0000 Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 4 Dec 2013 05:53:14 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Wed, 4 Dec 2013 13:53:05 +0800 From: Zongning To: Qin Wu , Melinda Shore , "vnfpool@ietf.org" Thread-Topic: [vnfpool] Question about addressing in pools Thread-Index: AQHO7VD62C4jKXk3dkmRj17vXacmCJpAIgmAgAI4NQCAAAQjgIAAY3sAgADK7xA= Date: Wed, 4 Dec 2013 05:53:04 +0000 Message-ID: References: <529912BF.4010307@nomountain.net> <701E4DC3-754C-4308-B507-D85BCAB9B2D6@tid.es> <4A95BA014132FF49AE685FAB4B9F17F645C2936D@dfweml509-mbx.china.huawei.com> <529E33BF.50002@gmail.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.28] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [vnfpool] Question about addressing in pools 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, 04 Dec 2013 05:53:24 -0000 Hi, To be clear, in our examples in problem statement text, VNF#1 and VNF#2 hav= e different functions, like FW and LB. Whether and how to deploy pool manager is implementation issue. One may eve= n consider the case that pool elements are self-organized to select designa= ted instance, like VRRP. The basic problem here is that there need a mechanism associated with insta= nce failover. It can be either RSerPool-like name resolution, or VRRP-like = virtual address provisioning. Before choosing solution, obviously we need u= se cases. -Ning > -----Original Message----- > From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of Qin Wu > Sent: Wednesday, December 04, 2013 9:37 AM > To: Melinda Shore; vnfpool@ietf.org > Subject: Re: [vnfpool] Question about addressing in pools >=20 > I think vNF#2 failover and replaced by VNF#1 means vNF#1 and vNF#2 has th= e > same functionality. > If it is this case, why vNF#2 and vNF#1 with the same functionality shoul= d be > managed by two different pool managers rather than > One common pool manager? >=20 > Even vNF#2 and vNF#1 has different functionality or provide different ser= vice, > can vNF#2 and vNF#1 be managed by the common pool manager? > If we place the pool manger in NFV architecture specified by ETSI NFV? Wh= at > the position of pool manager in such NFV architecture? Who manage vNF? > Hypervisor, controller or orchestrator, or just hosted system? >=20 > I agree with Melinda the endpoint doesn't need to know whether he is talk= ing > to vNF#1 or vNF#2. What he needs to do is > Using something like name/address resolution mechanism to get the new > address of backup vNF#2 when vNF#2 is down. >=20 > Regards! > -Qin > -----Original Message----- > From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of Melinda Shor= e > Sent: Wednesday, December 04, 2013 3:41 AM > To: vnfpool@ietf.org > Subject: Re: [vnfpool] Question about addressing in pools >=20 > On 12/3/13 10:25 AM, Linda Dunbar wrote: > > I think that it is the "VNF#2 pool manager" that will determine which > > instance in VNF#2 will be fail-over one, and is responsible for > > passing this VNF#2's failover instance address to "VNF#1 pool > > manager". >=20 > I think it might be a little early to assume that. It's generally > the case in HA scenarios that when there's a failover clients/endpoints > do not know that they are talking to what a different box (or virtual > box). In rserpool endpoints find and access services through > ENRP - that is to say, unmodified clients can't take advantage > of the pooling mechanism. I think we need to be clear about > that. >=20 > Melinda > _______________________________________________ > vnfpool mailing list > vnfpool@ietf.org > https://www.ietf.org/mailman/listinfo/vnfpool > _______________________________________________ > vnfpool mailing list > vnfpool@ietf.org > https://www.ietf.org/mailman/listinfo/vnfpool From zongning@huawei.com Tue Dec 3 22:27:30 2013 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 1E2DE1AE04C for ; Tue, 3 Dec 2013 22:27:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.202 X-Spam-Level: X-Spam-Status: No, score=-104.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 17WnGwIAJJQQ for ; Tue, 3 Dec 2013 22:27:28 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id DAE4A1ADBD0 for ; Tue, 3 Dec 2013 22:27:27 -0800 (PST) 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 AYP35105; Wed, 04 Dec 2013 06:27:24 +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, 4 Dec 2013 06:26:12 +0000 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 4 Dec 2013 06:26:58 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Wed, 4 Dec 2013 14:26:49 +0800 From: Zongning To: Zongning , Qin Wu , Melinda Shore , "vnfpool@ietf.org" Thread-Topic: [vnfpool] Question about addressing in pools Thread-Index: AQHO7VD62C4jKXk3dkmRj17vXacmCJpAIgmAgAI4NQCAAAQjgIAAY3sAgADK7xCAAAjPUA== Date: Wed, 4 Dec 2013 06:26:49 +0000 Message-ID: References: <529912BF.4010307@nomountain.net> <701E4DC3-754C-4308-B507-D85BCAB9B2D6@tid.es> <4A95BA014132FF49AE685FAB4B9F17F645C2936D@dfweml509-mbx.china.huawei.com> <529E33BF.50002@gmail.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.28] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [vnfpool] Question about addressing in pools 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, 04 Dec 2013 06:27:30 -0000 Sorry but my last several sentences were not concrete and helpful. Personally I prefer the way that the failover process of the instance in VN= F#1 pool is transparent to the instance in VNF#2 pool, to reduce the reliab= ility overhead. But in order to achieve this goal, we still need HA associa= ted mechanism amongst the instances in VNF#1 pool (or via pool manager) to = maintain the active and standby instance, e.g. by health checking, active/s= tandby announcement, etc. My 2 cents. -Ning > -----Original Message----- > From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of Zongning > Sent: Wednesday, December 04, 2013 1:53 PM > To: Qin Wu; Melinda Shore; vnfpool@ietf.org > Subject: Re: [vnfpool] Question about addressing in pools >=20 > Hi, >=20 > To be clear, in our examples in problem statement text, VNF#1 and VNF#2 h= ave > different functions, like FW and LB. > Whether and how to deploy pool manager is implementation issue. One may > even consider the case that pool elements are self-organized to select > designated instance, like VRRP. > The basic problem here is that there need a mechanism associated with > instance failover. It can be either RSerPool-like name resolution, or VRR= P-like > virtual address provisioning. Before choosing solution, obviously we need= use > cases. >=20 > -Ning >=20 > > -----Original Message----- > > From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of Qin Wu > > Sent: Wednesday, December 04, 2013 9:37 AM > > To: Melinda Shore; vnfpool@ietf.org > > Subject: Re: [vnfpool] Question about addressing in pools > > > > I think vNF#2 failover and replaced by VNF#1 means vNF#1 and vNF#2 has = the > > same functionality. > > If it is this case, why vNF#2 and vNF#1 with the same functionality sho= uld be > > managed by two different pool managers rather than > > One common pool manager? > > > > Even vNF#2 and vNF#1 has different functionality or provide different s= ervice, > > can vNF#2 and vNF#1 be managed by the common pool manager? > > If we place the pool manger in NFV architecture specified by ETSI NFV? = What > > the position of pool manager in such NFV architecture? Who manage vNF? > > Hypervisor, controller or orchestrator, or just hosted system? > > > > I agree with Melinda the endpoint doesn't need to know whether he is ta= lking > > to vNF#1 or vNF#2. What he needs to do is > > Using something like name/address resolution mechanism to get the new > > address of backup vNF#2 when vNF#2 is down. > > > > Regards! > > -Qin > > -----Original Message----- > > From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of Melinda Sh= ore > > Sent: Wednesday, December 04, 2013 3:41 AM > > To: vnfpool@ietf.org > > Subject: Re: [vnfpool] Question about addressing in pools > > > > On 12/3/13 10:25 AM, Linda Dunbar wrote: > > > I think that it is the "VNF#2 pool manager" that will determine which > > > instance in VNF#2 will be fail-over one, and is responsible for > > > passing this VNF#2's failover instance address to "VNF#1 pool > > > manager". > > > > I think it might be a little early to assume that. It's generally > > the case in HA scenarios that when there's a failover clients/endpoints > > do not know that they are talking to what a different box (or virtual > > box). In rserpool endpoints find and access services through > > ENRP - that is to say, unmodified clients can't take advantage > > of the pooling mechanism. I think we need to be clear about > > that. > > > > Melinda > > _______________________________________________ > > vnfpool mailing list > > vnfpool@ietf.org > > https://www.ietf.org/mailman/listinfo/vnfpool > > _______________________________________________ > > vnfpool mailing list > > vnfpool@ietf.org > > https://www.ietf.org/mailman/listinfo/vnfpool > _______________________________________________ > vnfpool mailing list > vnfpool@ietf.org > https://www.ietf.org/mailman/listinfo/vnfpool From bill.wu@huawei.com Wed Dec 4 01:42:03 2013 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 475691AE229 for ; Wed, 4 Dec 2013 01:42:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 2hlDSfIrw90k for ; Wed, 4 Dec 2013 01:42:01 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id EAB001AE09A for ; Wed, 4 Dec 2013 01:42:00 -0800 (PST) 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 BAZ70933; Wed, 04 Dec 2013 09:41:57 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 4 Dec 2013 09:41:03 +0000 Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 4 Dec 2013 09:41:49 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Wed, 4 Dec 2013 17:41:37 +0800 From: Qin Wu To: Zongning , Melinda Shore , "vnfpool@ietf.org" Thread-Topic: [vnfpool] Question about addressing in pools Thread-Index: AQHO7VD7cSDSc5yINUOiHv7ulkjXlZpAIgmAgAI4NQCAAAQjgIAA38tQ///LRwCAAAlugIAAu7Ig Date: Wed, 4 Dec 2013 09:41:36 +0000 Message-ID: References: <529912BF.4010307@nomountain.net> <701E4DC3-754C-4308-B507-D85BCAB9B2D6@tid.es> <4A95BA014132FF49AE685FAB4B9F17F645C2936D@dfweml509-mbx.china.huawei.com> <529E33BF.50002@gmail.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [vnfpool] Question about addressing in pools 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, 04 Dec 2013 09:42:03 -0000 Why not active active failover? You don't need to elect the active one. What you need to do is to detect fa= ilure first and redirect traffic away from failing one to another active on= e. Regards! -Qin -----Original Message----- From: Zongning=20 Sent: Wednesday, December 04, 2013 2:27 PM To: Zongning; Qin Wu; Melinda Shore; vnfpool@ietf.org Subject: RE: [vnfpool] Question about addressing in pools Sorry but my last several sentences were not concrete and helpful. Personally I prefer the way that the failover process of the instance in VN= F#1 pool is transparent to the instance in VNF#2 pool, to reduce the reliab= ility overhead. But in order to achieve this goal, we still need HA associa= ted mechanism amongst the instances in VNF#1 pool (or via pool manager) to = maintain the active and standby instance, e.g. by health checking, active/s= tandby announcement, etc. My 2 cents. -Ning > -----Original Message----- > From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of Zongning > Sent: Wednesday, December 04, 2013 1:53 PM > To: Qin Wu; Melinda Shore; vnfpool@ietf.org > Subject: Re: [vnfpool] Question about addressing in pools >=20 > Hi, >=20 > To be clear, in our examples in problem statement text, VNF#1 and VNF#2 h= ave > different functions, like FW and LB. > Whether and how to deploy pool manager is implementation issue. One may > even consider the case that pool elements are self-organized to select > designated instance, like VRRP. > The basic problem here is that there need a mechanism associated with > instance failover. It can be either RSerPool-like name resolution, or VRR= P-like > virtual address provisioning. Before choosing solution, obviously we need= use > cases. >=20 > -Ning >=20 > > -----Original Message----- > > From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of Qin Wu > > Sent: Wednesday, December 04, 2013 9:37 AM > > To: Melinda Shore; vnfpool@ietf.org > > Subject: Re: [vnfpool] Question about addressing in pools > > > > I think vNF#2 failover and replaced by VNF#1 means vNF#1 and vNF#2 has = the > > same functionality. > > If it is this case, why vNF#2 and vNF#1 with the same functionality sho= uld be > > managed by two different pool managers rather than > > One common pool manager? > > > > Even vNF#2 and vNF#1 has different functionality or provide different s= ervice, > > can vNF#2 and vNF#1 be managed by the common pool manager? > > If we place the pool manger in NFV architecture specified by ETSI NFV? = What > > the position of pool manager in such NFV architecture? Who manage vNF? > > Hypervisor, controller or orchestrator, or just hosted system? > > > > I agree with Melinda the endpoint doesn't need to know whether he is ta= lking > > to vNF#1 or vNF#2. What he needs to do is > > Using something like name/address resolution mechanism to get the new > > address of backup vNF#2 when vNF#2 is down. > > > > Regards! > > -Qin > > -----Original Message----- > > From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of Melinda Sh= ore > > Sent: Wednesday, December 04, 2013 3:41 AM > > To: vnfpool@ietf.org > > Subject: Re: [vnfpool] Question about addressing in pools > > > > On 12/3/13 10:25 AM, Linda Dunbar wrote: > > > I think that it is the "VNF#2 pool manager" that will determine which > > > instance in VNF#2 will be fail-over one, and is responsible for > > > passing this VNF#2's failover instance address to "VNF#1 pool > > > manager". > > > > I think it might be a little early to assume that. It's generally > > the case in HA scenarios that when there's a failover clients/endpoints > > do not know that they are talking to what a different box (or virtual > > box). In rserpool endpoints find and access services through > > ENRP - that is to say, unmodified clients can't take advantage > > of the pooling mechanism. I think we need to be clear about > > that. > > > > Melinda > > _______________________________________________ > > vnfpool mailing list > > vnfpool@ietf.org > > https://www.ietf.org/mailman/listinfo/vnfpool > > _______________________________________________ > > vnfpool mailing list > > vnfpool@ietf.org > > https://www.ietf.org/mailman/listinfo/vnfpool > _______________________________________________ > vnfpool mailing list > vnfpool@ietf.org > https://www.ietf.org/mailman/listinfo/vnfpool From linda.dunbar@huawei.com Wed Dec 4 07:33:10 2013 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 207AC1AE2A2 for ; Wed, 4 Dec 2013 07:33:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 CuhqTYcbZPJv for ; Wed, 4 Dec 2013 07:33:06 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 003D31AE2A1 for ; Wed, 4 Dec 2013 07:33:05 -0800 (PST) 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 AYP89198; Wed, 04 Dec 2013 15:33:01 +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.158.1; Wed, 4 Dec 2013 15:32:10 +0000 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 4 Dec 2013 15:32:57 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.24]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.03.0158.001; Wed, 4 Dec 2013 07:32:45 -0800 From: Linda Dunbar To: Zongning , Zongning , Qin Wu , Melinda Shore , "vnfpool@ietf.org" Thread-Topic: [vnfpool] Question about addressing in pools Thread-Index: AQHO7VD+jTbOOdlTZEWSSl1+dWxSzJpBLkKAgAGw5GCAAIt0gIAAY3sAgABHlwCAAAlugIAAEmBg Date: Wed, 4 Dec 2013 15:32:45 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645C2A139@dfweml509-mbx.china.huawei.com> References: <529912BF.4010307@nomountain.net> <701E4DC3-754C-4308-B507-D85BCAB9B2D6@tid.es> <4A95BA014132FF49AE685FAB4B9F17F645C2936D@dfweml509-mbx.china.huawei.com> <529E33BF.50002@gmail.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.197] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [vnfpool] Question about addressing in pools 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, 04 Dec 2013 15:33:10 -0000 Agree.=20 Linda > -----Original Message----- > From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of Zongning > Sent: Wednesday, December 04, 2013 12:27 AM > To: Zongning; Qin Wu; Melinda Shore; vnfpool@ietf.org > Subject: Re: [vnfpool] Question about addressing in pools >=20 >=20 > Sorry but my last several sentences were not concrete and helpful. > Personally I prefer the way that the failover process of the instance > in VNF#1 pool is transparent to the instance in VNF#2 pool, to reduce > the reliability overhead. But in order to achieve this goal, we still > need HA associated mechanism amongst the instances in VNF#1 pool (or > via pool manager) to maintain the active and standby instance, e.g. by > health checking, active/standby announcement, etc. > My 2 cents. >=20 > -Ning >=20 > > -----Original Message----- > > From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of Zongning > > Sent: Wednesday, December 04, 2013 1:53 PM > > To: Qin Wu; Melinda Shore; vnfpool@ietf.org > > Subject: Re: [vnfpool] Question about addressing in pools > > > > Hi, > > > > To be clear, in our examples in problem statement text, VNF#1 and > VNF#2 have > > different functions, like FW and LB. > > Whether and how to deploy pool manager is implementation issue. One > may > > even consider the case that pool elements are self-organized to > select > > designated instance, like VRRP. > > The basic problem here is that there need a mechanism associated with > > instance failover. It can be either RSerPool-like name resolution, or > VRRP-like > > virtual address provisioning. Before choosing solution, obviously we > need use > > cases. > > > > -Ning > > > > > -----Original Message----- > > > From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of Qin Wu > > > Sent: Wednesday, December 04, 2013 9:37 AM > > > To: Melinda Shore; vnfpool@ietf.org > > > Subject: Re: [vnfpool] Question about addressing in pools > > > > > > I think vNF#2 failover and replaced by VNF#1 means vNF#1 and vNF#2 > has the > > > same functionality. > > > If it is this case, why vNF#2 and vNF#1 with the same functionality > should be > > > managed by two different pool managers rather than > > > One common pool manager? > > > > > > Even vNF#2 and vNF#1 has different functionality or provide > different service, > > > can vNF#2 and vNF#1 be managed by the common pool manager? > > > If we place the pool manger in NFV architecture specified by ETSI > NFV? What > > > the position of pool manager in such NFV architecture? Who manage > vNF? > > > Hypervisor, controller or orchestrator, or just hosted system? > > > > > > I agree with Melinda the endpoint doesn't need to know whether he > is talking > > > to vNF#1 or vNF#2. What he needs to do is > > > Using something like name/address resolution mechanism to get the > new > > > address of backup vNF#2 when vNF#2 is down. > > > > > > Regards! > > > -Qin > > > -----Original Message----- > > > From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of > Melinda Shore > > > Sent: Wednesday, December 04, 2013 3:41 AM > > > To: vnfpool@ietf.org > > > Subject: Re: [vnfpool] Question about addressing in pools > > > > > > On 12/3/13 10:25 AM, Linda Dunbar wrote: > > > > I think that it is the "VNF#2 pool manager" that will determine > which > > > > instance in VNF#2 will be fail-over one, and is responsible for > > > > passing this VNF#2's failover instance address to "VNF#1 pool > > > > manager". > > > > > > I think it might be a little early to assume that. It's generally > > > the case in HA scenarios that when there's a failover > clients/endpoints > > > do not know that they are talking to what a different box (or > virtual > > > box). In rserpool endpoints find and access services through > > > ENRP - that is to say, unmodified clients can't take advantage > > > of the pooling mechanism. I think we need to be clear about > > > that. > > > > > > Melinda > > > _______________________________________________ > > > vnfpool mailing list > > > vnfpool@ietf.org > > > https://www.ietf.org/mailman/listinfo/vnfpool > > > _______________________________________________ > > > vnfpool mailing list > > > vnfpool@ietf.org > > > https://www.ietf.org/mailman/listinfo/vnfpool > > _______________________________________________ > > vnfpool mailing list > > vnfpool@ietf.org > > https://www.ietf.org/mailman/listinfo/vnfpool > _______________________________________________ > vnfpool mailing list > vnfpool@ietf.org > https://www.ietf.org/mailman/listinfo/vnfpool From chidung.lac@orange.com Fri Dec 6 08:53:51 2013 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 98F251AE054 for ; Fri, 6 Dec 2013 08:53:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.615 X-Spam-Level: * X-Spam-Status: No, score=1.615 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665] 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 NR-nNxit1-kP for ; Fri, 6 Dec 2013 08:53:46 -0800 (PST) Received: from r-mail1.rd.orange.com (r-mail1.rd.orange.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id 8C8311AE05C for ; Fri, 6 Dec 2013 08:53:45 -0800 (PST) Received: from r-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 5F04EA440C8; Fri, 6 Dec 2013 17:55:24 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.orange.com (Postfix) with ESMTP id 420FCA440C1; Fri, 6 Dec 2013 17:55:24 +0100 (CET) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 6 Dec 2013 17:42:32 +0100 Received: from [10.193.5.32] ([10.193.5.32]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 6 Dec 2013 17:42:32 +0100 Message-ID: <52A1FE77.10405@orange.com> Date: Fri, 06 Dec 2013 17:42:31 +0100 From: LAC Chidung User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Linda Dunbar , "vnfpool@ietf.org" References: <52940EB0.6040601@kddilabs.jp> <529C5A30.3070000@orange.com> <4A95BA014132FF49AE685FAB4B9F17F645C293E9@dfweml509-mbx.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645C293E9@dfweml509-mbx.china.huawei.com> Content-Type: multipart/alternative; boundary="------------060809000306060501020703" X-OriginalArrivalTime: 06 Dec 2013 16:42:32.0311 (UTC) FILETIME=[28C78070:01CEF2A2] Subject: Re: [vnfpool] VNF Pool 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: Fri, 06 Dec 2013 16:53:51 -0000 This is a multi-part message in MIME format. --------------060809000306060501020703 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi Linda, Please correct the following if I'm wrong. Let's define: VNF = one type of function. _Case 1:_ no service chaining, e.g., a firewall provides the network service Let's state that 3 firewalls are needed, i.e., 3 instances of the VNF "FW". "*/VNFs have higher chance to fail due to lack of built-in redundancy/*" combined with the use of "*/vnfpool/*" means: 1) The 3 FW instances are deployed neither in active/active, nor in active/standby mode, i.e., there are only 3 instances, and not 3 active, and 3 standby. 2) But this solution is not a trusted one because of "*/server failure, server over-utilized, or software failure, etc./*". 3) Assuming that the load of each (FW) instance is less than 60%, one can get HA for this system by using the 3 instances in a pool architecture (based on an efficient load balancing mechanism). 4) In this case, the failure of one instance is acceptable because its load will be shared by the two remaining instances. _Case 2:_ service chaining, e.g., VNF1 and VNF2 are needed in order to provide the network service (for instance, a kid requesting a Web page with the use of a smartphone -> "parental control" (VNF1) checks the URL, followed by "header enrichment" (VNF2) which adds the user ID in the media flow) Lets' state that we have 3 instances of VNF1 and 3 instances of VNF2. If we apply the same reasoning (and hypotheses) as above, we will have a 1st pool made up of 3 instances of VNF1, and a 2nd pool made up of 3 instances of VNF2. The HA of this system is guaranteed if: (i) 1 instance of VNF1 fails, (ii) 1 instance of VNF2 fails, (iii) 1 instance of VNF2 fails and 1 instance of VNF2 fails. Best, Chidung Le 03/12/2013 21:06, Linda Dunbar a écrit : > > Chidung, > > Thanks for the quote. > > Based on your quote, the goal of "vnfpool" should be about to achieve > "high availability" of service function chaining while individual > service function instances are NOT reliable. As stated in the problem > statement, the virtualized network functions have higher chance to > fail due to lack of built-in redundancy, server failure, server > over-utilized, or software failure, etc. > > Linda > > *From:*vnfpool [mailto:vnfpool-bounces@ietf.org] *On Behalf Of *LAC > Chidung > *Sent:* Monday, December 02, 2013 4:00 AM > *To:* vnfpool@ietf.org > *Subject:* Re: [vnfpool] VNF Pool Problem Statement > > Hi all, > /Reliability is the ability of an item to perform a required function > under stated conditions for a stated period of time/, > while/Availability is a measure of the degree to which an item is in > an operable state when called upon to perform./ (D.J. Klinger, Y. > Nakada, and M.A. Menedez (Eds.), "AT&T Reliability Manual", Van > Nostrand Reinhold, 1990) > Applied to the PSTN, the former includes "My call is not dropped > during a conversation", while the latter asks for "The phone service > is ready, i.e., a tone is present, whenever I lift the handset". > For years, /Dependability /has encompassed these concepts (together > with others such as /Maintainability) /to characterize the good > behavior (robustness) of a system when facing *accidental *events > (design faults, operations errors, hardware failures, natural > disasters, etc.) , while /Security, /which includes all *intentional > *actions (attacks, ...), is kept apart. This explains the presence, up > to now, of two communities working in these two separated subjects. > As (i) unavailability may the consequence of, e.g., software/hardware > failures OR (D)DoS attacks (ii) /Resilience/ is a fashionable > expression* (iii) etc., resilience is used since the last few years to > encompass both dependability and security. > Best, > Chidung > _______ > *: see, e.g., Obama's praise for the resilience of the Indian people > (http://articles.latimes.com/2010/nov/06/world/la-fgw-obama-mumbai-20101107) > > Le 02/12/2013 08:21, Cao,Zhen a écrit : > > Good point, Diego. > > I checked out the NFV ISG released documents of requirements and > > terminology, where i could not find 'reliability' but 'resilience'. > > -cz > > > > On Wed, Nov 27, 2013 at 2:06 AM, Diego R. Lopez wrote: > > Hi, > > When it comes to the reliability/availability issue I guess providing some > > (condensed) definition from the NFV REL group would help... > > Be goode, > > > > On 26 Nov 2013, at 04:00 , Hidetoshi Yokota wrote: > > > > Hi Ning and all, > > The proposed PS is a very good starting point covering major issues for the > > goal of VNF pool. One thing that I could add is the synchronization between > > the vNF migration/replacement and routing to make the relevant flows > > forwarded to the new location. The challenge is that the VMs/severs in a > > pool could be deployed over topologically different networks (in the > > physical world) and VNF migration could involve topologically independent > > routing. There are multiple ways to do it, but we should first generalize > > this issue and specify a common mechanism that may leverage existing ones. > > If this is already covered, that's fine. If some additional text is useful, > > the following could be a summary: > > o Synchronization between vNF migration and flow forwarding, which may > > require topologically independent routing in the physical transport network; > > There is a discussion about "reliability" and "availability" in another > > thread and I think this is also an issue in ETSI NFV. We need to define them > > either in this group or NFV to share the same view. > > Regards, > > -- > > Hidetoshi Yokota > > > > KDDI R&D Laboratories, Inc. > > e-mail:yokota@kddilabs.jp > > > > (2013/11/21 18:11), Zongning wrote: > > > > Hi, > > Please review the below brief version of VNF Pool Problem Statement, and > > feedback with your comments. I hope this text can serve as a base of VNF > > Pool Charter, by carving out real problems and work items. > > =========================================================================================== > > A virtualized network function (VNF) (e.g. vFW, vLB) provides the same > > function as the equivalent network function (e.g. FW, LB), but is usually > > instantiated as a cluster of software instances running on general purpose > > servers via virtualization platform. In an environment based on VNFs, a > > network service is typically realized by a chain of VNFs where the instances > > of adjacent VNFs are preferably directly connected. > > A VNF chain introduces additional points of failure beyond those inherent in > > a single dedicated server, and therefore additional challenges on > > reliability. By reliability, we mean the ability of a VNF chain to continue > > function when having transition or failure within the chain. For example, > > there are more factors such as software failure, server over-utilization, > > instance migration that potentially cause VNF instance transition or > > failure. Although a general pooling mechanism can be applied to address the > > reliability of a single VNF, there are still problems when addressing the > > reliability of a VNF chain, i.e. multiple pools for multiple VNFs. For > > example, how does an instance of VNF#1 know which instance in the pool of > > VNF#2 will replace the instance of VNF#2 it connects to? How does an > > instance of VNF#1 know the state of instance of VNF#2 that it connects to in > > order to enforce policy for reliability like load sharing, switch before > > break? How is the service state of an instance held and accessed for > > efficient synchronization with backup instances? > > The overall problem space can be further breakdown to the following study > > items: > > - Signalling to handle reliability and instance transition > > requirements > > o Signalling between VNF pools for transition (e.g. state change, scaling, > > moving) notification, backup announcement; > > o Service state management (e.g. synchronizing method, state data format, > > location and mechanism to access state data) within VNF pool; > > o Obtaining underlying network information (e.g. ALTO, I2RS); > > o Signalling to CMS for instance deployment reflecting reliability > > requirements (e.g. distribution of instances on different VMs or > > hypervisors); > > - Transport characteristics > > o Identify and analyze reliable transport characteristics for control > > plane traffic; > > o Analysis of transport security characteristics to provide protection > > against known threats, and identification of an appropriate trust model; > > =========================================================================================== > > Thanks. > > -Ning > > > > -- > > "Esta vez no fallaremos, Doctor Infierno" > > > > Dr Diego R. Lopez > > Telefonica I+D > > http://people.tid.es/diego.lopez/ > > > > e-mail:diego@tid.es > > Tel: +34 913 129 041 > > Mobile: +34 682 051 091 > > ----------------------------------------- > > > > vnfpool mailing list > > vnfpool@ietf.org > > https://www.ietf.org/mailman/listinfo/vnfpool > --------------060809000306060501020703 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Linda,
Please correct the following if I'm wrong.
Let's define: VNF = one type of function.
Case 1: no service chaining, e.g., a firewall provides the network service
Let's state that 3 firewalls are needed, i.e., 3 instances of the VNF "FW".
"VNFs have higher chance to fail due to lack of built-in redundancy" combined with the use of "vnfpool" means:
1) The 3 FW instances are deployed neither in active/active, nor in active/standby mode, i.e., there are only 3 instances, and not 3 active, and 3 standby.
2) But this solution is not a trusted one because of "server failure, server over-utilized, or software failure, etc.".
3) Assuming that the load of each (FW) instance is less than 60%, one can get HA for this system by using the 3 instances in a pool architecture (based on an efficient load balancing mechanism).
4) In this case, the failure of one instance is acceptable because its load will be shared by the two remaining instances.
Case 2: service chaining, e.g., VNF1 and VNF2 are needed in order to provide the network service (for instance, a kid requesting a Web page with the use of a smartphone -> "parental control" (VNF1) checks the URL, followed by "header enrichment" (VNF2) which adds the user ID in the media flow)
Lets' state that we have 3 instances of VNF1 and 3 instances of VNF2. If we apply the same reasoning (and hypotheses) as above, we will have a 1st pool made up of 3 instances of VNF1, and a 2nd pool made up of 3 instances of VNF2. The HA of this system is guaranteed if: (i) 1 instance of VNF1 fails, (ii) 1 instance of VNF2 fails, (iii) 1 instance of VNF2 fails and 1 instance of VNF2 fails.
Best,
Chidung

Le 03/12/2013 21:06, Linda Dunbar a écrit :

Chidung,

Thanks for the quote.

Based on your quote, the goal of “vnfpool” should be about to achieve “high availability” of service function chaining while individual service function instances are NOT reliable.  As stated in the problem statement, the virtualized network functions have higher chance to fail due to lack of built-in redundancy, server failure, server over-utilized, or software failure, etc.

Linda

 

From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of LAC Chidung
Sent: Monday, December 02, 2013 4:00 AM
To: vnfpool@ietf.org
Subject: Re: [vnfpool] VNF Pool Problem Statement

 

Hi all,
Reliability is the ability of an item to perform a required function under stated conditions for a stated period of time, while Availability is a measure of the degree to which an item is in an operable state when called upon to perform. (D.J. Klinger, Y. Nakada, and M.A. Menedez (Eds.), "AT&T Reliability Manual", Van Nostrand Reinhold, 1990)
Applied to the PSTN, the former includes "My call is not dropped during a conversation", while the latter asks for "The phone service is ready, i.e., a tone is present, whenever I lift the handset".
For years, Dependability has encompassed these concepts (together with others such as Maintainability) to characterize the good behavior (robustness) of a system when facing accidental events (design faults, operations errors, hardware failures, natural disasters, etc.) , while Security, which includes all intentional actions (attacks, ...), is kept apart. This explains the presence, up to now, of two communities working in these two separated subjects.
As (i) unavailability may the consequence of, e.g., software/hardware failures OR (D)DoS attacks (ii) Resilience is a fashionable expression* (iii) etc., resilience is used since the last few years to encompass both dependability and security.
Best,
Chidung
_______
*: see, e.g., Obama's praise for the resilience of the Indian people (http://articles.latimes.com/2010/nov/06/world/la-fgw-obama-mumbai-20101107)

Le 02/12/2013 08:21, Cao,Zhen a écrit :

Good point, Diego.
I checked out the NFV ISG released documents of requirements and
terminology, where i could not find 'reliability' but 'resilience'.
-cz
 
On Wed, Nov 27, 2013 at 2:06 AM, Diego R. Lopez <diego@tid.es> wrote:
Hi,
When it comes to the reliability/availability issue I guess providing some
(condensed) definition from the NFV REL group would help...
Be goode,
 
On 26 Nov 2013, at 04:00 , Hidetoshi Yokota wrote:
 
Hi Ning and all,
The proposed PS is a very good starting point covering major issues for the
goal of VNF pool. One thing that I could add is the synchronization between
the vNF migration/replacement and routing to make the relevant flows
forwarded to the new location. The challenge is that the VMs/severs in a
pool could be deployed over topologically different networks (in the
physical world) and VNF migration could involve topologically independent
routing. There are multiple ways to do it, but we should first generalize
this issue and specify a common mechanism that may leverage existing ones.
If this is already covered, that's fine. If some additional text is useful,
the following could be a summary:
o Synchronization between vNF migration and flow forwarding, which may
require topologically independent routing in the physical transport network;
There is a discussion about "reliability" and "availability" in another
thread and I think this is also an issue in ETSI NFV. We need to define them
either in this group or NFV to share the same view.
Regards,
--
Hidetoshi Yokota
 
KDDI R&D Laboratories, Inc.
e-mail:yokota@kddilabs.jp
 
(2013/11/21 18:11), Zongning wrote:
 
Hi,
Please review the below brief version of VNF Pool Problem Statement, and
feedback with your comments. I hope this text can serve as a base of VNF
Pool Charter, by carving out real problems and work items.
===========================================================================================
A virtualized network function (VNF) (e.g. vFW, vLB) provides the same
function as the equivalent network function (e.g. FW, LB), but is usually
instantiated as a cluster of software instances running on general purpose
servers via virtualization platform. In an environment based on VNFs, a
network service is typically realized by a chain of VNFs where the instances
of adjacent VNFs are preferably directly connected.
A VNF chain introduces additional points of failure beyond those inherent in
a single dedicated server, and therefore additional challenges on
reliability. By reliability, we mean the ability of a VNF chain to continue
function when having transition or failure within the chain. For example,
there are more factors such as software failure, server over-utilization,
instance migration that potentially cause VNF instance transition or
failure. Although a general pooling mechanism can be applied to address the
reliability of a single VNF, there are still problems when addressing the
reliability of a VNF chain, i.e. multiple pools for multiple VNFs. For
example, how does an instance of VNF#1 know which instance in the pool of
VNF#2 will replace the instance of VNF#2 it connects to? How does an
instance of VNF#1 know the state of instance of VNF#2 that it connects to in
order to enforce policy for reliability like load sharing, switch before
break? How is the service state of an instance held and accessed for
efficient synchronization with backup instances?
The overall problem space can be further breakdown to the following study
items:
-          Signalling to handle reliability and instance transition
requirements
o   Signalling between VNF pools for transition (e.g. state change, scaling,
moving) notification, backup announcement;
o   Service state management (e.g. synchronizing method, state data format,
location and mechanism to access state data) within VNF pool;
o   Obtaining underlying network information (e.g. ALTO, I2RS);
o   Signalling to CMS for instance deployment reflecting reliability
requirements (e.g. distribution of instances on different VMs or
hypervisors);
-          Transport characteristics
o   Identify and analyze reliable transport characteristics for control
plane traffic;
o   Analysis of transport security characteristics to provide protection
against known threats, and identification of an appropriate trust model;
===========================================================================================
Thanks.
-Ning
 
--
"Esta vez no fallaremos, Doctor Infierno"
 
Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/
 
e-mail: diego@tid.es
Tel:    +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------
 
vnfpool mailing list
vnfpool@ietf.org
https://www.ietf.org/mailman/listinfo/vnfpool
--------------060809000306060501020703-- From chidung.lac@orange.com Fri Dec 6 09:25:52 2013 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 BDF9F1AE1F9 for ; Fri, 6 Dec 2013 09:25:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.884 X-Spam-Level: X-Spam-Status: No, score=-0.884 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665] 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 JJgm-Lz_-S0t for ; Fri, 6 Dec 2013 09:25:50 -0800 (PST) Received: from r-mail2.rd.orange.com (r-mail2.rd.orange.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 6514A1ADF6E for ; Fri, 6 Dec 2013 09:25:50 -0800 (PST) Received: from r-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id DCCD55D8893 for ; Fri, 6 Dec 2013 18:25:45 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.orange.com (Postfix) with ESMTP id D0F295D86F9 for ; Fri, 6 Dec 2013 18:25:45 +0100 (CET) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 6 Dec 2013 18:13:49 +0100 Received: from [10.193.5.32] ([10.193.5.32]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 6 Dec 2013 18:13:48 +0100 Message-ID: <52A205CC.8060002@orange.com> Date: Fri, 06 Dec 2013 18:13:48 +0100 From: LAC Chidung User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "vnfpool@ietf.org" References: <529912BF.4010307@nomountain.net> <701E4DC3-754C-4308-B507-D85BCAB9B2D6@tid.es> <4A95BA014132FF49AE685FAB4B9F17F645C2936D@dfweml509-mbx.china.huawei.com> <529E33BF.50002@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090500050105010008090707" X-OriginalArrivalTime: 06 Dec 2013 17:13:48.0690 (UTC) FILETIME=[87303720:01CEF2A6] Subject: Re: [vnfpool] Question about addressing in pools 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, 06 Dec 2013 17:25:52 -0000 This is a multi-part message in MIME format. --------------090500050105010008090707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit "*Who manage vNF? Hypervisor, controller or orchestrator, or just hosted system?* " If we refer to http://docbox.etsi.org/ISG/NFV/Open/Published/gs_NFV002v010101p.pdf Figure 4 suggests that (of course, I may be wrong ...): - each VNF has its own element management system (EMS); different VNFs from different vendors may be used to provide a certain network service - the VNF Managers actions include (i) collecting data (OAM, etc.) from the VNFs and from the virtual infrastructure; (ii) providing scalability ('out' to create a new VM, or 'in' to suppress a VM - a VM being an instance of a VNF) - an unique orchestrator controlling the VNF Managers in a data center (cloud) environment, e.g., OpenStack Best, Chidung PS: the hypervisor, e.g., KVM, is represented in this figure by the "Virtualisation Layer" Le 04/12/2013 02:36, Qin Wu a écrit : > I think vNF#2 failover and replaced by VNF#1 means vNF#1 and vNF#2 has the same functionality. > If it is this case, why vNF#2 and vNF#1 with the same functionality should be managed by two different pool managers rather than > One common pool manager? > Even vNF#2 and vNF#1 has different functionality or provide different service, can vNF#2 and vNF#1 be managed by the common pool manager? > If we place the pool manger in NFV architecture specified by ETSI NFV? What the position of pool manager in such NFV architecture? Who manage vNF? Hypervisor, controller or orchestrator, or just hosted system? > I agree with Melinda the endpoint doesn't need to know whether he is talking to vNF#1 or vNF#2. What he needs to do is > Using something like name/address resolution mechanism to get the new address of backup vNF#2 when vNF#2 is down. > Regards! > -Qin > > -----Original Message----- > From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of Melinda Shore > Sent: Wednesday, December 04, 2013 3:41 AM > To: vnfpool@ietf.org > Subject: Re: [vnfpool] Question about addressing in pools > > On 12/3/13 10:25 AM, Linda Dunbar wrote: >> I think that it is the "VNF#2 pool manager" that will determine which >> instance in VNF#2 will be fail-over one, and is responsible for >> passing this VNF#2's failover instance address to "VNF#1 pool >> manager". > I think it might be a little early to assume that. It's generally > the case in HA scenarios that when there's a failover clients/endpoints > do not know that they are talking to what a different box (or virtual > box). In rserpool endpoints find and access services through > ENRP - that is to say, unmodified clients can't take advantage > of the pooling mechanism. I think we need to be clear about > that. > Melinda > _______________________________________________ > vnfpool mailing list > vnfpool@ietf.org > https://www.ietf.org/mailman/listinfo/vnfpool --------------090500050105010008090707 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit "Who manage vNF? Hypervisor, controller or orchestrator, or just hosted system? "
If we refer to http://docbox.etsi.org/ISG/NFV/Open/Published/gs_NFV002v010101p.pdf
Figure 4 suggests that (of course, I may be wrong ...):
- each VNF has its own element management system (EMS); different VNFs from different vendors may be used to provide a certain network service
- the VNF Managers actions include (i) collecting data (OAM, etc.) from the VNFs and from the virtual infrastructure; (ii) providing scalability ('out' to create a new VM, or 'in' to suppress a VM - a VM being an instance of a VNF)
- an unique orchestrator controlling the VNF Managers in a data center (cloud) environment, e.g., OpenStack
Best,
Chidung
PS: the hypervisor, e.g., KVM, is represented in this figure by the "Virtualisation Layer"

Le 04/12/2013 02:36, Qin Wu a écrit :
I think vNF#2 failover and replaced by VNF#1 means vNF#1 and vNF#2 has the same functionality.
If it is this case, why vNF#2 and vNF#1 with the same functionality should be managed by two different pool managers rather than
One common pool manager?
Even vNF#2 and vNF#1 has different functionality or provide different service, can vNF#2 and vNF#1 be managed by the common pool manager?
If we place the pool manger in NFV architecture specified by ETSI NFV? What the position of pool manager in such NFV architecture? Who manage vNF? Hypervisor, controller or orchestrator, or just hosted system?
I agree with Melinda the endpoint doesn't need to know whether he is talking to vNF#1 or vNF#2. What he needs to do is
Using something like name/address resolution mechanism to get the new address of backup vNF#2 when vNF#2 is down.
Regards!
-Qin

-----Original Message-----
From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of Melinda Shore
Sent: Wednesday, December 04, 2013 3:41 AM
To: vnfpool@ietf.org
Subject: Re: [vnfpool] Question about addressing in pools

On 12/3/13 10:25 AM, Linda Dunbar wrote:

I think that it is the "VNF#2 pool manager" that will determine which
instance in VNF#2 will be fail-over one, and is responsible for
passing this VNF#2's failover instance address to "VNF#1 pool
manager".

I think it might be a little early to assume that.  It's generally
the case in HA scenarios that when there's a failover clients/endpoints
do not know that they are talking to what a different box (or virtual
box).  In rserpool endpoints find and access services through
ENRP - that is to say, unmodified clients can't take advantage
of the pooling mechanism.  I think we need to be clear about
that.
Melinda
_______________________________________________
vnfpool mailing list
vnfpool@ietf.org
https://www.ietf.org/mailman/listinfo/vnfpool
--------------090500050105010008090707-- From d.king@lancaster.ac.uk Fri Dec 6 13:02:18 2013 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 023271AE0D8 for ; Fri, 6 Dec 2013 13:02:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, 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 OoyuYn5zpI3W for ; Fri, 6 Dec 2013 13:02:10 -0800 (PST) Received: from ignavia.lancs.ac.uk (ignavia.lancs.ac.uk [148.88.25.16]) by ietfa.amsl.com (Postfix) with ESMTP id 111221AE062 for ; Fri, 6 Dec 2013 13:02:10 -0800 (PST) Received: from ex-0-ht0.lancs.ac.uk ([10.42.18.47] helo=EX-0-HT0.lancs.local) by ignavia.lancs.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1Vp2XF-0001r1-I9; Fri, 06 Dec 2013 21:02:05 +0000 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.0158.001; Fri, 6 Dec 2013 21:02:05 +0000 From: "King, Daniel" To: LAC Chidung Thread-Topic: [vnfpool] VNF Pool Problem Statement Thread-Index: AQHY+TQ7dY3tQjejG3tIVJ9qDrtQ3QIpAmXyASf3zuYCZZPHvAKcw0hyAt4ScbICsFsViJnEeYQQ Date: Fri, 6 Dec 2013 21:02:03 +0000 Message-ID: <65174429B5AF4C45BD0798810EC48E0A0D38CF@EX-0-MB2.lancs.local> References: <52940EB0.6040601@kddilabs.jp> <529C5A30.3070000@orange.com> <4A95BA014132FF49AE685FAB4B9F17F645C293E9@dfweml509-mbx.china.huawei.com> <52A1FE77.10405@orange.com> In-Reply-To: <52A1FE77.10405@orange.com> 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_65174429B5AF4C45BD0798810EC48E0A0D38CFEX0MB2lancslocal_" MIME-Version: 1.0 Cc: "vnfpool@ietf.org" , Linda Dunbar Subject: Re: [vnfpool] VNF Pool 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: Fri, 06 Dec 2013 21:02:18 -0000 --_000_65174429B5AF4C45BD0798810EC48E0A0D38CFEX0MB2lancslocal_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Chidung, Thanks for using definitions, and providing the example use cases. The serv= ice chaining and non-service chaining examples are good, but could you also= clarify a deployment, and therefore, solution requirements from an operato= r perspective? Is it expected that client service ("FW" in this use case) resilience would= be typically be provided by each VNF pool sharing the same VLAN, with a vi= rtual server using a "fixed IP" address that maps to a cluster of "dynamic = IP addresses" to multiple VMs, with say one VM for hosting a VNF(s)? Spanni= ng tree would run between the VM instances, and VRRP used to provide backup= for the default gateways. This deployment scenario would support the follo= wing: - Load-balancing across VNFs - Fail-over between VNFs - Migration to new VNFs This architecture would also support mixed environments, where existing pro= priety FW hardware and virtual (VM/VNFs) might be used for migration and te= sting. Actually, the same question to the other operators. It would be real= ly good to understand the thinking behind how best to achieve cost-effectiv= e (time and resources) resilience. As a co-author of "draft-xia-vsnpool-man= agement-use-case" I am trying to figure out if "existing" (VRRP, RSPT, et a= l.) mechanisms are capable of providing client service continuity and distr= ibuted resilience, or indeed we need to document a set of generic requireme= nts that our work in vnfpool will need to solve. Br, Dan. From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of LAC Chidung Sent: 06 December 2013 16:43 To: Linda Dunbar; vnfpool@ietf.org Subject: Re: [vnfpool] VNF Pool Problem Statement Hi Linda, Please correct the following if I'm wrong. Let's define: VNF =3D one type of function. Case 1: no service chaining, e.g., a firewall provides the network service Let's state that 3 firewalls are needed, i.e., 3 instances of the VNF "FW". "VNFs have higher chance to fail due to lack of built-in redundancy" combin= ed with the use of "vnfpool" means: 1) The 3 FW instances are deployed neither in active/active, nor in active/= standby mode, i.e., there are only 3 instances, and not 3 active, and 3 sta= ndby. 2) But this solution is not a trusted one because of "server failure, serve= r over-utilized, or software failure, etc.". 3) Assuming that the load of each (FW) instance is less than 60%, one can g= et HA for this system by using the 3 instances in a pool architecture (base= d on an efficient load balancing mechanism). 4) In this case, the failure of one instance is acceptable because its load= will be shared by the two remaining instances. Case 2: service chaining, e.g., VNF1 and VNF2 are needed in order to provid= e the network service (for instance, a kid requesting a Web page with the u= se of a smartphone -> "parental control" (VNF1) checks the URL, followed by= "header enrichment" (VNF2) which adds the user ID in the media flow) Lets' state that we have 3 instances of VNF1 and 3 instances of VNF2. If we= apply the same reasoning (and hypotheses) as above, we will have a 1st poo= l made up of 3 instances of VNF1, and a 2nd pool made up of 3 instances of = VNF2. The HA of this system is guaranteed if: (i) 1 instance of VNF1 fails,= (ii) 1 instance of VNF2 fails, (iii) 1 instance of VNF2 fails and 1 instan= ce of VNF2 fails. Best, Chidung Le 03/12/2013 21:06, Linda Dunbar a =E9crit : Chidung, Thanks for the quote. Based on your quote, the goal of "vnfpool" should be about to achieve "high= availability" of service function chaining while individual service functi= on instances are NOT reliable. As stated in the problem statement, the vir= tualized network functions have higher chance to fail due to lack of built-= in redundancy, server failure, server over-utilized, or software failure, e= tc. Linda From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of LAC Chidung Sent: Monday, December 02, 2013 4:00 AM To: vnfpool@ietf.org Subject: Re: [vnfpool] VNF Pool Problem Statement Hi all, Reliability is the ability of an item to perform a required function under = stated conditions for a stated period of time, while Availability is a meas= ure of the degree to which an item is in an operable state when called upon= to perform. (D.J. Klinger, Y. Nakada, and M.A. Menedez (Eds.), "AT&T Relia= bility Manual", Van Nostrand Reinhold, 1990) Applied to the PSTN, the former includes "My call is not dropped during a c= onversation", while the latter asks for "The phone service is ready, i.e., = a tone is present, whenever I lift the handset". For years, Dependability has encompassed these concepts (together with othe= rs such as Maintainability) to characterize the good behavior (robustness) = of a system when facing accidental events (design faults, operations errors= , hardware failures, natural disasters, etc.) , while Security, which inclu= des all intentional actions (attacks, ...), is kept apart. This explains th= e presence, up to now, of two communities working in these two separated su= bjects. As (i) unavailability may the consequence of, e.g., software/hardware failu= res OR (D)DoS attacks (ii) Resilience is a fashionable expression* (iii) et= c., resilience is used since the last few years to encompass both dependabi= lity and security. Best, Chidung _______ *: see, e.g., Obama's praise for the resilience of the Indian people (http:= //articles.latimes.com/2010/nov/06/world/la-fgw-obama-mumbai-20101107) Le 02/12/2013 08:21, Cao,Zhen a =E9crit : Good point, Diego. I checked out the NFV ISG released documents of requirements and terminology, where i could not find 'reliability' but 'resilience'. -cz On Wed, Nov 27, 2013 at 2:06 AM, Diego R. Lopez wrote: Hi, When it comes to the reliability/availability issue I guess providing some (condensed) definition from the NFV REL group would help... Be goode, On 26 Nov 2013, at 04:00 , Hidetoshi Yokota wrote: Hi Ning and all, The proposed PS is a very good starting point covering major issues for the goal of VNF pool. One thing that I could add is the synchronization between the vNF migration/replacement and routing to make the relevant flows forwarded to the new location. The challenge is that the VMs/severs in a pool could be deployed over topologically different networks (in the physical world) and VNF migration could involve topologically independent routing. There are multiple ways to do it, but we should first generalize this issue and specify a common mechanism that may leverage existing ones. If this is already covered, that's fine. If some additional text is useful, the following could be a summary: o Synchronization between vNF migration and flow forwarding, which may require topologically independent routing in the physical transport network= ; There is a discussion about "reliability" and "availability" in another thread and I think this is also an issue in ETSI NFV. We need to define the= m either in this group or NFV to share the same view. Regards, -- Hidetoshi Yokota KDDI R&D Laboratories, Inc. e-mail:yokota@kddilabs.jp (2013/11/21 18:11), Zongning wrote: Hi, Please review the below brief version of VNF Pool Problem Statement, and feedback with your comments. I hope this text can serve as a base of VNF Pool Charter, by carving out real problems and work items. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D A virtualized network function (VNF) (e.g. vFW, vLB) provides the same function as the equivalent network function (e.g. FW, LB), but is usually instantiated as a cluster of software instances running on general purpose servers via virtualization platform. In an environment based on VNFs, a network service is typically realized by a chain of VNFs where the instance= s of adjacent VNFs are preferably directly connected. A VNF chain introduces additional points of failure beyond those inherent i= n a single dedicated server, and therefore additional challenges on reliability. By reliability, we mean the ability of a VNF chain to continue function when having transition or failure within the chain. For example, there are more factors such as software failure, server over-utilization, instance migration that potentially cause VNF instance transition or failure. Although a general pooling mechanism can be applied to address the reliability of a single VNF, there are still problems when addressing the reliability of a VNF chain, i.e. multiple pools for multiple VNFs. For example, how does an instance of VNF#1 know which instance in the pool of VNF#2 will replace the instance of VNF#2 it connects to? How does an instance of VNF#1 know the state of instance of VNF#2 that it connects to i= n order to enforce policy for reliability like load sharing, switch before break? How is the service state of an instance held and accessed for efficient synchronization with backup instances? The overall problem space can be further breakdown to the following study items: - Signalling to handle reliability and instance transition requirements o Signalling between VNF pools for transition (e.g. state change, scaling= , moving) notification, backup announcement; o Service state management (e.g. synchronizing method, state data format, location and mechanism to access state data) within VNF pool; o Obtaining underlying network information (e.g. ALTO, I2RS); o Signalling to CMS for instance deployment reflecting reliability requirements (e.g. distribution of instances on different VMs or hypervisors); - Transport characteristics o Identify and analyze reliable transport characteristics for control plane traffic; o Analysis of transport security characteristics to provide protection against known threats, and identification of an appropriate trust model; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Thanks. -Ning -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego@tid.es Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------------- vnfpool mailing list vnfpool@ietf.org https://www.ietf.org/mailman/listinfo/vnfpool --_000_65174429B5AF4C45BD0798810EC48E0A0D38CFEX0MB2lancslocal_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Chidung,

 

From= : vnfpool [mailto:v= nfpool-bounces@ietf.org] On Behalf Of LAC Chidung
Sent: 06 December 2013 16:43
To: Linda Dunbar; vnfpool@ietf.org
Subject: Re: [vnfpool] VNF Pool Problem Statement<= /p>

 

Hi Linda,
Please correct the following if I'm wrong.
Let's define: VNF =3D one type of function.
Case 1: no service chaining, e.g., a firewall provides the network s= ervice
Let's state that 3 firewalls are needed, i.e., 3 instances of the VNF "= ;FW".
"VNFs have higher chance to fail due to lack of built-in redunda= ncy" combined with the use of "vnfpool"= ; means:
1) The 3 FW instances are deployed neither in active/active, nor in active/= standby mode, i.e., there are only 3 instances, and not 3 active, and 3 sta= ndby.
2) But this solution is not a trusted one because of "server fai= lure, server over-utilized, or software failure, etc.".
3) Assuming that the load of each (FW) instance is less than 60%, one can g= et HA for this system by using the 3 instances in a pool architecture (base= d on an efficient load balancing mechanism).
4) In this case, the failure of one instance is acceptable because its load= will be shared by the two remaining instances.
Case 2: service chaining, e.g., VNF1 and VNF2 are needed in order to= provide the network service (for instance, a kid requesting a Web page wit= h the use of a smartphone -> "parental control" (VNF1) checks = the URL, followed by "header enrichment" (VNF2) which adds the user ID in the media flow)
Lets' state that we have 3 instances of VNF1 and 3 instances of VNF2. If we= apply the same reasoning (and hypotheses) as above, we will have a 1st poo= l made up of 3 instances of VNF1, and a 2nd pool made up of 3 instances of = VNF2. The HA of this system is guaranteed if: (i) 1 instance of VNF1 fails, (ii) 1 instance of VNF2 fails, (iii) 1 i= nstance of VNF2 fails and 1 instance of VNF2 fails.
Best,
Chidung

Le 03/12/2013 21:06= , Linda Dunbar a =E9crit :

Chidung,

Thanks for the quote.

Based on your quote, the = goal of “vnfpool” should be about to achieve “high availa= bility” of service function chaining while individual service functio= n instances are NOT reliable.  As stated in the problem statement, the virtualize= d network functions have higher chance to fail due to lack of built-in redu= ndancy, server failure, server over-utilized, or software failure, etc.

Linda

 <= /p>

From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of LAC Chidung
Sent: Monday, December 02, 2013 4:00 AM
To: vnfpool@ietf.org
Subject: Re: [vnfpool] VNF Pool Problem Statement<= /p>

 

Hi all,
Reliability is the ability of an item to perform a required function und= er stated conditions for a stated period of time, while Availability= is a measure of the degree to which an item is in an operable state when c= alled upon to perform. (D.J. Klinger, Y. Nakada, and M.A. Menedez (Eds.), "AT&T Reliability Ma= nual", Van Nostrand Reinhold, 1990)
Applied to the PSTN, the former includes "My call is not dropped durin= g a conversation", while the latter asks for "The phone service i= s ready, i.e., a tone is present, whenever I lift the handset".
For years, Dependability has encompassed these concepts (together wi= th others such as Maintainability) to characterize the good behavior (robustness) of a= system when facing accidental events (design faults, operations errors, hardware failur= es, natural disasters, etc.) , while Security, which includes all intentional actions (attacks, ..= .), is kept apart. This explains the presence, up to now, of two communitie= s working in these two separated subjects.
As (i) unavailability may the consequence of, e.g., software/hardware failu= res OR (D)DoS attacks (ii) Resilience is a fashionable expression* (iii) etc., resilience is us= ed since the last few years to encompass both dependability and security. Best,
Chidung
_______
*: see, e.g., Obama's praise for the resilience of the Indian people (http://articles.latimes.com/2010/nov/06/world/la-fgw-obama-mumbai-20= 101107)

Le 02/12/2013 08:21= , Cao,Zhen a =E9crit :

Good point, Diego.
I checked out the NFV ISG released documents of requirements and<=
/o:p>
terminology, where i could not find 'reliability' but 'resilience'.
-cz
 
On Wed, Nov 27, 2013 at 2:06 AM, Diego R. Lopez <diego@tid.es> wrote:
Hi,
When it comes to the reliability/availability issue I guess providing =
some
(condensed) definition from the NFV REL group would help...=

Be goode,
 
On 26 Nov 2013, at 04:00 , Hidetoshi Yokota wrote:
 
Hi Ning and all,
The proposed PS is a very good starting point covering major issues fo=
r the
goal of VNF pool. One thing that I could add is the synchronization be=
tween
the vNF migration/replacement and routing to make the relevant flows
forwarded to the new location. The challenge is that the VMs/severs in=
 a
pool could be deployed over topologically different networks (in the
physical world) and VNF migration could involve topologically independ=
ent
routing. There are multiple ways to do it, but we should first general=
ize
this issue and specify a common mechanism that may leverage existing o=
nes.
If this is already covered, that's fine. If some additional text is us=
eful,
the following could be a summary:
o Synchronization between vNF migration and flow forwarding, which may=

require topologically independent routing in the physical transport ne=
twork;
There is a discussion about "reliability" and "availabi=
lity" in another
thread and I think this is also an issue in ETSI NFV. We need to defin=
e them
either in this group or NFV to share the same view.
Regards,
--
Hidetoshi Yokota
 
KDDI R&D Laboratories, Inc.
e-mail:yokota@kddilabs.jp=

 
(2013/11/21 18:11), Zongning wrote:
 
Hi,
Please review the below brief version of VNF Pool Problem Statement, a=
nd
feedback with your comments. I hope this text can serve as a base of V=
NF
Pool Charter, by carving out real problems and work items.<=
/pre>

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


A virtualized network function (VNF) (e.g. vFW, vLB) provides the same=



function as the equivalent network function (e.g. FW, LB), but is usua=
lly


instantiated as a cluster of software instances running on general pur=
pose


servers via virtualization platform. In an environment based on VNFs, =
a


network service is typically realized by a chain of VNFs where the ins=
tances


of adjacent VNFs are preferably directly connected.


A VNF chain introduces additional points of failure beyond those inher=
ent in


a single dedicated server, and therefore additional challenges on=



reliability. By reliability, we mean the ability of a VNF chain to con=
tinue


function when having transition or failure within the chain. For examp=
le,


there are more factors such as software failure, server over-utilizati=
on,


instance migration that potentially cause VNF instance transition or


failure. Although a general pooling mechanism can be applied to addres=
s the


reliability of a single VNF, there are still problems when addressing =
the


reliability of a VNF chain, i.e. multiple pools for multiple VNFs. For=



example, how does an instance of VNF#1 know which instance in the pool=
 of


VNF#2 will replace the instance of VNF#2 it connects to? How does an


instance of VNF#1 know the state of instance of VNF#2 that it connects=
 to in


order to enforce policy for reliability like load sharing, switch befo=
re


break? How is the service state of an instance held and accessed for


efficient synchronization with backup instances?


The overall problem space can be further breakdown to the following st=
udy


items:


-          Signalling to =
handle reliability and instance transition


requirements


o   Signalling between VNF pools for transition (e.g. state =
change, scaling,


moving) notification, backup announcement;


o   Service state management (e.g. synchronizing method, sta=
te data format,


location and mechanism to access state data) within VNF pool;


o   Obtaining underlying network information (e.g. ALTO, I2R=
S);


o   Signalling to CMS for instance deployment reflecting rel=
iability


requirements (e.g. distribution of instances on different VMs or<=
/o:p>


hypervisors);


-          Transport char=
acteristics


o   Identify and analyze reliable transport characteristics =
for control


plane traffic;


o   Analysis of transport security characteristics to provid=
e protection


against known threats, and identification of an appropriate trust mode=
l;


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


Thanks.


-Ning


 


--


"Esta vez no fallaremos, Doctor Infierno"


 


Dr Diego R. Lopez


Telefonica I+D


http://people.tid.es/die=
go.lopez/


 


e-mail: diego@tid.es

Tel:    +34 913 129 041


Mobile: +34 682 051 091


-----------------------------------------


 


vnfpool mailing list


vnfpool@ietf.org

https://www.=
ietf.org/mailman/listinfo/vnfpool
--_000_65174429B5AF4C45BD0798810EC48E0A0D38CFEX0MB2lancslocal_-- From zongning@huawei.com Sun Dec 8 18:06:00 2013 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 576861AE1A5 for ; Sun, 8 Dec 2013 18:06:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.901 X-Spam-Level: X-Spam-Status: No, score=-100.901 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 CvQRKBuGzdBS for ; Sun, 8 Dec 2013 18:05:54 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D29591AE1A3 for ; Sun, 8 Dec 2013 18:05:51 -0800 (PST) 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 BBD51625; Mon, 09 Dec 2013 02:05:46 +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.158.1; Mon, 9 Dec 2013 02:05:41 +0000 Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 9 Dec 2013 02:05:43 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Mon, 9 Dec 2013 10:05:30 +0800 From: Zongning To: "King, Daniel" , LAC Chidung Thread-Topic: [vnfpool] VNF Pool Problem Statement Thread-Index: Ac7mmacuBQUiFtBEQ2CEYoAlHpu1YwDduMMAAB+kuIABF0DFAAAFh5wAAEd4ZIAAj75rgAAJEGmAAH9axeA= Date: Mon, 9 Dec 2013 02:05:29 +0000 Message-ID: References: <52940EB0.6040601@kddilabs.jp> <529C5A30.3070000@orange.com> <4A95BA014132FF49AE685FAB4B9F17F645C293E9@dfweml509-mbx.china.huawei.com> <52A1FE77.10405@orange.com> <65174429B5AF4C45BD0798810EC48E0A0D38CF@EX-0-MB2.lancs.local> In-Reply-To: <65174429B5AF4C45BD0798810EC48E0A0D38CF@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.28] Content-Type: multipart/alternative; boundary="_000_B0D29E0424F2DE47A0B36779EC66677925859300nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "vnfpool@ietf.org" , Linda Dunbar Subject: Re: [vnfpool] VNF Pool 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, 09 Dec 2013 02:06:00 -0000 --_000_B0D29E0424F2DE47A0B36779EC66677925859300nkgeml501mbschi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Daniel, I agree this is a fair question to ask, thanks! Please allow me to ask another question ("a flip side of the coin"): do we = have use case to show that the instance in VNF#1 pool needs to know the sta= ndby address of the instance in VNF#2 pool? For example, suppose we have a = vLB instance (vLB-1) talking to a vFW instance (vFW-1) with two standby ins= tances (vFW-2, vFW-3), if vLB-1 need to know the address of vFW-2, vFW-3, o= r not *in any case*? Anyway, I guess this is a good work for co-authors of use case draft. :) -Ning From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of King, Daniel Sent: Saturday, December 07, 2013 5:02 AM To: LAC Chidung Cc: vnfpool@ietf.org; Linda Dunbar Subject: Re: [vnfpool] VNF Pool Problem Statement Hi Chidung, Thanks for using definitions, and providing the example use cases. The serv= ice chaining and non-service chaining examples are good, but could you also= clarify a deployment, and therefore, solution requirements from an operato= r perspective? Is it expected that client service ("FW" in this use case) resilience would= be typically be provided by each VNF pool sharing the same VLAN, with a vi= rtual server using a "fixed IP" address that maps to a cluster of "dynamic = IP addresses" to multiple VMs, with say one VM for hosting a VNF(s)? Spanni= ng tree would run between the VM instances, and VRRP used to provide backup= for the default gateways. This deployment scenario would support the follo= wing: - Load-balancing across VNFs - Fail-over between VNFs - Migration to new VNFs This architecture would also support mixed environments, where existing pro= priety FW hardware and virtual (VM/VNFs) might be used for migration and te= sting. Actually, the same question to the other operators. It would be real= ly good to understand the thinking behind how best to achieve cost-effectiv= e (time and resources) resilience. As a co-author of "draft-xia-vsnpool-man= agement-use-case" I am trying to figure out if "existing" (VRRP, RSPT, et a= l.) mechanisms are capable of providing client service continuity and distr= ibuted resilience, or indeed we need to document a set of generic requireme= nts that our work in vnfpool will need to solve. Br, Dan. From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of LAC Chidung Sent: 06 December 2013 16:43 To: Linda Dunbar; vnfpool@ietf.org Subject: Re: [vnfpool] VNF Pool Problem Statement Hi Linda, Please correct the following if I'm wrong. Let's define: VNF =3D one type of function. Case 1: no service chaining, e.g., a firewall provides the network service Let's state that 3 firewalls are needed, i.e., 3 instances of the VNF "FW". "VNFs have higher chance to fail due to lack of built-in redundancy" combin= ed with the use of "vnfpool" means: 1) The 3 FW instances are deployed neither in active/active, nor in active/= standby mode, i.e., there are only 3 instances, and not 3 active, and 3 sta= ndby. 2) But this solution is not a trusted one because of "server failure, serve= r over-utilized, or software failure, etc.". 3) Assuming that the load of each (FW) instance is less than 60%, one can g= et HA for this system by using the 3 instances in a pool architecture (base= d on an efficient load balancing mechanism). 4) In this case, the failure of one instance is acceptable because its load= will be shared by the two remaining instances. Case 2: service chaining, e.g., VNF1 and VNF2 are needed in order to provid= e the network service (for instance, a kid requesting a Web page with the u= se of a smartphone -> "parental control" (VNF1) checks the URL, followed by= "header enrichment" (VNF2) which adds the user ID in the media flow) Lets' state that we have 3 instances of VNF1 and 3 instances of VNF2. If we= apply the same reasoning (and hypotheses) as above, we will have a 1st poo= l made up of 3 instances of VNF1, and a 2nd pool made up of 3 instances of = VNF2. The HA of this system is guaranteed if: (i) 1 instance of VNF1 fails,= (ii) 1 instance of VNF2 fails, (iii) 1 instance of VNF2 fails and 1 instan= ce of VNF2 fails. Best, Chidung Le 03/12/2013 21:06, Linda Dunbar a =E9crit : Chidung, Thanks for the quote. Based on your quote, the goal of "vnfpool" should be about to achieve "high= availability" of service function chaining while individual service functi= on instances are NOT reliable. As stated in the problem statement, the vir= tualized network functions have higher chance to fail due to lack of built-= in redundancy, server failure, server over-utilized, or software failure, e= tc. Linda From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of LAC Chidung Sent: Monday, December 02, 2013 4:00 AM To: vnfpool@ietf.org Subject: Re: [vnfpool] VNF Pool Problem Statement Hi all, Reliability is the ability of an item to perform a required function under = stated conditions for a stated period of time, while Availability is a meas= ure of the degree to which an item is in an operable state when called upon= to perform. (D.J. Klinger, Y. Nakada, and M.A. Menedez (Eds.), "AT&T Relia= bility Manual", Van Nostrand Reinhold, 1990) Applied to the PSTN, the former includes "My call is not dropped during a c= onversation", while the latter asks for "The phone service is ready, i.e., = a tone is present, whenever I lift the handset". For years, Dependability has encompassed these concepts (together with othe= rs such as Maintainability) to characterize the good behavior (robustness) = of a system when facing accidental events (design faults, operations errors= , hardware failures, natural disasters, etc.) , while Security, which inclu= des all intentional actions (attacks, ...), is kept apart. This explains th= e presence, up to now, of two communities working in these two separated su= bjects. As (i) unavailability may the consequence of, e.g., software/hardware failu= res OR (D)DoS attacks (ii) Resilience is a fashionable expression* (iii) et= c., resilience is used since the last few years to encompass both dependabi= lity and security. Best, Chidung _______ *: see, e.g., Obama's praise for the resilience of the Indian people (http:= //articles.latimes.com/2010/nov/06/world/la-fgw-obama-mumbai-20101107) Le 02/12/2013 08:21, Cao,Zhen a =E9crit : Good point, Diego. I checked out the NFV ISG released documents of requirements and terminology, where i could not find 'reliability' but 'resilience'. -cz On Wed, Nov 27, 2013 at 2:06 AM, Diego R. Lopez wrote: Hi, When it comes to the reliability/availability issue I guess providing some (condensed) definition from the NFV REL group would help... Be goode, On 26 Nov 2013, at 04:00 , Hidetoshi Yokota wrote: Hi Ning and all, The proposed PS is a very good starting point covering major issues for the goal of VNF pool. One thing that I could add is the synchronization between the vNF migration/replacement and routing to make the relevant flows forwarded to the new location. The challenge is that the VMs/severs in a pool could be deployed over topologically different networks (in the physical world) and VNF migration could involve topologically independent routing. There are multiple ways to do it, but we should first generalize this issue and specify a common mechanism that may leverage existing ones. If this is already covered, that's fine. If some additional text is useful, the following could be a summary: o Synchronization between vNF migration and flow forwarding, which may require topologically independent routing in the physical transport network= ; There is a discussion about "reliability" and "availability" in another thread and I think this is also an issue in ETSI NFV. We need to define the= m either in this group or NFV to share the same view. Regards, -- Hidetoshi Yokota KDDI R&D Laboratories, Inc. e-mail:yokota@kddilabs.jp (2013/11/21 18:11), Zongning wrote: Hi, Please review the below brief version of VNF Pool Problem Statement, and feedback with your comments. I hope this text can serve as a base of VNF Pool Charter, by carving out real problems and work items. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D A virtualized network function (VNF) (e.g. vFW, vLB) provides the same function as the equivalent network function (e.g. FW, LB), but is usually instantiated as a cluster of software instances running on general purpose servers via virtualization platform. In an environment based on VNFs, a network service is typically realized by a chain of VNFs where the instance= s of adjacent VNFs are preferably directly connected. A VNF chain introduces additional points of failure beyond those inherent i= n a single dedicated server, and therefore additional challenges on reliability. By reliability, we mean the ability of a VNF chain to continue function when having transition or failure within the chain. For example, there are more factors such as software failure, server over-utilization, instance migration that potentially cause VNF instance transition or failure. Although a general pooling mechanism can be applied to address the reliability of a single VNF, there are still problems when addressing the reliability of a VNF chain, i.e. multiple pools for multiple VNFs. For example, how does an instance of VNF#1 know which instance in the pool of VNF#2 will replace the instance of VNF#2 it connects to? How does an instance of VNF#1 know the state of instance of VNF#2 that it connects to i= n order to enforce policy for reliability like load sharing, switch before break? How is the service state of an instance held and accessed for efficient synchronization with backup instances? The overall problem space can be further breakdown to the following study items: - Signalling to handle reliability and instance transition requirements o Signalling between VNF pools for transition (e.g. state change, scaling= , moving) notification, backup announcement; o Service state management (e.g. synchronizing method, state data format, location and mechanism to access state data) within VNF pool; o Obtaining underlying network information (e.g. ALTO, I2RS); o Signalling to CMS for instance deployment reflecting reliability requirements (e.g. distribution of instances on different VMs or hypervisors); - Transport characteristics o Identify and analyze reliable transport characteristics for control plane traffic; o Analysis of transport security characteristics to provide protection against known threats, and identification of an appropriate trust model; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Thanks. -Ning -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego@tid.es Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------------- vnfpool mailing list vnfpool@ietf.org https://www.ietf.org/mailman/listinfo/vnfpool --_000_B0D29E0424F2DE47A0B36779EC66677925859300nkgeml501mbschi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi, Daniel= ,

 = ;

I agree th= is is a fair question to ask, thanks!

Please all= ow me to ask another question (“a flip side of the coin”): do w= e have use case to show that the instance in VNF#1 pool needs to know the standby address of the instance in VNF#2 pool? For example, suppose we= have a vLB instance (vLB-1) talking to a vFW instance (vFW-1) with two sta= ndby instances (vFW-2, vFW-3), if vLB-1 need to know the address of vFW-2, = vFW-3, or not *in any case*?

Anyway, I = guess this is a good work for co-authors of use case draft. J

 = ;

-Ning=

 = ;

From:= vnfpool [mailto:vnf= pool-bounces@ietf.org] On Behalf Of King, Daniel
Sent: Saturday, December 07, 2013 5:02 AM
To: LAC Chidung
Cc: vnfpool@ietf.org; Linda Dunbar
Subject: Re: [vnfpool] VNF Pool Problem Statement<= /p>

 

Hi Chidung,

 = ;

Thanks for= using definitions, and providing the example use cases. The service chaini= ng and non-service chaining examples are good, but could you also clarify a deployment, and therefore, solution requirements from an op= erator perspective?

 = ;

Is it expe= cted that client service (“FW” in this use case) resilience wou= ld be typically be provided by each VNF pool sharing the same VLAN, with a virtual server using a “fixed IP” address that maps to a clu= ster of “dynamic IP addresses” to multiple VMs, with say one VM= for hosting a VNF(s)? Spanning tree would run between the VM instances, an= d VRRP used to provide backup for the default gateways. This deployment scenario would support the following:

 = ;

- Load-bal= ancing across VNFs

- Fail-ove= r between VNFs

- Migratio= n to new VNFs

 = ;

This archi= tecture would also support mixed environments, where existing propriety FW = hardware and virtual (VM/VNFs) might be used for migration and testing. Actually, the same question to the other operators. It would = be really good to understand the thinking behind how best to achieve cost-e= ffective (time and resources) resilience. As a co-author of “draft-xi= a-vsnpool-management-use-case” I am trying to figure out if “existing” (VRRP, RSPT, et al.) mechanisms ar= e capable of providing client service continuity and distributed resilience= , or indeed we need to document a set of generic requirements that our work= in vnfpool will need to solve.

 = ;

Br, Dan.

 

From= : vnfpool [mailto:v= nfpool-bounces@ietf.org] On Behalf Of LAC Chidung
Sent: 06 December 2013 16:43
To: Linda Dunbar; vnfpool@ietf.org
Subject: Re: [vnfpool] VNF Pool Problem Statement<= /p>

 

Hi Linda,
Please correct the following if I'm wrong.
Let's define: VNF =3D one type of function.
Case 1: no service chaining, e.g., a firewall provides the network s= ervice
Let's state that 3 firewalls are needed, i.e., 3 instances of the VNF "= ;FW".
"VNFs have higher chance to fail due to lack of built-in redunda= ncy" combined with the use of "vnfpool"= ; means:
1) The 3 FW instances are deployed neither in active/active, nor in active/= standby mode, i.e., there are only 3 instances, and not 3 active, and 3 sta= ndby.
2) But this solution is not a trusted one because of "server fai= lure, server over-utilized, or software failure, etc.".
3) Assuming that the load of each (FW) instance is less than 60%, one can g= et HA for this system by using the 3 instances in a pool architecture (base= d on an efficient load balancing mechanism).
4) In this case, the failure of one instance is acceptable because its load= will be shared by the two remaining instances.
Case 2: service chaining, e.g., VNF1 and VNF2 are needed in order to= provide the network service (for instance, a kid requesting a Web page wit= h the use of a smartphone -> "parental control" (VNF1) checks = the URL, followed by "header enrichment" (VNF2) which adds the user ID in the media flow)
Lets' state that we have 3 instances of VNF1 and 3 instances of VNF2. If we= apply the same reasoning (and hypotheses) as above, we will have a 1st poo= l made up of 3 instances of VNF1, and a 2nd pool made up of 3 instances of = VNF2. The HA of this system is guaranteed if: (i) 1 instance of VNF1 fails, (ii) 1 instance of VNF2 fails, (iii) 1 i= nstance of VNF2 fails and 1 instance of VNF2 fails.
Best,
Chidung

Le 0= 3/12/2013 21:06, Linda Dunbar a =E9crit :<= o:p>

Chidung,

Thanks for= the quote.

Based on y= our quote, the goal of “vnfpool” should be about to achieve = 220;high availability” of service function chaining while individual = service function instances are NOT reliable.  As stated in the problem statem= ent, the virtualized network functions have higher chance to fail due to la= ck of built-in redundancy, server failure, server over-utilized, or softwar= e failure, etc.

Linda

 

From:= vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of LAC Chidung
Sent: Monday, December 02, 2013 4:00 AM
To: vnfpool@ietf.org
Subject: Re: [vnfpool] VNF Pool Problem Statement

 

Hi all,
Reliability is the ability of an item to perform a required function und= er stated conditions for a stated period of time, while Availability= is a measure of the degree to which an item is in an operable state when c= alled upon to perform. (D.J. Klinger, Y. Nakada, and M.A. Menedez (Eds.), "AT&T Reliability Ma= nual", Van Nostrand Reinhold, 1990)
Applied to the PSTN, the former includes "My call is not dropped durin= g a conversation", while the latter asks for "The phone service i= s ready, i.e., a tone is present, whenever I lift the handset".
For years, Dependability has encompassed these concepts (together wi= th others such as Maintainability) to characterize the good behavior (robustness) of a= system when facing accidental events (design faults, operations errors, hardware failur= es, natural disasters, etc.) , while Security, which includes all intentional actions (attacks, ..= .), is kept apart. This explains the presence, up to now, of two communitie= s working in these two separated subjects.
As (i) unavailability may the consequence of, e.g., software/hardware failu= res OR (D)DoS attacks (ii) Resilience is a fashionable expression* (iii) etc., resilience is us= ed since the last few years to encompass both dependability and security. Best,
Chidung
_______
*: see, e.g., Obama's praise for the resilience of the Indian people (http://articles.latimes.com/2010/nov/06/world/la-fgw-obama-mumbai-20= 101107)

Le 0= 2/12/2013 08:21, Cao,Zhen a =E9crit := 

Good point, Diego.
I checked out the NFV ISG released documents of r=
equirements and
terminology, where i could not find 'reliability'=
 but 'resilience'.
-cz
 
On Wed, Nov 27, 2013 at 2:06 AM, Diego R. Lopez <=
a href=3D"mailto:diego@tid.es"><diego@tid.es> wrote:
Hi,
When it comes to the reliability/availability iss=
ue I guess providing some
(condensed) definition from the NFV REL group wou=
ld help...
Be goode,
 
On 26 Nov 2013, at 04:00 , Hidetoshi Yokota wrote=
:
 
Hi Ning and all,
The proposed PS is a very good starting point cov=
ering major issues for the
goal of VNF pool. One thing that I could add is t=
he synchronization between
the vNF migration/replacement and routing to make=
 the relevant flows
forwarded to the new location. The challenge is t=
hat the VMs/severs in a
pool could be deployed over topologically differe=
nt networks (in the
physical world) and VNF migration could involve t=
opologically independent
routing. There are multiple ways to do it, but we=
 should first generalize
this issue and specify a common mechanism that ma=
y leverage existing ones.
If this is already covered, that's fine. If some =
additional text is useful,
the following could be a summary:
o Synchronization between vNF migration and flow =
forwarding, which may
require topologically independent routing in the =
physical transport network;
There is a discussion about "reliability&quo=
t; and "availability" in another
thread and I think this is also an issue in ETSI =
NFV. We need to define them
either in this group or NFV to share the same vie=
w.
Regards,
--
Hidetoshi Yokota
 
KDDI R&D Laboratories, Inc.=

e-ma=
il:yokota@kddilabs.jp
 
(2013/11/21 18:11), Zongning wrote:
 
Hi,
Please review the below brief version of VNF Pool=
 Problem Statement, and
feedback with your comments. I hope this text can=
 serve as a base of VNF
Pool Charter, by carving out real problems and wo=
rk items.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

A virtualized network function (VNF) (e.g. vFW, v=
LB) provides the same
function as the equivalent network function (e.g.=
 FW, LB), but is usually
instantiated as a cluster of software instances r=
unning on general purpose
servers via virtualization platform. In an enviro=
nment based on VNFs, a
network service is typically realized by a chain =
of VNFs where the instances
of adjacent VNFs are preferably directly connecte=
d.
A VNF chain introduces additional points of failu=
re beyond those inherent in
a single dedicated server, and therefore addition=
al challenges on
reliability. By reliability, we mean the ability =
of a VNF chain to continue
function when having transition or failure within=
 the chain. For example,
there are more factors such as software failure, =
server over-utilization,
instance migration that potentially cause VNF ins=
tance transition or
failure. Although a general pooling mechanism can=
 be applied to address the
reliability of a single VNF, there are still prob=
lems when addressing the
reliability of a VNF chain, i.e. multiple pools f=
or multiple VNFs. For
example, how does an instance of VNF#1 know which=
 instance in the pool of
VNF#2 will replace the instance of VNF#2 it conne=
cts to? How does an
instance of VNF#1 know the state of instance of V=
NF#2 that it connects to in
order to enforce policy for reliability like load=
 sharing, switch before
break? How is the service state of an instance he=
ld and accessed for
efficient synchronization with backup instances?<=
o:p>
The overall problem space can be further breakdow=
n to the following study
items:
-        =
  Signalling to handle reliability and instance transition<=
/span>
requirements
o   Signalling between VNF pools for tr=
ansition (e.g. state change, scaling,
moving) notification, backup announcement;
o   Service state management (e.g. sync=
hronizing method, state data format,
location and mechanism to access state data) with=
in VNF pool;
o   Obtaining underlying network inform=
ation (e.g. ALTO, I2RS);
o   Signalling to CMS for instance depl=
oyment reflecting reliability
requirements (e.g. distribution of instances on d=
ifferent VMs or
hypervisors);
-        =
  Transport characteristics
o   Identify and analyze reliable trans=
port characteristics for control
plane traffic;
o   Analysis of transport security char=
acteristics to provide protection
against known threats, and identification of an a=
ppropriate trust model;
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

Thanks.
-Ning
 
--
"Esta vez no fallaremos, Doctor Infierno&quo=
t;
 
Dr Diego R. Lopez
Telefonica I+D
htt=
p://people.tid.es/diego.lopez/
 
e-mail: diego@tid=
.es
Tel:    +34 913 129 041
Mobile: +34 682 051 091

-----------------------------------------


 


vnfpool mailing list


vnfpool@ietf.=
org


https://www.ietf.org/mailman/listinfo/vnfpool
--_000_B0D29E0424F2DE47A0B36779EC66677925859300nkgeml501mbschi_-- From bill.wu@huawei.com Sun Dec 8 18:18:42 2013 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 2EA981AE1AF for ; Sun, 8 Dec 2013 18:18:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 h5QfjlaiRUm5 for ; Sun, 8 Dec 2013 18:18:40 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5153D1AE17D for ; Sun, 8 Dec 2013 18:18:39 -0800 (PST) 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 BBD52299; Mon, 09 Dec 2013 02:18:34 +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; Mon, 9 Dec 2013 02:18:30 +0000 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 9 Dec 2013 02:18:33 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Mon, 9 Dec 2013 10:18:29 +0800 From: Qin Wu To: LAC Chidung , "vnfpool@ietf.org" Thread-Topic: [vnfpool] Question about addressing in pools Thread-Index: AQHO7VD7cSDSc5yINUOiHv7ulkjXlZpAIgmAgAI4NQCAAAQjgIAA38tQgAOuIwCABEF4MA== Date: Mon, 9 Dec 2013 02:18:29 +0000 Message-ID: References: <529912BF.4010307@nomountain.net> <701E4DC3-754C-4308-B507-D85BCAB9B2D6@tid.es> <4A95BA014132FF49AE685FAB4B9F17F645C2936D@dfweml509-mbx.china.huawei.com> <529E33BF.50002@gmail.com> <52A205CC.8060002@orange.com> In-Reply-To: <52A205CC.8060002@orange.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.149] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA43C6AA87nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [vnfpool] Question about addressing in pools 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, 09 Dec 2013 02:18:42 -0000 --_000_B8F9A780D330094D99AF023C5877DABA43C6AA87nkgeml501mbschi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If Pool manger can be compared to VNF manager, then the standards interface= we are really dealing with is the interface between EMS and VNF manager? Not sure my understanding is correct. Also I am wondering whether the interface between EMS and VNF manager is ma= nage plane interface or control plane interface? Regards! -Qin From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of LAC Chidung Sent: Saturday, December 07, 2013 1:14 AM To: vnfpool@ietf.org Subject: Re: [vnfpool] Question about addressing in pools "Who manage vNF? Hypervisor, controller or orchestrator, or just hosted sys= tem? " If we refer to http://docbox.etsi.org/ISG/NFV/Open/Published/gs_NFV002v0101= 01p.pdf Figure 4 suggests that (of course, I may be wrong ...): - each VNF has its own element management system (EMS); different VNFs from= different vendors may be used to provide a certain network service - the VNF Managers actions include (i) collecting data (OAM, etc.) from the= VNFs and from the virtual infrastructure; (ii) providing scalability ('out= ' to create a new VM, or 'in' to suppress a VM - a VM being an instance of = a VNF) - an unique orchestrator controlling the VNF Managers in a data center (clo= ud) environment, e.g., OpenStack Best, Chidung PS: the hypervisor, e.g., KVM, is represented in this figure by the "Virtua= lisation Layer" Le 04/12/2013 02:36, Qin Wu a =E9crit : I think vNF#2 failover and replaced by VNF#1 means vNF#1 and vNF#2 has the = same functionality. If it is this case, why vNF#2 and vNF#1 with the same functionality should = be managed by two different pool managers rather than One common pool manager? Even vNF#2 and vNF#1 has different functionality or provide different servi= ce, can vNF#2 and vNF#1 be managed by the common pool manager? If we place the pool manger in NFV architecture specified by ETSI NFV? What= the position of pool manager in such NFV architecture? Who manage vNF? Hyp= ervisor, controller or orchestrator, or just hosted system? I agree with Melinda the endpoint doesn't need to know whether he is talkin= g to vNF#1 or vNF#2. What he needs to do is Using something like name/address resolution mechanism to get the new addre= ss of backup vNF#2 when vNF#2 is down. Regards! -Qin -----Original Message----- From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of Melinda Shore Sent: Wednesday, December 04, 2013 3:41 AM To: vnfpool@ietf.org Subject: Re: [vnfpool] Question about addressing in pools On 12/3/13 10:25 AM, Linda Dunbar wrote: I think that it is the "VNF#2 pool manager" that will determine which instance in VNF#2 will be fail-over one, and is responsible for passing this VNF#2's failover instance address to "VNF#1 pool manager". I think it might be a little early to assume that. It's generally the case in HA scenarios that when there's a failover clients/endpoints do not know that they are talking to what a different box (or virtual box). In rserpool endpoints find and access services through ENRP - that is to say, unmodified clients can't take advantage of the pooling mechanism. I think we need to be clear about that. Melinda _______________________________________________ vnfpool mailing list vnfpool@ietf.org https://www.ietf.org/mailman/listinfo/vnfpool --_000_B8F9A780D330094D99AF023C5877DABA43C6AA87nkgeml501mbschi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

If Pool manger can be com= pared to VNF manager, then the standards interface we are really dealing wi= th is the interface between EMS and VNF manager?

Not sure my understanding= is correct.

Also I am wondering wheth= er the interface between EMS and VNF manager is manage plane interface or c= ontrol plane interface?

 <= /p>

Regards!

-Qin

From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of LAC Chidung
Sent: Saturday, December 07, 2013 1:14 AM
To: vnfpool@ietf.org
Subject: Re: [vnfpool] Question about addressing in pools=

 

"Who manage vNF? Hypervisor, controller or orchestrator= , or just hosted system? "
If we refer to http://docbox.etsi.org/ISG/NFV/Open/Published/gs_NFV002v010101p.pdf
Figure 4 suggests that (of course, I may be wrong ...):
- each VNF has its own element management system (EMS); different VNFs from= different vendors may be used to provide a certain network service
- the VNF Managers actions include (i) collecting data (OAM, etc.) from the= VNFs and from the virtual infrastructure; (ii) providing scalability ('out= ' to create a new VM, or 'in' to suppress a VM - a VM being an instance of = a VNF)
- an unique orchestrator controlling the VNF Managers in a data center (clo= ud) environment, e.g., OpenStack
Best,
Chidung
PS: the hypervisor, e.g., KVM, is represen= ted in this figure by the "Virtualisation Layer"

Le 04/12/2013 02:36= , Qin Wu a =E9crit :

I think vNF#2 failover and replaced by VNF#1 means vNF#1 and vNF#2 has=
 the same functionality.
If it is this case, why vNF#2 and vNF#1 with the same functionality sh=
ould be managed by two different pool managers rather than
One common pool manager?
Even vNF#2 and vNF#1 has different functionality or provide different =
service, can vNF#2 and vNF#1 be managed by the common pool manager?
If we place the pool manger in NFV architecture specified by ETSI NFV?=
 What the position of pool manager in such NFV architecture? Who manage vNF=
? Hypervisor, controller or orchestrator, or just hosted system?=

I agree with Melinda the endpoint doesn't need to know whether he is t=
alking to vNF#1 or vNF#2. What he needs to do is
Using something like name/address resolution mechanism to get the new =
address of backup vNF#2 when vNF#2 is down.
Regards!
-Qin
 
-----Original Message-----
From: vnfpool [mailto:vnfp=
ool-bounces@ietf.org] On Behalf Of Melinda Shore
Sent: Wednesday, December 04, 2013 3:41 AM
To: vnfpool@ietf.org
Subject: Re: [vnfpool] Question about addressing in pools

 


On 12/3/13 10:25 AM, Linda Dunbar wrote:




I think that it is the "VNF#2 pool manager" that will determ=
ine which


instance in VNF#2 will be fail-over one, and is responsible for


passing this VNF#2's failover instance address to "VNF#1 pool


manager".




I think it might be a little early to assume that.  It's generall=
y


the case in HA scenarios that when there's a failover clients/endpoint=
s


do not know that they are talking to what a different box (or virtual<=
o:p>


box).  In rserpool endpoints find and access services through


ENRP - that is to say, unmodified clients can't take advantage


of the pooling mechanism.  I think we need to be clear about=



that.


Melinda


_______________________________________________


vnfpool mailing list


vnfpool@ietf.org

https://www.=
ietf.org/mailman/listinfo/vnfpool
--_000_B8F9A780D330094D99AF023C5877DABA43C6AA87nkgeml501mbschi_-- From melinda.shore@nomountain.net Sun Dec 8 18:26:15 2013 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 709F71AE1B8 for ; Sun, 8 Dec 2013 18:26:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] 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 j1XfxmKBTKWv for ; Sun, 8 Dec 2013 18:26:14 -0800 (PST) Received: from homiemail-a86.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 452A61AE1B2 for ; Sun, 8 Dec 2013 18:26:14 -0800 (PST) Received: from homiemail-a86.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTP id A6C3D36006D for ; Sun, 8 Dec 2013 18:26:09 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=nomountain.net; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=nomountain.net ; b=aDJ1tbwk/3J0cNF1IGk5dMBebfquGAcVvsX9WrZ2ThpTHQZk5aa+Gko/Qydw zoz1xJWH8knvDP7YYo8CNIckCOT6Kr8OLI4ZJRkXn3jyIc0kfdif0yjTor3QuGMu zFqw7mXb2OxgkdFEuRXRVcLQaFv/PYl/T2wWsuRNZpb/XuA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=nomountain.net; h= message-id:date:from:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; s= nomountain.net; bh=EZUyTBhZprm8MHw8ozvYpgP7a8E=; b=QSiqT5sCWOO3K BfAvmsNDmWqOy5XGONobOtIOpIDBapjG8TNu2cxAX66RLzAU9EccTd6cfq4xH9OT SXan8e10zBgk/YWD+Dnz7lhWXwrgg5YHJi6H309z9ocdt1KHvEHR/dAmPRj4htpp WaoA40E8RTfsm7GBUITxIZBFAnaSBs= Received: from spandex.local (216-67-63-189-rb3.nwc.dsl.dynamic.acsalaska.net [216.67.63.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: melinda.shore@nomountain.net) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTPSA id 4EF8436005C for ; Sun, 8 Dec 2013 18:26:09 -0800 (PST) Message-ID: <52A52A3F.4060503@nomountain.net> Date: Sun, 08 Dec 2013 17:26:07 -0900 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: <52940EB0.6040601@kddilabs.jp> <529C5A30.3070000@orange.com> <4A95BA014132FF49AE685FAB4B9F17F645C293E9@dfweml509-mbx.china.huawei.com> <52A1FE77.10405@orange.com> <65174429B5AF4C45BD0798810EC48E0A0D38CF@EX-0-MB2.lancs.local> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [vnfpool] VNF Pool 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, 09 Dec 2013 02:26:15 -0000 I think Daniel is asking exactly the right questions. But to back up a bit, I've been thinking about this over the weekend and realized that the scenario is actually simpler than I'd been considering. If the VNF instances are pooled along the general lines of something like rserpool, it is not the case that an external client will need to be modified. The only elements which would need to be able to "talk" the pooling protocol are already participating - they'd be the pool manager and whatever service chain management function is being used, the pool members, and adjacent pools. So I think we're in good shape there; we could probably use some better text around this to make it clearer. Melinda From linda.dunbar@huawei.com Mon Dec 9 08:12:33 2013 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 9E9681ADF62 for ; Mon, 9 Dec 2013 08:12:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 PtaDyuIrAunY for ; Mon, 9 Dec 2013 08:12:28 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 34A811ADF55 for ; Mon, 9 Dec 2013 08:12:27 -0800 (PST) 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 BBE26988; Mon, 09 Dec 2013 16:12:21 +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; Mon, 9 Dec 2013 16:11:46 +0000 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 9 Dec 2013 16:11:50 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.24]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.03.0158.001; Mon, 9 Dec 2013 08:11:45 -0800 From: Linda Dunbar To: LAC Chidung , "vnfpool@ietf.org" Thread-Topic: [vnfpool] VNF Pool Problem Statement Thread-Index: Ac7mmacuBQUiFtBEQ2CEYoAlHpu1YwD/P9UAAB+kuIABF0DFAAAFh5wAADY6ElAAoPy9gACEuJvA Date: Mon, 9 Dec 2013 16:11:44 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645C2DD5C@dfweml509-mbx.china.huawei.com> References: <52940EB0.6040601@kddilabs.jp> <529C5A30.3070000@orange.com> <4A95BA014132FF49AE685FAB4B9F17F645C293E9@dfweml509-mbx.china.huawei.com> <52A1FE77.10405@orange.com> In-Reply-To: <52A1FE77.10405@orange.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.145.7] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645C2DD5Cdfweml509mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [vnfpool] VNF Pool 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, 09 Dec 2013 16:12:33 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645C2DD5Cdfweml509mbxchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Childung, What you described is good beginning. I add the remaining to your service c= hain (see the insert below) From: LAC Chidung [mailto:chidung.lac@orange.com] Sent: Friday, December 06, 2013 10:43 AM To: Linda Dunbar; vnfpool@ietf.org Subject: Re: [vnfpool] VNF Pool Problem Statement Hi Linda, Please correct the following if I'm wrong. Let's define: VNF =3D one type of function. Case 1: no service chaining, e.g., a firewall provides the network service Let's state that 3 firewalls are needed, i.e., 3 instances of the VNF "FW". "VNFs have higher chance to fail due to lack of built-in redundancy" combin= ed with the use of "vnfpool" means: 1) The 3 FW instances are deployed neither in active/active, nor in active/= standby mode, i.e., there are only 3 instances, and not 3 active, and 3 sta= ndby. 2) But this solution is not a trusted one because of "server failure, serve= r over-utilized, or software failure, etc.". 3) Assuming that the load of each (FW) instance is less than 60%, one can g= et HA for this system by using the 3 instances in a pool architecture (base= d on an efficient load balancing mechanism). 4) In this case, the failure of one instance is acceptable because its load= will be shared by the two remaining instances. Case 2: service chaining, e.g., VNF1 and VNF2 are needed in order to provid= e the network service (for instance, a kid requesting a Web page with the u= se of a smartphone -> "parental control" (VNF1) checks the URL, followed by= "header enrichment" (VNF2) which adds the user ID in the media flow) Lets' state that we have 3 instances of VNF1 and 3 instances of VNF2. If we= apply the same reasoning (and hypotheses) as above, we will have a 1st poo= l made up of 3 instances of VNF1, and a 2nd pool made up of 3 instances of = VNF2. The HA of this system is guaranteed if: (i) 1 instance of VNF1 fails, [Linda] VNFpool is to develop protocol for the replacement instance of VNF1= to be chained to the instance of VNF2 when the first instance of VNF1 fai= ls. (ii) 1 instance of VNF2 fails, [Linda] VNFpool is to develop protocol for the instance of VNF1 to be chain= ed to the replacement instance of VNF2 when the first instance of VNF2 fai= ls. (iii) 1 instance of VNF1 fails and 1 instance of VNF2 fails. [Linda] Then the VNFpool protocol is responsible for chaining the replaceme= nt of VNF1 to the replacement of VNF2. Best, Chidung Le 03/12/2013 21:06, Linda Dunbar a =E9crit : Chidung, Thanks for the quote. Based on your quote, the goal of "vnfpool" should be about to achieve "high= availability" of service function chaining while individual service functi= on instances are NOT reliable. As stated in the problem statement, the vir= tualized network functions have higher chance to fail due to lack of built-= in redundancy, server failure, server over-utilized, or software failure, e= tc. Linda From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of LAC Chidung Sent: Monday, December 02, 2013 4:00 AM To: vnfpool@ietf.org Subject: Re: [vnfpool] VNF Pool Problem Statement Hi all, Reliability is the ability of an item to perform a required function under = stated conditions for a stated period of time, while Availability is a meas= ure of the degree to which an item is in an operable state when called upon= to perform. (D.J. Klinger, Y. Nakada, and M.A. Menedez (Eds.), "AT&T Relia= bility Manual", Van Nostrand Reinhold, 1990) Applied to the PSTN, the former includes "My call is not dropped during a c= onversation", while the latter asks for "The phone service is ready, i.e., = a tone is present, whenever I lift the handset". For years, Dependability has encompassed these concepts (together with othe= rs such as Maintainability) to characterize the good behavior (robustness) = of a system when facing accidental events (design faults, operations errors= , hardware failures, natural disasters, etc.) , while Security, which inclu= des all intentional actions (attacks, ...), is kept apart. This explains th= e presence, up to now, of two communities working in these two separated su= bjects. As (i) unavailability may the consequence of, e.g., software/hardware failu= res OR (D)DoS attacks (ii) Resilience is a fashionable expression* (iii) et= c., resilience is used since the last few years to encompass both dependabi= lity and security. Best, Chidung _______ *: see, e.g., Obama's praise for the resilience of the Indian people (http:= //articles.latimes.com/2010/nov/06/world/la-fgw-obama-mumbai-20101107) Le 02/12/2013 08:21, Cao,Zhen a =E9crit : Good point, Diego. I checked out the NFV ISG released documents of requirements and terminology, where i could not find 'reliability' but 'resilience'. -cz On Wed, Nov 27, 2013 at 2:06 AM, Diego R. Lopez wrote: Hi, When it comes to the reliability/availability issue I guess providing some (condensed) definition from the NFV REL group would help... Be goode, On 26 Nov 2013, at 04:00 , Hidetoshi Yokota wrote: Hi Ning and all, The proposed PS is a very good starting point covering major issues for the goal of VNF pool. One thing that I could add is the synchronization between the vNF migration/replacement and routing to make the relevant flows forwarded to the new location. The challenge is that the VMs/severs in a pool could be deployed over topologically different networks (in the physical world) and VNF migration could involve topologically independent routing. There are multiple ways to do it, but we should first generalize this issue and specify a common mechanism that may leverage existing ones. If this is already covered, that's fine. If some additional text is useful, the following could be a summary: o Synchronization between vNF migration and flow forwarding, which may require topologically independent routing in the physical transport network= ; There is a discussion about "reliability" and "availability" in another thread and I think this is also an issue in ETSI NFV. We need to define the= m either in this group or NFV to share the same view. Regards, -- Hidetoshi Yokota KDDI R&D Laboratories, Inc. e-mail:yokota@kddilabs.jp (2013/11/21 18:11), Zongning wrote: Hi, Please review the below brief version of VNF Pool Problem Statement, and feedback with your comments. I hope this text can serve as a base of VNF Pool Charter, by carving out real problems and work items. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D A virtualized network function (VNF) (e.g. vFW, vLB) provides the same function as the equivalent network function (e.g. FW, LB), but is usually instantiated as a cluster of software instances running on general purpose servers via virtualization platform. In an environment based on VNFs, a network service is typically realized by a chain of VNFs where the instance= s of adjacent VNFs are preferably directly connected. A VNF chain introduces additional points of failure beyond those inherent i= n a single dedicated server, and therefore additional challenges on reliability. By reliability, we mean the ability of a VNF chain to continue function when having transition or failure within the chain. For example, there are more factors such as software failure, server over-utilization, instance migration that potentially cause VNF instance transition or failure. Although a general pooling mechanism can be applied to address the reliability of a single VNF, there are still problems when addressing the reliability of a VNF chain, i.e. multiple pools for multiple VNFs. For example, how does an instance of VNF#1 know which instance in the pool of VNF#2 will replace the instance of VNF#2 it connects to? How does an instance of VNF#1 know the state of instance of VNF#2 that it connects to i= n order to enforce policy for reliability like load sharing, switch before break? How is the service state of an instance held and accessed for efficient synchronization with backup instances? The overall problem space can be further breakdown to the following study items: - Signalling to handle reliability and instance transition requirements o Signalling between VNF pools for transition (e.g. state change, scaling= , moving) notification, backup announcement; o Service state management (e.g. synchronizing method, state data format, location and mechanism to access state data) within VNF pool; o Obtaining underlying network information (e.g. ALTO, I2RS); o Signalling to CMS for instance deployment reflecting reliability requirements (e.g. distribution of instances on different VMs or hypervisors); - Transport characteristics o Identify and analyze reliable transport characteristics for control plane traffic; o Analysis of transport security characteristics to provide protection against known threats, and identification of an appropriate trust model; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Thanks. -Ning -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego@tid.es Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------------- vnfpool mailing list vnfpool@ietf.org https://www.ietf.org/mailman/listinfo/vnfpool --_000_4A95BA014132FF49AE685FAB4B9F17F645C2DD5Cdfweml509mbxchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Childung,

 <= /p>

What you described is goo= d beginning. I add the remaining to your service chain (see the insert belo= w)

 <= /p>

 <= /p>

From: LAC Chidung [mailto:chidung.lac@orange.com]
Sent: Friday, December 06, 2013 10:43 AM
To: Linda Dunbar; vnfpool@ietf.org
Subject: Re: [vnfpool] VNF Pool Problem Statement<= /p>

 

Hi Linda,
Please correct the following if I'm wrong.
Let's define: VNF =3D one type of function.
Case 1: no service chaining, e.g., a firewall provides the network s= ervice
Let's state that 3 firewalls are needed, i.e., 3 instances of the VNF "= ;FW".
"VNFs have higher chance to fail due to lack of built-in redunda= ncy" combined with the use of "vnfpool"= ; means:
1) The 3 FW instances are deployed neither in active/active, nor in active/= standby mode, i.e., there are only 3 instances, and not 3 active, and 3 sta= ndby.
2) But this solution is not a trusted one because of "server fai= lure, server over-utilized, or software failure, etc.".
3) Assuming that the load of each (FW) instance is less than 60%, one can g= et HA for this system by using the 3 instances in a pool architecture (base= d on an efficient load balancing mechanism).
4) In this case, the failure of one instance is acceptable because its load= will be shared by the two remaining instances.
Case 2: service chaining, e.g., VNF1 and VNF2 are needed in order to= provide the network service (for instance, a kid requesting a Web page wit= h the use of a smartphone -> "parental control" (VNF1) checks = the URL, followed by "header enrichment" (VNF2) which adds the user ID in the media flow)
Lets' state that we have 3 instances of VNF1 and 3 instances of VNF2. If we= apply the same reasoning (and hypotheses) as above, we will have a 1st poo= l made up of 3 instances of VNF1, and a 2nd pool made up of 3 instances of = VNF2. The HA of this system is guaranteed if: (i) 1 instance of VNF1 fails,

[Linda] VNFpool is to develop protocol for the replacement instance o= f VNF1 to be chained to the  instance of VNF2 when the first instance of VNF1 fails.

 

(ii) 1 instance of VNF2 fails,

[Linda] VNFpool is to develop protocol for the instance of VNF1 to be= chained to the  replacement instance of VNF2 when the first instance of VNF2 fails.

 

(iii) 1 instance of VNF1 fails and 1 instanc= e of VNF2 fails.=

[Linda] Then the VNFpool protocol is responsible for chaining the rep= lacement of VNF1 to the replacement of VNF2.

 


Best,
Chidung

Le 03/12/2013 21:06= , Linda Dunbar a =E9crit :

Chidung,

Thanks for the quote.

Based on your quote, the = goal of “vnfpool” should be about to achieve “high availa= bility” of service function chaining while individual service functio= n instances are NOT reliable.  As stated in the problem statement, the virtualize= d network functions have higher chance to fail due to lack of built-in redu= ndancy, server failure, server over-utilized, or software failure, etc.

Linda

 <= /p>

From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of LAC Chidung
Sent: Monday, December 02, 2013 4:00 AM
To: vnfpool@ietf.org
Subject: Re: [vnfpool] VNF Pool Problem Statement<= /p>

 

Hi all,
Reliability is the ability of an item to perform a required function und= er stated conditions for a stated period of time, while Availability= is a measure of the degree to which an item is in an operable state when c= alled upon to perform. (D.J. Klinger, Y. Nakada, and M.A. Menedez (Eds.), "AT&T Reliability Ma= nual", Van Nostrand Reinhold, 1990)
Applied to the PSTN, the former includes "My call is not dropped durin= g a conversation", while the latter asks for "The phone service i= s ready, i.e., a tone is present, whenever I lift the handset".
For years, Dependability has encompassed these concepts (together wi= th others such as Maintainability) to characterize the good behavior (robustness) of a= system when facing accidental events (design faults, operations errors, hardware failur= es, natural disasters, etc.) , while Security, which includes all intentional actions (attacks, ..= .), is kept apart. This explains the presence, up to now, of two communitie= s working in these two separated subjects.
As (i) unavailability may the consequence of, e.g., software/hardware failu= res OR (D)DoS attacks (ii) Resilience is a fashionable expression* (iii) etc., resilience is us= ed since the last few years to encompass both dependability and security. Best,
Chidung
_______
*: see, e.g., Obama's praise for the resilience of the Indian people (http://articles.latimes.com/2010/nov/06/world/la-fgw-obama-mumbai-20= 101107)

Le 02/12/2013 08:21= , Cao,Zhen a =E9crit :

Good point, Diego.
I checked out the NFV ISG released documents of requirements and<=
/o:p>
terminology, where i could not find 'reliability' but 'resilience'.
-cz
 
On Wed, Nov 27, 2013 at 2:06 AM, Diego R. Lopez <diego@tid.es> wrote:
Hi,
When it comes to the reliability/availability issue I guess providing =
some
(condensed) definition from the NFV REL group would help...=

Be goode,
 
On 26 Nov 2013, at 04:00 , Hidetoshi Yokota wrote:
 
Hi Ning and all,
The proposed PS is a very good starting point covering major issues fo=
r the
goal of VNF pool. One thing that I could add is the synchronization be=
tween
the vNF migration/replacement and routing to make the relevant flows
forwarded to the new location. The challenge is that the VMs/severs in=
 a
pool could be deployed over topologically different networks (in the
physical world) and VNF migration could involve topologically independ=
ent
routing. There are multiple ways to do it, but we should first general=
ize
this issue and specify a common mechanism that may leverage existing o=
nes.
If this is already covered, that's fine. If some additional text is us=
eful,
the following could be a summary:
o Synchronization between vNF migration and flow forwarding, which may=

require topologically independent routing in the physical transport ne=
twork;
There is a discussion about "reliability" and "availabi=
lity" in another
thread and I think this is also an issue in ETSI NFV. We need to defin=
e them
either in this group or NFV to share the same view.
Regards,
--
Hidetoshi Yokota
 
KDDI R&D Laboratories, Inc.
e-mail:yokota@kddilabs.jp=

 
(2013/11/21 18:11), Zongning wrote:
 
Hi,
Please review the below brief version of VNF Pool Problem Statement, a=
nd
feedback with your comments. I hope this text can serve as a base of V=
NF
Pool Charter, by carving out real problems and work items.<=
/pre>

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


A virtualized network function (VNF) (e.g. vFW, vLB) provides the same=



function as the equivalent network function (e.g. FW, LB), but is usua=
lly


instantiated as a cluster of software instances running on general pur=
pose


servers via virtualization platform. In an environment based on VNFs, =
a


network service is typically realized by a chain of VNFs where the ins=
tances


of adjacent VNFs are preferably directly connected.


A VNF chain introduces additional points of failure beyond those inher=
ent in


a single dedicated server, and therefore additional challenges on=



reliability. By reliability, we mean the ability of a VNF chain to con=
tinue


function when having transition or failure within the chain. For examp=
le,


there are more factors such as software failure, server over-utilizati=
on,


instance migration that potentially cause VNF instance transition or


failure. Although a general pooling mechanism can be applied to addres=
s the


reliability of a single VNF, there are still problems when addressing =
the


reliability of a VNF chain, i.e. multiple pools for multiple VNFs. For=



example, how does an instance of VNF#1 know which instance in the pool=
 of


VNF#2 will replace the instance of VNF#2 it connects to? How does an


instance of VNF#1 know the state of instance of VNF#2 that it connects=
 to in


order to enforce policy for reliability like load sharing, switch befo=
re


break? How is the service state of an instance held and accessed for


efficient synchronization with backup instances?


The overall problem space can be further breakdown to the following st=
udy


items:


-          Signalling to =
handle reliability and instance transition


requirements


o   Signalling between VNF pools for transition (e.g. state =
change, scaling,


moving) notification, backup announcement;


o   Service state management (e.g. synchronizing method, sta=
te data format,


location and mechanism to access state data) within VNF pool;


o   Obtaining underlying network information (e.g. ALTO, I2R=
S);


o   Signalling to CMS for instance deployment reflecting rel=
iability


requirements (e.g. distribution of instances on different VMs or<=
/o:p>


hypervisors);


-          Transport char=
acteristics


o   Identify and analyze reliable transport characteristics =
for control


plane traffic;


o   Analysis of transport security characteristics to provid=
e protection


against known threats, and identification of an appropriate trust mode=
l;


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


Thanks.


-Ning


 


--


"Esta vez no fallaremos, Doctor Infierno"


 


Dr Diego R. Lopez


Telefonica I+D


http://people.tid.es/die=
go.lopez/


 


e-mail: diego@tid.es

Tel:    +34 913 129 041


Mobile: +34 682 051 091


-----------------------------------------


 


vnfpool mailing list


vnfpool@ietf.org

https://www.=
ietf.org/mailman/listinfo/vnfpool
--_000_4A95BA014132FF49AE685FAB4B9F17F645C2DD5Cdfweml509mbxchi_-- From chidung.lac@orange.com Mon Dec 9 08:20:43 2013 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 991011AE317 for ; Mon, 9 Dec 2013 08:20:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.316 X-Spam-Level: X-Spam-Status: No, score=0.316 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_35=0.6, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665] 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 URIaSQ9aRqg1 for ; Mon, 9 Dec 2013 08:20:38 -0800 (PST) Received: from r-mail1.rd.orange.com (r-mail1.rd.orange.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id 813911ADF73 for ; Mon, 9 Dec 2013 08:20:37 -0800 (PST) Received: from r-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 2CDBADE4003; Mon, 9 Dec 2013 17:22:16 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.orange.com (Postfix) with ESMTP id 17B11DE4001; Mon, 9 Dec 2013 17:22:16 +0100 (CET) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 Dec 2013 17:20:31 +0100 Received: from [10.193.5.32] ([10.193.5.32]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 Dec 2013 17:20:30 +0100 Message-ID: <52A5EC9B.3090703@orange.com> Date: Mon, 09 Dec 2013 17:15:23 +0100 From: LAC Chidung User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Linda Dunbar References: <52940EB0.6040601@kddilabs.jp> <529C5A30.3070000@orange.com> <4A95BA014132FF49AE685FAB4B9F17F645C293E9@dfweml509-mbx.china.huawei.com> <52A1FE77.10405@orange.com> <4A95BA014132FF49AE685FAB4B9F17F645C2DD5C@dfweml509-mbx.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645C2DD5C@dfweml509-mbx.china.huawei.com> Content-Type: multipart/alternative; boundary="------------000801090300040300060604" X-OriginalArrivalTime: 09 Dec 2013 16:20:30.0958 (UTC) FILETIME=[946E48E0:01CEF4FA] Cc: "vnfpool@ietf.org" Subject: Re: [vnfpool] VNF Pool 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, 09 Dec 2013 16:20:43 -0000 This is a multi-part message in MIME format. --------------000801090300040300060604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Thank you, Linda, for clarifying what I meant by "/*based on an efficient load balancing mechanism*/". Le 09/12/2013 17:11, Linda Dunbar a écrit : > > Childung, > > What you described is good beginning. I add the remaining to your > service chain (see the insert below) > > *From:*LAC Chidung [mailto:chidung.lac@orange.com] > *Sent:* Friday, December 06, 2013 10:43 AM > *To:* Linda Dunbar; vnfpool@ietf.org > *Subject:* Re: [vnfpool] VNF Pool Problem Statement > > Hi Linda, > Please correct the following if I'm wrong. > Let's define: VNF = one type of function. > _Case 1:_ no service chaining, e.g., a firewall provides the network > service > Let's state that 3 firewalls are needed, i.e., 3 instances of the VNF > "FW". > "*/VNFs have higher chance to fail due to lack of built-in > redundancy/*" combined with the use of "*/vnfpool/*" means: > 1) The 3 FW instances are deployed neither in active/active, nor in > active/standby mode, i.e., there are only 3 instances, and not 3 > active, and 3 standby. > 2) But this solution is not a trusted one because of "*/server > failure, server over-utilized, or software failure, etc./*". > 3) Assuming that the load of each (FW) instance is less than 60%, one > can get HA for this system by using the 3 instances in a pool > architecture (based on an efficient load balancing mechanism). > 4) In this case, the failure of one instance is acceptable because its > load will be shared by the two remaining instances. > _Case 2:_ service chaining, e.g., VNF1 and VNF2 are needed in order to > provide the network service (for instance, a kid requesting a Web page > with the use of a smartphone -> "parental control" (VNF1) checks the > URL, followed by "header enrichment" (VNF2) which adds the user ID in > the media flow) > Lets' state that we have 3 instances of VNF1 and 3 instances of VNF2. > If we apply the same reasoning (and hypotheses) as above, we will have > a 1st pool made up of 3 instances of VNF1, and a 2nd pool made up of 3 > instances of VNF2. The HA of this system is guaranteed if: (i) 1 > instance of VNF1 fails, > > [Linda] VNFpool is to develop protocol for the replacement instance of > VNF1 to be chained to the instance of VNF2 when the first instance of > VNF1 fails. > > (ii) 1 instance of VNF2 fails, > > [Linda] VNFpool is to develop protocol for the instance of VNF1 to be > chained to the replacement instance of VNF2 when the first instance > of VNF2 fails. > > (iii) 1 instance of VNF1fails and 1 instance of VNF2 fails. > > [Linda] Then the VNFpool protocol is responsible for chaining the > replacement of VNF1 to the replacement of VNF2. > > Best, > Chidung > > Le 03/12/2013 21:06, Linda Dunbar a écrit : > > Chidung, > > Thanks for the quote. > > Based on your quote, the goal of "vnfpool" should be about to > achieve "high availability" of service function chaining while > individual service function instances are NOT reliable. As stated > in the problem statement, the virtualized network functions have > higher chance to fail due to lack of built-in redundancy, server > failure, server over-utilized, or software failure, etc. > > Linda > > *From:*vnfpool [mailto:vnfpool-bounces@ietf.org] *On Behalf Of > *LAC Chidung > *Sent:* Monday, December 02, 2013 4:00 AM > *To:* vnfpool@ietf.org > *Subject:* Re: [vnfpool] VNF Pool Problem Statement > > Hi all, > /Reliability is the ability of an item to perform a required > function under stated conditions for a stated period of time/, > while/Availability is a measure of the degree to which an item is > in an operable state when called upon to perform./ (D.J. Klinger, > Y. Nakada, and M.A. Menedez (Eds.), "AT&T Reliability Manual", Van > Nostrand Reinhold, 1990) > Applied to the PSTN, the former includes "My call is not dropped > during a conversation", while the latter asks for "The phone > service is ready, i.e., a tone is present, whenever I lift the > handset". > For years, /Dependability /has encompassed these concepts > (together with others such as /Maintainability) /to characterize > the good behavior (robustness) of a system when facing *accidental > *events (design faults, operations errors, hardware failures, > natural disasters, etc.) , while /Security, /which includes all > *intentional *actions (attacks, ...), is kept apart. This explains > the presence, up to now, of two communities working in these two > separated subjects. > As (i) unavailability may the consequence of, e.g., > software/hardware failures OR (D)DoS attacks (ii) /Resilience/ is > a fashionable expression* (iii) etc., resilience is used since the > last few years to encompass both dependability and security. > Best, > Chidung > _______ > *: see, e.g., Obama's praise for the resilience of the Indian > people > (http://articles.latimes.com/2010/nov/06/world/la-fgw-obama-mumbai-20101107) > > Le 02/12/2013 08:21, Cao,Zhen a écrit : > > Good point, Diego. > > I checked out the NFV ISG released documents of requirements and > > terminology, where i could not find 'reliability' but 'resilience'. > > -cz > > > > On Wed, Nov 27, 2013 at 2:06 AM, Diego R. Lopez wrote: > > Hi, > > When it comes to the reliability/availability issue I guess providing some > > (condensed) definition from the NFV REL group would help... > > Be goode, > > > > On 26 Nov 2013, at 04:00 , Hidetoshi Yokota wrote: > > > > Hi Ning and all, > > The proposed PS is a very good starting point covering major issues for the > > goal of VNF pool. One thing that I could add is the synchronization between > > the vNF migration/replacement and routing to make the relevant flows > > forwarded to the new location. The challenge is that the VMs/severs in a > > pool could be deployed over topologically different networks (in the > > physical world) and VNF migration could involve topologically independent > > routing. There are multiple ways to do it, but we should first generalize > > this issue and specify a common mechanism that may leverage existing ones. > > If this is already covered, that's fine. If some additional text is useful, > > the following could be a summary: > > o Synchronization between vNF migration and flow forwarding, which may > > require topologically independent routing in the physical transport network; > > There is a discussion about "reliability" and "availability" in another > > thread and I think this is also an issue in ETSI NFV. We need to define them > > either in this group or NFV to share the same view. > > Regards, > > -- > > Hidetoshi Yokota > > > > KDDI R&D Laboratories, Inc. > > e-mail:yokota@kddilabs.jp > > > > (2013/11/21 18:11), Zongning wrote: > > > > Hi, > > Please review the below brief version of VNF Pool Problem Statement, and > > feedback with your comments. I hope this text can serve as a base of VNF > > Pool Charter, by carving out real problems and work items. > > =========================================================================================== > > A virtualized network function (VNF) (e.g. vFW, vLB) provides the same > > function as the equivalent network function (e.g. FW, LB), but is usually > > instantiated as a cluster of software instances running on general purpose > > servers via virtualization platform. In an environment based on VNFs, a > > network service is typically realized by a chain of VNFs where the instances > > of adjacent VNFs are preferably directly connected. > > A VNF chain introduces additional points of failure beyond those inherent in > > a single dedicated server, and therefore additional challenges on > > reliability. By reliability, we mean the ability of a VNF chain to continue > > function when having transition or failure within the chain. For example, > > there are more factors such as software failure, server over-utilization, > > instance migration that potentially cause VNF instance transition or > > failure. Although a general pooling mechanism can be applied to address the > > reliability of a single VNF, there are still problems when addressing the > > reliability of a VNF chain, i.e. multiple pools for multiple VNFs. For > > example, how does an instance of VNF#1 know which instance in the pool of > > VNF#2 will replace the instance of VNF#2 it connects to? How does an > > instance of VNF#1 know the state of instance of VNF#2 that it connects to in > > order to enforce policy for reliability like load sharing, switch before > > break? How is the service state of an instance held and accessed for > > efficient synchronization with backup instances? > > The overall problem space can be further breakdown to the following study > > items: > > - Signalling to handle reliability and instance transition > > requirements > > o Signalling between VNF pools for transition (e.g. state change, scaling, > > moving) notification, backup announcement; > > o Service state management (e.g. synchronizing method, state data format, > > location and mechanism to access state data) within VNF pool; > > o Obtaining underlying network information (e.g. ALTO, I2RS); > > o Signalling to CMS for instance deployment reflecting reliability > > requirements (e.g. distribution of instances on different VMs or > > hypervisors); > > - Transport characteristics > > o Identify and analyze reliable transport characteristics for control > > plane traffic; > > o Analysis of transport security characteristics to provide protection > > against known threats, and identification of an appropriate trust model; > > =========================================================================================== > > Thanks. > > -Ning > > > > -- > > "Esta vez no fallaremos, Doctor Infierno" > > > > Dr Diego R. Lopez > > Telefonica I+D > > http://people.tid.es/diego.lopez/ > > > > e-mail:diego@tid.es > > Tel: +34 913 129 041 > > Mobile: +34 682 051 091 > > ----------------------------------------- > > > > vnfpool mailing list > > vnfpool@ietf.org > > https://www.ietf.org/mailman/listinfo/vnfpool > --------------000801090300040300060604 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thank you, Linda, for clarifying what I meant by "based on an efficient load balancing mechanism".

Le 09/12/2013 17:11, Linda Dunbar a écrit :

Childung,

What you described is good beginning. I add the remaining to your service chain (see the insert below)

 

 

From: LAC Chidung [mailto:chidung.lac@orange.com]
Sent: Friday, December 06, 2013 10:43 AM
To: Linda Dunbar; vnfpool@ietf.org
Subject: Re: [vnfpool] VNF Pool Problem Statement

 

Hi Linda,
Please correct the following if I'm wrong.
Let's define: VNF = one type of function.
Case 1: no service chaining, e.g., a firewall provides the network service
Let's state that 3 firewalls are needed, i.e., 3 instances of the VNF "FW".
"VNFs have higher chance to fail due to lack of built-in redundancy" combined with the use of "vnfpool" means:
1) The 3 FW instances are deployed neither in active/active, nor in active/standby mode, i.e., there are only 3 instances, and not 3 active, and 3 standby.
2) But this solution is not a trusted one because of "server failure, server over-utilized, or software failure, etc.".
3) Assuming that the load of each (FW) instance is less than 60%, one can get HA for this system by using the 3 instances in a pool architecture (based on an efficient load balancing mechanism).
4) In this case, the failure of one instance is acceptable because its load will be shared by the two remaining instances.
Case 2: service chaining, e.g., VNF1 and VNF2 are needed in order to provide the network service (for instance, a kid requesting a Web page with the use of a smartphone -> "parental control" (VNF1) checks the URL, followed by "header enrichment" (VNF2) which adds the user ID in the media flow)
Lets' state that we have 3 instances of VNF1 and 3 instances of VNF2. If we apply the same reasoning (and hypotheses) as above, we will have a 1st pool made up of 3 instances of VNF1, and a 2nd pool made up of 3 instances of VNF2. The HA of this system is guaranteed if: (i) 1 instance of VNF1 fails,

[Linda] VNFpool is to develop protocol for the replacement instance of VNF1 to be chained to the  instance of VNF2 when the first instance of VNF1 fails.

 (ii) 1 instance of VNF2 fails,

[Linda] VNFpool is to develop protocol for the instance of VNF1 to be chained to the  replacement instance of VNF2 when the first instance of VNF2 fails.

 (iii) 1 instance of VNF1 fails and 1 instance of VNF2 fails.

[Linda] Then the VNFpool protocol is responsible for chaining the replacement of VNF1 to the replacement of VNF2.

Best,
Chidung

Le 03/12/2013 21:06, Linda Dunbar a écrit :

Chidung,

Thanks for the quote.

Based on your quote, the goal of “vnfpool” should be about to achieve “high availability” of service function chaining while individual service function instances are NOT reliable.  As stated in the problem statement, the virtualized network functions have higher chance to fail due to lack of built-in redundancy, server failure, server over-utilized, or software failure, etc.

Linda

 

From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of LAC Chidung
Sent: Monday, December 02, 2013 4:00 AM
To: vnfpool@ietf.org
Subject: Re: [vnfpool] VNF Pool Problem Statement

 

Hi all,
Reliability is the ability of an item to perform a required function under stated conditions for a stated period of time, while Availability is a measure of the degree to which an item is in an operable state when called upon to perform. (D.J. Klinger, Y. Nakada, and M.A. Menedez (Eds.), "AT&T Reliability Manual", Van Nostrand Reinhold, 1990)
Applied to the PSTN, the former includes "My call is not dropped during a conversation", while the latter asks for "The phone service is ready, i.e., a tone is present, whenever I lift the handset".
For years, Dependability has encompassed these concepts (together with others such as Maintainability) to characterize the good behavior (robustness) of a system when facing accidental events (design faults, operations errors, hardware failures, natural disasters, etc.) , while Security, which includes all intentional actions (attacks, ...), is kept apart. This explains the presence, up to now, of two communities working in these two separated subjects.
As (i) unavailability may the consequence of, e.g., software/hardware failures OR (D)DoS attacks (ii) Resilience is a fashionable expression* (iii) etc., resilience is used since the last few years to encompass both dependability and security.
Best,
Chidung
_______
*: see, e.g., Obama's praise for the resilience of the Indian people (http://articles.latimes.com/2010/nov/06/world/la-fgw-obama-mumbai-20101107)

Le 02/12/2013 08:21, Cao,Zhen a écrit :

Good point, Diego.
I checked out the NFV ISG released documents of requirements and
terminology, where i could not find 'reliability' but 'resilience'.
-cz
 
On Wed, Nov 27, 2013 at 2:06 AM, Diego R. Lopez <diego@tid.es> wrote:
Hi,
When it comes to the reliability/availability issue I guess providing some
(condensed) definition from the NFV REL group would help...
Be goode,
 
On 26 Nov 2013, at 04:00 , Hidetoshi Yokota wrote:
 
Hi Ning and all,
The proposed PS is a very good starting point covering major issues for the
goal of VNF pool. One thing that I could add is the synchronization between
the vNF migration/replacement and routing to make the relevant flows
forwarded to the new location. The challenge is that the VMs/severs in a
pool could be deployed over topologically different networks (in the
physical world) and VNF migration could involve topologically independent
routing. There are multiple ways to do it, but we should first generalize
this issue and specify a common mechanism that may leverage existing ones.
If this is already covered, that's fine. If some additional text is useful,
the following could be a summary:
o Synchronization between vNF migration and flow forwarding, which may
require topologically independent routing in the physical transport network;
There is a discussion about "reliability" and "availability" in another
thread and I think this is also an issue in ETSI NFV. We need to define them
either in this group or NFV to share the same view.
Regards,
--
Hidetoshi Yokota
 
KDDI R&D Laboratories, Inc.
e-mail:yokota@kddilabs.jp
 
(2013/11/21 18:11), Zongning wrote:
 
Hi,
Please review the below brief version of VNF Pool Problem Statement, and
feedback with your comments. I hope this text can serve as a base of VNF
Pool Charter, by carving out real problems and work items.
===========================================================================================
A virtualized network function (VNF) (e.g. vFW, vLB) provides the same
function as the equivalent network function (e.g. FW, LB), but is usually
instantiated as a cluster of software instances running on general purpose
servers via virtualization platform. In an environment based on VNFs, a
network service is typically realized by a chain of VNFs where the instances
of adjacent VNFs are preferably directly connected.
A VNF chain introduces additional points of failure beyond those inherent in
a single dedicated server, and therefore additional challenges on
reliability. By reliability, we mean the ability of a VNF chain to continue
function when having transition or failure within the chain. For example,
there are more factors such as software failure, server over-utilization,
instance migration that potentially cause VNF instance transition or
failure. Although a general pooling mechanism can be applied to address the
reliability of a single VNF, there are still problems when addressing the
reliability of a VNF chain, i.e. multiple pools for multiple VNFs. For
example, how does an instance of VNF#1 know which instance in the pool of
VNF#2 will replace the instance of VNF#2 it connects to? How does an
instance of VNF#1 know the state of instance of VNF#2 that it connects to in
order to enforce policy for reliability like load sharing, switch before
break? How is the service state of an instance held and accessed for
efficient synchronization with backup instances?
The overall problem space can be further breakdown to the following study
items:
-          Signalling to handle reliability and instance transition
requirements
o   Signalling between VNF pools for transition (e.g. state change, scaling,
moving) notification, backup announcement;
o   Service state management (e.g. synchronizing method, state data format,
location and mechanism to access state data) within VNF pool;
o   Obtaining underlying network information (e.g. ALTO, I2RS);
o   Signalling to CMS for instance deployment reflecting reliability
requirements (e.g. distribution of instances on different VMs or
hypervisors);
-          Transport characteristics
o   Identify and analyze reliable transport characteristics for control
plane traffic;
o   Analysis of transport security characteristics to provide protection
against known threats, and identification of an appropriate trust model;
===========================================================================================
Thanks.
-Ning
 
--
"Esta vez no fallaremos, Doctor Infierno"
 
Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/
 
e-mail: diego@tid.es
Tel:    +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------
 
vnfpool mailing list
vnfpool@ietf.org
https://www.ietf.org/mailman/listinfo/vnfpool
--------------000801090300040300060604-- From diego@tid.es Mon Dec 9 11:00:34 2013 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 7D92B1AE4B3 for ; Mon, 9 Dec 2013 11:00:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.803 X-Spam-Level: X-Spam-Status: No, score=-2.803 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 wTtpa-94VTf3 for ; Mon, 9 Dec 2013 11:00:32 -0800 (PST) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 59EDD1AE4B0 for ; Mon, 9 Dec 2013 11:00:29 -0800 (PST) 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 <0MXJ00HSPZGGAD@tid.hi.inet> for vnfpool@ietf.org; Mon, 09 Dec 2013 20:00:16 +0100 (MET) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id C5.73.02810.F3316A25; Mon, 09 Dec 2013 20:00:16 +0100 (CET) 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 <0MXJ00HSKZGFAD@tid.hi.inet> for vnfpool@ietf.org; Mon, 09 Dec 2013 20:00:15 +0100 (MET) Received: from EX10-MB1-MAD.hi.inet ([169.254.1.153]) by EX10-HTCAS6-MAD.hi.inet ([::1]) with mapi id 14.03.0158.001; Mon, 09 Dec 2013 20:00:15 +0100 Date: Mon, 09 Dec 2013 19:00:14 +0000 From: "Diego R. Lopez" In-reply-to: <52A52A3F.4060503@nomountain.net> X-Originating-IP: [10.95.64.115] To: Melinda Shore Message-id: Content-id: <2F1FA663E7B29A42A4B5B199EC7436E3@hi.inet> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US, es-ES Thread-topic: [vnfpool] VNF Pool Problem Statement Thread-index: Ac7mmacuBQUiFtBEQ2CEYoAlHpu1YwDsY9sAAB6uswABGDbKAADfPKFKAAaSMoAAby4dgAAAuHqAACK4P4A= X-AuditID: 0a5f4e69-b7f9b8e000000afa-9c-52a6133ffd18 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42Lhivcz1HUQXhZkMGsdk8WMS/9ZHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVceLaUtaCVyIVk1bcYWxgXCLSxcjJISFgIvGjcw4ThC0mceHe erYuRi4OIYFtjBKdVy4yQzi/GCX29u5lgXBmMkqcWfeBFaSFRUBV4uihqewgNhuQ/aj5N5DN wSEsYCgx63YKSJhTQE9i0u1FLBAbFCT+nHsMZosIGEh8etIMVs4soC3x/Y07SJhXwFLi8Ycm VoiwmcS8S7wQYUGJH5PvsUCE1SWmTMkFCTMLiEs0t95kgbAVJaYtamAEsRkFZCXezZ/PCrHI SGLmoldsIK0iAikSVyeIQ9wiILFkz3lmCFtU4uXjf6wQ/y1nkXjQ9I91AqPELIQjZiE5YhbC EbOQHDELyRELGFlXMYoVJxVlpmeU5CZm5qQbGOllZOpl5qWWbGKERFvmDsblO1UOMQpwMCrx 8Cr+WxokxJpYVlyZe4hRgoNZSYSXi31ZkBBvSmJlVWpRfnxRaU5q8SFGJg5OqQbGtpNbQhIW Ryp1ffkQuX3fm9f6G2ZpWDlMMbnHslqH76VNsaGS9ek+Xa+1Gzrjv0jxd/jPXf+1fUs3Q8Sq EIsiqVNy4V/OhnJamfklb33C+pnt0WV1thmz25bJhWTrhMrrrtEtMp+jw79uk2HVXb1pHhOu ZOhlHJ/Bt2yBcGFcUaDDkZgH/ueUWIozEg21mIuKEwHbJJYElAIAAA== References: <52940EB0.6040601@kddilabs.jp> <529C5A30.3070000@orange.com> <4A95BA014132FF49AE685FAB4B9F17F645C293E9@dfweml509-mbx.china.huawei.com> <52A1FE77.10405@orange.com> <65174429B5AF4C45BD0798810EC48E0A0D38CF@EX-0-MB2.lancs.local> <52A52A3F.4060503@nomountain.net> Cc: "" Subject: Re: [vnfpool] VNF Pool 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, 09 Dec 2013 19:00:34 -0000 SGksDQoNCkkgYWdyZWUgd2l0aCBNZWxpbmRhIGluIHRoYXQgdGhlIHByb2JsZW0gaGFzIHRvIGJl IGNvbmZpbmVkIHRvIHRoZSBWTkYgKGFuZCBpdHMgcG9vbGluZyBtYW5hZ2VyKSBhbmQgdGhlIHNl cnZpY2UgY2hhaW5pbmcgbWFuYWdlbWVudCBmdW5jdGlvbnMuIEV4dGVybmFsIGVsZW1lbnRzLCBs aWtlIG90aGVyIHZpcnR1YWwgYW5kL29yIHBoeXNpY2FsIG5ldHdvcmsgZnVuY3Rpb25zIGluIGEg Z2l2ZW4gcGF0aCAodGhlIHJlYWxpemF0aW9uIG9mIHRoZSBjaGFpbikgb3IgdXNlciBhcHBsaWNh dGlvbnMgc2hvdWxkIGJlIGNvbXBsZXRlbHkgb2JsaXZpb3VzIHRvIHRoZSBwb29saW5nIG1lY2hh bmlzbXMgaW4gcGxhY2UuDQoNCkJlIGdvb2RlLA0KDQoNCk9uIDkgRGVjIDIwMTMsIGF0IDAzOjI2 ICwgTWVsaW5kYSBTaG9yZSB3cm90ZToNCg0KPiBJIHRoaW5rIERhbmllbCBpcyBhc2tpbmcgZXhh Y3RseSB0aGUgcmlnaHQgcXVlc3Rpb25zLiAgQnV0DQo+IHRvIGJhY2sgdXAgYSBiaXQsIEkndmUg YmVlbiB0aGlua2luZyBhYm91dCB0aGlzIG92ZXIgdGhlDQo+IHdlZWtlbmQgYW5kIHJlYWxpemVk IHRoYXQgdGhlIHNjZW5hcmlvIGlzIGFjdHVhbGx5IHNpbXBsZXINCj4gdGhhbiBJJ2QgYmVlbiBj b25zaWRlcmluZy4gIElmIHRoZSBWTkYgaW5zdGFuY2VzIGFyZSBwb29sZWQNCj4gYWxvbmcgdGhl IGdlbmVyYWwgbGluZXMgb2Ygc29tZXRoaW5nIGxpa2UgcnNlcnBvb2wsIGl0IGlzDQo+IG5vdCB0 aGUgY2FzZSB0aGF0IGFuIGV4dGVybmFsIGNsaWVudCB3aWxsIG5lZWQgdG8gYmUNCj4gbW9kaWZp ZWQuICBUaGUgb25seSBlbGVtZW50cyB3aGljaCB3b3VsZCBuZWVkIHRvIGJlIGFibGUNCj4gdG8g InRhbGsiIHRoZSBwb29saW5nIHByb3RvY29sIGFyZSBhbHJlYWR5IHBhcnRpY2lwYXRpbmcgLQ0K PiB0aGV5J2QgYmUgdGhlIHBvb2wgbWFuYWdlciBhbmQgd2hhdGV2ZXIgc2VydmljZSBjaGFpbg0K PiBtYW5hZ2VtZW50IGZ1bmN0aW9uIGlzIGJlaW5nIHVzZWQsIHRoZSBwb29sIG1lbWJlcnMsIGFu ZA0KPiBhZGphY2VudCBwb29scy4gIFNvIEkgdGhpbmsgd2UncmUgaW4gZ29vZCBzaGFwZSB0aGVy ZTsgd2UNCj4gY291bGQgcHJvYmFibHkgdXNlIHNvbWUgYmV0dGVyIHRleHQgYXJvdW5kIHRoaXMg dG8gbWFrZQ0KPiBpdCBjbGVhcmVyLg0KPg0KPiBNZWxpbmRhDQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHZuZnBvb2wgbWFpbGluZyBsaXN0DQo+ IHZuZnBvb2xAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by92bmZwb29sDQoNCg0KLS0NCiJFc3RhIHZleiBubyBmYWxsYXJlbW9zLCBEb2N0b3IgSW5maWVy bm8iDQoNCkRyIERpZWdvIFIuIExvcGV6DQpUZWxlZm9uaWNhIEkrRA0KaHR0cDovL3Blb3BsZS50 aWQuZXMvZGllZ28ubG9wZXovDQoNCmUtbWFpbDogZGllZ29AdGlkLmVzDQpUZWw6ICAgICszNCA5 MTMgMTI5IDA0MQ0KTW9iaWxlOiArMzQgNjgyIDA1MSAwOTENCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCg0KRXN0ZSBtZW5zYWplIHNlIGRpcmlnZSBleGNsdXNpdmFtZW50ZSBhIHN1IGRlc3RpbmF0 YXJpby4gUHVlZGUgY29uc3VsdGFyIG51ZXN0cmEgcG9sw610aWNhIGRlIGVudsOtbyB5IHJlY2Vw Y2nDs24gZGUgY29ycmVvIGVsZWN0csOzbmljbyBlbiBlbCBlbmxhY2Ugc2l0dWFkbyBtw6FzIGFi YWpvLg0KVGhpcyBtZXNzYWdlIGlzIGludGVuZGVkIGV4Y2x1c2l2ZWx5IGZvciBpdHMgYWRkcmVz c2VlLiBXZSBvbmx5IHNlbmQgYW5kIHJlY2VpdmUgZW1haWwgb24gdGhlIGJhc2lzIG9mIHRoZSB0 ZXJtcyBzZXQgb3V0IGF0Og0KaHR0cDovL3d3dy50aWQuZXMvRVMvUEFHSU5BUy9kaXNjbGFpbWVy LmFzcHgNCg== From d.king@lancaster.ac.uk Mon Dec 9 12:15:54 2013 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 D26EA1AE51B for ; Mon, 9 Dec 2013 12:15:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 AERGmAfDnQKr for ; Mon, 9 Dec 2013 12:15:51 -0800 (PST) Received: from ignavia.lancs.ac.uk (ignavia.lancs.ac.uk [148.88.25.16]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC861AE0BD for ; Mon, 9 Dec 2013 12:15:51 -0800 (PST) Received: from ex-0-ht0.lancs.ac.uk ([10.42.18.47] helo=EX-0-HT0.lancs.local) by ignavia.lancs.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1Vq7F1-0000yv-1S; Mon, 09 Dec 2013 20:15:43 +0000 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.0158.001; Mon, 9 Dec 2013 20:15:42 +0000 From: "King, Daniel" To: "Diego R. Lopez" , Melinda Shore Thread-Topic: [vnfpool] VNF Pool Problem Statement Thread-Index: AQHY+TQ7dY3tQjejG3tIVJ9qDrtQ3QDsY9sAAB6uswABGDbKAADfPKFKAAaSMoAAby4dgAAAuHqAACK4P4CaG1Lg0A== Date: Mon, 9 Dec 2013 20:15:41 +0000 Message-ID: <65174429B5AF4C45BD0798810EC48E0A0D3C0B@EX-0-MB2.lancs.local> References: <52940EB0.6040601@kddilabs.jp> <529C5A30.3070000@orange.com> <4A95BA014132FF49AE685FAB4B9F17F645C293E9@dfweml509-mbx.china.huawei.com> <52A1FE77.10405@orange.com> <65174429B5AF4C45BD0798810EC48E0A0D38CF@EX-0-MB2.lancs.local> <52A52A3F.4060503@nomountain.net> 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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "" Subject: Re: [vnfpool] VNF Pool 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, 09 Dec 2013 20:15:55 -0000 SGkgQWxsLCANCg0KUmU6IERlcGxveW1lbnQgU2NlbmFyaW9zDQoNClNvdW5kcyBnb29kLCBpdCB3 YXMganVzdCBhIGdlbnRsZSByZW1pbmRlciB0aGF0IHRoZSBtb2RlbCB3ZSBzZXR0bGUgb24gc2hv dWxkIGZpdCB3aXRoIGV4aXN0aW5nL3BsYW5uZWQgZGVwbG95bWVudCBzY2VuYXJpb3MsIGFuZCBu ZXR3b3JrIHJlc2lsaWVuY2UgbWVjaGFuaXNtcy4gQXMgd2UgZGV2ZWxvcCB0aGUgdm5mcG9vbCBw cm9ibGVtIHN0YXRlbWVudCwgd2UgYXJlIGNhcHR1cmluZyB0aGUgc2NvcGUgYW5kIGtleSBwcm9i bGVtcyB0aGF0IGluZm9ybSB0aGUgc29sdXRpb24gd29yaywgYnV0IGlkZWFsbHkgdGhlc2Ugc2hv dWxkIGJlIGd1aWRlZCBieSBob3cgb3BlcmF0b3JzIGFuZCBzZXJ2aWNlIHByb3ZpZGVycyBwbGFu IHRvIHVzZSBWTkZzIGluIHRoZSBmaWVsZC4gT3BlcmF0b3JzIHRoYXQgaGF2ZSBORlYgdHJpYWxz IGFuZCBwcm90b3R5cGVzLCBwcm92aWRlcyB2YWx1YWJsZSBkYXRhIHRvIHVzZSBmb3IgdGhlIHNv bHV0aW9uIHdvcmssIHdlIGp1c3QgbmVlZCB0byBlbmNvdXJhZ2UgdGhlbSB0byBhc3NpZ24gbW9y ZSBDUFUgY3ljbGVzIHRvIHRoZSB2bmZwb29sIG1haWxpbmcgbGlzdC4gOy0pIA0KDQpSZTogKGhp Z2gtbGV2ZWwpIEFyY2hpdGVjdHVyZQ0KDQpJdCB3b3VsZCBiZSBncmVhdCB0byB2aXN1YWxpc2Ug dGhlIGFyY2hpdGVjdHVyZSAoQVNDSUkgb3Igb3RoZXJ3aXNlKSwgc3BlY2lmaWNhbGx5IHRoZSBj b21wb25lbnRzLCByZWxhdGlvbnNoaXBzLCBpbnRlcmFjdGlvbnMgYW5kIGludGVyZmFjZXMgcmVx dWlyZWQvZXhwZWN0ZWQgYmFzZWQgb24gdGhlIHByb2JsZW0gc3RhdGVtZW50ICh0aHVzIGZhcik6 DQoNCi0gVk5GIFBvb2wgTWFuYWdlciAoaW4tc2NvcGUsIG91dCBvZiBzY29wZT8pDQpvIFJlc2ls aWVudCBpdHNlbGYgKG11bHRpLWluc3RhbmNlKT8gDQoNCi0gU2luZ2xlIGluc3RhbmNlIFZORnMs IE11bHRpLWluc3RhbmNlIFZORnMgYW5kIENoYWluZWQgVk5Gcw0KbyBTaWduYWxpbmcgbWVjaGFu aXNtcy9jaGFyYWN0ZXJpc3RpY3MvcmVsYXRpb25zaGlwcw0KDQotIEFic3RyYWN0IGludGVyYWN0 aW9ucy9yZWxhdGlvbnNoaXBzIGJldHdlZW4gVk5GIFBvb2wgTWFuYWdlciBhbmQgVk5GcywgYW5k IFZORiB0byBWTkYocykuIA0KbyBJbnN0YW50aWF0aW9uIA0KbyBBZGFwdGF0aW9uDQpvIE1pZ3Jh dGlvbg0KbyBGYWlsLW92ZXINCm8gTG9hZC1iYWxhbmNpbmcNCm8gVGVybWluYXRpb24NCg0KLSBW TkYvUG9vbCBUb3BvbG9neSBNYW5hZ2VtZW50DQpvIEZ1bmN0aW9ucyBhbmQgSW50ZXJmYWNlcyAg DQoNCi0gIENvbnRyb2wgUGxhbmUNCm8gRnVuY3Rpb25zIGFuZCBJbnRlcmZhY2VzICANCg0KLSBS ZWxhdGlvbnNoaXAgKG9yIGNvbXBsZXRlbHkgdHJhbnNwYXJlbnQ/KSB3aXRoIHBoeXNpY2FsIGFu ZCB2aXJ0dWFsIGVsZW1lbnRzLCBwcm92aWRpbmcgY29ubmVjdGl2aXR5IGFuZCBhZGRpdGlvbmFs IGZ1bmN0aW9uDQoNCkJyLCBEYW4uIA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogdm5mcG9vbCBbbWFpbHRvOnZuZnBvb2wtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IERpZWdvIFIuIExvcGV6DQpTZW50OiAwOSBEZWNlbWJlciAyMDEzIDE5OjAwDQpUbzogTWVsaW5k YSBTaG9yZQ0KQ2M6IDx2bmZwb29sQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFt2bmZwb29sXSBW TkYgUG9vbCBQcm9ibGVtIFN0YXRlbWVudA0KDQpIaSwNCg0KSSBhZ3JlZSB3aXRoIE1lbGluZGEg aW4gdGhhdCB0aGUgcHJvYmxlbSBoYXMgdG8gYmUgY29uZmluZWQgdG8gdGhlIFZORiAoYW5kIGl0 cyBwb29saW5nIG1hbmFnZXIpIGFuZCB0aGUgc2VydmljZSBjaGFpbmluZyBtYW5hZ2VtZW50IGZ1 bmN0aW9ucy4gRXh0ZXJuYWwgZWxlbWVudHMsIGxpa2Ugb3RoZXIgdmlydHVhbCBhbmQvb3IgcGh5 c2ljYWwgbmV0d29yayBmdW5jdGlvbnMgaW4gYSBnaXZlbiBwYXRoICh0aGUgcmVhbGl6YXRpb24g b2YgdGhlIGNoYWluKSBvciB1c2VyIGFwcGxpY2F0aW9ucyBzaG91bGQgYmUgY29tcGxldGVseSBv YmxpdmlvdXMgdG8gdGhlIHBvb2xpbmcgbWVjaGFuaXNtcyBpbiBwbGFjZS4NCg0KQmUgZ29vZGUs DQoNCg0KT24gOSBEZWMgMjAxMywgYXQgMDM6MjYgLCBNZWxpbmRhIFNob3JlIHdyb3RlOg0KDQo+ IEkgdGhpbmsgRGFuaWVsIGlzIGFza2luZyBleGFjdGx5IHRoZSByaWdodCBxdWVzdGlvbnMuICBC dXQgdG8gYmFjayB1cCANCj4gYSBiaXQsIEkndmUgYmVlbiB0aGlua2luZyBhYm91dCB0aGlzIG92 ZXIgdGhlIHdlZWtlbmQgYW5kIHJlYWxpemVkIA0KPiB0aGF0IHRoZSBzY2VuYXJpbyBpcyBhY3R1 YWxseSBzaW1wbGVyIHRoYW4gSSdkIGJlZW4gY29uc2lkZXJpbmcuICBJZiANCj4gdGhlIFZORiBp bnN0YW5jZXMgYXJlIHBvb2xlZCBhbG9uZyB0aGUgZ2VuZXJhbCBsaW5lcyBvZiBzb21ldGhpbmcg bGlrZSANCj4gcnNlcnBvb2wsIGl0IGlzIG5vdCB0aGUgY2FzZSB0aGF0IGFuIGV4dGVybmFsIGNs aWVudCB3aWxsIG5lZWQgdG8gYmUgDQo+IG1vZGlmaWVkLiAgVGhlIG9ubHkgZWxlbWVudHMgd2hp Y2ggd291bGQgbmVlZCB0byBiZSBhYmxlIHRvICJ0YWxrIiB0aGUgDQo+IHBvb2xpbmcgcHJvdG9j b2wgYXJlIGFscmVhZHkgcGFydGljaXBhdGluZyAtIHRoZXknZCBiZSB0aGUgcG9vbCANCj4gbWFu YWdlciBhbmQgd2hhdGV2ZXIgc2VydmljZSBjaGFpbiBtYW5hZ2VtZW50IGZ1bmN0aW9uIGlzIGJl aW5nIHVzZWQsIA0KPiB0aGUgcG9vbCBtZW1iZXJzLCBhbmQgYWRqYWNlbnQgcG9vbHMuICBTbyBJ IHRoaW5rIHdlJ3JlIGluIGdvb2Qgc2hhcGUgDQo+IHRoZXJlOyB3ZSBjb3VsZCBwcm9iYWJseSB1 c2Ugc29tZSBiZXR0ZXIgdGV4dCBhcm91bmQgdGhpcyB0byBtYWtlIGl0IA0KPiBjbGVhcmVyLg0K Pg0KPiBNZWxpbmRhDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+IHZuZnBvb2wgbWFpbGluZyBsaXN0DQo+IHZuZnBvb2xAaWV0Zi5vcmcNCj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92bmZwb29sDQoNCg0KLS0NCiJFc3Rh IHZleiBubyBmYWxsYXJlbW9zLCBEb2N0b3IgSW5maWVybm8iDQoNCkRyIERpZWdvIFIuIExvcGV6 DQpUZWxlZm9uaWNhIEkrRA0KaHR0cDovL3Blb3BsZS50aWQuZXMvZGllZ28ubG9wZXovDQoNCmUt bWFpbDogZGllZ29AdGlkLmVzDQpUZWw6ICAgICszNCA5MTMgMTI5IDA0MQ0KTW9iaWxlOiArMzQg NjgyIDA1MSAwOTENCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KRXN0ZSBtZW5zYWplIHNlIGRp cmlnZSBleGNsdXNpdmFtZW50ZSBhIHN1IGRlc3RpbmF0YXJpby4gUHVlZGUgY29uc3VsdGFyIG51 ZXN0cmEgcG9sw610aWNhIGRlIGVudsOtbyB5IHJlY2VwY2nDs24gZGUgY29ycmVvIGVsZWN0csOz bmljbyBlbiBlbCBlbmxhY2Ugc2l0dWFkbyBtw6FzIGFiYWpvLg0KVGhpcyBtZXNzYWdlIGlzIGlu dGVuZGVkIGV4Y2x1c2l2ZWx5IGZvciBpdHMgYWRkcmVzc2VlLiBXZSBvbmx5IHNlbmQgYW5kIHJl Y2VpdmUgZW1haWwgb24gdGhlIGJhc2lzIG9mIHRoZSB0ZXJtcyBzZXQgb3V0IGF0Og0KaHR0cDov L3d3dy50aWQuZXMvRVMvUEFHSU5BUy9kaXNjbGFpbWVyLmFzcHgNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQp2bmZwb29sIG1haWxpbmcgbGlzdA0Kdm5m cG9vbEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92bmZw b29sDQo= From d.king@lancaster.ac.uk Mon Dec 9 13:19:45 2013 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 669AC1AE0E1 for ; Mon, 9 Dec 2013 13:19:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.6 X-Spam-Level: X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, 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 K2zD6mAQzwtU for ; Mon, 9 Dec 2013 13:19:39 -0800 (PST) Received: from sideburn.lancs.ac.uk (sideburn.lancs.ac.uk [148.88.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id AC4801AE0B1 for ; Mon, 9 Dec 2013 13:19:38 -0800 (PST) Received: from ex-1-ht0.lancs.ac.uk ([10.42.18.57] helo=EX-1-HT0.lancs.local) by sideburn.lancs.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1Vq8Em-0007Jb-UH; Mon, 09 Dec 2013 21:19:33 +0000 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.0158.001; Mon, 9 Dec 2013 21:19:31 +0000 From: "King, Daniel" To: Zongning , LAC Chidung Thread-Topic: [vnfpool] VNF Pool Problem Statement Thread-Index: AQHY+TQ7dY3tQjejG3tIVJ9qDrtQ3QIpAmXyASf3zuYCZZPHvAKcw0hyAt4ScbICsFsViAHVabrCAveJ9ciZot03AA== Date: Mon, 9 Dec 2013 21:19:30 +0000 Message-ID: <65174429B5AF4C45BD0798810EC48E0A0D3C3B@EX-0-MB2.lancs.local> References: <52940EB0.6040601@kddilabs.jp> <529C5A30.3070000@orange.com> <4A95BA014132FF49AE685FAB4B9F17F645C293E9@dfweml509-mbx.china.huawei.com> <52A1FE77.10405@orange.com> <65174429B5AF4C45BD0798810EC48E0A0D38CF@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_65174429B5AF4C45BD0798810EC48E0A0D3C3BEX0MB2lancslocal_" MIME-Version: 1.0 Cc: "vnfpool@ietf.org" , Linda Dunbar Subject: Re: [vnfpool] VNF Pool 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, 09 Dec 2013 21:19:45 -0000 --_000_65174429B5AF4C45BD0798810EC48E0A0D3C3BEX0MB2lancslocal_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ning, Good question, I would modify slightly. If VNF#2 needs to replicate state (= FW or otherwise) to its designated backup (VNF#3), it should probably have = the IP connectivity knowledge to do this. When failure (loss of VNF#2) happ= ens, should the existing network resilience mechanisms route traffic to VNF= #3, without VNF#1 having to detect loss of VNF#2 and switching to VNF#3 ins= tead. Phew, quite a number of permutations. We will update the I-D to encompass t= hese discussions/scenarios. Br, Dan. From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of Zongning Sent: 09 December 2013 02:05 To: King, Daniel; LAC Chidung Cc: vnfpool@ietf.org; Linda Dunbar Subject: Re: [vnfpool] VNF Pool Problem Statement Hi, Daniel, I agree this is a fair question to ask, thanks! Please allow me to ask another question ("a flip side of the coin"): do we = have use case to show that the instance in VNF#1 pool needs to know the sta= ndby address of the instance in VNF#2 pool? For example, suppose we have a = vLB instance (vLB-1) talking to a vFW instance (vFW-1) with two standby ins= tances (vFW-2, vFW-3), if vLB-1 need to know the address of vFW-2, vFW-3, o= r not *in any case*? Anyway, I guess this is a good work for co-authors of use case draft. :) -Ning From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of King, Daniel Sent: Saturday, December 07, 2013 5:02 AM To: LAC Chidung Cc: vnfpool@ietf.org; Linda Dunbar Subject: Re: [vnfpool] VNF Pool Problem Statement Hi Chidung, Thanks for using definitions, and providing the example use cases. The serv= ice chaining and non-service chaining examples are good, but could you also= clarify a deployment, and therefore, solution requirements from an operato= r perspective? Is it expected that client service ("FW" in this use case) resilience would= be typically be provided by each VNF pool sharing the same VLAN, with a vi= rtual server using a "fixed IP" address that maps to a cluster of "dynamic = IP addresses" to multiple VMs, with say one VM for hosting a VNF(s)? Spanni= ng tree would run between the VM instances, and VRRP used to provide backup= for the default gateways. This deployment scenario would support the follo= wing: - Load-balancing across VNFs - Fail-over between VNFs - Migration to new VNFs This architecture would also support mixed environments, where existing pro= priety FW hardware and virtual (VM/VNFs) might be used for migration and te= sting. Actually, the same question to the other operators. It would be real= ly good to understand the thinking behind how best to achieve cost-effectiv= e (time and resources) resilience. As a co-author of "draft-xia-vsnpool-man= agement-use-case" I am trying to figure out if "existing" (VRRP, RSPT, et a= l.) mechanisms are capable of providing client service continuity and distr= ibuted resilience, or indeed we need to document a set of generic requireme= nts that our work in vnfpool will need to solve. Br, Dan. From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of LAC Chidung Sent: 06 December 2013 16:43 To: Linda Dunbar; vnfpool@ietf.org Subject: Re: [vnfpool] VNF Pool Problem Statement Hi Linda, Please correct the following if I'm wrong. Let's define: VNF =3D one type of function. Case 1: no service chaining, e.g., a firewall provides the network service Let's state that 3 firewalls are needed, i.e., 3 instances of the VNF "FW". "VNFs have higher chance to fail due to lack of built-in redundancy" combin= ed with the use of "vnfpool" means: 1) The 3 FW instances are deployed neither in active/active, nor in active/= standby mode, i.e., there are only 3 instances, and not 3 active, and 3 sta= ndby. 2) But this solution is not a trusted one because of "server failure, serve= r over-utilized, or software failure, etc.". 3) Assuming that the load of each (FW) instance is less than 60%, one can g= et HA for this system by using the 3 instances in a pool architecture (base= d on an efficient load balancing mechanism). 4) In this case, the failure of one instance is acceptable because its load= will be shared by the two remaining instances. Case 2: service chaining, e.g., VNF1 and VNF2 are needed in order to provid= e the network service (for instance, a kid requesting a Web page with the u= se of a smartphone -> "parental control" (VNF1) checks the URL, followed by= "header enrichment" (VNF2) which adds the user ID in the media flow) Lets' state that we have 3 instances of VNF1 and 3 instances of VNF2. If we= apply the same reasoning (and hypotheses) as above, we will have a 1st poo= l made up of 3 instances of VNF1, and a 2nd pool made up of 3 instances of = VNF2. The HA of this system is guaranteed if: (i) 1 instance of VNF1 fails,= (ii) 1 instance of VNF2 fails, (iii) 1 instance of VNF2 fails and 1 instan= ce of VNF2 fails. Best, Chidung Le 03/12/2013 21:06, Linda Dunbar a =E9crit : Chidung, Thanks for the quote. Based on your quote, the goal of "vnfpool" should be about to achieve "high= availability" of service function chaining while individual service functi= on instances are NOT reliable. As stated in the problem statement, the vir= tualized network functions have higher chance to fail due to lack of built-= in redundancy, server failure, server over-utilized, or software failure, e= tc. Linda From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of LAC Chidung Sent: Monday, December 02, 2013 4:00 AM To: vnfpool@ietf.org Subject: Re: [vnfpool] VNF Pool Problem Statement Hi all, Reliability is the ability of an item to perform a required function under = stated conditions for a stated period of time, while Availability is a meas= ure of the degree to which an item is in an operable state when called upon= to perform. (D.J. Klinger, Y. Nakada, and M.A. Menedez (Eds.), "AT&T Relia= bility Manual", Van Nostrand Reinhold, 1990) Applied to the PSTN, the former includes "My call is not dropped during a c= onversation", while the latter asks for "The phone service is ready, i.e., = a tone is present, whenever I lift the handset". For years, Dependability has encompassed these concepts (together with othe= rs such as Maintainability) to characterize the good behavior (robustness) = of a system when facing accidental events (design faults, operations errors= , hardware failures, natural disasters, etc.) , while Security, which inclu= des all intentional actions (attacks, ...), is kept apart. This explains th= e presence, up to now, of two communities working in these two separated su= bjects. As (i) unavailability may the consequence of, e.g., software/hardware failu= res OR (D)DoS attacks (ii) Resilience is a fashionable expression* (iii) et= c., resilience is used since the last few years to encompass both dependabi= lity and security. Best, Chidung _______ *: see, e.g., Obama's praise for the resilience of the Indian people (http:= //articles.latimes.com/2010/nov/06/world/la-fgw-obama-mumbai-20101107) Le 02/12/2013 08:21, Cao,Zhen a =E9crit : Good point, Diego. I checked out the NFV ISG released documents of requirements and terminology, where i could not find 'reliability' but 'resilience'. -cz On Wed, Nov 27, 2013 at 2:06 AM, Diego R. Lopez wrote: Hi, When it comes to the reliability/availability issue I guess providing some (condensed) definition from the NFV REL group would help... Be goode, On 26 Nov 2013, at 04:00 , Hidetoshi Yokota wrote: Hi Ning and all, The proposed PS is a very good starting point covering major issues for the goal of VNF pool. One thing that I could add is the synchronization between the vNF migration/replacement and routing to make the relevant flows forwarded to the new location. The challenge is that the VMs/severs in a pool could be deployed over topologically different networks (in the physical world) and VNF migration could involve topologically independent routing. There are multiple ways to do it, but we should first generalize this issue and specify a common mechanism that may leverage existing ones. If this is already covered, that's fine. If some additional text is useful, the following could be a summary: o Synchronization between vNF migration and flow forwarding, which may require topologically independent routing in the physical transport network= ; There is a discussion about "reliability" and "availability" in another thread and I think this is also an issue in ETSI NFV. We need to define the= m either in this group or NFV to share the same view. Regards, -- Hidetoshi Yokota KDDI R&D Laboratories, Inc. e-mail:yokota@kddilabs.jp (2013/11/21 18:11), Zongning wrote: Hi, Please review the below brief version of VNF Pool Problem Statement, and feedback with your comments. I hope this text can serve as a base of VNF Pool Charter, by carving out real problems and work items. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D A virtualized network function (VNF) (e.g. vFW, vLB) provides the same function as the equivalent network function (e.g. FW, LB), but is usually instantiated as a cluster of software instances running on general purpose servers via virtualization platform. In an environment based on VNFs, a network service is typically realized by a chain of VNFs where the instance= s of adjacent VNFs are preferably directly connected. A VNF chain introduces additional points of failure beyond those inherent i= n a single dedicated server, and therefore additional challenges on reliability. By reliability, we mean the ability of a VNF chain to continue function when having transition or failure within the chain. For example, there are more factors such as software failure, server over-utilization, instance migration that potentially cause VNF instance transition or failure. Although a general pooling mechanism can be applied to address the reliability of a single VNF, there are still problems when addressing the reliability of a VNF chain, i.e. multiple pools for multiple VNFs. For example, how does an instance of VNF#1 know which instance in the pool of VNF#2 will replace the instance of VNF#2 it connects to? How does an instance of VNF#1 know the state of instance of VNF#2 that it connects to i= n order to enforce policy for reliability like load sharing, switch before break? How is the service state of an instance held and accessed for efficient synchronization with backup instances? The overall problem space can be further breakdown to the following study items: - Signalling to handle reliability and instance transition requirements o Signalling between VNF pools for transition (e.g. state change, scaling= , moving) notification, backup announcement; o Service state management (e.g. synchronizing method, state data format, location and mechanism to access state data) within VNF pool; o Obtaining underlying network information (e.g. ALTO, I2RS); o Signalling to CMS for instance deployment reflecting reliability requirements (e.g. distribution of instances on different VMs or hypervisors); - Transport characteristics o Identify and analyze reliable transport characteristics for control plane traffic; o Analysis of transport security characteristics to provide protection against known threats, and identification of an appropriate trust model; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Thanks. -Ning -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego@tid.es Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------------- vnfpool mailing list vnfpool@ietf.org https://www.ietf.org/mailman/listinfo/vnfpool --_000_65174429B5AF4C45BD0798810EC48E0A0D3C3BEX0MB2lancslocal_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Ning,

 <= /p>

Br, Dan.

From= : vnfpool [mailto:v= nfpool-bounces@ietf.org] On Behalf Of Zongning
Sent: 09 December 2013 02:05
To: King, Daniel; LAC Chidung
Cc: vnfpool@ietf.org; Linda Dunbar
Subject: Re: [vnfpool] VNF Pool Problem Statement<= /p>

 

Hi, Daniel,

 

I agree this is a fair question to ask, thanks!=

Please allow me to ask another question (“a flip sid= e of the coin”): do we have use case to show that the instance in VNF#1 pool needs to know the standby address of the instance in VNF#2 pool= ? For example, suppose we have a vLB instance (vLB-1) talking to a vFW inst= ance (vFW-1) with two standby instances (vFW-2, vFW-3), if vLB-1 need to kn= ow the address of vFW-2, vFW-3, or not *in any case*?

Anyway, I guess this is a good work for co-authors of use = case draft. J

 

-Ning

 

From: vnfpool [mailto:vnfpool-bounce= s@ietf.org] On Behalf Of King, Daniel
Sent: Saturday, December 07, 2013 5:02 AM
To: LAC Chidung
Cc: vnfpool@ietf.org; Linda = Dunbar
Subject: Re: [vnfpool] VNF Pool Problem Statement<= /p>

 

From: vnfpool [mailto:vnfpool-bounce= s@ietf.org] On Behalf Of LAC Chidung
Sent: 06 December 2013 16:43
To: Linda Dunbar; vnfpool@ietf.o= rg
Subject: Re: [vnfpool] VNF Pool Problem Statement<= /p>

&nbs= p;

Hi Linda,
Please correct the following if I'm wrong.
Let's define: VNF =3D one type of function.
Case 1: no service chaining, e.g., a firewall provides the network s= ervice
Let's state that 3 firewalls are needed, i.e., 3 instances of the VNF "= ;FW".
"VNFs have higher chance to fail due to lack of built-in redunda= ncy" combined with the use of "vnfpool"= ; means:
1) The 3 FW instances are deployed neither in active/active, nor in active/= standby mode, i.e., there are only 3 instances, and not 3 active, and 3 sta= ndby.
2) But this solution is not a trusted one because of "server fai= lure, server over-utilized, or software failure, etc.".
3) Assuming that the load of each (FW) instance is less than 60%, one can g= et HA for this system by using the 3 instances in a pool architecture (base= d on an efficient load balancing mechanism).
4) In this case, the failure of one instance is acceptable because its load= will be shared by the two remaining instances.
Case 2: service chaining, e.g., VNF1 and VNF2 are needed in order to= provide the network service (for instance, a kid requesting a Web page wit= h the use of a smartphone -> "parental control" (VNF1) checks = the URL, followed by "header enrichment" (VNF2) which adds the user ID in the media flow)
Lets' state that we have 3 instances of VNF1 and 3 instances of VNF2. If we= apply the same reasoning (and hypotheses) as above, we will have a 1st poo= l made up of 3 instances of VNF1, and a 2nd pool made up of 3 instances of = VNF2. The HA of this system is guaranteed if: (i) 1 instance of VNF1 fails, (ii) 1 instance of VNF2 fails, (iii) 1 i= nstance of VNF2 fails and 1 instance of VNF2 fails.
Best,
Chidung=

Le 03/12/2013 21:06, Linda Dunbar a =E9crit :

=

From: vnfpool [mailto:vnfpool-bounce= s@ietf.org] On Behalf Of LAC Chidung
Sent: Monday, December 02, 2013 4:00 AM
To: vnfpool@ietf.org
Subject: Re: [vnfpool] VNF Pool Problem Statement

 

Hi all,
Reliability is the ability of an item to perform a required function und= er stated conditions for a stated period of time, while Availability= is a measure of the degree to which an item is in an operable state when c= alled upon to perform. (D.J. Klinger, Y. Nakada, and M.A. Menedez (Eds.), "AT&T Reliability Ma= nual", Van Nostrand Reinhold, 1990)
Applied to the PSTN, the former includes "My call is not dropped durin= g a conversation", while the latter asks for "The phone service i= s ready, i.e., a tone is present, whenever I lift the handset".
For years, Dependability has encompassed these concepts (together wi= th others such as Maintainability) to characterize the good behavior (robustness) of a= system when facing accidental events (design faults, operations errors, hardware failur= es, natural disasters, etc.) , while Security, which includes all intentional actions (attacks, ..= .), is kept apart. This explains the presence, up to now, of two communitie= s working in these two separated subjects.
As (i) unavailability may the consequence of, e.g., software/hardware failu= res OR (D)DoS attacks (ii) Resilience is a fashionable expression* (iii) etc., resilience is us= ed since the last few years to encompass both dependability and security. Best,
Chidung
_______
*: see, e.g., Obama's praise for the resilience of the Indian people (http://articles.latimes.com/2010/nov/06/world/la-fgw-obama-mumbai-20= 101107)

Le 02/12/2013 08:21, Cao,Zhen a =E9crit :

Good point, Diego.
I checked out the NFV ISG released documents of r=
equirements and
terminology, where i could not find 'reliability'=
 but 'resilience'.
-cz
 
On Wed, Nov 27, 2013 at 2:06 AM, Diego R. Lopez <=
a href=3D"mailto:diego@tid.es"><diego@tid.es> wrote:
Hi,
When it comes to the reliability/availability iss=
ue I guess providing some
(condensed) definition from the NFV REL group wou=
ld help...
Be goode,
 
On 26 Nov 2013, at 04:00 , Hidetoshi Yokota wrote=
:
 
Hi Ning and all,
The proposed PS is a very good starting point cov=
ering major issues for the
goal of VNF pool. One thing that I could add is t=
he synchronization between
the vNF migration/replacement and routing to make=
 the relevant flows
forwarded to the new location. The challenge is t=
hat the VMs/severs in a
pool could be deployed over topologically differe=
nt networks (in the
physical world) and VNF migration could involve t=
opologically independent
routing. There are multiple ways to do it, but we=
 should first generalize
this issue and specify a common mechanism that ma=
y leverage existing ones.
If this is already covered, that's fine. If some =
additional text is useful,
the following could be a summary:
o Synchronization between vNF migration and flow =
forwarding, which may
require topologically independent routing in the =
physical transport network;
There is a discussion about "reliability&quo=
t; and "availability" in another
thread and I think this is also an issue in ETSI =
NFV. We need to define them
either in this group or NFV to share the same vie=
w.
Regards,
--
Hidetoshi Yokota
 
KDDI R&D Laboratories, Inc.=

e-ma=
il:yokota@kddilabs.jp
 
(2013/11/21 18:11), Zongning wrote:
 
Hi,
Please review the below brief version of VNF Pool=
 Problem Statement, and
feedback with your comments. I hope this text can=
 serve as a base of VNF
Pool Charter, by carving out real problems and wo=
rk items.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

A virtualized network function (VNF) (e.g. vFW, v=
LB) provides the same
function as the equivalent network function (e.g.=
 FW, LB), but is usually
instantiated as a cluster of software instances r=
unning on general purpose
servers via virtualization platform. In an enviro=
nment based on VNFs, a
network service is typically realized by a chain =
of VNFs where the instances
of adjacent VNFs are preferably directly connecte=
d.
A VNF chain introduces additional points of failu=
re beyond those inherent in
a single dedicated server, and therefore addition=
al challenges on
reliability. By reliability, we mean the ability =
of a VNF chain to continue
function when having transition or failure within=
 the chain. For example,
there are more factors such as software failure, =
server over-utilization,
instance migration that potentially cause VNF ins=
tance transition or
failure. Although a general pooling mechanism can=
 be applied to address the
reliability of a single VNF, there are still prob=
lems when addressing the
reliability of a VNF chain, i.e. multiple pools f=
or multiple VNFs. For
example, how does an instance of VNF#1 know which=
 instance in the pool of
VNF#2 will replace the instance of VNF#2 it conne=
cts to? How does an
instance of VNF#1 know the state of instance of V=
NF#2 that it connects to in
order to enforce policy for reliability like load=
 sharing, switch before
break? How is the service state of an instance he=
ld and accessed for
efficient synchronization with backup instances?<=
o:p>
The overall problem space can be further breakdow=
n to the following study
items:
-        =
  Signalling to handle reliability and instance transition<=
/span>
requirements
o   Signalling between VNF pools for tr=
ansition (e.g. state change, scaling,
moving) notification, backup announcement;
o   Service state management (e.g. sync=
hronizing method, state data format,
location and mechanism to access state data) with=
in VNF pool;
o   Obtaining underlying network inform=
ation (e.g. ALTO, I2RS);
o   Signalling to CMS for instance depl=
oyment reflecting reliability
requirements (e.g. distribution of instances on d=
ifferent VMs or
hypervisors);
-        =
  Transport characteristics
o   Identify and analyze reliable trans=
port characteristics for control
plane traffic;
o   Analysis of transport security char=
acteristics to provide protection
against known threats, and identification of an a=
ppropriate trust model;
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

Thanks.
-Ning
 
--
"Esta vez no fallaremos, Doctor Infierno&quo=
t;
 
Dr Diego R. Lopez
Telefonica I+D
htt=
p://people.tid.es/diego.lopez/
 
e-mail: diego@tid=
.es
Tel:    +34 913 129 041
Mobile: +34 682 051 091

-----------------------------------------


 


vnfpool mailing list


vnfpool@ietf.=
org


https://www.ietf.org/mailman/listinfo/vnfpool
--_000_65174429B5AF4C45BD0798810EC48E0A0D3C3BEX0MB2lancslocal_-- From zongning@huawei.com Mon Dec 9 17:42:01 2013 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 319B91AC829 for ; Mon, 9 Dec 2013 17:42:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.202 X-Spam-Level: X-Spam-Status: No, score=-104.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 qiEL3yQ5JIwj for ; Mon, 9 Dec 2013 17:41:58 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 53BFF1AC4C1 for ; Mon, 9 Dec 2013 17:41:56 -0800 (PST) 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 BBE54218; Tue, 10 Dec 2013 01:41:50 +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; Tue, 10 Dec 2013 01:41:44 +0000 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 10 Dec 2013 01:41:49 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Tue, 10 Dec 2013 09:41:44 +0800 From: Zongning To: "King, Daniel" , "Diego R. Lopez" , Melinda Shore Thread-Topic: [vnfpool] VNF Pool Problem Statement Thread-Index: Ac7mmacuBQUiFtBEQ2CEYoAlHpu1YwDduMMAAB+kuIABF0DFAAAFh5wAAEd4ZIAAj75rgAAJEGmAAH9axeD//4RegIABFcEAgAAVFID//yKLEA== Date: Tue, 10 Dec 2013 01:41:43 +0000 Message-ID: References: <52940EB0.6040601@kddilabs.jp> <529C5A30.3070000@orange.com> <4A95BA014132FF49AE685FAB4B9F17F645C293E9@dfweml509-mbx.china.huawei.com> <52A1FE77.10405@orange.com> <65174429B5AF4C45BD0798810EC48E0A0D38CF@EX-0-MB2.lancs.local> <52A52A3F.4060503@nomountain.net> <65174429B5AF4C45BD0798810EC48E0A0D3C0B@EX-0-MB2.lancs.local> In-Reply-To: <65174429B5AF4C45BD0798810EC48E0A0D3C0B@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.28] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "" Subject: Re: [vnfpool] VNF Pool 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: Tue, 10 Dec 2013 01:42:01 -0000 SGksIERhbmllbCwNCg0KVGhhbmtzIGZvciBzdGFydGluZyB0YWxraW5nIGFib3V0IGFyY2hpdGVj dHVyZS4gOikNCkkgYWN0dWFsbHkgcHV0IHNvbWUgdGV4dCBhYm91dCBWTkYgcG9vbCBhcmNoaXRl Y3R1cmUgaW4gbXkgZWFybHkgcG9zdCBvbiBiYXIgQm9GIHN1bW1hcnkuIFBsZWFzZSBzZWUgYXR0 YWNoZWQgUERGLiBTb21lIHN0cmF3LW1hbiBwb2ludHMgYmVsb3c6DQrigKJNdWx0aXBsZSBwb29s cyBmb3IgbXVsdGlwbGUgVk5Gcywgd2l0aCBlYWNoIHBvb2wgaGF2aW5nIHBvb2wgbWVtYmVycyAo Vk5GIGluc3RhbmNlcykgcHJvdmlkaW5nIHNhbWUgZnVuY3Rpb247DQrigKJFYWNoIHBvb2wgaGFz IGEgKGxvZ2ljYWwgb3IgcGh5c2ljYWwpIG1hbmFnZXIgdGhhdCBpbnRlcmFjdHMgd2l0aCBwb29s IG1lbWJlcnMgZm9yIHJlZHVuZGFuY3kgbWVjaGFuaXNtcywgZS5nLiBhY3RpdmUtc3RhbmRieSBt YW5hZ2VtZW50Ow0K4oCiUG9vbCBtYW5hZ2VyIG9mIGFkamFjZW50IHBvb2xzIGNhbiB0YWxrIHRv IGVhY2ggb3RoZXIgdG8gYWNoaWV2ZSByZWR1bmRhbmN5IGFtb25nIHRoZSBWTkYgY2hhaW4sIGUu Zy4gcG9vbCBzdGF0dXMgbm90aWZpY2F0aW9uOw0KQnV0IEkgYWJzb2x1dGVseSBhZ3JlZSB3aXRo IHlvdXIgaWRlYSB0aGF0IGl0IHdvdWxkIGJlIGdvb2QgdG8gc3RhcnQgd29ya2luZyBvbiAoYXJj aGl0ZWN0dXJlKSBkb2N1bWVudC4gU291bmRzIGxpa2UgeW91IGFyZSB3aWxsaW5nIHRvIGNvbnRy aWJ1dGUgc29tZSB0ZXh0LiA6KQ0KVGhhbmtzLg0KDQotTmluZw0KDQoNCj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogdm5mcG9vbCBbbWFpbHRvOnZuZnBvb2wtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIEtpbmcsIERhbmllbA0KPiBTZW50OiBUdWVzZGF5LCBEZWNl bWJlciAxMCwgMjAxMyA0OjE2IEFNDQo+IFRvOiBEaWVnbyBSLiBMb3BlejsgTWVsaW5kYSBTaG9y ZQ0KPiBDYzogPHZuZnBvb2xAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJlOiBbdm5mcG9vbF0gVk5G IFBvb2wgUHJvYmxlbSBTdGF0ZW1lbnQNCj4gDQo+IEhpIEFsbCwNCj4gDQo+IFJlOiBEZXBsb3lt ZW50IFNjZW5hcmlvcw0KPiANCj4gU291bmRzIGdvb2QsIGl0IHdhcyBqdXN0IGEgZ2VudGxlIHJl bWluZGVyIHRoYXQgdGhlIG1vZGVsIHdlIHNldHRsZSBvbiBzaG91bGQNCj4gZml0IHdpdGggZXhp c3RpbmcvcGxhbm5lZCBkZXBsb3ltZW50IHNjZW5hcmlvcywgYW5kIG5ldHdvcmsgcmVzaWxpZW5j ZQ0KPiBtZWNoYW5pc21zLiBBcyB3ZSBkZXZlbG9wIHRoZSB2bmZwb29sIHByb2JsZW0gc3RhdGVt ZW50LCB3ZSBhcmUgY2FwdHVyaW5nDQo+IHRoZSBzY29wZSBhbmQga2V5IHByb2JsZW1zIHRoYXQg aW5mb3JtIHRoZSBzb2x1dGlvbiB3b3JrLCBidXQgaWRlYWxseSB0aGVzZQ0KPiBzaG91bGQgYmUg Z3VpZGVkIGJ5IGhvdyBvcGVyYXRvcnMgYW5kIHNlcnZpY2UgcHJvdmlkZXJzIHBsYW4gdG8gdXNl IFZORnMgaW4NCj4gdGhlIGZpZWxkLiBPcGVyYXRvcnMgdGhhdCBoYXZlIE5GViB0cmlhbHMgYW5k IHByb3RvdHlwZXMsIHByb3ZpZGVzIHZhbHVhYmxlIGRhdGENCj4gdG8gdXNlIGZvciB0aGUgc29s dXRpb24gd29yaywgd2UganVzdCBuZWVkIHRvIGVuY291cmFnZSB0aGVtIHRvIGFzc2lnbiBtb3Jl DQo+IENQVSBjeWNsZXMgdG8gdGhlIHZuZnBvb2wgbWFpbGluZyBsaXN0LiA7LSkNCj4gDQo+IFJl OiAoaGlnaC1sZXZlbCkgQXJjaGl0ZWN0dXJlDQo+IA0KPiBJdCB3b3VsZCBiZSBncmVhdCB0byB2 aXN1YWxpc2UgdGhlIGFyY2hpdGVjdHVyZSAoQVNDSUkgb3Igb3RoZXJ3aXNlKSwgc3BlY2lmaWNh bGx5DQo+IHRoZSBjb21wb25lbnRzLCByZWxhdGlvbnNoaXBzLCBpbnRlcmFjdGlvbnMgYW5kIGlu dGVyZmFjZXMgcmVxdWlyZWQvZXhwZWN0ZWQNCj4gYmFzZWQgb24gdGhlIHByb2JsZW0gc3RhdGVt ZW50ICh0aHVzIGZhcik6DQo+IA0KPiAtIFZORiBQb29sIE1hbmFnZXIgKGluLXNjb3BlLCBvdXQg b2Ygc2NvcGU/KQ0KPiBvIFJlc2lsaWVudCBpdHNlbGYgKG11bHRpLWluc3RhbmNlKT8NCj4gDQo+ IC0gU2luZ2xlIGluc3RhbmNlIFZORnMsIE11bHRpLWluc3RhbmNlIFZORnMgYW5kIENoYWluZWQg Vk5Gcw0KPiBvIFNpZ25hbGluZyBtZWNoYW5pc21zL2NoYXJhY3RlcmlzdGljcy9yZWxhdGlvbnNo aXBzDQo+IA0KPiAtIEFic3RyYWN0IGludGVyYWN0aW9ucy9yZWxhdGlvbnNoaXBzIGJldHdlZW4g Vk5GIFBvb2wgTWFuYWdlciBhbmQgVk5GcywNCj4gYW5kIFZORiB0byBWTkYocykuDQo+IG8gSW5z dGFudGlhdGlvbg0KPiBvIEFkYXB0YXRpb24NCj4gbyBNaWdyYXRpb24NCj4gbyBGYWlsLW92ZXIN Cj4gbyBMb2FkLWJhbGFuY2luZw0KPiBvIFRlcm1pbmF0aW9uDQo+IA0KPiAtIFZORi9Qb29sIFRv cG9sb2d5IE1hbmFnZW1lbnQNCj4gbyBGdW5jdGlvbnMgYW5kIEludGVyZmFjZXMNCj4gDQo+IC0g IENvbnRyb2wgUGxhbmUNCj4gbyBGdW5jdGlvbnMgYW5kIEludGVyZmFjZXMNCj4gDQo+IC0gUmVs YXRpb25zaGlwIChvciBjb21wbGV0ZWx5IHRyYW5zcGFyZW50Pykgd2l0aCBwaHlzaWNhbCBhbmQg dmlydHVhbCBlbGVtZW50cywNCj4gcHJvdmlkaW5nIGNvbm5lY3Rpdml0eSBhbmQgYWRkaXRpb25h bCBmdW5jdGlvbg0KPiANCj4gQnIsIERhbi4NCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IHZuZnBvb2wgW21haWx0bzp2bmZwb29sLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBEaWVnbyBSLiBMb3Bleg0KPiBTZW50OiAwOSBEZWNlbWJlciAyMDEzIDE5OjAw DQo+IFRvOiBNZWxpbmRhIFNob3JlDQo+IENjOiA8dm5mcG9vbEBpZXRmLm9yZz4NCj4gU3ViamVj dDogUmU6IFt2bmZwb29sXSBWTkYgUG9vbCBQcm9ibGVtIFN0YXRlbWVudA0KPiANCj4gSGksDQo+ IA0KPiBJIGFncmVlIHdpdGggTWVsaW5kYSBpbiB0aGF0IHRoZSBwcm9ibGVtIGhhcyB0byBiZSBj b25maW5lZCB0byB0aGUgVk5GIChhbmQgaXRzDQo+IHBvb2xpbmcgbWFuYWdlcikgYW5kIHRoZSBz ZXJ2aWNlIGNoYWluaW5nIG1hbmFnZW1lbnQgZnVuY3Rpb25zLiBFeHRlcm5hbA0KPiBlbGVtZW50 cywgbGlrZSBvdGhlciB2aXJ0dWFsIGFuZC9vciBwaHlzaWNhbCBuZXR3b3JrIGZ1bmN0aW9ucyBp biBhIGdpdmVuIHBhdGgNCj4gKHRoZSByZWFsaXphdGlvbiBvZiB0aGUgY2hhaW4pIG9yIHVzZXIg YXBwbGljYXRpb25zIHNob3VsZCBiZSBjb21wbGV0ZWx5IG9ibGl2aW91cw0KPiB0byB0aGUgcG9v bGluZyBtZWNoYW5pc21zIGluIHBsYWNlLg0KPiANCj4gQmUgZ29vZGUsDQo+IA0KPiANCj4gT24g OSBEZWMgMjAxMywgYXQgMDM6MjYgLCBNZWxpbmRhIFNob3JlIHdyb3RlOg0KPiANCj4gPiBJIHRo aW5rIERhbmllbCBpcyBhc2tpbmcgZXhhY3RseSB0aGUgcmlnaHQgcXVlc3Rpb25zLiAgQnV0IHRv IGJhY2sgdXANCj4gPiBhIGJpdCwgSSd2ZSBiZWVuIHRoaW5raW5nIGFib3V0IHRoaXMgb3ZlciB0 aGUgd2Vla2VuZCBhbmQgcmVhbGl6ZWQNCj4gPiB0aGF0IHRoZSBzY2VuYXJpbyBpcyBhY3R1YWxs eSBzaW1wbGVyIHRoYW4gSSdkIGJlZW4gY29uc2lkZXJpbmcuICBJZg0KPiA+IHRoZSBWTkYgaW5z dGFuY2VzIGFyZSBwb29sZWQgYWxvbmcgdGhlIGdlbmVyYWwgbGluZXMgb2Ygc29tZXRoaW5nIGxp a2UNCj4gPiByc2VycG9vbCwgaXQgaXMgbm90IHRoZSBjYXNlIHRoYXQgYW4gZXh0ZXJuYWwgY2xp ZW50IHdpbGwgbmVlZCB0byBiZQ0KPiA+IG1vZGlmaWVkLiAgVGhlIG9ubHkgZWxlbWVudHMgd2hp Y2ggd291bGQgbmVlZCB0byBiZSBhYmxlIHRvICJ0YWxrIiB0aGUNCj4gPiBwb29saW5nIHByb3Rv Y29sIGFyZSBhbHJlYWR5IHBhcnRpY2lwYXRpbmcgLSB0aGV5J2QgYmUgdGhlIHBvb2wNCj4gPiBt YW5hZ2VyIGFuZCB3aGF0ZXZlciBzZXJ2aWNlIGNoYWluIG1hbmFnZW1lbnQgZnVuY3Rpb24gaXMg YmVpbmcgdXNlZCwNCj4gPiB0aGUgcG9vbCBtZW1iZXJzLCBhbmQgYWRqYWNlbnQgcG9vbHMuICBT byBJIHRoaW5rIHdlJ3JlIGluIGdvb2Qgc2hhcGUNCj4gPiB0aGVyZTsgd2UgY291bGQgcHJvYmFi bHkgdXNlIHNvbWUgYmV0dGVyIHRleHQgYXJvdW5kIHRoaXMgdG8gbWFrZSBpdA0KPiA+IGNsZWFy ZXIuDQo+ID4NCj4gPiBNZWxpbmRhDQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gPiB2bmZwb29sIG1haWxpbmcgbGlzdA0KPiA+IHZuZnBvb2xA aWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3ZuZnBv b2wNCj4gDQo+IA0KPiAtLQ0KPiAiRXN0YSB2ZXogbm8gZmFsbGFyZW1vcywgRG9jdG9yIEluZmll cm5vIg0KPiANCj4gRHIgRGllZ28gUi4gTG9wZXoNCj4gVGVsZWZvbmljYSBJK0QNCj4gaHR0cDov L3Blb3BsZS50aWQuZXMvZGllZ28ubG9wZXovDQo+IA0KPiBlLW1haWw6IGRpZWdvQHRpZC5lcw0K PiBUZWw6ICAgICszNCA5MTMgMTI5IDA0MQ0KPiBNb2JpbGU6ICszNCA2ODIgMDUxIDA5MQ0KPiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gDQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IA0KPiBFc3RlIG1lbnNhamUgc2UgZGlyaWdl IGV4Y2x1c2l2YW1lbnRlIGEgc3UgZGVzdGluYXRhcmlvLiBQdWVkZSBjb25zdWx0YXINCj4gbnVl c3RyYSBwb2zDrXRpY2EgZGUgZW52w61vIHkgcmVjZXBjacOzbiBkZSBjb3JyZW8gZWxlY3Ryw7Nu aWNvIGVuIGVsIGVubGFjZQ0KPiBzaXR1YWRvIG3DoXMgYWJham8uDQo+IFRoaXMgbWVzc2FnZSBp cyBpbnRlbmRlZCBleGNsdXNpdmVseSBmb3IgaXRzIGFkZHJlc3NlZS4gV2Ugb25seSBzZW5kIGFu ZA0KPiByZWNlaXZlIGVtYWlsIG9uIHRoZSBiYXNpcyBvZiB0aGUgdGVybXMgc2V0IG91dCBhdDoN Cj4gaHR0cDovL3d3dy50aWQuZXMvRVMvUEFHSU5BUy9kaXNjbGFpbWVyLmFzcHgNCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gdm5mcG9vbCBtYWls aW5nIGxpc3QNCj4gdm5mcG9vbEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3ZuZnBvb2wNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gdm5mcG9vbCBtYWlsaW5nIGxpc3QNCj4gdm5mcG9vbEBpZXRmLm9y Zw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3ZuZnBvb2wNCg== From zongning@huawei.com Mon Dec 9 17:43:22 2013 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 5B01F1AE09D for ; Mon, 9 Dec 2013 17:43:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.202 X-Spam-Level: X-Spam-Status: No, score=-104.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 Nst4WCYSsCLu for ; Mon, 9 Dec 2013 17:43:19 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1DEC61AC4C1 for ; Mon, 9 Dec 2013 17:43:17 -0800 (PST) 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 AYU28782; Tue, 10 Dec 2013 01:43:12 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 10 Dec 2013 01:43:02 +0000 Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 10 Dec 2013 01:43:07 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Tue, 10 Dec 2013 09:43:01 +0800 From: Zongning To: "King, Daniel" , "Diego R. Lopez" , Melinda Shore Thread-Topic: [vnfpool] VNF Pool Problem Statement Thread-Index: Ac7mmacuBQUiFtBEQ2CEYoAlHpu1YwDduMMAAB+kuIABF0DFAAAFh5wAAEd4ZIAAj75rgAAJEGmAAH9axeD//4RegIABFcEAgAAVFID//yKLEP/+QUBw Date: Tue, 10 Dec 2013 01:43:01 +0000 Message-ID: References: <52940EB0.6040601@kddilabs.jp> <529C5A30.3070000@orange.com> <4A95BA014132FF49AE685FAB4B9F17F645C293E9@dfweml509-mbx.china.huawei.com> <52A1FE77.10405@orange.com> <65174429B5AF4C45BD0798810EC48E0A0D38CF@EX-0-MB2.lancs.local> <52A52A3F.4060503@nomountain.net> <65174429B5AF4C45BD0798810EC48E0A0D3C0B@EX-0-MB2.lancs.local> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.28] Content-Type: multipart/mixed; boundary="_002_B0D29E0424F2DE47A0B36779EC666779258596DBnkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "" Subject: Re: [vnfpool] VNF Pool 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: Tue, 10 Dec 2013 01:43:22 -0000 --_002_B0D29E0424F2DE47A0B36779EC666779258596DBnkgeml501mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T29vcHMsIGZvcmdvdCB0aGUgZmlsZS4gSGVyZSBpdCBpcy4uLg0KDQo+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+IEZyb206IFpvbmduaW5nDQo+IFNlbnQ6IFR1ZXNkYXksIERlY2VtYmVy IDEwLCAyMDEzIDk6NDIgQU0NCj4gVG86ICdLaW5nLCBEYW5pZWwnOyBEaWVnbyBSLiBMb3Blejsg TWVsaW5kYSBTaG9yZQ0KPiBDYzogPHZuZnBvb2xAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJFOiBb dm5mcG9vbF0gVk5GIFBvb2wgUHJvYmxlbSBTdGF0ZW1lbnQNCj4gDQo+IEhpLCBEYW5pZWwsDQo+ IA0KPiBUaGFua3MgZm9yIHN0YXJ0aW5nIHRhbGtpbmcgYWJvdXQgYXJjaGl0ZWN0dXJlLiA6KQ0K PiBJIGFjdHVhbGx5IHB1dCBzb21lIHRleHQgYWJvdXQgVk5GIHBvb2wgYXJjaGl0ZWN0dXJlIGlu IG15IGVhcmx5IHBvc3Qgb24gYmFyDQo+IEJvRiBzdW1tYXJ5LiBQbGVhc2Ugc2VlIGF0dGFjaGVk IFBERi4gU29tZSBzdHJhdy1tYW4gcG9pbnRzIGJlbG93Og0KPiDigKJNdWx0aXBsZSBwb29scyBm b3IgbXVsdGlwbGUgVk5Gcywgd2l0aCBlYWNoIHBvb2wgaGF2aW5nIHBvb2wgbWVtYmVycyAoVk5G DQo+IGluc3RhbmNlcykgcHJvdmlkaW5nIHNhbWUgZnVuY3Rpb247DQo+IOKAokVhY2ggcG9vbCBo YXMgYSAobG9naWNhbCBvciBwaHlzaWNhbCkgbWFuYWdlciB0aGF0IGludGVyYWN0cyB3aXRoIHBv b2wNCj4gbWVtYmVycyBmb3IgcmVkdW5kYW5jeSBtZWNoYW5pc21zLCBlLmcuIGFjdGl2ZS1zdGFu ZGJ5IG1hbmFnZW1lbnQ7DQo+IOKAolBvb2wgbWFuYWdlciBvZiBhZGphY2VudCBwb29scyBjYW4g dGFsayB0byBlYWNoIG90aGVyIHRvIGFjaGlldmUgcmVkdW5kYW5jeQ0KPiBhbW9uZyB0aGUgVk5G IGNoYWluLCBlLmcuIHBvb2wgc3RhdHVzIG5vdGlmaWNhdGlvbjsNCj4gQnV0IEkgYWJzb2x1dGVs eSBhZ3JlZSB3aXRoIHlvdXIgaWRlYSB0aGF0IGl0IHdvdWxkIGJlIGdvb2QgdG8gc3RhcnQgd29y a2luZyBvbg0KPiAoYXJjaGl0ZWN0dXJlKSBkb2N1bWVudC4gU291bmRzIGxpa2UgeW91IGFyZSB3 aWxsaW5nIHRvIGNvbnRyaWJ1dGUgc29tZSB0ZXh0LiA6KQ0KPiBUaGFua3MuDQo+IA0KPiAtTmlu Zw0KPiANCj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiB2bmZw b29sIFttYWlsdG86dm5mcG9vbC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgS2luZywg RGFuaWVsDQo+ID4gU2VudDogVHVlc2RheSwgRGVjZW1iZXIgMTAsIDIwMTMgNDoxNiBBTQ0KPiA+ IFRvOiBEaWVnbyBSLiBMb3BlejsgTWVsaW5kYSBTaG9yZQ0KPiA+IENjOiA8dm5mcG9vbEBpZXRm Lm9yZz4NCj4gPiBTdWJqZWN0OiBSZTogW3ZuZnBvb2xdIFZORiBQb29sIFByb2JsZW0gU3RhdGVt ZW50DQo+ID4NCj4gPiBIaSBBbGwsDQo+ID4NCj4gPiBSZTogRGVwbG95bWVudCBTY2VuYXJpb3MN Cj4gPg0KPiA+IFNvdW5kcyBnb29kLCBpdCB3YXMganVzdCBhIGdlbnRsZSByZW1pbmRlciB0aGF0 IHRoZSBtb2RlbCB3ZSBzZXR0bGUgb24NCj4gc2hvdWxkDQo+ID4gZml0IHdpdGggZXhpc3Rpbmcv cGxhbm5lZCBkZXBsb3ltZW50IHNjZW5hcmlvcywgYW5kIG5ldHdvcmsgcmVzaWxpZW5jZQ0KPiA+ IG1lY2hhbmlzbXMuIEFzIHdlIGRldmVsb3AgdGhlIHZuZnBvb2wgcHJvYmxlbSBzdGF0ZW1lbnQs IHdlIGFyZQ0KPiBjYXB0dXJpbmcNCj4gPiB0aGUgc2NvcGUgYW5kIGtleSBwcm9ibGVtcyB0aGF0 IGluZm9ybSB0aGUgc29sdXRpb24gd29yaywgYnV0IGlkZWFsbHkgdGhlc2UNCj4gPiBzaG91bGQg YmUgZ3VpZGVkIGJ5IGhvdyBvcGVyYXRvcnMgYW5kIHNlcnZpY2UgcHJvdmlkZXJzIHBsYW4gdG8g dXNlIFZORnMgaW4NCj4gPiB0aGUgZmllbGQuIE9wZXJhdG9ycyB0aGF0IGhhdmUgTkZWIHRyaWFs cyBhbmQgcHJvdG90eXBlcywgcHJvdmlkZXMgdmFsdWFibGUNCj4gZGF0YQ0KPiA+IHRvIHVzZSBm b3IgdGhlIHNvbHV0aW9uIHdvcmssIHdlIGp1c3QgbmVlZCB0byBlbmNvdXJhZ2UgdGhlbSB0byBh c3NpZ24gbW9yZQ0KPiA+IENQVSBjeWNsZXMgdG8gdGhlIHZuZnBvb2wgbWFpbGluZyBsaXN0LiA7 LSkNCj4gPg0KPiA+IFJlOiAoaGlnaC1sZXZlbCkgQXJjaGl0ZWN0dXJlDQo+ID4NCj4gPiBJdCB3 b3VsZCBiZSBncmVhdCB0byB2aXN1YWxpc2UgdGhlIGFyY2hpdGVjdHVyZSAoQVNDSUkgb3Igb3Ro ZXJ3aXNlKSwNCj4gc3BlY2lmaWNhbGx5DQo+ID4gdGhlIGNvbXBvbmVudHMsIHJlbGF0aW9uc2hp cHMsIGludGVyYWN0aW9ucyBhbmQgaW50ZXJmYWNlcyByZXF1aXJlZC9leHBlY3RlZA0KPiA+IGJh c2VkIG9uIHRoZSBwcm9ibGVtIHN0YXRlbWVudCAodGh1cyBmYXIpOg0KPiA+DQo+ID4gLSBWTkYg UG9vbCBNYW5hZ2VyIChpbi1zY29wZSwgb3V0IG9mIHNjb3BlPykNCj4gPiBvIFJlc2lsaWVudCBp dHNlbGYgKG11bHRpLWluc3RhbmNlKT8NCj4gPg0KPiA+IC0gU2luZ2xlIGluc3RhbmNlIFZORnMs IE11bHRpLWluc3RhbmNlIFZORnMgYW5kIENoYWluZWQgVk5Gcw0KPiA+IG8gU2lnbmFsaW5nIG1l Y2hhbmlzbXMvY2hhcmFjdGVyaXN0aWNzL3JlbGF0aW9uc2hpcHMNCj4gPg0KPiA+IC0gQWJzdHJh Y3QgaW50ZXJhY3Rpb25zL3JlbGF0aW9uc2hpcHMgYmV0d2VlbiBWTkYgUG9vbCBNYW5hZ2VyIGFu ZCBWTkZzLA0KPiA+IGFuZCBWTkYgdG8gVk5GKHMpLg0KPiA+IG8gSW5zdGFudGlhdGlvbg0KPiA+ IG8gQWRhcHRhdGlvbg0KPiA+IG8gTWlncmF0aW9uDQo+ID4gbyBGYWlsLW92ZXINCj4gPiBvIExv YWQtYmFsYW5jaW5nDQo+ID4gbyBUZXJtaW5hdGlvbg0KPiA+DQo+ID4gLSBWTkYvUG9vbCBUb3Bv bG9neSBNYW5hZ2VtZW50DQo+ID4gbyBGdW5jdGlvbnMgYW5kIEludGVyZmFjZXMNCj4gPg0KPiA+ IC0gIENvbnRyb2wgUGxhbmUNCj4gPiBvIEZ1bmN0aW9ucyBhbmQgSW50ZXJmYWNlcw0KPiA+DQo+ ID4gLSBSZWxhdGlvbnNoaXAgKG9yIGNvbXBsZXRlbHkgdHJhbnNwYXJlbnQ/KSB3aXRoIHBoeXNp Y2FsIGFuZCB2aXJ0dWFsDQo+IGVsZW1lbnRzLA0KPiA+IHByb3ZpZGluZyBjb25uZWN0aXZpdHkg YW5kIGFkZGl0aW9uYWwgZnVuY3Rpb24NCj4gPg0KPiA+IEJyLCBEYW4uDQo+ID4NCj4gPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IHZuZnBvb2wgW21haWx0bzp2bmZwb29s LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBEaWVnbyBSLiBMb3Bleg0KPiA+IFNlbnQ6 IDA5IERlY2VtYmVyIDIwMTMgMTk6MDANCj4gPiBUbzogTWVsaW5kYSBTaG9yZQ0KPiA+IENjOiA8 dm5mcG9vbEBpZXRmLm9yZz4NCj4gPiBTdWJqZWN0OiBSZTogW3ZuZnBvb2xdIFZORiBQb29sIFBy b2JsZW0gU3RhdGVtZW50DQo+ID4NCj4gPiBIaSwNCj4gPg0KPiA+IEkgYWdyZWUgd2l0aCBNZWxp bmRhIGluIHRoYXQgdGhlIHByb2JsZW0gaGFzIHRvIGJlIGNvbmZpbmVkIHRvIHRoZSBWTkYgKGFu ZA0KPiBpdHMNCj4gPiBwb29saW5nIG1hbmFnZXIpIGFuZCB0aGUgc2VydmljZSBjaGFpbmluZyBt YW5hZ2VtZW50IGZ1bmN0aW9ucy4gRXh0ZXJuYWwNCj4gPiBlbGVtZW50cywgbGlrZSBvdGhlciB2 aXJ0dWFsIGFuZC9vciBwaHlzaWNhbCBuZXR3b3JrIGZ1bmN0aW9ucyBpbiBhIGdpdmVuIHBhdGgN Cj4gPiAodGhlIHJlYWxpemF0aW9uIG9mIHRoZSBjaGFpbikgb3IgdXNlciBhcHBsaWNhdGlvbnMg c2hvdWxkIGJlIGNvbXBsZXRlbHkNCj4gb2JsaXZpb3VzDQo+ID4gdG8gdGhlIHBvb2xpbmcgbWVj aGFuaXNtcyBpbiBwbGFjZS4NCj4gPg0KPiA+IEJlIGdvb2RlLA0KPiA+DQo+ID4NCj4gPiBPbiA5 IERlYyAyMDEzLCBhdCAwMzoyNiAsIE1lbGluZGEgU2hvcmUgd3JvdGU6DQo+ID4NCj4gPiA+IEkg dGhpbmsgRGFuaWVsIGlzIGFza2luZyBleGFjdGx5IHRoZSByaWdodCBxdWVzdGlvbnMuICBCdXQg dG8gYmFjayB1cA0KPiA+ID4gYSBiaXQsIEkndmUgYmVlbiB0aGlua2luZyBhYm91dCB0aGlzIG92 ZXIgdGhlIHdlZWtlbmQgYW5kIHJlYWxpemVkDQo+ID4gPiB0aGF0IHRoZSBzY2VuYXJpbyBpcyBh Y3R1YWxseSBzaW1wbGVyIHRoYW4gSSdkIGJlZW4gY29uc2lkZXJpbmcuICBJZg0KPiA+ID4gdGhl IFZORiBpbnN0YW5jZXMgYXJlIHBvb2xlZCBhbG9uZyB0aGUgZ2VuZXJhbCBsaW5lcyBvZiBzb21l dGhpbmcgbGlrZQ0KPiA+ID4gcnNlcnBvb2wsIGl0IGlzIG5vdCB0aGUgY2FzZSB0aGF0IGFuIGV4 dGVybmFsIGNsaWVudCB3aWxsIG5lZWQgdG8gYmUNCj4gPiA+IG1vZGlmaWVkLiAgVGhlIG9ubHkg ZWxlbWVudHMgd2hpY2ggd291bGQgbmVlZCB0byBiZSBhYmxlIHRvICJ0YWxrIiB0aGUNCj4gPiA+ IHBvb2xpbmcgcHJvdG9jb2wgYXJlIGFscmVhZHkgcGFydGljaXBhdGluZyAtIHRoZXknZCBiZSB0 aGUgcG9vbA0KPiA+ID4gbWFuYWdlciBhbmQgd2hhdGV2ZXIgc2VydmljZSBjaGFpbiBtYW5hZ2Vt ZW50IGZ1bmN0aW9uIGlzIGJlaW5nIHVzZWQsDQo+ID4gPiB0aGUgcG9vbCBtZW1iZXJzLCBhbmQg YWRqYWNlbnQgcG9vbHMuICBTbyBJIHRoaW5rIHdlJ3JlIGluIGdvb2Qgc2hhcGUNCj4gPiA+IHRo ZXJlOyB3ZSBjb3VsZCBwcm9iYWJseSB1c2Ugc29tZSBiZXR0ZXIgdGV4dCBhcm91bmQgdGhpcyB0 byBtYWtlIGl0DQo+ID4gPiBjbGVhcmVyLg0KPiA+ID4NCj4gPiA+IE1lbGluZGENCj4gPiA+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiB2bmZw b29sIG1haWxpbmcgbGlzdA0KPiA+ID4gdm5mcG9vbEBpZXRmLm9yZw0KPiA+ID4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92bmZwb29sDQo+ID4NCj4gPg0KPiA+IC0tDQo+ ID4gIkVzdGEgdmV6IG5vIGZhbGxhcmVtb3MsIERvY3RvciBJbmZpZXJubyINCj4gPg0KPiA+IERy IERpZWdvIFIuIExvcGV6DQo+ID4gVGVsZWZvbmljYSBJK0QNCj4gPiBodHRwOi8vcGVvcGxlLnRp ZC5lcy9kaWVnby5sb3Blei8NCj4gPg0KPiA+IGUtbWFpbDogZGllZ29AdGlkLmVzDQo+ID4gVGVs OiAgICArMzQgOTEzIDEyOSAwNDENCj4gPiBNb2JpbGU6ICszNCA2ODIgMDUxIDA5MQ0KPiA+IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4NCj4gPg0KPiA+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4NCj4gPiBFc3RlIG1lbnNhamUgc2Ug ZGlyaWdlIGV4Y2x1c2l2YW1lbnRlIGEgc3UgZGVzdGluYXRhcmlvLiBQdWVkZSBjb25zdWx0YXIN Cj4gPiBudWVzdHJhIHBvbMOtdGljYSBkZSBlbnbDrW8geSByZWNlcGNpw7NuIGRlIGNvcnJlbyBl bGVjdHLDs25pY28gZW4gZWwgZW5sYWNlDQo+ID4gc2l0dWFkbyBtw6FzIGFiYWpvLg0KPiA+IFRo aXMgbWVzc2FnZSBpcyBpbnRlbmRlZCBleGNsdXNpdmVseSBmb3IgaXRzIGFkZHJlc3NlZS4gV2Ug b25seSBzZW5kIGFuZA0KPiA+IHJlY2VpdmUgZW1haWwgb24gdGhlIGJhc2lzIG9mIHRoZSB0ZXJt cyBzZXQgb3V0IGF0Og0KPiA+IGh0dHA6Ly93d3cudGlkLmVzL0VTL1BBR0lOQVMvZGlzY2xhaW1l ci5hc3B4DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gPiB2bmZwb29sIG1haWxpbmcgbGlzdA0KPiA+IHZuZnBvb2xAaWV0Zi5vcmcNCj4gPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3ZuZnBvb2wNCj4gPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IHZuZnBvb2wgbWFp bGluZyBsaXN0DQo+ID4gdm5mcG9vbEBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vdm5mcG9vbA0K --_002_B0D29E0424F2DE47A0B36779EC666779258596DBnkgeml501mbschi_ Content-Type: application/pdf; name="VNF Pool.pdf" Content-Description: VNF Pool.pdf Content-Disposition: attachment; filename="VNF Pool.pdf"; size=130600; creation-date="Wed, 13 Nov 2013 06:27:02 GMT"; modification-date="Wed, 13 Nov 2013 06:27:03 GMT" Content-Transfer-Encoding: base64 JVBERi0xLjUNCiW1tbW1DQoxIDAgb2JqDQo8PC9UeXBlL0NhdGFsb2cvUGFnZXMgMiAwIFIvTGFu Zyh6aC1DTikgL1N0cnVjdFRyZWVSb290IDE4IDAgUi9NYXJrSW5mbzw8L01hcmtlZCB0cnVlPj4+ Pg0KZW5kb2JqDQoyIDAgb2JqDQo8PC9UeXBlL1BhZ2VzL0NvdW50IDEvS2lkc1sgMyAwIFJdID4+ DQplbmRvYmoNCjMgMCBvYmoNCjw8L1R5cGUvUGFnZS9QYXJlbnQgMiAwIFIvUmVzb3VyY2VzPDwv Rm9udDw8L0YxIDUgMCBSL0YyIDcgMCBSL0YzIDEyIDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0lt YWdlQi9JbWFnZUMvSW1hZ2VJXSA+Pi9NZWRpYUJveFsgMCAwIDcyMCA1NDBdIC9Db250ZW50cyA0 IDAgUi9Hcm91cDw8L1R5cGUvR3JvdXAvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCPj4vVGFi cy9TL1N0cnVjdFBhcmVudHMgMD4+DQplbmRvYmoNCjQgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURl Y29kZS9MZW5ndGggMTk2ND4+DQpzdHJlYW0NCnic7VnLcts2FN1rRv+AmWzITAzjTXLq8SKvTjt1 J23cdpFkoTDyI5GpVLKTcb++9wKgRJAgZMULb7yxDAj3fXFwAJHDN+To6PDkxS8vCTs+Js9fviD/ TieMMMoY40KwghSCEa0YWc2nk3+ekmY64eR8s4Yxw5kKFp09nU7+mE7Iq5MXhHQM8MPfZs05yebN wV9vc2/t+el0cviaE1nRqlTk9AzVg27CiSgN1YooDV9xcnqFNq3hn6eTd9nfv78m+Qdy+ut08gp0 oJ5WUBpBA7l32Ztc8Gy5zA9ktuhIDXwUHbdadUpKqk2oj6SUyPFABeFlEKQUtOAwqwqqjFN+xFhZ HIehYYp6kuBOXzI7uVnkMru+zHX2dTEn+UGRfV0uF2v4z2RnOS+z5Ypc3Syuc5Vdwkq7KJ5EAfqZ CdVDznNeZetnoE9n39HM9YXVPZ/lByKrQeXFaFVKaBgVKkTnxtYrbmgVLq9zzrJlg2ZzrrPZZXMJ gTTnWNZRNRUo6KVpRqzIKucmW958hQiqbHlGMDyIwgaE2WnWeeUtNfV8nbLSFkNoWm6CA/0qW+ZF 9u3yU8fRNRqZXc3toJljLb7nWJkv8B85u8H5pr4GB9CJZfPTWEKZoSY0mWxLlW5LyoSKtWaFbS92 teZA2mekK529srn0XaJt9eED8s1hZrZ2yTdQHqzA1ayZncPS+YpAdq6hFEtyhu1nFWA+F7aLlS8R CNp/RjtaSk6rnke2LCi5ygXqGAMUyHEZSh6MrS04gE+wdBuncT03t6F2Q5g39W1e6OwZtgDko8rm FD50dk4JNv3HWf0Ft69tVpi2fq9zzrf92Q97HDKKksqNc+u5A0VIdA3AYXB/xSPDTlNFKP0sly4u p2aFf75d1rktw0GZdVzcWR8hKsT70DsM+rapL1Youmwu/8t54XQh+iQ2h6poL9Lk5tD7Y7YWVFY7 N0asAF3J7JembeH5aiSYSlEje2Jj/ccZo1yHay3MrjBzDsUQVxYeX+YNzuCWurXnxXvXeRI6zwLU JbaZ6LYZlBW3i4IhaHMHia+G/bJZXmN7nkEbQPE7tXqfY/OWDsZnuFhkHx0MYgvN6gu7FWDtN2yg T5tvPsLwlqQOC59YyWixiRoABDV4EMkFy9bEWbaaDxFL4DgEl9i+cC8Mx9MkMHfm4P6KzKz6z7N6 bitr/Qb1azp60Akqer4ne9X49mTQ3PBHwzENsoqTFdAjrgGrCgA7OL41KSuiDZWF3jAzQb4Dh0KD IG40yoPkn8CpwJXPJCn/NuJMkWJ1XOGR390BvCys+oJRH6xlk9yRug1N09loqXmhIFFEakU3W/tk hqmGSkMpg100cLeMEDwBwAbMLtCYLEDVocrRTL4riSEfQDn5RCbQm6pSREAyJJBaIJOkgnptUhrl yiyZ1uFxW8B+lwZCEZRXMbL8hBNgIm9w32I/JqLjPJIjDm2gAv07csRFsksrTY2AfQRHSkWuthMl x7YT3FZEVJKagggFzSLbUQ09HEwsYAL0VGazHi4OkJ5Wlx85UygdTKRGg8WL7QScL5ULAA3LAmvr 3bKDjpvDL5Mr0YiP347b1DiLYebqfipTI1h84UAg2rWPRXm4osSQlSfukTFotXsTs1LhRx9a/eXm CbdMdORY4wU2hkDyoFqG3B6LeHACyNb2iE5tfBWDWKNszF3NafjQKfiAlrKQCinkBXZqOwF3zKIE BJO0dJ2KVz9Z4pHjR1icYAIqy41sWxfXl8p1qtPlR84USgcTqdFg8WI7AX2jYb03LI3tIu+XG3Uc jX29YzGa8llwE22GnOEwgXU/o6nRLhR5rM1D1yYKJmYMTLbXO+bgA1wdMrO7wAcHgPTwwcQPw0cR 882IFj7YnRgaL8exU+IFro+dpbClByYIZ1WPPh0xqSvGmMTP45TVqv+qOTAkpbSRbA3tiESwFBAq AHvJt2wdCKzuM/74Nt0lGWsikXzCHZ5ImnEwex+yr8qSqh/l+iL2mqshYC32IPtC7sX28f1H8v3Y vkg8zUXZvkSkEim2P/aIo6AlSzHO48O1+AIbLL3L/UHo2CO6g5W73x9E8parAT9hYktV2wlHLzXs Mlm21FNraCLVoarhBMCxtnXyY8McNjtV7WjD1sKJ1GiweLGdcLzR27WMsnWqpZ/BeHzQX4nR+Ojd Yp8YbzDIW91PZGq069x/LMkDlSSK1Hs+yyAqGrPr7jAGKrqwP650pMdBRUuFv1fc744hYs84Gs9w s8cdQ1TJo5XzNtWOx7YTjnsqCTivW16q8OQsOzw2nIAOUCX+LuDHeDCaqlXVjjYcLpxIjQaLF9sJ xya9XUc0W682xDScSI0GizEmnwO/3ufH2w3SV/fzmRrtQprHyjxsZWKAI0cfLLdsokDiteN+Mcpb Ck1lIJ3iLYIW972HyNgrqIK24PvcQ6TY7x6iK0tL73kPkXLnPcQoOEHKPe4hMsFRY5FIvPKWwLMZ Vbr9keyu/uvd9ygg1QD2XfU7/N/ySSDj7jeQCgZ4e4YpKR22CAZws/n54yryIBHt/vbSOpQfPItG 5dvzzB7+mLaN/ACuovLVqPyAWMXkVXvJHGLr4K01Ks838v5aaQqUsvEr+4OPm+jI/w9KrksjDQpl bmRzdHJlYW0NCmVuZG9iag0KNSAwIG9iag0KPDwvVHlwZS9Gb250L1N1YnR5cGUvVHJ1ZVR5cGUv TmFtZS9GMS9CYXNlRm9udC9BQkNERUUrQ2FsaWJyaS9FbmNvZGluZy9XaW5BbnNpRW5jb2Rpbmcv Rm9udERlc2NyaXB0b3IgNiAwIFIvRmlyc3RDaGFyIDMyL0xhc3RDaGFyIDEyMi9XaWR0aHMgNTgg MCBSPj4NCmVuZG9iag0KNiAwIG9iag0KPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9B QkNERUUrQ2FsaWJyaS9GbGFncyAzMi9JdGFsaWNBbmdsZSAwL0FzY2VudCA3NTAvRGVzY2VudCAt MjUwL0NhcEhlaWdodCA3NTAvQXZnV2lkdGggNTAzL01heFdpZHRoIDE2OTAvRm9udFdlaWdodCA0 MDAvWEhlaWdodCAyNTAvU3RlbVYgNTAvRm9udEJCb3hbIC00NzYgLTI1MCAxMjE0IDc1MF0gL0Zv bnRGaWxlMiA1OSAwIFI+Pg0KZW5kb2JqDQo3IDAgb2JqDQo8PC9UeXBlL0ZvbnQvU3VidHlwZS9U eXBlMC9CYXNlRm9udC9BcmlhbC9FbmNvZGluZy9JZGVudGl0eS1IL0Rlc2NlbmRhbnRGb250cyA4 IDAgUi9Ub1VuaWNvZGUgNjAgMCBSPj4NCmVuZG9iag0KOCAwIG9iag0KWyA5IDAgUl0gDQplbmRv YmoNCjkgMCBvYmoNCjw8L0Jhc2VGb250L0FyaWFsL1N1YnR5cGUvQ0lERm9udFR5cGUyL1R5cGUv Rm9udC9DSURUb0dJRE1hcC9JZGVudGl0eS9EVyAxMDAwL0NJRFN5c3RlbUluZm8gMTAgMCBSL0Zv bnREZXNjcmlwdG9yIDExIDAgUi9XIDYyIDAgUj4+DQplbmRvYmoNCjEwIDAgb2JqDQo8PC9PcmRl cmluZyhJZGVudGl0eSkgL1JlZ2lzdHJ5KEFkb2JlKSAvU3VwcGxlbWVudCAwPj4NCmVuZG9iag0K MTEgMCBvYmoNCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUvQXJpYWwvRmxhZ3MgMzIv SXRhbGljQW5nbGUgMC9Bc2NlbnQgOTA1L0Rlc2NlbnQgLTIxMC9DYXBIZWlnaHQgNzI4L0F2Z1dp ZHRoIDQ0MS9NYXhXaWR0aCAyNjY1L0ZvbnRXZWlnaHQgNDAwL1hIZWlnaHQgMjUwL0xlYWRpbmcg MzMvU3RlbVYgNDQvRm9udEJCb3hbIC02NjUgLTIxMCAyMDAwIDcyOF0gL0ZvbnRGaWxlMiA2MSAw IFI+Pg0KZW5kb2JqDQoxMiAwIG9iag0KPDwvVHlwZS9Gb250L1N1YnR5cGUvVHlwZTAvQmFzZUZv bnQvQUJDREVFK0NhbGlicmkvRW5jb2RpbmcvSWRlbnRpdHktSC9EZXNjZW5kYW50Rm9udHMgMTMg MCBSL1RvVW5pY29kZSA2MyAwIFI+Pg0KZW5kb2JqDQoxMyAwIG9iag0KWyAxNCAwIFJdIA0KZW5k b2JqDQoxNCAwIG9iag0KPDwvQmFzZUZvbnQvQUJDREVFK0NhbGlicmkvU3VidHlwZS9DSURGb250 VHlwZTIvVHlwZS9Gb250L0NJRFRvR0lETWFwL0lkZW50aXR5L0RXIDEwMDAvQ0lEU3lzdGVtSW5m byAxNSAwIFIvRm9udERlc2NyaXB0b3IgMTYgMCBSL1cgNjUgMCBSPj4NCmVuZG9iag0KMTUgMCBv YmoNCjw8L09yZGVyaW5nKElkZW50aXR5KSAvUmVnaXN0cnkoQWRvYmUpIC9TdXBwbGVtZW50IDA+ Pg0KZW5kb2JqDQoxNiAwIG9iag0KPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9BQkNE RUUrQ2FsaWJyaS9GbGFncyAzMi9JdGFsaWNBbmdsZSAwL0FzY2VudCA3NTAvRGVzY2VudCAtMjUw L0NhcEhlaWdodCA3NTAvQXZnV2lkdGggNTAzL01heFdpZHRoIDE2OTAvRm9udFdlaWdodCA0MDAv WEhlaWdodCAyNTAvU3RlbVYgNTAvRm9udEJCb3hbIC00NzYgLTI1MCAxMjE0IDc1MF0gL0ZvbnRG aWxlMiA2NCAwIFI+Pg0KZW5kb2JqDQoxNyAwIG9iag0KPDwvVGl0bGUoVmlydHVhbGl6ZWQgU2Vy dmljZSBOb2RlIFBvb2wpL0NyZWF0aW9uRGF0ZShEOjIwMTMxMTEzMTQyNzAzKSAvTW9kRGF0ZShE OjIwMTMxMTEzMTQyNzAzKSAvUHJvZHVjZXIo/v8ATQBpAGMAcgBvAHMAbwBmAHQArgAgAE8AZgBm AGkAYwBlACAAUABvAHcAZQByAFAAbwBpAG4AdACuACAAMgAwADAANykvQ3JlYXRvcij+/wBNAGkA YwByAG8AcwBvAGYAdACuACAATwBmAGYAaQBjAGUAIABQAG8AdwBlAHIAUABvAGkAbgB0AK4AIAAy ADAAMAA3KT4+DQplbmRvYmoNCjIzIDAgb2JqDQo8PC9UeXBlL09ialN0bS9OIDM5L0ZpcnN0IDI4 NC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDU5OD4+DQpzdHJlYW0NCniclZVNaxsxEIbvgfyH Oban1ceMpIUQaA+F4hJM7JvpIWmWEEjj4NoQ//u+2lmn9UYW3ovHs3r1aDSakZwlQ47JC7lEMZGL ZG0kb8gKvJZsC8+R84m8xXAkF/APY0I+OvKeGJ5nYvGZwy3GAwljLJIkTE8UHMZaCiERG4oGakuR W4IqtvA8JazJTCkCIdQ6RxyoDZEYIRmDZRIsfjDLmsQkiNEiQrE5ZPiOrLPwPWzIEZD11pMIbDAk gSwbhAQeY9DlPRpMBjcifky1ySId4CRs6+qqmWeRodtm0Sxe716a+SP53p+Rub6+vDiWLLu37f36 rZmtCJn6Se/yf9I4SH98XT/ss9AXZeEg+541OBm4RWE75vEZPG9O8bwd8+QcnjsZnxyE/T763Q9B D2sVZxUSqktW1eMTClVgpFSlfXt63G265svz9tPnrG/PjdTmspwUqHV1IOq5fKwngVIHohHi2dtB d9T3Pl7d1VvDoTfKzXEq9a7cJCU2urpcsSeDrVcJStbV6+QDsK0C0Xu+Xh3/i/P1erY43+KT8urD NHm9Zj7Ip/WXrxfZWM5mmryYc5sOh/j89NANxdlfUaxG9KbyavSjHz4GNXqn+aRGrzY2ahTGTo1S WCmsFFYKK4WVwkoRpYhSRCmiFFGKKEWUIrF8Ry73r12z2G52v7bLTdfdrtfbZn636V56N797femu hvRlwPvoDQps1u3JDqyb3e8/K+ofyV6aP39I22CGnOg29JEY57KY0mJmiwk+znMx3cWsF5NfOoPR URyfyOSDubz4C6DkEwoNCmVuZHN0cmVhbQ0KZW5kb2JqDQo1OCAwIG9iag0KWyAyMjYgMCAwIDQ5 OCAwIDAgMCAwIDMwMyAzMDMgMCAwIDI1MCAzMDYgMjUyIDM4NiAwIDUwNyAwIDAgMCAwIDAgMCAw IDAgMCAyNjggMCAwIDAgMCAwIDAgMCAwIDAgNDg4IDQ1OSAwIDAgMjUyIDAgMCAwIDg1NSA2NDYg MCA1MTcgMCAwIDAgMCAwIDU2NyAwIDAgMCAwIDAgMCAwIDAgMCAwIDQ3OSA1MjUgNDIzIDUyNSA0 OTggMzA1IDQ3MSA1MjUgMjMwIDIzOSA0NTUgMjMwIDc5OSA1MjUgNTI3IDUyNSAwIDM0OSAzOTEg MzM1IDUyNSA0NTIgNzE1IDAgNDUzIDM5NV0gDQplbmRvYmoNCjU5IDAgb2JqDQo8PC9GaWx0ZXIv RmxhdGVEZWNvZGUvTGVuZ3RoIDY0NzMzL0xlbmd0aDEgMTIxOTA0Pj4NCnN0cmVhbQ0KeJzsfAdc VFfa/jn3TmOGgRmYgYEBZsahKSgqFiyRUYoFG8ooqCgIKiYaDXZjS0wlmpg1zVSz6cEkw6gRk2xi EtPrZpNN2ySa3kxMLyr8n3PfOYglifv/9vvtt7/fXnju87zvKff0+w6CjDPGnLjp2PjiiSOH35e6 MZnxPW8w5q4sGVZcce3DzWcxdqCYsZj5JcNGF6VVhfIZ++R6xvR3Di8uKWWZutnI34pa0oaPHzdx 6F5/BWOHdjC27f3hE4PDvn3Z0sL4ndcw5vKOm5jXe15DI/Jy1M9q6ubXLnz05odtjMWPZ0zNrlu6 2Hvf5l2/MFa0FfWbZy+cM//HH8dEM5awnLGo5Dm1ixayFObH8zegvG3OvBWzJ2zxLWRsxDbG1q5p mFVb/36WsxD1T0N6vwY4rPda9LCvgJ3eMH/xcvPW7vsYUwoYsyecMavxTFe6cwZjLx9kzFQ/b0Fd 7T1DXviSsadzYe+dX7t8YdYvGZNQXvTPe2bt/FmZ9eVfMfYm+hiTsHDBosXtbnYB2jNPpC9snLWw /fOPUb8Hz0u3MDG2XO8Zv/2JGTNiB//AkkxMXA9+sep5wY9mjSg53KttUdT9xhthRjGF0YVyBtbG +F7zWKRviLpfq6nTpesmPLpadjPTs+VMRUkby2OzGPO78FwFqarOyDch1aTfoseM8TRi9WV2gcJM TInVK4qiUxXdVqZ8HWDes2XdYyZ6vQyOQzpqg/FGJdPL2E0iTd2ljxE9Re0xR1vDX2L/65f6Kdt2 Svnu+eN8iu7U6vpnLsPrbJu+27+mXl2Xf337fvd5TazL/6S8+j1W3z/7TB27WX2OzT9p2iys6871 rzvW/s12jGc3685l806ob/nR8vzL368L6XaplSGRep+hMsq+k5c1GPDcy0+eprubzT6VtstLfeJo PeqB48ZhHBt50jJVOBU7P3Mj7dZTet4R5jMMYf1Pmrb+xHlV57LiY+zX2LRTfVZH+/qwLepMNuVk acYFbIrhHYBTOvLWHPO8Q6z6VJ6hnMUyDNeyDNNrLEPXDH1dRA9mGadS3rD01PLJ+kR+QxSeUXTi M0Sa7sCxPnUv63tCXcf1NeLbIjX/Ozv/VNqklUtjF/HP21/reN4tx9Sz5WRlDPVsS+fnnVBnwcnn 7Dfzd6pLefbYelUfKz9ZGf29x/qVe5nvmDo/Zj7dkmN9J3028ujjmc9YhvX95h/nF3nQ3iv+KJ+8 1BtYF33riXOopd104nmqdmVVv1WXso0VKx+xecpYjUcorWw4f5SlK1ezbspnbB6vY7V8fvsbsOfx 6WyebhLyfqyhRJQTdfAfYfdkw/gHzC/KKOczj/o1y9Xqv4B5lP5s2Kn27T/1wrpm/MV/dyv+e/33 +u/134su5Tpu/s20Gnags83bcd6nsxFamp5d/a9sh5rIuPIe85zQhkV4hwCnWo8yn50PrDzBH2Dn ASv/KN9/wqUeZumCdXaWKlh5TvzM4Y8vfCa+91TyKRtZ0v9/605S37+4ffznU6uvI/9DrAao/B+X /YH1OqUyp5BPaWkv+2fa8S+81AhS6Kc2fDAsrtk67gX3ZF6mwycrH0aqK8tDXwaxUnyyG8vGs0ls IVuGXbOV3cN2e23eYu9a7zneSw/p2tuZ+LmLn2UjphMlSlBijFailjWyFZ1KrEaJjYeYKKFeoU7C /SHVzVj7x+0/MSOtaFh1yhPqkA9mfvAhYx+c/4H4XMHRMnH10O49O/rTDSfShE79G9VxV9VRalBt VCvVeehdJld4LLfxZJ7Gs/l4PoVX87l8Hl/Al/ClfDW/mG/gm/i1fCffwx/lT/HndapOx/fxHN6D D+cFvIwZ8OlbXN8c//Mu2Erkp2MK+/2LSqJl4qdVHVOyRl2rsWyt+Gx94sRNOkl96JfGeRG7WDsr J3fKseikzfiDsUCOTqMBC+PxBz37d1/q7yfrsonFbP5xZYHh9TOmV0+bOqWqMlgxcUL5+HFjx4wu GzVyxPDSkuKiYUMDhUNOGzxo4ICC/v365vXonpudmZHu7+JxOey2WKvFHGUyGvQ6VeEst8RfWuMN ZdaEdJn+ESO6C9tfC0dtJ0dNyAtX6bF5Qt4aLZv32JwB5Jx9XM4A5Qx05OQ272A2uHuut8TvDb1Q 7Pe28inlldAbi/1V3tABTY/RtC5TM6wwfD6U8Ja4Goq9IV7jLQmVLm1oKqkpRn0tFnORv2iWuXsu azFbIC1QoWz/whaePYRrQskuGdiiMJNVPDakZpTU1ofGl1eWFLt9virNx4q0ukKGopBRq8s7V7SZ XeJtyd3TtKHVxmbW5ETX++trp1WG1FoUalJLmpouDNlzQl39xaGuKz90ocuzQrn+4pJQjh+VlU3o eAAP6TNsfm/TDwyN9x/48lhPbcRjyLD9wIQUXewYJqRLzdA2tBD98/lEWy5pDbCZMELryivJ9rKZ 7jAL5OVUhZQakbJHpjiDImWdTOkoXuP3iakqqYl8L21whdbN9HbPxehr3xn4Rro3pGbWzKxrEFw7 q8lfXEzjVlEZChRDBGojfS1p6ZmH/LU16MRcMQzllaE8/8KQwz+MMsDhFXMwd2KlViRSLOQoCrGa ukipUF5JsWiXt6SpppgaKOryl1fuZvnt+1r6eN3b81kfViXaEUoowqRkljRV1s8OeWrc9Vifs72V bl8oUIXhq/JXzqoSs+S3hbruw+N82hO1UujbcbllZtFzY4bJW6m41SoxW3B4S3HzDxuMBBumSzPF jA4b7K3kbiaz4SmRHEIdUw8MNaNohEhSRdGiEW5flY+u32mSO9ImfUbI1KkuGxwdbaLn/GbTKLdo UFdvyaziTg08plJ9pIGR2k7eTkWMReTBKGES0zlCJqkZ2LnwKahGc4lZdHlDbLy30j/LX+XHGgqM rxR9E2OtzW/ZRH9Z+ZRKbbYjq6TiGIvSC8gKMR+SpaEUYQ2W5rjltGr2cM3uMEcclzxSJnubTP6y iU2icn+kQubFDkKnDZkjay8piOuDrVmK081fWutHkFDaVNvavm5mU0sg0LSwpKZhoKjDP7K+yT+x crBba+uEytXuleJRcayMl1UM656Ls2dYi59fVN4S4BdNnFK524aI5KKKyrDClaKaYVUt6Uir3O3F 4a55FeEVTmF4hSFqmgDDpOV37w4wtk5L1WkOza5r5UzzmaSPs7pWhXw26VPg05EvoPnEhUlyNWCI cdyWeOvF9KyqamiqqRKbiyVgKvHNQ9w/hIUU/5AWrhiiQ2b/rGEhi3+Y8BcKfyH5DcJvxMLgCRyD I86kpho/ziksqErm5rQUVVGlt7W9vaLS94L7QJUPS20aMKUyFJWDs1+fMQr5hgvUwD08tK6uVrSD BStFWWPGyLoqLFtZIbKMDEWhhqhIDchRqpURyxGF6jA3mECt/DoYoXVVoaoc8dDKuVXacraF2Aj/ QEw71anPFA/Kq2qK8/fW9ia2gjnjQkFRaBubWEkeN0w8rIoGyRiNltf5kVRX48Vo61jdRCx1OkvN bvLMwpGoy5ylweyOJDLRLTXDYjWHonqgQnwLbekhtqQ+w1hVRY3XrAsjGfBsW8iCFmV2GspIAYwO kkaKtuD7QjRVZH1UVFPeyib4l+NkEY3WajIiOWTNGFmLw5/KW+DxF8jCJnFGWCJ17CWvUfQ8GuOu ZlS0tt/hX+HrdHXP9YuXg1iYzL0bC5tVNR3vCE3N6Z5rOt5r1dxNTSbryQvQeJmsHSyc3hK8NRgL R6neVuW8HVEuPgpivRTnSnGOFOukWCvFGilWS7FKirOlWCnFCimWS7FMiqVSLJFisRSLpDhLioVS LJDiTCnmSzFPijOkOF2KuVI0SDFHitlSzJKiXoo6KWZKUStFjRQzpJguRbUU06SYKsUUKaqkqJRi shSTpAhKUSHFRCkmSFEuxXgpxkkxVooxUoyWokyKUVKMlGKEFMOlKJWiRIpiKYqkGCbFUCkCUhRK MUSK06QYLMUgKQZKMUCKAin6S9FPir5S9JEiX4reUvSSoqcUeVL0kKK7FLlS5EjRTYquUmRLkSVF phQZUqRL4ZeiixQ+KbxSeKRIkyJVihQp3FIkS5EkhUuKRCkSpHBK4ZAiXoo4KexS2KSIlSJGCqsU 0VJYpDBLESWFSQqjFAYp9FLopFClUKTgUrCI4O1StElxRIrDUhyS4lcpfpHiZyl+kuJHKX6Q4nsp vpPiWym+keKgFF9L8ZUUB6T4UoovpPhcis+k+FSKT6T4WIqPpPhQig+keF+K/VLsk+I9Kd6V4h0p /iHF21K8JcWbUrwhxetS/F2K16R4VYq/SfGKFH+V4mUpXpLiRSlekOJ5KZ6T4lkpnpHiaSmekuJJ KZ6QYq8Uj0vxmBSPSrFHikekeFiKv0jxkBQPSvGAFLulaJVilxT3S7FTih1SbJciLEWLFCEp7pPi XinukWKbFM1S3C3FXVLcKcUdUtwuxW1S3CrFLVL8WYqbpdgqxU1S3CjFDVJcL8V1UlwrxRYprpHi aimukuJKKa6QYrMUf5Licik2SXGZFJdKsVGKDVJcIkWTFBdLcZEUF0pxgRTnSyHDHi7DHi7DHi7D Hi7DHi7DHi7DHi7DHi7DHi7DHi7DHi7DHi7DHi7DHi7DHi7DHi7DHi7DHt4ohYx/uIx/uIx/uIx/ uIx/uIx/uIx/uIx/uIx/uIx/uIx/uIx/uIx/uIx/uIx/uIx/uIx/uIx/uIx/uIx/uIx/uIx/uIx/ uIx/uIx/uIx/uIx/uIx/uIx/uIx/uIx/uIx/uAx7uAx7uAx7uIx2uIx2uIx2uIx2uIx2uIx2uIx2 uIx2uIx2eNF2IRA1h9OGeBAzh9OcoHPJOiecNhC0jqy1RGvCadGg1WStIjqbaCXRinDqUNDycGoR aBnRUqIllLaYrEVEjeQ8K5w6DLSQaAHRmZRlPtE8ojPCKSWg04nmEjUQzSGaHU4pBs0iq56ojmgm US1RDdEMoulUrpqsaURTiaYQVRFVEk0mmkQUJKogmkg0gaicaDzROKKxRGOIRhOVEY0Ku0eCRhKN CLtHgYYTlYbdZaCSsHs0qJioiGgYpQ2lcgGiQio3hOg0osGUcxDRQCo+gKiAqD9RP6K+VFkfonyq pTdRL6KeVFkeUQ8q150olyiHqBtRV6JsoiyqOpMog+pMJ/ITdaGqfUReKuchSiNKJUohchMlh5PH gpKIXOHkcaBEogRyOokc5IwniiOyU5qNKJacMURWomhKsxCZiaIozURkJDKEk8aD9OGkcpCOSCWn QhYnYhrxdqI2LQs/QtZhokNEv1LaL2T9TPQT0Y9EP4RdFaDvw66JoO/I+pboG6KDlPY1WV8RHSD6 ktK+IPqcnJ8RfUr0CdHHlOUjsj4k6wOy3ifaT7SP0t4jepec7xD9g+htorcoy5tkvUH0ejhxMujv 4cRJoNeIXiXn34heIfor0cuU5SWiF8n5AtHzRM8RPUtZniF6mpxPET1J9ATRXqLHKedjZD1KtIfo EUp7mOgv5HyI6EGiB4h2E7VSzl1k3U+0k2gH0fZwQiEoHE6YCmohChHdR3Qv0T1E24iaie4OJ+C8 5ndRLXcS3UFptxPdRnQr0S1Efya6mWgr0U1U2Y1Uyw1E11PadUTXEm0huoYKXE3WVURXEl1BaZup lj8RXU5pm4guI7qUaCPRBsp5CVlNRBcTXUR0IdEFYWct6PywcyboPKL1Yeds0LlE54SdQdC6sBOH MV8bdvYDrSFaTcVXUbmziVaGnfWgFVR8OdEyoqVES4gWEy2iqhup+FlEC8POOtACquxMyjmfaB7R GUSnE82lcg1Ec6hls6n4LKJ6yllHNJOolqiGaAbRdOp0NbVsGtFU6vQUqrqKHlRJNJmaO4keFKRa KogmEk0gKg87AqDxYYd4wriwQyzvsWHHetCYsKM7aDRlKSMaFXYgLuAjyRpBNJycpWHHGlBJ2HEh qDjsWAsqCjvWgYaF40pBQ4kCRIVEQ8JxeL/z08gaHLZXgQYRDQzbxdIYQFQQtg8H9Q/bK0H9wvYp oL6U1ocoP2zPBfWmnL3CdtGxnmG72Jt5RD2oeHd6Qi5RDlXWjagrVZZNlEWUSZQRtotRSifyU51d qE4fVealWjxEaVQulSiFyE2UTJQUtlWDXGHbdFBi2DYDlEDkJHIQxRPFUQE7FbCRM5YohshKFE05 LZTTTM4oIhORkchAOfWUU0dOlUgh4kQs0B470yPQFlvnORJb7zkMfQj4FfgFvp/h+wn4EfgB+B7+ 74BvkfYN7IPA18BXwAH4vwS+QNrnsD8DPgU+AT6OmeP5KKbB8yHwAfA+sB++feD3gHeBd2D/A/w2 8BbwJvCG9QzP69Zenr+DX7PO87xqzfT8DXgF+q/WHM/LwEvAi0h/Ab7nrfM9z0E/C/0M9NPW0z1P Wed6nrQ2eJ6wzvHsRdnHUd9jwKNAoH0P7o8ADwN/iT7L81B0o+fB6EWeB6IXe3YDrcAu+O8HdiJt B9K2wxcGWoAQcJ9lhedey0rPPZZVnm2W1Z5myxrP3cBdwJ3AHcDtwG2W7p5bwbcAf0aZm8FbLWd4 boK+EfoG4Hro61DXtahrC+q6Br6rgauAK4ErgM3An1DuctS3yTzWc5l5nOdS8xzPRvNtng3mOzzn qxme89QCz3pe4Dk3uC54TvO64Nrg6uCa5tVBy2puWe1eXbb67NXNq99eHRhjMK8Krgye3bwyuCK4 LLi8eVlwafOSoG6JY8niJer3S3jzEl68hPdcwhW2xLbEu0SNXhxsDC5qbgyyxvGN6xpDjbpBocZ9 jQpr5ObW9j3bG91ppeDAqkarrfSs4ILgwuYFwTNnzw+ejmbNLZgTbGieE5xdUB+c1VwfrCuYGawt qAnOKKgOTm+uDk4rmBKc2jwlWFVQGZyM/JMKKoLB5orgxILy4ITm8uC4grHBsfCPKSgLjm4uC44q GBEc2TwiOLygNFiCLrMUW4o3RbWJBoxNQUuYmw/r6Q6497kPunXMHXLvcatxscmeZKVrbBIvGpfE FyStTbosSY11veRSAq6uuaWxiS8lvpf4daIuPpDYtUcpS7AleBNUp+hbwpiKUo0Li4l79dX6OibB n1ka6+SxTo9TKfE4ObPvsx+0q85HbC/ZlNhYHhvbHqsEYpE9NsYTo4hbe4waiOnVvzTW6rEq4tZu VRMCVnhEjVnR4ytKYy0eixIstIyzKAFLYVFpwNK9ZylTuZdzxm0g1YS8O7jTU6o+xMWvGukZ55ta Kibm5JS1mtiEspBp/NQQvyiUMVHcA+VTQoaLQiw4ZWplC+eXVrVwpagi5BD/UKvZ52/cyFKHlYVS J1aG1a1bU4dVlYXWCR0IaLpdaIYsVTnTFy1ZlJOzeDpu0xctztG+YfElwsoRTvG9aDFs8bVEs1nO 716UDTRjEa7FEd/i3y/0f/3i/+4G/OdfLUz8fsHQduU8Vq+sB84FzgHWAWuBNcBqYBVwNrASWAEs B5YBS4ElwGJgEXAWsBBYAJwJzAfmAWcApwNzgQZgDjAbmAXUA3XATKAWqAFmANOBamAaMBWYAlQB lcBkYBIQBCqAicAEoBwYD4wDxgJjgNFAGTAKGAmMAIYDpUAJUAwUAcOAoUAAKASGAKcBg4FBwEBg AFAA9Af6AX2BPkA+0BvoBfQE8oAeQHcgF8gBugFdgWwgC8gEMoB0wA90AXyAF/AAaUAqkAK4gWQg CXABiUAC4AQcQDwQB9gBGxALxABWIBqwAGYgCjABRsAA6AHd0HbcVUABOMBYPYePtwFHgMPAIeBX 4BfgZ+An4EfgB+B74DvgW+Ab4CDwNfAVcAD4EvgC+Bz4DPgU+AT4GPgI+BD4AHgf2A/sA94D3gXe Af4BvA28BbwJvAG8DvwdeA14Ffgb8ArwV+Bl4CXgReAF4HngOeBZ4BngaeAp4EngCWAv8DjwGPAo sAd4BHgY+AvwEPAg8ACwG2gFdgH3AzuBHcB2IAy0ACHgPuBe4B5gG9AM3A3cBdwJ3AHcDtwG3Arc AvwZuBnYCtwE3AjcAFwPXAdcC2wBrgGuBq4CrgSuADYDfwIuBzYBlwGXAhuBDcAlQBNwMXARcCFw AXA+qx+6jmP/c+x/jv3Psf859j/H/ufY/xz7n2P/c+x/jv3Psf859j/H/ufY/xz7n2P/c+x/3gjg DOA4AzjOAI4zgOMM4DgDOM4AjjOA4wzgOAM4zgCOM4DjDOA4AzjOAI4zgOMM4DgDOM4AjjOA4wzg OAM4zgCOM4DjDOA4AzjOAI4zgOMM4DgDOM4AjjOAY/9z7H+O/c+x9zn2Psfe59j7HHufY+9z7H2O vc+x9zn2/r/7HP4Pv6r+3Q34D79cM6YzxsT/DdG2+Zhfnh7PTmeL2Dp8XcA2ss3sEfY2m8nWQ21h W9nt7C4WYo+yZ9jrf/x72Kd+ta3Qz2fR6i5mYPGMtf/afqDtdqBVH9PJsxlWvM571NNua//qON9X bZvbbW2thjhm1spalVfg/Y4faf8VL1jY7f2ErVwIHauV+MZ4Y9t9bXccNwblbAqbyqaxalbDatH/ etbA5mJkzmDz2Hx2pmadibQ5uM+GNQO5cJho+miuBWwh0MgWsyVsKb4WQi+KWCLtLM1ewpbhazlb wVays9kqtjpyX6Z5ViFlpWYvB9awtZiZc9i5mpJMnvXsPHY+Zu1CdhG7+HetiztUE7uEbcA8X8ou +0298RhrE74uZ3/CeriCXcmuYtdgXVzHrj/Oe7Xmv5bdyG7CmhFpV8Jzk6ZE6kPsSbaT3cvuY/dr Y1mHUaMRkeMyWxvDhRiDVejh+k4tpvFb1jFaa9B30bemSE+Xw39upxJLI+Mocq5HTqqF5kHUsvq4 kdiEPpA+2iOyrtT6f9TbeVR+zyvH4/pOI3OdZgl1vPe39FXsBuzAm3EXoyrUn6FJ3aTpzv4bO/Ju 1exb2K3sNszFHZqSTJ7boe9gd2Jv382a2TZ8HdWdFfG97B5t5kKshYXZdrYDM3k/28VaNf/vpZ3M vz3iD3d4drMH2INYIQ+zPThpHsOX9PwFvkci3r2aj+zH2OOwRS6ynmRP4YR6lj3HnmcvsSdgvajd n4b1MnuF/Y29zq1Qf2Wf4X4EEJ+2Wdsi9RWcGiozsgFsDBvLpj7ErHi/J7CBfOdOZ3GxqbvxYby7 FebF29+Ej+dFgVidYt2VnFzo39XXsFG1j2zl3XcUGjciri088u6RF/OOvHsgbkDeAZ73zv5399u+ edE+IC9//6v7e/Xkdp9dgyNGMRodBn+XHkrfrMx++fm9hyh9+2T6u8Qomq9Pv/5D1PzeaYrqkJ4h irC5+srhKeq4IwZljb9wUr4+LTnWYTXolRRXXPfBGbaJUzMG90g1qkaDqjcZs/sP61I2r6TLW0Z7 qjMhNc5kiktNcKbajUfe1sf8+q0+5lCRbt6hK1TDoGmF6eo1ZpOiMxha01xJ3Qb5Rk6KjbfpLPE2 e4LJGGePzi6eduQCZ4qoI8XppLqOjGFc/M8y6iqMYC5b2pKc1dr+6XYbHwM+uD02wlaNf9werfGn 2y2CFXsgKireG+9lUSy5lZsC1nWZfE8mfzmTZ2YaksQPTK3lWaAWQwUrPFAoRrT6rEYMal7cgAF5 ebb92iutd6+eGWKIfF0y+9r79Mv3YYycmsN+nFRX6cxW05HNiV27JiqzTVaTXo9bm4GHTdYonS4K eqzCTVazbnicO87kydKdm+UxxbkdcW67qe30KFtKfFyyzdjWy2R3i78K29b+q1qBfmexaS3G+Ei/ 4yP9jo/0Oz7S7/hIv+PR753WVJaWakTXtsfHJxlaefb2LuVJQVZYGFk1eXvtAzp6x0/ojFwRsrtq BTpmbMPoGdF4TQdMDm+yq4vDhK6Wat698SnoxQijze2Md9ujjnxktBr1etx094pepkZ6xCv1DuZk 43cVJo5LvC9RZZF+sUi/WKRfLNIvFukXewAfCc3te3Y5+RizbYJe9Ibn5VAvevWszjjaaFrHTl5p cviSRBujnL7EJJ/DlGyKFk2KNunekirSKkMOxnkw2xaw1QxZOESx9uyZmJdn7uFyJUealxxpXnKk ecmR5iVHmpcslltaeq/oaLPLJloYK27IaDYjl9mFLGbRA9a+J5AkupPer9ziSrTmuXr1MHiyyz3B uKDWp8LCuMQB9nz07dVI53rb820dyj7gtLz8fHv+MT328xhVqCzuP2buxDAk8nyOja6NiCHH5PAk JfriTUpbvmpxpjqcaQ6L0jacYzaTXN54Y667wdsz3RXFl+n5BZZkT2bS/Fh3fPTRgZtz6Aqj2ajq jGYDNvaWDv/t3dKjk7Pdhyert6d1S7JExac6aWR1a/R2dho7f3tWbKwjMpgax0bYqvFBMZiOyGA6 tMFMM/fo0VsMZm9XrLghY29btFDI0ltksbG0ggnmHrFZuiSxvsU21oZPDN4JY5eXH9nINFKZmVn+ hATnScYrTU3Mz8w8uo50a6zOZGv/5Cy/39nW4B2aoiiKKd7jcnniTLnJE1KzPKl2PjC1X+9eLo7t He9JSvDGmYY7cJJZUntnKfsGrB404qpRh7/r2BB3Z3cxJ3b1HHm6T11Ndd645nHKw8ZocUJEG8Vf i4p9/xTWYwrrypa3pBsio2aILEFDZAkaIkvQEBk1gxiSRHuqGLJUsf5SbdFWPjrVi7RU8YsizJ7R ys3bDYZofyu3bHeWR3c6EmjAbMeeCv7jjwKdsU8P4RZvE/WpwLJ7lm+Oivclic3VLZk7u42ZO390 152DJlfn3nTd2Dml6erm2uvPHNzWo2OdoOvGxMJpKyaPO71PzJFfsofXiR3YBeukAedCOjszkJpu QoOz03my4Mxknp3IM608N4nnungS+roj1sZHa0J0zyU9QgTihCvJleTKzPBMcOnj6JyIG1Boj+Pi TKfDglVX8+rq6pzqnAxt4+jEcujXr9N26Z2QYDAqu3QxSVmpCT6XPdqotlWZeFx2lxRfXJSOL+J8 rmpypKd50q2qKc0SY1K5Tm+ymHThBHeMTsUhf+gRXaHw62PcCWJWbZjVD3WZ6GM2K9vpSsyKzrS2 KjwQlZjphc+SaW5VBmFJZ2akdsv6OTo6LnVWXIO+QVvSmCF73ACelOd6db99wIC4Acm2d0hgTaOp 2ms+K8tnFN1BV/prfUjTJRr9qk99y6jaMn2+DIdJndwWmKAzx6enpPpjFBOfq4t2ZaUl+V1xFpO6 WrmPzxmckIzmG6KjDnwRFS0an+JUn7DEGFWO1320aV2bWfxV7c3if2fC56M0lsMK2GktmfkPKiqz MI+SsN3ptOS2KqehJ5bkrPd79TJmfGyrz//BOEe+Yw8MEKsNYr9tPy003QkvV2Oaqh5dafGdFt0t KfklwbqhbY870tMdPHvGmkm58en9/DljBnT52tm9ZPBdOwcMzXYOcvefWPzwu32L81N5fp9JJb27 2FJ96q2+1C7FdUOzigd2jzF1K6rk1/oHZie0PeLuPritLGdYD1fbrQk5Q7Ae57cfVNfrerK+bFDY xRBKDAmYoxMO5aUWpiqpXVp5XMBin6387O3Vs5fSK7eV920xzkVk9mr1Ae3G8/a/ulc7bXSdIiud M7KZRAzmdKQpoj9aBLbelNxnZHX/eeG1pcPXbZ+XN3nUoOQoHLFGS2ZhdaB0UXlu3qRlI0+bfFq2 1WDSq9ek+pJ9KfHDL37m3HOev3SULcWX7PfFJdtNnvS0/nOuqp55VX1+mj/NYE8R607M1WHMVRzz sC4PsXhlAMLSZMWB4Mj1S0y9+xc9zYxo9H657ztNR+cdf3hk09MbD2kjb296dH1xKDt44bzLN82+ oCpX8Wx4/oKhNMgl5z2yZsKGOQMPf9Vr1tVif4s2xKANuayXiODwcEcUArN4FpX8k4jFfrbWZ/1s OLpCeN4LFIH9E8FXjM5oMRz5RDROiTNajDrYxrYaPseIta2aoLfwOwzwF2OojNRQBCtxcUmxprbn jbbkeHsSgq/bjLYk0WJ8sj+oE/97QY8WvV20OC7FYnGzFLf+F7s9UXfIW5/YcGxAlRdZzobfC6YS lIOxsW0r+EJDtGhhtKFtkwkHqAsHKAb1l9hY9e10b9sOky0JsSAaVmGinpjUZ32pPjGW89q/Ur/S 9WYBVrg9LS3WJX5TjmXHtioFAXNf/w9Jenz1NItfFRg424Gl2tJzbmRcxYjS2sTZkReZ6mPWY7/+ 9o4Fi7bi7WgwUmgh17D6ld4YpYvtNXr+6ElNtX36111c3qM260s53nxGgtdm942vmNR17TMbRo7b 9MzZRY3B/g6zuiHebTOlZqQOPv3KqplXzemb4ORpGGox/MZUT1udI9UYlxxvGb3hyZVrX9w0zunx xHtoHtTXcWrmsT4t/mjxy4GJ6RbxJygssdusdLETo044KrXXf++ji0cb/c4TEXmxwyel+rrJiVnw OoxtaVoshPlA9OhK8jpM/H2jw+tK8jlNiR3dfLJtoNTqtx2LrY7fIDWjtvMytN3J4ndjJzp2mG2z tFZiDjo3rSNgLZOPjhIPxKM7Hqj+P9a+O7yN805zGjAY1EHvvREEQYAAG1iAYQOGIEiKpApVSKqQ kq1iUpZk2RLjIsuOnWI7ccnjrJ/EuSeX5G6zTixTsmRnk/yhFGdXPu8+sm99cbzW5Ynt2IskzmWT 2JGg+74pIMSiYq0gYQYDFsz7a++vfJ/+n5Q/k16+jGjBz90ieQALcXujSLGQlttD4vIf0K+D31bD LdoDv82p9s9YoG+ScAoAlPRCReZSMdvj0sLFT/B1W+tU3paIOMGvxHApRcoM9oDNVWOWAwxsNo9e htavv22ojlSoFUrarDG5tKRSo9IG2hnsTfEjCveOfxF8mlaEOYP4sa0LsZipNfVDrBPxIQrMAJJf ObaDUSGmmhmfQuuY0Vbkx7M3+qPkhTiMEYtAhdEVRMgHOj5moIC64V+U6f1WR8CskpTvXibJWanG 5LHYfHoKlyqo8rfRw1KZFLeQwBZxwE4w7aXfy5YhXm5CfwGu4vCqVKHWKsoHypRMrZILng17E9yn BaKuh3pJqmaA2amfJ3bxqJ/jbkEquLCK6oFn7E1aU3YbAosfDzKkvgAwdPyfxd9+8T6SzwYBopIZ 4JFakfxCnTEWBqK9zFA+VVwei/ka5fCVFvE1TcdMCtwZmnbeQguQVhhxUgeSBwAwsAzAHao10I8K FOJqCYTJKJkh9R6z1aMjsfLnCX8NSNYpvPw0Ruo8VqtbR4Yse911XpA9RAg0qbR6I46d1sCiDh++ eFypBEolxecvPly5+jOfB2YOlxqxn7tqbQqPT9CePwBU24H39ergaKiDSJxG/wkojKN5RlFrht4X 31WtMKK9S2Hw4um9AQK97Hb0JpM5VY8vygL/g892wB2iy+/XDIdRQOFJrcNkccLbmdfaDSCpja6L YCj4I9U5zBanVtrt87i9mGLgq0VfYaDgu/TD6puRaSx0OTDyjdGadevW16D/CVgTQchgpokhOy// jugFvlsPcvrwjxAD1g4M2AWe5YgV1ZzQ7ATEXCPY6xUBuao+w8XjKgZB9Hbd84MjR1482tF97w+O HDo5z5zwFu4cH79rwO8ZAMcjRS/mOva/vjTU+9lfPHj3uceGeh/86aPjj+/tYGYfH9n81L727rkn OZ4AMN8N9MsJOF3d8yHpy8BKteDDdQDQteH/lEiUwT8bp5W3VKcMIoFbnimYzC6cbAyFQyGRO+xu 3PHozBOiSYYsqMrf62nbzPhe6M4Y46Yvf629v8GK/Wbs2OZ4+UvVgEpJZWpopsBu10ok5X3ulgHx 0z4DPm0KxMHOM8CZGBca6Ki2EY7Vh9q5gK1xRLXvtreb03+G2sLbgsg/LyQhA02/Ue1ewvX48oRH ZKNms8lUxUjxZ2TGoMPuNcrx9ZpAoqtxl3hjIIrbtj6wOeFsKjbYY0EvvVFO/ocxMcA8+UhmKGnV k0D9cUqt+GNtb9xWHq7c6D95naHcri7IVWmFN8HU/NZmxd72d0St5eescQZ6gP7Lv8MuAu0ZQAbO IN2Y7mSoMdSodsL1AYgamIeKodKZj509kuhO4A60pzz6hB7TAz+h4lSKo6fgpi+dL/EEPL16RGis vJYuYa1S7GL7zkfGUlPFJpqUYBigJopYbltHrNjijuY2TWzK1zZumWdrR3sa1Nz7FElFOkdTYabO UpffNLkpX4eGCweH63R2B62gjbTBaaCcfqcp0h6KdMaDtam+bV3MrYUIbbJqFFoLrQfE1ua0GYMp ZzRTH65J9k4CLBxA/hkgfw/ifh4hgLhfMGkIGvjdF+zTck5Hk2j87Ec/EQnZIg9Y5DeANGY06vIF Sue12twGWfmCSBWx96Fc8F8GvRePVSR0t0wL2KJdS0KHjCJf53hYCFhL4AeIB9MDSzZhhpPy0Aw9 Y1804+xSM16MAYal4Rf/XedtX9s+9cxsG9Ami82rl/n7ptLpyV6vTO+xON16Ev3qwa/c2pqaefIe bE6MEJee2TbT6wOJzTg2WwnBKOIFCL0FPp8PSZ1AzEALfn/SZ/bIzUZAGBm5wuycMUkEPgLyYz63 5BNLLqsUK0orJsa3EXJzyO2rtSiJ8t9JCU3A4/YbQI6YxIDrpww+p9OrIkguLcZlaiX+E5NdBSMs dfEb+Ba5SkiKUaTl8idSEnzGDmQ9Q8XlSqQjkVAmT6N/YOQdSrNFFfT7lb7TmInRWpQtM7UzCb8C ryZ7ILBVPrk1DvNhC82f68B51W3gfnzZDelTep48iGfw1oh3CZWtxuWLWhT4O/h5kB/XuD1RG7jP fyNRXcjj8upJ/E/Yf+Ayndfp8OlI/K/or3GZHt6yGpMKt0wrsU8uSZSaJbcvv/g/8TGFCl5VURf/ nj8n1HYztG5YHzjA1QfiZxAzIPUqpQ2uQwlYEOjNKKV7xiLVzUhFgcU/Sr9+AUgL1vwrurXs7jhx WSm9z2wF6lReUJKakM8VNFLERexPQFR+hy+olijQJ8sVRUfvxob5KgCgSAn0NZlCShAaK5RXL8jj gsDqIkjTGYTGtp3yGMADCcElX3IPZ37WaXmI035If5KcGV4QkrmqXA5aYAsKz0RTNPIUDkQO8BvA p7h0wOImZLQK/b9lL03DAIrtVeqVUlymUZa9GKLW9OlARuF2eTUms12PnfMG9NA2NQZVRGM0WvWX GnwgTmy5XMKz+C+4OPF9xqPpdnfHu3EFZW5UKtHBRlihbYT1xEYa1pAaT6N/YdRIOKxBUCUCa2hI m1CbbBNqlW1Cta1NrDu1ncZkjEFr/gnSSDdi7T9uRJFGtLGxvqv2NGpnNK/5UJ+PcH5QX+h8SzlI IHGx0wArOvGJ/ZNcuQDWpc5GJyfSQtchCXR3cgKwGSms5zQ18fSMAyvVJBAA4QrBuQ6Sd88mmMPh Wdpht7nV7V8ayR8YiWUOfufWeVPDULpzW3+DUqakCNLevX5n47aH1oa++cXe6W73xjVds50WpVIq VSo3ZXPB3M6u4lwhmGtc02QHrhkkoxqr0+Z36uvW3b32rDmWjeTGunsBuk8DdF+X7EdqYYX3JLBF ubdZqEo2C1XKZgEv+JrDq/k0+lfGbozqwBdFPeArohD/KKxaRiHi0dOYnKEQo7y5yUtIQFiTnAoV 7Dm6mAanz0sGOacKIDSnK1XeRcwmRDcbNi73t7y1i/yJ1JpMXCh/PbXjsYlofy4XlunsRoNDJwUs FxBynaxmgGVrtn9+Q81zxsb1jCfD9IV753sy4y1W9L1DLx/PaUNtkdtkfCIvk7SKTO/SbyKtfnro /u8f6js23amr7U6Wnx7b0LHjKLCgTQAxD/4K0oQ8/LwDgQPCfO/jHaHn8f4CbA6s0OT63ZXNrcsf 8E0vTMGo4mpUbX3PzchVrBukxNiCvoB/2ADHfikVC8tT0uepQRj/oyXuCY1P8LidrbS3pFUME0R8 KR/wpVdUqTyYhLR2DIzHtz0109S1/+mN0ZHeJgslxXQqTbhjXdvhe7zMREd6fTaqhC2C/6a1alXW oFPHHH3h0AM/OtJO23wWtd6iC7u9Nd4Xn9tw/3g0EPXL9FxnCOAi/aXkTuQQctcLu6ZGdsN9FRIt I4jjNPrxC+HwlOFl9GNEBliPgrFNRUuz+WzbcBuWKDJFrK3YVsxn309Os3lwq4x80yDiwH1FddEK 7xwvcAoD04RSNlXSQlc0MSGwa5hgJt8+f/6CFsY8lHed1TkDhwK5eCEUEmgQsTJIxiugNJlDIQFU 3EjcmX90YNPRAR8FsiWL20CaE/mGzNE+GZdS6WUKv6ZzQ6s9EOMQVQXTI2kB0XXZWg5RiH/7wAYO f2bvI0PGOr3Z0LDzq7dG+pp9Krx5oL9z58PbLr0Fy9AEeMI0g5O9gfF1lz4vXiH+FcPczWwkO5hQ a23asNsVcPOS8HOSMNJWndIadHAyO/6Pd6ZJ0tFT13372gYJyPhVgpxOAjkdRh56Yf0QsxHKyR1i TAd/iIWRGUQJpGRCdmJ7T82ZwGNI/jIG98ZvAGJzD80oJHv6baXJfDYyHMES7Uw7FmmPtDfXv+8d Y4FbkJ7sH9QWJUWOqFfLCkpPkBcXSOiPku/QFbGtVB+4CTktlhSkJIqC+HmSNHjtdr9FLS0fXyIs X3xRWIfuuwFhoetIndVnsfqMcrWm/BI6q5TboPvASRWF/rGsWiqw1nXxTyOwi79C75CrKBwnFZQS pKUvlYNaIy9FyY8ks8jdyL0LyOFbh3EoRrZlWA1o4seMItWZGgaPw4bQJuhgTIezo8OjWGKamcZG p0enpza8V5hnp6CxUbcPpiwldScL7JQ4GRvsKclyXPIKxJesFiJXduTEBztySfqnIHk8q4VGV4Ee UAABd5iGmapERQhVCoEuVCLgdcsXazEZ6jcfGxv7zGj0XRgBtfS7LTlzwGGUSWRSnFQ7wkl7fgfj OqzREZSKPGyNdUdquuutrgQlwXRKVbC1Yo2if6v2hkDAw8YovmDvjXbPjtbXr79v3SSptekDnrJr /xQlpyRqi87lU6kUZHDgwHb0E08ApDVkoWNDi92RzNW2jiTVOmu1eHnPaKj2oUC8rVKY+24FMeQZ yT4khKSRzzPubDuqsKchk0nDXnOapuETiBppGFjT0HEiSJyPMHEhsMSFwBIX2E1cCCxxGHzlem9O kQ7bCXUtXCRmKQBaRLygHuQss8SF3qzAWaJinzVd3ZCupivAuBbzm4pZcoJqwZ8htQ4DHPnIP715 xxc21CS3f2lq+H6GNLhh/KW+1fOZ3iyItiD6dnk7mVzYKgbbw4PrB+9/fvvBl4/n+3owhdhZvdQH 4uz2eab32AyIuz0NEK0JgNbTgAFGkUbkOaY23pxtnm3G9ZB56D1wkELvrYNt5TqIVh2EsY7jgiBu fnyyN/rNKBYFIJ2EzKSREAI1IcRj7rWCO/JkkID4eb11P7uXeIzAfkygrxEoQTjib4UKlg+2qufU mJr6wDEoJOOLEyc8gflVlA/M4DI308ClrqtqNXgdbuYAJfGnw9ZLJ1y5uRFmuj+uBAkgjgGbb16/ n5n99u1tHfuf3bH7ya2xb+F3He7ckvFhGBb2Dty5vt5oM5Jqq06l1ygVVos+c+T0kYNn7uvrPfB3 4/pjT9QXZ1pgbA5e/gR7EPj8DmT6hImGZIUjKXaB4dlFZmcXqJ9dUCY7XA6fqA2evvwao6O1aDEo LzXnbaFSgvUUaZZz80kYiaNnUx/xfCR1dklbotolVKqVi36Ab0pgDxLAjEmjK2IPNnrUr8gUlESn eQUmzRbgrO/h84d7/Oy+gr87ANuaGr1ZLaEUlCU10radt9SLH4pOFzfy5jkx+dn1EZVGqbdDPQqC yNcGUJhB7kT2LtTWGgNxyE3S8i1zcH+oEaMxvRN6SwXSm0nL989tISR7gPkwhm2F9TlXqZCvbyv1 so3FAEsXD1ZTWQ4EkdGeTXGsJHUhyZdpq9o0VZRWKr0xgMxCSFuFAkvbgOFBCtxXI9NBg9SSBCWl UokGc2ZNvfYM7zHPLMWzdsODE7bWVMSsxlFS67HB9yIFtj+8/XMbar5rgpS5s6sv3DPfmxlvXYky Ez/BcYC5tXG0ZVUhbJ14cF2EIElSLpMr5dfg15yUZIckdyE65FnkqYUnnph9Fkrn5PzUVGHjDng2 q5/NRhUwzFEFT2EWPOZBfu1g3E0P3jv/LPtM6Qu5uR3zpQfZO4q3FjeyfcWsQh4lEmroCdsGJeDw YgKkRmMla54Tn+APeTkm+Yp/SmAqXKhLc898e5CX5xL00YqUlmQqxhsWvHdVHYD12KpQaSR/Lson 1MOlNLa/NUN52oE8TWqCq+gDcdZw4gQZUIpTkL58mNTDHIlTEDlQEBNQEN1LwOAIreYlUUHKe5eq SoDdk6/rNsqB7clVMqOnxlboQM8vER/m2zbxwHpe2NQyYW+vqA/FFyoo4qe8+jSNtOxYrj7LVWkd /OkaigAGrfc4gfXvnNsg+Dfix0BntiGjC/m8bywA/Va90gSVxL3Wp/PpkHSqXlbalB9jh0vZnN8U L6XZSNFRVHJOTBA89GRnU2eh4FNcO0Kw3kXQb0pi3sXLxI8hiG4AYucrvG2+coPQPxEEV6M9RsB1 cAntccggGJ8axG2L1wQ8pVLgKfchkwupVAtsh328sMnl6oFmd2JfrAUcTg3me2b0VhqSSOMthalc uDSWb+kpDbKdxRhrFbKARd8IE4BzKb5sD+HVQWyDqydqn9pDCjmgVMrjaCBNlTSNg/XTOkaQ/G08 WvRar5KcfVpvyOd9AvIyBmjyk8hnFx56aMcT09DjzY2NZQY3wFi148kdjZznyygzO8BjLgprMU73 kYNzT7CPle7NTW+YKx1hdxcnioOs2ZYuBosJIKAXbQVtLl+SiA4Plh9Xc3fLnd1S33btJPu/zMl5 sfIKPi3/aGHj/IBXpuOLPJb6/kTmaC+QIZyM5AJfrOWm/NoThGUlP3Yd6TlwaHLqJh0ajIGf4KeA FuiRdUjP833Iy9htiBxxA9tbN+KB8jc2J+pG2MFSR95TV2rWSJrZUNHKGdz5c3RJlOqF5K8+On/h 1eUdSPw6RHFFFckIZ0nwU5Qp7HKGzXK5Oex0hU2U7iq45m/tNdUF7HIpgQFwtbago68NI21W4p8d IfgTQg5H0EpR1uDfGq6GEB9QZJRcQVu0HgcpI4Gbs1t4PveJ5CMOpXlk/8KaNbE7ITYLdRN1ewEh mD0lrwOPtBu6rPktMS4W9HSm72Q1EknPwdKO/BZ2vNSfi3nSpR42VRQBrMQC4KDOiTCKdYtXOevQ VZO6q2J6FXiJFULDcswlH1HmaszNHOacnpf3XEur3aJSR6xcxMgBkcT8QCQSTK4iddaQva8diMR2 3SJZTYFVy2LJKhIrPy7o9S5kw/MbBL1uAC5ul8+3a0cSysjCdmcShlt3QDGxU6WhfDJTYtnWIvB0 xPPWYd6DJQXxaFMpXkLngMMCuv7TVeUidEN5wnbTem/N3DJsiAQcCgmOEVK5lLJG3M6YU3MzdvDJ xS0Hx+rBN1EKmqZ1dpqk5PpYfz/ecWNWUX5csIpHkbsWjh2bfGQKWsAeH0B7FqA9Al4k60ch1J5H J7smu5KHZvesSX3pEfZzpaO5qdE9pUMaySF2pjheHACQv9g6XM/WLnJlwcNAExHAPyfyJYj/0pRH lIJkFWy1K04zfRoLWm4pl1RQ4y11ASsHvorUWgH4nMZD+ZlqePnhJJCfxuy1OWMuzQ0YlRAplorx tZVFc7HIitLV6DRQulJSCsTbhK+5YQvjeYLkAmBos8jcQm9vPMP+EP0YWYsYsRAiRQKAKcT3xMnT 2N5T2jh4rPWfxkYZh3VyfG1raTrPri1NskPFDFtblAaUrqKyH8mJkziVlL5CCjhK8FHyQkW0V45t 8TXWSqaD3hSDw0cg4LC2avFZLT4TrK2eQeeUcpmeq+BqpOUHRLFgMlKRaEqYrs3jmsICj5Psh1cv /usKNVVqxeLtjRM6gcM5gAU+hTx+BnkA23vy0amp9j0dkMmx0agpyFUd2ve2P/4ykNZxRAH5nOku Uzt4sHIoqCAyWmSPKySf67875y7dnt/D7iqN5zribGmU7S42FYOstkKvK+EqmxUo9iKXA0K7ks2t Noz3qfnaylGsiisuUROZQ6b32RYFyQUyIEhlnBfkdRO2JVbIk8SmsEmDiyQRXQsL9ECJjHK1GijR rFKxcoH+U+WgV9gjUIGlZHFFHeN1A/8msNs1SGbB7fbn5NA3r7H6oTs2pFPxgZy+lM37+fTUykpE SlJhdOcFKwzedKKEf/MmLInLiKw3YSfcQB3vx/4d2MphZIahxsYScbdbwaFxcms83rGPyzcPTyUg PM4c03E7gGdnfordXCrmEv6OUo5tLlbhtGgMFbD4ZBNAptXdEGyfXucl/y4qNs4rtvEmFRvAXlOV /Vj/CzV3hXINn4X+nvguVynd+DxTgCmmcsbvRxpnZpS58RQC/ZeJVg4BesAYpwYZNsW2tZliJUe+ gChLJlbKtRmSPEnLZvloAqRxFgpDJ47ZXxXg6gKyCPE120vo7mUF4/y+QjDnUpI4LpVJZAZYX055 NOhTMtjCBbnju3CRp07zXjNrCjqMJPgigqJdkbgpP8048fpVSso8iNUV6DfE5V9vCF0j+YTYNXL6 aDUlDQ4cGMLgGuImwIEfxn+OZJAhZAp5jTHqYnnY68nLlODJQ+vRYj6VPX35r7AQnxW6POD4zin4 VpYcBqeMSqNDi8N2QpPAUyQJexg0V7X/MaMCJ7EUabeTqRgBK/1MIyz1j8NfMe6hwbeN1wYZBTgG NQkSby38H+XY+0bj1lb8tx1sraf7zdbC5jc9w8KCgyw341J6gy9tR1PnYInfDAIJXIilBRfpc1Hw Nyo+8dUyv8gHQmEpYHwmM5fVLxLCFtgxbG4R+4YmM2CCaGOoMgAD1wuFwmE1LrzCH9Zr7vM7khP3 DrXssOvMXc0f9syN1jfu+db+fU9vr6O9DZ6GeDLoDjRuua8YybtRWqstl2cmEvm4eWZzAxs3j02N /NYTsVDH7xiYydjxg353YEN86M6xOqdJV+/y12NyzNu5sT0zt64hyGxs9GZaU1Zrsa5zayg40T14 ZG2MknnLH23Z5Wntr9m4093CXppsy2IyayxSY+zqcSYyXFcPSPYZ/BdIJ/DuhRNJ1xqYjSJqNZKD PSVVjRMZbe1PZta4CH8X3K0xVgAEGz/pL1o+lPCA85VojldfOMvZyWJ3/EqK3HTFog7MXDGR5R26 lr3f2NuwY6zZIIO5CiyO9N/ay2zr9kQK+XxYbNpF8n35iNg7WNa2C+57emudQmdUaWiDEhaP9Va9 rXOmOBNJBzSD939v+4GX7s9rg+2RfRQ/gEmV/8I18rJ9x6Y7dJGeBuBVngax71nJfiQJ8pJsI1q7 uOBZaD9VrYQWVkYDz2N2KWBTVAH7egrY4VNwzT0FfE+OMHCBsauWK0O+GCsEcpXCI9BeNC4sL+bH i9JXLjJeWrRaWt/Cn72iwDTfy/sMPSkOF+Uf69909YJg9USRWOPDkAcuf4KOSOKIEfEiX3gx6x/2 z/pxkzCdZhIw4F7ruSNn3CbBE5gE0EwvY/sRB2LkkTIK32UU3jWKkBoBTKfkbgZ8J9y+dcFK93P4 vFGKCj1Lof+78gpsPYx00FiBlaKZpQDo69rbovBfBQL8OMnfMIkm2mojafAPrjZ8CFjGV8Ad9yPr kG3IxBmkgM2dWFOzBW5Xv96Vgf8pC7QTrrSpAHayI+Py9/ZPjcFPvHGwvj+91E7eSAJKBGhutamc v0Cfv3ANc1k2utuyuHKm6lYlVef45xtv+dotDZPDDWYSwwgJSBYjfdO92S2dLl9frhDaeDjvgsuL YNgxRLvj9nRnb1gML5d+DuCpjba312K98Bm+4m1Ja9Bq1Aa11g5syczZ0vZgc0DbvvOhQSwF7AfH gSVd+nXbVE9AG8kmsIPitQqw4j8Eu/x6+XF0GuAbQBLIgy8MJ9GgMF4Gjn+EehEU29tBqEYKeAFA H1UiwtdVrdXn9aayaB+KRG61Isl6qEP1QCIv1Lj7DbAYwwsDaBIvBa7/y2sT0CUJLwZCcPFXjklf oVYjLmY674lZKALFSYqU+s3euEstRnK9CKBm+ujaqEyu0upUcI8FiSHG9uN/v1zdeD8zD/xMI/Ik o8w2o5EGtIHRoYMNpy+/xt1cgzAE0ADvXskduSGAhpexMOJDlAIGSsENKQVwlAImSuh6bKZYDIGQ 8C7I5FNIavoduUpixiVjZ4HTidNcZzz5jmhlEytlYKslTPj8YsJ0fKn9oWtlwgwSpYIzSLepVk5x Ft3QymkJjxmaAZgZEYbb12GW29dh5X0cFnUE2K2cznF3LCjAyvs4LPMc1uUfTfgUktdABF2DfMDY dTSMDdDjh2iFEi2GLfB5bhTNLd8xA3zSK3fW+KASP1wuEzh1uZL8Pg7cjg7cZg5cGIH514trGC06 uCazfAMS/scu26jkZfSvIIjRqPTEQCEA+1+qrkImF2vtjxWtVfIXlgBxck8Le0GARETYFAJGI26r 1KuFpNVilFGYEReURfIaH6qAB6rrrU8f4HpdMAMx1fXUpw9WIhdc/mRy0mTx0f7Wjb0JOjYykA9s uKPfvRjD/OklMWz5Ffy46IsOrxu2xbtqGnpr9SC4FcUYDySYRJ5gNLwE4ZMQ7pdKaZX9T+B4sUsB p6D4qA+5K08CuPgP3n9RCPxc91EeK9RaA/0i9JC1ViK/uB+CgPZ1hH/jtcJ/BcSvDF4j/F8BFABo K4z+cH74bYAQXEH2HcaRjaA1OjSihTskhJRoSIaGSLQWRyMY6hJGvVwCYC7BbbmE2SWXAJgL0ktX XI7KDXAG2wDhMsDpKAOc0DZAzAwvYXK4c8mLGmRwDojJCvcH1xRAoo0JUyxwpliATBwuhr5K+HOt JWz4220H/uH22f9+W3P6wHcPgGPLc/bM7mFANL327O5hdnevB/3NbWceHOi+e+F2cCyA43z/se3p xqljg4Vj29KNk8fgNHr5Cfx1gA2cRr8XTqN7m+WClsgFLZGL3kcu3L2cI4lGfhCdG0m3wLf5mfQV J9H76eFVJ9FXGkRfQUdWH0T/8mRNbxcTqFIWg9GuIyPFwZEYnKp5zpjiBtFz4d4jPZmNLTb0t3f8 4P487Wv0lzOiLyR+K9Lou2ozEWPx+PcO9d033aEHPLr81bHxjul5wVti3+ZWRuxYmGtCQxoBIo2A jEaESiNgqIFQ6RBGD6MWcHkIxAyxAQSDDBUthDRGT7+xiAjOiwtf0Qpzrh7qWslsOEik2LcxKSWT mZ0BozXR1OZfajTBrra0U+UNOJUEjuLbTS4tRVEyQ32x5dL3l5vN/c29YQ0uk8spNTeXMHK5hL0K 7rgfeZVRxgeyA8MD9wx8b0DSJdxgl4BAl2AxXXA8Xy+8poWjAh7Rtxh3IBlIKu3Qw9ihc7FDh2OH 3soOLcj+EvpnbrMfOQzySoYL/OBlCPy8rPJ7SkxZ/6sW+YfaNdqt2jkt3qJt0Zo6ftlll0QKpvd5 1QIwCtOzdInmDCwqbgnEr92rMG/0CrZ0HUv4Xk1NHhtKbOhLmOSEVEEqotn1rbW9SXuYWbNuhAlH Ro+OBti2iJHEca6/4Wvuj9cyEWMNM7pujAmj6r69QN5mqyHg1gM2ZffYdf7mYKixxu2LZtZ3NG3r r1PqjLRSY6Lhpgomq0nvTzjCTTUeX23HWkEWkn2SWeTLyJd/hLSibyEzyBaAWBcyh76zEIjojz4A qWObxqrZ1zXTpddo9F0zxOB9yOBR1l06lGvdsjs38OHomtGto3OjeP1o/eiG1Cuh3YUN7+cGH9CU rOzDkGJSvG+qHkSmYUkizZX4zp/V8bUIHT+iRb8NF7QKy5Skq48cY0vhNF4V/qrh8lVKUJJ9GEEq 3TVc2ch1VKOD24YdsdZ3R2p6Eja/UwaJLeVrKlTL4OoSjK3Zk7FGdSZzYsv9a0fn19a+C7cgEytV BlIqkxKbtSatQqERi0vVI8kNuQhTcHhcKwiv7eqib9vWF5JKLWyoe3bkijnoSkUL4dYm/h7bR/wD 0oZsWYggWn9MsLiYYIkxwRJjQgyLCT4pxhUTzapYyc86VSUz2wDFTPJiPgedTkqYRz53Nlm1Acuy GuEqksD2yWhPpN6cm2acd/Ny+IxIOt+DpW2AYEveHHAYZBJKQmyuLs7x+K1eyRPum/ib5E5kGtl4 crSrKzmdgjdkHXKEkkjSBx6q8aFpdnJSmgoNlcbZFlgilbODdUUHaypJ80LAgcVRWBoFd3tW6NWc E+bNYIPtyjKoUNBZpUh99Sl7ESq8zc/u6/f1wNFZrhIaTcBBW80rfPnzF6KbLkerwFkdSfzFxcla rgyqU6wyh1tdB/VqV4X68mWILP57SRwLod+BG9BiQexriIA4/hbQtC6k80S8i4Y5R9Tlimqgd1Hi TdEulo6W2ptYmJK+EByk+BH3c8BnoHFucAPWBri2ZfVeYdeP3HdcJnHNSDl+nejYbRe/csMYCNr1 L8S/AVe6FdyrGv4vZNGhcW5yRdWtcoAH0hRdiwyxXWx7u4dNsBg7ro6Wmlgd/E9ggoNbqowJ6tjZ CVh/B4Eclt0rKzc4OBYtawkUy/2mCMXiZivalUyP+BeZlq+cZ13lriqkMJzUuGpWxgr9kZjoc6s6 dOr3mvOVSvxmp5dWywW4qlDUGrQqlWo1HFFU3KusfHmZCXMYk1uBBT+C3Hti+8EeiPHkfWFYqu0+ 1E3bINih0LHQSHdTyGQKNXWPSJBbJo/edvS2W+Slh/L3sQfZnrBtsnQLXKtGnBgfhHMpJzsGK/Pw PPJJvgIJMIc2zkcpHv4qGVxzTn5lLb1u3a0SWKVNRW4lJJSUNDrhpL1bU5m013n5tlRdFf6k1hte QZ4y2ntNaaLn4ax+sMunuvas/ir2cZ1mUy1uziup1XCKlfco0jHOoyzwHkWCiR5F2gWsbDey+4Q7 M8w5kt3J3erdExO71bh9CPYcuxtgdeNE0D4GPbh5epAtZtgGNhr1tCZasdZhxF4KsgQ0N6NAUQRj y/IxDHoeTuqcuONcu+vGhXYdLgudqZaM1r2KT1qUDNbjNHMNSrhVUrxK2ovWi9ev0r66Gvar+7zq /heKPAHXPuE/QJLIlxl3thFVhCEDD0MGHob7BYa5ukyY5gow6Men+EzFLfAKt8ArwPGvXG4DTyCx cIvJjlvg+G5uTlYf6w8rJNb+AEj4FhdA8VvOCPT7fFVBZtkCqCUF4+bFejH+DKlzGs1OrXTwKa4Q IBaBzXE2kTnaRxrcsARMVeoDh9cNdex6eDvmq1R3/zQ81RMcX4cdEq8IOyniRwE+dcivzyD+yyC3 hWUvtww+B92oiz9xoSbhPo3C0bBYDOOOOuGoBe8zLeCkRYuGtGiYRmskqK8GXOj0oQEf6oWnWS8a 8KIe7qoHDXjQsAa9w4t64cIfSmtkvR6Q9Xjh/owUIHNeuOoKvoKS8MKfrwTf6K3p9yps/YqiuL0B hyoSneDqCFH+L9y1cYLHHe7eGOV2Oa5sflrV0NKbW4TNHfCjKIZj5XPctg6uGquaKL9KSOA2nWan X08RZQL/GybXe+1ml5bEv05QciV58X/AbRwImVqOb1DqKByoKQaeqEs2pRJ7F+6LiMkUEO2my59I jgO0+5C3zyB5kN51gltrha3YSCvaAo/BejTkRUMeNORGQy405ETDDrSGQCM42taOtreh7TG0ow6l PUZ0kBaaNfDIyIG60h7wE2iNcBkeGSVMxOFlTVc/93UQzCw9TM/S99AEzehMLJ3qD/a3PVaH1sH3 6mDWSetN7K66w3VYH7hqLnIs53WI5MTZbPYcQJLHe3F7TH6DTP4PD7S0gjMeJqs201gB8qpTyXFC Uv4LrjLXuNy1ViX+jxj2PVxli7jcYfCq/DHwG4AdOXyA9ryJYT/DKB1Qe7dOhv1vDH0Do/Rem8UJ xUIaNItCwb5IUZf+P3tfHh9HceVf1dfcR899adQzo2OkkWZ0H74kH1i25UM2+BIYPEhje4IuzyFj iA2EIzFHMARDMJtPwoYsSdiNMbaxMUmQfwvxEuz9hQQIhCOQwJKQmEBgY0Limd+r6p7RyJaJf/vJ 7l+rZ3+nuqe63rfee11d1VNdnZ50kcmm0ujAQyoDeEijAQ8ZYOAKzcoZV2GLUdPVuoK5e9jPg78q 0KonkBcir5VEthfXeLGL3ip24Spjm5Gp1mAPGbLP8GB3B3zOdOPyxW6tdbG2l1uBepVbtF0QmhE5 KElwBlj5rG+3VpEFqFqK66ZY5amjNhXTfLXQ2OSRREb4vMbM5p5Smyv8/qBNw2PMfiKIQclXIQq5 Q2aR19uMuJOzaNnL7C4jz6pNhjNR5iWrjidtItRkPULMz9nDKIJmPoHMUBMHWfm0iq74GoPvWzQL NIymUjyCmQPuRaZqequut7gkx4aTcF4pNzT/xnocMCr6uaA2qs+8ZPcSe+M7cteZrZzGoGE4nahX kX25LP4nGGAKC8kSHL5A0OhwuM3M5wKVZLkcwegQJaPL6TGfuVdlps/SLWCeYbp5L6qHEWDvYyr7 DPKabkTmiBzB67vLTJV7JMlrv0uK4oZod5SJRrXePeGt7V/RZti08gwqeXISxvRkHarJH7uVX+HO s1zG5DC8dLUMptvrD3gqN8yo620rD/cOzb/EUN5cVTmr3q82WIwzB2cv2NDpuWVVeGaVpamurquC +bVerzM0VNY46rpqoxfVO0LeWp/BYhdDPqvN7yprWxa7Xu+QHNXVFdWkrkNQ168JVlSF2lHLY9ry hifxWnL7Ft/aLSJrudZY92hwq3vYmG7ez2cKtxQ7O5XltTqnPP939lVFDjGVcjfaLt9HZL5GnlP2 NUXrXd6g2WHkBbPHZvOY+ab1zd39HZ4vG8qbKioXxsI9NaGmcjN7euHWvojWEXLN0hvIL/ysjycL NwHknq2vjPV9bkHlglappu0H0frylvlkFRiokYt3owYUfsyFKo9ATUxa+31lwa+atrL314X/QZUh D7iSxSYKS6HSRV6LDii5ISXIXqD1YFwMpwr2z7zl1kjvljm2SLjKqRNgwKlVqbThrkDP0t4lkblV OpUKxgQtBotB6wrce8eKdG+FoBNFrdFi1NksWi7g3BjfeGlZSCO6wPqLgOs1gghnfCtqekzjbn0S r4NuXD3e1W0Wy4fdGjb8qGNr0wP6ksjqlNdsKgbUhT7RDLF0jTsgOkxCLD5r3qWdHmnuFV2Nq8Iq E7W/8KVwT7gCes16f1NVxeIo87Zs77mxxtiK5KyF6RWRqioc5dUcCw0bn7s4GpVa5ocqFrYGIq0k knqgLiNw1lSiKJq3Pwr9xy8e9Iqit+oIXtvtRF7rPUajJnqXRB45dtXcLW3V7HFlCmuqbi2+MMBS ulJp8elih32KiyafLWZGPNbcXZaaeY1VXU0BrVZtDEYa26U9e6qXXLVgIfT3vshdtCDUUmFlOORx V8+udehgYO/xuY16DX/3noVbl9eGF17eJi7sdYZb/KQVrmCew0cFH2pDsYMWCzI6juB13WJtVVB9 b8NI8D7HfbWjvrRxlI6HTsnTvz5senpyXnjxjoZjusmKbZMTwfBRhhNYIeIkvdWs3mjQbROMXpsd fLFcB2fxcmfjkiZno13DM/zPjBYtY9B7a8s6XL4yV64LPMMR9+BjrjKfq619VatHrVEbbGRGQi0+ zSTgDJiFlqJL0a6n0Eq8AIWRBa+CBvkifPHhxghIpXc2eQ2vCi0jp7wXXYLXdIcruXs6R8Mr7+m2 99kZ+6K7TFEV2wYXdL1e6r6rbau0Fq+9q1vCElm+Ra1bJI2jrsiGU1tlH8Kg4NRLG051KsuXvPAa WQFDXhLjLboS1N+cPtV2zuwp+K86d/aUIChbTMKg6bUYA3PWtJZ3WLSGKukr0aUtvtDi0d5Fm+b6 66p9UsjjcAfnrG32xeyP63Q/mNHurfEaZrT4Il5DtDX2xZCrd0FkRsjEvep2WCOu6KImj0GvdZot LkZg7FUdwfD8ljIYK0vhuX5DzBOa6XR0RmKLmr0C7/p6Q7tYVm1raDGXVeQ+5/cznLfaEZJMLoms hMs8x+yElrUBxfaHLcTGPqSDUDIhnxh2GvdHtgaHnWk+XZjQ0zl1yUK5Ka367Gk8zE64ZNms0Hq2 d4QW1fByUyoUmtRof8OMlU0O5u1itHQs6onV5/YUtksb09pwxZyLO8mZHIczgOH/QufwhJ5CDvwL oI6gAuQxLc9Bt3mMsn6jsAak9Rx+7SVzIP6TN3nsBVZ2j4k3BBuigWC0ITDJi3EJaoFhAA7X+v01 teVwJjL5l/FprAceQWhRwjBewL94rEaPSBPpRHXY83hV2Zjtfn6ctCGUy9MlK9lxVDlt96anhZGl flGbI+oA7Tq1oDHZxcoKlclrJVT1wVgsEIrGAsyzDcvb/IJKpbeafU6WZ+s7mZZzucrejoO3W9DM uTrUiG8jK8mCyRxA+xD0JLT4CFlPlsykGPMNiwW/K26XV5QtuZiy0/i8fXL2hMrqcDBxlcXncPhE Df/Tsx1/kNNaPPS3OY3xoed06pIIqM/9bBrvB18RtAJLKqW2WR7N/c5ikuuEPoI6ySsE47UHteZh ypuuEHyu1z86m8ak2klVcrnse3ClWIi697eFyHvCo7NE4lYfWgjXCpvWuH/uVml/59ZZbTVNYzVp Z4m1lHkHsbc64d9nnipnbxOnyz+AO4qzxN8DptThLa3S/LBg8ljtXpOqqTU4r3guuUMhZ9PljYtX u7zNsZhrxvJG2/nPp7O3GZce/uY1R9tjviq3rmL2qg4lVq6F+teh+v0V4mTLYEQ+46PVWyuc0lih yvLv/aRd+OzKTlaOtArXEgdYoSZtHaGecKGO7lDA3bSxeeaqxiktwmLC+J5zGFOuDLoIruoPAlcr XNeD30c2vIusCQv9E43Wfa9pa+ircq/wwpaDbWMerFmRWrRibHGweml2+ZKRxZV3mCpnR2tnh23k c/lq9vT8sVX11UuHe+aPrqyr6R1eHO5p9ftaeupqF7aUXU57rPgT5mvAiPRY2x8rb9ASA9ppj9WG 7KS7qm2IlXO8d8ycLXZaydTTU9N0Ws86zYo2PLfT2nX5bE9dbdhZiAve6DAHPc3xWZOd1kX14YXh imbSae3ZuiKisZbZcmd4sqKqANfwU+Q0ANM2NsRWXEU7rZGWH9RHSadVjgn8PB1zVB0IepCJdJr0 Hu3T1VuDJrt/zJ6e/OX6w6ctnVPvr54bCfILFvDz0GXl1Tpo20xwIXSUxrSrtipkNQYcKuiP/VR0 GVW8wOtc4bLct6eGQk952Knm1ILRCSznMc/gU8CyCy16AnXiSw5JdVKd3n0Er+4uQ/rau95s/KCR aWy7293JV27V3jUh/kRkRMfdfKZ0fdcN0y3wWvLzZBuMibipPxMpfXGo0amKrvWt0sxouV5geRWn LQu3VdbPqZ2zuKtG6lzZ5G+u9uh4+IYXHBWx8qZIpGtJVy27LTKv3qUzmfROu8Gq580WU7DaF3A6 w92t1bMiDo3eoIVvRD1vMBtqPP6Qy1E5h3glBPXdxz+ImlDdARQqryZeMVtNuvLR6vvcuvuso5H7 VXL8n6SPZTz94TMvlownzu7yTekWkoEF2Yf3CVqHP2DaeMlynU6nXyYo/fHbYEt3m1TrqRI4gWdY s8MF1ynusstxFeny7eDVPMcB7KAdwvcbm0yczkIj6RlmJ2+Da2b9fk1IHlCUkdZFDGnYmjHnmPRo cThRXLpsmsFEyd1Bx5Sbg8xOd8jiNPANieaZKxsdAvRAbG6z0N4ZWFRTaHiKo4cm2pDgpYJ8Ggi5 f+tZHKvHQ4VtYuVy5gT0V22oGjU/ZgmUH8FfOmgNqANwZejv1qmkQMDgGTOk0ZjcIGJ3zOMi4wRl LVjyyB5cEgs3fWDMM/WeD1Nu85rULHeU1dqCPl/IrmWf5HmN2Wdz+CwCezfDfolRm728Da5+epMh Z1STJyrUOjX+o17Uq3mG0r7CasUPqtQCC3zrmBPsvwLf+Wj1YSnQ6IjFbPVAulsXsFlm2tSq2bNt XeROgaiytY3FZttYb3jMmy7UQF7wvLgsLF0KtrAurPzOlLNrVH3+ypUk2Z0QNSqWe4hVWwMeb8Cu YUYwk2A1NrJl07L/yLEq0WNz+kQVs51hxrHK7Lbb3UaBvZ5hUlgtyjbQmYwlNkjo9bkHJi1iNOuK FtHr8YOyG9VCboNO2SL+hPHHJrBPAM0h/YbHD6jVWucRvOtQwCFpHLYj+LZuvdbhG7NrTGOaFDuu XOimLvJL2wblllU7O7lwbHtx4Vi8nI3UOstMmFv2mgob/R4X9IW4e5hbGEEsc7n8JswzJoOOUxu0 +xmHyabnGJVel8sy+A6VFgJCZzUj2qY9jz+m7zFreAKZ8cuP+20gKHgEv9Kt0wTE+92jptBePgVN 2AT8K10wFk+5QWUNFW9QQQtMHEhP74/Jiwpyt5rAtlrVqV/rjPSye4VZ1Jre+zNdb1ttshlUDrtL azKZdXipx2uEbYvTbfXZcgd5MqZjYFh3mM6r1yE9spE3KGw9KGhYssLLGydx7K3izSW5b4tXFmav 5/ZxJ5XZw7n9pBxOwr38zZPlbKPlDJ6nnN66zo7aSGdHJHeIr2yP1LR3QDlPIwZr83/Cr/GXw4W3 BhnhO+8yM3nM9vXSBRnYquKU6Km9AvwDFXmJns+iErHaHvJ5Q3a1UeMOl5fXuDQaV015editwdnC jDH2qN6i5wU4G//SGYh4dTpvJBCod+t07nqo0an8KbyPu4Iykb6PHMwgkpCd6XxcZ64FXkkEpMxP n9U/qWZbzsdtDwwC7A6vWcCiYK3weYNWlUbjqCjzVTk1GmeVr6zCocGtZI09FoDJ681anteZ9H+V yqpdOp2ruqws7NZq3WGIrdrcGziN3oTRtfYxndOHzC+clCfxq5QXl7Rbi3rTcIkVd/EGq9sqOrWY u1nnqvC4K5y6O8tbovXufycxS24bY+v1Xon0sSUSF4tyv8R3sHugfxZDgf0VtieZFdAzQsy1h7Tl kQbehGInQSmt/TTrB4jTU7mD+EIKE1+EJeILweAUv8QbLG4LpXaj3lnhdgE1VpLqiD/qpGA9+aw/ s4ySPaHWqjgyxQ+LRbIY3Zc/jUfAGjrk3I+EI/mJx8n7wTTsUtQFDCPH5BckFINvJDZnVpT8H+6J RS+C/+Rsxbl3WS3/Q/C2er+ZR2RKiVPhr8wuV32bM9jK7O6AhROYDZzB6re7JQvHf2gwqTmVwWoQ rjWYNGBJG1kxtDzfwhzgXvys8iZYHZTnkkSOxR9Aq+GDskWW/y5ZKVwgnYYVdM1wiFEo7yJ8kIky s5EJGQ8ile4Uh+j7gpT7WXLd6F3rqEXMXW6BP/yPaoOGx3+u9pdXVfkF0ZPPQ697AZRyklGxKbh6 74Zyb849jD/ib0MhFOy2s+QHRJZM5GPpLXXWXq67GXWRn+PpTyRYgA63xVl89VaUpQ2UXB/8hys2 XHEpj41lbovHqmfbVnX4yjtXNWO4JDqcPjPDX/lsbv1LP8/1P6cXdTxcEfhNz7/8+tatr73y082c ILCClrab1wCjd4FRADU/gSzy73QWZaYU+TxEmFnIIsKP6+hMTJlhpEmmSCKv8D6wNktrC1OttBZO hwW/6+tY2cbqrR6Lp8yA+csuv/xyjoEBuN0nqpnNWca99fWXn9/Ewzic14n6H+OHf/4SfvhZjRnG sILAncytAH435U34R9xBsFjgKWjXv4EE5AGElpRhHwODITJ94cOX3nrprUmD2aY12LGlS5Yu5gx+ l8Vt1bF18+odrui8Wuh1e+xw+eG4L38z9+19+3OPfEsrasFeKv6Sf9534LINBx995BLoorK81kjt BXyOUj6hJ+ASueMxuwk9yViQBfGwYfJoKSGgY37prc+0j5/FR5118+oYHZyPHr8Bc0sWL1rKsaYy J/QA1EztvKgLv3XZgX3/DOrBQsDqIbxm/z687psao5ZnYUhwySOPHiSzCG7OcxBVv2EEdifaANvX wPa7dPs6tAFalwryfiO4kq+Hrc7usr5Va2Yv/mV/q9Dforr0l/5a0d8PUjF/VcVq52plkQUyK6CZ LKKhfHQVXsHByndxSarQ4ASKqeJcAWuhy2wtjNEDSopcTh08bAIjjUF1Yzhjsgpqg+rmWixAaDj9 0GLX5t6rZXiTz+kiWzU0h159S812k9Vq+lINVol+p8tn4mqxoxqrzX6Xs8zI43DaZD2zP4zttey4 6DKpcgf9Qfr5XfJiBZYsOr+mNF1GvlXjpX4p5MdzVYUX8fywNF2+MXcQLyUtdBnY8GOuCq1AF6P7 Hves7JvLdXuP4OcOV1ZFY+1cZccRfOJwt4HnlnK9RrLf5V518TzONZ+8Uaa+t7my29Wr0fS6uiub BVS7MLG0fe7bfTGuL8qvfNtTZfD0gUgzE9IW65bzuQDHCrN0yIIXzs6zQLkzyxbGJoULQnugmCp6 pZBol2+vqVSBdmXErCq452OL6Z7gzcTi95ZjQSSusQjYn3sXtsxl8lb5LSaLxXRf8FaSba8/EIOG B/ZidxlTHnOWmTnsu8lkObM3iD0B5o2gL/eBLxAMfFrwwaeTqUAg6MNm8u17RiN5K9177xlM9DNw Re4DbCajuPynjMCFoaUq3+/UHWE8B5Co1x3B8w74LoUuTFfXmZP0HT2lT9CrBEG+Cd1eqQQidN/s ktMh2XWfkik/5P0DuJbTi9AqlFtUbo2eEtKy6+/RkbZCdIt64SmGZzDpJgCL70HL83WuBsZl0M+s YTzdJtEv6kCQy2oJXVojHsG2/cIG+iPo60CoMHly8sUEynU7MA05OmmN/bqgNajOXAa9XEHQGNTY OIWpxWVxSRbhPehq8QvI7FjyVjmLR9Qwv6OUnaJL1AkTBcp//bxG9JDHKfKf4te46qL1rAcC1Hpz D/jk93Oc+RH53eY81ivctMSvaW2Sy1luV79ttuuhEdKq/6yzOr0WV7moctEBBvRt2I03aBlDmVN0 inruAZVGHmqggg95J7DwPYEC5OXJTlGn1/nkV2gSe51sfuvv4EC9hlt4j47V+50W6kCWZzGZwowK HgQOUfROd0WFH1eU4QofDnlxhQdXuDH5ed6Ja+gDLxbJjJc10GfWTcyyjQ0YkfecohplxnCNcp2s UWb+1Cgzf2qUCT815GWpRr+LHOTSEdSJZJ6FiU55eeEAlCkqq/OX7J8gRdApMRo44hsiFq2WI7jr QGhVjfkIVskvkm6i0a5MUzlJFrWlj/BFniFT9SMoMjmzYsN/c9ixL+/RymFnJobmOEyazr/cScIO rkUh5jmc5d9mVBwEAPsA7NnILMEDwhjssSh71sGey+geK9lD46QBZ5nFJFohTvD3DtIwOYKtB3xX 89cq5zoNFf6zojVLXnxNxtN7jBa4pvMa1VFWZ3KYbW4DdwTikmVgUMdk+lSM1iHCcE3Lj2IOzhu4 tpJI2ZjbhweYF0lvjfQ9dtK+x/Wk74EfOQB9j5tQ19MlnQ/6Q5hDGZlM7XtsnDljVgeHdS67yW7S MKHWkGipaAlgNfTILW49yxwe//QLN/5lO5mIxXA8N2fnDTcuWHDTDdd1MWT5J7UO2KwDNpdRNhWk 57GT9jzwv9Cex/UHoOch0yFdj8JDxkrXowUa91bynqzJrsdlllBrkNWYHEaHS8fO7OycyTB6l1V0 GAUcbK2w/p8FN96wcw4wYci8sGv+fNMXPh0ns+YYlme6rrvhJuDTCC3Kjczd4KMy4qN93VrqpL/6 ruNvKPXQZ7YnN6pF+ipv6iEOQzPxJKcx2M12t4kXyd1LhgyzP1muYjU2EfZruRHMYAw24kl0NTI3 4Bt5N0SOHS7SX0Q435t/jR3hW8k48glkzU8UntqfIMtJW9WQOASnm5oOEqAbS9fAnvpGW3JTIsgb bT6bw6tj1exNvNHutdu9elat1mhUrJrce9SodWRJd5sO0b8H/2uCy6aRW86R5y9UmJ2s+wLk7v+a cH/r73PnlV/w3SXyBUVePVeEsPD1opwhoqo5S1qoXAvyB9Uf1BUlslcjlMgl55FHiGgrFXmkRH4v i27WtPJlva1ENhXlKVkMI+cTo8r4lUkxbTYvEWtAJmSxxKeRt62Hbc/btzvanJ3OE+eK61vninut e61nidflq/J9T5ay7f5qWcptRXmoIFKYyoPTSWBl4GUiwRSVQ5MSureieoocml4ql1J5Rpaq2yal +lZZwoIiB8JPnS01rTXv1r5W+5uzJfJwXfu08n79jyYlGinKraUSQ7Fk7KmGyoZdDe81/kuTtml5 00PNxuYZzUdbzC3rW55uebrV2Xpn62/b5rXtba8FuaH9hf9x+aTD97/yv/J3kPgU2afIm51tIOsu UK7v/HZRnut8YTqZUTZjuCiHZuSJzFTNNP03yv6Z+2elQA6dK7PFaeSSC5R7z5U5y6aRNeeRK+Zs AXnkPPLHrhkgn59Gbj5HnvqfFvrUCVJvRBj65pBgViEfZvJvAJrzbwN68r8C9OdfBQznJwAjFKMU Oyj2UOyluIPm3Jv/DeBE/ieAx2hpx0maTeXfQVVQ/rOApPwqKP/3gH7QUgXHkj2786+jKnZ1vgVw Xb4LcCj/FFqL0vk/obVw7AuA5vyLgB4oeS0c+3PAMNIDRihGKXZQ7KHYS3EHzbk7/ybgXrrnOEHQ xQCuy/0FcCh/D2Aq/68oDaJBadD4ZUBz/n5AT/47gP78XsC+/D8AZvP/DjhOcUf+u4C7aPp2irvz /wR4iKaPQ73S+ET+eygNGvsB14CuNNSxGXAofy9gKv8AdHPD+Y8BIxSjFDso9lDspbg3fwpwIv8G 4LH8HwGP53+BTXDsHwAjFKMUOyj2UOyluDv/J8C9+dOAEzR9jOJxiifyb2Mz1PoPgDsA/VDm+4AR ilGKHRR7KPZS3Jv/T0BSmp+W5ofSPgI8kf89DmMyGywMNvwZoCf/HKA/fxIwTL+NUIxS7KDYQ7GX Yl/+acAd+RcBd+ffAZxABsBjSAA8jrSAVAtY9QuA6/JXA6byzwJeh4A31R6h2iNUe4Rqj1DtEao9 QrVHqPYI1R6h2iNUe4Rqj1DtEao9QrVHqPYI1R6h2iNUe4Rqj1DtfaD9F4Bm8FofaD8F6Aer9uE+ ZAXcAb7rA+u9hfvY1cgJOIQW434aA/00BvppDPTTGOinMdBPY6CfxkA/jYF+GgP9NAaGQOPrgOb8 TwA9+X8D9Od/CLgj/yTgbjhqCI79E+Ch/H/gIWB7AGepxizVmKUas1RjlmrMUo1ZqjFLNWapxizV OE6PHafHjtNjx+mx4/TYcXrsOD12nB47To8dp8fugD2nAY/lPwE8DlG0A+z5Dt4B9nwV76LxvIvG 8y4az7toPO+i8byLxvMuGs+7aDzvohG4i0bgLhrPu2g83w42eQnQnP8VoIfu8YOW28G/JL0j/0tA aHkAJ8Avt4N/dYDEv7cDkz7AdfkmwBTEw25gdQowQjFKsYNiD8VeinvzvwWcAM/upnx2A59XAU/A +bIX+LwLaKbogZx7gc97gDsglvbCsb/Ge0HXMTwBOX8FSHJOkNYS0E8xDAwnoMUjGKXYQbGHYi9F UrsJKPMU4G6wzwS0e1rACaQHPEbxOMUTEAkTUNM44Lr8OsBU/nl8DLT/FtAMGo+B9vcB/RTDEP/H QDvBKMUOij0Ueyn20ZxE+zHQTtJ7EQdItB8D7WrA4zR9Avx4jNr5GGiHaADtL+LjoP0tQDNwOw7a fwPoBzscB+1awAjFKMUOij0Ueyn20aN20KNIzB+ndT9OtR+n2o9T/x6n2o+D9hHAdfntgCloK06Q 6yCgmaY9+Z8C+imGwZsnwPsEoxQ7KPZQ7KXYB2WeAO3k2N3g2RNwrpH9E2CHExAPZM/x/Ptwzqfz WXY1ePxFdh2kk+w6KP9lwAjFKMUOij0Ueyn2IQfg3vwLgBP5A4DH8t8HPE7TJ5CWXQe1uJMlrcGr LGkNCPop9uVfZ0lrQHB3/hV2iD2dn8cOcQJgirT2gBGKUYodFHso9lKcoHg8/3t2JzDRAiZRF3ua Hcq9z57mwvk5XBjK3MiFocyN5JEIJkhun9F7JoMUWdrzMNItkmaQkeWUNIsaWIuS5kry8MjFzlPS Qsl+FfqU7VfSalTL/kRJa5DEXaKktcw3ivl1aA2XUdJ6VMv9WEkbmK9yHytpIxpS3U76RvSvSfWJ ksZIpa5V0gxSaa5R0ixyaW5Q0lxJHh7pNfcraaFkvwrt0HxLSauRXfOmktYgszaopLW4r5hfhyLa JiWtR3btBiVtwEu1KSVtRG26HwITzGkUO8tp2c5yWraznJbtLKe5kjyyneW0ULJftrOclu0sp2U7 y2nZznJatrOclu0sp2U7y2nZzt9BEmpCDSBtkFqGkmgApdAo9MBG0SaUgX3zIZVCYxTjsCcJqREU hW/moiEQCa2CfZvRFvguTbcS8JmA3OOAg5BzPhw3BHmuhH1JyJGk+eLwfxjKGqR5R2ArDftG6Hfy 8UlgIMH/OORLQgnbYWsbpDKgi+TJQokZ2J+ALcI5C0cPwvcjwIaUMqqUmoEcw4pOkkOCOo5SnURL mtZlMa3rJthD6piF/Ql6RIruGaKsM0o9BuCbOlryMN0zREuMg43k/QUtw1DOELXYmMJyBPYMU61y maSemRIGROMYrYts74K1Ze5E0yhYQIL6yxYnrIYhbxz0Z+gWqXGm6A/ZZrIWiXIfUeo1Sm17Jc05 ybi0Rhn6TryMojmJroLtKI2HUm9W09KGaQnbqR2yiudL7U08Jtc/QfmT+st+SdFoIJ+yRuJrCcoY K9ZG5rhZyZOGrWuU0jNQC9lD40UvxWmMxGHv8JR6FaJ5AJjEqf4BRX+URuxm6ivyzbnnwIxzaj2j eNa0ojVKFCWVeGskv1TCt9NHfUKJX7k2cYX/ZvqtzCehWIxwHKSRS1hdRX1WOGb6bzf9f53Bk9Ei +2Y1bCUpB6L/YhrtmSl+jCkMRktqMKCcdxlaywSN5aWwZwCFqY9rIM8gLb+HspKPzYCMgRVjINuo ROk5PpV5lJY+DHkyEFuE/2ZagzEoYTvsJR7cROtCzpyppRb2k9ZD9sBVxfLWU85y1G6n0ZamDDP0 vErTdkA+WqJ1IOdkgkZUkuqQLXQlPbZgvYvAfkuhRZSPTZV8I5/Pg9Qmk+foNqprgJ7D0+mVt0ne AYiiLLXhYDHmB+n3YzRit5fE+Rit6YgS6XJZCYrkzD273uR7uYUIw1E1NDqHoV6J4jl7LquRc0q+ cBtNll5opSWlnZWjZ2BKe3du3SfjdSqvmSUWIDWR6yK3+oWoTxWvIIO0DR2hbWn8vDWV7RyfYtOE Ev1nnwPEqiTysvTIQdoekdokiuWQnEO0TfssD/29zovJcyJG2ZBzQL4SRamvxtDV35GaGhrapGXJ gdRoenRTRpo/mhobTcUzydGRqDR3aEhaldy8JZOWViXSidR4YjA6Pz6UvDKVlJJpKS4Njw4mUiNS Oj6SluD75CZpU3w4ObRd2pbMbJHS2SszQwkpNZodGUyObE5Lo5A1kxiGI0cGpYHR1EgilY5KizPS pkQ8k00l0lIqER+SkhnQMZCuk9LDcWAwEB+DNDlkODuUSY5BkSPZ4UQKcqYTGVpAWhpLjQJvQhtK Hxoa3SZtAeJScngsPpCRkiNShtQDmMEh0lByBHSNbpKuTG6mBcuKMomrM3Bw8qpEVFKqWZ2WhuMj 26WBLFRe5p3ZAvoT26RUHOqSSkK14cD4sJQdI2qgxM2wJ528BrJnRqFC46RKcWlbPDUs6yJmHtgS TwGxRCq6KrE5OxRPFT0wo6B6BnFN6xowEVRKaow2NJWYPgH2BTVxKH9zkvBIALFUfDAxHE9dJY2S b0o2N03vYGoWqM3qkWQGjr84E8/IdYxBAaNUwQD4LpNKJtLRpdmBcDxdIw0mpJ7UKHybyYzNiMW2 bdsWHS4UHh0YHY5lto+Nbk7Fx7Zsjw1kNo2OZNJKVpLeFIcKXEXyrR/Ngmm3S9l0AkhAlcjXUhw8 mUgNJzOE0JXbKb2LVi+dC9+m6Ab4eTAre3TbluTAlpJj4TM5MjCUHSS2GJUGk+mxIVBAbD6WSkKG AciVGMlEpYLu0REIiHCyRkoMX0kOmixqpJB5WkY0OwlpMH8azDMgx11RO7WrUtZMSiCcBC0Q+sT0 KXKCDI5uGxkajZcqBc5xmSkYvuiB0WxmLJsBs48nBxIkz5bE0NhZFboQX1BPxAYTm+JwEkXj6bGr i+NBlHehW9B0fxhywIgCWZEqn0cmMv+djqIQjP8RmpDvXX/Gn48L6/UY8uDfXGh+g4HkZ759oflN JpKf3XKh+c1mkp+7YP6iSPNfMH+rFfL72NOIjCo5mp+MqmvJI8CoChmgLfagBdBfvgi1oLXQU0ij 5ZhBl2IT2oTN5A432on96Daw8L0wsv8m7keP4g3oBzC+/zEeQq/gUfQfOIs+wuMoh3dgDd6Fbfh2 HMC7cR3ei9vxITwfT+Dl+Bhej4/jz+ETeBu7BH+BXY3vZNfg+9h1+CF2CH+XTeGj7E48wV6H/y97 GL/BnsK/Y0/jT8D2Z/Fn+PPwnwX8FwP/NcB/APiPAP/PA/8vAv89wP8bwP97wP9J4P8s8H8J+L8D /D/CWYzxONYDfyfwDwL/GPCfAfwvAv6rgP8G4L8F+G8H/rcA/7uA/9eB/8PA/yDwPwr8fwz8fwL8 3wT+HwD/M+xpspIxY5vKn3OX8DcCfx/wrwX+c4H/CuC/AfhngP/1wP9O4P8A8P8u8H8c+D8D/F8A /r8G/h+SO7t4FIvAXwL+zcC/i9wDBf79wH8T8E8B/+uB/+3A/6vA/xHgfxT4/wj4vwj83wD+vwf+ H7Ephmd3Mjr2OqaMPczE2FPMbODfC/xXT+UvjJTwNwF/P/CvB/4Lgf9q4D8I/HcA/13A/37g/y3g fwj4HwP+zwP/N4H/B8A/B/xNwL8c+MeA/zzgvxz49wPbJPDPAv8bgP+dwP8B4P8w8D8K/J8F/i8C /3eA//vA/6/sEMMCfzvw9wL/KPCfC/z7gP8VwP+qqfzVr5TwNwN/Cfg3/D/ezgYgqjLf/+cwwzAz DGZuW3a327ptd9Nqi217YdUtcq11ydJ107TthS1TUXO5ritUqANikal/ESoV5EUQeTFTkEQ3mWlF YEQR41VWBAZoZnDiiJfAyjz385wBJdfd+2//L3P6wMAwM895zu/7+T0HnInxP8H45zH+5Yw/kfGn Mf4PGf/HjP84429m/GcZ/9dUg4UR/oDx/5TxP8xIpzH+uYz/Pxn/Ssa/gfGnMP5cxr+f8Zcx/pOM /zPG368LY7wz/W7QzWKuZ/vdzfh/zvgfZ/xTGX8441/G+OMZfzLjz/j2+ANfGzb+6xn/bYz/54x/ OuMXv09YyfhTGH8e4/8L43cw/r8xfg/j/5rZtTD+Wxl/MON/jPE/w/gjGL+V8W9g/KmM/wPG/xfG 72D8pxi/i/Ffkiv8vi8f87uP8Ycy/hmM/znG/yrjX8b41zL+jYx/B+M/yPgbGT+e8usTnjbqZaPh nNXKf9Zzw7+wGmXZqLcOXoxG2Wg+fHgHly1bjAbZaCwry85OTl63zugv7pOQkCDuZAyQjAFxcZMn j0WgBn/ZEHDOGJ2QEC1+KIDHTRA/Z9DLBv9I8aiR2veN4kf4Ie3nIxMuWK3RRj0DCw49Fyou/JDB EL1xY7g1MuHc4CPtqRR38Q1R8g3RrFONujHSGN/Fru2L1boxw56RsfFb+2IwygbzR463uWhP6Xus wWfnIkbFwBN8+2TQyQZ9m++ODNwQabUHj2wL0EsBet/4grV7ip/evMDgLxn8ExKmTx8zxmCSDKYE a4J1JuG7jc145bbQUPGo/m1csbYNG5tk1flJso7vGv0kgy5U9Aq+wIKyzhroL5n8jcaRI8eIB7Ba ZZ2k17eZ/bi3+FJcQkO1L8UVceF4GCSjYezYmLHTL0yfzgCMhvAMbXou6P0koy7Uzuz+bxaASTYG fmL9xLqdLZlN7NrfFULA/1QIJn/ZFGAdXgkGXyVoNxgvl4K4IXzjOXGDXjJRCteqhaEH+wfFoL9S DCa9bKIYBqvBJMumyzv2XctBFO8e+1XloNVr6LXrwfBP6sFwjXoYPrp/oSAC/bj7UEFQCNrXQxXx 9yXBMRsqCX8/yayVRKg2sResvjq4cPkrgfXbk2cyyyaLnUtmaGboJm1bx2YyyibzJ5mZiW+/vWbN apNBNhkvxMfH+x7AJJlM4sqjdFYxETewGaUAfzmACacANi8wG2SzkZ8oKeNOZSXiJkNkAt9IiNRu 0uv1y9Zx07plAQY5wBgdH3/Rao0x6yWz/+VKCeUnAwJixAG08gPR33rM+HjfbgxWi9WiU01XyoWC MfvLZlFaCaJiNiaYZdl8ZaetASY5wFIkHdNC4Nu0gQw+9tCg4n1PO/j9shJxT70cMFg+2nVR/eEj R7aJKvcfGnqw9gDa/dlDMS+iTKiTALMUEDg5dHLonVaxXU+bMQ+7mSrQHvPcSFEP58yyn9n/ciFZ SbyfXpSAyU+4K1QrpVCr9o91rdYggxRo0Ou/VU6y3r8tSCeb/ccMq6cx2nfEFd9FPGCAZAq4/faV t98+5eKUKVq5DNaUVlSBeq2otANwcaiMLmozfLmqrFfNsDlQNgfZw+3hGVwSxySOWcsWz2Y2ymat snylpT2oKC1fbZk5C7lGbVFdvkOij2FGAw1yoKiE4eUVMFhe2m36a9dXoF4KFPV1ucACuG2lOMjW mLi4mG8/7P9YYYH+cqCosKESC5TlwGET8H+rxsS+RYtOazz3/6LGAmW/wKEa+9eLbIRODhxWZKK4 tG9dqTJxo9komY233XabettkdfLkyWZ/P7NxzOVCC9BJFv3gV9qhEKU2WGtXvtY+WK+e68AgOfA6 +2j76IyxGWM3Ttk4Rdh7jXGNMU68tjYw0G7NYNvIlmCNZ4tji7UGBsiBpgvxcXFxvuILNEuBZmso g+bDjySxiZcdWti0RqmVH7NtCZAtJl+hcN+4shJxa0DIZPGtySHarX5cxj8ubn18vHbfkMmiBLnV X7L4h1ypwVAGYbxShHExVz14XJwvWENlaA3SqebhdTjGbjHIFuOwQoznTNwyfHasxkDZOOKAvVwL 4NBm5IlNQ0+ifREyWVydHBJ45RatHrVFxWA9WrWOQ9jCRxqROQ4whIZe8O1KiPYovgdkt1lBGIdW EMZAyWgRzxoWGhY6VJaBw3+CgtIe+oKRa6HWCxbZz2K4vAfDK1MskfxDB1vp5dIcESBZxP+bbbA4 B2vT37/tOp1sEbV5xYChY7TvadeGijPUGmiUAn3V6StPrTqCp28c6btcoj6DhupTO0iXRNu8KD7Y L135hvbBbrf4MXz7sItlhGwZ2XZL2y3nJtbc3bS4aXHl1GPHytZVrDtsOWyxmGWLpc1+zl5jb2I7 xlbO9lf7YfsndotRtpgvlh8+fLjc92yWQMkSKNwaLj7Yf2b9mfUHkthGsJkCZJMpptxgWFleXr08 yCgHmcV9Tn92WFw+Oy1uN06cpz3QvIna7TouE+Zrt8+fIDq/aeK88nJ25KWJQQY5yDAxPDz8Qvjg xSJuX1XOJca+knusvPopDh8O8pOD9Ha7JF3e+ZF6Ncg/OFiSgq9c2oIC5CCTuLX8WNO5c03HjpUP 3nHYxWSRTdedbnMFl39r05Ynl59P+2riPO36vImWYbd9dlo8huhnTW1DjyjWMtFl9rboWyzrooXE DVf2LkR7qMGHZS7ESkesmV+WxPYg2y1sJmZ5hDhsL4+ev3nu5vv3TDw3Onx0uOXaPz2aLVjSnvai ZfToYI7axSA/v6Bh1cFE+etkP39GYKfRyCauab9n0r4hXOJvt18fII0IMBgsFh5ktJhAcaNd1sv+ uFzPYfJ9w3fharD2Te3a4EXcziAtJp/bVM1xk9hU6yTts1ZpIdFNowcvKmdJI/wj92j3lgZ/K2aW lkhlku7l15Yulm6Yv/SVRVLw4j8sWyJN5Bb5dzMmjaFji1cO+d5nXVyTuS5+N+a7rpNGSn4zpj05 Rhr99IwnMNng9/WDn/0HPxukgJcj/xQp3b3olaVLpPu0jyHax4e1j5O1j2Hax+mXf2Mna5//2Uc/ 7V9a+L5iJJL4P1DfA2aeeSyPJMaql+I4vw72my6t8sv2a5QydNt026Q6Sc7bI8bpF63/6lpbQHBA sHmTJePKFpTj28QtV28jEkY9eHk7zdY/qv97z33vuZs2ie3fPr56Cwj+QeGtlT/c5Nt+FH9luy1N bHeMvua24a7soe3eo/c9N7Q91O/bxq/7+21CzoScicm/XHhle/h23yZuuXp7uPwR79AW+tQ/2GaH Hg09+mif2L59y69+cq1tQs6v3I+Nemyfb3t895Xt17vENiX/mtu533QPbWFNT6QNbVNzfduTy6+1 PVXyVMl0829jhm3N4ntXbzP0083TzTP04j5P3yO2mTFDm++RZjXP6pzV/0zwMwufyX7mzKzmZ9xi u/r55ky61ibGMN08J2FOmm97tvPKJp7ruQfFxxl6wfPrXuwe2l6a8nL+0DbP6Nvmn5l/ZsENMIkt ZkHOgjau5yzIifCLmBrxnrY1RfRH9C+8f+ELbHMXxi0sgbiFpQsvLhovtoVxiyIXrWXbteijRR8v +mzRZ4uNi2ewzV28ZPHmwe3gq7e/uunVklc/WxLMNn7J00uWL0le0jC4uZec/6P0x4fZpkbeGpkc 2S+2pfv+9JLYlknLti87Nrg1iD+D8rlP+6rvz3f++c5lx/6cvPy25aHLX4oeEz3mtdLXZy/d5/tp Pvf5fur1HvFzr198Y/wbi99Ie6PsjR6xxUyMidO2fTHNK0avuI3P+1bcz7ZkRe6K3SvqVo5im75y Kz83caV9pX3F/Xw8L66ttK/Sr7p11dRVy7XtnPVxbYu2bl8xmo/R1kprt7WSn7g11hh7T+z9sXFs lbFfrTrHz1b6bom7xVoZNylu6up5qy/Eb3pz+pvPvjl37fj1kxPzNy0b+pz8VPJTm0ducW7pS7kx ZUzKCynWlLUpySnbUz5OqU45l/JVqj51VOqY1AdTQ1OfSn0uNSe1MvXMtrHbHtw2ZdvKbZu3fbrN m3Zn2uy0TemW9IfTl6Xnp3+c7ky/mPFwRnTGwcz7M2dlWjO3Zu7KbMh0bx+1/bnt720/lzUq6/6s x7OmZy3NislKy2rLHpU9N3tl9ubsT7M7d9y4I3jH6zv27ejPCc15PWdXTvdOaeeDO5/euX1nW+5P cpflFua689ZK66VRaq/0PbgBvg83wk1wB4yFcXAn3AXjpZukCfCE6pGmwpPwFEyD6fBbmAG/g1kw B+aq4dIrMA8WqG1SBCyERbAYXoUl8EeIhP+EpfAndae0TN0j/RmWQxREw+vqQukNiIEVsBIS1ZPS JkiCZHgX3oMc2Am5kAf5cIBucBCOcr0KjsFxqIYTUAMn4VOohTqohyboUKOkTugCF/PhBg90w1nw wufQAwqcg144r6ZJ/6UekfrgC+iHAfhSTZW+gq/hInyjpspb1WNyCqRCGqRDBmTCdsiCbNgBObAT ciEP8qEAdsEHsBs+hD2wFwqhCPap4t/RNssVaqNcCQ44ClVqo+5J9WPdTOk63WzJontWfUL3e7VQ 9wKfX+TzUrVXVyo9JDVJerVb8gcDBIARTGCGQLBAEIyAUaqbCnNTYW4qzE2FuakwNxXmpsLcVJib CnNTYW4qq43KaqOy2qisNiqrjcpqo7LaqKw2KquNymqjstqkF1Sv9CKEwx/gJXgZVqn9khViIQ4S qcJNkATJ8C68BzmwE3IhD/LhqOqiKlxUhYuqcFEVLqrCRVW4qAoXVeGiKlxUhYuqcFEVLqlFvSCd gVZog3ZwQge3dUIXnFebqQAnFeCkApxUgJMKcEoXuO1LtZ4qqKcK6qmCeqqgXvuX0zrQgz8YIACM YAIzBEIQjFQ75ethFHwPboDvw41wE4yGm+HfVKf498vyD2EM/Ahugx/D7fAf8BO4A8aqdnkc3Al3 wd3wU7gH7oVg+BncBz+H++EBeBAeghD4BYyHCTARfgkPwyMQCo/CJPgVTIbH4HH4NUyB30AYPAFT 4Ul4CqbBTPZlFjwDs2EOrGDcK2EVWCEW4mA1xMMaeBPeggR4h/tsVd2kzU3a3KTNTdrcpM1N2tyk zU3a3KTNTdrcpM1N2tykzU3a3KTNTdrcpM1N2tykzU3a3KTNTdrcpM1N2tykzS1eySVexyX/FQ5D GRyBCr5fCQ44ClVqjfYar9UkzEvCvCTMS8K8JMxLwrwkzEvCvCTMS8K8JMyLY2twbA2OrcGbLrzp xptuvOnGm2686ZZeU+twZwXurMCdFbizAndWkBYvafGSFi9p8Uqr1S+keFgDb8JbkABvw1p4B9ZB h9pHdfdR3X1Ut5Pq7qG6e6juHqq7h+ruobqdVHcj1d1IdTdS3Y1Ud6P2uqFxcKd43Q/cDT8F8Rqi eyEYfgb3wc/hfngAHoSHQLzK6BcwHibARPglPAyPQCg8CpPgVzAZHoPHQbw2aQr8BsJAvEppKjwJ T8E08foRSIFUSIN0yIBM2A5ZkA07IAd2Qi7kQT4UwC74AHbDh7AH9kIhFME+8RoUKFd7xesAqAIv VeClCrxUgVc3U+3Ev524t1N6VLqOs687mNGxMA7uhLtgvGShI1vwZg/e7MGbPXizB2/24M0evNmD N3vwZg/e7MGbPdJczolegXmQiJc2QRIkw7vwHuSoTbixCTc24cYm3NhE57yJznkTjmzGkc04shlH NuPIZhzZjCObcWQzjmzGkc04shlHNuPIZrqlQrdU6JYK3VKhWyp0S4VuqdAtFbqlQrdU6JYKVaOw 9wO6Z+lAv5fm6F7g84vSHCmETDjJhJNMOMmEk0w4yYSTTDjJhJNMOMmEk0w4petI0Xi6zwSYi9lf gXnwJ7KwTD1PPs6Tj/Pk4zz5OE8+2snHKfJxinycIh+nyMcp8tFNPrrJRzf56CYfZ8nHWfJxlnyc JR9nycdZ8nGWfJwlH2fJx1npADN9UMtAn3SJLqSq/bIEstrP3jl0s0n6s+zp7yUdx1hhD3XSWfZw PXu4nj1czx6uZw/Xs4fr2cP17OF69nA9e7iePVzPHmbSW3vorT301h56aw+9tYfe2nPtWlGTmI2k 71QrL6gd9NgOemwHPbaDHttBj+1gtrqZmS+YmS+YmS+YmS+YmWxmJpuZyWZmspmZbGYmm5nJZmay mZlsZiZb2qhepO4qqbtK6q6Suquk7iqpu0rpfW7bDCmQCtsgDdIhAzJhO2RBNuyAHO63E3IhD/Kh gO/vgt3wIeyBvVAIRbAPiuEj2A8lcEDN44jlSX/h+sdwCErBBnb4KxyGMjgC5VABleCAo6qDXDjI hYNcOMiFg1w4yIWDXDjIhYNcOMiFg1w4pAbu0whNXD/F52b4G5yGFub+DLRCG7SDEzrUVqzbinVb yZSXTHnJlJdMecmUl0x5yZSXTHnJlJdMecmUF0N3YOhODN2JoTsxdCeG7qQ6KzG0C0O7MLQLQ7sw tIuKPUHFnqBiT1CxJ8QrjlmPOFiPOFiPOFiPOFiPOFiPOFiPOFiPOFiPOFiPOL7DesQrXrfMesTJ esTJesTJesTJesTJesTJesTJesTJesRJv/fS7730ey/93ku/98rh0vfkP0gz5Jekm+WXpR/Jc6Xr 5UWwgsdeCavACrEQB6shHtbAm/AWJMA7PJZ45WIibIIkSIZ34T14X20Rr6YWr6XW0kpStVdUjyOB /bilH7f045Z+7RXWy9QB3DKAWwZwywBuGcArTrzixCtOvOLEK06O5EWO5EWO5EWOzlccna85Ol9z dL7m6HzN0fmaI/MNR+Ybjsw3HJlvODLf0DM6tFe//RUOQxkcgXL1PH3ESR9x0kec9BEnfQRXMk8W 5ul65snCPJk162Ac6WZs04JtWrBNC7ZpwTYt2KYF27RgmxZs04JtWrBNC/vqIvVifeAl5V5S7iXl XlLuJeVeUu4l5V5S7iXlon91MWM9chCOKsRRhTiqEEcV4qhCHFWIo/bgqD04ag+O2oOj9uCmdNyU jpvScVM6bkrHTem4KR03peOmdNyUjpvScVMPburBTT24qQc39eCmHs4yOzjL7OAss4OzzA7OMjs4 y+zgLLODs8wOzjI7OMvs4Cyzg6N1hqN1hqN1hqN1hqN1BjeV4qZS3FSKm0pxUyluKsUzh/DMITxz CM8cwjOH6Ik30BNvIPulZL+U7JeS/VKyX0r2S8l+KdkvJfulZL+U7JeS/VIyX0rGz5Lxs2T8LBk/ S8bPkvGzVMZRKuMolXGUjNeQ8RoyXkPGa8h4DRmvIeM1ZLyGjNeQ8RoyXkMVHbnmWabvHOMIlXSE SjpCJR2hko58x3OMJjLdRKabyHQTmW4i001kuolMN5HpJjLdRKZbv8M5hotVoItVoItVoItVoItV oItVoItVoItVoItVoItVoItVoItVoItVoItVoItVoItVoItVoItVoItVoItVoItVoItVoItVoItV oItVoItVoItVoItVoItVoItVoItVoItVoItVoItVoItVoItVoItVoItVoItVoAvntOKcVpzTinNa cU6r/IJ0C3n6MXmaSZ7+nTz9GO/8hzxPbcM9P5L/zOflEAXR8Bq8DjHwXc9P3uY+74jXVfN5PWyA /wXilcCJsAmSIBnehffgffHaaM7sUyAV0iAdMiATtkMWZMMOyIGdkAt5kA8FsAs+gN3wIeyBvVAI RbAPihnLR7AfSuAAHIS/wMdwCErBBnY1BWtlYq1MrJWJtTKxVibGKsBYBRirAGMVYKwCzn/OSEdZ 8T6COboxRzfm6MYc3ZijG3N0Y46TmOMk5jiJOU5ijpOshG9mJXwzBqnFILUYpBaD1GKQWgxSi0Fq MUgtBqnFILUYpBZ3L8TdC3H3QqxRhzXqsEYd1qjDGnVYow5r1GGNOqxRhzXqsEYdnn8Vc6zFHGsx x1rMsRZzrMXzc/D8HDw/B8/PwfNzOJO7WYqHNfAmvAUJ8DashXdgHSSyCtgESZAM78J7kAM7IRfy IB8OSGFYJwzrVGGdKqxThXWqsE4V1qnCOlVYpwrrVGGdKqxThXWqsE4VdsnCLlnYJQu7dGCXDuzS gV06sEsHdunALh3YpQO7dGCXDuzSgV3exi4nsMsJ7HICu5zALicwy1LMshSzLMUsSzGLeAW0h2R7 SLaHZHtItodke0i2h2R7SLaHZHtItodke0i2h2R7SLaHZHtItodke0i2h2R7SLaHZHtItodke0i2 h2R7SLaHZHtItodke0i2h2R7SLaHZHtItodke0i2h2R7SLaHZHv+vyXErhZS9SVUfQlVX0LVl1D1 JVT9Xqp+L1W/l6rfS9Xv1c2UrqczT9D9Xn2V7jxB9yKfYzhPWKHu15VK43Ud6vu6TilY1yXdp3NJ d+k86kldt+Qn/ZIu7qGLe+jiHrq4hy7uoYt76OIeuriHLu6hi3vo4h66eAfnAV2cB3RR/Q6q30H1 OwZ/a9BNRXdT0d1UdDcV3U3Ht1PVDqraQVU7qGoHVe1g7d/M2r+ZtX8za/9mVgUKqwKFVYHCqkBh VaCwKlBYFSisChRWBQqrAoU1tpc1tpee5GWNqbDGVFhjKqwxFVYwffIxzpCOQzWc0M6UalhFOJmZ HtZeFmamh/WXRTrCXkew1xHsdQR7HcFeR7DXEex1BHsdwV5HsNcR7HUEe72MvV7GXi9jrwfY6wH2 ekBbr73G2uZ1zl7egBhYASthFTNlhViIg9VqInuYyB4msoeJ7GEie5jIHiayh4nsYSJ7mMgelrGH ZXR3he6u0N0VurtCd1fo7orUwXleJ3TBdzgrFu/bQ7euo1vX0a3r6NZ1dOs6unUd3bqObl1Ht66j W9eJd/ehW9fTrevp1vV063q6dT3dup5uXU+3rqdb14v3/xHv/kO3bqRbN9KtG+nWjXTrRrp1I926 kW7dSLduFO8PJI+DO+EuuBt+CvfAvRAMP4P74OdwPzwAD8JDEAK/gPEwASbCL+FheARC4VGYBL+C yfAYPA6/hinwGwiDJ2AqPAlPwTSYyb7MgmdgNsyBFYx7JawCK8RCHKyGeFgDb8JbkADvcJ+NdKtE 2ARJkAzvwnvwPmzluVIgFdIgHTIgE7ZDFmTDDsiBnZALeZAPBbALPoDd8CHsgb1QCEWwT7zDBlSC A45CFdU/U/UT77Kke1YKIg3Buhf4/CKfF6vJ2jsu3UfXDKMTjqMTjqPST1LpJ6n0k4P57iPffeS7 j3z3ke8+6TWy9Lr6KdX/KdX/KdX/KdX/KV1rHF1rHF1rHF1rHF1rHF1rHF1rHF1rHF1rHF1rHJ1o Ep1oknSB65dAlcbJEsgwXZog/xZmwO/gaYiQpsnl0g+xXYRuljSRvTCyB0bdYilBvNuPLlYao1st 3SrF/JPfbHxO7/+c3v85vf9zev/n9HwvPd9Lz/fS8730fC8930vP99LzvfR8Lz3fS8/3ctbQxVlD F2cNXZw1dHHW0MVZg7Chl9nyMlteZquT2ephtnqYrR5mq4fZ6rnmeRy1Qt9uo2+30bfb6Ntt9O02 +nY7fbudvt1O326nb7czWzpmS0ffbqdvt9O32+nb7fTtdvp2O327nb7dTt9up2+307fb6dvt9O12 XDGAKwZwxQCuGMAVA7hiAFcM4IoBXDGAKwZwxQC9uvOav4/9kn37Cr6Gi/CNdgZ+mvyfJv+nyf9p 8n+a/J8m/6fJ/2nyf5r8nyZLDWSpgSw1kKUGstRAlhrIUgNZaiBLDWSpgSw1kKUGet9n9L5Wel8r va+V3tdK72ul97XS+1rpfa30vlZ6X6tutmSWHsfovRi9F6P3YvRejN6L0Xsxei9G78XovRi9F6P3 YvSLGH0Aow9w5M5z5M5z5M5z5M5z5Ho5cr0cuV6OXC9HrhfL/xdHz8vR83L0vBw9L0dPnM1ewuqX sPolrH4Jq1/C6pew+iWsfgmrX8Lql1g1NbFqamLV1MTs1jC7TcxuE7PbxOw2MbtN9LRmZvggM3yQ GT7IDB9khg8yEx5mQmEmFGZCYSYUZkJhJlzMhIuZcDETLmbCRZ/zsgI4T5/zsgI4T6oH5FuZmXBm JlwS7wUTAEYwgRkCwQJBMAKuU2eRnQay00B2GshOA9lpIDsNZOcI2TlCdo6QnSNk5wizaGMWbWSo nAyVk6FyMlROhsrJUDkZKidD5WSonAyVk6FyMtRPhvrJUD8Z6idD/WSoX5or3SK9AvNgtRrCzIYw syHMbAgzG8LMhjCzIcxsCDMbwsyGSBvVIjL0PBl6ngw9T4aeJ0PPk6Hnpfe5bTOkQCpsgzRIhwzI hO2QBdmwA3LY/52QC3mQDwV8fxfshg9hD+yFQiiCfVAMH8F+KIEDajJ9PFn6C9c/hkNQCjaww1/h MJTBESiHCqgEBxzlWFTBMTgO1XACauAkfAq1UAf10MB9GqGJ66f43Ax/g9PQQiWdgVZog3ZwgktN wglJOCEJJyThhCSckIQTknBCEk5IwglJOCGJqv2Iqi2maoup2mKqtpiqLaZq91G1rVRtK1XbStW2 UrWtrM5aWJ21sDprYXXWwvojnPVHOOuPcNYf4aw/wll/hLP+CGf9Ec76I5z1Rzjrj3DWH9NYf0xj /TGN9cc01h/TWH9MY/0xjfXHNNYf01h/TGP98Sr+CcM/YfgnDP+E4Z8w/BOGf8LwTxj+CcM/YfJ0 NUL+LcyA38HTMJP7z4JnYDbMgRekn3CG/ihn6HGcof+OM/SXOEP/DWfosZyhh3KGHssZeixn6LGc ocdyhh7LGXosZ+ixOC4Mx4XhuDAcF4bjwnBcGI4Lw3FhOC4Mx4XhuDAcF8YZeixrhlc5Q4/lDD2W M/RYztBjWUPMZw0xnzXEfNYQ81lDzGcNMZ81xHzWEPM5c47lzDmWM+dYzpxjOXOO5cw5ljPnWM6c YzlzjuXMOZYz51jskY098rFHPvbIxx752COf1XIOBsnCIFkYJAuDZGGQLFbQS1lBL2UFvZQV9FLW DPfoZqkbdM+or7OSfoC1w42Da4cbB9cO72KZcF2pmqPr4NyCdanuM847PNLvpX/HPLWYpxbz1GKe WsxTi3lqMU8t5qnFPLWYpxbz1GKeM9ikCZs0kf5e0t9L+ntJfy/p7yX9vaS/l/T3kv5e0t877Hzg ovYXr9l0Gn+eNYNnzeBZM3jWDJ41g2fN4FkzeFZWWxAEI+A6dfE/WSu48J0L37nwHWdNMF7dwwjF bxq78F0XvuvCd134rgvfdeG7LnzXhe+68F0XvuvCd334rg/f9eG7PnzXh+/6tPe3XK1Gs6fR7Gk0 exrNnkazp9HsaTR7Gs2eRrOn0YN/9UjDc2l4Lg3PpeG5NDyX9i/+1WMbntuG57bhuW14btu/+FeP IxyBI/8Hf/UowHMFeK4AzxXguQI8V4DnCvBcAZ4rwHMFeK4AzxUM+6tHwTX+6vEJnvsEz32C5z7B c5/guU/wXCOea8RzjXiuEc814rlGPNeI5xrxXCOea8RzjVRSLe76End9ibu+xF1fincgxV0bcNcG 3LUBd23AXRtw1wbctQF3bcBdG3DXBvE+pbhrC+7agru24K4tuGsL7tqCu7bgri24a4t4J1PxPqa4 ayvu2oq7tuKurbhrK+7airu24q6tuGureKdT3JWKu1JxVyruSsVdebgrD3fl4a483JWHu+4d5q4p uGs57noMd1XjrofEe6WKd0rFXdW4qxp3VeOuatxVLd47FXfl46583JWPu/JxVz7uysdd+bgrH3fl 46583JUv3mUVd+WJ91nFXdW4qxp3VYt3XMVdObgrB3fl4K4c3JWDu3JwV454L1bcVY27qnFXNe6q xl3VuKsad1XjrmrcVY27qsU7tuKnFvzUgp9a8FOLeP9W/LQbP+3GT7vFO7mK93HFT/vFO7nipgfw 0gPi/VzFu7nioo9x0SzZhBWysEIWVsjCCllYIQsrZGGFLKzAeRcEwQi4Tl3zT3572I0VurFCN1bo xgrdWCEXK+RihW6s0I0VurFCN1boxgrdWKEbK3RjhW6s0I0Vuv/hKkisNVerCVghASskYIUErJCA FRKwQgJWSMAKCVghASsoWKEIKxRhhSKsUIQVirBCEVZQsIKCFRSsoGAFBSsoWEHBCgpWULCCghUU rKBgBQUrFGGFIqxQhBWKsEIRVlCwgoIVFKygYAUFKyhYQcEKClZQsIKCFRSsoGAF8Xuaj7DCR1hB wQoKVlCwgoIVFKygYAUFKyhYQcEKClZQsIKCFRSsoGCFIqxQhBWKsEIRVijCCkVYoQgrFGGFIqxQ hBWKsEIRVlCwgoIVirCCghUUrKBgBQUrOLGCEys4sYITKzixgvM7/v1TYfXjYvXjYvXjYvXjYvXj whZV/+Dvn50YpBODdGKQTgxyAIMcwCAHMMgBDHIAgxzAIAcwyAEMcgCDHMAgBzBIIQYpxCCFGKQQ gxRikEIMUohBCjFIIQYpxCAlGKQYgxRjkGIMUoxBijFIMQYpxiDFGKQYgxRjkKMY5CgGOYpBjmKQ oxikBIOUYJASDFKCQUowyEgMcgcGWYJB7sUg92KQuzBIGQa5A4OUYZAyDFKGQcowSBkGKcMgZf+C QcowSAkGKcMgZRikDIOUYZD9GGQ/BtmPQfZjkP0YZD8G2Y9B9mOQMgxShkHKMEgZBinDIGUYpAyD lGGQMgxShkHKtHe7rVCrsEgVFqnCIlVYpAprjMUac8V7ymKMERhjBLbIlbJJfQWpryD1FaS+gtRX kPoKUm8j9TZSbyP1NlIvznkqSHsFaa8g7RWkvYK0V5D2CtJeQdorSHsFaa/4h//aMJE19CZIgmR4 F96DHNgJuZAH+XDlr4XFpKOYdBSTjmLSUUw6iklHMekoJh3FpKOYdBSTjmJSUUwKvKTASwq8pMBL CrykwMuZqYMzUwdnpg4ScZxEHCcRx0nEcRJxnEQcJxHHScRxEnGcRBwnEcdJhINE1JKIWhJRSyJq SUQtaThGGo6RhmOk4RhpOEYaVNKgkgaVNKhUbh2Ve4rKPUXlnqJyT1G5p6jcU1TuKSr3FJV7iso9 ReUOULkDVO4AlTtA5Q5QuXVUbh2VW0fl1lG5dVRfM9XXTPU1U33NVF8z1ddM9TVTfc1UXzPV10z1 NVN9zVRenfauzymQCmmQDhmQCdshC7JhB+TATsiFPMiHAtgFH8Bu+BD2wF4ohCLYB8Xa7/IdrMNP sA4/wTr8BOvwE6zDT1Cd9VRnPdVZT3XWU5312hm87+z9Q3kefWsBfWsBfWsBfWsBfWsBfWsBfWsB fWsBfWsBfWsBfWsBfWs6FXyICj5EBR+igg9RwYeo4ENU8CEq+BAVfIgKPkQFH6JvbaRvbaSSS6nk Uiq5lEoupZJLqeRSKrmUSi6lkkup5FIquVQSf/t/EcLhD/ASvAxX/7vZ1ZyBx8MaeBPeggR4G9bC O7AONpKkRDWSFESSgkhSEEkKIklBJD3MRg+z0cNs9DAbPcxGD7PRw2z0MBs9zEYPs9HDbPQwGz3M RnKiSE4UyYkiOVEkJ4oeZqOH2ehhNnqYjR5mo4fZ6GE2epiNHmajh9noYTZ6mI0eZqOHbaaHbaaH 2ehhNnqYjR5mo4fZ6GE2epiNHmajh9noYTZ6mI0eZqOH2ehhNlIaRUqjSGkUKY0ipVGkNIqURpHS KFIaRUqjSGkUKY2ih9noYTbSGkUPs9HDbPQwGz3MRnrTSW866U0nvemkN530/jdz9x4eVXnufXwx EyMOULeHeqh9t6LWUz2L57NWq7ZqrcVDtVba3XK523TvatWW1jNVq4JVlNqtr1o1nqrBKpYiW0Ql HELAJEACCRCzJofJJBMgZIYIyHo/axy9rIW92/3Hvt4/viSQtdbz3L/7d9/PM2HNrCdU7xLVu0T1 LlG99aq3XvXWq9561VuveutVb73qrVe99aq3XvXWq943VG+V6q1SvVWqt0r1VlnPnlTB9Sq4XgXX q+B6FVyvgmco3hkqeIYKnmE9G2c9G2c9G2c9G2c9G2c9G2c9G2c9G2c9G2c9G2c9G2c9G2M9G2M9 G2M9G2M9G2M9G2M9G2M9G2M9G2M9G6Mr3KQrVOgKFbpCha5QoStU6AoVukKFrlChK1ToChVDDoje GXIgDsKXcTAOwaE4DIfjCByJozAKR+MYHIvjcDxOwIk4CSfjFJyK03A6zsCZ+ArOwtn4Ks7BuTgP X8PXcT4uwIX4hlfPF+GbuBjfwmjxXYJLEX/G9uX4TvS+NfeAId+N3rDuHmbd/a51d5R192Lr7qnW 3aeGXKNL/MjPrvf9DbgRP8cvMA6/wk3RWN1vrO43Vvcbq/uN1f3G6n5jdb+xut9Y3W+s7jdW9xtr 7X1KB7zJ2vuUtfcpa+9T1t6nrL0TrL0TrL0TrL0TrL0TrL0TrL0TrL0Thjxivf4PnfNRPIbH8QSe xB/wFJ7GM6jEs3gOz+MFvIg/4iW8jCpMwSv4E17Fa5iK183nz5iGv2A63sAM/CfexEy8hVk8+Tbd 38G7mI1qzKGrmtRh39Jh39Jh39Jh3/Iq4jGvIh7zKuIxryIesx8osx+4wauIH9oT7GRP8AV7gi94 FXGHLnxvMowGvJKoSWaiDq8mDklmo76gUmfO68x5nTmvM+d15rzOnNeZ8zpzXmfO68x5nTmvK3fp yl26cpeu3KUrd+nKXVt5F0NGN87oxhndOKMbZ3TjjG6c0Y0zunFGN87oxvG9qB8E1+MG3IifYxx+ iV/hJtyMB6JGHbZRh23UYRt12EYdtlG3bNQtG3XLRt2yUbdstM842j7jaB2sUQdr1MEadbBGHaxR B2vUwRp1sEYdrFEHa9TBGnWwRp2rUUfaqCNt1JE26khZHSmrI2V1pKyOlNWRsjpSVkfK6khZHSmr I2V1pPd1pIyOlNGRMjpSRkfK6EYZ3SijG2V0o4xulNF9CrpPQfcp6D4F3aeg+xR0n4LuUyg+XX0Y RiB+7sMO2BE7YWd8HrtgV+yG3RF/tv4/W6v3xF4Yib2xD/bFl7Af9sdox16CSxHfo3Y5rgp2UMEH qeBrVPCxKvgsFbyvyo2fnZFWnWnVmVadadWZVp1p1ZlWnWnVmVadadWZVp1pldnH0Ys5upmjmzm6 maObObq5+AyDeZiPGiyIWrj1UG49NP7U/OBsmU7LdFqm0zKdlum0TKdlulOmO2W6U6Y7ZbpTpg+X 6cNlOiPTGZnOyHRGpjMynZHpjExnZDoj0xmZzsh0RqYz1qTN1qTN1qTN1qTN1qTN1qT4/zoe5YBH OeBRDmjhgBYOaOGAFg5o4YAWDmjhgBYOaOGAFg5o4YApHDCFA6ZwwBQOmMIBU+L7ubngHi64hwvu 4YJ7uOCe5Ple8Y8OhpXeafQNu6Y3kldGVyS/E1Unr/J3PTV5tb+P8fdrow+DE+1IMnYkGTuSjB1J xo4kY0eSsSPJ2JFk7EgydiQZCmYomKFghoIZCmYomKFgloJZCmYpmKVg9n/0f3ErnbcKrXgfbQiL NZClwAAFBigwQIEBCgwU7wH/wI5qAzZiEz7EZ+8L/06wbXIM4neAHP333mkpgkERDIpgUASDIhgU waAIBkUwKIJBEQyKYFAEgyIYFEEkgkgEkQgiEUQiiOR+gdwvkPsFomnZymvmOtEsEM0C0SwQzQLR LBBNr2h6RdMrmvgO0LS8dsppfL9pZzLebx4aTPT654Folfyskp9V8rNKflbJz6ot5md6sAuH7yLK rCizosyKMivKrCizosyKMivKrCizosyKMivKbJAOUkE7OtDP2YPRcjPfaOYbzXyjmW80842ferfB lckrg6Q8jCi96+DK5NX+PiYYERwgH2n5SMtHWj7S8pGWj7R8pOUjLR9p+UgHE2VvutHfiGfg1VM7 OvBRh9zSu2QWmtVys1puVsvNarlZLadnhp4ZembomTHLmtK7BjI07aJphqZdye9FYfL7URica4aT zXCyGU42w8lmONkMJ5vhZDOcbIaTzXCyGb4sB+1y0C4H7XLQLgftctAuB71y0CsHvXLQKwe9n/yO uEZkC1CLhViE91CHejRgMZZgKZZha3e59kcrqdFKjVZqtFKjlRqtxd/ffsChG7ARm/AhNkf91Oin Rj81+qlxHjXOlbft5O0gedtW3kbK23bydpC8xbU0kjrnUec8O4HZyfeCLwe7iT5+T+Bm0W8W/WbR bxb9ZtHHvS8vX3n5ypd+Z7Slam7d0u+MPq7eIOG7ob4bWvxf0BYZaZGRFhlpkZEWGWmRkRYZaZGR FhlpMaetv4/wo3ulPvsOkvgpMy1G2sZI24gynYzfl3GeEUMjhkYMjRgaMTRiaMTQiKERQyPG9y1U UqCSApUUqKRAJQUq5b9S/ivlv1L+K+W/Ug0OV4PD5b9S/ivlv1L+K+W/Uv4r5b9S/ivlv1L+K+W/ Uv4r5b9SVDlR5USVE1VOVDlR5awsbVaWNitLm5WlzcrSZmVps7K0WVnarCxtVpY2K0ubTHTIRLNM NMtEs0w0y0RzaWVZJROrZGKVTKySiVU8sQ1P7McTKQqdwhPb8MR+PJGi1in6a3Pw9eCOYM9gPH6N O3EX7sZvcA/uxX2YGJxOrUXUWkStRdRaRK1F1Fq0ld3Xx2tyC7VaqNVCrRZqtVCrhVot1GqhVgu1 WqjVQq0WarXw34v89yL/vfgPvh58ikKPU+hxCj1Ooccp9Dh17qbO3dS5mzp3U+dua+5QPeRU6+31 +sih1tuf6SWnWm+v108Otd7+LPmr6M3kTdHrybrgy8n64J+Ti4MDRXQHl47Hr3En7sLd+A3uwb24 DxPjvi1nbxTrf2u7jDkinSPSOWbfZfZZs8+afdbss2afld85f+dKU68a2kp3CQ4V1cLSnYJDRbRQ dXQk43t84uqYKIKJIpgogokimCiCiSKYKIKJIpgogoki+JWc98l5n5z3yXmfnPfJed+WVyk9/A3U qNMFqMVCLMJ7qEM9GrAYS7AUy7BST1mFVryPNni9QqHVFFpNodUU6qfQIIUGKTRIoUEKxb2hhULr KLSOQusotI5C6yiUplCaQmkKpSm0G4W+qDK2p9AoVbGdqtieQqNUxHYUOp5Cx+uSt6uOpni1C0aq jpGqY6TqGKk6RqqOkapjpOoYqTpGqo6RquMYjt+X4/f9q99m9KvbdbroAPIoYD0Ggx3NuMOMO8y4 w4w7zLiDK7+WvMRsvi2PV0at8tcmd63J76nb78fPMAzGJ28J9kzehjuCPYJT5LJDLjvkskMuO+Sy Qy475LJDLjvkskMuO+SxRx575LFHHnvksUcee+SxRx575LFHHnvksUf+euSvR/565K9H/nrkr0f+ euSvR/565K9H/nrkr0f+ev6L38x2U6ObGt2l919t6Y6skBIhJUJKhJQI5W5A7gbkbkDuBuRru+Ie 6ru+xnuoU0WeE3lO5DmR50SeE3lO5DmR50SeE3mOi/tFnxV9VvRZ0WdFnxV9VvR50edFnxd9XvR5 Lh7k4kEq5KmQp0KeCnkq5KmQp0KeCnkq5KmQp0KeCnkq5P+LOs9RIUeFHBXWUqGfCv1U6KdCPxX6 ufj9La6o346yutQgL2R1p0HO7C9GP0n0k0Q/SfSTRD9J9JNEP0n0k0Q/SfSTRP9r0c8S/SzRzxL9 LNHPEv0s0c8U/UzRzxT9TNHPFP0S0S8RfbXoq0VfLfpq0VeLvlr01aKvFn216KtFXy36atFXi36T 6DeJfpPoN4l+k+jjexrOSV7CyZfqrZf5/tvB7vJ5aWllulAN7i6vl5ZWpgvV4b3q8F51WCna++xY zko2RK8ml0Sbk0uD7wU7iH6F6FeIfoXoV4h+hehXiH6F6FeIfoXoV4i+5eO7K8yi2ejLXL3Z1ZuL tTPVVaa6ylRXmeoqU11lqqtMdZWprjLVVaa6ys00XEnDlTRcScOVNFxJw5U0bKZhMw2badhMw2Yj zjDijP/hTnEjDTfScCMNN9JwIw3j3fn3aNhAw8WiOI2G29LwXBpuT8OrabgtDc+l4fY0vFqUvxXl b2k4kYZzaXgeDZfQ7/Lia8gqkVeJvErkVSKvEnmVyKtEXiXyKpFXlfbIW3slvoV7O63Cb+B/9gkS W3SPuoj3uZeKfqnol4j+vFL0x4l+O9FfW4r+ONFvJ/prRf970f++eD/wEX/3ffkPRK+K9FWRvirS V0X6qkhfFekUkU4R6RSRThHplE/dxTpNpNNEOk2k00Q6TaTTRDpNpNNEOk2k00Q6TaTTRDpta7tB Ee0lom1ENFY0e4km3teOFcVzwRmimCCKCaKYIIoJopggigmimCCKCaKYIIoJcvaDrb6z+Nlorkjm imSuSOaKZK6cvSdn74mkRiQ1IqkRSY1IakRSI5IakdSIpEYkNSKpEUmNSGpEskEkG0SyQSQbRLJB JBv+pnuPtrO6JFokf43yd2Jpb3q+aHcX7T2lven5It5dxPfI3z3ydw/3/kb0r3DvGdxbw72HB0dR op8S/ZTop0Q/Jfop0U+Jfkr0U6KfEnHXb6JCExWaqNBEhSYqNG1lvzpUPodSoYkKTVRookITFZqo 0ESFJio0UaGJCk1UaKJCExWadPP1uvl63Xy9br5eN1+/pd90iPgI0R4n0iNEeZzIlgffKD719EAc hPjZpwfjEMRPQD0Mh+MIHImjMApH4xgci/gZqcfjBJyIk3AyTsGpOA2n4wycia/gLJyN+Mmq5+Bc nIf4Gatfx/m4ABcifuLqo3gMj+MJPIk/4Ck8jWdQiWfxHJ7HC3gRf8RLeBlVmIJX8Ce8itcwNX62 aLSq+ETXd/AuZqMac+KnbkbNQ+ZhPmqwQA//tld+V+nv3yo+WfhAHIT4+cIH4xDETxk+DIfjCByJ ozAKR+MYHIv4OcTH4wSciJNwMk7BqTgNp+MMnImv4CycjfjpxefgXJyH+DnGX8f5uAAXFt+LmKdg noJ5CuYpmKdgnoJ5CuYpmKdgnoJ5CuYpmKdgnoJ5CuYpmKdgnoJ5CuYpmKdgnoJ5CuYpmKdgvvjU 2vgZse/gXcxGNebEzz+N1lFwHQXXUXAdBdcVnzi8EIvwnhUyfuUQv5/4yuLzcg/EQYifmnswDkH8 7NzDcDiOwJE4CqNwNI7BsYifrns8TsCJOAkn4xScitNwOs7AmfgKzsLZiJ/Jew7OxXmIn877dZyP C3Ah4mf1PoAHMQkP4WFMxu8QP8X3UTyGx/EEnsQf8BSexjOoxLN4Ds/jBbyIP+IlvIwqTMEr+BNe xWuYGj8Jd6uKNxWfGzwP8+EVEcULxacIL8QivFf8bJNsvK8Ldi0+KTuJMmyDcmyLodgOKQzDCMTP 074Zt+BW3IbbYZ0bYp0bYp0bYp0bYp0bEq9zqSHbB3sO+TZ+jAr8G/4dP8W1+BniV/v3FJ9ynUQZ tkE5tsVQbIcUhmEE4mfa7oAdsRN2xuexC3bFbtgd8dOy42dl74m9MBJ7Yx/siy9hP+wfP837//NP xYmf5H0RvomL8S2MFt8luBSX4XLEz/q+GbfgVtyG23EHxuPXuBN34W7c65z4yeAP4EFMwkN4GJPx O8TPDI+fGP4O3sVsVCN+/vA8zEcNFuCztT3aa9rLop+X9t4VpT13RfyM8eJ7jp4Mdk3OCI5Ovu3V Zxjsk0wHFyfbgx2THcEXkl3+ngl2TnZbhbP+rSc4Ori4+OzpJMqwDcqxLYZiO6QwDCMQP3d6B+yI nbAzPo9dsCt2w+6In2EdP8F6T+yFkdgb+2BffAn7YX+MduwluBSX4XLEz72+GbfgVtyG23EHxuPX uBN34W7cW3wfbFqvSOsVab0irVek9Yq0XpHWK9J6RVqvSOsVab0irVek9Yq0XpHWK9J6RVqvSOsV ab0irVek9Yq0XpHWK9J6RVqvSFN+GOW/SvlhlP9q/Fxuiu+SnBnsHVxafL57EmXYBuXYFkOxHVIY hhH4+/83MFd8Svye2AsjsTf2wb74EvbD/vGT5IOdhlyEb+JifAujnX8JLsVluBzxk+Zvxi24Fbfh dtiTUbifwv0U7qdwP4X7KZz737pDKTmahz96V+DFpXcFXpz8cXBukPAv8X3+uwRlfj60+LrpquJ7 7s4NPqc3Dtcbh+uNw/XG4XrjcL1xuN44XG8crjcO1xuHO3N/Z37Tmfs785vFM/dw5h7O3MOZezhz D2fu4cw9nLmHM/dw5h7O3NmZP3Hmzs78SfHMEc4c4cwRzhzhzBHOHOHMEc4c4cwRzhzhzP2Ku8ar fLVr/Idmu1/xd1wfnTmqqMFB8f8JxE+6ilby2kpeW8lrK3ltJa+t5LWVvLaS11by2kpeW8lrdbxW x2t1vFbHa3W8VsdrdbxWx2t1vFbHa/N4bSavzeS1mbw2k9dm8tpMXpvJazN5bSavzeSreXw1j6/m 8dU8vprHVzP4agZfzeCrGXw1g69m8NUMvprBVzP4agZfzeCrGXw1r/g89gfwICbhITyMyfhd0XcF vivwXYHvCnxX4LsC3xX4rsB3Bb4r8F2B7wp8V+C7At8V+K7AdwW+K/Bdge8KfFfguwLfFfiuwHcF visMeT3qVM2vBTvYD6y3Hxi0Hxi0Hxi0Hxi0Hxi0H1hmP5C3H8jbD+TtB/L2A3ldukOX7tClO3Tp Dl26Jdgmfha6WkypxZRaTKnFVHCRrDXKWqOsNcpao6w1ylqjrDXKWqOsNcpao6w1ylooa6GshbIW ylooa6GshbIWylooa6Gstctah6x1yFqHrHXIWoesdchah6x1yFqHrHVY+dqtfO1WvnYrX7uVr10m 22WyXSbbZbJdJttlslUmW2WyVSZbZbJVJltlslUmW2WyVSZbZbJVJltlsv2/++QhK99OVr5hVr5h Vr5hVr5hVr5hW1r5aPiN4h2x3w6+yPNXqIAv8v0VMjS7+FohZ3+Rs7/I2V/k7C9y9hc5+4uc/UXO /iJnf5Gzv8jZX+TsL3L2Fzn7i5z9Rc7+Imd/kbO/yNlf5OwvcvYXOfuLnP1Fzv4iZ3+Rs7/I2V/k 7C9y9hc5+4uc/UXO/iJnf5Gzv8jZX+TsL3L2Fzn7i5z9RezZbp7t5tlunu3m2W6e7ebZbp7t5tlu nu3m2W6e7ebZbp7t5tlunu3m2W6e7ebZbp7t5tlunu3m2W6e7ebZbp7t5tS2rexcs1u6O4NT+zi1 j1P7OLXPzrUjGb+LeDRFQ4qGFA0pGlI0pGhI0ZCiIUVDioYUDSkaUjSkaEjRkKIhRUOKhhQNKRpS NKRoSNGQoiFFQ4qGFA0pGlI0pGhI0ZCiIUVDioYUDSkaUjSkaEjRkKLxp1uGFA0pGlI0pGhI0ZCi IUVDioYUDSkaUjSkaEjRkKIhRUOKhhQNKRpSNKRoSNGQoiFFQ4qGFA11gdVUDbd4v8sc/76Fe2Sp 2knVTqp2UrWTqnVUrQt+p9pD1R6q9lC1h6o9VO2hag9Ve6jaQ9UeqvbwH9hdxe907lXtvaq9V7X3 qvZe1d6r2ntVe69q71XtvUMOUF0H4iB8GQfjEByKw3A4jsCROAqjcDSOwbE4DsfjBJyIk3AyTsGp OA2n4wycia/gLJyNr+IcnIvz8DV8HefjAlyILXejv/18tJvU1M24BbfiNtyOOzAev8aduAt346PP QVuvG63XjdbrRut1o/W60XrdaL1utH7If+g0j+IxPI4n8CT+gKfwNJ5BJZ7Fc3geL+BF/BEv4WVU YQpewZ/wKl7DVMyylr+Nd/AuZqN6y5+K8DdOGh2N0QUvK/1f10ml/+c6SResL7qrm7u6uaubu7q5 q5u7urmrm7u6uaubu7q5q5u7ermrl7t6uauXu3q5q5e7ermrl7t6uau3dO9ZH3f1cVcfd/VxVx93 9XFXH3f1cVcfd/VxVzl3lXNXOXeVc1c5d5VzVzl3lXNXOXeVc1c5d5VzVzl3lXNXOXeVc1c5d5Vz Vzl3lXNXOXeVc1c5d5VzVzl3lXNXOXeVc1c5d5VzVzl3lXNXOXeVc1c5d5VzVzl3lXNXOXeVc1cf d/VxVx939XFX3xbvl/vH3dX3339yVVDGXWXcVcZdZdxVxl1l3FXGXWXcVcZdZdxVxl1l3FXGXWXc VcZdZdxVxl1l3FXGXWXcVcZdZdxVxl1l3FXGXWUldw3lrqHcNZS7hnLX0K24azV3reau1dy1urTG 3rQFdy0NLuOuFu5q4a4W7mrhrhbuauGuFu5q4a4W7mrhrhbuauCuBu5q4K4G7mrgrgbuauCuBu5q 4K6G0rstarirhrtquKuGu2q4q4a7arirhrtquKtmK++smC9T82VqvkzNl6n5MjVfpubL1HyZmi9T 82VqvkzNL76z4rdeQz2ABzEJD+FhTMbv4t+McsqjeAyP4wk8iT/gKTyNZ1CJZ/EcnscLeBF/xEt4 GVWYglfwJ7yK1zAVr8efhxAcReGjKPxOsX7bKNxG4TYKt1G4jcJtFG6jcBuF2yjcRuE2CndSuJPC nRTupHAnhTsp3EnhTgp3UriTwhkKd1G4i8JdFO6icBeFuyjcReEuCndRuEv9ptRvSv2m1G9K/abU b0r9ptRvSv2m1G9K/abUb0r9ptRvSv2m1G9K/abUb0r9ptRvSv2m1G9K/abUb0r9ptRvSv2m1G9K /abUb0r9ptRvSv2m1G9K/abUb0r9ptRvSv2m1G9K/Xaq307126l+O9VvJ1dkuCLDFRmuyHBFhisy XJHhigxXZLgiwxUZrshwRYYrMlyR4YoMV2S4IvPfv+r4X10dtlS/W/pt0Gfr9yfq9xel+j2lVL+n FO+9vf4f/EzEv/d3gA3c1cBdDdzVwF0N3NXAXQ3c1cBdDdzVwF0NdpQFO8qCHWXBjrJgR1mwoyzY URbsKAt2lAU7yoIdZcGOsmBHWbCjLNhRFuwoC3aUBTvKgh1lwY6yYEdZsKMs2FEW7CgLdpQFO8qC HWXBjrJgR1mwoyzYURbsKAt2lAU7yoIdZcGOsmBHWbCjLNhRFuwoC9y1mrtWc9dq7lrNXau5q4G7 GrirgbsauKuBuxZz12LuWsxdi7lrMXct5q7F3LWYuxZz12LuWsxdi7mrgbuy3JXlrix3Zbkry11Z 7spyV1YvKNhl9m3x00/n+vd5mI8aLCjeCRS/+vliMCJxQpROnIlzoisT50b/nvha9O/J86N3k6O9 Zrqs+Imo8XMOppSeczCFF3LBsMThUTYxCsfiVJwT1Tt7gbMXJM6PlnDSKmeucNaK4HOO7nV0r6ML xmt1Rq8xWxMX+XqZf7vC9/+CCvwmakncE7UYpytIOTPvzLyzOpyVd1aHI9oc0SaGQ8RwiCMXFMfo dGSnMZoc2WlGtWa00IwWJorxRPPiT1Aofa70iNLnSo8Ihrr28677vFlUmUWVWVQZY5YxZhXvhtvR ta9x7WtcO+3a17j2etcecO0B147nvMzRy5KjNw8kL9ucL/226bDSb5sOK905NLt4patd6Wpjznel q407P3FO8H9c4QJXuKD03s17S/dEHFT6RIqjSp9IcVTpEykuD/7JlX7qSj81pwFXm+dqP3W1ea70 Q1f6oSsNd6UHXOkGV9rRVfZ0hT1d4WZXuDHY1lmznTHbGY3OaHTEjo7Y0U8nBdtTYx011iWuiZ5L /Gv0UOJH+DEqonWf8ccv+eNNev6SP9509oC8XcQTl+EavvhXnvgRfoyfGGd09P4n3hji+Ky5XCS3 V8jtv6DCa8grir+f2s9PG3j0Iv96WbTc1WpdrdbVal2t1tXe/kxeP1fK6+eKV24Vx0XRa84Nnbve uZucu8m5m5zb6tyhzh1G5VTxfQZX+Rq/1+Cj/1+eUzz7DvOaZ17zEtcEXzS3ec76PmU/oGzB2eOd vWvpt3G7Fv8P98fR7+L/nS7O+6fGHvjkCh+dfZyz3yu9p//s4pkfnTXJWdZ3Ry909EJHL/TTz/vp 5/3kYU693rxviD5I3Mjf44NtEhOivsTDauiRKJf4vbpM+OmGxPioEAzx5wfycKPq+rnIf4Hx0dLE na5yl6vcF2USk83wkWijMzf612td6zpc7wo38vlNUZfrtyceilYnvLrh3Wspfh2u968/d+QvcEtU l7gVt+F2jA8+n7gzmpK433G/jd5PPIAHMQmPRNONNT0oM8tVjlrsqLbE5GiteY+P+s1pvRlfGw0a ZdAIG4wQR9PGoQUOLTii4CqDrjJoxjeYZRzfTc692SzH6wJ3+rf7ZXtytDr4gmvNdK2ZZpxx5DzX TLtmOjHO32+Kup3VL4JeEfSKoFcEvcb70HgzjTfTeGsTE6O5ImkSSZNImkTSRJNaus8xl6XmsjTY w0gdRuow0jrzesdoq43QbIQeI/QZoc8IfUboM8/h5vmqUXqN0puw+6d0xrxfNlLGSBkjZYyUMVLO SGvF86bRWo3WGmxntILRCsXoP7ragKutdbW1rlRwpQE9+ufy/AuMN8adlL3Xkfc5sniE7yfjEb74 fSm7GdfMOKvXWb1mnTXrrFlnzTpbHOfjGbv+38z0Ecf8Xi3HuVxT/I1luWv2umavKHpF0eGYXsf0 FnOX/+v5ueK9xZkXxFrQEW5w/njXvNO49/r+Pj64n7smBynd72MFrpetm3BzsLujN5nhGjNc4+hB ca6RvQFnHWoGBTMY+MQ9sQdjj601g7XOnPtJ7QwEyeLPxuNOlbG9sWqMVePonKNzxoqrq9nMtjFe l/G6itre7+8PqY2HOesR//Z7K1iyWK8fRTgYjEpUyeHrwS6JN6P3EjPxNle+Y27vRrcmZkd/SFRj rrVoQfSrxKJofKLBMUt9bcRqKq/BOtfIR/cnCtEbifX4QN19GP3fZKDvlEWZ5La+DsUI3+8S5ZO7 YjccgANxSDSQPMxKfkQ0M3kkjsIoPfc4q+6J0dSkdfaTJx1dEvxT8tJgeOl9SIfr9K/osIfr9K/o SRkr1zNiq8I71H83WiKKAVEMiOKDxDxfF1jPF+lmS0S51NdGZHi4Wxbz6q/A/euxIVorgvfN/n2z fz+5uw57WJQ2y3Vmuc4s1yXt5swwDHYrjdpMv0GjNhk1Z9ScUTcZtd2oy4zaZNR1Rm0yapPRCkbr N1q/kfqN1G+kfqN8YJS8UfJGyRshF/ybEX6YeDH6pVEGE69HryT+Et2UmI439YWZeBvv6J5zo2cT C7inwd+XqPZl0Q8Sy6P/TDSjBSuwEquisYlWX0PHpaNpiXbfd6ALmeD6RHf0RCLr+x70Rjckcr72 YbVdwhqs9X0/1kWXJAZ0ioII1+OD6BTazUls9LNN+DD6c2Kzr5EMDkECyWg2Z1yd3Mb35dHEZMqe YJjvh9vvj4iWJrePfpr8J+yAHbFzNJJzRnHOKM4ZJRfXJL8Q/Sy5h599EXsGP0yO9HVv7BMdn9wX X/Lz/fx9fxwQ7cNp+yQP8v3BOCTaO3lodAaln6b0jZS+kdI3ct3Zcvpo8hjHHIvjovuSx/t6Ak6M 3kie5OvJOMWe5VTzOM33p0dXlO56bLWGPmkN/Vcr8F5W372S1xT3H28HX5alNllqk6U2/mj7lD9W 8kYnbyyTsTbeWMYby6jcSeVO6nbyySrqrqTuSup2UDTNL6so2Mkzq3hmFdW6KbSGQmsotEbEa0S8 RqRrRBmKMi3KtCjTolwtsj4RrRSF3hicqK5OVk+r1NKqYH8+K/BXhr8yZr7UzJeaeb2Zx3VUW3Jz oxkvLdVRo1k38s0/m3mzmTebeYPZzjfbTjNtNsN2eewwywazbDDLBnkbJl+d8tVpxsvMeJkZLynV 2XIzXm7Gy814SVxnZtsQHGBGC81ooRnNN6NOM/pzqarTZrTQbNJmkzabncymx2x6zKaNjq107KRj Z6lHLaNjk9n10LGJjk0cOFjqU2mzTJtl2iyHm13a7NJmV2d2q8yu3uzqza7e7N6n5woznGuGaSvb M6o8ntlstVqNeap8gRks0gmWWOGW+toYtavSjB3invFzVp3TT/dBuhfoXnDOBr5awU8d9kXPUP5F VOHjI96Nrv2kR8+zx1gQPRb3F3l8Rh6fsd94xg73RYpUcc4UbnvdnP7i79PxLgVmU6Qa86i3wOq0 KHorUa/3fZTTt8zxLf1jtV6R1QNWq9PVclgvZ81y1mx+TebXFOxjpPuNdKuR0n/Vnd61ms22jlVj np8tiCKjDJT64IARBoxQZYTXdJw6o8wxyhyj/OCvcrBPdJ0Rr1PVPXIRykUoF+1F7WmuCuN7R44w myNo+TYt51Ik4xVKEH0oux/K7oeUPtZaH2v5rghni7gamaBcPtfK51r5XFvstbeJZrJIZonkQZE8 yHV1XFfn2nMTs62Y1ZgbPS2ijVxXJ6JOkVy/lV57V6nX/qdeO+szvfY2kb/2qV5766d67XXce92n eu01em3dp3rtJXrtok/12je30muvK/Xap6l7a6nXVpR6bYVeW6HXVui1FZQ/kfLnUP4cyp+j196p 196o11botRU0vFyvrdBrK2TlbFk5W1au1Gsr9NoK2Tlbds7Wayv02gpZOlOvHaNqXqbybVS+jcq3 ydz5eu0EvbZCr61QQbfrtRV6bYVKukWvrdBrK/Ta78jwOXpthSzHn5F4Seku/Zdl+0a9dje9dje9 9j299qVgrOz9QPaulb0/yd51sned7C2RvSXFLvaOSpwbVctcj8wtkbkumfuZzNXKXK3M1cpcrczV ytz9Mlcra2/JWq2s1cparax9R9Zel7VaWauVtUdkrVbWamXtz7L2Z1mrlbVaWZsia/P1n7yMvSVj aRmrlbFa2aqVrVrZqpWtWtmql60/y1atbNXI1iOyVStbb8rWYtmaLlvTZWu6bE2XrbNk637Zul+2 7pett2RrrmxNl63psnWVbE2XremydYVsXSFbU2RrumxNl63fyNZvZGu6bE2XrQmyVS1bXbK1QrZW yNYK2XpYthbL1nTZml7cmx3v6wk4CSfjFPu2U83hNN+fHlXK1IUyNUum4vc/HiM77wX7yc4LsvOS TtGgJ62VpUWy9IIsvSAzfSrzJZXZqDIbdYxZspTTMV7Xl3Iy1a1rvK5rvC5jz8hOtZrqlolFMjCb wsvURqg2Qip3qf0lVFyt/peo/yXUnE2xlynxMiVeNsv4HQvfjNfs4Es8Us8j9TxSyx9/MXI7f9TL 9RlyukJOV8jlAqO8b5Q6o9TJ57RE/C7GwCvpMjpt6+tQDNenRljVdqHZrtgNewYH0349zZtp3kzr 5XTuoPNCOi+k80I6L6XtchWwjJaL7dczVp94nRwVbbL3ryruL39EoUco9AiF3jHPW6nwgXk9a16v mddros+W9glV5lRlTlVeEbwbTXDmbGfOFuF6Z0501puf7Nw/WhFXfbyrcMZqfXoN1rlePnrRkXMc OUfcqxz9kqOfF/c6ZzzvjOfto0NH5+1SCvKyHhvsMAKRlUdZRy101EIrZKgW8tFyR3U4qsNRGdeL 98F1jhxwZJ0j66zgy/hiFXqxmifWYJ1XIR9gg07+odW6LGp01gr5fUE+p3NdE9fFa9O04p1U8V1U sft2cIUBVxhwhYHSfqDV+K2uli3uVAKuKSuO32X8rtI73Q7zeuNI6+pS6+rSoipZV8m6yvuussJV el2l11X+H3PnAV5Vlb39tfc+IZ0ghEAAIfRQlKoDocSCBREiCApIB0FIIAjBggZnBEXRcbCMothm VMQSQKIgVQS92BJaApckFwUSakhA6SXn+52d6wwz43yWmf//+5487z655+y+17vWem+Sm+/opZxe VtKLt96V9LKSXSnn6VFQmc+d8/bP5vwOcSuY93O6fp56+1dOjaOgcpbfX5S1lLLm7bQspOU51nyM 1oW0LhTNSr335TqgJf1EtVL6OUvPEe4PUvVvUXwPDCu1Z7mFXnfR6y5qFdLjh/ie48G9/5AePzTe /4f1Wn5Oy49p+T0tV9Jy34+qxfNkF9sLLVay/33Z99FoUu9v6MJpf4w2x2hzmDaHg7qqnJEO0q6c duV25asYxccIX1zEtTxWnEWLk5ZbEfbdqkeCp7uTUcbb9+O81kusLyhFVZXjJ46CH/DqZ6xtHGEs bx920Hpy8L2uTbQeZH+OUJ3Wu2i9nBXm4Oe308snzHjxRVxaHmTGK+yR51G8vPsVZv4KvX5Cr0/Q 2yJ7yoWMXWhz3xPw64y7gVZHmEMhLY7Q4gjW42fn9mDvJ+DvSeLEKXAWfyBE2spdeZSaj2Jvo7C3 UZznCWZ0kj5PAWI8+Uo82WEb0I7zag86gCvcM/iJWLx/PGP9mKO1Yb/bsf72oAO4wv6t3gHvEwkk gtpl1D5N7TJql1HzFDVPUfNUUN0ewkselfpKuxuVAQ4IAVVAKAgD4SACRIJoxo9Cwca6L+P9DuP9 DuP9DjPCYkZYjAcswwMexAMexAPux6/tw9MdZpQydvINdvIN+9u/3m/+epytiR89bmLhYByrqgVq g0R40wJcBtrQUzssqT3oADpy7wqJwY962rmE3o/AY7IGacfKd7DyHfjUWLLHeLLIxthtE9DUvgtx +l/0/WDmNsw9zF5FUTuOnasFaoO/a4JDdswu1E5mV8Ppu9y+X9CYPKUJaMeT9qADuIIxvP9zGUaN 74Pve2zi6SaebgqO+DQjPi2hPC37hxP2TuNHL+SNkksfJxhlB6PsuDiHpR9vPiWimN0JqWGi+S7W fY35lzH/MuZfRrtltFvGyk9cdCJHWMth1lHGiXh/E/keJ/IeJ1KdE/Hei/fLJfT0wT+d7Vp6WktP P9DTcXo6Tk+n6emH4Nmeoaev6enrH3uyJ7Cb+e+n9U5a76T1yaDyu9imS1jHWXo4wY7Fke3XArVB ImgBLkN3V6qA7+yeBOgvQH8B+iunvzz620Z/2+hvGzZxyP6OaWMzXBrL9TLGfVHuBGPBVPd1mc6+ PwAeBJlgBtjrzpNiUAK+t5/ZNlfOgnPgPLjgzlWJ7mbVArQErUBrgFZUl4M2oC1oB9qDDqAjuAJc CX4HOoHOIAl0AV1BN9AdJIOrwNXgGnAt6AGuA9eDG8CNoCe4CfQCN4PeoA9IAeOlllrnfqI+dZer 9WAD+Ax8Dja6a9QX4EvwFfgaD9NEqru5UgNgZVITxIFaoDlIBC1AS9AK9AI3g96gD0gBt4C+oB+4 FdwGBoEx7svs+Mvs+Mvs+AzJcF+RaeAecC+4D0wnk3gAPAgywQzQTJ4mH3gGPAueA38Gz4MF4G2w ELwD3gVfga/BNyAH5IJNYDPYAlBssg3kgXzgB3vdpZzzUs55afATN78U8nY5AU6CU+CMu5izX8zZ L+bsF3P2iyVdHLlEQkAVEArCQDiIAJEgCkSDqiBJ4qQLGOM+wD48wD48wD5MYx8msA8T2IcJ7MME 9mGC3E8P092J7MVE9mIiezGRvZgoMyVGZoFHwKNgNngMPA7mgCfAk2CF1JeVYK87nZVNZ2XTWdlz rGwhK1vIyhaysoWsbKGcZsZn3ExWl8nqMlldJqvLVC+5+Wo+eBm8Cl4Dr4O/gL+CN8Cb4C2wALwN FoJ3wLvgPfA+yAKLwGKwBHwAloJs8KGbr9sSx9uhqTtyTQY3ug/onii3XqAvr8ejySe4aToVpLlp wZ8DZwR/DpxhMlBL01BPmyXEbJFYs00amnzyze147r1kp8X40xJJNPu47vc+VY7rYfyQNpuovZcT 8b7z/qKklpzgRKM40ShONIoTjeJEo9ifKM4jihONsl/RoCqo7hbAlAKYUgBTCmBKAUwpgCkFMKUA phTAlAKYUsDp1+D0a/yqz64e447DUsZhKePkLnKq8WACSAVpYCKYBNLBZHA3mAKmuuOxqslY1WSs ajJWNRmrmoxF9cCiemBRPbCoHlhUDywqAouKwKIisKgILCoCi4rAoiKwqAgsKgKL8v4HdREcLIKD RXCwCA4WwcEiOFgEB4vgYBEcLIKDRVhfPNYXDxfL4GIZXCyDi2VwsQwulsHFMrhYBhfL4GIZXCyD i2Vw0fvfuXdjsXdjsXf/ys+OfgHrXoB1L8C6F2DdC7DuBVj2/Vj2/Vj2/Vj2/Vj2/fhsPz7bj8/2 47P9+Gw/PtuPz/bjs/34bD8+24/P9uOz/fhsPz7bj8/247P9+Gw/PtuPz/bjs/34bD8+24/P9uOz /fhsPz7bj8/247P9+Gw/PtuPz/bjs/34bD8+24/P9uOz/fhsPz7bj8/247P96haJU31BP3Ar6A/+ tz4Pcp2bTaxYTaxYTaxYTaxYTaxYTazIJlZkEyuyiRXZxIps9Y1EKDSdygWbvN+RIMdtBzoC77c5 krlW/kbHQzC6D4zuYxl9B2pmDBgPwy9itp5o/8azG+yeALu7we4J5B1/MlNR7Kvc9WatVDWf4gE2 kbtsIZvYJrVg+iGYbswOcplKtofA9ib2v+8d4v5hvOF6cdz+EgKqgFAQBsJBBIgEUSAaVAUxbhcY XASDi2BwEQwugsFFkoQ1dQG/isFyh9wJxoKp0kkyYNI0cA+4F9zn+XlpJQ+AB0EmmAFmutfJLPAI eBTMBo+Bx8Ec8AR4Ejzldv2//C39T/xPSvcNWQm+Qv98Db4BOSAXbAKbwRawFWwDeSAf+MFe6SfF oAR8L+3lB/zjcXACnASnwBlpKmfBOXAeXJCm6Idc9EMu+iEX/ZCLfshFP+SiH3LRD7noh1z0Qy76 IVdVc/+iLgHVQQ0QC2qCOFAL1AbxoI77hqrvvqMagATQEDQCjUET0BQ0A83BLe4i1Rf0A7eC/gC9 oW4DtwN0hxoEhklvNUJuVSPlPjVKrlOjpasaI7erTHelmgEeAr8HfwAPg5lgFngEPApmg8fAE/Q1 192ingbPgGfBc+DP4HnwAgq8rTtAdwRJ7m6dzPVarjfKQN1TWuleoK87EJbshSV79Xi5TU+QRJ0K 0sBE7gV/L4Dc+hpy66vNSneBWev2NnvcL4ljsaaYLH4fauIAmuyg1DWHiI+H3ZMqXpyK0xICqoBQ EAbCQQSIBFEgGlQFMRVbiXGriXGriXGriXGriXGriXGrYUg2DMmGIdkwJBuGZMOQGTBkBgzJhiHZ MCQbhmTDkGwYkg1DsmFINgzJhiHZMCQbhsTAkBgYEgMTomFCNEyIhgnRMCEaJhCfwCPgUTAbPAYe B3PAE+BJ8FTFBpnrboUNqbAhFTakwoZU2JAKG1LlBZ7NA/PBy+AV8Cp4DbwO/gL+Ct4Ab4K3wAIy sbfBQvAOeBe8x/33wSKwGCwBH4ClIBt8CD4Cy8By8DFY4c6EdTNlFd+vBmvAWvAJWAfWgw3gM/A5 8IGN4AvwJfiKcb8G34AckAs2gc1gC9gKtoE8kA+202YH8PP9Tq4FoBAUgYC7XHaBb8F3YDfYA86Q 6ZwF58B5cEHCYG4qzE2FuakwNxXmpsLcVJibCnNTYW4qzE2FuakwNw3mpsHcNJibBnPTYG4azE2D uWkwNw3mpsHcdJibDnPTYW46zE2HuekwNx3mpsPcdJibDnPTYe5UmDsV5k6FuVNh7lSYmw5z02Fu OsxNh7npaihzHSbdg/9T4UrY2wr2toK9V6mx7jY1HsufxvUecC+4D9wPpoMHQSbzmgEeAr8HfwAP g5lgFngEPApmg8fA4/Z3IdPVk1z/CJ4CfwJz3ZmwfiasnwnrZ8L6mbB+JqyfCetnqo+oswwsBx+D FWAlWAVWgzVgLfgErHNLiMMlxOES4nAJcbiEOFyifHiQn/5Lnf0qB+SCTe5+PEwkHiYSD7MSDxOJ h1mJh4nRfStO4Vnm4Fnm4Fki8CZz8Ca34U1uw5sk4U264U2mmdXuKrMGrK0oNevcj4i7O8x693Oz wX0KLzMLD3PalKDh99HmADH6ILH2kPsqXsb7D5cz3WRYmwxrk2FtMqxNhrXJsDYZ1ibD2mRYmwxb 18DWNbB1DWxdA1vXwNY1MG8FzFsB81bAvBUwbwUs2giLNsKGLNiQBRuyYEMWbMiCDVmwIQs2ZMGG LNiQBRuyYEMWLMjC6oux+mKsvhirL8bqi7H6YpPrvmk24yNRhmarO9psc1eYPFa33S0kowgQp2dW nJBZ4BHwKJgNHgOPgzngCfAkmOv6WE1fVtOX1fRlNX1ZTV9W0xff48P3+PA9PnyPD9/jw/f48D0+ fI8P3+PD9/jwPT58jw/f42MH+rADfdiBPuxAH3agD77Hh+/x4Xt8+B4fvseH7/Hhe3z4Hh++x4fv 8eF7fPgeH77Hx66NYdfG4Ht8+B4fvseH7/Hhe3z4Hh++x4fv8eF7fPgeH77Hh+/x4Xt8+B4fu53C bqew2ynsdgq7ncJup7DbKex2Crudwm6nsNsp7HYKvseH7/Gx6yn4Hh++x4fv8eF7fJzCw5zCw5zC w5zCw5zCw5zCw+T8y8j5l5HzLyOPf4s8Pos8Pos8Pos8Pos8Piv4ebZ55PJ55PJ55PJ55PJ5UuG+ Jq77mhKg3Nc40UHkh7mc6guc6gNma0UFp/oXTrUnueJHnOy9nOxLchSlF4/Si0fpxZO5xOPz4lF6 8WRk8Si9ePRdPPEnHqUXT2zqSCQsIRKWEAlLiIQlRMISImEJkRB1CVqAlqAVSJK6qL26RMJ8ImE+ kTCfSJhPJMwnEuYTCfOJhPlEwnwiYT6RMB+1dzVq72rU3tWovQBqL4DaC6D2Aqi9AGovgNoLoPYC qL0Aai+A2gug9q5G7Y1D7Y1D7Y1D7Y1D7Y0L/tfYFii+Fii+Fii+Fii+Fii+eii+eii+eii+eii+ eii+eii+eii+eii+eii+evKUtMGid2PRu7Ho3Vj0bix6Nxa9+998ynUHVF8HLMaPxfixGD8W48di /FiMH4vxYzF+LMaPxfixGD8W48dS/FjAcCxgOBYwHNW3C9W3C9W3C9W3C9W3C9W3C9W3C9W3C9W3 C9W3C9W3C2vphbWMxVrGYi1jsZaxWMtYOY3SPuN2wFo6YC0dsJYOWEsHpaWKMsABIaAKCAVhIBxE gEgQ7f2NFVGlL+gHbgWoBlRYDiosBxWWgwrLQYXloMJyUGE5qLAcVFgOKiwHFZaDCstBheWgwnJQ YTmosBxUWA4qLAcVloMKy0GF5aDCclBhOaiwHFRYDiosB++fiffPxPtn4v0z8f6ZeP9MPP90PP90 PP90PP90PP/0n1Bh8aiwS1Fh8Xh/PyosHu/vR4X1RIV1RoV11r1RZn0lgUjgJxL4UWLjUWIpKLEU lFgKUcGvJ4nR70otvUi0/pjrCrDBHaU/c5fqz8FGd57+2o3Tu+QKfQL1dpK89hS44A41sRJj2rhv mXbu+6Y96AA6uYvMaolCxbUhmnwASzeazUSNrRIKMz9ExYXAzAqiSx5K7oGgkjPB920MUWa/OUiE OcT9w+4RtJRDVAgBVUAoCAPhIAJEgigQDaqCGHcV+Wkh+Wkh0WkJ0WkJ0WkJ0WkJ0WkJ0WkJ0WkJ 0WkJ0WkJ0WkJ6mrDj58Y9yv/ZqyQXKiQXKiQXKiQXKiQXKiQXKiQXKiQXKiQXKiQPKiQPKiQPKiQ PKiQPKiQPKiQPKiQPKiQPKiQPKiQPChAHhQgDwqQBwXIgwLkLAFylgA5S4CcJUDOEiBnCZCzBMhZ AuQsAXKWADlLgJwlQG6yk9xkJ7nJTnKTneQmO8lNdpKb7CQ32Um+sIR8YQm5whLUx8fkBAXkBAWo igGcSCnx/jyxfgmnUEqsTyHWnzcnKw6YUyiQ026oOVNxypytKDTn3CrmfMV+c8FNNhXcd914J6Ti gFPFvcYJdUOdsIpTTnhFoRPhVnEiK/Y7UW6yE839qi7ahBi8BE99yOTL5cb7/4M34sHm48Hm48Hm 48Hm48Hmw+wCmF0AswtgdgHMLvj//jO2vL+J8dn/LFAKg0thcCkMLoXBpbByHqycBwO3wcBtMHCb ftM9YH8jovJn5bth1m4Y5Yc5880maUB8+w7WPCmak3kfXsyBcSuls1klQ80n0tGsk9rUXW7Wo/42 SHOTK31o18dsgT1bpbvZJtVNnrSnj29hXn0JM3u4u1dawrc+8K2ZOSDX0+/64PulrRjpU/c96j9r x1zCswmwcpVU5d6XvNpkfea/fDKEGi/JnOwmacepdmWEm7GfnoxXeacd1nWKu9dgXauwrkP2U3wO i2KUvVKPV93t+7O1qNuU8bz/frpPLqPG5bzaJMmsJpZn9VmX97c+A90ckyFJzHW9040IqLnzBa++ pvYaN0AuW86rAK/SJJpXZ3n1hVQnG0gmG0gmG0gmG0gmG0gmG0gmG0gmG0imp2SygWSygWQzQGqa weQSw0Aaa1pFvrGO/PhTfEWY7Xele5y7AUbcZz5hh9fBpE/dZWTQh5lnBvNfSR9rqMXMmGe0VFeb pbHaIm1ZxTDmfK0ZTK3Kz4e4zH4+RJr7qfe3IOYed495Xq40L8jvGKeME2gKSxc5naW9kyRtWdkd Up8W9RmnIzufIQmMdMQb344UzQgljLDRDKH1UOqP4DqSawYnv9ndSd5USs50xp7rdgmjFTGTFl7t OGrGUTOcmmXUKGdH9sJU/APR+7z3V1l2/9Fa5GKlnFAMrN5i+8tjt/NpRZ+ep6fPAe4B7/ccadES Cw21tfPd4+RbF/c5BLsfASYy9wwiyCb3GKOXM88yTr8mfZ+g1ef0G0m/pykHsEcDQQZWnsuOb6LG ZmazhR3fytzz6aFyFuex3wHcHeietJ/X731W/xSeZEg8LcOZURVanqTleVpGM1aFt2panvN+viI3 SDEoAWekOQq6OQq6OQq6OQq6OT0Poue2ZggsHCrDzQiuI7lORHdMYT73uG+YBznX56UT59mVHdvM iEl2b7e6r9jR8tzt2HcsmevZ4Bm3Zw8GMIeB7OkQMNT7JH2uI7lmSB3m7bErjPlGMNf9ZodUs6e+ mhbraVFMizq0KKZFHVp0onY1xtxnT36re45xT9Oy2LbKs59hX/lXTQnBv2pKMNPwFnukEZ6gHD5G 4DHi8RiX4AdWY3OV+19ALcOdcvZxAN8NtLZpP+nITOXU78Wn7WPeBxjxoFtm7eE72hXTLoLew+hZ 86SA+Y9xj5EdHyM7PkbGe4ya53/8hEVqh9raeznlfezUfuZ0kJz/EL0cdkux31r2lDfbz9cdzLyG ganMeBp+bg97vJcTLsY67UrwRwdY/0H3G+89Mzv2OcY+x9jngisr/fF3pulF00tLxq9GL6fopYJe vM8kC6OH3cxBYydj5Ga5E4wF06WHPAAeBJlghvSg1xh6bR383NG+wc8b7Qvn32anlrJTa7CTjdhJ T+zkZvOu+zTz/hpv2KxyRPyxN+IBtwAbScJGkpxu5NVh9HwyeHY6eHba7pe30oPeXzZSYxFjLwjW igvWimPsMmq2t0r/oPffpU1axQZi/RFi+3fE8iPE7u+cxIoSzjutooy75dwpdxLd7vSaVrHLnGQ/ ztH6PPy64OY6Ie4p4v5pJ9I9Ts1cal5v237K0y3c2cKdCNu2zJxlvHOs7IKbTw5R4ZCd07aCWvnk ChXUTIbbaRX7GKWCLOQ4Mys1Z7ieY9TzWEdly/OMWkH2cZwZlzphXCOYRST3K3s6zwpOYB1p5C2n RNFLOb1U0ItrvN8w88auIorW5bSuoLVLywPBObTw9qliLnPYQ+vGtC6k9UmDSrWzP4+9XcAyKohr rnuBueyht8b0VkhvJ51wN8+uKtL1O1FSjUzoED1fYE5ZXiRxNT2eZh4BUyGaVqcZO+BE832i29Cr UbGJGvsZz9upAmrsp09vlwroA437z+fF6QfPidY/cz62rj0X6v7MebDG//Ac8Gm/cv9h+n9531nj v9lv++Qn91mqOrES7tRkfrUlwqlDb3VpU4+4eSnf1+dZA5414lkTXjflWTOeNcevOE4cI9TlaQLX ppxJlBPLq5pumVOL8eswQl1G8vqqz/0G3G/I/Sbcb8p9+uEUvNreyHWDNbyRvL6qMy/N0xInjju1 QG2pz/yqU7OEPuszP838NK1KnASeNwSNuN+EOk2514zvm7P2qvQSYK7eCrUTz1zrSEiwF691gPl7 K9ROY5414Vlla816Y0FNbC+OOdem3zqspS6nX4+xLvXWxfMGPE/geSOeN+FeU54343lz1scqOJua 9BvH3VqgtrudOVSwO3ucepzlpay5PnUaUCeB5w1BI+o0pk4T6jSjTnOii3dOUXZfa0ss8/B27DTz iGUekcwjyu5tI143sTt4mjnEModI71TE2LXXCe5z5ey93TN23ZUtyoOz1hLzW20C1paxf/9kF7C9 jUT/WtugVVsJ/Xf2wdOmUuO/ZSP01ppV/0Y7oXWiXPKf2gq9dPZW9N+xF07iK3uOv8lmbGyI/rV2 Y716Irr6IJ50BB6nHl6tN7q6HK92Hbr6EN5nDF4tAa+WhK4+iEcdgTeqh1frja4ux6tdh64+hGca g1dLwKslObEVJ9mRy9iRFuxIC6c2r+Pd1uxIVWbVjl1pxq40depzvwH1EqjTEDTidWPqNaFeU+o1 o15zrCYc9RKF7khGZUajLmuQccaSbTYhq+hErvA5GVcMLBiKqrpMRJLQTS3lar7aSi+5VdrJbXI7 dweRD3WVu+RJuUmekvclXRbJcr5bKWtlnqzj6xXZINvlVfGTYS+V/aqmrFN1VV0pV/XVZXJU3ax6 K1Epqr/SarAaqsLUcDVGRanxfFVXaWqSqqGmqXkqTr3EV5J6ma8u6lW+uqp31Luqm1qnNqlk3Va3 Vym6o/6d6qeTdJK6TXfXyep2fa3uoQbp6/X16g59o+6lhujeurcaofvqW9VIfZseqMboO/Qdapwe roeru/QYfacar8fpcSpVj9eTVJqeou9RU/R9era6Vz+u/6hm6z/p59WTep5+UT2n39QfqOd1tv5c vak36u1qufbrvWqjPqAPq226XB9VO/T3+pTaqc/oc+pb7RpRe4w2RhWbUBOt9pkYU10dMbEmVh0z caaO+t40MA3UKdPQNFKnTRPTVJ01zU0Ldd60Npcp17QxbbQy7Ux7rU1Hc6V2TJLpokNNN9Ndh5ur zFU60lxjrtFRpofpoaNNb5Oiq5r+ZqC+xAw2ozX5jpmoE8wUc69uZB40D+pEM8PM0C3M8+YF3dIs Mot0a/Oh+VBfZpab5fpys8Js0G1Mrtmhk8wec1j3MCeNq/s4IU5VPdCJdRL1KKeb003fi6UoEKGS qnwlZvT9U9IkdtyUO1NlUtrIjEnyElpc3drvmgT0j7iu/e26KlJXGqLeW2JZHbGoayVFBtBHT7lD Rsq4YL1oFH09aSQ1pBW2d4V0Ieu+BRtU2N0QGYUFOrSprFuVmHOpNJZYac04V2Kf10lfrFVjuUNl tIwnbut+Kb0TpGv/fr0SZIJtVwN7DyfPry1NpCY2/zvpJlfJ9dJP0DxowZtlGBqgsi5ejpU0kHhp KnFyuXSQTtIdbtwAMwYxk0TpLcNRC6nBnr3fJEyQOtIMFdNGOsOla+RG6S9oBWkhfWQELEqTiaPb Tx2t59ryJVu+actFtvzYlutHj0zL0N/YMs+WRbYstmWpLY+PHjn1Tn3eK422ZZgtq9oy1pZ1Ro+e ONkk2LKZLVvbsr0tO9my+5i08eNMD1veZMtbxkxKn2hus+UQW46y5V22nGTLjLFTRo420205y5ZP 2XKeLf9qy/fpbKRZZsvVtlyfNmnaRPOFLXNtmWfLAlt+Z8t9aemj00ypLb+35VmvdISHU5wqtoyy ZXVb1rZlfVs2SefitLRlW1teacuutrzGljemTxkzyeljy/62HDzZuz/ClmNtmWbLKba8z5YzprLn zixbzrHlM7acZ8tXbblg6vhJY533bbnUlh/bcq0tP7PlV1Mnjp7sbLblLluW2vKsV4aE2TJu6rRR U0Oa2LKlLdva8kpbdrXlNVOnTZ4acqMt+9iyvy0H23KELcdmMPOQNFtOseV9tpxhy1m2nAOdDLys BSN+y3fa+8vYX3FVcOHnS+cXlPX+pYz82dLgM8Lh9G/5TuHB/rms9gtKbVev6cl7pYK+0yvDfkEZ 8wvKOv9SVv0F5SV2XsZe1UWlN9+L70X9bBmC74vFm1ZaxH/2Ki746peMq/DMP19G/0zZCO/fhxgz DO88Se6RGfIomc3z5DILyHKWkeH4JJfcZpfskzI5KRWqiqpKnlJfNVOXqytVd3W96lN5rqpa8Fon eE0IXq/E+r1r18rXOqHytZ4bfL258mrqVN43wfrmluD96cHr88FrbuWVrLTyGnzuvBu8FlReQzpW XkPftKeqwosqX0dcGbxeVTlOxE3B13OC1/OV16jESq5FFVVeY6pU3o+5K3j9KnjNC16D48acZLwI MFr92TJglHqOMoyVzvc4oE54WlUcc525wdxoenr80NV1dYwvVsfZFtQ1Vb26JhobVZyOwudUcoe8 XKLUUXWUlyfoS6mz6qxo5SpXjA7RIeLoSB0pIbqariZVdE1dU0J1HY1K0Y10IwnXiTpRIkxPRo6k r1qs7mFv2ipGHlJ11KXye5WoEmUWmeoQeYTsdKI8ptJVusxRd6sMeULNUXPkT2SrL8pcMtJb5Bmd oadJtr6X3OgjPV1Pl2U6U8+Q5XqWniUr9Gw9W1bq5/Rzskq/oF+Q1eSTO2SNiWaNx8juOsoP5HI9 5DizaS019GvmZpNixppxZoJJNVPNNHOvud9kmsfM42aOecI8af5oXvF2Qb+qX8VJ9TK92Kk+po9o M8bcKcbcZcZLCLnfFAk1GSZDwsw95h70wH3mPlZONiiRZIMzUQfzzXx21ljf8fc9ru+dgu6ivbMJ 1e10O87mSo3d6M66M0+66q7sdQ/dg72+Sd/EXt/CPlShdm32t62+Qnei9bW6p07R3XQv7of/8l70 w/phRn1WP4sdaPE0WX2ngZPgNHQaOY2dJk5Tp5lV78qsRNWInX3ti2bfwFpOmlfD8VRvZY16F9VI uOiZ9n7GRG1xPLWonEQn0dqFN26sU9OJc2o5tZ14p45T16nnqcK/javJImOc6k4NcuQqTqgT5oQ7 EU6kE+VEO1WdGKeacwl1HHb6IabgtdFk0N1Ro1c7V8MATd5a2ywwC837ZrH5zHxufGaj+cJ8ab4y X5tvTI4pNUdMmSk3R80x8735wRw3J+x7XG+Zt+jxbfM2c3nPvMe5k8+zDm8Mx8ve/9b7W9R6j6cr zSqz2qwxa80nZp351Kw3G6i31xSbErPP7DcHzEFziHZe7wvMAnpfaBbS+/vmfXpfbBbT+2cmh95L mYPX++VoyZ/q9SfWYfdsD+0k2O4nRv43a/X2Ose2ayRV1QB1uxqkBqrb1F1qq56mZ+jH9J/NS+Yd s9TzOeoW1Z8DHqfGSYjarDZjSxk6A1vK1Jne55jBw3DLwwgzz8yDA94ORpkPzAdEAq1OymmZKbPk EWLAbHlMHpc58gSq949EhD/JXHlanpFn5Tn5M/HhBZTvi2id+fIy6vdVeU1el7/IX+UNeVPeIna8 LQvlHXlX3kMvZxFJFssS+QBtnC0fykfEleXysaxAQa+S1bKGKPMJKvpTWY+O/kw+J+ZslC/kS/lK vpZvJIcItEk2yxbZKtskT/KJRzvQ2julQAqlSAJEp2/lO9kte2SvFKPB98l+OSAH5ZAcllI5QuQq l6NyTL6XH/AyJ4hjp1jrGTkr5+S8XJAKcT3HjF7up2/V/fUANPPteqAepAejm4fooXoYynmEHqlH 6dGeetZjUc93oZ0n6FSdpifqSTpdT9Z3o4t36gJdqIt0QO/S3+rv9G69R+/VxbpE79P7UcwH9SF9 WJeaCH1El5lITz3rY6jnH/RxfUKf1Kf0aVT0WX1On9cXdIWnpY3ytLRxTIipgp4OM+Gmr+lnbkXv DjFDzQgz0kw0d5tZ5hHzqJltnjUvmpfNEs51qclG436Mts01m8xms8VsNdtMnsk3280Op4vTFaup Wen/rSd/yHrm181NeNQ8NHUf2Y6avkP8ZpgZLgXWTxSZyWayBGD1H2SXecY8I3usNe21vrTYcrPE WtY+7PId2W8ZesAy9KBZZpbLIcvTUqezk8RJaLWWM/yfsbt/tLr/KZsL/Fes7l/t7kfL+2nb+7v1 efb3dwt83drg/44VvujZj9KqJl6nDjlDrPVAjW3mkKiGqTullfVGHbx3uqSjSiWXuIJcYrp0Ug+S HfVQL6pXZJj6SG2S0XoK/mmGfly/KM/ZyP6WiTLVZYH3rpFkmTjTUhaZ1qaNbDDtyBY2WqsrJJ4l EXmrEwHrSzPyh47M6S2+vJKYYL9fZF+tCb5aw6sAX95v2bVSrZj75epyDqKT6oQ13qBuYKm9VC9x yHHmkZlXZnOL+CIrUEPV2OCdZRfd+ecMoqHNIIboCTaD6Kf7wbDb9e3E/sF6ME+G6qHE/jv1ncT+ VJ1K7L9b320ziEbeZ7P+QwbRF6sYRF9jOO/JXu74K3IJb+RQO3KYHTncjhxhR460I0fZkb2fHT0n N6htKk/lq+1qh/KrnapAFaoiFVC71LfqO7Vb7VF7VbEqUfvUfnVAHVSH1GFV6hjHMSfNKXPanDFn zTlz3lwwFcb9T+45bL7j6cY6WJe22Wk1T1mgLQzaoz6PvRw1BHtjldjbYAnlHLzfsPcsLZysNY14 6GWtkWqauoeMOVNlEkEfV49LjHpCPSnV1Fw1V6p777hKDSzwI6x3nfoUe/apjVJLfaO+kXibu9Sx MbiejeBtbQbTw2Yw1zO/JGb4G/YsyJv/hyvDclranGEwrPk5BfgNXtCPxyvGtx3Fj51n7mHowFjm nYASbK3aw57uqoe6SbVkHYms6jJ7HQynvOtQ1dleh6kkex2uutjrCFShdx2putnrKNXdXkerZHsd 87fr1fY6VvWw1/HqentNg6feNV21gIkxsFnzqrV477NfbrnZhnKYakv5f6q1Fniotra/98y4k7sw aEiIsMdtKLknXUjuldsYg3GdGOSSzFRu3RNFxSByi0p0kVASopRSSOp1raSQkOLbs6mc0znveX/f 7zvf+b3mN8+a9azZa6397Of5P89/GTcQD0t3UAOWRFATlh4gjBbwWtqw9IR5KgokgwRYeoEmsKSA prD0A9fB0h9GBRS8igUsqSDMC2AutBGWweBmWKbDHBgFngYtYXkGZlQQoAsYARaANeAEuAM+ABXY BcTCme0wHGPpcMbKg7PTZTgb3YIzTxNYCN9BOrzrIqR1AYuR1hW8gLRuYAnSuoOXkJYIliKtB3gR aUngZaT1BMuQlgxeQVovMAOxRSZiBSZihSzECtmIFXIRK+QgVjiHWCEPscJ5xAr5iBUKWPeGYJwS 0lrBtcISQAnQAPSRs6ElsGeJIbZeithIfOH7GFDixycfliWREzBeMBWxFSJZzAAUgH0fAEXh/AEi Po5CPBeN/BaFFxwFP4MzMAiwo3hRgigxFBa1HLUS4cv/l/wXRnKEo/1kfJwsFvSDQ/0bHvSDQbHm cEX5/8B8VgZgndGIIaNwD+MOfD+5AxbOv36chmFN4FZkXo1dDTGwOuxcynEWcZN8IAeKycAqwqrl KBDE80Bc7GwqS9AoSTYAIrJzq7CDGJBBQIEYpi20FVq1SCOVLRMrBT8k1msL4AGEAEGAP0AGaPDb gPWCZBdNhhEx6g2IZJKy5Ffiny85fSK68cmtiRgmQ7QHYqDr4LcqEw2DFUpgfbVESs8hG3PTya4A Cz78OYjvx1ZBNnhT9APIJtH2GHZh1HZjvCgkzOpwCvM6kkNo5OBAnCmRSsaLQEIsNYcwj1losAcx MIzi70/G88OzwVpuYXY7H2I4jYyXhrAsBY+wyLwCZ0oOplG8KCQijRIUiF8GSbOG0cJiC8N2lAB4 FWIAlRLojTM1hmSW8kGaeA1IC0L+ti/lw7O6mhqa2nraetsh20WbtbfFL4VE59df4kAOpthSvANX 4TYEktTwKtDK+YXkvg8gS+Fsv69lSw4Oo5DIIaxFGaDcYquAbACaAfIDsJ4bxQBBoKDp8rnmFlwp 9+7E4vjQj1esRntq+au9iVU5nlKdldNNmkX7oESnmINdft06GfzVj4Z3jYXnxQTpVyeX8t3w+eR/ oqnKRrXIYu1ExVMXNywq84u6n8y5yZz0PMkG1Os9m216l7gPG0nFXOd7aXjvSk98lVukL14NnUYX zl+Pe4AP4XNUbdmlpZkilCZ0/aWPeuFA7+2kg8p3DsjGe1XtdXIMCq3WL1SId2kSENXP3PfWrpY7 sG727sbu6xyCJ+WiuwwUH8nsGs7EN44OyEl01ZWtN02XdGPKHO1znRiJHt1d5AEembDkedkq55Cf 0lKSEFYycoNvvM+ygznjwywRWVMWX1uJQsOOn0PvgujPIS12Tthj2dg4QDjgIAVI/nsfAuPEfWg0 6mp19SBSCFUtDLZ7CGx3NVJQAOI70sIgOIfhhNjhBgUCkDFLtwyzGtKFdJhaTI04aOFyUrD/b65W n/eVxa5iaqwGfwvxVOkVGF6I+/su0JzQEpaSn7UWBo4AdniHcF8QA3vmOQlo6Xf/Rgvz2tkaw46m q4pX1db8XVSg6XRgo9/0W6fbZlL4xIg0ldRqRjHYLrW55WKSU2AP58oc14amZOFBjA3fh/WK6oDu xb7GZKv0J3IeopOGBNktVHzs6AHd+LKhoZPA7EP7VCv5xwWKVpElV4nG48oPBhs7XLsrVfYblJ8t 73jtOHfryt2YiYe8GR9Pzqq0rbHBYnUVJw03wjE8BzFQgwtxzPdG5eOT5ysTxDXYuFzTwxJ+H8d/ S2T8Go6Q7uJwdPwPF1WHVOcXVfirRVlj5OC/DMnL1koW3W0+kfvEzbxCXWLqrmWSFObWmp6JFtQV WGEf0hGqSPlmdR3n3MY9zcQqv7d3kCU+l+nqu6npd+9Ddw6BfBibzFthK+Mc7aXtxpa0bjbMqsc2 NpuOO1uS4JzNOdkPTY/IETabcD/oqV9W127/hm5YbpOzqhCMHMsuPKQ9mzng4suWudavtzq1ZrbZ fdpokINp9o6+NTBXeawiSUDp/ZEX7Mw46/SojZx8kHSTQIbf5BunEkyBUdplpaEjYsX6vbZBm9q0 z5YHeUqXpa6qXDsY8S4gclpsQOFC6Yc026tGq1KuRRTOPrEpWkmLMRnWk8n2FRvYVinv8xyINRWI j/VbCMkmiH7vfxmSvD9CEgUBkOZ8MK6ClCElpgJTPk7uz4KRFhKiSiIi4SeGhB9rin8Tgew1/1EE av0+AllPOX4XtdPKBsTteBXRyIDqvl2XSK06Btypammp/7Tk+dy0ZY2mByR4d4KGfXL8pdsZnPCl 6HW3rFv2DsYu3XteMdlb2Hym6dopY3Tz6a072A7syQ8ax1pj5dXGKIf85SYrm8RS3vPSanzCO96l ecTXhhydSqRFLi/KORV18tLkkZU7LdVCsRbGnR/L+XB27eHMkwwS5RvXw6SPoZVcpzumBe0V0oka tyJRF6PibmXfOSC3atcj7bCbx0Ocp68PbBblXt7c9/iJltoGI1F9fvdI+fpcrw+pD6nvDAY/8cW8 eBSdE7aTUntmy3pIW/ZSdqmkh75Kx+FCZY6o5+JlzlH/OpsbNKufeAFiYIRgCPgyDwH8QC1wQF8/ QfCRwWfScI/RYothYASgfo9tHmE50yBqRDDF24eGUyKtxOH19Ag4SwopOCgkyIuGMw0KpqrhZSCp +S+L/nYkKHg+V8tCy+Yfk/jPcZugIBrOOJTmExRMoUWw4EGPAOHxEERYgAcNCK+hiV/o/gM7+stU jqqqpQ6sGbPCKmWe3OUKvc0uOLTCbWo2ZXPO1dmz2TiD6K3Zp7OPuGv4PTLxjBgpDmu06xx7dyZO 6kjmPq+yu36RHsvbpfVf8oPHh1LrqlW90tN9FNJaV6+q5i13Uqg1H+Q20E1dVaCklz+8Ya9J7z7+ ynR/e2IxIzrLXTV885u0K55r0q2l8JzyIpkFg8dUxAfWniKJuDuxkTOlCTbxk+c/nEDVY9uq7deV JcZWrx62O2FV8u18ZADNqlS8OZVLSRZwPOpOIVRuEuLQd5jbMXPOi5sz7zHdwfFDxRpXMXo4pvPz rZLYlNmLLXvaz0sGO+s33fzImSMHlbHvbyzDhQvv71nAjXyIngvRs1lxCWLo6RD9ZKzAjlbqB0pw xvKtMSKXLQ/P3c8K/v9/foy/8HEEFVKGeGoOjZ8U135/DZR/Hi447uyukZnBc9+A7VjCkcbVA7Jj Hx2TV5Uz1zd4fPj6rHnNmu0FOnaUWfkAw8bmwpds0d34Q2szBai+lbNCW8QpNV9bTXsFt+O2vPWI Ki2UaFAhrFC9Rc4SSlrBT8qZtJOalm1sFx23KQ401eD4xlg61e/tz7f1c9Wozb2qwTroKw7PlSCd slLS8qk0Knc09hX6yo5Pl7obHEfIG+7Z2FVcQSsJzR1t/8h5JObaybtFhFV9kX354b1hTKDV17D2 sU7SK2OhfG1frG+X9usnUpi+/HWYhu2auoGWUnweV7mzD7Y9tTM0b5Gyz6N2Ca2OTw7NPP+YCaPC Hbg4KF0oDHx50rbUANJFgp11qCwvxRvfSYL0PwUJkA5cL2jhCVpaeC1WAQ9DvIbOd0ig5/22ZBCG BOfpBrcjMcQHLgVo8DoCSAqByQaHDdkzICjQ8/vOuP9sZ392mxrwor/c5nJIdv42JBePeJKR4oNV jVgjpAD3K5LwsZCEE0GSO824Qzd75gysRyJvP5Ff8Tnsgexci7KDVdOZq4zL2hGqQF0+51NS49Xc z29qa9svHUzN5vjCX8GwSX/HqK8SuJtfM+K377AtttL6iyeYWCv2hOEDGO0ymxDStZohbX31Ze31 fsKlHhLH8jU7jbTWf/IrMZ9QDJGRu28iIbO1wia9LadVuF7CcCd7wFiKrJmbyfuaxjRP3LVara/Z ZgNRl6XVr+W9/JTVc1qWf9YJb2yvG1PqNNg3vC1iRdGksrqgoe4uA5M95336YuR8lg5sPF63y8xm fdaWfYnJp2u8o95yzcShd39O26mvct7rVHOP6r9UUJL8WhbkCX2h0tF4KWkFm6Bm2PfQOQxQGbaH wh/V4ej/DngRYudaIOCiML6g0GgAg1BU6SUYMYzIiimVTS4NwXYX+j8zlZeKzdRO29IhiR+XiKAw vDLcgC0QCtN1U8AY4kEKH4R3mEP8PwosNggNN4viEoExUu+rcbZrF9/y8Gg9YuANEj3WPeU8P00k N6ihv+haGD8sH1Pc29Z718E2v1ziQfPAKHPaocLixHr5/oJlLyKffBaLFOoaP4od5nQp23/0+kGn SqnmlLaUE5qfjr2cSzjtummDtZ7CahzWjvB1t7No8p0XUoc/Em30+znee32IGD7ywJFEThHfwIzs IV/tUSiZbRCqqM9urnc7QB1v6ipiBHK8IEtcz/8cd5vL5NSoQjEl8lKtyvmLXstyS+M5/U4KX7uo kybDliOsm1NTDBnckH0G5TV5CEmVOh7qH40UvOGqz0sYTa49nmCF2c7mfO9he0HH693HdinOXAnM PcKu6XTJVVmQH2KwacJQhp2HMW6iecZ95LiF/MsJxX8LZPzEPj0tTS0dFlsiwLUR3NVmdSHa33If C+PoPxn/y5KohZ6qW+KcPVbb87K1KOVQu/7ZZQfuuMSpuXy8FDxRVJzgW955SS6Kp6Ehd9MxVznh N9MTy8+WfwoMK/kwck7/Xl3NNmfDorIQTYU8DzoxIsvjU2BCSmtg973Mx+e2CoYRb1CTyFmpYonn XeitZl79XQ4ZRk1fX4TJq5lBQH/77qgUwadO0jlDW3gaE15kt9um+TeRmtJ804+7brYUHFJv27HD 1c0mJ0Q1t3LfOr6DEqJh9zk70/OookOWw5RvLpf9jrxfuZWge6DefIPoCetTFz/5nHv2kmunNy0j /KD0fr+Tbwfd1jW/GtjJ94gEJEfhTx3muSJcVdY6MtojO1LgThwhmK69M18SMcDjsEUO/8JdfoLB SIdfQahty5YRrJUEu0zOmaKHJ779CfIVsLTLMfQsiJ4R+4cokkU790/g36/FwqZ54mcGmUBGTAOm ftzqRcQv4Ps8CPOj+lFYWnVqcJBnKIkWos4KAJb/w76vgRDCLYuYqClkDBn+YKKoOM2FecPDw/9o XnLwrxPS/ogT6nZ8SNE97XxKxMUukNKDahgsm2m7bXlBvWiPHV+nRsWU7wDfjKxkuEGuT+SVlJgk 5zHTur2nybsTrLdGM0Qm9oY8y77l3ISiPlDwX3rTRiQ3seZqX1ZzVujZYzvXYmscAIfyqX0Kna6a M+0rIl3TO/NmPo0ZSxbbm1+weHFMV9iJa8PoOD5+2U3M4R1CZPQbnq2tWbxJaVUdtfmtnKIrZMsr HBOlHu2I085t+lYYP1xAMLxq6teLG113M6bkzaj95SyLm+RbtlodjUPsJAz7rkDrOYvK029Nt8d3 XeCOndh2d1Vf/54dG/s1Ikbk9h/nVS2z3lF/28jJqehxS696bctwQCYhAs/ANMKweRcFghC9/L8G HH8D8D+PsZn0AUjkR0JVAvEcaDbkh6esNLvw6LnQeN7FJ+fw1n/2ePBLoMWjotDynxdi8HDcNoMT 3Tabqw1jZI101NdUmO++OE6GqIsu4cV7QO5MnVgtOIcTAX+AAmfzYFjiAHMgCAgEaEAI/NkBIMPa EFjP0uEAPKAGQIBGlkKs/J96Ni2CGuQdTKT6RPy+lsQwQCAvy+KusiYkaH2ndLubmxJ9blvF1LOG pFK3lrYrMw5hXuAB3LSKy8liT13aepKV756JwHemU8kVuw/TIGqHIary+e1OMVyz5cAl2dWiX1Jk JXu5jBO7Hhvet7Daxy5SFTewn2Ze6C7iJXfB36dea+mITP9X6lqJNRfq6vtib1oPHnk9ZduyZ+rx 22OhuT5Oerf7UwR4cqr1uleCLzvmXriKLIEUkwzM4tSfWyV2S84OSdYfuH59gtA6/uXjPkNe9spC knC4ir2p4LnuECsttNZx6rPCm0qd6IFy6dqbYpNrDRplxJOeNxlV9525MSZGWFdepRT40Zlgsq1T ruOgCHB7tGz91SwGXBQxwJmfz4sdzwCHYdUQy7m9/5YjzT84SOVl55zfAArGGOY2SHyx5/H8/McO CDvejxE2PD+S7fXweLweXkNLezuMvoscTwgjkCaRskyz/vJkxolWg83v7E79gQuIbzTVuItNUYxf edVE1DXeetm63OS9oX23crLCze/a7NyU3XJUMSk3etyuSOGp9x5v/unXnyWMLF60z2QWP92vEMtj U+LydCrPLvGpkV16kUAt12XH5s6x0vuFjf57o6JvQA23E19iLR6UbKbvG6Id6nJSSD1K9y0gZnRL 7539ai8gkqe9VsdM6ZrpvUc8Z1Y/1BqDVMOlpczrHsq2eK2BJE3SD5cMLX8zTNyQEs/4Ni4+HjDl oHttYIVTQF8Dnufsmmq7Gc62w/cu2irPeB/T2RT/6lolOmPIMkRc2vsmZ1RV1RXnDmlNScGzBW/b j81MqcwpOch90Ffw9nrh9S6ltJUg/+1iFQD8Dwb8YGcNCmVuZHN0cmVhbQ0KZW5kb2JqDQo2MCAw IG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAyMjY+Pg0Kc3RyZWFtDQp4nF2QwWrD MAyG734KHdtDcZrLdgiB0TLIYd1YtgdwbCUzLLJRnEPefrIXOpjABvn/P/Fb+tJdO/IJ9BsH22OC 0ZNjXMLKFmHAyZM6V+C8TXtXbjubqLTA/bYknDsag2oa0O8iLok3ODy5MOBR6Vd2yJ4mOHxeeun7 NcZvnJESVKptweEog15MvJkZQRfs1DnRfdpOwvw5PraIUJf+/BvGBodLNBbZ0ISqqaRaaJ6lWoXk /uk7NYz2y3B2Pz6Iu67qurj398zl791D2ZVZ8pQdlCA5gie8rymGmKl8fgAH/G8nDQplbmRzdHJl YW0NCmVuZG9iag0KNjEgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMTU1MjYv TGVuZ3RoMSA3OTQ0ND4+DQpzdHJlYW0NCnic7F0LYFTF1T5z7+5m8yJLgBBIIDeERMmbAAYCwoY8 ECPPBEwoSjabTbKSZOPuhhDrI7b1Fd9WqdJWrFpFrboJSANqob6qKOL7VRXEF7Yi2L9qfeX+38y9 eYlW078h8c89w3xz7syZmTNnzj1zb3ZJiBFRFMBE5fnFCxdMPvHz94nFvEI0/uwF+QWFpyec5iU2 shJSty0oXjH/xSNvPEUsMowo+M6Ti0sK65LdFsh3oH3iKSXFJ22Vgq4hik4lslyxpDgjK2z/+DuI 2EG0r1yad0rJ1z+dm4fx0E4nrMxfVLr0mjM+QdcHiEZe66xzNIy5NyaUaM969LnGuc6vbEh+bh3R /rMxXmZVQ3XdU81lG4n2Yn5LfbXD10DRFIzxYjGerbq2uSo1KOh4ovf+QCQl1VTWrT/4xl1ziTKX Ev32+BqXo/Lp65Ouxti1fP4aVEROs+3H9a24nlxT51+fFkQ70ddONOZvtR6n49y8c/YQHXyBKDyq zrG+IZRC50D+ccgr9Y46165/uGYTffIhUUx4g8fnV5NpAzHbV7y9wetqWN75yAdEL0L/EJW4rWUi X83ZY9dEzPnEGmMlTje/fVwyL7e/uPXTL+79utpGVqyPr4s0Qhk0t3Mx5dnoi3s7k2zU3aKTaS2v sbRSGEmiQiIbZdBKtIRjXjGGfDG7isxE5o3mabiM0Ur5WaqSIq1mKdRikjiZiM66qEUbVqi3yFPv ITvFH8wxP9+5jE0Lmsva7cRUVYxr0VWRZlFXGSCDDAJJe6husHUwyCCDDDLIIIMMMqgvsc3qjsHW 4YeSOebHo6tBBhlk0GASI3WHFdlGRtw0yCCD/q9kaQ1ijO4abDX4j50NMugYEPt+kf9A1KDvIcYM axr0/SSTzDiZZZlJ8Jlo84ehu+hfVpWsZFU7KZiC1a8phEKAoRQKDKMwYDiFA0cIjKARQBtFAEcC v6JIGgkcRZHA0TQKOAb4JUXRaOBYGgOMBn5B42gs+PE0DnwMjQfGCpxAMcCJFKt+TnECFZoAjKc4 4CRSgAnAf9Fkigcm0iRgEvAzOo4SgMfTZOAUSgImC0yh49RPKZWOB6YJTKdkYAalADMpDTgV+All UTpwGmUAp1Om+k+aIfAEmgrMpmnAmTRd/R+aJTCHZgBnC5xDJwBPpGzgXJoJnEez1H+QnXKAuTQb OJ/mAPOAH1M+nQgsoLnAQpqnHqEFZAeeRLnAhTQfeLLAIsoDnkL5wEVUqB6mxQKX0ALgUjoJuIwW qh/RcoHFdDKwhIrUQ7SCFgFXCjyVFgNLaYn6IZXRUuAq4CH6CS0Dv5qKgadRCfB0gWtohfp3KqeV QAedCqwA/o2cVAaspFVAF/0EWEWr1Q+oWmANnQZ00+nqQTqDysGvFVhLDmAdVaC+npxAj8AGqlTf pzPJBfRSNdAn0E816nvUSG7gOjoD2AR8l9bTWmAz1QHPonrgTwWeTR7gOdQAPJfOVN+h8wS2kA94 PvmBP6NG9W36Oa0D/kLgBdSkHqALaT3wImoGXkxnAS+hn6pvUSudDbyUzkHNZcC36HI6F3gFnQe8 ks4HXgXcT1fTz4DX0M+Bv6RfqPvoWoHX0QXADXQR8Fd0MVqvB+6jG+gS4EZqVd+kX9OlwN/QZcDf CryRrgBuoiuBN9FVwN8B36Cb6WrgLXQN8Fb6JfD3dK36Ot1G16l/pdtpA3Az/Qp4h8A76XrgXXQD 8A/0a+DdAu+h3wDvpd8CA3QjsA34GrXTJuAWugm4lW5WX6X76Bb1Fdom8I90K7CDfg/cTrcBdwi8 nzYDH6A71JfpQboT+CeBO+ku4C76A/DPdDfwIboH+DDdq75Ej1AA+Ci1qS/SYwL/Qu3Ax2mL+gI9 QVuBu+k+4JO0DfgU/RG4hzqAT9N24F6Bz9AO4LP0APA5elB9np4HPkcv0J+AL9JO4Eu0S32WXhb4 Cj0EfJUeBr5GjwD/KvB1ehT4Bj0GfJP+oj5D+wTupyfUvfQW7QYeoCeBbwt8h54Cvkt7gO/R08D3 6Rn1aToo8AN6Fvg3ek7dQ3+n54EfCjxELwA/opfUp+gwvQw8IvBjegX4D3oV+D/0GvCfAj+h19Un 6VN6A/gZvQn8F3A3fU77gF/QfuCX9BbwK4Ff09vqE9RJ7wBVehdoxPSBj+kf/8hj+t9/cEz/4Dti +gdHxfSD3xHT3z8qpr/3A2L6O90x3dsnpr/9HTH9bRHT3z4qph8QMf1Ar5h+QMT0AyKmH+gV0986 KqbvFzF9v4jp+3+EMf3VQYrpLxgx3YjpP7qY/mN/Tv/xxvTvek43YroR0789pj/+/yCmEyIuWS4L jbKSrH8ZfVDJNNgKGDQ8qB++HjRwWgw7YqFRg62CQUObwqKD+QcFg62GcRYZdIyoH2eRdeC0GHYk hUUPtgoGDW0KHx+CY2AInEXmwVbAoOFB/fB14yz675EUPn6wVTBoaFPExFCcRUPgIBgCKhg0HKgf Z1HIwGkx7EiKmDjYKhg0tMmmhA2Ns8j4nyUGHRMyzqJBIcmmDLYKBg1tGjkpHCeRcRYZNFyoHx9M hg6cFsOOpJGTBlsFg4Y2jUoagZNoCBwExneWDDom1I+zKGzgtBh2JI1KGmwVDBraNCbZhpPIOIsM Gi7Uj7MofOC0GHYkj0kebBUMGtoUnRmJY2AIfGFoCKhg0HCgfvw8OmLgtBh2JEdnDrYKBg1tijlh NP81BoOtBv+LUQYZdAyoHz8DGDlwWgw7kmNOGGwVDBraNCEnCifREDgIjO8sGXRMqB9n0aiB02LY kWlCzmCrYNDQJsXO/zjvEPjC0BBQwaDhQP34YHL0wGkx7Mik2AdbBYOGNsXPHzc0ziLjO0sGHRPq x1k0ZuC0GHZkip8/2CoYNLQp8eRYChkKZ5HxnSWDjgn147NR4zeo/ffInHjyYKtg0NCm5BIFryQj BlsN4ztLBh0j6sdnozEDp8WwI3NyyWCrYNDQpvTVCXglGQJnkW2wFTBoeFA/viQzYeC0GHZkSV89 2CoYNLQpqzIJJ5FtsNUgihxsBQwaHtSPs0gZMCWGH1myKgdbBYOGNp1QO4UihsJ/pDC+P2vQMaF+ fDZq/Aa1/x4FnVA72CoYNLQpx5+Kt6IhcBAY35816JhQP76wmThwWgw7CsrxD7YKBg1tyrswCyfR EPjzv2MHWwGDhgf147PRlIHTYtiRNe/CwVbBoKFNRRtm0pihcBAYf/XRoGNCth8umjlQOgxDCi7a MNgqGDS0qfi2uTiJxg22GsZ3lgw6RtSPz0ZnDJwWw45Cim8bbBUMGtq0uqMAryRD4KVEGWwFDBoe 1I/PRmcPnBbDjsJWdwy2CgYNbap8vIhikQadEgZbAYOGB/XjF/vYB0yJ4UfhlY8PtgoGDXmS9RxL TFyX4AocW0Ummkn8P2RYSUKKt9iVSQdzVBV13bz69leB/a7xb+l9dWIW6q5gEkD6xpy8sR9/1GzA 6KIBHPs/tp49b0VJrn3e3BPnzM6ZNTN7xvRpWVMzM9LTUlOSpxx/XFLi5IRJ8UrcxAmxMePHRY+N GjN6VORIW8SI8LDQkGBrkMVskiVGqQUJheVKIKk8YEpKOOmkNH6d4ECFo1dFeUBBVWFfmYBSLsSU vpJ2SFZ9Q9KuSdq7JZlNmUNz0lKVggQlsCc/Qelgq5aVgr88P6FMCRwS/CLBXyX4cPDx8eigFETX 5CsBVq4UBArX1bQWlOdjuLbQkLyEPFdIWiq1hYSCDQUXGJvQ0MbGzmWCkcYW5LRJZA2HUoHxCfkF gXEJ+VyDgJxY4KgMLF1WWpAfEx9flpYaYHnOhIoAJcwPRKQIEcoT0wQseYEgMY3i5quhS5W21F2t l3XYqKI8JawyodKxujQgO8r4HCNTMG9+YOxZ70T3XGLwyLzSi3q3xsitBdFuhV+2tl6kBG5aVtq7 NZ5jWRnGQF8psbC8tRBTXwYjFhUrmE26oKw0wC7AlApfCV+Vtj5XQgGvKT9DCQQnzE+oaT2jHFsz vjVAy5vj28ePt29X99P4AqW1pDQhPjAvJqHMkR/bNppalzdvGWdXxvVtSUtts43UDNs2IkJnwsJ7 M67uNsEJcc4VLe+2LOMaJSyEQwQUpwJNShOwppkcXDOp1TkTYqAyhl6BSuyIOxCcV95qy+H1vH/A nGhLUFo/IXhAwqEP+9Y49BpLou0T4iz3k25XQ3sXH0hJCSQncxcJysOeQse54npGWuq6DikhocGm oID5aCls6yjLyYD54+P5Bl/aYacKXARalpVq1wpVxLSTPSOlLCCV85ZdXS1jVvCWlq6W7u7lCfDk reJmHhOwJnX/i7BFjSqoyQmwqH/T7NLai4oTipatKlUKWst12xaV9LnS2md2t+lcYFReqRwj6ZwU I4tWOOXqbmF+URoWMCXin0U4dWVHkBVeKWqYUhiwlZ+kYVlIfPwP7NShHuG9RNHTTVczkJPS93p2 n+s+6oW1ylDYlCQVlaxqbQ3p0wZX0yZcqBfweCopjVfyArQCd2Yi/nWou2byXBYTsMNkeVwA/qdV 6Zd9BGN0vgzEvTMttRCBrrW1MEEpbC1vdXSoLRUJii2hdbv0kPRQa0NBeZfjdKg7Lo0JFF5WBlvV sBzcFBLNb0tgFy9rs7OLi1eVbrcRKReXlLZLTMorn1/WNhltpdsVBHdRK/FaXskvFH5BRQyLbJes Qj5mu52oRbSaRIW4dnYwEnXWrjpGzg5Jq7N11UmoM2l1dlHHiceYvJLS3t4jbsmyNKK2kojcSfJY OoysIssUB8xAXoK8BvlK5E3IForQazzI5yHvRD4iWuzy2PZrptk7UFwqii1n1GaJS4d2ufo0cbnl 1DKtXLRMK/MXamI5mtjU6Vp1+nytPC5VKyMTs1p4GRKetSs3So6iZ5AlagAy6RGKYIzi6CZ5DAWQ Jdmi19jlyC2Tk7I27ZRNxGRJZlRJceoumbWHj8zKDZFU6TBFUpz0kXRIa5EObRkxMmtT7snSAboX eSeyLB1Aekt6i86T9sPoNuA85E3IO5H3Ih9Gtkj7kfYhvSm9SRHSG5SBPA95DfIm5J3Ih5GDpDeA Nul1Hg4Ecn4esiS9DrRJf8Wy/gqMkF4D95r0GlR7vj17VtZ2waRk6Excos6MjdGZyKisDum59s+n xHVIb29RUuJuys2UXqAAMp7DgDZkBXkpcjlyA7IF3EvgXqIW5KuQb0IOIONZDmhDVqTdyE8hv0SZ yHbkpchW6Zl2TNMh7W1Pmh+XGyU9Lf2FxsKoe6THRfmU9Jgon5QeFeUTKCei3C091j4xjnJD0U7o Y0NpQ5mBdrP05y2TI+PU3JHSTpgnDpiBPA95CfIa5CuRLdJOaVJ7ZVwkBrmfdlsJku30gShvo5ut ZD8jzp6UBx9TOCTlnAgOsEnZlCTZkzbcgEsOSVdcA45D0i8uA8ch6azzwXFIql0HjkNS5RngOCSt WgOOQ9KSEnCADunGP04+Li57yVqm5EZITbBSE6zUBCs1kUlq4ok+N3Hdft2enAyLbbSnTEmOa9nB Wh5gLctZy82sxcVazmUt57OWOazldNaSwlpiWctE1mJnLfezmTBFC7Nv7XM5yx7NWnazlrtZi4+1 JLGWRNYymbUoLNveIcW3L5wmigJRbMnl9xXKE+dmRUDHeFg0Hm4dj9t+J3Avsiqu7BBSJmnC4yby ctKW5HnadXpOlif3JOlhdHwY2/Aw7UM2YYMehhs9jEEexgARwHnIa5B3IR9GVpEtkJ4Exa8UGAHM QJ6HvAb5POTDyBahzmFkiTy6ivcKxTJ0pZfwK+lhpElI8VK8fYIt1pZiO0m+MpZFTGRLJqoTpWyK 4t/MjhxpHdnBwrd9Fv6vz8IpODdYukK6kiZgI67SyyvbP58Q18Gub0+6Py53DPsVTTTB69gsSmKJ KGeST1zPoFgrL6dTrHQXyqz22JXoFtGelBq3g43gvbbFfR77TtwHsR0S2IOx98e9rHSYWHvci6i5 a1vcC7GXxD2R0WFFzQNJHQzFDkWIbo+dGXf3biF6Pho2tsedy4ttcefELohbGysaXFrD6T5c2SPi lietijsJ4+XHVsTZfRhzW9y82NPj5mhSM3ifbXGZUCFFY5Oh7JRYMWnCRDHgiuwOVmNPDdoQVBq0 JOiEoKyg1KD4oLigCUExQaOtkVabdYQ1zBpitVotVpNVspJ1dIe6357C3+FGW2y8sJg4mgRvkzjy 1z0e15hVopMpMEoukoqK57OiwC4nFVUogU+LEzpYCM5/c8J8FogsoqKS+YGZKUUdQeryQHZKUSBo 6U9K2xi7ogy1AelinHslpR1M5VUXxPAn7e3E2MgLLo/h5fEXXF5WRtFR6+ZFz4ucO3JWYf63QLmO KT0U3YefENhQVFwauHNCWSCLM+qEsqLAL/mj+Hb2D3akIH87+5gXZaXb5bnsHwXLeb08N7+srKiD rRRypLCPIQeP+VjIWSeSwuVIsU7U5DZqconoD7nJvIBccDAlCrnE4GAhZ2Jcrs03uSC/bfJkITNW IZ+Q8Y1VesvsToRMYqKQiWqh3UJmd1QLlwnMFSKxsRCZGCtE2HiKFSKxbLwQWdkjkqGLXNItcomY SWY9MrGaTPj+Lpnw/ZBJ+aHkmp+SwrbMLnOu5q8x5QkFLuTywKXraqIDLRWK0uYs099vksornDW8 dLgCZQmu/IAzIV9pm736W5pX8+bZCflttLqgpLRttd2V3z7bPrsgwZFftmXB0unZfea6pHuu6Uu/ ZbClfLDpfK4F2d/SnM2bF/C5svlc2XyuBfYFYi4SPr60tM1K88vw1CzKLVJoCPy1PCa+bH6UrWGu cN7Z8dHnxuzAA8lmCsVLRBheSMOReVNabloub8I9xZtG8HdVvSn63NnxMTvYZr3JhuqRCfMpxd/o a6ToAne+9s8HQpW/kRtcwxTfdxHaCvDame/zExUFkouLAvPwfNgWFITacr6kQE5XXWhoAZ6Wtcp0 VObwSlnuFuR1c3hdcLAuePT+N+plHr8LWqT7tzD7ROYnX5kcmFhUIiEUlOgvBTvwuMSPB18ZFuhj KczXNYZQmzSe+Hq7sr9R53Q7+PVS64Uuvi5zdBO3Epl30Djk8ebbaZwpif/mX/V95IO87HSrB3k7 L6W/Iax16JloM93N3HQ37aSH2BH0upe201biDzz59Bs6m66li3CIrULNJbQcyYz6a9k4dStl0O9w jP2O9kD2VDqXdlAUi1Y/oPPoAvl59LqAwmkS5dJS8tDl7BS1kVbTPtPPKZtOoXpqYC1qqXqFeo16 K/2etsuPq19TKI0nJ9Ie9SPzK+rrlIYe19ENtI9dE3wf2TFLCyR/S17aKJ9mYmq1+gU0iKcm6GCi RbSH7ZJSMLqL3mfR7Gw5D6PcogbURyAVS6dRDW2kHWwGWyDFm1eri9Q9FIU51mPUG6idtiF10IP0 GgszH1FvVY/QOEqlhVjPVnqa7ZI7vz6/cx7xPx0dTVNoFlo89Cf6Cz3DEtifJY85zJxltpvPUl+g 0TSVVkDb29HzPfaZdC7SefJjpkJ1Po2AXa7m1qZH6S02nmWwJWylNEXySDfKXrJixqlIleSGva/H 6G/CabZJYdJe+RbTXaYvLRM696sjsCNJ9Gv6Lf2ZhWOlCvOxn7GX2NtSnrRG+rV0QL7WdIfpuSAH Vn061dHldBd9xiLZTLaM/YTVsLPZRexqdgPbw55hB6VcqURaKx2Wa+Qz5QdN85GKTT7Tz80Xmi+1 HOws7Xyk89nOz9Qs9UJaBn84H9pfRzdiZdtpL72KtI8OMDMLZSOQFBbPVrCfIp3LLmc3s83sDrYV szzDDrAPcAB9wr7kP0aULFIMHnX4A0+C5MXz5LXSb6S9SM9IH0qfy2PlSXKKPEOeI5fJHmh1kXwV 0n3yW6bxpr0mFXbOMm8wbzJvNt9lfsh8xBIW9DOc6E99dcvXyV+/2UmdF3du6Gzv3Kq+RWOwhzgr 8AY1B9o7kM7Afm+Ax91Lz7Mw2G48S2Zz2SmwzBp2BjuTrYclf8E2st8L3e9hD8BKL7PD0DlcihU6 p0szpPnSEqTTJZd0Jh69rpG2Si9JX8hBcqgcIY+Rk+UF8mmyS/bLzfIGOSA/Jb8hH5A/lb9CUk0h pjjTJFOSKcW0wLTG1Gi60fS+6X3zavOT5nctIZY6y4WWDsvHeIaZG7Q0aFnQaUFXBm0LesFaDu98 mO6jP/b+GSvbL58vF8j30RXSNNM4vLA8DX9eQ5XyIgmeKm1mF0vnsK3SZPN6y2xpNltMR0xJsPVj 0ibpU2m2vIgVsWI6Q5qqjWYZbboTxRzTw3TI9ADW9jRGXm8JY+dKhy1h1I4nolmY81E505QiP0mv yftYkOl39FdTCBvLDkm3y0vhBQ+a5ppLKV7+Dd0jn8nOofukAqKQL62XwY8XszsRF0pYFvuXrOKh dzG8KFt+m35Oa6VX6BDu44vpV6zSVE1X0DR2Nr1Pt+GumGKutyRbxrAnJLepVRrFtpJkugOrm8Um M9k8mn7BTpM3Wg5Lr1Ij7TWF0JvyH6D9XukeeZHpiHk5q8EdcA5dSGeq51OzudT0HKsmma2kRNN+ RLez5SxTPMrzEFVWI6Ztw929A3EgV16Emmh4zinwixWIEBuRrkecMMGD3LjHT0UUe5q2WkqkDqo2 j2CIOkSmJzuX0yr1NrpBraZ69RpKQzy4SD0bI26md+lK2swu6PwpNeDF8VXc26eYC6W95kI1TWqV XpWKpQ199xfWTmTR9Deke3Ax13w/tZpepmKap16mvgjvPh4R9gaqwOPpO1jlR5jhJHkXTetcLLWp hXID1ruPlqm3q3EshGrUWlpCD9Dvg8zkCErBc60IZmb+uUkQUfzI+JGJADwD01eKvOsru5m+JMW0 i3/uEYAmV+IEMVMwndNm4T+EaZfI3CHdaw+1zrGEBOeY5lhyGMt45+t3aN7X782LaYsVrUlolcgS EvqkHJxjnmmaQzMhJ8+RJIUx9mRISOj58b+7Hs+wi23/PG3OItsh2zsY4h3bRzRv3iLb1+/hGXaL GY8YzDbHNqesbGrmKHnktJGyPGPamPez902/ZS+rlYNZQef9X33Wee2ePfyBvY49I9XAP0Mpbjs2 utg+ItjylEKZWEZj2Km3R6fYPj3tEGUcwljTT5iWFTVmtCVhUlLddTXu665z11wnPe2+9lo3eIyl 7oD9N7PnYaHoB0mSDhOT/g57HGkzswwbVopBWPyMeLa5M5J9xBLv0fuYY76/jznmi01mR08fRt/V 592eeahzByvs6WP9AX2s9NkOa68+th/Qx0aHd9i0PpzG6GmtkZCuNpKRjGSk/zfprgFJjxrJSEMw 7aPP2SgjGclIRvpPk3gvKpQXk/atQ6JOgbL4yCiEzdV5iUaY36Subyeebt6l86ZeMmaKNn+k8xYa YZmo80H0iCVV562UFHS2zgdTa/itOh9iekjMzPlQqhiRrvNhVDXiKp0Pt2y1HNH5EbR6xKfd39M7 L2K5zjMyR3ys8xIFRebqvEwZkVk6b+olY6awyIU6b4G8Q+eDqCKyRuetNGqUTeeDqSBqss6HSI6I Z3U+lKZGuXU+jKZFbdT5cHlV5G6dH0HpUXv4tzlNMnQLi/pS8GbwtrGhgrfw+rExgg8S9ccJ3ir4 bMEH63uk8doeaby2Rxqv7ZHGm3rJaHuk8doeaby2Rxqv7ZHGa3uk8doeaby2Rxqv7ZHGa3uk8doe cT6k13pDxVoWCD6sV/0IsfZTBW/jaxlbLfhR4CPHNgp+dC/5MXwcnY/qVT9O9L1I8DFiLm3MCb1k 4nrxk4X8dYJPFvwtgk8TfBvnrb30t/aaK6xXfVjXWkqomRrIRVXkICdKhe5ALqEawS8iD9Uj+3Up hfJw5QXP0YF6t5BQUFOL/ung8kW94/84Uka3ZgoVo6WWGrtlfKhbiFKbbyrNQsqkNJ3LErW56FGL cjn6VEMHv+i1HOP5kL20DlgpdKhHm4vqujXxYl4FUg59Jk3eDQsp6MH78xHrKVXMwlscYianPpYD NVrPOjEiX0ENtK8TI7rR4hfSNWIubnW/PoNPrNAp+vpFe70YhZdcJ4/Qwa2vpUGMzTVyCq18Yjbe wuUrRanp3yhmU8QMvbVyi/H9aK8X101i7Bp9dpcu6xFjaXN31deKsf26RZy40izzTTk/xnQJq7hR amM79ZpGYWm+Vz1e4hH74hUWrRX9uabcO+r0Xl0zOEX/dfqsbn2lvE2zZo8VqiDJR9Nqe+zq1q3r 0VfiFvKN4qpnV33CY2uFdt/uE113jq97LbytTozXM4YX86zVtXXo9ncKn1Z0v++yWaWYu1rUav2b 0OLW95DL1GLvNR/xAKvRtk63tjZCz73sEHuleYcibOjU1+8Wu1YrZBrEfaZ5Y73oqa2kt3e7uz1L Qft6fWfqhDbcN7V98+l3cm23HnXiqsd7/d+IN75vrM+pz1EhRmgUlq7s45suOhP1XZZtFJ9cdq2w Svi2InxgvbCtT/idX+xGdfeuc921+53fS6ndd5NP97KeeKS11okdcdBZor+mNR/XKVp7PE2bvVJY q0HcJc3dq+iam/dvEu0OYQmvPge/hzQr+kX/Lo27Rm8QPlQnYmiXbulHxdWcPrvG41218H++uzm0 Up+vK9ZOwwiZSAodj5H4HnjF/aDdR1N6jbUIft1zdY/wc69+39eJ0dd27/F/GvO1fanWI6FLj289 cUobdQXOA4WWiv4KJYn5FgGXYO4q4bldFuO+6RPWrtFHS6fFkCvB6VGInIcVcX4Jann/QuApor4A NcVAfg8sgBULkBaJ2hIKpxCRS4TX+r7Fp5Xuek1jbeca9L3tuReOto925nlgA6/wjhoh3bWersjf 5U8VorUZ8o3dczq7Y6hmu0bRtyf2ufS7g0eonnitxQm3Hpt9euyoFqO4umMvt22ZPhuPIuv0mF3R feppc/r/jWW6fKupOwq69Dvb1X3veEWc8utxo0r3+2+zV9fdzi3m6jVKT7Q4er5K3b+4L1eICKxp XaHvTL0+8rft0HFiVX0tpUX+o73i6Jm7YiiPlg7xROPArLW6tX16rPquudOF79f3iufNR+2FS3+a 6X3naKeEQ2jUICzLzy23uN++f88V3Rfre8XQrnn53V8pLO3udVp5ez1xpXZLe3v5bc8zwr+3FNeu Tozf5VeePuM1if1fK3azdzTpisM9kh7IanGmUVicj1/TvR5Nr97eXadHbs3+2l3VoPtHT4Tv60P/ bkU9/rFQrP3onet6xuNnm0t/EtRWoz1XOsWu1n9jD7zfsHfPyHx9HhH5K/W4uk48gzVR76e479/9 rvG0e9KlP2v0PZG7xjt6HzVr9TwZO8WYR9/HXTvm+Iatq/qlbY+Vj56h73NFX41c+tOyHydk1wj8 lMlFbRrxs3EmTadsnIcKcCqu0nBmThcnJ3/nXEFFumSm+BbRdCSNz8YJmy16nUAz8G7CMx+9RjyT NGC+DKQmkdLF2d73jneKyPdd5wTn8sXd2dTtF9op6NajLddpuYjQ2hm6WH/O8uhP8Pz+1E5Sr2hx ix0oBvacG9yr+JvVTLxZ9U/vDCFfh7kygH4RIfheZYizZ43wEu15Ir1b8r87Q5N4BtBkXf+VWbra Mr7hj91jlzQ3uKocTpdyh1JS41IWeeo9flQpeR5vg8fr8Ls99UpDrTNdyXf4Hd8jlMEHU4o9tY28 xqcsrEe/qbNmZaYBstKV3NpaZbm7usbvU5a7fC7vOldlnqfe76rjg3ibFZ8DnVDvrlIqXT53dX2q kut1O2oVJ6QcbjTWebwupaaxzlHv9vkVZ43D63D60cHndzt9ir/GUa+grVnxVCluzNLgdVW6nC6f z+P1KY76SsWB8RudNYpbH8pdr/gb611Kk9tfg+4u1HoqeW/O1zowB/o7oExXnb/JVe93uyDtBNPo bU5XhEk861xeB5bn97oc/jo08Q7ORizRxyfzeaqgplChqrG2FqzQFdPXeTCJu76y0ecXS/X5m2td vS3BN8fHZ3F569z1QsLrWYthHdDf2YiJ6oVmlW5HtYe3N9W4scIaV20DLOJRqt3rXEJA7LJDqYU5 lDoXbFfvdkLc0dDgghnrnS5MopnbzY2luNZjMXWu2mYFa/Nhk2v5GHXuWmFev+43Pn0+J3pUuJRG n6tSs6brzEaubKOT21+p8mDJGBGL8vvd9dV86V4X9t3vS+Xb5IPJhB/hss5R7TjLXY+hXX5nqmY0 dK90+xpqHc18Ct673tXka3A0QDWIVEJFv9vHB+biDV5PnUeMlt7lqzna0pa7qhtrHd6clejHvXZa emamcvwit9Pr4Xs0RUgtKhHFZqXEi72vc3jX8hX/O8/HWqrhhC74m/ApiK4oVpY6/EqSUrJIWVJV lS4Uc9X6XE01EEtfvKRkYeHCvNyShUsWK0sKlVMW5hUsLi5QchcsLyhYVLC4JDwkPKSkBlvRZWm+ LXxgLA6r9otd6NYHd56n2utoqGkW83Dn53aqaFaaPY28p5N7KLRrrK8U3gefgEMJv4ZPuOHNEHdU e10u7r3pShm61TjgOp4Kfuuhp7+PMtxaTdwFXdhsF98dr8vph29UwfY9evFt91S7hIhwi+5+2E54 fEWjH0NDTQ/uwl4LOs7XpRScv9sU3Z25hyrrHLWNjgp4pcMHr+rdO11ZUS/8vLlrFViTvjm4JRyK r8HldFe5nUevXIEV64WH8r6Oyko332N4jlcErlRe7RW2FRHhG0rVuuvcfEGYRMg1ebxrfZpjCx8W lZ4m+ExjRa3bV8PnwViauevg3NAfW9XQrGgOr1uo70TCHgurehbHI96ZjS6fmAax0uny1usr8Op6 C2FfjaexthK+us7tatJC3FHL53LYSReiRmVPWOxeI9QSwdjp79ljvjCHrnXVtw8rVO7uoMcKfSDM 4/DncIEVxblKmnL8zOnZU5TsqTPTMqdnZgYHryhCZebUqdOnA7OnZSvZJ8yYNWNWeEiN39+Qk5HR 1NSU/r/tXQk4Vdvb3+esszaOeSoZylim2OdknoeKZIojGhEKJUIDdcs5V6QUKooGU5HSiFIkjSrp KtWtVCpzE1Eo5Ft7k+re2/9+z/M9z//73+/5zn7O2mva71nrXe/7W+961977hHwdeL/QkO91IkBx arjvapIXSAVRoxAlt9BFSEOdEWaFIoDXJpU0PMgvyFfR3ZfSjQg0Yxmxf0JbNzAyZJluSORy35AA 3ZAIb18SJ3TIzP/mBasDlqHcgL+/hEzpjvCRqo2MoVBqGUwaIMspQxctAWnCaDIPRul2yhT4Wu5O GYukSUQaLf4gA5wE58EF9D0LzoHC72j5UobB1/QLinbAD78V8AM1ih5jPIPFmMmwY5ij0BjV9qWW iP4j5kgg7QQtG2CUiUc6YcIp84ykMboPhg1Nwn72TmVAvUVCHKMNDQ2/ncOJfkGZbsyYiGFWj+E5 lB6Zp75+htAHsxz6Yu3m6EYQI6/VoWHf/kaIjo2jt9E7MRr9Pb0PA/RPAGI0wA/4UcgEQiiUABIY AHJADsUnAGUUTgIGKLQDM1H+OvALim8AGzA6iAExKM4FiSi+FXxA8Y9gAMWHGKjlDAYDopCf3CNi CDMQTYYUQxqFjgxnjMZYwgjCaFATX4bR8HA8gWoj+WViFlgORkPT8CLUdyZGc7J2U6Re4MiHQeoR M4DOOJXGMWwkh4Hi/EERocswNhUaBS0PisQsQgL8g7Cpi5GtgDlQoeuyoCW+2OxwdMIWYtjoXh4N +/b42vCOJGN4j4/iGE7e7Us+8IZaJIHWFNNphwATcvj281dS19KoUeIne0KmYMN3uUIYwINxBbCD pIxPwBVxpe9Kj2EcoAQ0gC6YArrBFpACdoE9IBPkgnxQBM6AMiSol0EVqAa/gTrwO6gHDaARtILX 6OiGGlATOkJXyIFecD70gf4wEC6DYTASroHrYA7Mg4fhMXgKFsNSVPM8vAivwhuwBtSh8334CD6F L2AzbIdv4Xv4EX6CgzgNh7gALgwdcWmghMvhS3ED3AxfiC/CF6MWc5A8TAKTAQvogwSQBFJBOtgH ssFBpFIlSJ3Og4vgKrgBasAdcB88Ak/BC9AM2lFb30N1qA0doDN0g7PhXLgQLoKLYTBcDsPhKhgN s+ABeAgWwhOorafhOVgGL8DLsApWw9/gHVgHf4f1sAE2wlb4GnbAbtgL++EQDnA+XBAXxyXxsfg4 xFs93ASfj/vg/n/gsDLQBATQAx9AItgOdoO9IAscAIdAMSgF5aASXAHXwS1QC+6Bh+AJeA6aQBt4 g44PiMNa0AnOgh5wDlwAfWEADIIhcAVcCaPgLzAX5sMj8DgsgiXwLKpZAS/Ba/AmvA3uofMD+Bg+ gy9hC3wF38Eu2AM/wy84HcdxJi6CODwGKOPy+DLcEDfHvXE/fMk/k8M0ZWwbUATqQBvoADYwADwQ C+LAJrAZbAPJYCdIQ5C7H+SAPHAYFIJj4AQ4BU4j6K0Al8A1cBPcBnfBA/AYPAMvQQt4hY53oBN0 gR7QBz6DAapf5tASWkNbOA3awRlwJnSB7tATzoPe0A8ugUthKIyAq+FauAFy4a9wI4yHCXAL3AqT YArcAVPhLpgO98B9MBNmw4OwAB6FJ9GYnUF8KIeV8Aq8Dm/BWngX3oMP4RM8AjbBNvgGdsIPsA8O 4BjOwPlxIVwMl8ClcBlcFh8/rMm4Cq6GT8I1cC18Mq6Ls/ApuD5ujJvilrg1bosvwH3xAMSlbdSo ao2MKxf8CjaCeDS+W9EI7/hujAvAEXAUHP/bsX4LOsB7hLW94BPop/hjBi2gFbSBU+F0aP8vpGA9 jIE8GAvj4Ca4GSbCbTAZboc7YRrcDTPgXrj/fyQnoqOSojDCH2VcFZ+Iq+OauDaugxM4G0mQEZIh C9wKt/m/L0nw+f9L0r9RkhiYACVJNBodWQ6yWBh2CivHrmG12GOsCXuH9aHcMdh4bCKmjbExI2Rp TMUcMFdkywCE+q+Gz/gE8BHZMDzQi8JY8AmFm0A/CrfhazA6tMSjUWiNr0OhLb4JheaUVSCD6Kpi mhiBGWBmoIei0EdR+ExRGKAoRFEU1lIUfqEoJFAUkL2BrydrULENo7GY0Rh3NMYbjf06GosdjW0c iTGRpfAcDqIZh4bmHIhmHQGciTjEN8whzIQ645gIJoU4Re7GaSO7j05/D+xQ2AXsUdgNZqDwA3BA 4Udk/dHp5J1QNHrviOU0bKUJUXYYhkF6J5BDdl0gsuy+WlUjVp3sEmz0H1NlvQme7DxcQDPOPq5X mMZHz+LJOqIsezqNxhIhhHD+4RI6hBjhgzO1cBqDxjOk0xhZboQrof1djnzO+Bh5zIw6XNASIILy jgZQfmEL8iAUf6THEDswraZ8d9Om6Z+PdvRxXvqoZPGkygkenfyq0cUcxt01SuTNkT+4IMJbesGT XEJ4tJ3k/VMEdz9rAqGAAw8GU3LM7IDwIPegJcsVOeErIyIVnQMiySUuaywhTVYQlBT5WkGb8v6x tAnN4QKVb1cGhQQoukf6hoSR6zL3gPBV5MLMLTQ0kqVHsIdrazm7KDrOsLaZ4TiDM0fR2tZ2mitn 2lRtRXU/DWNDxR9/gxg/VtjYkNBnsQnqM3esMFo4sghD9hRynTj3P78D3MzveU5DKwjuVsT3BDqX i9XpKHYGrtOerMOVP4mfyhc8Iy7s+dj94crGG1M0T93rEZin192e/EVAqLZebu7ZmtaeTSf3Vcar vf7FSywieE31CunBa149Gke8FqYxBicvEvfiyt9csfO+spfu/VtSMNbg3M7DxU4O7e9MlY/OTl+v tHdZXKWD3a7g4jyD+wMCk+uKjfeQLxGi/UEkAGqXr4eIxdqq7RLrxcW2Kd+6VySpNa9tapPgmv0H 1nfn84WPfzmn41ZsY8JOx3pn346iA/3TzV31BDPDZvds09ww9naz34WoIL4InROp6ps/vj1ccHdB DfOmmEDS7aLj6mlXojRitz8ZOrfExj4vWazpgm/fXvfmHXciLPsG97nEFnrcGRT38yN4DDrBA0uz AJ1Gp4vxR4fMD120w+XclUHbF1Iy+/6JQoxkls02+lGIDUaFOOtr+5h/at9IzwR/2jNTwni4Apvz 1elHerB8IxVJH0TEiBNiFelIRxdTTojwMF+yoQSLNYlQIy8GkuP/de8JHk35j3LMo4liKJ9J59Fo WGW0b/zrU/nAT05L1vdZzBlphawtyeZlk7bHShm/3nhbYzu+2P4AcNna5pLfeXzhHd1xVSnvS/av TVG63T7U6Nw5cDzVq9Rvcsu2Hg2ZmrBtrpffppVZ1Veotdl4POjZ2IW3bkmXZ3UD0XuOe1U1n8jJ JfG6T3TkOzVK5T9PelAVeMnXqyD8Xh9h7/JIN9RP8VHCTd7aSzPL1a9yA1tbeFaF002yPlka1DiW cWzmRges/RLbVGXHKTxr/iamSrb3yhQu94Zmav+GhSbxyVL1t3RWdnUsbTEv8KmwoR12OTzvkKUy K1NC+lNE9njeFobWq+l0x5CkCa46qTM11+CxkeYpSdp2LEqVcrmlBLeEsML5EaJDyIfEEwkMQXxN E7Q41RHHUKhfRNiPg0Lm6JL+xJURhAAaFAVJpAQYMZWMKjLMCXKcBX3i7GlxfdNoiDShSah/JUyn jZH/V6NNSJJU1BhCBPPrJYCfECQzRRkMQMcr/wIFJne7+Ployzz+qCrqViT0uqh8ycZLKm+Tpgv/ JutU0b0uWpFgywRu2V7GTu/cUWoqjU9aa0HHsQNK22MlmVd3N1t5XoVqbcePiwcXNJtWt6v07NRY YOXRfdB933UDE+MA/oiIA+y7xwsvVEGzoWlvLrc9Vr1z2++YQH7/S7nGQWtmcBpCAQk0i30eRgFR 7CK2xcxsk/gdix6/Nw1WfwSBMJYWoTGsCMq2oWFRlGuUlHJyk8pQcXQXgPLu67DGE/LDlaV/LBnx +7OUiAnDiiHzrZxEAEXrlZGBoeFBkVEjUxOLRRCGI1rNJljsKayR5P9Ci/5OSQvo5y+GtZh2Ocup Z+5as5B4lVOwVc2770uqY+6ZL/tyFC3WzcrZk5Pkw156x8Y/6l3hqhucx12v98bJJ2XGLi66ujR6 kcoDBbNnorTtbWlXLkxenJERODG91kT7glCJ18SL01uZFkZp2gXqxofezPjVpjFWtCxjmYdvIW9d ts/k1Y7t6cX+phmu8ix+VanMgtYULZkW891+Uj5eMCBTwdAtvje/Yyf9mlzdBY9pRQkxF0zecHY6 HxvMjw6JdD4ucytNQF0J80z2CTIsmynBZzZ7aF7/gcVM/ry73NmeHadNF47hrmY87qk4FpP65UTN hgf5suHzzW6Wd/LnKhNF+MYbRYqrJTc2jCjpIYJ7kODmkNJPY3AzCO6uGLF5tWEdQeH7VWatlzrl tG2oOjv83z9+vL+RcUCOYWqbYOXW7l0y+m9LaaoPV4t3z/dhZ+4XrLaAKZuSbpi0KHV1eu7QLsmy u76oY+D3W6amcwsMOEFfVEMsb9w6/Ayue8raap4pFhZc9kXCRSaocqDWtlF8rqLLq0Vrjx8ed13L UG1yRUC2xGY1Ub/cXo78J6UbD6S73QqX27L5Bnlj+5qXLBOe1XP+vVvV+dYrxIAiS2CTQqqGrNN9 BfrB9zHPQfG8DyefXvd8FzCjyo1zuhioSwwlP+jkT1pfuuvqEUPtpuimQ6sbV2VhtcGWF+8abH5u LXFIP1guuF7/xT15RtOhaYzrc6cYLXeSF150hpmTWHefYzm9Rt4jL6xewiR+x8rM/LtZCBVuINvg 5IhtECyY7lKJPTssfu+hVcahipb/CFggEA4gWDD6Otnrs1jIgB1OEtw8liAF8Axcku7hzpIkxMkE vyTT05faNIpEvyNGiJCZfJJ8bgH+IaHL/b+2jPmzlv2sm6Th/KduqhBKw92Q/b7EH837aNIgp31X W2uEGop/RhNhEk34KTTJiZV2fyhIiOilDpnIXerWXRtiqOLUfTexefD44FW63gTVqubsJ5w36+mR dkfq2V5jpGZpGL1ff6o40cSuxNh5OecSS8gkpL+mptp1r9yx/IePHCZallytTkp7OaMr5GF7msUz +FtnnofhUV2fmhhfm+wZHAdRmTMzH+1IJ+barfQvrit7evqI0D6X0ghTGZPDxfGJJzadcHKZ4Cxe MiWmQdjEP3Rqld55hx17yvMUPkEVZx+NpFuaXbEZ6UcP1TPD1j7Qs04+eGZx1Xw5hdwpIns4QNZy d3LprVZzRqStfFKvcUtRoX30Uk2RRTRf41XLBy12882Uek+bPiiNPbd77NIEm2LU6DSQy6OpI36o /tX8Cv4ZECOGC4wsP6Vp1Pu2KXtTQYQxhiGlMf+s3OmaKe/K9s/5pbf5ps4VYT11YtzoBVJ0htB4 JuZO3chmi1l/Z1DQphOilA1Dow0xIAHQ6a/AbJrXywzrDQP7LtivXn0s8VHLuKuexbLni89607On BRvP+XR20t7JTvsHcpqMNhv5K9s0nNXV/O3MA/zma80Lz2U3rqufxW/+QbnuXmXIJq70VG//X/2v FOzU3lyfbOggeqbtnm/SqlUvHqkNqcambmXM5uzMljex4JW/OxifKJ84M8q7ZMbnhewgkwmcoyud GvxbCbN6/xlT+/uvyNusaMkyn/ZuKZZZaHP+nHjR7Kb++zma3IcTnHM8KiYlheXlLJMb4mzmlXNn 5mWfXBxdMDa/Gq+0e51X1M6SdjfXZFwYirB/smWS7YBf2zvV+HkVBnfaWB/ZjxY2REWfIwqD4hz6 E8UvyG3lzCF4UBSBWe8wmDF9+cRtKZeC3vfMIt0G/xjQINGPTeiz9QlCX1/PiES/KQj89NFyh0wS 3Ox/d0fYP1Mj8BNif2tGHU4/b3xIZtIHLXNBR8t1q3Xyq0vuJApfMon8fUfJ86yZlnMW3p7mkhGl 8X7GLVm7dx6X+C0kFPs8ut551z2/mVZOPPvidX0Su3Yjp60zRaysW6tiXDPYIxin0H3COLF0UFDB LGJioafWTY0c6WSe9MvVuVZuYMu+S2HnJrTr9XTrb3f2+LXvMXFa8ZknXjLXBn82p7qrIe+8tN2K cWoqd6tD94yLagie934VjNIYuDz7ZtJU/o0em6uvi06f6VGdmLbaIb6twBqvGhJuD/T0C78c5Fls +xvbhHgi137fdqJm1JfUeuUlqjd0a/UaW/pnzYgrNatV837wZj/wjS8ItKrqewlafoPDZhSPZoU4 YkYNlYIoqefDC4m/hMJvmLL0+rVZip3FunVZp49tWDjxVGm8mwbBLSDLVRjcbLSYj/lL3MmOPPC/ gZd/NjAcyKZOYNgS1oRllnmWaZzxyJLOL3yZTshXOtTKK2xpEJmrGxYe6r/SLzJCl1QXUluQpuig gj9oOQWJ+iqDkpyB9iedT4Wkoj/nF90ezDe5fq65tQf0u9fnpxdk7THYC17z7OSVzktVty6xEqga k0L3uG1rU1wjt+BEN5thLtGskM+Xn5S7fprHKrm01JSgzqdG3fYJHWFWZ+pLPGIqwRWd0+pPmDyR KtvGaPsFpXjCdqtly68+6cvoEKxQYibqmpS8zb+9Ij5Q5UVRk8wvpXa0g1pXvKpPJSzzHqzTvhJa qnJKeMisS3xaZJcAni7zNLQyjiYjoaA15vjsjoAp2a+WOH+YyTvSLvqE9rnBZ8NiuwXV2mG31jo/ wkuXJwp9WTTe5tOOdTlHmPtrVcSOOa2dlBI6sSLwc55lpsrr6/vK4lkUJEJBOlrhorX0PwX4fgDv H1y0WdwnhNTonKlOY/EBSG3JkzPpyOgLAJbQ945h1PpvKUHKifwtLY2kdvRCBkuCITaXj3G0bt67 GYR11v2HFXG1RPB31YVY84m5WUSMzg9P40wfuetY8WfP4WRPjFH9/iaWHwQ78tsdaX9ASgaPhjkb jn0pa5g+Z5LgjV2ar12f+9IfqMTZ7+vceT5dweeipt3xM0lzjGD3gV93pa59z1Dld78VcrOqapxV ipZLVfmuY/Imj9etvsdduW2+slk6n9vmL40nlrSKjP/wVidyx/TNEmmO9oLCQ96XN5u+KmuYx8+c P5Qr5NQ+y45Tzruv2sx9df7imZOXmFHhaf5HuxbzPn/E4uQ77h/MU0mVNFc6nNF9yrHd7IVr2q6N va7pv2+Sttyd4iVh85gTHbvnANtgauWR3tz9/NJjBwI9stzNvN5e0/yQ8UsNYZMYB/G715rlMjo+ smvrEhrKM1duvb0napHWZyktyaID4/kPeFomzvncf/XzibqBbB7dkeDR7b+NEs7i0Y1Rlj4l1UX/ 8R7Lv/C5/ijTcwiZ74VX8NvuBw3J7mgJZImS9gCLYBmxWSzDKXpz/yS7QkH9sgv1A6WSUyJUVj6N 8f4Lecpbqmb6knP3eG+rYVKKy++Yp7hBVi6n7bCANPPkS1HGGqPa9opnTMtE690ntL1MZ3+stZ1a 90x+4uHo1g6NZ+M3WYUGJ9s0SKyVOHluhdSh1/m5IgkR7SCmOO2yWHNL45RVex63rg95YyTNujj4 Rik4gTPgWvdl0VYjuLhzjVEjd8LSbVra7JTSh0N8zNgExzTLkIf7NvqaTky3KIvYlc08tb9AxyhX xLvIvb0+E+TJKxxxsPMTkc5Ipg8qfnSt3am8RmBj5B6njtfKVoWlx1YuKKzcZvKp94zevPkv9nzu uKKq57Awtf9FpHyGc+GqYxvG4DZdH1c4nbvXpdcrc3/3VNcuv/7wmdh/Ac+20GANCmVuZHN0cmVh bQ0KZW5kb2JqDQo2MiAwIG9iag0KWyA0WyAyNzhdICAxMzVbIDM1MF0gXSANCmVuZG9iag0KNjMg MCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMjM1Pj4NCnN0cmVhbQ0KeJxdkN1q wzAMhe/9FLrsLopdlw0GIVA6BrnYD8v2AI6tZIbFNopzkbef7JYOJrDhoPOJI8lz99QFn0G+U7Q9 Zhh9cIRLXMkiDDj5IA4KnLf5qupvZ5OEZLjfloxzF8YomgbkBzeXTBvsTi4OeCfkGzkkHybYfZ17 1v2a0g/OGDIo0bbgcORBLya9mhlBVmzfOe77vO2Z+XN8bglBV324hLHR4ZKMRTJhQtEorhaaZ65W YHD/+vpCDaP9NlTdR3YrpVXL6nj/yEor/VDZq6tMKcveItqViNPVi9RYJZAPeDtaiqlQ5f0ChO5x 0Q0KZW5kc3RyZWFtDQplbmRvYmoNCjY0IDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVu Z3RoIDQxOTAwL0xlbmd0aDEgODI3MDQ+Pg0Kc3RyZWFtDQp4nOx9CXSU1d3+vTOTfZuEJAQGmDcM CUsgCasRKIRs7BBIBhJAyGRmkgxkGWcmEJZAwI1GcUG0KPuOYnUYUaOiolJLrVutVetC0VqrVhSt UqtCvufe39wQInr8n9Nzvq/nz3vzvM9zf/d392VuRpoyzhhLxMvAcgtKJk98oPeGnoz3b2PMVFaY V1C6ROtxhLFKA7xuKcybln/o2OjpjFX0Yox/NLGgsIilG6rgvxnpfSYWzyyZcNxSCv9NjN33/sQS a96Xr0QdZjyuibEUbWZJ1rDaGg/K5ifgX2Gvs7mjXkufy1j8TsZ0Y+1LfdoDtz/yb8YmoL6QyCp3 dd3Zs9OjGev2DmMRPattXjfrxSzIChszVtcur3rx+PtvMlZkRP7zNU6b4/3+SeNR/jSkj6qBIeb+ yFGIX4t4v5o6X5NxoW4DfAcwFtdU22C3/en46/cwNhn5w4/X2Zrc/b/qdyP8D8Jfq7fVOdMdsz5j bNZrjMUmuxu8vnYTu56xRZ+KdLfH6W7/5MNTjPX6BsVHMTGWPMQ8ecfijEVxY79mPcKZeB7/x6oX BD/df1Lh90PPeyMeDtuOaATTMXqQL5SdZ/x45Ayk3xTxsCyp06OfLywGG5vJQqRBx4wsizkZs6Sg XuliCOO3IjU85K6Q4SiyD7H+FXa9joUzXVyITqcz6HWGnUz3eS7TVqqyp5doGoPhOwO1IWy7Ll1j bIcs9JGQWNFTlB57oTX8ZXb5ufxcfi4/l5/Lz+Xn8nP5ufxcfi4//98/ui088kfTKtjpn8obcj27 8z/fosvPf/mjD6JX8FuBYsS4jBvYCHC4+PUenMp2aunt7Uz8vh5U7fa/DodvuCpJP4WF8k+l/qLr dwyI64LfSOjYTz+8o7TLz3/w0ZfLef6PPbkTHYsWXrVg/rzyMmtpyexZxTNnTJ82dcrkSROLCgvy 8ybkjh/3i7FjRl+Zc8WokVmZQwYPSE/rZ+lrTkmMN8bFREVGhIeFhhj0Os4GF1qKKjR/eoXfkG6Z NGmIiFtsMNg6GSr8GkxFF/v4tQrppl3smQvPqi6eueSZ2+HJjdpYNnbIYK3QovlfLLBobXzerDLo DQWWcs1/WurpUhvSZSQGkdRU5NAKU2oKND+v0Ar9RUtrWgsrClDe4ajIfEu+M3LIYHY4MgoyCso/ wOI+zAeM41LoBhSOPqxj4TGiWr8+rdDm8BfPKissMKWmlksby5dl+UPz/WGyLM0l2sxu1A4PPtZ6 U5uRVVZkRDssDtuCMr/ehkyt+sLW1hv88Rn+gZYC/8AVH6Sgy07/YEtBoT/DgsKmzu6ogPtD0owW rfVrhsZbTn96scUWtISmGb9mQooudgwT0pVmaBtaiP6lpoq23NiWyyoR8bfMKqO4xipNAZablVHu 11WIlGMqJckqUlpUSkf2CkuqmKrCiuDP0poUf0ulNmQwRl/+pOEH6Zpfn15Raa8RbHO2WgoKaNxK y/y5BRC5tmBfCw9nZ8HfVoFOuMQwzCrzZ1nc/kRLHjnAoIk5cJWUySzBbP7EfD+rsAdz+bMKC0S7 tMLWigJqoCjLMqvsUTa8/dThEZrpweE4J8tFO/zJ+ZiU9MLWMkeV31xhcmB9VmllplR/bjmGr9xS 5iwXs2Qx+geeQnWpskaZC33r4q2cRc/D0sK1Mp1JXy5mCwatCC9L3lgkGDFdMipmNG+sVsZNTLmh lqCHUBeVg4g+LX+SSNKLrPmTTKnlqfT8RJNMwTaFpPnDO5VlhKGjTVTPjzaNvEWDBmqFzoJODbyo 0JBgA4OlXbqdOjEWwYqRI1xM5ySVpE/DzoVNh2KkScxiiuZnxVqZxWkpt2AN5RaXib6JsZbzO7XE MnXWvDI528FVUnpRjNJzKOZnqUhWEV0+1mBRhklNq4xPlPGO6KQuyZNVstYabpla0ioKtwQLZBp2 EDodmj7ZdmNOwghszSKcbpYim0UzakWttrb2lsrWw7m5re7CiprRogzLZEerpaRsrEm2dXZZs2mF qCqBTeVTS/OGDMbZk3fYwtfPOpzL15fMK3vUiE/z9aVlAR3X5VfklR/uh7SyRzUc7tKqE1ZhFBFN RERJsxEJl/6mR3MZa5GpBmmQcXsbZ9IWrmyc2dt0ZDMqmw42A9lypU08mKSUGgwxjttCzSGmZ1V5 TWtFudhcLBlTiR/u55ZxzK+zjDvMdaHR/kiLM88fZckT9vHCPp7socIehoXBkzkGR5xJrRUWnFNY UGXMxGkp6kWRWlt7e2lZ6oum0+WpWGoLgHll/ogMnP0haVPgN1GgAuaJ/ha7TbSDWctE3rC0yfZy LFtVIFwm+yNQQkSwBHgUyTxiOSKTHXODCZT5WxDxt5T7yzNEpWWucrmcjX42yTIa005lhqSLirLK WxMsw+TexFaITLtBUATaxkrKyGJCFJWV0yCFRaPldguS7BUaRtvA7CVY6nSWRprI4sSRaEh3SkSa golMdEufFhUT6Y/IRIH4EToqU2zJkLSw8nJqvIzdEHRA3UZ/FFqU3mkogxkwOkiaLNqCnxvQVOH6 tChmVhubbWnCySIaLUsKQ7I/Jm2yDYc/5Y+CxZKjMoeLMyIqWMZxsoaJnkdj3PVppW3tByzLUzs9 QwZbxIeDWJjM9CgWNitv7Wrwz88YMji8qzVGmltbw2MunYHGKzymg4VRK8SnBmOBCL3Wprv2SEQK nwJxjRLrlFirRIsSa5RYrUSzEquUWKnECiWWK9GkxDIllirRqIRPCa8SVyvhVqJBiXol6pSoVWKJ EouVcClRo0S1ElVKOJVwKGFXolIJmxIVSixSYqESVymxQIn5SsxTolyJMiXmKjFHCasSpUqUKDFb iVlKFCsxU4kZSkxXYpoSU5WYosRkJSYpMVGJIiUKlShQIl+JPCUmKJGrxHglxinxCyXGKjFGidFK XKlEjhJXKDFKiZFKjFBiuBLDlBiqRLYSWUpkKjFEicFKZCgxSImBSgxQor8S6UqkKdFPCYsSfZVI VUJTwqxEHyV6K9FLCZMSPZXooUSKEt2VSFYiSYlEJbopkaBEvBJGJeKUiFUiRoloJaKUiFQiQolw JcKUCFUiRAmDEnoldEpwJVhQ8HYlzitxTonvlfhOiW+V+LcS3yjxLyXOKvG1El8p8U8lvlTiCyXO KPG5Ep8pcVqJT5X4hxKfKPGxEh8p8XclPlTib0p8oMRflXhfifeUOKXEX5Q4qcS7SryjxNtKvKXE n5V4U4k3lHhdiT8p8ZoSf1TiVSX+oMQrSrysxEtKvKjEC0r8XonnlfidEieU+K0SzynxGyWOK/Gs Es8o8bQSx5R4SoknlXhCiaNKPK7EY0o8qkSbEo8o8bASDylxRIkHlQgocVgJvxIPKHG/Er9W4j4l DilxrxL3KHFQiQNK7FdinxJ7ldijxG4ldimxU4kdSmxXYpsSW5XYosTdStylxGYlfqXEnUrcocQm JW5XYqMStylxqxK3KHGzEhuUuEmJG5VoVeKXSqxX4gYlrlfiOiXUtYeraw9X1x6urj1cXXu4uvZw de3h6trD1bWHq2sPV9cerq49XF17uLr2cHXt4eraw9W1h6trD/cooe4/XN1/uLr/cHX/4er+w9X9 h6v7D1f3H67uP1zdf7i6/3B1/+Hq/sPV/Yer+w9X9x+u7j9c3X+4uv9wdf/h6v7D1f2Hq/sPV/cf ru4/XN1/uLr/cHX/4er+w9X9h6v7D1f3H66uPVxde7i69nB12+HqtsPVbYer2w5Xtx2ubjtc3Xa4 uu1wddvh+Q8KgVtzoM84M+7MgT5JoHUUWxvoMxrUQrE1RKsDfaJBzRRbRbSSaAXR8kDvCaCmQO98 0DKipUSNlOajmJfIQ8arA73zQG6iBqJ6cqkjqiVaEuhVCFpM5CKqIaomqgr0KgA5KeYgshNVEtmI KogWES2kfFdRbAHRfKJ5ROVEZURzieYQWYlKiUqIZhPNIiommkk0g2g60TSiqURTAqbJoMlEkwKm KaCJREUB01RQYcA0DVRAlE+UR2kTKF8u0XjKN47oF0RjyXMM0WjKfiVRDtEVRKOIRlJhI4iGUynD iIYSZVNhWUSZlG8I0WCiDKJBRAOJBhD1p6LTidKozH5EFqK+VHQqkUb5zER9iHoT9SIyEfUM9JwB 6kGUEug5E9SdKJmMSUSJZOxGlEAUT2lGojgyxhLFEEVTWhRRJFEEpYUThRGFBnoUg0ICPWaBDER6 MuooxomYJN5OdF668HMU+57oO6JvKe3fFPuG6F9EZ4m+DqSUgr4KpJSA/kmxL4m+IDpDaZ9T7DOi 00SfUto/iD4h48dEHxH9nehDcvkbxT6g2F8p9j7Re0SnKO0vRCfJ+C7RO0RvE71FLn+m2JtEbwS6 zwW9Hug+B/QnotfI+EeiV4n+QPQKubxM9BIZXyR6gej3RM+Ty++ITpDxt0TPEf2G6DjRs+T5DMWe JjpG9BSlPUn0BBmPEj1O9BjRo0Rt5PkIxR4meojoCNGDgeTxoEAgeT7oMJGf6AGi+4l+TXQf0SGi ewPJOK/5PVTKQaIDlLafaB/RXqI9RLuJdhHtJNpBhW2nUrYRbaW0LUR3E91FtJky/IpidxLdQbSJ 0m6nUjYS3UZptxLdQnQz0Qaim8jzRoq1Ev2SaD3RDUTXB5JsoOsCSZWga4muCSRVgdYRrQ0kWUEt gSQcxnxNIGkUaDVRM2VfRflWEq0IJDlAyyl7E9EyoqVEjUQ+Ii8V7aHsVxO5A0l2UAMVVk+edUS1 REuIFhO5KF8NUTW1rIqyO4kc5GknqiSyEVUQLSJaSJ2+ilq2gGg+dXoeFV1OFZURzaXmzqGKrFRK KVEJ0WyiWYHEXFBxIFHUMDOQKJb3jEDiNaDpgcQhoGnkMpVoSiAR9wI+mWKTiCaSsSiQuBpUGEi8 AVQQSFwDyg8ktoDyAglFoAlEuUTjicYFEvD5zn9BsbGB+HLQGKLRgXixNK4kygnETwRdEYgvA40K xM8DjaS0EUTDA/GDQcPIc2ggXnQsOxAv9mYWUSZlH0I1DCbKoMIGEQ2kwgYQ9SdKJ0oLxItR6kdk oTL7UpmpVJhGpZiJ+lC+3kS9iExEPYl6BIxXgVICxoWg7gHjIlAyURJRIlE3ogTKEE8ZjGSMI4ol iiGKJs8o8owkYwRROFEYUSh5hpCngYx6Ih0RJ2K57XGVZoHzcXbzuTiH+Xvo74BvgX/D9g1s/wLO Al8DX8H+T+BLpH2B+Bngc+Az4DTsnwL/QNoniH8MfAT8Hfgwttr8t9ga8wfAX4H3gfdgOwX+C3AS eBfxd8BvA28BfwbejFlifiNmqPl18J9ias2vxaSb/wi8Cv2HmAzzK8DLwEtIfxG2F2LqzL+Hfh76 d9AnYhabfxvjMj8XU2P+TUy1+TjyPovyngGeBnLbj+H9FPAk8ET01eaj0R7z49Fe82PRPvOjQBvw COwPAw8h7QjSHoQtABwG/MADUcvN90etMP86apX5vqhm86Go1eZ7gXuAg8ABYD+wL2qIeS94D7Ab eXaBd0YtMe+A3g69DdgKvQVl3Y2y7kJZm2H7FXAncAewCbgd2Ih8t6G8WyNnmG+JnGm+ObLavCFy n/mmyAPm6/Rp5mv1OeZreI55nbXFuvZQi3WNtdm6+lCzNaqZRzWbmqc2r2w+1Px2c+700MhV1hXW lYdWWJdbl1mbDi2zLj3UaDU0Jjb6GvVfNfJDjbygkWc3ch1rNDZqjfpon9Vj9R7yWJmn2NPi8XsM Y/yeUx4d8/DItvZjD3pMfYrAuas8Mcaiq60NVvehBmt9VZ11MZrlyqm21hyqtlblOKzOQw6rPafS asupsC7Kucq68NBV1gU586zzD82zlueUWefCf05OqdV6qNRakjPLOvvQLOvMnBnWGbBPz5lqnXZo qnVKziTr5EOTrBNziqyF6DLrZeyl9dIbRQNm9EJLmInnZZtyTadMZ0wGZvKbjpn0CXE9zT11A+N6 8PyZPXhDjzU9bumhj0t5OUWXmzJwcFFc95e7/6X7590N3XK7D8wsYsnGZC1ZnyT6ljy9tEjy+ALi oSNlX6cnW9KL4pJ4XJI5SVdoTuIs/lT8mXh90lPGl426uDgeF9cep8uNg3tcrDlWJ17tsfrc2KFX FMXFmGN04tUeo0/OjYFFlNg/uri0KC7KHKWzjo+aGaXLjRqfX5QbNSS7iOm5xjnjRpA+HL5HeJK5 SH+Ui39qFMI4v/VwaUlGxtS2cDZ7qj+8eL6fr/enlYh37qx5/tD1fmadN7/sMOc3lx/muvxSf6L4 D7Uyft2GDax33lR/75KygH7nzt555VP9LULn5krdLjSDS3nGQm+jNyPDtxCvhV5fhvxBjDeKWIYw ih+vD3ERGmWcZfzkQ26gRV48vqDN99OZ/q8//H+7Af/9z2Em/n3BhHbdtcyhuwZYB6wFWoA1wGqg GVgFrARWAMuBJmAZsBRoBHyAF7gacAMNQD1QB9QCS4DFgAuoAaqBKsAJOAA7UAnYgApgEbAQuApY AMwH5gHlQBkwF5gDWIFSoASYDcwCioGZwAxgOjANmApMASYDk4CJQBFQCBQA+UAeMAHIBcYD44Bf AGOBMcBo4EogB7gCGAWMBEYAw4FhwFAgG8gCMoEhwGAgAxgEDAQGAP2BdCAN6AdYgL5AKqABZqAP 0BvoBZiAnkAPIAXoDiQDSUAi0A1IAOIBIxAHxAIxQDQQBUQCEUA4EAaEAiGAYUI73npAB3CAMQeH jZ8HzgHfA98B3wL/Br4B/gWcBb4GvgL+CXwJfAGcAT4HPgNOA58C/wA+AT4GPgL+DnwI/A34APgr 8D7wHnAK+AtwEngXeAd4G3gL+DPwJvAG8DrwJ+A14I/Aq8AfgFeAl4GXgBeBF4DfA88DvwNOAL8F ngN+AxwHngWeAZ4GjgFPAU8CTwBHgceBx4BHgTbgEeBh4CHgCPAgEAAOA37gAeB+4NfAfcAh4F7g HuAgcADYD+wD9gJ7gN3ALmAnsAPYDmwDtgJbgLuBu4DNwK+AO4E7gE3A7cBG4DbgVuAW4GZgA3AT cCPQCvwSWA/cAFwPXMccE1o49j/H/ufY/xz7n2P/c+x/jv3Psf859j/H/ufY/xz7n2P/c+x/jv3P sf859j/H/uceAGcAxxnAcQZwnAEcZwDHGcBxBnCcARxnAMcZwHEGcJwBHGcAxxnAcQZwnAEcZwDH GcBxBnCcARxnAMcZwHEGcJwBHGcAxxnAcQZwnAEcZwDHGcBxBnCcARz7n2P/c+x/jr3Psfc59j7H 3ufY+xx7n2Pvc+x9jr3Psff/t8/h//Kn/H+7Af/lT8qihYwx8b/HP3/7Rf94upgtZl7WgnA928Bu Z0+xt1kluwbqLraT7Wf3MD97mv2OvfGf/Bfb55eH1LFo/SMslHVjrP3b9tPn9wNtIbGdLLcj1s2g XbC0G9s/62L77Pzt7cbzbaEJLFLmjdG9Cus/+bn2b/EBi3j7KBHX3QAdJ3N8Ebb9/APnD3QZg1ls HpvPFrCrWAWzof8OVsNcGJklrJbVsXoZq0daNd5ViC2CFw4TqS94NTA34GE+1siWIrihvcGYSLta xhvZMoQmtpytYCvZKtYcfC+TllVIWSHjTcBqtgYzs5atk0oxWa5h17LrMGs3sPXslz8Z+2WHamU3 spswzzezW35Ub7godivCbWwj1sMmdge7k23GutjCtnax/kra72bb2Q6sGZF2Byw7pBKpR9lz7CF2 P3uAPSzH0o5RoxFR41Ilx9CNMViFHl7TqcU0fss6Rms1+i761hrsaRPs6zrlWBocR+F5DTypFJoH UUpzl5G4FX0gfaFHFLtD9v+CtfOo/JRVjcfWTiOzRcaE6mr9MX0n24YduAtvMapC7YYmtUPqzvbt Hb47ZXwP28v2YS4OSKWYLPuhD7CD2Nv3skPsPoQLurMivp/9Ws6cnx1mAfYgO4KZfJg9wtqk/afS LmV/MGgPdFgeZY+xx7FCnmTHcNI8g6AsT8D2VNB6XNoo/gx7FnHhRbHn2G9xQj3Pfs9eYC+z3yD2 knyfQOwV9ir7I3uDx0D9gX2M9zlA/LbNznv1r+LU0LMwdiWbzmaw+UdZDD7fk9lo/tBDSQUF4UPC nsRnt45p+PQPx6/n+blxBl3MIz17jrc8MjJ0gz5+chsfcmR82Abca8efO3nupaxzJ08nXJl1mme9 +97J94xfvBR/Zdbw9157b2g2j0+Nl0iM1YWFJYZa+mbqRvZPHzV8+LBxupEj0i19Y3XSNmLUFeP0 w4f10ekTlWWcTsS5/tXv5+lnngvVrbaMnzM8pE/PuMSY0BBdr5SEIWPTjCXz08Zm9g7Th4XqQ8LD BlyR13dqbWHft8Lieycl904ID0/onZzUOz7s3Nshsd9+GRL7Xb6h9rtN+tAxC8b302+ODNcZQkPb +qT0GDQmdfKcuG5GQ1Q3Y3xyeFhCfPSAggXnrk/qJcrolZREZZ2bznQ8sv0sfydkIUtiA1nsQyFp punGIjZ+/Lsvobuq8fp0an1St67deSJMFNcrISyehydZepksSeGxET0GmM0DUyIiUgaazQN6RPDG 8OhwgwEv/WPRCdEhodHx0d9dmZphiooyZaSmDukRFdVjCCbodPtp/oBhkWyJdpQl4zc+jSXprnw4 yjgI7XIxNMp4nGfRVARb0l8/4sfadkdYnCkp2WQM5fGh3fr1MvXtFhYRkdyvd6/07hER3dN79e6X HMFHhkWG6fV46dqjjZEhIVFx0d9rvfunREWl9O/de0CPyMgeA7C67mz/l+EMO8miWHdmYYOeYin4 XbcPi8ZvuwmM6VY9EpqaFGGK009j44cPf3HYMLRShKHZaWKVpGNBDB+WHPIjmruyxo7OFODPZgo1 ZswQflzZaouyMgsuAfmpt+tyuBwuh8vhcrgc/o+EDzsHPqJLWHM5XA4XAu4wQ3R9GQv+r8kd8i00 Z7EyJrSOxeoNTP11gWx9QlAbOvmEsBR9XlCHdrKHsW/184I6nA3SvxLUEUwzlAZ1pG5nh38Um2Pw BXU0G2R4PqhjdJsNXwV1LKsNu6njbxIMC/smqDkLCx8U1DoWFrFC/fUBlhKxNqgNnXxCWHTEXUEd 2skexpoj9gV1OEuKOBXUEcwY2TeoI3lxh38Uy4gcFtTRLCnyqqCO4dMiPUEdy0ZFPSn+GoMhIjjO pGmcSdM4k6ZxJm3o5EPjTDq0k53GmTSNM2kaZ9I0zqRpnEnTOJOmcSZN43wPfg0YxrIRRkFNl988 eFgD8wJVzAdbvvzGhr63scHigqpnmUiZwGoRNDYbtmpWgzSvjDnBTngvxdsBz3zkq4VPJWwueLik nw2oQ1kO6VuPmBe2eplG+V1ogQbY4OdCCcsRWwblQ12a/J6oEroWvppscyNyO+T3UNWylIZgqT54 1AXrFB4a+tgg63TK75tEXybLvlbBYpPfg3hkLzTJNtlLUS/1w46UwbLkOmmplSXaMEZkV7XUoZxa OWLuYCvrYamTtVKZop++Ti0QNbplX9T3ZDTa1HZRUwNGQJPfEFXLUXDJ74TEd20+GRM99nXMB40Z 1aLJttcH+9Ugx7ZSel5oceceiVFrkvmo10sQz5TrofNs9pel1ckSlstxaAzOfOfxFjNG/XfK9ov+ 07x45GoQTDWKudZQhrujN9TG6qCPF7EVwdJ96AXN0NKOWbLJNWKDte6ifqnVbEdLbLJ+e7D+TLli q+VciZQf7oHRP+j16I5dM5LNCa4iV3C9DUWJ2Ui99Kp3Btcv9cYWbH+1TKX2OIMjJtrokCtXtGqJ nDOV59KpVf9PO/jCaqG5sSLmkm0Q9ZfI1e67aB6zgi1o6NQDe3Df+WQvnXItT4PFzgbIOR4IH4cs f6JsFeX1IbgxilkIy2TIlHv84pZnytLr4OPD2hLtr5Y9cKOE5bCKGaySfRE75+JSlb1KflvtketX lVcu20yrdrlcbV7ZQp/cV155DlBuTfZB7EmnXFEuWQeNUKXMq0avEOM3DSci5fV0SqH97JBjcmGP Lgt+y1vzI/VSXPjasYoa5Rg6Ota8Q6a75Ypd3mmdu2VP64MrncpyyrfYuV37LdLphBiAXAPl6qxD v5wde/aHrar/Qck/f4wulK5OaS14ztLqsV903v2w7xfW68XtGtNpBERPqC906qtV7+n4BHHIM7Re nqW2H+0pjbPtojF1Bld/1z0gRlWsvEaZ0yHPI9EbZ0c5wrNWnmk/NUP/qX1xYU9kydaIPUCfRJly rtys6R5tWHb2KG26y+5p8DZU+bT8Bo+7wWPzuRrqM7UJtbXabFd1jc+rzXZ6nZ6lTkdmvq3WVelx aS6vZtPqGhxOT73mtdV7NaS7qrQqW52rdrm2zOWr0byNlb5ap+ZpaKx3uOqrvVoDXH3OOuSsd2j2 Bk+90+PN1Cb7tCqnzdfocXo1j9NWq7l8qMPuHax562xogd3mhhZZ6hprfS43iqxvrHN64Ol1+mQB Xs3taUC7RbNRem1twzKtBg3XXHVum92nueo1n+gHWoYsWq2rHnU1VGmVrmpZMFXkczb5kNm1xJmp BbvZ36vV2eqXa/ZGdJ7a7atB/c5lmseGvnhc6DYy2uq0RreoBiVWw+J1rYC7rwEdWiq6ZNOW2Tx1 VJcYZnuNzYOGOT2Zs53VjbU2T8cMjFZVjxZTM3IOhgid0oZmZg/rNPROjC+qsaH8apdohxMN89gc zjqbZ4nWIFI6RasuPcFyWNAba73Lh/wlPpuP+piFAhpkBXbMnc/jcnozpzXaB9i8AzWHU5voaUCq z+cenZW1bNmyzDpVeKa9oS7Lt9zdUO2xuWuWZ9l9VQ31Pm/QVegqGzqwRPiVNzRiaJdrjV4nGoEu iWTNhpl0eupcPtGgyuWyeYXWaROQ6pERzLOjkWZ0WY3LXtMpL9hVb69tdIixaNAcLq+7FhWIMXd7 XHCww8tZ78vUVN0N9VgQA1wDNWddpch0oah65XzJFkl3saQx/F4Mj53WXUftclyDZY2RDRjgQi1Y +mLoPWKDOBqW1dc22DpXijbbqKUY+I4ZaGj0uRt9GPalLrtT+NQ4a91dOvRz5kLORJbDWWXDJsq0 ed1NHb8PsvYU8TfsL/FweOA3CtaNhbW3s7jg34ELRcIAJv6qHPvB34y76NFP0ZdHR3P48Ek/1z8m RvrX/Fz/uDjpv/7n+huN0v/gz/WPj5f+J36uf7dunAtm4rdKg/QXv1XrxN/GgzUGuluX9O6d0sVf 1U/skp7RKT0OOrlL+oRO6UboHl3S53VKj4fu2SXd1yld/NZvEvMcznm4oUU+rIWHIbYxgvOIoClo i9gYyXWRIR22Fl0Y4hs3RnFdlLJKcwQM61vWt0RzXXRoS5eUaJESo9PFhB7reNixY7pImF449sIx GvVIfJYdZ3r7ck8tS6z2OJew7Fqbr56NRQovmZ2nsUSs5Ha5RrlU4u8XirEnrcfY6GbPnK6xlNLZ UzUxm9JuCHJIkENZmN3tdbPBS/DRxobJd458j5PvAvmeIt/FHSuC0//Xw0+8dfI3eYqhJeI/k+Jz mKP1IbitFMu2Gtg6TEW2rpit0e3VvcF26rfpt7HXGL/HL9qpazJ8e6kQlh2WHbkxeueFELOfgkjp GmLXJ4zqCO8gnE04221BtwXdN4rQ82jXEJZtCvQ5Yd5IIfXaC6HvdhH6p1wy3JyxV4Ws54ctUOGK sxRG3/TDMGb/mP1jN/1i8YUwrh8FkdI1jHtu/Kcq5M74kVCW+3zu8xO+EuHilPz0S4Ux+/M/Kkwo PEKh6P4LYeJ9Iky695LhzORPVJjy5tTtKkw7SGH60kuFGW0z2oojZ63qFN4Stq5htqE4sjhytkHk Kc0UwbpKBSppzltzPphzdm723MVz9849OeetuR+J0LW+8rxLBdGG4sjy9eXbKcz74EIQdS0YJd6z DQJX3bToExUqJ9nvVaEqnEL1yeqTNYlAHsKqmv01p6D31+x36VzTXHfK8KbrrOvs4hGLFyI4Fq9b 3AasW/zk4u+XjBZh8bol7iWtCPcteXjJ0SUfLvmwNrx2NoKjtr52czA8VtevbmNdW92H9dkIo+tL 65fWb6p/PRg+qv8Sv16OQ5jm7uPe5D4rgueIt1IEXKx3+14IhtfFNRv8lYx91TiocZDvhcZNS/su zV1a2aQ1acufXFHmOULe4K/Ia8Vnwm/F9ytHr6xduX3l8ZWfibBq7Kp1MhxZ9VZzSnNf8JHmEQj1 zQeb729+bXUCQvHqu+E3dvWx1ceaR+D9pVCrj60xrOmzZtqapTKcaSmSoalld3MK3k0tJ1o+aTkB jz5rw9dmrh2xdh3CibXfrjkD3xOUsq5Xy4l1eeumXVN1zTfXbry++Pp51ztaR28ouO3ejT7Fm2Zs mrHZeNf7d321JXmLtmXhlpYtrVs2bdm95eiWl7ac2fLtVsPWhK3a1lFbc7fO2Lpg6/6tJ7ae3DZg 26htk7at3rZ526vbPt0+aHvZ9o07oneM2+Hbce+Oozve3/H9znE7m3Y+tmvErjm7Wnbdveu+Xa/v +mh3wu4Fu+/cfWZPwp4Re4r2FO/x7Fm1Z/ueU3sT9jr2rt67ee+rez/Yl7wve9+KfUf2nd2fu3/F /vv2f3KAHRh1oPTA7gOnDqYf9B0MHPzonla2gSW0f8G6AYlAEpAMdAf6AwOAgcAgIAMYjc/SMcDU 9o/ZNGA6MAOYCRQDs4DZQAkwBygHHO0VzAlUATXtp5gLWAwsAWqBOqAeaADcwNWAB/C2H2C+dj9r BJYCy4AmYEX7//By79F112W+x39xDyMgyDgzxxnmzOj06CiFERgFraCizniLOnV0uCrQomOpY89y MWprh4uhXEqhOZRAlVJ6T2kTbEvS0As2u2jSkIamDbl2p7ntnbAv+SX7JCRNsCW/80qt53hmgWvw rHX+eK8Uu5q9n+f7fN7P95eL3wn+HbfjDtyJFVFT8AhK8Cgew0psxlPYgq0owx7bYC8O+nMDXsQh NOIwjqAJL6EZLWhFB1LRwqAfA0jrRwZZ5DCIEEMYRh7/EyMYjdYEr0S1wRjGcRwTeDVaHfwKJ3AS r0WrC1ZFLxY8gdVYg7VYh/XYgI3YhFJsxlPYgq0oQzmexs+wDduxA8+gApXYif1RoqAuai94AfU4 iIaoPfbl6Oexq4PzYtcF58RuiL4Y+3pUEbvJx5t9vC0aiVUHHwk6gj+IcsEZ+EO8FWfiLJyNt+Ec nIu344+jjAnLmLCMCcuYsIwJy5iwjAnLmLCMCcuYsIzJ6jVZvSar12T1mqxek9VrsnpNVq/J6jVZ vSarN7gpCoObMQdzcQu+ibui48GPUYS7scIUPoISPIrHsBKb8RS2YCvKcDBKm4q0qUibirSpSJuK tKlIm4q0qUibirSpSJuKtKlIB13RZNCNHvSiD0mk/F0/BjAaJUxA0gQkTUDSBCRNQDKY9HevRq2m oNUUtJqCVlPQWvCWqLsghj/AGfhDvBVn4iycjbfhXPxR1F/wDvwx/gR/iv+Cd+LP8Oc4H38RJQve FXUWvBt/jRn4b3gP3ou/wfvwflwQ7S+YiQtxEf4WH8DFuASX4u/wQXwIl+FyfBgfwSx8FFfgSnwM H8cncBU+iU/h0/h7/AM+g8/ic/g8voBCfBFfwpfxj5iNq9VyDa7Fdbged3jfd+Iu/BhFuBtLcA/u xX24H0vxoH+zKspIW0baMtKWkbaMtGWkLSNtGWnLSFtG2jLSlpG2jLRlpC0jbRlpy0hbRtoy0paR toy0ZaQtI20ZactIW0bajhQ876x+gV+iBrWo87+/gHocREN0RMoGgiUSFkpYKGGhhIUSFkpYKGGh hIUSFkpYKGEhxx7h2CMce4Q307yZ4c0Mb2Z4M8ObmeBHUQt31nFnHXfWcWcdd9ZJSygtobSE0hIG S6Lx4B7ci/twP5biASzDg3gIqWjMdI+Z7jHTnTTdw6Z72HQPm+5h0z1supOmu910t5vudtPdbrrb TVdoukLTFZqu0HSFpis0XaHpCk1XaLpC0xWartB0haYrNF2h6QpNV2i6QtMVmq7QdIWmKzRdoekK TVdoukLTFZqu0HSFpis0XaHpCk1XaLpC0xWartB0haYrNF2h6QpNRWgqQlMRmorQVISmIjQVoakI TUVoKkJTEZqK0FSEpiI0FaGpCE1FaCpCUxGaitBUhKYiNBWhqQhNRWgqQlMRFhyIRkxBaApCUxCa gtAUhLGro37+7efefk+g53n6er+OXoCZuBAX4YrgHBv5HN4c5s1h3hzmzWHeHObNYd4c5s1h3hzm zWHeHA6+5ZnoX/BtrOClR1CCR/EYVmJz1MGNHdzYwY0d3Nhhc/6ZzflnHJngyARHJjgywZEJjkxw ZIIjExyZ4MgERyY4MsGRCdsyb1vmbcu8bZm3LfO2Zd62zNuWedsyb1vmbcu8qcmrfiJ2gw309eD6 2E0+3hxcH8ySiaRMJGUiKRNJmUjKRFImkjKRlImkTCRlIhmcJ0VX2D5X4lvM/i/4Nv5NFr4fjcrH qHyMyseofIzKR598HJWPo/JxVD6OysdR+cjJR04+cvKRk49B+RiUj0H5GJSPQfkYlI9B+RiUj0H5 GAz26PTeUxkYC6ZsoSg6XhCgIDquuvrYdZJ+g0q/HsSccV6FsWBQhctVuFyFy1W4XIXLVbhchctV uFyFy1W4XIXLVbjebh22W4ft1mG7ddhuHbZbh19/VqIS3Sh5U7NyU5SyY1N2bMqOTdmxKTs2pVs5 nRnXmXGdGdeZcZ3ZpDObdGaTzmzSmU06s0lnNunMJp3ZpDObgoejk+buBXP3grl7wdy9YO5eMHcv BD/xdz/FE1iNJ7EGa7EO67EBG7EJpdjs3z2FLdiKMpT735/GNmzHDjyDClRiJ6rwLHZhN/ZEW53Y 1uA5f/459qEacezHL/BL1KAWB1CHF1CPg1G9XNTLRb1c1MtFvVzUy0W9XNTLRb1c1MtFvVzUB23+ TTs6/Pmojwl04hi69L4bPehFH5JIRT2s28O6PTIVylQoU6FMhTIVylQoU6FMhTIVylQoUyFDpxi6 n6H7GbqfofsZut90vsDQaYZOM3SaodMMnTaxh03sYRN72MQedh+pdx+pdx+pdx+pdx+pdx+pdx+p dx+pdx+pdx+pdx+pfxP3kdB9JOk+knQfSbqPJN1Hku4jSfeRpPtI0n0k6T6StO9D+z6070P7PrTv w4I5wZ8UzA2+WnBLcH7BN4MZBd8K3lHwr7jD574Td+HHKMLdWIJ7cC/uw/1Yigd9roejroIVeAQl eBSPYSV+EnVJ7GUSe9WptEpq7LtRPJgpgce55Ti3HOeW49xynFsmuGWCWya4ZYJbJnglyStJXkny SpJXkk7ypJM86SRPOp1fOZ0TTueE0znhdE44nRNO5jUn85qTec3JvOZkXrMzUm4SOTeJnJtEzk0i 5yaRs0dG7ZGkPZK0R5L2SNIe4Up9Okef3qFP5+jT2aeswzjB+WzTxTZdbNPFNl1s08U2XWzTxTZd bNPFNl1s06XWtNRP3w9CKQ+lPJTyUMpDKQ+lPJTyUMpDKZ/eXwM6NlxwLkdVcFQFR1VwVAVHVXBU BUft4KgdHLWDo3Zw1A5uWstNa7lpLTet5aa13LSWm9Zy01puWstNa7lpLTcNc9MwNw1z0zA3DXPT sKfMlKfMlKfMlKfMlKfMlKfMlKfMlKfMlKfMlKfMlKfMlNPqdlrdTqvbaXU7rW5uquamam6q5qZq bqrmpmqe2ccz+3hmH8/s45l9duKf2ol/KvvVsl8t+9WyXy371bJfLfvVsl8t+9WyXy371bJfLfPV Mj4o44MyPijjgzI+KOODJuOgyThoMg7K+BEZPyLjR2T8iIwfkfEjMn5Exo/I+BEZPyLjR0xR7es+ Zf76GaPWJNWapFqTVGuSat/kM0aHTHfIdIdMd8h0h0x3yHSHTHfIdIdMd8h0z5t4xki7BabdAtNu gWm3wLRbYNotMO0WmHYLTLsFpt0C026BabfAtFtg2i0w7RaYdgtMuwWm3QLTboFpt8C0W2DaLTDt Fph2C0y7BabdAtNugWm3wLRbYNotMO0WmHYLTLsFpt0C026BabfAtFtg2i0w7RaY5pwezunhnB7O 6eGcnoKbgr+Up/fI09Xy9Ffy9B7e+ZuCb0e93DOj4Ac+/hALsQg/wmLcjjf7fPKAf/Og13zIx+Uo xv/Aw1K1Ao+gBI/iMazET7DKk/0TWI01WIt1WI8N2IhNKMVmPIUt2IoylONp/AzbsB078AwqUImd qPJensUu7MYe7MVz+Dn2oRpx7I+eYK31rLWetdaz1nrWWs9Y5YxVzljljFXOWOWef7qDg268VzFH jjlyzJFjjhxz5JgjxxxNzNHEHE3M0cQcTW7C57sJn88gzQzSzCDNDNLMIM0M0swgzQzSzCDNDNLM IM3c/R3u/g53f4c1WlijhTVaWKOFNVpYo4U1WlijhTVaWKOFNVp4fgFzLGOOZcyxjDmWMccynr+e 56/n+et5/nqev96T3PnBPbgX9+F+LMUDWIYH8RBWuAU8ghI8isewEpvxFLZgK8qwJyhknULWaWCd BtZpYJ0G1mlgnQbWaWCdBtZpYJ0G1mlgnQbWaWCXjeyykV02skuKXVLskmKXFLuk2CXFLil2SbFL il1S7JJilwfY5TC7HGaXw+xymF0OM8ttzHIbs9zGLLcxy22SnZXsrGRnJTsr2VnJzkp2VrKzkp2V 7KxkZyU7K9lZyc5Kdlays5KdleysZGclOyvZWcnOSnZWsrOSnZXsrGRnJTsr2VnJzkp2VrKzkp2V 7KxkZyU7K9lZyc5Kdlays//fErI/qjD1u039blO/29TvNvW7Tf0zpv4ZU/+MqX/G1D8Tuzp4h818 Zezr0QLb+crYzT7e7jnhjmhXrDq4IpaKfhLrDy6NDQQfjKWDi2LZqCmWC94SfNwWz9riWVs8a4tn bfGsLZ61xbO2eNYWz9riWVs8a4unPAcMeA4YMP31pr/e9Nef/qpBzkTnTHTOROdMdM7G32+q6011 vamuN9X1prre3T/h7p9w90+4+yfcCvJuBXm3grxbQd6tIO9WkHcryLsV5N0K8m4FeXfs0B07tJNC d8y8O2beHTPvjpl3gxkreNET0iE04vCpJ6UjbhFJnRl29zpHZ4bdv84JalU9X9XzVT1f1fNVPV/V 81U9X9XzVT1f1fNVPV/V31f191X9fVVPqHpC1ROn7ms/crdZ7Onl33E77sCduEunfowi3I0l0QoV rlDhChWuUOEKFa5Q4QoVrlDhChWuUGGNCmts97ztnrfd87Z73nbP2+75IOU5rx8DeBNPxbZ1i23d Ylu32NYttnWLbd1iW7fY1i22dYtt3WJbt9jWrbZ1q23dalu32tattnWrbd1qW7fa1q22datt3W1b t9vW7bZ1u23dblu329bttnW7bd1uW7fb1u0FF7g9zsSFuAh/iw/gYlyCS/F3+CA+hMtwOT6Mj2AW PoorcCU+ho/jE7gKn8Sn8Gn8Pf4Bn8Fn8Tl8Hl9AIb6IL+HL+EfMxtVquQbX4jpcjzu87ztxF36M ItyNJbgH9+I+3I+leNC/edi2WoFHUIJH8RhW4idY5bWewGqswVqsw3pswEZsQik24ylswVaUoRxP 42fYhu3YgWdQgUrsRB1eQD0OosH0Xx29JXbd1InYDcG50nBp7CYfb/bxu9GjtuYvgw/amoU24Uyb cKZJbzLpTSa96XS+x+R7TL7H5HtMvseCH8nS4ugl0/+S6X/J9L9k+l+ytWbaWjNtrZm21kxba6at NdPWmmlrzbS1ZtpaM22iT9tEnw4m/XkKUTCzIEABvhJcWfBP+Cq+hn/G/GB2wYHg3Ww3P3ZN8DFV nKmCM2PfDZbG7greFSsK/jq2JHhXcPvv+MrGkN0/ZPcP2f1Ddv+QnR/a+aGdH9r5oZ0f2vmhnR/a +aGdH9r5oZ0femoY8NQw4KlhwFPDgKeGAU8N0zYMdSvUrVC3+nVrWLeGdWtYt4Z1a/h1n+PMir3d a2/32tu99navvd1rb/fZ2332dp+93Wdv9+lWTLdi9nafvd1nb/fZ2332dp+93Wdv99nbffZ2n73d Z2/32dt99nYfV0xwxQRXTHDFBFdMcMUEV0xwxQRXTHDFBFdM2NX9r/v12FfV9iucwEm8duoJ/Jj8 H5P/Y/J/TP6Pyf8x+T8m/8fk/5j8H5OlNllqk6U2WWqTpTZZapOlNllqk6U2WWqTpTZZarP7Xrb7 euy+Hruvx+7rsft67L4eu6/H7uux+3rsvp7YdcHZwWcZfYTRRxh9hNFHGH2E0UcYfYTRRxh9hNFH GH2E0U8y+gSjTzi5USc36uRGndyokxtxciNObsTJjTi5EZZ/xemFTi90eqHTC53e9NPsFKtPsfoU q0+x+hSrT7H6FKtPsfoUq0+5NXW4NXW4NXXo7hHd7dDdDt3t0N0O3e2w0xI6vFeH9+rwXh3eq8N7 dSKrE3mdyOtEXifyOpHXibROpHUirRNpnUjbc6EbwKg9F7oBjEr1RMG7dGaOzszRmTk6M0dn5ujM HJ2ZozOe73Eu3o7zomtkp0122mSnTXbaZKdNdtpkp1Z2amWnVnZqZadWF+O6GJehAzJ0QIYOyNAB GTogQwdk6IAMHZChAzJ0QIYOyNBxGTouQ8dl6LgMHZeh48G3gr8M/gXfxpJols7O0tlZOjtLZ2fp 7CydnaWzs3R2ls7OCh6OKmXoRhm6UYZulKEbZehGGbox+Im/+ymewGo8iTVYi3VYjw3YiE0oxWb1 P4Ut2IoylPvfn8Y2bMcOPIMKVGInqvAsdmE39kSP2uOPBs/588+xD9WIYz9+gV+iBrU4gDq8gHoc dBYNeBGH0IjDOIImvIRmtKAVbf5NOzr8+aiPCXTiGLpMUjd60Is+JJGOSjihhBNKOKGEE0o4oYQT SjihhBNKOKGEE0pM7bOmtsrUVpnaKlNbZWqrTO1OU9tjantMbY+p7TG1PW5nXW5nXW5nXW5nXe4f c9w/5rh/zHH/mOP+Mcf9Y477xxz3jznuH3PcP+a4f8xx/5jt/jHb/WO2+8ds94/Z7h+z3T9mu3/M dv+Y7f4x2/1jAf8U8k8h/xTyTyH/FPJPIf8U8k8h/xTyT2HBV6L5Bf+Er+Jr+Gdc7d9fg2txHa7H TcH7PKF/yhP63Z7Qv+YJ/RZP6F/whF7kCf2TntCLPKEXeUIv8oRe5Am9yBN6kSf0Io4r5LhCjivk uEKOK+S4Qo4r5LhCjivkuEKOK+S4Qk/oRe4MCzyhF3lCL/KEXuQJvcgdYp47xDx3iHnuEPPcIea5 Q8xzh5jnDjHPk3ORJ+ciT85FnpyLPDkXeXIu8uRc5Mm5yJNzkSfnIk/OReyxiT3K2KOMPcrYo4w9 ytyWNzPIRgbZyCAbGWQjg2x0g77NDfo2N+jb3KBvc2e4OHZNVBy7NlrsJn25u8M7T98d3nn67vAY y8yJVUebYynPFu6lsZc9d2SDrwd/xTzNzNPMPM3M08w8zczTzDzNzNPMPM3M08w8zczTzSYdbNIh /SPSPyL9I9I/Iv0j0j8i/SPSPyL9I9I/8lvPAydPfcfrOpvmDK+6zquu86rrvOo6r7rOq67zquu8 qtsWzsXbcV703d9xV0jzXZrv0nznqQlXRDu8w+mvNA7w3QDfDfDdAN8N8N0A3w3w3QDfDfDdAN8N 8N0Y343x3RjfjfHdGN+NBf8WnKXSRSpdpNJFKl2k0kUqXaTSRSpdpNJFKl10+rsea3huDc+t4bk1 PLeG59b8nt/1eJLnnuS5J3nuSZ578vf8rketE6j9f/iuRznPlfNcOc+V81w5z5XzXDnPlfNcOc+V 81w5z5X/1nc9yl/nux7P89zzPPc8zz3Pc8/z3PM8185z7TzXznPtPNfOc+08185z7TzXznPtPNdu kpq561XuepW7XuWuV7mrmLuKuauYu4q5q5i7irmrmLuKuauYu4q5q5i7Hueux7nrce56nLse567H uetx7nqcux7nrse5ayt3reKuVdy1irtWcdcq7lrFXau4axV3reKuVdy1mrtWc9dq7lrNXau5ayt3 beWurdy1lbu2ctclv+Wuz3PXD7nrM9zVyF0f4a5G7mrkrkbuauSuRu5q5K5G7irjrjLuKuOuMu4q 464y7irjrjLuKuOuMu4q464y7mrkrq3c1chdjdzVyF2N3LWZuzZz12bu2sxdm7lrM3dt5q7N3NXI XY3c1chdjdzVyF2N3NXIXY3c1chdjdzVyE9d/NTFT1381MVPXfy0jZ+28dM2ftom9Tfw06P8tEv6 P8RNl/PS5by0kpee4KKfc9E1BWexwkZW2MgKG1lhIytsZIWNrLCRFTx34Vy8HedF9/6Orx7mWCHH CjlWyLFCjhW2sMIWVsixQo4VcqyQY4UcK+RYIccKOVbIsUKOFXJveAuavmsuiZaywlJWWMoKS1lh KSssZYWlrLCUFZaywlJWyLNCJStUskIlK1SyQiUrVLJCnhXyrJBnhTwr5Fkhzwp5VsizQp4V8qyQ Z4U8K+RZoZIVKlmhkhUqWaGSFfKskGeFPCvkWSHPCnlWyLNCnhXyrJBnhTwr5Flh+us0z7LCs6yQ Z4U8K+RZIc8KeVbIs0KeFfKskGeFPCvkWSHPCnlWyLNCJStUskIlK1SyQiUrVLJCJStUskIlK1Sy QiUrVLJCnhXyrFDJCnlWyLNCnhXyrJBkhSQrJFkhyQpJVki+ye9/5t1+0m4/abeftNtP2u0nzRYN b/D9z34G6WeQfgbpZ5A9DLKHQfYwyB4G2cMgexhkD4PsYZA9DLKHQfYwSAWDVDBIBYNUMEgFg1Qw SAWDVDBIBYNUMMhuBqlikCoGqWKQKgapYpAqBqlikCoGqWKQKgY5yCAHGeQggxxkkIMMsptBdjPI bgbZzSC7GeSPGOT9DPLfGeQSBrmEQS5ikBoGeT+D1DBIDYPUMEgNg9QwSA2D1PweBqlhkN0MUsMg NQxSwyA1DLKLQXYxyC4G2cUguxhkF4PsYpBdDFLDIDUMUsMgNQxSwyA1DFLDIDUMUsMgNQxS4/Yz /TNSDSzSwCINLNLAIg2scQFrfIsxPsgYb2eMt7PFlmCT1NdJfZ3U10l9ndTXSX2d1MelPi71camP S/30M0+dtNdJe52010l7nbTXSXudtNdJe52010l73Rv+tOEKd+hHUIJH8RhWYjOewhZsRRn+z3cL q6SjSjqqpKNKOqqko0o6qqSjSjqqpKNKOqqko0oqqqQglIJQCkIpCKUglILQk2m9J9N6T6b1EnFI Ig5JxCGJOCQRhyTikEQckohDEnFIIg5JxCGJqJeIZololohmiWiWiGZpeFEaXpSGF6XhRWl4URoi aYikIZKGyOS2mNyjJveoyT1qco+a3KMm96jJPWpyj5rcoyb3qMmdMLkTJnfC5E6Y3AmT22JyW0xu i8ltMbktpi9h+hKmL2H6EqYvYfoSpi9h+hKmL2H6EqYvYfoSJq+lYFXUV/AEVmMN1mId1mMDNmIT SrEZT2ELtqIM5XgaP8M2bMcOPIMKVGInqk59Lb/ePfywe/hh9/DD7uGH3cMPm85W09lqOltNZ6vp bD31BP/rp/ftBd+2t261t261t261t261t261t261t261t261t261t261t261t75igveZ4H0meJ8J 3meC95ngfSZ4nwneZ4L3meB9JnifvfWwvfWwSa42ydUmudokV5vkapNcbZKrTXK1Sa42ydUmuTqY /t7/zZiDubgF38R//LnZJZ7A78G9uA/3YykewDI8iIfwsCStiL4nBd+Tgu9Jwfek4HtS8D07LG6H xe2wuB0Wt8PidljcDovbYXE7LG6Hxe2wuB0Wt8PikrNQchZKzkLJWSg5C+2wuB0Wt8PidljcDovb YXE7LG6Hxe2wuB0Wt8PidljcDovbYT+1w35qh8XtsLgdFrfD4nZY3A6L22FxOyxuh8XtsLgdFrfD 4nZY3A6LS+lCKV0opQuldKGULpTShVK6UEoXSulCKV0opQuldKEdFrfD4tK60A6L22FxOyxuh8Wl d630rpXetdK7VnrXSu9a6W2R3hbpbZHeJultkt4m6W2S3ibpbZLeJultkt4m6W2S3ibp3Su926R3 m/Ruk95t0rvNPlsnwU0S3CTBTRLcJMFNEvyc8D4nwc9J8HP22WL7bLF9ttg+W2yfLbbPFttni+2z xfbZYvtssX222D6ba5/Ntc/m2mdz7bO59tlc+2yufTbXPptrn81lhTtYYQErLGCFBaywgBUWsMIC VljACgtYYQErLCi4IPpFwUxciIvwt/gALsYluBR/hw/iQ7gMl+PD+Ahm4aO4AlfiY/g4PoGr8El8 Cp/G3+Mf8Bl8Fp/D5/EFFOKL+BK+jH/EbHzF0/M/4av4Gv4ZV6vvGlyL63A9box67dwLCm6O9tq7 l9i7N9u7l9m7X7N3r7J3NxTMZ4l/9Xc/8OcfYiEW4UdYjNtxRzSP/eax3zz2m8d+89hvHvvNY795 7DeP/eax3zz2m2f3bmDAO+zeDXbvBrt3g927we5dbvcut3uX273L7d7ldu9yu3e53bu84Kf29Srm fAKrsQZrsQ7rsQEbsQml2IynsAVbUYZyPI2fYRu2YweeQQUqsRNV3s+z2IXd2IO9eA4/xz5UI479 ZvJ5ff8Ffoka1OKAvsokw8YZNs6wcYaNe4pY7SlitaeI1Z4iVrsP/IH7wA89RXzbneBP3An+wp3g LzxFLGHhB2PJaMyTxMFYJhrwNPGBWC4aDkqZeZyZx5l5nJnHmXmcmceZeZyZx5l5nJnHmXmcldOs nGblNCunWTnNyuk3+C2GDBtn2DjDxhk2zrBxho0zbJxh4wwbZ9h4+mdRXw1+gB9iIRZhMf4dt+MO 3IkVURvDtjFsG8O2MWwbw7axZRtbtrFlG1u2sWWbe8bl7hmXM1gbg7UxWBuDtTFYG4O1MVgbg7Ux WBuDtTFYG4O1MVcbI51gpBOMdIKRcoyUY6QcI+UYKcdIOUbKMVKOkXKMlGOkHCP1MlKGkTKMlGGk DCNl2CjDRhk2yrBRho0y7HOcfY6zz3H2Oc4+x9nnOPscZ5/jp/7/XN+Gc/FH0Rj7jLHPGPuMsc8Y +4yxzxj7jLHPGPuMsc8w+/SxTx/79LFPH/v0sU8f+/SxTx/79LFPnyQPS/KwJA8XTP+M2vW4KXiH BF8owfMl+CMS/BkJfq/kXiCdKelMSWdKOlPSmZLOlHSmpDMlnSnpTElnSjpTkjlsoptNdMJEJ0x0 wkQnTPT079x0muZO09xpmjtNc6dpvdi0XmxSm4PPOumUk0456ZSTTjnplJNOOemXnfTLTvplJ/2y k37ZSV/qpC910hknnXHSGSedcdIZJ51x0hknnXHSGSedcdIZJ51x0hk7acpOmrKTpuykKTtpyk6a /l7HEybgCRPwhAnoNAGdJqDTBHSagE4T0GkCOk1ApwnoNAGdJqDTBGw3AdtNwHYTsN0EbDcB26d/ ntsULDMFy0zBMlOwzBQsi33ZE//VwdtO/6bRV9ya9sa+EX09dmNUG7vJf3NqbI7/nuu/b4teC650 I8m4kWTcSDJuJBk3kowbScaNJONGknEjybiRZHQwo4MZHczoYEYHMzqY0cGcDuZ0MKeDOR3M/V7f i+vy77rRg170IXkqAzkdGNOBMR0Y04ExHRg79TPgr7pR/QoncBKv4T/+XPiNwVtjczH9GyCX/2d/ 0lIFkyqYVMGkCiZVMKmCSRVMqmBSBZMqmFTBpAomVTCpgkgFkQoiFUQqiFQQOfsGZ9/g7BtU0/kG z8xHVNOgmgbVNKimQTUNqglVE6omVM30T4CmnOvLznT6501fjk3fNy8Oij3/rIi6nU+38+l2Pt3O p9v5dL/u+ewJ3mnC36nKnCpzqsypMqfKnCpzqsypMqfKnCpzqsypMqfKXJAKzg76MYBRkz0ZHfXO T3jnJ7zzE975Ce/8xG/9tsE3Yt8IYs7h3NO/dfCN2Bz/PTc4N7jAeaScR8p5pJxHynmknEfKeaSc R8p5pJxHKih2enu8+t7pd+DpqR8D+LUhX++3ZA55V0e9q6Pe1VHv6qh3dVQ/M/qZ0c+Mfma8y4On f2sgo6dpPc3oaTp2S5SMfTNKBl/wDld6hyu9w5Xe4UrvcKV3uNI7XOkdrvQOV3qHK73DnzmDfmfQ 7wz6nUG/M+h3Bv3OIHQGoTMInUHoDML//TXigyprwIs4hEYcxhE04SU0owWt6MAb/ZTraNSlGz26 0aMbPbrRoxs9p75++6oJ/RVO4CRew1Q0qhujujGqG6O6UagbX3BuZzm3C53bW53bDOd2lnO70LlN Z2mG7hTqTqGbQE3scHBR8Oeqn/6dwCnVT6l+SvVTqp9S/bT7xp3XuPMaP/01o9dLc8/rfc3oN+kN 3uJPZ/rTmae+C9rpRDqdSKcT6XQinU6k04l0OpFOJ9LpRDq9pzf+PcJf/6zUf/wNkv2q7/RKZ3il M1SZik3/XkahV0x6xaRXTHrFpFdMesWkV0x6xaRXTHrF6Z9bKNWBUh0o1YFSHSjVgVLnX+r8S51/ qfMvdf6lMniODJ7j/Eudf6nzL3X+pc6/1PmXOv9S51/q/Eudf6nzL3X+pc6/VFVDqhpS1ZCqhlQ1 pKohm6XPZumzWfpslj6bpc9m6bNZ+myWPpulz2bps1n6nMSAk0g4iYSTSDiJhJNInN4s3U6i20l0 O4luJ9FtJs4wE+8zE2fr0CfMxBlm4n1m4mzd+gS/JoIvBUuCdwf34F7ch/uxFA9gGR7EQygOPqVb jbrVqFuNutWoW4261fgGt6/f7ORO3erUrU7d6tStTt3q1K1O3erUrU7d6tStTt3q1K1O81dm/srM X9mbfB7coENrdGiNDq3RoTU6tEZ3lurOUt1ZqjtLdWepnXsmh1xl3/6ARy62b7/PJVfZtz/gk4vt 2+/Hbo/2xe6IqmJHgotiTcG7Ys3BTBUtMaX34F7ch/uxFA9gGR7EQyie9rYz23sq/290yzig0gMq PeDdp737nHef8+5z3n3Ou8853wP/yU3TJA19p39K8ExVHTr9k4JnquiQdAzEpn/GZzodxSooVkGx CopVUKyCYhUUq6BYBcUqKFbB7c582JkPO/NhZz7szIed+fDrbykO34uDctqAF3EIjTiMI2jCS2hG C1rRgS5O6UYPetEHzys6lNehvA7ldWhUhyZ1aFKHJnVoUoem3dCpQ6/o0Cs69IoOvaJDr+hQSodS OpTSoZQO/bkO/aVknKdDl0nFWVJxng5dJhFn6dBHdeijLHm3dLRPb7tghnTMkI4Z0jFDOmZIxwzp mCEdM6RjhnTMkI4Pm/j3mvj3/l9fzRiV21dYdAzjOI4JTAZ/7B0PeMcD3vGAdzzgHQ+Yyi/GrvFu bnCO34h6nF+fs+uJ3SK338R3g3tidwXvjhVhSfBfg084ywFnOeAsB5zlgLMccJYDznLAWQ44ywFn OeAcB53joHMcdI6DznHQOQ46x0HnOOgcB53joHMcdH6Dzm/Q+Q06v0HnN+j8Bp3foPMbdH6Dzm/Q +Q06v0HnN/g7vjKb1Y2sbmRP//7V6/1EVlInkjqR1ImkTiSd3ZizG3N2Y85uzHmddeoOdbOP03eo q1Q+pPIhlQ+pfEjlQyofUvmQyodUPqTyIVM8qvqc6nOqz6k+p/qc6nOqH1f9uOrHVT+u+nFTPGmK J3VhXBfGdWFcF8Z1YVwXxnVhXBfGdWFcF8Z1YVwXxnVh/HfkfEgXhnRhSBdGdGFUF0Z1YVQXRnVh 1BT3vu5GvSHKsdSkWcix06TJHD1VfYnqS1RfovoS1ZeovkT1JaovUX2J6ktUf6/q96t+v+r3q36/ 6verfr/qq1Vfrfpq1Vervlr1LapvUX2t6mtVX6v6WtXXqr5W9bWqr1V9reprVV+r+lrV16r+pOpP qv6k6k+q/qTqp3+m4fOxa0zytdx6nT/fEJzvPK89vZlmy+D5zvXa05tpthw+KIcPymGpah9yY/lM 7KWoItYSTcVag1uCd6j+mOqPqf6Y6o+p/pjqj6n+mOqPqf6Y6o+pvvM3P13hXSS8eofPnvDZE6ey s9Nn2emz7PRZdvosO32WnT7LTp9lp8+y02fZ6bPcqYddetilh1162KWHXXrYpYcJPUzoYUIPE3qY 8IrPecXnfs+b4gk9PKGHJ/TwhB6e0MPp2/kteviSHv4v5u48Pur63vf4b2ZixCHRumvtrW3dtVYR bK1ra63VWq1o3eq5Xs85tl6EFBV3i0tLsS7UfWtt1WoRt6BEpQiisgiEACEQMoYAMtnDLBCYGUDt 7z5nGL20xXOO94/zuI8+Xk1Mft/l8/68P5/f9xdmkiWi+A4Nt6fh6TTciYaX0nB7Gp5Ow51oeKko 7xPlfTT8HQ3n0PCHNFxKv4tKz5C1Iq8Vea3Ia0VeK/JakdeKvFbktSKvLZ+RP+tJfBuv7XQXfhP/ b79BYpvuURfFc+4Fom8W/VLR/7Ac/TGi30H0V5ejP0b0O4j+atE/LvrHS68HHvRffl3+/eEkkU4S 6SSRThLpJJFOEulEkU4U6USRThTpxK1exTpZpJNFOlmkk0U6WaSTRTpZpJNFOlmkk0U6WaSTRTr5 s06DIvqKiLYT0eWi+Ypoiufay0XxXHCyKMaJYpwoxolinCjGiWKcKMaJYpwoxolinJz97DPfWTw+ nCOSOSKZI5I5IpkjZ4vkbJFI6kVSL5J6kdSLpF4k9SKpF0m9SOpFUi+SepHUi6ReJJtFslkkm0Wy WSSbRbL5n7r3eU5W54cL5W+Z/B1XPpueKdq9RXtX+Wx6poj3FvFd8neX/N3FvXeK/hXuPZl767n3 yGAwJfop0U+Jfkr0U6KfEv2U6KdEPyX6KVHs+i1UaKFCCxVaqNBChZbPOK8OkM8BVGihQgsVWqjQ QoUWKrRQoYUKLVRooUILFVqo0EKFFt28oJsXdPOCbl7QzQvb+kmHiAeJ9hiRDhLlMSJ7Pzg7cjCN DsGhOAxfx+H4Bo7AkRiEozAYQ3A0volv4Rh8G8fiOByPE3AiTsJ38F2cjO/hFHwfp+IHOA2n44c4 Az/CmTgLP8bvw3TkD3gCf8KTeApP4894Bs/iLxiP5zABz+MFvIiX8DJqi38ZCq/gVUxCHV5D8V+5 3/VcOwMzMQuz8Z7vzQlbI3MxD/WYr4f/1JPfJfr7TyiYoWCGghkKZiiYoWCGghkKZiiYoWCGghkK ZiiYoWCGghkKZiiYoWCGghkKZiiYoWCGghkKZiiYoWCGghkKZiiYoWCGghkKZiiYoWCGghkKZiiY oWCGghkKFt+LmKNgjoI5CuYomKNgjoI5CuYomKNgjoI5CuYomKNgjoI5CuYomKNgjoI5CuYomKNg joI5CuYomKNgjoJ5CuYpmKdgnoJ5CuYpuJqC6ym4noLrKbiegusjDZ4cFmAhFrlDFp8ciu8n/heK ZimapWiWolmKZimapWiWolmKZimapWiWolmKZimapWiWolmKZimapWiWolmKZimapWiWolmKZima pWiWolmKZimapWiWolmKZimapWiWolmKZimapWiWotnIfaK6Hw/gQTyEh/EIHsXvwwLFCxQvULxA 8QLFCxQvULxA8QLFCxQvULxA8QLFCxQvULxA8QLFCxQvULxA8QLFCxQvULxA8QLFC/+B4i0Uz1M8 T/E8xfMUz1O8g+IdFO+geEfpbHdJ8RVZkaioYqjAdqjE9hiAHRDHQFRjNG7BrbgNt+NXcJ+LuM9F 3Oci7nMR97lI8T4Xj+wU7Bv5KUagBiNxJa7C1bgGxaf9u+wjYR8J+0jYR8I+EvaRsI+EfSTsI2Ef CftIRL4QLonsjF2wK3bD7tgDe2Iv7I0vhvMjXw4XRPbFV/BVfA37YX8cgANxEP5//604Z4ezIkNx Ds7FT3Ce+M7HBbgQF2F02CxHzXLULEfNctQsR81y1CxHzXLULEfNctQsR82Ru425L+zk6k6u7uTq Tq7u5OpOru7k6s7IO0F15N2gMjIDMzELszFHhudiHuoxH/9Y2+d5pr0wvKF89q4pn7lr3IPmld5z 9FSwZ2xqcHTsXU+fyWC/WHtwbqwj2CXWGXwx1u2/e4LdYr3uwn2+tiY4OjiXU7o5pZtTujmlm1O6 OaWbU7o5pZtTujmlm1O6OaWbU7o5pZtTujmlm1O6OaWbU7o5pZtTujmll1P6OKWPU/o4pY9T+jil j1P6OKWPU/o4pY/qvVTvpXov1Xup3kv1FNVTVE9RPUX1FNVTVE9RPUX1FNVTVE9RPUX14vtg2/WK dr2iXa9o1yva9Yp2vaJdr2jXK9r1ina9ol2vaNcr2vWKdr2iXa9o1yva9Yp2vaJdr2jXK9r1ina9 ol2vaNcr2vWKdsoPpPwPKD+Q8j+g/LsU3yM2PfhacAE1W6nZSs1WarZSs5WardRspWYrNVup2UrN 1s/xr4FpamapmaVmlppZamapmaVmlppZamapmY2cHewaGYpzcC5+gvOMPx8X4EJchNHuyLfgVtyG 2/ErOJNRuJ/C/RTup3A/hfspnP7veoVS7Dwe3vKuwHPL7wo8NzYiOD2I+krxdf57BBW+P6D03HRJ 6T13pwc76o1VemOV3lilN1bpjVV6Y5XeWKU3VumNVXpjlZEHGXmOkQcZeU5p5D5G7mPkPkbuY+Q+ Ru5j5D5G7mPkPkbuY+RuRv7CyN2M/EVpZLWR1UZWG1ltZLWR1UZWG1ltZLWR1UYeWDo1XuKjU+Pn 2u2BpZ9xbRk5pKTBocV/EwjO57UVvLaC11bw2gpeW8FrK3htBa+t4LUVvLaC11bwWiOvNfJaI681 8lojrzXyWiOvNfJaI6818tpcXpvOa9N5bTqvTee16bw2ndem89p0XpvOa9P5ai5fzeWruXw1l6/m 8tVUvprKV1P5aipfTeWrqXw1la+m8tVUvprKV1P5aipfzdUv0/plWr9M65dp/TKtX6b1y7R+WfRd nu/yfJfnuzzf5fkuz3d5vsvzXZ7v8nyX57s83+X5Ls93eb7L812e7/J8l+e7PN/l+S7Pd3m+y/Nd nu/ykdfDLtVcF+zsPFBwHtjoPLDReWCj88BG54GNzgMJ54Gc80DOeSDnPJBzHsjp0p26dKcu3alL d+rSy4Pt1GJcLcbVYlwtxtViPBgqa8tkbZmsLZO1ZbK2TNaWydoyWVsma8tkbZmsLZO1pKwlZS0p a0lZS8paUtaSspaUtaSsJWWtQ9Y6Za1T1jplrVPWOmWtU9Y6Za1T1jplrdOdr8Odr8Odr8Odr8Od r0MmO2SyQyY7ZLJDJjtkcpVMrpLJVTK5SiZXyeQqmVwlk6tkcpVMrpLJVTK5SiY7/rPfPOTOt6s7 30B3voHufAPd+Qa68w3c1p2PhmeXXhH70+BLPH+xCvgS318sQ7NKzwpp54u080Xa+SLtfJF2vkg7 X6SdL9LOF2nni7TzRdr5Iu18kXa+SDtfpJ0v0s4XaeeLtPNF2vki7XyRdr5IO1+knS/Szhdp54u0 80Xa+SLtfJF2vkg7X6SdL9LOF2nni7TzRdr5Iu18kXa+SDtfpJ0vip7t5dlenu3l2V6e7eXZXp7t 5dlenu3l2V6e7eXZXp7t5dlenu3l2V6e7eXZXp7t5dlenu3l2V6e7eXZXp7t5dleTl39GSfXvm29 OoNTM5ya4dQMp2acXDtjxXcRn0fRJEWTFE1SNEnRJEWTFE1SNEnRJEWTFE1SNEnRJEWTFE1SNEnR JEWTFE1SNEnRJEWTFE1SNEnRJEWTFE1SNEnRJEWTFE1SNEnRJEWTFE1SNEnRJEWTFE1StPjbLZMU TVI0SdEkRZMUTVI0SdEkRZMUTVI0SdEkRZMUTVI0SdEkRZMUTVI0SdEkRZMUTVI0SdEkRZMUTeoC Waomt/l6l/d8fRuvkaVqF1W7qNpF1S6qNlK1MXhUtSdVe1K1J1V7UrUnVXtStSdVe1K1J1V7UrUn P8fpqvhO55RqT6n2lGpPqfaUak+p9pRqT6n2lGpPRQ5WXYfgUByGr+NwfANH4EgMwlEYjCE4Gt/E t3AMvo1jcRyOxwk4ESfhO/guTsb3cAq+j1PxA5yG0/FDnIEf4UychR9j293on38/2mg1dQtuxW24 Hb/CrzEGv8FY3IHfYsvvQSvoRgXdqKAbFXSjgm5U0I0KulEh8nud5g94An/Ck3gKT+PPeAbP4i8Y j+cwAc/jBbyIl/AyajERr+BVTEIdXsM77uXvYgZmYhZmb/u3IvyTk84L/1UXvLD8b13Hl/+d63hd cHHJXb3c1ctdvdzVy1293NXLXb3c1ctdvdzVy1293JXirhR3pbgrxV0p7kpxV4q7UtyV4q5U+bVn Ge7KcFeGuzLcleGuDHdluCvDXRnuynBXJXdVclcld1VyVyV3VXJXJXdVclcld1VyVyV3VXJXJXdV clcld1VyVyV3VXJXJXdVclcld1VyVyV3VXJXJXdVclcld1VyVyV3VXJXJXdVclcld1VyVyV3VXJX JXdVclcld1VyV4a7MtyV4a4Md2W2+Xq5z++uzH/+m6uCCu6q4K4K7qrgrgruquCuCu6q4K4K7qrg rgruquCuCu6q4K4K7qrgrgruquCuCu6q4K4K7qrgrgruquCuCu6qKLtrAHcN4K4B3DWAuwZ8hruy 3JXlrix3Zcv32NHbcFdzcCF3Leeu5dy1nLuWc9dy7lrOXcu5azl3Leeu5dy1nLuauKuJu5q4q4m7 mriribuauKuJu5q4q6n8bot67qrnrnruqueueu6q56567qrnrnruqv+Md1bMk6l5MjVPpubJ1DyZ midT82RqnkzNk6l5MjVPpuaV3llxn2eo+/EAHsRDeBiP4NHiT0Y55Q94An/Ck3gKT+PPeAbP4i8Y j+cwAc/jBbyIl/AyajERr+BVTEIdXsPrxd+HEAym8GAKzyjV72oKr6bwagqvpvBqCq+m8GoKr6bw agqvpvBqCndRuIvCXRTuonAXhbso3EXhLgp3UbiLwj0U7qZwN4W7KdxN4W4Kd1O4m8LdFO6mcLf6 javfuPqNq9+4+o2r37j6javfuPqNq9+4+o2r37j6javfuPqNq9+4+o2r37j6javfuPqNq9+4+o2r 37j6javfuPqNq9+4+o2r37j6javfuPqNq9+4+o2r37j6javfuPqNq9+4+u1Sv13qt0v9dqnfLq7o 4Yoerujhih6u6OGKHq7o4Yoerujhih6u6OGKHq7o4Yoerujhih6u6OGKnv/8qeO/9e6wrfrd1k+D /rF+f6F+byzX74nl+j2x9Nrbaz/n70T8r/4MsIm7mriribuauKuJu5q4q4m7mriribuauKvJiTLv RJl3osw7UeadKPNOlHknyrwTZd6JMu9EmXeizDtR5p0o806UeSfKvBNl3oky70SZd6LMO1HmnSjz TpR5J8q8E2XeiTLvRJl3osw7UeadKPNOlHknyrwTZd6JMu9EmXeizDtR5p0o806UeSfKvBNlnruy 3JXlrix3Zbkry11N3NXEXU3c1cRdTdy1hLuWcNcS7lrCXUu4awl3LeGuJdy1hLuWcNcS7lrCXU3c 1cddfdzVx1193NXHXX3c1cddfXpB3ikzs83ffjrH1+diHuoxv/RKoOLTz5eC6uixYXv0ezgt/Jfo 6eGV0TPCK2NnhjNj53lmurD0G1GLf+dgYvnvHEzkhXQwMHpk2Bcdgm/hJJwWLjZ6vtHzo2eGSzlp pZFtRrUFO7o65eqUq/PWW2VEypqrokN9vNDXLvb5ZajBneHy6F3hcut0B3Ejc0bmjOo0KmdUpytW u2K1GA4Xw+GunF9ao8uVXdZocWWXHTXY0QI7WhAtxRPOLf4GhfLvla4u/17p6mCAuSeYd4Jd1NpF rV3UWuMda7xTejXcLuYeZu5h5m439zBzF8y9wdwbzF3cc8LVidh5f9sQu/BvufJPm44o/7TpiPIr h2aVZrrUTJdac56ZLrXuvOhpwf8ww1lmOKv83s27y6+JOLT8GykGl38jxeDyb6S4KPiCma4y01X2 tMFsc812ldnmmunnZvq5marMdL+ZrjPTLmbZ1wz7muEWM1wfbG/ULCNmGbHMiGWu2MUVu/jug8FO 1FhPjfXRYeFz0SvCh6LDMQI14fp/8MfN/PEWPW/mj7eM3iBvQ3niQgzjiyt4YjhG4BfWOS/84FNv RFzfZy9D5fZiub0MNZ4hLy79fOpA323i0aG+emH4vtkazNZgtgazNZjt3X/I647lvO5YmnmVOIaG dcYmjS0Y+5GxHxn7kbGrjB1g7EAqx0vvM7jEx+J7Dbb8+/J7pdG/tq+59jU3Oiz4kr3NNerfKbuJ snmjxxi9Z/mncXuW/g13RPho8V+nS/u+ytobPp1hy+hjjF5Ufk//qaWRW0Y9aJT7u6sXuHqBqxf4 7u6+u7vvPMyp19r3deGm6PX8PSbYLjouzEQfVkOPheno4+oy6rubo2PCfBDx/5vk4XrVdYPIb8SY sDk61ix3mOWesCf6SPFvcYcfGvmhr15trlG41gzX8/nosNv8HdGHwmzU0w3vXk3xUbjWV29w5Y24 NWyM3obb8SuMCXaPjg0nRu913X3hB9H78QAexGPhFGtNCSrscqWrlrhqdfSRcJ19jwn77algx1eH G62y0QqbrVCMZjWH5jk074q8WTaaZaMdX2eXxfhGG3uLXY7RBcb62r2y/UiYDb5orunmmm7HPa6c a852c7ZHb/Lfo8Neo/pFkBJBSgQpEaSs97H1pltvuvXWRX8XzhFJi0haRNIikhaaNND9PXtptpfm YB8rdVqp00rr7WuG1bJWaLXCGitkrJCxQsYKGfusss9JVklZJRV1+qd0j32/bKUeK/VYqcdKPVZK W2mdeN6y2iqrrQp2sFreavlS9Ftm22C2dWZbZ6a8mTbo0TfI840YY42xlL3blfe4snSFzx/BY3zx eDm7PebsMSplVMqu++y6z6777LqvtM4nOzb/P+30Mdc8rpaLuVxb+ollpTlT5kyJIiWKTtekXJMq 5S739/sz492lnefFmtcRrjN+jDnHWvdun9/DB/dy1yNBXPf7RIFrZWs0bgn2dvVHdrjWDte6eqM4 18reBqO+YQd5O9jwqXuKHix6bJ0drDNyzqe1syGIlb43BmNVxk7WqrdWvavTrk5bq1hdrXa2nfW6 rddd0vZe//2Q2niYsx7ztcfdwWKlet0S4cZgSLRWDl8P9oi+FS6KTse7XDnD3maGt0VnhU9HZ2OO e9H88JfRheGYaJNrmn1chiyV12K9OXLhvdF8+Ga0gE3q7uPwj7FA36kIe2Lb+zgA1T7fI8zF9sRe OBiH4PBwQ+wId/JB4fTYURiMIXruMe66x4WvxdxnP/1LR+cHX4hdEFSV34d0pE7/ig57pE7/ip7U 4871rNhqMYP6M8Olotggig2i2BSd6+N89/OFutlSUTb7uAw9PNwrizn1l+f+AjaH60Twgd1/YPcf xPbWYY8I2+1yvV2ut8v1Mac5O0wGe5VXbaXfRqu2WDVt1bRVP7Jqh1UTVm2x6nqrtli1xWp5q/Vb rd9K/Vbqt1K/VTZZJWeVnFVyVkgHI63w8+gL4c1W2Rh9PXwl+tdwdHQK3tIXpuNdzNA954Tjo/O5 p8l/L1XtifBn0ffDadFWLEcbVmBleHl0lY9J17WHk6MdPu9EN3qCa6O94ZPRPp+vQSq8Lpr2MYOs U8JarPN5P9aH50c36BR5ERawKTyRdu9FP/S9j/Bx+Eb0bz6GMhhBFLFwFmdcGtvO55Xh72JxZ4KB Pq9y3q8Om2M7hVfFvoCdsQt2C7/KOUM4ZwjnDJGLYbEvhtfE9vG9L2Hf4Oexr/r4NewXfju2Pw7w /QP990E4ONyP0/aLHerzr+Pw8Guxb4QnU/oZSl9P6espfT3XnSqnf4h90zXfwjHhPbFv+3gsjgvf jB3v4wk40ZnlJPv4js+/G15cftXjKvfQp9xDr3AH/oq771diw0rnj3eDw2RptSytlqXV/LF6K3+s 4I0u3kjI2GreSPBGgspdVO6ibhefrKTuCuquoG4nRdv5ZSUFu3hmJc+spFovhdZSaC2F1op4rYjX inStKJOibBdluyjbRZkVWUZEK0ShNwbHqasT1NNKtbQyOIjP8vzVw189dt5s5812vtjOi3XUUHbz MjtuLtfRMrtexjdftvNWO2+18ya7nWe3XXbaaocd8thpl0122WSXTfI2UL665KvLjhN2nLDjpeU6 e9+O37fj9+14abHO7LYpONiOFtjRAjuaZ0dddvRGuarb7WiB3bTbTbvd7Go3a+xmjd2spuMqOnbR savcoxJ0bLG7NXRsoWMLB24s96l2u2y3y3a7rLK7drtrt7tGu1tpd4vtbrHdLba7D+jZZodz7LDd ne1ZVV7c2Sy1OhtzVfl8O1ioEyx1h2v2cVnYoUp7nBD3Lf6dVWP66b6R7nm6543ZzFdt/NTpXPQs 5V9ALT65YmZ49ac9eq4zxvzwiWJ/kcdn5fFZ541nnXBfoEgt50zkttft6a/+ewpmUmAWRWZjLvXm uzstDN+OLtb7tuT0bXt8W//I6hV9ekBWnWblcLGctcpZq/212F9LsJ+V7rXSbVZq/7vuNNPdbJb7 2GzM9b35YWiVDeU+uMEKG6xQa4U6HafRKu9Z5T2r/OzvcrBfOMqKo1T1GrlIykVSLjpK2tNcFRZf OzLIbgbR8l1azqFIjyeUIPxYdj+W3Y8p/S33+qKWM0U4S8Sz0RNUyuc6+Vwnn+tKvfZ20TwikndE 8oBIHuC6Rq5rNPec6Cx3zNmYEz4jog+5rlFEXSK59jN67R3lXjtNr33nH3rt7SKv26rX3rZVrx3F vaO26rXD9NrGrXrt+Xrtwq167Vuf0WtHlXvtM9S9rdxra8q9tkavrdFra/TaGsofR/nTKH8a5U/T a8fqtdfrtTV6bQ0NL9Jra/TaGlk5VVZOlZV/0Wtr9Noa2TlVdk7Va2v02hpZ+p5e+6+q5mUq307l 26l8u8ydqdeO02tr9NoaFfQrvbZGr61RSbfqtTV6bY1e+z9l+DS9tkaWi78j8fzyq/Rflu3r9dq9 9Nq99NpFeu1LweWy9zPZu1r2XpW9UbI3SvaWyt7SUheboRLnhLNlbo3MLZW5bpm7RuYaZK5B5hpk rkHmGmTuXplrkLW3Za1B1hpkrUHW/qesvS5rDbLWIGuPyVqDrDXI2huy9oasNchag6xNlLV5+k9O xt6WsXYZa5CxBtlqkK0G2WqQrQbZWixbb8hWg2zVy9ZjstUgW2/J1hLZmiJbU2RrimxNka3vy9a9 snWvbN0rW2/L1hzZmiJbU2TrEtmaIltTZOti2bpYtibK1hTZmiJbd8rWnbI1RbamyNY42ZotW92y 1SZbbbLVJlsPy9YS2ZoiW1NKZ7Nv+3gsjscJONG57SR7+I7Pvxv+RaZ+LFPvyFTx/Y/flJ1FwYGy 87zsvKRTNOlJ62RpoSw9L0vPy0xGZb6kMpepzGU6xjuylNYxXteX0jLVq2u8rmu8LmPPys5sNdUr EwtlYBaFE2ojqTaSVO5W+0upmFX/S9X/UmrOotjLlHiZEi/bZfEdC+cU79nBATyymEcW80gDf/zV yh38sViuT5bTNjltk8v5VvnAKo1WaZTPydHiuxgDT9IVdNrexwGo0qeq3dX2oNme2Av7Bl+nfYHm rTRvpfX7dO6k8wI6L6DzAjo30/Z9FZCg5RLn9R53n+J9ckj4kbN/bel8OZxCj1HoMQrNsM/bqLDJ vsbbV5191Ym+r3xOqLWnWnuq9UQwMxxn5CwjZ4mwYOTvjHrr05P7ljviyk9OFUZk9em1WG++XPiC K99z5XviXunql1w9QdzrjZhgxATn6KSrc04peXkpYLMTRiCyyrDPVQtctcAdMqkWcuH7rup0Vaer esxXPAc3unKDKxtd2egOnuCLlUghyxNrsd5TyCZs1sk/dreuCJcZ1Sa/z8vnFK5r4brivWly6ZVU xVdRFd23sxk2mGGDGTaUzwOrrL/KbH2lk0rANRWl9but311+p9sRnjeOcl9tdl9tLqnSZ5Y+s3xg ljazpMySMssHZsma5U2zFON90yxvUiXru2ux5Tz3YVG/0pm/wn2rfO6X3YTvFvXLumIttuyyf6tT S0rMy4xcbuSHYl5n9HKjlwdRkRZ/LjfYs2TCXS1lns1mjofrgx0/vYsnVViqlMvFZl1p1pWuWm7G 1/SeDWXtXzPja7Hi34ctjpxt5F+N7DfyTSO7PnlqKXayrf1ixJv0H0r3f/dMWnwP3Q7GrzNmnTFr jFlTfq7KWqnXuKxx2VLkU63ynhXmblVrS0X8shH5Um3FSz+t+k05u+9bZVjp53HF0a+UekHKU1VW n1iL9br6ppI30tYq6tBi9JXln3UtMvqi0r8j7GL0SqMni3CBPr/MLG/b8cStamlyuTL+SKNiRyme u/9o538069tmvdtstaUsL7f28tLZN6e+NoUzjUrbw3Ij0kakuSdBuSS/59Rv3n2igM36QeBOu0WV sa4cy2//xm//Jp85O8qbswD3eOeVvZ0Oj8Ag+ToKg3F0uEmf2E3339tan5zRjqD3IPEfhcE4uvRe vZ7ibyQI4q7OuHqjqzOuzriy4MqCKwvlp9s+XXJt8OVINJwTiaEC26ES22MAdkAcA1Ft/SpPsLuF T+h+a3S/NbrfGitMtMJEHTCjA/bqgL06YLe+1qXTrbFKhpLPUPKZ0qt/i6/8Ldbs7vrohthuanAP Ue2JvXCwujkEh+MIMw3ipKMwGEN87ehgJ320+Ozcafa0OnZqCAaJvEXkLXrqbk6PeztF7se3++OA 0k8hNv7T8/1P7e2ScA2tqly9B+X2xF74v88EfaU1j3P1SVTdwdzZ0s8L9nNO2R+DfOcoDMbR1ij+ ncsBrugv/9xjke8u8t1F5RXvt+L9wfa+m/m7DBez8UkXKq6y0Bw5q7RYpWXrM6x5ivvpDCJ2lwt2 jVX7bLfwSfvP2H/G/jPGvWHcGyLPbZWRtFjWiCMjI8X3RL4oIy/KyC4yUvxZfCLY2Uyv/kNup5tp upnWm2mDmTaYaaOZ1pdzu8lM8800/5OZShlYbf/dRr9v9PtG58tPflt7ulMcm82Qo9geTvt7Yi8c jENwuOfuLU8BH5Q0WWG+FeZbYb6s+Zaab4n5lphvCU/0lV5jul/sfwX7BacGl4WPBz/DzzEqfCq4 ie4345cYjVvQHj4WdKAT/aXf2XZfsBkf4iN8HN4XOThsjByCQ3EYvg7PipFv4AgciUE4CoMxBEfj m/gWjsG3cSyOw/E4ASfiJHwH38XJ+B5OwfdxKn6A03A6fogz8COcibPwYwwL9oy8E74deTecHJmB mZiF2ZgTvhWZi3mox3wdZv9gl3BhsCu4LNgde2BPHISDcQgOxWE4Az/CmTgLP8bZGIpzcC7Ox0W4 LHyC4k9Q/AmK3xJcE/4xuBbX4XrcgJucJG7GLzEat+DA4H7ngQfwIB7Cw3gE4/EcJuB5vIB6zEcD FmAhFqERi+GJLViCpWhGAu3hJHmeJM+Tyr9xc17g3B7kkEcBm8KJcj9R7ifK/US5nxiMDCqCnYPt UIntMQA7II6BqEI1dsSxwR7BcbgsvJkON9PhZjpcS4cr6HAFHa6gwxV0uCK40Qw3hTW0qKFFDS1q aFET/DrYKRiD32As7sBvcSfuwt24B1OCLwdvoj28SWQ3iewmkT0ksgkimyCyCSKbILIJwUY73hSO Ft1o0Y0W3WjRjY78PmyO/AFP4E94Ek/hafwZz+BZ/AXj8Rwm4Hm8gBfxEl5GLSbiFbyKSajDa2Fz 9Ej38UGeqYf4eBJOC2+Onu7J7QwM9d/DPJNfEY6IDseIcET534GvKf878DWxazwtXevpqTHYLrY4 2C22JPhqrNl5c5nO3e502qGfdgYHx7p87C7+Vjkf1+hD0dgiV7fLSPGz4jtK9gxyMlolo1UyWiWj VTJaRZ8q+aiS0arS/6qxI3YJW1VKq0ppVSmtKqVVpbSqlFaV0qpSWlVKq0pplf1dZX/Xz/W7qy8L L+eUyznl8uB/O1MNwxUYjhGowS8wElfiKlyNUeEwrrqSq67kqiu56kquupKjTuGoUzjqFI46haNO 4ag4R8U5Ks5RcY6Kc1Sco+IcFeeoOEcV/wZ1mxpsU4NtarBNDbapwTY12KYG29RgmxpsU4Nt3Lc3 9+2tFjNqMaMWM2oxoxYzajGjFjNqMaMWM2oxoxYzajGjFot/O/cqjr2KY6/6nL87+lHuHs/d47l7 PHeP5+7xnH0jZ9/I2Tdy9o2cfaOendCzE3p2Qs9O6NkJPTuhZyf07ISendCzE3p2Qs9O6NkJPTuh Zyf07ISendCzE3p2Qs9O6NkJPTuhZyf07ISendCzE3p2Qs9O6NkJPTuhZyf07ISendCzE3p2Qs9O 6NkJPTuhZyf07ETk7GCPyFCcg3PxE/x3/T7Id8I694pp7hXT3CumuVdMc6+Y5l5R515R515R515R 515RF2kI4hHPdJGFWFR8jYQz7iAMQfHVHCf5uOUVHbeq6LNU9Fmlir7Y08xlGKbCt6rsaE3pPZ4n qO4rVPcJqvsK5457Y6M8sU8NZ8SmBzvG3tUBFjm7LHaaWBLsqdL7VHos1uIss6Xat1Pt+5f++l6f r6/RDWcEFeFPgu1Qie0xADsgjoGoQjV2xE7hcSq4TQW3qeA2FdymgtuCY7npOHyuCg4uDn6Gn2NU cExwjUq6FtfhetxQ7PPBYcHN+CVG4xb8Ovx+MAa/wVjcgd/iTtyFu3EPfhce/x+8l34bf5MyfCZ4 E/Wef+ajAQuwEIvQiMVowhIsRTMSaA/OCTrQif7gqGC9/rgBOeRRwKbggGAzPsRH+Dg4wPPDQs8P Cz0/LPT8sNDzw0LPDws9Pyz0/LDQ88NCzw8LPT8sjHwhfDqyM3bBrtgNu2MP7Im9sDe+GD4T+XL4 fGRffAVfxdewH/bHATgQB+HssDYyFOfgXPwEnjci5+MCeO6IXIRLgjMjlwbnRv41uCHyb8H3I/8e HB+5LLggMjp8M3ILbsVtuB2/wq8xBr/BWNyB3+Juc90XLo7cjwfwIB7Cw3gEj3oCPzI8LzoEx4ar oyf5+D0fTwsujJ4eHBY9A0PDC1VJuyppjw4Lzo9eERwcHY4RqPG18usCnK1Pdrb+buzNcHxsenhm LBnOcx/bLdbhFN/laaLHM1lvsE+sz/1xTZiP7B1U/G1jsB0qsT0GYAfEMRBVqMaO2OlvTe5x09zj prnHTXOPm+YeN809bpoKqVMhdSqkToXUqZA6FXKLCrlFhdSpkDoVUqdC6lRInQqpUyF1KqROhdSp kDoVUqdCdlIhO6mQnVRCtUqoVgnVKqFaJVSrBPcn/AZjcQd+iztxF+7GPfjd32YG94VNqmG4ahiu GoarhuGqYbhqGB486nuP4Q94An/En/AknsLT+DOewbP4C8Y7iT2HCXgeL+BFX38JtZiIV/AqJqEO r+F1vIHJ+CumhL9Wdb8Opvp8Gt7CdLyNdzADMzELs/Ee5mAu5qHeuvPRgAVYiEVoxGI0YQmWohnL jGlBwufv+9iK5WjDinBysBKr8AFWI4lNTjqb8SE+wsfBAJU7XOUOV7nDVe5wlTtc5Q5XucNV7nCV O1zlDle5w1XuCJU7QuWOULkjVO4IlTtC5Y5QuSNU7giVO0LljlS5I1XuSJU7UuWOVLkjVe5IlTtS 5Y5UuSNV7kiVO0rljlK5o1Tu/2HuO8Ciura219770JvSpImIqNgHu4hiSyxRUKyxggiKIhDAEqJG 0dhS9CaxJ2pssWGIvWF3LBErGoQMRqVYUNSoWOf879kz5npzcz+T3Hu/73eetfacfXZde7V3nDmk wHJTYLmJsNxEWG4iLDcRlpvIBmGtg6m1+W8qNIX11oH11oH1tmGx6gUWB80fg3IsaBxoPOh9UBpo Amgi1jUJ9CFoMmgKKB00FTQN9BFoOmgGaCZolvwuZCL7BOWnoM9Ac0Bz1amw+qmw+qmw+qmw+qmw +qmw+qmw+qlsG9psB+0A7QTtAu0G7QHtBWWB9oH2gw6oRYjDRYjDRYjDRYjDRYjDRUwPD/L7v9Qp Ydmg06Azagk8jB08jB08zG54GDt4mN3wME68h7EcnmU2PMtseBZbeJPZ8CZ94E36wJsEw5u0gjcZ I/aqe0QWaJ+xVBxQtyHu/igOqUfFYfUzeJlp8DBPRBEwfDH63ECMvolYe0tdCi+j/YXLqWoorDYU VhsKqw2F1YbCakNhtaGw2lBYbSisNhTWmgVrzYK1ZsFas2CtWbDWLFjeLljeLljeLljeLljeLljR MVjRMVhDBqwhA9aQAWvIgDVkwBoyYA0ZsIYMWEMGrCED1pABa8iAFWRA6wuh9YXQ+kJofSG0vhBa XyhOq6vEWfhIIENxXo0WF9RdIge7u6TmI6MwIE5PNT6iaaCPQNNBM0AzQbNAs0Efgz4BzVX12E0P 7KYHdtMDu+mB3fTAbnrA9+jhe/TwPXr4Hj18jx6+Rw/fo4fv0cP36OF79PA9evgePXyPHhIIgwTC IIEwSCAMEgiD79HD9+jhe/TwPXr4Hj18jx6+Rw/fo4fv0cP36OF79PA9evgePaQ2DFIbBt+jh+/R w/fo4Xv08D16+B49fI8evkcP36OH79HD9+jhe/TwPXr4Hj2kHQ5ph0Pa4ZB2OKQdDmmHQ9rhkHY4 pB0OaYdD2uGQdjh8jx6+Rw+ph8P36OF79PA9evgePU4hHaeQjlNIxymk4xTScQrpyPm3I+ffjpx/ O/L41cjjM5DHZyCPz0Aen4E8PsP8PNsc5PI5yOVzkMvnIJfPIaO6jFR1GSMQU5fhRN9Ffngap7oA p/qBOG804lS/wal2Rq64DSc7Die7mO4B6XkC6XkC6Xkic/GEz/ME0vNERuYJpOcJfOeJ+OMJpOeJ 2NQYkbAIkbAIkbAIkbAIkbAIkbAIkRDoElQLVBtUBxRM3kB73oiEFxEJLyISXkQkvIhIeBGR8CIi 4UVEwouIhBcRCS8iEl4E2msLtNcWaK8t0J4BaM8AtGcA2jMA7RmA9gxAewagPQPQngFozwC0ZwDa awu0NxxobzjQ3nCgveFAe8PNfzW2FhBfLSC+WkB8tYD4agHx+QDx+QDx+QDx+QDx+QDx+QDx+QDx +QDx+QDx+dBn1AAafRUafRUafRUafRUafRUaffVfPOW6EVBfI2hMLjQmFxqTC43JhcbkQmNyoTG5 0JhcaEwuNCYXGpMLjcmFpuRCA4ZAA4ZAA4YA9RUA9RUA9RUA9RUA9RUA9RUA9RUA9RUA9RUA9RUA 9RVAW96BtsRCW2KhLbHQllhoSyw9AdJ+qjaCtjSCtjSCtjSCtjRinCyZACkgC5AlyApkDbIB2YLs QA7ab6wQVXqAIkA9QUANQGHZQGHZQGHZQGHZQGHZQGHZQGHZQGHZQGHZQGHZQGHZQGHZQGHZQGHZ QGHZQGHZQGHZQGHZQGHZQGHZQGHZQGHZQGHZQGHZQGHZQGHZ8P4T4f0nwvtPhPefCO8/Ed5/Ijx/ Gjx/Gjx/Gjx/Gjx/2u+gME+gsMpAYZ7w/rlAYZ7w/rlAYZ2BwloAhbXg3YDMepAfIkEuIkEukFgc kFg4kFg4kFg4okIuTyDB11Mlvok434lyF+iwOpQfUTfzo6Bj6kL+g+rOC6gJfwT09hh5bTnopTpI uJKTaKCuFkHqRtEQ1AjUXN0k9pI9UFwDRJPvYaXHxFlEjfNkBcvcChRnAcs0IrrkAMl9YEZywvy5 jUCUKRE3EWFuof62egdYSkFUsABZgqxA1iAbkC3IDmQPcgA5gpzUPchP85Gf5iM6ZSI6ZSI6ZSI6 ZSI6ZSI6ZSI6ZSI6ZSI6ZSI6ZQJdHX71xLg/+ZuxfORC+ciF8pEL5SMXykculI9cKB+5UD5yoXzk QvnIg/KRB+UjD8pHHpSPPCgfeVA+8qB85EH5yIPykQflIw8yIA8yIA8yIA8yIA8yIGcxIGcxIGcx IGcxIGcxIGcxIGcxIGcxIGcxIGcxIGcxIGcxIDe5jNzkMnKTy8hNLiM3uYzc5DJyk8vITS4jX8hE vpCJXCET6GMncoI85AR5QBW9cSKliPcvEOszcQqliPXhiPUvxGPjDVEOBPJEtRJPjeXimTFfPFct xQtjiXiphgoj6lXVU7Ew3lAs1XaKlWqlWBvLFRtjvmKrWip2xhLFXg1VHFDvqAKbIAZnwlPfEhep vtD+/mAneLAl8GBL4MGWwIMtgQdbAsvOg2XnwbLzYNl5sOy8/++fsaX9JkYv/7JAKSy4FBZcCgsu hQWXwioXwioXwgIvwAIvwAIv8FXqDfmNCNP/lV+FZV2FReXCcpaIM1QF8e1nWM0nxHEyG2EXs2Fx u6mF2EODxH5qLA6QB9ruEIeA/g5TTXGawtAvTJyD9Zyn1uICOYscaogxrsDyfMlaXEPtdaoNewuD vdUQN+htjHvI/HlpHcx0UN2A9l/IOTNxbySscg85ou4Ers5In/lPT4ZgcRSKkz1DQTjVEMzQFfrT GfOZaoKgXeWobQft2gPtuiWf4nObGGa5Tj64ai0/n62EttUxn/bXT4upHlrUx9UZCsVuXHHPF/vS fuvTT80WqRSMtR5SWiECctQcx9UPaJ2lGpDLluHKgKt4csDVM1wdJ2dkA6HIBkKRDYQiGwhFNhCK bCAU2UAosoFQjBSKbCAU2UCo6E1uoj9yicGgeOxpD/KNA8iPD8JXWMtxd6sPUWvAjMViPyR8AJZ0 UN2ODPo21pmK9e/GGFlohZVhnQ7kzM5SNXaOdNjFYKy5veiPVqbnQ9STz4eIVw9qvwURY9VrYj41 FQuoGea5ixOoDivdpLSghkow6bCzAeSLHr6YpzEkn0p+mOmONr+cyQEzFGGGY2Igeg9C+0iUUShT cfJn1cvIm0qRMz2V53qJrNELMRM9tNbuaOmOljZoeRctyiCR67BU+AdE7xfar7Kk/IG1kIuV4oSc YNXn5Hg5kPZF9MKYmqfHmL3VG9r3HNGjNjTUSra+qD5EvvX6mAOh95Gg0Vh7KiLIGfU+Zi/DOu/i 9N0w9iP0Oopx7TDuE/DekFE/UCq0/DQkfgYtzmI15yDx81j7RYxgWsUL6G9v1PZTH8vn9WvP6k/G nVTyRE8brMgSPR+j5wv0dMBcRm3X6Plc+/8V6kiFoCLQU6oJBF0TCLomEHRNIOiaGPldjKwTA2GF g2iIiEQZhXI0cEcy1jNWXSkm4FznU3OcZwgkdhYzBkvZnle/lrPlqJeg367IXJ+Zz7ghZNAba+gH mQ4EDdKepI8yCmUqeWHdmnVZY722WGuJ+JEqyFPfix6H0KMQPbzQoxA9vNCjOVpXwJzF8uTPq88x 7xP0LJS9cuQz7E2/avIz/6rJT4yBt7hG/vAEZbBHW3gMT3iMivADe6FzJvnnoZVATRnk2Bvv+knd lE86Eik49XHwacVY9w3MeFO9K/XhZ/QrRD9bjG6NkTnu5GH9w9T7yI7vIzu+j4z3Plq+ePWERbS2 kq2v45SLIakSrOkmcv5bGOW2Wgr9rSRP+ax8vm5/rGswKAUrHgM/dw0yvo4TLoR2yp3AH93A/m+q p7TPzOTczzH3c8z93Lyz0lffmcYoHKPUxvwVMEo5RjFiFO2ZZNYY4SrWwKEnw6grxYBiQWnUgT4A TQBNBE2iDhjVCaPWNT93tIf5eaM9YPPfQlKbIaks6Mkx6Eln6ElXsV79G9b9A7xhDdOM8MfajDfU POhIMHQkWGmFvNoaIz82nx03nx2X8tJ2elP7ZSNabMLca8yt3M2t3DH3XbRsKJH+Te2vS4t442HE +juI7T8jlt9B7P5ZCTQW4bzjjXdRW4aaMiVQbY1R440F4jHk8Ry9X8C+XqqnFQu1HHH/iWKnPkTL 02j5tux7EHfPoeYcamxl37viGeZ7jp29VC8ihzAqyM7R14hWF5ErGNEyFLYdbyzGLEZkIQ+xslLx FOVzzPoC2mHq+QKzGpF9PMSKSxVrlLZYhR3qTSO9wA4eQTvikbeUE8MoZRjFiFFUoX3DTJvbkhh6 l6G3Eb1V9LxhXkMtTU7GuVjDNfSuht756P1YAKXK1b+Avr2EZhgR11T1JdZyDaNVw2j5GO2xYqPm yF3ZqbmKPVVAJnQLI7/EmjK0SKJyjPgE6zAII3H0eoK5DYoD3geqVbUWxjNoUYL5NEnloUUJxtSk lIcxgHF/e144ffM5ofcbzke2leeCtm84D+zx3zwH+LQ/KX9Y+n9Y7tjjv5C3vPO7ciZHxZVsFDes z4NsFS+M5o0+PoiblfHeF/eq4J4/7gXgujru1cC9mvAriuKOGbxx1w9ldZyJveKKKzf1rlIJ83th Bm/MpI3li/oqqK+K+gDUV0c9xsEpaK21mb3NLbSZtLGcsS6Ou0WKO2oqgTzIF+tzRssijOmL9XGs j6NXkeKH+1VB/qgPQJvqqKuB9zWxd0eMYsBatR1yxRNr9SIL8yhabwPWr+2QK9VwLwD3TL059usK coPuuWPNHhjXC3vxxun7YK7K2r5wvwru++G+P+4HoK467tfA/ZrYH3aBs3HDuO6orQTyUC9hDUZI 55rig7OsjD37ok0VtPHD/aogf7SphjYBaFMDbWoiumjnZC/l6kGuWIcmsSdYhyvWYYd12EvZ+uM6 QErwCdbgijXYaadCQu7dyyxn0+o16Qm5b1OPMvOqOTn9VZ2A1d6F/H6jF7D2BuTwZ3UDvXRk9a/0 A3erk8t/SkcwWl3s+i/qCXoHUsV/V1cwSgttR/8ZfcFJnJTn+Jd0RsYGhz+rN9KrBwJX34QnjYTH 8YFX6wZcXQav9hZw9S14n2Hwan7wasHA1TfhUSPhjXzg1boBV5fBq70FXH0LnmkYvJofvFqw4mp8 DInUg0RqQSK1FA9ce6p1IRFHrCoIUqkBqVRXfFFfBe380KYqyB/X1dAuAO2qo10NtKsJrbEBerEH 7ggFynQAunRBxumKbDMAWUVz5ApHkXE5wQoGAVXVI6Jg4Kba1BYvHb1DPSmI+lBf1L6LfCiERtAn 1IU+o42USJtoB97tpn20kA7g9TUdpku0lHKRYW+mEuZGB5g386Yy5svq0T3WlXVjxMJZL8ZZfzaI WbMhbBizZ3F4ObN4lsBc2Bi2kLmzxXgFs6/wasmW4hXC1rH1rBU7wM6wUK7jDVk4b8ybsQgezINZ H96ah7K+vD3vwN7lb/O32QDeib/DBvJuvBuL5D14TxbF+/B+bBgfwAew4XwIH8JG8GE8hsXx4Xw4 G8XjeAKL58l8LEvm4/kMNo7P4p+yGXwOn88+4Qv5IvYlX8W/Z/P5Fn6UreLH+CW2g+fy6+wYv8Fv swu8jN9jP/IHvJxd5k/5c3aFq4LYNcGFYIXCSjiwYuEknNkd4Spc2X3hLrzYA1FFVGHloqrwZ09E gKjOnomaohZ7IeqKekwVDUQDzkSQaMi5aCyackUEi5bcSrQSrbmNaCPacDvRTrTj9qKD6MAdRDcR zh1FL9GPVxT9RTRHviNGcz+RLMZxfzFBTOCBYpKYxGuJ+WIBry02iU28rtgqtvJ6YofYweuLXeIw byBOix95sLgmbvMO4rFQeZhioTjyfoqrEsiHKq2UVnwcNIWBbFmw5UkS0e8nx5Pr8OSYUZQQH5Wa QIuBxVnPiHZ+wD+kqvLbdZbkTVWB3mtDsxpDo9pTOPXGGJ1pAEXRcHM7ByB6H/InF6oD3WtCLZF1 d4cOMujdQBoKDVTQx9TWETGnMlUjV6qLeZpCP9+iHtBWDs0dRNEUh7jNI8K7+VFIr4h3/Gik7OcC fbdBnu9BAeQGnW9GragNvU0RBMwDLNiVBgMDmNrCy2EnVciTqpM71adG1JxawzY6wjLexUoCqRsN AVoYZR5Z+yahH3lRDaCYBtQCttSOOlEvAlagWhRGkbCieBod3TAlms+VfLHkqyTfJPlOyQ9FR8Wn 8lOS50j+k+SFkpdK/jA6KiWGv9C44JJbS+4ouavkXtHRo5OEn+Q1JK8reUPJm0veelh83HDRQfIu kncflpA4WvSRfKDkQyUfIXmC5KmxyVHRIk3yaZJ/JvlCyVdIvhGDRYntku+V/FB8wpjR4rjkpyXP kTxP8p8lL45PjI4XpZI/kPyZxhXCzWTFUnJ7yZ0l95DcV/KARBRKbcl1kjeVPETydpJ3SkwelqCE Sd5L8v5JWn2k5LGSx0ueLPl4ySelQObKNMlnS/655AslXyr5mpS4hFhlo+SbJd8p+T7Jj0h+MmV0 dJJyVvICyUslf6ZxC2vJ3VPGDE2xCJC8tuQ6yZtKHiJ5u5QxSSkWnSQPk7yX5P0lj5Q8NhUrt4iX PFny8ZJPknya5LNhTgJ2WQkW8Vfece2XsX+iZLCFN3PlD3Cff+J2b+QCPsMGNv1X3jF4sN/yCn+A c7l7jpG0K2b2nRq3/gPc6Q9wr3/ijn+AV5TrErJkr3Ftva/X2b+RW8D3ucKbmjTi37tyN1/9kXkZ PPObucMbuD+8fxhizGB45wQaS5NoOjKb+chl1iDL2Y4MR0+nkdsUUDHdpcdkZJbMEXmKL6vB6rOm rDV7m4WZzpVVMJde5tLPXDaF9mtliOma+5mu+Vzz9VlTKbxM9cLcXnQ316eZy/nm8rSpRFZqKs33 lfXmMs9UWjQ2lVar5Kkym59M17ZNzWUb0zy2XczXs83lC1NpH2iyNfufTKWTpaneaYS5PGkuc8yl eV6nx5jPFhTN5kkLGMq+BLfGTpdoNsAeaViVFPGW6Cg6ic6afXBn7gzlc+XusgfaCketrXCAjjKc DoPPMdkO8nKyZ/fYPVw+wliMPWPPiDOVqSS4BbcghdtxO7LgFXgFsuRu3I2suBcHSuH+3J9seCAP JFvRGTPbYaxK2F26tmzmRB8yL1aZJrNAFkjTkKkOpI+QnY6mmSyRJdJs9h5LpY/ZbDab5iBbXURz kZF2p895Kh9DW/g45EbbeBpPo+18Ip9EO/g0Po128Rl8Bu3mX/IvaQ9fwBfQXuSTP1KWcMAe7yO7 a0y/IJfrQA+xmrrkwpeJriJcxIrhYqQYJVLEGDFOvC8miplilpgtPhafiE/F15oU+FK+FE7qHfEO JBUmwoiLYSKGhBgh4sgCuV8yWYlUkUrWYqwYCzwwXozHzpENkh2ywalAB0vEEkhWSN/xdxn7aqfA W3LtbKx4EA/C2TTl0BvegrfAnRAeAll34B0g6y68C2TdHXKwRGsPyFfHm/Dm6N2ed+bhvBV/B/U2 f3wUns7TMesX/AvoAScNk/kqVRQ/parir1RTApTqSg2J3pnYDVRDcvUer62+itSceK2FoqFeUwuf 11r4vXaPa//HhNakaGiRKYFKoNQLbV5XxU1xVyopHoqn4qV4Kz4aKvx1Xo4s0klxVlyQI1sqVoq1 YqPYKnaKveKgOCpOSgWlItookPSHWILWhyODbg002lZpCwvgyFs9xBqxVmwU34kj4qjQi2PiuDgh ToofxCmRLUrFHXFXlIl74r54IH4RD8Uj+RnXarEaI34rvsVaNogNOHfk89iHNoeiZe+/jr4arTbg 7m6xR+wVWWKf2C8OiIPikDiMdtdFoSgSxaJE3BA3xS3000ZfI9Zg9LViLUbfKDZi9O/Edxj9iMjG 6KVYgzZ6fWDJ3xv1d/YhZXYN/cjc73dm/hd71WSdLfv5kyPrzfqyd1k/1oeNYOf5GD6Jz+TzxGKx TmzWfA7rznrhgIez4WTBzrKz0KVUngpdmsgnas8xgx3aSDu0FQvFQtiAJkF78b34HpGAs8f0hKbS NPoIMWAGzaRZNJs+Bur9FBFhDs2lv9Hn9AV9SfMQHxYA+S4C1llCXwH9LqVltJy+oRW0klbRasSO b2ktraP1tAF4OQOR5DvKpO+BjbfQVtqGuLKDdtIuIOg9tJeyEGX2A0UfpEPA0UfoKGLOMTpOJ+gk /UCnKBsR6AydpXN0ni5QDl1EPPoRWPsy5VE+/UQGRKcr9DNdpWt0nQqBwYuphG7QTbpFt6mU7iBy ldE9uk8P6Bd4mUeIY+XY61N6Rs/pBb0kI6maYwZejuA9eS/eG5i5L+/H3+X9gZsH8kF8MJBzJI/i Q3m0hp55LNDzCGDnkXwUj+ejeQJP5En8PeDiyzyP5/OfuIEX8Cv8Z36VX+PXeSEv4sW8BIj5Jr/F b/NSYcvv8LvCTkPP/D7Q8y/8IX/EH/Ny/gQo+hl/zl/wl9yoYWnBNCwtFGEhLIGnrYWN6CEiRE/g 3YFikIgUUWK0eE9MEx+J6WKG+EIsEl+JTJzrZrEFGHcnsO1pcUacFefEeXFB5IiL4pL4UWmphEBr 3Ez+X3ryD6VnXi66wKPmAFOH0SWg6QGUKwaLIZQn/cRPIkkkkQFWPYUKxOfic7omtem69KWF0jaL pGYVQy/XUYm00BvSQm+K7WIH3ZJ2Wqq0UIJxEpztwxn+d/TuH7Xuv6Vzhv+I1v2z3r3SvN/Xvb9r n6Z/f9fA5VIH/3e0cJGmP4wzN3gdL+QMrtIDVZOZQyAbzGKojvRGjbRPuqgxG4VcoglyiTRqziYg O+rAFrGvaTDbxs5QNE+Gf5rEZ/FF9KWM7KuFvXCmNdqnRpQh3EVt2iTqigZ0WAQhWzgmtS4f8SwY kdcZEdCXaiB/aIw1rcZL44gJ8v0meZVlvsrClQEv7Vt2dVgdrL0+q4+DaM6aQxs7so7Y6jvsHVKQ 4yxEZm7K5jbhhayADWKx5prtr9X8NoOoKjOIgXykzCAieAQsrC/vi9jfn/fHnUF8EGJ/DI9B7B/F RyH2v8ffkxmEv/Zs1n/IIHpAK97FWMNw3kla7vgncgltZis5s7Wc2UbObCtntpMz28uZtf87+pI6 sgssh11kl9iPLJddZnksn/3EDKyAXWE/s6vsGrvOClkRK2Yl7Aa7yW6x26xUEYoiHoty8UQ8Fc/E c/FCvBRGof47dQqEr2i40QvaxWV2WkFDFsAWAtjDF7e1HNUC+oZdQt/6kxXOQfuGvaZpNsha4xEP tazVjo1hY5ExT2QTEUFnsVnkxD5mn1AFNpfNJWftE1dygQZug/YeYAehz3p2jCqxU+wUecrcxUvG YB8ZwXUyg+kgM5i3sb5grPAvyMxsN/+HO4Pm1JY5Q39YzZsQ4Cl4wVx4vEL4tnvwYy+wdmvgQFes 2w9IsC5rCOtpzTqwLqw29hGIXdWTZX/YlFYOYi1kOZgFy3IIaynLSKBCrYxirWQ5lLWWZTQLleWw X8u2soxlHWQZx96WZTzsVCsTWS1YohOsmeOqLmmfs9eXttkAfDDTgQ9hQeCRrCF4FGsEPpTBW2Cu JuDDgFM5i2HNwGNZO/A41h58FHsLPB5egWOWTuBJDLgAWKgLeDLrCr4YGJizJawb+FdAVDpqTm2o E3WnfhRJIyiJxtNkRLbPYGOLEbHWIDptRjTah8hzkq3HDhZj1RtkOYhtlOVgliHLIWyTLCPZ97KM Yt/JcijLlGU02yzLYWyLLGPYVlnGsqVSFsukFJZLKXwjpbBCSmG1lMJKKYVVUgprpBS+lVJYK6Ww Ttub9HGBsgxDruBIgdSQQuRnQ47QLHcp60pSRh7m9grz/PXdCE2S8hMwezZfykpyDRmwCtB9Ym6I H0zqOJeaK+R3UezZffaYPYcTsOT2vCJ35968Gq8l8fJ/Ev/Ck0uM9nfEZ62hoF8x1P+Ag35FUNoY g3n8rz5fiwDaZzTu8i6ulEh69ckdmT//+vXTMO92KF1N1d7BunTvppY2tad3ml7uwKz48nTvmqiq xhkLstPZWFrUcRTcy4J0UZa2dSyZwtKbcaYs76nroav7Wo3PCt/JPjgk7RVOQymFEimeYigV1Fp7 6aq+Npji2ub66LTl0d8E1ArKdVzy5YQTOfseTVqe7nZFly6OgOotF3BWvELH/Z7zrnwa8Xb78vzR nRyCVukcfl0qs8CipnwsFyl6K5YuvH/bIDedi3Zh7WLfNyYlNSY5wa99VFJMkKvOWau2crHrMCZ5 aFTC2Lj4+JggJ4yGWlsXy14josalxgRV1nlrFXYurqYKv/YxyalxsXHRUalxiQlBVXSVtdvCxd18 u1fcaMwSNTopLmG4X/u2Ot9KDrpGQQ11jXXyX/9KDkHaZaOGjZq0aNKiv67na4vt3TOoks7NNL9j n5jkuJ5xwxPq+nVOiK4fVEdXyzSR/6sbciq/nq/m6hmTPDYuOiZFmzSd+b8uFWZBIp05EepteTpj tO7k5lWnsv2+s504a+OMMfe2ht2/ctBp//CorJXDfPL2PD3ZaMM03ax+kz7JH2VoutRp/7nS8Q/G rZmUGLL/i+8cdo94GP/lyayIehs6tXq0/eKgId582bMGo3xXla9cvMbrOL/6YdeI646RpW18Ju1y KAg9tvXKjKwhaSOD6otFU1zWdvQ7HZTi0Lde9vjGjeY5L3LeVTCiwfri64dmf1L78MdVZ8RmTe3X N3HM/pD1NWYMOlnBLWTZtFu9DtomHDEe7WLYZVVxgf+E/NY1z/mOL10WdOJ+sb9n/pEtHdsv9hqy 3Hdu4eBHdyfcn7hhKJvzqJtdwVn/PmvnZW+aOXbT3d0OvxR2u7z8+Yjlm1xbbplxcA8XUPyVU/J1 U3J1jS2tobEWFlYMBqeroQt4da1j0z1GpKYmBTdokBidklR/LOSeArnXj04cLXWnsgtjqmKts0TB GenaanVVlGBdc13T5Y2XN5yuM3ePTo7/h94NTLryuqq0b1sfraSmVq6u2OtsX61CWOsctUonbS4F FmCJFeK6ogLNXOWpq/RKv4WLfa+ebaFozesF1WvS6DdWIaZMoS6jnt7qd6iDT9Cs9xfVmb8/fSO7 5NM1O3N2v4Qr1rVWDj5+8guXEiXCoaxjzQbUPLPwxBdhi3P8h7qVhzarGp4UNPn+x81nbLlxYwEZ z/SeHxZwfl3NsLRNO6La/lL7dMmJy4MNe+p81Hrb19suX+2r7tt6dNKjM/ZL7y0w1rnQMsLbu3nN 8tAusGFVl85LzHbscLPOvZzcWjM9GlrYDF48duZv7fi/Yhn/bI665q+bY98/OGkDXT3TpDXeNKl2 Lyb5jSa5uXtgJ8OFEWnTPDrEjhk06cjOZdE11Fbtv5pQsXmF6r1TLo+pGfcybJffwAu2T5d7177T u0/VqFzf/MK9jUYdKzOsbBbzmfcX9tt7+g6cENtkiMXst4xjw670nLxiit/Xm2YOXGFdXqR7ete/ Wdd2tqev6KscudT75pTQbREr665naQ9WrP+0iXFZ8aCRFstajbq+f/4B46nIp21KrJZ3uD2lR8Lq 2g+2z64QeGfOT5bLp3df/EEXawdd5ZMVlo4qv9lvk7KuzaLNgTfmuG8Mud4z8Z0LTb7eljis8pb5 dfe0Knn/9ui0p+7FNTK+K1vUc0ebuvN2vr/emBOxoVbqpHalLXxXjHQvfndPwIhcmty+wozJo8wm eVI35dhfNEn7X02S60jXyGSMdXW1dYHLaywPmO7/r4wxNSWlXnSUND93aX7aEP+DBVoe+EMW2Pi3 Fqid8ozxSXlhEcxvwM/vn0jXHXm5y3N+1t/ocFZ2tv6hY676tNuBRkN1FY8+SvXO+bxgyFd+Lt9P eGtf9+ypJZMrTf225hfDXd5+fnLnwrbi1JIeAyw+/nBt4i/e3b0D6j+I+zTev3zPSfd5d+xTD4wY d/n2oqEzDqbMfTIrNa3ahpULP1jwffmcWu91qz/Gu1PbvHvbHPx6XRq3fEF6dNxLmzOz743ZY7Pk 8tOKvWssjmq4L41nfjB934rDH/vXHX+uydi9n6cMfLqruKubbbVThedzGtfv3MYtxCkyLUC/OrZs /pmk261LHjpM+unchJVj34s7+FV4R12Tqt+v+M5raEidy5+tr231Qa7HloEfXPt6daIxZFaGLl1x hgt4ZnIBTnSQPg4JmVnxXOvH0aVX2rwuMQUeIOmVbdu5+LdPTHo/OW74iFS/wOhafkEtWjTz6xYX nZyYkhib6tc+MTmpfpCvzsfU2O0f7yQmm2J1VV0V0zF5/P1+RGJiql/bMakjEpPjUt/X3EOLZrqg IJ2umdk9NNQFNWwUZL78P1jRG0M5zzqYVNzyQZh34LIF4wfrbq1Y92n1IU+M87qu3GH8eoVf6wk9 VixZMSey4ahz7Ya9f3fj2BO98h7c/mq6z5xl02K3HB2VNrTapcohBU7s8xvzj+yvF7t48Ygai84G 191vv61fjYNvl9i2bj6/7rrAFmtLO09td32a057F8b2jNqZP+Cay3riuNxdtHdZycXefIOsA12Xr Sv5Wx6O41cJo18h+FjHLKjeLmFH+bdmXXO99YX/vt7bMmrw/uLTXl2GbXn6bNjo17DuPU/NtAqtS 37mRcc32vONsFdJHHfB8Vayt9ZrzU/r0LdvecrD7lHFK3uN9mybPM2Zmf3jpW6/kgSEn996zXumv 22L50YktfuNcPrpi9htrdVNW66as0OySKVMW66YsmFxhwNmksrjkpdV6THLd3O0z9Ydvkv/3zy/9 DTouvcK8G3YHPv1lgUeTOztZQO64ir8MjGy4bKndD60t/jZzzong4qoP7vX9ou625R2PDy178eOp li37r2vaK84YMDr0xKn1BRYTDEGftlpWIWnkHqNzuEfcgRdn21+v2N8v/NbQD75b73m8TrPq9fbF fOM8u7pT9MryXj5Pq5645PZLxMaE9g2tXqZXelI0PN6hx+Os+xHHskqO6F74BdnMrDyvlle3i5X5 6vuTfxZbBzz83nC8792Yzsciem3fKgKd1bmX7lnPmbRzwdENzeoWphWuHXd97HI6OzL04Pmms39u 67y2yUjvkflNrub4KIVr31KO92/UPKGbj8PQHbYrPvl/1Zp5OJRdH8fvMdZG2WVfM8Rb7mEylH1L KdkjW2IQ0dhDwpCtUmjKUjKEZCdLljK2EKVE2esNSVLWMJXnNiqel673r+d6rv6ZmXPOdc59zn3/ zuf3/Z57OruMVbTb+UwycX2seyPivW9lPU+FqFAPiYOCH8LAGZF4pBbgz2HpbaAiOohX/jQJ/P8W EkA5SC+gURg0GoVeEfAQ4mXkfiIhJPPvkoENZFm1G1uO2no6QVLAC7oOMyWFQGaDzhBr73razf7n zLb8bma/W6YMdNENyxQFhVeXwbO+xR5LER8rakSfYgqENpJk6wpJ6CkkqW8TulQ9tKysP+lf92KH 2LzPE+HldklTvdYb5fjiPX67gIY79F12LeUZ8+9JpO6ii9fS6JaYyvCGSR/wTTXMjXdqJ13CYox4 q/SX7GFRJM4XeCdA9YzmHKu8HtnO4PWS0v0RTNGQHZ3oPndV9P5Zl3ztOXFPAZHH6twCBmWGSZ3p HWxN3CrutK7TBGFNG/WPtS2J9kIVJPTXNM3RgGJ+6YrMwVniULIw03czlJqJ/LkCs3fDE+Z+Yjlf JKVZVOTPKKsHZTkNnxNx2j56MK7hjKbhfuKRsKj45FrHgHEGcjg8cD7RXVEqyyGhbWjXf6WoeJjQ Otg5RdaCqQg+fqTh6TYo9uDpeJgkdD+Qm+lw+J+BF1Zahh8GnAPiCxUcDlBTLCr/NmpOanaxBSld q2YP47yR+VTJ7Zxk0qJRCMj9qws7FTWjwBbACPCG7LoGoAYiKMKH4ju0QaZfAosGhENf6/YlBWN2 b1/P0FQUjiMQ6Gd4lHLUCa0u+qxFW2zzbviSvI7a09Jp8dDOt42mRndKuZ+0jU6lLpqW6Vzdv2Mk W7Df/8U8pz9r38wV3gl6q5LzV+5fNKviayN0Eq7KzsYOLkcmW+se0FdA7hXiNcZ8DbTkiK/v54v5 bGuoOEL30eGT38TlJ0ftsASuA6n+Q9jyIWT+92bWsqa0tiabC7iZ1r4cvBtdP5b7/p358DoG9YQp ZO5J/yKSVFahg2BGQQS9y3W2ikK5RAGadDb59NpcULlS+CWY2XqCla/g6KWRKX+WSmtFRsxUPCku Uo/6GI3lo6fd2T1vAmPPiJPvuWVcppU1K7KWZGEC8TSyEMp4VzG2xVY75THluAW74YTiT0HGGvsU 0LJouRW3hIG0EVTcs1IEvf6Rdfxoh/+m/f9KovaQa/L5lmnTpKHBjhzCpW7Fm4IX6q3Cd1t9LvKY y8mNdC7tLRIJQDQ3Z+jGWouwvV+cE71ZOuvmk/9p8rbio4Zac0uVnBJPWWTmiRBbP+KJWbdIQofb wKNbz28bsPjYVuKiscRrnFFZViEdmg4jfaYpqq1f+3127NYEgZHuwAACS5cZf/rYEURLZH9at1Hi qVa71kTnpDjrQ4dZxqQ7LSysbQzTPXdlVIVpbb3IzeHzmL43KRPHMXZ44uQ3q2KXyx93GmDkLzRp H+C4qp9QOOt0++Ugg7ujV4rvRf7zLtfH39lotb0edd/6zA6ID0AlxCDusdWUdExODQlPZh+3ncRo KNWvSiI8LA66IzEbvMsaDCZ7XLK9jdqPTPLqcdMKpN/IeXr122/Il71SK0odQgRDUoI3pQjR6/a/ wb+NYkF31fhpguqgaqpyqmL43nXGz/XnOBTnh3M5uVIrjfM4be9t5+UpvbIBVuIfin0ZiiE8ss6J aoBqoMovJ0oVLvtjXF9f383GxXpsHNBrM08o3/OJIJ9smcBuZex2coiq+V0JubPucJ50TpDx1l6Z sgXn0a1kYR5f5Qwn/3uEc9GW0xoNocnYwEh9g7N49rlQz5dpDyxbqXBPkKe2VxuyZ0TVlg8T24je N2PdlXhrTQHT0oUwZK+1LLlbzN86qTeTPDutxpNrop2n0x8rz2bGcGBqBhUhWE0dY8GKhb9HGHQQ GaMTa3pIdzroOcSES8uORvE9swjfk9H67W7ERDZGpVzD5a3QlFb1ufz3UybFRJ1q7AMjdE/LGK0d Ne0ZN/1lnarkcY1jEX15W4LnzBv/MzwSZHFwRMZvUuR8HOOuEn2LpjpVM7Oc5+1vpUntE663MH4o PHULhM1GKhgMDCn9Y+D4N8CvHWOnhoyC7L8SqgQMRQenofzxdCXN/nj0DHAU4/qTc2jqayUEahu4 vpUDFF3rSI2C9m0bbG7A8NBDlXPCqnLS+8q0AwtnsCBuXRdG1AnweKpcMBrK4bbAKeAklM09oE8h QBs4DbgBXoAn9NsUwEK1nlD9Sp0QgAJ2AyAgQ0QG7/htZHv54U47etjinPz+V0tS42FAJlGnUVIW ZNGvLzhmYyMRsmxetvCyObrApr3zHtnUxwF2QWhRyup6rr281347PeegObcPGgvxZYExXiCuR4Wq 6lVdL6dQ2+HRIuG9HEsEYZ63DGpRfc9VHuvohdGy14SPnvfSvnuc3UEk75RTE3r7pMDIV5wS9768 hqbh4Gr9d5ffLBi1By08H4/1znAyU6gbITAj0h8qDOyEDfYs91uzbwPFo5U1w6Vf6UUN8Hwf42m6 cP/+HKZjZulzmAojbdVdOzZfKRMNltsDnnpoODoO9/JutUQvfLSUn1TN+UVJuUWAK/pVq+rD4RuV 05wYrdIaCbfPlhh1816RnovsQN1Uyf5yIh4SRXgYee150aLwsAmoamwluB3/kSPNTQ5SGWnpVydA BTEm1RzkWh95iLUXOzAo8H610KCYKNleAYVCKaBk0HuOQfRdF3is1MyJ3ARB2abiLylXO5QPfTBO 2CQEuA5qyDTyEsQjdparc1hH6AtqZcSHeg8/SCf6ajcauuumtV8Rj844O2Ocg+xyDHJkWnwzz62q 099NvpXbdR4ZjDDMt+payDSO6lI1TsphJjEUH23rnS54fLflVGjA2UqwuS5qkFfnSf6hkLAxr0t9 ZshrV0Kcs21TBvhDv381YWbP3KMkpylRofHoGeLG3qfoaXCXLz+fdsNT4XaHfSCPelJM/pjo+wnb A4QI/LcZrhnXBVP5ilExM9fhZhTi5r6HxmT6zphHhUaSZMdYOd2I1xVV8JSxw55c/I7V9AE1Nfcs e/hleVhuZo93x5IXpJYlTEU+KSIdHfodPhAKOjA7vhXWAMBf0qWq1Q0KZW5kc3RyZWFtDQplbmRv YmoNCjY1IDAgb2JqDQpbIDNbIDIyNl0gIDg0MlsgMzI2XSAgODU3WyA2OTBdIF0gDQplbmRvYmoN CjY2IDAgb2JqDQo8PC9UeXBlL1hSZWYvU2l6ZSA2Ni9XWyAxIDQgMl0gL1Jvb3QgMSAwIFIvSW5m byAxNyAwIFIvSURbPDA0NTU0QTYwNTBFQTA5NDI5NUVFNTMyRDA5NDMyMEZBPjwwNDU1NEE2MDUw RUEwOTQyOTVFRTUzMkQwOTQzMjBGQT5dIC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDE4Mz4+ DQpzdHJlYW0NCnicNdG7DgFREIDhOe5rsXbX/X5XahVaHQlP4RlIPI1oJQoPotZJvAE1x/ycYr5M ZpLJzBGx7/02NvoiX/ZwUcxJcY5Keqm4M6DFvSqZDZyV7EHJjWEOD8WbKPm2SMQOKssAhtCHX21k O/3pPzPgQAqiEIE4xCAJCUiDCxnIQg48yIMPAYRQgCKUoAwVqEIN6tCAJrSgDR3oQs8uHT71SsXw iwkWSrhVVjvQXzHrm/K6i3wAvm8YmQ0KZW5kc3RyZWFtDQplbmRvYmoNCnhyZWYNCjAgNjcNCjAw MDAwMDAwMTggNjU1MzUgZg0KMDAwMDAwMDAxNyAwMDAwMCBuDQowMDAwMDAwMTI1IDAwMDAwIG4N CjAwMDAwMDAxODEgMDAwMDAgbg0KMDAwMDAwMDQzMCAwMDAwMCBuDQowMDAwMDAyNDY5IDAwMDAw IG4NCjAwMDAwMDI2MzcgMDAwMDAgbg0KMDAwMDAwMjg3NiAwMDAwMCBuDQowMDAwMDAyOTk3IDAw MDAwIG4NCjAwMDAwMDMwMjUgMDAwMDAgbg0KMDAwMDAwMzE3NSAwMDAwMCBuDQowMDAwMDAzMjQ5 IDAwMDAwIG4NCjAwMDAwMDM0OTEgMDAwMDAgbg0KMDAwMDAwMzYyMyAwMDAwMCBuDQowMDAwMDAz NjUzIDAwMDAwIG4NCjAwMDAwMDM4MTMgMDAwMDAgbg0KMDAwMDAwMzg4NyAwMDAwMCBuDQowMDAw MDA0MTI3IDAwMDAwIG4NCjAwMDAwMDAwMTkgNjU1MzUgZg0KMDAwMDAwMDAyMCA2NTUzNSBmDQow MDAwMDAwMDIxIDY1NTM1IGYNCjAwMDAwMDAwMjIgNjU1MzUgZg0KMDAwMDAwMDAyMyA2NTUzNSBm DQowMDAwMDAwMDI0IDY1NTM1IGYNCjAwMDAwMDAwMjUgNjU1MzUgZg0KMDAwMDAwMDAyNiA2NTUz NSBmDQowMDAwMDAwMDI3IDY1NTM1IGYNCjAwMDAwMDAwMjggNjU1MzUgZg0KMDAwMDAwMDAyOSA2 NTUzNSBmDQowMDAwMDAwMDMwIDY1NTM1IGYNCjAwMDAwMDAwMzEgNjU1MzUgZg0KMDAwMDAwMDAz MiA2NTUzNSBmDQowMDAwMDAwMDMzIDY1NTM1IGYNCjAwMDAwMDAwMzQgNjU1MzUgZg0KMDAwMDAw MDAzNSA2NTUzNSBmDQowMDAwMDAwMDM2IDY1NTM1IGYNCjAwMDAwMDAwMzcgNjU1MzUgZg0KMDAw MDAwMDAzOCA2NTUzNSBmDQowMDAwMDAwMDM5IDY1NTM1IGYNCjAwMDAwMDAwNDAgNjU1MzUgZg0K MDAwMDAwMDA0MSA2NTUzNSBmDQowMDAwMDAwMDQyIDY1NTM1IGYNCjAwMDAwMDAwNDMgNjU1MzUg Zg0KMDAwMDAwMDA0NCA2NTUzNSBmDQowMDAwMDAwMDQ1IDY1NTM1IGYNCjAwMDAwMDAwNDYgNjU1 MzUgZg0KMDAwMDAwMDA0NyA2NTUzNSBmDQowMDAwMDAwMDQ4IDY1NTM1IGYNCjAwMDAwMDAwNDkg NjU1MzUgZg0KMDAwMDAwMDA1MCA2NTUzNSBmDQowMDAwMDAwMDUxIDY1NTM1IGYNCjAwMDAwMDAw NTIgNjU1MzUgZg0KMDAwMDAwMDA1MyA2NTUzNSBmDQowMDAwMDAwMDU0IDY1NTM1IGYNCjAwMDAw MDAwNTUgNjU1MzUgZg0KMDAwMDAwMDA1NiA2NTUzNSBmDQowMDAwMDAwMDU3IDY1NTM1IGYNCjAw MDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwNTEwOCAwMDAwMCBuDQowMDAwMDA1Mzk1IDAwMDAwIG4N CjAwMDAwNzAyMjAgMDAwMDAgbg0KMDAwMDA3MDUyMSAwMDAwMCBuDQowMDAwMDg2MTM4IDAwMDAw IG4NCjAwMDAwODYxODEgMDAwMDAgbg0KMDAwMDA4NjQ5MSAwMDAwMCBuDQowMDAwMTI4NDgyIDAw MDAwIG4NCjAwMDAxMjg1MzYgMDAwMDAgbg0KdHJhaWxlcg0KPDwvU2l6ZSA2Ny9Sb290IDEgMCBS L0luZm8gMTcgMCBSL0lEWzwwNDU1NEE2MDUwRUEwOTQyOTVFRTUzMkQwOTQzMjBGQT48MDQ1NTRB NjA1MEVBMDk0Mjk1RUU1MzJEMDk0MzIwRkE+XSA+Pg0Kc3RhcnR4cmVmDQoxMjg5MjANCiUlRU9G DQp4cmVmDQowIDANCnRyYWlsZXINCjw8L1NpemUgNjcvUm9vdCAxIDAgUi9JbmZvIDE3IDAgUi9J RFs8MDQ1NTRBNjA1MEVBMDk0Mjk1RUU1MzJEMDk0MzIwRkE+PDA0NTU0QTYwNTBFQTA5NDI5NUVF NTMyRDA5NDMyMEZBPl0gL1ByZXYgMTI4OTIwL1hSZWZTdG0gMTI4NTM2Pj4NCnN0YXJ0eHJlZg0K MTMwNDE4DQolJUVPRg== --_002_B0D29E0424F2DE47A0B36779EC666779258596DBnkgeml501mbschi_-- From linda.dunbar@huawei.com Tue Dec 10 08:28:46 2013 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 854DC1AE03D for ; Tue, 10 Dec 2013 08:28:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 owL_9L2SjecI for ; Tue, 10 Dec 2013 08:28:39 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 97E6D1AD8F0 for ; Tue, 10 Dec 2013 08:28:38 -0800 (PST) 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 BBF71674; Tue, 10 Dec 2013 16:28:32 +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, 10 Dec 2013 16:28:24 +0000 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 10 Dec 2013 16:28:31 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.24]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.03.0158.001; Tue, 10 Dec 2013 08:28:24 -0800 From: Linda Dunbar To: LAC Chidung Thread-Topic: [vnfpool] VNF Pool Problem Statement Thread-Index: Ac7mmacuBQUiFtBEQ2CEYoAlHpu1YwD/P9UAAB+kuIABF0DFAAAFh5wAADY6ElAAoPy9gACEuJvAABE0nYAAIShaAA== Date: Tue, 10 Dec 2013 16:28:23 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645C2E895@dfweml509-mbx.china.huawei.com> References: <52940EB0.6040601@kddilabs.jp> <529C5A30.3070000@orange.com> <4A95BA014132FF49AE685FAB4B9F17F645C293E9@dfweml509-mbx.china.huawei.com> <52A1FE77.10405@orange.com> <4A95BA014132FF49AE685FAB4B9F17F645C2DD5C@dfweml509-mbx.china.huawei.com> <52A5EC9B.3090703@orange.com> In-Reply-To: <52A5EC9B.3090703@orange.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.146.233] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645C2E895dfweml509mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "vnfpool@ietf.org" Subject: Re: [vnfpool] VNF Pool 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: Tue, 10 Dec 2013 16:28:46 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645C2E895dfweml509mbxchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Chidung, It is more like "multidimensional load balancing mechanism without traffic = going through" for the following reasons: - Traditional Load balancing device direct traffic to different inst= ances based on the traffic, which means that the traffic goes to LB first a= nd then is dispatched to different instances of the service function. In VN= Fpool environment, having all traffic going through a single point of LB en= trance will make the LB being the bottleneck, that is not desirable. - There are multiple pools of service functions, with each having it= s own LB (or pool manager). Those pool managers have to coordinate with eac= h other. Linda From: LAC Chidung [mailto:chidung.lac@orange.com] Sent: Monday, December 09, 2013 10:15 AM To: Linda Dunbar Cc: vnfpool@ietf.org Subject: Re: [vnfpool] VNF Pool Problem Statement Thank you, Linda, for clarifying what I meant by "based on an efficient loa= d balancing mechanism". Le 09/12/2013 17:11, Linda Dunbar a =E9crit : Childung, What you described is good beginning. I add the remaining to your service c= hain (see the insert below) From: LAC Chidung [mailto:chidung.lac@orange.com] Sent: Friday, December 06, 2013 10:43 AM To: Linda Dunbar; vnfpool@ietf.org Subject: Re: [vnfpool] VNF Pool Problem Statement Hi Linda, Please correct the following if I'm wrong. Let's define: VNF =3D one type of function. Case 1: no service chaining, e.g., a firewall provides the network service Let's state that 3 firewalls are needed, i.e., 3 instances of the VNF "FW". "VNFs have higher chance to fail due to lack of built-in redundancy" combin= ed with the use of "vnfpool" means: 1) The 3 FW instances are deployed neither in active/active, nor in active/= standby mode, i.e., there are only 3 instances, and not 3 active, and 3 sta= ndby. 2) But this solution is not a trusted one because of "server failure, serve= r over-utilized, or software failure, etc.". 3) Assuming that the load of each (FW) instance is less than 60%, one can g= et HA for this system by using the 3 instances in a pool architecture (base= d on an efficient load balancing mechanism). 4) In this case, the failure of one instance is acceptable because its load= will be shared by the two remaining instances. Case 2: service chaining, e.g., VNF1 and VNF2 are needed in order to provid= e the network service (for instance, a kid requesting a Web page with the u= se of a smartphone -> "parental control" (VNF1) checks the URL, followed by= "header enrichment" (VNF2) which adds the user ID in the media flow) Lets' state that we have 3 instances of VNF1 and 3 instances of VNF2. If we= apply the same reasoning (and hypotheses) as above, we will have a 1st poo= l made up of 3 instances of VNF1, and a 2nd pool made up of 3 instances of = VNF2. The HA of this system is guaranteed if: (i) 1 instance of VNF1 fails, [Linda] VNFpool is to develop protocol for the replacement instance of VNF1= to be chained to the instance of VNF2 when the first instance of VNF1 fai= ls. (ii) 1 instance of VNF2 fails, [Linda] VNFpool is to develop protocol for the instance of VNF1 to be chain= ed to the replacement instance of VNF2 when the first instance of VNF2 fai= ls. (iii) 1 instance of VNF1 fails and 1 instance of VNF2 fails. [Linda] Then the VNFpool protocol is responsible for chaining the replaceme= nt of VNF1 to the replacement of VNF2. Best, Chidung Le 03/12/2013 21:06, Linda Dunbar a =E9crit : Chidung, Thanks for the quote. Based on your quote, the goal of "vnfpool" should be about to achieve "high= availability" of service function chaining while individual service functi= on instances are NOT reliable. As stated in the problem statement, the vir= tualized network functions have higher chance to fail due to lack of built-= in redundancy, server failure, server over-utilized, or software failure, e= tc. Linda From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of LAC Chidung Sent: Monday, December 02, 2013 4:00 AM To: vnfpool@ietf.org Subject: Re: [vnfpool] VNF Pool Problem Statement Hi all, Reliability is the ability of an item to perform a required function under = stated conditions for a stated period of time, while Availability is a meas= ure of the degree to which an item is in an operable state when called upon= to perform. (D.J. Klinger, Y. Nakada, and M.A. Menedez (Eds.), "AT&T Relia= bility Manual", Van Nostrand Reinhold, 1990) Applied to the PSTN, the former includes "My call is not dropped during a c= onversation", while the latter asks for "The phone service is ready, i.e., = a tone is present, whenever I lift the handset". For years, Dependability has encompassed these concepts (together with othe= rs such as Maintainability) to characterize the good behavior (robustness) = of a system when facing accidental events (design faults, operations errors= , hardware failures, natural disasters, etc.) , while Security, which inclu= des all intentional actions (attacks, ...), is kept apart. This explains th= e presence, up to now, of two communities working in these two separated su= bjects. As (i) unavailability may the consequence of, e.g., software/hardware failu= res OR (D)DoS attacks (ii) Resilience is a fashionable expression* (iii) et= c., resilience is used since the last few years to encompass both dependabi= lity and security. Best, Chidung _______ *: see, e.g., Obama's praise for the resilience of the Indian people (http:= //articles.latimes.com/2010/nov/06/world/la-fgw-obama-mumbai-20101107) Le 02/12/2013 08:21, Cao,Zhen a =E9crit : Good point, Diego. I checked out the NFV ISG released documents of requirements and terminology, where i could not find 'reliability' but 'resilience'. -cz On Wed, Nov 27, 2013 at 2:06 AM, Diego R. Lopez wrote: Hi, When it comes to the reliability/availability issue I guess providing some (condensed) definition from the NFV REL group would help... Be goode, On 26 Nov 2013, at 04:00 , Hidetoshi Yokota wrote: Hi Ning and all, The proposed PS is a very good starting point covering major issues for the goal of VNF pool. One thing that I could add is the synchronization between the vNF migration/replacement and routing to make the relevant flows forwarded to the new location. The challenge is that the VMs/severs in a pool could be deployed over topologically different networks (in the physical world) and VNF migration could involve topologically independent routing. There are multiple ways to do it, but we should first generalize this issue and specify a common mechanism that may leverage existing ones. If this is already covered, that's fine. If some additional text is useful, the following could be a summary: o Synchronization between vNF migration and flow forwarding, which may require topologically independent routing in the physical transport network= ; There is a discussion about "reliability" and "availability" in another thread and I think this is also an issue in ETSI NFV. We need to define the= m either in this group or NFV to share the same view. Regards, -- Hidetoshi Yokota KDDI R&D Laboratories, Inc. e-mail:yokota@kddilabs.jp (2013/11/21 18:11), Zongning wrote: Hi, Please review the below brief version of VNF Pool Problem Statement, and feedback with your comments. I hope this text can serve as a base of VNF Pool Charter, by carving out real problems and work items. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D A virtualized network function (VNF) (e.g. vFW, vLB) provides the same function as the equivalent network function (e.g. FW, LB), but is usually instantiated as a cluster of software instances running on general purpose servers via virtualization platform. In an environment based on VNFs, a network service is typically realized by a chain of VNFs where the instance= s of adjacent VNFs are preferably directly connected. A VNF chain introduces additional points of failure beyond those inherent i= n a single dedicated server, and therefore additional challenges on reliability. By reliability, we mean the ability of a VNF chain to continue function when having transition or failure within the chain. For example, there are more factors such as software failure, server over-utilization, instance migration that potentially cause VNF instance transition or failure. Although a general pooling mechanism can be applied to address the reliability of a single VNF, there are still problems when addressing the reliability of a VNF chain, i.e. multiple pools for multiple VNFs. For example, how does an instance of VNF#1 know which instance in the pool of VNF#2 will replace the instance of VNF#2 it connects to? How does an instance of VNF#1 know the state of instance of VNF#2 that it connects to i= n order to enforce policy for reliability like load sharing, switch before break? How is the service state of an instance held and accessed for efficient synchronization with backup instances? The overall problem space can be further breakdown to the following study items: - Signalling to handle reliability and instance transition requirements o Signalling between VNF pools for transition (e.g. state change, scaling= , moving) notification, backup announcement; o Service state management (e.g. synchronizing method, state data format, location and mechanism to access state data) within VNF pool; o Obtaining underlying network information (e.g. ALTO, I2RS); o Signalling to CMS for instance deployment reflecting reliability requirements (e.g. distribution of instances on different VMs or hypervisors); - Transport characteristics o Identify and analyze reliable transport characteristics for control plane traffic; o Analysis of transport security characteristics to provide protection against known threats, and identification of an appropriate trust model; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Thanks. -Ning -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego@tid.es Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------------- vnfpool mailing list vnfpool@ietf.org https://www.ietf.org/mailman/listinfo/vnfpool --_000_4A95BA014132FF49AE685FAB4B9F17F645C2E895dfweml509mbxchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Chidung,

 <= /p>

It is more like “multidimensional load balancing mechanism without traffic going through” for the following reasons:

- =        Traditional Load = balancing device direct traffic to different instances based on the traffic= , which means that the traffic goes to LB first and then is dispatched to different instances of the service function. In VNFpool e= nvironment, having all traffic going through a single point of LB entrance = will make the LB being the bottleneck, that is not desirable.

- =        There are multipl= e pools of service functions, with each having its own LB (or pool manager)= . Those pool managers have to coordinate with each other.

 <= /p>

Linda

 <= /p>

 <= /p>

 <= /p>

From: LAC Chidung [mailto:chidung.lac@orange.com]
Sent: Monday, December 09, 2013 10:15 AM
To: Linda Dunbar
Cc: vnfpool@ietf.org
Subject: Re: [vnfpool] VNF Pool Problem Statement<= /p>

 

Thank you, Linda, for clarifying what I meant by "<= b>based on an efficient l= oad balancing mechanism".

Le 09/12/2013 17:11= , Linda Dunbar a =E9crit :

Childung,

What you described is goo= d beginning. I add the remaining to your service chain (see the insert belo= w)

 <= /p>

 <= /p>

From: LAC Chidung [mailto:chidung.lac@orange.com]
Sent: Friday, December 06, 2013 10:43 AM
To: Linda Dunbar; vnfpool@ietf.o= rg
Subject: Re: [vnfpool] VNF Pool Problem Statement<= /p>

 

Hi Linda,
Please correct the following if I'm wrong.
Let's define: VNF =3D one type of function.
Case 1: no service chaining, e.g., a firewall provides the network s= ervice
Let's state that 3 firewalls are needed, i.e., 3 instances of the VNF "= ;FW".
"VNFs have higher chance to fail due to lack of built-in redunda= ncy" combined with the use of "vnfpool"= ; means:
1) The 3 FW instances are deployed neither in active/active, nor in active/= standby mode, i.e., there are only 3 instances, and not 3 active, and 3 sta= ndby.
2) But this solution is not a trusted one because of "server fai= lure, server over-utilized, or software failure, etc.".
3) Assuming that the load of each (FW) instance is less than 60%, one can g= et HA for this system by using the 3 instances in a pool architecture (base= d on an efficient load balancing mechanism).
4) In this case, the failure of one instance is acceptable because its load= will be shared by the two remaining instances.
Case 2: service chaining, e.g., VNF1 and VNF2 are needed in order to= provide the network service (for instance, a kid requesting a Web page wit= h the use of a smartphone -> "parental control" (VNF1) checks = the URL, followed by "header enrichment" (VNF2) which adds the user ID in the media flow)
Lets' state that we have 3 instances of VNF1 and 3 instances of VNF2. If we= apply the same reasoning (and hypotheses) as above, we will have a 1st poo= l made up of 3 instances of VNF1, and a 2nd pool made up of 3 instances of = VNF2. The HA of this system is guaranteed if: (i) 1 instance of VNF1 fails,

[Linda] VNFpool is to develop protocol for the replacement instance o= f VNF1 to be chained to the  instance of VNF2 when the first instance of VNF1 fails.

 (ii) 1 instance of VNF2 fails,

[Linda] VNFpool is to develop protocol for the instance of VNF1 to be= chained to the  replacement instance of VNF2 when the first instance of VNF2 fails.

 (iii) 1 instance of VNF1 fails and 1 i= nstance of VNF2 fails.

[Linda] Then the VNFpool protocol is responsible for chaining the rep= lacement of VNF1 to the replacement of VNF2.

Best,
Chidung

Le 03/12/2013 21:06= , Linda Dunbar a =E9crit :

Chidung,

Thanks for the quote.

Based on your quote, the = goal of “vnfpool” should be about to achieve “high availa= bility” of service function chaining while individual service functio= n instances are NOT reliable.  As stated in the problem statement, the virtualize= d network functions have higher chance to fail due to lack of built-in redu= ndancy, server failure, server over-utilized, or software failure, etc.

Linda

 <= /p>

From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of LAC Chidung
Sent: Monday, December 02, 2013 4:00 AM
To: vnfpool@ietf.org
Subject: Re: [vnfpool] VNF Pool Problem Statement<= /p>

 

Hi all,
Reliability is the ability of an item to perform a required function und= er stated conditions for a stated period of time, while Availability= is a measure of the degree to which an item is in an operable state when c= alled upon to perform. (D.J. Klinger, Y. Nakada, and M.A. Menedez (Eds.), "AT&T Reliability Ma= nual", Van Nostrand Reinhold, 1990)
Applied to the PSTN, the former includes "My call is not dropped durin= g a conversation", while the latter asks for "The phone service i= s ready, i.e., a tone is present, whenever I lift the handset".
For years, Dependability has encompassed these concepts (together wi= th others such as Maintainability) to characterize the good behavior (robustness) of a= system when facing accidental events (design faults, operations errors, hardware failur= es, natural disasters, etc.) , while Security, which includes all intentional actions (attacks, ..= .), is kept apart. This explains the presence, up to now, of two communitie= s working in these two separated subjects.
As (i) unavailability may the consequence of, e.g., software/hardware failu= res OR (D)DoS attacks (ii) Resilience is a fashionable expression* (iii) etc., resilience is us= ed since the last few years to encompass both dependability and security. Best,
Chidung
_______
*: see, e.g., Obama's praise for the resilience of the Indian people (http://articles.latimes.com/2010/nov/06/world/la-fgw-obama-mumbai-20= 101107)

Le 02/12/2013 08:21= , Cao,Zhen a =E9crit :

Good point, Diego.
I checked out the NFV ISG released documents of requirements and<=
/o:p>
terminology, where i could not find 'reliability' but 'resilience'.
-cz
 
On Wed, Nov 27, 2013 at 2:06 AM, Diego R. Lopez <diego@tid.es> wrote:
Hi,
When it comes to the reliability/availability issue I guess providing =
some
(condensed) definition from the NFV REL group would help...=

Be goode,
 
On 26 Nov 2013, at 04:00 , Hidetoshi Yokota wrote:
 
Hi Ning and all,
The proposed PS is a very good starting point covering major issues fo=
r the
goal of VNF pool. One thing that I could add is the synchronization be=
tween
the vNF migration/replacement and routing to make the relevant flows
forwarded to the new location. The challenge is that the VMs/severs in=
 a
pool could be deployed over topologically different networks (in the
physical world) and VNF migration could involve topologically independ=
ent
routing. There are multiple ways to do it, but we should first general=
ize
this issue and specify a common mechanism that may leverage existing o=
nes.
If this is already covered, that's fine. If some additional text is us=
eful,
the following could be a summary:
o Synchronization between vNF migration and flow forwarding, which may=

require topologically independent routing in the physical transport ne=
twork;
There is a discussion about "reliability" and "availabi=
lity" in another
thread and I think this is also an issue in ETSI NFV. We need to defin=
e them
either in this group or NFV to share the same view.
Regards,
--
Hidetoshi Yokota
 
KDDI R&D Laboratories, Inc.
e-mail:yokota@kddilabs.jp=

 
(2013/11/21 18:11), Zongning wrote:
 
Hi,
Please review the below brief version of VNF Pool Problem Statement, a=
nd
feedback with your comments. I hope this text can serve as a base of V=
NF
Pool Charter, by carving out real problems and work items.<=
/pre>

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


A virtualized network function (VNF) (e.g. vFW, vLB) provides the same=



function as the equivalent network function (e.g. FW, LB), but is usua=
lly


instantiated as a cluster of software instances running on general pur=
pose


servers via virtualization platform. In an environment based on VNFs, =
a


network service is typically realized by a chain of VNFs where the ins=
tances


of adjacent VNFs are preferably directly connected.


A VNF chain introduces additional points of failure beyond those inher=
ent in


a single dedicated server, and therefore additional challenges on=



reliability. By reliability, we mean the ability of a VNF chain to con=
tinue


function when having transition or failure within the chain. For examp=
le,


there are more factors such as software failure, server over-utilizati=
on,


instance migration that potentially cause VNF instance transition or


failure. Although a general pooling mechanism can be applied to addres=
s the


reliability of a single VNF, there are still problems when addressing =
the


reliability of a VNF chain, i.e. multiple pools for multiple VNFs. For=



example, how does an instance of VNF#1 know which instance in the pool=
 of


VNF#2 will replace the instance of VNF#2 it connects to? How does an


instance of VNF#1 know the state of instance of VNF#2 that it connects=
 to in


order to enforce policy for reliability like load sharing, switch befo=
re


break? How is the service state of an instance held and accessed for


efficient synchronization with backup instances?


The overall problem space can be further breakdown to the following st=
udy


items:


-          Signalling to =
handle reliability and instance transition


requirements


o   Signalling between VNF pools for transition (e.g. state =
change, scaling,


moving) notification, backup announcement;


o   Service state management (e.g. synchronizing method, sta=
te data format,


location and mechanism to access state data) within VNF pool;


o   Obtaining underlying network information (e.g. ALTO, I2R=
S);


o   Signalling to CMS for instance deployment reflecting rel=
iability


requirements (e.g. distribution of instances on different VMs or<=
/o:p>


hypervisors);


-          Transport char=
acteristics


o   Identify and analyze reliable transport characteristics =
for control


plane traffic;


o   Analysis of transport security characteristics to provid=
e protection


against known threats, and identification of an appropriate trust mode=
l;


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


Thanks.


-Ning


 


--


"Esta vez no fallaremos, Doctor Infierno"


 


Dr Diego R. Lopez


Telefonica I+D


http://people.tid.es/die=
go.lopez/


 


e-mail: diego@tid.es

Tel:    +34 913 129 041


Mobile: +34 682 051 091


-----------------------------------------


 


vnfpool mailing list


vnfpool@ietf.org

https://www.=
ietf.org/mailman/listinfo/vnfpool
--_000_4A95BA014132FF49AE685FAB4B9F17F645C2E895dfweml509mbxchi_-- From yokota@kddilabs.jp Tue Dec 10 17:16:26 2013 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 EA2791AE2F2 for ; Tue, 10 Dec 2013 17:16:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.408 X-Spam-Level: ** X-Spam-Status: No, score=2.408 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_74=0.6, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 8djXrcIjsvjJ for ; Tue, 10 Dec 2013 17:16:22 -0800 (PST) Received: from mandala.kddilabs.jp (mandala.kddilabs.jp [IPv6:2001:200:601:12::16]) by ietfa.amsl.com (Postfix) with ESMTP id 97E081AE049 for ; Tue, 10 Dec 2013 17:16:20 -0800 (PST) Received: from localhost (mandala.kddilabs.jp [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id B1F301748126; Wed, 11 Dec 2013 10:16:14 +0900 (JST) X-Virus-Scanned: amavisd-new at kddilabs.jp Received: from mandala.kddilabs.jp ([127.0.0.1]) by localhost (mandala.kddilabs.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LR1PngUvjlMq; Wed, 11 Dec 2013 10:16:11 +0900 (JST) Received: from ultra.mip.kddilabs.jp (ultra.mip.kddilabs.jp [172.19.90.145]) by mandala.kddilabs.jp (Postfix) with ESMTP id A13D71748123; Wed, 11 Dec 2013 10:16:11 +0900 (JST) Received: from [127.0.0.1] (dhcp197.west-4f.cn.kddilabs.jp [172.19.124.197]) by ultra.mip.kddilabs.jp (Postfix) with ESMTP id 7ECDA1B9B1; Wed, 11 Dec 2013 10:05:12 +0900 (JST) Message-ID: <52A7BCDF.4090207@kddilabs.jp> Date: Wed, 11 Dec 2013 10:16:15 +0900 From: Hidetoshi Yokota User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: zongning@huawei.com, d.king@lancaster.ac.uk, diego@tid.es, melinda.shore@nomountain.net References: <52940EB0.6040601@kddilabs.jp> <529C5A30.3070000@orange.com> <4A95BA014132FF49AE685FAB4B9F17F645C293E9@dfweml509-mbx.china.huawei.com> <52A1FE77.10405@orange.com> <65174429B5AF4C45BD0798810EC48E0A0D38CF@EX-0-MB2.lancs.local> <52A52A3F.4060503@nomountain.net> <65174429B5AF4C45BD0798810EC48E0A0D3C0B@EX-0-MB2.lancs.local> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040409060009090709050609" Cc: vnfpool@ietf.org Subject: Re: [vnfpool] VNF Pool 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: Wed, 11 Dec 2013 01:16:27 -0000 This is a multi-part message in MIME format. --------------040409060009090709050609 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Hi Ning and all. Sorry to jump into the discussion. Thanks for providing the architectural figure. As a matter of fact, even ETSI NFV does not a concrete and uniform concept about the interfaces and the role of each function, so the discussion in this ML is very valuable. So, the focus of VNF Pool is: 1) signaling between Pool Managers 2) signaling between Pool Manager and VNFs in its pool 3) signaling between Pool Manager and underlying network (routers/switches?) [*not in the figure, but described in the PS] 4) signaling between Pool Manager and CMS [*not in the figure but described in the PS] Of course, some may end up with out of scope. Which one will be most important (1 and 2, maybe)? Regards, -- Hidetoshi Yokota KDDI R&D Laboratories, Inc. e-mail:yokota@kddilabs.jp (2013/12/10 10:43), Zongning wrote: > Ooops, forgot the file. Here it is... > >> -----Original Message----- >> From: Zongning >> Sent: Tuesday, December 10, 2013 9:42 AM >> To: 'King, Daniel'; Diego R. Lopez; Melinda Shore >> Cc: >> Subject: RE: [vnfpool] VNF Pool Problem Statement >> >> Hi, Daniel, >> >> Thanks for starting talking about architecture. :) >> I actually put some text about VNF pool architecture in my early post on bar >> BoF summary. Please see attached PDF. Some straw-man points below: >> .Multiple pools for multiple VNFs, with each pool having pool members (VNF >> instances) providing same function; >> .Each pool has a (logical or physical) manager that interacts with pool >> members for redundancy mechanisms, e.g. active-standby management; >> .Pool manager of adjacent pools can talk to each other to achieve redundancy >> among the VNF chain, e.g. pool status notification; >> But I absolutely agree with your idea that it would be good to start working on >> (architecture) document. Sounds like you are willing to contribute some text. :) >> Thanks. >> >> -Ning >> >> >>> -----Original Message----- >>> From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of King, Daniel >>> Sent: Tuesday, December 10, 2013 4:16 AM >>> To: Diego R. Lopez; Melinda Shore >>> Cc: >>> Subject: Re: [vnfpool] VNF Pool Problem Statement >>> >>> Hi All, >>> >>> Re: Deployment Scenarios >>> >>> Sounds good, it was just a gentle reminder that the model we settle on >> should >>> fit with existing/planned deployment scenarios, and network resilience >>> mechanisms. As we develop the vnfpool problem statement, we are >> capturing >>> the scope and key problems that inform the solution work, but ideally these >>> should be guided by how operators and service providers plan to use VNFs in >>> the field. Operators that have NFV trials and prototypes, provides valuable >> data >>> to use for the solution work, we just need to encourage them to assign more >>> CPU cycles to the vnfpool mailing list. ;-) >>> >>> Re: (high-level) Architecture >>> >>> It would be great to visualise the architecture (ASCII or otherwise), >> specifically >>> the components, relationships, interactions and interfaces required/expected >>> based on the problem statement (thus far): >>> >>> - VNF Pool Manager (in-scope, out of scope?) >>> o Resilient itself (multi-instance)? >>> >>> - Single instance VNFs, Multi-instance VNFs and Chained VNFs >>> o Signaling mechanisms/characteristics/relationships >>> >>> - Abstract interactions/relationships between VNF Pool Manager and VNFs, >>> and VNF to VNF(s). >>> o Instantiation >>> o Adaptation >>> o Migration >>> o Fail-over >>> o Load-balancing >>> o Termination >>> >>> - VNF/Pool Topology Management >>> o Functions and Interfaces >>> >>> - Control Plane >>> o Functions and Interfaces >>> >>> - Relationship (or completely transparent?) with physical and virtual >> elements, >>> providing connectivity and additional function >>> >>> Br, Dan. >>> >>> -----Original Message----- >>> From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of Diego R. Lopez >>> Sent: 09 December 2013 19:00 >>> To: Melinda Shore >>> Cc: >>> Subject: Re: [vnfpool] VNF Pool Problem Statement >>> >>> Hi, >>> >>> I agree with Melinda in that the problem has to be confined to the VNF (and >> its >>> pooling manager) and the service chaining management functions. External >>> elements, like other virtual and/or physical network functions in a given path >>> (the realization of the chain) or user applications should be completely >> oblivious >>> to the pooling mechanisms in place. >>> >>> Be goode, >>> >>> >>> On 9 Dec 2013, at 03:26 , Melinda Shore wrote: >>> >>>> I think Daniel is asking exactly the right questions. But to back up >>>> a bit, I've been thinking about this over the weekend and realized >>>> that the scenario is actually simpler than I'd been considering. If >>>> the VNF instances are pooled along the general lines of something like >>>> rserpool, it is not the case that an external client will need to be >>>> modified. The only elements which would need to be able to "talk" the >>>> pooling protocol are already participating - they'd be the pool >>>> manager and whatever service chain management function is being used, >>>> the pool members, and adjacent pools. So I think we're in good shape >>>> there; we could probably use some better text around this to make it >>>> clearer. >>>> >>>> Melinda >>>> _______________________________________________ >>>> vnfpool mailing list >>>> vnfpool@ietf.org >>>> https://www.ietf.org/mailman/listinfo/vnfpool >>> >>> -- >>> "Esta vez no fallaremos, Doctor Infierno" >>> >>> Dr Diego R. Lopez >>> Telefonica I+D >>> http://people.tid.es/diego.lopez/ >>> >>> e-mail: diego@tid.es >>> Tel: +34 913 129 041 >>> Mobile: +34 682 051 091 >>> ----------------------------------------- >>> >>> >>> ________________________________ >>> >>> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar >>> nuestra poli'tica de envi'o y recepcio'n de correo electro'nico en el enlace >>> situado ma's abajo. >>> This message is intended exclusively for its addressee. We only send and >>> receive email on the basis of the terms set out at: >>> http://www.tid.es/ES/PAGINAS/disclaimer.aspx >>> _______________________________________________ >>> vnfpool mailing list >>> vnfpool@ietf.org >>> https://www.ietf.org/mailman/listinfo/vnfpool >>> _______________________________________________ >>> vnfpool mailing list >>> vnfpool@ietf.org >>> https://www.ietf.org/mailman/listinfo/vnfpool >>> >>> >>> _______________________________________________ >>> vnfpool mailing list >>> vnfpool@ietf.org >>> https://www.ietf.org/mailman/listinfo/vnfpool --------------040409060009090709050609 Content-Type: text/html; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Hi Ning and all.

Sorry to jump into the discussion.

Thanks for providing the architectural figure. As a matter of fact, even ETSI NFV does not a concrete and uniform concept about the interfaces and the role of each function, so the discussion in this ML is very valuable.

So, the focus of VNF Pool is:

1) signaling between Pool Managers
2) signaling between Pool Manager and VNFs in its pool
3) signaling between Pool Manager and underlying network (routers/switches?) [*not in the figure, but described in the PS]
4) signaling between Pool Manager and CMS [*not in the figure but described in the PS]

Of course, some may end up with out of scope. Which one will be most important (1 and 2, maybe)?

Regards,
 
-- 
Hidetoshi Yokota

KDDI R&D Laboratories, Inc.
e-mail:yokota@kddilabs.jp
(2013/12/10 10:43), Zongning wrote:
Ooops, forgot the file. Here it is...


-----Original Message-----
From: Zongning
Sent: Tuesday, December 10, 2013 9:42 AM
To: 'King, Daniel'; Diego R. Lopez; Melinda Shore
Cc: <vnfpool@ietf.org>
Subject: RE: [vnfpool] VNF Pool Problem Statement

Hi, Daniel,

Thanks for starting talking about architecture. :)
I actually put some text about VNF pool architecture in my early post on bar
BoF summary. Please see attached PDF. Some straw-man points below:
•Multiple pools for multiple VNFs, with each pool having pool members (VNF
instances) providing same function;
•Each pool has a (logical or physical) manager that interacts with pool
members for redundancy mechanisms, e.g. active-standby management;
•Pool manager of adjacent pools can talk to each other to achieve redundancy
among the VNF chain, e.g. pool status notification;
But I absolutely agree with your idea that it would be good to start working on
(architecture) document. Sounds like you are willing to contribute some text. :)
Thanks.

-Ning



-----Original Message-----
From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of King, Daniel
Sent: Tuesday, December 10, 2013 4:16 AM
To: Diego R. Lopez; Melinda Shore
Cc: <vnfpool@ietf.org>
Subject: Re: [vnfpool] VNF Pool Problem Statement

Hi All,

Re: Deployment Scenarios

Sounds good, it was just a gentle reminder that the model we settle on

should

fit with existing/planned deployment scenarios, and network resilience
mechanisms. As we develop the vnfpool problem statement, we are

capturing

the scope and key problems that inform the solution work, but ideally these
should be guided by how operators and service providers plan to use VNFs in
the field. Operators that have NFV trials and prototypes, provides valuable

data

to use for the solution work, we just need to encourage them to assign more
CPU cycles to the vnfpool mailing list. ;-)

Re: (high-level) Architecture

It would be great to visualise the architecture (ASCII or otherwise),

specifically

the components, relationships, interactions and interfaces required/expected
based on the problem statement (thus far):

- VNF Pool Manager (in-scope, out of scope?)
o Resilient itself (multi-instance)?

- Single instance VNFs, Multi-instance VNFs and Chained VNFs
o Signaling mechanisms/characteristics/relationships

- Abstract interactions/relationships between VNF Pool Manager and VNFs,
and VNF to VNF(s).
o Instantiation
o Adaptation
o Migration
o Fail-over
o Load-balancing
o Termination

- VNF/Pool Topology Management
o Functions and Interfaces

-  Control Plane
o Functions and Interfaces

- Relationship (or completely transparent?) with physical and virtual

elements,

providing connectivity and additional function

Br, Dan.

-----Original Message-----
From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of Diego R. Lopez
Sent: 09 December 2013 19:00
To: Melinda Shore
Cc: <vnfpool@ietf.org>
Subject: Re: [vnfpool] VNF Pool Problem Statement

Hi,

I agree with Melinda in that the problem has to be confined to the VNF (and

its

pooling manager) and the service chaining management functions. External
elements, like other virtual and/or physical network functions in a given path
(the realization of the chain) or user applications should be completely

oblivious

to the pooling mechanisms in place.

Be goode,


On 9 Dec 2013, at 03:26 , Melinda Shore wrote:


I think Daniel is asking exactly the right questions.  But to back up
a bit, I've been thinking about this over the weekend and realized
that the scenario is actually simpler than I'd been considering.  If
the VNF instances are pooled along the general lines of something like
rserpool, it is not the case that an external client will need to be
modified.  The only elements which would need to be able to "talk" the
pooling protocol are already participating - they'd be the pool
manager and whatever service chain management function is being used,
the pool members, and adjacent pools.  So I think we're in good shape
there; we could probably use some better text around this to make it
clearer.

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


--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: diego@tid.es
Tel:    +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------


________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar
nuestra política de envío y recepción de correo electrónico en el enlace
situado más abajo.
This message is intended exclusively for its addressee. We only send and
receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
_______________________________________________
vnfpool mailing list
vnfpool@ietf.org
https://www.ietf.org/mailman/listinfo/vnfpool
_______________________________________________
vnfpool mailing list
vnfpool@ietf.org
https://www.ietf.org/mailman/listinfo/vnfpool



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

--------------040409060009090709050609-- From zongning@huawei.com Tue Dec 10 17:35:35 2013 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 218EE1AE020 for ; Tue, 10 Dec 2013 17:35:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 xy8SCi2IttD1 for ; Tue, 10 Dec 2013 17:35:28 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D01141ADED8 for ; Tue, 10 Dec 2013 17:35:26 -0800 (PST) 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 AYV96033; Wed, 11 Dec 2013 01:35:20 +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.158.1; Wed, 11 Dec 2013 01:35:10 +0000 Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 11 Dec 2013 01:35:18 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Wed, 11 Dec 2013 09:35:13 +0800 From: Zongning To: Hidetoshi Yokota , "d.king@lancaster.ac.uk" , "diego@tid.es" , "melinda.shore@nomountain.net" Thread-Topic: [vnfpool] VNF Pool Problem Statement Thread-Index: Ac7mmacuBQUiFtBEQ2CEYoAlHpu1YwDduMMAAB+kuIABF0DFAAAFh5wAAEd4ZIAAj75rgAAJEGmAAH9axeD//4RegIABFcEAgAAVFID//yKLEP/+QUBwgASChID//3hLMA== Date: Wed, 11 Dec 2013 01:35:12 +0000 Message-ID: References: <52940EB0.6040601@kddilabs.jp> <529C5A30.3070000@orange.com> <4A95BA014132FF49AE685FAB4B9F17F645C293E9@dfweml509-mbx.china.huawei.com> <52A1FE77.10405@orange.com> <65174429B5AF4C45BD0798810EC48E0A0D38CF@EX-0-MB2.lancs.local> <52A52A3F.4060503@nomountain.net> <65174429B5AF4C45BD0798810EC48E0A0D3C0B@EX-0-MB2.lancs.local> <52A7BCDF.4090207@kddilabs.jp> In-Reply-To: <52A7BCDF.4090207@kddilabs.jp> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.28] Content-Type: multipart/alternative; boundary="_000_B0D29E0424F2DE47A0B36779EC66677925859ABCnkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "vnfpool@ietf.org" Subject: Re: [vnfpool] VNF Pool 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: Wed, 11 Dec 2013 01:35:35 -0000 --_000_B0D29E0424F2DE47A0B36779EC66677925859ABCnkgeml501mbschi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Hidetoshi, Thanks for the comments. You are right, we will start with a set of components and interfaces in the= figure as our initial scope. I haven't prioritize the work items yet, but my personal feeling by now is = that 1), 2), 3) are something we could start with. But we may also consider= transport reliability and security characteristics for these signaling. -Ning From: Hidetoshi Yokota [mailto:yokota@kddilabs.jp] Sent: Wednesday, December 11, 2013 9:16 AM To: Zongning; d.king@lancaster.ac.uk; diego@tid.es; melinda.shore@nomountai= n.net Cc: vnfpool@ietf.org Subject: Re: [vnfpool] VNF Pool Problem Statement Hi Ning and all. Sorry to jump into the discussion. Thanks for providing the architectural figure. As a matter of fact, even ET= SI NFV does not a concrete and uniform concept about the interfaces and the= role of each function, so the discussion in this ML is very valuable. So, the focus of VNF Pool is: 1) signaling between Pool Managers 2) signaling between Pool Manager and VNFs in its pool 3) signaling between Pool Manager and underlying network (routers/switches?= ) [*not in the figure, but described in the PS] 4) signaling between Pool Manager and CMS [*not in the figure but described= in the PS] Of course, some may end up with out of scope. Which one will be most import= ant (1 and 2, maybe)? Regards, -- Hidetoshi Yokota KDDI R&D Laboratories, Inc. e-mail:yokota@kddilabs.jp (2013/12/10 10:43), Zongning wrote: Ooops, forgot the file. Here it is... -----Original Message----- From: Zongning Sent: Tuesday, December 10, 2013 9:42 AM To: 'King, Daniel'; Diego R. Lopez; Melinda Shore Cc: Subject: RE: [vnfpool] VNF Pool Problem Statement Hi, Daniel, Thanks for starting talking about architecture. :) I actually put some text about VNF pool architecture in my early post on ba= r BoF summary. Please see attached PDF. Some straw-man points below: *Multiple pools for multiple VNFs, with each pool having pool members (VNF instances) providing same function; *Each pool has a (logical or physical) manager that interacts with pool members for redundancy mechanisms, e.g. active-standby management; *Pool manager of adjacent pools can talk to each other to achieve redundanc= y among the VNF chain, e.g. pool status notification; But I absolutely agree with your idea that it would be good to start workin= g on (architecture) document. Sounds like you are willing to contribute some tex= t. :) Thanks. -Ning -----Original Message----- From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of King, Daniel Sent: Tuesday, December 10, 2013 4:16 AM To: Diego R. Lopez; Melinda Shore Cc: Subject: Re: [vnfpool] VNF Pool Problem Statement Hi All, Re: Deployment Scenarios Sounds good, it was just a gentle reminder that the model we settle on should fit with existing/planned deployment scenarios, and network resilience mechanisms. As we develop the vnfpool problem statement, we are capturing the scope and key problems that inform the solution work, but ideally these should be guided by how operators and service providers plan to use VNFs in the field. Operators that have NFV trials and prototypes, provides valuable data to use for the solution work, we just need to encourage them to assign more CPU cycles to the vnfpool mailing list. ;-) Re: (high-level) Architecture It would be great to visualise the architecture (ASCII or otherwise), specifically the components, relationships, interactions and interfaces required/expecte= d based on the problem statement (thus far): - VNF Pool Manager (in-scope, out of scope?) o Resilient itself (multi-instance)? - Single instance VNFs, Multi-instance VNFs and Chained VNFs o Signaling mechanisms/characteristics/relationships - Abstract interactions/relationships between VNF Pool Manager and VNFs, and VNF to VNF(s). o Instantiation o Adaptation o Migration o Fail-over o Load-balancing o Termination - VNF/Pool Topology Management o Functions and Interfaces - Control Plane o Functions and Interfaces - Relationship (or completely transparent?) with physical and virtual elements, providing connectivity and additional function Br, Dan. -----Original Message----- From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of Diego R. Lopez Sent: 09 December 2013 19:00 To: Melinda Shore Cc: Subject: Re: [vnfpool] VNF Pool Problem Statement Hi, I agree with Melinda in that the problem has to be confined to the VNF (and its pooling manager) and the service chaining management functions. External elements, like other virtual and/or physical network functions in a given p= ath (the realization of the chain) or user applications should be completely oblivious to the pooling mechanisms in place. Be goode, On 9 Dec 2013, at 03:26 , Melinda Shore wrote: I think Daniel is asking exactly the right questions. But to back up a bit, I've been thinking about this over the weekend and realized that the scenario is actually simpler than I'd been considering. If the VNF instances are pooled along the general lines of something like rserpool, it is not the case that an external client will need to be modified. The only elements which would need to be able to "talk" the pooling protocol are already participating - they'd be the pool manager and whatever service chain management function is being used, the pool members, and adjacent pools. So I think we're in good shape there; we could probably use some better text around this to make it clearer. Melinda _______________________________________________ vnfpool mailing list vnfpool@ietf.org https://www.ietf.org/mailman/listinfo/vnfpool -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego@tid.es Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------------- ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el e= nlace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx _______________________________________________ vnfpool mailing list vnfpool@ietf.org https://www.ietf.org/mailman/listinfo/vnfpool _______________________________________________ vnfpool mailing list vnfpool@ietf.org https://www.ietf.org/mailman/listinfo/vnfpool _______________________________________________ vnfpool mailing list vnfpool@ietf.org https://www.ietf.org/mailman/listinfo/vnfpool --_000_B0D29E0424F2DE47A0B36779EC66677925859ABCnkgeml501mbschi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi, Hideto= shi,

 = ;

Thanks for= the comments.

You are ri= ght, we will start with a set of components and interfaces in the figure as= our initial scope.

I haven= 217;t prioritize the work items yet, but my personal feeling by now is that= 1), 2), 3) are something we could start with. But we may also consider transport reliability and security characteristics for these signaling.

 = ;

-Ning=

 = ;

From:= Hidetoshi Yokota [m= ailto:yokota@kddilabs.jp]
Sent: Wednesday, December 11, 2013 9:16 AM
To: Zongning; d.king@lancaster.ac.uk; diego@tid.es; melinda.shore@no= mountain.net
Cc: vnfpool@ietf.org
Subject: Re: [vnfpool] VNF Pool Problem Statement<= /p>

 

Hi Ning and all.

Sorry to jump into the discussion.

Thanks for providing the architectural figure. As a matter of fact, even ET= SI NFV does not a concrete and uniform concept about the interfaces and the= role of each function, so the discussion in this ML is very valuable.

So, the focus of VNF Pool is:

1) signaling between Pool Managers
2) signaling between Pool Manager and VNFs in its pool
3) signaling between Pool Manager and underlying network (routers/switches?= ) [*not in the figure, but described in the PS]
4) signaling between Pool Manager and CMS [*not in the figure but described= in the PS]

Of course, some may end up with out of scope. Which one will be most import= ant (1 and 2, maybe)?

Regards,

-- 
Hidetoshi Yokota
 
KDDI R&D Laboratories, Inc.=

e-ma=
il:yokota@kddilabs.jp

 

(2013/12/10 10:43), Zongning wr= ote:

Ooops, forgot the file. Here it is...<=
/span>
 
-----Original Message-----

From: Zongning


Sent: Tuesday, December 10, 2013 9:42 AM


To: 'King, Daniel'; Diego R. Lopez; Melinda Shore=



Cc: <vnfpo=
ol@ietf.org>


Subject: RE: [vnfpool] VNF Pool Problem Statement=



 


Hi, Daniel,


 


Thanks for starting talking about architecture. :=
)


I actually put some text about VNF pool architect=
ure in my early post on bar


BoF summary. Please see attached PDF. Some straw-=
man points below:


•Multiple pools for multiple VNFs, with eac=
h pool having pool members (VNF


instances) providing same function;


•Each pool has a (logical or physical) mana=
ger that interacts with pool


members for redundancy mechanisms, e.g. active-st=
andby management;


•Pool manager of adjacent pools can talk to=
 each other to achieve redundancy


among the VNF chain, e.g. pool status notificatio=
n;


But I absolutely agree with your idea that it wou=
ld be good to start working on


(architecture) document. Sounds like you are will=
ing to contribute some text. :)


Thanks.


 


-Ning


 


 




-----Original Message-----

From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of King, Daniel


Sent: Tuesday, December 10, 2013 4:16 AM


To: Diego R. Lopez; Melinda Shore


Cc: <vnfpo=
ol@ietf.org>


Subject: Re: [vnfpool] VNF Pool Problem Statement=



 


Hi All,


 


Re: Deployment Scenarios


 


Sounds good, it was just a gentle reminder that t=
he model we settle on




should




fit with existing/planned deployment scenarios, a=
nd network resilience


mechanisms. As we develop the vnfpool problem sta=
tement, we are




capturing




the scope and key problems that inform the soluti=
on work, but ideally these


should be guided by how operators and service pro=
viders plan to use VNFs in


the field. Operators that have NFV trials and pro=
totypes, provides valuable




data




to use for the solution work, we just need to enc=
ourage them to assign more


CPU cycles to the vnfpool mailing list. ;-)<=
/o:p>


 


Re: (high-level) Architecture

 


It would be great to visualise the architecture (=
ASCII or otherwise),




specifically




the components, relationships, interactions and i=
nterfaces required/expected


based on the problem statement (thus far):


 


- VNF Pool Manager (in-scope, out of scope?)=



o Resilient itself (multi-instance)?


 


- Single instance VNFs, Multi-instance VNFs and C=
hained VNFs


o Signaling mechanisms/characteristics/relationsh=
ips


 


- Abstract interactions/relationships between VNF=
 Pool Manager and VNFs,


and VNF to VNF(s).


o Instantiation


o Adaptation


o Migration


o Fail-over


o Load-balancing


o Termination


 


- VNF/Pool Topology Management<=
/pre>

o Functions and Interfaces

 


-  Control Plane


o Functions and Interfaces

 


- Relationship (or completely transparent?) with =
physical and virtual




elements,




providing connectivity and additional function


 


Br, Dan.


 


-----Original Message-----

From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of Diego R. Lopez<=
o:p>


Sent: 09 December 2013 19:00

To: Melinda Shore


Cc: <vnfpo=
ol@ietf.org>


Subject: Re: [vnfpool] VNF Pool Problem Statement=



 


Hi,


 


I agree with Melinda in that the problem has to b=
e confined to the VNF (and




its




pooling manager) and the service chaining managem=
ent functions. External


elements, like other virtual and/or physical netw=
ork functions in a given path


(the realization of the chain) or user applicatio=
ns should be completely




oblivious




to the pooling mechanisms in place.


 


Be goode,


 


 


On 9 Dec 2013, at 03:26 , Melinda Shore wrote:


 




I think Daniel is asking exactly the right questi=
ons.  But to back up


a bit, I've been thinking about this over the wee=
kend and realized


that the scenario is actually simpler than I'd be=
en considering.  If


the VNF instances are pooled along the general li=
nes of something like


rserpool, it is not the case that an external cli=
ent will need to be


modified.  The only elements which would nee=
d to be able to "talk" the


pooling protocol are already participating - they=
'd be the pool


manager and whatever service chain management fun=
ction is being used,


the pool members, and adjacent pools.  So I =
think we're in good shape


there; we could probably use some better text aro=
und this to make it


clearer.


 


Melinda


_______________________________________________


vnfpool mailing list


vnfpool@ietf.=
org


https://www.ietf.org/mailman/listinfo/vnfpool




 


 


--


"Esta vez no fallaremos, Doctor Infierno&quo=
t;


 


Dr Diego R. Lopez


Telefonica I+D


htt=
p://people.tid.es/diego.lopez/


 


e-mail: diego@tid=
.es


Tel:    +34 913 129 041


Mobile: +34 682 051 091

-----------------------------------------


 


 


________________________________


 


Este mensaje se dirige exclusivamente a su destin=
atario. Puede consultar


nuestra pol=EDtica de env=EDo y recepci=F3n de co=
rreo electr=F3nico en el enlace


situado m=E1s abajo.


This message is intended exclusively for its addr=
essee. We only send and


receive email on the basis of the terms set out a=
t:


http://www.tid.es/ES/PAGINAS/disclaimer.aspx<=
/pre>

_______________________________________________


vnfpool mailing list


vnfpool@ietf.=
org


https://www.ietf.org/mailman/listinfo/vnfpool


_______________________________________________


vnfpool mailing list


vnfpool@ietf.=
org


https://www.ietf.org/mailman/listinfo/vnfpool











_______________________________________________


vnfpool mailing list


vnfpool@ietf.=
org


https://www.ietf.org/mailman/listinfo/vnfpool

 

--_000_B0D29E0424F2DE47A0B36779EC66677925859ABCnkgeml501mbschi_-- From zongning@huawei.com Tue Dec 10 21:54:11 2013 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 B4E921AE384 for ; Tue, 10 Dec 2013 21:54:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 x6OV4yMMKKAQ for ; Tue, 10 Dec 2013 21:54:07 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 478421AE1A7 for ; Tue, 10 Dec 2013 21:54:06 -0800 (PST) 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 AYW12899; Wed, 11 Dec 2013 05:54:00 +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; Wed, 11 Dec 2013 05:53:47 +0000 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; Wed, 11 Dec 2013 05:53:56 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Wed, 11 Dec 2013 13:53:51 +0800 From: Zongning To: "vnfpool@ietf.org" Thread-Topic: Problem Statement V2 Thread-Index: Ac72NV32hcZ3zANsT5ufj0o84neRqQ== Date: Wed, 11 Dec 2013 05:53:51 +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.28] Content-Type: multipart/alternative; boundary="_000_B0D29E0424F2DE47A0B36779EC66677925859B24nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [vnfpool] Problem Statement V2 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, 11 Dec 2013 05:54:11 -0000 --_000_B0D29E0424F2DE47A0B36779EC66677925859B24nkgeml501mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, folks, Thank you all for valuable comments & suggestions on problem statement duri= ng the past a few weeks. Please see below updated text, which I hope captur= es what we have discussed and agreed so far. Here is the highlight of the m= ain changes: 1) Add more text to clarify the scope of "reliability" we want to add= ress; 2) Add more descriptive text about VNF, as well as how it would impac= t reliability; 3) Modify some work item bullets; 4) Clarify relation with service function chaining (SFC) group; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D A virtualized network function (VNF) provides network function (e.g., firew= alling, load balancing), but is typically implemented as software instances= running on general server via virtualization layer (e.g. hypervisor). This= is distinct from monolithic network devices, where a number of different f= unctions are provided in the same device. Based on concept of service funct= ion chaining (SFC), a network service can be implemented by a set of sequen= tially connected VNF instances deployed at different points in the network = (or a VNF chain). A VNF chain introduces additional points of failure beyond those inherent i= n a single dedicated server, and therefore additional challenges on reliabi= lity. For a single VNF instance, it typically would not have built-in relia= bility mechanisms on its host (i.e. general server). Instead, there are mor= e factors such as software failure, server overload, and instance migration= that lead to VNF instance transition or failure. Currently generalized poo= ling and other redundancy mechanisms may be applied to address some reliabi= lity requirements of a single VNF. However, the need to support a growing n= umber of VNFs including stateful function, and extend the redundancy across= a VNF chain (i.e. multiple pools for multiple VNFs) requires further solut= ion development. For example, when a "live" VNF pool member goes out of ser= vice, how do adjacent entities learn which pool member will replace it? How= do VNFs learn the state of adjacent VNFs to support reliability mechanisms= like load sharing and switch before break? How is the service state of an = instance held and accessed for efficient synchronization with backup instan= ces and other members of its pool? Ideally, the reliability of VNF chain would mean that a VNF chain continues= to function throughout an interruption and outages will not be visible to = users of the chain. In the current charter, we scope our work around severa= l mechanisms supporting the reliability of VNF chain, which are redundancy = along multiple VNF pools, and stateful failover among pool members. Additio= nal mechanisms for reliable VNF chain might be included after further gap a= nalysis between our requirements and IETF technologies. The overall problem space can be further broken to include the following it= ems: . Signaling between VNF pools for transition (e.g. state change, scaling, m= oving) notification, backup announcement; . Identification and evaluation of state sharing mechanisms, including (but= not limited to) distributed shared memory, gossip protocols, pfsync, and s= tate check pointing; . Exchange of reliability related information between VNF pools and underly= ing network (e.g. interfacing with ALTO, I2RS); . Identify and analyze reliable transport characteristics for control plane= traffic; . Analysis of transport security characteristics to provide protection agai= nst known threats, and identification of an appropriate trust model; The initial work will include a problem statement, VNF pooling architecture= , use cases and requirements analysis, and an evaluation of existing techno= logies against the architecture and requirements. It is our expectation tha= t we will be able to rely heavily on existing IETF technologies but that ga= ps will be found around problems like state transfer and trust/security, wh= ich will need to be addressed. Particularly, we will work closely with SFC = group to develop mechanisms complementary to service function chaining appr= oaches, based on identified reliability requirements. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Please let me know if the update doesn't address your previous concerns. Fu= rther comments are also highly appreciated. Thanks. -Ning --_000_B0D29E0424F2DE47A0B36779EC66677925859B24nkgeml501mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, folks,

 

Thank you all for valuable comm= ents & suggestions on problem statement during the past a few weeks. Pl= ease see below updated text, which I hope captures what we have discussed a= nd agreed so far. Here is the highlight of the main changes:

1= )   &= nbsp;   Add more text to clarif= y the scope of “reliability” we want to address;

2= )   &= nbsp;   Add more descriptive te= xt about VNF, as well as how it would impact reliability;=

3= )   &= nbsp;   Modify some work item b= ullets;

4= )   &= nbsp;   Clarify relation with s= ervice function chaining (SFC) group;

 

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

A virtualized network function = (VNF) provides network function (e.g., firewalling, load balancing), but is= typically implemented as software instances running on general server via = virtualization layer (e.g. hypervisor). This is distinct from monolithic network devices, where a number of differ= ent functions are provided in the same device. Based on concept of service = function chaining (SFC), a network service can be implemented by a set of s= equentially connected VNF instances deployed at different points in the network (or a VNF chain).

A VNF chain introduces addition= al points of failure beyond those inherent in a single dedicated server, and therefore = additional challenges on reliability. Fo= r a single VNF instance, it typically would not have built-in reliability m= echanisms on its host (i.e. general server). Instead, there are more factors such as software failure, server overload, and instance = migration that lead to VNF instance transition or failure. Currently generalized pooling and other redundancy mechanisms may be applied to address some rel= iability requirements of a single VNF. However, the need to support a growi= ng number of VNFs including stateful function, and extend the redundancy ac= ross a VNF chain (i.e. multiple pools for multiple VNFs) requi= res further solution development. For example, when a "live" VNF = pool member goes out of service, how do adjacent entities learn which pool = member will replace it? How do VNFs learn the state of adjacent VNFs to support reliability mechanisms like load sharing= and switch before break? How is the service state of an instance held and = accessed for efficient synchronization with backup instances and other memb= ers of its pool?

Ideally, the reliability of VNF= chain would mean that a VNF chain continues to function throughout an inte= rruption and outages will not be visible to users of the chain. In the curr= ent charter, we scope our work around several mechanisms supporting the reliability of VNF chain, which are redu= ndancy along multiple VNF pools, and stateful failover among pool members. = Additional mechanisms for reliable VNF chain might be included after furthe= r gap analysis between our requirements and IETF technologies.

 

The overall problem space can b= e further broken to include the following items:

. Signaling between VNF pools f= or transition (e.g. state change, scaling, moving) notification, backup ann= ouncement;

. Identification and evaluation= of state sharing mechanisms, including (but not limited to) distributed sh= ared memory, gossip protocols, pfsync, and state check pointing;=

. Exchange of reliability relat= ed information between VNF pools and underlying network (e.g. interfacing w= ith ALTO, I2RS);

. Identify and analyze reliable= transport characteristics for control plane traffic;

. Analysis of transport securit= y characteristics to provide protection against known threats, and identifi= cation of an appropriate trust model;

 

The initial work will include a= problem statement, VNF pooling architecture, use cases and requirements an= alysis, and an evaluation of existing technologies against the architecture= and requirements. It is our expectation that we will be able to rely heavily on existing IETF technologies but tha= t gaps will be found around problems like state transfer and trust/security= , which will need to be addressed. Particularly, we will work closely with = SFC group to develop mechanisms complementary to service function chaining approaches, based on identified= reliability requirements.

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

 

Please let me know if the updat= e doesn’t address your previous concerns. Further comments are also h= ighly appreciated.

 

Thanks.

 

-Ning

--_000_B0D29E0424F2DE47A0B36779EC66677925859B24nkgeml501mbschi_-- From chidung.lac@orange.com Wed Dec 11 06:20:09 2013 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 6025C1ADF54 for ; Wed, 11 Dec 2013 06:20:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.884 X-Spam-Level: X-Spam-Status: No, score=-0.884 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665] 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 ChzltILf-1Zv for ; Wed, 11 Dec 2013 06:20:07 -0800 (PST) Received: from p-mail2.rd.orange.com (p-mail2.rd.orange.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id 67A251ADF33 for ; Wed, 11 Dec 2013 06:20:06 -0800 (PST) Received: from p-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6C922E3011A for ; Wed, 11 Dec 2013 15:23:34 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.orange.com (Postfix) with ESMTP id B1F55E30116 for ; Wed, 11 Dec 2013 15:23:33 +0100 (CET) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Dec 2013 15:19:59 +0100 Received: from [10.193.5.32] ([10.193.5.32]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Dec 2013 15:19:58 +0100 Message-ID: <52A87459.2040506@orange.com> Date: Wed, 11 Dec 2013 15:19:05 +0100 From: LAC Chidung User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: vnfpool@ietf.org References: <529912BF.4010307@nomountain.net> <701E4DC3-754C-4308-B507-D85BCAB9B2D6@tid.es> <4A95BA014132FF49AE685FAB4B9F17F645C2936D@dfweml509-mbx.china.huawei.com> <529E33BF.50002@gmail.com> <52A205CC.8060002@orange.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000402000401000002020008" X-OriginalArrivalTime: 11 Dec 2013 14:19:58.0839 (UTC) FILETIME=[12940070:01CEF67C] Subject: Re: [vnfpool] Question about addressing in pools 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, 11 Dec 2013 14:20:09 -0000 This is a multi-part message in MIME format. --------------000402000401000002020008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit A correction and a (partial) reply with the help of a colleague actively involved in ETSI NFV: 1) Although "VNFC (VNF Component)" is absent from the doc I mentioned and from the terminology doc (http://www.etsi.org/deliver/etsi_gs/NFV/001_099/003/01.01.01_60/gs_NFV003v010101p.pdf), it is included in on-going work at groups such as "Management & orchestration" and "Software architecture". As a VNF is made of VNFCs, a VM is thus an instance of a VNFC (and not of a VNF). 2) Management plane vs. control plane: a quite "philosophical" question - let's say that it is a real time management plane, i.e., very close to the control plane. Best, Chidung Le 09/12/2013 03:18, Qin Wu a écrit : > > If Pool manger can be compared to VNF manager, then the standards > interface we are really dealing with is the interface between EMS and > VNF manager? > > Not sure my understanding is correct. > > Also I am wondering whether the interface between EMS and VNF manager > is manage plane interface or control plane interface? > > Regards! > > -Qin > > *From:*vnfpool [mailto:vnfpool-bounces@ietf.org] *On Behalf Of *LAC > Chidung > *Sent:* Saturday, December 07, 2013 1:14 AM > *To:* vnfpool@ietf.org > *Subject:* Re: [vnfpool] Question about addressing in pools > > "*Who manage vNF? Hypervisor, controller or orchestrator, or just > hosted system?* " > If we refer to > http://docbox.etsi.org/ISG/NFV/Open/Published/gs_NFV002v010101p.pdf > Figure 4 suggests that (of course, I may be wrong ...): > - each VNF has its own element management system (EMS); different VNFs > from different vendors may be used to provide a certain network service > - the VNF Managers actions include (i) collecting data (OAM, etc.) > from the VNFs and from the virtual infrastructure; (ii) providing > scalability ('out' to create a new VM, or 'in' to suppress a VM - a VM > being an instance of a VNF) > - an unique orchestrator controlling the VNF Managers in a data center > (cloud) environment, e.g., OpenStack > Best, > Chidung > PS: the hypervisor, e.g., KVM, is represented in this figure by the > "Virtualisation Layer" > > Le 04/12/2013 02:36, Qin Wu a écrit : > > I think vNF#2 failover and replaced by VNF#1 means vNF#1 and vNF#2 has the same functionality. > > If it is this case, why vNF#2 and vNF#1 with the same functionality should be managed by two different pool managers rather than > > One common pool manager? > > Even vNF#2 and vNF#1 has different functionality or provide different service, can vNF#2 and vNF#1 be managed by the common pool manager? > > If we place the pool manger in NFV architecture specified by ETSI NFV? What the position of pool manager in such NFV architecture? Who manage vNF? Hypervisor, controller or orchestrator, or just hosted system? > > I agree with Melinda the endpoint doesn't need to know whether he is talking to vNF#1 or vNF#2. What he needs to do is > > Using something like name/address resolution mechanism to get the new address of backup vNF#2 when vNF#2 is down. > > Regards! > > -Qin > > > > -----Original Message----- > > From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of Melinda Shore > > Sent: Wednesday, December 04, 2013 3:41 AM > > To:vnfpool@ietf.org > > Subject: Re: [vnfpool] Question about addressing in pools > > > > On 12/3/13 10:25 AM, Linda Dunbar wrote: > > I think that it is the "VNF#2 pool manager" that will determine which > > instance in VNF#2 will be fail-over one, and is responsible for > > passing this VNF#2's failover instance address to "VNF#1 pool > > manager". > > I think it might be a little early to assume that. It's generally > > the case in HA scenarios that when there's a failover clients/endpoints > > do not know that they are talking to what a different box (or virtual > > box). In rserpool endpoints find and access services through > > ENRP - that is to say, unmodified clients can't take advantage > > of the pooling mechanism. I think we need to be clear about > > that. > > Melinda > > _______________________________________________ > > vnfpool mailing list > > vnfpool@ietf.org > > https://www.ietf.org/mailman/listinfo/vnfpool > > > _______________________________________________ > vnfpool mailing list > vnfpool@ietf.org > https://www.ietf.org/mailman/listinfo/vnfpool --------------000402000401000002020008 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit A correction and a (partial) reply with the help of a colleague actively involved in ETSI NFV:
1) Although "VNFC (VNF Component)" is absent from the doc I mentioned and from the terminology doc (http://www.etsi.org/deliver/etsi_gs/NFV/001_099/003/01.01.01_60/gs_NFV003v010101p.pdf), it is included in on-going work at groups such as "Management & orchestration" and "Software architecture". As a VNF is made of VNFCs, a VM is thus an instance of a VNFC (and not of a VNF).
2) Management plane vs. control plane: a quite "philosophical" question - let's say that it is a real time management plane, i.e., very close to the control plane.
Best,
Chidung
Le 09/12/2013 03:18, Qin Wu a écrit :

If Pool manger can be compared to VNF manager, then the standards interface we are really dealing with is the interface between EMS and VNF manager?

Not sure my understanding is correct.

Also I am wondering whether the interface between EMS and VNF manager is manage plane interface or control plane interface?

 Regards!

-Qin

From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of LAC Chidung
Sent: Saturday, December 07, 2013 1:14 AM
To: vnfpool@ietf.org
Subject: Re: [vnfpool] Question about addressing in pools

 

"Who manage vNF? Hypervisor, controller or orchestrator, or just hosted system? "
If we refer to http://docbox.etsi.org/ISG/NFV/Open/Published/gs_NFV002v010101p.pdf
Figure 4 suggests that (of course, I may be wrong ...):
- each VNF has its own element management system (EMS); different VNFs from different vendors may be used to provide a certain network service
- the VNF Managers actions include (i) collecting data (OAM, etc.) from the VNFs and from the virtual infrastructure; (ii) providing scalability ('out' to create a new VM, or 'in' to suppress a VM - a VM being an instance of a VNF)
- an unique orchestrator controlling the VNF Managers in a data center (cloud) environment, e.g., OpenStack
Best,
Chidung
PS: the hypervisor, e.g., KVM, is represented in this figure by the "Virtualisation Layer"

Le 04/12/2013 02:36, Qin Wu a écrit :

I think vNF#2 failover and replaced by VNF#1 means vNF#1 and vNF#2 has the same functionality.
If it is this case, why vNF#2 and vNF#1 with the same functionality should be managed by two different pool managers rather than
One common pool manager?
Even vNF#2 and vNF#1 has different functionality or provide different service, can vNF#2 and vNF#1 be managed by the common pool manager?
If we place the pool manger in NFV architecture specified by ETSI NFV? What the position of pool manager in such NFV architecture? Who manage vNF? Hypervisor, controller or orchestrator, or just hosted system?
I agree with Melinda the endpoint doesn't need to know whether he is talking to vNF#1 or vNF#2. What he needs to do is
Using something like name/address resolution mechanism to get the new address of backup vNF#2 when vNF#2 is down.
Regards!
-Qin
 
-----Original Message-----
From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of Melinda Shore
Sent: Wednesday, December 04, 2013 3:41 AM
To: vnfpool@ietf.org
Subject: Re: [vnfpool] Question about addressing in pools
 
On 12/3/13 10:25 AM, Linda Dunbar wrote:
I think that it is the "VNF#2 pool manager" that will determine which
instance in VNF#2 will be fail-over one, and is responsible for
passing this VNF#2's failover instance address to "VNF#1 pool
manager".
I think it might be a little early to assume that.  It's generally
the case in HA scenarios that when there's a failover clients/endpoints
do not know that they are talking to what a different box (or virtual
box).  In rserpool endpoints find and access services through
ENRP - that is to say, unmodified clients can't take advantage
of the pooling mechanism.  I think we need to be clear about
that.
Melinda
_______________________________________________
vnfpool mailing list
vnfpool@ietf.org
https://www.ietf.org/mailman/listinfo/vnfpool

_______________________________________________
vnfpool mailing list
vnfpool@ietf.org
https://www.ietf.org/mailman/listinfo/vnfpool
--------------000402000401000002020008-- From yokota@kddilabs.jp Wed Dec 11 20:30:36 2013 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 9F96C1ADFB9 for ; Wed, 11 Dec 2013 20:30:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.608 X-Spam-Level: X-Spam-Status: No, score=0.608 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 vlwdT8EuXi1P for ; Wed, 11 Dec 2013 20:30:33 -0800 (PST) Received: from mandala.kddilabs.jp (mandala.kddilabs.jp [IPv6:2001:200:601:12::16]) by ietfa.amsl.com (Postfix) with ESMTP id 6331E1ADF7C for ; Wed, 11 Dec 2013 20:30:32 -0800 (PST) Received: from localhost (mandala.kddilabs.jp [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 319F217480D4 for ; Thu, 12 Dec 2013 13:30:26 +0900 (JST) X-Virus-Scanned: amavisd-new at kddilabs.jp Received: from mandala.kddilabs.jp ([127.0.0.1]) by localhost (mandala.kddilabs.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ON69G93Gb0AE for ; Thu, 12 Dec 2013 13:30:25 +0900 (JST) Received: from ultra.mip.kddilabs.jp (ultra.mip.kddilabs.jp [172.19.90.145]) by mandala.kddilabs.jp (Postfix) with ESMTP id 68376174805F for ; Thu, 12 Dec 2013 13:30:25 +0900 (JST) Received: from [127.0.0.1] (dhcp197.west-4f.cn.kddilabs.jp [172.19.124.197]) by ultra.mip.kddilabs.jp (Postfix) with ESMTP id 513FB1B9B1 for ; Thu, 12 Dec 2013 13:19:24 +0900 (JST) Message-ID: <52A93BE0.8090206@kddilabs.jp> Date: Thu, 12 Dec 2013 13:30:24 +0900 From: Hidetoshi Yokota User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: vnfpool@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------090804030000020109070807" Subject: Re: [vnfpool] Problem Statement V2 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, 12 Dec 2013 04:30:36 -0000 This is a multi-part message in MIME format. --------------090804030000020109070807 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Hi Ning, Thanks for your update, which is starting to look like the charter. I have a couple of questions and comments: o I think it is good to emphasize reliability to clarify the scope of this work. RSerpool deals with pooling configuration, SFC deals with chaining configuration and VNFpool could leverage their work to enhance reliability. o Are we focusing more on VNF chain rather than VNF itself with regard to reliability? Maybe, we could include both and it is part of the study to identify the additional requirements for VNF chain. o Based on the architecture figure you provided, we should also study the signaling between Pool manager and VNFs. I would propose the following text "Signaling between VNF pools for transition..." -> "Signaling "within and" between VNF pools for transition..." o State synchronization is important, but when VNF migration or replacement occurs, flow route synchronization is also important. This feature should also be captured. Regards, -- Hidetoshi Yokota KDDI R&D Laboratories, Inc. e-mail:yokota@kddilabs.jp (2013/12/11 14:53), Zongning wrote: > > Hi, folks, > > Thank you all for valuable comments & suggestions on problem statement > during the past a few weeks. Please see below updated text, which I > hope captures what we have discussed and agreed so far. Here is the > highlight of the main changes: > > 1)Add more text to clarify the scope of $B!H(Breliability$B!I(B we want to address; > > 2)Add more descriptive text about VNF, as well as how it would impact > reliability; > > 3)Modify some work item bullets; > > 4)Clarify relation with service function chaining (SFC) group; > > =========================================================== > > A virtualized network function (VNF) provides network function (e.g., > firewalling, load balancing), but is typically implemented as software > instances running on general server via virtualization layer (e.g. > hypervisor). This is distinct from monolithic network devices, where a > number of different functions are provided in the same device. Based > on concept of service function chaining (SFC), a network service can > be implemented by a set of sequentially connected VNF instances > deployed at different points in the network (or a VNF chain). > > A VNF chain introduces additional points of failure beyond those > inherent in a single dedicated server, and therefore additional > challenges on reliability. For a single VNF instance, it typically > would not have built-in reliability mechanisms on its host (i.e. > general server). Instead, there are more factors such as software > failure, server overload, and instance migration that lead to VNF > instance transition or failure. Currently generalized pooling and > other redundancy mechanisms may be applied to address some reliability > requirements of a single VNF. However, the need to support a growing > number of VNFs including stateful function, and extend the redundancy > across a VNF chain (i.e. multiple pools for multiple VNFs) requires > further solution development. For example, when a "live" VNF pool > member goes out of service, how do adjacent entities learn which pool > member will replace it? How do VNFs learn the state of adjacent VNFs > to support reliability mechanisms like load sharing and switch before > break? How is the service state of an instance held and accessed for > efficient synchronization with backup instances and other members of > its pool? > > Ideally, the reliability of VNF chain would mean that a VNF chain > continues to function throughout an interruption and outages will not > be visible to users of the chain. In the current charter, we scope our > work around several mechanisms supporting the reliability of VNF > chain, which are redundancy along multiple VNF pools, and stateful > failover among pool members. Additional mechanisms for reliable VNF > chain might be included after further gap analysis between our > requirements and IETF technologies. > > The overall problem space can be further broken to include the > following items: > > . Signaling between VNF pools for transition (e.g. state change, > scaling, moving) notification, backup announcement; > > . Identification and evaluation of state sharing mechanisms, including > (but not limited to) distributed shared memory, gossip protocols, > pfsync, and state check pointing; > > . Exchange of reliability related information between VNF pools and > underlying network (e.g. interfacing with ALTO, I2RS); > > . Identify and analyze reliable transport characteristics for control > plane traffic; > > . Analysis of transport security characteristics to provide protection > against known threats, and identification of an appropriate trust model; > > The initial work will include a problem statement, VNF pooling > architecture, use cases and requirements analysis, and an evaluation > of existing technologies against the architecture and requirements. It > is our expectation that we will be able to rely heavily on existing > IETF technologies but that gaps will be found around problems like > state transfer and trust/security, which will need to be addressed. > Particularly, we will work closely with SFC group to develop > mechanisms complementary to service function chaining approaches, > based on identified reliability requirements. > > ============================================================ > > Please let me know if the update doesn$B!G(Bt address your previous > concerns. Further comments are also highly appreciated. > > Thanks. > > -Ning > > > > _______________________________________________ > vnfpool mailing list > vnfpool@ietf.org > https://www.ietf.org/mailman/listinfo/vnfpool --------------090804030000020109070807 Content-Type: text/html; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Hi Ning,

Thanks for your update, which is starting to look like the charter.

I have a couple of questions and comments:

o I think it is good to emphasize reliability to clarify the scope of this work. RSerpool deals with pooling configuration, SFC deals with chaining configuration and VNFpool could leverage their work to enhance reliability.
 
o Are we focusing more on VNF chain rather than VNF itself with regard to reliability? Maybe, we could include both and it is part of the study to identify the additional requirements for VNF chain.

o Based on the architecture figure you provided, we should also study the signaling between Pool manager and VNFs. I would propose the following text

"Signaling between VNF pools for transition..."
->
"Signaling "within and" between VNF pools for transition..."

o State synchronization is important, but when VNF migration or replacement occurs, flow route synchronization is also important. This feature should also be captured.

Regards,
 
-- 
Hidetoshi Yokota

KDDI R&D Laboratories, Inc.
e-mail:yokota@kddilabs.jp
(2013/12/11 14:53), Zongning wrote:

Hi, folks,

 

Thank you all for valuable comments & suggestions on problem statement during the past a few weeks. Please see below updated text, which I hope captures what we have discussed and agreed so far. Here is the highlight of the main changes:

1)       Add more text to clarify the scope of $B!H(Breliability$B!I(B we want to address;

2)       Add more descriptive text about VNF, as well as how it would impact reliability;

3)       Modify some work item bullets;

4)       Clarify relation with service function chaining (SFC) group;

 

===========================================================

A virtualized network function (VNF) provides network function (e.g., firewalling, load balancing), but is typically implemented as software instances running on general server via virtualization layer (e.g. hypervisor). This is distinct from monolithic network devices, where a number of different functions are provided in the same device. Based on concept of service function chaining (SFC), a network service can be implemented by a set of sequentially connected VNF instances deployed at different points in the network (or a VNF chain).

A VNF chain introduces additional points of failure beyond those inherent in a single dedicated server, and therefore additional challenges on reliability. For a single VNF instance, it typically would not have built-in reliability mechanisms on its host (i.e. general server). Instead, there are more factors such as software failure, server overload, and instance migration that lead to VNF instance transition or failure. Currently generalized pooling and other redundancy mechanisms may be applied to address some reliability requirements of a single VNF. However, the need to support a growing number of VNFs including stateful function, and extend the redundancy across a VNF chain (i.e. multiple pools for multiple VNFs) requires further solution development. For example, when a "live" VNF pool member goes out of service, how do adjacent entities learn which pool member will replace it? How do VNFs learn the state of adjacent VNFs to support reliability mechanisms like load sharing and switch before break? How is the service state of an instance held and accessed for efficient synchronization with backup instances and other members of its pool?

Ideally, the reliability of VNF chain would mean that a VNF chain continues to function throughout an interruption and outages will not be visible to users of the chain. In the current charter, we scope our work around several mechanisms supporting the reliability of VNF chain, which are redundancy along multiple VNF pools, and stateful failover among pool members. Additional mechanisms for reliable VNF chain might be included after further gap analysis between our requirements and IETF technologies.

 

The overall problem space can be further broken to include the following items:

. Signaling between VNF pools for transition (e.g. state change, scaling, moving) notification, backup announcement;

. Identification and evaluation of state sharing mechanisms, including (but not limited to) distributed shared memory, gossip protocols, pfsync, and state check pointing;

. Exchange of reliability related information between VNF pools and underlying network (e.g. interfacing with ALTO, I2RS);

. Identify and analyze reliable transport characteristics for control plane traffic;

. Analysis of transport security characteristics to provide protection against known threats, and identification of an appropriate trust model;

 

The initial work will include a problem statement, VNF pooling architecture, use cases and requirements analysis, and an evaluation of existing technologies against the architecture and requirements. It is our expectation that we will be able to rely heavily on existing IETF technologies but that gaps will be found around problems like state transfer and trust/security, which will need to be addressed. Particularly, we will work closely with SFC group to develop mechanisms complementary to service function chaining approaches, based on identified reliability requirements.

============================================================

 

Please let me know if the update doesn$B!G(Bt address your previous concerns. Further comments are also highly appreciated.

 

Thanks.

 

-Ning



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

--------------090804030000020109070807-- From yokota@kddilabs.jp Wed Dec 11 20:42:20 2013 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 DBD061ADFF5 for ; Wed, 11 Dec 2013 20:42:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.808 X-Spam-Level: * X-Spam-Status: No, score=1.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_34=0.6, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 c09Ir5KGI0oY for ; Wed, 11 Dec 2013 20:42:16 -0800 (PST) Received: from mandala.kddilabs.jp (mandala.kddilabs.jp [IPv6:2001:200:601:12::16]) by ietfa.amsl.com (Postfix) with ESMTP id 5B7F11ADFE2 for ; Wed, 11 Dec 2013 20:42:15 -0800 (PST) Received: from localhost (mandala.kddilabs.jp [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id EA0B417480CA for ; Thu, 12 Dec 2013 13:42:02 +0900 (JST) X-Virus-Scanned: amavisd-new at kddilabs.jp Received: from mandala.kddilabs.jp ([127.0.0.1]) by localhost (mandala.kddilabs.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0gkTfdFEwfp for ; Thu, 12 Dec 2013 13:42:01 +0900 (JST) Received: from ultra.mip.kddilabs.jp (ultra.mip.kddilabs.jp [172.19.90.145]) by mandala.kddilabs.jp (Postfix) with ESMTP id 421131748101 for ; Thu, 12 Dec 2013 13:42:00 +0900 (JST) Received: from [127.0.0.1] (dhcp197.west-4f.cn.kddilabs.jp [172.19.124.197]) by ultra.mip.kddilabs.jp (Postfix) with ESMTP id 16D5D1B9B1 for ; Thu, 12 Dec 2013 13:30:59 +0900 (JST) Message-ID: <52A93E96.5090805@kddilabs.jp> Date: Thu, 12 Dec 2013 13:41:58 +0900 From: Hidetoshi Yokota User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: vnfpool@ietf.org References: <52940EB0.6040601@kddilabs.jp> <529C5A30.3070000@orange.com> <4A95BA014132FF49AE685FAB4B9F17F645C293E9@dfweml509-mbx.china.huawei.com> <52A1FE77.10405@orange.com> <65174429B5AF4C45BD0798810EC48E0A0D38CF@EX-0-MB2.lancs.local> <65174429B5AF4C45BD0798810EC48E0A0D3C3B@EX-0-MB2.lancs.local> In-Reply-To: <65174429B5AF4C45BD0798810EC48E0A0D3C3B@EX-0-MB2.lancs.local> Content-Type: multipart/alternative; boundary="------------050600050602030203040808" Subject: Re: [vnfpool] VNF Pool 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, 12 Dec 2013 04:42:20 -0000 This is a multi-part message in MIME format. --------------050600050602030203040808 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Hi Dan and Ning, The following scenario is very important and should be captured in this work. At least, the IP address of VNF#2 should be preserved even if the role is handed over to VNF#3. This is because in some applications, the state information includes the IP address of the peer, so if the IP address changes due to the failure recovery, the state information in VNF#1 will become inconsistent. Please take this scenario into consideration. Regards, -- Hidetoshi Yokota KDDI R&D Laboratories, Inc. e-mail:yokota@kddilabs.jp (2013/12/10 6:19), King, Daniel wrote: > > Hi Ning, > > Good question, I would modify slightly. If VNF#2 needs to replicate > state (FW or otherwise) to its designated backup (VNF#3), it should > probably have the IP connectivity knowledge to do this. When failure > (loss of VNF#2) happens, should the existing network resilience > mechanisms route traffic to VNF#3, without VNF#1 having to detect loss > of VNF#2 and switching to VNF#3 instead. > > Phew, quite a number of permutations. We will update the I-D to > encompass these discussions/scenarios. > > Br, Dan. > > *From:*vnfpool [mailto:vnfpool-bounces@ietf.org] *On Behalf Of *Zongning > *Sent:* 09 December 2013 02:05 > *To:* King, Daniel; LAC Chidung > *Cc:* vnfpool@ietf.org; Linda Dunbar > *Subject:* Re: [vnfpool] VNF Pool Problem Statement > > Hi, Daniel, > > I agree this is a fair question to ask, thanks! > > Please allow me to ask another question ($B!H(Ba flip side of the coin$B!I(B): > do we have use case to show that the instance in VNF#1 pool needs to > know the standby address of the instance in VNF#2 pool? For example, > suppose we have a vLB instance (vLB-1) talking to a vFW instance > (vFW-1) with two standby instances (vFW-2, vFW-3), if vLB-1 need to > know the address of vFW-2, vFW-3, or not **in any case**? > > Anyway, I guess this is a good work for co-authors of use case draft. J > > -Ning > > *From:*vnfpool [mailto:vnfpool-bounces@ietf.org] *On Behalf Of *King, > Daniel > *Sent:* Saturday, December 07, 2013 5:02 AM > *To:* LAC Chidung > *Cc:* vnfpool@ietf.org ; Linda Dunbar > *Subject:* Re: [vnfpool] VNF Pool Problem Statement > > Hi Chidung, > > Thanks for using definitions, and providing the example use cases. The > service chaining and non-service chaining examples are good, but could > you also clarify a deployment, and therefore, solution requirements > from an operator perspective? > > Is it expected that client service ($B!H(BFW$B!I(B in this use case) resilience > would be typically be provided by each VNF pool sharing the same VLAN, > with a virtual server using a $B!H(Bfixed IP$B!I(B address that maps to a > cluster of $B!H(Bdynamic IP addresses$B!I(B to multiple VMs, with say one VM for > hosting a VNF(s)? Spanning tree would run between the VM instances, > and VRRP used to provide backup for the default gateways. This > deployment scenario would support the following: > > - Load-balancing across VNFs > > - Fail-over between VNFs > > - Migration to new VNFs > > This architecture would also support mixed environments, where > existing propriety FW hardware and virtual (VM/VNFs) might be used for > migration and testing. Actually, the same question to the other > operators. It would be really good to understand the thinking behind > how best to achieve cost-effective (time and resources) resilience. As > a co-author of $B!H(Bdraft-xia-vsnpool-management-use-case$B!I(B I am trying to > figure out if $B!H(Bexisting$B!I(B (VRRP, RSPT, et al.) mechanisms are capable > of providing client service continuity and distributed resilience, or > indeed we need to document a set of generic requirements that our work > in vnfpool will need to solve. > > Br, Dan. > > *From:*vnfpool [mailto:vnfpool-bounces@ietf.org] *On Behalf Of *LAC > Chidung > *Sent:* 06 December 2013 16:43 > *To:* Linda Dunbar; vnfpool@ietf.org > *Subject:* Re: [vnfpool] VNF Pool Problem Statement > > Hi Linda, > Please correct the following if I'm wrong. > Let's define: VNF = one type of function. > _Case 1:_ no service chaining, e.g., a firewall provides the network > service > Let's state that 3 firewalls are needed, i.e., 3 instances of the VNF > "FW". > "*/VNFs have higher chance to fail due to lack of built-in > redundancy/*" combined with the use of "*/vnfpool/*" means: > 1) The 3 FW instances are deployed neither in active/active, nor in > active/standby mode, i.e., there are only 3 instances, and not 3 > active, and 3 standby. > 2) But this solution is not a trusted one because of "*/server > failure, server over-utilized, or software failure, etc./*". > 3) Assuming that the load of each (FW) instance is less than 60%, one > can get HA for this system by using the 3 instances in a pool > architecture (based on an efficient load balancing mechanism). > 4) In this case, the failure of one instance is acceptable because its > load will be shared by the two remaining instances. > _Case 2:_ service chaining, e.g., VNF1 and VNF2 are needed in order to > provide the network service (for instance, a kid requesting a Web page > with the use of a smartphone -> "parental control" (VNF1) checks the > URL, followed by "header enrichment" (VNF2) which adds the user ID in > the media flow) > Lets' state that we have 3 instances of VNF1 and 3 instances of VNF2. > If we apply the same reasoning (and hypotheses) as above, we will have > a 1st pool made up of 3 instances of VNF1, and a 2nd pool made up of 3 > instances of VNF2. The HA of this system is guaranteed if: (i) 1 > instance of VNF1 fails, (ii) 1 instance of VNF2 fails, (iii) 1 > instance of VNF2 fails and 1 instance of VNF2 fails. > Best, > Chidung > > Le 03/12/2013 21:06, Linda Dunbar a e'crit : > > Chidung, > > Thanks for the quote. > > Based on your quote, the goal of $B!H(Bvnfpool$B!I(B should be about to > achieve $B!H(Bhigh availability$B!I(B of service function chaining while > individual service function instances are NOT reliable. As stated > in the problem statement, the virtualized network functions have > higher chance to fail due to lack of built-in redundancy, server > failure, server over-utilized, or software failure, etc. > > Linda > > *From:*vnfpool [mailto:vnfpool-bounces@ietf.org] *On Behalf Of > *LAC Chidung > *Sent:* Monday, December 02, 2013 4:00 AM > *To:* vnfpool@ietf.org > *Subject:* Re: [vnfpool] VNF Pool Problem Statement > > Hi all, > /Reliability is the ability of an item to perform a required > function under stated conditions for a stated period of time/, > while/Availability is a measure of the degree to which an item is > in an operable state when called upon to perform./ (D.J. Klinger, > Y. Nakada, and M.A. Menedez (Eds.), "AT&T Reliability Manual", Van > Nostrand Reinhold, 1990) > Applied to the PSTN, the former includes "My call is not dropped > during a conversation", while the latter asks for "The phone > service is ready, i.e., a tone is present, whenever I lift the > handset". > For years, /Dependability /has encompassed these concepts > (together with others such as /Maintainability) /to characterize > the good behavior (robustness) of a system when facing *accidental > *events (design faults, operations errors, hardware failures, > natural disasters, etc.) , while /Security, /which includes all > *intentional *actions (attacks, ...), is kept apart. This explains > the presence, up to now, of two communities working in these two > separated subjects. > As (i) unavailability may the consequence of, e.g., > software/hardware failures OR (D)DoS attacks (ii) /Resilience/ is > a fashionable expression* (iii) etc., resilience is used since the > last few years to encompass both dependability and security. > Best, > Chidung > _______ > *: see, e.g., Obama's praise for the resilience of the Indian > people > (http://articles.latimes.com/2010/nov/06/world/la-fgw-obama-mumbai-20101107) > > Le 02/12/2013 08:21, Cao,Zhen a e'crit : > > Good point, Diego. > > I checked out the NFV ISG released documents of requirements and > > terminology, where i could not find 'reliability' but 'resilience'. > > -cz > > > > On Wed, Nov 27, 2013 at 2:06 AM, Diego R. Lopez wrote: > > Hi, > > When it comes to the reliability/availability issue I guess providing some > > (condensed) definition from the NFV REL group would help... > > Be goode, > > > > On 26 Nov 2013, at 04:00 , Hidetoshi Yokota wrote: > > > > Hi Ning and all, > > The proposed PS is a very good starting point covering major issues for the > > goal of VNF pool. One thing that I could add is the synchronization between > > the vNF migration/replacement and routing to make the relevant flows > > forwarded to the new location. The challenge is that the VMs/severs in a > > pool could be deployed over topologically different networks (in the > > physical world) and VNF migration could involve topologically independent > > routing. There are multiple ways to do it, but we should first generalize > > this issue and specify a common mechanism that may leverage existing ones. > > If this is already covered, that's fine. If some additional text is useful, > > the following could be a summary: > > o Synchronization between vNF migration and flow forwarding, which may > > require topologically independent routing in the physical transport network; > > There is a discussion about "reliability" and "availability" in another > > thread and I think this is also an issue in ETSI NFV. We need to define them > > either in this group or NFV to share the same view. > > Regards, > > -- > > Hidetoshi Yokota > > > > KDDI R&D Laboratories, Inc. > > e-mail:yokota@kddilabs.jp > > > > (2013/11/21 18:11), Zongning wrote: > > > > Hi, > > Please review the below brief version of VNF Pool Problem Statement, and > > feedback with your comments. I hope this text can serve as a base of VNF > > Pool Charter, by carving out real problems and work items. > > =========================================================================================== > > A virtualized network function (VNF) (e.g. vFW, vLB) provides the same > > function as the equivalent network function (e.g. FW, LB), but is usually > > instantiated as a cluster of software instances running on general purpose > > servers via virtualization platform. In an environment based on VNFs, a > > network service is typically realized by a chain of VNFs where the instances > > of adjacent VNFs are preferably directly connected. > > A VNF chain introduces additional points of failure beyond those inherent in > > a single dedicated server, and therefore additional challenges on > > reliability. By reliability, we mean the ability of a VNF chain to continue > > function when having transition or failure within the chain. For example, > > there are more factors such as software failure, server over-utilization, > > instance migration that potentially cause VNF instance transition or > > failure. Although a general pooling mechanism can be applied to address the > > reliability of a single VNF, there are still problems when addressing the > > reliability of a VNF chain, i.e. multiple pools for multiple VNFs. For > > example, how does an instance of VNF#1 know which instance in the pool of > > VNF#2 will replace the instance of VNF#2 it connects to? How does an > > instance of VNF#1 know the state of instance of VNF#2 that it connects to in > > order to enforce policy for reliability like load sharing, switch before > > break? How is the service state of an instance held and accessed for > > efficient synchronization with backup instances? > > The overall problem space can be further breakdown to the following study > > items: > > - Signalling to handle reliability and instance transition > > requirements > > o Signalling between VNF pools for transition (e.g. state change, scaling, > > moving) notification, backup announcement; > > o Service state management (e.g. synchronizing method, state data format, > > location and mechanism to access state data) within VNF pool; > > o Obtaining underlying network information (e.g. ALTO, I2RS); > > o Signalling to CMS for instance deployment reflecting reliability > > requirements (e.g. distribution of instances on different VMs or > > hypervisors); > > - Transport characteristics > > o Identify and analyze reliable transport characteristics for control > > plane traffic; > > o Analysis of transport security characteristics to provide protection > > against known threats, and identification of an appropriate trust model; > > =========================================================================================== > > Thanks. > > -Ning > > > > -- > > "Esta vez no fallaremos, Doctor Infierno" > > > > Dr Diego R. Lopez > > Telefonica I+D > > http://people.tid.es/diego.lopez/ > > > > e-mail: diego@tid.es > > Tel: +34 913 129 041 > > Mobile: +34 682 051 091 > > ----------------------------------------- > > > > vnfpool mailing list > > vnfpool@ietf.org > > https://www.ietf.org/mailman/listinfo/vnfpool > > > > _______________________________________________ > vnfpool mailing list > vnfpool@ietf.org > https://www.ietf.org/mailman/listinfo/vnfpool --------------050600050602030203040808 Content-Type: text/html; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Hi Dan and Ning,

The following scenario is very important and should be captured in this work. At least, the IP address of VNF#2 should be preserved even if the role is handed over to VNF#3. This is because in some applications, the state information includes the IP address of the peer, so if the IP address changes due to the failure recovery, the state information in VNF#1 will become inconsistent. Please take this scenario into consideration.

Regards,
 
-- 
Hidetoshi Yokota

KDDI R&D Laboratories, Inc.
e-mail:yokota@kddilabs.jp
(2013/12/10 6:19), King, Daniel wrote:

Hi Ning,

 

Good question, I would modify slightly. If VNF#2 needs to replicate state (FW or otherwise) to its designated backup (VNF#3), it should probably have the IP connectivity knowledge to do this. When failure (loss of VNF#2) happens, should the existing network resilience mechanisms route traffic to VNF#3, without VNF#1 having to detect loss of VNF#2 and switching to VNF#3 instead.

 

Phew, quite a number of permutations. We will update the I-D to encompass these discussions/scenarios.

 

Br, Dan.

 

From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of Zongning
Sent: 09 December 2013 02:05
To: King, Daniel; LAC Chidung
Cc: vnfpool@ietf.org; Linda Dunbar
Subject: Re: [vnfpool] VNF Pool Problem Statement

 

Hi, Daniel,

 

I agree this is a fair question to ask, thanks!

Please allow me to ask another question ($B!H(Ba flip side of the coin$B!I(B): do we have use case to show that the instance in VNF#1 pool needs to know the standby address of the instance in VNF#2 pool? For example, suppose we have a vLB instance (vLB-1) talking to a vFW instance (vFW-1) with two standby instances (vFW-2, vFW-3), if vLB-1 need to know the address of vFW-2, vFW-3, or not *in any case*?

Anyway, I guess this is a good work for co-authors of use case draft. J

 

-Ning

 

From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of King, Daniel
Sent: Saturday, December 07, 2013 5:02 AM
To: LAC Chidung
Cc: vnfpool@ietf.org; Linda Dunbar
Subject: Re: [vnfpool] VNF Pool Problem Statement

 

Hi Chidung,

 

Thanks for using definitions, and providing the example use cases. The service chaining and non-service chaining examples are good, but could you also clarify a deployment, and therefore, solution requirements from an operator perspective?

 

Is it expected that client service ($B!H(BFW$B!I(B in this use case) resilience would be typically be provided by each VNF pool sharing the same VLAN, with a virtual server using a $B!H(Bfixed IP$B!I(B address that maps to a cluster of $B!H(Bdynamic IP addresses$B!I(B to multiple VMs, with say one VM for hosting a VNF(s)? Spanning tree would run between the VM instances, and VRRP used to provide backup for the default gateways. This deployment scenario would support the following:

 

- Load-balancing across VNFs

- Fail-over between VNFs

- Migration to new VNFs

 

This architecture would also support mixed environments, where existing propriety FW hardware and virtual (VM/VNFs) might be used for migration and testing. Actually, the same question to the other operators. It would be really good to understand the thinking behind how best to achieve cost-effective (time and resources) resilience. As a co-author of $B!H(Bdraft-xia-vsnpool-management-use-case$B!I(B I am trying to figure out if $B!H(Bexisting$B!I(B (VRRP, RSPT, et al.) mechanisms are capable of providing client service continuity and distributed resilience, or indeed we need to document a set of generic requirements that our work in vnfpool will need to solve.

 

Br, Dan.

 

From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of LAC Chidung
Sent: 06 December 2013 16:43
To: Linda Dunbar; vnfpool@ietf.org
Subject: Re: [vnfpool] VNF Pool Problem Statement

 

Hi Linda,
Please correct the following if I'm wrong.
Let's define: VNF = one type of function.
Case 1: no service chaining, e.g., a firewall provides the network service
Let's state that 3 firewalls are needed, i.e., 3 instances of the VNF "FW".
"VNFs have higher chance to fail due to lack of built-in redundancy" combined with the use of "vnfpool" means:
1) The 3 FW instances are deployed neither in active/active, nor in active/standby mode, i.e., there are only 3 instances, and not 3 active, and 3 standby.
2) But this solution is not a trusted one because of "server failure, server over-utilized, or software failure, etc.".
3) Assuming that the load of each (FW) instance is less than 60%, one can get HA for this system by using the 3 instances in a pool architecture (based on an efficient load balancing mechanism).
4) In this case, the failure of one instance is acceptable because its load will be shared by the two remaining instances.
Case 2: service chaining, e.g., VNF1 and VNF2 are needed in order to provide the network service (for instance, a kid requesting a Web page with the use of a smartphone -> "parental control" (VNF1) checks the URL, followed by "header enrichment" (VNF2) which adds the user ID in the media flow)
Lets' state that we have 3 instances of VNF1 and 3 instances of VNF2. If we apply the same reasoning (and hypotheses) as above, we will have a 1st pool made up of 3 instances of VNF1, and a 2nd pool made up of 3 instances of VNF2. The HA of this system is guaranteed if: (i) 1 instance of VNF1 fails, (ii) 1 instance of VNF2 fails, (iii) 1 instance of VNF2 fails and 1 instance of VNF2 fails.
Best,
Chidung

Le 03/12/2013 21:06, Linda Dunbar a écrit :

Chidung,

Thanks for the quote.

Based on your quote, the goal of $B!H(Bvnfpool$B!I(B should be about to achieve $B!H(Bhigh availability$B!I(B of service function chaining while individual service function instances are NOT reliable.  As stated in the problem statement, the virtualized network functions have higher chance to fail due to lack of built-in redundancy, server failure, server over-utilized, or software failure, etc.

Linda

 

From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of LAC Chidung
Sent: Monday, December 02, 2013 4:00 AM
To: vnfpool@ietf.org
Subject: Re: [vnfpool] VNF Pool Problem Statement

 

Hi all,
Reliability is the ability of an item to perform a required function under stated conditions for a stated period of time, while Availability is a measure of the degree to which an item is in an operable state when called upon to perform. (D.J. Klinger, Y. Nakada, and M.A. Menedez (Eds.), "AT&T Reliability Manual", Van Nostrand Reinhold, 1990)
Applied to the PSTN, the former includes "My call is not dropped during a conversation", while the latter asks for "The phone service is ready, i.e., a tone is present, whenever I lift the handset".
For years, Dependability has encompassed these concepts (together with others such as Maintainability) to characterize the good behavior (robustness) of a system when facing accidental events (design faults, operations errors, hardware failures, natural disasters, etc.) , while Security, which includes all intentional actions (attacks, ...), is kept apart. This explains the presence, up to now, of two communities working in these two separated subjects.
As (i) unavailability may the consequence of, e.g., software/hardware failures OR (D)DoS attacks (ii) Resilience is a fashionable expression* (iii) etc., resilience is used since the last few years to encompass both dependability and security.
Best,
Chidung
_______
*: see, e.g., Obama's praise for the resilience of the Indian people (http://articles.latimes.com/2010/nov/06/world/la-fgw-obama-mumbai-20101107)

Le 02/12/2013 08:21, Cao,Zhen a écrit :

Good point, Diego.
I checked out the NFV ISG released documents of requirements and
terminology, where i could not find 'reliability' but 'resilience'.
-cz
 
On Wed, Nov 27, 2013 at 2:06 AM, Diego R. Lopez <diego@tid.es> wrote:
Hi,
When it comes to the reliability/availability issue I guess providing some
(condensed) definition from the NFV REL group would help...
Be goode,
 
On 26 Nov 2013, at 04:00 , Hidetoshi Yokota wrote:
 
Hi Ning and all,
The proposed PS is a very good starting point covering major issues for the
goal of VNF pool. One thing that I could add is the synchronization between
the vNF migration/replacement and routing to make the relevant flows
forwarded to the new location. The challenge is that the VMs/severs in a
pool could be deployed over topologically different networks (in the
physical world) and VNF migration could involve topologically independent
routing. There are multiple ways to do it, but we should first generalize
this issue and specify a common mechanism that may leverage existing ones.
If this is already covered, that's fine. If some additional text is useful,
the following could be a summary:
o Synchronization between vNF migration and flow forwarding, which may
require topologically independent routing in the physical transport network;
There is a discussion about "reliability" and "availability" in another
thread and I think this is also an issue in ETSI NFV. We need to define them
either in this group or NFV to share the same view.
Regards,
--
Hidetoshi Yokota
 
KDDI R&D Laboratories, Inc.
e-mail:yokota@kddilabs.jp
 
(2013/11/21 18:11), Zongning wrote:
 
Hi,
Please review the below brief version of VNF Pool Problem Statement, and
feedback with your comments. I hope this text can serve as a base of VNF
Pool Charter, by carving out real problems and work items.
===========================================================================================
A virtualized network function (VNF) (e.g. vFW, vLB) provides the same
function as the equivalent network function (e.g. FW, LB), but is usually
instantiated as a cluster of software instances running on general purpose
servers via virtualization platform. In an environment based on VNFs, a
network service is typically realized by a chain of VNFs where the instances
of adjacent VNFs are preferably directly connected.
A VNF chain introduces additional points of failure beyond those inherent in
a single dedicated server, and therefore additional challenges on
reliability. By reliability, we mean the ability of a VNF chain to continue
function when having transition or failure within the chain. For example,
there are more factors such as software failure, server over-utilization,
instance migration that potentially cause VNF instance transition or
failure. Although a general pooling mechanism can be applied to address the
reliability of a single VNF, there are still problems when addressing the
reliability of a VNF chain, i.e. multiple pools for multiple VNFs. For
example, how does an instance of VNF#1 know which instance in the pool of
VNF#2 will replace the instance of VNF#2 it connects to? How does an
instance of VNF#1 know the state of instance of VNF#2 that it connects to in
order to enforce policy for reliability like load sharing, switch before
break? How is the service state of an instance held and accessed for
efficient synchronization with backup instances?
The overall problem space can be further breakdown to the following study
items:
-          Signalling to handle reliability and instance transition
requirements
o   Signalling between VNF pools for transition (e.g. state change, scaling,
moving) notification, backup announcement;
o   Service state management (e.g. synchronizing method, state data format,
location and mechanism to access state data) within VNF pool;
o   Obtaining underlying network information (e.g. ALTO, I2RS);
o   Signalling to CMS for instance deployment reflecting reliability
requirements (e.g. distribution of instances on different VMs or
hypervisors);
-          Transport characteristics
o   Identify and analyze reliable transport characteristics for control
plane traffic;
o   Analysis of transport security characteristics to provide protection
against known threats, and identification of an appropriate trust model;
===========================================================================================
Thanks.
-Ning
 
--
"Esta vez no fallaremos, Doctor Infierno"
 
Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/
 
e-mail: diego@tid.es
Tel:    +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------
 
vnfpool mailing list
vnfpool@ietf.org
https://www.ietf.org/mailman/listinfo/vnfpool


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

--------------050600050602030203040808-- From d.king@lancaster.ac.uk Wed Dec 11 22:54:58 2013 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 8FCCE1AE18E for ; Wed, 11 Dec 2013 22:54:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.6 X-Spam-Level: X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, 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 Tz28iT4vUaM8 for ; Wed, 11 Dec 2013 22:54:49 -0800 (PST) Received: from ignavia.lancs.ac.uk (ignavia.lancs.ac.uk [148.88.25.16]) by ietfa.amsl.com (Postfix) with ESMTP id D3EF91AE186 for ; Wed, 11 Dec 2013 22:54:48 -0800 (PST) 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 1Vr0AT-0006CU-R4; Thu, 12 Dec 2013 06:54:41 +0000 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.0158.001; Thu, 12 Dec 2013 06:54:41 +0000 From: "King, Daniel" To: Hidetoshi Yokota , "vnfpool@ietf.org" Thread-Topic: [vnfpool] VNF Pool Problem Statement Thread-Index: AQHY+TQ7dY3tQjejG3tIVJ9qDrtQ3QIpAmXyASf3zuYCZZPHvAKcw0hyAt4ScbICsFsViAHVabrCAveJ9ciZot03AIADo8gAgAAko3A= Date: Thu, 12 Dec 2013 06:54:40 +0000 Message-ID: <65174429B5AF4C45BD0798810EC48E0A0D4087@EX-0-MB2.lancs.local> References: <52940EB0.6040601@kddilabs.jp> <529C5A30.3070000@orange.com> <4A95BA014132FF49AE685FAB4B9F17F645C293E9@dfweml509-mbx.china.huawei.com> <52A1FE77.10405@orange.com> <65174429B5AF4C45BD0798810EC48E0A0D38CF@EX-0-MB2.lancs.local> <65174429B5AF4C45BD0798810EC48E0A0D3C3B@EX-0-MB2.lancs.local> <52A93E96.5090805@kddilabs.jp> In-Reply-To: <52A93E96.5090805@kddilabs.jp> 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_65174429B5AF4C45BD0798810EC48E0A0D4087EX0MB2lancslocal_" MIME-Version: 1.0 Subject: Re: [vnfpool] VNF Pool 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, 12 Dec 2013 06:54:58 -0000 --_000_65174429B5AF4C45BD0798810EC48E0A0D4087EX0MB2lancslocal_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Hidetoshi, Thanks for the clarification, we will write up the scenario in the use case= I-D and if ok, we will bounce the suggest text off you for your input. Br, Dan. From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of Hidetoshi Yoko= ta Sent: 12 December 2013 04:42 To: vnfpool@ietf.org Subject: Re: [vnfpool] VNF Pool Problem Statement Hi Dan and Ning, The following scenario is very important and should be captured in this wor= k. At least, the IP address of VNF#2 should be preserved even if the role i= s handed over to VNF#3. This is because in some applications, the state inf= ormation includes the IP address of the peer, so if the IP address changes = due to the failure recovery, the state information in VNF#1 will become inc= onsistent. Please take this scenario into consideration. Regards, -- Hidetoshi Yokota KDDI R&D Laboratories, Inc. e-mail:yokota@kddilabs.jp (2013/12/10 6:19), King, Daniel wrote: Hi Ning, Good question, I would modify slightly. If VNF#2 needs to replicate state (= FW or otherwise) to its designated backup (VNF#3), it should probably have = the IP connectivity knowledge to do this. When failure (loss of VNF#2) happ= ens, should the existing network resilience mechanisms route traffic to VNF= #3, without VNF#1 having to detect loss of VNF#2 and switching to VNF#3 ins= tead. Phew, quite a number of permutations. We will update the I-D to encompass t= hese discussions/scenarios. Br, Dan. From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of Zongning Sent: 09 December 2013 02:05 To: King, Daniel; LAC Chidung Cc: vnfpool@ietf.org; Linda Dunbar Subject: Re: [vnfpool] VNF Pool Problem Statement Hi, Daniel, I agree this is a fair question to ask, thanks! Please allow me to ask another question ("a flip side of the coin"): do we = have use case to show that the instance in VNF#1 pool needs to know the sta= ndby address of the instance in VNF#2 pool? For example, suppose we have a = vLB instance (vLB-1) talking to a vFW instance (vFW-1) with two standby ins= tances (vFW-2, vFW-3), if vLB-1 need to know the address of vFW-2, vFW-3, o= r not *in any case*? Anyway, I guess this is a good work for co-authors of use case draft. :) -Ning From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of King, Daniel Sent: Saturday, December 07, 2013 5:02 AM To: LAC Chidung Cc: vnfpool@ietf.org; Linda Dunbar Subject: Re: [vnfpool] VNF Pool Problem Statement Hi Chidung, Thanks for using definitions, and providing the example use cases. The serv= ice chaining and non-service chaining examples are good, but could you also= clarify a deployment, and therefore, solution requirements from an operato= r perspective? Is it expected that client service ("FW" in this use case) resilience would= be typically be provided by each VNF pool sharing the same VLAN, with a vi= rtual server using a "fixed IP" address that maps to a cluster of "dynamic = IP addresses" to multiple VMs, with say one VM for hosting a VNF(s)? Spanni= ng tree would run between the VM instances, and VRRP used to provide backup= for the default gateways. This deployment scenario would support the follo= wing: - Load-balancing across VNFs - Fail-over between VNFs - Migration to new VNFs This architecture would also support mixed environments, where existing pro= priety FW hardware and virtual (VM/VNFs) might be used for migration and te= sting. Actually, the same question to the other operators. It would be real= ly good to understand the thinking behind how best to achieve cost-effectiv= e (time and resources) resilience. As a co-author of "draft-xia-vsnpool-man= agement-use-case" I am trying to figure out if "existing" (VRRP, RSPT, et a= l.) mechanisms are capable of providing client service continuity and distr= ibuted resilience, or indeed we need to document a set of generic requireme= nts that our work in vnfpool will need to solve. Br, Dan. From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of LAC Chidung Sent: 06 December 2013 16:43 To: Linda Dunbar; vnfpool@ietf.org Subject: Re: [vnfpool] VNF Pool Problem Statement Hi Linda, Please correct the following if I'm wrong. Let's define: VNF =3D one type of function. Case 1: no service chaining, e.g., a firewall provides the network service Let's state that 3 firewalls are needed, i.e., 3 instances of the VNF "FW". "VNFs have higher chance to fail due to lack of built-in redundancy" combin= ed with the use of "vnfpool" means: 1) The 3 FW instances are deployed neither in active/active, nor in active/= standby mode, i.e., there are only 3 instances, and not 3 active, and 3 sta= ndby. 2) But this solution is not a trusted one because of "server failure, serve= r over-utilized, or software failure, etc.". 3) Assuming that the load of each (FW) instance is less than 60%, one can g= et HA for this system by using the 3 instances in a pool architecture (base= d on an efficient load balancing mechanism). 4) In this case, the failure of one instance is acceptable because its load= will be shared by the two remaining instances. Case 2: service chaining, e.g., VNF1 and VNF2 are needed in order to provid= e the network service (for instance, a kid requesting a Web page with the u= se of a smartphone -> "parental control" (VNF1) checks the URL, followed by= "header enrichment" (VNF2) which adds the user ID in the media flow) Lets' state that we have 3 instances of VNF1 and 3 instances of VNF2. If we= apply the same reasoning (and hypotheses) as above, we will have a 1st poo= l made up of 3 instances of VNF1, and a 2nd pool made up of 3 instances of = VNF2. The HA of this system is guaranteed if: (i) 1 instance of VNF1 fails,= (ii) 1 instance of VNF2 fails, (iii) 1 instance of VNF2 fails and 1 instan= ce of VNF2 fails. Best, Chidung Le 03/12/2013 21:06, Linda Dunbar a =E9crit : Chidung, Thanks for the quote. Based on your quote, the goal of "vnfpool" should be about to achieve "high= availability" of service function chaining while individual service functi= on instances are NOT reliable. As stated in the problem statement, the vir= tualized network functions have higher chance to fail due to lack of built-= in redundancy, server failure, server over-utilized, or software failure, e= tc. Linda From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of LAC Chidung Sent: Monday, December 02, 2013 4:00 AM To: vnfpool@ietf.org Subject: Re: [vnfpool] VNF Pool Problem Statement Hi all, Reliability is the ability of an item to perform a required function under = stated conditions for a stated period of time, while Availability is a meas= ure of the degree to which an item is in an operable state when called upon= to perform. (D.J. Klinger, Y. Nakada, and M.A. Menedez (Eds.), "AT&T Relia= bility Manual", Van Nostrand Reinhold, 1990) Applied to the PSTN, the former includes "My call is not dropped during a c= onversation", while the latter asks for "The phone service is ready, i.e., = a tone is present, whenever I lift the handset". For years, Dependability has encompassed these concepts (together with othe= rs such as Maintainability) to characterize the good behavior (robustness) = of a system when facing accidental events (design faults, operations errors= , hardware failures, natural disasters, etc.) , while Security, which inclu= des all intentional actions (attacks, ...), is kept apart. This explains th= e presence, up to now, of two communities working in these two separated su= bjects. As (i) unavailability may the consequence of, e.g., software/hardware failu= res OR (D)DoS attacks (ii) Resilience is a fashionable expression* (iii) et= c., resilience is used since the last few years to encompass both dependabi= lity and security. Best, Chidung _______ *: see, e.g., Obama's praise for the resilience of the Indian people (http:= //articles.latimes.com/2010/nov/06/world/la-fgw-obama-mumbai-20101107) Le 02/12/2013 08:21, Cao,Zhen a =E9crit : Good point, Diego. I checked out the NFV ISG released documents of requirements and terminology, where i could not find 'reliability' but 'resilience'. -cz On Wed, Nov 27, 2013 at 2:06 AM, Diego R. Lopez wrote: Hi, When it comes to the reliability/availability issue I guess providing some (condensed) definition from the NFV REL group would help... Be goode, On 26 Nov 2013, at 04:00 , Hidetoshi Yokota wrote: Hi Ning and all, The proposed PS is a very good starting point covering major issues for the goal of VNF pool. One thing that I could add is the synchronization between the vNF migration/replacement and routing to make the relevant flows forwarded to the new location. The challenge is that the VMs/severs in a pool could be deployed over topologically different networks (in the physical world) and VNF migration could involve topologically independent routing. There are multiple ways to do it, but we should first generalize this issue and specify a common mechanism that may leverage existing ones. If this is already covered, that's fine. If some additional text is useful, the following could be a summary: o Synchronization between vNF migration and flow forwarding, which may require topologically independent routing in the physical transport network= ; There is a discussion about "reliability" and "availability" in another thread and I think this is also an issue in ETSI NFV. We need to define the= m either in this group or NFV to share the same view. Regards, -- Hidetoshi Yokota KDDI R&D Laboratories, Inc. e-mail:yokota@kddilabs.jp (2013/11/21 18:11), Zongning wrote: Hi, Please review the below brief version of VNF Pool Problem Statement, and feedback with your comments. I hope this text can serve as a base of VNF Pool Charter, by carving out real problems and work items. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D A virtualized network function (VNF) (e.g. vFW, vLB) provides the same function as the equivalent network function (e.g. FW, LB), but is usually instantiated as a cluster of software instances running on general purpose servers via virtualization platform. In an environment based on VNFs, a network service is typically realized by a chain of VNFs where the instance= s of adjacent VNFs are preferably directly connected. A VNF chain introduces additional points of failure beyond those inherent i= n a single dedicated server, and therefore additional challenges on reliability. By reliability, we mean the ability of a VNF chain to continue function when having transition or failure within the chain. For example, there are more factors such as software failure, server over-utilization, instance migration that potentially cause VNF instance transition or failure. Although a general pooling mechanism can be applied to address the reliability of a single VNF, there are still problems when addressing the reliability of a VNF chain, i.e. multiple pools for multiple VNFs. For example, how does an instance of VNF#1 know which instance in the pool of VNF#2 will replace the instance of VNF#2 it connects to? How does an instance of VNF#1 know the state of instance of VNF#2 that it connects to i= n order to enforce policy for reliability like load sharing, switch before break? How is the service state of an instance held and accessed for efficient synchronization with backup instances? The overall problem space can be further breakdown to the following study items: - Signalling to handle reliability and instance transition requirements o Signalling between VNF pools for transition (e.g. state change, scaling= , moving) notification, backup announcement; o Service state management (e.g. synchronizing method, state data format, location and mechanism to access state data) within VNF pool; o Obtaining underlying network information (e.g. ALTO, I2RS); o Signalling to CMS for instance deployment reflecting reliability requirements (e.g. distribution of instances on different VMs or hypervisors); - Transport characteristics o Identify and analyze reliable transport characteristics for control plane traffic; o Analysis of transport security characteristics to provide protection against known threats, and identification of an appropriate trust model; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Thanks. -Ning -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego@tid.es Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------------- vnfpool mailing list vnfpool@ietf.org https://www.ietf.org/mailman/listinfo/vnfpool _______________________________________________ vnfpool mailing list vnfpool@ietf.org https://www.ietf.org/mailman/listinfo/vnfpool --_000_65174429B5AF4C45BD0798810EC48E0A0D4087EX0MB2lancslocal_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Hidetoshi,

 <= /p>

Br, Dan.

From= : vnfpool [mailto:v= nfpool-bounces@ietf.org] On Behalf Of Hidetoshi Yokota
Sent: 12 December 2013 04:42
To: vnfpool@ietf.org
Subject: Re: [vnfpool] VNF Pool Problem Statement<= /p>

 

Hi Dan and Ning,

The following scenario is very important and should be captured in this wor= k. At least, the IP address of VNF#2 should be preserved even if the role i= s handed over to VNF#3. This is because in some applications, the state inf= ormation includes the IP address of the peer, so if the IP address changes due to the failure recovery, the= state information in VNF#1 will become inconsistent. Please take this scen= ario into consideration.

Regards,

-- 
Hidetoshi Yokota
 
KDDI R&D Laboratories, Inc.
e-mail:yokota@kddilabs.jp=

 

(2013/12/10 6:19), King, Daniel wrote:

 <= /p>

Br, Dan.

From= : vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of Zongning
Sent: 09 December 2013 02:05
To: King, Daniel; LAC Chidung
Cc: vnfpool@ietf.org; Linda = Dunbar
Subject: Re: [vnfpool] VNF Pool Problem Statement<= /p>

 

Hi, Daniel,

 

I agree this is a fair question to ask, thanks!

Please allow me to ask another question (“a flip sid= e of the coin”): do we have use case to show that the instance in VNF#1 pool needs to know the standby address of the instance in VNF#2 pool= ? For example, suppose we have a vLB instance (vLB-1) talking to a vFW inst= ance (vFW-1) with two standby instances (vFW-2, vFW-3), if vLB-1 need to kn= ow the address of vFW-2, vFW-3, or not *in any case*?

Anyway, I guess this is a good work for co-authors of use = case draft. J

 

-Ning

 

From: vnfpool [mailto:vnfpool-bounce= s@ietf.org] On Behalf Of King, Daniel
Sent: Saturday, December 07, 2013 5:02 AM
To: LAC Chidung
Cc: vnfpool@ietf.org; Linda = Dunbar
Subject: Re: [vnfpool] VNF Pool Problem Statement<= /p>

 

From: vnfpool [mailto:vnfpool-bounce= s@ietf.org] On Behalf Of LAC Chidung
Sent: 06 December 2013 16:43
To: Linda Dunbar; vnfpool@ietf.o= rg
Subject: Re: [vnfpool] VNF Pool Problem Statement<= /p>

 

Hi Linda,
Please correct the following if I'm wrong.
Let's define: VNF =3D one type of function.
Case 1: no service chaining, e.g., a firewall provides the network s= ervice
Let's state that 3 firewalls are needed, i.e., 3 instances of the VNF "= ;FW".
"VNFs have higher chance to fail due to lack of built-in redunda= ncy" combined with the use of "vnfpool"= ; means:
1) The 3 FW instances are deployed neither in active/active, nor in active/= standby mode, i.e., there are only 3 instances, and not 3 active, and 3 sta= ndby.
2) But this solution is not a trusted one because of "server fai= lure, server over-utilized, or software failure, etc.".
3) Assuming that the load of each (FW) instance is less than 60%, one can g= et HA for this system by using the 3 instances in a pool architecture (base= d on an efficient load balancing mechanism).
4) In this case, the failure of one instance is acceptable because its load= will be shared by the two remaining instances.
Case 2: service chaining, e.g., VNF1 and VNF2 are needed in order to= provide the network service (for instance, a kid requesting a Web page wit= h the use of a smartphone -> "parental control" (VNF1) checks = the URL, followed by "header enrichment" (VNF2) which adds the user ID in the media flow)
Lets' state that we have 3 instances of VNF1 and 3 instances of VNF2. If we= apply the same reasoning (and hypotheses) as above, we will have a 1st poo= l made up of 3 instances of VNF1, and a 2nd pool made up of 3 instances of = VNF2. The HA of this system is guaranteed if: (i) 1 instance of VNF1 fails, (ii) 1 instance of VNF2 fails, (iii) 1 i= nstance of VNF2 fails and 1 instance of VNF2 fails.
Best,
Chidung

Le 03/12/2013 21:06, Linda Dunbar a =E9crit :

From: vnfpool [mailto:vnfpool-bounce= s@ietf.org] On Behalf Of LAC Chidung
Sent: Monday, December 02, 2013 4:00 AM
To: vnfpool@ietf.org
Subject: Re: [vnfpool] VNF Pool Problem Statement<= /p>

 

Hi all,
Reliability is the ability of an item to perform a required function und= er stated conditions for a stated period of time, while Availability= is a measure of the degree to which an item is in an operable state when c= alled upon to perform. (D.J. Klinger, Y. Nakada, and M.A. Menedez (Eds.), "AT&T Reliability Ma= nual", Van Nostrand Reinhold, 1990)
Applied to the PSTN, the former includes "My call is not dropped durin= g a conversation", while the latter asks for "The phone service i= s ready, i.e., a tone is present, whenever I lift the handset".
For years, Dependability has encompassed these concepts (together wi= th others such as Maintainability) to characterize the good behavior (robustness) of a= system when facing accidental events (design faults, operations errors, hardware failur= es, natural disasters, etc.) , while Security, which includes all intentional actions (attacks, ..= .), is kept apart. This explains the presence, up to now, of two communitie= s working in these two separated subjects.
As (i) unavailability may the consequence of, e.g., software/hardware failu= res OR (D)DoS attacks (ii) Resilience is a fashionable expression* (iii) etc., resilience is us= ed since the last few years to encompass both dependability and security. Best,
Chidung
_______
*: see, e.g., Obama's praise for the resilience of the Indian people (http://articles.latimes.com/2010/nov/06/world/la-fgw-obama-mumbai-20= 101107)

Le 02/12/2013 08:21, Cao,Zhen a =E9crit : 

Good point, Diego.
I checked out the NFV ISG released documents of r=
equirements and
terminology, where i could not find 'reliability'=
 but 'resilience'.
-cz
 
On Wed, Nov 27, 2013 at 2:06 AM, Diego R. Lopez <=
a href=3D"mailto:diego@tid.es"><diego@tid.es> wrote:<=
/o:p>
Hi,
When it comes to the reliability/availability iss=
ue I guess providing some
(condensed) definition from the NFV REL group wou=
ld help...
Be goode,
 
On 26 Nov 2013, at 04:00 , Hidetoshi Yokota wrote=
:
 
Hi Ning and all,
The proposed PS is a very good starting point cov=
ering major issues for the
goal of VNF pool. One thing that I could add is t=
he synchronization between
the vNF migration/replacement and routing to make=
 the relevant flows
forwarded to the new location. The challenge is t=
hat the VMs/severs in a
pool could be deployed over topologically differe=
nt networks (in the
physical world) and VNF migration could involve t=
opologically independent
routing. There are multiple ways to do it, but we=
 should first generalize
this issue and specify a common mechanism that ma=
y leverage existing ones.
If this is already covered, that's fine. If some =
additional text is useful,
the following could be a summary:
o Synchronization between vNF migration and flow =
forwarding, which may
require topologically independent routing in the =
physical transport network;
There is a discussion about "reliability&quo=
t; and "availability" in another
thread and I think this is also an issue in ETSI =
NFV. We need to define them
either in this group or NFV to share the same vie=
w.
Regards,
--
Hidetoshi Yokota
 
KDDI R&D Laboratories, Inc.=

e-ma=
il:yokota@kddilabs.jp
 
(2013/11/21 18:11), Zongning wrote:
 
Hi,
Please review the below brief version of VNF Pool=
 Problem Statement, and
feedback with your comments. I hope this text can=
 serve as a base of VNF
Pool Charter, by carving out real problems and wo=
rk items.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

A virtualized network function (VNF) (e.g. vFW, v=
LB) provides the same
function as the equivalent network function (e.g.=
 FW, LB), but is usually
instantiated as a cluster of software instances r=
unning on general purpose
servers via virtualization platform. In an enviro=
nment based on VNFs, a
network service is typically realized by a chain =
of VNFs where the instances
of adjacent VNFs are preferably directly connecte=
d.
A VNF chain introduces additional points of failu=
re beyond those inherent in
a single dedicated server, and therefore addition=
al challenges on
reliability. By reliability, we mean the ability =
of a VNF chain to continue
function when having transition or failure within=
 the chain. For example,
there are more factors such as software failure, =
server over-utilization,
instance migration that potentially cause VNF ins=
tance transition or
failure. Although a general pooling mechanism can=
 be applied to address the
reliability of a single VNF, there are still prob=
lems when addressing the
reliability of a VNF chain, i.e. multiple pools f=
or multiple VNFs. For
example, how does an instance of VNF#1 know which=
 instance in the pool of
VNF#2 will replace the instance of VNF#2 it conne=
cts to? How does an
instance of VNF#1 know the state of instance of V=
NF#2 that it connects to in
order to enforce policy for reliability like load=
 sharing, switch before
break? How is the service state of an instance he=
ld and accessed for
efficient synchronization with backup instances?<=
/span>
The overall problem space can be further breakdow=
n to the following study
items:
-        =
  Signalling to handle reliability and instance transition=

requirements
o   Signalling between VNF pools for tr=
ansition (e.g. state change, scaling,
moving) notification, backup announcement;=

o   Service state management (e.g. sync=
hronizing method, state data format,
location and mechanism to access state data) with=
in VNF pool;
o   Obtaining underlying network inform=
ation (e.g. ALTO, I2RS);
o   Signalling to CMS for instance depl=
oyment reflecting reliability
requirements (e.g. distribution of instances on d=
ifferent VMs or
hypervisors);
-        =
  Transport characteristics
o   Identify and analyze reliable trans=
port characteristics for control
plane traffic;
o   Analysis of transport security char=
acteristics to provide protection
against known threats, and identification of an a=
ppropriate trust model;
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

Thanks.
-Ning
 
--
"Esta vez no fallaremos, Doctor Infierno&quo=
t;
 
Dr Diego R. Lopez
Telefonica I+D
htt=
p://people.tid.es/diego.lopez/
 
e-mail: diego@tid=
.es
Tel:    +34 913 129 041=

Mobile: +34 682 051 091

-----------------------------------------<=
o:p>


 


vnfpool mailing list


vnfpool@ietf.=
org


https://www.ietf.org/mailman/listinfo/vnfpool






_______________________________________________
vnfpool mailing list
vnfpool@ietf.org

https://www.=
ietf.org/mailman/listinfo/vnfpool

 

--_000_65174429B5AF4C45BD0798810EC48E0A0D4087EX0MB2lancslocal_-- From zongning@huawei.com Thu Dec 12 00:27:52 2013 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 56E6C1AE062 for ; Thu, 12 Dec 2013 00:27:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 mSBRUMiazNon for ; Thu, 12 Dec 2013 00:27:47 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 123141ADF51 for ; Thu, 12 Dec 2013 00:27:45 -0800 (PST) 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 AYX27702; Thu, 12 Dec 2013 08:27:39 +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, 12 Dec 2013 08:27:08 +0000 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 12 Dec 2013 08:27:20 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Thu, 12 Dec 2013 16:27:17 +0800 From: Zongning To: Hidetoshi Yokota , "vnfpool@ietf.org" Thread-Topic: [vnfpool] Problem Statement V2 Thread-Index: Ac72NV32hcZ3zANsT5ufj0o84neRqQAenPYAABNyUiA= Date: Thu, 12 Dec 2013 08:27:14 +0000 Message-ID: References: <52A93BE0.8090206@kddilabs.jp> In-Reply-To: <52A93BE0.8090206@kddilabs.jp> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.28] Content-Type: multipart/alternative; boundary="_000_B0D29E0424F2DE47A0B36779EC6667792585A054nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [vnfpool] Problem Statement V2 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, 12 Dec 2013 08:27:52 -0000 --_000_B0D29E0424F2DE47A0B36779EC6667792585A054nkgeml501mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Hidetoshi, Thanks for your comments and questions. See inline. o I think it is good to emphasize reliability to clarify the scope of this = work. RSerpool deals with pooling configuration, SFC deals with chaining co= nfiguration and VNFpool could leverage their work to enhance reliability. [Ning] Good point. I should mention this in the text. o Are we focusing more on VNF chain rather than VNF itself with regard to r= eliability? Maybe, we could include both and it is part of the study to ide= ntify the additional requirements for VNF chain. [Ning] If you mean VNF pool when saying "VNF itself", then, yes, we include= both. o Based on the architecture figure you provided, we should also study the s= ignaling between Pool manager and VNFs. I would propose the following text "Signaling between VNF pools for transition..." -> "Signaling "within and" between VNF pools for transition..." [Ning] Agree. o State synchronization is important, but when VNF migration or replacement= occurs, flow route synchronization is also important. This feature should = also be captured. [Ning] You are right this feature is related. Now I prefer focusing scope o= n signaling in pool architecture, but we could look into additional layers = as you suggested as next step of work. How do other folks think? -Ning From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of Hidetoshi Yoko= ta Sent: Thursday, December 12, 2013 12:30 PM To: vnfpool@ietf.org Subject: Re: [vnfpool] Problem Statement V2 Hi Ning, Thanks for your update, which is starting to look like the charter. I have a couple of questions and comments: o I think it is good to emphasize reliability to clarify the scope of this = work. RSerpool deals with pooling configuration, SFC deals with chaining co= nfiguration and VNFpool could leverage their work to enhance reliability. o Are we focusing more on VNF chain rather than VNF itself with regard to r= eliability? Maybe, we could include both and it is part of the study to ide= ntify the additional requirements for VNF chain. o Based on the architecture figure you provided, we should also study the s= ignaling between Pool manager and VNFs. I would propose the following text "Signaling between VNF pools for transition..." -> "Signaling "within and" between VNF pools for transition..." o State synchronization is important, but when VNF migration or replacement= occurs, flow route synchronization is also important. This feature should = also be captured. Regards, -- Hidetoshi Yokota KDDI R&D Laboratories, Inc. e-mail:yokota@kddilabs.jp (2013/12/11 14:53), Zongning wrote: Hi, folks, Thank you all for valuable comments & suggestions on problem statement duri= ng the past a few weeks. Please see below updated text, which I hope captur= es what we have discussed and agreed so far. Here is the highlight of the m= ain changes: 1) Add more text to clarify the scope of "reliability" we want to add= ress; 2) Add more descriptive text about VNF, as well as how it would impac= t reliability; 3) Modify some work item bullets; 4) Clarify relation with service function chaining (SFC) group; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D A virtualized network function (VNF) provides network function (e.g., firew= alling, load balancing), but is typically implemented as software instances= running on general server via virtualization layer (e.g. hypervisor). This= is distinct from monolithic network devices, where a number of different f= unctions are provided in the same device. Based on concept of service funct= ion chaining (SFC), a network service can be implemented by a set of sequen= tially connected VNF instances deployed at different points in the network = (or a VNF chain). A VNF chain introduces additional points of failure beyond those inherent i= n a single dedicated server, and therefore additional challenges on reliabi= lity. For a single VNF instance, it typically would not have built-in relia= bility mechanisms on its host (i.e. general server). Instead, there are mor= e factors such as software failure, server overload, and instance migration= that lead to VNF instance transition or failure. Currently generalized poo= ling and other redundancy mechanisms may be applied to address some reliabi= lity requirements of a single VNF. However, the need to support a growing n= umber of VNFs including stateful function, and extend the redundancy across= a VNF chain (i.e. multiple pools for multiple VNFs) requires further solut= ion development. For example, when a "live" VNF pool member goes out of ser= vice, how do adjacent entities learn which pool member will replace it? How= do VNFs learn the state of adjacent VNFs to support reliability mechanisms= like load sharing and switch before break? How is the service state of an = instance held and accessed for efficient synchronization with backup instan= ces and other members of its pool? Ideally, the reliability of VNF chain would mean that a VNF chain continues= to function throughout an interruption and outages will not be visible to = users of the chain. In the current charter, we scope our work around severa= l mechanisms supporting the reliability of VNF chain, which are redundancy = along multiple VNF pools, and stateful failover among pool members. Additio= nal mechanisms for reliable VNF chain might be included after further gap a= nalysis between our requirements and IETF technologies. The overall problem space can be further broken to include the following it= ems: . Signaling between VNF pools for transition (e.g. state change, scaling, m= oving) notification, backup announcement; . Identification and evaluation of state sharing mechanisms, including (but= not limited to) distributed shared memory, gossip protocols, pfsync, and s= tate check pointing; . Exchange of reliability related information between VNF pools and underly= ing network (e.g. interfacing with ALTO, I2RS); . Identify and analyze reliable transport characteristics for control plane= traffic; . Analysis of transport security characteristics to provide protection agai= nst known threats, and identification of an appropriate trust model; The initial work will include a problem statement, VNF pooling architecture= , use cases and requirements analysis, and an evaluation of existing techno= logies against the architecture and requirements. It is our expectation tha= t we will be able to rely heavily on existing IETF technologies but that ga= ps will be found around problems like state transfer and trust/security, wh= ich will need to be addressed. Particularly, we will work closely with SFC = group to develop mechanisms complementary to service function chaining appr= oaches, based on identified reliability requirements. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Please let me know if the update doesn't address your previous concerns. Fu= rther comments are also highly appreciated. Thanks. -Ning _______________________________________________ vnfpool mailing list vnfpool@ietf.org https://www.ietf.org/mailman/listinfo/vnfpool --_000_B0D29E0424F2DE47A0B36779EC6667792585A054nkgeml501mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, Hid= etoshi,

&n= bsp;

Thanks = for your comments and questions. See inline.

&n= bsp;

o I think it is good to emphasize relia= bility to clarify the scope of this work. RSerpool deals with pooling confi= guration, SFC deals with chaining configuration and VNFpool could leverage their work to enhance reliability.=

 

[Ning] = Good point. I should mention this in the text.
 
o Are we focusing more on VNF chain rather than VNF itself with regard to r= eliability? Maybe, we could include both and it is part of the study to ide= ntify the additional requirements for VNF chain.

 

[Ning] = If you mean VNF pool when saying “VNF itself”, then, yes, we in= clude both.

o Based on the architecture figure you provided, we should also study the s= ignaling between Pool manager and VNFs. I would propose the following text

"Signaling between VNF pools for transition..."
->
"Signaling "within and" between VNF pools for transition...&= quot;

 

[Ning] = Agree.

o State synchronization is important, but when VNF migration or replacement= occurs, flow route synchronization is also important. This feature should = also be captured.

 

[Ning] = You are right this feature is related. Now I prefer focusing scope on signa= ling in pool architecture, but we could look into additional layers as you = suggested as next step of work. How do other folks think?

&n= bsp;

-Ning

&n= bsp;

From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of Hidetoshi Yo= kota
Sent: Thursday, December 12, 2013 12:30 PM
To: vnfpool@ietf.org
Subject: Re: [vnfpool] Problem Statement V2

 

Hi Ning,

Thanks for your update, which is starting to look like the charter.

I have a couple of questions and comments:

o I think it is good to emphasize reliability to clarify the scope of this = work. RSerpool deals with pooling configuration, SFC deals with chaining co= nfiguration and VNFpool could leverage their work to enhance reliability.  
o Are we focusing more on VNF chain rather than VNF itself with regard to r= eliability? Maybe, we could include both and it is part of the study to ide= ntify the additional requirements for VNF chain.

o Based on the architecture figure you provided, we should also study the s= ignaling between Pool manager and VNFs. I would propose the following text

"Signaling between VNF pools for transition..."
->
"Signaling "within and" between VNF pools for transition...&= quot;

o State synchronization is important, but when VNF migration or replacement= occurs, flow route synchronization is also important. This feature should = also be captured.

Regards,

-- 
Hidetoshi Yokota
 
KDDI R&D Laboratories, Inc.=

e-ma=
il:yokota@kddilabs.jp

 

(2013/12/11 14:53), Zongning wr= ote:

Hi, folks,

 

Thank you all for valuable comm= ents & suggestions on problem statement during the past a few weeks. Pl= ease see below updated text, which I hope captures what we have discussed a= nd agreed so far. Here is the highlight of the main changes:

1= )   &= nbsp;   Add more text to clarif= y the scope of “reliability” we want to address;

2= )   &= nbsp;   Add more descriptive te= xt about VNF, as well as how it would impact reliability;=

3= )   &= nbsp;   Modify some work item b= ullets;

4= )   &= nbsp;   Clarify relation with s= ervice function chaining (SFC) group;

 

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

A virtualized network function = (VNF) provides network function (e.g., firewalling, load balancing), but is= typically implemented as software instances running on general server via = virtualization layer (e.g. hypervisor). This is distinct from monolithic network devices, where a number of differ= ent functions are provided in the same device. Based on concept of service = function chaining (SFC), a network service can be implemented by a set of s= equentially connected VNF instances deployed at different points in the network (or a VNF chain).

A VNF chain introduces addition= al points of failure beyond those inherent in a single dedicated server, and therefore additional challenges on rel= iability. For a single VNF instance, it typically would not have bui= lt-in reliability mechanisms on its host (i.e. general server). Instead, th= ere are more factors such as software failure, server o= verload, and instance migration that lead to VNF instance transition or fai= lure. Currently generalized pooling and other redundancy mechanisms = may be applied to address some reliability requirements of a single VNF. However, the need to support a growing numbe= r of VNFs including stateful function, and extend the redundancy across a V= NF chain (i.e. multiple pools for multiple= VNFs) requires further solution development. For example, when a "live" VNF pool member goes out= of service, how do adjacent entities learn which pool member will replace = it? How do VNFs learn the state of adjacent VNFs to support reliability mec= hanisms like load sharing and switch before break? How is the service state of an instance held and accessed for effic= ient synchronization with backup instances and other members of its pool?

Ideally, the reliability of VNF= chain would mean that a VNF chain continues to function throughout an inte= rruption and outages will not be visible to users of the chain. In the curr= ent charter, we scope our work around several mechanisms supporting the reliability of VNF chain, which are redu= ndancy along multiple VNF pools, and stateful failover among pool members. = Additional mechanisms for reliable VNF chain might be included after furthe= r gap analysis between our requirements and IETF technologies.

 

The overall problem space can b= e further broken to include the following items:

. Signaling between VNF pools f= or transition (e.g. state change, scaling, moving) notification, backup ann= ouncement;

. Identification and evaluation= of state sharing mechanisms, including (but not limited to) distributed sh= ared memory, gossip protocols, pfsync, and state check pointing;=

. Exchange of reliability relat= ed information between VNF pools and underlying network (e.g. interfacing w= ith ALTO, I2RS);

. Identify and analyze reliable= transport characteristics for control plane traffic;

. Analysis of transport securit= y characteristics to provide protection against known threats, and identifi= cation of an appropriate trust model;

 

The initial work will include a= problem statement, VNF pooling architecture, use cases and requirements an= alysis, and an evaluation of existing technologies against the architecture= and requirements. It is our expectation that we will be able to rely heavily on existing IETF technologies but tha= t gaps will be found around problems like state transfer and trust/security= , which will need to be addressed. Particularly, we will work closely with = SFC group to develop mechanisms complementary to service function chaining approaches, based on identified= reliability requirements.

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

 

Please let me know if the updat= e doesn’t address your previous concerns. Further comments are also h= ighly appreciated.

 

Thanks.

 

-Ning




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

 

--_000_B0D29E0424F2DE47A0B36779EC6667792585A054nkgeml501mbschi_-- From chidung.lac@orange.com Thu Dec 12 07:16:25 2013 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 043DC1AE221 for ; Thu, 12 Dec 2013 07:16:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.884 X-Spam-Level: X-Spam-Status: No, score=-0.884 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665] 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 9LjzHfljr5ze for ; Thu, 12 Dec 2013 07:16:20 -0800 (PST) Received: from r-mail2.rd.orange.com (r-mail2.rd.orange.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 8AFE81ADBD0 for ; Thu, 12 Dec 2013 07:16:18 -0800 (PST) Received: from r-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E5EF25D891E; Thu, 12 Dec 2013 16:16:11 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.orange.com (Postfix) with ESMTP id CF9265D891B; Thu, 12 Dec 2013 16:16:11 +0100 (CET) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 Dec 2013 16:16:09 +0100 Received: from [10.193.5.32] ([10.193.5.32]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 Dec 2013 16:16:11 +0100 Message-ID: <52A9D33A.3020305@orange.com> Date: Thu, 12 Dec 2013 16:16:10 +0100 From: LAC Chidung User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Zongning , "vnfpool@ietf.org" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------020601010603060308060408" X-OriginalArrivalTime: 12 Dec 2013 15:16:11.0303 (UTC) FILETIME=[1722EB70:01CEF74D] Subject: Re: [vnfpool] Problem Statement V2 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, 12 Dec 2013 15:16:25 -0000 This is a multi-part message in MIME format. --------------020601010603060308060408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi Ning, 1- To create a virtual layer starting from h/w, is there anything else than hypervisor ? "(e.g. hypervisor)" -> "(i.e. hypervisor)" 2- Up to now, it is possible to find a single network function included in a single h/w: "are provided in the same device" -> "may be provided in the same device" 3-If "instance" means "Virtual Machine", it may be premature to talk of "instances" at this point: "a network service can be implemented by a set of sequentially connected VNF instances" ->"a network service can be implemented by a set of sequentially connected VNFs" 4- "For a single VNF instance, it typically would not have built-in reliability mechanisms on its host ": it would be nice to introduce/define "instance" before using this word*. 5- "there are more factors" -> "there are more factors of risk" 6- "the need to support a growing number of VNFs including stateful function": IMHO, this sentence does not fully reflect the two following ideas: (i) a complex situation because we (may) deal with a lot of VNFs in a VNF chain; (ii) simultaneously, these VNFs (in the VNF chain) may not be identical (some are stateless, some are stateful, etc.) Just my two cents. Best, Chidung __________ *: if we'd like to refer to current ETSI NFV work/jargon, please have in mind that VM = instance of a VNFC (and not instance of a VNF - see my post sent on Dec 11th) - if not, then forget about this remark. Le 11/12/2013 06:53, Zongning a écrit : > > Hi, folks, > > Thank you all for valuable comments & suggestions on problem statement > during the past a few weeks. Please see below updated text, which I > hope captures what we have discussed and agreed so far. Here is the > highlight of the main changes: > > 1)Add more text to clarify the scope of "reliability" we want to address; > > 2)Add more descriptive text about VNF, as well as how it would impact > reliability; > > 3)Modify some work item bullets; > > 4)Clarify relation with service function chaining (SFC) group; > > =========================================================== > > A virtualized network function (VNF) provides network function (e.g., > firewalling, load balancing), but is typically implemented as software > instances running on general server via virtualization layer (e.g. > hypervisor). This is distinct from monolithic network devices, where a > number of different functions are provided in the same device. Based > on concept of service function chaining (SFC), a network service can > be implemented by a set of sequentially connected VNF instances > deployed at different points in the network (or a VNF chain). > > A VNF chain introduces additional points of failure beyond those > inherent in a single dedicated server, and therefore additional > challenges on reliability. For a single VNF instance, it typically > would not have built-in reliability mechanisms on its host (i.e. > general server). Instead, there are more factors such as software > failure, server overload, and instance migration that lead to VNF > instance transition or failure. Currently generalized pooling and > other redundancy mechanisms may be applied to address some reliability > requirements of a single VNF. However, the need to support a growing > number of VNFs including stateful function, and extend the redundancy > across a VNF chain (i.e. multiple pools for multiple VNFs) requires > further solution development. For example, when a "live" VNF pool > member goes out of service, how do adjacent entities learn which pool > member will replace it? How do VNFs learn the state of adjacent VNFs > to support reliability mechanisms like load sharing and switch before > break? How is the service state of an instance held and accessed for > efficient synchronization with backup instances and other members of > its pool? > > Ideally, the reliability of VNF chain would mean that a VNF chain > continues to function throughout an interruption and outages will not > be visible to users of the chain. In the current charter, we scope our > work around several mechanisms supporting the reliability of VNF > chain, which are redundancy along multiple VNF pools, and stateful > failover among pool members. Additional mechanisms for reliable VNF > chain might be included after further gap analysis between our > requirements and IETF technologies. > > The overall problem space can be further broken to include the > following items: > > . Signaling between VNF pools for transition (e.g. state change, > scaling, moving) notification, backup announcement; > > . Identification and evaluation of state sharing mechanisms, including > (but not limited to) distributed shared memory, gossip protocols, > pfsync, and state check pointing; > > . Exchange of reliability related information between VNF pools and > underlying network (e.g. interfacing with ALTO, I2RS); > > . Identify and analyze reliable transport characteristics for control > plane traffic; > > . Analysis of transport security characteristics to provide protection > against known threats, and identification of an appropriate trust model; > > The initial work will include a problem statement, VNF pooling > architecture, use cases and requirements analysis, and an evaluation > of existing technologies against the architecture and requirements. It > is our expectation that we will be able to rely heavily on existing > IETF technologies but that gaps will be found around problems like > state transfer and trust/security, which will need to be addressed. > Particularly, we will work closely with SFC group to develop > mechanisms complementary to service function chaining approaches, > based on identified reliability requirements. > > ============================================================ > > Please let me know if the update doesn't address your previous > concerns. Further comments are also highly appreciated. > > Thanks. > > -Ning > > > > _______________________________________________ > vnfpool mailing list > vnfpool@ietf.org > https://www.ietf.org/mailman/listinfo/vnfpool --------------020601010603060308060408 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Hi Ning,

1- To create a virtual layer starting from h/w, is there anything else than hypervisor ? "(e.g. hypervisor)" -> "(i.e. hypervisor)"

2- Up to now, it is possible to find a single network function included in a single h/w: "are provided in the same device" -> "may be provided in the same device"

3-  If "instance" means "Virtual Machine", it may be premature to talk of "instances" at this point:

"a network service can be implemented by a set of sequentially connected VNF instances" ->  "a network service can be implemented by a set of sequentially connected VNFs"

4- "For a single VNF instance, it typically would not have built-in reliability mechanisms on its host ": it would be nice to introduce/define "instance" before using this word*.

5- "there are more factors" -> "there are more factors of risk"

6- "the need to support a growing number of VNFs including stateful function": IMHO, this sentence does not fully reflect the two following ideas: (i) a complex situation because we (may) deal with a lot of VNFs in a VNF chain; (ii) simultaneously, these VNFs (in the VNF chain) may not be identical (some are stateless, some are stateful, etc.)

Just my two cents.

Best,

Chidung

__________

*: if we'd like to refer to current ETSI NFV work/jargon, please have in mind that VM = instance of a VNFC (and not instance of a VNF - see my post sent on Dec 11th) - if not, then forget about this remark.


Le 11/12/2013 06:53, Zongning a écrit :

Hi, folks,

 

Thank you all for valuable comments & suggestions on problem statement during the past a few weeks. Please see below updated text, which I hope captures what we have discussed and agreed so far. Here is the highlight of the main changes:

1)       Add more text to clarify the scope of “reliability” we want to address;

2)       Add more descriptive text about VNF, as well as how it would impact reliability;

3)       Modify some work item bullets;

4)       Clarify relation with service function chaining (SFC) group;

 

===========================================================

A virtualized network function (VNF) provides network function (e.g., firewalling, load balancing), but is typically implemented as software instances running on general server via virtualization layer (e.g. hypervisor). This is distinct from monolithic network devices, where a number of different functions are provided in the same device. Based on concept of service function chaining (SFC), a network service can be implemented by a set of sequentially connected VNF instances deployed at different points in the network (or a VNF chain).

A VNF chain introduces additional points of failure beyond those inherent in a single dedicated server, and therefore additional challenges on reliability. For a single VNF instance, it typically would not have built-in reliability mechanisms on its host (i.e. general server). Instead, there are more factors such as software failure, server overload, and instance migration that lead to VNF instance transition or failure. Currently generalized pooling and other redundancy mechanisms may be applied to address some reliability requirements of a single VNF. However, the need to support a growing number of VNFs including stateful function, and extend the redundancy across a VNF chain (i.e. multiple pools for multiple VNFs) requires further solution development. For example, when a "live" VNF pool member goes out of service, how do adjacent entities learn which pool member will replace it? How do VNFs learn the state of adjacent VNFs to support reliability mechanisms like load sharing and switch before break? How is the service state of an instance held and accessed for efficient synchronization with backup instances and other members of its pool?

Ideally, the reliability of VNF chain would mean that a VNF chain continues to function throughout an interruption and outages will not be visible to users of the chain. In the current charter, we scope our work around several mechanisms supporting the reliability of VNF chain, which are redundancy along multiple VNF pools, and stateful failover among pool members. Additional mechanisms for reliable VNF chain might be included after further gap analysis between our requirements and IETF technologies.

 

The overall problem space can be further broken to include the following items:

. Signaling between VNF pools for transition (e.g. state change, scaling, moving) notification, backup announcement;

. Identification and evaluation of state sharing mechanisms, including (but not limited to) distributed shared memory, gossip protocols, pfsync, and state check pointing;

. Exchange of reliability related information between VNF pools and underlying network (e.g. interfacing with ALTO, I2RS);

. Identify and analyze reliable transport characteristics for control plane traffic;

. Analysis of transport security characteristics to provide protection against known threats, and identification of an appropriate trust model;

 

The initial work will include a problem statement, VNF pooling architecture, use cases and requirements analysis, and an evaluation of existing technologies against the architecture and requirements. It is our expectation that we will be able to rely heavily on existing IETF technologies but that gaps will be found around problems like state transfer and trust/security, which will need to be addressed. Particularly, we will work closely with SFC group to develop mechanisms complementary to service function chaining approaches, based on identified reliability requirements.

============================================================

 

Please let me know if the update doesn’t address your previous concerns. Further comments are also highly appreciated.

 

Thanks.

 

-Ning



_______________________________________________
vnfpool mailing list
vnfpool@ietf.org
https://www.ietf.org/mailman/listinfo/vnfpool
--------------020601010603060308060408-- From linda.dunbar@huawei.com Thu Dec 12 15:19:13 2013 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 C7A631AE203 for ; Thu, 12 Dec 2013 15:19:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 wRSgcuH-kGvt for ; Thu, 12 Dec 2013 15:19:11 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 372411AE1EB for ; Thu, 12 Dec 2013 15:19:10 -0800 (PST) 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 AYX92154; Thu, 12 Dec 2013 23:19:03 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 12 Dec 2013 23:18:49 +0000 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 12 Dec 2013 23:19:02 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.24]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.03.0158.001; Thu, 12 Dec 2013 15:18:52 -0800 From: Linda Dunbar To: LAC Chidung , Zongning , "vnfpool@ietf.org" Thread-Topic: [vnfpool] Problem Statement V2 Thread-Index: Ac72NV32hcZ3zANsT5ufj0o84neRqQBWsaIAAAAk0MA= Date: Thu, 12 Dec 2013 23:18:51 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645C3037A@dfweml509-mbx.china.huawei.com> References: <52A9D33A.3020305@orange.com> In-Reply-To: <52A9D33A.3020305@orange.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.197] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645C3037Adfweml509mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [vnfpool] Problem Statement V2 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, 12 Dec 2013 23:19:14 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645C3037Adfweml509mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Chidung, Jumped in to give my interpretation: 3- If "instance" means "Virtual Machine", it may be premature to talk of "= instances" at this point: "a network service can be implemented by a set of sequentially connected VN= F instances" -> "a network service can be implemented by a set of sequenti= ally connected VNFs" [Linda] "instance" should be the service function instances. For example, t= here are 10 Firewall instances. Each instance, most likely software based, = can be instantiated on any general purpose server platforms. For a data flo= w that needs FW, one of those instances will be used. IMHO, the servers to which those Service Function Instances are instantiate= d can be "virtualized" or "not virtualized". Linda --_000_4A95BA014132FF49AE685FAB4B9F17F645C3037Adfweml509mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Chidung,

 

Jumped in to give my interpretation:

 

3-  If "instance&qu= ot; means "Virtual Machine", it may be premature to talk of "= ;instances" at this point:

"a network service can b= e implemented by a set of sequentially connected VNF instances" ->&= nbsp; "a network service can be implemented by a set of sequentially c= onnected VNFs"

 

[Linda] “instance” should be the service function instan= ces. For example, there are 10 Firewall instances. Each instance, most likely software based, can be instantiated on any general purpose server p= latforms. For a data flow that needs FW, one of those instances will be use= d.

 

IMHO, the servers to which those Service Function Instances are inst= antiated can be “virtualized” or “not virtualized”.

 

 

Linda

 

--_000_4A95BA014132FF49AE685FAB4B9F17F645C3037Adfweml509mbxchi_-- From zongning@huawei.com Thu Dec 12 19:46:19 2013 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 D41D91AE0EE for ; Thu, 12 Dec 2013 19:46:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 4Fb396qfZ6yx for ; Thu, 12 Dec 2013 19:46:14 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A902D1AE0D2 for ; Thu, 12 Dec 2013 19:46:13 -0800 (PST) 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 BBI12140; Fri, 13 Dec 2013 03:46:06 +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.158.1; Fri, 13 Dec 2013 03:45:50 +0000 Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 13 Dec 2013 03:46:04 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Fri, 13 Dec 2013 11:45:57 +0800 From: Zongning To: LAC Chidung , "vnfpool@ietf.org" Thread-Topic: [vnfpool] Problem Statement V2 Thread-Index: Ac72NV32hcZ3zANsT5ufj0o84neRqQA1KpAAAClAw/A= Date: Fri, 13 Dec 2013 03:45:56 +0000 Message-ID: References: <52A9D33A.3020305@orange.com> In-Reply-To: <52A9D33A.3020305@orange.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.28] Content-Type: multipart/alternative; boundary="_000_B0D29E0424F2DE47A0B36779EC6667792585A439nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [vnfpool] Problem Statement V2 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, 13 Dec 2013 03:46:20 -0000 --_000_B0D29E0424F2DE47A0B36779EC6667792585A439nkgeml501mbschi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Lac, Thanks for the comments. Please see inline. From: LAC Chidung [mailto:chidung.lac@orange.com] Sent: Thursday, December 12, 2013 11:16 PM To: Zongning; vnfpool@ietf.org Subject: Re: [vnfpool] Problem Statement V2 Hi Ning, 1- To create a virtual layer starting from h/w, is there anything else= than hypervisor ? "(e.g. hypervisor)" -> "(i.e. hypervisor)" 2- Up to now, it is possible to find a single network function include= d in a single h/w: "are provided in the same device" -> "may be provided in= the same device" [Ning]: Agree. 3- If "instance" means "Virtual Machine", it may be premature to talk of "= instances" at this point: "a network service can be implemented by a set of sequentially connected VN= F instances" -> "a network service can be implemented by a set of sequenti= ally connected VNFs" [Ning]: According to ETSI NFV MANO, VNF instance means a run-time instantia= tion of the VNF software like load balancing, packet filtering. I assume th= at when we say "a network service can be implemented...", we are talking ab= out run-time instantiation of VNFs. :) Furthermore, based on ETSI NFV SWA a= nd INF, a VNF can be decomposed by multiple VNF Components, with each compo= nent instantiated in one virtual container which is typically a VM. To simp= lify our context for the time being, let's assume VNF has single component = which is instantiated in one VM. 3- "For a single VNF instance, it typically would not have built-in re= liability mechanisms on its host ": it would be nice to introduce/define "i= nstance" before using this word*. [Ning]: See above. I will add the definition into the text later. 5- "there are more factors" -> "there are more factors of risk" [Ning]: Agree. 6- "the need to support a growing number of VNFs including stateful functio= n": IMHO, this sentence does not fully reflect the two following ideas: (i)= a complex situation because we (may) deal with a lot of VNFs in a VNF chai= n; (ii) simultaneously, these VNFs (in the VNF chain) may not be identical = (some are stateless, some are stateful, etc.) [Ning]: Good point, I will update this sentence later. Just my two cents. Best, Chidung __________ *: if we'd like to refer to current ETSI NFV work/jargon, please have in mi= nd that VM =3D instance of a VNFC (and not instance of a VNF - see my post = sent on Dec 11th) - if not, then forget about this remark. Le 11/12/2013 06:53, Zongning a =E9crit : Hi, folks, Thank you all for valuable comments & suggestions on problem statement duri= ng the past a few weeks. Please see below updated text, which I hope captur= es what we have discussed and agreed so far. Here is the highlight of the m= ain changes: 1) Add more text to clarify the scope of "reliability" we want to add= ress; 2) Add more descriptive text about VNF, as well as how it would impac= t reliability; 3) Modify some work item bullets; 4) Clarify relation with service function chaining (SFC) group; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D A virtualized network function (VNF) provides network function (e.g., firew= alling, load balancing), but is typically implemented as software instances= running on general server via virtualization layer (e.g. hypervisor). This= is distinct from monolithic network devices, where a number of different f= unctions are provided in the same device. Based on concept of service funct= ion chaining (SFC), a network service can be implemented by a set of sequen= tially connected VNF instances deployed at different points in the network = (or a VNF chain). A VNF chain introduces additional points of failure beyond those inherent i= n a single dedicated server, and therefore additional challenges on reliabi= lity. For a single VNF instance, it typically would not have built-in relia= bility mechanisms on its host (i.e. general server). Instead, there are mor= e factors such as software failure, server overload, and instance migration= that lead to VNF instance transition or failure. Currently generalized poo= ling and other redundancy mechanisms may be applied to address some reliabi= lity requirements of a single VNF. However, the need to support a growing n= umber of VNFs including stateful function, and extend the redundancy across= a VNF chain (i.e. multiple pools for multiple VNFs) requires further solut= ion development. For example, when a "live" VNF pool member goes out of ser= vice, how do adjacent entities learn which pool member will replace it? How= do VNFs learn the state of adjacent VNFs to support reliability mechanisms= like load sharing and switch before break? How is the service state of an = instance held and accessed for efficient synchronization with backup instan= ces and other members of its pool? Ideally, the reliability of VNF chain would mean that a VNF chain continues= to function throughout an interruption and outages will not be visible to = users of the chain. In the current charter, we scope our work around severa= l mechanisms supporting the reliability of VNF chain, which are redundancy = along multiple VNF pools, and stateful failover among pool members. Additio= nal mechanisms for reliable VNF chain might be included after further gap a= nalysis between our requirements and IETF technologies. The overall problem space can be further broken to include the following it= ems: . Signaling between VNF pools for transition (e.g. state change, scaling, m= oving) notification, backup announcement; . Identification and evaluation of state sharing mechanisms, including (but= not limited to) distributed shared memory, gossip protocols, pfsync, and s= tate check pointing; . Exchange of reliability related information between VNF pools and underly= ing network (e.g. interfacing with ALTO, I2RS); . Identify and analyze reliable transport characteristics for control plane= traffic; . Analysis of transport security characteristics to provide protection agai= nst known threats, and identification of an appropriate trust model; The initial work will include a problem statement, VNF pooling architecture= , use cases and requirements analysis, and an evaluation of existing techno= logies against the architecture and requirements. It is our expectation tha= t we will be able to rely heavily on existing IETF technologies but that ga= ps will be found around problems like state transfer and trust/security, wh= ich will need to be addressed. Particularly, we will work closely with SFC = group to develop mechanisms complementary to service function chaining appr= oaches, based on identified reliability requirements. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Please let me know if the update doesn't address your previous concerns. Fu= rther comments are also highly appreciated. Thanks. -Ning _______________________________________________ vnfpool mailing list vnfpool@ietf.org https://www.ietf.org/mailman/listinfo/vnfpool --_000_B0D29E0424F2DE47A0B36779EC6667792585A439nkgeml501mbschi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi, Lac,

 

Thanks for the comments. Please see inline.

 

From: LAC Chidung [mailto:chidung.lac@orange.com]
Sent: Thursday, December 12, 2013 11:16 PM
To: Zongning; vnfpool@ietf.org
Subject: Re: [vnfpool] Problem Statement V2

 

Hi Ning,

1-      To create a virtual layer starting fro= m h/w, is there anything else than hypervisor ? "(e.g. hypervisor)&quo= t; -> "(i.e. hypervisor)"

2-      Up to now, it is possible to find a si= ngle network function included in a single h/w: "are provided in the s= ame device" -> "may be provided in the same device"

 

[Ning]: Agree.

 

3-  If "instance" means "Virtual Machine= ", it may be premature to talk of "instances" at this point:=

"a network service can be implemented by a set of seque= ntially connected VNF instances" ->  "a network service c= an be implemented by a set of sequentially connected VNFs"

 

[Ning]: According to ETSI NFV MANO, VNF i= nstance means a run-time instantiation of the VNF software like load balancing, packet filtering. I assume that when we say “a netwo= rk service can be implemented…”, we are talking about run-time = instantiation of VNFs. J= Furthermore, based on ETSI NFV SWA and INF= , a VNF can be decomposed by multiple VNF Components, with each component instantiated in one virtual container which is typically a VM. T= o simplify our context for the time being, let’s assume VNF has singl= e component which is instantiated in one VM.

 

3-      "For a single VNF instance, it ty= pically would not have built-in reliability mechanisms on its host ": = it would be nice to introduce/define "instance" before using this word*.

 

[Ning]: See above. I will add the definit= ion into the text later.

 

5- "there are more factors" -> "there are = more factors of risk"

 

[Ning]: Agree.

 

6- "the need to support a growing number of VNFs includ= ing stateful function": IMHO, this sentence does not fully reflect the two following ideas: (i) a complex situation because we (may) deal wit= h a lot of VNFs in a VNF chain; (ii) simultaneously, these VNFs (in the VNF= chain) may not be identical (some are stateless, some are stateful, etc.)<= /span>

 

[Ning]: Good point, I will update this se= ntence later.

 

Just my two cents.

Best,

Chidung

__________

*: if we'd like to refer to current ETSI NFV work/jargon, pl= ease have in mind that VM =3D instance of a VNFC (and not instance of a VNF - see my post sent on Dec 11th) - if not, then forget about this = remark.


Le 11/12/2013 06:53, Zongning a =E9crit :

Hi, folks,

 

Thank you all for valuable comm= ents & suggestions on problem statement during the past a few weeks. Pl= ease see below updated text, which I hope captures what we have discussed a= nd agreed so far. Here is the highlight of the main changes:

1= )   &= nbsp;   Add more text to clarif= y the scope of “reliability” we want to address;

2= )   &= nbsp;   Add more descriptive te= xt about VNF, as well as how it would impact reliability;=

3= )   &= nbsp;   Modify some work item b= ullets;

4= )   &= nbsp;   Clarify relation with s= ervice function chaining (SFC) group;

 

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

A virtualized network function = (VNF) provides network function (e.g., firewalling, load balancing), but is= typically implemented as software instances running on general server via = virtualization layer (e.g. hypervisor). This is distinct from monolithic network devices, where a number of differ= ent functions are provided in the same device. Based on concept of service = function chaining (SFC), a network service can be implemented by a set of s= equentially connected VNF instances deployed at different points in the network (or a VNF chain).

A VNF chain introduces addition= al points of failure beyond those inherent in a single dedicated server, and therefore additional challenges on rel= iability. For a single VNF instance, it typically would not have bui= lt-in reliability mechanisms on its host (i.e. general server). Instead, th= ere are more factors such as software failure, server o= verload, and instance migration that lead to VNF instance transition or fai= lure. Currently generalized pooling and other redundancy mechanisms = may be applied to address some reliability requirements of a single VNF. However, the need to support a growing numbe= r of VNFs including stateful function, and extend the redundancy across a V= NF chain (i.e. multiple pools for multiple= VNFs) requires further solution development. For example, when a "live" VNF pool member goes out= of service, how do adjacent entities learn which pool member will replace = it? How do VNFs learn the state of adjacent VNFs to support reliability mec= hanisms like load sharing and switch before break? How is the service state of an instance held and accessed for effic= ient synchronization with backup instances and other members of its pool?

Ideally, the reliability of VNF= chain would mean that a VNF chain continues to function throughout an inte= rruption and outages will not be visible to users of the chain. In the curr= ent charter, we scope our work around several mechanisms supporting the reliability of VNF chain, which are redu= ndancy along multiple VNF pools, and stateful failover among pool members. = Additional mechanisms for reliable VNF chain might be included after furthe= r gap analysis between our requirements and IETF technologies.

 

The overall problem space can b= e further broken to include the following items:

. Signaling between VNF pools f= or transition (e.g. state change, scaling, moving) notification, backup ann= ouncement;

. Identification and evaluation= of state sharing mechanisms, including (but not limited to) distributed sh= ared memory, gossip protocols, pfsync, and state check pointing;=

. Exchange of reliability relat= ed information between VNF pools and underlying network (e.g. interfacing w= ith ALTO, I2RS);

. Identify and analyze reliable= transport characteristics for control plane traffic;

. Analysis of transport securit= y characteristics to provide protection against known threats, and identifi= cation of an appropriate trust model;

 

The initial work will include a= problem statement, VNF pooling architecture, use cases and requirements an= alysis, and an evaluation of existing technologies against the architecture= and requirements. It is our expectation that we will be able to rely heavily on existing IETF technologies but tha= t gaps will be found around problems like state transfer and trust/security= , which will need to be addressed. Particularly, we will work closely with = SFC group to develop mechanisms complementary to service function chaining approaches, based on identified= reliability requirements.

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

 

Please let me know if the updat= e doesn’t address your previous concerns. Further comments are also h= ighly appreciated.

 

Thanks.

 

-Ning




_______________________________________________
vnfpool mailing list
vnfpool@ietf.=
org
https://www.ietf.org/mailman/listinfo/vnfpool
--_000_B0D29E0424F2DE47A0B36779EC6667792585A439nkgeml501mbschi_-- From shares@ndzh.com Sun Dec 15 17:52:51 2013 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 2FA0D1AE27A for ; Sun, 15 Dec 2013 17:52:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.646 X-Spam-Level: *** X-Spam-Status: No, score=3.646 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] 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 HkTqLqaZKbGp for ; Sun, 15 Dec 2013 17:52:46 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id A55291AE273 for ; Sun, 15 Dec 2013 17:52:45 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Y. Richard Yang'" , "'Melinda Shore'" References: <003601ceb0d9$717507d0$545f1770$@ndzh.com> <523920AC.8010308@gmail.com> In-Reply-To: Date: Sun, 15 Dec 2013 20:52:38 -0500 Message-ID: <001201cefa01$808cb760$81a62620$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01CEF9D7.97BDDB50" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQD+8qkmOCbXlbcgUPQva3ZxQq9gBAK1v74DAVXjuw4Bb89esgHxZto5AgDNuk6bqoES8A== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: vnfpool@ietf.org Subject: Re: [vnfpool] Great effort 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, 16 Dec 2013 01:52:51 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0013_01CEF9D7.97BDDB50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Richard and Melinda: In an effort to review carefully Ning, Linda, and Melinda's draft - I wanted to re-engage with a few points on your earlier posts. The VNF pools have scope beyond just the network service provider generic usage. The VNF pools can be used in the vertical markets in medical, financial, and mobile-stores. I apologize that I am coming in late to the discussion. Rather than create a new post for all my questions, I've found some original posts, and I am commenting on these posts. I'd like to pick up the discussion of Richard's questions on the post below: . is there any reference (sub-ms, 10s ms) on the requirement of latency for the back-up devices (e.g. firewall) to take over? Short answer: Yes, the medical, financial, and mobile-store applications can require a latency for back-up devices that is sub-ms, 10s ms. It depends on the device and applications. I will start with medical examples below. Financial and mobile-store applications later (if I am on track). . What is the persistency requirement regarding NF state recover: no loss because master state is not recoverable or the state is reconstructable and fast recover is just an optimization? Short answer: No loss is important in medical crisis/critical/urgent data so that it is auditable what data got delivered when. (Medical care is audited in the US due to insurance). In other portions of the applications fast-recover that reconstructs is possible. This need sets the adaptability requirements for the VNF Pools. Please see gets into Section 3.5 section of Dreibholz, Tuxen, Shore, Zong document on RSerPool for Virtual Network Function Resource Pooling (draft-dreibholz-vnf-pool-rserpool-applic-00.txt) especially in the pool member selection in adaptive strategies or over-provisioning with non-adaptive strategies. ADARA's product does have sub-second adaptive strategies that condition the VRF pools deployed in medical, financial (E.g. stock trades/Quick loans approvals), and mobile-store scenarios. Context for my comments: Let me give an example of a few markets in which the whole process has time-critical nature: medical, financial, and mobile store. Let me start with medical. I will add additional posts on financial and mobile. Medical devices exist with hospitals at all levels. If you visit a top-ranked US hospital you will find that he Doctors and nurses are carrying mobile devices that allow them to access patient results, patent records, and surgical information. Doctors may communicate within a single hospital or a multi-building complex or within the hospitals within a metro Area. For example the University of Michigan (U of M) Hospital is a single hospital with over 30 buildings. It exists in Ann Arbor with 3 other research hospitals that are the same size, and within the Detroit Metro-Area with 20+ other large hospitals. Doctors within Ann Arbor may be consulting on patience within Ann Arbor or the Detroit Area. Patients come from the regional area which includes the Canadian city of Windsor plus around the US for the advance treatment. The medical traffic has several priorities: . Crisis alerts for Doctors, . Critical information needed to alert doctors on patient care, . Urgent important information on consultations needed for urgent patient care, . Medical records of a recent test that Doctors have flagged for updates, . Doctor's notes on patient visits; . Nurses chart information on patient vital signs or . Medical financial records on charges due to the patient, . Medical insurance records (payments and coverage), and . Social services on patient care needed. In this environment, by US law medical information must be kept secure, confidential and private. It must not travel to certain geographical boundaries (E.g. not outside United States). The medical traffic ranges from short texts to massive files for medical images. VNF pools need to handle the firewall, load-balance, WAN acceleration, traffic monitoring, and SPAN/TAP at some level. However, the key important that seems to be lost is the understanding that these functions need to be application aware. For example, the most important thing for the Doctor's Crisis alerts is that the application that informs the doctors and/or nurses on-call has the necessary things to get the information to the doctor, and provide receive/response times for the medical audit. This crisis alert may be used in the surgical post-operation system or in the emergency ward. The Wireless/Wired system can have requirements for 10ms set-up of VNF. Fast Adaptability is key. After the alert for the medical information, the system may spin up VMs with VRF functions to provide the critical information and then provide quick reference to massive amounts of data is also necessary. It may be that the most important thing to transfer to the Doctor iPad is the key medical test information along with patient data. Data may come from multiple hospitals in multiple networks to a Virtual applications on some server. You can see that the Firewall, LB, WAN Acceleration, and Traffic Monitoring, SPAN/TAP are just a few things that the networking system must track. Impact on the Reliable VNF Problem statement: - VNF on page 5 states: failures of hardware, status change (over-utilization, network congestion), software failure (VM, VNF I nstance), performance downgrade (contention between VNF instances), and instance migration due to software instance. All of these are great, and should be handled at every layer of the stack (physical, link, network, transport, and application). The question is how do you have vertical applications which know certain things about the stack influences changes. How do we do this and keep secure? Please let me know if there are reasonable questions or if I have missed something in the discussion. Sue Hares From: vnfpool-bounces@ietf.org [mailto:vnfpool-bounces@ietf.org] On Behalf Of Y. Richard Yang Sent: Wednesday, September 18, 2013 12:14 AM To: Melinda Shore Cc: vnfpool@ietf.org Subject: Re: [vnfpool] Great effort Hi Melinda, On Tuesday, September 17, 2013, Melinda Shore wrote: On 9/17/13 7:32 PM, Y. Richard Yang wrote: > 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. Hi, Richard: I am not previously familiar with Zookeeper so I may be misunderstanding something fundamental, but it seems to me from what I've read that Zookeeper may not be suitable for HA applications, in that it may not meet performance requirements. In this case "distributed synchronization" means something more closely aligned with, say, rsync than with keeping stateful network devices in sync. If you think about, say, a firewall in a service provider network, do you think that Zookeeper is suitable for moving firewall-associated state from one device to another within extremely constrained elapsed time requirements? Good question. Is there any reference (sub-ms, 10s ms, ...) on the requirement of latency for a backup device (e.g., firewal) to take over? What is the persistency requirement regarding NF state recovery: no loss because master state is not recoverable or the state is reconstructable and fast recovery is just an optimization? Richard To me it looks more like a network configuration platform. Melinda _______________________________________________ vnfpool mailing list vnfpool@ietf.org https://www.ietf.org/mailman/listinfo/vnfpool ------=_NextPart_000_0013_01CEF9D7.97BDDB50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Richard = and Melinda:

=

In an = effort to review carefully Ning, Linda, and Melinda’s draft = – I wanted to re-engage with a few points on your earlier posts. =   The VNF pools have scope beyond just the network service = provider generic usage.  The VNF pools can be used in the vertical = markets in medical, financial, and mobile-stores. =  

 =

I = apologize that I am coming in late to the discussion. Rather than create = a new post for all my questions, I’ve found some original posts, = and I am commenting on these posts.  

 =

I’d = like to pick up the discussion of Richard’s questions on the post = below:

·         = is there = any reference (sub-ms, 10s ms) on the requirement of latency for the = back-up devices (e.g. firewall) to take over?

 =

Short = answer: Yes, the medical, financial, and mobile-store applications can = require a latency for back-up devices that is sub-ms, 10s ms.  It = depends on the device and applications.  I will start with medical = examples below.  Financial and mobile-store applications later (if = I am on track).

 =

·         = What is = the persistency requirement regarding NF state recover: no loss because = master state is not recoverable or the state is reconstructable and fast = recover is just an optimization?

 =

Short = answer:  No loss is important in medical crisis/critical/urgent = data so that it is auditable what data got delivered when.  = (Medical care is audited in the US due to insurance).  In other = portions of the applications fast-recover that reconstructs is = possible. 

 =

This need = sets the adaptability requirements for the VNF Pools. =

 =

Please see =  gets into Section 3.5 section of Dreibholz, Tuxen, Shore, Zong = document on RSerPool for Virtual Network Function Resource Pooling = (draft-dreibholz-vnf-pool-rserpool-applic-00.txt) especially in the pool = member selection in adaptive strategies or over-provisioning with = non-adaptive strategies.   ADARA’s product does have = sub-second adaptive strategies that condition the VRF pools deployed in = medical, financial (E.g. stock trades/Quick loans approvals),  and = mobile-store scenarios.

 =

Context = for my comments:

 =

Let me = give an example of a few markets in which the whole process has = time-critical nature: medical, financial, and mobile store.  Let me = start with medical.  I will add additional posts on financial and = mobile.

 =

Medical = devices exist with hospitals at all levels.  If you visit a = top-ranked US hospital you will find that he Doctors and nurses are = carrying mobile devices that allow them to access patient results, = patent records, and surgical information.  Doctors may communicate = within a single hospital or a multi-building complex or within the = hospitals within a metro Area. For example the University of Michigan (U = of M) Hospital is a single hospital with over 30 buildings.  It = exists in Ann Arbor with 3 other research hospitals that are the same = size, and within the Detroit Metro-Area with 20+ other large hospitals. =  Doctors within Ann Arbor may be consulting on patience within Ann = Arbor or the Detroit Area.  Patients come from the regional area = which includes the Canadian city of Windsor plus around the US for the = advance treatment.

 =

The = medical traffic has several priorities:

·         = Crisis = alerts for Doctors,

·         = Critical = information needed to alert doctors on patient = care,

·         = Urgent = important information on consultations needed for urgent patient care, =

·         = Medical = records of a recent test that Doctors have flagged for updates, =

·         = Doctor̵= 7;s notes on patient visits;

·         = Nurses = chart information on patient vital signs or

·         = Medical = financial records on charges due to the patient,

·         = Medical = insurance records (payments and coverage), and

·         = Social = services on patient care needed.

 =

In this = environment, by US law medical information must be kept secure, = confidential and private.  It must not travel to certain = geographical boundaries (E.g. not outside United States).  The = medical traffic ranges from short texts to massive files for medical = images.  

 =

VNF pools = need to handle the firewall, load-balance, WAN acceleration, traffic = monitoring, and SPAN/TAP at some level.   However, the key = important that seems to be lost is the understanding that these = functions need to be application aware. 

 =

For = example, the most important thing for the Doctor’s Crisis alerts = is that the application that informs the doctors and/or nurses on-call = has the necessary things to get the information to the doctor, and = provide receive/response times for the medical audit. This crisis alert = may be used in the surgical post-operation system or in the emergency = ward.  The Wireless/Wired system can have requirements for 10ms = set-up of VNF.  Fast Adaptability is key.

 =

After the = alert for the medical information, the system may spin up VMs with VRF = functions to provide the critical information and then provide quick = reference to massive amounts of data is also necessary.  It may be = that the most important thing to transfer to the Doctor iPad is the key = medical test information along with patient data.  Data may come = from multiple hospitals in multiple networks to a Virtual applications = on some server.

 =

You can = see that the Firewall, LB, WAN Acceleration, and Traffic Monitoring, = SPAN/TAP are just a few things that the networking system must track. =

 =

Impact on = the Reliable VNF Problem statement:

-          = VNF on = page 5 states: failures of hardware, status change (over-utilization, = network congestion), software failure (VM, VNF I nstance), performance = downgrade (contention between VNF instances), and instance migration due = to software instance.

 =

All of = these are great, and should be handled at every layer of the stack = (physical, link, network, transport, and application). =

 =

The = question is how do you have vertical applications which know certain = things about the stack influences changes.  How do we do this and = keep secure?

 =

Please let = me know if there are reasonable questions or if I have missed something = in the discussion.

 =

Sue Hares =

 

 

 

 

From:= = vnfpool-bounces@ietf.org [mailto:vnfpool-bounces@ietf.org] On Behalf = Of Y. Richard Yang
Sent: Wednesday, September 18, 2013 = 12:14 AM
To: Melinda Shore
Cc: = vnfpool@ietf.org
Subject: Re: [vnfpool] Great = effort

 

Hi Melinda,

On Tuesday, September 17, 2013, = Melinda Shore wrote:

On 9/17/13 7:32 = PM, Y. Richard Yang wrote:
> 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.

Hi, Richard:

I am not previously familiar with = Zookeeper so I may be
misunderstanding something fundamental, but it = seems to
me from what I've read that Zookeeper may not be
suitable = for HA applications, in that it may not meet
performance = requirements. In this case "distributed
synchronization" = means something more closely aligned
with, say, rsync than with = keeping stateful network
devices in sync.  If you think about, = say, a firewall
in a service provider network, do you think = that
Zookeeper is suitable for moving firewall-associated
state = from one device to another within extremely
constrained elapsed time = requirements?  

 

Good question.

 

Is there any reference (sub-ms, 10s ms, ...) on = the requirement of latency 

for a backup device (e.g., firewal) to take over? = What is the persistency requirement

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

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

 

Richard

 

To me it = looks
more like a network configuration = platform.

Melinda
_____________________________________________= __
vnfpool mailing list
vnfpool@ietf.org
https://www.ietf.org/mailman/listinfo/vnfpool<= /o:p>

------=_NextPart_000_0013_01CEF9D7.97BDDB50-- From shares@ndzh.com Mon Dec 16 08:19:04 2013 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 91A0D1AE35A for ; Mon, 16 Dec 2013 08:19:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] 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 gsFNJAQik8VL for ; Mon, 16 Dec 2013 08:19:02 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 8DFA31ADF83 for ; Mon, 16 Dec 2013 08:19:02 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Melinda Shore'" , References: <201309172005.r8HK5XK5014894@cichlid.raleigh.ibm.com> <5238B9AE.5080103@nomountain.net> In-Reply-To: <5238B9AE.5080103@nomountain.net> Date: Mon, 16 Dec 2013 11:18:57 -0500 Message-ID: <009201cefa7a$8650f610$92f2e230$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHEKiK/3PyZ2GmpSPuyZgwQjLgljgJN8CVkmlolvyA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Subject: Re: [vnfpool] RSerPool protocol experience 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, 16 Dec 2013 16:19:04 -0000 Melinda: I'm trying to provide input for problem statement 2. This post is to dig into the issues you mentioned on the RSerPool protocol experience. Focus in the draft-zong-vnfpool-problem-statement-01: section 3.3 service state synchronization plus impact on 3.1, 3.4, & 3.5 (see below for the comments). ------------- Can you provide details on the comment: "The principal authors had a hammer (SCTP) and wanted to pound things. They failed to adequately address core problems around state sharing, synchronization, etc. - distributed computing problems" What exactly did the principal authors "hammer" with STCP? And how to impact it: Why am I curious: I convinced that the distribute of state has time-dependencies (critical/urgent, quick, configuration state). Different algorithm have different strengths. State sharing for sub-second of massive amounts of network-dependent data has a study of routing for 30+ years. A few algorithms there are extremely useful to do state sharing. One lesson for the SDN TE/Link state is that the work horses of the Internet routing (ISIS/OSPF, BGP, VRRP) or name distribution (DNS, DHCP) do a good job for the distribution with/or without policy. Combining the routing state distribution with augmented TCP handling makes sense for rapid congestion avoidance. The state distribution (L1-L7) tells me where the bottle necks are. Link states algorithms and coding have improved to be able to handle L1-L7 state distribution rapidly. Explicit congestion notification can be passed sub-second in order to tune the TCP bandwidth and avoid the TCP saw-tooth. If you distribute the levels of the network congestion, you can avoid sending the whole system into the repeat performance of TCP. So.. can we go a level deeper on this discussion ? Sue Hares ===== Focus in draft-zong-vnfpool-problem-statement-01: 3.3) Service state synchronization: a) Who is responsible and how to collect/keep service state of instance? b) How to synchronize service state with back-up instsance. Questions implied but not in document: 1) Does the work need a cluster concept within a pool manager? To clarify this new question: Do the verticals of mobile istores, medical devices, and financial devices require a the concepts of a cluster to make vertical NFV connections easy to make? [There may be machine-2-machine devices that require the same things, but since m2m is consider a bit off I have quoted the current applications.] 2) How does the VNF clusters interact with instance selection/status (3.1), backup selection/status (3.2), transition handling (3.4), and policy enforcement (3.5). -----Original Message----- From: vnfpool-bounces@ietf.org [mailto:vnfpool-bounces@ietf.org] On Behalf Of Melinda Shore Sent: Tuesday, September 17, 2013 4:21 PM To: vnfpool@ietf.org Subject: Re: [vnfpool] RSerPool protocol experience On 9/17/13 12:05 PM, Thomas Narten wrote: > I believe they were published as experimental protocols. Have they > been implemented in any products? Do we have any deployment experience > with them? I co-authored a few of those documents and I know of no deployments. I was concerned when I first saw rserpool in the vnfpool documents, but here's my take on it: 1) rserpool was not a good answer to the problem that it purported to address. The principal authors had a hammer (SCTP) and wanted to pound things. They failed to adequately address core problems around state sharing, synchronization, etc. - distributed computing problems 2) It's fine for providing a pooling mechanism, but an actual application built around it will require significant effort 3) the VNF reliability problem is probably a pretty good use of rserpool, as long as the work is properly scoped and the charter is very, very clear about what would need to be done. This is not really a distributed computing problem. To summarize, I think that the core problems with rserpool have to do with its nearly complete inadequacy as a telephony gateway and/or switch pooling solution. That doesn't mean that it's inapplicable to other problems. -- Melinda Shore No Mountain Software melinda.shore@nomountain.net "Software longa, hardware brevis." _______________________________________________ vnfpool mailing list vnfpool@ietf.org https://www.ietf.org/mailman/listinfo/vnfpool From melinda.shore@nomountain.net Mon Dec 16 08:35:44 2013 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 6A8771AE037 for ; Mon, 16 Dec 2013 08:35:44 -0800 (PST) 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_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] 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 qeFzKJ0E4AWp for ; Mon, 16 Dec 2013 08:35:43 -0800 (PST) Received: from homiemail-a63.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 39DB51ADF50 for ; Mon, 16 Dec 2013 08:35:43 -0800 (PST) Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id 6BEAC2F4057 for ; Mon, 16 Dec 2013 08:35:42 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=nomountain.net; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=nomountain.net ; b=nkxPKh7L3wbB+wc1k91m32MDWVGsGWamPTCV7szg12C+suw5FARkRojBDOuw 25h45mCTjaEH2bGT3QB5m2Mof9FOib7j+vyd5VSdrTAQqv/J2FfEFs/LFazMhz7c L/iQQET6QT7tJsnGdL4i6hbBStqkM7VUCmVfse+Q5PCtS0g= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=nomountain.net; h= message-id:date:from:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; s= nomountain.net; bh=yIMeGWaMwonlop9feX14EDyKQ7A=; b=av8CsZEXWuK9i bhm8Pa1f2OUKVXpD9Lg0qmAx+leT5bLLQorhMoLi7NdrlBPuA0/qOkO+zEbe2gN7 b60RRH24w2BFkfOTPrRK4axmgeQDveDQq1X8q+YbGZ7l3WUPMIt9SPbcGTB8yWpl /MOfYc/gJfcvqflMYT/w/bCVVReNgw= Received: from spandex.local (216-67-50-190-rb3.nwc.dsl.dynamic.acsalaska.net [216.67.50.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: melinda.shore@nomountain.net) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTPSA id 1FB942F4076 for ; Mon, 16 Dec 2013 08:35:41 -0800 (PST) Message-ID: <52AF2BDC.1020706@nomountain.net> Date: Mon, 16 Dec 2013 07:35:40 -0900 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: <201309172005.r8HK5XK5014894@cichlid.raleigh.ibm.com> <5238B9AE.5080103@nomountain.net> <009201cefa7a$8650f610$92f2e230$@ndzh.com> In-Reply-To: <009201cefa7a$8650f610$92f2e230$@ndzh.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [vnfpool] RSerPool protocol experience 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, 16 Dec 2013 16:35:44 -0000 On 12/16/13 7:18 AM, Susan Hares wrote: > What exactly did the principal authors "hammer" with STCP? Sure: what SCTP provided, relevant to this question, was multihomed endpoints. There were other attractive transport features, of course, but it was if they said "What can we do with multihoming?" rather than asking "How can we do server pooling/provide reliability/whatever?" I tend to think that the further you move up the stack the harder it is to do the kind of state distribution you're asking for and keep it in the sub-second range. For example, firewalling and load balancing tend to have or need awareness of session or application protocol state. I really don't think this devolves to a routing problem. Melinda -- Melinda Shore No Mountain Software melinda.shore@nomountain.net "Software longa, hardware brevis." From shares@ndzh.com Mon Dec 16 09:35:37 2013 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 26A4C1ADFE6 for ; Mon, 16 Dec 2013 09:35:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] 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 1V9al2zce-TA for ; Mon, 16 Dec 2013 09:35:34 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id B03F81ADF83 for ; Mon, 16 Dec 2013 09:35:33 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Thomas Dreibholz'" , "'Zongning'" References: <8273359.HSCiJkfoIv@nordmarka.simula.nornet> In-Reply-To: <8273359.HSCiJkfoIv@nordmarka.simula.nornet> Date: Mon, 16 Dec 2013 12:35:24 -0500 Message-ID: <00b801cefa85$34349a20$9c9dce60$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B9_01CEFA5B.4B696790" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFWRHILUlQfvTyJWuH8cZSnyaN6AQKE/HUUmzRJ+WA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com 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.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, 16 Dec 2013 17:35:37 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00B9_01CEFA5B.4B696790 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thomas and Ning:=20 =20 This another post in my chain of post to ask questions from past email. = =20 Questions: =20 Is the charter written to allow state synchronization via a process that does "state synchronization for VNF" to be done in another network = service (E.g. ISIS/OSPF/BGP/VRRP), and the VNF Pool manager interacts with that demon to get state synchronization? =20 =20 I=92ve included below the charter text that this question impacts.=20 =20 It is unclear if the VNF Pool architecture in problem statement (draft-zong-vnfpool-problem-statement-01) address this point.=20 =20 Reason:=20 The state synchronization on the VNF Pool, PE, PU requests, and PM load = is critical to allow virtualization . This state synchronization is part of = the L1-L7 state synchronization I mentioned in my previous post. The state synchronization allows you to know fate sharing, and individual layers. (See Fate sharing info below).=20 =20 How: The concepts of L1-L7 state sharing of critical information being = done a separate demon (link-state/BGP/hybrid) is possible. It can be a = single demon running 1 or many protocols.=20 =20 Problem space text impacted=20 ------------------------------------------------ a) Signaling between VNF pools for transition (e.g. state change, scaling, moving) notification, backup announcement; =20 b) Identification and evaluation of state sharing mechanisms, including (but not limited to) distributed shared memory, gossip = protocols, pfsync, and state check pointing; =20 c) Exchange of reliability related information between VNF pools = and underlying network (e.g. interfacing with ALTO, I2RS); =20 d) Identify and analyze reliable transport characteristics for = control plane traffic; =20 e) Analysis of transport security characteristics to provide protection against known threats, and identification of an appropriate = trust model; =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Examples of L1-L4, L7 critical information that impacts VNF Pools=20 =20 1) Physical connectivity has change=20 a) optical fiber cuts may cause fate sharing with a lot = of work; b) WiFi /LTE activity is key to the critical SMS/Message/VOIP=20 (E.g. Hospitals Monitoring failures within the hospital = of WiFi failures. It is important to know where status messages can go.) = =20 2) L2 connectivity=20 a) Data centers need to have TE in TE in order to move critical traffic around b) LTE/Wifi connectivity in the home to Financial Brokers/Medical/Insurance =20 A SOHO router for key small cell devices needs to prioritize the critical traffic vs. normal traffic.=20 =20 3) Network connectivity and status=20 a) Tier 1 to Tier 3 providers may have failures or re-routing b) Brokers pay top dollar to have ultra-fast service=20 the Firewall/LB or Security status is monitored tightly = and corrected quickly=20 =20 4) Transport service - and WAN optimization=20 a) Balanced and fully utilized TCP provides 90-95% utilization of WAN (by avoiding TCP Sawtooth) b) TCP pipes over mobile link also provides WAN = optimization Status on these links in critical fashion allows the TCP = to be balanced.=20 =20 5) application location services=20 a) load on application services for critical = applications (web or processing) b) Pool availability=20 =20 Final comment on State: If you think this is too much, please note that = the ADARA code base has this in deployed product for edge routers, servers, = and mobile devices.=20 =20 -----Original Message----- From: vnfpool-bounces@ietf.org [mailto:vnfpool-bounces@ietf.org] On = Behalf Of Thomas Dreibholz Sent: Monday, September 30, 2013 4:01 AM To: Zongning Cc: vnfpool@ietf.org; Michael Tuexen; Melinda Shore Subject: Re: [vnfpool] pool manager for state sync? =20 Hi, =20 Torsdag 26. september 2013 07.09.20 skrev Zongning: > Hi, all, >=20 > In current RSerPool mechanism, the service states (for stateful=20 > service like > FW) are synchronized between active and backup servers via the relay=20 > 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=20 > downstream pool 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=20 > would be a problem. I'd think a feasible approach would be to use pool = > manager for service states synchronization, e.g. retrieving, storing,=20 > distributing service states amongst VNF instances? Comments are highly appreciated! =20 This sounds useful. =20 Originally, RSerPool did not intend to define any state synchronisation. = But ASAP has the ASAP Cookie/ASAP Cookie Echo mechanism built in, because it = is very simple and therefore easy to implement and may be useful for a = number of applications. It is, however, somewhat limited: the cookie size is < = 64 KiB, the state should not change too often to avoid network overhead, = and security has to be ensured so that a malicious PU does not use the same cookie for resumption on multiple PEs. =20 Since VNF is a specific application, it makes sense to define a specific state synchronisation approach. May be, "state synchronisation for VNF" could be another service on top of RSerPool? That is, RSerPool would not = be modified to add state synchronisation but a service that realises it = could be realised based on RSerPool? This would separate the = application-specific task from the pool management task. Of course, pool management (i.e. the = PR) and state synchronisation management could be deployed on the same = machines. =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 ------=_NextPart_000_00B9_01CEFA5B.4B696790 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Thomas = and Ning:

 

This another post in my chain of post to ask = questions from past email.=A0

 

Questions: =A0

Is the charter written to allow state = synchronization via a process that does "state synchronization for = VNF" to be done in another network service (E.g. = ISIS/OSPF/BGP/VRRP), and the VNF Pool manager interacts with that demon = to get state synchronization?=A0

 

I’ve included below the charter text that = this question impacts.

 

It is = unclear if the VNF Pool architecture in problem statement = (draft-zong-vnfpool-problem-statement-01) address this point. =

 

Reason:

The = state synchronization on the VNF Pool, PE, PU requests, and PM load is = critical to allow virtualization . This state synchronization is part of = the L1-L7 state synchronization I mentioned in my previous post.=A0 The = state synchronization allows you to know fate sharing, and individual = layers.=A0 (See Fate sharing info below).

 

How: = The concepts of L1-L7 state sharing of critical information being done a = separate demon (link-state/BGP/hybrid) is possible. =A0It can be a = single demon running 1 or many protocols.

 

Problem space text impacted

------------------------------------------------

a)      = Signaling between VNF pools for transition (e.g. = state change, scaling, moving) notification, backup = announcement;

 

b)      = =A0Identification and evaluation of state = sharing mechanisms, including (but not limited to) distributed shared = memory, gossip protocols, pfsync, and state check = pointing;

 

c)       = =A0Exchange of reliability related information = between VNF pools and underlying network (e.g. interfacing with ALTO, = I2RS);

 

d)      = =A0Identify and analyze reliable transport = characteristics for control plane traffic;

 

e)      = =A0Analysis of transport security = characteristics to provide protection against known threats, and = identification of an appropriate trust model;

 

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

Examples of L1-L4, L7 critical = information that impacts VNF Pools

=A0

1) = Physical connectivity has change

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 a) = optical fiber cuts may cause fate sharing with a lot of = work;

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 b) = WiFi /LTE activity is key to the critical SMS/Message/VOIP =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (E.g. = Hospitals Monitoring failures within the hospital of WiFi = failures.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0 = It is important to know where status messages can go.)

 

2) L2 = connectivity

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 a) = Data centers need to have TE in TE in order to move critical traffic = around

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 b) = LTE/Wifi connectivity in the home to Financial = Brokers/Medical/Insurance

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 A = SOHO router for key =A0small cell devices needs to prioritize the = critical traffic vs. normal traffic.

 

3) = Network connectivity and status

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 a) = Tier 1 to Tier 3 providers may have failures or = re-routing

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 b) = Brokers pay top dollar to have ultra-fast service

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = =A0the Firewall/LB or Security status is monitored tightly and corrected = quickly

 

4) Transport service - and WAN optimization =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 a) = Balanced and fully utilized TCP provides 90-95% utilization of WAN (by = avoiding TCP Sawtooth)

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 b) = TCP pipes over mobile link also provides WAN = optimization

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = Status on these links in critical fashion allows the TCP to be balanced. =

 

5) application location services

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 a) = load on application services for critical applications (web or = processing)

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 b) = Pool availability

 

Final = comment on State: =A0If you think this is too much, please note that the = ADARA code base has this in deployed product for edge routers, servers, = and mobile devices.

 

-----Original Message-----
From: = vnfpool-bounces@ietf.org [mailto:vnfpool-bounces@ietf.org] On Behalf Of = Thomas Dreibholz
Sent: Monday, September 30, 2013 4:01 AM
To: = Zongning
Cc: vnfpool@ietf.org; Michael Tuexen; Melinda = Shore
Subject: Re: [vnfpool] pool manager for state sync?

 

Hi,

 

Torsdag 26. september 2013 07.09.20 skrev = Zongning:

> 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 fine = assuming that pool user is stable.

> Consider the VNF pools model where a pool user = (i.e. user of

> downstream = pool 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 feasible = approach would be to use pool

> manager for service states synchronization, = e.g. retrieving, storing,

> = distributing service states amongst VNF instances? Comments are highly = appreciated!

 

This = sounds useful.

 

Originally, RSerPool did not intend to define any = state synchronisation. But ASAP has the ASAP Cookie/ASAP Cookie Echo = mechanism built in, because it is very simple and therefore easy to = implement and may be useful for a number of applications. It is, = however, somewhat limited: the cookie size is < 64 KiB, the state = should not change too often to avoid network overhead, and security has = to be ensured so that a malicious PU does not use the same cookie for = resumption on multiple PEs.

 

Since = VNF is a specific application, it makes sense to define a specific state = synchronisation approach. May be, "state synchronisation for = VNF" could be another service on top of RSerPool? That is, RSerPool = would not be modified to add state synchronisation but a service that = realises it could be realised based on RSerPool? This would separate the = application-specific task from the pool management task. Of course, pool = management (i.e. the PR) and state synchronisation management could be = deployed on the same machines.

 

--

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=A0 = Visiting address: Martin Linges vei 17, 1364 Fornebu, Norway=A0 Mailing = address:=A0 P.O.Box 134, 1325 Lysaker, Norway

----------------------------------------------------= -------------------

= E-Mail:=A0=A0=A0=A0 dreibh@simula.no

Homepage:=A0=A0 http://simula.no/people/d= reibh

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

------=_NextPart_000_00B9_01CEFA5B.4B696790-- From shares@ndzh.com Mon Dec 16 10:06:32 2013 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 0001E1ADFD9 for ; Mon, 16 Dec 2013 10:06:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] 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 j1kN9oiGCUWF for ; Mon, 16 Dec 2013 10:06:30 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9D81ADF50 for ; Mon, 16 Dec 2013 10:06:30 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Melinda Shore'" , References: <201309172005.r8HK5XK5014894@cichlid.raleigh.ibm.com> <5238B9AE.5080103@nomountain.net> <009201cefa7a$8650f610$92f2e230$@ndzh.com> <52AF2BDC.1020706@nomountain.net> In-Reply-To: <52AF2BDC.1020706@nomountain.net> Date: Mon, 16 Dec 2013 13:06:26 -0500 Message-ID: <00cb01cefa89$89f6cec0$9de46c40$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHEKiK/3PyZ2GmpSPuyZgwQjLgljgJN8CVkAcwVycEBqMEG5po+lUWQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Subject: Re: [vnfpool] RSerPool protocol experience 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, 16 Dec 2013 18:06:32 -0000 Melinda: Thank you for the fast response. The multi-homing endpoints is a critical new feature for many types of applications that we struggle with in IPv6 and many cases -- so I can image why SCTP authors asked the question. Can we dig down on what you thought was valuable on the multi-homed endpoints for the RSerPool work? My question are: ------------------------ 1) Since the beginning of web service on financial institutions the HA demands required multiple interfaces on web-server, and fail-over between web servers. If we redefine the web server as a cluster of web-applications, does the multiple-end points work? 2) If we have the mega-web server broken down into secure functions (e.g. financial transactions that a broker needs a secure network) versus queries that are open (e.g. Details on what broker services), does the connection coming in need to be split or multi-homed? 3) Can you give an example of what you meant by multi-homed endpoints? Example Scenario for discussion ----------------------------------------------- Let's focus on the broker scenario to chat about this. For example, the financial transactions may require the broker to be run through firewall, AAA server, load-balancing (to give every broker the same service response time), and then into a cluster of NFV VMs that provide the brokerage services or web interfaces. Within the Web services, there may be web authorization or security. All of these brokerage services VMs may be connected to multiple places within the Data Center or multiple data centers to obtain information. The financial VMs need compute, network, and data storage. Connecting all three according to business policy is critical to balancing the Financial houses budget. Some of the connections may need to be secure (due to transfer of money or privacy issues). -------- Thanks ! Sue -----Original Message----- From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of Melinda Shore Sent: Monday, December 16, 2013 11:36 AM To: vnfpool@ietf.org Subject: Re: [vnfpool] RSerPool protocol experience On 12/16/13 7:18 AM, Susan Hares wrote: > What exactly did the principal authors "hammer" with STCP? Sure: what SCTP provided, relevant to this question, was multihomed endpoints. There were other attractive transport features, of course, but it was if they said "What can we do with multihoming?" rather than asking "How can we do server pooling/provide reliability/whatever?" I tend to think that the further you move up the stack the harder it is to do the kind of state distribution you're asking for and keep it in the sub-second range. For example, firewalling and load balancing tend to have or need awareness of session or application protocol state. I really don't think this devolves to a routing problem. Melinda -- Melinda Shore No Mountain Software melinda.shore@nomountain.net "Software longa, hardware brevis." _______________________________________________ vnfpool mailing list vnfpool@ietf.org https://www.ietf.org/mailman/listinfo/vnfpool From Michael.Tuexen@lurchi.franken.de Mon Dec 16 10:25:23 2013 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 913241AE18E for ; Mon, 16 Dec 2013 10:25:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.538, SPF_HELO_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 asKEetecb7TO for ; Mon, 16 Dec 2013 10:25:20 -0800 (PST) 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 7C4391A9313 for ; Mon, 16 Dec 2013 10:25:19 -0800 (PST) Received: from [10.225.9.5] (unknown [194.95.73.101]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 3802D1C0C0692; Mon, 16 Dec 2013 19:25:17 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Tuexen In-Reply-To: <009201cefa7a$8650f610$92f2e230$@ndzh.com> Date: Mon, 16 Dec 2013 19:25:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <31EA8A53-732A-4810-8BF0-A91F97190733@lurchi.franken.de> References: <201309172005.r8HK5XK5014894@cichlid.raleigh.ibm.com> <5238B9AE.5080103@nomountain.net> <009201cefa7a$8650f610$92f2e230$@ndzh.com> To: "Susan Hares" X-Mailer: Apple Mail (2.1510) Cc: vnfpool@ietf.org, 'Melinda Shore' Subject: Re: [vnfpool] RSerPool protocol experience 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, 16 Dec 2013 18:25:23 -0000 On Dec 16, 2013, at 5:18 PM, "Susan Hares" wrote: > Melinda: >=20 > I'm trying to provide input for problem statement 2. This post is to = dig > into the issues you mentioned on the RSerPool protocol experience.=20 >=20 > Focus in the draft-zong-vnfpool-problem-statement-01: section 3.3 = service > state synchronization plus impact on 3.1, 3.4, & 3.5 (see below for = the > comments).=20 >=20 > ------------- >=20 > Can you provide details on the comment:=20 > "The principal authors had a hammer (SCTP) and wanted to pound = things. > They failed to > adequately address core problems around state sharing, = synchronization, > etc. - distributed computing=20 > problems" >=20 > What exactly did the principal authors "hammer" with STCP? And how = to > impact it:=20 Hi Susan, a very high level view: If you want to build a fault tolerant system, SCTP deals with network = failures by using multiple path (multi-homing) and RSerPool deals with end-point = failures by using multiple end-points (server pools). Best regards Michael >=20 > Why am I curious:=20 >=20 > I convinced that the distribute of state has time-dependencies > (critical/urgent, quick, configuration state).=20 > Different algorithm have different strengths.=20 >=20 > State sharing for sub-second of massive amounts of network-dependent = data > has a study of routing for 30+ years. A few algorithms there are = extremely > useful to do state sharing. One lesson for the SDN TE/Link state is = that > the work horses of the Internet routing (ISIS/OSPF, BGP, VRRP) or name > distribution (DNS, DHCP) do a good job for the distribution with/or = without > policy.=20 >=20 > Combining the routing state distribution with augmented TCP handling = makes > sense for rapid congestion avoidance. The state distribution (L1-L7) = tells > me where the bottle necks are. Link states algorithms and coding = have > improved to be able to handle L1-L7 state distribution rapidly.=20 >=20 > Explicit congestion notification can be passed sub-second in order to = tune > the TCP bandwidth and avoid the TCP saw-tooth. If you distribute the = levels > of the network congestion, you can avoid sending the whole system into = the > repeat performance of TCP.=20 >=20 > So.. can we go a level deeper on this discussion ? >=20 > Sue Hares=20 >=20 > =3D=3D=3D=3D=3D >=20 > Focus in draft-zong-vnfpool-problem-statement-01: >=20 > 3.3) Service state synchronization: =20 > a) Who is responsible and how to collect/keep service state of = instance? >=20 > b) How to synchronize service state with back-up instsance.=20 >=20 > Questions implied but not in document:=20 >=20 > 1) Does the work need a cluster concept within a pool manager?=20 >=20 > To clarify this new question: Do the verticals of mobile istores, = medical > devices, and financial devices require a the concepts of a cluster to = make > vertical NFV connections easy to make?=20 >=20 > [There may be machine-2-machine devices that require the same things, = but > since m2m is consider a bit off I have quoted the current = applications.] =20 >=20 > 2) How does the VNF clusters interact with instance selection/status = (3.1), > backup selection/status (3.2), transition handling (3.4), and policy > enforcement (3.5).=20 >=20 >=20 >=20 > -----Original Message----- > From: vnfpool-bounces@ietf.org [mailto:vnfpool-bounces@ietf.org] On = Behalf > Of Melinda Shore > Sent: Tuesday, September 17, 2013 4:21 PM > To: vnfpool@ietf.org > Subject: Re: [vnfpool] RSerPool protocol experience >=20 > On 9/17/13 12:05 PM, Thomas Narten wrote: >> I believe they were published as experimental protocols. Have they=20 >> been implemented in any products? Do we have any deployment = experience=20 >> with them? >=20 > I co-authored a few of those documents and I know of no deployments. >=20 > I was concerned when I first saw rserpool in the vnfpool documents, = but > here's my take on it: >=20 > 1) rserpool was not a good answer to the problem that > it purported to address. The principal authors had a hammer > (SCTP) and wanted to pound things. They failed to > adequately address core problems around state sharing, > synchronization, etc. - distributed computing problems >=20 > 2) It's fine for providing a pooling mechanism, but an > actual application built around it will require significant > effort >=20 > 3) the VNF reliability problem is probably a pretty good > use of rserpool, as long as the work is properly scoped > and the charter is very, very clear about what would > need to be done. This is not really a distributed > computing problem. >=20 > To summarize, I think that the core problems with rserpool have to do = with > its nearly complete inadequacy as a telephony gateway and/or switch = pooling > solution. That doesn't mean that it's inapplicable to other problems. >=20 > -- > Melinda Shore > No Mountain Software > melinda.shore@nomountain.net >=20 > "Software longa, hardware brevis." > _______________________________________________ > vnfpool mailing list > vnfpool@ietf.org > https://www.ietf.org/mailman/listinfo/vnfpool >=20 > _______________________________________________ > vnfpool mailing list > vnfpool@ietf.org > https://www.ietf.org/mailman/listinfo/vnfpool >=20 From shares@ndzh.com Mon Dec 16 10:53:20 2013 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 996DC1AE118 for ; Mon, 16 Dec 2013 10:53:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] 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 Mof3Llehb_RZ for ; Mon, 16 Dec 2013 10:53:19 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 354BE1AE0D1 for ; Mon, 16 Dec 2013 10:53:19 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Michael Tuexen'" References: <201309172005.r8HK5XK5014894@cichlid.raleigh.ibm.com> <5238B9AE.5080103@nomountain.net> <009201cefa7a$8650f610$92f2e230$@ndzh.com> <31EA8A53-732A-4810-8BF0-A91F97190733@lurchi.franken.de> In-Reply-To: <31EA8A53-732A-4810-8BF0-A91F97190733@lurchi.franken.de> Date: Mon, 16 Dec 2013 13:53:15 -0500 Message-ID: <00dd01cefa90$14144370$3c3cca50$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHEKiK/3PyZ2GmpSPuyZgwQjLgljgJN8CVkAcwVycEBX4wUU5pA/beg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: vnfpool@ietf.org, 'Melinda Shore' Subject: Re: [vnfpool] RSerPool protocol experience 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, 16 Dec 2013 18:53:20 -0000 Michael: > > >> What exactly did the principal authors "hammer" with STCP? And how to impact it: >> >Hi Susan, > >a very high level view: >If you want to build a fault tolerant system, SCTP deals with network failures by using multiple path (multi->homing) and RSerPool deals with end-point failures by using multiple end-points (server pools). > >Best regards >Michael Michael: This matches my understanding. Both are necessary to build a product. Three resources needed for VMs: computer, network, storage. If the VNF Pools needs end-point reliability: see RSerPools or others such pools. If the VNF Pools network pathway reliability: see SCTP (transport) + network pathways If the VNF Pools needs storage check-offs, see another protocol. Sue From shares@ndzh.com Mon Dec 16 11:01:31 2013 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 441241AE138 for ; Mon, 16 Dec 2013 11:01:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.645 X-Spam-Level: *** X-Spam-Status: No, score=3.645 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845] 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 FwrT2lKpWocS for ; Mon, 16 Dec 2013 11:01:30 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id EAB171AE11F for ; Mon, 16 Dec 2013 11:01:29 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Diego R. Lopez'" , "'Melinda Shore'" References: <52940EB0.6040601@kddilabs.jp> <529C5A30.3070000@orange.com> <4A95BA014132FF49AE685FAB4B9F17F645C293E9@dfweml509-mbx.china.huawei.com> <52A1FE77.10405@orange.com> <65174429B5AF4C45BD0798810EC48E0A0D38CF@EX-0-MB2.lancs.local> <52A52A3F.4060503@nomountain.net> In-Reply-To: Date: Mon, 16 Dec 2013 14:01:26 -0500 Message-ID: <00ef01cefa91$38c130b0$aa439210$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHY+TQ7dY3tQjejG3tIVJ9qDrtQ3QIpAmXyASf3zuYCZZPHvAKcw0hyAt4ScbICsFsViAHVabrCAveJ9cgCSuU+3QJmsqPkmYgfcWA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: vnfpool@ietf.org Subject: Re: [vnfpool] VNF Pool 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, 16 Dec 2013 19:01:31 -0000 Diego: I'm catching up your email (12/9/13).=20 Can you explain a bit more about your statement: "External elements, = like other virtual and/or physical network functions in a given path = (the realization of the chain) or user applications should be completely = oblivious to the pooling mechanisms in place." I'm not suggesting a feature expansion in the VNF and pooling manager = work, but rather a reduction with an API added. The APIs would Pool = Manager to obtain information from other sources (i2rs, ALTO, etc).=20 An API can allow infrastructure VMs/process to share status on = infrastructure that fate-shares with the VNF pools. This allows the = infrastructure to notify the Pool manager "hints" on good algorithmic = placement/balancing of pools. =20 An API would also benefit application deployment. If Service provider = schedules a very popular mobile application via the app-store, this API = allows a feedback application download traffic spikes. The VNF Pool = Manager could obtain more resources based on the policy pre-set for the = traffic spikes.=20 Real Example:=20 Suppose a new version of the Angry Birds mobile phone app called "Angry = Birds: Thor's revenge" is schedule to deploy with a new Marvel: Thor's = Revenge movie. During the first few weeks it make sense to have a = feedback loop that can increase the VNF (pools) that need the = firewall/security/loadbalancing to handle the sales.=20 U 2 Be Goode,=20 Sue Hares=20 -----Original Message----- From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of Diego R. = Lopez Sent: Monday, December 09, 2013 2:00 PM To: Melinda Shore Cc: Subject: Re: [vnfpool] VNF Pool Problem Statement Hi, I agree with Melinda in that the problem has to be confined to the VNF = (and its pooling manager) and the service chaining management functions. = External elements, like other virtual and/or physical network functions = in a given path (the realization of the chain) or user applications = should be completely oblivious to the pooling mechanisms in place. Be goode, On 9 Dec 2013, at 03:26 , Melinda Shore wrote: > I think Daniel is asking exactly the right questions. But to back up=20 > a bit, I've been thinking about this over the weekend and realized=20 > that the scenario is actually simpler than I'd been considering. If=20 > the VNF instances are pooled along the general lines of something like = > rserpool, it is not the case that an external client will need to be=20 > modified. The only elements which would need to be able to "talk" the = > pooling protocol are already participating - they'd be the pool=20 > manager and whatever service chain management function is being used,=20 > the pool members, and adjacent pools. So I think we're in good shape=20 > there; we could probably use some better text around this to make it=20 > clearer. > > Melinda > _______________________________________________ > vnfpool mailing list > vnfpool@ietf.org > https://www.ietf.org/mailman/listinfo/vnfpool -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego@tid.es Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------------- ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar = nuestra pol=C3=ADtica de env=C3=ADo y recepci=C3=B3n de correo = electr=C3=B3nico en el enlace situado m=C3=A1s abajo. This message is intended exclusively for its addressee. We only send and = receive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx _______________________________________________ vnfpool mailing list vnfpool@ietf.org https://www.ietf.org/mailman/listinfo/vnfpool From Michael.Tuexen@lurchi.franken.de Mon Dec 16 11:04:53 2013 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 A23351AE2F5 for ; Mon, 16 Dec 2013 11:04:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.538, SPF_HELO_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 diDpsUugAVSE for ; Mon, 16 Dec 2013 11:04:51 -0800 (PST) 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 3FCC01AE2C1 for ; Mon, 16 Dec 2013 11:04:51 -0800 (PST) Received: from [10.225.9.5] (unknown [194.95.73.101]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 38C4C1C0C0692; Mon, 16 Dec 2013 20:04:50 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Tuexen In-Reply-To: <00dd01cefa90$14144370$3c3cca50$@ndzh.com> Date: Mon, 16 Dec 2013 20:04:50 +0100 Content-Transfer-Encoding: 7bit Message-Id: <4D15D4B8-4858-487C-AFC5-0CC93B6FF810@lurchi.franken.de> References: <201309172005.r8HK5XK5014894@cichlid.raleigh.ibm.com> <5238B9AE.5080103@nomountain.net> <009201cefa7a$8650f610$92f2e230$@ndzh.com> <31EA8A53-732A-4810-8BF0-A91F97190733@lurchi.franken.de> <00dd01cefa90$14144370$3c3cca50$@ndzh.com> To: Susan Hares X-Mailer: Apple Mail (2.1510) Cc: vnfpool@ietf.org, 'Melinda Shore' Subject: Re: [vnfpool] RSerPool protocol experience 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, 16 Dec 2013 19:04:53 -0000 On Dec 16, 2013, at 7:53 PM, Susan Hares wrote: > Michael: > > >>> >>> What exactly did the principal authors "hammer" with STCP? And how to > impact it: > >>> >> Hi Susan, >> >> a very high level view: >> If you want to build a fault tolerant system, SCTP deals with network > failures by using multiple path (multi->homing) and RSerPool deals with > end-point failures by using multiple end-points (server pools). >> >> Best regards >> Michael > > Michael: > > This matches my understanding. Both are necessary to build a product. > > Three resources needed for VMs: computer, network, storage. > > If the VNF Pools needs end-point reliability: see RSerPools or others such > pools. > If the VNF Pools network pathway reliability: see SCTP (transport) + > network pathways > If the VNF Pools needs storage check-offs, see another protocol. You could use RSerPool to handle a pool of file servers. The syncing between the file servers has to be done somehow. But you could use RSerPool to say "I want to connect to a file server" and get back the IP address / port number / protocol for your NFS server, for example. The service provided by the server pool is generic and not limited in any way by RSerPool. Best regards Michael > > Sue > > > > > From melinda.shore@nomountain.net Mon Dec 16 14:28:16 2013 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 B15A61ADBCD for ; Mon, 16 Dec 2013 14:28:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] 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 n-5B_OL5TTSA for ; Mon, 16 Dec 2013 14:28:15 -0800 (PST) Received: from homiemail-a35.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 785D11A1F62 for ; Mon, 16 Dec 2013 14:28:15 -0800 (PST) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id D987354073 for ; Mon, 16 Dec 2013 14:28:14 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=nomountain.net; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=nomountain.net ; b=YRJ+U973aGLrAO3YoeP9QwoJGYfMzmVodML2Tn/t3CabR8K8DFo+EHA642vZ w/ryJoX0/u+jlCYI5XnRuWqlqoo4oRMz05LnQvw+djrcgGqaeW/TQt5yhPfPbOTf 1/uzxsYA1o0kIT4K9xsa9bOEQkgpUvwQkiFew+zNg9zvNsQ= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=nomountain.net; h= message-id:date:from:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; s= nomountain.net; bh=Y1QtJj42D3wjnm96Un8yYLvC4U8=; b=clP/l3x8l64MV 2z6aPilC7VhJQWTiEywoGJ91mtPlPIhTF2WKxUUdlSwEcriJbF0ZY0okqLv9GaUp BkqJcWwMPrjw0Z+lhC6SBxdtlRHdIv4P51q8Qot69bcDLIIl817xHSA1d7g6z39x JSbOghO5dHFle5N/MmwidiHG+nGohQ= Received: from spandex.local (216-67-50-190-rb3.nwc.dsl.dynamic.acsalaska.net [216.67.50.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: melinda.shore@nomountain.net) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPSA id 88F2654055 for ; Mon, 16 Dec 2013 14:28:14 -0800 (PST) Message-ID: <52AF7E7C.3010800@nomountain.net> Date: Mon, 16 Dec 2013 13:28:12 -0900 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: <201309172005.r8HK5XK5014894@cichlid.raleigh.ibm.com> <5238B9AE.5080103@nomountain.net> <009201cefa7a$8650f610$92f2e230$@ndzh.com> <52AF2BDC.1020706@nomountain.net> <00cb01cefa89$89f6cec0$9de46c40$@ndzh.com> In-Reply-To: <00cb01cefa89$89f6cec0$9de46c40$@ndzh.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [vnfpool] RSerPool protocol experience 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, 16 Dec 2013 22:28:16 -0000 On 12/16/13 9:06 AM, Susan Hares wrote: > 1) Since the beginning of web service on financial institutions the HA > demands required multiple interfaces on web-server, and fail-over between > web servers. If we redefine the web server as a cluster of > web-applications, does the multiple-end points work? I hope to holler that application services are out of scope for this particular piece of work. I am not particularly a fan of rigid layering and I think that layering discussions in the IETF have tended to rathole (see: nvo3) but some clarity about it can help prevent unfortunate architectural mistakes. For example, the nsis working group had a difficult time conceptualizing lines between layers and ended up with a clunky, expensive security mechanism, while I think we got that one right in NLS by having a clearer model of what's in and what's out and by focusing on protecting the protocol components we can expect to have "knowledge" of. In this case, I think we need to be clear about what a virtualized network function can reasonably be expected to have knowledge of, in terms of protocol and network state. A firewall may track certain aspects of application protocol state and we may want to provide reliable firewall modularization. But doing that does not necessitate putting a virtualized web service into the NFV graph, any more than a web server runs directly on a firewall (leaving aside for the moment specialized use-specific web services, like a management interface). I think that aspects of this are going to be difficult enough that we probably want to avoid vertical applications and keep a tight focus on basically decomposing a network device. Melinda -- Melinda Shore No Mountain Software melinda.shore@nomountain.net "Software longa, hardware brevis." From shares@ndzh.com Mon Dec 16 15:47:12 2013 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 658031ADE87 for ; Mon, 16 Dec 2013 15:47:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] 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 DEq7o9RyN26g for ; Mon, 16 Dec 2013 15:47:10 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE5A1AD945 for ; Mon, 16 Dec 2013 15:47:10 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Melinda Shore'" , References: <201309172005.r8HK5XK5014894@cichlid.raleigh.ibm.com> <5238B9AE.5080103@nomountain.net> <009201cefa7a$8650f610$92f2e230$@ndzh.com> <52AF2BDC.1020706@nomountain.net> <00cb01cefa89$89f6cec0$9de46c40$@ndzh.com> <52AF7E7C.3010800@nomountain.net> In-Reply-To: <52AF7E7C.3010800@nomountain.net> Date: Mon, 16 Dec 2013 18:47:05 -0500 Message-ID: <014101cefab9$20d0ed60$6272c820$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHEKiK/3PyZ2GmpSPuyZgwQjLgljgJN8CVkAcwVycEBqMEG5gHczyyyArBppOaaGplZkA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Subject: Re: [vnfpool] RSerPool protocol experience 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, 16 Dec 2013 23:47:12 -0000 Melinda: While you are holler that application services are out of scope, can we refocus on the question and use case I asked about? Why do you want to avoid consider vertical applications as a use case for deployment? The medical, financial, insurance, business SAP/Order transactions, mobile store applications actually consume DC and network resources. Are you looking for only home-based NFV (firewall, load balancers, AAA, email spam reduction)? If you start by answering that question, it would help me understand your market. I gave a use cases in a set of markets for you to solve. If some of the use case below are out, just let me know and why. If a use case is in, tell me where you draw the lines for the NFV graph and why. The Pool Managers will come in different sizes and shapes - just as routing PCEs, SDN controllers, and NSC calculation devices. Allowing a protocol with options allows vendors to innovate. By the way, there are reasons to shorten the web-server distance to the firewall. Pop-up ads run in the delay it take to get your web page. Inquiring minds want to know, Cheerily, Sue -----Original Message----- From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of Melinda Shore Sent: Monday, December 16, 2013 5:28 PM To: vnfpool@ietf.org Subject: Re: [vnfpool] RSerPool protocol experience On 12/16/13 9:06 AM, Susan Hares wrote: > 1) Since the beginning of web service on financial institutions the HA > demands required multiple interfaces on web-server, and fail-over > between web servers. If we redefine the web server as a cluster of > web-applications, does the multiple-end points work? I hope to holler that application services are out of scope for this particular piece of work. I am not particularly a fan of rigid layering and I think that layering discussions in the IETF have tended to rathole (see: nvo3) but some clarity about it can help prevent unfortunate architectural mistakes. For example, the nsis working group had a difficult time conceptualizing lines between layers and ended up with a clunky, expensive security mechanism, while I think we got that one right in NLS by having a clearer model of what's in and what's out and by focusing on protecting the protocol components we can expect to have "knowledge" of. In this case, I think we need to be clear about what a virtualized network function can reasonably be expected to have knowledge of, in terms of protocol and network state. A firewall may track certain aspects of application protocol state and we may want to provide reliable firewall modularization. But doing that does not necessitate putting a virtualized web service into the NFV graph, any more than a web server runs directly on a firewall (leaving aside for the moment specialized use-specific web services, like a management interface). I think that aspects of this are going to be difficult enough that we probably want to avoid vertical applications and keep a tight focus on basically decomposing a network device. Melinda -- Melinda Shore No Mountain Software melinda.shore@nomountain.net "Software longa, hardware brevis." _______________________________________________ vnfpool mailing list vnfpool@ietf.org https://www.ietf.org/mailman/listinfo/vnfpool From zongning@huawei.com Wed Dec 18 02:27:15 2013 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 ADC3D1AE130 for ; Wed, 18 Dec 2013 02:27:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.738 X-Spam-Level: X-Spam-Status: No, score=-104.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 H3tToMO_9qfx for ; Wed, 18 Dec 2013 02:27:12 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC791AE0A2 for ; Wed, 18 Dec 2013 02:27:11 -0800 (PST) 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 BBO15215; Wed, 18 Dec 2013 10:27:09 +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.158.1; Wed, 18 Dec 2013 10:26:37 +0000 Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 18 Dec 2013 10:27:08 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Wed, 18 Dec 2013 18:27:02 +0800 From: Zongning To: "vnfpool@ietf.org" Thread-Topic: Draft Charter Thread-Index: Ac7727CzSbDOhs/tTPeAW3DmZge09g== Date: Wed, 18 Dec 2013 10:27:02 +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.28] Content-Type: multipart/alternative; boundary="_000_B0D29E0424F2DE47A0B36779EC6667792585B31Cnkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [vnfpool] Draft Charter 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, 18 Dec 2013 10:27:15 -0000 --_000_B0D29E0424F2DE47A0B36779EC6667792585B31Cnkgeml501mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, folks, Based on the feedback, I made another revision of the problem description t= ext, as below. The main updates are: 1) Modification based on the comments from Hidetoshi and Lac, thank y= ou; 2) Avoid limiting VNF pools to be applied to SFC, by rewording VNF ch= ain to VNF set; 3) Add goals and milestones to make the whole text more like a charte= r. I believe we need a draft charter as we are going to request a WG forming B= oF in London. This is also why I changed the name of the thread. You are welcome to use this version as a starting point for further comment= s, or bring a completely new *and* better one in your mind. :) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D A Virtualized Network Function (VNF) provides network function (e.g., packe= t filtering at firewalls, load balancing, etc) and is typically implemented= as software instance running on commodity hardware server via virtualization layer (i.e., hyperv= isor). This is distinct from monolithic network devices, where either a sin= gle or a number of different network functions are provided in the same specialized hardware s= erver. There is a trend to move such network functions away from specialized hardw= are to commodity hardware server, based on virtualized resources, to suppor= t VNF and further also to support Service Function Chaining (SFC). In SFC, a network service can be i= mplemented by a set of sequentially connected VNFs deployed at different po= ints in the network. We call a group of VNFs a VNF set, which can be used not only as a SFC, but al= so solely as one or more pools of VNFs. A VNF set can introduce additional points of failure beyond those inherent = in a single specialized server, and therefore poses additional challenges o= n reliability of the provided services. For a single VNF, it typically would not have built-in r= eliability mechanisms on its host (i.e., a commodity hardware server). Inst= ead, there are more factors or risk such as software failure, server overload, and instance mig= ration that may lead to VNF failures. Currently generalized pooling and oth= er redundancy mechanisms may be applied to address some reliability requirements of a single VNF. However, the complexity of dealing with a growing number of VNFs including = stateful and stateless functions, and extending the redundancy across a VNF= set (i.e., multiple pools for multiple VNFs) requires further solution development. For example, when= a "live" VNF pool member goes out of service, how do adjacent entities lea= rn which pool member will replace it? How do VNFs learn the state of adjacent VNFs to support reliabi= lity mechanisms like load sharing and switch before break? How is the servi= ce state of an instance held and accessed for efficient synchronization with backup instances and o= ther members of its pool? Ideally, the reliability of a VNF set means that the services provided by s= uch a VNF set will continue throughout an interruption and the outages of o= ne or more VNFs will not be visible to the users of the VNF set. In the current charter, the WG focu= ses the work around several mechanisms supporting the reliability of a VNF = set: redundancy across a VNF set and stateful failover among pool members. Additional mechanisms for= reliable VNF set might be included after further gap analysis between our = requirements and IETF technologies. The overall problem space can be further broken to include the following it= ems: . Signaling within and between VNF pools for transition (e.g. state change,= scaling, moving) notification, backup advertisement; . Identification and evaluation of state sharing mechanisms, including (but= not limited to) distributed shared memory, gossip protocols, pfsync, and s= tate check pointing; . Exchange of reliability related information between a VNF set and the und= erlying network (e.g. interfacing with ALTO, I2RS); . Identify and analyze reliable transport characteristics for control plane= traffic; . Analysis of transport security characteristics to provide protection agai= nst known threats, and identification of an appropriate trust model; The initial work will include a problem statement, VNF pooling architecture= , use cases and requirements analysis, and an evaluation of existing techno= logies against the architecture and requirements. It is our expectation that we will be able t= o rely heavily on existing IETF technologies but that gaps will be found ar= ound problems like state transfer and trust/security, which will need to be addressed. Particularly,= we will work closely with SFC WG to develop mechanisms complementary to SF= C approaches, based on identified reliability requirements. Goals and Milestones: September 2014 Submit VNF Pool Problem Statement to IESG for publication a= s Informational December 2014 Submit VNF Pool Use Cases and Requirements to IESG for publi= cation as Informational April 2015 Submit VNF Pooling Architecture to IESG for publication as Propo= sed Standard April 2015 Submit first document of gap analysis to IESG for publication as= Informational =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Thanks. -Ning --_000_B0D29E0424F2DE47A0B36779EC6667792585B31Cnkgeml501mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, folks,

 

Based on the feedback, I made a= nother revision of the problem description text, as below. The main updates= are:

1= )   &= nbsp;   Modification based on t= he comments from Hidetoshi and Lac, thank you;

2= )   &= nbsp;   Avoid limiting VNF pool= s to be applied to SFC, by rewording VNF chain to VNF set;

3= )   &= nbsp;   Add goals and milestone= s to make the whole text more like a charter.

I believe we need a draft chart= er as we are going to request a WG forming BoF in London. This is also why = I changed the name of the thread.

You are welcome to use this ver= sion as a starting point for further comments, or bring a completely new *<= b>and* better one in your mind. J

 

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

A Virtualized Network Function = (VNF) provides network function (e.g., packet filtering at firewalls, load = balancing, etc) and is typically implemented as software instance

running on commodity hardware s= erver via virtualization layer (i.e., hypervisor). This is distinct from mo= nolithic network devices, where either a single or a number of

different network functions are= provided in the same specialized hardware server.

 

There is a trend to move such n= etwork functions away from specialized hardware to commodity hardware serve= r, based on virtualized resources, to support VNF and further also to

support Service Function Chaini= ng (SFC). In SFC, a network service can be implemented by a set of sequenti= ally connected VNFs deployed at different points in the network. We

call a group of VNFs a VNF set,= which can be used not only as a SFC, but also solely as one or more pools = of VNFs.

 

A VNF set can introduce additio= nal points of failure beyond those inherent in a single specialized server,= and therefore poses additional challenges on reliability of the

provided services. For a single= VNF, it typically would not have built-in reliability mechanisms on its ho= st (i.e., a commodity hardware server). Instead, there are more

factors or risk such as softwar= e failure, server overload, and instance migration that may lead to VNF fai= lures. Currently generalized pooling and other redundancy mechanisms

may be applied to address some = reliability requirements of a single VNF.

 

However, the complexity of deal= ing with a growing number of VNFs including stateful and stateless function= s, and extending the redundancy across a VNF set (i.e., multiple pools

for multiple VNFs) requires fur= ther solution development. For example, when a "live" VNF pool me= mber goes out of service, how do adjacent entities learn which pool member = will

replace it? How do VNFs learn t= he state of adjacent VNFs to support reliability mechanisms like load shari= ng and switch before break? How is the service state of an instance

held and accessed for efficient= synchronization with backup instances and other members of its pool?<= /o:p>

 

Ideally, the reliability of a V= NF set means that the services provided by such a VNF set will continue thr= oughout an interruption and the outages of one or more VNFs will not

be visible to the users of the = VNF set. In the current charter, the WG focuses the work around several mec= hanisms supporting the reliability of a VNF set: redundancy across a

VNF set and stateful failover a= mong pool members. Additional mechanisms for reliable VNF set might be incl= uded after further gap analysis between our requirements and IETF

technologies.=

 

The overall problem space can b= e further broken to include the following items:

. Signaling within and between = VNF pools for transition (e.g. state change, scaling, moving) notification,= backup advertisement;

. Identification and evaluation= of state sharing mechanisms, including (but not limited to) distributed sh= ared memory, gossip protocols, pfsync, and state check pointing;=

. Exchange of reliability relat= ed information between a VNF set and the underlying network (e.g. interfaci= ng with ALTO, I2RS);

. Identify and analyze reliable= transport characteristics for control plane traffic;

. Analysis of transport securit= y characteristics to provide protection against known threats, and identifi= cation of an appropriate trust model;

 

The initial work will include a= problem statement, VNF pooling architecture, use cases and requirements an= alysis, and an evaluation of existing technologies against the

architecture and requirements. = It is our expectation that we will be able to rely heavily on existing IETF= technologies but that gaps will be found around problems like state

transfer and trust/security, wh= ich will need to be addressed. Particularly, we will work closely with SFC = WG to develop mechanisms complementary to SFC approaches, based on

identified reliability requirem= ents.

 

Goals and Milestones:

September 2014  Submit VNF= Pool Problem Statement to IESG for publication as Informational=

December 2014  Submit VNF = Pool Use Cases and Requirements to IESG for publication as Informational

April 2015 Submit VNF Pooling A= rchitecture to IESG for publication as Proposed Standard<= /p>

April 2015 Submit first documen= t of gap analysis to IESG for publication as Informational

 

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

 

Thanks.

 

-Ning

--_000_B0D29E0424F2DE47A0B36779EC6667792585B31Cnkgeml501mbschi_-- From zongning@huawei.com Wed Dec 18 02:39:46 2013 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 964EC1ADFD5 for ; Wed, 18 Dec 2013 02:39:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.738 X-Spam-Level: X-Spam-Status: No, score=-104.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 IzjP1HAlmeUF for ; Wed, 18 Dec 2013 02:39:44 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 68C051AD6D1 for ; Wed, 18 Dec 2013 02:39:43 -0800 (PST) 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 AZD18273; Wed, 18 Dec 2013 10:39:41 +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, 18 Dec 2013 10:38:53 +0000 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; Wed, 18 Dec 2013 10:39:21 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Wed, 18 Dec 2013 18:39:18 +0800 From: Zongning To: "vnfpool@ietf.org" Thread-Topic: Draft Charter (Pls ignore previous post having editorial nits) Thread-Index: Ac773Wa4Q3mfxMweQRG+gKR59d6VgQ== Date: Wed, 18 Dec 2013 10:39:17 +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.28] Content-Type: multipart/alternative; boundary="_000_B0D29E0424F2DE47A0B36779EC6667792585B342nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [vnfpool] Draft Charter (Pls ignore previous post having editorial nits) 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, 18 Dec 2013 10:39:46 -0000 --_000_B0D29E0424F2DE47A0B36779EC6667792585B342nkgeml501mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, folks, Based on the feedback, I made another revision of the problem description t= ext, as below. The main updates are: 1) Modification based on the comments from Hidetoshi and Lac, thank y= ou; 2) Avoid limiting VNF pools to be applied to SFC, by rewording VNF ch= ain to VNF set; 3) Add goals and milestones to make the whole text more like a charte= r. I believe we need a draft charter as we are going to request a WG forming B= oF in London. This is also why I changed the name of the thread. You are welcome to use this version as a starting point for further comment= s, or bring a completely new *and* better one in your mind. :) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D A Virtualized Network Function (VNF) provides network function (e.g., packe= t filtering at firewalls, load balancing, etc) and is typically implemented= as software instance running on commodity hardware server via virtualizati= on layer (i.e., hypervisor). This is distinct from monolithic network devic= es, where either a single or a number of different network functions are pr= ovided in the same specialized hardware server. There is a trend to move such network functions away from specialized hardw= are to commodity hardware server, based on virtualized resources, to suppor= t VNF and further also to support Service Function Chaining (SFC). In SFC, = a network service can be implemented by a set of sequentially connected VNF= s deployed at different points in the network. We call a group of VNFs a VN= F set, which can be used not only as a SFC, but also solely as one or more = pools of VNFs. A VNF set can introduce additional points of failure beyond those inherent = in a single specialized server, and therefore poses additional challenges o= n reliability of the provided services. For a single VNF, it typically woul= d not have built-in reliability mechanisms on its host (i.e., a commodity h= ardware server). Instead, there are more factors or risk such as software f= ailure, server overload, and instance migration that may lead to VNF failur= es. Currently generalized pooling and other redundancy mechanisms may be ap= plied to address some reliability requirements of a single VNF. However, the complexity of dealing with a growing number of VNFs including = stateful and stateless functions, and extending the redundancy across a VNF= set (i.e., multiple pools for multiple VNFs) requires further solution dev= elopment. For example, when a "live" VNF pool member goes out of service, h= ow do adjacent entities learn which pool member will replace it? How do VNF= s learn the state of adjacent VNFs to support reliability mechanisms like l= oad sharing and switch before break? How is the service state of an instanc= e held and accessed for efficient synchronization with backup instances and= other members of its pool? Ideally, the reliability of a VNF set means that the services provided by s= uch a VNF set will continue throughout an interruption and the outages of o= ne or more VNFs will not be visible to the users of the VNF set. In the cur= rent charter, the WG focuses the work around several mechanisms supporting = the reliability of a VNF set: redundancy across a VNF set and stateful fail= over among pool members. Additional mechanisms for reliable VNF set might b= e included after further gap analysis between our requirements and IETF tec= hnologies. The overall problem space can be further broken to include the following it= ems: . Signaling within and between VNF pools for transition (e.g. state change,= scaling, moving) notification, backup advertisement; . Identification and evaluation of state sharing mechanisms, including (but= not limited to) distributed shared memory, gossip protocols, pfsync, and s= tate check pointing; . Exchange of reliability related information between a VNF set and the und= erlying network (e.g. interfacing with ALTO, I2RS); . Identify and analyze reliable transport characteristics for control plane= traffic; . Analysis of transport security characteristics to provide protection agai= nst known threats, and identification of an appropriate trust model; The initial work will include a problem statement, VNF pooling architecture= , use cases and requirements analysis, and an evaluation of existing techno= logies against the architecture and requirements. It is our expectation tha= t we will be able to rely heavily on existing IETF technologies but that ga= ps will be found around problems like state transfer and trust/security, wh= ich will need to be addressed. Particularly, we will work closely with SFC = WG to develop mechanisms complementary to SFC approaches, based on identifi= ed reliability requirements. Goals and Milestones: September 2014 Submit VNF Pool Problem Statement to IESG for publication a= s Informational December 2014 Submit VNF Pool Use Cases and Requirements to IESG for publi= cation as Informational April 2015 Submit VNF Pooling Architecture to IESG for publication as Prop= osed Standard April 2015 Submit first document of gap analysis to IESG for publication a= s Informational =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Thanks. -Ning --_000_B0D29E0424F2DE47A0B36779EC6667792585B342nkgeml501mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, folks,

 

Based on the feedback, I made a= nother revision of the problem description text, as below. The main updates= are:

1= )   &= nbsp;   Modification based on t= he comments from Hidetoshi and Lac, thank you;

2= )   &= nbsp;   Avoid limiting VNF pool= s to be applied to SFC, by rewording VNF chain to VNF set;

3= )   &= nbsp;   Add goals and milestone= s to make the whole text more like a charter.

I believe we need a draft chart= er as we are going to request a WG forming BoF in London. This is also why = I changed the name of the thread.

You are welcome to use this ver= sion as a starting point for further comments, or bring a completely new *<= b>and* better one in your mind. J

 

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

A Virtualized Network Function = (VNF) provides network function (e.g., packet filtering at firewalls, load = balancing, etc) and is typically implemented as software instance running o= n commodity hardware server via virtualization layer (i.e., hypervisor). This is distinct from monolithic network devices= , where either a single or a number of different network functions are prov= ided in the same specialized hardware server.

 

There is a trend to move such n= etwork functions away from specialized hardware to commodity hardware serve= r, based on virtualized resources, to support VNF and further also to suppo= rt Service Function Chaining (SFC). In SFC, a network service can be implemented by a set of sequentially conn= ected VNFs deployed at different points in the network. We call a group of = VNFs a VNF set, which can be used not only as a SFC, but also solely as one= or more pools of VNFs.

 

A VNF set can introduce additio= nal points of failure beyond those inherent in a single specialized server,= and therefore poses additional challenges on reliability of the provided s= ervices. For a single VNF, it typically would not have built-in reliability mechanisms on its host (i.e., a commod= ity hardware server). Instead, there are more factors or risk such as softw= are failure, server overload, and instance migration that may lead to VNF f= ailures. Currently generalized pooling and other redundancy mechanisms may be applied to address some reliability= requirements of a single VNF.

 

However, the complexity of deal= ing with a growing number of VNFs including stateful and stateless function= s, and extending the redundancy across a VNF set (i.e., multiple pools for = multiple VNFs) requires further solution development. For example, when a "live" VNF pool member goes out= of service, how do adjacent entities learn which pool member will replace = it? How do VNFs learn the state of adjacent VNFs to support reliability mec= hanisms like load sharing and switch before break? How is the service state of an instance held and accessed for effic= ient synchronization with backup instances and other members of its pool?

 

Ideally, the reliability of a V= NF set means that the services provided by such a VNF set will continue thr= oughout an interruption and the outages of one or more VNFs will not be vis= ible to the users of the VNF set. In the current charter, the WG focuses the work around several mechanisms sup= porting the reliability of a VNF set: redundancy across a VNF set and state= ful failover among pool members. Additional mechanisms for reliable VNF set= might be included after further gap analysis between our requirements and IETF technologies.

 

The overall problem space can b= e further broken to include the following items:

. Signaling within and between = VNF pools for transition (e.g. state change, scaling, moving) notification,= backup advertisement;

. Identification and evaluation= of state sharing mechanisms, including (but not limited to) distributed sh= ared memory, gossip protocols, pfsync, and state check pointing;=

. Exchange of reliability relat= ed information between a VNF set and the underlying network (e.g. interfaci= ng with ALTO, I2RS);

. Identify and analyze reliable= transport characteristics for control plane traffic;

. Analysis of transport securit= y characteristics to provide protection against known threats, and identifi= cation of an appropriate trust model;

 

The initial work will include a= problem statement, VNF pooling architecture, use cases and requirements an= alysis, and an evaluation of existing technologies against the architecture= and requirements. It is our expectation that we will be able to rely heavily on existing IETF technologies but tha= t gaps will be found around problems like state transfer and trust/security= , which will need to be addressed. Particularly, we will work closely with = SFC WG to develop mechanisms complementary to SFC approaches, based on identified reliability requirements.

 

Goals and Milestones:

September 2014  Submit VNF= Pool Problem Statement to IESG for publication as Informational=

December 2014  Submit VNF = Pool Use Cases and Requirements to IESG for publication as Informational

April 2015  Submit VNF Poo= ling Architecture to IESG for publication as Proposed Standard

April 2015  Submit first d= ocument of gap analysis to IESG for publication as Informational=

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

 

Thanks.

 

-Ning

--_000_B0D29E0424F2DE47A0B36779EC6667792585B342nkgeml501mbschi_-- From diego@tid.es Tue Dec 31 05:44:59 2013 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 44F561AE2A6 for ; Tue, 31 Dec 2013 05:44:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.039 X-Spam-Level: X-Spam-Status: No, score=-2.039 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 QVr6xymzGA-X for ; Tue, 31 Dec 2013 05:44:56 -0800 (PST) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id 73B0A1AE2A3 for ; Tue, 31 Dec 2013 05:44:54 -0800 (PST) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MYO008Z5BI9XS@tid.hi.inet> for vnfpool@ietf.org; Tue, 31 Dec 2013 14:44:42 +0100 (MET) Received: from dequeue_removeroute (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id 02.32.03314.A4AC2C25; Tue, 31 Dec 2013 14:44:42 +0100 (CET) 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 ESMTP id <0MYO008ZVBIIXS@tid.hi.inet> for vnfpool@ietf.org; Tue, 31 Dec 2013 14:44:42 +0100 (MET) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.204]) by EX10-HTCAS5-MAD.hi.inet ([::1]) with mapi id 14.03.0158.001; Tue, 31 Dec 2013 14:44:41 +0100 Date: Tue, 31 Dec 2013 13:44:41 +0000 From: "Diego R. Lopez" In-reply-to: <00ef01cefa91$38c130b0$aa439210$@ndzh.com> X-Originating-IP: [10.95.64.115] To: Susan Hares Message-id: <4C14BA4E-1BA6-4FD9-B3AD-75FF020C6676@tid.es> Content-id: <383CC2C5F1A1AD4DB10DAC8EC9463747@hi.inet> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US, es-ES Thread-topic: [vnfpool] VNF Pool Problem Statement Thread-index: Ac7mmacuBQUiFtBEQ2CEYoAlHpu1YwDsY9sAAB6uswABGDbKAADfPKFKAAaSMoAAby4dgAAAuHqAACK4P4ABYBTNAALnWOuA X-AuditID: 0a5f4068-b7fe58e000000cf2-4f-52c2ca4ad9de X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42Lhinfg0vU6dSjI4O0BJYsZl/6zODB6LFny kymAMYrLJiU1J7MstUjfLoEro/+tc8Fb3Yq+5k/MDYwrVLsYOTkkBEwkpq/5yQRhi0lcuLee rYuRi0NI4ACjxOErV9hBEkICPxkltp1JgLBnMkrs+h0LYrMIqEp0Nl1iAbHZgOxHzb+B6jk4 hAUMJWbdTgEJcwqYS7x9PZUVYr6CxJ9zj8HKRQQUJY5cXQc2nlkgWqKrZQtYDa+ApcS0ddeY IeJmEpsuzGeEiAtK/Jh8jwUiriPR+/0bVI24RHPrTai4tsSTdxfA5jAKyEq8mz+fFWKXkcTM Ra/YIOwCiTsnd7BB3CMgsWTPeWYIW1Ti5eN/rBAvtrBKzH8hMIFRYhaSM2YhOWMWkjNmITlj FpIzFjCyrmIUK04qykzPKMlNzMxJNzDUy8jUy8xLLdnECIm4jB2My3eqHGIU4GBU4uFt0DsU JMSaWFZcmXuIUYKDWUmEN2g/UIg3JbGyKrUoP76oNCe1+BAjEwenVAPj/F32GZMtH3L2Kns4 s9d5B51pqFd4v2PXS7c2pZ88tzliDdTVWc6cTgyWnqjV6n1n3f1n8Ve3bner2KDoeD2NqX5H f9zHciWntxUCswwKY9Ys3G++9NtjuWlzA6xn6BvFcoX+b0g5lJXGeSHk6KG7n4J6/eTm1CwU v7nfQjJwXyn7e/n2/ypKLMUZiYZazEXFiQAHr44KlgIAAA== References: <52940EB0.6040601@kddilabs.jp> <529C5A30.3070000@orange.com> <4A95BA014132FF49AE685FAB4B9F17F645C293E9@dfweml509-mbx.china.huawei.com> <52A1FE77.10405@orange.com> <65174429B5AF4C45BD0798810EC48E0A0D38CF@EX-0-MB2.lancs.local> <52A52A3F.4060503@nomountain.net> <00ef01cefa91$38c130b0$aa439210$@ndzh.com> Cc: "" , Melinda Shore Subject: Re: [vnfpool] VNF Pool 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: Tue, 31 Dec 2013 13:44:59 -0000 Hi Susan, I think you express my intention very well when you say you did not propose= an expansion of the VNF and pooling manager. My point was to isolate the o= ther functions in the network from knowing any detail on the actual impleme= ntation/deployment details of the VNF in question. The VNFPOOL will become = a technique for such implementation, where the pool manager will be one of = the components of the VNFs that use this technique. For sure an API (or APIs, I'd say) are required for taking a real advantage= of the virtualized functions. As far as I can tell these APIs are being co= nsidered in the NFV architecture, precisely to deal with the interactions w= ith the infrastructure, with other network functions, and the apps using th= e network functions (or the OSS/BSS if you like) The diagram in Figure 4 of= the NFV architecture framework (at http://www.etsi.org/deliver/etsi_gs/NFV= /001_099/002/01.01.01_60/gs_NFV002v010101p.pdf) includes a set of reference= points where these APIs shall live. Be goode and have an Extremely Goode New Year, On 16 Dec 2013, at 20:01 , Susan Hares wrote: > Diego: > > I'm catching up your email (12/9/13). > > Can you explain a bit more about your statement: "External elements, lik= e other virtual and/or physical network functions in a given path (the real= ization of the chain) or user applications should be completely oblivious t= o the pooling mechanisms in place." > > I'm not suggesting a feature expansion in the VNF and pooling manager wor= k, but rather a reduction with an API added. The APIs would Pool Manager t= o obtain information from other sources (i2rs, ALTO, etc). > > An API can allow infrastructure VMs/process to share status on infrastruc= ture that fate-shares with the VNF pools. This allows the infrastructure t= o notify the Pool manager "hints" on good algorithmic placement/balancing o= f pools. > > An API would also benefit application deployment. If Service provider sc= hedules a very popular mobile application via the app-store, this API allow= s a feedback application download traffic spikes. The VNF Pool Manager cou= ld obtain more resources based on the policy pre-set for the traffic spikes= . > > Real Example: > Suppose a new version of the Angry Birds mobile phone app called "Angry B= irds: Thor's revenge" is schedule to deploy with a new Marvel: Thor's Reven= ge movie. During the first few weeks it make sense to have a feedback loo= p that can increase the VNF (pools) that need the firewall/security/loadbal= ancing to handle the sales. > > U 2 Be Goode, > > Sue Hares > > -----Original Message----- > From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of Diego R. Lop= ez > Sent: Monday, December 09, 2013 2:00 PM > To: Melinda Shore > Cc: > Subject: Re: [vnfpool] VNF Pool Problem Statement > > Hi, > > I agree with Melinda in that the problem has to be confined to the VNF (a= nd its pooling manager) and the service chaining management functions. Exte= rnal elements, like other virtual and/or physical network functions in a gi= ven path (the realization of the chain) or user applications should be comp= letely oblivious to the pooling mechanisms in place. > > Be goode, > > > On 9 Dec 2013, at 03:26 , Melinda Shore wrote: > >> I think Daniel is asking exactly the right questions. But to back up >> a bit, I've been thinking about this over the weekend and realized >> that the scenario is actually simpler than I'd been considering. If >> the VNF instances are pooled along the general lines of something like >> rserpool, it is not the case that an external client will need to be >> modified. The only elements which would need to be able to "talk" the >> pooling protocol are already participating - they'd be the pool >> manager and whatever service chain management function is being used, >> the pool members, and adjacent pools. So I think we're in good shape >> there; we could probably use some better text around this to make it >> clearer. >> >> Melinda >> _______________________________________________ >> vnfpool mailing list >> vnfpool@ietf.org >> https://www.ietf.org/mailman/listinfo/vnfpool > > > -- > "Esta vez no fallaremos, Doctor Infierno" > > Dr Diego R. Lopez > Telefonica I+D > http://people.tid.es/diego.lopez/ > > e-mail: diego@tid.es > Tel: +34 913 129 041 > Mobile: +34 682 051 091 > ----------------------------------------- > > > ________________________________ > > Este mensaje se dirige exclusivamente a su destinatario. Puede consultar = nuestra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el e= nlace situado m=E1s abajo. > This message is intended exclusively for its addressee. We only send and = receive email on the basis of the terms set out at: > http://www.tid.es/ES/PAGINAS/disclaimer.aspx > _______________________________________________ > vnfpool mailing list > vnfpool@ietf.org > https://www.ietf.org/mailman/listinfo/vnfpool > > _______________________________________________ > vnfpool mailing list > vnfpool@ietf.org > https://www.ietf.org/mailman/listinfo/vnfpool -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego@tid.es Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------------- ________________________________ 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