Re: [vnfpool] Version 05 of VNFPool Problem Statement

["Susan Hares" <[e-mail]>]

Ning:

 

In looking at the diffs from -04 question, I delighted with at the clarity
of the restatement of much of the text.  

Kudos/Congratulations on the excellent job there.  I only hope I do as well
in the editing of documents. 

 

However one editorial issues: 

 

Section 5.6 

 

We do not work on other management aspects of the VNF such as scaling, or
load balancing, even though these aspects may be complementary to
reliability in order to provide network services. 

[I think you want to say .. Will do not plan to work on. ] 

 

On a few technical points, I'd like to opine

1.  Changes to Section 5.4 

 

5.4.  Interaction between VNF and Service Control Entity

 

   Some information needs to be exchanged between a VNF and the Service

   Control Entity when the Service Control Entity orchestrates a VNF

   Pool-enable VNF.  For example, how can a VNF Pool be addressed by the

   Service Control Entity?  A Pool Manager can advertise the locator

   (e.g., IP address) of the active instance - subject to dynamic due to

   failover.  It is also possible to use a virtual address for the whole

   VNF Pool (similar to RSerPool or VRRP), and map between virtual and

   actual addresses.  Moreover, when a live VNF instance goes out of

   service, how does the Service Control Entity learn which VNF instance

   will replace it, and learn the characteristic of the new instance?

 

[Sue's opine on] 

The addressing between the VNF and the Service Control entity is an
important part.  VRRP worked in the past for some of VNF/Service Control
Entity, but had failure points within servers with VMs, and 

Failures points across multiple servers with VMs. 

 

Are we allowing VNF pools to go across multiple servers in multiple
locations? 

Within a single machine with the right OS modifications, the VRRP has
simplicity

and a sub-second VRRP failover is possible. VRRP can expand to multiple
boxes,

and a subsecond failover is possible, but has additional requirements to 

instrument the sub-second failover between VMs. 

 

The point is . we should know from the past work with RSerPool and VRRP
where the issues with the can be.  The WG should be able to choose to:

a)  select existing protocols, 

b)  extend existing protocol, or 

c)  create new protocols. 

 

We should prefer a and b over c.  

[Sue opine off]

 

Is this what you are considering in this problem statement? If so, then your
draft really, really improves the clarity of the problem. 

 

Sue 

 

=====

 

By the way:  Opine -means to hold and state as one's opinion

 

From: vnfpool [mailto:[e-mail]] On Behalf Of Zongning
Sent: Monday, May 05, 2014 4:47 AM
To: [e-mail]
Subject: [vnfpool] Version 05 of VNFPool Problem Statement

 

Hi,

 

A new revision -05 of VNFPool Problem Statement I-D is posted as below:

http://www.ietf.org/id/draft-zong-vnfpool-problem-statement-05.txt

 

Many thanks to Qiang, Marco, and Georgios for your comments on -04 version.
I mainly incorporated your suggestions, as well as further clarified VNFPool
scope and relation to SFC.

 

Main changes:

1)       Update definition of VNF set to clarify the relation to VNF pools;

2)       Focus VNFPool scope to internal VNF, and interface between VNF and
Service Control Entity, *not* communications between VNFs;

3)       Change 5.4 to "Interaction between VNF and Service Control Entity";

4)       Emphasize that we currently assume VNF pool contains the instances
of same functional type, *not* different VNF components;

5)       Update 6.3 about VNFPool relation to SFC;

 

Please folks continue reviewing the new version. Your comments are ALWAYS
welcome!

 

-Ning