Subject: On policy conditions

From: Silvano Gai <[email-masked]>
Date: Wed, 10 Mar 1999 22:09:43 -0800

After the interesting discussion with David Black, Hugh Mahon and Raju Rajan, I have tryed to collect my ideas and to organize them better. This is the result.

Cheers

-- Silvano

--------------------------------------

The current Policy Core Schema specifies that a rule has the form:

             if condition then action

Condition cannot be a generic CNF/DNF expression. In fact we should recognize that there are three possible condition types:

- T (Transition), e.g,  at 5 PM do something;
- S (State),  e.g,  while the network is congested do something;
- P (Packet),  e.g,  if ProtocolType == UDP do something.

Transitions are instantaneous events that trigger the execution of a set of actions. Entering a given state is a transition, exiting a given state is a transition, a specific time of the day is a transition (e.g., at 5 PM), the fact that user john logs on is a transition.

States are intervals during which certain policies may apply or not. Examples of state are:
- network congested (for all the time the network is congested);
- from 8 AM to 8 PM (the time interval);
- if john is logged on (during the interval in which john is logged on).

Packet conditions are conditions that test specific fields of the packets. Currently the field are:
- IPSA and IPDA
- ProtocolType (UDP/TCP/...)
- Source/Destinations ports
- IPPrecendence/ DSCP.

The architecture must be flexible to allow other fields to be added.

It is important to realize that while it is always legal to "OR" together transitions, states and packet conditions, the following limitations apply to "AND" them together:

    T   S   P
  +---+---+---+
T | N | Y | N |
--+---+---+---+
S | Y | Y | Y |  Y: Yes, legal
+-+---+---+---+  N: No, illegal
P | N | Y | Y |
  +---+---+---+

That means that a transition, due to its event nature (instantaneous), cannot be ANDed with another transition or with a packet condition.

Therefore a generic CNF/DNF expression of conditions is not appropriate.

It is agreeable that transitions and states are part of the condition. It has been questioned if the packet condition is part of the condition or of the action. Let's assume it is part of the action (not my proposal). For example, we can write something like:

if state1 then action1
action1 = if packet1 then drop

this is equivalent to

if state1 then if packet1 then drop.

This is equivalent to:

if state1 && packet1 then drop

which seems more elegant. The important part is that the action should not be an opaque object, otherwise conflict detection is very limited or impossible.

I think it is possible to prove that transition, states and packet conditions have a given degree of redundancy, but I think the core schema must allow for this redundancy, gaining in flexibility.

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

---

From: "Hugh F. Mahon" <[email-masked]>
Date: Thu, 11 Mar 1999 21:52:19 MST

Hi Silvano,

> After the interesting discussion with David Black, Hugh Mahon and 
> Raju Rajan, I have tryed to collect my ideas and to organize them 
> better. This is the result.  
> 
> Cheers
> 
> -- Silvano
> 
> Condition cannot be a generic CNF/DNF expression. In fact we should 
> recognize that there are three possible condition types: 
> 

I agree with the concepts for Transition and State, but so far am 
uneasy with calling a condition a 'transition' or 'state' condition 
type because whether they are a 'transition' or 'state' is dependent 
on the context of what the policy is being applied to and how the 
policy is being evaluated.  

What would you think of the term 'quality' to describe what you call 
'packet', since I think the same concept can be applied to things 
beyond a packet?

...
> The architecture must be flexible to allow other fields to be added.

I most strongly agree!

> 
> It is important to realize that while it is always legal to "OR" 
> together transitions, states and packet conditions, the following 
> limitations apply to "AND" them together:  
> 
>     T   S   P
>   +---+---+---+
> T | N | Y | N |
> --+---+---+---+
> That means that a transition, due to its event nature 
> (instantaneous), cannot be ANDed with another transition or with a 
> packet condition.  

Hmmm.  I would very much like to discuss this with you further.  It 
would be good to find some examples of policies which demonstrate 
these behaviors.

> Therefore a generic CNF/DNF expression of conditions is not appropriate.

In your table the illegal conditions are when ANDing a transition with 
a quality of a short-lived entity (e.g., a packet).  No argument (at 
least not for now :-).

> It is agreeable that transitions and states are part of the 
> condition. It has been questioned if the packet condition is part of 
> the condition or of the action. Let's assume it is part of the action 
> (not my proposal). For example, we can write something like:   
> 
> if state1 then action1
> which seems more elegant. The important part is that the action 

I agree.

> should not be an opaque object, otherwise conflict detection is very 
> limited or impossible.  

I think we are in agreement.  I would state that there is a 
well-defined meaning for the action, which allows for conflict 
detection but also allows some room for specific implementations.

> I think it is possible to prove that transition, states and packet 
> conditions have a given degree of redundancy, but I think the core 
> schema must allow for this redundancy, gaining in flexibility.  
> 
> 
> Silvano Gai               

Good stuff.

        Hugh Mahon                              
        Hewlett-Packard Company                 
        Network Management Division  
        e-mail: [email-masked]               
        Phone: 1-970-898-2487

---

From: Silvano Gai <[email-masked]>
Date: Sat, 13 Mar 1999 08:14:22 -0800

I have prepared few slides that I intend to present at the next IETF. They are in:

ftp://ftpeng.cisco.com/sgai/conditions.pdf

Cheers

-- Silvano

Silvano Gai