RE: [Dcpel] Dcpel BoF support

Attila Báder (IJ/ETH) <attila.bader@ericsson.com> Thu, 03 November 2005 09:59 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 1EXbsC-0000Cs-3R; Thu, 03 Nov 2005 04:59:08 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXbsA-0000Cc-Bs for dcpel@megatron.ietf.org; Thu, 03 Nov 2005 04:59:06 -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 EAA18576 for <dcpel@ietf.org>; Thu, 3 Nov 2005 04:58:45 -0500 (EST)
Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXc6p-0000xh-KN for dcpel@ietf.org; Thu, 03 Nov 2005 05:14:22 -0500
Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 0E89DE29; Thu, 3 Nov 2005 10:58:58 +0100 (CET)
Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Nov 2005 10:58:48 +0100
Content-class: urn:content-classes:message
Subject: RE: [Dcpel] Dcpel BoF support
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 3 Nov 2005 10:58:48 +0100
Message-ID: <F005CD411D18D3119C8F00508B087480139F4985@ehubunt100.eth.ericsson.se>
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Thread-Topic: [Dcpel] Dcpel BoF support
Thread-Index: AcXf61gfg0YW4f6ORGS7MUVF6DGKJAAaL8eg
From: =?iso-8859-15?Q?Attila_B=E1der_=28IJ/ETH=29?= <attila.bader@ericsson.com>
To: "Kathleen Nichols" <nichols@pollere.com>, "Paulo Mendes" <mendes@docomolab-euro.com>, <dcpel@ietf.org>
X-OriginalArrivalTime: 03 Nov 2005 09:58:48.0843 (UTC) FILETIME=[2FCC5DB0:01C5E05D]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
Content-Transfer-Encoding: quoted-printable
Cc:
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 Kathie, Paolo,

Ok, I see now better the scope. I am thinking that one of the potential applications will be resource management within one or muliple Diffserv domain(s). 

Interdomain problem would be interesting because there is lack of standard solutions. The needed elements depends very much on the supporteed architecture and functions, so probably defining a concrete solution cannot be avoided. NSIS may want to address this problem from off-path signaling point of view, but there is not a concrete proposal what architecture and which automatism it should support. 

Best regards, Attila  


> -----Original Message-----
> From: dcpel-bounces@ietf.org [mailto:dcpel-bounces@ietf.org]
> Sent: Wednesday, November 02, 2005 9:22 PM
> To: dcpel@ietf.org
> Subject: Re: [Dcpel] Dcpel BoF support
> 
> 
> Attila Báder (IJ/ETH) wrote:
> ..
> > Dear all, as I understand the main goal of the working 
> group would be
> > to identify and define elements for DiffServ-based resource manager
> > concept.
> > 
> We should spell this out better. It's really first to specify the
> elements we can use to build a diffserv control plane. This lets
> us figure out what we already have and what is still missing (in
> the standards sense). I believe this of necessity includes documenting
> some ways to use the control plane for operational control of
> some useful differentiated services.
> 
> > I think that such concept should address inter-domain signaling as
> > well. Note that there is an NSIS a proposal for path-decoupled
> > signaling. If it gets through, NSIS could be used as 
> protocol between
> > resource managers. Anyway it should be avoided that IETF 
> develops two
> > protocols parallel for the same purpose.
> 
> It looks like many folks want to look at inter-domain issues. I don't
> believe we should address the signaling protocol issue, but certainly
> there needs to be some element of the intra-domain CP that handles
> requests, including (or perhaps particularly) those from outside the
> domain. I think the emphasis would be on what kind of 
> information would
> need to be extracted from those requests that would be necessary and
> useful to the diffserv CP. If NSIS has a protocol that fits the bill,
> great. If not, perhaps it's possible to add some options (as 
> in Paulo's
> work) working in the NSIS WG. I absolutely agree that we would not
> want "parallel protocols" and, in fact, I think of developing a
> signaling protocols (which is a transport issue not an ops issue)
> as a definite non-item for this group.
> 
> 	Kathie
> 
> _______________________________________________
> Dcpel mailing list
> Dcpel@ietf.org
> https://www1.ietf.org/mailman/listinfo/dcpel
> 

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