Subject: Re: Consensus ?

From: John Schnizlein <[email-masked]>
Date: Fri, 03 Dec 1999 14:38:18 -0500

Since I have not seen a sufficiently clear answer to this,
here is one: These new colloquial terms are not useful.
More importantly, they apply to the architectural blocks that 
we have failed to progress for a year (for different reasons).

The proposal that we focus on functional blocks instead of
components of an architecture identified the functions of
translating, storing, and distributing policy information.
This approach holds some promise for helping to crystalize
the meaning of the critical term, "policy". Mark's proposal
that a Policy Rule is "to express a desired outcome of the 
operation of a service in a network" is a good start.

We have also discussed statements that policy is a set of
relatively stable rules for configuration in business terms.

A source of some concern, and at least 3 BOF presentations,
is the idea that policy, expressed in terms of
if <condition>, then <action>,
supports general programming of devices. Most of the buzz
in my vicinity during these discussions was that programming
was much to general and powerful for what we want to do.
Instead of conditional actions, I propose that we specify
policy rules in terms of what are called "invariants" in
programming language theory. These are statements that are
supposed to be true across the flow of execution of a program,
and therefore independent of the state of the program.

Examples would be like these:
1) this kind of traffic gets this service
2) traffic from/to these stations/users is of this kind
3) this service requires this per-hop behavior across its path
4) this service gets this amount/share of bandwidth
While these examples relate to QoS, more detail about the path
(containing a firewall) and less about the service (drop) might
extend it to much of the security domain.

Information other than policy, but necessary in order to translate
policy into configuration, such as which users appear at what IP
addresses and ports, would also me exposed by this sort of
functional decomposition. 

The term policy appears to have the following partial definition:
a set of statements about the treatment of network traffic based
on the business's allocation of resources, and invariant across 
the network.

Is this alternative approach attractive to you?

John

At 06:46 PM 11/22/1999 -0500, Shai Herzog wrote:
>I agree, we are generally describing 4 basic functional
>blocks.
>
>1. MA: Repository                 (non volatile storage, interoperable)
>2. PA: Policy server/advisor/...  (brains)
>3. ED: Enforcement                (muscles)
>4. UI                             (Console)
>
>I think this is the clearest functional breakup that we started
>with and we keep on returning to (under different names).
>
>As usual, the IETF doesn't care about specific implementations
>which may couple one or more of these blocks in the same physical
>device (such as ED+PA: a.k.a. grown up kid ;-)
>
>I think we've been confusing this with what I call "Policy Operations"
>which is the "Algebra" of policy processing.
>
>So far, we've defined the following policy operations:
>
>1. Decision
>2. Translation
>3. Formatting (which I'm not sure we defined well as of yet).
>4. ...
>
>I claim that this is ALGEBRA operators and NOT functional blocks
>and the reason is that they have no pre-defined order and may apply
>on PORTIONS of a policy rule.
> ...
>At 12:03 PM 11/22/1999, Ron Josephson wrote:
>>...
>>We are basically defining a rather simple 3-Tier architecture:
>>
>>Policy Server - MA - (Repository, DB) - Dumb.
>>PA - PDP -Intelligence - Smart.
>>ED - PEP - Client. - Dumb.
>>**Can someone explain me why we've changed the wording?
>>
>>
>>From: John Strassner <[email-masked]>
>>...
>> > Mark is also correct, in that we decided in the Policy Framework wg
>>meeting to define terminology that described functional blocks of a system
>>that are independent of protocol or implementation. There are many possible
>>architectures that can be built. It is not our job to define an architecture
>>in the terminology draft, or even to imply one; rather, it is our job to
>>define terminology to represent functions that can be used to assemble an
>>architecture. We should strive NOT to define an architecture, but rather to
>>describe terms that can be used to build an architecture
>>...
>> > At 05:00 PM 11/15/99 -0500, Stevens, Mark wrote:
>> > >...
>> > >From my perspective, it appeared that we had developed a
>> > >modicum of consensus in the policy working group meeting
>> > >when we heard the suggestion that we define terms that
>> > >describe functional blocks within a policy system. It was
>> > >my understanding of the suggestion to mean that these
>> > >functional blocks would describe necessary and sufficient
>> > >processes within a policy system that when combined in one
>> > >way or another could affect policy in a network. The terms
>> > >you describe below appear to be little more than new names
>> > >for the components of a preconceived architectural model.
>> > >Policy-based networking is more than outsourcing decisions.
>> > >We need to break the process down into functional blocks
>> > >and work from there. Once defined, the functional blocks
>> > >can then be grouped and interconnected with protocols as
>> > >appropriate.
>> > >
>> > >My first pass at functional blocks includes:
>> > >
>> > >Policy Rule - to express a desired outcome of
>> > >              the operation of a service in a network
>> > >
>> > >Policy Processor  - to find and interpret policy rules
>> > >                    by or on behalf of a service
>> > >
>> > >Policy Repository - to store and retrieve policy rules
>> > >
>> > >Policy Interface - to provide an implementation-independent
>> > >                   description of interesting network
>> > >                   services
>> > >
>> > >Policy Proxy - to provide a Policy Interface where none
>> > >               exists
>> >
>> > [js] I think that this is a good start. I do, however, think that we may
>>want to formalize the notion of "translating" the description and/or
>>specification of a policy rule between functional components (e.g., it may
>>need one form in a UI, a different form for storage in a particular type of
>>data store, and yet another form to be applied to a device).
>> 
>> > [js] .... So, I would propose that we go back to Mark's
>>definitions and begin anew.

---

From: Shai Herzog <[email-masked]>
Date: Thu, 23 Dec 1999 16:14:22 -0500

I am not sure if I understood it ;-)

Are you asking me to try and place operations within the functional
blocks?

Shai

At 04:48 PM 12/08/1999, Ron Josephson wrote:
>Hi Shai,
>
>Basically the functional blocks should include the entire cycle, where what
>we're currently doing is to decide which operations should be included in
>each functional block.
>
>I think that the question is too long ;-), could you rephrase it,
>
>Regards,
>
>Ron Josephson
>Digital Intelligence Systems, Inc.
>
>----- Original Message -----
>From: Shai Herzog <[email-masked]>
>To: Ron Josephson <[email-masked]>; John Strassner <[email-masked]>;
>Stevens, Mark <[email-masked]>; <[email-masked]>;
><[email-masked]>
>Sent: Tuesday, November 23, 1999 1:46 AM
>Subject: Re: Consensus ?
>
>
> > For example:
> > IF  (Time-of-day= 9-11am) & (UID = "Shai") THEN  Gold-Service
> >                |
> >                | DECISION (Since Time-of-day=10am)
> >               \|/
> > IF  (UID = "Shai") THEN  Gold-Service
> >                |
> >                | TRANSLATION (UID to IP)
> >               \|/
> > IF  (IP = 200.2.2.2) THEN Gold-Service
> >                |
> >                | DECISION (Gold-Service means marking at the Edge Device)
> >               \|/
> > IF  (Role=Edge-Device) THEN (Mark IP=200.2.2.2 with DSCP=AF1)
> >
> > I could have applied these in any other order and it should still have
> > worked well. I name it ALGEBRA since it reminds me of features of
> > algebra like "transitivity".
> >
> > What do you think?
> >
> > Shai
> >
> >
> >
> > >Hi John,
> > >I agree with the points you've raised here;
> > >
> > >What's needed to be added is a UI which is also a sort of a dumb client:
> > >UI - / / - Client. - Dumb.
> > >
> > >The PDP or PA is in contact with all of the other elements (The middle
> > >Tier), which is basically the Digital Intelligence System.
> > >
> > >I think that we should stop there, meaning to define a set of APIs for
>each
> > >of these elements. We cannot enforce a usage of specific protocols.
> > >
> > >Ron Josephson
> > >Digital Intelligence Systems, Inc.
> > >
> > >----- Original Message -----
> > >To: Stevens, Mark <[email-masked]>; 'Shai Herzog'
> > ><[email-masked]>; <[email-masked]>; <[email-masked]>
> > >Sent: Sunday, November 21, 1999 11:11 PM
> > >Subject: RE: Consensus ?
> > >
> > >
> > > > I agree with Mark's analysis. We have always said that the
>communication
> > >between what Shai terms the PDP and the PEP could be done by a number of
> > >different protocols. I have nothing against COPS, I even like COPS, but
>to
> > >force its semantics down the throat of devices that don't speak it is a
>Bad
> > >Thing.
> > > >
> > > > More specific comments inline, on Mark's and Shai's messages.
> > > >
> > > > regards,
> > > > John
> > > >
> > > > >Perhaps the diesel fumes were getting to me in the meeting
> > > > >on Friday, but I do not remember this terminology, nor do I
> > > > >think that this set of terms moves us closer to consensus.
> > > > >
> > > > >The outsourcing concept that you reiterate has no bearing
> > > > >on policy and the implementation of policy in networks. The
> > > > >request-response pattern of operation is a side-effect of a
> > > > >protocol, not a requirement for implementing policies in
> > > > >network. Purposefully, we are avoiding the discussion of
> > > > >protocols in the policy working group to insure that we
> > > > >don't allow a protocol to interfere with the development of
> > > > >an information-based infrastructure to support policy.
> > > >
> > > > [js] This is a very key point. In fact, the charter of the Policy
> > >Framework wg specifically disallows work on protocols.
> > > >
> > > > >In an earlier version of the policy framework draft we
> > > > >called out functions that we thought would need to exist
> > > > >in a policy system. We elected to omit them from the most
> > > > >recent version of the draft, because it seemed that they
> > > > >were implied by functional groupings that we had become
> > > > >accustomed to using in our discussions. Perhaps we need to
> > > > >jettison our implementation-specific terminology and
> > > > >revisit the basics of the problem before we attempt to
> > > > >name policy system components after modules existing
> > > > >prototypes that implement specific protocols.
> > > > >
> > > > >-Mark Stevens
> > > > >Lucent Technologies
> > > > >
> > > > >> -----Original Message-----
> > > > >> From: Shai Herzog [SMTP:[email-masked]]
> > > > >> Sent: Friday, November 12, 1999 6:37 PM
> > > > >> To: [email-masked]; [email-masked];
>[email-masked];
> > > > >> [email-masked]
> > > > >> Subject: Consensus ?
> > > > >>
> > > > >> Hi,
> > > > >>
> > > > >> During the meeting on Friday (policy terminology) some of us had
> > > > >> seem to converge on terminology. I'd like to lay it down
> > > > >> and test whether we actually do agree on it (and if not, consider
> > > > >> this a continuation to the discussion)
> > > > >>
> > > > >> This family naming scheme came from a discussion we had after the
>WG,
> > > > >> on Friday. (Ed Ellesson "volunteered" to play the "Kid" in a family
> > > > >> where the PA stays at home with the kids, and MA is out at work ;-)
> > > > >> Putting aside the humor in this naming scheme, it may actually be
> > > > >> quite effective in explaining the role of each component.
> > > > >>
> > > > >> 1. The bottom of the food chain is an enforcement device (formally
> > > > >>     known as PEP), which has the ability to actually performs the
> > > > >>     task (service packets, encrypt IPSec, etc.)
> > > > >>
> > > > >>     Lets (temporarily) call it "Enforcement Device" or ED.
> > > >
> > > > [js] I think that any notion of "food chain" is tied specifically to
>an
> > >architectural implementation. I don't think we should pursue this idea or
> > >analogy; we should instead define terminology independent of any specific
> > >architecture.
> > > >
> > > > >> 2. The top of the food chain is a non-volatile repository (formally
> > > > >>     known as LDAP directory). Which is entrusted with storing the
> > >standard
> > > > >>     high level policy in an interoperable format. This storage
>isn't
> > > > >>     necessarily centralized, and may comprise of a set of
>distributed
> > > > >>     repositories.
> > > > >>
> > > > >>     Lets (temp) call it "MA" (Master Archive).
> > > > >>
> > > > >>     [Other options: "ESP" (External Storage Point) or
> > > > >>     GOD (Goals & Objective Directory) have been rejected
> > > > >>     at this time ;-)]
> > > >
> > > > [js] I think that this is incorrect. The "top" of the food chain is
> > >dependent on the specific architecture that one is using. If we have an
> > >architecture that revolves around the repository (e.g., if a new or
>modified
> > >policy rule is received by the system, then it is immediately stored in
>the
> > >repository), then this may be a correct assumption. But there are other
> > >architectures in which the repository is clearly NOT the top of the food
> > >chain. For example, the newly received policy rule may first go to one or
> > >more functional blocks ("PDPs" in your terminology) for examination,
> > >conflict detection, and other types of processing BEFORE the rule is
>stored
> > >in the repository. In this case, the repository is certainly not the
>"top"
> > >of the food chain.
> > > >
> > > > I therefore think that we should abandon the use of a "food chain"
> > >analogy, and strive to remain independent of any one specific
>architectural
> > >implementation.
> > > >
> > > > >> 3. In some cases (Outsourcing or Provisioning), the enforcement
> > > > >>     device needs assistance from an external policy advisor
> > > > >>     (if it is incapable or deficient in policy processing)
> > > > >>     on it's own. (Formally known as "Policy Server").
> > > > >>
> > > > >>     Lets (temp) call it "PA" for Policy Advisor.
> > > > >>
> > > > >>     Unlike ED, PA is totally incapable of actually enforcing
> > > > >>     anything. It is a mere advisor, providing ED with
> > > > >>     instructions, hoping that the "ED" will implement them.
> > > >
> > > > [js] I don't understand this at all. In the original RSVP model, the
>PDP
> > >(your PA) was responsible for providing a decision. So while it is
>incapable
> > >of enforcement, it is certainly more than an advisor. The problem is that
> > >"advisement" means that the decision rendered can be ignored. So, while
>we
> > >all assumed that the PEP could say "no" to the PDP telling it to
>provision a
> > >reservation request, it could never say the opposite (e.g., provision a
> > >reservation when the PDP said not to).
> > > >
> > > > >> 4. As in most application there is a GUI/UI component
> > > > >>     which receives administrator input.
> > > > >>     The Form of this input, or where the GUI is hooked up to
> > > > >>     is totally a vendor dependent issue: for example, some vendors
>may
> > > > >>     have a GUI that is a smart "LDAP Directory Editor", which
>allows
> > >the
> > > > >>     administrator to edit the contents of the "MA", while others
>may
> > > > >>     have a GUI that works directly with the "PA", while the PA
> > >indirectly
> > > > >>     populates the MA repository.
> > > > >>
> > > > >> This 4 components can be viewed architecturally as:
> > > > >>
> > > > >>                 +----------+
> > > > >>    Master       |    MA    |<----+
> > > > >>    Archive      +-----+----+      \
> > > > >>                      /|\           \     +-----------+
> > > > >>                       |  LDAP       >----+    UI     |
> > > > >>                      \|/           /     +-----------+
> > > > >>    Policy       +-----+----+      /
> > > > >>    Advisor      |    PA    |<----+
> > > > >>                 +-----+----+
> > > > >>                      /|\
> > > > >>                       |  Standard Policy Protocols (COPS etc.)
> > > > >>                      \|/
> > > > >>    Enforcement  +-----+----+
> > > > >>    Device       |    ED    |
> > > > >>                 +----------+
> > > > >>
> > > >
> > > > [js] I'm confused by the above drawing, and have the following
>questions:
> > > >
> > > >   - If by master archive you mean any type of data store, why are you
> > > >     limiting the protocol to LDAP?
> > > >   - Are you also implying that LDAP is used between the UI and the MA?
> > > >     If so, I disagree - this is too limiting.
> > > >   - Are you also implying that LDAP is used between the UI and the PA?
> > > >     If so, I disagree - this is too limiting.
> > > >   - The "SNMP crowd" (to use Bert's words) is proposing that they can
> > > >     do policy provisioning using SNMP. This would seem to imply some
> > > >     type of communication between the ED and the MA (and also that
> > > >     the MA is NOT limited to a directory). I would submit that even if
>the
> > > >     actual provisioning is not done thru SNMP, but some other
>protocol,
> > > >     there is not a single master archive, but rather a confederation
>of
> > > >     different types of repositories. I would like to see this
>reflected in
> > >any
> > > >     architectural drawing that we produce.
> > > >
> > > > >> In the outsourcing case: ED has a policy question and it goes to
>ask
> > > > >> PA's advice. PA looks at the policy set by MA, and after careful
> > > > >> consideration provides ED with a reply.
> > > >
> > > > [js] see above comments
> > > >
> > > > >> In the provisioning case: MA sets policy instructions. PA examines
> > > > >> them and gives ED his specific instructions (at his level of
> > > > >> understanding).
> > > >
> > > > [js] Huh? What do you mean by "MA sets policy instructions"? If MA is
>a
> > >directory, as is implied in your diagram (since you are defining LDAP as
>the
> > >protocol for communicating to MA) it most certainly doesn't "set"
>anything -
> > >it is simply a dumb store that happens to contain SOME, but not ALL,
> > >components of a policy rule.
> > > >
> > > > Also, what do you mean by "PA examines them and gives ED his specific
> > >instructions (at his level of understanding)?"
> > > > >> --------------------------
> > > > >>
> > > > >> Now that we defined the basic functional blocks, the next question
>is
> > > > >> what kind of functions are needed to bring the policy set by MA to
> > > > >> the form understood by ED. In the meeting we discussed several
> > >functions.
> > > > >> (Note that this list may not be conclusive; there may be more such
> > > > >> functions to be discovered later.)
> > > > >>
> > > > >> a. Translation
> > > > >>
> > > > >>     "Compilation" of High-Level policy into lower level one.
> > > > >>
> > > > >>     An example could be translation of DNS names or UserIDs into
> > > > >>     IP Addresses. "Gold Service" into AF1, etc.
> > > > >>     The main idea here is that it is pure translation that always
> > >produces
> > > > >>     the same results (w/o taking into account dynamic network
> > > > >> information).
> > > >
> > > > [js] Note that the original proposal defined two possible levels of
> > >translation: high-level (e.g., defined by the network administrator) to
>an
> > >intermediate form that is independent of the specific capabilities of a
> > >device, and intermediate-level to low-level (e.g., a form that is
>specific
> > >to a particular device). This two-level translation is highly desirable,
>as
> > >it enables heterogeneous devices from different vendors to implement the
> > >same policy.
> > > >
> > > > >> b. Decision
> > > > >>
> > > > >>     "considering multiple independent sources of information and
>policy
> > > > >>      to form an "Ad Hoc" lower level policy.
> > > > >>
> > > > >>     An example could be combining congestion information with type
>of
> > > > >> device
> > > > >>     to decide on the class of service a certain flow should be
>mapped
> > >to.
> > > > >>     Naturally a decision may change over time even with the policy
>in
> > > > >>     effect is NOT changed (hence, it is NOT a translation).
> > > >
> > > > [js] So why don't we shows this ability to use different types of data
> > >stores in the policy architecture? This also destroys the "food chain"
> > >argument: a policy rule can represent the overall structure of a policy
>to
> > >be carried out, but its operands could in general come from different
>data
> > >stores. So although the center of attention may be the policy rule, it
> > >certainly isn't any one particular repository.
> > > >
> > > > >> c. Formatting
> > > > >>
> > > > >>     Once either Decision or Translation has been made into lower
>level
> > > > >>     policy it may be the case that the device needs proprietary
>(non
> > > > >>     standard) set of instructions (for instance, a non-COPS legacy
> > > > >> device).
> > > > >>     It may then be needed to reformat the policy instructions into
>the
> > > > >>     proprietary format for this legacy device. This feature was
> > > > >>     previously known as "COPS Proxy").
> > > > >>
> > > > >> So, the overall components may look like:
> > > > >>
> > > > >>
> > > > >>                         +----------+
> > > > >>                         |    MA    |<----+
> > > > >>                         +-----+----+      \
> > > > >>                              /|\           \     +-----------+
> > > > >>                               |  LDAP       >----+    UI     |
> > > > >>                              \|/           /     +-----------+
> > > > >>                +--------------+----+      /
> > > > >>                |             PA    |<----+
> > > > >>                | +------+  +-----+ |
> > > > >>                | |Trans.|  |Dec. | |
> > > > >>                | +------+  +-----+ |
> > > > >>                +--------------+----+
> > > > >>                  /|\         /|\
> > > > >>                   |           |  Standard Policy Protocol (COPS
>etc.)
> > > > >>                  \|/         \|/
> > > > >>                +--+----+   +-------+
> > > > >>                | Format|   |  ED   |
> > > > >>                +-------+   +-------+
> > > > >>                  /|\
> > > > >>                   |              Proprietary Management Protocol
> > > > >>                  \|/
> > > > >>                +--+----+
> > > > >>                | Legacy|
> > > > >>                | ED    |
> > > > >>                +-------+
> > > >
> > > > [js] Ignoring for the moment the problems with the top half of this
> > >drawing, I'm not sure that the new components help. For example, adding a
> > >Translation component to the PA may be correct, but it implies that this
>is
> > >done outside of the device. Otherwise, what is the difference between
> > >"translation" and "formatting"? Especially if you have two different EDs,
> > >made by two different vendors, that have two completely different types
>of
> > >CLIs. The intermediate form may indeed be AFxx, but the device-specific
>form
> > >will be different for each. This, to my way of thinking, is much more
>than a
> > >reformatting - it is another translation, since the two devices may use
> > >different mechanisms to implement the desired service.
> > > >
> > > > >> I do believe that translation and Decision are used in typical
>policies
> > > > >> in any combination and order. I don't see how we can decide one is
>done
> > > > >> prior to the other. In fact, this is where different vendors will
> > >choose
> > > > >> different ways.
> > > >
> > > > [js] Then I don't see how we can ever interoperate. If we instead say
>that
> > >we go from high-level to device-independent (a translation), and then
>from
> > >device-independent to device-specific (another translation), I would
>agree
> > >that we could make decisions before or after the device-specific form. I
> > >don't agree that we could make decisions above the device-independent
>form.
> > > >
> > > > >> There may be other policy related funtions that should reside in
> > > > >> PA: contention resolution, error resolution (where a decision must
> > > > >> change as a result of an error from the device), etc. But we
>haven't
> > > > >> discussed those in the BOF meeting.
> > > >
> > > > [js] I agree that we should discuss additional functions, but think
>that
> > >you are correct in trying to resolve our differences and gaining
>consensus
> > >on this terminology first. So, I would propose that we go back to Mark's
> > > > regards,
> > > > >> Comments? Tomatoes?
> > > > >> Shai
> > > > >> __________________________________________________________________
> > > > >> Shai Herzog, Founder & CTO         http://www.iphighway.com/herzog
> > > > >> Cell: (917) 449-7889                      Parker Plaza, 16th Floor
> > > > >> Tel : (201) 585-0800                                 400 Kelby St.
> > > > >> Fax : (212) 656-1006                             Fort-Lee NJ 07024
> > > > >
> > > >
> > > >
> > > >
> >
> >
> > __________________________________________________________________
> > Shai Herzog, Founder & CTO         http://www.iphighway.com/herzog
> > Cell: (917) 449-7889                      Parker Plaza, 16th Floor
> > Tel : (201) 585-0800                                 400 Kelby St.
> > Fax : (212) 656-1006                             Fort-Lee NJ 07024
> >

__________________________________________________________________
Shai Herzog, Founder & CTO     IPHighway      Cell: (917) 449-7889
400 Kelby St. 16th Fl                         Tel : (914) 654-4810
Fort-Lee NJ 07024                             Fax : (212) 656-1006