Subject: [Supa] Policy and Service

From: John Strassner <[email-masked]>
Date: Wed, 20 May 2015 19:23:25 -0700

Fukushima-san wrote:

I wrote:
> >    - It is **generic**, in that it defines policy concepts
> >      independent of how those concepts are implemented.

I totally agree with John that the right level of generality is preferable
because such a generic model allows us to share high-level understanding of
concepts commonly observed in various services in our networks.

At the same time, if a model was overly generalized/abstracted, it could
make the scope of the model somewhat ambiguous. For example, if a policy
model is overly generalized, it could look like a policy for everything.

<jcs>
This depends on how you define policy.

Look at my reply to the netmod acl draft. There, I state that an ACL is NOT
a policy, because it simply represents a way to select entities (e.g.,
traffic). The fact that it may also have a set of actions to do if
the selection overloads the semantics of selecting something with also
doing something to the entities that was selected. This is why the ECA
model separates the condition (e.g., the selection part of the ACL) from
the action.

This is why I, in draft-strassner-supa-generic-policy-info-model, policy
is defined as:

    "SUPAPolicy is defined generically as a means to monitor and
      control the changing and/or maintaining of the state of one or
      more managed objects"

This is not to say ACLs aren't useful - of course they are. But an ACL, in
and of itself, lacks the context that enables a decision to be made as to
whether the current state is good or bad.
</jcs>

So, in order to convince those who are concerned that the scope of supa
might be too broad, we need to clarify the scope/applicability of the model.

<jcs>
Agreed. As Juergen noted, I do not think that we should
artificially restrict the power of the model. Rather, we should restrict
which domain(s) we are investigating the use of policy for, and gradually
prove that it can indeed handle multiple domains.

As stated in the call on 5/18, I think we should do what Benoit asked :-)
and investigate BGP, routing, ACLs, and DiffServ.
</jcs>

>From this viewpoint, I have a question.
What element in the generic model makes it a policy model for service (or
something worth to be focused on in supa) and makes it distinct from a
policy model for everything?

<jcs>
Juergen is right - until we have an accepted definition of service, this is
a difficult discussion. However, note that I do not recommend that we
develop a full "service model", such as what you find in the TMF or DEN-ng.
I don't even think we should develop a transport service model, such as you
find in the MEF. These models are huge and complex, and have taken years to
get this far, and will continue to be worked on for a while.

Rather, we should abstract the notion of a service as a set of managed
objects.

More on providing such abstractions later...
</jcs>

 Thank you.
Masaki Fukushima

-- 
regards,
John