Subject: [vnfpool] Virtualized vs. physical network functions

From: Melinda Shore <[email-masked]>
Date: Thu, 08 May 2014 11:59:52 -0800

One of the things that came up at the BOF in London and that
hasn't received any subsequent discussion is the question of
the applicability of network function reliability based on
a pooling/redundancy model being applicable to network functions
running directly on hardware, in addition to virtualized
functions (as we've been discussing).  To be honest I'm still
not 100% clear on the issue and it would be helpful if
someone who's got opinions on the topic could take a whack at
it.

Thanks,

Melinda

-- 
Melinda Shore
No Mountain Software
[email-masked]

"Software longa, hardware brevis."

---

From: Dave Dolson <[email-masked]>
Date: Fri, 9 May 2014 04:23:19 +0000

At the BOF in London I asked why a solution should only be applicable to software running on a virtual machine vs. running on any machine.
The point of virtualization is that it is transparently so; it could be real or it could be virtual.

So I was scratching my head when some people were saying, "no, this must only be about virtual functions."

My understanding from the BoF was that the solutions will be applicable to any kind of network functions, but virtualization is driving the use cases, hence the name of the working group.

I'm satisfied with that answer.

So I'm assuming that the solution devised here could be applicable to a pool of software services, regardless of where they are running. Presumably the only requirement is that they reside at IP end-points.

Make sense?

David Dolson
Senior Software Architect, Sandvine Inc.

-----Original Message-----
From: vnfpool [mailto:[email-masked]] On Behalf Of Melinda Shore
Sent: Thursday, May 08, 2014 4:00 PM
To: [email-masked]
Subject: [vnfpool] Virtualized vs. physical network functions

Thanks,

Melinda

_______________________________________________
vnfpool mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vnfpool

---

From: <[email-masked]>
Date: Fri, 9 May 2014 05:27:34 +0000

Hi Melinda,

Please note that a reliability model for network functions running directly on hardware might be different than the reliability model for virtualized functions running on a virtualization platform. So, if we would want to support both, then we may need to broaden the scope of the WG, which we do not want.
So for the initial phase of the WG we could focus only on the reliability model for virtualized functions and as a second step (after re-chartering) we could see how the provided solutions could be applied to functions running directly on hardware.

Best regards,
Georgios

________________________________________
Van: vnfpool [[email-masked]] namens Melinda Shore [[email-masked]]
Verzonden: donderdag 8 mei 2014 21:59
Aan: [email-masked]
Onderwerp: [vnfpool] Virtualized vs. physical network functions

Thanks,

Melinda

---

From: PEDRO ANDRES ARANDA GUTIERREZ <[email-masked]>
Date: Fri, 09 May 2014 07:13:32 +0000

Hi

I¹d really wonder why we have the Œv¹ then but let¹s assume we drop it
(could it be that the Œv¹ is the cool letter of the day?) :-) Anyhow, just
going on with what I¹m learning with the CDN use caseŠ

Let¹s assume three major categories where we want to achieve resilience:
compute, storage and network.
Leaving  the virtualised vs. physical axis of the problem aside for one
moment, let¹s look at the possible resilience mechanisms.

In the network, you can use state of the art (HSRP, etc.) to make sure two
endpoints coordinate to take care that a specific connection is not lost.
Going one step beyond that and looking at what we could do, then we could
even define a way to orchestrate the networking part and redirect traffic
towards a ¹stand-by¹ network function if there is evidence that an
Œactive¹ network function is unreachable.

As far as the compute part is concerned, we could use the same
orchestration mechanism to redirect traffic when the network function is
not responsive.

And regarding storage, we can look at two possibilities: local and remote
storage. If local storage fails, we can either treat the function as if it
was down and go back to the beginning of this paragraph. Alternatively, we
could have the NF signal a storage failure and the orchestration find an
alternative remote storage location which the NF could use to resume
working. And this same mechanism could be used to treat the case when a NF
is using remote storage only. It starts with a specific copy of the
storage and switches over to the backup copy.

In all cases, we need mechanisms to replicate the state to make sure that
the stand-by NF or storage can take over when a problem arises.

Now, going back to the Œv¹-word, and after this short recap of the
problem, I have to confess that the main difference (or advantage) of a
VNF versus a non-V NF is that you could create an instance of the NF
on-the-fly in case of failure, provided you are able to solve the state
replication issue.

Dr. Pedro A. Aranda Gutiérrez

Technology Exploration -
Network Innovation & Virtualisation

mailto:[email-masked]
Telefónica, Investigación y Desarrollo
C/ D. Ramón de la Cruz,84
28006 Madrid, Spain

Fragen sind nicht da, um beantwortet zu werden.
Fragen sind da, um gestellt zu werden.
Georg Kreisler

>someone who's got opinions on the topic could take a whack at

________________________________

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: Fri, 9 May 2014 22:40:50 +0000

Pedro, 

Are you saying that the physical boxes also have chance to fail, why VNFpool emphasizes so much on Virtualized Network Functions? 

Here is my take on this issue:

It is very likely that the physical devices, either compute or storage devices, have embedded restoration & protection mechanism. 

Take your storage example, many storage arrays have their own embedded protection mechanism. When a server write/read from a storage array, it doesn't know if the data is from stand-by devices. 

Whereas, in the virtualized environment, functions instantiated on virtual mechanism doesn't have its own protection mechanism. Therefore, the "high availability" requires the "coordination" among all the other instances, hopefully in the standard way. 

Linda

-----Original Message-----
From: vnfpool [mailto:[email-masked]] On Behalf Of PEDRO ANDRES ARANDA GUTIERREZ
Sent: Friday, May 09, 2014 2:14 AM
To: [email-masked]
Subject: Re: [vnfpool] Virtualized vs. physical network functions

Hi

I¹d really wonder why we have the Œv¹ then but let¹s assume we drop it (could it be that the Œv¹ is the cool letter of the day?) :-) Anyhow, just going on with what I¹m learning with the CDN use caseŠ

Let¹s assume three major categories where we want to achieve resilience:
compute, storage and network.
Leaving  the virtualised vs. physical axis of the problem aside for one moment, let¹s look at the possible resilience mechanisms.

In the network, you can use state of the art (HSRP, etc.) to make sure two endpoints coordinate to take care that a specific connection is not lost.
Going one step beyond that and looking at what we could do, then we could even define a way to orchestrate the networking part and redirect traffic towards a ¹stand-by¹ network function if there is evidence that an Œactive¹ network function is unreachable.

As far as the compute part is concerned, we could use the same orchestration mechanism to redirect traffic when the network function is not responsive.

And regarding storage, we can look at two possibilities: local and remote storage. If local storage fails, we can either treat the function as if it was down and go back to the beginning of this paragraph. Alternatively, we could have the NF signal a storage failure and the orchestration find an alternative remote storage location which the NF could use to resume working. And this same mechanism could be used to treat the case when a NF is using remote storage only. It starts with a specific copy of the storage and switches over to the backup copy.

In all cases, we need mechanisms to replicate the state to make sure that the stand-by NF or storage can take over when a problem arises.

Now, going back to the Œv¹-word, and after this short recap of the problem, I have to confess that the main difference (or advantage) of a VNF versus a non-V NF is that you could create an instance of the NF on-the-fly in case of failure, provided you are able to solve the state replication issue.

Technology Exploration -

mailto:[email-masked]

El 08/05/14 21:59, "Melinda Shore" <[email-masked]> escribió:

>One of the things that came up at the BOF in London and that hasn't 
>received any subsequent discussion is the question of the applicability 
>of network function reliability based on a pooling/redundancy model 
>being applicable to network functions running directly on hardware, in 
>addition to virtualized functions (as we've been discussing).  To be 
>honest I'm still not 100% clear on the issue and it would be helpful if 
>someone who's got opinions on the topic could take a whack at it.
>
>Thanks,
>
>Melinda
>
>--
>Melinda Shore
>No Mountain Software

---

From: PEDRO ANDRES ARANDA GUTIERREZ <[email-masked]>
Date: Sat, 10 May 2014 07:00:12 +0000

Hi Linda,
Congratulations for reading through a coding mess :-) Answers inline,

Best, /PA

Technology Exploration -

mailto:[email-masked]

El 10/05/14 00:40, "Linda Dunbar" <[email-masked]> escribió:

>Pedro,
>
>Are you saying that the physical boxes also have chance to fail, why
>VNFpool emphasizes so much on Virtualized Network Functions?

Yes, physical boxes also tend to fail (in the worst possible moment, if
you believe in Murphy’s law :-) )

>It is very likely that the physical devices, either compute or storage
>devices, have embedded restoration & protection mechanism.

OK, but at what price? If you want to keep costs at a reasonable level,
you will probably go to a virtualised environment, with HW that is more
cost effective and with simpler mechanisms for resilience.

>Take your storage example, many storage arrays have their own embedded
>protection mechanism. When a server write/read from a storage array, it
>doesn't know if the data is from stand-by devices.

Once again, I agree. But while many do, not all have it necessarily. This
is also a question of costs. Thus we can’t take protection for granted in
‘discrete’ boxes.

>Whereas, in the virtualized environment, functions instantiated on
>virtual mechanism doesn't have its own protection mechanism. Therefore,
>the "high availability" requires the "coordination" among all the other
>instances, hopefully in the standard way.

Completely agree. And hopefully we can use the same standard mechanisms in
cost effective physical (as opposed to virtualised) devices, too.

>Linda

My point is that I see network functions independently of the device that
implements them and whether this is a physical device or a virtualised
function. IMHO, hybrid environments tend to have the advantage of lowering
the entry barrier: continue using what you have deployes and press the
last dime out of it while introducing next-gen solutions in a virtualised
environment that is more cost-effective than your current system. This
‘soft’ introduction also alleviates the pressure of having to cope with
something completely new on network admins.

Best,/PA

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 27 May 2014 21:20:16 +0000

Pedro,

I see your point. Do you think adding the following sentence at the end of the Section 1 can address the issues you brought up?

"It worth noting that the proposed mechanism also works for unprotected hardware based service functions."

Linda
-----Original Message-----
From: vnfpool [mailto:[email-masked]] On Behalf Of PEDRO ANDRES ARANDA GUTIERREZ
Sent: Saturday, May 10, 2014 2:00 AM
To: [email-masked]
Subject: Re: [vnfpool] Virtualized vs. physical network functions

Hi Linda,

Best, /PA

Technology Exploration -

mailto:[email-masked]

>VNFpool emphasizes so much on Virtualized Network Functions?

Yes, physical boxes also tend to fail (in the worst possible moment, if you believe in Murphy’s law :-) )

>devices, have embedded restoration & protection mechanism.

OK, but at what price? If you want to keep costs at a reasonable level, you will probably go to a virtualised environment, with HW that is more cost effective and with simpler mechanisms for resilience.

>doesn't know if the data is from stand-by devices.

Once again, I agree. But while many do, not all have it necessarily. This is also a question of costs. Thus we can’t take protection for granted in ‘discrete’ boxes.

>instances, hopefully in the standard way.

Completely agree. And hopefully we can use the same standard mechanisms in cost effective physical (as opposed to virtualised) devices, too.

>Linda

My point is that I see network functions independently of the device that implements them and whether this is a physical device or a virtualised function. IMHO, hybrid environments tend to have the advantage of lowering the entry barrier: continue using what you have deployes and press the last dime out of it while introducing next-gen solutions in a virtualised environment that is more cost-effective than your current system. This ‘soft’ introduction also alleviates the pressure of having to cope with something completely new on network admins.

Best,/PA

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

---

From: PEDRO ANDRES ARANDA GUTIERREZ <[email-masked]>
Date: Wed, 28 May 2014 12:04:28 +0000

Hi Linda,

Yes, it would do it!

Best,
/PA

Technology Exploration -

mailto:[email-masked]

De: Linda Dunbar <[email-masked]<mailto:[email-masked]>>
Fecha: martes, 27 de mayo de 2014 23:20
Para: PEDRO ANDRES ARANDA GUTIERREZ <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Asunto: RE: [vnfpool] Virtualized vs. physical network functions

Pedro,

"It worth noting that the proposed mechanism also works for unprotected hardwarebased service functions."

Linda
-----Original Message-----
From: vnfpool [mailto:[email-masked]] On Behalf Of PEDRO ANDRES ARANDA GUTIERREZ
Sent: Saturday, May 10, 2014 2:00 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [vnfpool] Virtualized vs. physical network functions

Hi Linda,

Best, /PA

Technology Exploration -

mailto:[email-masked]

Best,/PA

---

From: Zongning <[email-masked]>
Date: Thu, 29 May 2014 00:02:36 +0000

Thanks, Linda and Pedro. I will put some words in PS draft to reflect this.

-Ning

发件人: vnfpool [mailto:[email-masked]] 代表 PEDRO ANDRES ARANDA GUTIERREZ
发送时间: 2014年5月28日 20:04
收件人: Linda Dunbar; [email-masked]
主题: Re: [vnfpool] Virtualized vs. physical network functions

Hi Linda,

Yes, it would do it!

Best,
/PA

Technology Exploration -

mailto:[email-masked]

Pedro,

Linda
-----Original Message-----
From: vnfpool [mailto:[email-masked]] On Behalf Of PEDRO ANDRES ARANDA GUTIERREZ
Sent: Saturday, May 10, 2014 2:00 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [vnfpool] Virtualized vs. physical network functions

Hi Linda,

Best, /PA

Technology Exploration -

mailto:[email-masked]

Best,/PA