Re: [Dcpel] Dcpel BoF support

Paulo Mendes <mendes@docomolab-euro.com> Wed, 02 November 2005 19:34 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 1EXONo-0004zX-HD; Wed, 02 Nov 2005 14:34:52 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXONm-0004yC-D2 for dcpel@megatron.ietf.org; Wed, 02 Nov 2005 14:34:50 -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 OAA03397 for <dcpel@ietf.org>; Wed, 2 Nov 2005 14:34:28 -0500 (EST)
Received: from deprox.docomolab-euro.com ([212.119.9.186]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EXOcP-00031r-Ec for dcpel@ietf.org; Wed, 02 Nov 2005 14:49:58 -0500
Received: from 172.27.10.3 by deprox.docomolab-euro.com (InterScan E-Mail VirusWall NT); Wed, 02 Nov 2005 20:33:50 +0100
Received: from [172.27.100.47] ([172.27.100.47]) by deex.docomolab-euro.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 2 Nov 2005 20:33:50 +0100
Message-ID: <43691477.4080608@docomolab-euro.com>
Date: Wed, 02 Nov 2005 20:33:11 +0100
From: Paulo Mendes <mendes@docomolab-euro.com>
User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "\"Attila Báder (IJ/ETH)\"" <attila.bader@ericsson.com>
Subject: Re: [Dcpel] Dcpel BoF support
References: <F005CD411D18D3119C8F00508B087480139F4975@ehubunt100.eth.ericsson.se>
In-Reply-To: <F005CD411D18D3119C8F00508B087480139F4975@ehubunt100.eth.ericsson.se>
Content-Type: text/plain; charset="ISO-8859-15"; format="flowed"
X-OriginalArrivalTime: 02 Nov 2005 19:33:50.0755 (UTC) FILETIME=[5A209730:01C5DFE4]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id OAA03397
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

Dear Attila,

as I mentioned before, i fully agree that inter-domain QoS control 
should be included in the charter, although probably with lower priority 
than the intra-domain study.

About the NSIS proposal for path-decoupled signalling. In my opinion 
path-decoupled signalling is well suitable for inter-domain QoS control, 
but it is still not clear to me what is the best solution, or if we can 
have more than one complementary solutions. In what concerns this issue, 
here are for now two questions:
- Should the inter-domain signalling go through 'QoS controllers' or 
should that signalling occur between 'QoS controllers'? The answer to 
this question requires some analysis of assumptions and goals.
- Will networks want to control traffic or flows?

Regards
Paulo


Attila Báder (IJ/ETH) wrote:

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


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