Shai,
I agree with the functions identified and the naming used. They are the basic functions we need (one might want to break into sub functions later).
From a product development perspective one concern I have is the line from "format" to 'legacy". I do not honestly believe that any company (at least for the near future) will stick to all the parms the way we (IETF) define. If it changes any parm (adds/ deletes/extends) it will need formatting. Then does it become a legacy node ?.
Also answering someone else's question : yes we will have several PAs talking to one ED (failure recovery for example will need it). But one PA will be in control at a time. This is an implementation aspect.
Good job.
cheers,
Anruda (Anurudha) Kulatunge,
Service Management, Broadband Wireless Acess,
Nortel Networks
-----Original Message-----
From: Shai Herzog [SMTP:herzog@iphighway.com]
Sent: Friday, November 12, 1999 5:36 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