Subject: RE: Consensus ?

From: "Ken Roberts" <[email-masked]>
Date: Mon, 29 Nov 1999 13:08:04 -0500

My $0.02 worth, comments inline.
I believe this to be a productive line of discussion.

--------------------------------------------------------------------------
Regards,
Ken Roberts
INM Product Architecture
Nortel Networks
?ESN   :        655-7844			?Direct  : 408-565-7844
?  Fax    :        408-565-8226
? email :      [email-masked]
 
This message may contain information proprietary to Nortel Networks
Corporation so any
unauthorised disclosure, copying or distribution of its contents is strictly
prohibited.

 -----Original Message-----
From: 	[email-masked] [mailto:[email-masked]] 
Sent:	Tuesday, November 23, 1999 5:27 AM
To:	[email-masked]; [email-masked]; [email-masked]
Subject:	RE: Consensus ?

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.

2. I am also still unsure of how a policy is 
activated, and in what way it is activated.
>> To my way of thinking policy activation is a property of the policy.
Namely what has been called "Administrative >>Aspects" in other standards.
This covers such interesting things as security, ownership, activation,
de-activation, etc. >>Our current models do not accommodate this concept but
hopefully will in the [not to distant] future  in the meantime >>for further
info I recommend X.749.
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. 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) 
>>Agree! Policies will be formulated and executed at differing times and
situations will change perhaps making policy >>condition un-executable. This
is really a "run-time" violation and its resolution is another policy (IMO).
While policies themselves could be treated as objects,
and thus be controlled by the policy mechanisms themselves,
>>Management of the policy system can be a "self-managed" thing with
recursion being applied. I believe there will be >>policies that talk to
other aspects of management (i.e. business/service/ policy management et
al). The only >>complication I see is if the system is inflexible such that
each and every interaction must be pre-conceived and coded >>for - in effect
prohibiting the user from making mistakes. The user must take responsibility
for what policies they enact >>and what complication they create so in this
vein I believe it is OK for policy management to be managed by policy.
I don't think this is a good idea - it becomes way too
complicated.  So how is this operation handled in the 
current architecture.

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
>