From nobody Sun Mar 2 08:01:48 2014 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC2361A07EC for ; Sun, 2 Mar 2014 08:01:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZWaTS6hYtqR for ; Sun, 2 Mar 2014 08:01:45 -0800 (PST) Received: from omzsmtpe03.verizonbusiness.com (omzsmtpe03.verizonbusiness.com [199.249.25.208]) by ietfa.amsl.com (Postfix) with ESMTP id CC3DF1A07A2 for ; Sun, 2 Mar 2014 08:01:44 -0800 (PST) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143]) by omzsmtpe03.verizonbusiness.com with ESMTP; 02 Mar 2014 16:01:41 +0000 From: "Mcdysan, David E" X-IronPort-AV: E=Sophos;i="4.97,572,1389744000"; d="scan'208";a="684622136" Received: from fhdp1lumxc7hb05.verizon.com (HELO FHDP1LUMXC7HB05.us.one.verizon.com) ([166.68.59.192]) by fldsmtpi01.verizon.com with ESMTP; 02 Mar 2014 16:01:41 +0000 Received: from fhdp1lumxc7v11.us.one.verizon.com ([166.68.59.148]) by FHDP1LUMXC7HB05.us.one.verizon.com ([166.68.59.192]) with mapi; Sun, 2 Mar 2014 11:01:41 -0500 To: "vnfpool@ietf.org" Date: Sun, 2 Mar 2014 11:01:37 -0500 Thread-Topic: Comments on draft-zong-vnfpool-problem-statement-03.txt Thread-Index: Ac82MLMz8AHpRS5oTWmjQrcEnSZeAw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/OLL0EttDTMvQfXmT32vM0YtDCaQ Subject: [vnfpool] Comments on draft-zong-vnfpool-problem-statement-03.txt 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, 02 Mar 2014 16:01:47 -0000 Hi, I read the subject draft and believe that it states the background and a number of the problems. I have a few major comments and suggestions on this version: Section 1, Background: I think that the potential benefits of vnfpool could be further stated. Possibly something like the following could be added after the fourth paragraph: "One means of recovery would be for a centralized orchestrator to select a server and create a new VNF instance. However, the recovery time of such a method may be many minutes and not acceptable for somemVNFs. Furthermore, this method relies on the central orchestrator being highly available. A pool of preconfigured VNFs makes recovery much faster and may also use a distributed method for recovry, not relying on a single centralized orchestrator." Section 3.2, Concept of VNF Set: - Material related to Service Function Chaining is in the same section. Suggest making Service Chaining a separate section. - In the new service chaining section, suggest adding some text like the following: "The VNFs in a set (i.e., pool) have a locator (e.g., IP address) and the Service Function Chain information from the control plane could have a level of indirection between the links that connect the VNFs; for example, as described in draft-boucadair-sfc-framework section 10.7, Figure 4. Ignoring state (for the moment) it may be possible to include an SF from the pool to replace a failed SF in an SFC using a form of indirection like this. For example, it may be possible to use central configuration as described in this draft or LISP (or some other protocol) in a distributed fashion to do this." Section 3.3 Problems, item 4 Service state synchronization: Suggest adding some text indicating that since VNFs operate in a data-center like environment, there are additional methods available for VNFs to store/checkpoint state; for example in Network Attached Storage (NAS), which may be made highly reliable via synchronous data replication. Suggest noting that there will be tradeoff between the checkpointing interval and the amount of state (or sessions) that could be lost in the event of a failure. Not sure if 4. VNF Pooling Architecture should be in the Problem statement - charter discussion item. Some of Section 5. Related Works seems like it belongs in an architecture/framework document since it talks about solutions to the problems. Some of the material on RSerPool and VRRP is relevant since there are problems that these do not solve. I also have a few minor suggestions/comments: Section 3.3 Problems, item 1, 2): "Software failure at various levels including hypervisor, Virtual Machine (VM), VNF instance." Suggest replacing "VNF instance" with "the proper actual functioning of the VNF" Section 3.3 Problems, item 5. Complication of VNFs placement: Suggest mentioning that affinity attributes (e.g., in OpenStack) could be also be used in addition to the cited IETF work to eliminate shared risk VNF placements. Thanks, Dave =20 From nobody Tue Mar 4 03:21:12 2014 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3101A06DF for ; Tue, 4 Mar 2014 03:21:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547, 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 0n2yT17mEmRO for ; Tue, 4 Mar 2014 03:21:09 -0800 (PST) Received: from fldsmtpe02.verizon.com (fldsmtpe02.verizon.com [140.108.26.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0B7F41A0499 for ; Tue, 4 Mar 2014 03:21:08 -0800 (PST) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143]) by fldsmtpe02.verizon.com with ESMTP; 04 Mar 2014 11:21:05 +0000 From: "Mcdysan, David E" X-IronPort-AV: E=Sophos;i="4.97,584,1389744000"; d="scan'208";a="685986334" Received: from fhdp1lumxc7hb02.verizon.com (HELO FHDP1LUMXC7HB02.us.one.verizon.com) ([166.68.59.189]) by fldsmtpi01.verizon.com with ESMTP; 04 Mar 2014 11:21:02 +0000 Received: from fhdp1lumxc7v11.us.one.verizon.com ([166.68.59.148]) by FHDP1LUMXC7HB02.us.one.verizon.com ([166.68.59.189]) with mapi; Tue, 4 Mar 2014 06:21:02 -0500 To: "vnfpool@ietf.org" Date: Tue, 4 Mar 2014 06:20:57 -0500 Thread-Topic: My Notes on the VNFPool BoF Charter related discussion Thread-Index: Ac83m9LB8UMVlieGS6KPtWO0Pw3JpQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/sk0TzK9k3DHExOiPPKdIQJyI3H0 Subject: [vnfpool] My Notes on the VNFPool BoF Charter related discussion 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, 04 Mar 2014 11:21:11 -0000 General Charter Comments: * Some (possibly much) of this work could apply to Pool Elements that are physical entities, software running on bare metal and not just ones running on a virtualization layer (i.e., hypervisor) as stated in the charter. * Suggest stating what are gaps with RserPool related to SFC separately from what are gaps specific to virtualization. See draft-dreibholz-vnfpool-rserpool-applic-00 and draft-dreibholz-rserpool-nextgen-ideas-01. Is it a potential charter item to move RserPool protocols (ASAP, ENRP) from Experimental to Standards track? * As Tom Narten and others stated, an SFC could be constructed that could handle reliability and resource management, or this could be done separately in a clustered mode not visible to SFC. Is the scope of this proposed work focused on the latter? Does the community view it as necessary? Relationship to SFC needs to be more clearly stated and agreed. Some problems stated in the use cases that are not in the current problem statement draft nor in the Draft Charter: * Need to define whether an "outage" includes insufficient resources and/or performance (e.g., duration of an outage, availability), as is done in NFV and would likely be oversubscribed. draft-king-vnfpool-mobile-use-case-00, draft-xia-vnfpool-use-cases-00, draft-hares-vnf-pool-use-case-01 and a "virtual load balancer" that has insufficient capacity as described by Andy Reid. Could these be work items to extend the policy framework of RserPool? e.g., the aranda (Telefonica) draft. * Some of the above drafts include scale in-out by removing-adding VMs (or combinations of them). Since VM resources are fungible (i.e., different VNFs (VNFCs) can be allocated a VM), it does appear to unique to virtualization. Suggest stating this more precisely in the charter. * Need to explicitly state what assumptions are made on network reachability/ connectivity for Pool Elements and whether this is out of scope. Are there gaps with existing network failure recovery mechanisms or is there a need for documentation of best practices in a virtualized environment (e.g., when a Network Interface Card has redundant ports)? * Avoidance of fate sharing is important for some physical Pool Elements (e.g., cards in the same chassis) and certainly for virtual ones (e.g., avoid running on the same compute server/blade, or pool manager vendors: see draft-hares-vnf-pool-use-case-01). Comments/Questions on Specific Draft Charter items stated in "quotes" below: "* Identification and evaluation of state sharing mechanisms between members of a VNF pool, including distributed shared memory, gossip protocols, pfsync, and state check pointing" Comment: Is there a standards setting activity? Is a requirements development and gap analysis against current approaches proposed? Is the ietf the right place to do this? Is the type of Network Attached Storage (NAS) as synchronously/asynchronously replicated or check pointed relevant? "* Exchange of reliability related information between a VNF set and VNF set users, and information between a VNF set and underlying network (e.g., interfacing with ALTO, I2RS)" Comment: Need better definition of "reliability related information" "* Identify and analyze reliable transport characteristics for the aforementioned control plane traffic of VNF pools" Comment: Need better definition of "aforementioned control plane traffic of VNF pools" since there is no mention of a control protocol before this statement. There is a mention of the SFC control protocol later in the Draft Charter -- is this what is meant? "* Analysis of transport security characteristics to provide protection against known threats, and identification of an appropriate trust model" Comment: Need to define the control protocols above to scope this charter item. Questions/Comments on Goals and Milestones: December 2014 - Submit VNFPool Problem Statement to IESG for publication as Informational April 2015 - Submit VNFPool Use Cases to IESG for publication as Informational Comment: How can problem statement be finalized before getting problems from specific user cases? August 2015 - Submit VNF Pooling Requirements and Architecture including the manageability of VNF pools to IESG for publication as Proposed Standard Question: How would this align with ETSI NFV architecture and reliability requirements? August 2015 - Submit Gap Analysis to IESG for publication as Informational From nobody Tue Mar 4 03:47:11 2014 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10DF41A0033 for ; Tue, 4 Mar 2014 03:47:09 -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 XEyi6tXCweE2 for ; Tue, 4 Mar 2014 03:47:07 -0800 (PST) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 8F8B81A0031 for ; Tue, 4 Mar 2014 03:47:07 -0800 (PST) Received: by mail-wg0-f52.google.com with SMTP id k14so2988067wgh.23 for ; Tue, 04 Mar 2014 03:47:04 -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 :content-type:content-transfer-encoding; bh=k69ir42QPEzaag01Bd2RoZfBz1NE8RrVSw/k9qHQqXY=; b=Un6+WNVvRQ0k4zvAYpZAXmUPyYV8uWe3udDOM2pIWzcNqT0e+K4885u650yiXGGD7c YpdBxm3GYXYbsBQ4ysOLjFBVIp+BHVA6YjrfrlODynHok+itMDAIGjRgcXoE/qgxzIt5 /QdJhxupC2soASyalP+Z7lNHALbwD2Lr/BD/DSiJfPNT3DsxSh2vglSyV7iY5NyfdB0q 0lyKsvGx/WJ4oY6KbRUfzBbV/H2nnYOwlcNMqgHzFGJaZwOY37rIrPeO3FfaIc4uGIuC 4ojmS9JEkde5COntHonKwTug2D9PJ3A8eKvNrL9j11Cs6zFPYWMfuYVqAvl2+qO6OE/e 0Xvw== X-Received: by 10.194.60.103 with SMTP id g7mr26902135wjr.37.1393933623905; Tue, 04 Mar 2014 03:47:03 -0800 (PST) Received: from ?IPv6:2001:67c:1232:152:3445:a9ee:1896:f382? ([2001:67c:1232:152:3445:a9ee:1896:f382]) by mx.google.com with ESMTPSA id h13sm51352570wjr.22.2014.03.04.03.47.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Mar 2014 03:47:03 -0800 (PST) Message-ID: <5315BD36.8020300@gmail.com> Date: Tue, 04 Mar 2014 11:47:02 +0000 From: Melinda Shore User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: vnfpool@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/7IPpRS1iqgZPMKQ8eO28wZnpTWw Subject: [vnfpool] BOF follow-up 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, 04 Mar 2014 11:47:09 -0000 Many thanks to everyone who participated in this morning's BOF. We'll be sending along complete minutes when those are available but in the meantime I took notes on some of the areas that have been identified as needing additional clarification in both the problem statement and the draft charter. These include: problem statement Clarify issues around why virtualized functions are distinct from physical ones <----- discuss degraded performance clarify what we mean by "transport" discuss transfer of security state make sure that problem statement and charter align Align use cases, consolidate commonalities Need a lexicon/terminology section tease apart issues related to pooling vs. service graph charter: failover performance may be issues with inter-pool coordination clarify what's meant by service availability being out of scope need to investigate whether or not we have state sharing expertise in those participating need to be clearer about the boundaries of the work business case and state synchronization application vs. pool state We'll be working on revisions of both and will get those sent out in the next few weeks. In the meantime, contributions of text are always (ALWAYS) welcome. Many thanks, Melinda From nobody Wed Mar 12 08:50:31 2014 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 298A71A095D for ; Wed, 12 Mar 2014 08:50:27 -0700 (PDT) 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 0vQ1a_HoYL0G for ; Wed, 12 Mar 2014 08:50:17 -0700 (PDT) Received: from sideburn.lancs.ac.uk (sideburn.lancs.ac.uk [148.88.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 258D61A09B9 for ; Wed, 12 Mar 2014 08:50:16 -0700 (PDT) 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 1WNlPz-0003Ij-Jk; Wed, 12 Mar 2014 15:50:07 +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.0174.001; Wed, 12 Mar 2014 15:50:07 +0000 From: "King, Daniel" To: "vnfpool@ietf.org" Thread-Topic: VNFPool BoF Minutes Thread-Index: Ac8+Ckp89QGGYom6Q4e9wO17cx/Nww== X-VoiceMessageDuration: 1 Date: Wed, 12 Mar 2014 15:50:06 +0000 Message-ID: <65174429B5AF4C45BD0798810EC48E0A11429D@EX-0-MB2.lancs.local> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [88.97.23.122] x-iss-local-domain: 1 Content-Type: multipart/mixed; boundary="_002_65174429B5AF4C45BD0798810EC48E0A11429DEX0MB2lancslocal_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/QfGrFYASHwsSg5vdCfEERen9pVs Cc: Melinda Shore , 'Zongning' Subject: [vnfpool] VNFPool BoF Minutes X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for virtual network function resource pooling." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 15:50:27 -0000 --_002_65174429B5AF4C45BD0798810EC48E0A11429DEX0MB2lancslocal_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All,=20 Please find the VNF Pool BoF Minutes below. If you have any clarifications = or updates please let me know.=20 Br, Dan.=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 VNFPool BoF Draft Agenda, IETF 89th, London. Viscount, Tuesday Morning Session I, 0900-1130 GMT, March 4, 2014. 09:00 Admin (Chairs, 5 minutes) No Agenda changes. 09:05 Introduction & Purpose of the BoF (Chairs, 5 minutes) 09:10 Problem Space (35 minutes) 1) Problem Statement (Melinda, 15 minutes) https://datatracker.ietf.org/doc/draft-zong-vnfpool-problem-stateme= nt/ Comments at microphone, discussion points and actions: - Clarification that the work should not overlap within IETF or=20 anywhere else.=20 - [Chairs]: VNF Pool effort is mostly concerned with solving unique=20 problems in IETF. - Request to see if any business discussion for reliability function=20 has been conducted. - [Chairs]: Effort concerned with reliability that has been identified=20 by service providers and customers highlighting their problems (in use=20 cases). - Suggested that performance monitoring should also be considered, in=20 context of performance degradation and VNF Pool switching.=20 Question: Why not Hardware devices? [Chairs]: VNF Pool is applicable to=20 hardware but for now the context is virtual network devices.=20 - Request to make sure charter reflects problem statement, and vice=20 versa. - Security of state sharing is a concern. The security section of the=20 problem statement, but you do not look at security state. Bob suggested=20 that security between VNFs, when state sharing, should also be=20 considered. [Bob Moskowitz] - Maybe some requirements from the Fixed Mobile Convergence (FMC) work. - Request to look at existing IETF protocols for configuration of=20 devices and DNS (OPS-NM AD: Benoit Claise).=20 Action: Synch Problem Statement with Charter text Action: Coordination with SFC to agree on scope and perceived overlap=20 would be helpful. Action: Security must be investigated for security of solution, and=20 security of state passing in the VNF Pool.=20 Action: Clarify business case(s) in summary of use cases. =20 2) Q & A (all, 20 m minutes) 09:50 Use Cases (50 minutes) 1) Generic Use Case (Michiaki, 5 minutes) https://datatracker.ietf.org/doc/draft-xia-vnfpool-use-cases/ 2) vEPC Use Case (Marco, 10 minutes) https://datatracker.ietf.org/doc/draft-king-vnfpool-mobile-use- case/ Comments at microphone, discussion points and actions: - Software/Virtualization resilience is a reasonable requirement.=20 - Some participants felt that it was unclear if we are discussing a VM=20 Pool or VNF Pool. The Chairs clarified that this was not VM pooling.=20 - [Kireeti Kompella]: Is it then groups of virtual functions and=20 multiple pools?=20 - Suggestion that the work should deal with hardware and not just=20 virtualised Network Functions (vNF).=20 - Observation that SFC charter does not mention virtualisation.=20 - A number of factors exist in vEPC that may be unique for providing=20 reliance in a virtualised environment. =20 - State management may be required, but in some cases it may be=20 acceptable to simply recover.=20 - Consideration of the role of VNF Pool Manager. - A need to mindful of not over reaching on requirements, is=20 synchronization of state feasible and is it reasonable to expect state=20 sharing between vendor implementations. =20 - Dave Dysan: The recovery of virtual components is beneficial. The=20 VNF can be a connected set of VMs. You can utilize a set of work from=20 the Reliable Server pooling (RSerPool) - Thomas Nordmark: The link between virtual network functions and the=20 synchronized pool is not clear in this presentation, and it seems to be=20 different from the previous definition of pools and pool manager.=20 - Daniel King: The uses were developed in isolation, and additional=20 synchronization of terminology needs to occur.=20 =20 Action: Synch terminology across VNF Pool I-Ds, including Use Case=20 documents. Action: Continue to develop Use Case I-Ds to help identify if State=20 Synchronization is a reasonable requirement, and what is the scope of=20 the required state synchronization.=20 =20 3) Load Balancing (Andy, 5 minutes) Comments at microphone, discussion points and actions: - Suggestion that if SFC is correctly implemented then this [the load=20 balancing scaling issue] should not be applicable. (Eric Nordmark and=20 Jim Beecher)=20 - Service graph and pooling are separate things, how the virtual=20 network function is pooled should be abstracted away from SFC. (Kireeti=20 Kompella)=20 - Assertion that SFC can provide the required solution.=20 - State Sharing interacts with the service graph. Where these=20 functions touch, it will be important to keep the functions separate in=20 the interaction. [Erik Nordmark] - Request to help clarify this [load balancing] problem to help with WG=20 assignment (VNF Pool, SFC, or other). - VNF Pool is building on ETSI NFV architecture and does not describe=20 the internal architecture of a VNF. - SFC is a special case of service graph and is not addressing what we=20 [VNF Pool] is investigating. - Request to look at the scaling of the solutions (Thomas Narten) - Constantine: The Unify European project is investigating functions=20 like the VNF Pool.=20 Action: Describe and document requirements for the load balancing=20 scenario in a use case I-D. Action: Investigate comment that SFC can provide the required solution=20 for load balancing described in the presentation. =20 Action: If the SFC + VNF Pool are required to solve the load balancing=20 problem, determine where the points of interaction with SFC are and=20 develop clean interfaces so that SFC and VNF Pool remain separate=20 entities.=20 Action: Look at scaling of VNF Solution.=20 3) vCDN Use Case (Pedro, 10 minutes) https://datatracker.ietf.org/doc/draft-aranda-vnfpool-cdn-use-case/ Comments at microphone, discussion points and actions: - Echo from other operator that CDN is a useful use case for operators.=20 - Important to note that policy applies to resource management. A gap=20 analysis and I-D might also be needed.=20 Action: Investigate resilience resource policy requirements.=20 4) Resource Pool Use Case (Sue, 10 minutes) https://datatracker.ietf.org/doc/draft-hares-vnf-pool-use-case/ - Suggestion that a recent paper submitted to the SDN RG list might=20 help highlight existing/new requirements.=20 5) Q & A (all, 10 minutes) 10:35 Related Works (15 minutes) 1) RSerPool Applicability (Thomas, 10 minutes) https://datatracker.ietf.org/doc/draft-dreibholz-vnfpool-rserpool-a= pplic/ Comments at microphone, discussion points and actions: - Suggestion that the RSerPool work should have been presented first=20 (Dave Dysan)=20 - If used, the RSerPool work is Experimental (Status) so would have to=20 be published as Standards Track.=20 - RSerPool work was shutdown years ago, but it represents an=20 opportunity to restart and develop as needed. - [NTT person): Would there be multiple network functions operating as=20 VNF Pools?=20 - Suggestion that SCTP is used but MSCTP might be an alternative=20 (Randall Stewart, Jabber)=20 - Are the assumptions previous used in the development of RSerPool=20 still valid?=20 - System architecture should have inherent redundancy, the [RSerPool=20 authors] should analyse the impact of RSerPool.=20 - A number of future research is documented in RSerPool Next Generation=20 I-D. - RSerPool will require 64 bit capability. 10:50 Charter Discussion (30 minutes) =20 1) Charter (Chairs, 5 minutes) http://www.ietf.org/mail- archive/web/vnfpool/current/msg00224.html =20 Comments at microphone, discussion points and actions: - Some discussion already on scope of protection for both internal and=20 external functions. Some discussion on time dimension in the scope of=20 protection. Also the protection may also be participating in a larger=20 protection scheme. - What is the server application that is being examined? Does it need=20 reliability of pools?=20 - [Jamal Salim]: The VNF pool application is describing high=20 availability that MPLS and GMPLS utilize. ForCES has High availability=20 based on Forces running over a control. Based on the ForCES experience,=20 it is important to know are these functions highly available or not?=20 - [unknown]: Do we have flow stitching? =20 - Not total agreement that work should be independent of SFC.=20 - Current fate sharing, load balancing, pool function are not fit for=20 purpose. These are problems that need to be worked on.=20 - UNIFY is a European Research project investigating the problem space,=20 some shared findings/discussion may be beneficial. =20 - It would be valuable to coordinate within a VNFPool. If you extend it=20 to inter-pools, it becomes "orchestration". - Observation that a pool of NFs, in a virtual FW you have higher=20 failure rate.=20 - Hardwire based solutions have built in redundancy, network function=20 resiliency, and the drafts (problem or use cases) do not state how to=20 use this. - Scepticism that flow forwarding state synchronisation can be=20 achieved. Also do operators really require this capability?=20 - Question: What is in-scope versus out-of-scope? Do we handle service=20 state recovery? =20 - The service state recovery is beyond the scope of SFC. - [Jim Beecher] Service availability is not in scope.=20 - [Eric Nordmark}: Are there people that can help us with fate sharing=20 within the NFV Pool functions?=20 - [George (from Greece)]: In the virtual clusters fate sharing, load=20 balancing and pool functions are not yet working. =20 - Linda Dunbar: What happens if one instance fails which is not a=20 routing instance?=20 - Thomas Narten: Sceptical whether IETF has the expertise to examine=20 the state synchronization issue. IETF does not have large amounts of=20 firewall vendors.=20 - [Sue Hares]: Today's access devices all contain first level=20 firewalls so all access devices have now installed firewalls. The more=20 common firewall is this firewall within the access device.=20 Action: We need a common understanding between VNF POOL and SFC as to=20 scope of work.=20 Action: Determine scope of protection for internal and external=20 functions.=20 Action: Consider what applications (or class of applications) might=20 utilize VNF Pool.=20 Action: Clarify the architecture aspect of VNFPOOL, what is in scope,=20 and what is out of scope. =20 Action: Definition of a VNF, is there a VNF, SFC VNF and ETSI VNF? Where=20 is overlap, can we agree definitions.=20 Action: Operators need to discuss if FW state synchronisation, or indeed=20 other NF state synchronisation, is actually required.=20 Action: Examine how the need for high availability impacts the VNF Pool=20 design and=20 Action: Examine failures scenarios if one instance fails.=20 Action: Examine existing solutions to determine if some existing IETF=20 protocol or design fits most of the parameters. This is the concept of=20 re-use rather than reinvent due to NIH (not-invented here).=20 2) Open Discussion (all, 25 minutes) =20 11:20 Wrap-up (Chairs, 10 minutes) 11:30 End --_002_65174429B5AF4C45BD0798810EC48E0A11429DEX0MB2lancslocal_ Content-Type: text/plain; name="VNF Pool Minutes.txt" Content-Description: VNF Pool Minutes.txt Content-Disposition: attachment; filename="VNF Pool Minutes.txt"; size=11284; creation-date="Wed, 12 Mar 2014 15:37:52 GMT"; modification-date="Wed, 12 Mar 2014 15:49:04 GMT" Content-Transfer-Encoding: base64 Vk5GUG9vbCBCb0YgRHJhZnQgQWdlbmRhLCBJRVRGIDg5dGgsIExvbmRvbi4NClZpc2NvdW50LCBU dWVzZGF5IE1vcm5pbmcgU2Vzc2lvbiBJLCAwOTAwLTExMzAgR01ULCBNYXJjaCA0LCAyMDE0Lg0K DQowOTowMCBBZG1pbiAoQ2hhaXJzLCA1IG1pbnV0ZXMpDQpObyBBZ2VuZGEgY2hhbmdlcy4NCg0K MDk6MDUgSW50cm9kdWN0aW9uICYgUHVycG9zZSBvZiB0aGUgQm9GIChDaGFpcnMsIDUgbWludXRl cykNCg0KMDk6MTAgUHJvYmxlbSBTcGFjZSAoMzUgbWludXRlcykNCiAgICAgICAgMSkgUHJvYmxl bSBTdGF0ZW1lbnQgKE1lbGluZGEsIDE1IG1pbnV0ZXMpDQogICAgICAgDQpodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC16b25nLXZuZnBvb2wtcHJvYmxlbS1zdGF0ZW1lbnQv DQoNCkNvbW1lbnRzIGF0IG1pY3JvcGhvbmUsIGRpc2N1c3Npb24gcG9pbnRzIGFuZCBhY3Rpb25z Og0KDQotIENsYXJpZmljYXRpb24gdGhhdCB0aGUgd29yayBzaG91bGQgbm90IG92ZXJsYXAgd2l0 aGluIElFVEYgb3IgDQphbnl3aGVyZSBlbHNlLiANCg0KLSBbQ2hhaXJzXTogVk5GIFBvb2wgZWZm b3J0IGlzIG1vc3RseSBjb25jZXJuZWQgd2l0aCBzb2x2aW5nIHVuaXF1ZSANCnByb2JsZW1zIGlu IElFVEYuDQoNCi0gUmVxdWVzdCB0byBzZWUgaWYgYW55IGJ1c2luZXNzIGRpc2N1c3Npb24gZm9y IHJlbGlhYmlsaXR5IGZ1bmN0aW9uIA0KaGFzIGJlZW4gY29uZHVjdGVkLg0KDQotIFtDaGFpcnNd OiBFZmZvcnQgY29uY2VybmVkIHdpdGggcmVsaWFiaWxpdHkgdGhhdCBoYXMgYmVlbiBpZGVudGlm aWVkIA0KYnkgc2VydmljZSBwcm92aWRlcnMgYW5kIGN1c3RvbWVycyBoaWdobGlnaHRpbmcgdGhl aXIgcHJvYmxlbXMgKGluIHVzZSANCmNhc2VzKS4NCg0KLSBTdWdnZXN0ZWQgdGhhdCBwZXJmb3Jt YW5jZSBtb25pdG9yaW5nIHNob3VsZCBhbHNvIGJlIGNvbnNpZGVyZWQsIGluIA0KY29udGV4dCBv ZiBwZXJmb3JtYW5jZSBkZWdyYWRhdGlvbiBhbmQgVk5GIFBvb2wgc3dpdGNoaW5nLiANCg0KUXVl c3Rpb246IFdoeSBub3QgSGFyZHdhcmUgZGV2aWNlcz8gIFtDaGFpcnNdOiBWTkYgUG9vbCBpcyBh cHBsaWNhYmxlIHRvIA0KaGFyZHdhcmUgYnV0IGZvciBub3cgdGhlIGNvbnRleHQgaXMgdmlydHVh bCBuZXR3b3JrIGRldmljZXMuIA0KDQotIFJlcXVlc3QgdG8gbWFrZSBzdXJlIGNoYXJ0ZXIgcmVm bGVjdHMgcHJvYmxlbSBzdGF0ZW1lbnQsIGFuZCB2aWNlIA0KdmVyc2EuDQoNCi0gU2VjdXJpdHkg b2Ygc3RhdGUgc2hhcmluZyBpcyBhIGNvbmNlcm4uICBUaGUgc2VjdXJpdHkgc2VjdGlvbiBvZiB0 aGUgDQpwcm9ibGVtIHN0YXRlbWVudCwgYnV0IHlvdSBkbyBub3QgbG9vayBhdCBzZWN1cml0eSBz dGF0ZS4gQm9iIHN1Z2dlc3RlZCANCnRoYXQgc2VjdXJpdHkgYmV0d2VlbiBWTkZzLCB3aGVuIHN0 YXRlIHNoYXJpbmcsIHNob3VsZCBhbHNvIGJlIA0KY29uc2lkZXJlZC4gW0JvYiBNb3Nrb3dpdHpd DQoNCi0gTWF5YmUgc29tZSByZXF1aXJlbWVudHMgZnJvbSB0aGUgRml4ZWQgTW9iaWxlIENvbnZl cmdlbmNlIChGTUMpIHdvcmsuDQoNCi0gUmVxdWVzdCB0byBsb29rIGF0IGV4aXN0aW5nIElFVEYg cHJvdG9jb2xzIGZvciBjb25maWd1cmF0aW9uIG9mIA0KZGV2aWNlcyBhbmQgRE5TIChPUFMtTk0g QUQ6IEJlbm9pdCBDbGFpc2UpLiANCg0KQWN0aW9uOiBTeW5jaCBQcm9ibGVtIFN0YXRlbWVudCB3 aXRoIENoYXJ0ZXIgdGV4dA0KDQpBY3Rpb246IENvb3JkaW5hdGlvbiB3aXRoIFNGQyB0byBhZ3Jl ZSBvbiBzY29wZSBhbmQgcGVyY2VpdmVkIG92ZXJsYXAgDQp3b3VsZCBiZSBoZWxwZnVsLg0KDQpB Y3Rpb246IFNlY3VyaXR5IG11c3QgYmUgaW52ZXN0aWdhdGVkIGZvciBzZWN1cml0eSBvZiBzb2x1 dGlvbiwgYW5kIA0Kc2VjdXJpdHkgb2Ygc3RhdGUgcGFzc2luZyBpbiB0aGUgVk5GIFBvb2wuIA0K DQpBY3Rpb246IENsYXJpZnkgYnVzaW5lc3MgY2FzZShzKSBpbiBzdW1tYXJ5IG9mIHVzZSBjYXNl cy4gIA0KDQogICAgICAgIDIpIFEgJiBBIChhbGwsIDIwIG0gbWludXRlcykNCg0KMDk6NTAgVXNl IENhc2VzICg1MCBtaW51dGVzKQ0KDQogICAgICAgIDEpIEdlbmVyaWMgVXNlIENhc2UgKE1pY2hp YWtpLCA1IG1pbnV0ZXMpDQogICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LXhpYS12bmZwb29sLXVzZS1jYXNlcy8NCg0KICAgICAgICAyKSB2RVBDIFVzZSBDYXNl IChNYXJjbywgMTAgbWludXRlcykNCiAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQta2luZy12bmZwb29sLW1vYmlsZS11c2UtDQogICAgICAgIGNhc2UvDQoNCkNv bW1lbnRzIGF0IG1pY3JvcGhvbmUsIGRpc2N1c3Npb24gcG9pbnRzIGFuZCBhY3Rpb25zOg0KDQot IFNvZnR3YXJlL1ZpcnR1YWxpemF0aW9uIHJlc2lsaWVuY2UgaXMgYSByZWFzb25hYmxlIHJlcXVp cmVtZW50LiANCg0KLSBTb21lIHBhcnRpY2lwYW50cyBmZWx0IHRoYXQgaXQgd2FzIHVuY2xlYXIg aWYgd2UgYXJlIGRpc2N1c3NpbmcgYSBWTSANClBvb2wgb3IgVk5GIFBvb2wuIFRoZSBDaGFpcnMg Y2xhcmlmaWVkIHRoYXQgdGhpcyB3YXMgbm90IFZNIHBvb2xpbmcuIA0KDQotIFtLaXJlZXRpIEtv bXBlbGxhXTogSXMgaXQgdGhlbiBncm91cHMgb2YgdmlydHVhbCBmdW5jdGlvbnMgYW5kIA0KbXVs dGlwbGUgcG9vbHM/IA0KDQotIFN1Z2dlc3Rpb24gdGhhdCB0aGUgd29yayBzaG91bGQgZGVhbCB3 aXRoIGhhcmR3YXJlIGFuZCBub3QganVzdCANCnZpcnR1YWxpc2VkIE5ldHdvcmsgRnVuY3Rpb25z ICh2TkYpLiANCg0KLSBPYnNlcnZhdGlvbiB0aGF0IFNGQyBjaGFydGVyIGRvZXMgbm90IG1lbnRp b24gdmlydHVhbGlzYXRpb24uIA0KDQotIEEgbnVtYmVyIG9mIGZhY3RvcnMgZXhpc3QgaW4gdkVQ QyB0aGF0IG1heSBiZSB1bmlxdWUgZm9yIHByb3ZpZGluZyANCnJlbGlhbmNlIGluIGEgdmlydHVh bGlzZWQgZW52aXJvbm1lbnQuICANCg0KLSBTdGF0ZSBtYW5hZ2VtZW50IG1heSBiZSByZXF1aXJl ZCwgYnV0IGluIHNvbWUgY2FzZXMgaXQgbWF5IGJlIA0KYWNjZXB0YWJsZSB0byBzaW1wbHkgcmVj b3Zlci4gDQoNCi0gQ29uc2lkZXJhdGlvbiBvZiB0aGUgcm9sZSBvZiBWTkYgUG9vbCBNYW5hZ2Vy Lg0KDQotIEEgbmVlZCB0byBtaW5kZnVsIG9mIG5vdCBvdmVyIHJlYWNoaW5nIG9uIHJlcXVpcmVt ZW50cywgaXMgDQpzeW5jaHJvbml6YXRpb24gb2Ygc3RhdGUgZmVhc2libGUgYW5kIGlzIGl0IHJl YXNvbmFibGUgdG8gZXhwZWN0IHN0YXRlIA0Kc2hhcmluZyBiZXR3ZWVuIHZlbmRvciBpbXBsZW1l bnRhdGlvbnMuICANCg0KLSBEYXZlIER5c2FuOiAgVGhlIHJlY292ZXJ5IG9mIHZpcnR1YWwgY29t cG9uZW50cyBpcyBiZW5lZmljaWFsLiAgVGhlIA0KVk5GIGNhbiBiZSBhIGNvbm5lY3RlZCBzZXQg b2YgVk1zLiBZb3UgY2FuIHV0aWxpemUgYSBzZXQgb2Ygd29yayBmcm9tIA0KdGhlIFJlbGlhYmxl IFNlcnZlciBwb29saW5nIChSU2VyUG9vbCkNCg0KLSBUaG9tYXMgTm9yZG1hcms6IFRoZSBsaW5r IGJldHdlZW4gdmlydHVhbCBuZXR3b3JrIGZ1bmN0aW9ucyBhbmQgdGhlIA0Kc3luY2hyb25pemVk IHBvb2wgaXMgbm90IGNsZWFyIGluIHRoaXMgcHJlc2VudGF0aW9uLCBhbmQgaXQgc2VlbXMgdG8g YmUgDQpkaWZmZXJlbnQgZnJvbSB0aGUgcHJldmlvdXMgZGVmaW5pdGlvbiBvZiBwb29scyBhbmQg cG9vbCBtYW5hZ2VyLiANCg0KLSBEYW5pZWwgS2luZzogVGhlIHVzZXMgd2VyZSBkZXZlbG9wZWQg aW4gaXNvbGF0aW9uLCBhbmQgYWRkaXRpb25hbCANCnN5bmNocm9uaXphdGlvbiBvZiB0ZXJtaW5v bG9neSBuZWVkcyB0byBvY2N1ci4gDQogDQpBY3Rpb246IFN5bmNoIHRlcm1pbm9sb2d5IGFjcm9z cyBWTkYgUG9vbCBJLURzLCBpbmNsdWRpbmcgVXNlIENhc2UgDQpkb2N1bWVudHMuDQoNCkFjdGlv bjogQ29udGludWUgdG8gZGV2ZWxvcCBVc2UgQ2FzZSBJLURzIHRvIGhlbHAgaWRlbnRpZnkgaWYg U3RhdGUgDQpTeW5jaHJvbml6YXRpb24gaXMgYSByZWFzb25hYmxlIHJlcXVpcmVtZW50LCBhbmQg d2hhdCBpcyB0aGUgc2NvcGUgb2YgDQp0aGUgcmVxdWlyZWQgc3RhdGUgc3luY2hyb25pemF0aW9u LiANCiAgICAgICAgDQogICAgICAgIDMpIExvYWQgQmFsYW5jaW5nIChBbmR5LCA1IG1pbnV0ZXMp DQoNCkNvbW1lbnRzIGF0IG1pY3JvcGhvbmUsIGRpc2N1c3Npb24gcG9pbnRzIGFuZCBhY3Rpb25z Og0KDQotIFN1Z2dlc3Rpb24gdGhhdCBpZiBTRkMgaXMgY29ycmVjdGx5IGltcGxlbWVudGVkIHRo ZW4gdGhpcyBbdGhlIGxvYWQgDQpiYWxhbmNpbmcgc2NhbGluZyBpc3N1ZV0gc2hvdWxkIG5vdCBi ZSBhcHBsaWNhYmxlLiAgICAoRXJpYyBOb3JkbWFyayBhbmQgDQpKaW0gQmVlY2hlcikgDQoNCi0g U2VydmljZSBncmFwaCBhbmQgcG9vbGluZyBhcmUgc2VwYXJhdGUgdGhpbmdzLCBob3cgdGhlIHZp cnR1YWwgDQpuZXR3b3JrIGZ1bmN0aW9uIGlzIHBvb2xlZCBzaG91bGQgYmUgYWJzdHJhY3RlZCBh d2F5IGZyb20gU0ZDLiAgKEtpcmVldGkgDQpLb21wZWxsYSkgDQoNCi0gQXNzZXJ0aW9uIHRoYXQg U0ZDIGNhbiBwcm92aWRlIHRoZSByZXF1aXJlZCBzb2x1dGlvbi4gDQoNCi0gU3RhdGUgU2hhcmlu ZyBpbnRlcmFjdHMgd2l0aCB0aGUgc2VydmljZSBncmFwaC4gIFdoZXJlIHRoZXNlIA0KZnVuY3Rp b25zIHRvdWNoLCBpdCB3aWxsIGJlIGltcG9ydGFudCB0byBrZWVwIHRoZSBmdW5jdGlvbnMgc2Vw YXJhdGUgaW4gDQp0aGUgaW50ZXJhY3Rpb24uICBbRXJpayBOb3JkbWFya10NCg0KLSBSZXF1ZXN0 IHRvIGhlbHAgY2xhcmlmeSB0aGlzIFtsb2FkIGJhbGFuY2luZ10gcHJvYmxlbSB0byBoZWxwIHdp dGggV0cgDQphc3NpZ25tZW50IChWTkYgUG9vbCwgU0ZDLCBvciBvdGhlcikuDQoNCi0gVk5GIFBv b2wgaXMgYnVpbGRpbmcgb24gRVRTSSBORlYgYXJjaGl0ZWN0dXJlIGFuZCBkb2VzIG5vdCBkZXNj cmliZSANCnRoZSBpbnRlcm5hbCBhcmNoaXRlY3R1cmUgb2YgYSBWTkYuDQoNCi0gU0ZDIGlzIGEg c3BlY2lhbCBjYXNlIG9mIHNlcnZpY2UgZ3JhcGggYW5kIGlzIG5vdCBhZGRyZXNzaW5nIHdoYXQg d2UgDQpbVk5GIFBvb2xdIGlzIGludmVzdGlnYXRpbmcuDQoNCi0gUmVxdWVzdCB0byBsb29rIGF0 IHRoZSBzY2FsaW5nIG9mIHRoZSBzb2x1dGlvbnMgKFRob21hcyBOYXJ0ZW4pDQoNCi0gQ29uc3Rh bnRpbmU6IFRoZSBVbmlmeSBFdXJvcGVhbiBwcm9qZWN0IGlzIGludmVzdGlnYXRpbmcgZnVuY3Rp b25zIA0KbGlrZSB0aGUgVk5GIFBvb2wuIA0KDQpBY3Rpb246IERlc2NyaWJlIGFuZCBkb2N1bWVu dCByZXF1aXJlbWVudHMgZm9yIHRoZSBsb2FkIGJhbGFuY2luZyANCnNjZW5hcmlvIGluIGEgdXNl IGNhc2UgSS1ELg0KDQpBY3Rpb246IEludmVzdGlnYXRlIGNvbW1lbnQgdGhhdCBTRkMgY2FuIHBy b3ZpZGUgdGhlIHJlcXVpcmVkIHNvbHV0aW9uIA0KZm9yIGxvYWQgYmFsYW5jaW5nIGRlc2NyaWJl ZCBpbiB0aGUgcHJlc2VudGF0aW9uLiAgIA0KDQpBY3Rpb246IElmIHRoZSBTRkMgKyBWTkYgUG9v bCBhcmUgcmVxdWlyZWQgdG8gc29sdmUgdGhlIGxvYWQgYmFsYW5jaW5nIA0KcHJvYmxlbSwgZGV0 ZXJtaW5lIHdoZXJlIHRoZSBwb2ludHMgb2YgaW50ZXJhY3Rpb24gd2l0aCBTRkMgYXJlIGFuZCAN CmRldmVsb3AgY2xlYW4gaW50ZXJmYWNlcyBzbyB0aGF0IFNGQyBhbmQgVk5GIFBvb2wgcmVtYWlu IHNlcGFyYXRlIA0KZW50aXRpZXMuIA0KDQpBY3Rpb246IExvb2sgYXQgc2NhbGluZyBvZiBWTkYg U29sdXRpb24uIA0KDQogICAgICAgIDMpIHZDRE4gVXNlIENhc2UgKFBlZHJvLCAxMCBtaW51dGVz KQ0KICAgICAgIA0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYXJhbmRh LXZuZnBvb2wtY2RuLXVzZS1jYXNlLw0KDQpDb21tZW50cyBhdCBtaWNyb3Bob25lLCBkaXNjdXNz aW9uIHBvaW50cyBhbmQgYWN0aW9uczoNCg0KLSBFY2hvIGZyb20gb3RoZXIgb3BlcmF0b3IgdGhh dCBDRE4gaXMgYSB1c2VmdWwgdXNlIGNhc2UgZm9yIG9wZXJhdG9ycy4gDQoNCi0gSW1wb3J0YW50 IHRvIG5vdGUgdGhhdCBwb2xpY3kgYXBwbGllcyB0byByZXNvdXJjZSBtYW5hZ2VtZW50LiBBIGdh cCANCmFuYWx5c2lzIGFuZCBJLUQgbWlnaHQgYWxzbyBiZSBuZWVkZWQuIA0KDQpBY3Rpb246IElu dmVzdGlnYXRlIHJlc2lsaWVuY2UgcmVzb3VyY2UgcG9saWN5IHJlcXVpcmVtZW50cy4gDQoNCiAg ICAgICAgNCkgUmVzb3VyY2UgUG9vbCBVc2UgQ2FzZSAoU3VlLCAxMCBtaW51dGVzKQ0KICAgICAg ICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1oYXJlcy12bmYtcG9vbC11 c2UtY2FzZS8NCg0KLSBTdWdnZXN0aW9uIHRoYXQgYSByZWNlbnQgcGFwZXIgc3VibWl0dGVkIHRv IHRoZSBTRE4gUkcgbGlzdCBtaWdodCANCmhlbHAgaGlnaGxpZ2h0IGV4aXN0aW5nL25ldyByZXF1 aXJlbWVudHMuIA0KICAgICAgICA1KSBRICYgQSAoYWxsLCAxMCBtaW51dGVzKQ0KDQoxMDozNSBS ZWxhdGVkIFdvcmtzICgxNSBtaW51dGVzKQ0KICAgICAgICAxKSBSU2VyUG9vbCBBcHBsaWNhYmls aXR5IChUaG9tYXMsIDEwIG1pbnV0ZXMpDQogICAgICAgDQpodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1kcmVpYmhvbHotdm5mcG9vbC1yc2VycG9vbC1hcHBsaWMNCi8NCg0K Q29tbWVudHMgYXQgbWljcm9waG9uZSwgZGlzY3Vzc2lvbiBwb2ludHMgYW5kIGFjdGlvbnM6DQoN Ci0gU3VnZ2VzdGlvbiB0aGF0IHRoZSBSU2VyUG9vbCB3b3JrIHNob3VsZCBoYXZlIGJlZW4gcHJl c2VudGVkIGZpcnN0IA0KKERhdmUgRHlzYW4pIA0KDQotIElmIHVzZWQsIHRoZSBSU2VyUG9vbCB3 b3JrIGlzIEV4cGVyaW1lbnRhbCAoU3RhdHVzKSBzbyB3b3VsZCBoYXZlIHRvIA0KYmUgcHVibGlz aGVkIGFzIFN0YW5kYXJkcyBUcmFjay4gDQoNCi0gUlNlclBvb2wgd29yayB3YXMgc2h1dGRvd24g eWVhcnMgYWdvLCBidXQgaXQgcmVwcmVzZW50cyBhbiANCm9wcG9ydHVuaXR5IHRvIHJlc3RhcnQg YW5kIGRldmVsb3AgYXMgbmVlZGVkLg0KDQotIFtOVFQgcGVyc29uKTogV291bGQgdGhlcmUgYmUg bXVsdGlwbGUgbmV0d29yayBmdW5jdGlvbnMgb3BlcmF0aW5nIGFzIA0KVk5GIFBvb2xzPyANCg0K LSBTdWdnZXN0aW9uIHRoYXQgU0NUUCBpcyB1c2VkIGJ1dCBNU0NUUCBtaWdodCBiZSBhbiBhbHRl cm5hdGl2ZSANCihSYW5kYWxsIFN0ZXdhcnQsIEphYmJlcikgDQoNCi0gQXJlIHRoZSBhc3N1bXB0 aW9ucyBwcmV2aW91cyB1c2VkIGluIHRoZSBkZXZlbG9wbWVudCBvZiBSU2VyUG9vbCANCnN0aWxs IHZhbGlkPyANCg0KLSBTeXN0ZW0gYXJjaGl0ZWN0dXJlIHNob3VsZCBoYXZlIGluaGVyZW50IHJl ZHVuZGFuY3ksIHRoZSBbUlNlclBvb2wgDQphdXRob3JzXSBzaG91bGQgYW5hbHlzZSB0aGUgaW1w YWN0IG9mIFJTZXJQb29sLiANCg0KLSBBIG51bWJlciBvZiBmdXR1cmUgcmVzZWFyY2ggaXMgZG9j dW1lbnRlZCBpbiBSU2VyUG9vbCBOZXh0IEdlbmVyYXRpb24gDQpJLUQuDQoNCi0gUlNlclBvb2wg d2lsbCByZXF1aXJlIDY0IGJpdCBjYXBhYmlsaXR5Lg0KDQoxMDo1MCBDaGFydGVyIERpc2N1c3Np b24gKDMwIG1pbnV0ZXMpDQogICAgICAgIA0KICAgICAgICAxKSBDaGFydGVyIChDaGFpcnMsIDUg bWludXRlcykNCiAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLQ0KICAgICAgICBhcmNo aXZlL3dlYi92bmZwb29sL2N1cnJlbnQvbXNnMDAyMjQuaHRtbA0KICAgICAgICANCkNvbW1lbnRz IGF0IG1pY3JvcGhvbmUsIGRpc2N1c3Npb24gcG9pbnRzIGFuZCBhY3Rpb25zOg0KDQotIFNvbWUg ZGlzY3Vzc2lvbiBhbHJlYWR5IG9uIHNjb3BlIG9mIHByb3RlY3Rpb24gZm9yIGJvdGggaW50ZXJu YWwgYW5kIA0KZXh0ZXJuYWwgZnVuY3Rpb25zLiAgU29tZSBkaXNjdXNzaW9uIG9uIHRpbWUgZGlt ZW5zaW9uIGluIHRoZSBzY29wZSBvZiANCnByb3RlY3Rpb24uICBBbHNvIHRoZSBwcm90ZWN0aW9u IG1heSBhbHNvIGJlIHBhcnRpY2lwYXRpbmcgaW4gYSBsYXJnZXIgDQpwcm90ZWN0aW9uIHNjaGVt ZS4NCg0KLSBXaGF0IGlzIHRoZSBzZXJ2ZXIgYXBwbGljYXRpb24gdGhhdCBpcyBiZWluZyBleGFt aW5lZD8gIERvZXMgaXQgbmVlZCANCnJlbGlhYmlsaXR5IG9mIHBvb2xzPyANCg0KLSBbSmFtYWwg U2FsaW1dOiBUaGUgVk5GIHBvb2wgYXBwbGljYXRpb24gaXMgZGVzY3JpYmluZyBoaWdoIA0KYXZh aWxhYmlsaXR5IHRoYXQgTVBMUyBhbmQgR01QTFMgdXRpbGl6ZS4gIEZvckNFUyBoYXMgSGlnaCBh dmFpbGFiaWxpdHkgDQpiYXNlZCBvbiBGb3JjZXMgcnVubmluZyBvdmVyIGEgY29udHJvbC4gIEJh c2VkIG9uIHRoZSBGb3JDRVMgZXhwZXJpZW5jZSwgDQppdCBpcyBpbXBvcnRhbnQgdG8ga25vdyBh cmUgdGhlc2UgZnVuY3Rpb25zIGhpZ2hseSBhdmFpbGFibGUgb3Igbm90PyANCg0KLSBbdW5rbm93 bl06IERvIHdlIGhhdmUgZmxvdyBzdGl0Y2hpbmc/ICANCg0KLSBOb3QgdG90YWwgYWdyZWVtZW50 IHRoYXQgd29yayBzaG91bGQgYmUgaW5kZXBlbmRlbnQgb2YgU0ZDLiANCg0KLSBDdXJyZW50IGZh dGUgc2hhcmluZywgbG9hZCBiYWxhbmNpbmcsIHBvb2wgZnVuY3Rpb24gYXJlIG5vdCBmaXQgZm9y IA0KcHVycG9zZS4gIFRoZXNlIGFyZSBwcm9ibGVtcyB0aGF0IG5lZWQgdG8gYmUgd29ya2VkIG9u LiANCg0KLSBVTklGWSBpcyBhIEV1cm9wZWFuIFJlc2VhcmNoIHByb2plY3QgaW52ZXN0aWdhdGlu ZyB0aGUgcHJvYmxlbSBzcGFjZSwgDQpzb21lIHNoYXJlZCBmaW5kaW5ncy9kaXNjdXNzaW9uIG1h eSBiZSBiZW5lZmljaWFsLiAgDQoNCi0gSXQgd291bGQgYmUgdmFsdWFibGUgdG8gY29vcmRpbmF0 ZSB3aXRoaW4gYSBWTkZQb29sLiBJZiB5b3UgZXh0ZW5kIGl0IA0KdG8gaW50ZXItcG9vbHMsIGl0 IGJlY29tZXMgk29yY2hlc3RyYXRpb26ULg0KDQotIE9ic2VydmF0aW9uIHRoYXQgYSBwb29sIG9m IE5GcywgaW4gYSB2aXJ0dWFsIEZXIHlvdSBoYXZlIGhpZ2hlciANCmZhaWx1cmUgcmF0ZS4gDQoN Ci0gSGFyZHdpcmUgYmFzZWQgc29sdXRpb25zIGhhdmUgYnVpbHQgaW4gcmVkdW5kYW5jeSwgbmV0 d29yayBmdW5jdGlvbiANCnJlc2lsaWVuY3ksIGFuZCB0aGUgZHJhZnRzIChwcm9ibGVtIG9yIHVz ZSBjYXNlcykgZG8gbm90IHN0YXRlIGhvdyB0byANCnVzZSB0aGlzLg0KDQotIFNjZXB0aWNpc20g dGhhdCBmbG93IGZvcndhcmRpbmcgIHN0YXRlIHN5bmNocm9uaXNhdGlvbiBjYW4gYmUgDQphY2hp ZXZlZC4gQWxzbyBkbyBvcGVyYXRvcnMgcmVhbGx5IHJlcXVpcmUgdGhpcyBjYXBhYmlsaXR5PyAN Cg0KLSBRdWVzdGlvbjogV2hhdCBpcyBpbi1zY29wZSB2ZXJzdXMgb3V0LW9mLXNjb3BlPyAgRG8g d2UgaGFuZGxlIHNlcnZpY2UgDQpzdGF0ZSByZWNvdmVyeT8gIA0KDQotIFRoZSBzZXJ2aWNlIHN0 YXRlIHJlY292ZXJ5IGlzIGJleW9uZCB0aGUgc2NvcGUgb2YgU0ZDLg0KDQotIFtKaW0gQmVlY2hl cl0gU2VydmljZSBhdmFpbGFiaWxpdHkgaXMgbm90IGluIHNjb3BlLiANCg0KLSBbRXJpYyBOb3Jk bWFya306IEFyZSB0aGVyZSBwZW9wbGUgdGhhdCBjdmFuIGhlbHAgdXMgd2l0aCBmYXRlIHNoYXJp bmcgDQp3aXRoaW4gdGhlIE5GViBQb29sIGZ1bmN0aW9ucz8gDQoNCi0gW0dlb3JnZSAoZnJvbSBH cmVlY2UpXTogSW4gdGhlIHZpcnR1YWwgY2x1c3RlcnMgZmF0ZSBzaGFyaW5nLCBsb2FkIA0KYmFs YW5jaW5nIGFuZCBwb29sIGZ1bmN0aW9ucyBhcmUgbm90IHlldCB3b3JraW5nLiAgDQoNCi0gTGlu ZGEgRHVuYmFyOiBXaGF0IGhhcHBlbnMgaWYgb25lIGluc3RhbmNlIGZhaWxzIHdoaWNoIGlzIG5v dCBhIA0Kcm91dGluZyBpbnN0YW5jZT8gDQoNCi0gVGhvbWFzIE5hcnRlbjogU2NlcHRpY2FsIHdo ZXRoZXIgSUVURiBoYXMgdGhlIGV4cGVydGlzZSB0byBleGFtaW5lIA0KdGhlIHN0YXRlIHN5bmNo cm9uaXphdGlvbiBpc3N1ZS4gIElFVEYgZG9lcyBub3QgaGF2ZSBsYXJnZSBhbW91bnRzIG9mIA0K ZmlyZXdhbGwgdmVuZG9ycy4gDQoNCi0gW1N1ZSBIYXJlc106IFRvZGF5knMgYWNjZXNzIGRldmlj ZXMgYWxsIGNvbnRhaW4gZmlyaXN0IGxldmVsIA0KZmlyZXdhbGxzIHNvIGFsbCBhY2Nlc3MgZGV2 aWNlcyBoYXZlIG5vdyBpbnN0YWxsZWQgZmlyZXdhbGxzLiBUaGUgbW9yZSANCmNvbW1vbiBmaXJl d2FsbCBpcyB0aGlzIGZpcmV3YWxsIHdpdGhpbiB0aGUgYWNjZXNzIGRldmljZS4gDQoNCkFjdGlv bjogV2UgbmVlZCBhIGNvbW1vbiB1bmRlcnN0YW5kaW5nIGJldHdlZW4gVk5GIFBPT0wgYW5kIFNG QyBhcyB0byANCnNjb3BlIG9mIHdvcmsuIA0KDQpBY3Rpb246IERldGVybWluZSBzY29wZSBvZiBw cm90ZWN0aW9uIGZvciBpbnRlcm5hbCBhbmQgZXh0ZXJuYWwgDQpmdW5jdGlvbnMuIA0KDQpBY3Rp b246IENvbnNpZGVyIHdoYXQgYXBwbGljYXRpb25zIChvciBjbGFzcyBvZiBhcHBsaWNhdGlvbnMp IG1pZ2h0IA0KdXRpbGl6ZSBWTkYgUG9vbC4gDQoNCkFjdGlvbjogQ2xhcmlmeSB0aGUgYXJjaGl0 ZWN0dXJlIGFzcGVjdCBvZiBWTkZQT09MLCB3aGF0IGlzIGluIHNjb3BlLCANCmFuZCB3aGF0IGlz IG91dCBvZiBzY29wZS4gICANCg0KQWN0aW9uOiBEZWZpbml0aW9uIG9mIGEgVk5GLCBpcyB0aGVy ZSBhIFZORiwgU0ZDIFZORiBhbmQgRVRTSSBWTkY/IFdoZXJlIA0KaXMgb3ZlcmxhcCwgY2FuIHdl IGFncmVlIGRlZmluaXRpb25zLiANCg0KQWN0aW9uOiBPcGVyYXRvcnMgbmVlZCB0byBkaXNjdXNz IGlmIEZXIHN0YXRlIHN5bmNocm9uaXNhdGlvbiwgb3IgaW5kZWVkIA0Kb3RoZXIgTkYgc3RhdGUg c3luY2hyb25pc2F0aW9uLCBpcyBhY3R1YWxseSByZXF1aXJlZC4gDQoNCkFjdGlvbjogRXhhbWlu ZSBob3cgdGhlIG5lZWQgZm9yIGhpZ2ggYXZhaWxhYmlsaXR5IGltcGFjdHMgdGhlIFZORiBQb29s IA0KZGVzaWduIGFuZCANCg0KQWN0aW9uOiBFeGFtaW5lIGZhaWx1cmVzIHNjZW5hcmlvcyBpZiBv bmUgaW5zdGFuY2UgZmFpbHMuIA0KDQpBY3Rpb246IEV4YW1pbmUgZXhpc3Rpbmcgc29sdXRpb25z IHRvIGRldGVybWluZSBpZiBzb21lIGV4aXN0aW5nIElFVEYgDQpwcm90b2NvbCBvciBkZXNpZ24g Zml0cyBtb3N0IG9mIHRoZSBwYXJhbWV0ZXJzLiAgVGhpcyBpcyB0aGUgY29uY2VwdCBvZiANCnJl LXVzZSByYXRoZXIgdGhhbiByZWludmVudCBkdWUgdG8gTklIIChub3QtaW52ZW50ZWQgaGVyZSku IA0KDQogICAgICAgIDIpIE9wZW4gRGlzY3Vzc2lvbiAoYWxsLCAyNSBtaW51dGVzKQ0KICAgICAg ICANCjExOjIwIFdyYXAtdXAgKENoYWlycywgMTAgbWludXRlcykNCg0KMTE6MzAgRW5kDQoNCg== --_002_65174429B5AF4C45BD0798810EC48E0A11429DEX0MB2lancslocal_-- From nobody Wed Mar 12 11:44:54 2014 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D81961A0755 for ; Wed, 12 Mar 2014 11:44:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNRESOLVED_TEMPLATE=1.252] 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 9e6UiFMciJOz for ; Wed, 12 Mar 2014 11:44:48 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe003.messaging.microsoft.com [207.46.163.26]) by ietfa.amsl.com (Postfix) with ESMTP id 3801C1A0479 for ; Wed, 12 Mar 2014 11:44:48 -0700 (PDT) Received: from mail205-co9-R.bigfish.com (10.236.132.227) by CO9EHSOBE005.bigfish.com (10.236.130.68) with Microsoft SMTP Server id 14.1.225.22; Wed, 12 Mar 2014 18:44:42 +0000 Received: from mail205-co9 (localhost [127.0.0.1]) by mail205-co9-R.bigfish.com (Postfix) with ESMTP id D58E790018D; Wed, 12 Mar 2014 18:44:41 +0000 (UTC) X-Forefront-Antispam-Report: CIP:144.229.32.56; KIP:(null); UIP:(null); IPV:NLI; H:pdaasdm1.corp.sprint.com; RD:smtpda1.sprint.com; EFVD:NLI X-SpamScore: -22 X-BigFish: VS-22(zz9371I542I4015I14ffIzz1f42h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h1033IL17326ah8275dh1de097h186068hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h2461h2487h24d7h2516h2545h255eh25f6h2605h262fh9a9j1155h) Received-SPF: pass (mail205-co9: domain of sprint.com designates 144.229.32.56 as permitted sender) client-ip=144.229.32.56; envelope-from=David.Holmes@sprint.com; helo=pdaasdm1.corp.sprint.com ; p.sprint.com ; Received: from mail205-co9 (localhost.localdomain [127.0.0.1]) by mail205-co9 (MessageSwitch) id 1394649879946837_8571; Wed, 12 Mar 2014 18:44:39 +0000 (UTC) Received: from CO9EHSMHS002.bigfish.com (unknown [10.236.132.241]) by mail205-co9.bigfish.com (Postfix) with ESMTP id DB839C40062; Wed, 12 Mar 2014 18:44:39 +0000 (UTC) Received: from pdaasdm1.corp.sprint.com (144.229.32.56) by CO9EHSMHS002.bigfish.com (10.236.130.12) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 12 Mar 2014 18:44:38 +0000 Received: from PDAWEH04.ad.sprint.com (pdaweh04.corp.sprint.com [144.226.111.59]) by pdaasdm1.corp.sprint.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id s2CIiW1N014443 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 12 Mar 2014 13:44:36 -0500 Received: from PLSWE13M02.ad.sprint.com (144.229.214.21) by PDAWEH04.ad.sprint.com (144.226.111.59) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 12 Mar 2014 13:44:33 -0500 Received: from PLSWE13M01.ad.sprint.com (2002:90e5:d614::90e5:d614) by plswe13m02.ad.sprint.com (2002:90e5:d615::90e5:d615) with Microsoft SMTP Server (TLS) id 15.0.775.38; Wed, 12 Mar 2014 13:44:22 -0500 Received: from PLSWE13M01.ad.sprint.com ([fe80::bd53:22c7:943c:2bb9]) by PLSWE13M01.ad.sprint.com ([fe80::bd53:22c7:943c:2bb9%15]) with mapi id 15.00.0775.031; Wed, 12 Mar 2014 13:44:22 -0500 From: "Holmes, David W [CTO]" To: "King, Daniel" , "vnfpool@ietf.org" Thread-Topic: VNFPool BoF Minutes Thread-Index: Ac8+Ckp89QGGYom6Q4e9wO17cx/NwwAF9THg Date: Wed, 12 Mar 2014 18:44:21 +0000 Message-ID: <5cc46b54cca24a3c87debc89fc6dd6f6@PLSWE13M01.ad.sprint.com> References: <65174429B5AF4C45BD0798810EC48E0A11429D@EX-0-MB2.lancs.local> In-Reply-To: <65174429B5AF4C45BD0798810EC48E0A11429D@EX-0-MB2.lancs.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.123.104.24] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CRA-Verdict: 144.229.32.56$lancaster.ac.uk%0%1%sprint.com%False%False%0$ X-OriginatorOrg: sprint.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%0$Dn%LANCASTER.AC.UK$RO%1$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/kQN28kVPH2-Lyy3AworPCi-IeFU Cc: Melinda Shore , 'Zongning' Subject: Re: [vnfpool] VNFPool BoF Minutes X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for virtual network function resource pooling." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 18:44:52 -0000 Hi Daniel et al, Being something of an IETF newbie, I'm not sure as to how any decisions/rec= ommendations/feelings on how this topic will proceed (i.e. @ IETF90) would = be recorded. Specifically, as I recollect, the outgoing assumption was that this was not= a topic yet ripe for the creation of a WG, but I don't see how this was re= corded; or maybe it is by omission; i.e. no positive statement to move to a= WG? Thanks, David Holmes -----Original Message----- From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of King, Daniel Sent: Wednesday, March 12, 2014 8:50 AM To: vnfpool@ietf.org Cc: Melinda Shore; 'Zongning' Subject: [vnfpool] VNFPool BoF Minutes Hi All, Please find the VNF Pool BoF Minutes below. If you have any clarifications = or updates please let me know. Br, Dan. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D VNFPool BoF Draft Agenda, IETF 89th, London. Viscount, Tuesday Morning Session I, 0900-1130 GMT, March 4, 2014. 09:00 Admin (Chairs, 5 minutes) No Agenda changes. 09:05 Introduction & Purpose of the BoF (Chairs, 5 minutes) 09:10 Problem Space (35 minutes) 1) Problem Statement (Melinda, 15 minutes) https://datatracker.ietf.org/doc/draft-zong-vnfpool-problem-stateme= nt/ Comments at microphone, discussion points and actions: - Clarification that the work should not overlap within IETF or anywhere el= se. - [Chairs]: VNF Pool effort is mostly concerned with solving unique problem= s in IETF. - Request to see if any business discussion for reliability function has be= en conducted. - [Chairs]: Effort concerned with reliability that has been identified by s= ervice providers and customers highlighting their problems (in use cases). - Suggested that performance monitoring should also be considered, in conte= xt of performance degradation and VNF Pool switching. Question: Why not Hardware devices? [Chairs]: VNF Pool is applicable to ha= rdware but for now the context is virtual network devices. - Request to make sure charter reflects problem statement, and vice versa. - Security of state sharing is a concern. The security section of the prob= lem statement, but you do not look at security state. Bob suggested that se= curity between VNFs, when state sharing, should also be considered. [Bob Mo= skowitz] - Maybe some requirements from the Fixed Mobile Convergence (FMC) work. - Request to look at existing IETF protocols for configuration of devices a= nd DNS (OPS-NM AD: Benoit Claise). Action: Synch Problem Statement with Charter text Action: Coordination with SFC to agree on scope and perceived overlap would= be helpful. Action: Security must be investigated for security of solution, and securit= y of state passing in the VNF Pool. Action: Clarify business case(s) in summary of use cases. 2) Q & A (all, 20 m minutes) 09:50 Use Cases (50 minutes) 1) Generic Use Case (Michiaki, 5 minutes) https://datatracker.ietf.org/doc/draft-xia-vnfpool-use-cases/ 2) vEPC Use Case (Marco, 10 minutes) https://datatracker.ietf.org/doc/draft-king-vnfpool-mobile-use- case/ Comments at microphone, discussion points and actions: - Software/Virtualization resilience is a reasonable requirement. - Some participants felt that it was unclear if we are discussing a VM Pool= or VNF Pool. The Chairs clarified that this was not VM pooling. - [Kireeti Kompella]: Is it then groups of virtual functions and multiple p= ools? - Suggestion that the work should deal with hardware and not just virtualis= ed Network Functions (vNF). - Observation that SFC charter does not mention virtualisation. - A number of factors exist in vEPC that may be unique for providing relian= ce in a virtualised environment. - State management may be required, but in some cases it may be acceptable = to simply recover. - Consideration of the role of VNF Pool Manager. - A need to mindful of not over reaching on requirements, is synchronizatio= n of state feasible and is it reasonable to expect state sharing between ve= ndor implementations. - Dave Dysan: The recovery of virtual components is beneficial. The VNF c= an be a connected set of VMs. You can utilize a set of work from the Reliab= le Server pooling (RSerPool) - Thomas Nordmark: The link between virtual network functions and the synch= ronized pool is not clear in this presentation, and it seems to be differen= t from the previous definition of pools and pool manager. - Daniel King: The uses were developed in isolation, and additional synchro= nization of terminology needs to occur. Action: Synch terminology across VNF Pool I-Ds, including Use Case document= s. Action: Continue to develop Use Case I-Ds to help identify if State Synchro= nization is a reasonable requirement, and what is the scope of the required= state synchronization. 3) Load Balancing (Andy, 5 minutes) Comments at microphone, discussion points and actions: - Suggestion that if SFC is correctly implemented then this [the load balancing scaling issue] should not be applicable. (Eric Nordmark and Jim Beecher) - Service graph and pooling are separate things, how the virtual network fu= nction is pooled should be abstracted away from SFC. (Kireeti Kompella) - Assertion that SFC can provide the required solution. - State Sharing interacts with the service graph. Where these functions to= uch, it will be important to keep the functions separate in the interaction= . [Erik Nordmark] - Request to help clarify this [load balancing] problem to help with WG ass= ignment (VNF Pool, SFC, or other). - VNF Pool is building on ETSI NFV architecture and does not describe the i= nternal architecture of a VNF. - SFC is a special case of service graph and is not addressing what we [VNF= Pool] is investigating. - Request to look at the scaling of the solutions (Thomas Narten) - Constantine: The Unify European project is investigating functions like t= he VNF Pool. Action: Describe and document requirements for the load balancing scenario = in a use case I-D. Action: Investigate comment that SFC can provide the required solution for load balancing described in the presentation. Action: If the SFC + VNF Pool are required to solve the load balancing prob= lem, determine where the points of interaction with SFC are and develop cle= an interfaces so that SFC and VNF Pool remain separate entities. Action: Look at scaling of VNF Solution. 3) vCDN Use Case (Pedro, 10 minutes) https://datatracker.ietf.org/doc/draft-aranda-vnfpool-cdn-use-case/ Comments at microphone, discussion points and actions: - Echo from other operator that CDN is a useful use case for operators. - Important to note that policy applies to resource management. A gap analy= sis and I-D might also be needed. Action: Investigate resilience resource policy requirements. 4) Resource Pool Use Case (Sue, 10 minutes) https://datatracker.ietf.org/doc/draft-hares-vnf-pool-use-case/ - Suggestion that a recent paper submitted to the SDN RG list might help hi= ghlight existing/new requirements. 5) Q & A (all, 10 minutes) 10:35 Related Works (15 minutes) 1) RSerPool Applicability (Thomas, 10 minutes) https://datatracker.ietf.org/doc/draft-dreibholz-vnfpool-rserpool-a= pplic/ Comments at microphone, discussion points and actions: - Suggestion that the RSerPool work should have been presented first (Dave = Dysan) - If used, the RSerPool work is Experimental (Status) so would have to be p= ublished as Standards Track. - RSerPool work was shutdown years ago, but it represents an opportunity to= restart and develop as needed. - [NTT person): Would there be multiple network functions operating as VNF = Pools? - Suggestion that SCTP is used but MSCTP might be an alternative (Randall S= tewart, Jabber) - Are the assumptions previous used in the development of RSerPool still va= lid? - System architecture should have inherent redundancy, the [RSerPool author= s] should analyse the impact of RSerPool. - A number of future research is documented in RSerPool Next Generation I-D= . - RSerPool will require 64 bit capability. 10:50 Charter Discussion (30 minutes) 1) Charter (Chairs, 5 minutes) http://www.ietf.org/mail- archive/web/vnfpool/current/msg00224.html Comments at microphone, discussion points and actions: - Some discussion already on scope of protection for both internal and exte= rnal functions. Some discussion on time dimension in the scope of protecti= on. Also the protection may also be participating in a larger protection s= cheme. - What is the server application that is being examined? Does it need reli= ability of pools? - [Jamal Salim]: The VNF pool application is describing high availability t= hat MPLS and GMPLS utilize. ForCES has High availability based on Forces r= unning over a control. Based on the ForCES experience, it is important to = know are these functions highly available or not? - [unknown]: Do we have flow stitching? - Not total agreement that work should be independent of SFC. - Current fate sharing, load balancing, pool function are not fit for purpo= se. These are problems that need to be worked on. - UNIFY is a European Research project investigating the problem space, som= e shared findings/discussion may be beneficial. - It would be valuable to coordinate within a VNFPool. If you extend it to = inter-pools, it becomes "orchestration". - Observation that a pool of NFs, in a virtual FW you have higher failure r= ate. - Hardwire based solutions have built in redundancy, network function resil= iency, and the drafts (problem or use cases) do not state how to use this. - Scepticism that flow forwarding state synchronisation can be achieved. A= lso do operators really require this capability? - Question: What is in-scope versus out-of-scope? Do we handle service sta= te recovery? - The service state recovery is beyond the scope of SFC. - [Jim Beecher] Service availability is not in scope. - [Eric Nordmark}: Are there people that can help us with fate sharing with= in the NFV Pool functions? - [George (from Greece)]: In the virtual clusters fate sharing, load balanc= ing and pool functions are not yet working. - Linda Dunbar: What happens if one instance fails which is not a routing i= nstance? - Thomas Narten: Sceptical whether IETF has the expertise to examine the st= ate synchronization issue. IETF does not have large amounts of firewall ve= ndors. - [Sue Hares]: Today's access devices all contain first level firewalls so = all access devices have now installed firewalls. The more common firewall i= s this firewall within the access device. Action: We need a common understanding between VNF POOL and SFC as to scope= of work. Action: Determine scope of protection for internal and external functions. Action: Consider what applications (or class of applications) might utilize= VNF Pool. Action: Clarify the architecture aspect of VNFPOOL, what is in scope, and what is out of scope. Action: Definition of a VNF, is there a VNF, SFC VNF and ETSI VNF? Where is= overlap, can we agree definitions. Action: Operators need to discuss if FW state synchronisation, or indeed ot= her NF state synchronisation, is actually required. Action: Examine how the need for high availability impacts the VNF Pool des= ign and Action: Examine failures scenarios if one instance fails. Action: Examine existing solutions to determine if some existing IETF proto= col or design fits most of the parameters. This is the concept of re-use r= ather than reinvent due to NIH (not-invented here). 2) Open Discussion (all, 25 minutes) 11:20 Wrap-up (Chairs, 10 minutes) 11:30 End ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. From nobody Wed Mar 12 12:09:41 2014 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 221AF1A0766 for ; Wed, 12 Mar 2014 12:09:39 -0700 (PDT) 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 q-V9G5Ugou5p for ; Wed, 12 Mar 2014 12:09:37 -0700 (PDT) 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 E26071A074C for ; Wed, 12 Mar 2014 12:09:34 -0700 (PDT) Received: by mail-pb0-f53.google.com with SMTP id rp16so1495217pbb.26 for ; Wed, 12 Mar 2014 12:09:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=+Bu8fAfDih+/ErJYKSz7BlLsoP+Lxh3vmM+wLWPmhws=; b=KvAEyxpadS+UigeXZOdANIzcZkXwDTz0lj1jn+/ZCrOx/CZ93Vj+qK/yiB1swnkFtr qm/N79bth0pgawpX2QGuhAIScAmcQ+/LY0Xkj0WyYuPYk6Y1rqauaLNvGdd3fql4rGkh rL/i8SQy0p1Qo1tuVTGqViSe7Fr+vJfPsqy5FSaPkZOLL3MUorDAvkTlir9yZ9+hmSaO AUqZx/wlvMNMT0eQzh/TTAjtwq98Liw5EL9sYGlmF0P6e8UXzEfCavatCFUhS+Rb+BYl Bod8rH+lpj3QINvT8+QZfoBN1KW2h7AYMPl+36QL0VOY17UT2oGua77+OemcH48g4Q50 6DNw== X-Received: by 10.68.234.230 with SMTP id uh6mr7100517pbc.161.1394651366891; Wed, 12 Mar 2014 12:09:26 -0700 (PDT) Received: from spandex.local (209-112-197-35-rb1.nwc.dsl.dynamic.acsalaska.net. [209.112.197.35]) by mx.google.com with ESMTPSA id bz4sm9558704pbb.12.2014.03.12.12.09.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 12 Mar 2014 12:09:26 -0700 (PDT) Message-ID: <5320B0E3.9030109@gmail.com> Date: Wed, 12 Mar 2014 11:09:23 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: vnfpool@ietf.org References: <65174429B5AF4C45BD0798810EC48E0A11429D@EX-0-MB2.lancs.local> <5cc46b54cca24a3c87debc89fc6dd6f6@PLSWE13M01.ad.sprint.com> In-Reply-To: <5cc46b54cca24a3c87debc89fc6dd6f6@PLSWE13M01.ad.sprint.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/TB3Wvn3Fn2VnRq4fOJ-wxCbBO8I Subject: Re: [vnfpool] VNFPool BoF Minutes X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for virtual network function resource pooling." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 19:09:39 -0000 On 3/12/14 10:44 AM, Holmes, David W [CTO] wrote: > Specifically, as I recollect, the outgoing assumption was that this > was not a topic yet ripe for the creation of a WG, but I don't see > how this was recorded; or maybe it is by omission; i.e. no positive > statement to move to a WG? Generally, decisions are not made at meetings, but on mailing lists. It's sometimes helpful to get the sense of the room at a meeting to get a better handle on how people are feeling about a given topic, but that's not quite the same as a decision. It looks like we're making reasonable progress towards having a working group chartered, but there's still some work to do to clarify several documents and to tighten up the proposed charter. In that sense it was an extremely productive meeting, in terms of identifying areas where there's confusion about what's being proposed, how it's scoped, and so on. We're working towards getting a revised problem statement out in the next week or so, and on a proposed charter revision as well. We'll keep the mailing list in the loop as things proceed. Melinda From nobody Wed Mar 12 13:03:39 2014 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38F231A0756 for ; Wed, 12 Mar 2014 13:03:37 -0700 (PDT) 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 faAMPSs1xqGn for ; Wed, 12 Mar 2014 13:03:35 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id EC9811A074E for ; Wed, 12 Mar 2014 13:03:34 -0700 (PDT) Received: from mail78-va3-R.bigfish.com (10.7.14.239) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 14.1.225.22; Wed, 12 Mar 2014 20:03:28 +0000 Received: from mail78-va3 (localhost [127.0.0.1]) by mail78-va3-R.bigfish.com (Postfix) with ESMTP id B0F564E0210; Wed, 12 Mar 2014 20:03:28 +0000 (UTC) X-Forefront-Antispam-Report: CIP:144.230.168.26; KIP:(null); UIP:(null); IPV:NLI; H:plsasdm2.corp.sprint.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: VS-22(zzbb2dI98dI9371I542Izz1f42h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h1033IL8275dh1de097h186068hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h262fh9a9j1155h) Received-SPF: pass (mail78-va3: domain of sprint.com designates 144.230.168.26 as permitted sender) client-ip=144.230.168.26; envelope-from=David.Holmes@sprint.com; helo=plsasdm2.corp.sprint.com ; p.sprint.com ; Received: from mail78-va3 (localhost.localdomain [127.0.0.1]) by mail78-va3 (MessageSwitch) id 1394654605813470_27297; Wed, 12 Mar 2014 20:03:25 +0000 (UTC) Received: from VA3EHSMHS020.bigfish.com (unknown [10.7.14.239]) by mail78-va3.bigfish.com (Postfix) with ESMTP id A626D4004D; Wed, 12 Mar 2014 20:03:25 +0000 (UTC) Received: from plsasdm2.corp.sprint.com (144.230.168.26) by VA3EHSMHS020.bigfish.com (10.7.99.30) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 12 Mar 2014 20:03:21 +0000 Received: from PLSWEH02.ad.sprint.com (plsweh02.corp.sprint.com [144.226.242.131]) by plsasdm2.corp.sprint.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id s2CK3KZf029739 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 12 Mar 2014 15:03:20 -0500 Received: from PREWE13M02.ad.sprint.com (144.226.128.21) by PLSWEH02.ad.sprint.com (144.226.242.131) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 12 Mar 2014 15:03:20 -0500 Received: from PLSWE13M01.ad.sprint.com (2002:90e5:d614::90e5:d614) by PREWE13M02.ad.sprint.com (2002:90e2:8015::90e2:8015) with Microsoft SMTP Server (TLS) id 15.0.775.38; Wed, 12 Mar 2014 16:03:19 -0400 Received: from PLSWE13M01.ad.sprint.com ([fe80::bd53:22c7:943c:2bb9]) by PLSWE13M01.ad.sprint.com ([fe80::bd53:22c7:943c:2bb9%15]) with mapi id 15.00.0775.031; Wed, 12 Mar 2014 15:03:18 -0500 From: "Holmes, David W [CTO]" To: Melinda Shore , "vnfpool@ietf.org" Thread-Topic: [vnfpool] VNFPool BoF Minutes Thread-Index: Ac8+Ckp89QGGYom6Q4e9wO17cx/NwwAF9THgAAuXZoAACl6zUA== Date: Wed, 12 Mar 2014 20:03:18 +0000 Message-ID: <31bc2cdda4a44d03b700f1f0a4a1f482@PLSWE13M01.ad.sprint.com> References: <65174429B5AF4C45BD0798810EC48E0A11429D@EX-0-MB2.lancs.local> <5cc46b54cca24a3c87debc89fc6dd6f6@PLSWE13M01.ad.sprint.com> <5320B0E3.9030109@gmail.com> In-Reply-To: <5320B0E3.9030109@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.123.104.24] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sprint.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/EWeBWYyzrmypJBxxrSghq0HN-fM Subject: Re: [vnfpool] VNFPool BoF Minutes X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for virtual network function resource pooling." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 20:03:37 -0000 Melinda, thanks, understood; but so we don't even record the "sense" of a t= opic in the minutes? DH -----Original Message----- From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of Melinda Shore Sent: Wednesday, March 12, 2014 12:09 PM To: vnfpool@ietf.org Subject: Re: [vnfpool] VNFPool BoF Minutes On 3/12/14 10:44 AM, Holmes, David W [CTO] wrote: > Specifically, as I recollect, the outgoing assumption was that this > was not a topic yet ripe for the creation of a WG, but I don't see how > this was recorded; or maybe it is by omission; i.e. no positive > statement to move to a WG? Generally, decisions are not made at meetings, but on mailing lists. It's = sometimes helpful to get the sense of the room at a meeting to get a better= handle on how people are feeling about a given topic, but that's not quite= the same as a decision. It looks like we're making reasonable progress towards having a working gro= up chartered, but there's still some work to do to clarify several document= s and to tighten up the proposed charter. In that sense it was an extremel= y productive meeting, in terms of identifying areas where there's confusion= about what's being proposed, how it's scoped, and so on. We're working to= wards getting a revised problem statement out in the next week or so, and o= n a proposed charter revision as well. We'll keep the mailing list in the = loop as things proceed. Melinda _______________________________________________ vnfpool mailing list vnfpool@ietf.org https://www.ietf.org/mailman/listinfo/vnfpool ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. From nobody Wed Mar 12 13:17:28 2014 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B441D1A0754 for ; Wed, 12 Mar 2014 13:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.478 X-Spam-Level: ** X-Spam-Status: No, score=2.478 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RCVD_IN_BL_SPAMCOP_NET=1.347, RDNS_NONE=0.793] 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 2zqW7uzYXp7I for ; Wed, 12 Mar 2014 13:17:20 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (unknown [69.163.253.163]) by ietfa.amsl.com (Postfix) with ESMTP id 00A3E1A0496 for ; Wed, 12 Mar 2014 13:17:19 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id 95B99594061 for ; Wed, 12 Mar 2014 13:17:13 -0700 (PDT) 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=w8NMfmOqQvs+c39gRZKORdUFkH8=; b=y0s0EI4KH/6Vu l0Hd/NVttRnR7cMUlnrp4NouIOzwCRiHu1Q6LVbKMtcc1yhwhpVvAiQUm7eY8H2M DvMmP5/JubTau0xAmyVvbsvkoTEb6OL3hTb7RZG4ijLt5wtWDIBfZX9/rjuD607Y kmtdTXKorZPQPHWk3PhtV6O8ePLsK8= Received: from spandex.local (209-112-197-35-rb1.nwc.dsl.dynamic.acsalaska.net [209.112.197.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: melinda.shore@nomountain.net) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPSA id 42CCE594057 for ; Wed, 12 Mar 2014 13:17:13 -0700 (PDT) Message-ID: <5320C0C7.5000404@nomountain.net> Date: Wed, 12 Mar 2014 12:17:11 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: vnfpool@ietf.org References: <65174429B5AF4C45BD0798810EC48E0A11429D@EX-0-MB2.lancs.local> <5cc46b54cca24a3c87debc89fc6dd6f6@PLSWE13M01.ad.sprint.com> <5320B0E3.9030109@gmail.com> <31bc2cdda4a44d03b700f1f0a4a1f482@PLSWE13M01.ad.sprint.com> In-Reply-To: <31bc2cdda4a44d03b700f1f0a4a1f482@PLSWE13M01.ad.sprint.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/ERnzmx1i8DmLl2LimZKJ2RPurUE Subject: Re: [vnfpool] VNFPool BoF Minutes X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for virtual network function resource pooling." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 20:17:21 -0000 On 3/12/14 12:03 PM, Holmes, David W [CTO] wrote: > Melinda, thanks, understood; but so we don't even record the "sense" > of a topic in the minutes? DH We do, where we take them, but usually an action item is flagged to take something to the mailing list. What do you see missing? Is it the responses to Martin's questions? Melinda -- Melinda Shore No Mountain Software melinda.shore@nomountain.net "Software longa, hardware brevis." From nobody Wed Mar 12 17:27:10 2014 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53B391A07BD for ; Wed, 12 Mar 2014 17:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.748 X-Spam-Level: X-Spam-Status: No, score=-104.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 nIAI2aWCc2bC for ; Wed, 12 Mar 2014 17:27:05 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id ED08B1A07A6 for ; Wed, 12 Mar 2014 17:27:04 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEM96124; Thu, 13 Mar 2014 00:26:58 +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; Thu, 13 Mar 2014 00:26:08 +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; Thu, 13 Mar 2014 00:26:57 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.85]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Thu, 13 Mar 2014 08:26:53 +0800 From: Zongning To: "King, Daniel" , "vnfpool@ietf.org" , "'Mcdysan, David E'" Thread-Topic: VNFPool BoF Minutes Thread-Index: Ac8+Ckp89QGGYom6Q4e9wO17cx/NwwAR1VYA Date: Thu, 13 Mar 2014 00:26:52 +0000 Message-ID: References: <65174429B5AF4C45BD0798810EC48E0A11429D@EX-0-MB2.lancs.local> In-Reply-To: <65174429B5AF4C45BD0798810EC48E0A11429D@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.108] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/pR341LQ6cYpHCg-xaiQeMBQ47vQ Cc: Melinda Shore Subject: Re: [vnfpool] VNFPool BoF Minutes X-BeenThere: vnfpool@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for virtual network function resource pooling." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 00:27:09 -0000 Hi, Dan, Dave, and all. Thank you for posting the BoF notes. We are now working on new revision of = I-Ds and charter, in order to resolve most issues recorded in the notes. BTW, if you have plan to write more drafts, please consider starting now. := -) -Ning > -----Original Message----- > From: King, Daniel [mailto:d.king@lancaster.ac.uk] > Sent: Wednesday, March 12, 2014 11:50 PM > To: vnfpool@ietf.org > Cc: Melinda Shore; Zongning > Subject: VNFPool BoF Minutes >=20 > Hi All, >=20 > Please find the VNF Pool BoF Minutes below. If you have any clarification= s or > updates please let me know. >=20 > Br, Dan. >=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 >=20 > VNFPool BoF Draft Agenda, IETF 89th, London. > Viscount, Tuesday Morning Session I, 0900-1130 GMT, March 4, 2014. >=20 > 09:00 Admin (Chairs, 5 minutes) > No Agenda changes. >=20 > 09:05 Introduction & Purpose of the BoF (Chairs, 5 minutes) >=20 > 09:10 Problem Space (35 minutes) > 1) Problem Statement (Melinda, 15 minutes) >=20 > https://datatracker.ietf.org/doc/draft-zong-vnfpool-problem-statement/ >=20 > Comments at microphone, discussion points and actions: >=20 > - Clarification that the work should not overlap within IETF or anywhere = else. >=20 > - [Chairs]: VNF Pool effort is mostly concerned with solving unique probl= ems in > IETF. >=20 > - Request to see if any business discussion for reliability function has = been > conducted. >=20 > - [Chairs]: Effort concerned with reliability that has been identified by= service > providers and customers highlighting their problems (in use cases). >=20 > - Suggested that performance monitoring should also be considered, in con= text > of performance degradation and VNF Pool switching. >=20 > Question: Why not Hardware devices? [Chairs]: VNF Pool is applicable to > hardware but for now the context is virtual network devices. >=20 > - Request to make sure charter reflects problem statement, and vice versa= . >=20 > - Security of state sharing is a concern. The security section of the pr= oblem > statement, but you do not look at security state. Bob suggested that secu= rity > between VNFs, when state sharing, should also be considered. [Bob > Moskowitz] >=20 > - Maybe some requirements from the Fixed Mobile Convergence (FMC) work. >=20 > - Request to look at existing IETF protocols for configuration of devices= and DNS > (OPS-NM AD: Benoit Claise). >=20 > Action: Synch Problem Statement with Charter text >=20 > Action: Coordination with SFC to agree on scope and perceived overlap wou= ld > be helpful. >=20 > Action: Security must be investigated for security of solution, and secur= ity of > state passing in the VNF Pool. >=20 > Action: Clarify business case(s) in summary of use cases. >=20 > 2) Q & A (all, 20 m minutes) >=20 > 09:50 Use Cases (50 minutes) >=20 > 1) Generic Use Case (Michiaki, 5 minutes) > https://datatracker.ietf.org/doc/draft-xia-vnfpool-use-cases/ >=20 > 2) vEPC Use Case (Marco, 10 minutes) > https://datatracker.ietf.org/doc/draft-king-vnfpool-mobile-use- > case/ >=20 > Comments at microphone, discussion points and actions: >=20 > - Software/Virtualization resilience is a reasonable requirement. >=20 > - Some participants felt that it was unclear if we are discussing a VM Po= ol or > VNF Pool. The Chairs clarified that this was not VM pooling. >=20 > - [Kireeti Kompella]: Is it then groups of virtual functions and multiple= pools? >=20 > - Suggestion that the work should deal with hardware and not just virtual= ised > Network Functions (vNF). >=20 > - Observation that SFC charter does not mention virtualisation. >=20 > - A number of factors exist in vEPC that may be unique for providing reli= ance in > a virtualised environment. >=20 > - State management may be required, but in some cases it may be acceptabl= e > to simply recover. >=20 > - Consideration of the role of VNF Pool Manager. >=20 > - A need to mindful of not over reaching on requirements, is synchronizat= ion of > state feasible and is it reasonable to expect state sharing between vendo= r > implementations. >=20 > - Dave Dysan: The recovery of virtual components is beneficial. The VNF= can > be a connected set of VMs. You can utilize a set of work from the Reliabl= e > Server pooling (RSerPool) >=20 > - Thomas Nordmark: The link between virtual network functions and the > synchronized pool is not clear in this presentation, and it seems to be d= ifferent > from the previous definition of pools and pool manager. >=20 > - Daniel King: The uses were developed in isolation, and additional > synchronization of terminology needs to occur. >=20 > Action: Synch terminology across VNF Pool I-Ds, including Use Case docume= nts. >=20 > Action: Continue to develop Use Case I-Ds to help identify if State > Synchronization is a reasonable requirement, and what is the scope of the > required state synchronization. >=20 > 3) Load Balancing (Andy, 5 minutes) >=20 > Comments at microphone, discussion points and actions: >=20 > - Suggestion that if SFC is correctly implemented then this [the load > balancing scaling issue] should not be applicable. (Eric Nordmark and > Jim Beecher) >=20 > - Service graph and pooling are separate things, how the virtual network > function is pooled should be abstracted away from SFC. (Kireeti > Kompella) >=20 > - Assertion that SFC can provide the required solution. >=20 > - State Sharing interacts with the service graph. Where these functions = touch, > it will be important to keep the functions separate in the interaction. = [Erik > Nordmark] >=20 > - Request to help clarify this [load balancing] problem to help with WG > assignment (VNF Pool, SFC, or other). >=20 > - VNF Pool is building on ETSI NFV architecture and does not describe the > internal architecture of a VNF. >=20 > - SFC is a special case of service graph and is not addressing what we [V= NF Pool] > is investigating. >=20 > - Request to look at the scaling of the solutions (Thomas Narten) >=20 > - Constantine: The Unify European project is investigating functions like= the VNF > Pool. >=20 > Action: Describe and document requirements for the load balancing scenari= o in > a use case I-D. >=20 > Action: Investigate comment that SFC can provide the required solution > for load balancing described in the presentation. >=20 > Action: If the SFC + VNF Pool are required to solve the load balancing pr= oblem, > determine where the points of interaction with SFC are and develop clean > interfaces so that SFC and VNF Pool remain separate entities. >=20 > Action: Look at scaling of VNF Solution. >=20 > 3) vCDN Use Case (Pedro, 10 minutes) > https://datatracker.ietf.org/doc/draft-aranda-vnfpool-cdn-use-cas= e/ >=20 > Comments at microphone, discussion points and actions: >=20 > - Echo from other operator that CDN is a useful use case for operators. >=20 > - Important to note that policy applies to resource management. A gap ana= lysis > and I-D might also be needed. >=20 > Action: Investigate resilience resource policy requirements. >=20 > 4) Resource Pool Use Case (Sue, 10 minutes) > https://datatracker.ietf.org/doc/draft-hares-vnf-pool-use-case/ >=20 > - Suggestion that a recent paper submitted to the SDN RG list might help > highlight existing/new requirements. > 5) Q & A (all, 10 minutes) >=20 > 10:35 Related Works (15 minutes) > 1) RSerPool Applicability (Thomas, 10 minutes) >=20 > https://datatracker.ietf.org/doc/draft-dreibholz-vnfpool-rserpool-applic/ >=20 > Comments at microphone, discussion points and actions: >=20 > - Suggestion that the RSerPool work should have been presented first (Dav= e > Dysan) >=20 > - If used, the RSerPool work is Experimental (Status) so would have to be > published as Standards Track. >=20 > - RSerPool work was shutdown years ago, but it represents an opportunity = to > restart and develop as needed. >=20 > - [NTT person): Would there be multiple network functions operating as VN= F > Pools? >=20 > - Suggestion that SCTP is used but MSCTP might be an alternative (Randall > Stewart, Jabber) >=20 > - Are the assumptions previous used in the development of RSerPool still = valid? >=20 > - System architecture should have inherent redundancy, the [RSerPool auth= ors] > should analyse the impact of RSerPool. >=20 > - A number of future research is documented in RSerPool Next Generation I= -D. >=20 > - RSerPool will require 64 bit capability. >=20 > 10:50 Charter Discussion (30 minutes) >=20 > 1) Charter (Chairs, 5 minutes) > http://www.ietf.org/mail- > archive/web/vnfpool/current/msg00224.html >=20 > Comments at microphone, discussion points and actions: >=20 > - Some discussion already on scope of protection for both internal and ex= ternal > functions. Some discussion on time dimension in the scope of protection. > Also the protection may also be participating in a larger protection sche= me. >=20 > - What is the server application that is being examined? Does it need > reliability of pools? >=20 > - [Jamal Salim]: The VNF pool application is describing high availability= that > MPLS and GMPLS utilize. ForCES has High availability based on Forces run= ning > over a control. Based on the ForCES experience, it is important to know = are > these functions highly available or not? >=20 > - [unknown]: Do we have flow stitching? >=20 > - Not total agreement that work should be independent of SFC. >=20 > - Current fate sharing, load balancing, pool function are not fit for pur= pose. > These are problems that need to be worked on. >=20 > - UNIFY is a European Research project investigating the problem space, s= ome > shared findings/discussion may be beneficial. >=20 > - It would be valuable to coordinate within a VNFPool. If you extend it t= o > inter-pools, it becomes "orchestration". >=20 > - Observation that a pool of NFs, in a virtual FW you have higher failure= rate. >=20 > - Hardwire based solutions have built in redundancy, network function res= iliency, > and the drafts (problem or use cases) do not state how to use this. >=20 > - Scepticism that flow forwarding state synchronisation can be achieved.= Also > do operators really require this capability? >=20 > - Question: What is in-scope versus out-of-scope? Do we handle service s= tate > recovery? >=20 > - The service state recovery is beyond the scope of SFC. >=20 > - [Jim Beecher] Service availability is not in scope. >=20 > - [Eric Nordmark}: Are there people that can help us with fate sharing wi= thin > the NFV Pool functions? >=20 > - [George (from Greece)]: In the virtual clusters fate sharing, load bala= ncing and > pool functions are not yet working. >=20 > - Linda Dunbar: What happens if one instance fails which is not a routing > instance? >=20 > - Thomas Narten: Sceptical whether IETF has the expertise to examine the > state synchronization issue. IETF does not have large amounts of firewal= l > vendors. >=20 > - [Sue Hares]: Today's access devices all contain first level firewalls s= o all access > devices have now installed firewalls. The more common firewall is this fi= rewall > within the access device. >=20 > Action: We need a common understanding between VNF POOL and SFC as to > scope of work. >=20 > Action: Determine scope of protection for internal and external functions= . >=20 > Action: Consider what applications (or class of applications) might utili= ze VNF > Pool. >=20 > Action: Clarify the architecture aspect of VNFPOOL, what is in scope, > and what is out of scope. >=20 > Action: Definition of a VNF, is there a VNF, SFC VNF and ETSI VNF? Where = is > overlap, can we agree definitions. >=20 > Action: Operators need to discuss if FW state synchronisation, or indeed = other > NF state synchronisation, is actually required. >=20 > Action: Examine how the need for high availability impacts the VNF Pool d= esign > and >=20 > Action: Examine failures scenarios if one instance fails. >=20 > Action: Examine existing solutions to determine if some existing IETF pro= tocol > or design fits most of the parameters. This is the concept of re-use rat= her > than reinvent due to NIH (not-invented here). >=20 > 2) Open Discussion (all, 25 minutes) >=20 > 11:20 Wrap-up (Chairs, 10 minutes) >=20 > 11:30 End From nobody Tue Mar 25 08:17:29 2014 Return-Path: X-Original-To: vnfpool@ietfa.amsl.com Delivered-To: vnfpool@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 165A11A019A for ; Tue, 25 Mar 2014 08:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.922 X-Spam-Level: X-Spam-Status: No, score=-97.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 0gwXrTTuDCAh for ; Tue, 25 Mar 2014 08:16:57 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3745B1A0182 for ; Tue, 25 Mar 2014 08:16:56 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEX88944; Tue, 25 Mar 2014 15:16:52 +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, 25 Mar 2014 15:13:47 +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; Tue, 25 Mar 2014 15:14:17 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.85]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Tue, 25 Mar 2014 23:14:10 +0800 From: Zongning To: "King, Daniel" , "vnfpool@ietf.org" Thread-Topic: VNFPool BoF Minutes Thread-Index: Ac8+Ckp89QGGYom6Q4e9wO17cx/NwwKMksTw Date: Tue, 25 Mar 2014 15:14:09 +0000 Message-ID: References: <65174429B5AF4C45BD0798810EC48E0A11429D@EX-0-MB2.lancs.local> In-Reply-To: <65174429B5AF4C45BD0798810EC48E0A11429D@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.47.147.108] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/gY7T91JkpxWfpmx_Sx5BZ629_gE Cc: Melinda Shore Subject: [vnfpool] =?gb2312?b?tPC4tDogVk5GUG9vbCBCb0YgTWludXRlcw==?= 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, 25 Mar 2014 15:17:02 -0000 SGksIGFsbCwNCg0KV2Ugd2lsbCBzb29uIHB1Ymxpc2ggdGhpcyBtaW51dGVzIGFzIHBhcnQgb2Yg dGhlIElFVEYgODl0aCBwcm9jZWVkaW5nLiBTbyBwbGVhc2UgZ2l2ZSB5b3VyIGNvbW1lbnRzIC8g Y29ycmVjdGlvbnMgLyBldGMgdG8gdGhlIG1pbnV0ZXMuDQoNClRoYW5rcy4NCg0KLU5pbmcNCg0K LS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IEtpbmcsIERhbmllbCBbbWFpbHRvOmQua2luZ0Bs YW5jYXN0ZXIuYWMudWtdIA0Kt6LLzcqxvOQ6IDIwMTTE6jPUwjEyyNUgODo1MA0KytW8/sjLOiB2 bmZwb29sQGlldGYub3JnDQqzrcvNOiBNZWxpbmRhIFNob3JlOyBab25nbmluZw0K1vfM4jogVk5G UG9vbCBCb0YgTWludXRlcw0KDQpIaSBBbGwsIA0KDQpQbGVhc2UgZmluZCB0aGUgVk5GIFBvb2wg Qm9GIE1pbnV0ZXMgYmVsb3cuIElmIHlvdSBoYXZlIGFueSBjbGFyaWZpY2F0aW9ucyBvciB1cGRh dGVzIHBsZWFzZSBsZXQgbWUga25vdy4gDQoNCkJyLCBEYW4uIA0KDQo9PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PQ0KDQpWTkZQb29sIEJvRiBEcmFmdCBBZ2VuZGEsIElFVEYgODl0 aCwgTG9uZG9uLg0KVmlzY291bnQsIFR1ZXNkYXkgTW9ybmluZyBTZXNzaW9uIEksIDA5MDAtMTEz MCBHTVQsIE1hcmNoIDQsIDIwMTQuDQoNCjA5OjAwIEFkbWluIChDaGFpcnMsIDUgbWludXRlcykN Ck5vIEFnZW5kYSBjaGFuZ2VzLg0KDQowOTowNSBJbnRyb2R1Y3Rpb24gJiBQdXJwb3NlIG9mIHRo ZSBCb0YgKENoYWlycywgNSBtaW51dGVzKQ0KDQowOToxMCBQcm9ibGVtIFNwYWNlICgzNSBtaW51 dGVzKQ0KICAgICAgICAxKSBQcm9ibGVtIFN0YXRlbWVudCAoTWVsaW5kYSwgMTUgbWludXRlcykN CiAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtem9uZy12bmZw b29sLXByb2JsZW0tc3RhdGVtZW50Lw0KDQpDb21tZW50cyBhdCBtaWNyb3Bob25lLCBkaXNjdXNz aW9uIHBvaW50cyBhbmQgYWN0aW9uczoNCg0KLSBDbGFyaWZpY2F0aW9uIHRoYXQgdGhlIHdvcmsg c2hvdWxkIG5vdCBvdmVybGFwIHdpdGhpbiBJRVRGIG9yIGFueXdoZXJlIGVsc2UuIA0KDQotIFtD aGFpcnNdOiBWTkYgUG9vbCBlZmZvcnQgaXMgbW9zdGx5IGNvbmNlcm5lZCB3aXRoIHNvbHZpbmcg dW5pcXVlIHByb2JsZW1zIGluIElFVEYuDQoNCi0gUmVxdWVzdCB0byBzZWUgaWYgYW55IGJ1c2lu ZXNzIGRpc2N1c3Npb24gZm9yIHJlbGlhYmlsaXR5IGZ1bmN0aW9uIGhhcyBiZWVuIGNvbmR1Y3Rl ZC4NCg0KLSBbQ2hhaXJzXTogRWZmb3J0IGNvbmNlcm5lZCB3aXRoIHJlbGlhYmlsaXR5IHRoYXQg aGFzIGJlZW4gaWRlbnRpZmllZCBieSBzZXJ2aWNlIHByb3ZpZGVycyBhbmQgY3VzdG9tZXJzIGhp Z2hsaWdodGluZyB0aGVpciBwcm9ibGVtcyAoaW4gdXNlIGNhc2VzKS4NCg0KLSBTdWdnZXN0ZWQg dGhhdCBwZXJmb3JtYW5jZSBtb25pdG9yaW5nIHNob3VsZCBhbHNvIGJlIGNvbnNpZGVyZWQsIGlu IGNvbnRleHQgb2YgcGVyZm9ybWFuY2UgZGVncmFkYXRpb24gYW5kIFZORiBQb29sIHN3aXRjaGlu Zy4gDQoNClF1ZXN0aW9uOiBXaHkgbm90IEhhcmR3YXJlIGRldmljZXM/ICBbQ2hhaXJzXTogVk5G IFBvb2wgaXMgYXBwbGljYWJsZSB0byBoYXJkd2FyZSBidXQgZm9yIG5vdyB0aGUgY29udGV4dCBp cyB2aXJ0dWFsIG5ldHdvcmsgZGV2aWNlcy4gDQoNCi0gUmVxdWVzdCB0byBtYWtlIHN1cmUgY2hh cnRlciByZWZsZWN0cyBwcm9ibGVtIHN0YXRlbWVudCwgYW5kIHZpY2UgdmVyc2EuDQoNCi0gU2Vj dXJpdHkgb2Ygc3RhdGUgc2hhcmluZyBpcyBhIGNvbmNlcm4uICBUaGUgc2VjdXJpdHkgc2VjdGlv biBvZiB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQsIGJ1dCB5b3UgZG8gbm90IGxvb2sgYXQgc2VjdXJp dHkgc3RhdGUuIEJvYiBzdWdnZXN0ZWQgdGhhdCBzZWN1cml0eSBiZXR3ZWVuIFZORnMsIHdoZW4g c3RhdGUgc2hhcmluZywgc2hvdWxkIGFsc28gYmUgY29uc2lkZXJlZC4gW0JvYiBNb3Nrb3dpdHpd DQoNCi0gTWF5YmUgc29tZSByZXF1aXJlbWVudHMgZnJvbSB0aGUgRml4ZWQgTW9iaWxlIENvbnZl cmdlbmNlIChGTUMpIHdvcmsuDQoNCi0gUmVxdWVzdCB0byBsb29rIGF0IGV4aXN0aW5nIElFVEYg cHJvdG9jb2xzIGZvciBjb25maWd1cmF0aW9uIG9mIGRldmljZXMgYW5kIEROUyAoT1BTLU5NIEFE OiBCZW5vaXQgQ2xhaXNlKS4gDQoNCkFjdGlvbjogU3luY2ggUHJvYmxlbSBTdGF0ZW1lbnQgd2l0 aCBDaGFydGVyIHRleHQNCg0KQWN0aW9uOiBDb29yZGluYXRpb24gd2l0aCBTRkMgdG8gYWdyZWUg b24gc2NvcGUgYW5kIHBlcmNlaXZlZCBvdmVybGFwIHdvdWxkIGJlIGhlbHBmdWwuDQoNCkFjdGlv bjogU2VjdXJpdHkgbXVzdCBiZSBpbnZlc3RpZ2F0ZWQgZm9yIHNlY3VyaXR5IG9mIHNvbHV0aW9u LCBhbmQgc2VjdXJpdHkgb2Ygc3RhdGUgcGFzc2luZyBpbiB0aGUgVk5GIFBvb2wuIA0KDQpBY3Rp b246IENsYXJpZnkgYnVzaW5lc3MgY2FzZShzKSBpbiBzdW1tYXJ5IG9mIHVzZSBjYXNlcy4gIA0K DQogICAgICAgIDIpIFEgJiBBIChhbGwsIDIwIG0gbWludXRlcykNCg0KMDk6NTAgVXNlIENhc2Vz ICg1MCBtaW51dGVzKQ0KDQogICAgICAgIDEpIEdlbmVyaWMgVXNlIENhc2UgKE1pY2hpYWtpLCA1 IG1pbnV0ZXMpDQogICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LXhpYS12bmZwb29sLXVzZS1jYXNlcy8NCg0KICAgICAgICAyKSB2RVBDIFVzZSBDYXNlIChNYXJj bywgMTAgbWludXRlcykNCiAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQta2luZy12bmZwb29sLW1vYmlsZS11c2UtDQogICAgICAgIGNhc2UvDQoNCkNvbW1lbnRz IGF0IG1pY3JvcGhvbmUsIGRpc2N1c3Npb24gcG9pbnRzIGFuZCBhY3Rpb25zOg0KDQotIFNvZnR3 YXJlL1ZpcnR1YWxpemF0aW9uIHJlc2lsaWVuY2UgaXMgYSByZWFzb25hYmxlIHJlcXVpcmVtZW50 LiANCg0KLSBTb21lIHBhcnRpY2lwYW50cyBmZWx0IHRoYXQgaXQgd2FzIHVuY2xlYXIgaWYgd2Ug YXJlIGRpc2N1c3NpbmcgYSBWTSBQb29sIG9yIFZORiBQb29sLiBUaGUgQ2hhaXJzIGNsYXJpZmll ZCB0aGF0IHRoaXMgd2FzIG5vdCBWTSBwb29saW5nLiANCg0KLSBbS2lyZWV0aSBLb21wZWxsYV06 IElzIGl0IHRoZW4gZ3JvdXBzIG9mIHZpcnR1YWwgZnVuY3Rpb25zIGFuZCBtdWx0aXBsZSBwb29s cz8gDQoNCi0gU3VnZ2VzdGlvbiB0aGF0IHRoZSB3b3JrIHNob3VsZCBkZWFsIHdpdGggaGFyZHdh cmUgYW5kIG5vdCBqdXN0IHZpcnR1YWxpc2VkIE5ldHdvcmsgRnVuY3Rpb25zICh2TkYpLiANCg0K LSBPYnNlcnZhdGlvbiB0aGF0IFNGQyBjaGFydGVyIGRvZXMgbm90IG1lbnRpb24gdmlydHVhbGlz YXRpb24uIA0KDQotIEEgbnVtYmVyIG9mIGZhY3RvcnMgZXhpc3QgaW4gdkVQQyB0aGF0IG1heSBi ZSB1bmlxdWUgZm9yIHByb3ZpZGluZyByZWxpYW5jZSBpbiBhIHZpcnR1YWxpc2VkIGVudmlyb25t ZW50LiAgDQoNCi0gU3RhdGUgbWFuYWdlbWVudCBtYXkgYmUgcmVxdWlyZWQsIGJ1dCBpbiBzb21l IGNhc2VzIGl0IG1heSBiZSBhY2NlcHRhYmxlIHRvIHNpbXBseSByZWNvdmVyLiANCg0KLSBDb25z aWRlcmF0aW9uIG9mIHRoZSByb2xlIG9mIFZORiBQb29sIE1hbmFnZXIuDQoNCi0gQSBuZWVkIHRv IG1pbmRmdWwgb2Ygbm90IG92ZXIgcmVhY2hpbmcgb24gcmVxdWlyZW1lbnRzLCBpcyBzeW5jaHJv bml6YXRpb24gb2Ygc3RhdGUgZmVhc2libGUgYW5kIGlzIGl0IHJlYXNvbmFibGUgdG8gZXhwZWN0 IHN0YXRlIHNoYXJpbmcgYmV0d2VlbiB2ZW5kb3IgaW1wbGVtZW50YXRpb25zLiAgDQoNCi0gRGF2 ZSBEeXNhbjogIFRoZSByZWNvdmVyeSBvZiB2aXJ0dWFsIGNvbXBvbmVudHMgaXMgYmVuZWZpY2lh bC4gIFRoZSBWTkYgY2FuIGJlIGEgY29ubmVjdGVkIHNldCBvZiBWTXMuIFlvdSBjYW4gdXRpbGl6 ZSBhIHNldCBvZiB3b3JrIGZyb20gdGhlIFJlbGlhYmxlIFNlcnZlciBwb29saW5nIChSU2VyUG9v bCkNCg0KLSBUaG9tYXMgTm9yZG1hcms6IFRoZSBsaW5rIGJldHdlZW4gdmlydHVhbCBuZXR3b3Jr IGZ1bmN0aW9ucyBhbmQgdGhlIHN5bmNocm9uaXplZCBwb29sIGlzIG5vdCBjbGVhciBpbiB0aGlz IHByZXNlbnRhdGlvbiwgYW5kIGl0IHNlZW1zIHRvIGJlIGRpZmZlcmVudCBmcm9tIHRoZSBwcmV2 aW91cyBkZWZpbml0aW9uIG9mIHBvb2xzIGFuZCBwb29sIG1hbmFnZXIuIA0KDQotIERhbmllbCBL aW5nOiBUaGUgdXNlcyB3ZXJlIGRldmVsb3BlZCBpbiBpc29sYXRpb24sIGFuZCBhZGRpdGlvbmFs IHN5bmNocm9uaXphdGlvbiBvZiB0ZXJtaW5vbG9neSBuZWVkcyB0byBvY2N1ci4gDQogDQpBY3Rp b246IFN5bmNoIHRlcm1pbm9sb2d5IGFjcm9zcyBWTkYgUG9vbCBJLURzLCBpbmNsdWRpbmcgVXNl IENhc2UgZG9jdW1lbnRzLg0KDQpBY3Rpb246IENvbnRpbnVlIHRvIGRldmVsb3AgVXNlIENhc2Ug SS1EcyB0byBoZWxwIGlkZW50aWZ5IGlmIFN0YXRlIFN5bmNocm9uaXphdGlvbiBpcyBhIHJlYXNv bmFibGUgcmVxdWlyZW1lbnQsIGFuZCB3aGF0IGlzIHRoZSBzY29wZSBvZiB0aGUgcmVxdWlyZWQg c3RhdGUgc3luY2hyb25pemF0aW9uLiANCiAgICAgICAgDQogICAgICAgIDMpIExvYWQgQmFsYW5j aW5nIChBbmR5LCA1IG1pbnV0ZXMpDQoNCkNvbW1lbnRzIGF0IG1pY3JvcGhvbmUsIGRpc2N1c3Np b24gcG9pbnRzIGFuZCBhY3Rpb25zOg0KDQotIFN1Z2dlc3Rpb24gdGhhdCBpZiBTRkMgaXMgY29y cmVjdGx5IGltcGxlbWVudGVkIHRoZW4gdGhpcyBbdGhlIGxvYWQgDQpiYWxhbmNpbmcgc2NhbGlu ZyBpc3N1ZV0gc2hvdWxkIG5vdCBiZSBhcHBsaWNhYmxlLiAgICAoRXJpYyBOb3JkbWFyayBhbmQg DQpKaW0gQmVlY2hlcikgDQoNCi0gU2VydmljZSBncmFwaCBhbmQgcG9vbGluZyBhcmUgc2VwYXJh dGUgdGhpbmdzLCBob3cgdGhlIHZpcnR1YWwgbmV0d29yayBmdW5jdGlvbiBpcyBwb29sZWQgc2hv dWxkIGJlIGFic3RyYWN0ZWQgYXdheSBmcm9tIFNGQy4gIChLaXJlZXRpDQpLb21wZWxsYSkgDQoN Ci0gQXNzZXJ0aW9uIHRoYXQgU0ZDIGNhbiBwcm92aWRlIHRoZSByZXF1aXJlZCBzb2x1dGlvbi4g DQoNCi0gU3RhdGUgU2hhcmluZyBpbnRlcmFjdHMgd2l0aCB0aGUgc2VydmljZSBncmFwaC4gIFdo ZXJlIHRoZXNlIGZ1bmN0aW9ucyB0b3VjaCwgaXQgd2lsbCBiZSBpbXBvcnRhbnQgdG8ga2VlcCB0 aGUgZnVuY3Rpb25zIHNlcGFyYXRlIGluIHRoZSBpbnRlcmFjdGlvbi4gIFtFcmlrIE5vcmRtYXJr XQ0KDQotIFJlcXVlc3QgdG8gaGVscCBjbGFyaWZ5IHRoaXMgW2xvYWQgYmFsYW5jaW5nXSBwcm9i bGVtIHRvIGhlbHAgd2l0aCBXRyBhc3NpZ25tZW50IChWTkYgUG9vbCwgU0ZDLCBvciBvdGhlciku DQoNCi0gVk5GIFBvb2wgaXMgYnVpbGRpbmcgb24gRVRTSSBORlYgYXJjaGl0ZWN0dXJlIGFuZCBk b2VzIG5vdCBkZXNjcmliZSB0aGUgaW50ZXJuYWwgYXJjaGl0ZWN0dXJlIG9mIGEgVk5GLg0KDQot IFNGQyBpcyBhIHNwZWNpYWwgY2FzZSBvZiBzZXJ2aWNlIGdyYXBoIGFuZCBpcyBub3QgYWRkcmVz c2luZyB3aGF0IHdlIFtWTkYgUG9vbF0gaXMgaW52ZXN0aWdhdGluZy4NCg0KLSBSZXF1ZXN0IHRv IGxvb2sgYXQgdGhlIHNjYWxpbmcgb2YgdGhlIHNvbHV0aW9ucyAoVGhvbWFzIE5hcnRlbikNCg0K LSBDb25zdGFudGluZTogVGhlIFVuaWZ5IEV1cm9wZWFuIHByb2plY3QgaXMgaW52ZXN0aWdhdGlu ZyBmdW5jdGlvbnMgbGlrZSB0aGUgVk5GIFBvb2wuIA0KDQpBY3Rpb246IERlc2NyaWJlIGFuZCBk b2N1bWVudCByZXF1aXJlbWVudHMgZm9yIHRoZSBsb2FkIGJhbGFuY2luZyBzY2VuYXJpbyBpbiBh IHVzZSBjYXNlIEktRC4NCg0KQWN0aW9uOiBJbnZlc3RpZ2F0ZSBjb21tZW50IHRoYXQgU0ZDIGNh biBwcm92aWRlIHRoZSByZXF1aXJlZCBzb2x1dGlvbiANCmZvciBsb2FkIGJhbGFuY2luZyBkZXNj cmliZWQgaW4gdGhlIHByZXNlbnRhdGlvbi4gICANCg0KQWN0aW9uOiBJZiB0aGUgU0ZDICsgVk5G IFBvb2wgYXJlIHJlcXVpcmVkIHRvIHNvbHZlIHRoZSBsb2FkIGJhbGFuY2luZyBwcm9ibGVtLCBk ZXRlcm1pbmUgd2hlcmUgdGhlIHBvaW50cyBvZiBpbnRlcmFjdGlvbiB3aXRoIFNGQyBhcmUgYW5k IGRldmVsb3AgY2xlYW4gaW50ZXJmYWNlcyBzbyB0aGF0IFNGQyBhbmQgVk5GIFBvb2wgcmVtYWlu IHNlcGFyYXRlIGVudGl0aWVzLiANCg0KQWN0aW9uOiBMb29rIGF0IHNjYWxpbmcgb2YgVk5GIFNv bHV0aW9uLiANCg0KICAgICAgICAzKSB2Q0ROIFVzZSBDYXNlIChQZWRybywgMTAgbWludXRlcykN CiAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYXJhbmRhLXZu ZnBvb2wtY2RuLXVzZS1jYXNlLw0KDQpDb21tZW50cyBhdCBtaWNyb3Bob25lLCBkaXNjdXNzaW9u IHBvaW50cyBhbmQgYWN0aW9uczoNCg0KLSBFY2hvIGZyb20gb3RoZXIgb3BlcmF0b3IgdGhhdCBD RE4gaXMgYSB1c2VmdWwgdXNlIGNhc2UgZm9yIG9wZXJhdG9ycy4gDQoNCi0gSW1wb3J0YW50IHRv IG5vdGUgdGhhdCBwb2xpY3kgYXBwbGllcyB0byByZXNvdXJjZSBtYW5hZ2VtZW50LiBBIGdhcCBh bmFseXNpcyBhbmQgSS1EIG1pZ2h0IGFsc28gYmUgbmVlZGVkLiANCg0KQWN0aW9uOiBJbnZlc3Rp Z2F0ZSByZXNpbGllbmNlIHJlc291cmNlIHBvbGljeSByZXF1aXJlbWVudHMuIA0KDQogICAgICAg IDQpIFJlc291cmNlIFBvb2wgVXNlIENhc2UgKFN1ZSwgMTAgbWludXRlcykNCiAgICAgICAgaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaGFyZXMtdm5mLXBvb2wtdXNlLWNh c2UvDQoNCi0gU3VnZ2VzdGlvbiB0aGF0IGEgcmVjZW50IHBhcGVyIHN1Ym1pdHRlZCB0byB0aGUg U0ROIFJHIGxpc3QgbWlnaHQgaGVscCBoaWdobGlnaHQgZXhpc3RpbmcvbmV3IHJlcXVpcmVtZW50 cy4gDQogICAgICAgIDUpIFEgJiBBIChhbGwsIDEwIG1pbnV0ZXMpDQoNCjEwOjM1IFJlbGF0ZWQg V29ya3MgKDE1IG1pbnV0ZXMpDQogICAgICAgIDEpIFJTZXJQb29sIEFwcGxpY2FiaWxpdHkgKFRo b21hcywgMTAgbWludXRlcykNCiAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtZHJlaWJob2x6LXZuZnBvb2wtcnNlcnBvb2wtYXBwbGljLw0KDQpDb21tZW50cyBh dCBtaWNyb3Bob25lLCBkaXNjdXNzaW9uIHBvaW50cyBhbmQgYWN0aW9uczoNCg0KLSBTdWdnZXN0 aW9uIHRoYXQgdGhlIFJTZXJQb29sIHdvcmsgc2hvdWxkIGhhdmUgYmVlbiBwcmVzZW50ZWQgZmly c3QgKERhdmUgRHlzYW4pIA0KDQotIElmIHVzZWQsIHRoZSBSU2VyUG9vbCB3b3JrIGlzIEV4cGVy aW1lbnRhbCAoU3RhdHVzKSBzbyB3b3VsZCBoYXZlIHRvIGJlIHB1Ymxpc2hlZCBhcyBTdGFuZGFy ZHMgVHJhY2suIA0KDQotIFJTZXJQb29sIHdvcmsgd2FzIHNodXRkb3duIHllYXJzIGFnbywgYnV0 IGl0IHJlcHJlc2VudHMgYW4gb3Bwb3J0dW5pdHkgdG8gcmVzdGFydCBhbmQgZGV2ZWxvcCBhcyBu ZWVkZWQuDQoNCi0gW05UVCBwZXJzb24pOiBXb3VsZCB0aGVyZSBiZSBtdWx0aXBsZSBuZXR3b3Jr IGZ1bmN0aW9ucyBvcGVyYXRpbmcgYXMgVk5GIFBvb2xzPyANCg0KLSBTdWdnZXN0aW9uIHRoYXQg U0NUUCBpcyB1c2VkIGJ1dCBNU0NUUCBtaWdodCBiZSBhbiBhbHRlcm5hdGl2ZSAoUmFuZGFsbCBT dGV3YXJ0LCBKYWJiZXIpIA0KDQotIEFyZSB0aGUgYXNzdW1wdGlvbnMgcHJldmlvdXMgdXNlZCBp biB0aGUgZGV2ZWxvcG1lbnQgb2YgUlNlclBvb2wgc3RpbGwgdmFsaWQ/IA0KDQotIFN5c3RlbSBh cmNoaXRlY3R1cmUgc2hvdWxkIGhhdmUgaW5oZXJlbnQgcmVkdW5kYW5jeSwgdGhlIFtSU2VyUG9v bCBhdXRob3JzXSBzaG91bGQgYW5hbHlzZSB0aGUgaW1wYWN0IG9mIFJTZXJQb29sLiANCg0KLSBB IG51bWJlciBvZiBmdXR1cmUgcmVzZWFyY2ggaXMgZG9jdW1lbnRlZCBpbiBSU2VyUG9vbCBOZXh0 IEdlbmVyYXRpb24gSS1ELg0KDQotIFJTZXJQb29sIHdpbGwgcmVxdWlyZSA2NCBiaXQgY2FwYWJp bGl0eS4NCg0KMTA6NTAgQ2hhcnRlciBEaXNjdXNzaW9uICgzMCBtaW51dGVzKQ0KICAgICAgICAN CiAgICAgICAgMSkgQ2hhcnRlciAoQ2hhaXJzLCA1IG1pbnV0ZXMpDQogICAgICAgIGh0dHA6Ly93 d3cuaWV0Zi5vcmcvbWFpbC0NCiAgICAgICAgYXJjaGl2ZS93ZWIvdm5mcG9vbC9jdXJyZW50L21z ZzAwMjI0Lmh0bWwNCiAgICAgICAgDQpDb21tZW50cyBhdCBtaWNyb3Bob25lLCBkaXNjdXNzaW9u IHBvaW50cyBhbmQgYWN0aW9uczoNCg0KLSBTb21lIGRpc2N1c3Npb24gYWxyZWFkeSBvbiBzY29w ZSBvZiBwcm90ZWN0aW9uIGZvciBib3RoIGludGVybmFsIGFuZCBleHRlcm5hbCBmdW5jdGlvbnMu ICBTb21lIGRpc2N1c3Npb24gb24gdGltZSBkaW1lbnNpb24gaW4gdGhlIHNjb3BlIG9mIHByb3Rl Y3Rpb24uICBBbHNvIHRoZSBwcm90ZWN0aW9uIG1heSBhbHNvIGJlIHBhcnRpY2lwYXRpbmcgaW4g YSBsYXJnZXIgcHJvdGVjdGlvbiBzY2hlbWUuDQoNCi0gV2hhdCBpcyB0aGUgc2VydmVyIGFwcGxp Y2F0aW9uIHRoYXQgaXMgYmVpbmcgZXhhbWluZWQ/ICBEb2VzIGl0IG5lZWQgcmVsaWFiaWxpdHkg b2YgcG9vbHM/IA0KDQotIFtKYW1hbCBTYWxpbV06IFRoZSBWTkYgcG9vbCBhcHBsaWNhdGlvbiBp cyBkZXNjcmliaW5nIGhpZ2ggYXZhaWxhYmlsaXR5IHRoYXQgTVBMUyBhbmQgR01QTFMgdXRpbGl6 ZS4gIEZvckNFUyBoYXMgSGlnaCBhdmFpbGFiaWxpdHkgYmFzZWQgb24gRm9yY2VzIHJ1bm5pbmcg b3ZlciBhIGNvbnRyb2wuICBCYXNlZCBvbiB0aGUgRm9yQ0VTIGV4cGVyaWVuY2UsIGl0IGlzIGlt cG9ydGFudCB0byBrbm93IGFyZSB0aGVzZSBmdW5jdGlvbnMgaGlnaGx5IGF2YWlsYWJsZSBvciBu b3Q/IA0KDQotIFt1bmtub3duXTogRG8gd2UgaGF2ZSBmbG93IHN0aXRjaGluZz8gIA0KDQotIE5v dCB0b3RhbCBhZ3JlZW1lbnQgdGhhdCB3b3JrIHNob3VsZCBiZSBpbmRlcGVuZGVudCBvZiBTRkMu IA0KDQotIEN1cnJlbnQgZmF0ZSBzaGFyaW5nLCBsb2FkIGJhbGFuY2luZywgcG9vbCBmdW5jdGlv biBhcmUgbm90IGZpdCBmb3IgcHVycG9zZS4gIFRoZXNlIGFyZSBwcm9ibGVtcyB0aGF0IG5lZWQg dG8gYmUgd29ya2VkIG9uLiANCg0KLSBVTklGWSBpcyBhIEV1cm9wZWFuIFJlc2VhcmNoIHByb2pl Y3QgaW52ZXN0aWdhdGluZyB0aGUgcHJvYmxlbSBzcGFjZSwgc29tZSBzaGFyZWQgZmluZGluZ3Mv ZGlzY3Vzc2lvbiBtYXkgYmUgYmVuZWZpY2lhbC4gIA0KDQotIEl0IHdvdWxkIGJlIHZhbHVhYmxl IHRvIGNvb3JkaW5hdGUgd2l0aGluIGEgVk5GUG9vbC4gSWYgeW91IGV4dGVuZCBpdCB0byBpbnRl ci1wb29scywgaXQgYmVjb21lcyAib3JjaGVzdHJhdGlvbiIuDQoNCi0gT2JzZXJ2YXRpb24gdGhh dCBhIHBvb2wgb2YgTkZzLCBpbiBhIHZpcnR1YWwgRlcgeW91IGhhdmUgaGlnaGVyIGZhaWx1cmUg cmF0ZS4gDQoNCi0gSGFyZHdpcmUgYmFzZWQgc29sdXRpb25zIGhhdmUgYnVpbHQgaW4gcmVkdW5k YW5jeSwgbmV0d29yayBmdW5jdGlvbiByZXNpbGllbmN5LCBhbmQgdGhlIGRyYWZ0cyAocHJvYmxl bSBvciB1c2UgY2FzZXMpIGRvIG5vdCBzdGF0ZSBob3cgdG8gdXNlIHRoaXMuDQoNCi0gU2NlcHRp Y2lzbSB0aGF0IGZsb3cgZm9yd2FyZGluZyAgc3RhdGUgc3luY2hyb25pc2F0aW9uIGNhbiBiZSBh Y2hpZXZlZC4gQWxzbyBkbyBvcGVyYXRvcnMgcmVhbGx5IHJlcXVpcmUgdGhpcyBjYXBhYmlsaXR5 PyANCg0KLSBRdWVzdGlvbjogV2hhdCBpcyBpbi1zY29wZSB2ZXJzdXMgb3V0LW9mLXNjb3BlPyAg RG8gd2UgaGFuZGxlIHNlcnZpY2Ugc3RhdGUgcmVjb3Zlcnk/ICANCg0KLSBUaGUgc2VydmljZSBz dGF0ZSByZWNvdmVyeSBpcyBiZXlvbmQgdGhlIHNjb3BlIG9mIFNGQy4NCg0KLSBbSmltIEJlZWNo ZXJdIFNlcnZpY2UgYXZhaWxhYmlsaXR5IGlzIG5vdCBpbiBzY29wZS4gDQoNCi0gW0VyaWMgTm9y ZG1hcmt9OiBBcmUgdGhlcmUgcGVvcGxlIHRoYXQgY2FuIGhlbHAgdXMgd2l0aCBmYXRlIHNoYXJp bmcgd2l0aGluIHRoZSBORlYgUG9vbCBmdW5jdGlvbnM/IA0KDQotIFtHZW9yZ2UgKGZyb20gR3Jl ZWNlKV06IEluIHRoZSB2aXJ0dWFsIGNsdXN0ZXJzIGZhdGUgc2hhcmluZywgbG9hZCBiYWxhbmNp bmcgYW5kIHBvb2wgZnVuY3Rpb25zIGFyZSBub3QgeWV0IHdvcmtpbmcuICANCg0KLSBMaW5kYSBE dW5iYXI6IFdoYXQgaGFwcGVucyBpZiBvbmUgaW5zdGFuY2UgZmFpbHMgd2hpY2ggaXMgbm90IGEg cm91dGluZyBpbnN0YW5jZT8gDQoNCi0gVGhvbWFzIE5hcnRlbjogU2NlcHRpY2FsIHdoZXRoZXIg SUVURiBoYXMgdGhlIGV4cGVydGlzZSB0byBleGFtaW5lIHRoZSBzdGF0ZSBzeW5jaHJvbml6YXRp b24gaXNzdWUuICBJRVRGIGRvZXMgbm90IGhhdmUgbGFyZ2UgYW1vdW50cyBvZiBmaXJld2FsbCB2 ZW5kb3JzLiANCg0KLSBbU3VlIEhhcmVzXTogVG9kYXkncyBhY2Nlc3MgZGV2aWNlcyBhbGwgY29u dGFpbiBmaXJzdCBsZXZlbCBmaXJld2FsbHMgc28gYWxsIGFjY2VzcyBkZXZpY2VzIGhhdmUgbm93 IGluc3RhbGxlZCBmaXJld2FsbHMuIFRoZSBtb3JlIGNvbW1vbiBmaXJld2FsbCBpcyB0aGlzIGZp cmV3YWxsIHdpdGhpbiB0aGUgYWNjZXNzIGRldmljZS4gDQoNCkFjdGlvbjogV2UgbmVlZCBhIGNv bW1vbiB1bmRlcnN0YW5kaW5nIGJldHdlZW4gVk5GIFBPT0wgYW5kIFNGQyBhcyB0byBzY29wZSBv ZiB3b3JrLiANCg0KQWN0aW9uOiBEZXRlcm1pbmUgc2NvcGUgb2YgcHJvdGVjdGlvbiBmb3IgaW50 ZXJuYWwgYW5kIGV4dGVybmFsIGZ1bmN0aW9ucy4gDQoNCkFjdGlvbjogQ29uc2lkZXIgd2hhdCBh cHBsaWNhdGlvbnMgKG9yIGNsYXNzIG9mIGFwcGxpY2F0aW9ucykgbWlnaHQgdXRpbGl6ZSBWTkYg UG9vbC4gDQoNCkFjdGlvbjogQ2xhcmlmeSB0aGUgYXJjaGl0ZWN0dXJlIGFzcGVjdCBvZiBWTkZQ T09MLCB3aGF0IGlzIGluIHNjb3BlLCANCmFuZCB3aGF0IGlzIG91dCBvZiBzY29wZS4gICANCg0K QWN0aW9uOiBEZWZpbml0aW9uIG9mIGEgVk5GLCBpcyB0aGVyZSBhIFZORiwgU0ZDIFZORiBhbmQg RVRTSSBWTkY/IFdoZXJlIGlzIG92ZXJsYXAsIGNhbiB3ZSBhZ3JlZSBkZWZpbml0aW9ucy4gDQoN CkFjdGlvbjogT3BlcmF0b3JzIG5lZWQgdG8gZGlzY3VzcyBpZiBGVyBzdGF0ZSBzeW5jaHJvbmlz YXRpb24sIG9yIGluZGVlZCBvdGhlciBORiBzdGF0ZSBzeW5jaHJvbmlzYXRpb24sIGlzIGFjdHVh bGx5IHJlcXVpcmVkLiANCg0KQWN0aW9uOiBFeGFtaW5lIGhvdyB0aGUgbmVlZCBmb3IgaGlnaCBh dmFpbGFiaWxpdHkgaW1wYWN0cyB0aGUgVk5GIFBvb2wgZGVzaWduIGFuZCANCg0KQWN0aW9uOiBF eGFtaW5lIGZhaWx1cmVzIHNjZW5hcmlvcyBpZiBvbmUgaW5zdGFuY2UgZmFpbHMuIA0KDQpBY3Rp b246IEV4YW1pbmUgZXhpc3Rpbmcgc29sdXRpb25zIHRvIGRldGVybWluZSBpZiBzb21lIGV4aXN0 aW5nIElFVEYgcHJvdG9jb2wgb3IgZGVzaWduIGZpdHMgbW9zdCBvZiB0aGUgcGFyYW1ldGVycy4g IFRoaXMgaXMgdGhlIGNvbmNlcHQgb2YgcmUtdXNlIHJhdGhlciB0aGFuIHJlaW52ZW50IGR1ZSB0 byBOSUggKG5vdC1pbnZlbnRlZCBoZXJlKS4gDQoNCiAgICAgICAgMikgT3BlbiBEaXNjdXNzaW9u IChhbGwsIDI1IG1pbnV0ZXMpDQogICAgICAgIA0KMTE6MjAgV3JhcC11cCAoQ2hhaXJzLCAxMCBt aW51dGVzKQ0KDQoxMTozMCBFbmQNCg0K