RE: [Dcpel] Dcpel BoF support

Attila Báder (IJ/ETH) <attila.bader@ericsson.com> Fri, 28 October 2005 09:28 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVQXN-0002dV-8G; Fri, 28 Oct 2005 05:28:37 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVQXL-0002dM-10 for dcpel@megatron.ietf.org; Fri, 28 Oct 2005 05:28:35 -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 FAA03768 for <dcpel@ietf.org>; Fri, 28 Oct 2005 05:28:18 -0400 (EDT)
Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVQkq-0007mK-KS for dcpel@ietf.org; Fri, 28 Oct 2005 05:42:34 -0400
Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id AD01E136B; Fri, 28 Oct 2005 11:28:17 +0200 (CEST)
Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Oct 2005 11:28:12 +0200
Content-class: urn:content-classes:message
Subject: RE: [Dcpel] Dcpel BoF support
Date: Fri, 28 Oct 2005 11:27:52 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Message-ID: <F005CD411D18D3119C8F00508B087480139F4975@ehubunt100.eth.ericsson.se>
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Thread-Topic: [Dcpel] Dcpel BoF support
Thread-Index: AcXbGrRcBK6TvTBlQ9ipfckzMv7CLQAgdPvQ
From: "Attila Báder (IJ/ETH)" <attila.bader@ericsson.com>
To: Kathleen Nichols <nichols@pollere.com>, dcpel@ietf.org
X-OriginalArrivalTime: 28 Oct 2005 09:28:12.0500 (UTC) FILETIME=[EAC62940:01C5DBA1]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f
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

Dear All,  

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.

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. 

Best regards, Attila

> -----Original Message-----
> From: dcpel-bounces@ietf.org [mailto:dcpel-bounces@ietf.org]
> Sent: Thursday, October 27, 2005 7:19 PM
> To: dcpel@ietf.org
> Subject: Re: [Dcpel] Dcpel BoF support
> 
> 
> Paulo Mendes wrote:
> ...
> > 
> > Concerning  the charter, I think that it will be more efficient to
> > divide the effort in inter- and intra-domain. The main reason, in my
> > opinion is that decoupling inter- and intra- this will bring more
> > flexibility in end-to-end operations. Modularity is always a good
> > principle.
> 
> [Kathie]I believe division is the way to go, but I think we 
> need to keep
> in mind that we have to make the step from intra- to inter-. This
> hasn't seemed all that divergent in the work I've done, but I'm
> interested to see others' approaches and concerns. For example,
> I think when one constructs in interior control plane, it is
> necessary to think about what information  you are willing to
> expose to the outside, what you will send and what you will
> accept. So I think that sets you up for the inter- step.
> 
> <The "you" below refers to Olivier, not to me.>
> > 
> > You say that your focus in not on DiffServ to enforce QoS in the
> > network, but on the definition of a Resource Manager 
> framework. Good,
> > but this Resource Management framework can still be defined with two
> > modules for inter- and intra-domain, connected by a network 
> interface.
> > But, in what concerns the intra-domain resource control, I 
> don't know
> > why shouldn't we focus on DiffServ. First, the DiffServ 
> model is clearly
> > lacking a control plane; second, other QoS enforcement 
> mechanisms, such
> > as MPLS, already define how resources may be controlled. Moreover, I
> > still think that DiffServ as a lot of potential, not only to support
> > qualitative traffic, but also quantitative one.
> 
> [Kathie] I really feel the focus should be on a diffserv control plane
> for exactly your reasons. I think people like Olivier can perhaps
> try to keep us on track not to conflict with other control plane
> actions.
> <again, the "you" below is Olivier, I think.>
> > 
> > Another question is related to the 'topology acquisition' item. This
> > means that you think that the control of resources within a DiffServ
> > network should be centralized in a "resource manager", 
> which will then
> > need to collect topology information? Since a PDB is 
> already defined in
> > a distributed way, why not allow the control of resources to be
> > distributed, with most of the operations being located at the edges?
> > This distributed approach brings the benefits of higher 
> robustness and
> > perhaps performance.
> 
> Hmm, I don't think topology acquisition necessarily means 
> "centralized".
> After all, routing protocols construct a topology and are distributed.
> I've been bothered by the characterization of bandwidth/resource
> manager style solutions as "centralized" where I would characterize
> them as "network-wide". I think of a diffserv control plane as being
> decoupled from the forwarding path but having the network 
> wide awareness
> needed to enforce a PDB (so it sounds like we agree here). The actual
> entity or entities that implement this can be as "centralized" or
> "distributed" as needed.
> > 
> > In what concerns the other standardization efforts, I would 
> say that it
> > would help a lot this BoF, if we had a brief document 
> characterizing the
> > differences between all these approaches to see where this 
> BoF would fit.
> 
> Okay. Do you mean centralized vs distributed approaches to diffserv
> control plane? I would somewhat like to see if we can do something
> that can include all of that range, but perhaps that's not possible.
> 
> 	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