Hi, Sue,
Thanks for review. See inline marked by [Ning].
·¢ŒþÈË: Susan Hares [mailto:***@ndzh.com]
·¢ËÍʱŒä: 2014Äê6ÔÂ6ÈÕ 5:16
ÊÕŒþÈË: Zongning; ***@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-***@ietf.org] On Behalf Of Zongning
Sent: Monday, May 05, 2014 4:47 AM
To: ***@ietf.org<mailto:***@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