Re: [Dcpel] questions related to DCPEL scope

[Kathleen Nichols <[e-mail]>]

Georgios,
> 
> Is the scope of starting this BOF/WG the specification of new Per 
> Domain Behaviours (PDBs) and the specification of new interfaces that
> can be used by existing signaling protocols (such as NSIS) to
> influence/ manage these PDB's?

Those items are in the scope of our current proposal. In addition,
we want to have the discussion that will result in specification
of service models and metrics that can be used externally by network
operators to describe their offerings (without exposing the
internal implementations). We've proposed a starting point of
looking at the NSIS Qspec which in turn builds on the ITU Y1554.
However, we don't feel the dcpel effort should be bound to those
metrics if they are not sufficient.

> Could you specify what do you mean by a distributed Difsserv control
> plane approach? Will this distributed approach impact an individual
> Diffserv router, e.g., a Diffserv core router?

I'm just giving a short answer here. A distributed DiffServ control
plane is one where the control plane actions do not reside in
one physical location and probably not in one logical location.
We would expect an impact on DiffServ edge routers, but probably
not DiffServ core routers. Following the model of RFC3290, we
expect to spend time on the QoS agent and the configuration and
management interface. In draft-nichols-dcpel-strawman-arch-00, this is
where we located the DiffServ Control Plane Agent or DCPA. I
believe a longer answer is the work of the proposed working group.
Please note that we have put out some proposals based on our
own work and based on meeting with several folks last November.
The final form of a solution would be an outcome of the consensus
process.

> From what I know other stardardisation bodies are working for a long time 
> already
> on a centralized (bandwidth broker like) architecture/framework.
> Such standardisation bodies are:
> the ITU-t, ETSI-tispan, DSL, packetcable, 3gpp, 3gpp2,  ipshere, wimax.
> My question is how is the DCPEL effort related to this work? 

Well, we have contributors and reviewers of our work who are
involved with some of these efforts who still feel IETF work is
needed. Since IETF sets standards and practices for the more general
internet, this seems appropriate to me. However, the IETF framework
for a DCP ought to look at some of these approaches as specific
instances of solutions and it would be good if they fit into the
framework. Unless we come to the consensus opinion that someone
is just doing it wrong! So I would hope we would have some cross-
participation. (I coauthored my first document in this area in
November of 1997, now rfc2638, and one of my coauthors had been
working on the architecture a few years before that, so I think there
is a history in the IETF and the IRTF too).

The feedback we've gotten is that "something"
is needed and we were told from a provider perspective that
the acknowleged "big problem" is having common notions of the
differentiated services that are openly provided along with
a few examples of how to achieve these. Getting to that point
is clearly best done through the open, consensus-driven,
experience-driven process.

	regards,
		Kathie

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