[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Consensus ?
I completely agree that we should focus on doing FUNCTIONAL
blocks simillary to what diffserv WG has done for example in
"A Conceptual Model for Diffserv Routers"
(draft-ietf-diffserv-model-01.txt).
We should have a similary model but for a Policy based concept.
// Patrik Lindergren
----- Original Message -----
From: Francis Reichmeyer -NJ <FranR@iphighway.com>
To: Shai Herzog - NJ <herzog@iphighway.com>; <Polterm@ops.ietf.org>;
<mumble@ops.ietf.org>; <policy@raleigh.ibm.com>; rap <rap@iphighway.com>
Sent: den 14 november 1999 00:13
Subject: RE: Consensus ?
> Overall, I've got no problem with the terminology
> propsed here. I see it as expanding on the "functions"
> that were discussed in the presentation in the polterm
> BOF by removing the arrows from the individual functions
> given in the BOF (this is a good thing since more than a
> few people noted that the functions themselves may actually
> be carried out in more than one place in the policy system).
>
> I would like to see emphasized in the discussion below that
> the boxes shown are FUNCTIONAL blocks and not system components.
> These functional blocks may reside in different components in
> different systems, especially the PA and ED functional blocks,
> depending on the implementation.
>
> -Fran
>
> > -----Original Message-----
> > From: Shai Herzog [mailto:herzog@iphighway.com]
> > Sent: Friday, November 12, 1999 6:37 PM
> > To: Polterm@ops.ietf.org; mumble@ops.ietf.org; policy@raleigh.ibm.com;
> > rap@iphighway.com
> > 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.
> >
> > 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 ;-)]
> >
> > 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.
> >
> > 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 |
> > +----------+
> >
> >
> > 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.
> >
> > In the provisioning case: MA sets policy instructions. 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).
> >
> > 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).
> >
> > 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 |
> > +-------+
> >
> > 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.
> >
> > 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.
> >
> > 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
> >
>