Subject: Re: [vnfpool] VNF Pool Problem Statement

From: "Diego R. Lopez" <[email-masked]>
Date: Sun, 01 Dec 2013 18:18:38 +0000

Hi,

Fully agree with Richard here: The VNF pools could be used to construct the service chains defined in SFC or whatever other network function supported by the resource pools supported by the VNFPOOL constructs.

Be goode,

On 1 Dec 2013, at 06:42 , Y. Richard Yang wrote:

The discussion regarding FSC is a good one. Overall, I like the Problem Statement. Two concepts stand out: VNF and Service Chain, both are large concepts. The nice drawing by Linda helps, but I believe that this is a simplified illustration, as during the meeting Diego showed that the model can be more complex, if I understand him correctly. Does the intended WG want to build on top of these two specific concepts, or build a more general and hence reusable, modular solution? I see the more general solution approach as one possible way to decouple from the Service Chain definitions WG. To be concrete, the concepts from Chabby and rservpool appear to be general.

> During the Vancouver bar BoF, we also discussed the relation between VNF
> pool and FSC.

Sorry I was not there physically.

> We agreed that VNF pool will address different problem space.
> Assuming that some chaining mechanism has been defined in FSC regarding how
> to connect/chain the VNF instances, we focus on signaling related to
> resiliency, e.g. backup announcement, status notification, etc. So I’d see
> these two groups as complementary.

Ok, then we need to specify in the charter that the discussion in this
working group is orthogonal to the detail chaining header used or
chosen by the SFC group, and the way the two potential groups works
together.

>
> You are absolutely right that these two groups are related with each other.
> I can put some text in our proposed working scope to clarify this issue.
>
_______________________________________________
vnfpool mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/vnfpool
_______________________________________________
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

---

From: Zongning <[email-masked]>
Date: Mon, 2 Dec 2013 02:32:00 +0000

Hi, Richard and Diego,

Thanks for your comments.
Generally I agree with both of you. We develop general multi-pool mechanism on reliability perspective, hence decouple ourselves from any specific Service Chaining approach. As I replied to Zhen, the signaling to be developed in our group will be complementary to SFC. But, I don't want the intended solution to be too general to be done (or boiling the ocean). So, let's focus on problems based on a limited set of cases like VNF chain could be good starting point.

-Ning

From: Diego R. Lopez [mailto:[email-masked]]
Sent: Monday, December 02, 2013 2:19 AM
To: Y. Richard Yang
Cc: Cao,Zhen; <[email-masked]>; Mukhtiar Shaikh; Zongning
Subject: Re: [vnfpool] VNF Pool Problem Statement

Hi,

Be goode,

> resiliency, e.g. backup announcement, status notification, etc. So I'd see

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091

---

From: "Y. Richard Yang" <[email-masked]>
Date: Sun, 1 Dec 2013 22:06:03 -0500

Hi Ning,

Being focused definitely makes sense. Here is one question that the
proposed WG will need to resolve:

- What is an VNF?

There are multiple types of VNFs and vnfpool will depend on a "base class"
of these multiple types of VNFs, in the context of vnfpool. What does this
base class, in the context of vnfpool, define? There are three approaches:
(1) this is outside the scope of this WG, but is a prerequisite for the WG
to get started, or (2) this is a WG item? I feel that it is (2) in this
stage. Or it could be (1), and then who defines it?

Richard

On Sun, Dec 1, 2013 at 9:32 PM, Zongning <[email-masked]> wrote:

> Generally I agree with both of you. We develop general multi-pool
> mechanism on reliability perspective, hence decouple ourselves from any
> specific Service Chaining approach. As I replied to Zhen, the signaling to
> be developed in our group will be complementary to SFC. But, I don’t want
> the intended solution to be too general to be done (or boiling the ocean).
> So, let’s focus on problems based on a limited set of cases like VNF chain
> could be good starting point.
>
>
>
> -Ning
>
>
>
>
>
> *From:* Diego R. Lopez [mailto:[email-masked]]
> *Sent:* Monday, December 02, 2013 2:19 AM
> *To:* Y. Richard Yang
> *Cc:* Cao,Zhen; <[email-masked]>; Mukhtiar Shaikh; Zongning
>
> *Subject:* Re: [vnfpool] VNF Pool Problem Statement
>
>
>
> Hi,
>
>
>
> Fully agree with Richard here: The VNF pools could be used to construct
> the service chains defined in SFC or whatever other network function
> supported by the resource pools supported by the VNFPOOL constructs.
>
>
>
> Be goode,
>
>
>
>  The discussion regarding FSC is a good one. Overall, I like the Problem
> Statement. Two concepts stand out: VNF and Service Chain, both are large
> concepts. The nice drawing by Linda helps, but I believe that this is a
> simplified illustration, as during the meeting Diego showed that the model
> can be more complex, if I understand him correctly. Does the intended WG
> want to build on top of these two specific concepts, or build a more
> general and hence reusable, modular solution? I see the more general
> solution approach as one possible way to decouple from the Service Chain
> definitions WG. To be concrete, the concepts from Chabby and rservpool
> appear to be general.
>
> [email-masked]
> [email-masked]
>  ------------------------------
>
>
> 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:

-- 
-- 
 =====================================
| Y. Richard Yang <[email-masked]>   |
| Professor of Computer Science       |
| http://www.cs.yale.edu/~yry/        |
 =====================================

---

From: "Cao,Zhen" <[email-masked]>
Date: Mon, 2 Dec 2013 15:21:56 +0800

Good point, Diego.

I checked out the NFV ISG released documents of requirements and
terminology, where i could not find 'reliability' but 'resilience'.

-cz

On Wed, Nov 27, 2013 at 2:06 AM, Diego R. Lopez <[email-masked]> wrote:
> Hi,
>
> When it comes to the reliability/availability issue I guess providing some
> (condensed) definition from the NFV REL group would help...
>
> Be goode,
>
> On 26 Nov 2013, at 04:00 , Hidetoshi Yokota wrote:
>
> Hi Ning and all,
>
> The proposed PS is a very good starting point covering major issues for the
> goal of VNF pool. One thing that I could add is the synchronization between
> the vNF migration/replacement and routing to make the relevant flows
> forwarded to the new location. The challenge is that the VMs/severs in a
> pool could be deployed over topologically different networks (in the
> physical world) and VNF migration could involve topologically independent
> routing. There are multiple ways to do it, but we should first generalize
> this issue and specify a common mechanism that may leverage existing ones.
>
> If this is already covered, that's fine. If some additional text is useful,
> the following could be a summary:
>
> o Synchronization between vNF migration and flow forwarding, which may
> require topologically independent routing in the physical transport network;
>
> There is a discussion about "reliability" and "availability" in another
> thread and I think this is also an issue in ETSI NFV. We need to define them
> either in this group or NFV to share the same view.
>
> Regards,
>
> --
> Hidetoshi Yokota
>
> KDDI R&D Laboratories, Inc.
> e-mail:[email-masked]
>
>
> (2013/11/21 18:11), Zongning wrote:
>
> Hi,
>
>
>
> Please review the below brief version of VNF Pool Problem Statement, and
> feedback with your comments. I hope this text can serve as a base of VNF
> Pool Charter, by carving out real problems and work items.
>
>
>
> ===========================================================================================
>
> A virtualized network function (VNF) (e.g. vFW, vLB) provides the same
> function as the equivalent network function (e.g. FW, LB), but is usually
> instantiated as a cluster of software instances running on general purpose
> servers via virtualization platform. In an environment based on VNFs, a
> network service is typically realized by a chain of VNFs where the instances
> of adjacent VNFs are preferably directly connected.
>
>
>
> A VNF chain introduces additional points of failure beyond those inherent in
> a single dedicated server, and therefore additional challenges on
> reliability. By reliability, we mean the ability of a VNF chain to continue
> function when having transition or failure within the chain. For example,
> there are more factors such as software failure, server over-utilization,
> instance migration that potentially cause VNF instance transition or
> failure. Although a general pooling mechanism can be applied to address the
> reliability of a single VNF, there are still problems when addressing the
> reliability of a VNF chain, i.e. multiple pools for multiple VNFs. For
> example, how does an instance of VNF#1 know which instance in the pool of
> VNF#2 will replace the instance of VNF#2 it connects to? How does an
> instance of VNF#1 know the state of instance of VNF#2 that it connects to in
> order to enforce policy for reliability like load sharing, switch before
> break? How is the service state of an instance held and accessed for
> efficient synchronization with backup instances?
>
>
>
> The overall problem space can be further breakdown to the following study
> items:
>
> -          Signalling to handle reliability and instance transition
> requirements
>
> o   Signalling between VNF pools for transition (e.g. state change, scaling,
> moving) notification, backup announcement;
>
> o   Service state management (e.g. synchronizing method, state data format,
> location and mechanism to access state data) within VNF pool;
>
> o   Obtaining underlying network information (e.g. ALTO, I2RS);
>
> o   Signalling to CMS for instance deployment reflecting reliability
> requirements (e.g. distribution of instances on different VMs or
> hypervisors);
>
> -          Transport characteristics
>
> o   Identify and analyze reliable transport characteristics for control
> plane traffic;
>
> o   Analysis of transport security characteristics to provide protection
> against known threats, and identification of an appropriate trust model;
>
> ===========================================================================================
>
>
>
> Thanks.
>
>
>
> -Ning
>
>
>

---

From: "Cao,Zhen" <[email-masked]>
Date: Mon, 2 Dec 2013 16:13:47 +0800

I agree the discussion is one of good ones.

but two more questions to discuss:

a) Resilience of vnf pool is independent of the service chaining. Even
without service chain, the problem still exist. I do not know if you
agree.

b) The description in the text now seems not highly relevant to the
NFV context. Some description seems valid even without virtualisation
basis. Anyway service chain is not only a problem originating from
virtualisation but more general.  Do we need to find more vnf related
text, e.g., what's the difference between vnf reliability and none
virtualized system reliability.

Regards,
cz

On Sun, Dec 1, 2013 at 1:42 PM, Y. Richard Yang <[email-masked]> wrote:
> want to build on top of these two specific concepts, or build a more general
> and hence reusable, modular solution? I see the more general solution
> approach as one possible way to decouple from the Service Chain definitions
> WG. To be concrete, the concepts from Chabby and rservpool appear to be
> general.
>

---

From: Zongning <[email-masked]>
Date: Mon, 2 Dec 2013 09:17:23 +0000

Hi, Zhen and Richard,

Thanks for the comments.
Please allow me to combine your comments to a single one - "we need more descriptive text about VNF, as well as how it would impact reliability?" :-))
I plan to add more sentences as below (or similar) into the problem statement.

A virtualized network function (VNF) provides network functions (e.g. firewalling, load balancing), but typically can be modularized and decomposed as instance running on general server via virtualization layer. This is distinct from monolithic network devices, where a number of different services are provided in the same device... I think ETSI NFV has definitions on VNF, VNFC, etc. which VNF pool can follow upon and use as starting point.
In the context of NFV, network services are typically implemented by a set of sequentially connected VNF instances deployed at different points in the network...
The challenges to reliability would then include: 1) for a single virtual instance, it normally doesn't assume built-in high reliability mechanism implemented by dedicated device on its host (i.e. general server). Therefore redundancy model where the role of active, standby instance are more dynamic...; 2) Virtual instance migration would require standard based, efficient stateful failover especially in the case of multi-vendor VNF deployment...; 3) the topology nature of VNF chain may require additional reliability supports, e.g. failure/status notification between node within the chain...; <we can add more later>

-Ning

> -----Original Message-----
> From: vnfpool [mailto:[email-masked]] On Behalf Of Cao,Zhen
> Sent: Monday, December 02, 2013 4:14 PM
> To: Y. Richard Yang
> Cc: [email-masked]; Mukhtiar Shaikh; Zongning

---

From: LAC Chidung <[email-masked]>
Date: Mon, 02 Dec 2013 11:00:16 +0100

Hi all,
/Reliability is the ability of an item to perform a required function 
under stated conditions for a stated period of time/, while/Availability 
is a measure of the degree to which an item is in an operable state when 
called upon to perform./ (D.J. Klinger, Y. Nakada, and M.A. Menedez 
(Eds.), "AT&T Reliability Manual", Van Nostrand Reinhold, 1990)
Applied to the PSTN, the former includes "My call is not dropped during 
a conversation", while the latter asks for "The phone service is ready, 
i.e., a tone is present, whenever I lift the handset".
For years, /Dependability /has encompassed these concepts (together with 
others such as /Maintainability) /to characterize the good behavior 
(robustness) of a system when facing *accidental *events (design faults, 
operations errors, hardware failures, natural disasters, etc.) , while 
/Security, /which includes all *intentional *actions (attacks, ...), is 
kept apart. This explains the presence, up to now, of two communities 
working in these two separated subjects.
As (i) unavailability may the consequence of, e.g., software/hardware 
failures OR (D)DoS attacks (ii) /Resilience/ is a fashionable 
expression* (iii) etc., resilience is used since the last few years to 
encompass both dependability and security.
Best,
Chidung
_______
*: see, e.g., Obama's praise for the resilience of the Indian people 
(http://articles.latimes.com/2010/nov/06/world/la-fgw-obama-mumbai-20101107)

---

From: Qin Wu <[email-masked]>
Date: Tue, 3 Dec 2013 01:19:15 +0000

In my understanding, availability is more about "don't loss connection to the network at any time anywhere using any device" or ubiquity. The resilience should be used to support high availability as well.

If resilience doesn't mean high availability then resilience can be redefined to support high availability.

My 2 cents.

Regards!
-Qin
From: vnfpool [mailto:[email-masked]] On Behalf Of LAC Chidung
Sent: Monday, December 02, 2013 6:00 PM
To: [email-masked]
Subject: Re: [vnfpool] VNF Pool Problem Statement

Hi all,
Reliability is the ability of an item to perform a required function under stated conditions for a stated period of time, while Availability is a measure of the degree to which an item is in an operable state when called upon to perform. (D.J. Klinger, Y. Nakada, and M.A. Menedez (Eds.), "AT&T Reliability Manual", Van Nostrand Reinhold, 1990)
Applied to the PSTN, the former includes "My call is not dropped during a conversation", while the latter asks for "The phone service is ready, i.e., a tone is present, whenever I lift the handset".
For years, Dependability has encompassed these concepts (together with others such as Maintainability) to characterize the good behavior (robustness) of a system when facing accidental events (design faults, operations errors, hardware failures, natural disasters, etc.) , while Security, which includes all intentional actions (attacks, ...), is kept apart. This explains the presence, up to now, of two communities working in these two separated subjects.
As (i) unavailability may the consequence of, e.g., software/hardware failures OR (D)DoS attacks (ii) Resilience is a fashionable expression* (iii) etc., resilience is used since the last few years to encompass both dependability and security.
Best,
Chidung
_______
*: see, e.g., Obama's praise for the resilience of the Indian people (http://articles.latimes.com/2010/nov/06/world/la-fgw-obama-mumbai-20101107)
Le 02/12/2013 08:21, Cao,Zhen a écrit :

Good point, Diego.

-cz

On Wed, Nov 27, 2013 at 2:06 AM, Diego R. Lopez <[email-masked]><mailto:[email-masked]> wrote:

Hi,

Be goode,

Hi Ning and all,

Regards,

--

Hidetoshi Yokota

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

Hi,

items:

requirements

hypervisors);

plane traffic;

Thanks.

-Ning

--

Dr Diego R. Lopez

Telefonica I+D

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

Tel:    +34 913 129 041

Mobile: +34 682 051 091

situado más abajo.

vnfpool mailing list

---

From: Qin Wu <[email-masked]>
Date: Tue, 3 Dec 2013 01:35:54 +0000

[Qin]: Do we really care the difference between the system that is virtualized and the system that is
Not virtualized? It looks service chaining don't care.

Regarding the difference between vnf reliability and none virtualized system reliability, I can see
They share a lot of similarities. However vnf can be located anywhere, can be relocated anywhere,
Can follow some specific order in service chaining case and may need to deal with large number of 
requests from subscribers due to multi-tenancy, may need more dynamic configurations or provisions.
I doubt the performance of the system that is virtualized is far less than one of the system that is
Not virtualized.

---

From: "Cao,Zhen" <[email-masked]>
Date: Tue, 3 Dec 2013 17:39:25 +0800

> Not virtualized? It looks service chaining don't care.

[cz] If you do not care, nor do I. Because in the text, it starts with
'vnf'. I thought we are discussing the issues and problems caused by
virtualisation.  And the list is vnf-pool, anyway.

> They share a lot of similarities. However vnf can be located anywhere, can be relocated anywhere,

[cz] I am just concerned if we are going to talk about reliability
generally here.

---

From: Qin Wu <[email-masked]>
Date: Tue, 3 Dec 2013 10:03:34 +0000

Hi, Zhen:
-----Original Message-----
From: vnfpool [mailto:[email-masked]] On Behalf Of Cao,Zhen
Sent: Tuesday, December 03, 2013 5:39 PM
To: Qin Wu
Cc: [email-masked]; Mukhtiar Shaikh; Y. Richard Yang; Zongning
Subject: Re: [vnfpool] VNF Pool Problem Statement

[Qin]: You misunderstand what I said above. I am just asking question.
I want to know if people care the difference between virtualized system and physical system.
In service chain discussion, I fail to see they care or any discussion about distinguishing one from another.

[Qin]: Again, here I am just explaining what the difference is. I am wondering whether these difference has any
Impact on the VNF performance. I guess many of us assume VNF can achieve the same performance as the physical system that has
The same functionality. E.g., physical firewall can be replaced by vFirewall in case of failure. 
Please correct me if I am wrong.

---

From: LAC Chidung <[email-masked]>
Date: Tue, 03 Dec 2013 13:54:33 +0100

Hi Qin,
1- Your understanding of availability is perfectly aligned with my 
sentence "/The phone service is ready/ ...": it is just an update of the 
context, i.e.,
* "/a tone is present/" => "/don't loss connection to the network at any 
time/" ('I get the connection whenever I ask for it')
* "/anywhere/" : from the POTS (PSTN) standpoint, it only happened at 
home, at work, or in phone booths - but with the mobile (r)evolution, it 
is practically anywhere (except during some situations like scubadiving, 
etc.)
* "/using any device/" : nowadays, the plethora of apparatus (desktop, 
laptop, smartphone, tablet, ...) has replaced the traditional (phone) 
receiver
2- HA: this highly requested criteria in the communications field is 
supported, of course, by resilience. It is just a subset of the field of 
values taken by the "availability" metric, which spans from 0 to 1. HA 
is usually characterized by the mean value 0.99999 (five "9" or 5 min of 
unavailabilty per year).
Best,
Chidung
PS: in the ETSI NFV ISG, besides the "Reliability & Availability Working 
Group", there is a "Security Expert Group", i.e., when the word 
'resilience' is employed in the R&A WG, security is not included - in 
other words, "resilience" is used in this WG as "dependability", and not 
as an expression encompassing both dependability and security.

Le 03/12/2013 02:19, Qin Wu a écrit :
>
> In my understanding, availability is more about "don't loss connection 
> to the network at any time anywhere using any device" or ubiquity. The 
> resilience should be used to support high availability as well.
>
> *From:*vnfpool [mailto:[email-masked]] *On Behalf Of *LAC 
> Chidung
> *Sent:* Monday, December 02, 2013 6:00 PM
> *To:* [email-masked]
> under stated conditions for a stated period of time/, 
> while/Availability is a measure of the degree to which an item is in 
> an operable state when called upon to perform./ (D.J. Klinger, Y. 
> Nakada, and M.A. Menedez (Eds.), "AT&T Reliability Manual", Van 
> Nostrand Reinhold, 1990)
> Applied to the PSTN, the former includes "My call is not dropped 
> during a conversation", while the latter asks for "The phone service 
> is ready, i.e., a tone is present, whenever I lift the handset".
> For years, /Dependability /has encompassed these concepts (together 
> with others such as /Maintainability) /to characterize the good 
> behavior (robustness) of a system when facing *accidental *events 
> (design faults, operations errors, hardware failures, natural 
> disasters, etc.) , while /Security, /which includes all *intentional 
> *actions (attacks, ...), is kept apart. This explains the presence, up 
> to now, of two communities working in these two separated subjects.
>     On Wed, Nov 27, 2013 at 2:06 AM, Diego R. Lopez<[email-masked]>  <mailto:[email-masked]>  wrote:
>
>         Hi,
>
>         e-mail:[email-masked]  <mailto:e-mail:[email-masked]>
>
>           
>
>         e-mail:[email-masked]  <mailto:[email-masked]>
>
>         Tel:    +34 913 129 041
>
>         Mobile: +34 682 051 091
>
>         [email-masked]  <mailto:[email-masked]>
>

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 3 Dec 2013 20:06:41 +0000

Chidung,

Thanks for the quote.

Based on your quote, the goal of "vnfpool" should be about to achieve "high availability" of service function chaining while individual service function instances are NOT reliable.  As stated in the problem statement, the virtualized network functions have higher chance to fail due to lack of built-in redundancy, server failure, server over-utilized, or software failure, etc.

Linda

From: vnfpool [mailto:[email-masked]] On Behalf Of LAC Chidung
Sent: Monday, December 02, 2013 4:00 AM
To: [email-masked]
Subject: Re: [vnfpool] VNF Pool Problem Statement

Hi all,

Good point, Diego.

-cz

Hi,

Be goode,

Hi Ning and all,

Regards,

--

Hidetoshi Yokota

Hi,

items:

requirements

hypervisors);

plane traffic;

Thanks.

-Ning

--

Dr Diego R. Lopez

Telefonica I+D

Tel:    +34 913 129 041

Mobile: +34 682 051 091

situado más abajo.

vnfpool mailing list

---

From: Qin Wu <[email-masked]>
Date: Wed, 4 Dec 2013 00:55:20 +0000

Yes, agree, we are on the page, thank for your good clarification on these definitions.

Regards!
-Qin
From: LAC Chidung [mailto:[email-masked]]
Sent: Tuesday, December 03, 2013 8:55 PM
To: Qin Wu; [email-masked]
Subject: Re: [vnfpool] VNF Pool Problem Statement

Hi Qin,
1- Your understanding of availability is perfectly aligned with my sentence "The phone service is ready ...": it is just an update of the context, i.e.,
* "a tone is present" => "don't loss connection to the network at any time" ('I get the connection whenever I ask for it')
* "anywhere" : from the POTS (PSTN) standpoint, it only happened at home, at work, or in phone booths - but with the mobile (r)evolution, it is practically anywhere (except during some situations like scubadiving, etc.)
* "using any device" : nowadays, the plethora of apparatus (desktop, laptop, smartphone, tablet, ...) has replaced the traditional (phone) receiver
2- HA: this highly requested criteria in the communications field is supported, of course, by resilience. It is just a subset of the field of values taken by the "availability" metric, which spans from 0 to 1. HA is usually characterized by the mean value 0.99999 (five "9" or 5 min of unavailabilty per year).
Best,
Chidung
PS: in the ETSI NFV ISG, besides the "Reliability & Availability Working Group", there is a "Security Expert Group", i.e., when the word 'resilience' is employed in the R&A WG, security is not included - in other words, "resilience" is used in this WG as "dependability", and not as an expression encompassing both dependability and security.
Le 03/12/2013 02:19, Qin Wu a écrit :
In my understanding, availability is more about "don't loss connection to the network at any time anywhere using any device" or ubiquity. The resilience should be used to support high availability as well.
If resilience doesn't mean high availability then resilience can be redefined to support high availability.
My 2 cents.
Regards!
-Qin

From: vnfpool [mailto:[email-masked]] On Behalf Of LAC Chidung
Sent: Monday, December 02, 2013 6:00 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [vnfpool] VNF Pool Problem Statement

Hi all,

Good point, Diego.

-cz

Hi,

Be goode,

Hi Ning and all,

Regards,

--

Hidetoshi Yokota

Hi,

items:

requirements

hypervisors);

plane traffic;

Thanks.

-Ning

--

Dr Diego R. Lopez

Telefonica I+D

Tel:    +34 913 129 041

Mobile: +34 682 051 091

situado más abajo.

vnfpool mailing list

---

From: "Cao,Zhen" <[email-masked]>
Date: Wed, 4 Dec 2013 09:25:57 +0800

Hi Qin,

> In service chain discussion, I fail to see they care or any discussion about distinguishing one from another.

[cz] glad to know we two are align with each other. thanks for clarification.

> Please correct me if I am wrong.

If the VNF has to achieved comparable performance to the physical
infrastructure, the pool size is normally bigger and hence more
difficult to manage.

Physical fail-over process is normally achieved via hot standby, but
in VNF, could be achieved by state transfer.

---

From: Qin Wu <[email-masked]>
Date: Wed, 4 Dec 2013 01:53:36 +0000

[Qin]: For physical fail-over, you still need state synchronization between active system and standby one.
VNF can also use such active-standby fail-over mechanism.

Therefore I fail to see the difference. But you are right, if we have a large number active vNFs working, you 
Also need the same amount of standby or backup vNF for fail-over processing ,which is very expensive.
_______________________________________________
vnfpool mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vnfpool

---

From: LAC Chidung <[email-masked]>
Date: Fri, 06 Dec 2013 17:42:31 +0100

Hi Linda,
Please correct the following if I'm wrong.
Let's define: VNF = one type of function.
_Case 1:_ no service chaining, e.g., a firewall provides the network service
Let's state that 3 firewalls are needed, i.e., 3 instances of the VNF "FW".
"*/VNFs have higher chance to fail due to lack of built-in redundancy/*" 
combined with the use of "*/vnfpool/*" means:
1) The 3 FW instances are deployed neither in active/active, nor in 
active/standby mode, i.e., there are only 3 instances, and not 3 active, 
and 3 standby.
2) But this solution is not a trusted one because of "*/server failure, 
server over-utilized, or software failure, etc./*".
3) Assuming that the load of each (FW) instance is less than 60%, one 
can get HA for this system by using the 3 instances in a pool 
architecture (based on an efficient load balancing mechanism).
4) In this case, the failure of one instance is acceptable because its 
load will be shared by the two remaining instances.
_Case 2:_ service chaining, e.g., VNF1 and VNF2 are needed in order to 
provide the network service (for instance, a kid requesting a Web page 
with the use of a smartphone -> "parental control" (VNF1) checks the 
URL, followed by "header enrichment" (VNF2) which adds the user ID in 
the media flow)
Lets' state that we have 3 instances of VNF1 and 3 instances of VNF2. If 
we apply the same reasoning (and hypotheses) as above, we will have a 
1st pool made up of 3 instances of VNF1, and a 2nd pool made up of 3 
instances of VNF2. The HA of this system is guaranteed if: (i) 1 
instance of VNF1 fails, (ii) 1 instance of VNF2 fails, (iii) 1 instance 
of VNF2 fails and 1 instance of VNF2 fails.
Best,
Chidung

Le 03/12/2013 21:06, Linda Dunbar a écrit :
>
> Chidung,
>
> Thanks for the quote.
>
> Based on your quote, the goal of "vnfpool" should be about to achieve 
> "high availability" of service function chaining while individual 
> service function instances are NOT reliable.  As stated in the problem 
> statement, the virtualized network functions have higher chance to 
> fail due to lack of built-in redundancy, server failure, server 
> over-utilized, or software failure, etc.
>
> Linda
>
> *Sent:* Monday, December 02, 2013 4:00 AM
> *To:* [email-masked]

---

From: "King, Daniel" <[email-masked]>
Date: Fri, 6 Dec 2013 21:02:03 +0000

Hi Chidung,

Thanks for using definitions, and providing the example use cases. The service chaining and non-service chaining examples are good, but could you also clarify a deployment, and therefore, solution requirements from an operator perspective?

Is it expected that client service ("FW" in this use case) resilience would be typically be provided by each VNF pool sharing the same VLAN, with a virtual server using a "fixed IP" address that maps to a cluster of "dynamic IP addresses" to multiple VMs, with say one VM for hosting a VNF(s)? Spanning tree would run between the VM instances, and VRRP used to provide backup for the default gateways. This deployment scenario would support the following:

- Load-balancing across VNFs
- Fail-over between VNFs
- Migration to new VNFs

This architecture would also support mixed environments, where existing propriety FW hardware and virtual (VM/VNFs) might be used for migration and testing. Actually, the same question to the other operators. It would be really good to understand the thinking behind how best to achieve cost-effective (time and resources) resilience. As a co-author of "draft-xia-vsnpool-management-use-case" I am trying to figure out if "existing" (VRRP, RSPT, et al.) mechanisms are capable of providing client service continuity and distributed resilience, or indeed we need to document a set of generic requirements that our work in vnfpool will need to solve.

Br, Dan.

From: vnfpool [mailto:[email-masked]] On Behalf Of LAC Chidung
Sent: 06 December 2013 16:43
To: Linda Dunbar; [email-masked]
Subject: Re: [vnfpool] VNF Pool Problem Statement

Hi Linda,
Please correct the following if I'm wrong.
Let's define: VNF = one type of function.
Case 1: no service chaining, e.g., a firewall provides the network service
Let's state that 3 firewalls are needed, i.e., 3 instances of the VNF "FW".
"VNFs have higher chance to fail due to lack of built-in redundancy" combined with the use of "vnfpool" means:
1) The 3 FW instances are deployed neither in active/active, nor in active/standby mode, i.e., there are only 3 instances, and not 3 active, and 3 standby.
2) But this solution is not a trusted one because of "server failure, server over-utilized, or software failure, etc.".
3) Assuming that the load of each (FW) instance is less than 60%, one can get HA for this system by using the 3 instances in a pool architecture (based on an efficient load balancing mechanism).
4) In this case, the failure of one instance is acceptable because its load will be shared by the two remaining instances.
Case 2: service chaining, e.g., VNF1 and VNF2 are needed in order to provide the network service (for instance, a kid requesting a Web page with the use of a smartphone -> "parental control" (VNF1) checks the URL, followed by "header enrichment" (VNF2) which adds the user ID in the media flow)
Lets' state that we have 3 instances of VNF1 and 3 instances of VNF2. If we apply the same reasoning (and hypotheses) as above, we will have a 1st pool made up of 3 instances of VNF1, and a 2nd pool made up of 3 instances of VNF2. The HA of this system is guaranteed if: (i) 1 instance of VNF1 fails, (ii) 1 instance of VNF2 fails, (iii) 1 instance of VNF2 fails and 1 instance of VNF2 fails.
Best,
Chidung
Le 03/12/2013 21:06, Linda Dunbar a écrit :
Chidung,
Thanks for the quote.
Based on your quote, the goal of "vnfpool" should be about to achieve "high availability" of service function chaining while individual service function instances are NOT reliable.  As stated in the problem statement, the virtualized network functions have higher chance to fail due to lack of built-in redundancy, server failure, server over-utilized, or software failure, etc.
Linda

Hi all,

Good point, Diego.

-cz

Hi,

Be goode,

Hi Ning and all,

Regards,

--

Hidetoshi Yokota

Hi,

items:

requirements

hypervisors);

plane traffic;

Thanks.

-Ning

--

Dr Diego R. Lopez

Telefonica I+D

Tel:    +34 913 129 041

Mobile: +34 682 051 091

vnfpool mailing list

---

From: Zongning <[email-masked]>
Date: Mon, 9 Dec 2013 02:05:29 +0000

Hi, Daniel,

I agree this is a fair question to ask, thanks!
Please allow me to ask another question ("a flip side of the coin"): do we have use case to show that the instance in VNF#1 pool needs to know the standby address of the instance in VNF#2 pool? For example, suppose we have a vLB instance (vLB-1) talking to a vFW instance (vFW-1) with two standby instances (vFW-2, vFW-3), if vLB-1 need to know the address of vFW-2, vFW-3, or not *in any case*?
Anyway, I guess this is a good work for co-authors of use case draft. :)

-Ning

From: vnfpool [mailto:[email-masked]] On Behalf Of King, Daniel
Sent: Saturday, December 07, 2013 5:02 AM
To: LAC Chidung
Cc: [email-masked]; Linda Dunbar
Subject: Re: [vnfpool] VNF Pool Problem Statement

Hi Chidung,

Br, Dan.

Hi Linda,

Hi all,

Good point, Diego.

-cz

Hi,

Be goode,

Hi Ning and all,

Regards,

--

Hidetoshi Yokota

Hi,

items:

requirements

hypervisors);

plane traffic;

Thanks.

-Ning

--

Dr Diego R. Lopez

Telefonica I+D

Tel:    +34 913 129 041

Mobile: +34 682 051 091

vnfpool mailing list

---

From: Melinda Shore <[email-masked]>
Date: Sun, 08 Dec 2013 17:26:07 -0900

I think Daniel is asking exactly the right questions.  But
to back up a bit, I've been thinking about this over the
weekend and realized that the scenario is actually simpler
than I'd been considering.  If the VNF instances are pooled
along the general lines of something like rserpool, it is
not the case that an external client will need to be
modified.  The only elements which would need to be able
to "talk" the pooling protocol are already participating -
they'd be the pool manager and whatever service chain
management function is being used, the pool members, and
adjacent pools.  So I think we're in good shape there; we
could probably use some better text around this to make
it clearer.

Melinda

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 9 Dec 2013 16:11:44 +0000

Childung,

What you described is good beginning. I add the remaining to your service chain (see the insert below)

From: LAC Chidung [mailto:[email-masked]]
Sent: Friday, December 06, 2013 10:43 AM
To: Linda Dunbar; [email-masked]
Subject: Re: [vnfpool] VNF Pool Problem Statement

Hi Linda,
Lets' state that we have 3 instances of VNF1 and 3 instances of VNF2. If we apply the same reasoning (and hypotheses) as above, we will have a 1st pool made up of 3 instances of VNF1, and a 2nd pool made up of 3 instances of VNF2. The HA of this system is guaranteed if: (i) 1 instance of VNF1 fails,
[Linda] VNFpool is to develop protocol for the replacement instance of VNF1 to be chained to the  instance of VNF2 when the first instance of VNF1 fails.

(ii) 1 instance of VNF2 fails,
[Linda] VNFpool is to develop protocol for the instance of VNF1 to be chained to the  replacement instance of VNF2 when the first instance of VNF2 fails.

(iii) 1 instance of VNF1 fails and 1 instance of VNF2 fails.
[Linda] Then the VNFpool protocol is responsible for chaining the replacement of VNF1 to the replacement of VNF2.

Best,
Chidung

Hi all,

Good point, Diego.

-cz

Hi,

Be goode,

Hi Ning and all,

Regards,

--

Hidetoshi Yokota

Hi,

items:

requirements

hypervisors);

plane traffic;

Thanks.

-Ning

--

Dr Diego R. Lopez

Telefonica I+D

Tel:    +34 913 129 041

Mobile: +34 682 051 091

vnfpool mailing list

---

From: LAC Chidung <[email-masked]>
Date: Mon, 09 Dec 2013 17:15:23 +0100

Thank you, Linda, for clarifying what I meant by "/*based on an 
efficient load balancing mechanism*/".

Le 09/12/2013 17:11, Linda Dunbar a écrit :
> *From:*LAC Chidung [mailto:[email-masked]]
> *Sent:* Friday, December 06, 2013 10:43 AM
> *To:* Linda Dunbar; [email-masked]
> "*/VNFs have higher chance to fail due to lack of built-in 
> redundancy/*" combined with the use of "*/vnfpool/*" means:
> active/standby mode, i.e., there are only 3 instances, and not 3 
> active, and 3 standby.
> 2) But this solution is not a trusted one because of "*/server 
> failure, server over-utilized, or software failure, etc./*".
> Lets' state that we have 3 instances of VNF1 and 3 instances of VNF2. 
> If we apply the same reasoning (and hypotheses) as above, we will have 
> a 1st pool made up of 3 instances of VNF1, and a 2nd pool made up of 3 
> instance of VNF1 fails,
> [Linda] VNFpool is to develop protocol for the replacement instance of 
> VNF1 to be chained to the  instance of VNF2 when the first instance of 
> VNF1 fails.
>
> [Linda] VNFpool is to develop protocol for the instance of VNF1 to be 
> chained to the  replacement instance of VNF2 when the first instance 
> of VNF2 fails.
>
> (iii) 1 instance of VNF1fails and 1 instance of VNF2 fails.
>
> [Linda] Then the VNFpool protocol is responsible for chaining the 
> replacement of VNF1 to the replacement of VNF2.
>
> Best,
> Chidung
>
>     Based on your quote, the goal of "vnfpool" should be about to
>     achieve "high availability" of service function chaining while
>     individual service function instances are NOT reliable.  As stated
>     in the problem statement, the virtualized network functions have
>     higher chance to fail due to lack of built-in redundancy, server
>     failure, server over-utilized, or software failure, etc.
>
>     Linda
>
>     *From:*vnfpool [mailto:[email-masked]] *On Behalf Of
>     *LAC Chidung
>     *To:* [email-masked] <mailto:[email-masked]>
>     /Reliability is the ability of an item to perform a required
>     function under stated conditions for a stated period of time/,
>     while/Availability is a measure of the degree to which an item is
>     in an operable state when called upon to perform./ (D.J. Klinger,
>     Y. Nakada, and M.A. Menedez (Eds.), "AT&T Reliability Manual", Van
>     Nostrand Reinhold, 1990)
>     during a conversation", while the latter asks for "The phone
>     service is ready, i.e., a tone is present, whenever I lift the
>     handset".
>     For years, /Dependability /has encompassed these concepts
>     (together with others such as /Maintainability) /to characterize
>     the good behavior (robustness) of a system when facing *accidental
>     *events (design faults, operations errors, hardware failures,
>     natural disasters, etc.) , while /Security, /which includes all
>     *intentional *actions (attacks, ...), is kept apart. This explains
>     the presence, up to now, of two communities working in these two
>     separated subjects.
>     As (i) unavailability may the consequence of, e.g.,
>     software/hardware failures OR (D)DoS attacks (ii) /Resilience/ is
>     a fashionable expression* (iii) etc., resilience is used since the
>     last few years to encompass both dependability and security.
>     Best,
>     Chidung
>     _______

---

From: "Diego R. Lopez" <[email-masked]>
Date: Mon, 09 Dec 2013 19:00:14 +0000

Hi,

I agree with Melinda in that the problem has to be confined to the VNF (and its pooling manager) and the service chaining management functions. External elements, like other virtual and/or physical network functions in a given path (the realization of the chain) or user applications should be completely oblivious to the pooling mechanisms in place.

Be goode,

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091

---

From: "King, Daniel" <[email-masked]>
Date: Mon, 9 Dec 2013 20:15:41 +0000

Hi All, 

Re: Deployment Scenarios

Sounds good, it was just a gentle reminder that the model we settle on should fit with existing/planned deployment scenarios, and network resilience mechanisms. As we develop the vnfpool problem statement, we are capturing the scope and key problems that inform the solution work, but ideally these should be guided by how operators and service providers plan to use VNFs in the field. Operators that have NFV trials and prototypes, provides valuable data to use for the solution work, we just need to encourage them to assign more CPU cycles to the vnfpool mailing list. ;-) 

Re: (high-level) Architecture

It would be great to visualise the architecture (ASCII or otherwise), specifically the components, relationships, interactions and interfaces required/expected based on the problem statement (thus far):

- VNF Pool Manager (in-scope, out of scope?)
o Resilient itself (multi-instance)? 

- Single instance VNFs, Multi-instance VNFs and Chained VNFs
o Signaling mechanisms/characteristics/relationships

- Abstract interactions/relationships between VNF Pool Manager and VNFs, and VNF to VNF(s). 
o Instantiation 
o Adaptation
o Migration
o Fail-over
o Load-balancing
o Termination

- VNF/Pool Topology Management
o Functions and Interfaces  

-  Control Plane
o Functions and Interfaces  

- Relationship (or completely transparent?) with physical and virtual elements, providing connectivity and additional function

Br, Dan. 

-----Original Message-----
From: vnfpool [mailto:[email-masked]] On Behalf Of Diego R. Lopez
Sent: 09 December 2013 19:00
To: Melinda Shore
Cc: <[email-masked]>
Subject: Re: [vnfpool] VNF Pool Problem Statement

Hi,

Be goode,

On 9 Dec 2013, at 03:26 , Melinda Shore wrote:

> I think Daniel is asking exactly the right questions.  But to back up 
> a bit, I've been thinking about this over the weekend and realized 
> that the scenario is actually simpler than I'd been considering.  If 
> the VNF instances are pooled along the general lines of something like 
> rserpool, it is not the case that an external client will need to be 
> modified.  The only elements which would need to be able to "talk" the 
> pooling protocol are already participating - they'd be the pool 
> manager and whatever service chain management function is being used, 
> the pool members, and adjacent pools.  So I think we're in good shape 
> there; we could probably use some better text around this to make it 
> clearer.
>
> Melinda

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091

---

From: "King, Daniel" <[email-masked]>
Date: Mon, 9 Dec 2013 21:19:30 +0000

Hi Ning,

Good question, I would modify slightly. If VNF#2 needs to replicate state (FW or otherwise) to its designated backup (VNF#3), it should probably have the IP connectivity knowledge to do this. When failure (loss of VNF#2) happens, should the existing network resilience mechanisms route traffic to VNF#3, without VNF#1 having to detect loss of VNF#2 and switching to VNF#3 instead.

Phew, quite a number of permutations. We will update the I-D to encompass these discussions/scenarios.

Br, Dan.

From: vnfpool [mailto:[email-masked]] On Behalf Of Zongning
Sent: 09 December 2013 02:05
To: King, Daniel; LAC Chidung
Cc: [email-masked]; Linda Dunbar
Subject: Re: [vnfpool] VNF Pool Problem Statement

Hi, Daniel,

-Ning

From: vnfpool [mailto:[email-masked]] On Behalf Of King, Daniel
Sent: Saturday, December 07, 2013 5:02 AM
To: LAC Chidung
Cc: [email-masked]<mailto:[email-masked]>; Linda Dunbar
Subject: Re: [vnfpool] VNF Pool Problem Statement

Hi Chidung,

Br, Dan.

From: vnfpool [mailto:[email-masked]] On Behalf Of LAC Chidung
Sent: 06 December 2013 16:43
To: Linda Dunbar; [email-masked]<mailto:[email-masked]>
Subject: Re: [vnfpool] VNF Pool Problem Statement

Hi Linda,

Hi all,

Good point, Diego.

-cz

Hi,

Be goode,

Hi Ning and all,

Regards,

--

Hidetoshi Yokota

Hi,

items:

requirements

hypervisors);

plane traffic;

Thanks.

-Ning

--

Dr Diego R. Lopez

Telefonica I+D

Tel:    +34 913 129 041

Mobile: +34 682 051 091

vnfpool mailing list

---

From: Zongning <[email-masked]>
Date: Tue, 10 Dec 2013 01:41:43 +0000

Hi, Daniel,

Thanks for starting talking about architecture. :)
I actually put some text about VNF pool architecture in my early post on bar BoF summary. Please see attached PDF. Some straw-man points below:
•Multiple pools for multiple VNFs, with each pool having pool members (VNF instances) providing same function;
•Each pool has a (logical or physical) manager that interacts with pool members for redundancy mechanisms, e.g. active-standby management;
•Pool manager of adjacent pools can talk to each other to achieve redundancy among the VNF chain, e.g. pool status notification;
But I absolutely agree with your idea that it would be good to start working on (architecture) document. Sounds like you are willing to contribute some text. :)
Thanks.

-Ning

> Sent: Tuesday, December 10, 2013 4:16 AM
> To: Diego R. Lopez; Melinda Shore
> Cc: <[email-masked]>
> Sounds good, it was just a gentle reminder that the model we settle on should
> fit with existing/planned deployment scenarios, and network resilience
> mechanisms. As we develop the vnfpool problem statement, we are capturing
> the scope and key problems that inform the solution work, but ideally these
> should be guided by how operators and service providers plan to use VNFs in
> the field. Operators that have NFV trials and prototypes, provides valuable data
> to use for the solution work, we just need to encourage them to assign more
> CPU cycles to the vnfpool mailing list. ;-)
> 
> It would be great to visualise the architecture (ASCII or otherwise), specifically
> the components, relationships, interactions and interfaces required/expected
> based on the problem statement (thus far):
> 
> - Relationship (or completely transparent?) with physical and virtual elements,
> providing connectivity and additional function
> 
> Br, Dan.
> 
> I agree with Melinda in that the problem has to be confined to the VNF (and its
> pooling manager) and the service chaining management functions. External
> elements, like other virtual and/or physical network functions in a given path
> (the realization of the chain) or user applications should be completely oblivious
> to the pooling mechanisms in place.
> 
> Be goode,
> 
>

---

From: Zongning <[email-masked]>
Date: Tue, 10 Dec 2013 01:43:01 +0000

Ooops, forgot the file. Here it is...

> From: Zongning
> Sent: Tuesday, December 10, 2013 9:42 AM
> To: 'King, Daniel'; Diego R. Lopez; Melinda Shore
> Cc: <[email-masked]>
> Subject: RE: [vnfpool] VNF Pool Problem Statement
> 
> Hi, Daniel,
> 
> I actually put some text about VNF pool architecture in my early post on bar
> BoF summary. Please see attached PDF. Some straw-man points below:
> •Each pool has a (logical or physical) manager that interacts with pool
> members for redundancy mechanisms, e.g. active-standby management;
> •Pool manager of adjacent pools can talk to each other to achieve redundancy
> among the VNF chain, e.g. pool status notification;
> But I absolutely agree with your idea that it would be good to start working on
> (architecture) document. Sounds like you are willing to contribute some text. :)
> Thanks.
> 
> -Ning
> 
>

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 10 Dec 2013 16:28:23 +0000

Chidung,

It is more like "multidimensional load balancing mechanism without traffic going through" for the following reasons:

-        Traditional Load balancing device direct traffic to different instances based on the traffic, which means that the traffic goes to LB first and then is dispatched to different instances of the service function. In VNFpool environment, having all traffic going through a single point of LB entrance will make the LB being the bottleneck, that is not desirable.

-        There are multiple pools of service functions, with each having its own LB (or pool manager). Those pool managers have to coordinate with each other.

Linda

From: LAC Chidung [mailto:[email-masked]]
Sent: Monday, December 09, 2013 10:15 AM
To: Linda Dunbar
Cc: [email-masked]
Subject: Re: [vnfpool] VNF Pool Problem Statement

Thank you, Linda, for clarifying what I meant by "based on an efficient load balancing mechanism".
Le 09/12/2013 17:11, Linda Dunbar a écrit :
Childung,
What you described is good beginning. I add the remaining to your service chain (see the insert below)

Hi Linda,

Hi all,

Good point, Diego.

-cz

Hi,

Be goode,

Hi Ning and all,

Regards,

--

Hidetoshi Yokota

Hi,

items:

requirements

hypervisors);

plane traffic;

Thanks.

-Ning

--

Dr Diego R. Lopez

Telefonica I+D

Tel:    +34 913 129 041

Mobile: +34 682 051 091

vnfpool mailing list

---

From: Hidetoshi Yokota <[email-masked]>
Date: Wed, 11 Dec 2013 10:16:15 +0900

Hi Ning and all.

Sorry to jump into the discussion.

Thanks for providing the architectural figure. As a matter of fact, even
ETSI NFV does not a concrete and uniform concept about the interfaces
and the role of each function, so the discussion in this ML is very
valuable.

So, the focus of VNF Pool is:

1) signaling between Pool Managers
2) signaling between Pool Manager and VNFs in its pool
3) signaling between Pool Manager and underlying network
(routers/switches?) [*not in the figure, but described in the PS]
4) signaling between Pool Manager and CMS [*not in the figure but
described in the PS]

Of course, some may end up with out of scope. Which one will be most
important (1 and 2, maybe)?

Regards,

-- 
Hidetoshi Yokota

(2013/12/10 10:43), Zongning wrote:
>> .Multiple pools for multiple VNFs, with each pool having pool members (VNF
>> instances) providing same function;
>> .Each pool has a (logical or physical) manager that interacts with pool
>> .Pool manager of adjacent pools can talk to each other to achieve redundancy
>>> nuestra poli'tica de envi'o y recepcio'n de correo electro'nico en el enlace
>>> situado ma's abajo.

---

From: Zongning <[email-masked]>
Date: Wed, 11 Dec 2013 01:35:12 +0000

Hi, Hidetoshi,

Thanks for the comments.
You are right, we will start with a set of components and interfaces in the figure as our initial scope.
I haven't prioritize the work items yet, but my personal feeling by now is that 1), 2), 3) are something we could start with. But we may also consider transport reliability and security characteristics for these signaling.

-Ning

From: Hidetoshi Yokota [mailto:[email-masked]]
Sent: Wednesday, December 11, 2013 9:16 AM
To: Zongning; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [vnfpool] VNF Pool Problem Statement

Hi Ning and all.

Thanks for providing the architectural figure. As a matter of fact, even ETSI NFV does not a concrete and uniform concept about the interfaces and the role of each function, so the discussion in this ML is very valuable.

1) signaling between Pool Managers
2) signaling between Pool Manager and VNFs in its pool
3) signaling between Pool Manager and underlying network (routers/switches?) [*not in the figure, but described in the PS]
4) signaling between Pool Manager and CMS [*not in the figure but described in the PS]

Of course, some may end up with out of scope. Which one will be most important (1 and 2, maybe)?

Regards,

--

Hidetoshi Yokota

-----Original Message-----

From: Zongning

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

Hi, Daniel,

*Multiple pools for multiple VNFs, with each pool having pool members (VNF

*Each pool has a (logical or physical) manager that interacts with pool

*Pool manager of adjacent pools can talk to each other to achieve redundancy

Thanks.

-Ning

-----Original Message-----

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

Hi All,

Re: Deployment Scenarios

Sounds good, it was just a gentle reminder that the model we settle on

should

mechanisms. As we develop the vnfpool problem statement, we are

capturing

the field. Operators that have NFV trials and prototypes, provides valuable

data

It would be great to visualise the architecture (ASCII or otherwise),

specifically

- Abstract interactions/relationships between VNF Pool Manager and VNFs,

and VNF to VNF(s).

o Instantiation

o Adaptation

o Migration

o Fail-over

o Load-balancing

o Termination

-  Control Plane

- Relationship (or completely transparent?) with physical and virtual

elements,

Br, Dan.

-----Original Message-----

To: Melinda Shore

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

Hi,

I agree with Melinda in that the problem has to be confined to the VNF (and

its

(the realization of the chain) or user applications should be completely

oblivious

Be goode,

clearer.

Melinda

vnfpool mailing list

--

Dr Diego R. Lopez

Telefonica I+D

Tel:    +34 913 129 041

Mobile: +34 682 051 091

situado más abajo.

vnfpool mailing list

vnfpool mailing list

vnfpool mailing list

---

From: Hidetoshi Yokota <[email-masked]>
Date: Thu, 12 Dec 2013 13:41:58 +0900

Hi Dan and Ning,

The following scenario is very important and should be captured in this
work. At least, the IP address of VNF#2 should be preserved even if the
role is handed over to VNF#3. This is because in some applications, the
state information includes the IP address of the peer, so if the IP
address changes due to the failure recovery, the state information in
VNF#1 will become inconsistent. Please take this scenario into
consideration.

Regards,

-- 
Hidetoshi Yokota

(2013/12/10 6:19), King, Daniel wrote:
>
> Hi Ning,
>
> Good question, I would modify slightly. If VNF#2 needs to replicate
> state (FW or otherwise) to its designated backup (VNF#3), it should
> probably have the IP connectivity knowledge to do this. When failure
> (loss of VNF#2) happens, should the existing network resilience
> mechanisms route traffic to VNF#3, without VNF#1 having to detect loss
> of VNF#2 and switching to VNF#3 instead.
>
> *From:*vnfpool [mailto:[email-masked]] *On Behalf Of *Zongning
> *Sent:* 09 December 2013 02:05
> *To:* King, Daniel; LAC Chidung
> *Cc:* [email-masked]; Linda Dunbar
> Please allow me to ask another question (“a flip side of the coin”):
> do we have use case to show that the instance in VNF#1 pool needs to
> know the standby address of the instance in VNF#2 pool? For example,
> suppose we have a vLB instance (vLB-1) talking to a vFW instance
> (vFW-1) with two standby instances (vFW-2, vFW-3), if vLB-1 need to
> know the address of vFW-2, vFW-3, or not **in any case**?
>
> Anyway, I guess this is a good work for co-authors of use case draft. J
>
> -Ning
>
> *From:*vnfpool [mailto:[email-masked]] *On Behalf Of *King,
> Daniel
> *Sent:* Saturday, December 07, 2013 5:02 AM
> *To:* LAC Chidung
> *Cc:* [email-masked] <mailto:[email-masked]>; Linda Dunbar
> Thanks for using definitions, and providing the example use cases. The
> service chaining and non-service chaining examples are good, but could
> you also clarify a deployment, and therefore, solution requirements
> from an operator perspective?
>
> Is it expected that client service (“FW” in this use case) resilience
> would be typically be provided by each VNF pool sharing the same VLAN,
> with a virtual server using a “fixed IP” address that maps to a
> cluster of “dynamic IP addresses” to multiple VMs, with say one VM for
> hosting a VNF(s)? Spanning tree would run between the VM instances,
> and VRRP used to provide backup for the default gateways. This
> deployment scenario would support the following:
>
> This architecture would also support mixed environments, where
> existing propriety FW hardware and virtual (VM/VNFs) might be used for
> migration and testing. Actually, the same question to the other
> operators. It would be really good to understand the thinking behind
> how best to achieve cost-effective (time and resources) resilience. As
> a co-author of “draft-xia-vsnpool-management-use-case” I am trying to
> figure out if “existing” (VRRP, RSPT, et al.) mechanisms are capable
> of providing client service continuity and distributed resilience, or
> indeed we need to document a set of generic requirements that our work
> in vnfpool will need to solve.
>
> Br, Dan.
>
> *Sent:* 06 December 2013 16:43
> *To:* Linda Dunbar; [email-masked] <mailto:[email-masked]>
> instance of VNF1 fails, (ii) 1 instance of VNF2 fails, (iii) 1
> instance of VNF2 fails and 1 instance of VNF2 fails.
> Best,
> Chidung
>
> Le 03/12/2013 21:06, Linda Dunbar a e'crit :
>
>     Chidung,
>
>     Thanks for the quote.
>
>     Based on your quote, the goal of “vnfpool” should be about to
>     achieve “high availability” of service function chaining while
>     Le 02/12/2013 08:21, Cao,Zhen a e'crit :
>
>         Good point, Diego.
>
>         On Wed, Nov 27, 2013 at 2:06 AM, Diego R. Lopez <[email-masked]> <mailto:[email-masked]> wrote:
>
>             Hi,
>
>             e-mail: [email-masked] <mailto:[email-masked]>
>
>             Tel:    +34 913 129 041
>
>             Mobile: +34 682 051 091
>

---

From: "King, Daniel" <[email-masked]>
Date: Thu, 12 Dec 2013 06:54:40 +0000

Hi Hidetoshi,

Thanks for the clarification, we will write up the scenario in the use case I-D and if ok, we will bounce the suggest text off you for your input.

Br, Dan.

From: vnfpool [mailto:[email-masked]] On Behalf Of Hidetoshi Yokota
Sent: 12 December 2013 04:42
To: [email-masked]
Subject: Re: [vnfpool] VNF Pool Problem Statement

Hi Dan and Ning,

The following scenario is very important and should be captured in this work. At least, the IP address of VNF#2 should be preserved even if the role is handed over to VNF#3. This is because in some applications, the state information includes the IP address of the peer, so if the IP address changes due to the failure recovery, the state information in VNF#1 will become inconsistent. Please take this scenario into consideration.

Regards,

--

Hidetoshi Yokota

Br, Dan.

Hi, Daniel,

-Ning

Hi Chidung,

Br, Dan.

Hi Linda,

Hi all,

Good point, Diego.

-cz

Hi,

Be goode,

Hi Ning and all,

Regards,

--

Hidetoshi Yokota

Hi,

items:

requirements

hypervisors);

plane traffic;

Thanks.

-Ning

--

Dr Diego R. Lopez

Telefonica I+D

Tel:    +34 913 129 041

Mobile: +34 682 051 091

vnfpool mailing list

vnfpool mailing list

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 16 Dec 2013 14:01:26 -0500

Diego:

I'm catching up your email (12/9/13). 

Can you explain a bit more about your statement:  "External elements, like other virtual and/or physical network functions in a given path (the realization of the chain) or user applications should be completely oblivious to the pooling mechanisms in place."

I'm not suggesting a feature expansion in the VNF and pooling manager work, but rather a reduction with an API added.  The APIs would Pool Manager to obtain information from other sources (i2rs, ALTO, etc). 

An API can allow infrastructure VMs/process to share status on infrastructure that fate-shares with the VNF pools.  This allows the infrastructure to notify the Pool manager "hints" on good algorithmic placement/balancing of pools.  

An API would also benefit application deployment.  If Service provider schedules a very popular mobile application via the app-store, this API allows a feedback  application download traffic spikes. The VNF Pool Manager could obtain more resources based on the policy pre-set for the traffic spikes. 

Real Example: 
Suppose a new version of the Angry Birds mobile phone app called "Angry Birds: Thor's revenge" is schedule to deploy with a new Marvel: Thor's Revenge movie.   During the first few weeks it make sense to have a feedback loop that can increase the VNF (pools) that need the firewall/security/loadbalancing to handle the sales. 

U 2 Be Goode, 

Sue Hares 

-----Original Message-----
From: vnfpool [mailto:[email-masked]] On Behalf Of Diego R. Lopez
Sent: Monday, December 09, 2013 2:00 PM
To: Melinda Shore
Cc: <[email-masked]>
Subject: Re: [vnfpool] VNF Pool Problem Statement

Hi,

Be goode,

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091

---

From: "Diego R. Lopez" <[email-masked]>
Date: Tue, 31 Dec 2013 13:44:41 +0000

Hi Susan,

I think you express my intention very well when you say you did not propose an expansion of the VNF and pooling manager. My point was to isolate the other functions in the network from knowing any detail on the actual implementation/deployment details of the VNF in question. The VNFPOOL will become a technique for such implementation, where the pool manager will be one of the components of the VNFs that use this technique.

For sure an API (or APIs, I'd say) are required for taking a real advantage of the virtualized functions. As far as I can tell these APIs are being considered in the NFV architecture, precisely to deal with the interactions with the infrastructure, with other network functions, and the apps using the network functions (or the OSS/BSS if you like) The diagram in Figure 4 of the NFV architecture framework (at http://www.etsi.org/deliver/etsi_gs/NFV/001_099/002/01.01.01_60/gs_NFV002v010101p.pdf) includes a set of reference points where these APIs shall live.

Be goode and have an Extremely Goode New Year,

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091