Subject: Consensus ?

From: Shai Herzog <[email-masked]>
Date: Fri, 12 Nov 1999 18:36:30 -0500

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

---

From: Keith McCloghrie <[email-masked]>
Date: Mon, 15 Nov 1999 14:33:25 -0800 (PST)

Shai,

I understand MA, PA and ED, but I have a comment and a question regarding:
Translation versus Decision versus Formatting.

First, I suggest that "formatting" goes with "translating" and "deciding".
To go with "Translation" and "Decision", it needs to be something like
"Formation".

Second, draft-ops-mumble-conf-management-00.txt defines three terms:

 - "Network-Wide Configuration",
 - "Device-Local Configuration", and
 - "Configuration Data Translator".

For example: "Device-Local Configuration" can be per-interface config,
and "Network-Wide Configuration" can be per-role config.

To further understand these, consider:

a. With today's standards for provisioning, PA would perform the
   translation of "Network-Wide Configuration" into "Device-Local
   Configuration", and use SNMP or CLI to download the "Device-Local
   Configuration" into ED.

b. In the future, we anticipated that PA would use COPS-for-PR (or an
   enhanced-SNMP) to download "Network-Wide Configuration" to ED, and
   ED would perform the translation of "Network-Wide Configuration"
   into "Device-Local Configuration".

The function described as "perform the translation" in both the above
paragraphs was defined as the "Configuration Data Translator".

So, my question is in regards to how this "Configuration Data Translator"
equates to your functions: Translation, Decision and Formatting ??

Note that the "Configuration Data Translator" is done after the data is
transported by COPS (see b. paragragh above), and thus, does not appear
to be any of those you show in your "overall components" picture below.

Keith.