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

From: Paul Duffy <[email-masked]>
Date: Fri, 25 Sep 2009 11:44:36 -0400

Folks,

I recently had to do a quick eval re: COPS-PR viability.  Please correct 
as needed, and thanks for your input.

-----------

COPS-PR seems a solution that was looking for a problem.  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.

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

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

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

- there are few, if any, significant deployments.

AFAIK, there is minimal commercial or open source support.

Cheers

---

From: Ron Bonica <[email-masked]>
Date: Fri, 25 Sep 2009 11:54:46 -0400

Paul,

Speaking as an individual contributor, I think that your analysis is on
target. Speaking as AD, I would support a motion to move the COPS
documents to HISTORIC.

                                Ron

Paul Duffy wrote:
> _______________________________________________
> OPS-AREA mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ops-area
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Fri, 25 Sep 2009 18:00:24 +0200

Let us move this discussion to OPSAWG where a proposal was made in
Stockholm on this respect. We need a volunteer to write the RFC. 

Dan

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Ron Bonica
> Sent: Friday, September 25, 2009 6:55 PM
> To: [email-masked]
> Cc: OPS Area (E-mail)
> Subject: Re: [OPS-AREA] Present day reality of COPS-PR
> 
> Paul,
> 
> Speaking as an individual contributor, I think that your 
> analysis is on target. Speaking as AD, I would support a 
> motion to move the COPS documents to HISTORIC.
> 
>                                 Ron
> 
> 
> Paul Duffy wrote:
> > Folks,
> > 
> > I recently had to do a quick eval re: COPS-PR viability.  Please 
> > correct as needed, and thanks for your input.
> > 
> > -----------
> > 
> > - 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.
> > 
> > - IETF has since gone down the path of Netconf and started 
> discussion 
> > to make COPS-PR historical.
> >

---

From: Ron Bonica <[email-masked]>
Date: Fri, 25 Sep 2009 12:11:08 -0400

Sorry. I confused the two mailing lists....

                         Ron

Romascanu, Dan (Dan) wrote:
> .

---

From: "David Harrington" <[email-masked]>
Date: Fri, 25 Sep 2009 18:16:57 -0400

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 

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 

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

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?)

> discussion to

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.

> 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
[email-masked]
[email-masked]
[email-masked]

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Sun, 27 Sep 2009 22:06:17 +0200

I am not really interested to get involved too deeply in this discussion,
certainly not at the level of detail that David does in his repsonse to Paul.

But I would like to comment on one statement from David Harrington,
namely:

  ----- Original Message ----- 
  From: David Harrington 
  To: [email-masked] ; 'OPS Area (E-mail)' 
  Sent: Saturday, September 26, 2009 12:16 AM
  Subject: Re: [OPS-AREA] Present day reality of COPS-PR

  Hi,

This gives the impression that the IESG decided this on her own. The IESG did collect
IETF input in various ways (BOF, info-gathering meetings, plenary discussion etc)
and based on the input concluded that there was (albeit very rough) consensus to not 
support PIB Modules on the standards track.

Bert

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 28 Sep 2009 09:53:25 +1300

> certainly not at the level of detail that David does in his repsonse to Paul.

Ditto, however:

...
> support PIB Modules on the standards track.

I'd like to say, as a case in point, that the diffserv WG produced both a MIB
(because Bert said we had to ;-) and a PIB. The latter (RFC3317) took almost a
year after we'd finished all the core work of the WG, but I've really never heard
of it being used extensively and it was only somewhat supported even while under
active development (see below). What Bert says fits that picture.

    Brian

-------- Original Message --------
Subject: Updated summary Re: diffserv PIB: a question to the WG
Date: Wed, 12 Dec 2001 22:47:35 +0100
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Diff Serv <[email-masked]>
CC: Bert Wijnen <[email-masked]>, Randy Bush <[email-masked]>
References: <[email-masked]>

Summary so far:

Plan to use the PIB: 1
May use and implement the PIB: 1
Implemented/now implementing the draft PIB: 3

Also, the PIB is currently a normative reference in 3GPP.

More replies welcome; anonymity guaranteed if requested.

   Brian

Brian E Carpenter wrote:
>
> Diffservers,
>
> As you know the Diffserv PIB recently passed WG last call, and will be forwarded
> to the IESG as soon as the draft is updated.
>
> Now I have a question, at the request of the Ops and Management Area Directors:
>
> Can anyone who plans to implement the diffserv PIB (or has already done so)
> please let us know? If you don't want to answer on the list, please send
> me a private response.
>
> Thanks
>    Brian Carpenter
>    diffserv co-chair

---

From: "David Harrington" <[email-masked]>
Date: Sun, 27 Sep 2009 18:43:46 -0400

Hi,
 
I did not mean to imply that the IESG did this without following the
normal IETF review process.
I agree it was IETF rough consensus.
 
and I have a typo in that paragraph. 
s/SNMP could work with PIBs/SNMP could not work with PIBs/
 
dbh

  _____  

From: Bert Wijnen (IETF) [mailto:[email-masked]] 
Sent: Sunday, September 27, 2009 4:06 PM
To: David Harrington; [email-masked]; 'OPS Area (E-mail)'
Cc: [email-masked]
Subject: Re: [OPS-AREA] Present day reality of COPS-PR

I am not really interested to get involved too deeply in this
discussion,
certainly not at the level of detail that David does in his repsonse
to Paul.

----- Original Message ----- 
From: David Harrington 
To: [email-masked] ; 'OPS Area (E-mail)' 
Sent: Saturday, September 26, 2009 12:16 AM
Subject: Re: [OPS-AREA] Present day reality of COPS-PR

Hi,

This gives the impression that the IESG decided this on her own. The
IESG did collect
IETF input in various ways (BOF, info-gathering meetings, plenary
discussion etc)
and based on the input concluded that there was (albeit very rough)
consensus to not 
support PIB Modules on the standards track.
 
Bert

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 29 Sep 2009 09:23:05 +0200

> Stockholm on this respect. We need a volunteer to write the RFC. 

I have posted <draft-schoenw-opsawg-copspr-historic-00.txt> and all
followup discussion should take place on the OPSAWG mailing, as
suggested by Dan.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>