Subject: RE: Consensus ?

From: "Stevens, Mark" <[email-masked]>
Date: Mon, 15 Nov 1999 17:00:35 -0500

Perhaps the diesel fumes were getting to me in the meeting
on Friday, but I do not remember this terminology, nor do I
think that this set of terms moves us closer to consensus. 

The outsourcing concept that you reiterate has no bearing
on policy and the implementation of policy in networks. The
request-response pattern of operation is a side-effect of a
protocol, not a requirement for implementing policies in 
network. Purposefully, we are avoiding the discussion of 
protocols in the policy working group to insure that we 
don't allow a protocol to interfere with the development of
an information-based infrastructure to support policy.

From my perspective, it appeared that we had developed a
modicum of consensus in the policy working group meeting
when we heard the suggestion that we define terms that 
describe functional blocks within a policy system. It was
my understanding of the suggestion to mean that these 
functional blocks would describe necessary and sufficient
processes within a policy system that when combined in one
way or another could affect policy in a network. The terms
you describe below appear to be little more than new names
for the components of a preconceived architectural model. 
Policy-based networking is more than outsourcing decisions.
We need to break the process down into functional blocks
and work from there. Once defined, the functional blocks
can then be grouped and interconnected with protocols as
appropriate.

My first pass at functional blocks includes:

Policy Rule - to express a desired outcome of
              the operation of a service in a network

Policy Processor  - to find and interpret policy rules
                    by or on behalf of a service

Policy Repository - to store and retrieve policy rules

Policy Interface - to provide an implementation-independent
                   description of interesting network
                   services

Policy Proxy - to provide a Policy Interface where none
               exists

In an earlier version of the policy framework draft we 
called out functions that we thought would need to exist
in a policy system. We elected to omit them from the most
recent version of the draft, because it seemed that they
were implied by functional groupings that we had become
accustomed to using in our discussions. Perhaps we need to
jettison our implementation-specific terminology and 
revisit the basics of the problem before we attempt to
name policy system components after modules existing 
prototypes that implement specific protocols.
  
-Mark Stevens
Lucent Technologies 

> -----Original Message-----
> From:	Shai Herzog [SMTP:[email-masked]]
> Sent:	Friday, November 12, 1999 6:37 PM
> 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