Subject: [Supa] Supa notes for 4/1/2015

From: "Susan Hares" <[email-masked]>
Date: Thu, 2 Apr 2015 00:48:05 -0400

SUPA 4/1/2015 

Attendees: 

·         John Strassner (Huawei) 

·         Juergen Schoenwaelder  

·         Tina Tsou (Huawei) 

·         Georgeios Karagiannis Huawei)  

·         Sue Hares (Huawei) 

·         Will Liu 

·         Norival Figueira (Brocade) 

Policy Architecture and Framework for NFV infrastructure 

Co-authors: Norival Figueira (Brocade), Ram (Ramki) Krishnan (Dell), Diego
Lopez (Telefonica I+D) 

Discussion on draft-norival-nfvrg-nfv-policy-arch-02

http://www.ietf.org/proceedings/92/slides/slides-92-nfvrg-8.pdf

This section contains comments on the slides. 

·         Scope of the draft (slide 2 of  presentation) 

o    Not on policy models for configuration into subsystems, but policy
concepts used to enforce business rules and resources across all the
sub-systems (compute, storage, network, and others).   The subsystems may be
in “infrastructure domains”. 

·         Policy intent vs. Sub-systems configurations action (slide 4 of
the presentation) 

o    Policy specifies the intent and it does specify what it is translated
into 

o    Draft is not dealing with the translations or architecture within the
systems,

·         Global vs. local policies (slide 5) 

o    global policies can be expressed in the congress policies framework

·         Hierarchical policy frameworks (slide 6) 

o    Policy framework is hierarchical in nature.  Policy in the Data Center
tends to collect the data center into administrative domains. Group the
administrative domain in to a regions with one administrative leader.  

o    Hierarchy – SDN architecture in a multi-domain architecture (Norival
Figueira (Brocade) and Ramki Krishnan (Dell) published the policy paper in
February,

·         Policy Conflicts and Resolutions (slide 7) 

o    As new policy is added to a subsystem, its policy engine should perform
conflict checks. More complex conflicts may arise depending on how new
policies are entered (e.g. a manually vs. batched)

o    Note: Draft has a number of conflicts discussed.  

·         Discussion: 

o    John Strasser: You are talking in general about policy confederations
where the relationships are expressed hierarchy?  Can different hierarchies
talk to one another? 

o    Norival Figueira:   You can assume that an east-coast and west-coast
region with different policy hierarchies.  Each of these regions would
communicate to a bus within a region, and a cross-US region bus. 

o    John Strasser: Within the hierarchy in a basic federation, then the top
level of the hierarchy has a policy.  The lower levels enforce the policy,
and the lower levels can define additional policies as long 

o    Norival Figueira: The policy is distributed downward so the lower
systems can detect if the local policy conflicts with the higher level
policy.  You can have real-time addition of policies that are allocated with
the administrators.   Alternatively, policies can be defined as a batch.
For example, suppose the polices of a company’s headquarters define a
policies and send the policies as a batch to the lower policies.  If these
non-real time policies, impact the lower levels by creating conflict – the
lower level policies cannot resolve the conflict.  The lower levels then
send back up the hierarchy the conflict alert. In this way, the policies may
be resolved at different layers. The resolution can be defined over a set of
providers. 

o    John: Is this framework dealing with any type of policy rule or
intent-based policy? 

o    Norival Figueira: The purpose at this time is “intent” based as an
abstract definition. As you go higher in the hierarchy, the policy becomes
abstract – which is therefore “intent” policy.  If you go lower in the
hierarchy, it becomes less abstract. 

o    John: You would have a continuum of policies.  Would you have a
difference between ECA and intent?  ECA has a clear way to define the
conflict.  Intent will not be as simple to define the policy.  

o    Norival: If you define intent as a simple case, you can detect the
conflict.  You are not defining the details in intent that provide enough
details to detect the configuration.  Only with the configuration, can you
see the conflict.  

o    John: I disagree.  The more abstract a policy, the more ways you can
define the policy.  In contrast, the ECA policies are very specific.  In
intent two generic policies cannot easily be compared. I’m trying to lead
you to determine a more specific definition of intent.  You need some type
of lexicon as a bare minimum. 

o    Norival: For example, one network has 2 levels of next hop, and a
second network has 5 levels of network. The definition of platinum in two
systems is defined uniquely for both systems so that in each system can
configure the platinum services.  If you define platinum intent as specific
set of lexicon, you make it more difficult to de-couple the policy from the
network.  

o    John: I was not assuming that you were tightly coupled to technology.
If intent does not have a specific vocabulary, then how do you know if the
intent conflicts. It is not a mapping to technology, but an understanding of
what the actual intent is. 

o    Norival: I see your point.  I think the distinction between your point
and my point. You are seeing two requests entering into the system that
conflict.  For example, two network applications that expressing the intent
policies.  You are trying to resolve the multiple writers in one system.
You have different types of constraints.  We are looking across multiple
seasons. 

o    John: I do not think so. Maybe we should take this offline. 

·         John’s presentation:  (presentation at the IETF)

o    Policy overview 

§  We do have the concepts of a bus.  We do have the concept of conflict
resolution at local domains and across different domains.  

§  How do we send policies from one domain to another?   How do we do policy
model updates? I do not see anyone working on this fact.  We need to look at
this. 

§  We have the concepts: of policy request, policy decision, policy
executed, and a separate process that validates whether the policy did what
it was planned to be. 

o    Policy and VPN Service Management 

§  Explain the difference between the representation of policy and the
actual policy. The actors using the policy are different within the system. 

o    Discussion: 

§  Georgios: Please go back to the Policy and VPN Service Management.
Cannot we map the two policies to the different frameworks?  

§  John: This is what I was trying to say.  I forget what policy called the
policy domain.  This policy domain is a building block. You can nest policy
domains within each other.  You can have hierarchy of policy domains.  You
can link policy domains together. 

§  Norival: You are opening up the sub-systems of network policy.  You are
showing how this sub-system interacts. 

§  John: These are generic functions that can be used as generic functions
within a sub-system. 

o    Jun Bi’s draft: DDC service policy

§  This draft talks about an event in a specific time. 

·         Policy rule: event, condition, action 

·         event – time based/match 

·         Condition: set of tests

·         Actions: Are a set of actions 

·         Policy rule – has meta-data that aids interpretation 

§  Yang model that discusses the policy – provides 

·         Jun’s Bi’s draft – is looking only at the ECA policy.

o    John: We should have an intent-based policy that is tied into the work.

o    Tina: There is an updated draft based on the discussion, but it is not
submitted.

o    John: Policy-time-period

§  priority? – the policy does not make sense for the policy 

§  rw start? 

§  rw end? 

§  rw duration?

§  rw periodicity  enumeration 

§  if you say the priority of the policy, then you say 

·         the events, actions, conditions are more important. 

§  priority – is usually disambiguate policy actions

o    John: The Policy rule is lacking meta-data

§  #1 – executes fine, 

§  #2 – does not execute fine

§  Do we roll-back 1, do we go on to #3 ignoring the #2 failure. 

§  This policy lacks the meta data to instruct what actions are next.  

o    John: There is the notions of constraints that can be applied

§  This is true for the event, condition, and actions.  

§  Rules can have sub-rules in order to have this for certain use cases. 

§  We need to do some work on this structure.

o    Tina: 

§  This draft needs to improve a lot. 

·         Tina: Norival is there any interest to work together? 

·         Norival: There is some synergy between John’s work and the Jun
Bi’s draft. I think there is a way to look and learn more about.   This is
submitted in a different group in the IETF.  Will you target your work for
NFVrg?  We are trying to focus on the NFV architecture so we can figure out
a framework for the NFV work.  At some point, the group will be interested
in policy models. The specific focus for us in NFVrg is specific for this
point.  Do you have a focus work on NFVrg? 

·         Tina: We used the NFVrg architecture for both sides.  We both
worked with Diego Lopez.

·         Norival: Diego Lopez was added for a co-author for our work.  We
have not discussed the work in detail on this policy. 

·         John: I do not see any reason why we could not extend SUPA to NFV
or SDN.  Policy is independent from domain.  A policy rule should be applied
to networking or storage.  An NFV based system that is using a service chain
that was orchestrated to apply to the VIM.  At this level, we should not
have a policy at this level.  The NFV literature does not have the policy
block. 

·         Norival: Are you interested to make sure the policy can apply to
the NFVrg?   The policy in Congress can express policies that can apply to
the NFVrg.  Policy used in a VM.  The policy applies to VM whether in the
public model or the private model. It goes from compute to network to users.
It provides a simple policy to link between these domains.  This type of
reach needs to be expressed in the policy framework that needs to be
handled. 

·         John: I think these types of policies that stretch between the
domains.  I was an active participant in NFVv1.   It does not provide any
policy building block.  What is it that you are looking for policy in NFV. 

·         Norival: You are right.   We talk about the potential policy in
Brocade and Telefonica.  Telefonica see the OSS and BSS with the legacy
technology. They want to understand how policy would be adopted in those
systems. They described examples of policies that Telefonica or Brocade
customers want to implement.  

·         Georgios:   We can use the SUPA models to define the policies
model, and bring these concepts into the NFV as a use case.  Then we can
bring these policies to the NFV.  

·         Norival: I could not understand you due to the background voices. 

·         Georgios:  SUPA could be seen as the base where we can work out
the policy framework that was emphasized by John.  By having that, we can
provide the output that can provide the input to NFV.  The NFV could be seen
as a use case within SUPA. 

·         Norival: I agree with you.  There are some aspects of policy that
are not specific to NFV.  Of course, in the NFVrg, we are trying to make
very specific studies to NFVrg.  We are planning to do updates that will
make it more specific.  We are trying to keep it at the level of the
framework, and keep it above the subsystem level.  This work is
complementary to SUPA. 

·         Tina: Please keep discussion on the mail list. We clarified a lot
of issues and scope.  

o    Any other comments? 

o    Do we have any work plan you wish to see? 

·         [silence} 

·         Tina: Any other business? 

·         [silence] 

·         We are adjourned for today.