[vnfpool] 答复: Version 05 of VNFPool Problem Statement

Zongning <zongning@huawei.com> Fri, 06 June 2014 02:29 UTC

From: Zongning <zongning@huawei.com>
To: Susan Hares <shares@ndzh.com>, "vnfpool@ietf.org" <vnfpool@ietf.org>
Thread-Topic: [vnfpool] Version 05 of VNFPool Problem Statement
Thread-Index: Ac9oPocGo3WIP3ImTQ6fDXxa8QDf+AYgcOKAABtK6FA=
Date: Fri, 6 Jun 2014 02:29:05 +0000
Message-ID: <B0D29E0424F2DE47A0B36779EC66677966141ED3@nkgeml501-mbs.china.huawei.com>
References: <B0D29E0424F2DE47A0B36779EC66677966117311@nkgeml501-mbs.china.huawei.com> <012c01cf8103$5929f280$0b7dd780$@ndzh.com>
In-Reply-To: <012c01cf8103$5929f280$0b7dd780$@ndzh.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
Content-Type: multipart/alternative; boundary="_000_B0D29E0424F2DE47A0B36779EC66677966141ED3nkgeml501mbschi_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/dClY6txp4J9fmF8f5E7iheGGJus
Subject: [vnfpool] =?gb2312?b?tPC4tDogIFZlcnNpb24gMDUgb2YgVk5GUG9vbCBQcm9i?= =?gb2312?b?bGVtIFN0YXRlbWVudA==?=
Precedence: list

Hi, Sue,

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

·¢¼þÈË: Susan Hares [mailto:shares@ndzh.com]
·¢ËÍÊ±¼ä: 2014Äê6ÔÂ6ÈÕ 5:16
ÊÕ¼þÈË: Zongning; vnfpool@ietf.org
Ö÷Ìâ: 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.

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

[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

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]

[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 ¨Cmeans to hold and state as one's opinion

From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of Zongning
Sent: Monday, May 05, 2014 4:47 AM
To: vnfpool@ietf.org<mailto:vnfpool@ietf.org>
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

[vnfpool] Version 05 of VNFPool Problem Statement Zongning
Re: [vnfpool] Version 05 of VNFPool Problem State… Susan Hares
[vnfpool] 答复: Version 05 of VNFPool Problem State… Zongning