Subject: RE: Consensus ?

From: "Anurudha Kulatunge" <[email-masked]>
Date: Mon, 15 Nov 1999 17:26:30 -0600

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:[email-masked]]
> Sent:	Friday, November 12, 1999 5:36 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