Subject: RE: Consensus ?

From: Francis Reichmeyer -NJ <[email-masked]>
Date: Sat, 13 Nov 1999 17:36:59 -0500

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:[email-masked]]
> Sent: Friday, November 12, 1999 8:20 PM
> To: 'Shai Herzog'; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> 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:[email-masked]]
> > Sent:	Sat November 13 1999 1:37
> > 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.
> > 
> > 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
>