[vnfpool] Comments on draft-zong-vnfpool-problem-statement-03.txt

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

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