Re: [Dcpel] response (changed long subject line)

Olivier Dugeon <> Wed, 02 November 2005 17:47 UTC

Received: from ([] by with esmtp (Exim 4.32) id 1EXMhw-0007uf-GR; Wed, 02 Nov 2005 12:47:32 -0500
Received: from ([] by with esmtp (Exim 4.32) id 1EXMhs-0007tX-J7 for; Wed, 02 Nov 2005 12:47:28 -0500
Received: from (ietf-mx []) by (8.9.1a/8.9.1a) with ESMTP id MAA25840 for <>; Wed, 2 Nov 2005 12:47:06 -0500 (EST)
Received: from ([]) by with esmtp (Exim 4.43) id 1EXMwU-0006Pu-JK for; Wed, 02 Nov 2005 13:02:36 -0500
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.211); Wed, 2 Nov 2005 18:47:24 +0100
Received: from [] ([]) by with Microsoft SMTPSVC(6.0.3790.211); Wed, 2 Nov 2005 18:47:23 +0100
Message-ID: <>
Date: Wed, 02 Nov 2005 18:47:23 +0100
From: Olivier Dugeon <>
Organization: France Telecom
User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716)
X-Accept-Language: fr, en
MIME-Version: 1.0
To: Paulo Mendes <>, Kathleen Nichols <>
Subject: Re: [Dcpel] response (changed long subject line)
References: <> <><> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
X-OriginalArrivalTime: 02 Nov 2005 17:47:23.0903 (UTC) FILETIME=[7B4450F0:01C5DFD5]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d
Content-Transfer-Encoding: quoted-printable
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for possible diffserv control plane elements WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

Hi Paulo and Kathleen,

I stronger support the Paulo proposal and I'm also in favor of the b) 



Paulo Mendes a écrit :

> Hi Kathleen,
> Kathleen Nichols wrote:
>> Paulo Mendes wrote:
>>> Hello,
>>> I'm quite interested in this BOF. Actually, for a long time that I was
>>> expecting a BOF like this to show up. This because it is perfectly
>>> synchronized with the work that I'm currently doing at the NTT DoCoMo
>>> laboratories in Europe. Currently, we are working on the following 
>>> topics:
>>> - Dynamic control of inter-domain QoS with local configuration of PDBs:
>>>  - Standard Information model
>>>  - Standard interface
>>>  - Standard protocol for local configuration of classes
>>> - Distributed control of intra-domain QoS with admission control and
>>> dynamic allocation of BW to different classes.
>>> I enumerated these two topic in a clear separation between inter-domain
>>> and intra-domain. This because the requirements are clearly different.
>>> For instance, in what concerns signaling, while inter-domain must be
>>> done at the network level, and a protocol much simpler than NSIS may be
>>> used, intra-domain control of classes resources should be done in the
>>> data path from ingress to egress.
>> That has been our thinking also. And I think it makes sense to seek
>> a charter that is limited to intra-domain at first. Many WGs
>> (including Diffserv) recharter when it is time for new work items
>> and that's a nice way to keep focus.
> [Paulo] I agree. We can do this is two ways: a) create a charter only 
> for intra-domain issues, keeping in mind that the charter may be 
> changed latter to include inter-domain issues; b) he create a charter 
> encompassing intra- and inter- domain issues, but we define a clear 
> work plan, which should give higher priority to intra-domain issues. I 
> would prefer the option b), because this will make the WG stronger, 
> since we aim to provide the needed E2E solution. And in the end is 
> this that matters. If you follow option a), we are leaving behind the 
> major reason not to have QoS deployed in the Internet, which is the 
> lack of inter-domain control.
> I'm a little afraid that if we don't include the inter-domain control 
> in our list of priorities, it may happen that we end up again with a 
> half-solution: control of Diffserv networks but still no end-to-end QoS.
>>> It seems that for now there is only Nichols's et al. ID about a 
>>> strawman
>>> description of components. If there is already a stable idea of what
>>> this control plane must, should and may provide, I agree that the next
>>> step may be the classification of existing solutions and identification
>>> of missing functionalities. Otherwise, it is better to clearly identify
>>> the problem statement, and a set or requirements and assumptions.
>> I would welcome your input on any of these items. We put out a
>> strawman to give something common to talk about (even if it is
>> just to disagree with it. If you would like to write a brief
>> draft of a proposed problem statement, we could discuss that
>> on the list and at Vancouver. So, we have the possibility of
>> using the COPS RFCs as a basis for a diffserv control plane,
>> we have the option of looking at some solution approaches to
>> see if there is a stable idea of the control plane, and
>> we have the option of writing a problem statement.
> I would very much like to contribute to this problem statement draft, 
> since it will clarify our goals. If we do this, can you present the 
> draft in Vancouver? (like I said in my last email, unfortunately I 
> cannot attend the IETF meeting in Vancouver).
>>> So, I'm available to contribute to the following actions:
>>> - Classification of requirements and assumptions for the control of
>>> DiffServ networks
>>> - Specification of control elements/protocols (which should all have a
>>> good security assurance :) )
>>> I could also help in the shape the BoF proposal, if still needed, but
>>> unfortunately, due to other travel appointments, I cannot attend the
>>> Vancouver meeting.
>> Certainly shaping a proposal for a WG charter is still needed. This
>> can be done through email.
>>     regards,
>>         Kathie Nichols
> Cheers
> Paulo
> _______________________________________________
> Dcpel mailing list

Project Manager for Network architecture and switching Division
 & FT/DR&D/CORE/M2I           |
 2, Avenue Pierre Marzin      | Phone/Fax:  +(33) 296 05 2880/1470
 F-22307 LANNION              | Mobile:     +(33) 6 82 90 37 85

Dcpel mailing list