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

Olivier Dugeon <olivier.dugeon@francetelecom.com> Wed, 02 November 2005 17:46 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 1EXMgg-0007Iy-NO; Wed, 02 Nov 2005 12:46:14 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXMgd-0007IS-Io for dcpel@megatron.ietf.org; Wed, 02 Nov 2005 12:46: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 MAA25476 for <dcpel@ietf.org>; Wed, 2 Nov 2005 12:45:49 -0500 (EST)
Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXMvE-0006It-LK for dcpel@ietf.org; Wed, 02 Nov 2005 13:01:19 -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:46:04 +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:46:04 +0100
Message-ID: <4368FB5C.6060108@francetelecom.com>
Date: Wed, 02 Nov 2005 18:46: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: Paulo Mendes <mendes@docomolab-euro.com>
Subject: Re: [Dcpel] response (changed long subject line)
References: <28F05C819859B042BBF585C4997D5A476ED7B2@deex.docomolab-euro.com> <4358D229.8050808@docomolab-euro.com> <435D630E.9010701@pollere.com> <435F5CCC.2090205@francetelecom.com> <4360BC0A.40302@docomolab-euro.com>
In-Reply-To: <4360BC0A.40302@docomolab-euro.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-OriginalArrivalTime: 02 Nov 2005 17:46:04.0684 (UTC) FILETIME=[4C0C74C0:01C5DFD5]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4
Content-Transfer-Encoding: quoted-printable
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>
Sender: dcpel-bounces@ietf.org
Errors-To: dcpel-bounces@ietf.org

Hi Paulo,

Paulo Mendes a écrit :

> Hi there,
>
> some comments inline...
>
> Olivier Dugeon wrote:
>
>> Hi Kathleen,
>>
>> Kathleen Nichols a écrit :
>>
>>> Paulo Mendes wrote:
>>>  
>>>
>>>
[ ... skip ... ]

>>>
>> I take the opportunity to give my understanding about COPS. I think 
>> that COPS is more devoted to apply policy to a given set of device 
>> rather than building a control Plane. In fact, the Dcpel could used 
>> COPS to enforce QoS in the network and IMHO is placed on top of PDP 
>> since it facilitate the PDP configuration. i.e. that it is not solved 
>> in COPS is how/when/with which information an operator could easely 
>> fullfill the PIB in a PDP.
>
>
> [Paulo] Keeping in mind a modular distinction between inter- and 
> intra-domain, I would say that based on a set of available 
> inter-domain QoS agreements, the PDP, which control the QoS 
> agreements, may use COPS to enforce QoS in the network, as you say. 
> But we must see what do you mean by "enforcing the QoS in the 
> network". IMHO there are two options: a) a centralized one, in which 
> the PDP uses COPS to configure all the needed routers; b) a 
> decentralized one, in which the PDP used COPS to configure the ingress 
> PEP, and to inform the PEP about the PDB that needs to be setup. Based 
> on this information the PEP uses an intra-domain signaling protocol to 
> perform class configuration until the required egress point. This 
> signaling may be based on a NSIS protocol.

[OD]. I'm agree with your analyze. I have in mind the b) solution where 
effectively only the ingress node need to be configured. The a) option 
mostly refer to OSS management and not to control plane. But, the main 
argument in favor of b) is performance issue. It is more scalable and 
faster to just enforce QoS on the ingress node. Now, what mechanism is 
needed to enforce QoS on ingress node vary depending on what the network 
support. It could be setup a path with NSIS or RSVP or RSVP-TE or simply 
configure a classifier/marker for a simple DiffServ node.

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