[vnfpool] My Notes on the VNFPool BoF Charter related discussion

["Mcdysan, David E" <[e-mail]>]

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