[vnfpool] Updated VNFPool Charter

[Zongning]

Dear all,
Based on the list discussion since we posted the last version, I have made some (minor) revision of the charter. The main changes are:

1) State that service state synchronization is out of scope "in this phase";

2) Include VNF Pool with both virtualized and non-virtualized network function for further study;

3) Explicitly state that the reference solution & gap analysis is not limited to RSerPool, but open to any other solutions, although no decision on protocols will be made in this phase;

4) State that the linkage between SFC and VNF Pool is just like a pool user and a pool - nothing specified (yet);

5) Update bullet #4 under "Questions that are raised...", to keep it consistent with the idea that pooling is not visible to the service control entity.
==========================================================================
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 achieve higher reliability, 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.Conceptually, a Pool Manager is used to manage a 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?

* After a VNF instance failover, how does the Pool Manager notify the service control entity some characteristic changes of the VNF, e.g., capacity change, but without disclosure of the pooling procedure?
The WG initially focuses on several reliability mechanisms that are mainly associated with a redundancy model based on a VNF Pool. Additional mechanisms may include pool state maintenance only for pooling purpose. Service state synchronization is out of scope for this phase. The WG assumes that a VNF Pool contains redundant VNF instances of same functional type. Different types of VNFs are envisioned to be held in separate VNF Pools. VNF Pool composed by both virtualized and non-virtualized functional instances may be included after further use case and requirements study. 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 interfaces, such as transport protocol like 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 the Pool Manager.
The WG plans to deliver a problem statement, a set of use cases, requirements and an architecture covering the aforementioned technical aspects, and applicability and gap analysis of existing technologies including but not limited to RSerPool. We will 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. Although no decision on protocols will be made in this phase, we will keep open for candidate protocols for 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. Just like the communication between any pool users and VNF Pool, the information exchanged between the VNF Pool and the SFC may include some operational information of the VNF Pool.
Goals and Milestones:
December 2014 - Submit VNFPool Problem Statement to IESG for publication as an Informational document.
April 2015 - Submit VNFPool Use Cases to IESG for publication as an Informational document.
August 2015 - Submit VNFPool Requirements, including the manageability of VNF Pool to IESG for publication as an Informational document.
August 2015 - Submit VNFPool Architecture to IESG for publication as an Informational document.
December 2015 - Submit one or more Applicability and Gap Analysis of existing protocols to VNFPool to IESG for publication as Informational document(s).
==========================================================================

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

Thanks.

-Ning

[Zongning]

Dear all,

Please review the charter text included in the last email. We are hoping that a general consensus on the charter could be achieved on the list, then a stable charter is ready for the VNFPool session in Toronto.

Thanks.

-Ning

·¢ŒþÈË: vnfpool [mailto:vnfpool-***@ietf.org] Žú±í Zongning
·¢ËÍʱŒä: 2014Äê6ÔÂ12ÈÕ 11:20
ÊÕŒþÈË: ***@ietf.org
Ö÷Ìâ: [vnfpool] Updated VNFPool Charter

Dear all,
Based on the list discussion since we posted the last version, I have made some (minor) revision of the charter. The main changes are:

1) State that service state synchronization is out of scope ¡°in this phase¡±;

2) Include VNF Pool with both virtualized and non-virtualized network function for further study;

3) Explicitly state that the reference solution & gap analysis is not limited to RSerPool, but open to any other solutions, although no decision on protocols will be made in this phase;

4) State that the linkage between SFC and VNF Pool is just like a pool user and a pool šC nothing specified (yet);

5) Update bullet #4 under ¡°Questions that are raised¡­¡±, to keep it consistent with the idea that pooling is not visible to the service control entity.
==========================================================================
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 achieve higher reliability, 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.Conceptually, a Pool Manager is used to manage a 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?

¡€ After a VNF instance failover, how does the Pool Manager notify the service control entity some characteristic changes of the VNF, e.g., capacity change, but without disclosure of the pooling procedure?
The WG initially focuses on several reliability mechanisms that are mainly associated with a redundancy model based on a VNF Pool. Additional mechanisms may include pool state maintenance only for pooling purpose. Service state synchronization is out of scope for this phase. The WG assumes that a VNF Pool contains redundant VNF instances of same functional type. Different types of VNFs are envisioned to be held in separate VNF Pools. VNF Pool composed by both virtualized and non-virtualized functional instances may be included after further use case and requirements study. 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 interfaces, such as transport protocol like 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 the Pool Manager.
The WG plans to deliver a problem statement, a set of use cases, requirements and an architecture covering the aforementioned technical aspects, and applicability and gap analysis of existing technologies including but not limited to RSerPool. We will 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. Although no decision on protocols will be made in this phase, we will keep open for candidate protocols for 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. Just like the communication between any pool users and VNF Pool, the information exchanged between the VNF Pool and the SFC may include some operational information of the VNF Pool.
Goals and Milestones:
December 2014 - Submit VNFPool Problem Statement to IESG for publication as an Informational document.
April 2015 - Submit VNFPool Use Cases to IESG for publication as an Informational document.
August 2015 - Submit VNFPool Requirements, including the manageability of VNF Pool to IESG for publication as an Informational document.
August 2015 - Submit VNFPool Architecture to IESG for publication as an Informational document.
December 2015 - Submit one or more Applicability and Gap Analysis of existing protocols to VNFPool to IESG for publication as Informational document(s).
==========================================================================

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

Thanks.

-Ning

[LAC Chidung]

Hi Ning,
1) Is it exact that scaling out/in, one main characteristic of VNFs
(compared to PNFs), is not included ?
2) Some comments/suggestions are enclosed.
Best,
Chidung

Post by Zongning
Dear all,
Please review the charter text included in the last email. We are
hoping that a general consensus on the charter could be achieved on
the list, then a stable charter is ready for the VNFPool session in
Toronto.
Thanks.
-Ning
*发送时闎:*2014幎6月12日11:20
*䞻题:*[vnfpool] Updated VNFPool Charter
Dear all,
Based on the list discussion since we posted the last version, I have
1)State that service state synchronization is out of scope “in this
phase”;**
2)Include VNF Pool with both virtualized and non-virtualized network
function for further study;**
3)Explicitly state that the reference solution & gap analysis is not
limited to RSerPool, but open to any other solutions, although no
decision on protocols will be made in this phase;**
4)State that the linkage between SFC and VNF Pool is just like a pool
user and a pool – nothing specified (yet);**
5)Update bullet #4 under “Questions that are raised
”, to keep it
consistent with the idea that pooling is not visible to the service
control entity.**
==========================================================================
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 achieve higher reliability, 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.Conceptually, a Pool Manager is used to manage a 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?
·After a VNF instance failover, how does the Pool Manager notify the
service control entity some characteristic changes of the VNF, e.g.,
capacity change, but without disclosure of the pooling procedure?
The WG initially focuses on several reliability mechanisms that are
mainly associated with a redundancy model based on a VNF Pool.
Additional mechanisms may include pool state maintenance only for
pooling purpose. Service state synchronization is out of scope for
this phase. The WGassumesthat a VNF Pool contains redundant VNF
instances of same functional type. Different types of VNFs are
envisioned to be held in separate VNF Pools. VNF Pool composed by both
virtualized and non-virtualized functional instances may be included
after further use case and requirements study. 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 Pooland the service control entity.
·Identify and analyze reliable interfaces, such as transport protocol
like 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 the Pool Manager.
The WG plans to deliver a problem statement, a set of use cases,
requirements and an architecture covering the aforementioned technical
aspects, and applicability and gap analysis of existing technologies
including but not limited to RSerPool. We will rely heavily on
existing IETF technologies, but that gaps will be found around
problems like redundancy mechanisms, state maintenancesolely for
pooling purposes, reliable transport, and trust/security, all of which
will need to be considered and addressed. Although no decision on
protocols will be made in this phase, we will keep open for candidate
protocols for 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. Just like the communication between any pool users
and VNF Pool, the information exchanged between the VNF Pool and the
SFC may include some operational information of the VNF Pool.
December 2014 - Submit VNFPool Problem Statement to IESG for
publication as an Informational document.
April 2015 - Submit VNFPool Use Cases to IESG for publication as an Informational document.
August 2015 - Submit VNFPool Requirements, including the manageability
of VNF Pool to IESG for publication as an Informational document.
August 2015 - Submit VNFPool Architecture to IESG for publication as
an Informational document.
December 2015 - Submit one or more Applicability and Gap Analysis of
existing protocols to VNFPool to IESG for publication as Informational
document(s).
==========================================================================
Your comments and suggestions to the charter are ALWAYS highly
appreciated!
Thanks.
-Ning
_______________________________________________
vnfpool mailing list
https://www.ietf.org/mailman/listinfo/vnfpool

[Zongning]

Hi, Chidung,
Thank you so much for the detailed review. Just a quick reply – the VNF instance scaling within a VNF pool is included in the charter. It is part of pool redundancy management.
I will review your attached version and get back to you later.

-Ning
发件人: LAC Chidung [mailto:***@orange.com]
发送时闎: 2014幎6月19日 0:40
收件人: Zongning
抄送: ***@ietf.org
䞻题: Re: [vnfpool] 答倍: Updated VNFPool Charter

Hi Ning,
1) Is it exact that scaling out/in, one main characteristic of VNFs (compared to PNFs), is not included ?
2) Some comments/suggestions are enclosed.
Best,
Chidung
Le 12/06/2014 05:38, Zongning a écrit :
Dear all,
Please review the charter text included in the last email. We are hoping that a general consensus on the charter could be achieved on the list, then a stable charter is ready for the VNFPool session in Toronto.
Thanks.
-Ning
发件人: vnfpool [mailto:vnfpool-***@ietf.org] 代衚 Zongning
发送时闎: 2014幎6月12日 11:20
收件人: ***@ietf.org<mailto:***@ietf.org>
䞻题: [vnfpool] Updated VNFPool Charter

Dear all,
Based on the list discussion since we posted the last version, I have made some (minor) revision of the charter. The main changes are:

1) State that service state synchronization is out of scope “in this phase”;

2) Include VNF Pool with both virtualized and non-virtualized network function for further study;

3) Explicitly state that the reference solution & gap analysis is not limited to RSerPool, but open to any other solutions, although no decision on protocols will be made in this phase;

4) State that the linkage between SFC and VNF Pool is just like a pool user and a pool – nothing specified (yet);

5) Update bullet #4 under “Questions that are raised
”, to keep it consistent with the idea that pooling is not visible to the service control entity.
==========================================================================
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 achieve higher reliability, 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.Conceptually, a Pool Manager is used to manage a 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?

· After a VNF instance failover, how does the Pool Manager notify the service control entity some characteristic changes of the VNF, e.g., capacity change, but without disclosure of the pooling procedure?
The WG initially focuses on several reliability mechanisms that are mainly associated with a redundancy model based on a VNF Pool. Additional mechanisms may include pool state maintenance only for pooling purpose. Service state synchronization is out of scope for this phase. The WG assumes that a VNF Pool contains redundant VNF instances of same functional type. Different types of VNFs are envisioned to be held in separate VNF Pools. VNF Pool composed by both virtualized and non-virtualized functional instances may be included after further use case and requirements study. 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 interfaces, such as transport protocol like 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 the Pool Manager.
The WG plans to deliver a problem statement, a set of use cases, requirements and an architecture covering the aforementioned technical aspects, and applicability and gap analysis of existing technologies including but not limited to RSerPool. We will 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. Although no decision on protocols will be made in this phase, we will keep open for candidate protocols for 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. Just like the communication between any pool users and VNF Pool, the information exchanged between the VNF Pool and the SFC may include some operational information of the VNF Pool.
Goals and Milestones:
December 2014 - Submit VNFPool Problem Statement to IESG for publication as an Informational document.
April 2015 - Submit VNFPool Use Cases to IESG for publication as an Informational document.
August 2015 - Submit VNFPool Requirements, including the manageability of VNF Pool to IESG for publication as an Informational document.
August 2015 - Submit VNFPool Architecture to IESG for publication as an Informational document.
December 2015 - Submit one or more Applicability and Gap Analysis of existing protocols to VNFPool to IESG for publication as Informational document(s).
==========================================================================

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

Thanks.

-Ning




_______________________________________________

vnfpool mailing list

***@ietf.org<mailto:***@ietf.org>

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

[Zongning]

Hi, Chidung,
Please see my reply enclosed in the attachment. Regarding comment#6, I’d like to explain that we don’t restrict to the case that in a pool, at a given time, there is only one running instance and all others are sleeping. A pool should be flexible to handle more cases, including multiple running instances and multiple standby instances.
Look forward to your further comments & suggestions.
-Ning

发件人: LAC Chidung [mailto:***@orange.com]
发送时闎: 2014幎6月19日 0:40
收件人: Zongning
抄送: ***@ietf.org
䞻题: Re: [vnfpool] 答倍: Updated VNFPool Charter

Hi Ning,
1) Is it exact that scaling out/in, one main characteristic of VNFs (compared to PNFs), is not included ?
2) Some comments/suggestions are enclosed.
Best,
Chidung
Le 12/06/2014 05:38, Zongning a écrit :
Dear all,
Please review the charter text included in the last email. We are hoping that a general consensus on the charter could be achieved on the list, then a stable charter is ready for the VNFPool session in Toronto.
Thanks.
-Ning
发件人: vnfpool [mailto:vnfpool-***@ietf.org] 代衚 Zongning
发送时闎: 2014幎6月12日 11:20
收件人: ***@ietf.org<mailto:***@ietf.org>
䞻题: [vnfpool] Updated VNFPool Charter

Dear all,
Based on the list discussion since we posted the last version, I have made some (minor) revision of the charter. The main changes are:

1) State that service state synchronization is out of scope “in this phase”;

2) Include VNF Pool with both virtualized and non-virtualized network function for further study;

3) Explicitly state that the reference solution & gap analysis is not limited to RSerPool, but open to any other solutions, although no decision on protocols will be made in this phase;

4) State that the linkage between SFC and VNF Pool is just like a pool user and a pool – nothing specified (yet);

5) Update bullet #4 under “Questions that are raised
”, to keep it consistent with the idea that pooling is not visible to the service control entity.
==========================================================================
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 achieve higher reliability, 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.Conceptually, a Pool Manager is used to manage a 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?

· After a VNF instance failover, how does the Pool Manager notify the service control entity some characteristic changes of the VNF, e.g., capacity change, but without disclosure of the pooling procedure?
The WG initially focuses on several reliability mechanisms that are mainly associated with a redundancy model based on a VNF Pool. Additional mechanisms may include pool state maintenance only for pooling purpose. Service state synchronization is out of scope for this phase. The WG assumes that a VNF Pool contains redundant VNF instances of same functional type. Different types of VNFs are envisioned to be held in separate VNF Pools. VNF Pool composed by both virtualized and non-virtualized functional instances may be included after further use case and requirements study. 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 interfaces, such as transport protocol like 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 the Pool Manager.
The WG plans to deliver a problem statement, a set of use cases, requirements and an architecture covering the aforementioned technical aspects, and applicability and gap analysis of existing technologies including but not limited to RSerPool. We will 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. Although no decision on protocols will be made in this phase, we will keep open for candidate protocols for 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. Just like the communication between any pool users and VNF Pool, the information exchanged between the VNF Pool and the SFC may include some operational information of the VNF Pool.
Goals and Milestones:
December 2014 - Submit VNFPool Problem Statement to IESG for publication as an Informational document.
April 2015 - Submit VNFPool Use Cases to IESG for publication as an Informational document.
August 2015 - Submit VNFPool Requirements, including the manageability of VNF Pool to IESG for publication as an Informational document.
August 2015 - Submit VNFPool Architecture to IESG for publication as an Informational document.
December 2015 - Submit one or more Applicability and Gap Analysis of existing protocols to VNFPool to IESG for publication as Informational document(s).
==========================================================================

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

Thanks.

-Ning




_______________________________________________

vnfpool mailing list

***@ietf.org<mailto:***@ietf.org>

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

[LAC Chidung]

Hi Ning,
Thank you for the reply. Some comments/suggestions to your:
* comment Z2:I knew that the « elementary » NFs are part of the job, but
wanted to suggest to add something in this section to avoid readers to
perceivethe wrong feeling mentioned in my comment #1
* comment Z7:Thank you for this clarification. I thus understand that
three types of pools (and not more than three) may exist:
- (i) no redundancy at all, i.e., all instances of the pool
participate actively - an upstream load balancing mechanism shares the
incoming load among these instances;
- (ii) 1:1 (active-active) redundancy - for example, 5 "images"
(to avoid the word 'instance') of the VNF, and each of them is redundant
-> in this case, there are 10 instances running in parallel in the pool;
- (iii) N+K (active-standby) redundancy where some instances run
actively, while others are in a dormant state.
* comment Z9:How about this add-on then ? "... achieved by the VNF Pool
*architecture* utilized/adopted by the VNF ..."
Best,
Chidung

Post by Zongning
Hi, Chidung,
Please see my reply enclosed in the attachment. Regarding comment#6,
I’d like to explain that we don’t restrict to the case that in a pool,
at a given time, there is only one running instance and all others are
sleeping. A pool should be flexible to handle more cases, including
multiple running instances and multiple standby instances.
Look forward to your further comments & suggestions.
-Ning
*发 送时闎:*2014幎6月19日0:40
*收件人:*Zongning
*䞻题:*Re: [vnfpool] 答倍: Updated VNFPool Charter
Hi Ning,
1) Is it exact that scaling out/in, one main characteristic of VNFs
(compared to PNFs), is not included ?
2) Some comments/suggestions are enclosed.
Best,
Chidung
Dear all,
Please review the charter text included in the last email. We are
hoping that a general consensus on the charter could be achieved
on the list, then a stable charter is ready for the VNFPool
session in Toronto.
Thanks.
-Ning
*发 送时闎:*2014幎6月12日11:20
*䞻题:*[vnfpool] Updated VNFPool Charter
Dear all,
Based on the list discussion since we posted the last version, I
1)State that service state synchronization is out of scope “in
this phase”;
2)Include VNF Pool with both virtualized and non-virtualized
network function for further study;
3)Explicitly state that the reference solution & gap analysis is
not limited to RSerPool, but open to any other solutions, although
no decision on protocols will be made in this phase;
4)State that the linkage between SFC and VNF Pool is just like a
pool user and a pool – nothing specified (yet);
5)Update bullet #4 under “Questions that are raised
”, to keep it
consistent with the idea that pooling is not visible to the
service control entity.
==========================================================================
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 achieve higher reliability, 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.Conceptually, a Pool Manager is used to manage a
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?
·After a VNF instance failover, how does the Pool Manager notify
the service control entity some characteristic changes of the VNF,
e.g., capacity change, but without disclosure of the pooling
procedure?
The WG initially focuses on several reliability mechanisms that
are mainly associated with a redundancy model based on a VNF Pool.
Additional mechanisms may include pool state maintenance only for
pooling purpose. Service state synchronization is out of scope for
this phase. The WGassumesthat a VNF Pool contains redundant VNF
instances of same functional type. Different types of VNFs are
envisioned to be held in separate VNF Pools. VNF Pool composed by
both virtualized and non-virtualized functional instances may be
included after further use case and requirements study. 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 Pooland the service
control entity.
·Identify and analyze reliable interfaces, such as transport
protocol like 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 the Pool Manager.
The WG plans to deliver a problem statement, a set of use cases,
requirements and an architecture covering the aforementioned
technical aspects, and applicability and gap analysis of existing
technologies including but not limited to RSerPool. We will rely
heavily on existing IETF technologies, but that gaps will be found
around problems like redundancy mechanisms, state
maintenancesolely for pooling purposes, reliable transport, and
trust/security, all of which will need to be considered and
addressed. Although no decision on protocols will be made in this
phase, we will keep open for candidate protocols for 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. Just like the communication between
any pool users and VNF Pool, the information exchanged between the
VNF Pool and the SFC may include some operational information of
the VNF Pool.
December 2014 - Submit VNFPool Problem Statement to IESG for
publication as an Informational document.
April 2015 - Submit VNFPool Use Cases to IESG for publication as
an Informational document.
August 2015 - Submit VNFPool Requirements, including the
manageability of VNF Pool to IESG for publication as an
Informational document.
August 2015 - Submit VNFPool Architecture to IESG for publication
as an Informational document.
December 2015 - Submit one or more Applicability and Gap Analysis
of existing protocols to VNFPool to IESG for publication as
Informational document(s).
==========================================================================
Your comments and suggestions to the charter are ALWAYS highly appreciated!
Thanks.
-Ning
_______________________________________________
vnfpool mailing list
https://www.ietf.org/mailman/listinfo/vnfpool

[Zongning]

Hi, Chidung,
Thanks for your suggestions. I will make the text clear for comment Z2. But for comment Z9, I’d prefer to keep “VNF Pool”, as we don’t propose/discuss a concrete VNF Pool architecture in the charter, but just introduce a general concept.
Look forward to your further comments.
-Ning
发件人: LAC Chidung [mailto:***@orange.com]
发送时闎: 2014幎6月26日 22:53
收件人: Zongning
抄送: ***@ietf.org
䞻题: Re: 答倍: [vnfpool] 答倍: Updated VNFPool Charter

Hi Ning,
Thank you for the reply. Some comments/suggestions to your:
* comment Z2: I knew that the « elementary » NFs are part of the job, but wanted to suggest to add something in this section to avoid readers to perceive the wrong feeling mentioned in my comment #1
* comment Z7: Thank you for this clarification. I thus understand that three types of pools (and not more than three) may exist:
- (i) no redundancy at all, i.e., all instances of the pool participate actively - an upstream load balancing mechanism shares the incoming load among these instances;
- (ii) 1:1 (active-active) redundancy - for example, 5 "images" (to avoid the word 'instance') of the VNF, and each of them is redundant -> in this case, there are 10 instances running in parallel in the pool;
- (iii) N+K (active-standby) redundancy where some instances run actively, while others are in a dormant state.

* comment Z9: How about this add-on then ? "... achieved by the VNF Pool architecture utilized/adopted by the VNF ..."
Best,
Chidung

Le 19/06/2014 05:14, Zongning a écrit :
Hi, Chidung,
Please see my reply enclosed in the attachment. Regarding comment#6, I’d like to explain that we don’t restrict to the case that in a pool, at a given time, there is only one running instance and all others are sleeping. A pool should be flexible to handle more cases, including multiple running instances and multiple standby instances.
Look forward to your further comments & suggestions.
-Ning

发 件人: LAC Chidung [mailto:***@orange.com]
发 送时闎: 2014幎6月19日 0:40
收件人: Zongning
抄送: ***@ietf.org<mailto:***@ietf.org>
䞻题: Re: [vnfpool] 答倍: Updated VNFPool Charter

Hi Ning,
1) Is it exact that scaling out/in, one main characteristic of VNFs (compared to PNFs), is not included ?
2) Some comments/suggestions are enclosed.
Best,
Chidung
Le 12/06/2014 05:38, Zongning a écrit :
Dear all,
Please review the charter text included in the last email. We are hoping that a general consensus on the charter could be achieved on the list, then a stable charter is ready for the VNFPool session in Toronto.
Thanks.
-Ning
发件人: vnfpool [mailto:vnfpool-***@ietf.org] 代 è¡š Zongning
发 送时闎: 2014幎6月12日 11:20
收件人: ***@ietf.org<mailto:***@ietf.org>
䞻题: [vnfpool] Updated VNFPool Charter

Dear all,
Based on the list discussion since we posted the last version, I have made some (minor) revision of the charter. The main changes are:

1) State that service state synchronization is out of scope “in this phase”;

2) Include VNF Pool with both virtualized and non-virtualized network function for further study;

3) Explicitly state that the reference solution & gap analysis is not limited to RSerPool, but open to any other solutions, although no decision on protocols will be made in this phase;

4) State that the linkage between SFC and VNF Pool is just like a pool user and a pool – nothing specified (yet);

5) Update bullet #4 under “Questions that are raised
”, to keep it consistent with the idea that pooling is not visible to the service control entity.
==========================================================================
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 achieve higher reliability, 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.Conceptually, a Pool Manager is used to manage a 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?

· After a VNF instance failover, how does the Pool Manager notify the service control entity some characteristic changes of the VNF, e.g., capacity change, but without disclosure of the pooling procedure?
The WG initially focuses on several reliability mechanisms that are mainly associated with a redundancy model based on a VNF Pool. Additional mechanisms may include pool state maintenance only for pooling purpose. Service state synchronization is out of scope for this phase. The WG assumes that a VNF Pool contains redundant VNF instances of same functional type. Different types of VNFs are envisioned to be held in separate VNF Pools. VNF Pool composed by both virtualized and non-virtualized functional instances may be included after further use case and requirements study. 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 interfaces, such as transport protocol like 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 the Pool Manager.
The WG plans to deliver a problem statement, a set of use cases, requirements and an architecture covering the aforementioned technical aspects, and applicability and gap analysis of existing technologies including but not limited to RSerPool. We will 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. Although no decision on protocols will be made in this phase, we will keep open for candidate protocols for 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. Just like the communication between any pool users and VNF Pool, the information exchanged between the VNF Pool and the SFC may include some operational information of the VNF Pool.
Goals and Milestones:
December 2014 - Submit VNFPool Problem Statement to IESG for publication as an Informational document.
April 2015 - Submit VNFPool Use Cases to IESG for publication as an Informational document.
August 2015 - Submit VNFPool Requirements, including the manageability of VNF Pool to IESG for publication as an Informational document.
August 2015 - Submit VNFPool Architecture to IESG for publication as an Informational document.
December 2015 - Submit one or more Applicability and Gap Analysis of existing protocols to VNFPool to IESG for publication as Informational document(s).
==========================================================================
Your comments and suggestions to the charter are ALWAYS highly appreciated!
Thanks.
-Ning

_______________________________________________

vnfpool mailing list

***@ietf.org<mailto:***@ietf.org>

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

[LAC Chidung]

Hi Ning,
1- On further consideration, my remark (i) in the previous e-mail ("/no
redundancy at all ...../") should not be applied in the VNF context if
the intention is to use a pool for redundancy purposes *while minimizing
the needed resources*. As shown in the figure enclosed, this PNF scheme
(no redundancy at all, i.e., all instances of the pool participate
actively) is not applicable in the VNF framework where additional
instances are created *only* if needed.
2- Back to your e-mail of June 19th "/the VNF instance scaling within a
VNF pool is included in the charter/": I don't think "scaling",
"scalability" appearing in the charter - it would be nice to introduce a
sentence (somewhere) with one of these two words to avoid this
ambiguity. Again, scaling in/out is one main characteristic of VNF.
Best,
Chidung

Post by Zongning
Hi, Chidung,
Thanks for your suggestions. I will make the text clear for comment
Z2. But for comment Z9, I’d prefer to keep “VNF Pool”, as we don’t
propose/discuss a concrete VNF Pool architecture in the charter, but
just introduce a general concept.
Look forward to your further comments.
-Ning
*发 送时闎:*2014幎6月26日22:53
*收件人:*Zongning
*䞻题:*Re: 答倍: [vnfpool] 答倍: Updated VNFPool Charter
Hi Ning,
* comment Z2: I knew that the « elementary » NFs are part of the job,
but wanted to suggest to add something in this section to avoid
readers to perceive the wrong feeling mentioned in my comment #1
* comment Z7: Thank you for this clarification. I thus understand that
- (i) no redundancy at all, i.e., all instances of the pool
participate actively - an upstream load balancing mechanism shares the
incoming load among these instances;
- (ii) 1:1 (active-active) redundancy - for example, 5 "images"
(to avoid the word 'instance') of the VNF, and each of them is
redundant -> in this case, there are 10 instances running in parallel
in the pool;
- (iii) N+K (active-standby) redundancy where some instances run
actively, while others are in a dormant state.
* comment Z9: How about this add-on then ? "... achieved by the VNF
Pool *architecture* utilized/adopted by the VNF ..."
Best,
Chidung
Hi, Chidung,
Please see my reply enclosed in the attachment. Regarding
comment#6, I’d like to explain that we don’t restrict to the case
that in a pool, at a given time, there is only one running
instance and all others are sleeping. A pool should be flexible to
handle more cases, including multiple running instances and
multiple standby instances.
Look forward to your further comments & suggestions.
-Ning
*发 送时闎:* 2014幎6月19日 0:40
*收件人:* Zongning
*䞻题:* Re: [vnfpool] 答倍: Updated VNFPool Charter
Hi Ning,
1) Is it exact that scaling out/in, one main characteristic of
VNFs (compared to PNFs), is not included ?
2) Some comments/suggestions are enclosed.
Best,
Chidung
Dear all,
Please review the charter text included in the last email. We
are hoping that a general consensus on the charter could be
achieved on the list, then a stable charter is ready for the
VNFPool session in Toronto.
Thanks.
-Ning
*Zongning
*发 送时闎:* 2014幎6月12日 11:20
*䞻题:* [vnfpool] Updated VNFPool Charter
Dear all,
Based on the list discussion since we posted the last version,
I have made some (minor) revision of the charter. The main
1)State that service state synchronization is out of scope “in
this phase”;
2)Include VNF Pool with both virtualized and non-virtualized
network function for further study;
3)Explicitly state that the reference solution & gap analysis
is not limited to RSerPool, but open to any other solutions,
although no decision on protocols will be made in this phase;
4)State that the linkage between SFC and VNF Pool is just like
a pool user and a pool – nothing specified (yet);
5)Update bullet #4 under “Questions that are raised
”, to keep
it consistent with the idea that pooling is not visible to the
service control entity.
==========================================================================
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 achieve higher reliability, 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.Conceptually, a Pool
Manager is used to manage a 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
·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?
·After a VNF instance failover, how does the Pool Manager
notify the service control entity some characteristic changes
of the VNF, e.g., capacity change, but without disclosure of
the pooling procedure?
The WG initially focuses on several reliability mechanisms
that are mainly associated with a redundancy model based on a
VNF Pool. Additional mechanisms may include pool state
maintenance only for pooling purpose. Service state
synchronization is out of scope for this phase. The
WGassumesthat a VNF Pool contains redundant VNF instances of
same functional type. Different types of VNFs are envisioned
to be held in separate VNF Pools. VNF Pool composed by both
virtualized and non-virtualized functional instances may be
included after further use case and requirements study. 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 Pooland the
service control entity.
·Identify and analyze reliable interfaces, such as transport
protocol like 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 the Pool
Manager.
The WG plans to deliver a problem statement, a set of use
cases, requirements and an architecture covering the
aforementioned technical aspects, and applicability and gap
analysis of existing technologies including but not limited to
RSerPool. We will rely heavily on existing IETF technologies,
but that gaps will be found around problems like redundancy
mechanisms, state maintenancesolely for pooling purposes,
reliable transport, and trust/security, all of which will need
to be considered and addressed. Although no decision on
protocols will be made in this phase, we will keep open for
candidate protocols for 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.
Just like the communication between any pool users and VNF
Pool, the information exchanged between the VNF Pool and the
SFC may include some operational information of the VNF Pool.
December 2014 - Submit VNFPool Problem Statement to IESG for
publication as an Informational document.
April 2015 - Submit VNFPool Use Cases to IESG for publication
as an Informational document.
August 2015 - Submit VNFPool Requirements, including the
manageability of VNF Pool to IESG for publication as an
Informational document.
August 2015 - Submit VNFPool Architecture to IESG for
publication as an Informational document.
December 2015 - Submit one or more Applicability and Gap
Analysis of existing protocols to VNFPool to IESG for
publication as Informational document(s).
==========================================================================
Your comments and suggestions to the charter are ALWAYS highly appreciated!
Thanks.
-Ning
_______________________________________________
vnfpool mailing list
https://www.ietf.org/mailman/listinfo/vnfpool

[Zongning]

Hi, Chidung,
Point#1 – thank you for providing such detailed information on redundancy. I will carefully read it and post my opinion on the redundancy model, if any.
Point#2 – yes, I will put one or two words in existing sentence(s) in the charter to reflect the scaling within a pool, or inherent to pooling itself.
Thanks.
-Ning

发件人: LAC Chidung [mailto:***@orange.com]
发送时闎: 2014幎6月27日 17:24
收件人: Zongning
抄送: ***@ietf.org
䞻题: Re: 答倍: 答倍: [vnfpool] 答倍: Updated VNFPool Charter

Hi Ning,
1- On further consideration, my remark (i) in the previous e-mail ("no redundancy at all .....") should not be applied in the VNF context if the intention is to use a pool for redundancy purposes while minimizing the needed resources. As shown in the figure enclosed, this PNF scheme (no redundancy at all, i.e., all instances of the pool participate actively) is not applicable in the VNF framework where additional instances are created only if needed.
2- Back to your e-mail of June 19th "the VNF instance scaling within a VNF pool is included in the charter": I don't think "scaling", "scalability" appearing in the charter - it would be nice to introduce a sentence (somewhere) with one of these two words to avoid this ambiguity. Again, scaling in/out is one main characteristic of VNF.
Best,
Chidung
Le 27/06/2014 03:36, Zongning a écrit :
Hi, Chidung,
Thanks for your suggestions. I will make the text clear for comment Z2. But for comment Z9, I’d prefer to keep “VNF Pool”, as we don’t propose/discuss a concrete VNF Pool architecture in the charter, but just introduce a general concept.
Look forward to your further comments.
-Ning
发 件人: LAC Chidung [mailto:***@orange.com]
发 送时闎: 2014幎6月26日 22:53
收件人: Zongning
抄送: ***@ietf.org<mailto:***@ietf.org>
䞻题: Re: 答倍: [vnfpool] 答倍: Updated VNFPool Charter

Hi Ning,
Thank you for the reply. Some comments/suggestions to your:
* comment Z2: I knew that the « elementary » NFs are part of the job, but wanted to suggest to add something in this section to avoid readers to perceive the wrong feeling mentioned in my comment #1
* comment Z7: Thank you for this clarification. I thus understand that three types of pools (and not more than three) may exist:
- (i) no redundancy at all, i.e., all instances of the pool participate actively - an upstream load balancing mechanism shares the incoming load among these instances;
- (ii) 1:1 (active-active) redundancy - for example, 5 "images" (to avoid the word 'instance') of the VNF, and each of them is redundant -> in this case, there are 10 instances running in parallel in the pool;
- (iii) N+K (active-standby) redundancy where some instances run actively, while others are in a dormant state.
* comment Z9: How about this add-on then ? "... achieved by the VNF Pool architecture utilized/adopted by the VNF ..."
Best,
Chidung

Le 19/06/2014 05:14, Zongning a écrit :
Hi, Chidung,
Please see my reply enclosed in the attachment. Regarding comment#6, I’d like to explain that we don’t restrict to the case that in a pool, at a given time, there is only one running instance and all others are sleeping. A pool should be flexible to handle more cases, including multiple running instances and multiple standby instances.
Look forward to your further comments & suggestions.
-Ning

发 件人: LAC Chidung [mailto:***@orange.com]
发 送时闎: 2014幎6月19日 0:40
收件人: Zongning
抄送: ***@ietf.org<mailto:***@ietf.org>
䞻题: Re: [vnfpool] 答倍: Updated VNFPool Charter

Hi Ning,
1) Is it exact that scaling out/in, one main characteristic of VNFs (compared to PNFs), is not included ?
2) Some comments/suggestions are enclosed.
Best,
Chidung
Le 12/06/2014 05:38, Zongning a écrit :
Dear all,
Please review the charter text included in the last email. We are hoping that a general consensus on the charter could be achieved on the list, then a stable charter is ready for the VNFPool session in Toronto.
Thanks.
-Ning
发件人: vnfpool [mailto:vnfpool-***@ietf.org] 代 è¡š Zongning
发 送时闎: 2014幎6月12日 11:20
收件人: ***@ietf.org<mailto:***@ietf.org>
䞻题: [vnfpool] Updated VNFPool Charter

Dear all,
Based on the list discussion since we posted the last version, I have made some (minor) revision of the charter. The main changes are:

1) State that service state synchronization is out of scope “in this phase”;

2) Include VNF Pool with both virtualized and non-virtualized network function for further study;

3) Explicitly state that the reference solution & gap analysis is not limited to RSerPool, but open to any other solutions, although no decision on protocols will be made in this phase;

4) State that the linkage between SFC and VNF Pool is just like a pool user and a pool – nothing specified (yet);

5) Update bullet #4 under “Questions that are raised
”, to keep it consistent with the idea that pooling is not visible to the service control entity.
==========================================================================
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 achieve higher reliability, 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.Conceptually, a Pool Manager is used to manage a 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?

· After a VNF instance failover, how does the Pool Manager notify the service control entity some characteristic changes of the VNF, e.g., capacity change, but without disclosure of the pooling procedure?
The WG initially focuses on several reliability mechanisms that are mainly associated with a redundancy model based on a VNF Pool. Additional mechanisms may include pool state maintenance only for pooling purpose. Service state synchronization is out of scope for this phase. The WG assumes that a VNF Pool contains redundant VNF instances of same functional type. Different types of VNFs are envisioned to be held in separate VNF Pools. VNF Pool composed by both virtualized and non-virtualized functional instances may be included after further use case and requirements study. 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 interfaces, such as transport protocol like 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 the Pool Manager.
The WG plans to deliver a problem statement, a set of use cases, requirements and an architecture covering the aforementioned technical aspects, and applicability and gap analysis of existing technologies including but not limited to RSerPool. We will 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. Although no decision on protocols will be made in this phase, we will keep open for candidate protocols for 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. Just like the communication between any pool users and VNF Pool, the information exchanged between the VNF Pool and the SFC may include some operational information of the VNF Pool.
Goals and Milestones:
December 2014 - Submit VNFPool Problem Statement to IESG for publication as an Informational document.
April 2015 - Submit VNFPool Use Cases to IESG for publication as an Informational document.
August 2015 - Submit VNFPool Requirements, including the manageability of VNF Pool to IESG for publication as an Informational document.
August 2015 - Submit VNFPool Architecture to IESG for publication as an Informational document.
December 2015 - Submit one or more Applicability and Gap Analysis of existing protocols to VNFPool to IESG for publication as Informational document(s).
==========================================================================
Your comments and suggestions to the charter are ALWAYS highly appreciated!
Thanks.
-Ning

_______________________________________________

vnfpool mailing list

***@ietf.org<mailto:***@ietf.org>

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

[Linda Dunbar]

Chidung,
A few questions to your attached file:

- All the models assume that there is a central LBM that traffic traverse through. I would think that VNFpool doesn’t require the traffic to go through a single point of LB. Correct?

- 1+1 protection can be very expensive. I would think only the stateful VNF might need 1+1 or N+K protection. For stateless VNF, the Model 1 should be used.
My two cents,
Linda

From: vnfpool [mailto:vnfpool-***@ietf.org] On Behalf Of LAC Chidung
Sent: Friday, June 27, 2014 4:24 AM
To: Zongning
Cc: ***@ietf.org
Subject: Re: [vnfpool] 答倍: 答倍: 答倍: Updated VNFPool Charter

Hi Ning,
1- On further consideration, my remark (i) in the previous e-mail ("no redundancy at all .....") should not be applied in the VNF context if the intention is to use a pool for redundancy purposes while minimizing the needed resources. As shown in the figure enclosed, this PNF scheme (no redundancy at all, i.e., all instances of the pool participate actively) is not applicable in the VNF framework where additional instances are created only if needed.
2- Back to your e-mail of June 19th "the VNF instance scaling within a VNF pool is included in the charter": I don't think "scaling", "scalability" appearing in the charter - it would be nice to introduce a sentence (somewhere) with one of these two words to avoid this ambiguity. Again, scaling in/out is one main characteristic of VNF.
Best,
Chidung
Le 27/06/2014 03:36, Zongning a écrit :
Hi, Chidung,
Thanks for your suggestions. I will make the text clear for comment Z2. But for comment Z9, I’d prefer to keep “VNF Pool”, as we don’t propose/discuss a concrete VNF Pool architecture in the charter, but just introduce a general concept.
Look forward to your further comments.
-Ning
发 件人: LAC Chidung [mailto:***@orange.com]
发 送时闎: 2014幎6月26日 22:53
收件人: Zongning
抄送: ***@ietf.org<mailto:***@ietf.org>
䞻题: Re: 答倍: [vnfpool] 答倍: Updated VNFPool Charter

Hi Ning,
Thank you for the reply. Some comments/suggestions to your:
* comment Z2: I knew that the « elementary » NFs are part of the job, but wanted to suggest to add something in this section to avoid readers to perceive the wrong feeling mentioned in my comment #1
* comment Z7: Thank you for this clarification. I thus understand that three types of pools (and not more than three) may exist:
- (i) no redundancy at all, i.e., all instances of the pool participate actively - an upstream load balancing mechanism shares the incoming load among these instances;
- (ii) 1:1 (active-active) redundancy - for example, 5 "images" (to avoid the word 'instance') of the VNF, and each of them is redundant -> in this case, there are 10 instances running in parallel in the pool;
- (iii) N+K (active-standby) redundancy where some instances run actively, while others are in a dormant state.
* comment Z9: How about this add-on then ? "... achieved by the VNF Pool architecture utilized/adopted by the VNF ..."
Best,
Chidung

Le 19/06/2014 05:14, Zongning a écrit :
Hi, Chidung,
Please see my reply enclosed in the attachment. Regarding comment#6, I’d like to explain that we don’t restrict to the case that in a pool, at a given time, there is only one running instance and all others are sleeping. A pool should be flexible to handle more cases, including multiple running instances and multiple standby instances.
Look forward to your further comments & suggestions.
-Ning

发 件人: LAC Chidung [mailto:***@orange.com]
发 送时闎: 2014幎6月19日 0:40
收件人: Zongning
抄送: ***@ietf.org<mailto:***@ietf.org>
䞻题: Re: [vnfpool] 答倍: Updated VNFPool Charter

Hi Ning,
1) Is it exact that scaling out/in, one main characteristic of VNFs (compared to PNFs), is not included ?
2) Some comments/suggestions are enclosed.
Best,
Chidung
Le 12/06/2014 05:38, Zongning a écrit :
Dear all,
Please review the charter text included in the last email. We are hoping that a general consensus on the charter could be achieved on the list, then a stable charter is ready for the VNFPool session in Toronto.
Thanks.
-Ning
发件人: vnfpool [mailto:vnfpool-***@ietf.org] 代 è¡š Zongning
发 送时闎: 2014幎6月12日 11:20
收件人: ***@ietf.org<mailto:***@ietf.org>
䞻题: [vnfpool] Updated VNFPool Charter

Dear all,
Based on the list discussion since we posted the last version, I have made some (minor) revision of the charter. The main changes are:

1) State that service state synchronization is out of scope “in this phase”;

2) Include VNF Pool with both virtualized and non-virtualized network function for further study;

3) Explicitly state that the reference solution & gap analysis is not limited to RSerPool, but open to any other solutions, although no decision on protocols will be made in this phase;

4) State that the linkage between SFC and VNF Pool is just like a pool user and a pool – nothing specified (yet);

5) Update bullet #4 under “Questions that are raised
”, to keep it consistent with the idea that pooling is not visible to the service control entity.
==========================================================================
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 achieve higher reliability, 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.Conceptually, a Pool Manager is used to manage a 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?

· After a VNF instance failover, how does the Pool Manager notify the service control entity some characteristic changes of the VNF, e.g., capacity change, but without disclosure of the pooling procedure?
The WG initially focuses on several reliability mechanisms that are mainly associated with a redundancy model based on a VNF Pool. Additional mechanisms may include pool state maintenance only for pooling purpose. Service state synchronization is out of scope for this phase. The WG assumes that a VNF Pool contains redundant VNF instances of same functional type. Different types of VNFs are envisioned to be held in separate VNF Pools. VNF Pool composed by both virtualized and non-virtualized functional instances may be included after further use case and requirements study. 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 interfaces, such as transport protocol like 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 the Pool Manager.
The WG plans to deliver a problem statement, a set of use cases, requirements and an architecture covering the aforementioned technical aspects, and applicability and gap analysis of existing technologies including but not limited to RSerPool. We will 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. Although no decision on protocols will be made in this phase, we will keep open for candidate protocols for 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. Just like the communication between any pool users and VNF Pool, the information exchanged between the VNF Pool and the SFC may include some operational information of the VNF Pool.
Goals and Milestones:
December 2014 - Submit VNFPool Problem Statement to IESG for publication as an Informational document.
April 2015 - Submit VNFPool Use Cases to IESG for publication as an Informational document.
August 2015 - Submit VNFPool Requirements, including the manageability of VNF Pool to IESG for publication as an Informational document.
August 2015 - Submit VNFPool Architecture to IESG for publication as an Informational document.
December 2015 - Submit one or more Applicability and Gap Analysis of existing protocols to VNFPool to IESG for publication as Informational document(s).
==========================================================================
Your comments and suggestions to the charter are ALWAYS highly appreciated!
Thanks.
-Ning

_______________________________________________

vnfpool mailing list

***@ietf.org<mailto:***@ietf.org>

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

[Zongning]

Hi, Linda and Chidung,
I’d think that usually a pool would have a control point in the data path to allocate incoming traffic to different pool members that belongs to a tenant. I’d call such a control point a traffic manager in a pool. Note that this traffic manager is part of the pooling mechanism itself, thus is not handled by the control entity outside of the pool. Moreover, based on our charter, we currently focus on the pool management, such as instance registration, active/standby instance selection. So such a traffic manager is not our focus for this phase.
Thoughts?

-Ning

发件人: Linda Dunbar
发送时闎: 2014幎7月1日 7:18
收件人: LAC Chidung; Zongning
抄送: ***@ietf.org
䞻题: RE: [vnfpool] 答倍: 答倍: 答倍: Updated VNFPool Charter

Chidung,
A few questions to your attached file:

- All the models assume that there is a central LBM that traffic traverse through. I would think that VNFpool doesn’t require the traffic to go through a single point of LB. Correct?

- 1+1 protection can be very expensive. I would think only the stateful VNF might need 1+1 or N+K protection. For stateless VNF, the Model 1 should be used.
My two cents,
Linda

From: vnfpool [mailto:vnfpool-***@ietf.org] On Behalf Of LAC Chidung
Sent: Friday, June 27, 2014 4:24 AM
To: Zongning
Cc: ***@ietf.org<mailto:***@ietf.org>
Subject: Re: [vnfpool] 答倍: 答倍: 答倍: Updated VNFPool Charter

Hi Ning,
1- On further consideration, my remark (i) in the previous e-mail ("no redundancy at all .....") should not be applied in the VNF context if the intention is to use a pool for redundancy purposes while minimizing the needed resources. As shown in the figure enclosed, this PNF scheme (no redundancy at all, i.e., all instances of the pool participate actively) is not applicable in the VNF framework where additional instances are created only if needed.
2- Back to your e-mail of June 19th "the VNF instance scaling within a VNF pool is included in the charter": I don't think "scaling", "scalability" appearing in the charter - it would be nice to introduce a sentence (somewhere) with one of these two words to avoid this ambiguity. Again, scaling in/out is one main characteristic of VNF.
Best,
Chidung
Le 27/06/2014 03:36, Zongning a écrit :
Hi, Chidung,
Thanks for your suggestions. I will make the text clear for comment Z2. But for comment Z9, I’d prefer to keep “VNF Pool”, as we don’t propose/discuss a concrete VNF Pool architecture in the charter, but just introduce a general concept.
Look forward to your further comments.
-Ning
发 件人: LAC Chidung [mailto:***@orange.com]
发 送时闎: 2014幎6月26日 22:53
收件人: Zongning
抄送: ***@ietf.org<mailto:***@ietf.org>
䞻题: Re: 答倍: [vnfpool] 答倍: Updated VNFPool Charter

Hi Ning,
Thank you for the reply. Some comments/suggestions to your:
* comment Z2: I knew that the « elementary » NFs are part of the job, but wanted to suggest to add something in this section to avoid readers to perceive the wrong feeling mentioned in my comment #1
* comment Z7: Thank you for this clarification. I thus understand that three types of pools (and not more than three) may exist:
- (i) no redundancy at all, i.e., all instances of the pool participate actively - an upstream load balancing mechanism shares the incoming load among these instances;
- (ii) 1:1 (active-active) redundancy - for example, 5 "images" (to avoid the word 'instance') of the VNF, and each of them is redundant -> in this case, there are 10 instances running in parallel in the pool;
- (iii) N+K (active-standby) redundancy where some instances run actively, while others are in a dormant state.
* comment Z9: How about this add-on then ? "... achieved by the VNF Pool architecture utilized/adopted by the VNF ..."
Best,
Chidung

Le 19/06/2014 05:14, Zongning a écrit :
Hi, Chidung,
Please see my reply enclosed in the attachment. Regarding comment#6, I’d like to explain that we don’t restrict to the case that in a pool, at a given time, there is only one running instance and all others are sleeping. A pool should be flexible to handle more cases, including multiple running instances and multiple standby instances.
Look forward to your further comments & suggestions.
-Ning

发 件人: LAC Chidung [mailto:***@orange.com]
发 送时闎: 2014幎6月19日 0:40
收件人: Zongning
抄送: ***@ietf.org<mailto:***@ietf.org>
䞻题: Re: [vnfpool] 答倍: Updated VNFPool Charter

Hi Ning,
1) Is it exact that scaling out/in, one main characteristic of VNFs (compared to PNFs), is not included ?
2) Some comments/suggestions are enclosed.
Best,
Chidung
Le 12/06/2014 05:38, Zongning a écrit :
Dear all,
Please review the charter text included in the last email. We are hoping that a general consensus on the charter could be achieved on the list, then a stable charter is ready for the VNFPool session in Toronto.
Thanks.
-Ning
发件人: vnfpool [mailto:vnfpool-***@ietf.org] 代 è¡š Zongning
发 送时闎: 2014幎6月12日 11:20
收件人: ***@ietf.org<mailto:***@ietf.org>
䞻题: [vnfpool] Updated VNFPool Charter

Dear all,
Based on the list discussion since we posted the last version, I have made some (minor) revision of the charter. The main changes are:

1) State that service state synchronization is out of scope “in this phase”;

2) Include VNF Pool with both virtualized and non-virtualized network function for further study;

3) Explicitly state that the reference solution & gap analysis is not limited to RSerPool, but open to any other solutions, although no decision on protocols will be made in this phase;

4) State that the linkage between SFC and VNF Pool is just like a pool user and a pool – nothing specified (yet);

5) Update bullet #4 under “Questions that are raised
”, to keep it consistent with the idea that pooling is not visible to the service control entity.
==========================================================================
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 achieve higher reliability, 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.Conceptually, a Pool Manager is used to manage a 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?

· After a VNF instance failover, how does the Pool Manager notify the service control entity some characteristic changes of the VNF, e.g., capacity change, but without disclosure of the pooling procedure?
The WG initially focuses on several reliability mechanisms that are mainly associated with a redundancy model based on a VNF Pool. Additional mechanisms may include pool state maintenance only for pooling purpose. Service state synchronization is out of scope for this phase. The WG assumes that a VNF Pool contains redundant VNF instances of same functional type. Different types of VNFs are envisioned to be held in separate VNF Pools. VNF Pool composed by both virtualized and non-virtualized functional instances may be included after further use case and requirements study. 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 interfaces, such as transport protocol like 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 the Pool Manager.
The WG plans to deliver a problem statement, a set of use cases, requirements and an architecture covering the aforementioned technical aspects, and applicability and gap analysis of existing technologies including but not limited to RSerPool. We will 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. Although no decision on protocols will be made in this phase, we will keep open for candidate protocols for 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. Just like the communication between any pool users and VNF Pool, the information exchanged between the VNF Pool and the SFC may include some operational information of the VNF Pool.
Goals and Milestones:
December 2014 - Submit VNFPool Problem Statement to IESG for publication as an Informational document.
April 2015 - Submit VNFPool Use Cases to IESG for publication as an Informational document.
August 2015 - Submit VNFPool Requirements, including the manageability of VNF Pool to IESG for publication as an Informational document.
August 2015 - Submit VNFPool Architecture to IESG for publication as an Informational document.
December 2015 - Submit one or more Applicability and Gap Analysis of existing protocols to VNFPool to IESG for publication as Informational document(s).
==========================================================================
Your comments and suggestions to the charter are ALWAYS highly appreciated!
Thanks.
-Ning

_______________________________________________

vnfpool mailing list

***@ietf.org<mailto:***@ietf.org>

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

[LAC Chidung]

Linda,
1) IMHO, the difficulty is to marry the pool and the NFV scaling in/out
concepts. Actually, the lower part of the picture (called "VNF") should
be appropriate to the NFV environment, but using the expression "pool"
for it is not necessary, i.e., what means "pool" in the case where a
single VNF instance is sufficient to treat the load ? We definitively
need to comprehend "pool" differently (compared to the PNF context) ...
If scaling in/out is used, it is hard to imagine how to exempt the
architecture from including a mechanism to distribute the load among the
different instances.
Furthermore, as Ning wrote to Adrian on June 27th "/You are right that a
VNF pool appears as a single instance to outside entity such as service
control entity/": as the pool is hidden, the load sent to the pool's
elements (VNF instances in the NFV context) goes necessarily to a single
address (which could be redundant for HA purposes), leaving to this
entity the job to distribute the load.
2) If "/the Model 1/" = no redundancy, IMO, stateful/stateless and
no_redundancy/redundancy are independent. If there is a need for (high)
availability, stateless VNF redundancy should be carried out (and is
usually much more easy than stateful redundancy).
Best,
Chidung

Post by Zongning
Chidung,
-All the models assume that there is a central LBM that traffic
traverse through. I would think that VNFpool doesn’t require the
traffic to go through a single point of LB. Correct?
-1+1 protection can be very expensive. I would think only the stateful
VNF might need 1+1 or N+K protection. For stateless VNF, the Model 1
should be used.
My two cents,
Linda
Chidung
*Sent:* Friday, June 27, 2014 4:24 AM
*To:* Zongning
*Subject:* Re: [vnfpool] 答倍: 答倍: 答倍: Updated VNFPool Charter
Hi Ning,
1- On further consideration, my remark (i) in the previous e-mail
("/no redundancy at all ...../") should not be applied in the VNF
context if the intention is to use a pool for redundancy purposes
*while minimizing the needed resources*. As shown in the figure
enclosed, this PNF scheme (no redundancy at all, i.e., all instances
of the pool participate actively) is not applicable in the VNF
framework where additional instances are created *only* if needed.
2- Back to your e-mail of June 19th "/the VNF instance scaling within
a VNF pool is included in the charter/": I don't think "scaling",
"scalability" appearing in the charter - it would be nice to introduce
a sentence (somewhere) with one of these two words to avoid this
ambiguity. Again, scaling in/out is one main characteristic of VNF.
Best,
Chidung
Hi, Chidung,
Thanks for your suggestions. I will make the text clear for
comment Z2. But for comment Z9, I’d prefer to keep “VNF Pool”, as
we don’t propose/discuss a concrete VNF Pool architecture in the
charter, but just introduce a general concept.
Look forward to your further comments.
-Ning
*发****送时闎**:*2014幎6月26日22:53
*收件人**:*Zongning
*䞻题**:*Re: 答倍: [vnfpool] 答倍: Updated VNFPool Charter
Hi Ning,
* comment Z2: I knew that the « elementary » NFs are part of the
job, but wanted to suggest to add something in this section to
avoid readers to perceive the wrong feeling mentioned in my
comment #1
* comment Z7: Thank you for this clarification. I thus understand
- (i) no redundancy at all, i.e., all instances of the pool
participate actively - an upstream load balancing mechanism shares
the incoming load among these instances;
- (ii) 1:1 (active-active) redundancy - for example, 5
"images" (to avoid the word 'instance') of the VNF, and each of
them is redundant -> in this case, there are 10 instances running
in parallel in the pool;
- (iii) N+K (active-standby) redundancy where some instances
run actively, while others are in a dormant state.
* comment Z9: How about this add-on then ? "... achieved by the
VNF Pool *architecture* utilized/adopted by the VNF ..."
Best,
Chidung
Hi, Chidung,
Please see my reply enclosed in the attachment. Regarding
comment#6, I’d like to explain that we don’t restrict to the
case that in a pool, at a given time, there is only one
running instance and all others are sleeping. A pool should be
flexible to handle more cases, including multiple running
instances and multiple standby instances.
Look forward to your further comments & suggestions.
-Ning
*发****送时闎**:*2014幎6月19日0:40
*收件人**:*Zongning
*䞻题**:*Re: [vnfpool] 答倍: Updated VNFPool Charter
Hi Ning,
1) Is it exact that scaling out/in, one main characteristic of
VNFs (compared to PNFs), is not included ?
2) Some comments/suggestions are enclosed.
Best,
Chidung
Dear all,
Please review the charter text included in the last email.
We are hoping that a general consensus on the charter
could be achieved on the list, then a stable charter is
ready for the VNFPool session in Toronto.
Thanks.
-Ning
代****衚***Zongning
*发****送时闎**:*2014幎6月12日11:20
*䞻题**:*[vnfpool] Updated VNFPool Charter
Dear all,
Based on the list discussion since we posted the last
version, I have made some (minor) revision of the charter.
1)State that service state synchronization is out of scope
“in this phase”;
2)Include VNF Pool with both virtualized and
non-virtualized network function for further study;
3)Explicitly state that the reference solution & gap
analysis is not limited to RSerPool, but open to any other
solutions, although no decision on protocols will be made
in this phase;
4)State that the linkage between SFC and VNF Pool is just
like a pool user and a pool – nothing specified (yet);
5)Update bullet #4 under “Questions that are raised
”, to
keep it consistent with the idea that pooling is not
visible to the service control entity.
==========================================================================
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 achieve higher reliability, 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.Conceptually, a
Pool Manager is used to manage a 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
·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?
·After a VNF instance failover, how does the Pool Manager
notify the service control entity some characteristic
changes of the VNF, e.g., capacity change, but without
disclosure of the pooling procedure?
The WG initially focuses on several reliability mechanisms
that are mainly associated with a redundancy model based
on a VNF Pool. Additional mechanisms may include pool
state maintenance only for pooling purpose. Service state
synchronization is out of scope for this phase. The WG
assumes that a VNF Pool contains redundant VNF instances
of same functional type. Different types of VNFs are
envisioned to be held in separate VNF Pools. VNF Pool
composed by both virtualized and non-virtualized
functional instances may be included after further use
case and requirements study. 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 Pooland
the service control entity.
·Identify and analyze reliable interfaces, such as
transport protocol like 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
the Pool Manager.
The WG plans to deliver a problem statement, a set of use
cases, requirements and an architecture covering the
aforementioned technical aspects, and applicability and
gap analysis of existing technologies including but not
limited to RSerPool. We will rely heavily on existing IETF
technologies, but that gaps will be found around problems
like redundancy mechanisms, state maintenancesolely for
pooling purposes, reliable transport, and trust/security,
all of which will need to be considered and addressed.
Although no decision on protocols will be made in this
phase, we will keep open for candidate protocols for 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. Just like the communication
between any pool users and VNF Pool, the information
exchanged between the VNF Pool and the SFC may include
some operational information of the VNF Pool.
December 2014 - Submit VNFPool Problem Statement to IESG
for publication as an Informational document.
April 2015 - Submit VNFPool Use Cases to IESG for
publication as an Informational document.
August 2015 - Submit VNFPool Requirements, including the
manageability of VNF Pool to IESG for publication as an
Informational document.
August 2015 - Submit VNFPool Architecture to IESG for
publication as an Informational document.
December 2015 - Submit one or more Applicability and Gap
Analysis of existing protocols to VNFPool to IESG for
publication as Informational document(s).
==========================================================================
Your comments and suggestions to the charter are ALWAYS
highly appreciated!
Thanks.
-Ning
_______________________________________________
vnfpool mailing list
https://www.ietf.org/mailman/listinfo/vnfpool

[Hidetoshi Yokota]

Dear Ning,

Thanks a lot for updating the charter and congratulations on BoF
approval! Allow me to ask a couple of clarification questions.

o Could you clarify what "service state synchronization" is and why it
is out of scope in this phase?
- Does this service state include "networking service"? If so,
active/active redundancy cannot maintain the state information in, for
example, virtual routers any more, which would be a significant degrade
from the current physical networks.
- What is the relationship between service state synchronization and
pool state maintenance?

2) Is the service control entity the NFV Orchestrator or VNF Manager or
none of them in NFV terminolgy?

3) In the last paragraph just before Goals and Milestones, it says, "the
information exchanged between the VNF Pool and the SFC may..." If some
information is exchanged between them, they are not independent any
more, which would contradict the first sentence of this paragraph.

Could you clarify a bit more on them please?

Regards,
--
Hidetoshi Yokota

KDDI R&D Laboratories, Inc.

Post by Zongning
Dear all,
Based on the list discussion since we posted the last version, I have
1)State that service state synchronization is out of scope “in this
phase”;**
2)Include VNF Pool with both virtualized and non-virtualized network
function for further study;**
3)Explicitly state that the reference solution & gap analysis is not
limited to RSerPool, but open to any other solutions, although no
decision on protocols will be made in this phase;**
4)State that the linkage between SFC and VNF Pool is just like a pool
user and a pool – nothing specified (yet);**
5)Update bullet #4 under “Questions that are raised…”, to keep it
consistent with the idea that pooling is not visible to the service
control entity.**
==========================================================================
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 achieve higher reliability, 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.Conceptually, a Pool Manager is used to manage a 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?
·After a VNF instance failover, how does the Pool Manager notify the
service control entity some characteristic changes of the VNF, e.g.,
capacity change, but without disclosure of the pooling procedure?
The WG initially focuses on several reliability mechanisms that are
mainly associated with a redundancy model based on a VNF Pool.
Additional mechanisms may include pool state maintenance only for
pooling purpose. Service state synchronization is out of scope for
this phase. The WGassumesthat a VNF Pool contains redundant VNF
instances of same functional type. Different types of VNFs are
envisioned to be held in separate VNF Pools. VNF Pool composed by both
virtualized and non-virtualized functional instances may be included
after further use case and requirements study. 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 Pooland the service control entity.
·Identify and analyze reliable interfaces, such as transport protocol
like 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 the Pool Manager.
The WG plans to deliver a problem statement, a set of use cases,
requirements and an architecture covering the aforementioned technical
aspects, and applicability and gap analysis of existing technologies
including but not limited to RSerPool. We will rely heavily on
existing IETF technologies, but that gaps will be found around
problems like redundancy mechanisms, state maintenancesolely for
pooling purposes, reliable transport, and trust/security, all of which
will need to be considered and addressed. Although no decision on
protocols will be made in this phase, we will keep open for candidate
protocols for 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 aVNFPool-enabled VNFas a normal service function and
therefore be able to merge it into an SFC just like any other service
functions. Just like the communication between any pool users and VNF
Pool, the information exchanged between the VNF Pool and the SFC may
include some operational information of the VNF Pool.
December 2014 - Submit VNFPool Problem Statement to IESG for
publication as an Informational document.
April 2015 - Submit VNFPool Use Cases to IESG for publication as an Informational document.
August 2015 - Submit VNFPool Requirements, including the manageability
of VNF Pool to IESG for publication as an Informational document.
August 2015 - Submit VNFPool Architecture to IESG for publication as
an Informational document.
December 2015 - Submit one or more Applicability and Gap Analysis of
existing protocols to VNFPool to IESG for publication as Informational
document(s).
==========================================================================
Your comments and suggestions to the charter are ALWAYS highly
appreciated!
Thanks.
-Ning
_______________________________________________
vnfpool mailing list
https://www.ietf.org/mailman/listinfo/vnfpool

[Zongning]

Hi, Hidetoshi,

Thanks for reviewing the new charter. Please see inline.

-----邮件原件-----
发件人: vnfpool [mailto:vnfpool-***@ietf.org] 代表 Hidetoshi Yokota
发送时间: 2014年6月16日 22:58
收件人: ***@ietf.org
主题: Re: [vnfpool] Updated VNFPool Charter

Dear Ning,

Thanks a lot for updating the charter and congratulations on BoF approval! Allow me to ask a couple of clarification questions.

o Could you clarify what "service state synchronization" is and why it is out of scope in this phase?

[Ning] Service state related to a specific function, e.g., NAT translation table, is usually synchronized between a live and backup VNF instance for stateful failover. However, this seemed to be a controversial item during the last BoF in London IETF, where we could not find multi-vendor support to standardize the state synchronization interface among their VNFs. We certainly understand that this is still a very important item for VNF failover, and will keep looking for the multi-vendor support. As mentioned in the charter, we leave it out of scope in this phase, which means we don't exclude it but will treat it as a future work.

- Does this service state include "networking service"? If so, active/active redundancy cannot maintain the state information in, for example, virtual routers any more, which would be a significant degrade from the current physical networks.

[Ning] See above. We agree it is important to maintain service state, but leave it out of scope until we find enough multi-vendor support.

- What is the relationship between service state synchronization and pool state maintenance?

[Ning] Pool states could be operational information of VNF pool itself, e.g. redundancy settings (n+k, 1:n, etc.), backup location/status, etc. They are not related to service state.

2) Is the service control entity the NFV Orchestrator or VNF Manager or none of them in NFV terminolgy?

[Ning] I would guess it is more like the NFV Orchestrator to orchestrate the whole service, although we don’t map the VNFPool terminology to NFV terminology by purpose. :-)

3) In the last paragraph just before Goals and Milestones, it says, "the information exchanged between the VNF Pool and the SFC may..." If some information is exchanged between them, they are not independent any more, which would contradict the first sentence of this paragraph.

[Ning] Well, "independent" means that the pooling mechanisms defined in VNFPool are not coupled/dependent to SFC. But "independent" doesn't mean that they are not communicating at all. :-) So we have "information exchanged ...".

Could you clarify a bit more on them please?

Regards,
--
Hidetoshi Yokota

KDDI R&D Laboratories, Inc.

Post by Zongning
Dear all,
Based on the list discussion since we posted the last version, I have
1)State that service state synchronization is out of scope “in this
phase”;**
2)Include VNF Pool with both virtualized and non-virtualized network
function for further study;**
3)Explicitly state that the reference solution & gap analysis is not
limited to RSerPool, but open to any other solutions, although no
decision on protocols will be made in this phase;**
4)State that the linkage between SFC and VNF Pool is just like a pool
user and a pool – nothing specified (yet);**
5)Update bullet #4 under “Questions that are raised…”, to keep it
consistent with the idea that pooling is not visible to the service
control entity.**
======================================================================
====
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 achieve higher reliability, 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.Conceptually, a Pool Manager is used to manage a 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?
·After a VNF instance failover, how does the Pool Manager notify the
service control entity some characteristic changes of the VNF, e.g.,
capacity change, but without disclosure of the pooling procedure?
The WG initially focuses on several reliability mechanisms that are
mainly associated with a redundancy model based on a VNF Pool.
Additional mechanisms may include pool state maintenance only for
pooling purpose. Service state synchronization is out of scope for
this phase. The WGassumesthat a VNF Pool contains redundant VNF
instances of same functional type. Different types of VNFs are
envisioned to be held in separate VNF Pools. VNF Pool composed by both
virtualized and non-virtualized functional instances may be included
after further use case and requirements study. 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 Pooland the service control entity.
·Identify and analyze reliable interfaces, such as transport protocol
like 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 the Pool Manager.
The WG plans to deliver a problem statement, a set of use cases,
requirements and an architecture covering the aforementioned technical
aspects, and applicability and gap analysis of existing technologies
including but not limited to RSerPool. We will rely heavily on
existing IETF technologies, but that gaps will be found around
problems like redundancy mechanisms, state maintenancesolely for
pooling purposes, reliable transport, and trust/security, all of which
will need to be considered and addressed. Although no decision on
protocols will be made in this phase, we will keep open for candidate
protocols for 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 aVNFPool-enabled VNFas a normal service function and
therefore be able to merge it into an SFC just like any other service
functions. Just like the communication between any pool users and VNF
Pool, the information exchanged between the VNF Pool and the SFC may
include some operational information of the VNF Pool.
December 2014 - Submit VNFPool Problem Statement to IESG for
publication as an Informational document.
April 2015 - Submit VNFPool Use Cases to IESG for publication as an Informational document.
August 2015 - Submit VNFPool Requirements, including the manageability
of VNF Pool to IESG for publication as an Informational document.
August 2015 - Submit VNFPool Architecture to IESG for publication as
an Informational document.
December 2015 - Submit one or more Applicability and Gap Analysis of
existing protocols to VNFPool to IESG for publication as Informational
document(s).
======================================================================
====
Your comments and suggestions to the charter are ALWAYS highly
appreciated!
Thanks.
-Ning
_______________________________________________
vnfpool mailing list
https://www.ietf.org/mailman/listinfo/vnfpool

_______________________________________________
vnfpool mailing list
***@ietf.org
https://www.ietf.org/ma

[Hidetoshi Yokota]

<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<font face="Helvetica, Arial, sans-serif">Hi Ning,<br>
<br>
Thanks for your answer and clarification and sorry for my late response.<br>
<br>
Please see inline:<br>
<br>
</font>
<div class="moz-cite-prefix">(2014/06/17 10:36), Zongning wrote:<br>
</div>
<blockquote
cite="mid:***@nkgeml501-mbs.china.huawei.com"
type="cite">
<pre wrap="">Hi, Hidetoshi,

Thanks for reviewing the new charter. Please see inline.

-----邮件原件-----
发件人: vnfpool [<a class="moz-txt-link-freetext" href="mailto:vnfpool-***@ietf.org">mailto:vnfpool-***@ietf.org</a>] 代表 Hidetoshi Yokota
发送时间: 2014年6月16日 22:58
收件人: <a class="moz-txt-link-abbreviated" href="mailto:***@ietf.org">***@ietf.org</a>
主题: Re: [vnfpool] Updated VNFPool Charter

Dear Ning,

Thanks a lot for updating the charter and congratulations on BoF approval! Allow me to ask a couple of clarification questions.

o Could you clarify what "service state synchronization" is and why it is out of scope in this phase?

[Ning] Service state related to a specific function, e.g., NAT translation table, is usually synchronized between a live and backup VNF instance for stateful failover. However, this seemed to be a controversial item during the last BoF in London IETF, where we could not find multi-vendor support to standardize the state synchronization interface among their VNFs. We certainly understand that this is still a very important item for VNF failover, and will keep looking for the multi-vendor support. As mentioned in the charter, we leave it out of scope in this phase, which means we don't exclude it but will treat it as a future work.
</pre>
</blockquote>
<font face="Helvetica, Arial, sans-serif"><br>
HY&gt; State synchronization is already identified by the PS
document, so it is not appropriate just to say "out of scope in
this phase". It may be possible to provide some assisting
functions to the VNF even if service state synchronization is done
within VNFs. </font><font face="Helvetica, Arial, sans-serif"><font
face="Helvetica, Arial, sans-serif">At least, it should be
discussed what level of synchronization can be supported and
when. My proposal is: "<b>T</b><b>he support of service state
synchronization (e.g., its level and timing) will be
determined during the course of this work</b>"<br>
  </font><br>
</font>
<blockquote
cite="mid:***@nkgeml501-mbs.china.huawei.com"
type="cite">
<pre wrap="">
- Does this service state include "networking service"? If so, active/active redundancy cannot maintain the state information in, for example, virtual routers any more, which would be a significant degrade from the current physical networks.

[Ning] See above. We agree it is important to maintain service state, but leave it out of scope until we find enough multi-vendor support. </pre> </blockquote> <font face="Helvetica, Arial, sans-serif">HY&gt; The same discussion
as the above. We should at least discuss it and potential
requirement may be identified apart from when to fulfill it.<br>
<br>
</font>
<blockquote
cite="mid:***@nkgeml501-mbs.china.huawei.com"
type="cite">
<pre wrap="">
- What is the relationship between service state synchronization and pool state maintenance?

[Ning] Pool states could be operational information of VNF pool itself, e.g. redundancy settings (n+k, 1:n, etc.), backup location/status, etc. They are not related to service state. </pre> </blockquote> <font face="Helvetica, Arial, sans-serif">HY&gt; Ok. Thanks.</font><br>
<blockquote
cite="mid:***@nkgeml501-mbs.china.huawei.com"
type="cite">
<pre wrap="">
2) Is the service control entity the NFV Orchestrator or VNF Manager or none of them in NFV terminolgy?

[Ning] I would guess it is more like the NFV Orchestrator to orchestrate the whole service, although we don’t map the VNFPool terminology to NFV terminology by purpose. :-)

3) In the last paragraph just before Goals and Milestones, it says, "the information exchanged between the VNF Pool and the SFC may..." If some information is exchanged between them, they are not independent any more, which would contradict the first sentence of this paragraph.

[Ning] Well, "independent" means that the pooling mechanisms defined in VNFPool are not coupled/dependent to SFC. But "independent" doesn't mean that they are not communicating at all. :-) So we have "information exchanged ...". </pre> </blockquote> <br> <font face="Helvetica, Arial, sans-serif">HY&gt; Ok, I think what is
important is "complementary" and "independent" could be
misleading. My proposal is: <b>In particular, the WG will work
closely with the SFC WG, which is expected to provide
complementary functionality to VNF Pool</b>.</font><br>
<br>
<font face="Helvetica, Arial, sans-serif">Regards,</font><font
face="Helvetica, Arial, sans-serif"><br>
</font>
<pre class="moz-signature" cols="72">--
Hidetoshi Yokota

KDDI R&amp;D Laboratories, Inc.
<a class="moz-txt-link-abbreviated" href="mailto:e-mail:***@kddilabs.jp">e-mail:***@kddilabs.jp</a></pre>
<font face="Helvetica, Arial, sans-serif"><br>
</font>
<blockquote
cite="mid:***@nkgeml501-mbs.china.huawei.com"
type="cite">
<pre wrap="">
Could you clarify a bit more on them please?

Regards,

--
Hidetoshi Yokota

KDDI R&amp;D Laboratories, Inc.
<a class="moz-txt-link-abbreviated" href="mailto:e-mail:***@kddilabs.jp">e-mail:***@kddilabs.jp</a>

(2014/06/12 12:19), Zongning wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
Dear all,

Based on the list discussion since we posted the last version, I have
made some (minor) revision of the charter. The main changes are:

1)State that service state synchronization is out of scope “in this
phase”;**

2)Include VNF Pool with both virtualized and non-virtualized network
function for further study;**

3)Explicitly state that the reference solution &amp; gap analysis is not
limited to RSerPool, but open to any other solutions, although no
decision on protocols will be made in this phase;**

4)State that the linkage between SFC and VNF Pool is just like a pool
user and a pool – nothing specified (yet);**

5)Update bullet #4 under “Questions that are raised…”, to keep it
consistent with the idea that pooling is not visible to the service
control entity.**

======================================================================
====

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 achieve higher reliability, 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.Conceptually, a Pool Manager is used to manage a 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?

·After a VNF instance failover, how does the Pool Manager notify the
service control entity some characteristic changes of the VNF, e.g.,
capacity change, but without disclosure of the pooling procedure?

The WG initially focuses on several reliability mechanisms that are
mainly associated with a redundancy model based on a VNF Pool.
Additional mechanisms may include pool state maintenance only for
pooling purpose. Service state synchronization is out of scope for
this phase. The WGassumesthat a VNF Pool contains redundant VNF
instances of same functional type. Different types of VNFs are
envisioned to be held in separate VNF Pools. VNF Pool composed by both
virtualized and non-virtualized functional instances may be included
after further use case and requirements study. 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 Pooland the service control entity.

·Identify and analyze reliable interfaces, such as transport protocol
like 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 the Pool Manager.

The WG plans to deliver a problem statement, a set of use cases,
requirements and an architecture covering the aforementioned technical
aspects, and applicability and gap analysis of existing technologies
including but not limited to RSerPool. We will rely heavily on
existing IETF technologies, but that gaps will be found around
problems like redundancy mechanisms, state maintenancesolely for
pooling purposes, reliable transport, and trust/security, all of which
will need to be considered and addressed. Although no decision on
protocols will be made in this phase, we will keep open for candidate
protocols for 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 aVNFPool-enabled VNFas a normal service function and
therefore be able to merge it into an SFC just like any other service
functions. Just like the communication between any pool users and VNF
Pool, the information exchanged between the VNF Pool and the SFC may
include some operational information of the VNF Pool.

Goals and Milestones:

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

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

August 2015 - Submit VNFPool Requirements, including the manageability
of VNF Pool to IESG for publication as an Informational document.

August 2015 - Submit VNFPool Architecture to IESG for publication as
an Informational document.

December 2015 - Submit one or more Applicability and Gap Analysis of
existing protocols to VNFPool to IESG for publication as Informational
document(s).

======================================================================
====

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

Thanks.

-Ning



_______________________________________________
vnfpool mailing list
<a class="moz-txt-link-abbreviated" href="mailto:***@ietf.org">***@ietf.org</a>
<a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/vnfpool">https://www.ietf.org/mailman/listinfo/vnfpool</a>
</pre>
</blockquote>
<pre wrap="">

_______________________________________________
vnfpool mailing list
<a class="moz-txt-link-abbreviated" href="mailto:***@ietf.org">***@ietf.org</a>
<a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/vnfpool">https://www.ietf.org/mailman/listinfo/vnfpool</a>
_______________________________________________
vnfpool mailing list
<a class="moz-txt-link-abbreviated" href="mailto:***@ietf.org">***@ietf.org</a>
<a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/vnfpool">https://www.ietf.org/mailman/listinfo/vnfpool</a>
</pre>
</blockquote>
<br>
</body>
</html>

[Zongning]

Hi, Hidetoshi,

Sorry for my belated reply.
I tend to agree that we could at least discuss the use cases and requirements for service state synchronization among different vendors, but without making a formal deliverable until re-charter.
Let’s put this as a open question to be discussed during Toronto BoF.

Thanks.

-Ning

发件人: vnfpool [mailto:vnfpool-***@ietf.org] 代衚 Hidetoshi Yokota
发送时闎: 2014幎6月21日 20:35
收件人: ***@ietf.org
䞻题: Re: [vnfpool] 答倍: Updated VNFPool Charter

Hi Ning,

Thanks for your answer and clarification and sorry for my late response.

Please see inline:
(2014/06/17 10:36), Zongning wrote:

Hi, Hidetoshi,



Thanks for reviewing the new charter. Please see inline.



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

发件人: vnfpool [mailto:vnfpool-***@ietf.org] 代衚 Hidetoshi Yokota

发送时闎: 2014幎6月16日 22:58

收件人: ***@ietf.org<mailto:***@ietf.org>

䞻题: Re: [vnfpool] Updated VNFPool Charter



Dear Ning,



Thanks a lot for updating the charter and congratulations on BoF approval! Allow me to ask a couple of clarification questions.



o Could you clarify what "service state synchronization" is and why it is out of scope in this phase?



[Ning] Service state related to a specific function, e.g., NAT translation table, is usually synchronized between a live and backup VNF instance for stateful failover. However, this seemed to be a controversial item during the last BoF in London IETF, where we could not find multi-vendor support to standardize the state synchronization interface among their VNFs. We certainly understand that this is still a very important item for VNF failover, and will keep looking for the multi-vendor support. As mentioned in the charter, we leave it out of scope in this phase, which means we don't exclude it but will treat it as a future work.

HY> State synchronization is already identified by the PS document, so it is not appropriate just to say "out of scope in this phase". It may be possible to provide some assisting functions to the VNF even if service state synchronization is done within VNFs. At least, it should be discussed what level of synchronization can be supported and when. My proposal is: "The support of service state synchronization (e.g., its level and timing) will be determined during the course of this work"





- Does this service state include "networking service"? If so, active/active redundancy cannot maintain the state information in, for example, virtual routers any more, which would be a significant degrade from the current physical networks.



[Ning] See above. We agree it is important to maintain service state, but leave it out of scope until we find enough multi-vendor support.
HY> The same discussion as the above. We should at least discuss it and potential requirement may be identified apart from when to fulfill it.





- What is the relationship between service state synchronization and pool state maintenance?



[Ning] Pool states could be operational information of VNF pool itself, e.g. redundancy settings (n+k, 1:n, etc.), backup location/status, etc. They are not related to service state.
HY> Ok. Thanks.




2) Is the service control entity the NFV Orchestrator or VNF Manager or none of them in NFV terminolgy?



[Ning] I would guess it is more like the NFV Orchestrator to orchestrate the whole service, although we don’t map the VNFPool terminology to NFV terminology by purpose. :-)



3) In the last paragraph just before Goals and Milestones, it says, "the information exchanged between the VNF Pool and the SFC may..." If some information is exchanged between them, they are not independent any more, which would contradict the first sentence of this paragraph.



[Ning] Well, "independent" means that the pooling mechanisms defined in VNFPool are not coupled/dependent to SFC. But "independent" doesn't mean that they are not communicating at all. :-) So we have "information exchanged ...".

HY> Ok, I think what is important is "complementary" and "independent" could be misleading. My proposal is: In particular, the WG will work closely with the SFC WG, which is expected to provide complementary functionality to VNF Pool.

Regards,
--
Hidetoshi Yokota



KDDI R&D Laboratories, Inc.

e-mail:***@kddilabs.jp<mailto:e-mail:***@kddilabs.jp>





Could you clarify a bit more on them please?



Regards,
--
Hidetoshi Yokota



KDDI R&D Laboratories, Inc.

e-mail:***@kddilabs.jp<mailto:e-mail:***@kddilabs.jp>



(2014/06/12 12:19), Zongning wrote:



Dear all,



Based on the list discussion since we posted the last version, I have

made some (minor) revision of the charter. The main changes are:



1)State that service state synchronization is out of scope “in this

phase”;**



2)Include VNF Pool with both virtualized and non-virtualized network

function for further study;**



3)Explicitly state that the reference solution & gap analysis is not

limited to RSerPool, but open to any other solutions, although no

decision on protocols will be made in this phase;**



4)State that the linkage between SFC and VNF Pool is just like a pool

user and a pool – nothing specified (yet);**



5)Update bullet #4 under “Questions that are raised
”, to keep it

consistent with the idea that pooling is not visible to the service

control entity.**



======================================================================

====



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 achieve higher reliability, 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.Conceptually, a Pool Manager is used to manage a 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?



·After a VNF instance failover, how does the Pool Manager notify the

service control entity some characteristic changes of the VNF, e.g.,

capacity change, but without disclosure of the pooling procedure?



The WG initially focuses on several reliability mechanisms that are

mainly associated with a redundancy model based on a VNF Pool.

Additional mechanisms may include pool state maintenance only for

pooling purpose. Service state synchronization is out of scope for

this phase. The WGassumesthat a VNF Pool contains redundant VNF

instances of same functional type. Different types of VNFs are

envisioned to be held in separate VNF Pools. VNF Pool composed by both

virtualized and non-virtualized functional instances may be included

after further use case and requirements study. 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 Pooland the service control entity.



·Identify and analyze reliable interfaces, such as transport protocol

like 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 the Pool Manager.



The WG plans to deliver a problem statement, a set of use cases,

requirements and an architecture covering the aforementioned technical

aspects, and applicability and gap analysis of existing technologies

including but not limited to RSerPool. We will rely heavily on

existing IETF technologies, but that gaps will be found around

problems like redundancy mechanisms, state maintenancesolely for

pooling purposes, reliable transport, and trust/security, all of which

will need to be considered and addressed. Although no decision on

protocols will be made in this phase, we will keep open for candidate

protocols for 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 aVNFPool-enabled VNFas a normal service function and

therefore be able to merge it into an SFC just like any other service

functions. Just like the communication between any pool users and VNF

Pool, the information exchanged between the VNF Pool and the SFC may

include some operational information of the VNF Pool.



Goals and Milestones:



December 2014 - Submit VNFPool Problem Statement to IESG for

publication as an Informational document.



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

Informational document.



August 2015 - Submit VNFPool Requirements, including the manageability

of VNF Pool to IESG for publication as an Informational document.



August 2015 - Submit VNFPool Architecture to IESG for publication as

an Informational document.



December 2015 - Submit one or more Applicability and Gap Analysis of

existing protocols to VNFPool to IESG for publication as Informational

document(s).



======================================================================

====



Your comments and suggestions to the charter are ALWAYS highly

appreciated!



Thanks.



-Ning







_______________________________________________

vnfpool mailing list

***@ietf.org<mailto:***@ietf.org>

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





_______________________________________________

vnfpool mailing list

***@ietf.org<mailto:***@ietf.org>

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

_______________________________________________

vnfpool mailing list

***@ietf.org<mailto:***@ietf.org>

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

[Adrian Farrel]

Hi Ning,

I know that there have been some discussions on the list about the draft
charter, but I am returning to your clean copy from 12th June.

The charter looks good to me (at least from an RTG perspective). I have some
nits and a minor comment below.

Thanks,
Adrian

Post by Zongning
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

s/of the/of/

Post by Zongning
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).

I think that should read...
(i.e., under the control of a hypervisor)

Post by Zongning
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

s/factors of risk/risk factors/

Post by Zongning
levels including hypervisors and virtual machines, hardware failure, and
instance migration that can make a VNF instance unreliable.
In order to achieve higher reliability, 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.Conceptually, a Pool Manager is used to manage a VNF Pool,

s/Pool.Conceptually/Pool. Conceptually/

Post by Zongning
e.g., selects active/standby VNF instances, and potentially interacts

s/selects/to select/
s/interacts/to interact/

Post by Zongning
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.

Is this completely how you want it? Isn't there some benefit to a service
control entity in knowing that a VNF is protected through a pool compared to
unprotected? That is, when a service control entity is selecting between NFV
instances it may select according to various factors (such as path length
between functions in a chain, and loading of VNF instances) and the knowledge
that one VNF instance is protected through an VNV pool may be significant.

So, I think that it is the operation of the VNF pool reliability mechanism that
is unknown to the service control entity, but not the fact of reliability.

Post by Zongning
. 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?

Here we include the fact of reliability.

Post by Zongning
. After a VNF instance failover, how does the Pool Manager notify
the service control entity some characteristic changes of the VNF,
e.g., capacity change, but without disclosure of the pooling
procedure?
The WG initially focuses on several reliability mechanisms that are
mainly associated with a redundancy model based on a VNF Pool.
Additional mechanisms may include pool state maintenance only
for pooling purpose. Service state synchronization is out of scope
for this phase. The WG assumes that a VNF Pool contains redundant
VNF instances of same functional type. Different types of VNFs are
envisioned to be held in separate VNF Pools. VNF Pool composed
by both virtualized and non-virtualized functional instances may be
included after further use case and requirements study. 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.

I wonder whether the charter should be clearer that the VNF pool appears as an
instance and that only one instance in a pool is really active. The point here
is that the pool is not a set for load balancing across and does not increase
the load capacity of the VNF that the service control function can see.

Post by Zongning
. 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 interfaces, such as transport protocol like
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 the Pool Manager.
The WG plans to deliver a problem statement, a set of use cases,
requirements and an architecture covering the aforementioned technical
aspects, and applicability and gap analysis of existing technologies including
but not limited to RSerPool. We will rely heavily on existing IETF

technologies,

Post by Zongning
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. Although no
decision on protocols will be made in this phase, we will keep open for
candidate protocols for 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. Just like
the communication between any pool users and VNF Pool, the information
exchanged between the VNF Pool and the SFC may include some operational
information of the VNF Pool.
December 2014 - Submit VNFPool Problem Statement to IESG for publication
as an Informational document.
April 2015 - Submit VNFPool Use Cases to IESG for publication as an

Informational

Post by Zongning
document.
August 2015 - Submit VNFPool Requirements, including the manageability of VNF
Pool to IESG for publication as an Informational document.
August 2015 - Submit VNFPool Architecture to IESG for publication as an
Informational document.
December 2015 - Submit one or more Applicability and Gap Analysis of existing
protocols to VNFPool to IESG for publication as Informational document(s).

[Zongning]

Hi, Adrian,

Thank you for kindly review. I appreciate the nits correction, and see inline for minor comments.

-----邮件原件-----
发件人: Adrian Farrel [mailto:***@olddog.co.uk]
发送时间: 2014年6月24日 23:27
收件人: Zongning; ***@ietf.org
主题: RE: [vnfpool] Updated VNFPool Charter

Hi Ning,

I know that there have been some discussions on the list about the draft charter, but I am returning to your clean copy from 12th June.

The charter looks good to me (at least from an RTG perspective). I have some nits and a minor comment below.

Thanks,
Adrian

Post by Zongning
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.

Is this completely how you want it? Isn't there some benefit to a service control entity in knowing that a VNF is protected through a pool compared to unprotected? That is, when a service control entity is selecting between NFV instances it may select according to various factors (such as path length between functions in a chain, and loading of VNF instances) and the knowledge that one VNF instance is protected through an VNV pool may be significant.

So, I think that it is the operation of the VNF pool reliability mechanism that is unknown to the service control entity, but not the fact of reliability.

[Ning] Yes, you are right. A VNF could tell a service control entity that it is protected by a pool for better service orchestration. But this should be based on the negotiation between VNF pool and service control entity. Some control entity may only wants to know if a VNF is reliable or less reliable, without knowing too much about if there is a pool ... Anyway, thank you for suggestion, and we will keep this as an important case during requirement study. :)

Post by Zongning
The WG initially focuses on several reliability mechanisms that are
mainly associated with a redundancy model based on a VNF Pool.
Additional mechanisms may include pool state maintenance only for
pooling purpose. Service state synchronization is out of scope for
this phase. The WG assumes that a VNF Pool contains redundant VNF
instances of same functional type. Different types of VNFs are
envisioned to be held in separate VNF Pools. VNF Pool composed by both
virtualized and non-virtualized functional instances may be included
after further use case and requirements study. 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.

I wonder whether the charter should be clearer that the VNF pool appears as an instance and that only one instance in a pool is really active. The point here is that the pool is not a set for load balancing across and does not increase the load capacity of the VNF that the service control function can see.

[Ning] You are right that a VNF pool appears as a single instance to outside entity such as service control entity. Regarding the internal model to a VNF pool, I do agree with Lac Chidung that we would not constrain a VNF pool's internal model to have only one active instance. Redundancy model with more than one active instance (e.g. n+k, n:m) is inherent to pooling methodology and will benefit a VNF pool with good flexibility & reliability.


Please let me know your further comments & suggestions.
Thank