Subject: [Supa] questions concerning draft-norival-nfvrg-nfv-policy-arch

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 1 Apr 2015 18:16:37 +0200

Hi,

having followed your presentation, I have a few questions:

1) In which format is policy communicated from the global level down
   to the subsystems? How do you make sure policy is understood by all
   parties involved in the same way?

2) Where is policy interpretation and refinement taking place? Is the
   global level just a collection of declarative predicates that are
   essentially sent to the subsystems for interpretation? Or is the
   global level producing any active subsystem specific interpretation
   or refinement of the generic policy input? In other words, is the
   global level mainly a repository or an active policy interpretation
   component?

3) Policy conflict detection and resolution is tricky. There are many
   different cases, a few ones that come to mind immediately:

   - conflict in global policy
   - conflict of global policy with local policy
   - conflict of global or local policy with resources available
   - no policy conflicts and policy that leads to instability

   There may be more. But these different types of policy conflicts
   may need different procedures for resolution. In fact, resolution
   may be policy driven itself. If we talk about a distributed
   hierarchical approach, we in addition get into rollback semantics.
   Is there a clear idea how this is going to work?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Norival Figueira <[email-masked]>
Date: Tue, 14 Apr 2015 22:11:46 +0000

Hi Juergen,

My apologies for the delayed response to your message. I was on a business trip flowed by short vacation with very limited access to my email.

>   parties involved in the same way?

The draft proposes use of a pub/sub bus for policy engines to communicate policies to lower and higher level policy engines in the hierarchy. Policies to be defined as high level "intent" using (implementation/configuration/technology agnostic/independent) information/data models, since the policy framework must cover multiple subsystem types, e.g., networking, storage, compute, and etc. For example, "User" and "Platinum" in the policy "give User X Platinum treatment" would be translated at each subsystem to something meaningful to the subsystem. For the compute subsystem, this could mean that all VMs belonging to user X would receive Platinum treatment, where what "Platinum" is translated to locally (as a configuration) is defined locally. How translations are defined is more an implementation detail. Subsystems could be manually configured with appropriate local translations or they could be configured from a central repository. The proposed architecture decouples translations (which represent local technology-dependent configurations) from the actual policies/intents, allowing translations to be modified without requiring policies to be modified, and vice versa. Consider, for example, a same high-level policy/intent being translated by one networking subsystem to an MPLS configuration and by another networking subsystem to a set of OpenFlow flows. By decoupling subsystem translation from policy/indent, the words "User" and "Platinum" above have no pre-defined implicit meanings for the policy engines.

>   global level mainly a repository or an active policy interpretation

Please refer to the response to question 1 above.

>   Is there a clear idea how this is going to work?

The subject of conflict detection is addressed by the existing draft and will be further improved in subsequent updates. Is see rollback as an example of a particular implementation to address specific issues. Alternatively, an implementation could check all policies in a defined "group" for potential conflicts with already committed/applied policies before committing/applying any policies in the group. This could eliminate the need for a rollback, since polices in a group would be either all in or out. Policies could be declared as part of a same "group" when the failure to commit one of the policies in the group (e.g., due to a conflict) would prevent the other policies in the group from being committed/applied. While the framework should discuss implementation options like these, it should not mandate the implementation of any particular one. Rollback is an implementation option that can support policy batch files. Use of "group" definitions along with batch files would be an implementation option to eliminate the need for rollbacks. In fact, an implementation not allowing policy batch files would be another option that could eliminate the need for rollbacks. There could be other examples or use cases not mentioned here that could require rollback. We plan to add more discussions on these topics to future revisions of the draft (and we will acknowledge this helpful discussions).

Best regards,
Norival

=================
Norival Figueira
Office of the CTO, Brocade
[email-masked]

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Wednesday, April 01, 2015 9:17 AM
To: Norival Figueira; [email-masked]
Subject: questions concerning draft-norival-nfvrg-nfv-policy-arch

Hi,

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 15 Apr 2015 23:46:17 +0200

Thanks.

My first question was about the notation or syntax that you plan to
use to communicate policy from the global level down to the
subsystems. I guess it won't be English prose such as "give User X
Platinum treatment".

/js

---

From: Norival Figueira <[email-masked]>
Date: Thu, 16 Apr 2015 21:40:59 +0000

Hi Juergen,

Your guess is correct, that is, it will not be English prose.

Regards,
Norival

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Wednesday, April 15, 2015 2:46 PM
To: Norival Figueira
Cc: [email-masked]; [email-masked]; DIEGO LOPEZ GARCIA
Subject: Re: questions concerning draft-norival-nfvrg-nfv-policy-arch

Thanks.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 17 Apr 2015 00:02:09 +0200

And the plan is?

/js

On Thu, Apr 16, 2015 at 09:40:59PM +0000, Norival Figueira wrote:
> > The draft proposes use of a pub/sub bus for policy engines to communicate policies to lower and higher level policy engines in the hierarchy. Policies to be defined as high level "intent" using (implementation/configuration/technology agnostic/independent) information/data models, since the policy framework must cover multiple subsystem types, e.g., networking, storage, compute, and etc. For example, "User" and "Platinum" in the policy "give User X Platinum treatment" would be translated at each subsystem to something meaningful to the subsystem. For the compute subsystem, this could mean that all VMs belonging to user X would receive Platinum treatment, where what "Platinum" is translated to locally (as a configuration) is defined locally. How translations are defined is more an implementation detail. Subsystems could be manually configured with appropriate local translations or they could be configured from a central repository. The proposed architecture decouples translations (w
>  hich represent local technology-dependent configurations) from the actual policies/intents, allowing translations to be modified without requiring policies to be modified, and vice versa. Consider, for example, a same high-level policy/intent being translated by one networking subsystem to an MPLS configuration and by another networking subsystem to a set of OpenFlow flows. By decoupling subsystem translation from policy/indent, the words "User" and "Platinum" above have no pre-defined implicit meanings for the policy engines.
> > 
> > The subject of conflict detection is addressed by the existing draft and will be further improved in subsequent updates. Is see rollback as an example of a particular implementation to address specific issues. Alternatively, an implementation could check all policies in a defined "group" for potential conflicts with already committed/applied policies before committing/applying any policies in the group. This could eliminate the need for a rollback, since polices in a group would be either all in or out. Policies could be declared as part of a same "group" when the failure to commit one of the policies in the group (e.g., due to a conflict) would prevent the other policies in the group from being committed/applied. While the framework should discuss implementation options like these, it should not mandate the implementation of any particular one. Rollback is an implementation option that can support policy batch files. Use of "group" definitions along with batch files would be an im
>  plementation option to eliminate the need for rollbacks. In fact, an implementation not allowing policy batch files would be another option that could eliminate the need for rollbacks. There could be other examples or use cases not mentioned here that could require rollback. We plan to add more discussions on these topics to future revisions of the draft (and we will acknowledge this helpful discussions).
> > 
> > Best regards,
> > Norival
> > 
> > =================
> > Norival Figueira
> _______________________________________________
> Supa mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/supa

---

From: <[email-masked]>
Date: Thu, 16 Apr 2015 18:47:14 -0500

++ NFVRG since this is an interesting topic.

--
Thanks,
Ramki

-----Original Message-----
From: Norival Figueira [mailto:[email-masked]]
Sent: Thursday, April 16, 2015 2:41 PM
To: Juergen Schoenwaelder
Cc: [email-masked]; Krishnan, Ramki; DIEGO LOPEZ GARCIA
Subject: RE: questions concerning draft-norival-nfvrg-nfv-policy-arch

Hi Juergen,

Regards,
Norival

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]]
Sent: Wednesday, April 15, 2015 2:46 PM
To: Norival Figueira
Cc: [email-masked]; [email-masked]; DIEGO LOPEZ GARCIA
Subject: Re: questions concerning draft-norival-nfvrg-nfv-policy-arch

Thanks.

My first question was about the notation or syntax that you plan to use to communicate policy from the global level down to the subsystems. I guess it won't be English prose such as "give User X Platinum treatment".

/js

On Tue, Apr 14, 2015 at 10:11:46PM +0000, Norival Figueira wrote:
> From: Juergen Schoenwaelder
> [mailto:[email-masked]]
> Fax: +49 421 200 3103

Fax: +49 421 200 3103

---

From: <[email-masked]>
Date: Wed, 29 Apr 2015 22:18:52 -0500

Hi Juergen, Supa Team,

The scope of this document is policy framework. There are many possible implementations for various aspects of the policy framework such as policy communication syntax, and this is best described in separate information model/data model documents. We are looking forward to your contributions to NFVRG on the topic of info/data models for the policy framework (we have some ideas and would be glad to collaborate if your desire).

--
Thanks,
Ramki

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]]
Sent: Thursday, April 16, 2015 3:02 PM
To: Norival Figueira
Cc: Krishnan, Ramki; DIEGO LOPEZ GARCIA; [email-masked]
Subject: Re: [Supa] questions concerning draft-norival-nfvrg-nfv-policy-arch

And the plan is?

/js

On Thu, Apr 16, 2015 at 09:40:59PM +0000, Norival Figueira wrote:
> > The draft proposes use of a pub/sub bus for policy engines to
> > communicate policies to lower and higher level policy engines in the
> > hierarchy. Policies to be defined as high level "intent" using
> > (implementation/configuration/technology agnostic/independent)
> > information/data models, since the policy framework must cover
> > multiple subsystem types, e.g., networking, storage, compute, and
> > etc. For example, "User" and "Platinum" in the policy "give User X
> > Platinum treatment" would be translated at each subsystem to
> > something meaningful to the subsystem. For the compute subsystem,
> > this could mean that all VMs belonging to user X would receive
> > Platinum treatment, where what "Platinum" is translated to locally
> > (as a configuration) is defined locally. How translations are
> > defined is more an implementation detail. Subsystems could be
> > manually configured with appropriate local translations or they
> > could be configured from a central repository. The proposed
> > architecture decouples translations (w
> > The subject of conflict detection is addressed by the existing draft
> > and will be further improved in subsequent updates. Is see rollback
> > as an example of a particular implementation to address specific
> > issues. Alternatively, an implementation could check all policies in
> > a defined "group" for potential conflicts with already
> > committed/applied policies before committing/applying any policies
> > in the group. This could eliminate the need for a rollback, since
> > polices in a group would be either all in or out. Policies could be
> > declared as part of a same "group" when the failure to commit one of
> > the policies in the group (e.g., due to a conflict) would prevent
> > the other policies in the group from being committed/applied. While
> > the framework should discuss implementation options like these, it
> > should not mandate the implementation of any particular one.
> > Rollback is an implementation option that can support policy batch
> > files. Use of "group" definitions along with batch files would be an
> > im