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

From: "Raju Rajan" <[email-masked]>
Date: Tue, 1 Jun 1999 11:12:14 -0400

Hi Keith,

Thanks for you informative reply. Your reply to my Question 3 says :

> 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.

I agree with your answer about the neccessity of COPS for outsourced QoS
decision making. Further, your answer suggests that COPS is not required in
a network where PDPs are co-located with PEPs. It is this latter point that
I wish to see re-inforced. If data formats for policy errors and device
capabilities (for e.g., "Is RSVP turned on?") will be COPS-PIBS like and not
SNMP-MIB like, then I need COPS in my network, whether or not policy
decisions are outsourced. This is what I'm afraid of.

raju rajan

----- Original Message -----
From: Keith McCloghrie <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, May 26, 1999 9:56 PM
Subject: Re: Suggested new charter for discussion at the interim meeting

> 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).
>
> > 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?
>
> 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).
>
> > 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?
>
> 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.
>
> > 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
notfor
> > IPSec too? I believe there are suggestions to extend COPS to IPSec. It
would
> > be useful to design PIBs with IPSec in mind too.
>
> 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: Andrew Smith <[email-masked]>
Date: Tue, 1 Jun 1999 14:23:30 -0700

Raju,

Let's not get too hung up in this policy framework over what exactly the
device protocols/formats (PEP<->PDP) will be. COPS is good for some of it,
RADIUS for some, SNMPv1/v2/v3 for some. The really important part is that we
achieve real multi-vendor interoperability at this boundary *without*
pseudo-standards (e.g. enterprise SNMP MIBs, enterprise COPS PIBs, RADIUS
vendor-extensions).

Having said that, there does seem to be significant industry momentum
(concensus might be too strong a term) around some form of COPS PIB, at
least in the enterprise-product space, but that is meaningless until there
is a standards'-track proposal and more than a handful of vendors
implementing and shipping it.

Andrew

****************************************************************
Andrew Smith                              tel: +1 (408) 579-2821
Extreme Networks                          fax: +1 (408) 579-3000
3585 Monroe St.                   http://www.extremenetworks.com
Santa Clara CA 95051-1450        em:  [email-masked]
****************************************************************

> -----Original Message-----
> From: Raju Rajan [mailto:[email-masked]]
> Sent: Tuesday, June 01, 1999 8:12 AM
> To: Keith McCloghrie
> Cc: [email-masked]