Re: [Dcpel] Dcpel BoF support

Kathleen Nichols <nichols@pollere.com> Mon, 24 October 2005 22:48 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUB7j-0004Js-Rq; Mon, 24 Oct 2005 18:48:59 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUB7i-0004Jh-AX for dcpel@megatron.ietf.org; Mon, 24 Oct 2005 18:48:58 -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 SAA26482 for <dcpel@ietf.org>; Mon, 24 Oct 2005 18:48:45 -0400 (EDT)
Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUBKY-0002oV-KM for dcpel@ietf.org; Mon, 24 Oct 2005 19:02:14 -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 1EUB7h-000EYV-5R; Mon, 24 Oct 2005 18:48:57 -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: <435D64E1.4000605@pollere.com>
Date: Mon, 24 Oct 2005 15:49:05 -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: Olivier Dugeon <olivier.dugeon@francetelecom.com>
Subject: Re: [Dcpel] Dcpel BoF support
References: <43590931.5080809@francetelecom.com>
In-Reply-To: <43590931.5080809@francetelecom.com>
X-Enigmail-Version: 0.90.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a
Content-Transfer-Encoding: 7bit
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

Olivier Dugeon wrote:
> Hi Kahtleen and all,
> 
> I saw some days ago your announce for the Dcpel BoF, and I'm very
> enthousiste about your initiative. Indeed, I'm working for 5 years now
> in the field of QoS control and especially the control plane of IP
> network. 
...

Thanks for an impressive list of reference links!
> From the EuQoS board, many peoples have express their interrest for this
> BoF. Inside France Telecom, I already got interests from my colleagues
> for such study, and of course, to support this BoF.
> 
> Concerning the charter, in our initiative, we intend to not only focus
> on DiffServ to enforce QoS in the network. Our goal was more to define a
> Resource Manager framework with the corresponding interface/protocols
> around it:
> 
> - Topology acquisition
> - Inter Resouce Manager protocol both for intra and inter domain SLS
> exchange
> - Service request interface
> - Devices configuration which in fact have link to COPS and netconf WG
> - Link to PCE
> 
> We have volunteer exclude business aspect as well as the Call Admission
> Control algorithm which, in our opinion are not in the scope of the
> IETF. In parallel, and for the framework, we think that we must seperate
> what is devoted for the provisionning of resources and the usage of the
> resources itself (i.e. the per flow control). In fact, it could be
> related to the NSIS off-path BoF attempt which occur some time ago.
> 
So, this is all quite interesting. Sounds like there are commonalities
to our proposal.

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

> 
> I'm also very confident in this attempt since this kind of functions are
> now studied in various place:
> 
> - The Multi Switching Forum (MSF) have already identified a such
> function (Bandwidth Manager) for VoIP. The document was written by
> Operax people.
> - The ETSI-TISPAN have almost achieve the specification of the RACS
> (Resource Allocation Control Subsystem) which embedded the RACF
> (Resource Allocation Control Function) for the fixed/mobile IMS convergence.
> - 3Gpp has already specify such function in Release R6 for the IMS (IP
> Multemedia Subsystem)
> - The ITU-T NGN Focus Group doing a parallel work as the ETSI, but
> including the intra domain and in a more general way as the IMS
> - And recently the DSL Forum has lunch a new Work Item about the Policy
> Control Framework.
> 
> Finally, the IETF is the only place where such study is not yet conduct.
> 
> I not planned to attend the Vancouver meeting, but people from the EuQoS
> board as well as the France Telecom delegation could attend the BoF.
> 

It would be nice if someone could attend. We don't have a very long time
slot, so perhaps we could find some time to get together in addition
to the BoF.

	regards,
		Kathie

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