Re: [OPS-AREA] Present day reality of COPS-PR

["David Harrington" <ietfdbh at comcast.net>]

Hi,

comments inline. I can help with the RFC. here's a start ... ;-)

> COPS-PR seems a solution that was looking for a problem.  

I disagree. The problem - how to standardize configuration - had been
talked about in the OPS area for years. COPS-PR was designed to solve
that problem. 

COPS-PR also addressed some related issues:
	1. how to do policy-based configuration
	2. how to do policy-server discovery
	3. how to separate policy distribution from policy
enforcement.
	4. how to do vendor-specific enforcement behind standardized
policies

> It never 
> really took off, for the following reasons....
> 
> - most, if not all, of what could be done with COPS-PR/PIBs 
> can be done
> with SNMP/MIBs. To do both is significant duplicated effort.

That is true, and that is what really killed it in IETF, where there
was a policy that all WGs were expected to "write a MIB" to make their
protoocls manageable. The IESG decided that they could not insist that
WGs duplicate effort by writing both a MIB and a PIB, but SNMP could
work with PIBs (and it would not have been easy to make that work), so
just "write a PIB" for both COPS-PR and SNMP usage was not a viable
option either.

Most of what can be done with PIBs could be done with MIBs, but
wildcarding and other policy specification cannot be done easily with
MIBs. SPPI added extensions to SMI to address those limitations. 

Much of what can be done with COPS-PR can be done with SNMP, but only
in an assembly language (or peek/poke) style, and only when the SNMP
agent actually supports both the SET command and secure
communications. To a large degree, since we are considering reality,
SNMP cannot do what COPS-PR was designed to do because SET is not
supported consistently, and SNMPv3 security is still not supported
consistently. COPS-PR added functionality that knew how to work with
the SPPI extensions (such as wildcard evaluation/expansion); SNMP does
not have that functionality. 

The SNMPCONF WG tried to do something similar to what COPS-PR did,
using scripting, and failed to catch anybody's interest. Operators
have made it clear that a standardized scripting language (ala
SNMPCONF) and or a standardized approach to support scripting in a
variety of languages (ala SCRIPT-MIB) is not of much interest. 

Architecturally, the IETF had an established framework (RFC1052) for
doing all network management using MIBs, and mostly using SNMP as the
protocol. COPS-PR was not consistent with the prevailing IETF
architecture.

Operationally, A policy-driven approach demands a single decision
point to ensure consistent policy. The COPS-PR global lock and
modification overwrites prevented operators from easily modifying the
policy-driven devices using other NM interfaces, such as SNMP and the
CLI. This was extremely unpopular with operators.

Operators made it very clear that the COPS-PR approach of using
standardized polices with vendor-specific enforcement mechanisms made
the enforcement non-deterministic, and allowing enforcement procedures
to be changed by vendors during software updates, was totally
unacceptable.

Politically, the SNMP community had gone through the SNMPv2 wars and
were not allowed to address anything other than security for a number
of years. The SNMP community was not allowed to address configuration
and policy-based management, but the COPS-PR WG did so in the
background (in a different IETF area, if I recall correctly). Some
COPS-PR advocates were very vocal that their intention was to replace
SNMP, totally. In response, many in the SNMP community fought hard to
ensure that COPS-PR did not get accepted.

> 
> - operators don't want binary PIBs, prefer ASCII based 
> CLI-type interfaces.

Involved operators made it clear they preferred an ASCII protocol so
they could see the commands on-the-wire, and an ASCII (or XML) data
modeling language rather than SMI, with its OID labeling and
two-dimension tables and no nesting.

I think they made it less clear that operators seem to prefer a
task-oriented interface, like a CLI, rather than a database-driven
approach like MIBs and PIBs. YANG will be an interesting test of
whether an XML-database approach can work to replace an ASCII
task-oriented CLI for configuration.

> 
> - key players (who?) withdrew from COPS-PR and PIB approach,
claiming
> there was no market.

Probably the most important were Cisco, Intel.
Probably the most important SDO that suppoprted COPS-PR and then
withdrew support (they would use it if it was available, but if it
wasn't available they'd find another solution) was 3GPP (or was it
3GPP2?)

> 
> - IETF has since gone down the path of Netconf and started 
> discussion to
> make COPS-PR historical.

Following long discussions with operators, in many venues, netconf was
specifically designed to match what the operators told us they wanted.

Venues included the IAB Workshop (RFC3535), the Dilbert mailing list,
the "world Tour" meetings at NANOG, RIPE, APRICOT, etc.

> 
> - there are few, if any, significant deployments.
> 
> AFAIK, there is minimal commercial or open source support.

I have not been able to research these claims, but I am told that
COPS-PR is actually in use in a number of places. Here are some of the
claims I have heard:

1) Juniper uses COPS-PR for their resource allocation, using both push
and pull methods, at least in the access and aggregation network. 
2) COPS-PR may be deployed in the Verizon FIOS (FTTH) access network
in the US.
3) COPS-PR may be deployed in the FT-Orange IPTV access network in UK.
4) Comcast uses a mix of COPS and COPS-PR in cable TV video QoS
control. 
5) COPS-PR is in DOCSIS 1.0 QoS, which may still be used in cable
deployments
6) Huawei uses both COPS and COPS-PR in their Quidway RM9000 Resource
Manager and their Multi-Service Control Gateway solution (public
documents show COPS, but I have not found explicit mention of COPS-PR;
I am checking further)
7) ITU-T has a proposal being considered that is based on COPS-PR

Searching the Web I found some additional information that might bear
further research (many items have no associated dates):
8) MultiService Forum has an Implementation Agreement for Dynamic
Policy Control Using COPS-PR (2005)
http://www.msforum.org/techinfo/approved/MSF-IA-COPS-PR.001-FINAL.pdf
9) IEEE Xplore has a paper that apparently was presented at ICT 2008
comparing the performance of COPS-PR and Netconf. The paper might
identify some equipment that has COPS-PR support.
10) A 2006 paper was published in the Proceedings of the IEEE
International Workshop on Policies for Distributed Systems and
Networks. The paper considers substituting Netconf and/or SOAP for
COPS-PR
11) I found discussion of COPS-PR in JUNOSe and the SAE on the web,
apparently for the SDX line (dated 2008). Was this from the Juniper
acquisition of netscreen and neoteris?
12) Sejong University apparently has developed a COPS-PR lite
http://ietcom.oxfordjournals.org/cgi/content/abstract/E90-B/11/3024
13) EION has an implementation
http://www.eion.com/protocols/protocols_traffic_cops.html
14) Cisco Catalyst has an implementation
15) Wireshark apparently implements it
16) ACSE Networks implements COPS-PR in their NeuTrans product line
17) ZNYX Networks implements COPS-PR in the ZX4900
18) libsmi implemented it
19) Operax AB implemented it
20) MIB Smithy implemented it
21) GridNet has implemented it in its products for managing utility
(power) grids
22) GE apparently embeds the GridNet implementation in its WiMax
SmartMeter and SmartGrid Router family of products
23) COPS-PR has been the subject of a tremendous number of academic
papers

David Harrington
dbharrington at comcast.net
ietfdbh at comcast.net
dharrington at huawei.com