Subject: RE: Suggested new charter for discussion at the interim meeting

From: Andrew Smith <[email-masked]>
Date: Wed, 26 May 1999 11:09:15 -0700

John,

Your discussion includes the paragraph:

"The PIB represents a
“missing link” between device-specific parameters, such as those
stored in a MIB, and the higher-level policies that are expressed in
the QoS schema. It is proposed that this working group take on this
work as part of a coherent strategy to link policies expressed as
business rules to how they are implemented in devices."

but then the proposed charter and deliverables does not address PIBs or
MIBs. Is this omission an oversight or by design?

Do you have a vision for how we can most efficiently produce the actual
syntactical definitions of PIBs and MIBs for RSVP and DiffServ? ISSL WG has
some fairly detailed work in progress on DiffServ (see
draft-ietf-diffserv-model-01.txt) and a DiffServ MIB is also in the works in
the DiffServ WG (I think) based on this. There are RAP WG charter revisions
under discussion to include syntactical definition for a DiffServ PIB (based
on draft-ietf-diffserv-model-01.txt semantics) to be transported in COPS. 

Andrew Smith 
RAP WG co-chair

> -----Original Message-----
> From: John Strassner [mailto:[email-masked]]
> Sent: Wednesday, May 26, 1999 9:11 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Suggested new charter for discussion at the interim meeting
> Importance: High
>

---

From: "Raju Rajan" <[email-masked]>
Date: Wed, 26 May 1999 15:20:19 -0400

John and Ed,

Following Andrew's note on PIBS, I too have the following comments and
questions regarding the use of PIBs.

1. I agree that we need means of recording PEP capabilities, so that policy
servers and other management entities may query a network device (say a
router) and figure out whether it is RSVP aware, or DS capable or whatever,
and the service types it supports (controlled load, expedited forwarding
...).
Are we using PIBs to be the common information model to record this
information? Why cant we use MIBs to do the same job?

2. Further, during the operation of the device we may need to store certain
device states that are germane to policy. These could include link
utilization or policy errors or warnings about imminent policy failure.
These too need to be stored and dynamically retrieved by policy
servers/management tools. Do we intend to use PIBs for this purpose too? Why
not MIBs?

3. If the use of PIBs is to put in hooks through the policy working group so
that COPS may be the carrier of this information at a later date, I say
great! But let's say so right up front, so that those of us interested in
design/implementation can take a closer look at how it all fits together,
what works, what doesn't and build it right. If PIBs are to be an essential
component of the architecture, then let's not pretend in various
architectural drawings that an LDAP-only router solution is even supported.
We are saying that QoS policy is impossible without COPS. (I have no problem
with such an architecture, and to the best of my knowledge, neither does
AT&T :)

4. If we have PIBs in the architecture for QoS, one would wonder why not for
IPSec too? I believe there are suggestions to extend COPS to IPSec. It would
be useful to design PIBs with IPSec in mind too.
raju rajan

----- Original Message -----
From: Andrew Smith <[email-masked]>
To: 'John Strassner' <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>; 'Scott
Bradner' <[email-masked]>; <[email-masked]>
Sent: Wednesday, May 26, 1999 2:09 PM
Subject: RE: Suggested new charter for discussion at the interim meeting

---

From: Keith McCloghrie <[email-masked]>
Date: Wed, 26 May 1999 18:56:38 -0700 (PDT)

Raju,

On day-one of SNMP, each device had at most one agent and that agent
was for its device.  Not too many years later, we had multiple agents
in a single chassis, agents with multiple logical devices, proxy agents
handling requests for multiple devices, etc., etc.  I can't predict
whether the same will the same happen for PEPs.  In any case, an issue
when using both MIBs and PIBs will be that the COPS agent will not
necessarily be one-to-one with an SNMP agent (or, a contextEngineID
and contextName, see RFC 2571).

> and the service types it supports (controlled load, expedited forwarding..).

In this case, because you're asking about (static) "PEP capabilities",
use of the PIB ensures that you get the right information, irrespective
of the relationship between the PEP and associated SNMP agent(s).

> servers/management tools. Do we intend to use PIBs for this purpose too? =
> Why not MIBs?

The COPS protocol contains error/warning codes about policies previously
downloaded to that PEP.  Other network states which might be "germane to
policy" seem to me to be appropriate for MIBs.

> with such an architecture, and to the best of my knowledge, neither does

I've not heard people say "QoS policy is impossible without COPS".
Rather, I think we've said that it's essential to allow the PEP and PDP
to be separated (to introduce hierarchy, and therefore scaleability),
and that COPS is being specified as a standard protocol for PEP-PDP
communication.

> 4. If we have PIBs in the architecture for QoS, one would wonder why notfor

I presume you mean to define the PIB definition language with IPSec in
mind, rather than to define a QoS PIB with IPSec in mind, yes ?

Keith.

---

From: John Schnizlein <[email-masked]>
Date: Thu, 27 May 1999 09:26:16 -0400

At 06:56 PM 5/26/99 -0700, Keith McCloghrie wrote:
> in reply to Raju Rajan's:
>> 3. If the use of PIBs is to put in hooks through the policy working 
>> group so that COPS may be the carrier of this information at a 
>> later date, I say great! But let's say so right up front, so that 
>> those of us interested in design/implementation can take a closer 
>> look at how it all fits together, what works, what doesn't and build 
>> it right. If PIBs are to be an essential component of the architecture, 
>> then let's not pretend in various architectural drawings that an 
>> LDAP-only router solution is even supported.
>> We are saying that QoS policy is impossible without COPS. 
>> (I have no problem with such an architecture, and to the best of 
>> my knowledge, neither does AT&T :)
>

We should recall the point of view that directories were designed 
around hierarchy, so that hierarchy was introduced with LDAP,
although LDAP relaxes the obsession with hierarchy in X.500.

A more central question is if the hierarchy of the directory
(more attention needed on the containment issues Lee raised in MN)
is sufficient. And the question of how dynamic policy propagation is
needs to be resolved. Before MN, drafts differed in whether policy
should be distributed through an event notification mechanism. 
Everyone seemed to agree signalling between nodes is necessary.

It seems to me that policy can be static enough for the propagation
speed of directory replication (which provides both reliability and
distribution) if "policy" is defined as those rules the administrator
wants enforced across all the state transitions in the network.
This returns us to the question of "What is policy?" in a way that
relates directly to the architecture, assuming the hierarchy in the
directory can be used effectively to represent the semantics of policy.

If we don't get consensus on the question if policy should be declarative
or procedural, it is not clear we can get in on other questions.

John