[Dcpel] Comments on draft-vandenberghe-dcpel-basics-00.txt

Olivier Dugeon <Olivier.Dugeon@francetelecom.com> Mon, 16 January 2006 16:33 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 1EyXI8-00077Y-V8; Mon, 16 Jan 2006 11:33:12 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyXI7-00077Q-BO for dcpel@megatron.ietf.org; Mon, 16 Jan 2006 11:33:11 -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 LAA25434 for <dcpel@ietf.org>; Mon, 16 Jan 2006 11:31:47 -0500 (EST)
Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyXQ2-0000X5-Gu for dcpel@ietf.org; Mon, 16 Jan 2006 11:41:25 -0500
Received: from ftrdmel10.rd.francetelecom.fr ([10.193.117.156]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Mon, 16 Jan 2006 17:33:06 +0100
Received: from [10.193.11.122] ([10.193.11.122]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Mon, 16 Jan 2006 17:33:06 +0100
Message-ID: <43CBCAC2.6080406@francetelecom.com>
Date: Mon, 16 Jan 2006 17:33:06 +0100
From: Olivier Dugeon <Olivier.Dugeon@francetelecom.com>
Organization: France Telecom R&D
User-Agent: Thunderbird 1.5 (X11/20051201)
MIME-Version: 1.0
To: dcpel@ietf.org
Content-Type: text/plain; charset="ISO-8859-15"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 16 Jan 2006 16:33:06.0431 (UTC) FILETIME=[876350F0:01C61ABA]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
Content-Transfer-Encoding: 7bit
Subject: [Dcpel] Comments on draft-vandenberghe-dcpel-basics-00.txt
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

Hello Steven and all,

Following the last draft sent by Kathleen, here it is some comments 
about your draft:

Concerning the scope of DCP: is DCP will provision and enforce basic 
DiffServ router configuration or not ?
In fact, I just want to know if an operator needs to continue to setup 
manually some configuration (like queuing, bandwidth, priority ...) of 
the DCPEL (a), or if the DCP could help an operator to provision its 
DiffServ Domain (b). For example, I want to support this PDBs from this 
ingress to this egress. The DCP verify it its possible and enforce the 
PDBs inside the domain including both ingress, egress and core node. In 
case of (a), how a DCP could retrieve all DS setup (it is also related 
to another question - see below). In case of (b), I think that the draft 
should explicitly state this and make distinction between provisioning  
and invocation (or perhaps is what you state with pre-provisioning and 
provisioning). As usual, definition is very important.

In figure I (section 4.1) you describe and comment the monitoring 
function of the DCP. Instead of "defining what types of network status 
are needed" I would prefer speaking about information which are needed. 
Indeed, I think that a DCP need more than simple network status. For 
example, if PDBs are manually setup, the DCP must retrieve all this kind 
of information. In order to perform a correct and efficient admission 
control, the DCP must be aware of the topology of the network (path 
awareness).

It is not clear for me which entity could request some SLSs in a DCP 
control DS domain. Is it only another DS domain or a customer could do 
this. Do you assume that its the same from the DCP point of view ? and, 
so, make no distinction between a network and a end-host ? In this case, 
why make distinction between intra and inter domain for the request and 
the interface. Do you think that the figure 1 could be enhance by 
designing a common interface used by customer, provider, other DCP in 
order to request some SLSs ?

Despite this, I'm agree with your draft and think that is in good shape 
to define the DCPEL WG.

Best regards,

Olivier

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