RE: why i should like pibs

["Hahn, Scott" <scott.hahn@intel.com>]

Randy,
Here is a list that Dave Durham recently sent to the RAP mailing list that
answers your question.
	-Scott

--------------------------

* COPS-PR supports a completely transactional model:
	o Messages represent atomic transactions. 
	o All parts of a transaction either succeed or fail.
	o On failure, the device automatically rolls-back to its last
operational state.
	o The server can also quickly switch between provisioned contexts
(eg. from day policies to night policies).
	o Failures and errors are very precisely reported PEP to PDP.
	o Supports large transactions.
	o Implementations do not worry about caching random attributes
waiting for a complete transaction (as is a problem for SNMP), everything in
the transaction comes at once in one message.
* COPS-PR supports structured row-level access:
	o A row represents an atomic unit for data communication.
	o There is no need for rowstatus, owner strings and the like.
	o A row is essentially an indivisible structured data type.
	o OID data is sent only once per row, representing a 10x gain in
on-the-wire efficiency over SNMP for e.g. a packet classifier filter w/ 10
fields.
* COPS-PR supports multi-manager control without the danger of corruption:
	o Each PDP has its own data instance space on the PEP which cannot
be manipulated by other PDPs.
	o PDPs data instances are isolated by the message-level client-type
field.
* Completely event-driven:
	o There is no polling in COPS-PR. 
	o PEPs notify PDPs only when there is something to report and vice
versa.
	o Persistent TCP connection means no 3-way handshake overhead for
messages.
	o TCP heartbeat verifies aggregate communication over the connection
and confirms operational status.
* Multiple Levels of security:
	o COPS intrinsically provides message-level integrity with PEP and
PDP authentication.
	o COPS over TLS provides additional level of authentication and
private communication.
	o IPSec provides yet another level of authentication and privacy. 
	o ... All communication is secure before the first COPS-PR message
is even exchanged. 	
* Object-Oriented Data Model and Data Definition Language.
	o COPS-PR via the SPPI improves the state of the art over the SNMP
SMI.
		- Allows inheritance of data structures.
		- Allows typed references.
		- Allows structured containment.
		- Allows typed associations.
		- Allows typed groupings.
		- Adds support for Integer64 and other basic data types.
		- Maximizes reuse of data definitions.
	o Via the framework PIB provides a data model that can be
reused/shared across PIBs for common/redundant policy functions and
definitions.
	o All new PIB definitions can integrate with existing PIB
definitions to add features and capabilities.
	o Common data-path theme throughout COPS-PR PIBs.
* Capabilities Reporting:
	o COPS-PR via the framework PIB provides a mechanism by which the
PEP clearly yet generically describes what PIBs and parts of PIBs it
supports.
	o Both semantic and syntactic capabilities are generically
communicated PEP to PDP.
* COPS-PR integrates event outsourcing and provisioning:
	o Eg. when an RSVP message is signaled & outsourced PEP-PDP, a
diffserv provisioning policy can be pushed down.
	o Integrated provisioning and outsourcing can be accomplished over
one message RTT. One RTT is critical when the time granularity for 
allocation of resources is dictated by, for example, call setup time.
	o Policy usage information can be used to signal a policy change.
* COPS provides built-in synchronization and failover:
	o PEP automatically moves to backup PDPs on failure.
	o PDP quickly synchronizes state with PEP after communication
failure.
		- Quick last transaction ID verifies PEP state.
		- PDP can resynchronize all or any selected state.
	o Enables quick TCP session recovery.
* COPS-PR inherently was designed to run over reliable transport via TCP.


Well, anyway, these are some of the main reasons for COPS-PR that come to my
mind.

Cheers,
-Dave



> -----Original Message-----
> From: Randy Bush [mailto:randy@psg.com]
> Sent: Monday, March 18, 2002 6:13 AM
> To: rap@ops.ietf.org; diffserv@ietf.org
> Cc: ipsec-policy@vpnc.org
> Subject: why i should like pibs
> 
> 
> wearing my iesg hat but being just a stupid operator, i am trying to
> understand the pib/mib controversy.  fyi, i currently use snmp heavily
> for monitoring devices on my network.  i configure using 
> large db-driven
> code and spew text-based cli to the devices.
> 
> let's assume i want to take the leap to a binary, as opposed 
> to textual,
> configuration language.  i.e. for some reason(s) [which we will PLEASE
> NOT discuss here] i decide to move from pushing text-based cli configs
> out to pushing a binary format.
> 
> hence, i would have to push my vendors to implement snmp/cops 
> writes for
> all configuration aspects of all devices.  this would be big cost for
> both me and for my vendors.
> 
> why would cops/pibs be significantly better (remember it has 
> to replace
> my current investment, so it can not be 'just as good') than 
> snmp/mibs?
> 
> randy
> 
>