Subject: [Nfvrg] Fwd: results of virtual IMS and virtual SBC testing using COTS hardware. Thanks.

From: "B. Khasnabish" <[email-masked]>
Date: Tue, 15 Dec 2015 12:35:11 -0500

..... In the tests, the *vIMS *& *vSBC *Cloud UniCore solutions achieved
*high *Call Attempts Per Second(*CAPS*) capacity and throughput
with *excellent *Mean Opinion Score (*MOS*) on a Commercial
Off-The-Shelf (*COTS*) Intel-based server.

(for more details, pls see below and at the following URL:
http://www.cn-c114.net/577/a931739.html)

​====================================================
​Telefonica Successfully Completes ZTE vIMS and vSBC Performance Tests in
Madrid NFV Reference Lab

Updated:2015/12/9 10:53

ZTE Corporation (0763.HK / 000063.SZ), a major international provider of
telecommunications, enterprise and consumer technology solutions for the
Mobile Internet, and Telefonica have jointly tested ZTE vIMS & vSBC VNFs,
part of ZTE’s Cloud UniCore portfolio, in Telefonica’s NFV Reference Lab in
Madrid, Spain. OpenMANO stack, the ground-breaking module for the easy
creation and deployment of complex network scenarios of Telefonica’s NFV
Reference Lab, was used to test ZTE’s solutions.

The objective of the tests was to benchmark the deployment and performance
of network functions virtualisation (NFV) solutions. The resulting data has
provided clear evidence of the performance range service providers can
expect from virtualised, software-based networking infrastructure.

The establishment of NFV benchmarks is part of a joint effort by both
companies within the Telefonica NFV Reference Lab framework. ZTE’s
virtualised evolved packet core (vEPC) was previously tested in
Telefonica’s Reference Lab as part of this effort.

Cloud UniCore is based on virtualisation technology with software and
hardware decoupling. Hardware resources are virtualised and various
applications can be deployed on the same virtualised hardware platform.
With the quick deployment capabilities of cloud computing, Cloud UniCore
shortens the configuration and provisioning process from several weeks to
several minutes, thus significantly enhancing agility of network expansion.
It also implements dynamic scalability of virtualised network functions to
eliminate capacity bottlenecks.

The vIMS & vSBC Cloud UniCore solutions were deployed on a set of virtual
machines (VM) which takes advantage of Intel? Xeon? processor-based servers
and the Intel? Data Plane Development Kit in order to meet the performance
required by the world's largest telecommunication and service providers.

In the tests, the vIMS & vSBC Cloud UniCore solutions achieved high Call
Attempts Per Second(CAPS)capacity and throughput with excellent Mean
Opinion Score(MOS)on a Commercial Off-The-Shelf (COTS) Intel?-based server.

The results delivered were outstanding, reaching Telefonica’s expected
performance levels and smooth deployment objectives which allowed the test
to be completed in a very short amount of time. ZTE and Telefonica will
continue testing other elements of ZTE’s NFV portfolio in the coming months.

Javier Gavilán, Planning and Technology Director at Telefonica- Global CTO
said: “Telefonica has been and will be quite active on the evolution of
network virtualisation technologies. With our NFV Reference Lab we aim to
help the ecosystem of partners and network equipment vendors to test and
develop virtualised network functions, so we are very pleased to
collaborate with ZTE, a reference partner in NFV.”

Antonio Elizondo, Head of Network Virtualisation Strategy at Telefonica
I+D-Global CTO said: “The performance of ZTE vIMS & vSBC Cloud UniCore
solutions is quite high and aligned with our expectations on a
well-designed VNF, as it is needed for its deployment in the commercial
network. We’re looking forward to continuing our work with ZTE, and
strengthening our collaboration in the NFV field.”

ZTE is committed to the development of NFV and cloud-based network
technologies, cooperating with operators and technology providers around
the world in proof of concept (PoC) projects. To date, ZTE’s virtualised
core network solutions are deployed in 5 commercial, and 28 trial projects
globally.
  Source:C114
​ ​====================================================

On Wed, Dec 2, 2015 at 11:03 AM, B. Khasnabish <[email-masked]> wrote:

> ​Dave, Diego,
>
> Many Thanks to both of you.
>
> We plan to address these comments/suggestions in a future version of this
> draft by
>
> (a) adding appropriate citations and reasons behind the assumptions ,
>
> ​(b) adopting a consistent definition,
>
> (c) exploring further the categories of COTS which are more suitable for
> reliable services
>
> (d) discussing any add-on features of COTS that  may make certain COTS
> hardware more suitable for reliable services than others
>
> (e) clearly mentioning the functions being simulated, and
>
> (f) exploring how the concept of silent error can be applied to both
> hardware and software.
>
> Once again, many thanks, and we looking forward to other suggestions and
> comments.
>
> Best.
>
> Bhumip
> ​
>
> Best.
> ​
>
>
> On Tue, Dec 1, 2015 at 12:36 PM, DIEGO LOPEZ GARCIA <
> [email-masked]> wrote:
>
>> Hi,
>>
>> <unchair_mode>
>>
>>  Just to express my support to all of Dave´s comments, and especially to
>> the suspicion you express as conclusion. I see a great value in this draft
>> from the point of view of strategies to achieve system-wide five-nines (or
>> even beyond), and don’t see the need to confront COTS vs special-purpose
>> telecom hardware.
>>
>> </unchair_mode>
>>
>> Be goode,
>>
>> On 1 Dec 2015, at 18:05 , Dave Dolson <[email-masked]> wrote:
>>
>> Some comments:
>>
>> 1. In the draft there is a premise that software errors on COTS hardware
>> are different from hardware/software errors on dedicated telecom equipment.
>> Obviously there could be silent hardware and software errors on any type of
>> device. If you are going to have this premise, I think there needs to be
>> some evidence, citation or explanation. In my career I have seen some
>> pretty nasty hardware defects. Some were fatal but some were silent. One
>> could claim that functional hardware flaws are *less* likely in COTS
>> hardware, based on wide adoption and wide testing base. And both types of
>> systems are largely controlled by software.
>>
>> 2. You state COTS machines have relaxed design criteria. Obviously this
>> is a huge generalization, not supported by any citations. Certainly there
>> are also custom hardware solutions with relaxed design criteria. I think
>> you need to be specific by referring to specific designs. E.g., RAM with
>> error correction? Dual power supplies? RAID disks? And in that case, you
>> should discuss hardware with or without such features, not “COTS vs.
>> traditional”.
>>
>> 3. Some of the language in the draft is derogatory or dismissive of COTS
>> equipment. I think you should avoid such language to be respectful of
>> different designs. (use of “cowboy manner”, “COTS hardware and all its
>> undesirable features”, “the COTS hardware and its related software are
>> notorious” …) Don’t treat the COTS systems as poorly designed; rather see
>> the design goals as different.
>>
>> 4. On the subject of five-9s, clearly the NFV approach is to create
>> five-9s at the *system* level vs. the level of the individual box. Can you
>> consistently adopt that definition? For example, it is confusing near the
>> end of section 5 when you say “the requirements for traditional five 9s
>> could be relaxed while keeping the same user experience in downtime.” Above
>> that you say “with only two 9s server availability, the five 9s server part
>> of  system availability can be achieved,” which I think is a more useful
>> statement.
>>
>> 5. I think it would be helpful if you explained the function of the
>> system being simulated. It seems like it is a database replicated on
>> several servers?
>>
>> My suspicion is that juxtaposing COTS vs. traditional telecom in this
>> draft is distracting from the value of your research. The silent error idea
>> could be applied to any type of hardware.
>>
>>
>> Sorry, but I’m not comfortable commenting on your theoretical analysis or
>> simulation. Yes, I know that's the main point of the work... But as seen
>> above, I find the assumptions about COTS vs. traditional telecom hardware
>> to undermine any conclusions.
>>
>>
>> -Dave
>>
>>
>>
>> From: Nfvrg [mailto:[email-masked] <[email-masked]>] On
>> Behalf Of B. Khasnabish
>> Sent: Saturday, October 17, 2015 8:24 PM
>> To: [email-masked]
>> Subject: [Nfvrg] Requesting review of and comments on
>> draft-mlk-nfvrg-nfv-​reliability-using-co​
>>
>> Dear All,
>> We have recently published a draft
>> (datatracker.ietf.org/doc/draft-mlk-nfvrg-nfv-reliability-using-cots/) on
>> "NFV Reliability using COTS Hardware" discussing the results of a recent
>> study on the feasibility of using Commercial Off-The-Shelf (COTS) hardware
>> for virtualized network functions in telecom equipment.
>> This draft is based on the presentation
>> (https://www.ietf.org/proceedings/92/slides/slides-92-nfvrg-9.pdf)
>> during IETF/IRTF-92 mtg. in Dallas, TX, USA on
>> the 26th of March 2015. This draft attempts to address the work item
>> no. 4 in the charter (http://datatracker.ietf.org/rg/nfvrg/charter/)
>>
>> -------------------------------------------------------------------------------
>> 4. Service Verification with Regards to Security and Resiliency
>> Reliability and security issues and relevant solutions related to the
>> nature of VNFs are the objectives of this work item.
>>
>> ----------------------------------------------------------------------------------
>> We are requesting your review of this draft and comments on it
>> so that we can update the draft ASAP.
>> Many thanks in advance for your kind attention.
>> Best.
>> Bhumip
>> =====================================================
>> _______________________________________________
>> Nfvrg mailing list
>> [email-masked]
>> https://www.irtf.org/mailman/listinfo/nfvrg
>>
>>
>> --
>> "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 y sus adjuntos se dirigen exclusivamente a su destinatario,
>> puede contener información privilegiada o confidencial y es para uso
>> exclusivo de la persona o entidad de destino. Si no es usted. el
>> destinatario indicado, queda notificado de que la lectura, utilización,
>> divulgación y/o copia sin autorización puede estar prohibida en virtud de
>> la legislación vigente. Si ha recibido este mensaje por error, le rogamos
>> que nos lo comunique inmediatamente por esta misma vía y proceda a su
>> destrucción.
>>
>> The information contained in this transmission is privileged and
>> confidential information intended only for the use of the individual or
>> entity named above. If the reader of this message is not the intended
>> recipient, you are hereby notified that any dissemination, distribution or
>> copying of this communication is strictly prohibited. If you have received
>> this transmission in error, do not read it. Please immediately reply to the
>> sender that you have received this communication in error and then delete
>> it.
>>
>> Esta mensagem e seus anexos se dirigem exclusivamente ao seu
>> destinatário, pode conter informação privilegiada ou confidencial e é para
>> uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o
>> destinatário indicado, fica notificado de que a leitura, utilização,
>> divulgação e/ou cópia sem autorização pode estar proibida em virtude da
>> legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos
>> o comunique imediatamente por esta mesma via e proceda a sua destruição
>>
>
>

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Tue, 15 Dec 2015 19:01:13 +0000

Hi Bhumip,

As NFVRG chair I’d like to request you to refrain from sending this kind of press releases through the NFVRG list. I hope that you’ll agree with me that this kind of communications is not relevant to the work of the group and follows a commercial style that is far from the open discussion on research and technical matters that is the goal of the NFVRG.

Thanks for your understanding.

Be goode,

On 15 Dec 2015, at 12:35 , B. Khasnabish <[email-masked]<mailto:[email-masked]>> wrote:

..... In the tests, the vIMS & vSBC Cloud UniCore solutions achieved
high Call Attempts Per Second(CAPS) capacity and throughput
with excellent Mean Opinion Score (MOS) on a Commercial
Off-The-Shelf (COTS) Intel-based server.

​====================================================
​Telefonica Successfully Completes ZTE vIMS and vSBC Performance Tests in Madrid NFV Reference Lab

Updated:2015/12/9 10:53

ZTE Corporation (0763.HK<http://0763.hk/> / 000063.SZ<http://000063.sz/>), a major international provider of telecommunications, enterprise and consumer technology solutions for the Mobile Internet, and Telefonica have jointly tested ZTE vIMS & vSBC VNFs, part of ZTE’s Cloud UniCore portfolio, in Telefonica’s NFV Reference Lab in Madrid, Spain. OpenMANO stack, the ground-breaking module for the easy creation and deployment of complex network scenarios of Telefonica’s NFV Reference Lab, was used to test ZTE’s solutions.

The objective of the tests was to benchmark the deployment and performance of network functions virtualisation (NFV) solutions. The resulting data has provided clear evidence of the performance range service providers can expect from virtualised, software-based networking infrastructure.

The establishment of NFV benchmarks is part of a joint effort by both companies within the Telefonica NFV Reference Lab framework. ZTE’s virtualised evolved packet core (vEPC) was previously tested in Telefonica’s Reference Lab as part of this effort.

Cloud UniCore is based on virtualisation technology with software and hardware decoupling. Hardware resources are virtualised and various applications can be deployed on the same virtualised hardware platform. With the quick deployment capabilities of cloud computing, Cloud UniCore shortens the configuration and provisioning process from several weeks to several minutes, thus significantly enhancing agility of network expansion. It also implements dynamic scalability of virtualised network functions to eliminate capacity bottlenecks.

The vIMS & vSBC Cloud UniCore solutions were deployed on a set of virtual machines (VM) which takes advantage of Intel? Xeon? processor-based servers and the Intel? Data Plane Development Kit in order to meet the performance required by the world's largest telecommunication and service providers.

In the tests, the vIMS & vSBC Cloud UniCore solutions achieved high Call Attempts Per Second(CAPS)capacity and throughput with excellent Mean Opinion Score(MOS)on a Commercial Off-The-Shelf (COTS) Intel?-based server.

The results delivered were outstanding, reaching Telefonica’s expected performance levels and smooth deployment objectives which allowed the test to be completed in a very short amount of time. ZTE and Telefonica will continue testing other elements of ZTE’s NFV portfolio in the coming months.

Javier Gavilán, Planning and Technology Director at Telefonica- Global CTO said: “Telefonica has been and will be quite active on the evolution of network virtualisation technologies. With our NFV Reference Lab we aim to help the ecosystem of partners and network equipment vendors to test and develop virtualised network functions, so we are very pleased to collaborate with ZTE, a reference partner in NFV.”

Antonio Elizondo, Head of Network Virtualisation Strategy at Telefonica I+D-Global CTO said: “The performance of ZTE vIMS & vSBC Cloud UniCore solutions is quite high and aligned with our expectations on a well-designed VNF, as it is needed for its deployment in the commercial network. We’re looking forward to continuing our work with ZTE, and strengthening our collaboration in the NFV field.”

ZTE is committed to the development of NFV and cloud-based network technologies, cooperating with operators and technology providers around the world in proof of concept (PoC) projects. To date, ZTE’s virtualised core network solutions are deployed in 5 commercial, and 28 trial projects globally.
  Source:C114
​ ​====================================================

On Wed, Dec 2, 2015 at 11:03 AM, B. Khasnabish <[email-masked]<mailto:[email-masked]>> wrote:
​Dave, Diego,

We plan to address these comments/suggestions in a future version of this draft by

(c) exploring further the categories of COTS which are more suitable for reliable services

(d) discussing any add-on features of COTS that  may make certain COTS hardware more suitable for reliable services than others

(f) exploring how the concept of silent error can be applied to both hardware and software.

Once again, many thanks, and we looking forward to other suggestions and comments.

Best.

Bhumip
​

Best.
​

On Tue, Dec 1, 2015 at 12:36 PM, DIEGO LOPEZ GARCIA <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

<unchair_mode>

 Just to express my support to all of Dave´s comments, and especially to the suspicion you express as conclusion. I see a great value in this draft from the point of view of strategies to achieve system-wide five-nines (or even beyond), and don’t see the need to confront COTS vs special-purpose telecom hardware.

</unchair_mode>

Be goode,

On 1 Dec 2015, at 18:05 , Dave Dolson <[email-masked]<mailto:[email-masked]>> wrote:

Some comments:

1. In the draft there is a premise that software errors on COTS hardware are different from hardware/software errors on dedicated telecom equipment. Obviously there could be silent hardware and software errors on any type of device. If you are going to have this premise, I think there needs to be some evidence, citation or explanation. In my career I have seen some pretty nasty hardware defects. Some were fatal but some were silent. One could claim that functional hardware flaws are *less* likely in COTS hardware, based on wide adoption and wide testing base. And both types of systems are largely controlled by software.

2. You state COTS machines have relaxed design criteria. Obviously this is a huge generalization, not supported by any citations. Certainly there are also custom hardware solutions with relaxed design criteria. I think you need to be specific by referring to specific designs. E.g., RAM with error correction? Dual power supplies? RAID disks? And in that case, you should discuss hardware with or without such features, not “COTS vs. traditional”.

3. Some of the language in the draft is derogatory or dismissive of COTS equipment. I think you should avoid such language to be respectful of different designs. (use of “cowboy manner”, “COTS hardware and all its undesirable features”, “the COTS hardware and its related software are notorious” …) Don’t treat the COTS systems as poorly designed; rather see the design goals as different.

4. On the subject of five-9s, clearly the NFV approach is to create five-9s at the *system* level vs. the level of the individual box. Can you consistently adopt that definition? For example, it is confusing near the end of section 5 when you say “the requirements for traditional five 9s could be relaxed while keeping the same user experience in downtime.” Above that you say “with only two 9s server availability, the five 9s server part of  system availability can be achieved,” which I think is a more useful statement.

5. I think it would be helpful if you explained the function of the system being simulated. It seems like it is a database replicated on several servers?

My suspicion is that juxtaposing COTS vs. traditional telecom in this draft is distracting from the value of your research. The silent error idea could be applied to any type of hardware.

Sorry, but I’m not comfortable commenting on your theoretical analysis or simulation. Yes, I know that's the main point of the work... But as seen above, I find the assumptions about COTS vs. traditional telecom hardware to undermine any conclusions.

-Dave

From: Nfvrg [mailto:[email-masked]] On Behalf Of B. Khasnabish
Sent: Saturday, October 17, 2015 8:24 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Nfvrg] Requesting review of and comments on draft-mlk-nfvrg-nfv-​reliability-using-co​

Dear All,
(datatracker.ietf.org/doc/draft-mlk-nfvrg-nfv-reliability-using-cots/<http://datatracker.ietf.org/doc/draft-mlk-nfvrg-nfv-reliability-using-cots/>) on
"NFV Reliability using COTS Hardware" discussing the results of a recent study on the feasibility of using Commercial Off-The-Shelf (COTS) hardware for virtualized network functions in telecom equipment.
[email-masked]<mailto:[email-masked]>

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]<mailto:[email-masked]>
Tel:    +34 913 129 041<tel:%2B34%20913%20129%20041>
Mobile: +34 682 051 091<tel:%2B34%20682%20051%20091>
----------------------------------

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

Dr Diego R. Lopez
Telefonica I+D

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: ANTONIO JOSE ELIZONDO ARMENGOL <[email-masked]>
Date: Tue, 15 Dec 2015 19:18:15 +0000

Hi Bhumip,

                As responsible of the tests that you have mentioned, let me clarify that tests were focused on performance (dataplane performance in mpps – for the vSBC - and control plane performance in caps – for the vIMS). These tests do not relate with the subject that was being discussed about achieving 5 nines availability with COTS servers.

BR,

                Antonio Elizondo

De: Nfvrg [mailto:[email-masked]] En nombre de DIEGO LOPEZ GARCIA
Enviado el: martes, 15 de diciembre de 2015 20:01
Para: B. Khasnabish <[email-masked]>
CC: [email-masked]
Asunto: Re: [Nfvrg] results of virtual IMS and virtual SBC testing using COTS hardware. Thanks.

Hi Bhumip,

Be goode,

Updated:2015/12/9 10:53

Best.

Bhumip
​

Best.
​

<unchair_mode>

</unchair_mode>

Be goode,

Some comments:

-Dave

Dear All,

Dr Diego R. Lopez
Telefonica I+D

Dr Diego R. Lopez
Telefonica I+D

---

From: "B. Khasnabish" <[email-masked]>
Date: Tue, 15 Dec 2015 17:09:01 -0500

​Hi Diego,

Sure, no problem, and we understand.

​Thanks a lot.​

Best.

Bhumip

​

On Tue, Dec 15, 2015 at 2:01 PM, DIEGO LOPEZ GARCIA <
[email-masked]> wrote:

> Hi Bhumip,
>
> As NFVRG chair I’d like to request you to refrain from sending this kind
> of press releases through the NFVRG list. I hope that you’ll agree with me
> that this kind of communications is not relevant to the work of the group
> and follows a commercial style that is far from the open discussion on
> research and technical matters that is the goal of the NFVRG.
>
> On 15 Dec 2015, at 12:35 , B. Khasnabish <[email-masked]> wrote:
>
>
> ZTE Corporation (0763.HK <http://0763.hk/> / 000063.SZ <http://000063.sz/>),
> a major international provider of telecommunications, enterprise and
> consumer technology solutions for the Mobile Internet, and Telefonica have
> jointly tested ZTE vIMS & vSBC VNFs, part of ZTE’s Cloud UniCore portfolio,
> in Telefonica’s NFV Reference Lab in Madrid, Spain. OpenMANO stack, the
> ground-breaking module for the easy creation and deployment of complex
> network scenarios of Telefonica’s NFV Reference Lab, was used to test ZTE’s
> solutions.
>
>>> Sorry, but I’m not comfortable commenting on your theoretical analysis
>>> or simulation. Yes, I know that's the main point of the work... But as seen
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário,
> pode conter informação privilegiada ou confidencial e é para uso exclusivo
> da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário
> indicado, fica notificado de que a leitura, utilização, divulgação e/ou
> cópia sem autorização pode estar proibida em virtude da legislação vigente.
> Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique
> imediatamente por esta mesma via e proceda a sua destruição
>

---

From: "B. Khasnabish" <[email-masked]>
Date: Tue, 15 Dec 2015 17:11:00 -0500

​Hi Antonio,

Yes, thanks for the clarifications, and we understand.

Best.

Bhumip

​

On Tue, Dec 15, 2015 at 2:18 PM, ANTONIO JOSE ELIZONDO ARMENGOL <
[email-masked]> wrote:

> Hi Bhumip,
>
>
>
>                 As responsible of the tests that you have mentioned, let
> me clarify that tests were focused on performance (dataplane performance in
> mpps – for the vSBC - and control plane performance in caps – for the
> vIMS). These tests do not relate with the subject that was being discussed
> about achieving 5 nines availability with COTS servers.
>
>
>
> BR,
>
>
>
>                 Antonio Elizondo
>
>
>
> *De:* Nfvrg [mailto:[email-masked]] *En nombre de *DIEGO LOPEZ
> GARCIA
> *Enviado el:* martes, 15 de diciembre de 2015 20:01
> *Para:* B. Khasnabish <[email-masked]>
> *CC:* [email-masked]
> *Asunto:* Re: [Nfvrg] results of virtual IMS and virtual SBC testing
> using COTS hardware. Thanks.
>
>
>
> Hi Bhumip,
>
>
>
> ..... In the tests, the *vIMS *& * vSBC *Cloud UniCore solutions achieved
>
> 2. You state COTS machines have relaxed design criteria. Obviously this is
> a huge generalization, not supported by any citations. Certainly there are
> also custom hardware solutions with relaxed design criteria. I think you
> need to be specific by referring to specific designs. E.g., RAM with error
> correction? Dual power supplies? RAID disks? And in that case, you should
> discuss hardware with or without such features, not “COTS vs. traditional”.
>
> 5. I think it would be helpful if you explained the function of the system
> being simulated. It seems like it is a database replicated on several
> servers?
>