Subject: [vnfpool] Problem Statement V2

From: Zongning <[email-masked]>
Date: Wed, 11 Dec 2013 05:53:51 +0000

Hi, folks,

Thank you all for valuable comments & suggestions on problem statement during the past a few weeks. Please see below updated text, which I hope captures what we have discussed and agreed so far. Here is the highlight of the main changes:

1)       Add more text to clarify the scope of "reliability" we want to address;

2)       Add more descriptive text about VNF, as well as how it would impact reliability;

3)       Modify some work item bullets;

4)       Clarify relation with service function chaining (SFC) group;

===========================================================
A virtualized network function (VNF) provides network function (e.g., firewalling, load balancing), but is typically implemented as software instances running on general server via virtualization layer (e.g. hypervisor). This is distinct from monolithic network devices, where a number of different functions are provided in the same device. Based on concept of service function chaining (SFC), a network service can be implemented by a set of sequentially connected VNF instances deployed at different points in the network (or a VNF chain).
A VNF chain introduces additional points of failure beyond those inherent in a single dedicated server, and therefore additional challenges on reliability. For a single VNF instance, it typically would not have built-in reliability mechanisms on its host (i.e. general server). Instead, there are more factors such as software failure, server overload, and instance migration that lead to VNF instance transition or failure. Currently generalized pooling and other redundancy mechanisms may be applied to address some reliability requirements of a single VNF. However, the need to support a growing number of VNFs including stateful function, and extend the redundancy across a VNF chain (i.e. multiple pools for multiple VNFs) requires further solution development. For example, when a "live" VNF pool member goes out of service, how do adjacent entities learn which pool member will replace it? How do VNFs learn the state of adjacent VNFs to support reliability mechanisms like load sharing and switch before break? How is the service state of an instance held and accessed for efficient synchronization with backup instances and other members of its pool?
Ideally, the reliability of VNF chain would mean that a VNF chain continues to function throughout an interruption and outages will not be visible to users of the chain. In the current charter, we scope our work around several mechanisms supporting the reliability of VNF chain, which are redundancy along multiple VNF pools, and stateful failover among pool members. Additional mechanisms for reliable VNF chain might be included after further gap analysis between our requirements and IETF technologies.

The overall problem space can be further broken to include the following items:
. Signaling between VNF pools for transition (e.g. state change, scaling, moving) notification, backup announcement;
. Identification and evaluation of state sharing mechanisms, including (but not limited to) distributed shared memory, gossip protocols, pfsync, and state check pointing;
. Exchange of reliability related information between VNF pools and underlying network (e.g. interfacing with ALTO, I2RS);
. Identify and analyze reliable transport characteristics for control plane traffic;
. Analysis of transport security characteristics to provide protection against known threats, and identification of an appropriate trust model;

The initial work will include a problem statement, VNF pooling architecture, use cases and requirements analysis, and an evaluation of existing technologies against the architecture and requirements. It is our expectation that we will be able to rely heavily on existing IETF technologies but that gaps will be found around problems like state transfer and trust/security, which will need to be addressed. Particularly, we will work closely with SFC group to develop mechanisms complementary to service function chaining approaches, based on identified reliability requirements.
============================================================

Please let me know if the update doesn't address your previous concerns. Further comments are also highly appreciated.

Thanks.

-Ning

---

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

Hi Ning,

Thanks for your update, which is starting to look like the charter.

I have a couple of questions and comments:

o I think it is good to emphasize reliability to clarify the scope of
this work. RSerpool deals with pooling configuration, SFC deals with
chaining configuration and VNFpool could leverage their work to enhance
reliability.

o Are we focusing more on VNF chain rather than VNF itself with regard
to reliability? Maybe, we could include both and it is part of the study
to identify the additional requirements for VNF chain.

o Based on the architecture figure you provided, we should also study
the signaling between Pool manager and VNFs. I would propose the
following text

"Signaling between VNF pools for transition..."
->
"Signaling "within and" between VNF pools for transition..."

o State synchronization is important, but when VNF migration or
replacement occurs, flow route synchronization is also important. This
feature should also be captured.

Regards,

-- 
Hidetoshi Yokota

KDDI R&D Laboratories, Inc.
e-mail:[email-masked]

(2013/12/11 14:53), Zongning wrote:
>
> Hi, folks,
>
> Thank you all for valuable comments & suggestions on problem statement
> during the past a few weeks. Please see below updated text, which I
> hope captures what we have discussed and agreed so far. Here is the
> highlight of the main changes:
>
> 1)Add more text to clarify the scope of “reliability” we want to address;
>
> 2)Add more descriptive text about VNF, as well as how it would impact
> reliability;
>
> 3)Modify some work item bullets;
>
> 4)Clarify relation with service function chaining (SFC) group;
>
> A virtualized network function (VNF) provides network function (e.g.,
> firewalling, load balancing), but is typically implemented as software
> instances running on general server via virtualization layer (e.g.
> hypervisor). This is distinct from monolithic network devices, where a
> number of different functions are provided in the same device. Based
> on concept of service function chaining (SFC), a network service can
> be implemented by a set of sequentially connected VNF instances
> deployed at different points in the network (or a VNF chain).
>
> A VNF chain introduces additional points of failure beyond those
> inherent in a single dedicated server, and therefore additional
> challenges on reliability. For a single VNF instance, it typically
> would not have built-in reliability mechanisms on its host (i.e.
> general server). Instead, there are more factors such as software
> failure, server overload, and instance migration that lead to VNF
> instance transition or failure. Currently generalized pooling and
> other redundancy mechanisms may be applied to address some reliability
> requirements of a single VNF. However, the need to support a growing
> number of VNFs including stateful function, and extend the redundancy
> across a VNF chain (i.e. multiple pools for multiple VNFs) requires
> further solution development. For example, when a "live" VNF pool
> member goes out of service, how do adjacent entities learn which pool
> member will replace it? How do VNFs learn the state of adjacent VNFs
> to support reliability mechanisms like load sharing and switch before
> break? How is the service state of an instance held and accessed for
> efficient synchronization with backup instances and other members of
> its pool?
>
> Ideally, the reliability of VNF chain would mean that a VNF chain
> continues to function throughout an interruption and outages will not
> be visible to users of the chain. In the current charter, we scope our
> work around several mechanisms supporting the reliability of VNF
> chain, which are redundancy along multiple VNF pools, and stateful
> failover among pool members. Additional mechanisms for reliable VNF
> chain might be included after further gap analysis between our
> requirements and IETF technologies.
>
> . Signaling between VNF pools for transition (e.g. state change,
> scaling, moving) notification, backup announcement;
>
> . Identification and evaluation of state sharing mechanisms, including
> (but not limited to) distributed shared memory, gossip protocols,
> pfsync, and state check pointing;
>
> . Exchange of reliability related information between VNF pools and
> underlying network (e.g. interfacing with ALTO, I2RS);
>
> . Analysis of transport security characteristics to provide protection
> against known threats, and identification of an appropriate trust model;
>
> The initial work will include a problem statement, VNF pooling
> architecture, use cases and requirements analysis, and an evaluation
> of existing technologies against the architecture and requirements. It
> is our expectation that we will be able to rely heavily on existing
> IETF technologies but that gaps will be found around problems like
> state transfer and trust/security, which will need to be addressed.
> Particularly, we will work closely with SFC group to develop
> mechanisms complementary to service function chaining approaches,
> based on identified reliability requirements.
>
> Please let me know if the update doesn’t address your previous
> concerns. Further comments are also highly appreciated.
>
> Thanks.
>
> -Ning
>
>
>
> _______________________________________________
> vnfpool mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vnfpool

---

From: Zongning <[email-masked]>
Date: Thu, 12 Dec 2013 08:27:14 +0000

Hi, Hidetoshi,

Thanks for your comments and questions. See inline.

o I think it is good to emphasize reliability to clarify the scope of this work. RSerpool deals with pooling configuration, SFC deals with chaining configuration and VNFpool could leverage their work to enhance reliability.

[Ning] Good point. I should mention this in the text.

o Are we focusing more on VNF chain rather than VNF itself with regard to reliability? Maybe, we could include both and it is part of the study to identify the additional requirements for VNF chain.

[Ning] If you mean VNF pool when saying "VNF itself", then, yes, we include both.

o Based on the architecture figure you provided, we should also study the signaling between Pool manager and VNFs. I would propose the following text

[Ning] Agree.

o State synchronization is important, but when VNF migration or replacement occurs, flow route synchronization is also important. This feature should also be captured.

[Ning] You are right this feature is related. Now I prefer focusing scope on signaling in pool architecture, but we could look into additional layers as you suggested as next step of work. How do other folks think?

-Ning

From: vnfpool [mailto:[email-masked]] On Behalf Of Hidetoshi Yokota
Sent: Thursday, December 12, 2013 12:30 PM
To: [email-masked]
Subject: Re: [vnfpool] Problem Statement V2

Hi Ning,

o I think it is good to emphasize reliability to clarify the scope of this work. RSerpool deals with pooling configuration, SFC deals with chaining configuration and VNFpool could leverage their work to enhance reliability.

o Are we focusing more on VNF chain rather than VNF itself with regard to reliability? Maybe, we could include both and it is part of the study to identify the additional requirements for VNF chain.

o Based on the architecture figure you provided, we should also study the signaling between Pool manager and VNFs. I would propose the following text

o State synchronization is important, but when VNF migration or replacement occurs, flow route synchronization is also important. This feature should also be captured.

Regards,

--

Hidetoshi Yokota

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

Thanks.

-Ning

vnfpool mailing list

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

---

From: LAC Chidung <[email-masked]>
Date: Thu, 12 Dec 2013 16:16:10 +0100

Hi Ning,

1- To create a virtual layer starting from h/w, is there anything else 
than hypervisor ? "(e.g. hypervisor)" -> "(i.e. hypervisor)"

2- Up to now, it is possible to find a single network function included 
in a single h/w: "are provided in the same device" -> "may be provided 
in the same device"

3-If "instance" means "Virtual Machine", it may be premature to talk of 
"instances" at this point:

"a network service can be implemented by a set of sequentially connected 
VNF instances" ->"a network service can be implemented by a set of 
sequentially connected VNFs"

4- "For a single VNF instance, it typically would not have built-in 
reliability mechanisms on its host ": it would be nice to 
introduce/define "instance" before using this word*.

5- "there are more factors" -> "there are more factors of risk"

6- "the need to support a growing number of VNFs including stateful 
function": IMHO, this sentence does not fully reflect the two following 
ideas: (i) a complex situation because we (may) deal with a lot of VNFs 
in a VNF chain; (ii) simultaneously, these VNFs (in the VNF chain) may 
not be identical (some are stateless, some are stateful, etc.)

Just my two cents.

Best,

Chidung

__________

*: if we'd like to refer to current ETSI NFV work/jargon, please have in 
mind that VM = instance of a VNFC (and not instance of a VNF - see my 
post sent on Dec 11th) - if not, then forget about this remark.

Le 11/12/2013 06:53, Zongning a écrit :
> 1)Add more text to clarify the scope of "reliability" we want to address;
>
> Please let me know if the update doesn't address your previous

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 12 Dec 2013 23:18:51 +0000

Chidung,

Jumped in to give my interpretation:

3-  If "instance" means "Virtual Machine", it may be premature to talk of "instances" at this point:

"a network service can be implemented by a set of sequentially connected VNF instances" ->  "a network service can be implemented by a set of sequentially connected VNFs"

[Linda] "instance" should be the service function instances. For example, there are 10 Firewall instances. Each instance, most likely software based, can be instantiated on any general purpose server platforms. For a data flow that needs FW, one of those instances will be used.

IMHO, the servers to which those Service Function Instances are instantiated can be "virtualized" or "not virtualized".

Linda

---

From: Zongning <[email-masked]>
Date: Fri, 13 Dec 2013 03:45:56 +0000

Hi, Lac,

Thanks for the comments. Please see inline.

From: LAC Chidung [mailto:[email-masked]]
Sent: Thursday, December 12, 2013 11:16 PM
To: Zongning; [email-masked]
Subject: Re: [vnfpool] Problem Statement V2

Hi Ning,

1-      To create a virtual layer starting from h/w, is there anything else than hypervisor ? "(e.g. hypervisor)" -> "(i.e. hypervisor)"

2-      Up to now, it is possible to find a single network function included in a single h/w: "are provided in the same device" -> "may be provided in the same device"

[Ning]: Agree.

[Ning]: According to ETSI NFV MANO, VNF instance means a run-time instantiation of the VNF software like load balancing, packet filtering. I assume that when we say "a network service can be implemented...", we are talking about run-time instantiation of VNFs. :) Furthermore, based on ETSI NFV SWA and INF, a VNF can be decomposed by multiple VNF Components, with each component instantiated in one virtual container which is typically a VM. To simplify our context for the time being, let's assume VNF has single component which is instantiated in one VM.

3-      "For a single VNF instance, it typically would not have built-in reliability mechanisms on its host ": it would be nice to introduce/define "instance" before using this word*.

[Ning]: See above. I will add the definition into the text later.

[Ning]: Agree.

6- "the need to support a growing number of VNFs including stateful function": IMHO, this sentence does not fully reflect the two following ideas: (i) a complex situation because we (may) deal with a lot of VNFs in a VNF chain; (ii) simultaneously, these VNFs (in the VNF chain) may not be identical (some are stateless, some are stateful, etc.)

[Ning]: Good point, I will update this sentence later.

Just my two cents.

Best,

Chidung

__________

*: if we'd like to refer to current ETSI NFV work/jargon, please have in mind that VM = instance of a VNFC (and not instance of a VNF - see my post sent on Dec 11th) - if not, then forget about this remark.

Thanks.

-Ning

vnfpool mailing list