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

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

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