cenario analysis doc - general issues for VNF HA

Scenario Analysis doc - general issues for VNF HA
JIRA:HA 15

Change-Id: Iba2a6e467005b3bf332a04444564e69b92bc23dc

1 files changed, 19 insertions, 17 deletions

diff --git a/Scenario_1/scenario_analysis_VNF_external_interface.rst b/Scenario_1/scenario_analysis_VNF_external_interface.rst
index 7667993..c634c20 100644
--- a/Scenario_1/scenario_analysis_VNF_external_interface.rst
+++ b/Scenario_1/scenario_analysis_VNF_external_interface.rst
@@ -1,12 +1,13 @@
-2. Discussion for the General Issues for VNF HA schemes
+3. Communication Interfaces for VNF HA schemes
 ===========================================================
 
-This section is intended to talk about some general issues in the VNF HA schemes.
-In sections 1, the usecases of both stateful and stateless VNFs are discussed.
-While in this section, we would like to discuss some specific issues
-which are quite general for all the usecases proposed in the previous sections.
+This section will discuss some general issues about communication interfaces
+in the VNF HA schemes. In sections 2, the usecases of both stateful and
+stateless VNFs are discussed. While in this section, we would like to discuss
+some specific issues which are quite general for all the usecases proposed
+in the previous sections.
 
-1.1. VNF External Interfacece
+3.1. VNF External Interfacece
 
 Regardless whether the VNF is stateful or stateless, all the VNFCs should act as
 a union from the perspective of the outside world. That means all the VNFCs should
@@ -18,14 +19,15 @@ ignorant to the outside modules.
 There are several approaches for the VNFs to share the interfaces. A few of them
 are listed as follows and will be discussed in detail. 
 
-1) IP address of active/stand-by VM.
+1) IP address of VMs for active/stand-by VM.
 
 2) Load balancers for active/active use cases
 
 Note that combinition of these two approaches is also feasible.
 
-For active/standby VNFCs, the HA manager will manage a common IP address
-to the active and standby VMs, so that they look as one instance from outside.
+For active/standby VNFCs, there is a common IP address shared by the VMs hosting
+the active and standby VNFCs, so that they look as one instance from outside.
+The HA manager will manage the assignment of the IP address to the VMs.
 (The HA manager may not be aware of this, I.e. the address may be configured
 and the active/standby state management is linked to the possession of the IP
 address, i.e. the active VNFC claims it as part of becoming active.) Only the
@@ -38,27 +40,27 @@ manager and not provided. But as a concrete use case "provide" works fine.
 So it depends how you want to use this text.
 ..[fq] Agree, Thank you!
 
-For active/active VNFCs, LB(Load Balancer) could be used. In such scenario, there
+For active/active VNFCs, a LB(Load Balancer) could be used. In such scenario, there
 could be two cases for the deployment and usage of LB.
 
-Case 1: LB used before a cluster of VNFCs to distribute traffic flow.
+Case 1: LB used in front of a cluster of VNFCs to distribute the traffic flow.
 
 In such case, the LB is deployed in front of a cluster of multiple VNFCs. Such
-cluster can be managered by a seperate cluster manager, or can be managed just
-by the LB,  which is using heartbeat to monitor each VNFC. When one of VNFCs fails,
+cluster can be managed by a seperate cluster manager, or can be managed just
+by the LB,  which uses heartbeat to monitor each VNFC. When one of VNFCs fails,
 the cluster manager should recover the failed one, and should also exclude the 
 failed VNFC from the cluster so that the LB will re-route the traffic to
 to the other VNFCs. In the case when the LB is acting as the cluster manager, it is
 the LB's responsibility to inform the VNFM to recover the failed VNFC if possible.
 
 
-Case 2: LB used before a cluster of VMs to distribute traffic flow.
+Case 2: LB used in front of a cluster of VMs to distribute traffic flow.
 
 In this case, there exists a cluster manager(e.g. Pacemaker) to monitor and manage
 the VMs in the cluster. The LB sits in front of the VM cluster so as to distribute
-the traffic. When one of the VM fails, the cluster manager will ditect that and will
+the traffic. When one of the VM fails, the cluster manager will detect that and will
 be in charge of the recovery. The cluster manager will also exclude the failed VM
-out of the cluster, so that the LB won't re-route traffic to the failed one.
+out of the cluster, so that the LB won't route traffic to the failed one.
  
 In both two cases, the HA of the LB should also be considered.
 
@@ -75,7 +77,7 @@ actives but also M standbys at the VNF level.
 ..[fq] It could be. But I actually haven't see such a deployed case. So I am not sure
 if I can discribe the schemes correctly:)
 
-1.2. Intra-VNF Communication
+3.2. Intra-VNF Communication
 
 For stateful VNFs, data synchronization is necessary between the active and standby VMs.
 The HA manager is responsible for handling VNFC failover, and do the assignment of the