Subject: RE: Core Model Last Call Issue: Execution Semantics

From: Andrew Smith <[email-masked]>
Date: Mon, 17 Apr 2000 12:06:51 -0700

Yoram,

Yes, I'm not quite clear on why David is insisting on unique priority for
each rule (I do understand his point that, if you insist on this, you need
them to be automatically generated/re-generated by any UI tool). If you find
2 rules with the same priority that conflict you just flag the error
(somewhere close to the UI hopefully) - that's fine I think.

I think I understand "Nested rules priority" but can you explain
"PolicyGroup priority" (why does that need to be a separate attribute? Maybe
I should re-read the QoS PIM ...)? If these are generally applicable, rather
than QoS-specific, they should be "promoted" to the core model [and if
people are maintaining that priority is not needed then these need to be
removed from the QoS PIM, right?] 

Are people disputing the need for conflict detection or are they just saying
it does not need to be addressed in the information models?

Andrew

> -----Original Message-----
> From: Yoram Snir [mailto:[email-masked]]
> Sent: Sunday, April 16, 2000 12:42 AM
> To: 'John Strassner'; [email-masked]; 'Andrew Smith';
> [email-masked]
> Cc: [email-masked]
> Subject: RE: Core Model Last Call Issue: Execution Semantics
> 
> 
> Making the rule priority mandatory solves some of the 
> problems although I
> think that uniqueness is not required.
> To complete the picture and have a fully consistent model 2 
> other things are
> required;
> 1. PolicyGroup priority.
> 2. Nested rules priority.
> Both were defined as part of the QoS Policy information model.
> 
> Yoram Snir
> Cisco Systems
> Tel.   972-9-9700085
> Mobile 972-54-970085
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of John Strassner
> > Sent: Sunday, April 16, 2000 4:00 AM
> > To: [email-masked]; Andrew Smith; [email-masked]
> > Cc: [email-masked]; [email-masked]
> > Subject: Re: Core Model Last Call Issue: Execution Semantics
> >
> >
> > Comments inline.
> >
> > regards,
> > John
> >
> > ----- Original Message -----
> > From: <[email-masked]>
> > To: <[email-masked]>; <[email-masked]>
> > Cc: <[email-masked]>; <[email-masked]>
> > Sent: Friday, April 14, 2000 12:36 PM
> > Subject: RE: Core Model Last Call Issue: Execution Semantics
> >
> >
> > ...
> >
> > > Making priority mandatory is at best a step towards
> > > addressing the problem in the small.  Finishing the
> > > job entails requiring that all priorities are
> > > unique - the IPsec SPD does this by implicitly
> > > associating priority with the entry
> > > position in the linear ordering...
> >
> > You are comparing the operation of an algorithm with the
> > operation of a system. This is apples and oranges.
> >
> > > IMHO, requiring that each rule has a unique
> > >priority does not scale up well in the core model.
> >
> > I'm confused - it just seems that you just said that what
> > you really want - making all rule priorities unique -
> > doesn't scale. Please help me understand what you do want.
> > As far as your approaches:
> >
> > > I can see two alternative approaches:
> > > (1) Adopt the Container construct from the QoS model,
> > > require unique priorities within each Container, and
> > > describe how to order nested priorities (it's like
> > > ordering words in a dictionary: albatross comes
> > > before alpha because b comes before p).
> >
> > This doesn't solve your problem, because this still allows
> > multiple objects to have the same priority. In fact, we
> > explicitly allow this, because sometimes the semantics "Do
> > this set of rules before this one and after that other one
> > in whatever order is convenient" is important.
> >
> > > (2) Use the corresponding lexical ordering of DNs to
> > > resolve ties that aren't resolved by priority.
> > > Both of these approaches match the hierarchical structure
> > > of the policy model in a fashion similar to linear search
> > > matching the linear ordering of the IPsec SPD.
> >
> > Please remember that we are talking about an information
> > model. An information model is by definition INDEPENDENT of
> > any one particular repository. So any talk of ordered DNs is
> > inappropriate for the core information model, and MUST ;-)
> > be delegated to one of the schema drafts.
> >
> > ...
> >
> > > --David
> > >
> > > ---------------------------------------------------
> > > David L. Black, Senior Technologist
> > > EMC Corporation, 42 South St., Hopkinton, MA  01748
> > > +1 (508) 435-1000 x75140, FAX: +1 (508) 497-6909
> > > [email-masked]  Cellular: +1 (978) 394-7754
> > > ---------------------------------------------------
> > >
> > >
> > >
> >
> >
> >
> >
>

---

From: "Yoram Snir" <[email-masked]>
Date: Tue, 18 Apr 2000 10:29:19 +0200

Please see inline.

Yoram Snir
Cisco Systems
Tel.   972-9-9700085
Mobile 972-54-970085

> From: Andrew Smith [mailto:[email-masked]]
> Sent: Monday, April 17, 2000 9:07 PM
> To: 'Yoram Snir'

I think  more then one rule with the same priority is OK, since any policy
decision point would know exactly what to do.
> removed from the QoS PIM, right?]
Maybe, the QoS PIM clearly defines a consistent model of decision making.
Quating from the QoS PIM: ( I am sorry for the length of the section but it
covers the whole subject and include examples that clear up the relevant
issues)

-------------- From the QoS PIM ---------------
Section 3.2.4:
"Each policy container is assigned a "match strategy", which is a name
of a method to interpret the order of its rules (see section 1.2.1.5).
For example, a FirstMatch strategy means that the rules will be
"matched" according to ascending order of their Priority attribute.
Decision strategy is explained in section 5."