Subject: Re: [Nfvrg] NFVRG draft Policy Arch and Framework for NFV Infrastructures

From: <[email-masked]>
Date: Fri, 9 Oct 2015 15:36:56 -0500

Thanks Bruno and Norival. Copying nfvrg.

Thanks,
Ramki

From: Norival Figueira [mailto:[email-masked]]
Sent: Friday, October 09, 2015 1:35 PM
To: [email-masked]
Cc: Krishnan, Ramki; 'DIEGO LOPEZ GARCIA'
Subject: RE: NFVRG draft Policy Arch and Framework for NFV Infrastructures

Hi Bruno,

Thank you for taking the time to review the draft. Your comments are highly appreciated. Please see my proposed fixes below.

The wording of the 1st paragraph suggests that the service policy received by the OSS/BSS ("multipoint Silver Ethernet service between vPoPs A, B, and C for customer Z") is propagated unchanged to the VIM (and presumably to the VNFMs) through the NFVO. Is it a correct interpretation of your text?

If the answer is yes, it sounds like a big departure from the ETSI NFV architectural framework. For example, I would not expect the "silver" indication to be propagated to the NFVO and VIMs. I would rather expect the OSS to translate "silver" into a Network Service (NS) Flavour ID and then use this Flavour ID in the NS instantiation request sent to the NFVO. I would then expect the NFVO to derive QoS parameters and placement constraints for virtual links based on both the contents of the NSD descriptor (more precisely the part of the NSD that is related to the selected flavor) and on (semi) static operator's policy data (e.g. energy saving policy).

NF: The OSS/BSS, NFVO, VNFM and other components of the architecture would form a policy hierarchy (refer to Figure 5: "Pub/Sub Bus - Hierarchy Policy Framework") where each pub/sub bus level in the policy hierarchy would define its own local "name space". The last two paragraphs of Section 8.1 include a discussion on name spaces. As you correctly pointed out, the policy name space between the OSS/BSS and the NFVO would not define a "silver service" level. The OSS/BSS would translate the "silver service" level to an appropriate policy using the defined name space between the OSS/BSS and NFVO, e.g., Network Service (NS) Flavour ID instead of "silver service". I will update Section 8.1 to indicate that appropriate name space translations would be performed.

Moreover, in the 3rd paragraph you provide the following example "Silver service type, as specified in the policy, may translate in vPoP A to use a specific vCPE VNF type, say vCPE_X, while Silver service type in vPoP B may translate to a different vCPE VNF type, say vCPE_Y, due to local subsystem configurations".

I assume that this translation is performed by the VIM, since you indicate at the end of the 2Nd paragraph that in this example there is no NFVO in the PoPs. This seems to conflict with the fundamental principle that, unlike the NFVO and the VNFMs, the VIM does not have any knowledge about the VNFs. It does not know that a particular set of VMs belong to one VNF or the other.

NF: Thanks for catching this inconsistency. To keep with the original intent of that paragraph, which is to discuss the local interpretation/translation of policies based on local resource constraints and availability, I believe that the easiest fix is to add an NFVO to each vPoP in this example and make the necessary updates to the text (including updates to reflect the fact that the policy sent to the vPoP would use the appropriate name space at that level of the policy hierarchy).

Please let me know if these proposed fixes would address the issues you pointed out in section 8.1.

Again, thanks for reviewing the draft and for providing valuable comments!

Thanks,
Norival

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Thursday, October 08, 2015 1:07 AM
To: Norival Figueira
Cc: [email-masked]<mailto:[email-masked]>; 'DIEGO LOPEZ GARCIA'
Subject: RE: NFVRG draft Policy Arch and Framework for NFV Infrastructures

Hi Norival,

Sorry for the delay. I have been busy with man other items since I'm back from vacation...

I tried to understand the example you provide in clause 8.1 and have a couple of comments.

The wording of the 1st paragraph suggests that the service policy received by the OSS/BSS ("multipoint Silver Ethernet service between vPoPs A, B, and C for customer Z") is propagated unchanged to the VIM (and presumably to the VNFMs) through the NFVO. Is it a correct interpretation of your text?

If the answer is yes, it sounds like a big departure from the ETSI NFV architectural framework. For example, I would not expect the "silver" indication to be propagated to the NFVO and VIMs. I would rather expect the OSS to translate "silver" into a Network Service (NS) Flavour ID and then use this Flavour ID in the NS instantiation request sent to the NFVO. I would then expect the NFVO to derive QoS parameters and placement constraints for virtual links based on both the contents of the NSD descriptor (more precisely the part of the NSD that is related to the selected flavor) and on (semi) static operator's policy data (e.g. energy saving policy).

Moreover, in the 3rd paragraph you provide the following example "Silver service type, as specified in the policy, may translate in vPoP A to use a specific vCPE VNF type, say vCPE_X, while Silver service type in vPoP B may translate to a different vCPE VNF type, say vCPE_Y, due to local subsystem configurations".

I assume that this translation is performed by the VIM, since you indicate at the end of the 2Nd paragraph that in this example there is no NFVO in the PoPs. This seems to conflict with the fundamental principle that, unlike the NFVO and the VNFMs, the VIM does not have any knowledge about the VNFs. It does not know that a particular set of VMs belong to one VNF or the other.

Best Regards,
Bruno

De : Norival Figueira [mailto:[email-masked]]
Envoyé : samedi 3 octobre 2015 02:31
À : CHATRAS Bruno IMT/OLN
Cc : [email-masked]<mailto:[email-masked]>
Objet : RE: NFVRG draft Policy Arch and Framework for NFV Infrastructures

Hi Bruno,

Please let us know if you have any comments or suggestions for improvement for our NVFRG draft: "Policy Architecture and Framework for NFV Infrastructures". The deadline for draft updates for IETF 94 in Yokohama is approaching.

"Policy Architecture and Framework for NFV Infrastructures"
https://datatracker.ietf.org/doc/draft-irtf-nfvrg-nfv-policy-arch/

Regards,
Norival

From: Norival Figueira
Sent: Tuesday, September 01, 2015 11:18 AM
To: [email-masked]'
Subject: RE: NFVRG draft Policy Arch and Framework for NFV Infrastructures

Hi Bruno,

No hurry. Take your time.

Thanks,
Norival

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Tuesday, September 01, 2015 10:52 AM
To: Norival Figueira
Subject: RE: NFVRG draft Policy Arch and Framework for NFV Infrastructures

Hi Norival,

I'm just back from vacation with many urgent things to manage. I'll provide comments as soon as I can.

Best Regards,
Bruno

De : Norival Figueira [mailto:[email-masked]]
Envoyé : mardi 1 septembre 2015 02:13
À : CHATRAS Bruno IMT/OLN
Objet : NFVRG draft Policy Arch and Framework for NFV Infrastructures

Hi Bruno,

Diego Lopes told me at the NFV#11 meeting in San Jose that I should connect with you to request your comments regarding our NVFRG draft: "Policy Architecture and Framework for NFV Infrastructures". Unfortunately, I was not able to meet you at NFV#11. Please let us know if you have any comments or suggestions for improvement. Any feedback you can provide will be valuable and appreciated.

"Policy Architecture and Framework for NFV Infrastructures"
https://datatracker.ietf.org/doc/draft-irtf-nfvrg-nfv-policy-arch/

Best regards,
Norival

Norival Figueira
Office of the CTO
Brocade

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.

---

From: Norival Figueira <[email-masked]>
Date: Tue, 20 Oct 2015 01:48:22 +0000

Hi Bruno,

An updated draft was uploaded to address the proposed fixes described below.

Please refer to: draft-irtf-nfvrg-nfv-policy-arch-02
https://datatracker.ietf.org/doc/draft-irtf-nfvrg-nfv-policy-arch/

Regards,
Norival

From: [email-masked] [mailto:[email-masked]]
Sent: Friday, October 09, 2015 1:37 PM
To: Norival Figueira; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: NFVRG draft Policy Arch and Framework for NFV Infrastructures

Thanks,
Ramki

To: [email-masked]<mailto:[email-masked]>

Hi Bruno,

Thanks,
Norival

Hi Norival,

Best Regards,
Bruno

Hi Bruno,

Regards,
Norival

From: Norival Figueira

Hi Bruno,

Thanks,
Norival

Hi Norival,

Best Regards,
Bruno

Hi Bruno,

Best regards,
Norival

Norival Figueira
Office of the CTO
Brocade

Thank you.

Thank you.