Subject: [Dcpel] Re: diffserv control plane

From: "James M. Polk" <[email-masked]>
Date: Sat, 15 Oct 2005 14:42:02 -0500

Kathleen

Can you give an overview of how something like COPS cannot do what you are 
envisioning, with or without extension?

 From the RAP Charter page:
http://www.ietf.org/html.charters/OLD/rap-charter.html

"The working group will define general-purpose objects that facilitate
the manipulation of policies and provisioned objects available through
COPS and COPS-PR. Where appropriate, these will include frameworks
clarifying the applicability of COPS objects and the best practices
for the definition of additional objects defined in other working
groups."

with the following deliverables (delivered already):

"- A standards track framework document describing the usage of COPS
in carrying usage reporting and unsolicited state change
information between a PDP and a PEP [FEEDBACKFRWK].

- A standards track document describing a modular architecture for a
COPS based Management Framework. The document will address the COPS
message processing, security and access control and may specify
examples of how the framework may be implemented. [COPSFRWK]"

I'm not suggesting COPS solves for what you are looking for, just want to 
know what you see as the difference in what COPS does today, or could do 
with minor extensions, vs. what you want this DCPEL group to accomplish?

At 03:35 PM 10/3/2005 -0700, Kathleen Nichols wrote:
>We've been working toward a possible IETF BoF on diffserv control plane
>elements to be under the Operations and Management Area. Our in-progress
>Background and Goals for the BoF:
>
>It's been some time since the Diffserv forwarding path elements were
>standardized. At that time, the approach was to get the mechanisms
>deployed in routers so that approaches to service creation and control
>plane could be attempted. Before closing, the Diffserv WG defined the
>concept of Per-Domain Behaviors (PDBs) in RFC 3086, but left the
>approach to controling PDBs open.
>
>Now Diffserv forwarding elements are available in most routers and are
>in use to create services in some networks. A variety of approaches are
>being used for control and management of Diffserv but there appears to
>be some commonality. A possible path for IETF work is to enumerate and
>classify the common elements and to work toward some best common
>practices. Additionally, it may be useful to present specifications for
>a range of diffserv control plane elements using common interfaces.
>
>The major issues to deploying Diffserv-based services are primarily
>operational. The deployment must be cost-effective, be secured against
>vulnerabilities and not become a vehicle for denial of service attacks.
>Standardization should result in existing toolsets being either expanded
>to cover more needed functionality or to interact with other tools. A
>standardization effort should cover how to secure the architecture to
>mitigate vulnerabilities. Standards for a control plane QoS agent for
>routers may be useful. A desired outcome of IETF efforts is to make
>multiple products available to network operators, obviating the time and
>personnel expense of individual solutions. The end goal is to enable
>more services, both for network customers and for control of the
>network, without taxing personnel.
>
>The starting point for a BoF is to look at what's out there, determine
>if there is indeed some uniformity of approach useful as a starting
>point, and determine what's missing.
>
>The intial focus would be the intradomain control plane moving to
>interdomain or AS under same provider and finally to interprovider or
>interoperator.
>
>------------------------------------------------------------------
>
>The entire in-progress proposal for the BoF can be viewed at
>www.pollere.com under Resources, then Current Work or you
>can find a text version in the archives of the dcpel list.
>
>If you are interested in helping to further shape the proposal, please
>sign up for the email list [email-masked] through
>www1.ietf.org/mailman/listinfo/dcpel and comment on the list.
>
>         thanks,
>                 Kathie Nichols
>                 Scott Bradner
>
>_______________________________________________
>Ietf mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/ietf

cheers,
James

                                 *******************
                 Truth is not to be argued... it is to be presented.

_______________________________________________
Dcpel mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dcpel

---

From: Kathleen Nichols <[email-masked]>
Date: Mon, 17 Oct 2005 10:15:14 -0700

James M. Polk wrote:
> Kathleen
> 
> Can you give an overview of how something like COPS cannot do what you
> are envisioning, with or without extension?
> 
....
James,
I don't have anything to add to what Jeff Pulliam has said about this,
but do want to reiterate that there is no intention to ignore COPS.
The dcpel effort is for a BoF at present, a chance to discuss if
something else is needed at the IETF, and an explicit goal is to
see what related work is relevent even if something more is needed.
I think you'll see in our draft that we've always thought of COPS
as a possible option for use but not one we employed in a prototype.
Hopefully, we'll get to see some ways that people are using COPS.

	Kathie

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 17 Oct 2005 12:59:43 -0500

Kathie

Thanks for the feedback

I was just thinking about what I can gleen from the messages so far and 
thought of the old saying: why invent something new when something old 
would suffice.

I don't know if COPS will address your requirements, but was initially 
curious if it had been looked at, even if it needed some extensions to 
solve what you were looking for in the control plane.

The next thing I was thinking is that if COPS had been ruled out, why was 
it ruled out.

There likely are some perfectly valid reasons to rule COPS out, I was just 
wondering if the list was going to see that reasoning - and it sounds like 
we will.

I look forward to reading the ID(s).

cheers,
James

                                 *******************