Hi
-----Original Message-----
From: Paul Duffy [mailto:paduffy at cisco.com]
Sent: Wednesday, September 30, 2009 9:57 AM
To: Romascanu, Dan (Dan)
Cc: David Harrington; opsawg at ietf.org
Subject: Re: [OPS-AREA] Present day reality of COPS-PR
Appreciate the investigation, but also agree it needs to be vetted
(academic versus real world deployments).
I absolutely agree that the list needs vetting.
I suspect the claims I have seen might blur the distinction between
COPS-PR and "COPS with some COPS-PR-like proprietary extensions"
For example...
- AFAIK COPS, not COPS-PR, is used for DOCSIS/PacketCable
DQoS. Hope the
rest of the list correctly makes this distinction.
I seem to recall vaguely that COPS-PR was in DOCSIS 1.0, but removed
from 2.0, IIRC.
(Or was that SNMPv3?)
I don't work with DOCSIS standards, so I cannot vet this myself.
- I've not been able to locate any open source community
- I've located a single vendor, Trillium, that offers support
(embedded
in an IMS suite).
I searched the web and found more than just Trillium. YMMV.
- the word from my colleagues @ Cisco is that its time has passed.
Certainly Cisco pulled the plug on it a long time ago.
- etc.
Its pretty clear its not massively deployed.
Neither is Netconf and YANG.
And if the IESG refused to allow any YANG models to advance to
standards track, because the contents would duplicate MIB content,
YANG probably will never get wide deployment.
Should we declare Netconf and YANG Historic as well?
Let's use consistent comparisons if Netconf and YANG are the
replacement for COPS-PR.
Please understand. Up until recently I was fully convinced COPS-PR was
dead. I didn't think declaring it Historic would make any difference
because as far as I knew NOBODY was using it anyway.
COPS-PR only came up when Washam Fan wrote a LOCK-MIB that included a
table for COPS-PR locks (which, as far as I knew, nobody would ever
use). It was there for completeness; COPS-PR is an IETF standard that
has a lock, and so is Netconf. So they should both be included in the
LOCK-MIB. We have LOTS of things in MIB modules that are never used,
so having a potential COPS-PR lock represented was largely meaningless
and certainly not harmful.
But the Netconf community stepped up and said "Hey wait! ****we****
have the only IETF-BLESSED solution for configuration. We need to make
sure this other thing gets declared Historic so nobody will be tempted
to use it instead our solution." I don't think that's the best
justification for declaring something Historic.
At the same time, this WG has been developing a guidelines document,
and during IETF Last Call it was made very clear that the OPS-approach
to management seems too oriented toward routers and device management,
and that approach is NOT IETF-BLESSED as the only approach to
management. Netconf and YANG very much follow that approach. So it
seems apparent that the Netconf/YANG approach is not IETF-BLESSED as
the ONLY way to do configuration management. In fact, the charter for
YANG was required to say that it was ONE language, but not the only
language, that could be used with netconf. And other areas are working
on alternative approaches to configuration.
So I have a real problem with the desire to declare COPS-PR Historic
because Netconf and YANG are BLESSED by the whole IETF to replace
COPS-PR. As the editor for the Guidleines document, I had to deal
directly with the feedback we got, and I do not believe Netconf and
YANG are the BLESSED protocols for doing all configuration in the
IETF.
If you look at COPS-PR, you will also see that COPS-PR does MUCH more
than Netconf. The COPS-PR approach is very oriented toward
policy-based management, with its policy decision points and policy
enforcement points and policy-server discovery and so on. Netconf
doesn't provide those features at all.
I have a history or questioning claims made by the netconf community.
I actually support netconf and YANG, but I think they really need to
stop making inflated claims about what they can do. I think netconf
has standardized some very important aspects of configuration, and I
think YANG may be a very expressive langugae for data modeling. But
they are still unproven in the marketplace. They do not have wide
deployment yet. Cisco doesn't seem at all committed to YANG. Huawei
implemented Netconf, but have no intention that I am aware of to
implement YANG.
I question whether Netconf and YANG replace the functionality found in
COPS-PR. I think it does not. I was around when COPS-PR came out, and
there were aspects that I thought would be useful for management
purposes. My background is in NMS systems, and having to poll whole
ranges of IP addresses to try to find the devices to manage is a
horrible design; letting the devices come to the manager and ask to be
managed makes tremendous sense to me. COPS-PR has that; SNMP and
Netconf do not.
I don't want to throw out the baby with the bathwater in this rush to
declare COPS-PR Historic. There are features in COPS-PR that we should
be looking at to consider what might be good to keep. Declaring the
whole thing Historic is not the right way to do that.
Technologies are converging. I think COPS-PR is more-telco oriented
than Netconf is. The OPS area and the IETF in general are in the midst
of a debate about allowing multiple protocols to be used to manage
networks, rather than trying to force one protocol to be used for all
purposes. We are having a discussion of what OAM means in different
environments. When COPS-PR came out, we had a philosophy of
SNMP-to-do-all-management, and "write a MIB" for all IETF standard
protocols. We have grown significantly in our viewpoints since then,
and are moving toward a "pick the tool that best does the job you need
done". I don't think that declaring COPS-PR Historic at this point in
time helps that. Maybe if we allowed PIBs to be standardized, COPS-PR
would actually get implemented and deployed on a wider basis. I
wouldn't bet on it, but we would be no worse off than we are now.
I don't see the problem inherent in allowing COPS-PR and SPPI to
remain standards, and allowing PIBs to be standards-track, as long as
WGs are not required to write them. We are already allowing WGs to
"pick the tool that best does the job you need done" - including
SNMP, Netconf, Syslog, IPFIX, and others that are being developed in
other areas. Maybe WGs would find COPS-PR to be a valuable tool for
managing Internet resources, such as applications and services, where
Netconf may not be "the best tool". Maybe if PIBs were allowed to be
standards-track, somebody would be willing to make the changes to
COPS-PR to make it more Netconf-compatible.
I just feel like we are trying to declare this Historic for the wrong
reasons.
dbh
Romascanu, Dan (Dan) wrote:
We can write a short cal for input about implementations
and deployments
of COPS-PR on the general IETF list, pointing to the
discussion going on
in OPSAWG. Certainly such input may also arrive at the time
of the IETF
LC but it would be better to know about it earlier.
Dan
-----Original Message-----
From: David Harrington [mailto:ietfdbh at comcast.net]
Sent: Wednesday, September 30, 2009 2:22 PM
To: Romascanu, Dan (Dan); paduffy at cisco.com
Cc: opsawg at ietf.org
Subject: RE: [OPS-AREA] Present day reality of COPS-PR
Hi,
These claims were gathered by me from co-workers familiar
with COPS-PR.
I have not checked any of the claims.
The most interesting to me are the claims of deployment in
FIOS, FT-Orange, and Comcast.
We should seek out people knowledgeable about the
technologies used in these networks, and ask about COPS-PR.
Does anybody have contacts within the IT departments of these
companies?
dbh
-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:dromasca at avaya.com]
Sent: Wednesday, September 30, 2009 7:14 AM
To: David Harrington; paduffy at cisco.com
Cc: opsawg at ietf.org
Subject: RE: [OPS-AREA] Present day reality of COPS-PR
(moving the discussion to OPSAWG).
-----Original Message-----
From: ops-area-bounces at ietf.org
[mailto:ops-area-bounces at ietf.org] On Behalf Of David
Harrington
- 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
There claims need to be examined carefully. We need to
differentiate
between academic papers, code implementation and
deployment. It is
probably true that a number of open source packages and tools
implemented COPS-PR after it was put on standards track, but the
question is to what extent this code was also used and deployed.
Same
for the vendors implementations - was COPS-PR deployed
and how? In
the absence of standards PIBs I suspect that the majority
or all the
deployments use one vendor tools and agents, but we need to give
enough time for these vendors to step ahead and explain in case
interoperability is impacted by the proposed standards action.
Dan