Re: [Dcpel] Dcpel BoF support

Kathleen Nichols <nichols@pollere.com> Wed, 02 November 2005 20:21 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 1EXP7L-00022L-7r; Wed, 02 Nov 2005 15:21:55 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXP7I-000205-FX for dcpel@megatron.ietf.org; Wed, 02 Nov 2005 15:21:52 -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 PAA06316 for <dcpel@ietf.org>; Wed, 2 Nov 2005 15:21:30 -0500 (EST)
Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXPLw-0005Df-9F for dcpel@ietf.org; Wed, 02 Nov 2005 15:37:01 -0500
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 1EXP7A-000JnY-35 for dcpel@ietf.org; Wed, 02 Nov 2005 15:21:44 -0500
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: <43691FD7.3070608@pollere.com>
Date: Wed, 02 Nov 2005 12:21:43 -0800
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: dcpel@ietf.org
Subject: Re: [Dcpel] Dcpel BoF support
References: <F005CD411D18D3119C8F00508B087480139F4975@ehubunt100.eth.ericsson.se>
In-Reply-To: <F005CD411D18D3119C8F00508B087480139F4975@ehubunt100.eth.ericsson.se>
X-Enigmail-Version: 0.90.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset="ISO-8859-15"
X-Spam-Score: 0.1 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id PAA06316
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

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