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

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

Hi,

To be clear, I did not come to this discussion to compare COPS-PR to
Netconf either.

I came to this discussion because two documents I am associated with
contained reference to COPS-PR, and members of the Netconf/YANG
community reacted strongly to its being mentioned in documents, and
wanted it declared Historic and the references removed from the two
documents. 

The proposed document for declaring COPS-PR Historic originally said
that all IETF configuration work is now centered on Netconf and YANG.
I dispute that all IETF configuration work is now centered on Netconf
and YANG. (This claim has been limited in -01-, but -01- still does
mention that other areas are considering other alternatives.)

As a result of this discussion occuring in IETF, we have found that
COPS-PR is in real-world use (although we need to vet the claims to
understand the extent of deployment).

In the course of this discussion, most of the reasons given for not
approving any PIBs for standards-track could equally apply to YANG
models, with an expected similar result of non-deployment. Andy
Bierman has been arguing that we need to get some standard YANG data
models, or Netconf will likely die.

The arguments that COPS-PR and PIBs lack wide deployment could also be
applied to YANG and Netconf. The fact that COPS-PR does not have wider
deployment may be directly related to a lack of standard PIBs.

I do not believe Netconf does a good job of replacing all the
functionality found in COPS-PR. Declaring COPS-PR Historic, and
continuing to explicitly discourage its use, denies the IETF a
potentially useful tool for managing technologies where a policy-based
management approach might make sense.

I question the need to declare COPS-PR et al Historic.

dbh

> -----Original Message-----
> From: Paul Duffy [mailto:paduffy at cisco.com] 
> Sent: Wednesday, September 30, 2009 1:20 PM
> To: David Harrington
> Cc: 'Romascanu, Dan (Dan)'; opsawg at ietf.org
> Subject: Re: [OPS-AREA] Present day reality of COPS-PR
> 
> Understood.  And to clarify, I (just me) came to this 
> discussion just to 
> confirm real world reality of the COPR-PR ecosystem, not to compare 
> COPR-PR to NETCONF.
> 
> As an aside, I don't get the need for YANG, but that's just me  ;)
> 
> 
> 
> David Harrington wrote:
> > 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
> >>>>>
> >>>>>       
> >>>>>           
> >>>>     
> >>>>         
> >>>   
> >>>       
> >>     
> >
> >
> >   
> 
>