Subject: Policy conditions - a plea for simplicity

From: "Ken Roberts" <[email-masked]>
Date: Thu, 22 Apr 1999 10:16:22 -0700

Hi Group,

First let me introduce myself to you and establish a bit of my background and [hopefully] credential for my comment. I am the editor 
for the twinned ISO and ITU-T standard/ recommendation on Management Policy, as such I have had the "pleasure" of attending numerous meetings both nationally and internationally on this topic and heard all manner of interpretations on policy. Some rational and some not.

What has emerged, as an un-argued consensus is the only scenarios that folks can either get their minds around or agree on are the simple ones! Policy is an extremely powerful concept and therefore can be applied to a wide range of situations some simple, some not.

What constitutes a "simple" policy? A set of simple rules applied to a simple jurisdiction invoking a simple action. This seems simple enough.

Simple rules incorporate a predicate that is parsable and halts. It must 
contain all variables either within itself, or be generic such that when 
computed produces a Boolean result. Examples are "If current-time less 
than 17:00 AND greater than 09:00", simple statements may be combined to form a condition (as in the example) under the overriding proviso that they conform to the "simple" rules.

Simple jurisdictions are those that can be enumerated without computation. An expressly enumerated list is an example of such a jurisdiction, "originating-address equals 1.2.3.4 and 
destination-address equals 2.4.6.8" is a simple rule statement 
containing the jurisdiction for the rule within its syntax.

Simple actions are those that can be performed without reference to 
other managed systems. Examples are "mark as Premium [GOLD] ELSE mark as Best Effort".

If you put it all together you get:
IF (current-time less 17:00 AND current-time greater 09:00) AND
     (originating-address equals 1.2.3.4 AND destination-address equals 
2.4.6.8)
     THEN
               Mark(Premium, GOLD)
      ELSE
               Mark(Best-Effort)
Endif

This is something that folks can see as being implement-able, and is a 
good place to start. My recommendation to the group is definitely to 
start simple and then complicate your lives. If you try to solve the 
more complex scenario's you WILL "boils the ocean" and achieve little - 
believe me I've been there and have been involved for over seven years.

By the way most examples I've seen are more or less constructed as above using TIME as a variable, network time is itself a large problem and keeping NE clocks synchronized is a work item that will occupy folks for some time I expect.

Anyway my two cents worth.

Regards,

Ken Roberts
Email: [email-masked]
Phone:+1(408)565-7844

---

From: sanjay <[email-masked]>
Date: Thu, 22 Apr 1999 14:17:11 -0400 (EDT)

Ken,
   I fully support your plea for simplicity. That is the only way we can have a first
generation of standards-based interoperable policy based networking solution. In all
the networking policy related drafts we have submitted, we have tried to keep this
objective central. Please look at the following two drafts

   Networking Policy Condition Information Model
   (draft-rajan-policy-conditions-00.txt)
   and
   Policy Action Classes for Differentiated Services and Integrated Services"
   (draft-rajan-policy-qosschema-01.txt).

   Suggestions for improvement and discussion on the list are most welcome.
-Sanjay

---

From: Silvano Gai <[email-masked]>
Date: Thu, 22 Apr 1999 14:48:31 -0700

>Hi Group,

...

>     (originating-address equals 1.2.3.4 AND destination-address equals 

According to my terminology and my presentation you have only used state conditions and packet conditions. This is fine for me and I think we can write effective policies in this way.

What we don't have agrement on is how do we model/handle transitions/events that change states. In the case of time, it is clear that we can immagine a simple "implicit handler" that maps  transitions/events to states.

The more complex case is:

IF "user John is logged on" THEN

where is the handler that set/reset the state "user John is logged on"?

As David mentioned, the handler cannot be associated with the arrival of the logon or logoff packets, but must take into account the execution of a login/logout procedure that could be quite complex.

I think we should introduce in the PDPs the concept of "explicit event handlers". An Event handler is a procedure to map event/transitions into states. I also think we should write the policies only in term of states and packet conditions.

-- Silvano

Silvano Gai               
Cisco Systems                  Empowering the Internet Generation
170 West Tasman Drive                         Tel. (408) 527 2690
San Jose, CA, 95134-1706                      Fax. (408) 527 2690
                                                   [email-masked]