[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
>