Subject: Re: [vnfpool] Version 05 of VNFPool Problem Statement

From: "Susan Hares" <[email-masked]>
Date: Thu, 5 Jun 2014 17:15:59 -0400

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:[email-masked]] On Behalf Of Zongning
Sent: Monday, May 05, 2014 4:47 AM
To: [email-masked]
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

---

From: Zongning <[email-masked]>
Date: Fri, 6 Jun 2014 02:29:05 +0000

Hi, Sue,

Thanks for review. See inline marked by [Ning].

发件人: Susan Hares [mailto:[email-masked]]
发送时间: 2014年6月6日 5:16
收件人: Zongning; [email-masked]
主题: RE: [vnfpool] Version 05 of VNFPool Problem Statement

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.

[Ning] Thanks.

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… ]

[Ning] We will still need to clean-up this part of content in the next revision before Toronto. Anyway, the current statement may be over-shooting, by excluding some useful mechanisms for VNFPool itself. We will make it more clear.

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

[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:

c)  create new protocols.

[Ning] Yes, we do prefer a & b, by further investigating and gap analyzing RSerPool, VRRP, and maybe more protocols.

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:[email-masked]] On Behalf Of Zongning
Sent: Monday, May 05, 2014 4:47 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [vnfpool] Version 05 of VNFPool Problem Statement

Hi,

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:

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;

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

-Ning