Re: [Dcpel] Dcpel BoF support

Olivier Dugeon <olivier.dugeon@francetelecom.com> Wed, 02 November 2005 17:54 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXMoO-00031Q-OB; Wed, 02 Nov 2005 12:54:12 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXMoM-0002zK-Bq for dcpel@megatron.ietf.org; Wed, 02 Nov 2005 12:54:10 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26506 for <dcpel@ietf.org>; Wed, 2 Nov 2005 12:53:48 -0500 (EST)
Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXN2x-0006uD-Sb for dcpel@ietf.org; Wed, 02 Nov 2005 13:09:16 -0500
Received: from ftrdmel10.rd.francetelecom.fr ([10.193.117.156]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Wed, 2 Nov 2005 18:54:05 +0100
Received: from [10.193.11.122] ([10.193.11.122]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Wed, 2 Nov 2005 18:54:05 +0100
Message-ID: <4368FD3C.8050107@francetelecom.com>
Date: Wed, 02 Nov 2005 18:54:04 +0100
From: Olivier Dugeon <olivier.dugeon@francetelecom.com>
Organization: France Telecom
User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716)
X-Accept-Language: fr, en
MIME-Version: 1.0
To: Kathleen Nichols <nichols@pollere.com>
Subject: Re: [Dcpel] Dcpel BoF support
References: <43590931.5080809@francetelecom.com> <435D64E1.4000605@pollere.com><435F5B3D.40706@francetelecom.com> <435FB01A.1080306@pollere.com>
In-Reply-To: <435FB01A.1080306@pollere.com>
X-OriginalArrivalTime: 02 Nov 2005 17:54:05.0075 (UTC) FILETIME=[6A624E30:01C5DFD6]
X-Spam-Score: 1.1 (+)
X-Scan-Signature: 2086112c730e13d5955355df27e3074b
Cc: dcpel@ietf.org
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>
Content-Type: multipart/mixed; boundary="===============0651714969=="
Sender: dcpel-bounces@ietf.org
Errors-To: dcpel-bounces@ietf.org

Hi Kathleen,

Kathleen Nichols a écrit :
mid435FB01A.1080306@pollere.com" type="cite">
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?
  
From your remarks, I think we need to add a focus on technology independent control plane with a link to L2. I.e. add a clear separation between the control part and the device configuration part in the architecture of the control plane. Concerning the device configuration, the WG could just focus on DiffServ configuration through COPS for example and let open configuration of others technology. IMHO, I think that the WG should be chartered in order to build an open framework and decline this framework for a use case which is DiffServ.

Regards,

Olivier
mid435FB01A.1080306@pollere.com" type="cite">
	Kathie


_______________________________________________
Dcpel mailing list
Dcpel@ietf.org
https://www1.ietf.org/mailman/listinfo/dcpel" rel="nofollow">https://www1.ietf.org/mailman/listinfo/dcpel

  

-- 
Project Manager for Network architecture and switching Division
 & FT/DR&D/CORE/M2I           | mailto:Olivier.Dugeon@francetelecom.com
 2, Avenue Pierre Marzin      | Phone/Fax:  +(33) 296 05 2880/1470
 F-22307 LANNION              | Mobile:     +(33) 6 82 90 37 85
_______________________________________________
Dcpel mailing list
Dcpel@ietf.org
https://www1.ietf.org/mailman/listinfo/dcpel