Subject: [vnfpool] new VNFPool draft charter

From: Zongning <[email-masked]>
Date: Tue, 3 Jun 2014 09:35:51 +0000

Hi, folks,

Please see the below new draft charter of VNFPool. We believe that we have updated the charter to address most of the comments from London BoF. Main changes are:

1)       We narrow down our scope to only focus on the redundancy model and the related interfaces associated with the VNF Pool in a single VNF.

2)       Service state synchronization between VNF instances is out-of-scope. We may consider how to maintain the pool states in a VNF Pool only for pooling purpose.

3)       We assume that a VNF Pool contains redundant VNF instances of same functional type. Different types of VNFs are envisoned to be held in separate VNF Pools.

4)       We do not address reliability related control or routing between adjacent VNFs in the service graph. This is also applied to update the relation between VNF Pool and SFC WG.

==========================================================================
Network functions such as firewalls, load balancers, and WAN optimizers are conventionally deployed as specialized hardware servers in both network operators' networks and data center networks as the building blocks of the network services. There is a trend to implement such network functions as software instances running on general purpose servers, via a virtualization layer (i.e., hypervisors). These virtualized functions are called Virtualized Network Functions (VNFs), which can be used to build network services.

The use of VNFs introduces additional challenges to the reliability of the provided network services. A single VNF instance would typically not have built-in reliability mechanisms on its host (i.e., a general purpose server). Instead, there are more factors of risk such as software failure at various levels including hypervisors and virtual machines, hardware failure, and instance migration that can make a VNF instance unreliable.

In order to provide a reliable function, a VNF may adopt a pooling mechanism by using a number of VNF instances providing the same function, which we call a "VNF Pool". Conceptionally, a Pool Manager is used to manage the VNF Pool, e.g., selects active/standby VNF instances, and potentially interacts with a service control entity. Such a service control entity is an entity that orchestrates a set of network functions to build network services. The major benefit of using VNF Pool is that reliability mechanisms such as redundancy model are achieved by the VNF Pool inside the VNF and thus not visible to the service control entity. A VNF Pool-enabled VNF still appears as a normal VNF when orchestrated by a service control entity.

Questions that are raised by the addition of a pooling mechanism to VNF include:

*           How to manage the redundancy model, e.g., select active/standby VNF instances in a VNF Pool?

*           What pool states need to be maintained to support the pooling mechanism itself, and how are such states maintained?

*           What information is exchanged between a VNF and a service control entity? For example, how can a VNF Pool be addressed by the service control entity?

*           When a live VNF instance goes out of service, how does the service control entity learn which instance in a VNF Pool will replace it, and learn the characteristics of the new instance?
The WG initially focuses on several reliability mechanisms that are mainly associated with a redundancy model based on a VNF Pool in a VNF. Additional mechanisms that may be needed include state maintenance in a VNF Pool only for pooling purpose (service state synchronization is out of scope). The WG assumes that a VNF Pool contains redundant VNF instances of same functional type. Different types of VNFs are envisoned to be held in separate VNF Pools. The WG will address the reliability of an individual VNF, but not the reliability related to the control or the routing between adjacent VNFs that can form a network service.
Specifically, the WG will work on the following technical aspects:

*           Redundancy management within a VNF Pool, such as the signaling between the Pool Manager and the instances in the pool for instance registration, backup instances selection, and switching between active and standby instances.

*           The protocol between the Pool Manager and the underlying network to collect the network information required for appropriate placement/selection of backup instances.

*           The protocol between a VNF and the service control entity to exchange operational information between a VNF Pool and the service control entity.

*           Identify and analyze reliable transport protocols, such as MPTCP and SCTP for reliable delivery of the messages associated with the redundancy management within a VNF Pool.

*           Analysis of pooling security characteristics and requirements to identify and mitigate threats against the pooling mechanism. Identification of an appropriate trust model between pool members, and between pool members and Pool Manager.
The WG plans to deliver a problem statement, a set of use cases, VNF Pool requirements and an architecture covering the aforementioned technical aspects, and applicability and gap analysis of existing technologies such as RSerPool. 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 redundancy mechanisms, state maintenance solely for pooling purposes, reliable transport, and trust/security, all of which will need to be considered and addressed. The WG will include consideration of the manageability of a VNF Pool. The WG will seek re-chartering before adopting any work to develop new, or extend existing, protocols.

In particular, we will work closely with the SFC WG, as we believe that SFC and VNF Pool are independent but complementary. SFC would essentially see a VNF Pool-enabled VNF as a normal service function and therefore be able to merge it into an SFC just like any other service functions. Information exchanged between the VNF Pool and the SFC may include some operational information from the VNF Pool including the pool address, pool instance characteristic, and so on, as requested by the SFC WG.

Goals and Milestones:
December 2014 - Submit VNFPool Problem Statement to IESG for publication as Informational
April 2015 - Submit VNFPool Use Cases to IESG for publication as Informational
August 2015 - Submit VNFPool Requirements, including the manageability of VNF Pool to IESG for publication as Informational
August 2015 - Submit VNFPool Architecture to IESG for publication as Proposed Standard
December 2015 - Submit Applicability and Gap Analysis of RSerPool to IESG for publication as Informational
==========================================================================

Your comments and suggestions to the charter text are highly appreciated!

Thanks.

-Ning

---

From: "Diego R. Lopez" <[email-masked]>
Date: Tue, 03 Jun 2014 22:23:09 +0000

Hi,

It looks really good to me, Ning!

I am just wondering whether we could give state synchronization a special category (of being "out of scope in this phase" or similar) because I think it is a extremely relevant issue.

Be goode,

On 3 Jun 2014, at 11:35 , Zongning <[email-masked]<mailto:[email-masked]>> wrote:

Hi, folks,

In order to provide a reliable function, a VNF may adopt a pooling mechanism by using a number of VNF instances providing the same function, which we call a “VNF Pool”. Conceptionally, a Pool Manager is used to manage the VNF Pool, e.g., selects active/standby VNF instances, and potentially interacts with a service control entity. Such a service control entity is an entity that orchestrates a set of network functions to build network services. The major benefit of using VNF Pool is that reliability mechanisms such as redundancy model are achieved by the VNF Pool inside the VNF and thus not visible to the service control entity. A VNF Pool-enabled VNF still appears as a normal VNF when orchestrated by a service control entity.

Questions that are raised by the addition of a pooling mechanism to VNF include:
•           How to manage the redundancy model, e.g., select active/standby VNF instances in a VNF Pool?
•           What pool states need to be maintained to support the pooling mechanism itself, and how are such states maintained?
•           What information is exchanged between a VNF and a service control entity? For example, how can a VNF Pool be addressed by the service control entity?
•           When a live VNF instance goes out of service, how does the service control entity learn which instance in a VNF Pool will replace it, and learn the characteristics of the new instance?
The WG initially focuses on several reliability mechanisms that are mainly associated with a redundancy model based on a VNF Pool in a VNF. Additional mechanisms that may be needed include state maintenance in a VNF Pool only for pooling purpose (service state synchronization is out of scope). The WG assumes that a VNF Pool contains redundant VNF instances of same functional type. Different types of VNFs are envisoned to be held in separate VNF Pools. The WG will address the reliability of an individual VNF, but not the reliability related to the control or the routing between adjacent VNFs that can form a network service.
Specifically, the WG will work on the following technical aspects:
•           Redundancy management within a VNF Pool, such as the signaling between the Pool Manager and the instances in the pool for instance registration, backup instances selection, and switching between active and standby instances.
•           The protocol between the Pool Manager and the underlying network to collect the network information required for appropriate placement/selection of backup instances.
•           The protocol between a VNF and the service control entity to exchange operational information between a VNF Pool and the service control entity.
•           Identify and analyze reliable transport protocols, such as MPTCP and SCTP for reliable delivery of the messages associated with the redundancy management within a VNF Pool.
•           Analysis of pooling security characteristics and requirements to identify and mitigate threats against the pooling mechanism. Identification of an appropriate trust model between pool members, and between pool members and Pool Manager.
The WG plans to deliver a problem statement, a set of use cases, VNF Pool requirements and an architecture covering the aforementioned technical aspects, and applicability and gap analysis of existing technologies such as RSerPool. 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 redundancy mechanisms, state maintenance solely for pooling purposes, reliable transport, and trust/security, all of which will need to be considered and addressed. The WG will include consideration of the manageability of a VNF Pool. The WG will seek re-chartering before adopting any work to develop new, or extend existing, protocols.

Goals and Milestones:

Thanks.

-Ning
_______________________________________________
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: Melinda Shore <[email-masked]>
Date: Tue, 03 Jun 2014 14:35:54 -0800

On 6/3/14 2:23 PM, Diego R. Lopez wrote:
> I am just wondering whether we could give state synchronization a 
> special category (of being "out of scope in this phase" or similar) 
> because I think it is a extremely relevant issue.

This is an extremely contested question.  It seems appropriate to me
to view vnfpool as a layered mechanism, where a layer handling the
reliability/redundancy mechanism may carry other traffic, but that
traffic is opaque to the pooling mechanism.  That traffic might
include service state.  But, this is my second go-'round on state
transfer (third, if you include sami, the first one being rserpool
itself) and I really think it's best to be left out of scope with
no specific future plans for the time being, but to allow a generic
transport mechanism in the pooling traffic.

Melinda

-- 
Melinda Shore
No Mountain Software
[email-masked]

"Software longa, hardware brevis."

---

From: <[email-masked]>
Date: Wed, 4 Jun 2014 18:26:30 +0000

Hi Ning,

The charter looks good to me!

In order to solve the state synchronisation issue, you may want to modify the sentence from:

Additional mechanisms that may be needed include state maintenance in a VNF Pool only for pooling purpose (service state synchronization is out of scope).

INTO:

Service state synchronization is out of scope. However, state maintenance mechanisms required in a VNF pool for pooling purposes are also in scope.

Diego, Melinda, does the above change address your concerns.

Best regards,

Georgios

________________________________
Van: vnfpool [[email-masked]] namens Zongning [[email-masked]]
Verzonden: dinsdag 3 juni 2014 11:35
Aan: [email-masked]
Onderwerp: [vnfpool] new VNFPool draft charter

Hi, folks,

Goals and Milestones:

Thanks.

-Ning

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 4 Jun 2014 15:32:26 -0400

Georgios,

I support the proposed charter in general, and this proposed change in
particular. This is important work and is a very necessary part of a VNF
implementation. Working on it in the IETF allows us to take advantage of
related experience and expertise and have output that's useful to the work
in the SFC WG.

Cheers,
Andy

On Wed, Jun 4, 2014 at 2:26 PM, <[email-masked]> wrote:

> Additional mechanisms that may be needed include state maintenance in a
> VNF Pool only for pooling purpose (service state synchronization is out of
> scope).
>
>
>
> INTO:
>
>
>
> Service state synchronization is out of scope. However, state maintenance
> mechanisms required in a VNF pool for pooling purposes are also in scope.
>
>
>
>   ------------------------------
> *Van:* vnfpool [[email-masked]] namens Zongning [
> [email-masked]]
> *Verzonden:* dinsdag 3 juni 2014 11:35
> *Aan:* [email-masked]
> *Onderwerp:* [vnfpool] new VNFPool draft charter
>
>   Hi, folks,
>
>
>
> Please see the below new draft charter of VNFPool. We believe that we have
> updated the charter to address most of the comments from London BoF. Main
> changes are:
>
> 1)       We narrow down our scope to only focus on the redundancy model
> and the related interfaces associated with the VNF Pool in a single VNF.
>
> 2)       Service state synchronization between VNF instances is
> out-of-scope. We may consider how to maintain the pool states in a VNF Pool
> only for pooling purpose.
>
> 3)       We assume that a VNF Pool contains redundant VNF instances of
> same functional type. Different types of VNFs are envisoned to be held in
> separate VNF Pools.
>
> 4)       We do not address reliability related control or routing between
> adjacent VNFs in the service graph. This is also applied to update the
> relation between VNF Pool and SFC WG.
>
>
>
> Network functions such as firewalls, load balancers, and WAN optimizers
> are conventionally deployed as specialized hardware servers in both network
> operators' networks and data center networks as the building blocks of the
> network services. There is a trend to implement such network functions as
> software instances running on general purpose servers, via a virtualization
> layer (i.e., hypervisors). These virtualized functions are called
> Virtualized Network Functions (VNFs), which can be used to build network
> services.
>
>
>
> The use of VNFs introduces additional challenges to the reliability of the
> provided network services. A single VNF instance would typically not have
> built-in reliability mechanisms on its host (i.e., a general purpose
> server). Instead, there are more factors of risk such as software failure
> at various levels including hypervisors and virtual machines, hardware
> failure, and instance migration that can make a VNF instance unreliable.
>
>
>
> In order to provide a reliable function, a VNF may adopt a pooling
> mechanism by using a number of VNF instances providing the same function,
> which we call a “VNF Pool”. Conceptionally, a Pool Manager is used to
> manage the VNF Pool, e.g., selects active/standby VNF instances, and
> potentially interacts with a service control entity. Such a service
> control entity is an entity that orchestrates a set of network functions to
> build network services. The major benefit of using VNF Pool is that
> reliability mechanisms such as redundancy model are achieved by the VNF
> Pool inside the VNF and thus not visible to the service control entity. A
> VNF Pool-enabled VNF still appears as a normal VNF when orchestrated by a service
> control entity.
>
>
>
> ·           How to manage the redundancy model, e.g., select
> active/standby VNF instances in a VNF Pool?
>
> ·           What pool states need to be maintained to support the pooling
> mechanism itself, and how are such states maintained?
>
> ·           What information is exchanged between a VNF and a service
> control entity? For example, how can a VNF Pool be addressed by the service
> control entity?
>
> ·           When a live VNF instance goes out of service, how does the
> service control entity learn which instance in a VNF Pool will replace it,
> and learn the characteristics of the new instance?
>
> The WG initially focuses on several reliability mechanisms that are mainly
> associated with a redundancy model based on a VNF Pool in a VNF. Additional
> mechanisms that may be needed include state maintenance in a VNF Pool
> only for pooling purpose (service state synchronization is out of scope).
> The WG assumes that a VNF Pool contains redundant VNF instances of same
> functional type. Different types of VNFs are envisoned to be held in
> separate VNF Pools. The WG will address the reliability of an individual
> VNF, but not the reliability related to the control or the routing
> between adjacent VNFs that can form a network service.
>
> ·           Redundancy management within a VNF Pool, such as the
> signaling between the Pool Manager and the instances in the pool for
> instance registration, backup instances selection, and switching between
> active and standby instances.
>
> ·           The protocol between the Pool Manager and the underlying
> network to collect the network information required for appropriate
> placement/selection of backup instances.
>
> ·           The protocol between a VNF and the service control entity to
> exchange operational information between a VNF Pool and the service
> control entity.
>
> ·           Identify and analyze reliable transport protocols, such as
> MPTCP and SCTP for reliable delivery of the messages associated with the
> redundancy management within a VNF Pool.
>
> ·           Analysis of pooling security characteristics and requirements
> to identify and mitigate threats against the pooling mechanism.
> Identification of an appropriate trust model between pool members, and
> between pool members and Pool Manager.
>
> The WG plans to deliver a problem statement, a set of use cases, VNF Pool
> requirements and an architecture covering the aforementioned technical
> aspects, and applicability and gap analysis of existing technologies such
> as RSerPool. 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 redundancy mechanisms, state maintenance solely for pooling purposes,
> reliable transport, and trust/security, all of which will need to be
> considered and addressed. The WG will include consideration of the
> manageability of a VNF Pool. The WG will seek re-chartering before adopting
> any work to develop new, or extend existing, protocols.
>
>
>
> In particular, we will work closely with the SFC WG, as we believe that
> SFC and VNF Pool are independent but complementary. SFC would essentially
> see a VNF Pool-enabled VNF as a normal service function and therefore be
> able to merge it into an SFC just like any other service functions.
> Information exchanged between the VNF Pool and the SFC may include some
> operational information from the VNF Pool including the pool address, pool
> instance characteristic, and so on, as requested by the SFC WG.
>
>
>
> Goals and Milestones:
>
> August 2015 - Submit VNFPool Requirements, including the manageability of
> VNF Pool to IESG for publication as Informational
>
> [email-masked]

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 4 Jun 2014 20:12:58 +0000

Ning,

I made some wording changes to the proposed charter. The attached Word document has the changes mark, making it easier to see. In case the mailing list doesn't allow attachment, here is the proposed changes.

Should we also add a paragraph to show why/how VNFpool is different from SFC?

Linda

Network functions such as firewalls, load balancers, and WAN optimizers are conventionally deployed as specialized hardware servers in both network operators' networks and data center networks as the building blocks of the network services. There is a trend to implement such network functions as software instances running on general purpose servers, via a virtualization layer (i.e., hypervisors). These virtualized functions are called Virtualized Network Functions (VNFs), which can be instantiated to build network services.

In order to achieve higher reliability, a pool of VNFs that perform the same function can be grouped together for the network services.  Conceptionally, multiple instances of a same function are grouped together and managed by its Pool Manager. Different functions have different pool manager.  A Pool Manager is responsible for monitoring  the status of the instances in the pool, selecting active/standby instances for specific services, and potentially interacts with other entities, e.g. service control entity or  service orchestration system. The major benefit of using VNF Pool is that reliability mechanisms such as redundancy & protection are achieved by the VNF Pool and thus not visible to the service control entity. A VNF Pool-enabled VNF still appears as a normal VNF when orchestrated by a service control entity.[L1]

*     When a live VNF instance goes out of service, how does the service control entity learn which instance in a VNF Pool will replace it, and learn the characteristics of the new instance?
The WG initially focuses on several reliability mechanisms that are mainly associated with a redundancy model based on a VNF Pool in a VNF. Additional mechanisms might include state maintenance of instances in a VNF Pool only for pooling purpose (service state synchronization is out of scope). The WG assumes that a VNF Pool contains identical VNF instances of same functional type. Different types of VNFs are envisoned to be held in separate VNF Pools. The WG will address the reliability of an individual VNF, but not the reliability related to the control or the routing between adjacent VNFs that can form a network service.

From: vnfpool [mailto:[email-masked]] On Behalf Of Zongning
Sent: Tuesday, June 03, 2014 4:36 AM
To: [email-masked]
Subject: [vnfpool] new VNFPool draft charter

Hi, folks,

Goals and Milestones:

Thanks.

-Ning

 [L1]Not clear of the intent.

Do you mean: "VNF instances in the VNF pool are still visible by the service control entity"?

---

From: "Diego R. Lopez" <[email-masked]>
Date: Wed, 04 Jun 2014 23:08:46 +0000

+1

On 4 Jun 2014, at 21:32 , Andrew G. Malis <[email-masked]<mailto:[email-masked]>> wrote:

Georgios,

I support the proposed charter in general, and this proposed change in particular. This is important work and is a very necessary part of a VNF implementation. Working on it in the IETF allows us to take advantage of related experience and expertise and have output that's useful to the work in the SFC WG.

Cheers,
Andy

On Wed, Jun 4, 2014 at 2:26 PM, <[email-masked]<mailto:[email-masked]>> wrote:

Hi Ning,

INTO:

Best regards,

Georgios

________________________________
Van: vnfpool [[email-masked]<mailto:[email-masked]>] namens Zongning [[email-masked]<mailto:[email-masked]>]
Verzonden: dinsdag 3 juni 2014 11:35
Aan: [email-masked]<mailto:[email-masked]>
Onderwerp: [vnfpool] new VNFPool draft charter

Hi, folks,

Goals and Milestones:

Thanks.

-Ning

Dr Diego R. Lopez
Telefonica I+D

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

---

From: Zongning <[email-masked]>
Date: Thu, 5 Jun 2014 01:11:33 +0000

Hi, Linda,

Thanks for re-wording. I will incorporate some of the suggested changes in the final charter. Specifically, the below sentence means that a VNF appears to outside entity such as service control entity a normal, single VNF (instance), although internally there is a pool for high reliability.
“A VNF Pool-enabled VNF still appears as a normal VNF when orchestrated by a service control entity.”

We do have a dedicated paragraph about relation between VNFPool and SFC – it is the last paragraph of the main text, just above the milestone part. In that paragraph, we don’t emphasize much on how VNFPool and SFC are different (as they are different in nature), but describe how they relate and work with each other.

-Ning

发件人: Linda Dunbar
发送时间: 2014年6月5日 4:13
收件人: Zongning; [email-masked]
主题: RE: new VNFPool draft charter

Ning,

I made some wording changes to the proposed charter. The attached Word document has the changes mark, making it easier to see. In case the mailing list doesn’t allow attachment, here is the proposed changes.

Linda

·           How to manage the redundancy model, e.g., select active/standby VNF instances in a VNF Pool?

·           What pool states need to be maintained to support the pooling mechanism itself, and how are such states maintained?

·           What information is exchanged between a VNF and a service control entity? For example, how can a VNF Pool be addressed by the service control entity?

·           When a live VNF instance goes out of service, how does the service control entity learn which instance in a VNF Pool will replace it, and learn the characteristics of the new instance?
The WG initially focuses on several reliability mechanisms that are mainly associated with a redundancy model based on a VNF Pool in a VNF. Additional mechanisms might include state maintenance of instances in a VNF Pool only for pooling purpose (service state synchronization is out of scope). The WG assumes that a VNF Pool contains identical VNF instances of same functional type. Different types of VNFs are envisoned to be held in separate VNF Pools. The WG will address the reliability of an individual VNF, but not the reliability related to the control or the routing between adjacent VNFs that can form a network service.

From: vnfpool [mailto:[email-masked]] On Behalf Of Zongning
Sent: Tuesday, June 03, 2014 4:36 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [vnfpool] new VNFPool draft charter

Hi, folks,

·           How to manage the redundancy model, e.g., select active/standby VNF instances in a VNF Pool?

·           What pool states need to be maintained to support the pooling mechanism itself, and how are such states maintained?

·           What information is exchanged between a VNF and a service control entity? For example, how can a VNF Pool be addressed by the service control entity?

·           When a live VNF instance goes out of service, how does the service control entity learn which instance in a VNF Pool will replace it, and learn the characteristics of the new instance?
The WG initially focuses on several reliability mechanisms that are mainly associated with a redundancy model based on a VNF Pool in a VNF. Additional mechanisms that may be needed include state maintenance in a VNF Pool only for pooling purpose (service state synchronization is out of scope). The WG assumes that a VNF Pool contains redundant VNF instances of same functional type. Different types of VNFs are envisoned to be held in separate VNF Pools. The WG will address the reliability of an individual VNF, but not the reliability related to the control or the routing between adjacent VNFs that can form a network service.
Specifically, the WG will work on the following technical aspects:

·           Redundancy management within a VNF Pool, such as the signaling between the Pool Manager and the instances in the pool for instance registration, backup instances selection, and switching between active and standby instances.

·           The protocol between the Pool Manager and the underlying network to collect the network information required for appropriate placement/selection of backup instances.

·           The protocol between a VNF and the service control entity to exchange operational information between a VNF Pool and the service control entity.

·           Identify and analyze reliable transport protocols, such as MPTCP and SCTP for reliable delivery of the messages associated with the redundancy management within a VNF Pool.

·           Analysis of pooling security characteristics and requirements to identify and mitigate threats against the pooling mechanism. Identification of an appropriate trust model between pool members, and between pool members and Pool Manager.
The WG plans to deliver a problem statement, a set of use cases, VNF Pool requirements and an architecture covering the aforementioned technical aspects, and applicability and gap analysis of existing technologies such as RSerPool. 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 redundancy mechanisms, state maintenance solely for pooling purposes, reliable transport, and trust/security, all of which will need to be considered and addressed. The WG will include consideration of the manageability of a VNF Pool. The WG will seek re-chartering before adopting any work to develop new, or extend existing, protocols.

Goals and Milestones:

Thanks.

-Ning

 Not clear of the intent.

Do you mean: “VNF instances in the VNF pool are still visible by the service control entity”?

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 5 Jun 2014 16:41:20 -0400

Ning:

This charter is really good.  The focus to a Pool for single VNF of a single
type is a great place to start.  Once we get a working situation we can go
out to important issues like state synchronization.  Like Diego, I agree we
should place the state synchronization “out of scope for this phase”. 

Sue Hares

From: vnfpool [mailto:[email-masked]] On Behalf Of Diego R. Lopez
Sent: Tuesday, June 03, 2014 6:23 PM
To: Zongning
Cc: [email-masked]
Subject: Re: [vnfpool] new VNFPool draft charter

Hi, 

I am just wondering whether we could give state synchronization a special
category (of being "out of scope in this phase" or similar) because I think
it is a extremely relevant issue.

Be goode,

On 3 Jun 2014, at 11:35 , Zongning <[email-masked]> wrote:

Hi, folks,

1)       We narrow down our scope to only focus on the redundancy model and
the related interfaces associated with the VNF Pool in a single VNF.

3)       We assume that a VNF Pool contains redundant VNF instances of same
functional type. Different types of VNFs are envisoned to be held in
separate VNF Pools.

Network functions such as firewalls, load balancers, and WAN optimizers are
conventionally deployed as specialized hardware servers in both network
operators' networks and data center networks as the building blocks of the
network services. There is a trend to implement such network functions as
software instances running on general purpose servers, via a virtualization
layer (i.e., hypervisors). These virtualized functions are called
Virtualized Network Functions (VNFs), which can be used to build network
services.

The use of VNFs introduces additional challenges to the reliability of the
provided network services. A single VNF instance would typically not have
built-in reliability mechanisms on its host (i.e., a general purpose
server). Instead, there are more factors of risk such as software failure at
various levels including hypervisors and virtual machines, hardware failure,
and instance migration that can make a VNF instance unreliable.

In order to provide a reliable function, a VNF may adopt a pooling mechanism
by using a number of VNF instances providing the same function, which we
call a “VNF Pool”. Conceptionally, a Pool Manager is used to manage the VNF
Pool, e.g., selects active/standby VNF instances, and potentially interacts
with a service control entity. Such a service control entity is an entity
that orchestrates a set of network functions to build network services. The
major benefit of using VNF Pool is that reliability mechanisms such as
redundancy model are achieved by the VNF Pool inside the VNF and thus not
visible to the service control entity. A VNF Pool-enabled VNF still appears
as a normal VNF when orchestrated by a service control entity.

Questions that are raised by the addition of a pooling mechanism to VNF
include:

·           How to manage the redundancy model, e.g., select active/standby
VNF instances in a VNF Pool?

The WG initially focuses on several reliability mechanisms that are mainly
associated with a redundancy model based on a VNF Pool in a VNF. Additional
mechanisms that may be needed include state maintenance in a VNF Pool only
for pooling purpose (service state synchronization is out of scope). The WG
assumes that a VNF Pool contains redundant VNF instances of same functional
type. Different types of VNFs are envisoned to be held in separate VNF
Pools. The WG will address the reliability of an individual VNF, but not the
reliability related to the control or the routing between adjacent VNFs that
can form a network service.

·           Redundancy management within a VNF Pool, such as the signaling
between the Pool Manager and the instances in the pool for instance
registration, backup instances selection, and switching between active and
standby instances.

·           The protocol between the Pool Manager and the underlying network
to collect the network information required for appropriate
placement/selection of backup instances.

·           The protocol between a VNF and the service control entity to
exchange operational information between a VNF Pool and the service control
entity.

·           Identify and analyze reliable transport protocols, such as MPTCP
and SCTP for reliable delivery of the messages associated with the
redundancy management within a VNF Pool.

·           Analysis of pooling security characteristics and requirements to
identify and mitigate threats against the pooling mechanism. Identification
of an appropriate trust model between pool members, and between pool members
and Pool Manager.

The WG plans to deliver a problem statement, a set of use cases, VNF Pool
requirements and an architecture covering the aforementioned technical
aspects, and applicability and gap analysis of existing technologies such as
RSerPool. 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
redundancy mechanisms, state maintenance solely for pooling purposes,
reliable transport, and trust/security, all of which will need to be
considered and addressed. The WG will include consideration of the
manageability of a VNF Pool. The WG will seek re-chartering before adopting
any work to develop new, or extend existing, protocols.

In particular, we will work closely with the SFC WG, as we believe that SFC
and VNF Pool are independent but complementary. SFC would essentially see a
VNF Pool-enabled VNF as a normal service function and therefore be able to
merge it into an SFC just like any other service functions. Information
exchanged between the VNF Pool and the SFC may include some operational
information from the VNF Pool including the pool address, pool instance
characteristic, and so on, as requested by the SFC WG.

Goals and Milestones:

December 2014 - Submit VNFPool Problem Statement to IESG for publication as
Informational

April 2015 - Submit VNFPool Use Cases to IESG for publication as
Informational

August 2015 - Submit VNFPool Architecture to IESG for publication as
Proposed Standard

December 2015 - Submit Applicability and Gap Analysis of RSerPool to IESG
for publication as Informational

Thanks.

-Ning

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

Dr Diego R. Lopez
Telefonica I+D

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: "Susan Hares" <[email-masked]>
Date: Thu, 5 Jun 2014 16:44:25 -0400

Melinda:

If we leave it scope for this phase,  but open for some future phase I think
it will help the discussion.  This will allows to build toward this phase.
Of course, I'm coming from the router/SDN platform view point. 

Sue 

-----Original Message-----
From: vnfpool [mailto:[email-masked]] On Behalf Of Melinda Shore
Sent: Tuesday, June 03, 2014 6:36 PM
To: [email-masked]
Subject: Re: [vnfpool] new VNFPool draft charter

> because I think it is a extremely relevant issue.

This is an extremely contested question.  It seems appropriate to me to view
vnfpool as a layered mechanism, where a layer handling the
reliability/redundancy mechanism may carry other traffic, but that traffic
is opaque to the pooling mechanism.  That traffic might include service
state.  But, this is my second go-'round on state transfer (third, if you
include sami, the first one being rserpool
itself) and I really think it's best to be left out of scope with no
specific future plans for the time being, but to allow a generic transport
mechanism in the pooling traffic.

Melinda

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 5 Jun 2014 16:58:30 -0400

Linda and Ning. 

My understanding from this charter is that the pool would be transparent to
whatever entity used it. 

If it was a pool of firewalls, then the VNF would be a firewall. It would be
hidden to SFC or SDN controller wanting to use the firewall that it was part
of a pool. 

This comes from section 4 in the problem statement that states: 

"The main benefit of using VNF Pool is the pooling mechanism such as
redundancy management are achieved by the VNF Pool inside the VNF and
transparent to the Service Control Entity.  The Service control Entity
simply interacts with the Pool Manager in each VNF to request and
orchestrate the network functions with desired reliability level."

To me, in my past work this was important to make the overall process work
simply.   Is this the source of your astute question? 

Sue 

From: vnfpool [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Wednesday, June 04, 2014 4:13 PM
To: Zongning; [email-masked]
Subject: Re: [vnfpool] new VNFPool draft charter

Ning, 

I made some wording changes to the proposed charter. The attached Word
document has the changes mark, making it easier to see. In case the mailing
list doesn't allow attachment, here is the proposed changes. 

Should we also add a paragraph to show why/how VNFpool is different from
SFC? 

Linda

Virtualized Network Functions (VNFs), which can be instantiated to build
network services.

In order to achieve higher reliability, a pool of VNFs that perform the same
function can be grouped together for the network services.  Conceptionally,
multiple instances of a same function are grouped together and managed by
its Pool Manager. Different functions have different pool manager.  A Pool
Manager is responsible for monitoring  the status of the instances in the
pool, selecting active/standby instances for specific services, and
potentially interacts with other entities, e.g. service control entity or
service orchestration system. The major benefit of using VNF Pool is that
reliability mechanisms such as redundancy & protection are achieved by the
VNF Pool and thus not visible to the service control entity. A VNF
Pool-enabled VNF still appears as a normal VNF when orchestrated by a
service control entity.[L1] <>   

.       How to manage the redundancy model, e.g., select active/standby VNF
instances in a VNF Pool?

.       What pool states need to be maintained to support the pooling
mechanism itself, and how are such states maintained?

.       What information is exchanged between a VNF and a service control
entity? For example, how can a VNF Pool be addressed by the service control
entity?

.       When a live VNF instance goes out of service, how does the service
control entity learn which instance in a VNF Pool will replace it, and learn
the characteristics of the new instance?

The WG initially focuses on several reliability mechanisms that are mainly
associated with a redundancy model based on a VNF Pool in a VNF. Additional
mechanisms might include state maintenance of instances in a VNF Pool only
for pooling purpose (service state synchronization is out of scope). The WG
assumes that a VNF Pool contains identical VNF instances of same functional
type. Different types of VNFs are envisoned to be held in separate VNF
Pools. The WG will address the reliability of an individual VNF, but not the
reliability related to the control or the routing between adjacent VNFs that
can form a network service.

 

Hi, folks,

call a "VNF Pool". Conceptionally, a Pool Manager is used to manage the VNF

.       How to manage the redundancy model, e.g., select active/standby VNF
instances in a VNF Pool?

.       What pool states need to be maintained to support the pooling
mechanism itself, and how are such states maintained?

.       What information is exchanged between a VNF and a service control
entity? For example, how can a VNF Pool be addressed by the service control
entity?

.       When a live VNF instance goes out of service, how does the service
control entity learn which instance in a VNF Pool will replace it, and learn
the characteristics of the new instance?

.           Redundancy management within a VNF Pool, such as the signaling
between the Pool Manager and the instances in the pool for instance
registration, backup instances selection, and switching between active and
standby instances.

.           The protocol between the Pool Manager and the underlying network
to collect the network information required for appropriate
placement/selection of backup instances.

.           The protocol between a VNF and the service control entity to
exchange operational information between a VNF Pool and the service control
entity.

.           Identify and analyze reliable transport protocols, such as MPTCP
and SCTP for reliable delivery of the messages associated with the
redundancy management within a VNF Pool.

.           Analysis of pooling security characteristics and requirements to
identify and mitigate threats against the pooling mechanism. Identification
of an appropriate trust model between pool members, and between pool members
and Pool Manager.

Goals and Milestones:

Thanks.

-Ning

  _____  

 Not clear of the intent. 

Do you mean: "VNF instances in the VNF pool are still visible by the service
control entity"?

---

From: Melinda Shore <[email-masked]>
Date: Thu, 05 Jun 2014 13:02:58 -0800

> Of course, I'm coming from the router/SDN platform view point. 

I think it will help among people who'd like to use it but
hurt us politically, to be frank - this is an issue that always
raises a lot of ire in the quarter of the IETF in which we're
now operating.  We'd also be faced with the difficult of answering
the question of why a vendor would want a customer to be able to fail,
say, their firewall over to another vendor's firewall.  The obvious
answer to that is that customers want it, but that doesn't mean
that vendors will implement that kind of mechanism, and when we've
done polls about this kind of thing we haven't been able to get
any vendor to say they'd do it.  So, if people really want to
include text saying that this is future work, by all means do so
but do so with knowledge of how discussions have gone in the very
recent past.

And to be clear, to say that it's out of scope means that it's out of
scope *now* - as we know all decisions may be revisited in the
future.

Melinda

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 5 Jun 2014 17:18:59 -0400

Melinda:

If it is a layer 9 issue (politics) to get the work started, then it out of
scope. I really just want to get going on this work. 

Sue 

-----Original Message-----
From: vnfpool [mailto:[email-masked]] On Behalf Of Melinda Shore
Sent: Thursday, June 05, 2014 5:03 PM
To: [email-masked]
Subject: Re: [vnfpool] new VNFPool draft charter

On 6/5/14 12:44 PM, Susan Hares wrote:
> Melinda:
> 
> If we leave it scope for this phase,  but open for some future phase I 
> think it will help the discussion.  This will allows to build toward this
phase.
> Of course, I'm coming from the router/SDN platform view point. 

I think it will help among people who'd like to use it but hurt us
politically, to be frank - this is an issue that always raises a lot of ire
in the quarter of the IETF in which we're now operating.  We'd also be faced
with the difficult of answering the question of why a vendor would want a
customer to be able to fail, say, their firewall over to another vendor's
firewall.  The obvious answer to that is that customers want it, but that
doesn't mean that vendors will implement that kind of mechanism, and when
we've done polls about this kind of thing we haven't been able to get any
vendor to say they'd do it.  So, if people really want to include text
saying that this is future work, by all means do so but do so with knowledge
of how discussions have gone in the very recent past.

And to be clear, to say that it's out of scope means that it's out of scope
*now* - as we know all decisions may be revisited in the future.

Melinda

---

From: Zongning <[email-masked]>
Date: Fri, 6 Jun 2014 01:57:14 +0000

Hi, Sue,

Yes, this is exactly what we mean in both PS draft and charter text. The pooling is transparent to outside service control entities/controllers using VNF to implement services.

Thanks.

-Ning

发件人: Susan Hares [mailto:[email-masked]]
发送时间: 2014年6月6日 4:59
收件人: Linda Dunbar; Zongning; [email-masked]
主题: RE: [vnfpool] new VNFPool draft charter

Linda and Ning.

My understanding from this charter is that the pool would be transparent to whatever entity used it.

If it was a pool of firewalls, then the VNF would be a firewall. It would be hidden to SFC or SDN controller wanting to use the firewall that it was part of a pool.

This comes from section 4 in the problem statement that states:
“The main benefit of using VNF Pool is the pooling mechanism such as redundancy management are achieved by the VNF Pool inside the VNF and transparent to the Service Control Entity.  The Service control Entity simply interacts with the Pool Manager in each VNF to request and orchestrate the network functions with desired reliability level.”

To me, in my past work this was important to make the overall process work simply.   Is this the source of your astute question?

Sue

From: vnfpool [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Wednesday, June 04, 2014 4:13 PM
To: Zongning; [email-masked]<mailto:[email-masked]>
Subject: Re: [vnfpool] new VNFPool draft charter

Ning,

Linda

・           How to manage the redundancy model, e.g., select active/standby VNF instances in a VNF Pool?

・           What pool states need to be maintained to support the pooling mechanism itself, and how are such states maintained?

・           What information is exchanged between a VNF and a service control entity? For example, how can a VNF Pool be addressed by the service control entity?

・           When a live VNF instance goes out of service, how does the service control entity learn which instance in a VNF Pool will replace it, and learn the characteristics of the new instance?
The WG initially focuses on several reliability mechanisms that are mainly associated with a redundancy model based on a VNF Pool in a VNF. Additional mechanisms might include state maintenance of instances in a VNF Pool only for pooling purpose (service state synchronization is out of scope). The WG assumes that a VNF Pool contains identical VNF instances of same functional type. Different types of VNFs are envisoned to be held in separate VNF Pools. The WG will address the reliability of an individual VNF, but not the reliability related to the control or the routing between adjacent VNFs that can form a network service.

Hi, folks,

・           How to manage the redundancy model, e.g., select active/standby VNF instances in a VNF Pool?

・           What pool states need to be maintained to support the pooling mechanism itself, and how are such states maintained?

・           What information is exchanged between a VNF and a service control entity? For example, how can a VNF Pool be addressed by the service control entity?

・           When a live VNF instance goes out of service, how does the service control entity learn which instance in a VNF Pool will replace it, and learn the characteristics of the new instance?
The WG initially focuses on several reliability mechanisms that are mainly associated with a redundancy model based on a VNF Pool in a VNF. Additional mechanisms that may be needed include state maintenance in a VNF Pool only for pooling purpose (service state synchronization is out of scope). The WG assumes that a VNF Pool contains redundant VNF instances of same functional type. Different types of VNFs are envisoned to be held in separate VNF Pools. The WG will address the reliability of an individual VNF, but not the reliability related to the control or the routing between adjacent VNFs that can form a network service.
Specifically, the WG will work on the following technical aspects:

・           Redundancy management within a VNF Pool, such as the signaling between the Pool Manager and the instances in the pool for instance registration, backup instances selection, and switching between active and standby instances.

・           The protocol between the Pool Manager and the underlying network to collect the network information required for appropriate placement/selection of backup instances.

・           The protocol between a VNF and the service control entity to exchange operational information between a VNF Pool and the service control entity.

・           Identify and analyze reliable transport protocols, such as MPTCP and SCTP for reliable delivery of the messages associated with the redundancy management within a VNF Pool.

・           Analysis of pooling security characteristics and requirements to identify and mitigate threats against the pooling mechanism. Identification of an appropriate trust model between pool members, and between pool members and Pool Manager.
The WG plans to deliver a problem statement, a set of use cases, VNF Pool requirements and an architecture covering the aforementioned technical aspects, and applicability and gap analysis of existing technologies such as RSerPool. 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 redundancy mechanisms, state maintenance solely for pooling purposes, reliable transport, and trust/security, all of which will need to be considered and addressed. The WG will include consideration of the manageability of a VNF Pool. The WG will seek re-chartering before adopting any work to develop new, or extend existing, protocols.

Goals and Milestones:

Thanks.

-Ning

 Not clear of the intent.

---

From: Zongning <[email-masked]>
Date: Fri, 6 Jun 2014 02:04:19 +0000

Hi, Sue, Melinda, and Diego,

I don't see any controversy in your views. As said by Melinda, it's out of scope means that it's out of scope *now*, or *in this phase*.

So I'd propose:
service state synchronization is out of scope - > service state synchronization is out of scope in this phase.

Make sense?

Thanks,

-Ning

-----邮件原件-----
发件人: vnfpool [mailto:[email-masked]] 代表 Susan Hares
发送时间: 2014年6月6日 5:19
收件人: 'Melinda Shore'; [email-masked]
主题: Re: [vnfpool] new VNFPool draft charter

Melinda:

If it is a layer 9 issue (politics) to get the work started, then it out of scope. I really just want to get going on this work. 

Sue 

-----Original Message-----
From: vnfpool [mailto:[email-masked]] On Behalf Of Melinda Shore
Sent: Thursday, June 05, 2014 5:03 PM
To: [email-masked]
Subject: Re: [vnfpool] new VNFPool draft charter

phase.
> Of course, I'm coming from the router/SDN platform view point. 

I think it will help among people who'd like to use it but hurt us politically, to be frank - this is an issue that always raises a lot of ire in the quarter of the IETF in which we're now operating.  We'd also be faced with the difficult of answering the question of why a vendor would want a customer to be able to fail, say, their firewall over to another vendor's firewall.  The obvious answer to that is that customers want it, but that doesn't mean that vendors will implement that kind of mechanism, and when we've done polls about this kind of thing we haven't been able to get any vendor to say they'd do it.  So, if people really want to include text saying that this is future work, by all means do so but do so with knowledge of how discussions have gone in the very recent past.

Melinda

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 6 Jun 2014 18:38:16 +0000

Hi Ning,

the charter looks good to me and is valuable. I am very much in favor of this work. 

Concerning "a VNF may adopt a pooling mechanism by using a number of VNF instances providing the same function, which we call a “VNF Pool”."

I think a VNF exists as a template plus a SW package, which can be instantiated to create VNF instances. It is probably not the best wording if we say: "A VNF uses a number of VNF instances providing the same function."
	
Would the text below work for you?
"a VNF may adopt a pooling mechanism, where a "VNF Pool" is used comprising a number of VNF instances with the same function."

s/normal/regular/

Cheers, 
Mehmet 

> From: vnfpool [mailto:[email-masked]] On Behalf Of ext
> Zongning
> Sent: Friday, June 06, 2014 4:04 AM
> To: Susan Hares; 'Melinda Shore'; [email-masked]
> Subject: [vnfpool] 答复: new VNFPool draft charter
> 
> I don't see any controversy in your views. As said by Melinda, it's out
> of scope means that it's out of scope *now*, or *in this phase*.
> 
> So I'd propose:
> service state synchronization is out of scope - > service state
> synchronization is out of scope in this phase.
> 
> Make sense?
> 
> Thanks,
> 
> -Ning
> 
> -----邮件原件-----
> If it is a layer 9 issue (politics) to get the work started, then it
> out of scope. I really just want to get going on this work.
> 
> Sue
> 
> politically, to be frank - this is an issue that always raises a lot of
> ire in the quarter of the IETF in which we're now operating.  We'd also
> be faced with the difficult of answering the question of why a vendor
> would want a customer to be able to fail, say, their firewall over to
> another vendor's firewall.  The obvious answer to that is that
> customers want it, but that doesn't mean that vendors will implement
> that kind of mechanism, and when we've done polls about this kind of
> thing we haven't been able to get any vendor to say they'd do it.  So,
> if people really want to include text saying that this is future work,
> by all means do so but do so with knowledge of how discussions have
> gone in the very recent past.
> 
> scope

---

From: Zu Qiang <[email-masked]>
Date: Fri, 6 Jun 2014 18:40:47 +0000

Hello, Zongning
                Thanks for updating the charter. It looks better than the first version. However, I have some concerns below:

-          It is good to narrow down the scope to redundancy module only. I’m assuming that a transparent redundancy module is the preferable solution of this WG. With transparent solutions, no impacts are expected on the pool user. Therefore, I would avoid any linkage with SFC.

-          I also don’t understand the statement “When a live VNF instance goes out of service, how does the service control entity learn which instance in a VNF Pool will replace it, and learn the characteristics of the new instance?” If transparent solutions are expected, why SCE needs to learn the failover?

-          There was some discussions in the mailing list regarding the virtualized/non-virtualized case where a network application may run on a server with/without a hypervisor. In both cases (with/without a hypervisor), the application may not have any redundancy solutions. Both cases shall be covered by the solutions provided by this WG. However the charter only have virtualized functions covered. Is the non-virtualized use case out of the scope?

-          Some statements, such as “Identify and analyze reliable transport protocols”, sounds like we do have a specific solution already. I won’t assume there is always an IP connection between the pool manager and the pool instance. The interface between the two entities can be a TCP based protocol if there is an IP connection, or it can be an API if they both locate in the same server. It is real dependence on the solutions itself. Besides, if HW redundancy is needed that there may be always a “remote” instance. The question is really how the “remote” instance is handled, by whom; what homogeneity is assumed or whether this should be part of the investigation. If it is expected that the VNF instances of a pool come from different vendors then even the state synchronization becomes an issue. If the pools are expected to be built from identical instances then one questions why should the pool manager come from a different vendor. I won’t want to see any solution limitations at this stage of the discussion. And I prefer to keep it open until the solution discussion phase.

-          My assumption is that the output from this proposed WG is one or more generic HA solutions. As we are in the early stage of the discussion, I don’t think we shall limit the solution to a specific one. I do have a hard time to understand why the Applicability and Gap Analysis shall be done based on a specific protocol?

-          Reading the charter, it is not very clear that what the scope of the VNF is. Is it the service/function, or the entities providing this service/function? Some clarification of this use would be good.

Have a nice day
Zu Qiang

From: vnfpool [mailto:[email-masked]] On Behalf Of Zongning
Sent: Tuesday, June 03, 2014 5:36 AM
To: [email-masked]
Subject: [vnfpool] new VNFPool draft charter

Hi, folks,

Goals and Milestones:

Thanks.

-Ning

---

From: <[email-masked]>
Date: Fri, 6 Jun 2014 20:59:13 +0200

Hi,

From my point of view this should be also in scope. Otherwise you are not able to include non virtualized functions (which is necessary due to the reasons already pointed out by Pedro) in the framework itself.  It should be possible to have a pool of virtualized and non-virtualized functions which can be used based on the requirements derived from the services.

   Regards

     Nic

Hi, folks,

Goals and Milestones:

Thanks.

-Ning

---

From: Zu Qiang <[email-masked]>
Date: Fri, 6 Jun 2014 19:07:46 +0000

Hello, Nic
                That’s my understanding as well.

Have a nice weekend
Zu Qiang

From: [email-masked] [mailto:[email-masked]]
Sent: Friday, June 06, 2014 2:59 PM
To: Zu Qiang; [email-masked]; [email-masked]
Subject: AW: new VNFPool draft charter

Hi,

   Regards

     Nic

Hi, folks,

Goals and Milestones:

Thanks.

-Ning

---

From: Melinda Shore <[email-masked]>
Date: Fri, 06 Jun 2014 11:09:42 -0800

On 6/6/14 10:40 AM, Zu Qiang wrote:
> -          It is good to narrow down the scope to redundancy module
> only. I’m assuming that a transparent redundancy module is the
> preferable solution of this WG. With transparent solutions, no impacts
> are expected on the pool user. Therefore, I would avoid any linkage with
> SFC.

We tried that!  There's some fairly deep concern about
overlap, and about whether or not some of this might encroach
on sfc turf - that was probably the main issue raised at
the BOF at IETF 89.  Because of that it's necessary to highlight
the differences between the work and clarify the relationship
between what sfc is doing and what vnfpool would do.

> -          I also don’t understand the statement “When a live VNF
> instance goes out of service, how does the service control entity learn
> which instance in a VNF Pool will replace it, and learn the
> characteristics of the new instance?” If transparent solutions are
> expected, why SCE needs to learn the failover?

That's a good point.

> -          My assumption is that the output from this proposed WG is one
> or more generic HA solutions. As we are in the early stage of the
> discussion, I don’t think we shall limit the solution to a specific one.
> I do have a hard time to understand why the Applicability and Gap
> Analysis shall be done based on a specific protocol?

IETF work tends to be bottom-up - specific, discrete, concrete
pieces of work are identified and scoped.  We don't solve A Big
Problem and assume it's generally applicable, but rather do work
of the nature of "Here's how to use <x> to do <y>."  It may in
fact turn out that there's interest in developing an availability
mechanism based on a different architectural model, and that's
okay.

> -          Reading the charter, it is not very clear that what the scope
> of the VNF is. Is it the service/function, or the entities providing
> this service/function? 

I think this is the question that "service state synchronization is
out of scope" answers.

Melinda

---

From: Zu Qiang <[email-masked]>
Date: Fri, 6 Jun 2014 19:20:41 +0000

Have a nice day
Zu Qiang

>> discussion, I don't think we shall limit the solution to a specific one.
>IETF work tends to be bottom-up - specific, discrete, concrete pieces of work are
>identified and scoped.  We don't solve A Big Problem and assume it's generally
>applicable, but rather do work of the nature of "Here's how to use <x> to do
><y>."  It may in fact turn out that there's interest in developing an availability
>mechanism based on a different architectural model, and that's okay.
>

[Zu Qiang] Just for my clarification. Does that means all the WG discussion must be based on that specific solution from day one?

---

From: Melinda Shore <[email-masked]>
Date: Fri, 06 Jun 2014 11:26:56 -0800

> [Zu Qiang] Just for my clarification. Does that means all the WG discussion must be based on that specific solution from day one?

The working group hasn't been chartered yet, but if a group
is formed based on some version of the current charter, the
documents need to stick to that charter.  If there's a proposal
for a reliability mechanism based on a different model the
best thing to do is to prepare a draft and get feedback on it,
and create interest.  But, if there's no specific proposal
but broad interest in discussing availability/reliability
mechanisms more generally, it may be possible to create a
non-WG mailing list.

Melinda

---

From: Zongning <[email-masked]>
Date: Mon, 9 Jun 2014 02:28:14 +0000

Hi, Qiang,

Thanks for the comments. Please see inline.

[Ning] Yes, the pooling mechanism will be transparent to the pool user. But a VNF including a VNF Pool (we call a VNFPool-enabled VNF) will be used as a normal VNF in a service chain to build a network service. Therefore, from the service orchestration point of view, some features (mostly operational, NOT pooling mechanism) of a VNFPool-enabled VNF such as address/location, load capability, etc., are still needed by the service control entity.

[Ning] Excellent point! You are right that this sentence is somehow misleading. How about a new sentence like - “After a VNF instance failover, how does the Pool Manager notify the service control entity some characteristic changes of the VNF, but without disclosure of the pooling procedure?”.

[Ning] I agree with you, Nic and Pedro that the solution should be applicable to non-virtualized function, from the pooling perspective. But, consider that we currently don’t describe any specific solution in the charter, how about add a new sentence like – “VNF Pool composed by both virtualized and non-virtualized functional instances will be included after further use case and requirements study”. With this statement, I’d solicit you all to bring use case and requirement for the pooling of non-virtualized function, to help the future solution developed by the WG to cover both. ☺

[Ning] I think the statement “Identify and analyze reliable transport protocols” is more like a requirement for the reliable delivery of pooling messages. We give examples of existing IETF solution like MPTCP, but this doesn’t mean we have already determined the solution at this stage. You are right that we are open to solutions and solution discussion will be in next phase.

[Ning] I believe you had misunderstood the Applicability and Gap Analysis I-D (to RSerPool) at this point. ☺ I think anyone (other than RSerPool folks) can bring their I-D about applicability and gap analysis to solution “x”. Currently we have an I-D based on RSerPool. But this doesn’t mean that the WG will start solution based on RSerPool. We will be looking at more reference solutions and find out which parts of them can be reused/extended/referred/etc.

[Ning] In  our charter, a VNF includes a pool of VNF instances implementing a certain function (not a whole service), and a manager to interface with the outside service control entity to provide such function. So I assume a VNF has both roles in your question. Does it make sense? Or you have some suggested text to further clarify this issue? ☺

I hope my reply helps to address your concerns. Otherwise please let me know.

-Ning

---

From: Zongning <[email-masked]>
Date: Mon, 9 Jun 2014 02:37:40 +0000

Hi, Qiang,

I don’t believe the WG discussion will be based on any specific solution at this stage. Reading the charter, it says:
"The WG plans to deliver a problem statement, a set of use cases, VNF Pool requirements and an architecture covering the aforementioned technical aspects, and applicability and gap analysis of existing technologies.", and
"The WG will seek re-chartering before adopting any work to develop new, or extend existing, protocols."

Please let us know any statement in the charter that makes you feel that we are doing solution right now. We can do re-wording. :-)

Thanks.

-Ning

-----邮件原件-----
发件人: vnfpool [mailto:[email-masked]] 代表 Zu Qiang
发送时间: 2014年6月7日 3:21
收件人: Melinda Shore; [email-masked]
主题: Re: [vnfpool] new VNFPool draft charter

Have a nice day
Zu Qiang

>IETF work tends to be bottom-up - specific, discrete, concrete pieces 
>of work are identified and scoped.  We don't solve A Big Problem and 
>assume it's generally applicable, but rather do work of the nature of 
>"Here's how to use <x> to do <y>."  It may in fact turn out that 
>there's interest in developing an availability mechanism based on a different architectural model, and that's okay.
>

---

From: Zongning <[email-masked]>
Date: Mon, 9 Jun 2014 02:42:22 +0000

Hi, Nic,

I agree with you, Qiang, Pedro on this point, and has proposed a sentence to address this in my reply to Qiang’s discussion - “VNF Pool composed by both virtualized and non-virtualized functional instances will be included after further use case and requirements study”.

Please let us know your further suggestions & comments.

Thanks.

-Ning

发件人: [email-masked] [mailto:[email-masked]]
发送时间: 2014年6月7日 2:59
收件人: [email-masked]; Zongning; [email-masked]
主题: AW: new VNFPool draft charter

Hi,

   Regards

     Nic

Hi, folks,

Goals and Milestones:

Thanks.

-Ning

---

From: Zongning <[email-masked]>
Date: Mon, 9 Jun 2014 03:02:17 +0000

Hi, Mehmet,

Thanks for your support and suggestions!

Yes, I agree that we can do better wording (combing what you and Linda have suggested) along the lines of - 
"a VNF may adopt a pooling mechanism, where a number of VNF instances with the same function can be grouped as a pool to provide the function. We call such a pool a VNF Pool.".

-Ning

-----邮件原件-----
发件人: Ersue, Mehmet (NSN - DE/Munich) [mailto:[email-masked]] 
发送时间: 2014年6月7日 2:38
收件人: Zongning; [email-masked]
主题: RE: [vnfpool] 答复: new VNFPool draft charter

Hi Ning,

	

s/normal/regular/

Cheers, 
Mehmet

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 9 Jun 2014 09:49:00 +0000

WFM

Cheers, 
Mehmet 

> From: ext Zongning [mailto:[email-masked]]
> Sent: Monday, June 09, 2014 5:02 AM
> To: Ersue, Mehmet (NSN - DE/Munich); [email-masked]
> Subject: 答复: [vnfpool] 答复: new VNFPool draft charter
> 
> Hi, Mehmet,
> 
> "a VNF may adopt a pooling mechanism, where a number of VNF instances
> with the same function can be grouped as a pool to provide the
> function. We call such a pool a VNF Pool.".
> 
> -Ning
> 
> -----邮件原件-----
> Concerning "a VNF may adopt a pooling mechanism by using a number of
> VNF instances providing the same function, which we call a “VNF Pool”."
> 
> I think a VNF exists as a template plus a SW package, which can be
> instantiated to create VNF instances. It is probably not the best
> wording if we say: "A VNF uses a number of VNF instances providing the
> same function."
> 
> "a VNF may adopt a pooling mechanism, where a "VNF Pool" is used
> comprising a number of VNF instances with the same function."
> 
> s/normal/regular/
> 
> Cheers,
> Mehmet
> 
> 
> > > If we leave it scope for this phase,  but open for some future
> phase
> > I
> > > think it will help the discussion.  This will allows to build
> toward
> > > this
> > phase.

---

From: Zu Qiang <[email-masked]>
Date: Tue, 10 Jun 2014 01:30:51 +0000

Hello, Zongning
                Thanks for your reply. See inline below.
Have a nice day
Zu Qiang

From: Zongning [mailto:[email-masked]]
Sent: Sunday, June 08, 2014 10:28 PM
To: Zu Qiang; [email-masked]
Subject: 答复: new VNFPool draft charter

Hi, Qiang,

[Ning] Yes, the pooling mechanism will be transparent to the pool user. But a VNF including a VNF Pool (we call a VNFPool-enabled VNF) will be used as a normal VNF in a service chain to build a network service. Therefore, from the service orchestration point of view, some features (mostly operational, NOT pooling mechanism) of a VNFPool-enabled VNF such as address/location, load capability, etc., are still needed by the service control entity.
[Zu Qiang] My understanding is that SFC is just one of the VNF pool users. It shall not make any different with another network applications which will use the VNF pool for redundancy. Therefore I don’t see any need for a linkage with SFC in the charter.

[Ning] Excellent point! You are right that this sentence is somehow misleading. How about a new sentence like - “After a VNF instance failover, how does the Pool Manager notify the service control entity some characteristic changes of the VNF, but without disclosure of the pooling procedure?”.
[Zu Qiang] It’s good that you agree with me. The PM-SCE interface is more for the purpose of the pool OAM. The PM shall report to the SCE with the pool status (including both the application and the HW) at any time or periodically, right? Therefore the above statement shall be in the scope of the normal OAM report, isn’t it? Failover is just a normal HA procedure. The SCE doesn’t have to know it. If the failover is due to an application error, the PM may have enough capability to handle it. But if the failover is due to a HW or VM problem where new network resource allocation may be needed, it may be good to inform the SCE. If that is agreeable, I propose some rewording such as “How does the Pool Manager notify the Service Control Entity of some characteristic changes of the VNF, e.g. system failure, but without disclosure of the pooling procedure?”

[Ning] I agree with you, Nic and Pedro that the solution should be applicable to non-virtualized function, from the pooling perspective. But, consider that we currently don’t describe any specific solution in the charter, how about add a new sentence like – “VNF Pool composed by both virtualized and non-virtualized functional instances will be included after further use case and requirements study”. With this statement, I’d solicit you all to bring use case and requirement for the pooling of non-virtualized function, to help the future solution developed by the WG to cover both. :)
[Zu Qiang] Great.

[Ning] I think the statement “Identify and analyze reliable transport protocols” is more like a requirement for the reliable delivery of pooling messages. We give examples of existing IETF solution like MPTCP, but this doesn’t mean we have already determined the solution at this stage. You are right that we are open to solutions and solution discussion will be in next phase.
[Zu Qiang] If that’s the case, please make it clear in the charter. And I propose to reword with “Identify and analyze reliable interfaces transport protocols”

[Ning] I believe you had misunderstood the Applicability and Gap Analysis I-D (to RSerPool) at this point. :) I think anyone (other than RSerPool folks) can bring their I-D about applicability and gap analysis to solution “x”. Currently we have an I-D based on RSerPool. But this doesn’t mean that the WG will start solution based on RSerPool. We will be looking at more reference solutions and find out which parts of them can be reused/extended/referred/etc.
[Zu Qiang] If that’s the case, it would be good to make it clear in the charter to avoid any misunderstandings or layer 9 issues.

[Ning] In  our charter, a VNF includes a pool of VNF instances implementing a certain function (not a whole service), and a manager to interface with the outside service control entity to provide such function. So I assume a VNF has both roles in your question. Does it make sense? Or you have some suggested text to further clarify this issue? :)
[Zu Qiang] So the WG will work on the Pool enabled VNF (not the generic VNF), right? :) And a Pool enabled VNF including the VNF function and the network entities (e.g. HW, interface, etc.), right? It is better to add this clarification in the charter.

-Ning

---

From: Zongning <[email-masked]>
Date: Tue, 10 Jun 2014 02:52:39 +0000

Hi, Qiang,

Please see inline.

[Ning] The reason we describe the relation between SFC and VNFPool is mainly based on the conclusion of London BoF, where people wanted to see such relation to be clearly addressed in the new charter. I agree with you that SFC is just one type of service control entities/pool users, so we don’t state how SFC differ from other pool users in the charter. If you still feel uncomfortable, I’d replace the last sentence to “Just like the communication between any pool user and VNF Pool, the information exchanged between the VNF Pool and the SFC may include some operational information of the VNF Pool”. Make sense?

[Ning] Your understanding is correct. But I don’t think “system failure” is clear enough, as “system” is a fairly general term. How about “resource re-allocation”, or “load/capacity change”?

[Ning] I am OK with your proposal.

[Ning] Deal! No issues above layer 7. :)

[Ning]Yes, the WG will focus on Pool enabled VNF. However, to be clear, we are not working on HW/hypervisor layer functionalities. We focus on VNF function, and the associated resource status for pool OAM purpose only (as discussed in the second item above).

-Ning