Re: [vnfpool] Virtualized vs. physical network functions

[Linda Dunbar <[e-mail]>]

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:[e-mail]] On Behalf Of PEDRO ANDRES ARANDA GUTIERREZ
Sent: Friday, May 09, 2014 2:14 AM
To: [e-mail]
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.



Dr. Pedro A. Aranda Gutiérrez

Technology Exploration -
Network Innovation & Virtualisation

mailto:[e-mail]
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





El 08/05/14 21:59, "Melinda Shore" <[e-mail]> 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
>[e-mail]
>
>"Software longa, hardware brevis."
>
>_______________________________________________
>vnfpool mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/vnfpool


________________________________

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

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