RE: [Dcpel] Re: diffserv control plane

["Pulliam, Jeffrey S" <[e-mail]>]

James 

To all - apologies for the email client.  Have not broken the code on
the most recent IT config of our Outlook clients so I am breaking
formatting here.  Will fix this soon, so again, apologies.  

James - you raise a legitimate question, and one that should be included
in the face to face discussion.  

Small diversion
- I support the effort to define a standardized architecture and
elements of DiffServ Control Plane, wherever it may lead.  

- It would be very useful to get the best approaches in public view,
find the common elements, determine the differentiators, make the
tradeoffs, and establish a best position for end to end integration of
QoS services.  We have several major network efforts within our team
that would benefit from the work of Dcpel, and we will contribute to
this discussion where we can.

- Wherever it may lead, as our customers need answers that will work,
and are supportable for the long term.  We strongly support the need for
this dicussion, and want to see a result that allows our customer to
meet their objectives for QoS.

End Diversion

Regarding COPS - 

Our team considered COPS for our current work, and did not select it for
use as our policy protocol framework.  I have some exposure to practical
application of COPS within a few enterprise networks, and spent some
time considering the COPS suite of standards as a basis for the work we
are doing in this area.  Our primary reason for not selecting COPS was
commercial support, message format, and security mechanisms scalability
concerns.  I will not claim expertise, just novice level familiarity,
however, and would welcome a reference to a COPS expert who can take our
work in that area further - and will take any responses in this area off
list.

Just a little input to your question to Kathleen - 

I do think that the DCPEL BOF should consider concepts contained within
COPS under the proposed charter Itinerary Item 4
"Is there other IETF work that applies?" and that concepts contained
within COPS are relevant to some strawman elements.  There are some
concerns I would like to raise with COPS as a basis for DiffServ control
plane.  (It is entirely possible that I've missed some features that
COPS provides.)

- COPS comes with a specific messaging format and protocol for message
exchange.  This format and protocol should be examined to determine
suitability within a service oriented approach to resource allocation.
The message formats and  protocol brings some interesting impact to
network security infrastructures, which can be costly.    

- There is a need for a common reference for resources and services that
a network implements and makes available.  An example of this is
generalized aggregation control, in particular within the mobile ad-hoc
networks.

- There is a need for exchange of control plane information across
network domain interfaces with static and adhoc networks, across
interfaces with individual users, and with user enterprise networks.
These networks support a variety of QoS control plane mechanisms, but
all have in common use of the DiffServ forwarding plane mechanisms.   

- Performance monitoring, measurement, and reporting are significant
concerns, to include feedback into the control plane to drive effective
use of available resources.

- Security mechanisms are a concern, in particular the ability to
integrate the DiffServ Control plane into the model of the network, and
to protect the information contained on the control plane.  I like the
idea of a TLS function - which protects messages from view, but there
are other concerns, such as "guarding" information in the message which
need to be addressed.  XML guards are the in-vogue approach to this
issue.  Ability to use XML messaging between "server" and client may be
essential.  Of course some guards support formatting such as COPS.  We
like our results to date based on NETCONF syntax for configuration of
routers.

Standardization of these items is a significant concern for the effort
we are working on, and the perception of available standards is all over
the map.  Our driving need is to determine what can be standardized,
what should be standardized, and what should be different from domain to
domain.

Finally - configuration management is a concern.  We need a control
plane which is visible to other systems within the BSS/OSS and uses
common concepts and syntax.  Translations between syntax systems adds to
fragility.  The control plane can employ COPS where applicable, but
needs to have an information, resource, and data model that is easily
integrated with other network information, resource, and data models as
required.  

Transport layer independence is a concern.

Somehow in all of this, the keep it simple rule needs to reign.  If the
end solution is not simple and flexible, then the effort defining the
solution will be for naught.

Within our team, we've developed working models of multiple control
plane approaches, and have evaluated COPS based approaches for use.  We
are describing some of our efforts to date within the dcpel group, and
are excited about addressing the architectures, data models, syntax,
protocols, and security of DiffServ control planes.

Jeff Pulliam
Lockheed Martin

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of James M. Polk
Sent: Saturday, October 15, 2005 12:42 PM
To: Kathleen Nichols
Cc: [e-mail]
Subject: [Dcpel] Re: diffserv control plane


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 [e-mail] through 
>www1.ietf.org/mailman/listinfo/dcpel and comment on the list.
>
>         thanks,
>                 Kathie Nichols
>                 Scott Bradner
>
>_______________________________________________
>Ietf mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/ietf


cheers,
James

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

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

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