Subject: RE: Consensus ?

From: John Strassner <[email-masked]>
Date: Fri, 26 Nov 1999 16:08:05 -0800

Responses inline.

regards,
John

At 03:26 PM 11/23/99 +0200, [email-masked] wrote:
>
>I understand the division between the 
>policy functions and the policy operations.  
>My questions have to do with the operations.
>
>1. I still don't understand how the formatting
>operation differs from the translating one.

Nor do I. See my response to Shair earlier.

>2. I am also still unsure of how a policy is 
>activated, and in what way it is activated.
>As I understand it, we will have both pushed
>and pulled policies.  In this case there will
>need to be some operation that determines how
>a policy is to be handled.

The policy framework must allow both cases (push and pull). Activation of a policy relates directly to how a given policy system works, and therefore can't be specified.

>Also is seems to me
>that there will need to be attributes to a policy
>that determine when it is to be activated and what
>to do with it if it cannot be activated (e.g. rollbacks) 

There is the start of this in the core information model and schema that we have defined in the policy framework wg.

>While policies themselves could be treated as objects,

ummm, they ARE being treated as objects, as described in the drafts of the policy framework wg

>and thus be controlled by the policy mechanisms themselves,

???  Not sure what you mean here. What policy mechanisms are you referring to?

>I don't think this is a good idea - it becomes way too
>complicated.  So how is this operation handled in the 
>current architecture.

Do you mean distributing the policy objects, or accessing them, or what? What specifically is your worry about why either of these operations is way too complicated?

>a.
>-----------------------------------
>avri doria
>+1 617 678 9402
> 
>
>> -----Original Message-----
>> From: EXT Shai Herzog [mailto:[email-masked]]
>> Sent: 22 November, 1999 6:46 PM
>> To: Ron Josephson; John Strassner; Stevens, Mark; 
>> [email-masked];
>> [email-masked]
>> Subject: Re: Consensus ?
>> 
>> 
>> 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.
>> 
>> 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
>> 
>> 
>> 
>> At 12:03 PM 11/22/1999, Ron Josephson wrote:
>> >Hi John,
>> >
>> >I agree with the points you've raised here;
>> >
>> >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?
>> >
>> >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 -----
>> >From: John Strassner <[email-masked]>
>> >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.
>> > >
>> > > 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
>> > >
>> > > More specific comments inline, on Mark's and Shai's messages.
>> > >
>> > > regards,
>> > > John
>> > >
>> > > At 05:00 PM 11/15/99 -0500, Stevens, Mark wrote:
>> > > >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.
>> > >
>> > > >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).
>> > >
>> > > >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
>> >definitions and begin anew.
>> > >
>> > > regards,
>> > > John
>> > >
>> > >
>> > > >> 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
>> 
>