Subject: [vnfpool] comments on VNF Pool Charter

From: "Sood, Kapil" <[email-masked]>
Date: Mon, 16 Jun 2014 17:51:35 +0000

Hello All,

A couple comments, maybe questions, on the VNF Charter:

1.      The point below indicates “to collect network information”…did you consider collecting the platform information as well?  I would suggest to add that.

2.      Please clarify the scope of the protocols work within the charter.  Current text says “re-chartering before adopting any work to develop new, or extend existing, protocols”.  But, it also says that group will work on 2 protocols.

Best Regards,

Kapil.

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

---

From: Zongning <[email-masked]>
Date: Tue, 17 Jun 2014 02:16:17 +0000

Hi, Kapil,

Thanks for the review. Please see inline.

Hello All,

[Ning] I’d think “platform information” may be too general term to be focused. In our charter, we collect network information for specific purpose, e.g., place a live and backup VNF instances into distributed physical locations, or locations without shared risk in the network. Could you please elaborate more on the purpose of using any specific piece of platform information, or give some use cases? We could then think about how to make it more focused, as required by the charter.

[Ning] Current charter lists a set of interfaces/protocols to be standardized, but will only delivers documents such as requirements to these interfaces/protocols, and architecture highlighting the functionalities of these interfaces/protocols. The protocol development, i.e., specifying on-the-wire message format, will be after the re-chartering.

Best Regards,

Kapil.

Hope my reply helps.

Thanks.

-Ning

---

From: "Sood, Kapil" <[email-masked]>
Date: Tue, 17 Jun 2014 22:44:11 +0000

Hello Ning,

Thank you for your comments.  Please see below:

Best Regards,

Kapil.

From: Zongning [mailto:[email-masked]]
Sent: Monday, June 16, 2014 7:16 PM
To: Sood, Kapil; [email-masked]
Subject: 答复: comments on VNF Pool Charter

Hi, Kapil,

Hello All,

[Ning] I’d think “platform information” may be too general term to be focused. In our charter, we collect network information for specific purpose, e.g., place a live and backup VNF instances into distributed physical locations, or locations without shared risk in the network. Could you please elaborate more on the purpose of using any specific piece of platform information, or give some use cases? We could then think about how to make it more focused, as required by the charter.
[Kapil] ETSI-NFV has defined multiple use cases for NFV placements/migration that depends on the target NFVI (platform) conditions – e.g. available CPU, Memory, Network Capabilities, etc.  So, it makes sense to consider those requirements as we define this charter.  Please share what network information this group is looking to collect and what are the possible sources?  Those might not be too different from some of the VNFI information sources.

[Kapil] OK, thanks.

Best Regards,

Kapil.

Hope my reply helps.

Thanks.

-Ning

---

From: Zongning <[email-masked]>
Date: Wed, 18 Jun 2014 02:00:26 +0000

Hi, Kapil,

Please see inline.

发件人: Sood, Kapil [mailto:[email-masked]]
发送时间: 2014年6月18日 6:44
收件人: Zongning; [email-masked]
主题: RE: comments on VNF Pool Charter

Hello Ning,

Best Regards,

Kapil.

From: Zongning [mailto:[email-masked]]
Sent: Monday, June 16, 2014 7:16 PM
To: Sood, Kapil; [email-masked]<mailto:[email-masked]>
Subject: 答复: comments on VNF Pool Charter

Hi, Kapil,

Hello All,

[Ning] You are right that a rich set of platform conditions are useful for VNF instance placement. This group will not address the whole issue of VNF deployment, but only focus on redundancy. One issue we have identified in Problem Statement I-D is to distribute active & standby instances into different network locations to avoid shared risk. Some existing interfaces defined by IETF (e.g., ALTO, I2RS) may be utilized to obtain network information such as network topology, link status, for such purpose. I do agree with you that if there are more requirements on placing VNF instance, more NFVI information should be considered. At this stage, I’d prefer to add a few words like “considering the infrastructure conditions…” in the bullet under “Questions that are raised…” in the charter. Is this OK for you?

Best Regards,

Kapil.

Hope my reply helps.

Thanks.

-Ning

---

From: "Sood, Kapil" <[email-masked]>
Date: Fri, 20 Jun 2014 05:17:14 +0000

Hi Ning,  Please see below…I trimmed the thread for readability…

[Ning] You are right that a rich set of platform conditions are useful for VNF instance placement. This group will not address the whole issue of VNF deployment, but only focus on redundancy. One issue we have identified in Problem Statement I-D is to distribute active & standby instances into different network locations to avoid shared risk. Some existing interfaces defined by IETF (e.g., ALTO, I2RS) may be utilized to obtain network information such as network topology, link status, for such purpose. I do agree with you that if there are more requirements on placing VNF instance, more NFVI information should be considered. At this stage, I’d prefer to add a few words like “considering the infrastructure conditions…” in the bullet under “Questions that are raised…” in the charter. Is this OK for you?
[Kapil] Well, I believe there will be many cases where the VIM/VNFM will need to determine the infrastructure conditions, even for SBY/ACT placements,  so I agree your suggestion to add appropriate text to the charter questions.

I do have a follow-up question on the contents of the specific images, more specifically live state including any secrets or sensitive information protection.  Is the charter dealing with the security aspects, too?

---

From: Melinda Shore <[email-masked]>
Date: Thu, 19 Jun 2014 23:00:44 -0800

On 6/19/14 9:17 PM, Sood, Kapil wrote:
> [Kapil] Well, I believe there will be many cases where the VIM/VNFM will
> need to determine the infrastructure conditions, even for SBY/ACT
> placements,  so I agree your suggestion to add appropriate text to the
> charter questions.

Hi, Kapil: at this point in the process we're trying to identify
the questions that a working group, should it be chartered, will
address, and it seems to me that at this time we're probably more
concerned with how to define the question so that it's something
we can answer - that is to say, we need to identify which pieces
of information will need to be used as the basis for a failover,
as well as which pieces of information will need to be transferred
or replicated.  (As a side note it's pretty clear that we'll need
to identify what's coupled with and dependent on ETSI NFV vs.
what's coupled with and dependent on IETF sfc).

> I do have a follow-up question on the contents of the specific images,
> more specifically live state including any secrets or sensitive
> information protection.  Is the charter dealing with the security
> aspects, too?

Yes, any work undertaken in the IETF needs to address security issues
(including privacy), and that's one of our higher-priority concerns
given the sensitivity of network state and potentially very serious
problems around service state.  We've got people with security
expertise involved right now, and may choose to exercise the option
of early security review as the documents progress.

Melinda

---

From: "Sood, Kapil" <[email-masked]>
Date: Fri, 20 Jun 2014 17:52:53 +0000

Thank you, Melinda.  This helps.  I am just joining the discussion, so just understanding context. 

Best Regards,

Kapil.

-----Original Message-----
From: Melinda Shore [mailto:[email-masked]] 
Sent: Friday, June 20, 2014 12:01 AM
To: Sood, Kapil; Zongning; [email-masked]
Subject: Re: [vnfpool] comments on VNF Pool Charter

On 6/19/14 9:17 PM, Sood, Kapil wrote:
> [Kapil] Well, I believe there will be many cases where the VIM/VNFM 
> will need to determine the infrastructure conditions, even for SBY/ACT 

Hi, Kapil: at this point in the process we're trying to identify the questions that a working group, should it be chartered, will address, and it seems to me that at this time we're probably more concerned with how to define the question so that it's something we can answer - that is to say, we need to identify which pieces of information will need to be used as the basis for a failover, as well as which pieces of information will need to be transferred or replicated.  (As a side note it's pretty clear that we'll need to identify what's coupled with and dependent on ETSI NFV vs.
what's coupled with and dependent on IETF sfc).

> information protection.  Is the charter dealing with the security 

Yes, any work undertaken in the IETF needs to address security issues (including privacy), and that's one of our higher-priority concerns given the sensitivity of network state and potentially very serious problems around service state.  We've got people with security expertise involved right now, and may choose to exercise the option of early security review as the documents progress.

Melinda

---

From: Melinda Shore <[email-masked]>
Date: Fri, 20 Jun 2014 10:12:16 -0800

> Thank you, Melinda.  This helps.  I am just joining the discussion, so just understanding context. 

Great!  I hope you'll continue to add comments or questions, and I hope
we'll see you in Toronto.

Melinda