Re: [Dcpel] questions related to DCPEL scope

["Georgios Karagiannis" <[e-mail]>]

Hi Kathie

Thank you very much for your quick reply!

Please see in line!

On 2/22/2006, "Kathleen Nichols" <[e-mail]> wrote:

>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. 

Georgios: But I suppose that this will of depend on the specified PDBs.
What if a PDB requires a control plane support for a core Diffserv router?

>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.

Georgios: Maybe it is very useful to perform an extensive state of the
art study on the area of centralized control plane architectures that
are developed in ITU-t, ETSI-tispan, DSL, packetcable, 3gpp, 3gpp2, 
ipshere, wimax. The outcome of this state of the art study could then
help to define
the final charter of the DCPEL BOF/WG.

Best Regards,
Georgios

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