Subject: Re: [vnfpool] VNF Pool bar BoF follow-up

From: lingli deng <[email-masked]>
Date: Thu, 28 Nov 2013 14:49:01 +0800

Hi Ning, Melinda and all,

As I understand it, the issue with " Better coordination of VNF instance
deployment" also covers the fact that a group of VNF instances backing up
each other is not necessarily as reliable as a group of physically
separated NF instances backing up each other, since a failure of a single
physical device would potentially cause both the main instance and its
backup instance to fall at the same time, if they are to be deployed on the
same physical platform.

And the things can be even more complicated, if there are also
application-level resilience mechanisms between different VNFs along a
logical service chain, which may have further implications and restrictions
on "safe" deployment consideration about VNF instances across different
pools.

Getting network/physical information was proposed at the Bar Bof at
Vancouver as a potential solution for the above issue.

While I am highly interested in solving the issue, I am not sure about that
simply to have the upper management level to be notified about physical
information is the right choice.

One may also be thinking about the other way around, having the physical
management layer to be notified about higher level constraints about
instance deployment and do the right thing.

Since in my opinion, there is a clear question but not so clear solution,
I'd prefer it to be a separate study item as in the earlier version of the
PS.

BR

Lingli

-----邮件原件-----

发件人: [email-masked]
[mailto:[email-masked]<[email-masked]>]
代表 Zongning

发送时间: 2013年11月14日 16:53

收件人: Melinda Shore; [email-masked]

主题: Re: [vnfpool] VNF Pool bar BoF follow-up

Hi, Melinda,

Thanks for your comments and suggestions. Please see inline.

> -----Original Message-----

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

> Behalf Of Melinda Shore

> Sent: Thursday, November 14, 2013 11:56 AM

> To: [email-masked]

> Subject: Re: [vnfpool] VNF Pool bar BoF follow-up

> Thank you again for putting together what I thought was a useful

> session, and thank you for the sandwiches and beer!

> A couple of points:

> I think it's really important to have

> a crisp, clear problem statement in a few sentences, what's sometimes

> called an "elevator pitch" (i.e. make your case in the time it takes

> to ride an elevator, although obviously the elevators in the Hyatt in

> Vancouver distort the time expectations ... ).  An actual charter

> would be much longer and more detailed, but I think a simple problem

> statement is a good place to start.

[Ning] I fully agree we need to get agreement on problem statement, before
working on the charter.

> One thing that I think is missing but really needs to be made both

> explicit and clear is what's meant by "reliable."

> It's one of those words, like "scalable" or "secure" that can mean any

> one of a number of things and should be explained both in terms of

> what's covered and what's not.

[][Ning] Ideally, "reliability" means "the ability of the a system to limit
disruption and return to normal when having fault, failure, etc.". But I
intend to limit our scope to a pooling architecture that enables
self-healing capability of VNF instances distributed in multiple pools in
case of instance transition or failure. This VNF pool can be regarded as a
underlying layer to support applications that may have various reliability
requirements.

> In this case an abstract might look something like:

> ========

> A vnfpool working group would focus on the problem of providing

> reliable VNF instances and service chains, where by "reliable"

> we mean <some text>.  The component problems that would need to be

> solved include:

> ========

> and then include your bullet points.  On "transport characteristics"

> I'd probably say something along the lines of . Identify and analyze

> transport characteristics for control plane

>   traffic (reliability, QoS, etc.)

> . Detailed analysis of transport security characteristics to provide

>   protection against known threats, and identification of an appropriate

>   trust model (with an eye towards key management)

[Ning] Thanks for the suggested text.

> I'm not sure I fully understand "Better coordination of VNF instance

> deployment with underlying network information, performed in VNF pool

> manager" and that may need some wordsmithing.

[Ning] I think the general idea is that network information (e.g. topology,
link status, etc.) needs to be considered during virtualized instance
deployment. Jan, I suppose you could elaborate a little bit more on this
issue? :-)

> I believe the most recently chartered working group in the Transport

> area is aqm, and it may be worthwhile taking a look at that to get a

> feel for what a successful charter looks like these days.

> Thanks again!

> Melinda

-Ning

_______________________________________________

vnfpool mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/vnfpool

-- 
邓灵莉/Lingli Deng
中国移动通信研究院/China Mobile Research Institute
e-mail: [email-masked]
tel: 15801696688-3367
mobile: 13810597148

---

From: "Diego R. Lopez" <[email-masked]>
Date: Thu, 28 Nov 2013 09:24:40 +0000

Hi,

I tend to agree with the idea of considering bi-directional exchange of information between the NFV management layer and the infrastructural one.

Be goode,

On 28 Nov 2013, at 07:49 , lingli deng wrote:

As I understand it, the issue with " Better coordination of VNF instance deployment" also covers the fact that a group of VNF instances backing up each other is not necessarily as reliable as a group of physically separated NF instances backing up each other, since a failure of a single physical device would potentially cause both the main instance and its backup instance to fall at the same time, if they are to be deployed on the same physical platform.

And the things can be even more complicated, if there are also application-level resilience mechanisms between different VNFs along a logical service chain, which may have further implications and restrictions on "safe" deployment consideration about VNF instances across different pools.

Getting network/physical information was proposed at the Bar Bof at Vancouver as a potential solution for the above issue.
While I am highly interested in solving the issue, I am not sure about that simply to have the upper management level to be notified about physical information is the right choice.
One may also be thinking about the other way around, having the physical management layer to be notified about higher level constraints about instance deployment and do the right thing.

Since in my opinion, there is a clear question but not so clear solution, I'd prefer it to be a separate study item as in the earlier version of the PS.

BR
Lingli

-----邮件原件-----
发件人: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] 代表 Zongning
发送时间: 2013年11月14日 16:53
收件人: Melinda Shore; [email-masked]<mailto:[email-masked]>
主题: Re: [vnfpool] VNF Pool bar BoF follow-up

Hi, Melinda,

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On
> Behalf Of Melinda Shore
> To: [email-masked]<mailto:[email-masked]>

[Ning] I fully agree we need to get agreement on problem statement, before working on the charter.

> what's covered and what's not.

[][Ning] Ideally, "reliability" means "the ability of the a system to limit disruption and return to normal when having fault, failure, etc.". But I intend to limit our scope to a pooling architecture that enables self-healing capability of VNF instances distributed in multiple pools in case of instance transition or failure. This VNF pool can be regarded as a underlying layer to support applications that may have various reliability requirements.

> manager" and that may need some wordsmithing.

[Ning] I think the general idea is that network information (e.g. topology, link status, etc.) needs to be considered during virtualized instance deployment. Jan, I suppose you could elaborate a little bit more on this issue? :-)

-Ning

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

--
邓灵莉/Lingli Deng
中国移动通信研究院/China Mobile Research Institute
e-mail: [email-masked]<mailto:[email-masked]>
tel: 15801696688-3367
mobile: 13810597148
_______________________________________________
vnfpool mailing list
[email-masked]<mailto:[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