Subject: request for feedback: Policy requirements drafts

From: Hugh Mahon <[email-masked]>
Date: Mon, 19 Jun 2000 13:43:17 -0600 (MDT)

Hi Folks,

        We are interested in getting feedback on the requirements draft 
and a sense of what people in the WG think is missing, could be 
enhanced, etc., in the drafts describing requirements and expected use 
of a policy management system.

        The current revisions of the draft are available at:

http://www.users.uswest.net/~hmahon/draft-ietf-policy-req-02-diffs.txt
http://www.users.uswest.net/~hmahon/draft-mahon-policy-use-00.txt
http://www.users.uswest.net/~hmahon/draft-mahon-policy-mgmt-00.txt

        The documents contain the contents of previous revisions of 
the requirements draft plus other information (change bars are in the 
drafts to show new or changed content from the -01 rev of the 
requirements draft).  The current structure of the documents is in 
response to feedback from the WG that the draft should be shorter but 
the information should be preserved.  

        To leverage from the 'next steps' slide for the requirements 
document:

next steps
    - can continue to add more information, but is there a specific
      direction people would like this to go in?
    - one suggestion for how to proceed is to describe what needs to be
      done to manage QoS in the environment, then describe the
      requirements to support those activities
    - should I go into more detail on the existing usage cases?
    - shorten all of the drafts (with suggestions of what is not 
      important to keep)
    - other feedback, questions?

Thanks,

Hugh Mahon
John Schnizlein

---

From: Jon Saperia <[email-masked]>
Date: Mon, 26 Jun 2000 10:29:03 -0400

on 06/19/2000 3:43 PM, Hugh Mahon at [email-masked] wrote:

Hugh some comments about:

~hmahon/draft-mahon-policy-use-00.txt

First, I find it helpful for work items that are the result of or intended
products of an active WG to be published on the WG page. Helps with
references and keeping current.

Page 4. 

> Policy Management is a way for the Network Administrator to
> pro-actively manage the network, not simply  react  to  how
> users  use  the network.  The intent is to ensure the value
> of a shared resource, which is what the network is, not  to
> take anything away from the users.

The second sentence could use a bit of rewording for clarity. I also have an
issue with what is not included here. Policy is also to cause a consistent
behavior or configuration. For example, I want to have all systems from XYZ
vendor that are model 2's running release 4.4. I want to make sure we
support they type of shared resource provisioning for 'quality of service'
type examples but we should also include examples such as the one I
describe. as well.

Page 7 - 8.

> Once the administrator has authored these rules they  would
> be  committed  to  a repository.  How the Policy Management
> Application chooses to order operations  is  implementation
> dependent, but the Policy Rules must be grouped together to
> form a Policy Group.  Once grouped the Policy  can  option-
> ally  be  run  through tools to determine if there are con-
> flicts between Policy Rules within the Policy.
> 

It may not be obvious to unfamiliar readers what is meant by a policy group
here. I think the document would benefit from a table of terms for rule,
condition, etc. I am aware of the terminology work that has been done in
other documents, but think importing a few terms here would be helpful.

Page 10.

> Once the Policy Rules based configuration has been  sent
> to  the Policy Target(s) the Policy Consumer will deter-
> mine the success of the deployment and provide  feedback
> to  the  Policy  Management  Application.   In  order to
> determine the success, for this example, the Policy Con-
> sumer  will query the device and examine the information
> relating to the configuration of the Policy Target(s) to
> determine if the configuration now matches what the Pol-
> icy Consumer expects based on the Policy  Data.

This is one way of confirming correctness of the configuration operation
which is quite reasonable. Another way would be via exception reporting or
an ack. from the target. That is, an ack confirms correct reciept, i.e.,
success. Error messages can be sent back with what when wrong.

Page 11.

> As  described  above, at the start or end of a time/date
> period expressed in  a  condition  the  Policy  Consumer
> would re-evaluate the Policy Rules for the Policy Target
> and perform the necessary translations,  check  existing
> configuration,  perform  any  necessary clean-up, deploy
> the  corresponding  configuration,  and  report  status.
> (Alternatively  the  Policy  Consumer could generate the
> appropriate information for any given time period speci-
> fied in the Policy Rules and simply download them at the
> appropriate times rather than filter at each time bound-
> ary.)

Also reasonable. Some policy consumers can send to the policy target the
schedule for policy execution. Perhaps this is for a 'policy aware' device?
The point is some devices under policy control will have scheduling
capability locally and all the need is that the policy information contain
this when deployed. This facility does not prevent the other type of
distribution where the policy consumer reloads policy when needed.

Page 16.

> bilities.   A  well implemented Policy Consumer will detect
> any problems with a Policy before deploying it on a  Target
> (if  the  problem  wasn't detected in an automated way ear-
> lier).  If a Policy Consumer does detect such a problem  it
> will provide feedback to the Administrator through the Pol-
> icy Management Repository.

I understand policy consumer to be management application. In this context I
agree that such software should check before deploying a policy. In some
cases only the managed element will know at the time the request is made if
the policy will work or not - this should be the exception.

That said, the exception, that is to say the failed policy deployment should
in my view be stored somewere - the repository is fine. The the event
enunnciation is not via the repository it is via some enunciation software
such as a gui, email, pager, etc.

Page 18.

> Scenario 1 allows for minimal change to the  Core  Informa-
> tion  Model.  It would, however, cause Policies to be clut-
> tered with Policy Rules (or condition lists  within  Policy
> Rules) which only exist to handle contingencies.  Such con-
> ditions which deal with state likely would not be evaluated
> on  the  Policy  Targets  (using  existing  devices  as the
> model), rather they would be evaluated on the  Policy  Con-
> sumer.
> 
> An example of such a state condition could be:
> 
> condition type name: deviceDown
> attributes: device address: 192.168.14.12
> considered down if no contact after: 30
> seconds
> 
> To enable such a  condition,  either  the  Policy  Consumer
> would  need  to poll each of the devices named in each such
> condition, or would need to be notified by some third party
> monitoring  the condition of each device named in each pol-
> icy condition.
> 
> 

I have a bit of a problem with this model in that it is too restrictive. I
have no problem if people want to deploy policy in the fashion you describe
here for failures and architectures should support this - but believe there
is a better approach. Sure, the managed element should keep it's manager
posted as to its status. This can be achieved via asynchronous or polling
methods or a combination of both. In some cases, however; the managed
element (policy target) should have the policy to apply in the case of a
failure and is in the right place to do so rapidly. In SONET networks change
over as a result of failure can take place fairly rapidly (that is the goal
at least). These machines should have the policy to employ locally in the
case of the failure due to time constraints, a polling based approach when
rapid correction is desired would be problematic.  My other concern about
the example is that it is on a device basis. While it is true that entire
devices can fail, it is more true that parts fail or the network
infrastructure that connects them has a failure. so the condition is not
deviceDown, but interface down.

Page 19.

> Scenario  2  would require a change to the Core Information
> Model.  On the association between a Policy and Policy Tar-
> get, there would be conditional associations to other Poli-
> cies.  In the association would be  conditions  similar  to
> those  described  in  Scenario 1, which describe conditions
> under which the Policies for unusual circumstances would be
> deployed.   If  the current indirect model for distribution
> is followed, all of the policies would  be  placed  in  the
> directory  and  the Policy Consumer would obtain all of the
> policies, then change which Policy is deployed to the  Pol-
> icy  Target  on a status change as described in Scenario 1.
> If a more direct model for Policy distribution  were  used,
> then  the Policy Management Application could be enabled to
> change Policy distribution based on state  not  related  to
> traffic based conditions.
> 

This is a bit closer to what I had in mind, except that it assumes that the
policy management application is watching over everything and knows enough
what to do in the case of a failure condition and then loads the correct
policy to the devices it needs to. There is no problem in an architecture
allowing for this type of approach but believe it to be insufficient in many
circumstances. For this reason, a policy application may send to a managed
device the policy to use when things are ok, and the policy to use (perhaps
more than one) when there is a failure.

Page 21.

> 2.6.2.  Snooping Signaling Messages to Glean Classification
> Information

There is no problem in principle with a management application collecting
data from the network and using that for policy setting. My objection is
that the example is RSVP specific and should be in this type of document, I
think more broadly worded. For example, a management application could learn
a lot from other types of instrumentation in the network about who is using
the net, what type of traffic is being sent, etc. Both these examples have
some interesting security implications though.

Page 22.

> 2.6.3.  Offering High Quality Guarantees

My comment about this section is that is why policy is most usefully
expressed in terms of amount of traffic, capacity of a device and
utilization. A device might be configured to deliver a maximum of X voice
over IP sec. I like some of the examples but again find that they are too
restrictive. A policy manager can send information to devices under some
circumstances. In other cases the policy should contain what to do if a
resource is exceeded, or alternatively a second policy would be triggered in
the event of 'oversubscription'. This is not to say that the centralized
policy manager would not have a function in this area since it may monitor
for aggregate usage and cause policies to changes based on state or usage
information from many places in the network.

Page 33.

> 3.  Security Considerations

My problem is not with what is there, but what is missing. Either the list
should be complete or a pointer to other documents provided.  I believe that
user authentication is important for example.

/jon