Re: [Dcpel] Dcpel BoF support

Kathleen Nichols <nichols@pollere.com> Wed, 26 October 2005 16:34 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUoEh-0006HZ-Mp; Wed, 26 Oct 2005 12:34:47 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUoEf-0006Fe-T6 for dcpel@megatron.ietf.org; Wed, 26 Oct 2005 12:34:45 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06085 for <dcpel@ietf.org>; Wed, 26 Oct 2005 12:34:29 -0400 (EDT)
Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUoRq-00013p-UU for dcpel@ietf.org; Wed, 26 Oct 2005 12:48:24 -0400
Received: from c-24-6-155-12.hsd1.ca.comcast.net ([24.6.155.12] helo=[10.1.1.74]) by outbound.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.51) id 1EUoEZ-000FDy-3G for dcpel@ietf.org; Wed, 26 Oct 2005 12:34:39 -0400
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 24.6.155.12
X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information)
X-MHO-User: kmnichols
Message-ID: <435FB01A.1080306@pollere.com>
Date: Wed, 26 Oct 2005 09:34:34 -0700
From: Kathleen Nichols <nichols@pollere.com>
User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: dcpel@ietf.org
Subject: Re: [Dcpel] Dcpel BoF support
References: <43590931.5080809@francetelecom.com> <435D64E1.4000605@pollere.com> <435F5B3D.40706@francetelecom.com>
In-Reply-To: <435F5B3D.40706@francetelecom.com>
X-Enigmail-Version: 0.90.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset="ISO-8859-15"
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id MAA06085
X-BeenThere: dcpel@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for possible diffserv control plane elements WG <dcpel.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dcpel>, <mailto:dcpel-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dcpel>
List-Post: <mailto:dcpel@ietf.org>
List-Help: <mailto:dcpel-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dcpel>, <mailto:dcpel-request@ietf.org?subject=subscribe>
Sender: dcpel-bounces@ietf.org
Errors-To: dcpel-bounces@ietf.org

Olivier Dugeon wrote:
> Kathleen Nichols a écrit :
> 
>> Olivier Dugeon wrote:
...
> 
>>> So, do you think the charter must be only focus on DiffServ or could it
>>> be open to other QoS enforcement mechanism ? Or, for the strategy, is it
>>> preferable to focus on DiffServ, and after the WG created, open the
>>> scope to other technology ?
>>>   
>> I'm in favor of keeping the focus limited at any one time, but
>> rechartering is fine when some things get done. But what other QoS
>> enforcement mechanisms did you have in mind besides diffserv?
>>  
> In fact, inside the EuQoS project, we intend to manage several
> technology (in particular the access part) across a common view of the
> QoS. This why, in our architecture there is 2 view of the Control Plane.
> One which technology independent and manage the inter-domain and the
> other which is technology dependent and manage the intra domain part.
> So, from the DiffServ point of view, this could result to setup
> approriate L2 mechanism in order to provide a DiffServ aware QoS
> mechanism. For example, in xDSL ATM or GE network, the EF class could be
> map to a CBR ATM ATC or a particular VLAN. This could be also apply if
> you intend to used MPLS-DiffServ mechanism.
>

Okay, this is of course useful stuff and something we all end up doing
in adapting to a particular network. It seems like it would be useful
if it is possible to have some kind of commonality in how L2 interacts
with L3 diffserv mechansims so that the control plane can be
technology independent. Though this needs to be considered when
designing a network QoS solution, I'm not sure we should put it on
dcpel's work list. At least not immediately. It seems to me that
at some point this might need some kind of sub-category of "Advice
to Link Layer Designers".
>>
>>> I'm also very confident in this attempt since this kind of functions are
>>> now studied in various place:
>>>

So, in your opinion, what are the major things Dcpel could *add* to this
work?

	Kathie


_______________________________________________
Dcpel mailing list
Dcpel@ietf.org
https://www1.ietf.org/mailman/listinfo/dcpel