Subject: Re: [vnfpool] Question about addressing in pools

From: "Diego R. Lopez" <[email-masked]>
Date: Mon, 02 Dec 2013 09:32:17 +0000

Hi Melinda,

I agree you have a point here. And one of the reasons for using rserpool or similar mechanisms would be precisely to have those address management in place. May be a better wording would be something like "Any instance of VNF#1 can be sure it will be talking with an appropriate instance of VNF#2"

Be goode,

On 29 Nov 2013, at 23:18 , Melinda Shore wrote:

> It's typically the case in a stateful failover scenario that
> when a device has a given address (or set of addresses), after
> a failover the new instance has the same address.  The current
> version of the problem statement includes the following text:
> "For example, how does an instance of VNF#1 know which instance
> in the pool of VNF#2"?
>
> It seems to me that unless we're assuming the use of hardware
> addressing we should probably explain why this is an issue.
> If we go with rserpool or a similar mechanism, addresses are
> not shared but instead a pool manager (such as an ENRP server)
> is used to select "live" instances and addressing is mediated
> through the pooling mechanism.
>
> It seems to me that we should probably be prepared to discuss
> the tradeoffs between the two approaches.
>
> Melinda
> --
> Melinda Shore
> No Mountain Software
> [email-masked]
>
> "Software longa, hardware brevis."
> _______________________________________________
> vnfpool mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vnfpool

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 3 Dec 2013 19:25:58 +0000

I think that it is the "VNF#2 pool manager" that will determine which instance in VNF#2 will be fail-over one, and is responsible for passing this VNF#2's failover instance address to "VNF#1 pool manager". 

Linda

> -----Original Message-----
> From: vnfpool [mailto:[email-masked]] On Behalf Of Diego R.
> Lopez
> Sent: Monday, December 02, 2013 3:32 AM
> To: Melinda Shore
> Cc: [email-masked]
> Subject: Re: [vnfpool] Question about addressing in pools
> 
> Hi Melinda,
> 
> I agree you have a point here. And one of the reasons for using
> rserpool or similar mechanisms would be precisely to have those address
> management in place. May be a better wording would be something like
> "Any instance of VNF#1 can be sure it will be talking with an
> appropriate instance of VNF#2"
> 
> Be goode,
> 
> Este mensaje se dirige exclusivamente a su destinatario. Puede
> consultar nuestra política de envío y recepción de correo electrónico
> en el enlace situado más abajo.
> This message is intended exclusively for its addressee. We only send
> and receive email on the basis of the terms set out at:

---

From: Melinda Shore <[email-masked]>
Date: Tue, 03 Dec 2013 10:40:47 -0900

On 12/3/13 10:25 AM, Linda Dunbar wrote:
> I think that it is the "VNF#2 pool manager" that will determine which
> instance in VNF#2 will be fail-over one, and is responsible for
> passing this VNF#2's failover instance address to "VNF#1 pool
> manager".

I think it might be a little early to assume that.  It's generally
the case in HA scenarios that when there's a failover clients/endpoints
do not know that they are talking to what a different box (or virtual
box).  In rserpool endpoints find and access services through
ENRP - that is to say, unmodified clients can't take advantage
of the pooling mechanism.  I think we need to be clear about
that.

Melinda

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 3 Dec 2013 19:46:00 +0000

Melinda, 

Agree what you said there. 
But I think it is too messy for the instances in VNF#1 to be aware of different addresses of other instances. Maybe virtual address for VNF#2 can be used?

Linda

> From: vnfpool [mailto:[email-masked]] On Behalf Of Melinda
> Shore
> Sent: Tuesday, December 03, 2013 1:41 PM
> To: [email-masked]

---

From: Melinda Shore <[email-masked]>
Date: Tue, 03 Dec 2013 10:54:11 -0900

On 12/3/13 10:46 AM, Linda Dunbar wrote:
> Agree what you said there. But I think it is too messy for the
> instances in VNF#1 to be aware of different addresses of other
> instances. Maybe virtual address for VNF#2 can be used?

I think this is one of the issues we need to sort out as
we move towards a mature problem statement.  Or to put
it another way, do we expect clients to be modified or
unmodified?

Melinda

---

From: Qin Wu <[email-masked]>
Date: Wed, 4 Dec 2013 01:36:50 +0000

I think vNF#2 failover and replaced by VNF#1 means vNF#1 and vNF#2 has the same functionality.
If it is this case, why vNF#2 and vNF#1 with the same functionality should be managed by two different pool managers rather than
One common pool manager?

Even vNF#2 and vNF#1 has different functionality or provide different service, can vNF#2 and vNF#1 be managed by the common pool manager?
If we place the pool manger in NFV architecture specified by ETSI NFV? What the position of pool manager in such NFV architecture? Who manage vNF? Hypervisor, controller or orchestrator, or just hosted system?

I agree with Melinda the endpoint doesn't need to know whether he is talking to vNF#1 or vNF#2. What he needs to do is
Using something like name/address resolution mechanism to get the new address of backup vNF#2 when vNF#2 is down.

Regards!
-Qin
-----Original Message-----
From: vnfpool [mailto:[email-masked]] On Behalf Of Melinda Shore
Sent: Wednesday, December 04, 2013 3:41 AM
To: [email-masked]
Subject: Re: [vnfpool] Question about addressing in pools

Melinda

---

From: Melinda Shore <[email-masked]>
Date: Tue, 03 Dec 2013 16:51:19 -0900

On 12/3/13 4:36 PM, Qin Wu wrote:
> I agree with Melinda the endpoint doesn't need to know whether he is
> talking to vNF#1 or vNF#2. What he needs to do is Using something
> like name/address resolution mechanism to get the new address of
> backup vNF#2 when vNF#2 is down.

I'm not sure.  My real question is whether or not the endpoint
needs to be modified.

Melinda

---

From: Qin Wu <[email-masked]>
Date: Wed, 4 Dec 2013 02:01:01 +0000

What you said is endpoint relies on pooling mechanism and access service through ENRP while what I am saying is endpoint relies on name/address resolution mechanism to talk with pool manager and get the right vNF# instance.
Suppose one instance 1 fails, pool manger can provide another vNF instance 2 to the endpoint. Two instances share the same name and provide the same service.

I see no difference. Please correct me if I am wrong.

Regards!
-Qin
-----Original Message-----
From: Melinda Shore [mailto:[email-masked]] 
Sent: Wednesday, December 04, 2013 9:51 AM
To: Qin Wu
Cc: [email-masked]
Subject: Re: [vnfpool] Question about addressing in pools

Melinda

---

From: Melinda Shore <[email-masked]>
Date: Tue, 03 Dec 2013 17:06:25 -0900

On 12/3/13 5:01 PM, Qin Wu wrote:
> What you said is endpoint relies on pooling mechanism and access
> service through ENRP while what I am saying is endpoint relies on
> name/address resolution mechanism to talk with pool manager and get
> the right vNF# instance. Suppose one instance 1 fails, pool manger
> can provide another vNF instance 2 to the endpoint. Two instances
> share the same name and provide the same service.

Conventional HA deployments are transparent to endpoints,
requiring no additional software.  The IP address (not
really a fan of layering discussions but for the sake of
this discussion let's say layer 3) remains the same.  The
endpoint may see a very brief interruption but that's it.
In a pooling deployment the endpoint must have additional
software providing both name/directory services for a
pooled service plus session layer management.  I
believe that we're talking about a pooled scenario but
we really do need to be thorough as we move towards a
mature problem statement, if for no other reason than
wanting to encounter fewer surprises as chartering
discussions get underway.

Melinda

---

From: Qin Wu <[email-masked]>
Date: Wed, 4 Dec 2013 02:23:24 +0000

You are right, I am talking about tradition pooling technology, i.e.,rserpool. 
I am not familiar with other pooling technology(maybe zookeeper).
I agree the session will be interrupted if the address for VNF is not kept the 
same. The endpoint will know if the address for VNF changes.

So I am wondering if you are going to recommend to add service/session continuity
as a requirement during VNF failover.

Regards!
-Qin
-----Original Message-----
From: vnfpool [mailto:[email-masked]] On Behalf Of Melinda Shore
Sent: Wednesday, December 04, 2013 10:06 AM
To: [email-masked]
Subject: Re: [vnfpool] Question about addressing in pools

Melinda

---

From: Zongning <[email-masked]>
Date: Wed, 4 Dec 2013 05:53:04 +0000

Hi,

To be clear, in our examples in problem statement text, VNF#1 and VNF#2 have different functions, like FW and LB.
Whether and how to deploy pool manager is implementation issue. One may even consider the case that pool elements are self-organized to select designated instance, like VRRP.
The basic problem here is that there need a mechanism associated with instance failover. It can be either RSerPool-like name resolution, or VRRP-like virtual address provisioning. Before choosing solution, obviously we need use cases.

-Ning

> From: vnfpool [mailto:[email-masked]] On Behalf Of Qin Wu
> Sent: Wednesday, December 04, 2013 9:37 AM
> To: Melinda Shore; [email-masked]
> If it is this case, why vNF#2 and vNF#1 with the same functionality should be
> managed by two different pool managers rather than
> One common pool manager?
> 
> Even vNF#2 and vNF#1 has different functionality or provide different service,
> can vNF#2 and vNF#1 be managed by the common pool manager?
> If we place the pool manger in NFV architecture specified by ETSI NFV? What
> the position of pool manager in such NFV architecture? Who manage vNF?
> Hypervisor, controller or orchestrator, or just hosted system?
> 
> I agree with Melinda the endpoint doesn't need to know whether he is talking
> to vNF#1 or vNF#2. What he needs to do is
> Using something like name/address resolution mechanism to get the new
> address of backup vNF#2 when vNF#2 is down.
> 
> Regards!
> -Qin

---

From: Zongning <[email-masked]>
Date: Wed, 4 Dec 2013 06:26:49 +0000

Sorry but my last several sentences were not concrete and helpful.
Personally I prefer the way that the failover process of the instance in VNF#1 pool is transparent to the instance in VNF#2 pool, to reduce the reliability overhead. But in order to achieve this goal, we still need HA associated mechanism amongst the instances in VNF#1 pool (or via pool manager) to maintain the active and standby instance, e.g. by health checking, active/standby announcement, etc.
My 2 cents.

-Ning

> From: vnfpool [mailto:[email-masked]] On Behalf Of Zongning
> Sent: Wednesday, December 04, 2013 1:53 PM
> To: Qin Wu; Melinda Shore; [email-masked]
> Whether and how to deploy pool manager is implementation issue. One may
> even consider the case that pool elements are self-organized to select
> designated instance, like VRRP.
> The basic problem here is that there need a mechanism associated with
> instance failover. It can be either RSerPool-like name resolution, or VRRP-like
> virtual address provisioning. Before choosing solution, obviously we need use
> cases.
> 
> -Ning
>

---

From: Qin Wu <[email-masked]>
Date: Wed, 4 Dec 2013 09:41:36 +0000

Why not active active failover?
You don't need to elect the active one. What you need to do is to detect failure first and redirect traffic away from failing one to another active one.

Regards!
-Qin
-----Original Message-----
From: Zongning 
Sent: Wednesday, December 04, 2013 2:27 PM
To: Zongning; Qin Wu; Melinda Shore; [email-masked]
Subject: RE: [vnfpool] Question about addressing in pools

-Ning

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 4 Dec 2013 15:32:45 +0000

Agree. 

Linda

> Sent: Wednesday, December 04, 2013 12:27 AM
> Personally I prefer the way that the failover process of the instance
> in VNF#1 pool is transparent to the instance in VNF#2 pool, to reduce
> the reliability overhead. But in order to achieve this goal, we still
> need HA associated mechanism amongst the instances in VNF#1 pool (or
> via pool manager) to maintain the active and standby instance, e.g. by
> health checking, active/standby announcement, etc.
> My 2 cents.
> 
> -Ning
> 
> > To be clear, in our examples in problem statement text, VNF#1 and
> VNF#2 have
> > different functions, like FW and LB.
> > > I think vNF#2 failover and replaced by VNF#1 means vNF#1 and vNF#2
> has the
> > > same functionality.

---

From: LAC Chidung <[email-masked]>
Date: Fri, 06 Dec 2013 18:13:48 +0100

"*Who manage vNF? Hypervisor, controller or orchestrator, or just hosted 
system?* "
If we refer to 
http://docbox.etsi.org/ISG/NFV/Open/Published/gs_NFV002v010101p.pdf
Figure 4 suggests that (of course, I may be wrong ...):
- each VNF has its own element management system (EMS); different VNFs 
from different vendors may be used to provide a certain network service
- the VNF Managers actions include (i) collecting data (OAM, etc.) from 
the VNFs and from the virtual infrastructure; (ii) providing scalability 
('out' to create a new VM, or 'in' to suppress a VM - a VM being an 
instance of a VNF)
- an unique orchestrator controlling the VNF Managers in a data center 
(cloud) environment, e.g., OpenStack
Best,
Chidung
PS: the hypervisor, e.g., KVM, is represented in this figure by the 
"Virtualisation Layer"

---

From: Qin Wu <[email-masked]>
Date: Mon, 9 Dec 2013 02:18:29 +0000

If Pool manger can be compared to VNF manager, then the standards interface we are really dealing with is the interface between EMS and VNF manager?
Not sure my understanding is correct.
Also I am wondering whether the interface between EMS and VNF manager is manage plane interface or control plane interface?

Regards!
-Qin
From: vnfpool [mailto:[email-masked]] On Behalf Of LAC Chidung
Sent: Saturday, December 07, 2013 1:14 AM
To: [email-masked]
Subject: Re: [vnfpool] Question about addressing in pools

"Who manage vNF? Hypervisor, controller or orchestrator, or just hosted system? "
If we refer to http://docbox.etsi.org/ISG/NFV/Open/Published/gs_NFV002v010101p.pdf
Figure 4 suggests that (of course, I may be wrong ...):
- each VNF has its own element management system (EMS); different VNFs from different vendors may be used to provide a certain network service
- the VNF Managers actions include (i) collecting data (OAM, etc.) from the VNFs and from the virtual infrastructure; (ii) providing scalability ('out' to create a new VM, or 'in' to suppress a VM - a VM being an instance of a VNF)
- an unique orchestrator controlling the VNF Managers in a data center (cloud) environment, e.g., OpenStack
Best,
Chidung
PS: the hypervisor, e.g., KVM, is represented in this figure by the "Virtualisation Layer"
Le 04/12/2013 02:36, Qin Wu a écrit :

One common pool manager?

Regards!

-Qin

-----Original Message-----

To: [email-masked]<mailto:[email-masked]>

manager".

that.

Melinda

vnfpool mailing list

[email-masked]<mailto:[email-masked]>

---

From: LAC Chidung <[email-masked]>
Date: Wed, 11 Dec 2013 15:19:05 +0100

A correction and a (partial) reply with the help of a colleague actively 
involved in ETSI NFV:
1) Although "VNFC (VNF Component)" is absent from the doc I mentioned 
and from the terminology doc 
(http://www.etsi.org/deliver/etsi_gs/NFV/001_099/003/01.01.01_60/gs_NFV003v010101p.pdf), 
it is included in on-going work at groups such as "Management & 
orchestration" and "Software architecture". As a VNF is made of VNFCs, a 
VM is thus an instance of a VNFC (and not of a VNF).
2) Management plane vs. control plane: a quite "philosophical" question 
- let's say that it is a real time management plane, i.e., very close to 
the control plane.
Best,
Chidung

Le 09/12/2013 03:18, Qin Wu a écrit :
>
> If Pool manger can be compared to VNF manager, then the standards 
> interface we are really dealing with is the interface between EMS and 
> VNF manager?
>
> Also I am wondering whether the interface between EMS and VNF manager 
> is manage plane interface or control plane interface?
>
> Regards!
>
> -Qin
>
> *From:*vnfpool [mailto:[email-masked]] *On Behalf Of *LAC 
> Chidung
> *Sent:* Saturday, December 07, 2013 1:14 AM
> *To:* [email-masked]
> *Subject:* Re: [vnfpool] Question about addressing in pools
>
> "*Who manage vNF? Hypervisor, controller or orchestrator, or just 
> hosted system?* "
> If we refer to 
> - the VNF Managers actions include (i) collecting data (OAM, etc.) 
> from the VNFs and from the virtual infrastructure; (ii) providing 
> scalability ('out' to create a new VM, or 'in' to suppress a VM - a VM 
> being an instance of a VNF)
>     To:[email-masked]  <mailto:[email-masked]>
>
>     [email-masked]  <mailto:[email-masked]>
>