Subject: [vnfpool] New Charter for Toronto

From: Zongning <[email-masked]>
Date: Fri, 4 Jul 2014 01:36:56 +0000

Hi, all,
Please find below the new VNFPool Charter, by which I'd like to keep entertaining you. :)
This new version is based on the list discussion and feedback mainly from LAC Chidung, Hidetoshi, Sood, and Adrian. Thank you guys for improving our charter. Although I'd regard this version as a stable charter that reflects a rough agreement on the list and is ready for Toronto, further comments and suggestions are *always* welcome.
=======================================================================
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 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 risk factors 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 implementation 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 adopted by 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 considering the infrastructure conditions, and scale a VNF instance 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 of 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 a same functional type. Different types of VNFs are envisioned to be held in separate VNF Pools. VNF Pool composed of 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 study 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.

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

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

*           Identification and analysis of 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 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.
We will work closely with the SFC WG, as we believe that SFC and VNF Pool are 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).
=======================================================================
Thanks.
-Ning

---

From: Don Clarke <[email-masked]>
Date: Fri, 4 Jul 2014 16:19:20 +0000

Ning and All,

I welcome this work as I have a strong belief that such mechanisms if properly implemented will enable NFV-based network topologies to provide many more options for delivering scalable high reliability networks than traditional point-hardware bounded topologies. I have highlighted this message in public statements whenever I get an opportunity and I have encouraged efforts in the ETSI NFV ISG towards this goal.

I would like to see a reference in this charter to related work in the ETSI NFV ISG for example in the REL Working Group (Naseem Khan copied) and the INF Working Group (Steve Wright copied). Also MANO (Raquel Morera copied). I know that you and no doubt many others on this list are involved in both places, but could we at least see some words in this charter that acknowledge relevant requirements coming from the NFV ISG?

Suggested text in line below.

Regards,
Don Clarke.

Chair, NFV ISG Network Operator Council

From: vnfpool [mailto:[email-masked]] On Behalf Of Zongning
Sent: Thursday, July 03, 2014 8:37 PM
To: [email-masked]
Subject: [vnfpool] New Charter for Toronto

Hi, all,

*       After a VNF instance failover, how does the Pool Manager notify the service control entity of some characteristic changes of the VNF, e.g., capacity change, but without disclosure of the pooling procedure?
The WG will refer to published ETSI NFV ISG documents relevant to this work, notably (but not limited to) the outputs of the REL, MANO and INF Working Groups to ensure that VNF Pooling mechanisms are compatible with the requirements published by the ETSI NFV ISG.
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 a same functional type. Different types of VNFs are envisioned to be held in separate VNF Pools. VNF Pool composed of 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 study the following technical aspects:

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 4 Jul 2014 19:31:52 +0100

Hi Don,
Just chipping in from the side lines....
I think this group of people working on VNFpool and those in the SFC working
group take the work done by ETSI on NFV very seriously. They coordinate closely
with Diego Lopez and consider the ETSI work as input.
However, your proposed text might be a little unusual in an IETF working group
charter. More likely would be to add to the final paragraph as:
OLD
We will work closely with the SFC WG, as we believe that SFC and VNF Pool are
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.
NEW
The VNFpool working group will work closely with the SFC WG, as SFC and VNF Pool
are 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. Furthermore, the VNFpool working
group will exchange information with ETSI to ensure that the work done by that
body is taken into account and to share the progress of the working group as it
produces documents.
 
Cheers,
Adrian (hating HTML emails)
From: vnfpool [mailto:[email-masked]] On Behalf Of Don Clarke
Sent: 04 July 2014 17:19
To: Zongning; [email-masked]
Cc: WRIGHT, STEVEN A; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: Re: [vnfpool] New Charter for Toronto
 
Ning and All,
 
I welcome this work as I have a strong belief that such mechanisms if properly
implemented will enable NFV-based network topologies to provide many more
options for delivering scalable high reliability networks than traditional
point-hardware bounded topologies. I have highlighted this message in public
statements whenever I get an opportunity and I have encouraged efforts in the
ETSI NFV ISG towards this goal.
 
I would like to see a reference in this charter to related work in the ETSI NFV
ISG for example in the REL Working Group (Naseem Khan copied) and the INF
Working Group (Steve Wright copied). Also MANO (Raquel Morera copied). I know
that you and no doubt many others on this list are involved in both places, but
could we at least see some words in this charter that acknowledge relevant
requirements coming from the NFV ISG?

Regards,
Don Clarke.

 
Hi, all,
Please find below the new VNFPool Charter, by which I'd like to keep
entertaining you. J
This new version is based on the list discussion and feedback mainly from LAC
Chidung, Hidetoshi, Sood, and Adrian. Thank you guys for improving our charter.
Although I'd regard this version as a stable charter that reflects a rough
agreement on the list and is ready for Toronto, further comments and suggestions
are *always* welcome.
=======================================================================
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 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 risk factors 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 implementation 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
adopted by 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 considering the infrastructure conditions, and scale a
VNF instance 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 of some characteristic changes of the VNF, e.g., capacity change,
but without disclosure of the pooling procedure?
The WG will refer to published ETSI NFV ISG documents relevant to this work,
notably (but not limited to) the outputs of the REL, MANO and INF Working Groups
to ensure that VNF Pooling mechanisms are compatible with the requirements
published by the ETSI NFV ISG.
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 a same functional type. Different types of
VNFs are envisioned to be held in separate VNF Pools. VNF Pool composed of 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 study 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.
.           Protocol between the Pool Manager and the underlying network to
collect the network information required for appropriate placement/selection of
backup instances.
.           Protocol between a VNF and the service control entity to exchange
operational information between a VNF Pool and the service control entity.
.           Identification and analysis of 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 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.
We will work closely with the SFC WG, as we believe that SFC and VNF Pool are
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).
=======================================================================
Thanks.
-Ning

---

From: "King, Daniel" <[email-masked]>
Date: Fri, 4 Jul 2014 20:25:14 +0000

Hi Don, 

Just an observational comment, and following on from Adrian, but not directly related to the Charter text proposal.

We (as authors) of Internet Drafts (I-Ds) cite documents where requirements and input is sourced, and within the context of VNF Pool  we have been referencing applicable (and especially openly available) ETSI documentation. As you mention VNF Pool discussions have taken place within the various ETSI NFV ISG WG sessions (especially REL, INF and MANO), so where relevant we can look to add specific references in I-D Acknowledgment sections as well. 

Br, Dan. 

From: vnfpool [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: 04 July 2014 19:32
To: 'Don Clarke'; 'Zongning'; [email-masked]
Cc: 'WRIGHT, STEVEN A'; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [vnfpool] New Charter for Toronto

Hi Don,
Just chipping in from the side lines....
I think this group of people working on VNFpool and those in the SFC working group take the work done by ETSI on NFV very seriously. They coordinate closely with Diego Lopez and consider the ETSI work as input.
However, your proposed text might be a little unusual in an IETF working group charter. More likely would be to add to the final paragraph as:
OLD
We will work closely with the SFC WG, as we believe that SFC and VNF Pool are 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.
NEW
The VNFpool working group will work closely with the SFC WG, as SFC and VNF Pool are 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. Furthermore, the VNFpool working group will exchange information with ETSI to ensure that the work done by that body is taken into account and to share the progress of the working group as it produces documents.

Cheers,
Cc: WRIGHT, STEVEN A; [email-masked]; [email-masked]; [email-masked]; [email-masked]

Ning and All,

Regards,
Don Clarke.

Hi, all,
Please find below the new VNFPool Charter, by which I’d like to keep entertaining you. ☺
This new version is based on the list discussion and feedback mainly from LAC Chidung, Hidetoshi, Sood, and Adrian. Thank you guys for improving our charter. Although I’d regard this version as a stable charter that reflects a rough agreement on the list and is ready for Toronto, further comments and suggestions are *always* welcome.
=======================================================================
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 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 risk factors 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 implementation 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 adopted by 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 considering the infrastructure conditions, and scale a VNF instance 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 of some characteristic changes of the VNF, e.g., capacity change, but without disclosure of the pooling procedure?
The WG will refer to published ETSI NFV ISG documents relevant to this work, notably (but not limited to) the outputs of the REL, MANO and INF Working Groups to ensure that VNF Pooling mechanisms are compatible with the requirements published by the ETSI NFV ISG.
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 a same functional type. Different types of VNFs are envisioned to be held in separate VNF Pools. VNF Pool composed of 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 study 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.
• Protocol between the Pool Manager and the underlying network to collect the network information required for appropriate placement/selection of backup instances.
• Protocol between a VNF and the service control entity to exchange operational information between a VNF Pool and the service control entity.
• Identification and analysis of 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 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.
We will work closely with the SFC WG, as we believe that SFC and VNF Pool are 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).
=======================================================================
Thanks.
-Ning

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 4 Jul 2014 22:32:05 +0000

Hi Adrian,
I understand why you want to avoid introducing a dependency between SDOs in the charter.
Some of the first drafts for VNFPOOL requirements and use cases have been written by people from and discussed in ETSI NFV REL WG.
I think there is already a natural cooperation between VNFPOOL BoF and NFV REL WG.
That said ETSI is a big organization and saying "will exchange information with ETSI" appears to be insufficient.
I would suggest to write "will exchange information with relevant WGs in ETSI NFV".

Cheers,
Mehmet

From: vnfpool [mailto:[email-masked]] On Behalf Of ext Adrian Farrel
Sent: Friday, July 04, 2014 8:32 PM
To: 'Don Clarke'; 'Zongning'; [email-masked]
Cc: 'WRIGHT, STEVEN A'; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [vnfpool] New Charter for Toronto

  Hi Don,

  Cheers,
  Adrian (hating HTML emails)
From: vnfpool [mailto:[email-masked]] On Behalf Of Don Clarke
Sent: 04 July 2014 17:19
To: Zongning; [email-masked]<mailto:[email-masked]>
Cc: WRIGHT, STEVEN A; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [vnfpool] New Charter for Toronto

Ning and All,

Regards,
Don Clarke.

From: vnfpool [mailto:[email-masked]] On Behalf Of Zongning
Sent: Thursday, July 03, 2014 8:37 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [vnfpool] New Charter for Toronto

  Hi, all,

---

From: Melinda Shore <[email-masked]>
Date: Fri, 04 Jul 2014 16:30:35 -0800

On 7/4/14 2:32 PM, Ersue, Mehmet (NSN - DE/Munich) wrote:
> That said ETSI is a big organization and saying “will exchange
> information with ETSI” appears to be insufficient.
> I would suggest to write“will exchange information with relevant WGs in
> ETSI NFV”.

Are you anticipating a liaison, or keeping it informal?

I agree about being specific about which ETSI body will be
engaged.

Melinda

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

"Software longa, hardware brevis."

---

From: <[email-masked]>
Date: Sat, 5 Jul 2014 06:30:54 +0000

Hi all,

If possible a liaison will be IMHO better! This will probably increase the 
certainty of specifying solutions that will be beneficiary for both SDOs.

In addition to that I would also like to mention that the 3GPP SA WG5 
approved a new Study Item on Network Management of Virtualized Networks. 
The objective of this activity is to provide recommendations for the 
standardization of the network management of fully virtualized mobile networks 
and mixed networks. 
I think that a possible cooperation between IETF and this new 3GPP SA WG5 will also be
beneficiary!

Best regards,
Georgios

________________________________________
Van: vnfpool [[email-masked]] namens Melinda Shore [[email-masked]]
Verzonden: zaterdag 5 juli 2014 2:30
Aan: [email-masked]; Ersue, Mehmet (NSN - DE/Munich)
Onderwerp: Re: [vnfpool] New Charter for Toronto

Melinda

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

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Sat, 5 Jul 2014 19:34:37 +0000

> > That said ETSI is a big organization and saying "will exchange
> > information with ETSI" appears to be insufficient.
> > I would suggest to write"will exchange information with relevant WGs
> in
> > ETSI NFV".
> 

I think a liaison between VNFPOOL and NFV REL WGs would be valuable, 
which I assume will happen sooner or later.
 
> I agree about being specific about which ETSI body will be

You can express what is already happening in many ways, also e.g.
"..will exchange information with relevant WGs in ETSI NFV, e.g. REL WG.." or 
"..will exchange information with ETSI NFV REL, MANO and INF WGs..".

Let me know which one you prefer.

There is one point though, which I would like to underline.
Being active in two organizations I know that compared to some other SDOs, ETSI NFV people are not trying to declare a technology as their ownership. It is just the aim to contribute and cooperate in the interest of reliable VNF pools.

Cheers,
Mehmet

---

From: Don Clarke <[email-masked]>
Date: Sun, 6 Jul 2014 20:52:59 +0000

Sorry for triggering such a big discussion. I think Mehmet captured my concern exactly. I only wanted to be sure that the IETF vnfpool folks take account of the excellent ground work already documented. I also recognize that the best way to achieve that is by active contribution.  On the other hand it does no harm to be explicit in the charter and through ongoing formal liaison to help "institutionalize" the relationship. Especially for folks in the IETF who might not understand the significance of the ISG work.

I also agree there is no rush to put in a liaison as we have high profile individuals active in both places at the moment and hopefully ongoing. 

Regards,
Don. 
________________________________________
From: DIEGO LOPEZ GARCIA [[email-masked]]
Sent: Saturday, July 05, 2014 18:38
To: ext Melinda Shore; Ersue, Mehmet (NSN - DE/Munich)
Cc: [email-masked]; Don Clarke; Zongning; [email-masked]; WRIGHT, STEVEN A; [email-masked]; [email-masked]; DIEGO LOPEZ GARCIA; Raquel Morera
Subject: Re: [vnfpool] New Charter for Toronto

Hi,

On 5 Jul 2014, at 21:34 , Ersue, Mehmet (NSN - DE/Munich) <[email-masked]<mailto:[email-masked]>> wrote:

Just let me note that I think the first one, as it is more open to future evolution in the ETSI NFV.

Being in the same position as Mehmet is, let me support his view on this as well.

Be goode,

--
PLEASE NOTE MY NEW EMAIL ADDRESS
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

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

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: Zongning <[email-masked]>
Date: Mon, 7 Jul 2014 02:26:30 +0000

Hi, Don and All,

(deleted some recipients as they are already the members of vnfpool list ...)

Firstly, thank you so much for acknowledging our work of VNFPool in IETF. :-)
I absolutely agree that VNFPool folks should properly take the excellent work done by NFV ISG into account whenever appropriate. Actually, as mentioned by Daniel, the co-authors of existing VNFPool drafts have been kindly regarding ISG as key informational resource, and will continue making appropriate references when more ISG documents are publicly available.
I am also glad to let you know that from the day one of VNFPool initiative, the active contributors are (really) active in both communities. For instance, I was leading Gap Analysis section in REL GS, and had communications with REL folks about VNFPool. On the VNFPool list, from time to time there are folks talking about the requirements from REL WG. So both communities have been in a good alignment in a nature (de facto) way. But I do agree with you that it does no harm to be explicit in VNFPool charter and through LS to formalized such coordination.
I will try to suggest some words into the charter and also help on the LS, when appropriate.

Thanks.

-Ning

-----邮件原件-----
发件人: Don Clarke [mailto:[email-masked]] 
发送时间: 2014年7月7日 4:53
收件人: DIEGO LOPEZ GARCIA; ext Melinda Shore; Ersue, Mehmet (NSN - DE/Munich)
抄送: [email-masked]; Zongning; [email-masked]; WRIGHT, STEVEN A; [email-masked]; [email-masked]; Raquel Morera
主题: RE: [vnfpool] New Charter for Toronto

Regards,
Don. 

Hi,

I agree about being specific about which ETSI body will be engaged.

You can express what is already happening in many ways, also e.g.
"..will exchange information with relevant WGs in ETSI NFV, e.g. REL WG.." or "..will exchange information with ETSI NFV REL, MANO and INF WGs..".

Be goode,

Dr Diego R. Lopez
Telefonica I+D

---

From: Zongning <[email-masked]>
Date: Mon, 7 Jul 2014 02:47:57 +0000

Hi, Diego and Mehmet,

I prefer the first one as well. ☺

Thanks.

-Ning

发件人: DIEGO LOPEZ GARCIA [mailto:[email-masked]]
发送时间: 2014年7月6日 7:38
收件人: ext Melinda Shore; Ersue, Mehmet (NSN - DE/Munich)
抄送: [email-masked]; Don Clarke; Zongning; [email-masked]; WRIGHT, STEVEN A; [email-masked]; [email-masked]; DIEGO LOPEZ GARCIA; Raquel Morera
主题: Re: [vnfpool] New Charter for Toronto

Hi,

Be goode,

Dr Diego R. Lopez
Telefonica I+D

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