[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [OPSAWG] [OPS-AREA] Present day reality of COPS-PR
One aspect of this discussion is surprising me a little :-)
For the record, since I am an AD (March 2006) I have never received a
request for chartering a new PIB work in the IETF. Neither have I
received any legacy instructions from my predecessor Bert Wijnen about
new COPS-PR or PIB being a taboo. I think that I know his position, but
this is not necessarily the same as mine. If I ever had received such a
request I would have considered it without prejudice. It's still true
even now. Probably everybody knows by now that I am not a 'one protocol
fits all' adept.
Dan
> -----Original Message-----
> From: David Harrington [mailto:ietfdbh at comcast.net]
> Sent: Wednesday, September 30, 2009 6:34 PM
> To: paduffy at cisco.com; Romascanu, Dan (Dan)
> Cc: opsawg at ietf.org
> Subject: RE: [OPS-AREA] Present day reality of COPS-PR
>
> 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
> > >>>
> > >>>
> > >>
> > >
> > >
> >
> >
>
>