[Dcpel] Re: [e2e] FYI: A Proposed IETF BoF on Diff-Serv Control Plane

Paulo Mendes <mendes@docomolab-euro.com> Fri, 21 October 2005 11:31 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESv7W-000179-3m; Fri, 21 Oct 2005 07:31:34 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESv7U-000170-1b for dcpel@megatron.ietf.org; Fri, 21 Oct 2005 07:31:33 -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 HAA15121 for <dcpel@ietf.org>; Fri, 21 Oct 2005 07:31:22 -0400 (EDT)
Received: from deprox.docomolab-euro.com ([212.119.9.186]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ESvJc-0005Al-8o for dcpel@ietf.org; Fri, 21 Oct 2005 07:44:04 -0400
Received: from 172.27.10.3 by deprox.docomolab-euro.com (InterScan E-Mail VirusWall NT); Fri, 21 Oct 2005 13:31:22 +0200
Received: from [172.27.100.57] ([172.27.100.57]) by deex.docomolab-euro.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 21 Oct 2005 13:31:22 +0200
Message-ID: <4358D229.8050808@docomolab-euro.com>
Date: Fri, 21 Oct 2005 13:34:01 +0200
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: dcpel@ietf.org
References: <28F05C819859B042BBF585C4997D5A476ED7B2@deex.docomolab-euro.com>
In-Reply-To: <28F05C819859B042BBF585C4997D5A476ED7B2@deex.docomolab-euro.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 21 Oct 2005 11:31:22.0305 (UTC) FILETIME=[F68CAB10:01C5D632]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db
Content-Transfer-Encoding: 7bit
Subject: [Dcpel] Re: [e2e] FYI: A Proposed IETF BoF on Diff-Serv Control Plane
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

Hello,

I'm quite interested in this BOF. Actually, for a long time that I was expecting a BOF like this to show up. This because it is perfectly synchronized with the work that I'm currently doing at the NTT DoCoMo laboratories in Europe. Currently, we are working on the following topics:
- Dynamic control of inter-domain QoS with local configuration of PDBs:
   - Standard Information model
   - Standard interface
   - Standard protocol for local configuration of classes
- Distributed control of intra-domain QoS with admission control and dynamic allocation of BW to different classes.

I enumerated these two topic in a clear separation between inter-domain and intra-domain. This because the requirements are clearly different. For instance, in what concerns signaling, while inter-domain must be done at the network level, and a protocol much simpler than NSIS may be used, intra-domain control of classes resources should be done in the data path from ingress to egress.

It seems that for now there is only Nichols's et al. ID about a strawman description of components. If there is already a stable idea of what this control plane must, should and may provide, I agree that the next step may be the classification of existing solutions and identification of missing functionalities. Otherwise, it is better to clearly identify the problem statement, and a set or requirements and assumptions.

So, I'm available to contribute to the following actions:
- Classification of requirements and assumptions for the control of DiffServ networks
- Specification of control elements/protocols (which should all have a good security assurance :) )

I could also help in the shape the BoF proposal, if still needed, but unfortunately, due to other travel appointments, I cannot attend the Vancouver meeting.

Cheers,
Paulo Mendes


>>Posted at the request of Bob Braden:
>>
>>----
>>
>>A Proposed IETF BoF on Diff-Serv Control Plane
>>
>>---------------------------------------------------------------
>>
>>We've been working toward a possible IETF BoF on diffserv 
>>control plane
>>elements to be under the Operations and Management Area. Our 
>>in-progress
>>Background and Goals for the BoF:
>>
>>It's been some time since the Diffserv forwarding path elements were
>>standardized. At that time, the approach was to get the mechanisms
>>deployed in routers so that approaches to service creation and control
>>plane could be attempted. Before closing, the Diffserv WG defined the
>>concept of Per-Domain Behaviors (PDBs) in RFC 3086, but left the
>>approach to controling PDBs open.
>>
>>Now Diffserv forwarding elements are available in most routers and are
>>in use to create services in some networks. A variety of 
>>approaches are
>>being used for control and management of Diffserv but there appears to
>>be some commonality. A possible path for IETF work is to enumerate and
>>classify the common elements and to work toward some best common
>>practices. Additionally, it may be useful to present 
>>specifications for
>>a range of diffserv control plane elements using common interfaces.
>>
>>The major issues to deploying Diffserv-based services are primarily
>>operational. The deployment must be cost-effective, be secured against
>>vulnerabilities and not become a vehicle for denial of 
>>service attacks.
>>Standardization should result in existing toolsets being 
>>either expanded
>>to cover more needed functionality or to interact with other tools. A
>>standardization effort should cover how to secure the architecture to
>>mitigate vulnerabilities. Standards for a control plane QoS agent for
>>routers may be useful. A desired outcome of IETF efforts is to make
>>multiple products available to network operators, obviating 
>>the time and
>>personnel expense of individual solutions. The end goal is to enable
>>more services, both for network customers and for control of the
>>network, without taxing personnel.
>>
>>The starting point for a BoF is to look at what's out there, determine
>>if there is indeed some uniformity of approach useful as a starting
>>point, and determine what's missing.
>>
>>The intial focus would be the intradomain control plane moving to
>>interdomain or AS under same provider and finally to interprovider or
>>interoperator.
>>
>>------------------------------------------------------------------
>>
>>The entire in-progress proposal for the BoF can be viewed at
>>www.pollere.com under Resources, then Current Work.
>>
>>If you are interested in helping to further shape the proposal, please
>>sign up for the email list dcpel@ietf.org through
>>www1.ietf.org/mailman/listinfo/dcpel and comment on the list.
>>
>>	thanks,
>>		Kathie Nichols
>>		Scott Bradner
>>
>>    
>>
>
>  
>


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