[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Consensus ?
Dan,
Way back when, when we had PDPs and PEPs (sounds like a story
a PA would tell, "Back when I was an ED... " :^) we allowed the
scenario you described in question 1 and said that conflicts would
be handled by only allowing a single PDP to set any particular
policy-related configuration paramter. You could have two PDPs
talking to a PEP, each one responsible for setting separate
parameters. In this case, the PEP would have to tell PDPs what
policies they expected to receive configuration info for, from
each one.
I would assume the same model would hold for PAs and EDs as well.
Thanks,
-Fran
> -----Original Message-----
> From: Dan Romascanu [mailto:dromasca@lucent.com]
> Sent: Friday, November 12, 1999 8:20 PM
> To: 'Shai Herzog'; Polterm@ops.ietf.org; mumble@ops.ietf.org;
> policy@raleigh.ibm.com; rap@iphighway.com
> Subject: RE: Consensus ?
>
>
> Shai,
>
> Two clarification questions:
>
> 1. Can ED have several PAs? (maybe specialized in
> 'advising/parenting' on
> different types of policies). If you answer me yes, I would
> be happy if you
> can explain me shortly how you solve the potential conflicts
> 2. Is the arrow labeled by you 'Standard Policy Protocols (COPS
> etc.)' the Configuration Protocol that was discussed in the
> BOF on Thursday?
>
> Thanks and Regards,
>
> Dan
>
>
>
>
> > -----Original Message-----
> > From: Shai Herzog [SMTP:herzog@iphighway.com]
> > Sent: Sat November 13 1999 1:37
> > 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
>