[vnfpool] New revision of VNFPool Problem Statement posted

[Zongning]

Hi, folks,

The new revision (-04) of VNFPool Problem Statement I-D is available on the below page.
https://datatracker.ietf.org/doc/draft-zong-vnfpool-problem-statement/

Here are the major changes:

1) Clarify VNFPool architecture and intended scope.

1. Add new section of VNF Pools before the section of Problem. This new section is mainly to outline our scope based on high level description of VNF Pools architecture.

2. Add text to clarify that we are specifically concerned with reliability (e.g. redundancy model, state sharing) that is managed inside the VNF. We are only concerned with the whole VNF set (or forwarding graph) to the extent that it involves reliability impact on adjacent instances of different VNFs.

3. We focus on reliability mechanisms based on VNF pool. Other VNF management aspects such as scaling, load balancing are out of scope.

2) Update terminologies to define Service Control Entity, and delete Pool User as the pool will be internal to VNF only.

3) Re-arrange the text in section of Problems.

4) Update text of VNF instance performance degradation in section of Problems.

5) Update text of Reliable Transport in section of Problems.

6) Add text to explain why service availability is not in scope in section of Problems.

7) Re-write the section describing the relationship of VNFPool and SFC.

8) Add text of transfer of security states in section of Security Consideration.

We hope that the changes have addressed most of the comments, and reflected most of the suggestions during London BoF.

Please review this new revision. Your further comments and suggestions are highly appreciated!

Thanks.

-Ning

[PEDRO ANDRES ARANDA GUTIERREZ]

Reading through the ID, I have found some typos:

s/How is the service states/How are the service states/g
s/how do an adjacent VNF instance/how does an adjacent VNF instance/g
s/For a VNF instance, it typically would not have built-in reliability/A VNF instance would typically not have built-in reliability/g

A mail with requests for clarification will follow.

Thx,
BR,/PA
Dr. Pedro A. Aranda Gutiérrez

Technology Exploration -
Network Innovation & Virtualisation

mailto:***@tid.es
Telefónica, Investigación y Desarrollo
C/ D. Ramón de la Cruz,84
28006 Madrid, Spain

Fragen sind nicht da, um beantwortet zu werden.
Fragen sind da, um gestellt zu werden.
Georg Kreisler

De: Zongning <***@huawei.com<mailto:***@huawei.com>>
Fecha: jueves, 10 de abril de 2014 05:21
Para: "***@ietf.org<mailto:***@ietf.org>" <***@ietf.org<mailto:***@ietf.org>>
Asunto: [vnfpool] New revision of VNFPool Problem Statement posted

Hi, folks,

The new revision (-04) of VNFPool Problem Statement I-D is available on the below page.
https://datatracker.ietf.org/doc/draft-zong-vnfpool-problem-statement/

Here are the major changes:

1) Clarify VNFPool architecture and intended scope.

1. Add new section of VNF Pools before the section of Problem. This new section is mainly to outline our scope based on high level description of VNF Pools architecture.

2. Add text to clarify that we are specifically concerned with reliability (e.g. redundancy model, state sharing) that is managed inside the VNF. We are only concerned with the whole VNF set (or forwarding graph) to the extent that it involves reliability impact on adjacent instances of different VNFs.

3. We focus on reliability mechanisms based on VNF pool. Other VNF management aspects such as scaling, load balancing are out of scope.

2) Update terminologies to define Service Control Entity, and delete Pool User as the pool will be internal to VNF only.

3) Re-arrange the text in section of Problems.

4) Update text of VNF instance performance degradation in section of Problems.

5) Update text of Reliable Transport in section of Problems.

6) Add text to explain why service availability is not in scope in section of Problems.

7) Re-write the section describing the relationship of VNFPool and SFC.

8) Add text of transfer of security states in section of Security Consideration.

We hope that the changes have addressed most of the comments, and reflected most of the suggestions during London BoF.

Please review this new revision. Your further comments and suggestions are highly appreciated!

Thanks.

-Ning

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

[Zongning]

Hi, Pedro.

Thanks for pointing out the typos.

I assume that some co-authors of use cases (including you :)) are working on a new set of Use Case I-Ds. So please make sure that we keep aligned with each other very well. For example, in new PS I-D:

1) Terminologies: NF -> (virtualization) -> VNF -> (instantiation)-> VNF instance -> (a group of VNF instances) -> VNF set -> (use pooling idea)-> VNF Pools (including Pool Element, Pool Manager)

2) Scope: please refer to my previous list message of new revision notification.

Hope these would help!

-Ning


·¢ŒþÈË: PEDRO ANDRES ARANDA GUTIERREZ [mailto:***@tid.es]
·¢ËÍʱŒä: 2014Äê4ÔÂ10ÈÕ 16:14
ÊÕŒþÈË: Zongning; ***@ietf.org
Ö÷Ìâ: Re: [vnfpool] New revision of VNFPool Problem Statement posted

Reading through the ID, I have found some typos:

s/How is the service states/How are the service states/g
s/how do an adjacent VNF instance/how does an adjacent VNF instance/g
s/For a VNF instance, it typically would not have built-in reliability/A VNF instance would typically not have built-in reliability/g

A mail with requests for clarification will follow.

Thx,
BR,/PA
Dr. Pedro A. Aranda GutišŠrrez

Technology Exploration -
Network Innovation & Virtualisation

mailto:***@tid.es
Telefš®nica, Investigaciš®n y Desarrollo
C/ D. Ramš®n de la Cruz,84
28006 Madrid, Spain

Fragen sind nicht da, um beantwortet zu werden.
Fragen sind da, um gestellt zu werden.
Georg Kreisler

De: Zongning <***@huawei.com<mailto:***@huawei.com>>
Fecha: jueves, 10 de abril de 2014 05:21
Para: "***@ietf.org<mailto:***@ietf.org>" <***@ietf.org<mailto:***@ietf.org>>
Asunto: [vnfpool] New revision of VNFPool Problem Statement posted

Hi, folks,

The new revision (-04) of VNFPool Problem Statement I-D is available on the below page.
https://datatracker.ietf.org/doc/draft-zong-vnfpool-problem-statement/

Here are the major changes:

1) Clarify VNFPool architecture and intended scope.

1. Add new section of VNF Pools before the section of Problem. This new section is mainly to outline our scope based on high level description of VNF Pools architecture.

2. Add text to clarify that we are specifically concerned with reliability (e.g. redundancy model, state sharing) that is managed inside the VNF. We are only concerned with the whole VNF set (or forwarding graph) to the extent that it involves reliability impact on adjacent instances of different VNFs.

3. We focus on reliability mechanisms based on VNF pool. Other VNF management aspects such as scaling, load balancing are out of scope.

2) Update terminologies to define Service Control Entity, and delete Pool User as the pool will be internal to VNF only.

3) Re-arrange the text in section of Problems.

4) Update text of VNF instance performance degradation in section of Problems.

5) Update text of Reliable Transport in section of Problems.

6) Add text to explain why service availability is not in scope in section of Problems.

7) Re-write the section describing the relationship of VNFPool and SFC.

8) Add text of transfer of security states in section of Security Consideration.

We hope that the changes have addressed most of the comments, and reflected most of the suggestions during London BoF.

Please review this new revision. Your further comments and suggestions are highly appreciated!

Thanks.

-Ning

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra polšªtica de envšªo y recepciš®n de correo electrš®nico en el enlace situado mš¢s abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

[Zu Qiang]

Hello, Zongning
Thanks for updating the draft. I do see this version is much better than the previous version. I have a few clarification questions below:

- First, there are some existing HA solutions. Can you tell me what is the extra functionalities provided by the VNF Pool? Or the VNF Pool is only another alternative solution? Or are we going to use the existing HA solutions as inputs only?

- Second, in the early version, you have the interactions between the Pool Managers of different pools and between the Pool Functions of different pools specified, which is removed in this version. Do you see that type of interactions are still needed? And why it is needed?

- 3rd, the VNF set is a new concept. What is the linkage with the proposed VNF Pool architecture?

- 4th, RSerPool is referred by your draft. I assume that VNF Pool will not reused the RSerPool unchanged. So which part of RSerPool can be reused by VNF Pool?
Thanks.
Have a nice day
Zu Qiang

From: vnfpool [mailto:vnfpool-***@ietf.org] On Behalf Of Zongning
Sent: Wednesday, April 09, 2014 11:22 PM
To: ***@ietf.org
Subject: [vnfpool] New revision of VNFPool Problem Statement posted

Hi, folks,

The new revision (-04) of VNFPool Problem Statement I-D is available on the below page.
https://datatracker.ietf.org/doc/draft-zong-vnfpool-problem-statement/

Here are the major changes:

1) Clarify VNFPool architecture and intended scope.

1. Add new section of VNF Pools before the section of Problem. This new section is mainly to outline our scope based on high level description of VNF Pools architecture.

2. Add text to clarify that we are specifically concerned with reliability (e.g. redundancy model, state sharing) that is managed inside the VNF. We are only concerned with the whole VNF set (or forwarding graph) to the extent that it involves reliability impact on adjacent instances of different VNFs.

3. We focus on reliability mechanisms based on VNF pool. Other VNF management aspects such as scaling, load balancing are out of scope.

2) Update terminologies to define Service Control Entity, and delete Pool User as the pool will be internal to VNF only.

3) Re-arrange the text in section of Problems.

4) Update text of VNF instance performance degradation in section of Problems.

5) Update text of Reliable Transport in section of Problems.

6) Add text to explain why service availability is not in scope in section of Problems.

7) Re-write the section describing the relationship of VNFPool and SFC.

8) Add text of transfer of security states in section of Security Consideration.

We hope that the changes have addressed most of the comments, and reflected most of the suggestions during London BoF.

Please review this new revision. Your further comments and suggestions are highly appreciated!

Thanks.

-Ning

[Zongning]

Hi, Qiang,

Please see inline.


·¢ŒþÈË: Zu Qiang [mailto:***@ericsson.com]
·¢ËÍʱŒä: 2014Äê4ÔÂ17ÈÕ 2:13
ÊÕŒþÈË: Zongning; ***@ietf.org
Ö÷Ìâ: RE: New revision of VNFPool Problem Statement posted

Hello, Zongning
Thanks for updating the draft. I do see this version is much better than the previous version. I have a few clarification questions below:

- First, there are some existing HA solutions. Can you tell me what is the extra functionalities provided by the VNF Pool? Or the VNF Pool is only another alternative solution? Or are we going to use the existing HA solutions as inputs only?

[Ning] For sure there are existing HA solutions. For example, the SAF is about Service Availability mechanisms. I agree that there are definitely many pieces of existing work can be investigated as the basis of VNF Pool, e.g. redundancy model, state sharing. I think the extra work needed in VNF Pool is to address specific requirements on VNF failover procedure, VNF state sharing, etc. This will depend on further use case and gap analysis.


- Second, in the early version, you have the interactions between the Pool Managers of different pools and between the Pool Functions of different pools specified, which is removed in this version. Do you see that type of interactions are still needed? And why it is needed?

[Ning] Yes, I do think those interactions are still needed. But I prefer an VNF Pool architecture document to describe them, rather than Problem Statement draft.


- 3rd, the VNF set is a new concept. What is the linkage with the proposed VNF Pool architecture?

[Ning] VNF set is just a general set of all the VNF instances. In VNF Pool architecture, these VNF instances are actually grouped into multiple pools, based on the functions they provided. For example, a VNF set {vFW#1, vFW#2, vLB#1, vLB#2, vLB#3} can be organized as two VNF pools šC one pool is {vFW#1, vFW#2}, another is {vLB#1, vLB#2, vLB#3}. I will try to enhance this in the draft later on.


- 4th, RSerPool is referred by your draft. I assume that VNF Pool will not reused the RSerPool unchanged. So which part of RSerPool can be reused by VNF Pool?

[Ning] Yes, we believe some mechanisms introduced by RSerPool can be extended and reused, such as PE registration, pool handle resolution and response. We have a RSerPool applicability and gap analysis draft dedicated on this perspective.


Thanks.
Have a nice day
Zu Qiang

From: vnfpool [mailto:vnfpool-***@ietf.org] On Behalf Of Zongning
Sent: Wednesday, April 09, 2014 11:22 PM
To: ***@ietf.org<mailto:***@ietf.org>
Subject: [vnfpool] New revision of VNFPool Problem Statement posted

Hi, folks,

The new revision (-04) of VNFPool Problem Statement I-D is available on the below page.
https://datatracker.ietf.org/doc/draft-zong-vnfpool-problem-statement/

Here are the major changes:

1) Clarify VNFPool architecture and intended scope.

1. Add new section of VNF Pools before the section of Problem. This new section is mainly to outline our scope based on high level description of VNF Pools architecture.

2. Add text to clarify that we are specifically concerned with reliability (e.g. redundancy model, state sharing) that is managed inside the VNF. We are only concerned with the whole VNF set (or forwarding graph) to the extent that it involves reliability impact on adjacent instances of different VNFs.

3. We focus on reliability mechanisms based on VNF pool. Other VNF management aspects such as scaling, load balancing are out of scope.

2) Update terminologies to define Service Control Entity, and delete Pool User as the pool will be internal to VNF only.

3) Re-arrange the text in section of Problems.

4) Update text of VNF instance performance degradation in section of Problems.

5) Update text of Reliable Transport in section of Problems.

6) Add text to explain why service availability is not in scope in section of Problems.

7) Re-write the section describing the relationship of VNFPool and SFC.

8) Add text of transfer of security states in section of Security Consideration.

We hope that the changes have addressed most of the comments, and reflected most of the suggestions during London BoF.

Please review this new revision. Your further comments and suggestions are highly appreciated!

Thanks.

-Ning

[Zu Qiang]

Hello, Zongning
Thanks for your response. Can you give a use case of ¡°the interactions between the Pool Managers of different pools and between the Pool Functions of different¡±? and a use case of ¡°VNF set¡±?

Have a nice day
Zu Qiang

From: Zongning [mailto:***@huawei.com]
Sent: Wednesday, April 16, 2014 11:45 PM
To: Zu Qiang; ***@ietf.org
Subject: ŽðžŽ: New revision of VNFPool Problem Statement posted

Hi, Qiang,

Please see inline.


·¢ŒþÈË: Zu Qiang [mailto:***@ericsson.com]
·¢ËÍʱŒä: 2014Äê4ÔÂ17ÈÕ 2:13
ÊÕŒþÈË: Zongning; ***@ietf.org<mailto:***@ietf.org>
Ö÷Ìâ: RE: New revision of VNFPool Problem Statement posted

Hello, Zongning
Thanks for updating the draft. I do see this version is much better than the previous version. I have a few clarification questions below:

- First, there are some existing HA solutions. Can you tell me what is the extra functionalities provided by the VNF Pool? Or the VNF Pool is only another alternative solution? Or are we going to use the existing HA solutions as inputs only?

[Ning] For sure there are existing HA solutions. For example, the SAF is about Service Availability mechanisms. I agree that there are definitely many pieces of existing work can be investigated as the basis of VNF Pool, e.g. redundancy model, state sharing. I think the extra work needed in VNF Pool is to address specific requirements on VNF failover procedure, VNF state sharing, etc. This will depend on further use case and gap analysis.


- Second, in the early version, you have the interactions between the Pool Managers of different pools and between the Pool Functions of different pools specified, which is removed in this version. Do you see that type of interactions are still needed? And why it is needed?

[Ning] Yes, I do think those interactions are still needed. But I prefer an VNF Pool architecture document to describe them, rather than Problem Statement draft.


- 3rd, the VNF set is a new concept. What is the linkage with the proposed VNF Pool architecture?

[Ning] VNF set is just a general set of all the VNF instances. In VNF Pool architecture, these VNF instances are actually grouped into multiple pools, based on the functions they provided. For example, a VNF set {vFW#1, vFW#2, vLB#1, vLB#2, vLB#3} can be organized as two VNF pools šC one pool is {vFW#1, vFW#2}, another is {vLB#1, vLB#2, vLB#3}. I will try to enhance this in the draft later on.


- 4th, RSerPool is referred by your draft. I assume that VNF Pool will not reused the RSerPool unchanged. So which part of RSerPool can be reused by VNF Pool?

[Ning] Yes, we believe some mechanisms introduced by RSerPool can be extended and reused, such as PE registration, pool handle resolution and response. We have a RSerPool applicability and gap analysis draft dedicated on this perspective.


Thanks.
Have a nice day
Zu Qiang

From: vnfpool [mailto:vnfpool-***@ietf.org] On Behalf Of Zongning
Sent: Wednesday, April 09, 2014 11:22 PM
To: ***@ietf.org<mailto:***@ietf.org>
Subject: [vnfpool] New revision of VNFPool Problem Statement posted

Hi, folks,

The new revision (-04) of VNFPool Problem Statement I-D is available on the below page.
https://datatracker.ietf.org/doc/draft-zong-vnfpool-problem-statement/

Here are the major changes:

1) Clarify VNFPool architecture and intended scope.

1. Add new section of VNF Pools before the section of Problem. This new section is mainly to outline our scope based on high level description of VNF Pools architecture.

2. Add text to clarify that we are specifically concerned with reliability (e.g. redundancy model, state sharing) that is managed inside the VNF. We are only concerned with the whole VNF set (or forwarding graph) to the extent that it involves reliability impact on adjacent instances of different VNFs.

3. We focus on reliability mechanisms based on VNF pool. Other VNF management aspects such as scaling, load balancing are out of scope.

2) Update terminologies to define Service Control Entity, and delete Pool User as the pool will be internal to VNF only.

3) Re-arrange the text in section of Problems.

4) Update text of VNF instance performance degradation in section of Problems.

5) Update text of Reliable Transport in section of Problems.

6) Add text to explain why service availability is not in scope in section of Problems.

7) Re-write the section describing the relationship of VNFPool and SFC.

8) Add text of transfer of security states in section of Security Consideration.

We hope that the changes have addressed most of the comments, and reflected most of the suggestions during London BoF.

Please review this new revision. Your further comments and suggestions are highly appreciated!

Thanks.

-Ning

[Zongning]

Hi, Qiang,

I¡¯d prefer to leave these questions to the co-authors of Use Case I-Ds. :)
I remember that we have a case of multi-tier service where data connections are directly between pool elements of different pools. Also in RSerPool, a pool element can announce its backup elements to the pool users via business card. The interaction between pool managers can be used for pooling information / status enquiry, and so on. Anyway, I think the details can be in the Use Case I-Ds.

Thanks.

-Ning

·¢ŒþÈË: Zu Qiang [mailto:***@ericsson.com]
·¢ËÍʱŒä: 2014Äê4ÔÂ21ÈÕ 21:10
ÊÕŒþÈË: Zongning; ***@ietf.org
Ö÷Ìâ: RE: New revision of VNFPool Problem Statement posted

Hello, Zongning
Thanks for your response. Can you give a use case of ¡°the interactions between the Pool Managers of different pools and between the Pool Functions of different¡±? and a use case of ¡°VNF set¡±?

Have a nice day
Zu Qiang

From: Zongning [mailto:***@huawei.com]
Sent: Wednesday, April 16, 2014 11:45 PM
To: Zu Qiang; ***@ietf.org<mailto:***@ietf.org>
Subject: ŽðžŽ: New revision of VNFPool Problem Statement posted

Hi, Qiang,

Please see inline.


·¢ŒþÈË: Zu Qiang [mailto:***@ericsson.com]
·¢ËÍʱŒä: 2014Äê4ÔÂ17ÈÕ 2:13
ÊÕŒþÈË: Zongning; ***@ietf.org<mailto:***@ietf.org>
Ö÷Ìâ: RE: New revision of VNFPool Problem Statement posted

Hello, Zongning
Thanks for updating the draft. I do see this version is much better than the previous version. I have a few clarification questions below:

- First, there are some existing HA solutions. Can you tell me what is the extra functionalities provided by the VNF Pool? Or the VNF Pool is only another alternative solution? Or are we going to use the existing HA solutions as inputs only?

[Ning] For sure there are existing HA solutions. For example, the SAF is about Service Availability mechanisms. I agree that there are definitely many pieces of existing work can be investigated as the basis of VNF Pool, e.g. redundancy model, state sharing. I think the extra work needed in VNF Pool is to address specific requirements on VNF failover procedure, VNF state sharing, etc. This will depend on further use case and gap analysis.


- Second, in the early version, you have the interactions between the Pool Managers of different pools and between the Pool Functions of different pools specified, which is removed in this version. Do you see that type of interactions are still needed? And why it is needed?

[Ning] Yes, I do think those interactions are still needed. But I prefer an VNF Pool architecture document to describe them, rather than Problem Statement draft.


- 3rd, the VNF set is a new concept. What is the linkage with the proposed VNF Pool architecture?

[Ning] VNF set is just a general set of all the VNF instances. In VNF Pool architecture, these VNF instances are actually grouped into multiple pools, based on the functions they provided. For example, a VNF set {vFW#1, vFW#2, vLB#1, vLB#2, vLB#3} can be organized as two VNF pools šC one pool is {vFW#1, vFW#2}, another is {vLB#1, vLB#2, vLB#3}. I will try to enhance this in the draft later on.


- 4th, RSerPool is referred by your draft. I assume that VNF Pool will not reused the RSerPool unchanged. So which part of RSerPool can be reused by VNF Pool?

[Ning] Yes, we believe some mechanisms introduced by RSerPool can be extended and reused, such as PE registration, pool handle resolution and response. We have a RSerPool applicability and gap analysis draft dedicated on this perspective.


Thanks.
Have a nice day
Zu Qiang

From: vnfpool [mailto:vnfpool-***@ietf.org] On Behalf Of Zongning
Sent: Wednesday, April 09, 2014 11:22 PM
To: ***@ietf.org<mailto:***@ietf.org>
Subject: [vnfpool] New revision of VNFPool Problem Statement posted

Hi, folks,

The new revision (-04) of VNFPool Problem Statement I-D is available on the below page.
https://datatracker.ietf.org/doc/draft-zong-vnfpool-problem-statement/

Here are the major changes:

1) Clarify VNFPool architecture and intended scope.

1. Add new section of VNF Pools before the section of Problem. This new section is mainly to outline our scope based on high level description of VNF Pools architecture.

2. Add text to clarify that we are specifically concerned with reliability (e.g. redundancy model, state sharing) that is managed inside the VNF. We are only concerned with the whole VNF set (or forwarding graph) to the extent that it involves reliability impact on adjacent instances of different VNFs.

3. We focus on reliability mechanisms based on VNF pool. Other VNF management aspects such as scaling, load balancing are out of scope.

2) Update terminologies to define Service Control Entity, and delete Pool User as the pool will be internal to VNF only.

3) Re-arrange the text in section of Problems.

4) Update text of VNF instance performance degradation in section of Problems.

5) Update text of Reliable Transport in section of Problems.

6) Add text to explain why service availability is not in scope in section of Problems.

7) Re-write the section describing the relationship of VNFPool and SFC.

8) Add text of transfer of security states in section of Security Consideration.

We hope that the changes have addressed most of the comments, and reflected most of the suggestions during London BoF.

Please review this new revision. Your further comments and suggestions are highly appreciated!

Thanks.

-Ning