Subject: [Supa] questions about SUPA charter

From: Andy Bierman <[email-masked]>
Date: Mon, 22 Jun 2015 12:22:19 -0700

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.

thanks,
Andy