[vnfpool] Virtualized vs. physical network functions

[Melinda Shore]

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

[Dave Dolson]

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:vnfpool-***@ietf.org] On Behalf Of Melinda Shore
Sent: Thursday, May 08, 2014 4:00 PM
To: ***@ietf.org
Subject: [vnfpool] Virtualized vs. physical network functions

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

[k***@cs.utwente.nl]

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 [vnfpool-***@ietf.org] namens Melinda Shore [***@nomountain.net]
Verzonden: donderdag 8 mei 2014 21:59
Aan: ***@ietf.org
Onderwerp: [vnfpool] Virtualized vs. physical network functions

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
***@nomountain.net

"Software longa, hardware brevis."

[PEDRO ANDRES ARANDA GUTIERREZ]

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:***@tid.es
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

Post by Melinda Shore
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
"Software longa, hardware brevis."
_______________________________________________
vnfpool mailing list
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

[Linda Dunbar]

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:vnfpool-***@ietf.org] On Behalf Of PEDRO ANDRES ARANDA GUTIERREZ
Sent: Friday, May 09, 2014 2:14 AM
To: ***@ietf.org
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:***@tid.es
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

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
"Software longa, hardware brevis."
_______________________________________________
vnfpool mailing list
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
***@ietf.org

[PEDRO ANDRES ARANDA GUTIERREZ]

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

Best, /PA

Dr. Pedro A. Aranda Gutiérrez

Technology Exploration -
Network Innovation & Virtualisation

mailto:***@tid.es
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

Post by Linda Dunbar
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 :-) )

Post by Linda Dunbar
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.

Post by Linda Dunbar
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.

Post by Linda Dunbar
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.

Post by Linda Dunbar
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


________________________________

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:/

[Linda Dunbar]

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:vnfpool-***@ietf.org] On Behalf Of PEDRO ANDRES ARANDA GUTIERREZ
Sent: Saturday, May 10, 2014 2:00 AM
To: ***@ietf.org
Subject: Re: [vnfpool] Virtualized vs. physical network functions

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

Best, /PA

Dr. Pedro A. Aranda Gutiérrez

Technology Exploration -
Network Innovation & Virtualisation

mailto:***@tid.es
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

Post by Linda Dunbar
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 :-) )

Post by Linda Dunbar
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.

Post by Linda Dunbar
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.

Post by Linda Dunbar
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.

Post by Linda Dunbar
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


________________________________

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
***@ietf.org<mailto:***@ietf.org>
https://www.ietf.org/mailman/listinfo/vnfpool

[PEDRO ANDRES ARANDA GUTIERREZ]

Hi Linda,

Yes, it would do it!

Best,
/PA
Dr. Pedro A. Aranda Gutiérrez

Technology Exploration -
Network Innovation & Virtualisation

mailto:***@tid.es
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

De: Linda Dunbar <***@huawei.com<mailto:***@huawei.com>>
Fecha: martes, 27 de mayo de 2014 23:20
Para: PEDRO ANDRES ARANDA GUTIERREZ <***@tid.es<mailto:***@tid.es>>, "***@ietf.org<mailto:***@ietf.org>" <***@ietf.org<mailto:***@ietf.org>>
Asunto: RE: [vnfpool] Virtualized vs. physical network functions

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 hardwarebased service functions."


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

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

Best, /PA

Dr. Pedro A. Aranda Gutiérrez

Technology Exploration -
Network Innovation & Virtualisation

mailto:***@tid.es
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

Post by Linda Dunbar
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 :-) )

Post by Linda Dunbar
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.

Post by Linda Dunbar
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.

Post by Linda Dunbar
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.

Post by Linda Dunbar
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


________________________________

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
***@ietf.org<mailto:***@ietf.org>
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

[Zongning]

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

-Ning

发件人: vnfpool [mailto:vnfpool-***@ietf.org] 代衚 PEDRO ANDRES ARANDA GUTIERREZ
发送时闎: 2014幎5月28日 20:04
收件人: Linda Dunbar; ***@ietf.org
䞻题: Re: [vnfpool] Virtualized vs. physical network functions

Hi Linda,

Yes, it would do it!

Best,
/PA
Dr. Pedro A. Aranda Gutiérrez

Technology Exploration -
Network Innovation & Virtualisation

mailto:***@tid.es
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

De: Linda Dunbar <***@huawei.com<mailto:***@huawei.com>>
Fecha: martes, 27 de mayo de 2014 23:20
Para: PEDRO ANDRES ARANDA GUTIERREZ <***@tid.es<mailto:***@tid.es>>, "***@ietf.org<mailto:***@ietf.org>" <***@ietf.org<mailto:***@ietf.org>>
Asunto: RE: [vnfpool] Virtualized vs. physical network functions

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 hardwarebased service functions."


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

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

Best, /PA

Dr. Pedro A. Aranda Gutiérrez

Technology Exploration -
Network Innovation & Virtualisation

mailto:***@tid.es
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

Post by Linda Dunbar
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 :-) )

Post by Linda Dunbar
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.

Post by Linda Dunbar
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.

Post by Linda Dunbar
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.

Post by Linda Dunbar
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


________________________________

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
***@ietf.org<mailto:***@ietf.org>
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

[Susan Hares]

Dr. Pedro:

I think you have mentioned a very important point about costs. Data centers have a "fail in place" methodology to deal with hardware failure that reduces cost rather than have expensive hardware for servers or routers.

I want to also "ack" what you are saying regarding the 'soft' instructions. I have seen enterprises deploy next-gen solutions that are virtualized due to two abilities:

a) abilities to do partial deployment of new technology (may be a server or Virtual server gets added),
b) ability to reduce cost and increase uptime.

The VNF pools can provide back up in a partial deployment seamless across networks. I have deployments where just 10-15 servers in key spots with this type of VNF pool technology can greatly increase through (via virtual load balance, WAN optimizers, and firewalls).

Sue Hares

-----Original Message-----
From: vnfpool [mailto:vnfpool-***@ietf.org] On Behalf Of PEDRO ANDRES ARANDA GUTIERREZ
Sent: Saturday, May 10, 2014 3:00 AM
To: ***@ietf.org
Subject: Re: [vnfpool] Virtualized vs. physical network functions

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

Best, /PA

Dr. Pedro A. Aranda Gutiérrez

Technology Exploration -
Network Innovation & Virtualisation

mailto:***@tid.es
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

Post by Linda Dunbar
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 :-) )

Post by Linda Dunbar
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.

Post by Linda Dunbar
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.

Post by Linda Dunbar
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.

Post by Linda Dunbar
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


________________________________

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