Subject: [OPS-NM] Question about draft-xu-cops-push-00.txt

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Tue, 13 Mar 2007 02:48:25 +0200

I have a question related to
http://www.ietf.org/internet-drafts/draft-xu-cops-push-00.txt, which
will be the subject of a mini-BOF in the OPS Area meeting in Prague. The
document describes an optimization of COPS so that it can be used in a
push mode at a degree of efficiency that is similar to the one of the
pull mode for which the protocol was originally designed. What are the
use cases and application or applications that require using COPS in a
push mode? And if push mode is required, than why COPS? 

Thanks and Regards,

Dan

_______________________________________________
OPS-NM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ops-nm

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 13 Mar 2007 16:02:57 -0400

The other individuals copied on this response are probably better qualified to 
answer, but I'll have a go.

The architecture, using ITU-T terminology, is as follows: the Policy Decision 
Function (PDF) sets policy. The Transport Enforcement function (TEF) enforces 
the policy. The interface between them is variously designated Rw (in the 
ITU-T), Ia (in TISPAN), Go/Gx (in 3GPP), or TC-1 (in the MultiService Forum). 
The particular role of the Rw interface is to carry admission decisions and 
related material such as NAT configuration requests and responses.

To broaden the picture, the Policy Decision Function gets requests from the 
P-CSCF (more abstractly, the Service Control Function, SCF). That interface is 
designated Rs in the ITU-T, Gq' in TISPAN, Gq in 3GPP, and TC-0 in the 
MultiService Forum. Everyone agrees that the protocol across that interface is 
Diameter, but there is variation in the AVPs that have to be supported.

The SCF, PDF, and TEF interact on a per-session basis. Whether push or pull mode 
is used depends on signalling capabilities at the user terminal and the access 
technology in use. That can vary from session to session.

To take the push mode example: suppose the terminal is unable to signal at the 
transport level (e.g. using RSVP or NSIS). Then the network has to act on its 
behalf. The terminal sends a SIP INVITE with SDP to the P-CSCF. The P-CSCF 
analyzes the SDP to determine the implied QoS requirements and the external 
transport addresses associated with the flow and passes an admission request on 
to the PDF. The PDF checks its sources of policy information to decide whether 
the flows can be admitted; if so, it sends a request down to the TEF to admit 
the flow and set up NATing (if applicable). The TEF returns the NAT address 
assignments, which the PDF passes back to the SCF in its response to the 
original request.

A pull mode example is probably more familiar, so I won't go into detail.

My co-authors can better explain the choice of COPS. Back when they first 
started this work, the industry had not yet made a choice between COPS and other 
protocols, so their decision was reasonable. I should mention that the ITU-T is 
also working on draft Recommendations based on H.248 (like the TISPAN Ia 
interface) and on Diameter. Diameter presents similar problems to COPS, in that 
the natural roles of client and server are reversed when moving from pull to 
push mode.

Romascanu, Dan (Dan) wrote:
> OPS-AREA mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ops-area
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 15 Mar 2007 08:24:41 +0100

On Tue, Mar 13, 2007 at 04:02:57PM -0400, Tom-PT Taylor wrote:
 
> My co-authors can better explain the choice of COPS.

So can one of your co-authors please speak up and address Dan's
question in technical terms?

In particular, I like to know what you consider the essential
technical features making COPS-PR more desirable than other protocols
to push configuration information (like NETCONF) that seem to have
gained more community support during the last few years (at least in
the IETF).

/js

-- 
Juergen Schoenwaelder		 Jacobs University Bremen
<http://www.eecs.iu-bremen.de/>	 P.O. Box 750 561, 28725 Bremen, Germany

---

From: "xuheyuan" <[email-masked]>
Date: Thu, 15 Mar 2007 22:19:18 +0800

At that time the Re reference point, merged into Rw reference point later, controlled the IP edge, actually an IP-IP gateway. In the current network, most existing IP-IP gateways are routers, which support COPS already. In reality, using COPS is the quickest way to do that as described in approach 2 in this draft. 

COPS-PR by nature does policy control, Rw interface  mainly does policy control dynamically, not just push configuration information. Besides,  in 2005,NETCONF was a pretty new protocol, and few existing routers supported NETCONF.

As RACF supports both fix and mobile, push and pull modes, in the real networking, PD-FE may possibly support both modes, and in pull modes, COPS is very effective, so, in push mode, if approach 2 COPS could be adopted, it will simplify the implementation.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 15 Mar 2007 15:46:31 +0100

On Thu, Mar 15, 2007 at 10:19:18PM +0800, xuheyuan wrote:

> At that time the Re reference point, merged into Rw reference point
> later, controlled the IP edge, actually an IP-IP gateway. In the
> current network, most existing IP-IP gateways are routers, which
> support COPS already. In reality, using COPS is the quickest way to
> do that as described in approach 2 in this draft.

I have routers that support NETCONF in my lab and no routers
supporting COPS-PR or COPS.  Perhaps this is why our views of the
world are somewhat different.

> COPS-PR by nature does policy control, Rw interface mainly does
> policy control dynamically, not just push configuration
> information. Besides, in 2005,NETCONF was a pretty new protocol, and
> few existing routers supported NETCONF.

I never understood the distinction between configuration and policy
information when it comes to the device interface. The PDP is the
policy engine and what comes out of this engine as provisioning
information is for me not really distinct from configuration data
coming out of other systems (e.g. customer provisioning systems).

I agree that NETCONF was pretty new in 2005 and it still is in 2007.
COPS-PR is older but as far as I can tell not too widely implemented
and the number of people within the IETF who do understand COPS-PR
well is like to be somewhat smaller than the number of people within
the IETF who understand NETCONF and my impression was that COPS-PR
awareness declines.

> As RACF supports both fix and mobile, push and pull modes, in the
> real networking, PD-FE may possibly support both modes, and in pull
> modes, COPS is very effective, so, in push mode, if approach 2 COPS
> could be adopted, it will simplify the implementation.

The implementation simplification is a relative thing (if you have
COPS, using COPS is simple, if you have NETCONF, using NETCONF is
simple). Not sure how to make a decision on this.

Again, I like to see the discussion raised to the technical level to
first understand if NETCONF could do what you need it to do equally
well or whether there is any technical feature that really
distinguishes COPS-PR from NETCONF.

/js

---

From: "Durham, David" <[email-masked]>
Date: Sat, 17 Mar 2007 16:23:10 -0700

If the goal is to use XML, then why reinvent the wheel on webservices
for management outside of the W3C and DMTF? 
SNMP, COPS, DIAMETER, NETCONF... Where does it end?

Is there an RFC that does a thorough analysis of the alternatives
(IETF's and other standards bodies' included) in terms of capabilities,
latency, bandwidth, complexity, backward compatibility and other such
quantitative metrics? If not, this might be a helpful activity as the
mailing list discussions quickly become crystal ball gazing and
philosophical in nature. Then folks can figure out if their requirements
make a better fit for one protocol over another. 

-Dave

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Juergen Schoenwaelder
> Sent: Thursday, March 15, 2007 7:47 AM
> To: xuheyuan
> Cc: Tina Tsou; [email-masked]; [email-masked]; Romascanu,
Dan
> (Dan); Hexian Huang; Tom-PT Taylor; [email-masked]; ops-
> [email-masked]
> Subject: [nmrg] Re: Comments Question about draft-xu-cops-push-00.txt
> 
> !! This message is brought to you via the `nmrg' mailing list.
> !! Please do not reply to this message to unsubscribe. To unsubscribe
or
> adjust
> !! your settings, send a mail message to
<[email-masked]>
> !! or look at https://mail.ibr.cs.tu-bs.de/mailman/listinfo/nmrg.

---

From: Andy Bierman <[email-masked]>
Date: Mon, 19 Mar 2007 03:03:22 -0700

> SNMP, COPS, DIAMETER, NETCONF... Where does it end?

I would assume it ends when vendors are given a reasonable solution
that they can deploy in their products at a reasonable cost.
NETCONF is designed to be an "evolution of the CLI",
which can be integrated with the native CLI API relatively easily.

Hopefully,  the migration away from informally documented ad-hoc CLI
with no structured error return codes, towards structured XML with
standard operations and return codes, is enough to foster  interoperability
and improve tool automation.

IMO, protocols which totally ignore the existence of the CLI based 
management,
and rely on large amounts of new code and new data models for success,
will never be adopted by the NE vendor community.

Andy

---

From: "Natale, Bob" <[email-masked]>
Date: Mon, 19 Mar 2007 08:51:05 -0400

Hi Dave,

If I understand your position correctly, then the intent of the
mini-BOF that I will brief is find the "best fit" means of making SNMP
MIBs -- which, at least IMHO, represent the crown jewels of what the
IETF O&M community has given to the practice of network management --
more directly accessible by SOA/WS management tools.  The mini-BOF will
propose a WG to determine the actual make-up of that "best fit" from
among a set of reasonable alternatives...a degree of "business
judgment" might not to be applied over and above technical analysis in
making a final determination, as many of the related standards and open
source reference projects are at early stages of maturation.  This is
more an exercise in standardizing a resource modeling methodology, as
opposed to a new management protocol.

Rushed,
BobN

-----Original Message-----
From: Durham, David [mailto:[email-masked]] 
Sent: Saturday, March 17, 2007 7:23 PM
To: [email-masked]; xuheyuan
Cc: [email-masked]; [email-masked]; Hexian Huang;
[email-masked]; [email-masked]; Tina Tsou
Subject: [OPS-AREA] RE: [nmrg] Re: Comments Question
aboutdraft-xu-cops-push-00.txt

philosophical in nature. Then folks can figure out if their
requirements

-Dave

Dan
> <http://www.eecs.iu-bremen.de/>	 P.O. Box 750 561, 28725
Bremen,
> Germany
or

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 19 Mar 2007 14:28:11 +0100

On Mon, Mar 19, 2007 at 08:51:05AM -0400, Natale, Bob wrote:
 
> [...] The mini-BOF will
> source reference projects are at early stages of maturation.

I believe this approach is asking for endless discussions. I would
very much prefer to see a critical number of people agreeing on a
particular approach and committing themself to put energy into working
out the details before a WG is being chartered. Well scoped WGs have a
much better chance to complete in time (whatever that means in the
IETF ;-).

I had the pleasure to participate in a few WGs trying to formulate
requirements before doing the actual work and this has always been a
pain and if you ask me a waste of time. (There might be WGs where this
requirements approach works well but then I did not have the pleasure
to participate in those WGs - or it is because of my absence that it
worked out well. ;-)

/js

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 26 Mar 2007 10:54:34 -0400

Hi David,

(I changed the subject line since this is not about the cops-pr
proposal anymore)

(I reduced the CC's to the ops-area and the nmrg mailing lists, hoping
that will reduce duplicate mailings, I BCC'd the other addresses, to
alert them they should join the ops-area list or the nmrg list for
this discussion.) 

So far we have not done a very good job of comparing and contrasting
IETF NM standards, and providing guidelines of how they might operate
together in a system. 

I am editing an OPS area "Guidelines for Operability and
Manageability" draft that currently includes sections for describing
the applicability of IETF NM protocols and IETF NM data models.
This document may be similar to what you are describing, but to avoid
the "boiling the ocean" problem, we are focusing on comparing and
contrasting IETF standards for NM, before we consider expanding it to
include NM-related standards of other SDOs. 

As we develop the operability and manageability guidelines draft, we
may split these sections into  a second draft specifically for
comparing and contrasting available technologies. We plan to use a
bottom-up approach of understanding and documenting how IETF NM
protocols are **actually deployed** to manage real IP-based networks
today, so we can understand current practices better. It would be
helpful if other SDOs provided similar documentation of how their
NM-related standards are actually deployed to manage real IP-based
networks today. 

Such a focused approach does have its potential pitfalls, of course;
by focusing only on the IETF NM standards, in a bottom-up approach, we
might miss the bigger picture espoused by other SDOs that prefer a
top-down approach.

We are faced with a lack of quantitative research into how NM
protocols (standard or not) are used today in real networks, so it
will be hard to compare and contrast based on quantitative measures.
We will probably need to base the document we are producing on
anecdotal reports and empirical data from small research networks
until the research community can get enough cooperation from
commercial interests to be able to study patterns in commercial
enterprise and service provider networks. 

The current work being done by the NMRG and others to generate
quantitative data, and to address the concerns of commercial interests
about the sharing of data (such as anonymization), hopefully will lead
to better information in the future.

David Harrington
[email-masked] 
[email-masked]
[email-masked]

> [mailto:[email-masked]] On Behalf Of Durham, David
> Cc: [email-masked]; [email-masked]; 
> Romascanu,Dan (Dan); Hexian Huang; Tom-PT Taylor; 
> Subject: RE: [nmrg] Re: Comments Question about 
> draft-xu-cops-push-00.txt
> 
Bremen,
> !! Please do not reply to this message to unsubscribe. To 
> unsubscribe or adjust