Subject: Re: [Supa] questions about SUPA

From: John Strassner <[email-masked]>
Date: Fri, 26 Jun 2015 14:00:35 -0700

Hi Andy,

good questions. My responses are inline: please see <jcs>...</jcs>

regards,
John

Hi,

I am really trying to understand SUPA.
The charter does not really give me a clear
picture of the deliverables.

<jcs>
Please tell us what is not clear about the deliverables
</jcs>

I would like to start with a 1 leaf boolean policy
and understand what SUPA is going to provide
the developer of this policy.

<jcs>
There are two answers. The first, and simplest, is that
SUPA is the ONLY model being used. The second, and
more powerful, is that SUPA is being used with other
models. I'll try and address both below.
</jcs>

-------------------------------
The example policy said:

    drop all SNMP traffic on customer facing links

If you want a policy saying:

    drop all SNMP traffic on all network elements tagged 'security'

then this seems to be a slightly different policy. Perhaps the first
one can be written slightly differently:

    drop all SNMP traffic on all links tagged 'customer'
------------------------------------

Notice how the first form is really unimplementable
because there is no framework (even implied) to
identify customer facing links.

<jcs>
For the first answer (SUPA) only, you are correct. While
SUPA has a SUPAMetadata class, there is currently no
means for representing a customer. However, for the
second, there are existing model frameworks in place that
provide the "magic decoding" of what a customer is. SUPA
could use these by associating those model elements with
appropriate classes. For example, the SUPAPolicyTarget
class could be populated by roles or metadata that identify
the interface as "customer-facing". The action clause(s)
would then be applied to the SUPAPolicyTarget.
</jcs>

But the 2nd and 3rd forms imply there is a framework
for tagging data model nodes (e.g. interfaces) with properties
or even just user-managed tags (like git)

<jcs>
A simple way of implementing tagging in SUPA is to use
the SUPAMetadata class. However, we can have a much
more general answer by allowing other models to define
objects that are then referenced by SUPA. Since a "tag" is
just an annotation, this could be done in a variety of ways.
Two examples are using the role-object pattern, and using
metadata to associate metadata properties with objects.

Note that while the implication is there, the above forms
have not identified how the tagging is done, or what the
tag is, or what it can represent. It is trivial to have a tag
equal to a property; can the tag also be the evaluation of
a function that dynamically selects objects? Both, and
others, are possible in a model.

The advantage of using a model is that you have
objects and relationships to help you do this. When you
translate (the (in)famous "SUPA function" in Juergen's
diagram), you select the particular approach used to
identify an object (or set of objects), such as metadata,
and then instantiate only those objects needed.
</jcs>

The 2nd form is really too course. #3 is better.

<jcs>
I assume you mean because #2 says "network element"
and #3 says "link". But don't both of these end up saying
an interface in the end? So then you need a mechanism
to translate these two different nouns to a third noun. Or
am I misunderstanding you?
</jcs>

tail-f supports data tagging in conf-d.
Not sure about the details but we can ask Martin.

I am interested in hearing about your solution proposals.
This seems like a very simple boolean policy.
Seems like it only gets much harder from here.

Policy datastore:

   container snmp-policy {
     leaf allow-incoming-snmp {
         type boolean;
         default true;
         description
           "If true, incoming SNMP PDUs will be allowed on
            customer facing interfaces.  If false, all SNMP
            traffic will be blocked.";
      }
   }

<jcs>
Why is the above even necessary? In a policy system,
all the policy repository does is contain policies. There
MAY be a special mechanism to search on them, in which
case you look at the metadata associated with the policy
(refer to 3.2.1.4, PolicyContainer, in draft-strassner-...).

In other words, while you could do this, there should be no
need to, and the policies should be directly consumable.
</jcs>

Target datastore:

      container interfaces { ... ietf-interfaces ... }

      container  acls { ACL draft }

<jcs>
Again, why do this?
In policy management, there isn't typically a target data store.
Both of the above would exist as reusable objects, described
by properties and metadata. The SUPAPolicyTarget object
would contain ONLY those interfaces that are selected to be
acted upon (as opposed to a listing of all interfaces), and the
ACLs would exist as reusable SUPAAction objects
</jcs>

Policy snmp1:
   event: snmp initialized
   condition A:
        "/snmp-policy/allow-incoming-snmp"
    action A:
         enable-incoming-snmp
    condition B:
        "not(/snmp-policy/allow-incoming-snmp)"
     action A:
         disable-incoming-snmp

<jcs>
Typically, ECA policy rules only test for the condition being
true (upon which actions are then executed). DEN-ng actually
defines policies like what you did above. However, this is in
general more difficult, because if you start to nest policies, or
have policies call other policies, then the logic is much more
complex. But sure, this could be a SUPAECAPolicyRule.
</jcs>

The actions are really protocol exchanges with the target NE:

   $cust-itf = eval(/interfaces/interface[@tag='customer'])

  for all $itf in $cust-itf:
     $ifname = $itf/name

    configure ACL to deny all SNMP ports
       (may need more config to determine which ports are being
        used for SNMP by each customer)

 Config commands can be specified:

     <command> <target> [<value>]

    create /acl/interface-acl[name='$ifname']   \
        value="JSON object for the ACL entry"

I have no idea what work items (2) and (3) really look like.
How will even a trivial policy like this actually be expressed
and implemented?

<jcs>
You did express it :-)

In work item (2), the expression is a collection of SUPAPolicy
objects and their relationships. This could take the form of a
pretty picture or a textual form, such as what you defined. I
could add examples into -02 of draft-strassner-... if you'd like.

In work item (3), either of the above would be translated into
a YANG data model.

So I'm confused as to what, exactly, you don't understand.
</jcs>

People at the BoF want to know what SUPA will deliver
(in 2 years?) to make things better.

<jcs>
Here is a simple comparison between draft-shaikh and draft-strassner:

+--rw routing-policy         +--rw SUPAPolicyComposite*
                                +--rw supaPolicyName
   +--rw policy-definition*     +--rw SUPAPolicyAtomic*
      +--rw name string            +--rw supaPolicyName
      +--rw statement*                +--rw SUPAPolicyStatement*
         +--rw name string               +--rw supaPolicyName
         +--rw conditions!                  +--rw SUPAPolicyCondition*
         | ...                              | ...
         +--rw actions!                  +--rw SUPAPolicyAction*

Note that the above comparison does NOT include higher order
elements, such as SUPAMetadata, SUPAPolicySubject, and
SUPAPolicyTarget, in order to keep the comparison simple.

Now, when I read draft-shaikh, four things were noticeable.

1. Both the condition and action elements only define
   properties for a specific domain (e.g., routing). There
   were no real instances of domain-independent properties
   (except things like name).

2. There is no organization to the defined properties;
   they are just a simple listing. The one exception is
   the concept of igp-conditions and igp-actions.

3. The BGP examples all define new concepts. Yes, there is
   a structure (kind of) if you look at defined-sets, but
   mostly the approach is to use this, conditions, and
   actions as containers that you stuff values into.

4. I have no idea how to express even simple semantics.
   For example, tags magically appear. I like to see what
   the tag is and its structure, and how to create, update,
   and delete it. The model can do this; flat data structures
   cannot.
</jcs>

The routing-coordination team is already working
on model consistency.  Openconfig and others
are also pushing for infrastructure work in this area.
So the argument "YANG is just a bunch of random parts"
is not going to work.

<jcs>
I don't see any evidence on how this is going to solve the
problem. There is syntax alignment, sure, but how do you
do semantics? If you don't want to do semantics, then why
not just use CLI and be done with it?
</jcs>

The value of SUPA seems to be a standard policy controller.
Is that correct? Is there going to be such a thing?

<jcs>
I don't know what you mean by a "standard policy controller".
I didn't think that we were chartered to architect a policy
server/controller/manager/foobar.

The value of SUPA is a vendor- and technology-neutral model
for expressing policy, both in an ECA form as well as in a
declarative form.
</jcs>

If so, what does the northbound interface from SUPA look like?
I don't see the point of standardizing above the NE devices
unless this controller has a standard NBI.

<jcs>
So there is no value in standardizing how to define a policy,
what types of metadata it can have, how to query it, ... ?
</jcs>

3) A set of YANG data models that express the concepts defined in the
   generic policy information model in concrete data models. These
   models will be designed to be generic and extensible.

It is not a good thing if the audience has no idea what the solution
space looks like at the BoF.  The implementable solution
seems to be embodied in work item (3).  It would be better if more detail
on this work item could be provided.

<jcs>
What, exactly, isn't clear? There will be YANG models, one for ECA
and one for declarative policy. Does it matter if there is one each or
a suite of 10? Why?
</jcs>

Andy

On Mon, Jun 22, 2015 at 12:22 PM, Andy Bierman <[email-masked]> wrote:

> OK -- reposted to [email-masked].
>
>
> Andy
>
>
> On Mon, Jun 22, 2015 at 12:19 PM, Benoit Claise <[email-masked]> wrote:
>
>>  Hi Andy,
>>
>> Great question.
>> Can we please have this type of questions on the SUPA mailing list.
>> Everybody could then benefit from the answer.
>>
>> Regards, B.
>>
>> Hi,
>>
>>  I am really trying to understand SUPA.
>> The charter does not really give me a clear
>> picture of the deliverables.
>>
>>  I would like to start with a 1 leaf boolean policy
>> and understand what SUPA is going to provide
>> the developer of this policy.
>>
>>  -------------------------------
>> The example policy said:
>>
>>     drop all SNMP traffic on customer facing links
>>
>> If you want a policy saying:
>>
>>     drop all SNMP traffic on all network elements tagged 'security'
>>
>> then this seems to be a slightly different policy. Perhaps the first
>> one can be written slightly differently:
>>
>>     drop all SNMP traffic on all links tagged 'customer'
>>  ------------------------------------
>>
>>  Notice how the first form is really unimplementable
>> because there is no framework (even implied) to
>> identify customer facing links.
>>
>>  But the 2nd and 3rd forms imply there is a framework
>> for tagging data model nodes (e.g. interfaces) with properties
>> or even just user-managed tags (like git)
>>
>>  The 2nd form is really too course. #3 is better.
>>
>>  tail-f supports data tagging in conf-d.
>> Not sure about the details but we can ask Martin.
>>
>>  I am interested in hearing about your solution proposals.
>> This seems like a very simple boolean policy.
>> Seems like it only gets much harder from here.
>>
>>  Policy datastore:
>>
>>     container snmp-policy {
>>      leaf allow-incoming-snmp {
>>          type boolean;
>>          default true;
>>          description
>>            "If true, incoming SNMP PDUs will be allowed on
>>             customer facing interfaces.  If false, all SNMP
>>             traffic will be blocked.";
>>       }
>>    }
>>
>>  Target datastore:
>>
>>        container interfaces { ... ietf-interfaces ... }
>>
>>
>>        container  acls { ACL draft }
>>
>>
>>  Policy snmp1:
>>    event: snmp initialized
>>    condition A:
>>         "/snmp-policy/allow-incoming-snmp"
>>     action A:
>>          enable-incoming-snmp
>>     condition B:
>>         "not(/snmp-policy/allow-incoming-snmp)"
>>      action A:
>>          disable-incoming-snmp
>>
>>  The actions are really protocol exchanges with the target NE:
>>
>>     $cust-itf = eval(/interfaces/interface[@tag='customer'])
>>
>>    for all $itf in $cust-itf:
>>      $ifname = $itf/name
>>
>>      configure ACL to deny all SNMP ports
>>        (may need more config to determine which ports are being
>>         used for SNMP by each customer)
>>
>>   Config commands can be specified:
>>
>>       <command> <target> [<value>]
>>
>>      create /acl/interface-acl[name='$ifname']   \
>>         value="JSON object for the ACL entry"
>>
>>  I have no idea what work items (2) and (3) really look like.
>> How will even a trivial policy like this actually be expressed
>> and implemented?
>>
>>  People at the BoF want to know what SUPA will deliver
>> (in 2 years?) to make things better.
>>
>>  The routing-coordination team is already working
>> on model consistency.  Openconfig and others
>> are also pushing for infrastructure work in this area.
>> So the argument "YANG is just a bunch of random parts"
>> is not going to work.
>>
>>  The value of SUPA seems to be a standard policy controller.
>> Is that correct? Is there going to be such a thing?
>>
>>  If so, what does the northbound interface from SUPA look like?
>> I don't see the point of standardizing above the NE devices
>> unless this controller has a standard NBI.
>>
>>   3) A set of YANG data models that express the concepts defined in the
>>    generic policy information model in concrete data models. These
>>    models will be designed to be generic and extensible.
>>
>>
>>
>>  It is not a good thing if the audience has no idea what the solution
>> space looks like at the BoF.  The implementable solution
>> seems to be embodied in work item (3).  It would be better if more detail
>> on this work item could be provided.
>>
>>
>>  Andy
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>

-- 
regards,
John

---

From: Andy Bierman <[email-masked]>
Date: Fri, 26 Jun 2015 16:20:40 -0700

> Please tell us what is not clear about the deliverables

It is not clear what type of YANG data models are being created
or how the info models will be used.

> models. I'll try and address both below.

It would help to see a solution that implemented this policy.
There is a SUPA info model that contains all the YANG data models
in it somehow?  How does it know about interfaces, ACLs, etc?

Perhaps an actual example of a policy that uses SUPA
instead of describing which classes would be used for this or that.
Juergen says any YANG module can be used with SUPA.
I provide a boolean leaf and you say that is not needed in SUPA.

The only examples I have seen are supposedly not relevant to
the "real" SUPA solution.  A hand-written policy module that
hard-wires specific events, conditions, and actions
(like the topology policy draft) is a direct approach that could work.
I would like to see an instance of the more generic approach.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 26 Jun 2015 19:33:47 -0700

Hi,

see more comments inline

Andy

> models. I'll try and address both below.

<andy>
"Only model" meaning all other models have to be entered into the
SUPA model as UML somehow?
</andy>

<andy>
Is the solution you have in mind a YANG data model that implements
the info model in your draft? SUPA is configured like a NETCONF server?

An operator or other developer would use some tool to configure
a SUPA agent with an instances of various subtrees, representing
classes in the InfoModel?

If so, then I was asking for a mock-up of such an instance document
for this SNMP policy.   Or is this part still very TBD?
</andy>

> and then instantiate only those objects needed.

<andy>
I don't really think the info models are needed for the policies.
The data model may not mirrr the info model though.
For example (IMO) XPath should be used anywhere it can be used.
There is no need to reinvent this wheel.
</andy>

> am I misunderstanding you?
<andy>
Yes. "security" could apply to anything.
"customer-link" or some other specific tag could be used.

Or the solution could require that the YANG model itself
has some leaf identifying "customer-link".
This is a reasonable requirement.
There should be no need to decorate the YANG nodes with metadata
in order to use them.
</andy>

> need to, and the policies should be directly consumable.

<andy>
OK -- so this would be configured somehow in the SUPA data model?
Policies themselves are not configurable?
There would need to be a allow-SNMP policy and
another disallow-SNMP policy?  Or just one policy that
has a user-setting like allow-incoming-snmp.
</andy>

> ACLs would exist as reusable SUPAAction objects

<andy>
I thought SUPA could work with the data models on the NE device?
The device has an interfaces module and an ACL module.
By target datastore I mean the SUPA server's copy of the
running configuration datastore from each NE
</andy>

> So I'm confused as to what, exactly, you don't understand.

<andy>
I guess the "translation to a YANG module" sounds very vague to me.
This could be anything from 1 leaf containing the URL of the script
for the policy to a massive container with a subtree for every little
detail.
The solution should be easy to use and not require
massive front-end tools just to use it.
</andy>

>          +--rw conditions!                  +--rw SUPAPolicyCondition*

<andy>
It would help to see the a policy instance document for both solutions
</andy>

---

From: John Strassner <[email-masked]>
Date: Sat, 27 Jun 2015 14:59:35 -0700

Hi Andy,

Thanks for the detailed questions. I'm pulling them up to make the
thread easier to read:

<jcs>

<andy>

<jcs2>
Sorry, should have elaborated more. SUPA is designed as
a model **fragment**, meaning that you can take all or
part of SUPA and reparent it under another class in
another model. Most policy models are NOT designed this
way.

So, if you just use SUPA, and no other model, then you
need to establish associations, aggregations, or
compositions between elements external to SUPA and the
appropriate SUPA object.
</jcs2>

<jcs>

<andy>

<jcs2>
I was envisioning two YANG data models for #3. The first is a YANG
data model that implements GPIM and the ECA info model; the second is
a YANG data model that implements GPIM and the Logic info model.

I've always concentrated on the top-down side (just ask Juergen :-) ).
So for me, I worry about the policy server - the interface, the
structure of the models, the mapping between info and data model
(NOTE: we are NOT doing "mapping" or "schema matching" in SUPA, we
are taking a simpler translation approach). I think all of this then
talks to a NETCONF server. However, I have no preconceived ideas of
the NETCONF server - I was hoping that experts like you and
Juergen would guide us there.
</jcs2>

...talking about tagging...

<andy>

<jcs2>
My point was that the info model IS the design. It not only is
used to define object classes, attributes, and relationships, it
also is used to define metadata, such as tags.

I don't like designs where tags appear out of the ether. I
prefer designs where there are touchpoints defined in the design
that warrant the use of a tag. Then, we can model the tag
according to the needs of that particular touchpoint. Put
another way, a tag shouldn't be limited a set of pre-defined
strings; it should be able to express something interesting.
Along these lines, XPath is one of many solutions that should
be supported. In the info model world, I would argue that
XPath is not sufficient; in the YANG data model world, I agree
with you.
</jcs2>

<andy>

<jcs2>
I agree. In my mind, the decoration is done in the info
model; the data model is then generated. Note: in my
work, which is model-driven, this isn't the case, as the
data model changes dynamically at runtime. However, I think
we agreed that this is too ambitious for right now.
</jcs2>

 ... policy datastore model...

<jcs>

<andy>

<jcs2>
You asked three questions; let me break up my reply accordingly.

#1. Where is it configured?
In a policy server, policies are stored in a repository. It
may be one repository, it may be many, it doesn't matter.

Policies are identified in the repository using metadata as
well as attributes (e.g., supaPolicyName, supaPolicyDescription).
Policies can be searched on using the native facilities of that
repository. So, if I'm using an RDBMS, I'll use SQL.

This is why I asked why would you need the snmp-policy container
in the policy repository. The snmp-policy could be applied
wherever you want; if it needs to go in a specific place in the
data model, that shouldn't be encoded in a repository or the
policy info model.

#2. Aren't policies configurable?

Of course they are. But in a model, you would modify the
model elements (i.e., classes, attributes, relationships)
directly. For example, if I have an ECA policy rule, and I
want to keep the event and action clauses but use a new
condition clause, I would either duplicate or edit the
original ECA policy rule, and then replace the condition
clause with a new clause. In SUPA, this could be done by
replacing SUPACondition with a new SUPACondition, or at a
lower level by replacing the SUPAPolicyTerms that make up
a condition clause. Other ways (e.g., SUPAEncodedClause)
are also possible.

#3. How would it be structured?
If it was me, I would have a single policy that had a
configurable setting, as in your allow-incoming-snmp.

... target data store discussion ...

<andy>

<jcs2>
Aahh, ok, I thought you meant a generic policy repository.
In that case, I probably misunderstood the above comment
as well.
</jcs2>

...

<andy>

<jcs2>
It sounds very vague to you because we haven't defined it yet. :-)
But wouldn't your comments apply even if SUPA wasn't there, due to
the large variety of possible policies and their structures?

I don't think that tooling is in scope now, but if that is what is
needed, I'd certainly support working on it.
</jcs2>

... comparison of drafts...

<andy>

<jcs2>
By "instance document", what do you mean?
</jcs2>

-- 
regards,
John

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 29 Jun 2015 15:48:38 +0200

> the developer of this policy.

When I wrote the first example, I had in mind that there is a topology
data model that provides the relevant information. (Recall that SUPA
back in a day had a topology component. This work got shifted to I2RS
since they do policy models these days.) 

> Is that correct? Is there going to be such a thing?

I call it a policy function, I want to leave it to implementors to
determine where it should be located. There are obvious trade-offs.

- You can implement the policy function on the NE. This then requires
  to make sure the NE has access to all the information needed to
  process policies. The benefit is that the NE can go down and come
  back and synchronize its config to the policy independently. This is
  BTW the model used by system administration tools like cfengine or
  puppet.

- You can implement the policy function outside the NEs. This then
  requires that the policy function can track NEs effectively and
  relevant state changes that require policy re-interpretation.

-- 
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: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 29 Jun 2015 15:56:33 +0200

> since they do policy models these days.)

Typo: s/policy models/topology models/

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 29 Jun 2015 15:42:37 +0000

We discussed this in the SUPA call today, but ... we missed Andy. 

So, trying to wrap-up - two questions for Andy and of course, anybody else can jump into this discussion: 

1. Were Andy's questions answered clearly and satisfactorily? 
2. Any changes are needed in the proposed charter as a result of the clarifications brought up by this discussion?

Thanks and Regards,

Dan

> -----Original Message-----
> From: Supa [mailto:[email-masked]] On Behalf Of Juergen
> Schoenwaelder
> Sent: Monday, June 29, 2015 4:57 PM
> To: Andy Bierman; [email-masked]
> Subject: Re: [Supa] questions about SUPA
> 
> > > The charter does not really give me a clear picture of the
> > > deliverables.
> > >
> > > I would like to start with a 1 leaf boolean policy and understand
> > > what SUPA is going to provide the developer of this policy.
> > >
> > > Notice how the first form is really unimplementable because there is
> > > no framework (even implied) to identify customer facing links.
> > >
> > > But the 2nd and 3rd forms imply there is a framework for tagging
> > > data model nodes (e.g. interfaces) with properties or even just
> > > user-managed tags (like git)
> > >
> > > How will even a trivial policy like this actually be expressed and
> > > implemented?
> > >
> > > People at the BoF want to know what SUPA will deliver (in 2 years?)
> > > to make things better.
> > >
> > > The routing-coordination team is already working on model
> > > consistency.  Openconfig and others are also pushing for
> > > infrastructure work in this area.
> > > I don't see the point of standardizing above the NE devices unless
> > > this controller has a standard NBI.
> > >
> > > space looks like at the BoF.  The implementable solution seems to be
> > > embodied in work item (3).  It would be better if more detail on
> > > this work item could be provided.
> > >
> > >
> > > Andy
> >
> > --
> > Fax:   +49 421 200 3103
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.jacobs-
> 2Duniversity.de_&d=AwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31O
> cNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=uNUlp2L-P7BM-
> 61L4WFknDRmVSS0pQzS7AJhW1BJSqg&s=1T5xqa_OTP_XvIxh4cbyDIN0VJkH
> RNYtIoojyeVYo60&e= >
> 
> --
> Fax:   +49 421 200 3103
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.jacobs-
> 2Duniversity.de_&d=AwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31O
> cNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=uNUlp2L-P7BM-
> 61L4WFknDRmVSS0pQzS7AJhW1BJSqg&s=1T5xqa_OTP_XvIxh4cbyDIN0VJkH
> RNYtIoojyeVYo60&e= >
> 
> _______________________________________________
> Supa mailing list
> [email-masked]
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_supa&d=AwICAg&c=BFpWQw8bsuKpl1
> SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=uNUlp2L
> -P7BM-
> 61L4WFknDRmVSS0pQzS7AJhW1BJSqg&s=6Z3E6b27Gp3XT9UaqdaqrPGDVTL
> VVd1gNDWWwO-vwSw&e=

---

From: Andy Bierman <[email-masked]>
Date: Mon, 29 Jun 2015 10:19:50 -0700

Hi,

Sorry I had another meeting this morning.
I guess my questions were answered.

I am still not convinced the generic approach would be better
for reaching consensus on standards than the direct approach.

The way parameters are handled in a policy seems quite different.
In the direct approach, the model would have a leaf like
the 'enable-incoming-snmp' leaf in the example.  The generic approach
requires a lot of configuration to model that leaf, and then it seems
2 policies are needed (1 for true and 1 for false).

I assume each NE has a set of YANG configuration models
that can be manipulated by the SUPA policy engine.  These are just
as hard-wired into the policy either way.  I don't quire understand
why the NE data models need to be "pulled into" the SUPA info model.
This seems like a lot of extra work for nothing.  SUPA should be able
to use NE YANG models directly without any work by an operator.
(And punting to work to some complex front-end tool is not acceptable.)

I just can't imagine a workable solution for programming in YANG.
Deconstructing business logic into YANG data nodes seems like
a really complex system to implement and use.

Andy

On Mon, Jun 29, 2015 at 8:42 AM, Romascanu, Dan (Dan) <[email-masked]>
wrote:

> 2. Any changes are needed in the proposed charter as a result of the
> clarifications brought up by this discussion?
>
> Thanks and Regards,
>
> Dan
>
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 29 Jun 2015 19:38:24 +0200

> (And punting to work to some complex front-end tool is not acceptable.)

I do not follow. What does "pulled into" SUPA info model mean? How can
a policy of an operator be written without input from the operator?

/js

---

From: Andy Bierman <[email-masked]>
Date: Mon, 29 Jun 2015 10:55:42 -0700

> a policy of an operator be written without input from the operator?

I don't really understand the solution yet.
I understand a hand-written YANG module that provides the
operator with policy parameters that are implemented somehow
(totally out of scope for the standard).

I understand the boolean parameter "allow incoming SNMP".
I can easily see how one could write an SNMP policy module
and provide parameters for how SNMP is used in the administrative domain.
There are no "target models" to pick in this approach.
That is left as an implementation detail.

It would really help to see an attempt at a YANG module snippet for
the SNMP example.  If the operator has to program in the policy
then I assume that means that all events, conditions and actions
are fully specified by the operator into this SUPA engine?

Why would an operator bother doing this?
Why not just write your own scripts to define and implement
a policy?  What does the SUPA engine provide that makes
it worthwhile for an operator to use it?

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 29 Jun 2015 20:39:13 +0200

> it worthwhile for an operator to use it?

Have you ever used system administration tools like cfengine or
puppet? Yes, you can code everything as collection of scripts but it
seems that having some structure helps people to keep things
organized. Here is a cfengine rule taken from our cfengine setup:

   any::
      { /etc/sysctl.conf
            ReplaceAll ".*net.ipv4.tcp_congestion_control.*"
               With "net.ipv4.tcp_congestion_control = cubic"
            AppendIfNoSuchLine "net.ipv4.tcp_congestion_control = cubic"
         DefineClasses "reload_sysctl"
      }

This is applied to all (any) systems (but you can easily write more
complex expressions) and it sets TCP congestion control to cubic. You
can write the same in Perl, Python, Ruby, whatever but it turns out
that having suitable primitives makes it easier. Of course, cfengine
is text file centric (since this is how config files on Unix typically
look like). I would like to have something similar to work on YANG
data models. The precise delineation between scripts and structure is
something SUPA has to work out.

/js

---

From: Andy Bierman <[email-masked]>
Date: Mon, 29 Jun 2015 12:45:37 -0700

> something SUPA has to work out.

Now is seems you are talking about something that is a lot closer
to RFC 4011 than draft-strassner-supa-generic-policy-info-model-01.
Something like this could work. The SNMP Policy MIB had 1
fatal flaw -- SNMP is used for monitoring, not configuration.

I would note that the primitives are really NETCONF primitives
not policy primitives.  The policy is completely up to
the operator.  The mechanics of sending NETCONF requests
and processing NETCONF replies and notifications seem to
be the only thing provided by the policy engine. Maybe the
WG will come up with some policy primitives.

I could not have guessed the solution would be script-like
from reading the charter. I don't see any other workable
choice for the implementation of a generic action.

/js

Andy