[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
- [Dcpel] Comments on draft-vandenberghe-dcpel-basi… Olivier Dugeon
- Re: [Dcpel] Comments on draft-vandenberghe-dcpel-… Steven Van den Berghe