From dcpel-bounces@ietf.org Fri Oct 07 06:12:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENpDS-00040j-2f; Fri, 07 Oct 2005 06:12:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENpDR-00040e-4v for dcpel@megatron.ietf.org; Fri, 07 Oct 2005 06:12:37 -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 GAA08568 for ; Fri, 7 Oct 2005 06:12:34 -0400 (EDT) Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80] ident=[U2FsdGVkX1+Fa1tkzWga3rcwnK38dXGnO5C+qRDbGKA=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENpMh-0006qJ-LV for dcpel@ietf.org; Fri, 07 Oct 2005 06:22:12 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1ENpD7-0002bQ-QD; Fri, 07 Oct 2005 12:12:25 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 3B84FB246; Fri, 7 Oct 2005 12:12:17 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1ENpD7-0004Yn-05; Fri, 07 Oct 2005 12:12:17 +0200 Message-ID: <43464A00.2020909@tm.uka.de> Date: Fri, 07 Oct 2005 12:12:16 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Kathleen Nichols X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.5 (----) X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Cc: dcpel@ietf.org Subject: [Dcpel] DCPEL Proposal X-BeenThere: dcpel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for possible diffserv control plane elements WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dcpel-bounces@ietf.org Errors-To: dcpel-bounces@ietf.org Hi Kathie, I agree very much with your proposal. It would be a good starting point and the logical consequence to continue the work that begun in the DiffServ WG. Furthermore, I think that the increasing deployment of VoIP and DoS protection (http://www.internet2.edu/~ben/papers/20030827-qos-dos.pdf) are be a good driver for QoS-based solutions. And some people already started to deploy things, see e.g. http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl-architecture-00.txt http://www.ietf.org/internet-drafts/draft-briscoe-twvwg-cl-phb-00.txt So there needs to be discussion whether such approaches are the right basis towards a common solution or CP architecture. I think PDBs are a really useful concept, but it is very important to show exactly how PDBs should be controlled, which includes IMHO a very detailed PDB specification. So far we don't have many standardized PDBs for "elevated" services, but many operators have a rough guessing/feeling what they could do with DiffServ. AFAIK most operators (start to) use DiffServ as an overlay for splitting bandwidth into different isolated traffic classes, i.e. they simply prioritize their traffic, e.g., for VoIP. A static DiffServ setup this is elatively easy to deploy, but currently providers probably don't care much about the actual PDB attributes or PDB guarantees (though it would be good hear counter examples...). So I feel that we have a lack of PDBs for elevated services, e.g., guaranteed bandwidth. Moreover, as soon as we start to deploy DiffServ dynamically, we may need admission control, resource management and signaling. Therefore, I see a possible strong relation to the work in the NSIS WG. If QoS a agents, Proxies, BBs are used it would be good to hear what protocols should be used for configuring routers (FP elements). A suitable protocol could be COPS, but I'm unsure whether this has enough support from the IETF community (esp. vendors, operators). So it would be good to gather input about such issues. I've been working on inter-domain (and inter-AS/inter-operator) DiffServ management which is the last point on your list of goals. From my perspective it is important to provide QoS-based services globally just like today Internet access or IP connectivity. In order to get a scalable solution we also need to apply inter-domain aggregation concepts in the control plane, not only in the data plane (DiffServ). I'm currently preparing a draft for NSIS that tries some kind of analysis what would be required for this. Best regards, Roland _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel From dcpel-bounces@ietf.org Fri Oct 07 08:24:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENrGe-0004mH-5g; Fri, 07 Oct 2005 08:24:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENrGc-0004m8-IN for dcpel@megatron.ietf.org; Fri, 07 Oct 2005 08:24:02 -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 IAA14577 for ; Fri, 7 Oct 2005 08:24:01 -0400 (EDT) Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80] ident=[U2FsdGVkX196Hywpvf2qidQfaFdE7ip6EylgYCP4RBE=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENrPt-0003fg-Ly for dcpel@ietf.org; Fri, 07 Oct 2005 08:33:38 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1ENrGX-0002Hd-D8 for ; Fri, 07 Oct 2005 14:23:59 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id D2E378B6E for ; Fri, 7 Oct 2005 14:23:55 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1ENrGV-0004fi-Fy for dcpel@ietf.org; Fri, 07 Oct 2005 14:23:55 +0200 Message-ID: <434668DA.3010302@tm.uka.de> Date: Fri, 07 Oct 2005 14:23:54 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: dcpel@ietf.org Subject: Re: [Dcpel] DCPEL Proposal References: <43464A00.2020909@tm.uka.de> In-Reply-To: <43464A00.2020909@tm.uka.de> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.5 (----) X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit X-BeenThere: dcpel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for possible diffserv control plane elements WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dcpel-bounces@ietf.org Errors-To: dcpel-bounces@ietf.org Hi, I forgot to mention that an important operational point is the security. The correct operation of DiffServ networks depends heavily on a correct marking at the first-hop/boundary node. Due to aggregation it is usually later not easily possible to figure out a particular non-admitted flow... Consequently, one should probably use an IPsec tunnel for packets sent to the first-hop router in order to authenticate packets from legitimate users and thus to prevent theft of resources etc. This IMHO would increase the operational complexity a lot... Regards, Roland _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel From dcpel-bounces@ietf.org Fri Oct 07 12:52:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENvSt-0003QN-RZ; Fri, 07 Oct 2005 12:52:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENvSs-0003QG-EB for dcpel@megatron.ietf.org; Fri, 07 Oct 2005 12:52:58 -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 MAA29846 for ; Fri, 7 Oct 2005 12:52:55 -0400 (EDT) Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENvcB-00079H-Ur for dcpel@ietf.org; Fri, 07 Oct 2005 13:02:37 -0400 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 1ENvSl-000HYh-JO for dcpel@ietf.org; Fri, 07 Oct 2005 12:52:51 -0400 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: <4346A7E0.7050809@pollere.com> Date: Fri, 07 Oct 2005 09:52:48 -0700 From: Kathleen Nichols User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dcpel@ietf.org X-Enigmail-Version: 0.90.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Subject: [Dcpel] earlier note from Roland X-BeenThere: dcpel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for possible diffserv control plane elements WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dcpel-bounces@ietf.org Errors-To: dcpel-bounces@ietf.org Roland's earlier comments were sent to me: > Thanks for pointing me to this. I agree very much with your proposal. > I've been working on inter-domain (and inter-AS) diffserv management > which is the last point on your list. However, I think it is really > important to show exactly how PDBs should be controlled, which includes > IMHO a very detailed PDB specification. So far we don't have many PDBs > for "elevated" services, but many operators have a rough > guessing/feeling what they could do with DiffServ. AFAIK most operators > (start to) use DiffServ as an overlay for splitting bandwidth into > different isolated traffic classes, i.e. they simply prioritize their > traffic, e.g., for VoIP. As a static setup this is relatively easy, but > currently they don't care much about the actual PDB attributes or PDB > guarantees. > > Regards, > Roland _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel From dcpel-bounces@ietf.org Fri Oct 07 14:05:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENwbE-0006RH-2A; Fri, 07 Oct 2005 14:05:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENwbC-0006R4-R6 for dcpel@megatron.ietf.org; Fri, 07 Oct 2005 14:05:38 -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 OAA03423 for ; Fri, 7 Oct 2005 14:05:37 -0400 (EDT) Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENwkU-0001ax-Q8 for dcpel@ietf.org; Fri, 07 Oct 2005 14:15:18 -0400 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 1ENwb8-0006IL-AL; Fri, 07 Oct 2005 14:05:34 -0400 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: <4346B8ED.9000803@pollere.com> Date: Fri, 07 Oct 2005 11:05:33 -0700 From: Kathleen Nichols User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roland Bless References: <43464A00.2020909@tm.uka.de> In-Reply-To: <43464A00.2020909@tm.uka.de> X-Enigmail-Version: 0.90.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Content-Transfer-Encoding: 7bit Cc: dcpel@ietf.org Subject: [Dcpel] Re: DCPEL Proposal X-BeenThere: dcpel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for possible diffserv control plane elements WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dcpel-bounces@ietf.org Errors-To: dcpel-bounces@ietf.org Roland Bless wrote: .. > I agree very much with your proposal. It would be a good starting > point and the logical consequence to continue the work that begun in the > DiffServ WG. That's good to hear. Clearly a lot of work to clarify and constrain the useful issues is still needed. Furthermore, I think that the increasing deployment of VoIP > and DoS protection > (http://www.internet2.edu/~ben/papers/20030827-qos-dos.pdf) > are be a good driver for QoS-based solutions. There was certainly discussion in the earlier days (perhaps not on the diffserv WG list) of problems of DOS attacks. Decoupling the control plane and forwarding path and properly structuring the authentication mechanisms across domain boundaries seems like it can be helpful here. And some people already > started to deploy things, see e.g. > http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl-architecture-00.txt > http://www.ietf.org/internet-drafts/draft-briscoe-twvwg-cl-phb-00.txt > So there needs to be discussion whether such approaches are > the right basis towards a common solution or CP architecture. I read those drafts as describing a stand-alone architecture, not diffserv, that just wants to use the DSCP mechanism. From the abstract: "This document describes an architecture to achieve a Controlled Load (CL) service edge-to-edge, i.e. within a particular region of the Internet, by using distributed measurement-based admission control." and later in the document, the approach is contrasted to "diffserv". Although a comparative discussion of QoS architectures might be a useful exercise in some forum, if we take that approach we will end up having a very difficult time constraining our work here. This is why the proposed goals are explicitly for the diffserv architecture that was described in RFCs 2474, 2475, and 3086. And, to the abstract router model of RFC 3290. > > I think PDBs are a really useful concept, but it is very > important to show exactly how PDBs should be controlled, which includes > IMHO a very detailed PDB specification. So far we don't have many > standardized PDBs for "elevated" services, but many operators have a > rough guessing/feeling what they could do with DiffServ. AFAIK most > operators (start to) use DiffServ as an overlay for splitting bandwidth > into different isolated traffic classes, i.e. they simply prioritize > their traffic, e.g., for VoIP. A static DiffServ setup this is elatively > easy to deploy, but currently providers probably don't care much about > the actual PDB attributes or PDB guarantees (though it would be good > hear counter examples...). So I feel that we have a lack of PDBs for > elevated services, e.g., guaranteed bandwidth. Yes, agree. Though we may have some PDBs for "elevated services" and just a dearth of discussion. Not clear at this point. > > Moreover, as soon as we start to deploy DiffServ dynamically, we may > need admission control, resource management and signaling. Therefore, I > see a possible strong relation to the work in the NSIS WG. Yes, absolutely we need more control plane structure. I believe we can discuss a framework for what each of these elements needs to do and perhaps standardize how they can interact. Thus, analogously to the forwarding path, we allow innovation in the implementation of resource management, admission control, etc. Signaling is more problematic. A problem is the the NSIS WG says in the abstract and introduction of RFC4080: The Next Steps in Signaling (NSIS) working group is considering protocols for signaling information about a data flow along its path in the network. And the rest of the text makes it clear this is a path-oriented protocol. Following a diffserv approach, where QoS is delivered by a network domain, the signaling (from outside) needs to be to the network domain. If QoS a > agents, Proxies, BBs are used it would be good to hear what protocols > should be used for configuring routers (FP elements). > A suitable protocol could be COPS, but I'm unsure whether this > has enough support from the IETF community (esp. vendors, operators). > So it would be good to gather input about such issues. Yes, this configuration protocol is a different issue. COPS seems suitable on the surface, but other approaches may be more efficacious. It seems an issue worth exploring > > I've been working on inter-domain (and inter-AS/inter-operator) DiffServ > management which is the last point on your list of goals. From my > perspective it is important to provide QoS-based services globally just > like today Internet access or IP connectivity. In order to get a > scalable solution we also need to apply inter-domain aggregation > concepts in the control plane, not only in the data plane (DiffServ). > I'm currently preparing a draft for NSIS that tries some kind of > analysis what would be required for this. > Aggregation is clearly a topic that should be examined further. _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel From dcpel-bounces@ietf.org Fri Oct 14 16:51:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQWWQ-0003XD-Gs; Fri, 14 Oct 2005 16:51:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQWWP-0003X8-WD for dcpel@megatron.ietf.org; Fri, 14 Oct 2005 16:51:22 -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 QAA23935 for ; Fri, 14 Oct 2005 16:51:15 -0400 (EDT) Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQWhC-0005qe-5F for dcpel@ietf.org; Fri, 14 Oct 2005 17:02:31 -0400 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 1EQWWJ-000Iep-CV for dcpel@ietf.org; Fri, 14 Oct 2005 16:51:15 -0400 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: <43501A4A.8080605@pollere.com> Date: Fri, 14 Oct 2005 13:51:22 -0700 From: Kathleen Nichols User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dcpel@ietf.org X-Enigmail-Version: 0.90.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Subject: [Dcpel] drafts anyone? X-BeenThere: dcpel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for possible diffserv control plane elements WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dcpel-bounces@ietf.org Errors-To: dcpel-bounces@ietf.org IETF deadline for new drafts is Monday morning (US eastern). I'm co-authoring one and it would be good to have more! I'm not going to have time to convert pictures to ascii art so will put up the pdf version for that. I can put up anyone else's pdf version if desired. thanks, Kathie _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel From dcpel-bounces@ietf.org Sat Oct 15 15:42:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQrvA-00071D-KK; Sat, 15 Oct 2005 15:42:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQrv9-000718-1A for dcpel@megatron.ietf.org; Sat, 15 Oct 2005 15:42:19 -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 PAA24434 for ; Sat, 15 Oct 2005 15:42:12 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQs66-00038G-QF for dcpel@ietf.org; Sat, 15 Oct 2005 15:53:40 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 15 Oct 2005 12:42:07 -0700 X-IronPort-AV: i="3.97,218,1125903600"; d="scan'208"; a="220493106:sNHT26005088" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j9FJg4Uw027243; Sat, 15 Oct 2005 12:42:05 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 15 Oct 2005 12:42:04 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.90.213]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 15 Oct 2005 12:42:03 -0700 Message-Id: <4.3.2.7.2.20051015143501.0298bf08@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 15 Oct 2005 14:42:02 -0500 To: Kathleen Nichols From: "James M. Polk" In-Reply-To: <4341B244.30905@pollere.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 15 Oct 2005 19:42:04.0167 (UTC) FILETIME=[84C9C970:01C5D1C0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: dcpel@ietf.org Subject: [Dcpel] Re: diffserv 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dcpel-bounces@ietf.org Errors-To: dcpel-bounces@ietf.org Kathleen Can you give an overview of how something like COPS cannot do what you are envisioning, with or without extension? From the RAP Charter page: http://www.ietf.org/html.charters/OLD/rap-charter.html "The working group will define general-purpose objects that facilitate the manipulation of policies and provisioned objects available through COPS and COPS-PR. Where appropriate, these will include frameworks clarifying the applicability of COPS objects and the best practices for the definition of additional objects defined in other working groups." with the following deliverables (delivered already): "- A standards track framework document describing the usage of COPS in carrying usage reporting and unsolicited state change information between a PDP and a PEP [FEEDBACKFRWK]. - A standards track document describing a modular architecture for a COPS based Management Framework. The document will address the COPS message processing, security and access control and may specify examples of how the framework may be implemented. [COPSFRWK]" I'm not suggesting COPS solves for what you are looking for, just want to know what you see as the difference in what COPS does today, or could do with minor extensions, vs. what you want this DCPEL group to accomplish? At 03:35 PM 10/3/2005 -0700, Kathleen Nichols wrote: >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 or you >can find a text version in the archives of the dcpel list. > >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 > >_______________________________________________ >Ietf mailing list >Ietf@ietf.org >https://www1.ietf.org/mailman/listinfo/ietf cheers, James ******************* Truth is not to be argued... it is to be presented. _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel From dcpel-bounces@ietf.org Sun Oct 16 07:01:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ER6Gy-0006Rr-Ee; Sun, 16 Oct 2005 07:01:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ER6Gw-0006Rm-UY for dcpel@megatron.ietf.org; Sun, 16 Oct 2005 07:01:47 -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 HAA25177 for ; Sun, 16 Oct 2005 07:01:40 -0400 (EDT) Received: from mailgw2a.lmco.com ([192.91.147.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ER6Ry-0007p7-KR for dcpel@ietf.org; Sun, 16 Oct 2005 07:13:15 -0400 Received: from emss01g01.ems.lmco.com (relay1.ems.lmco.com [129.197.181.54]) by mailgw2a.lmco.com (8.12.10/8.12.10) with ESMTP id j9GB1SXE003968; Sun, 16 Oct 2005 07:01:29 -0400 (EDT) Received: from CONVERSION-DAEMON.lmco.com by lmco.com (PMDF V6.1-1X6 #30875) id <0IOG00H019AGW1@lmco.com>; Sun, 16 Oct 2005 04:01:28 -0700 (PDT) Received: from EMSS01I00.us.lmco.com ([129.197.181.70]) by lmco.com (PMDF V6.1-1X6 #30875) with ESMTP id <0IOG00ED49AFXK@lmco.com>; Sun, 16 Oct 2005 04:01:27 -0700 (PDT) Received: from EMSS01M10.us.lmco.com ([129.197.181.75]) by EMSS01I00.us.lmco.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 16 Oct 2005 04:01:27 -0700 Date: Sun, 16 Oct 2005 04:01:27 -0700 From: "Pulliam, Jeffrey S" Subject: RE: [Dcpel] Re: diffserv control plane To: "James M. Polk" , Kathleen Nichols Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [Dcpel] Re: diffserv control plane Thread-Index: AcXRwOry7Fcu28sURAC/xXCr5S/wDgAanlyw content-class: urn:content-classes:message X-OriginalArrivalTime: 16 Oct 2005 11:01:27.0632 (UTC) FILETIME=[F4C68D00:01C5D240] X-Spam-Score: 0.0 (/) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd Content-Transfer-Encoding: 7BIT 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dcpel-bounces@ietf.org Errors-To: dcpel-bounces@ietf.org James To all - apologies for the email client. Have not broken the code on the most recent IT config of our Outlook clients so I am breaking formatting here. Will fix this soon, so again, apologies. James - you raise a legitimate question, and one that should be included in the face to face discussion. Small diversion - I support the effort to define a standardized architecture and elements of DiffServ Control Plane, wherever it may lead. - It would be very useful to get the best approaches in public view, find the common elements, determine the differentiators, make the tradeoffs, and establish a best position for end to end integration of QoS services. We have several major network efforts within our team that would benefit from the work of Dcpel, and we will contribute to this discussion where we can. - Wherever it may lead, as our customers need answers that will work, and are supportable for the long term. We strongly support the need for this dicussion, and want to see a result that allows our customer to meet their objectives for QoS. End Diversion Regarding COPS - Our team considered COPS for our current work, and did not select it for use as our policy protocol framework. I have some exposure to practical application of COPS within a few enterprise networks, and spent some time considering the COPS suite of standards as a basis for the work we are doing in this area. Our primary reason for not selecting COPS was commercial support, message format, and security mechanisms scalability concerns. I will not claim expertise, just novice level familiarity, however, and would welcome a reference to a COPS expert who can take our work in that area further - and will take any responses in this area off list. Just a little input to your question to Kathleen - I do think that the DCPEL BOF should consider concepts contained within COPS under the proposed charter Itinerary Item 4 "Is there other IETF work that applies?" and that concepts contained within COPS are relevant to some strawman elements. There are some concerns I would like to raise with COPS as a basis for DiffServ control plane. (It is entirely possible that I've missed some features that COPS provides.) - COPS comes with a specific messaging format and protocol for message exchange. This format and protocol should be examined to determine suitability within a service oriented approach to resource allocation. The message formats and protocol brings some interesting impact to network security infrastructures, which can be costly. - There is a need for a common reference for resources and services that a network implements and makes available. An example of this is generalized aggregation control, in particular within the mobile ad-hoc networks. - There is a need for exchange of control plane information across network domain interfaces with static and adhoc networks, across interfaces with individual users, and with user enterprise networks. These networks support a variety of QoS control plane mechanisms, but all have in common use of the DiffServ forwarding plane mechanisms. - Performance monitoring, measurement, and reporting are significant concerns, to include feedback into the control plane to drive effective use of available resources. - Security mechanisms are a concern, in particular the ability to integrate the DiffServ Control plane into the model of the network, and to protect the information contained on the control plane. I like the idea of a TLS function - which protects messages from view, but there are other concerns, such as "guarding" information in the message which need to be addressed. XML guards are the in-vogue approach to this issue. Ability to use XML messaging between "server" and client may be essential. Of course some guards support formatting such as COPS. We like our results to date based on NETCONF syntax for configuration of routers. Standardization of these items is a significant concern for the effort we are working on, and the perception of available standards is all over the map. Our driving need is to determine what can be standardized, what should be standardized, and what should be different from domain to domain. Finally - configuration management is a concern. We need a control plane which is visible to other systems within the BSS/OSS and uses common concepts and syntax. Translations between syntax systems adds to fragility. The control plane can employ COPS where applicable, but needs to have an information, resource, and data model that is easily integrated with other network information, resource, and data models as required. Transport layer independence is a concern. Somehow in all of this, the keep it simple rule needs to reign. If the end solution is not simple and flexible, then the effort defining the solution will be for naught. Within our team, we've developed working models of multiple control plane approaches, and have evaluated COPS based approaches for use. We are describing some of our efforts to date within the dcpel group, and are excited about addressing the architectures, data models, syntax, protocols, and security of DiffServ control planes. Jeff Pulliam Lockheed Martin -----Original Message----- From: dcpel-bounces@ietf.org [mailto:dcpel-bounces@ietf.org] On Behalf Of James M. Polk Sent: Saturday, October 15, 2005 12:42 PM To: Kathleen Nichols Cc: dcpel@ietf.org Subject: [Dcpel] Re: diffserv control plane Kathleen Can you give an overview of how something like COPS cannot do what you are envisioning, with or without extension? From the RAP Charter page: http://www.ietf.org/html.charters/OLD/rap-charter.html "The working group will define general-purpose objects that facilitate the manipulation of policies and provisioned objects available through COPS and COPS-PR. Where appropriate, these will include frameworks clarifying the applicability of COPS objects and the best practices for the definition of additional objects defined in other working groups." with the following deliverables (delivered already): "- A standards track framework document describing the usage of COPS in carrying usage reporting and unsolicited state change information between a PDP and a PEP [FEEDBACKFRWK]. - A standards track document describing a modular architecture for a COPS based Management Framework. The document will address the COPS message processing, security and access control and may specify examples of how the framework may be implemented. [COPSFRWK]" I'm not suggesting COPS solves for what you are looking for, just want to know what you see as the difference in what COPS does today, or could do with minor extensions, vs. what you want this DCPEL group to accomplish? At 03:35 PM 10/3/2005 -0700, Kathleen Nichols wrote: >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 or you can find a >text version in the archives of the dcpel list. > >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 > >_______________________________________________ >Ietf mailing list >Ietf@ietf.org >https://www1.ietf.org/mailman/listinfo/ietf cheers, James ******************* Truth is not to be argued... it is to be presented. _______________________________________________ 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 From dcpel-bounces@ietf.org Sun Oct 16 10:24:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ER9Rb-0003bT-5g; Sun, 16 Oct 2005 10:24:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ER9RZ-0003aL-J5 for dcpel@megatron.ietf.org; Sun, 16 Oct 2005 10:24:57 -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 KAA04049 for ; Sun, 16 Oct 2005 10:24:48 -0400 (EDT) Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ER9cf-000449-9f for dcpel@ietf.org; Sun, 16 Oct 2005 10:36:26 -0400 Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id j9GEOelL013132 for ; Sun, 16 Oct 2005 16:24:40 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id j9GEOeqD004469 for ; Sun, 16 Oct 2005 16:24:40 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Sun, 16 Oct 2005 16:24:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Sun, 16 Oct 2005 16:24:20 +0200 Message-ID: Thread-Topic: bof? Thread-Index: AcXRwOry7Fcu28sURAC/xXCr5S/wDgAanlywAAxdvVA= From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 16 Oct 2005 14:24:39.0323 (UTC) FILETIME=[5796F6B0:01C5D25D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: quoted-printable Subject: [Dcpel] bof? X-BeenThere: dcpel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for possible diffserv control plane elements WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dcpel-bounces@ietf.org Errors-To: dcpel-bounces@ietf.org hi all,=20 i just took a look at the most recent meeting agenda for the 64th ietf meeting. (see http://www.ietf.org/meetings/agenda_64.txt)=20 it seems that the dcpel bof is not scheduled.=20 is your plan todo this work in the transport area? i ask because this work was not advertised on some of the obvious mailing lists.=20 ciao hannes _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel From dcpel-bounces@ietf.org Sun Oct 16 23:24:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERLcC-0007X2-H6; Sun, 16 Oct 2005 23:24:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERLcA-0007Wx-6K for dcpel@megatron.ietf.org; Sun, 16 Oct 2005 23:24:42 -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 XAA11311 for ; Sun, 16 Oct 2005 23:24:34 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERLnO-00066i-Rx for dcpel@ietf.org; Sun, 16 Oct 2005 23:36:20 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 16 Oct 2005 20:24:32 -0700 X-IronPort-AV: i="3.97,220,1125903600"; d="scan'208"; a="352858304:sNHT24716044" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9H3O59Q016351; Sun, 16 Oct 2005 20:24:29 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 16 Oct 2005 20:24:12 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.81.236]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 16 Oct 2005 20:24:11 -0700 Message-Id: <4.3.2.7.2.20051016221545.031ef368@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 16 Oct 2005 22:24:10 -0500 To: "Pulliam, Jeffrey S" From: "James M. Polk" Subject: RE: [Dcpel] Re: diffserv control plane In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 17 Oct 2005 03:24:11.0779 (UTC) FILETIME=[3E255D30:01C5D2CA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dcpel-bounces@ietf.org Errors-To: dcpel-bounces@ietf.org Jeff Thank you for your feedback There is one comment you made that is curious: At 04:01 AM 10/16/2005 -0700, Pulliam, Jeffrey S wrote: >James > >We are describing some of our efforts to date within the dcpel group, and >are excited about addressing the architectures, data models, syntax, >protocols, and security of DiffServ control planes. I believe there has been exactly 7 messages on this dcpel list before your message here, and I do not find any description of anything other than what Kathleen has stated in general, and then your message that basically addresses my questions. How much of this future group's work do you believe you have completed already? You make it sound as though there is a lot of it already done; that several choices have already been made. I am curious where this has been discussed openly, as in: what IDs is this work in to date? >Jeff Pulliam >Lockheed Martin cheers, James ******************* Truth is not to be argued... it is to be presented. _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel From dcpel-bounces@ietf.org Sun Oct 16 23:34:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERLm7-0001bn-1D; Sun, 16 Oct 2005 23:34:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERLm6-0001bh-5v for dcpel@megatron.ietf.org; Sun, 16 Oct 2005 23:34:58 -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 XAA11651 for ; Sun, 16 Oct 2005 23:34:50 -0400 (EDT) Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERLxK-0006I7-V8 for dcpel@ietf.org; Sun, 16 Oct 2005 23:46:36 -0400 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 1ERLlx-0004Ic-Hd for dcpel@ietf.org; Sun, 16 Oct 2005 23:34:49 -0400 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: <43531BD6.3000509@pollere.com> Date: Sun, 16 Oct 2005 20:34:46 -0700 From: Kathleen Nichols 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] bof? References: In-Reply-To: X-Enigmail-Version: 0.90.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit X-BeenThere: dcpel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for possible diffserv control plane elements WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dcpel-bounces@ietf.org Errors-To: dcpel-bounces@ietf.org Tschofenig, Hannes wrote: > hi all, > > i just took a look at the most recent meeting agenda for the 64th ietf > meeting. (see http://www.ietf.org/meetings/agenda_64.txt) > > it seems that the dcpel bof is not scheduled. I just had word from David Kessens that he was scheduling us for 30 minutes in the Ops open area meeting for now. > > is your plan todo this work in the transport area? i ask because this > work was not advertised on some of the obvious mailing lists. No, not in transport. Scott and I discussed this a fair amount, along with some discussion with other folks, and felt, as we say in the proposal, that the major issues are more operational now. We aren't really planning on writing a transport protocol (say messaging or signaling) going into this. Seems like the proper home for control plane stuff in the IETF is either Routing or Operations and Management and this seems like the latter to us. But where else would you like to advertise this? I have been a bit lax on that, got buried under other stuff. Kathie _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel From dcpel-bounces@ietf.org Mon Oct 17 01:44:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERNnT-0000fm-Bb; Mon, 17 Oct 2005 01:44:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERNnQ-0000eQ-7Y for dcpel@megatron.ietf.org; Mon, 17 Oct 2005 01:44:28 -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 BAA17918 for ; Mon, 17 Oct 2005 01:44:21 -0400 (EDT) Received: from mailgw2a.lmco.com ([192.91.147.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERNyf-00016t-TV for dcpel@ietf.org; Mon, 17 Oct 2005 01:56:07 -0400 Received: from emss01g01.ems.lmco.com (relay1.ems.lmco.com [129.197.181.54]) by mailgw2a.lmco.com (8.12.10/8.12.10) with ESMTP id j9H5iIXE011003; Mon, 17 Oct 2005 01:44:18 -0400 (EDT) Received: from CONVERSION-DAEMON.lmco.com by lmco.com (PMDF V6.1-1X6 #30875) id <0IOH00201P9U3S@lmco.com>; Sun, 16 Oct 2005 22:44:18 -0700 (PDT) Received: from EMSS01I00.us.lmco.com ([129.197.181.70]) by lmco.com (PMDF V6.1-1X6 #30875) with ESMTP id <0IOH00IVOP9RTP@lmco.com>; Sun, 16 Oct 2005 22:44:15 -0700 (PDT) Received: from EMSS01M10.us.lmco.com ([129.197.181.75]) by EMSS01I00.us.lmco.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 16 Oct 2005 22:44:15 -0700 Date: Sun, 16 Oct 2005 22:44:14 -0700 From: "Pulliam, Jeffrey S" Subject: RE: [Dcpel] Re: diffserv control plane To: "James M. Polk" Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [Dcpel] Re: diffserv control plane Thread-Index: AcXSyk0jHg1G9i2GRAiCZkU17dcsKQACMPPg content-class: urn:content-classes:message X-OriginalArrivalTime: 17 Oct 2005 05:44:15.0300 (UTC) FILETIME=[CF08E840:01C5D2DD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7BIT 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dcpel-bounces@ietf.org Errors-To: dcpel-bounces@ietf.org James First - let me apologize for an overly contracted description - where I referred to "...describing some of our efforts...", I should have been clear about who we are and what areas of the DiffServ control plane we are working on. So please accept my apology for any implications to the contrary, and accept the following as a replacement. In a just-completed draft about to be put in front of the dcpel list, we (a team from Lockheed, Telcordia, Pollere) are describing our efforts to date and are excited about further addressing the architectures, data models, syntax, protocols, and security of DiffServ control planes in a public forum with other folks working in and concerned with the area. >How much of this future group's work do you believe you have completed already? I think the work we've done to date is of interest to this group - and relevant. I would not presume to state we've completed the work of the group. We have a working start. I would not characterize our system as finished - more that we have a start and we like the results to date. >You make it sound as though there is a lot of it already done; that several >choices have already been made. Again I apologize for being unclear. While we've made choices in order to proceed with our effort, it is just a start. What I described in my reply to you was included for context regarding the question about COPS, and our evaluation of its use for our effort. >cheers, >James Jeff Pulliam Lockheed _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel From dcpel-bounces@ietf.org Mon Oct 17 02:31:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EROXH-0004Os-GJ; Mon, 17 Oct 2005 02:31:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EROXF-0004Ok-GR for dcpel@megatron.ietf.org; Mon, 17 Oct 2005 02:31:49 -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 CAA19646 for ; Mon, 17 Oct 2005 02:31:43 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EROiU-00026l-Qn for dcpel@ietf.org; Mon, 17 Oct 2005 02:43:29 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 16 Oct 2005 23:31:28 -0700 X-IronPort-AV: i="3.97,221,1125903600"; d="scan'208"; a="352907607:sNHT24728492" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9H6VPJh015727; Sun, 16 Oct 2005 23:31:26 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 16 Oct 2005 23:30:36 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.81.236]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 16 Oct 2005 23:30:35 -0700 Message-Id: <4.3.2.7.2.20051017012833.0319c7f8@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 17 Oct 2005 01:30:34 -0500 To: "Pulliam, Jeffrey S" From: "James M. Polk" Subject: RE: [Dcpel] Re: diffserv control plane In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 17 Oct 2005 06:30:36.0097 (UTC) FILETIME=[4884DB10:01C5D2E4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dcpel-bounces@ietf.org Errors-To: dcpel-bounces@ietf.org Jeff No need to apologize. I was just looking for your work to review and comment on. I agree that proposals mean choices are made, hopefully with a sufficient explanation as to why something seamingly close wasn't chosen. It sounds as if we all can expect that from your doc. I look forward to reading it. At 10:44 PM 10/16/2005 -0700, Pulliam, Jeffrey S wrote: >James > >First - let me apologize for an overly contracted description - where I >referred to "...describing some of our efforts...", I should have been >clear about who we are and what areas of the DiffServ control plane we >are working on. So please accept my apology for any implications to the >contrary, and accept the following as a replacement. > >In a just-completed draft about to be put in front of the dcpel list, we >(a team from Lockheed, Telcordia, Pollere) are describing our efforts >to date and are excited about further addressing the architectures, data >models, syntax, protocols, and security of DiffServ control planes in a >public forum with other folks working in and concerned with the area. > > >How much of this future group's work do you believe you have completed >already? > >I think the work we've done to date is of interest to this group - and >relevant. I would not presume to state we've completed the work of the >group. We have a working start. I would not characterize our system as >finished - more that we have a start and we like the results to date. > > >You make it sound as though there is a lot of it already done; that >several > >choices have already been made. > >Again I apologize for being unclear. While we've made choices in order >to proceed with our effort, it is just a start. What I described in my >reply to you was included for context regarding the question about COPS, >and our evaluation of its use for our effort. > > >cheers, > >James > >Jeff Pulliam >Lockheed cheers, James ******************* Truth is not to be argued... it is to be presented. _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel From dcpel-bounces@ietf.org Mon Oct 17 13:15:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERYa2-0004wq-Gf; Mon, 17 Oct 2005 13:15:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERYa0-0004wl-Ic for dcpel@megatron.ietf.org; Mon, 17 Oct 2005 13:15:20 -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 NAA25384 for ; Mon, 17 Oct 2005 13:15:12 -0400 (EDT) Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERYlM-0004Vh-KG for dcpel@ietf.org; Mon, 17 Oct 2005 13:27:05 -0400 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 1ERYZx-000OFR-N9 for dcpel@ietf.org; Mon, 17 Oct 2005 13:15:17 -0400 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: <4353DC22.80900@pollere.com> Date: Mon, 17 Oct 2005 10:15:14 -0700 From: Kathleen Nichols User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dcpel@ietf.org References: <4.3.2.7.2.20051015143501.0298bf08@email.cisco.com> In-Reply-To: <4.3.2.7.2.20051015143501.0298bf08@email.cisco.com> X-Enigmail-Version: 0.90.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Subject: [Dcpel] Re: diffserv 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dcpel-bounces@ietf.org Errors-To: dcpel-bounces@ietf.org James M. Polk wrote: > Kathleen > > Can you give an overview of how something like COPS cannot do what you > are envisioning, with or without extension? > .... James, I don't have anything to add to what Jeff Pulliam has said about this, but do want to reiterate that there is no intention to ignore COPS. The dcpel effort is for a BoF at present, a chance to discuss if something else is needed at the IETF, and an explicit goal is to see what related work is relevent even if something more is needed. I think you'll see in our draft that we've always thought of COPS as a possible option for use but not one we employed in a prototype. Hopefully, we'll get to see some ways that people are using COPS. Kathie _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel From dcpel-bounces@ietf.org Mon Oct 17 13:59:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERZHD-0008HV-B5; Mon, 17 Oct 2005 13:59:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERZHC-0008Gj-Fu for dcpel@megatron.ietf.org; Mon, 17 Oct 2005 13:59:58 -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 NAA28229 for ; Mon, 17 Oct 2005 13:59:49 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERZSY-0005tC-Lu for dcpel@ietf.org; Mon, 17 Oct 2005 14:11:44 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 17 Oct 2005 10:59:48 -0700 X-IronPort-AV: i="3.97,222,1125903600"; d="scan'208"; a="666775821:sNHT58289334" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9HHx89c029089; Mon, 17 Oct 2005 10:59:46 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 17 Oct 2005 10:59:45 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.144.104]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 17 Oct 2005 10:59:44 -0700 Message-Id: <4.3.2.7.2.20051017125441.03470a20@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 17 Oct 2005 12:59:43 -0500 To: Kathleen Nichols , dcpel@ietf.org From: "James M. Polk" Subject: Re: [Dcpel] Re: diffserv control plane In-Reply-To: <4353DC22.80900@pollere.com> References: <4.3.2.7.2.20051015143501.0298bf08@email.cisco.com> <4.3.2.7.2.20051015143501.0298bf08@email.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 17 Oct 2005 17:59:44.0995 (UTC) FILETIME=[8E61FB30:01C5D344] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dcpel-bounces@ietf.org Errors-To: dcpel-bounces@ietf.org Kathie Thanks for the feedback I was just thinking about what I can gleen from the messages so far and thought of the old saying: why invent something new when something old would suffice. I don't know if COPS will address your requirements, but was initially curious if it had been looked at, even if it needed some extensions to solve what you were looking for in the control plane. The next thing I was thinking is that if COPS had been ruled out, why was it ruled out. There likely are some perfectly valid reasons to rule COPS out, I was just wondering if the list was going to see that reasoning - and it sounds like we will. I look forward to reading the ID(s). At 10:15 AM 10/17/2005 -0700, Kathleen Nichols wrote: >James M. Polk wrote: > > Kathleen > > > > Can you give an overview of how something like COPS cannot do what you > > are envisioning, with or without extension? > > >.... >James, >I don't have anything to add to what Jeff Pulliam has said about this, >but do want to reiterate that there is no intention to ignore COPS. >The dcpel effort is for a BoF at present, a chance to discuss if >something else is needed at the IETF, and an explicit goal is to >see what related work is relevent even if something more is needed. >I think you'll see in our draft that we've always thought of COPS >as a possible option for use but not one we employed in a prototype. >Hopefully, we'll get to see some ways that people are using COPS. > > Kathie > > > >_______________________________________________ >Dcpel mailing list >Dcpel@ietf.org >https://www1.ietf.org/mailman/listinfo/dcpel cheers, James ******************* Truth is not to be argued... it is to be presented. _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel From dcpel-bounces@ietf.org Mon Oct 17 14:17:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERZYK-00042i-7V; Mon, 17 Oct 2005 14:17:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERZYI-00042a-MS for dcpel@megatron.ietf.org; Mon, 17 Oct 2005 14:17:38 -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 OAA29185 for ; Mon, 17 Oct 2005 14:17:32 -0400 (EDT) Received: from newdev.eecs.harvard.edu ([140.247.60.212] helo=newdev.harvard.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERZjd-0006HJ-BA for dcpel@ietf.org; Mon, 17 Oct 2005 14:29:24 -0400 Received: by newdev.harvard.edu (Postfix, from userid 501) id AAED352400F; Mon, 17 Oct 2005 14:17:26 -0400 (EDT) To: dcpel@ietf.org Subject: Re: [Dcpel] Re: diffserv control plane Message-Id: <20051017181726.AAED352400F@newdev.harvard.edu> Date: Mon, 17 Oct 2005 14:17:26 -0400 (EDT) From: sob@harvard.edu (Scott Bradner) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de X-BeenThere: dcpel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for possible diffserv control plane elements WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dcpel-bounces@ietf.org Errors-To: dcpel-bounces@ietf.org > I don't know if COPS will address your requirements, but was initially > curious if it had been looked at, even if it needed some extensions to > solve what you were looking for in the control plane. I don't think that COPS will address all the needs but COPS is a factor that must be taken into account when thinking about the solution set (after thinking about the probpem set) Scott _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel From dcpel-bounces@ietf.org Fri Oct 21 07:31:34 2005 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 ; 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 From dcpel-bounces@ietf.org Fri Oct 21 11:29:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESypJ-0005Yw-3B; Fri, 21 Oct 2005 11:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESypG-0005Te-Tu for dcpel@megatron.ietf.org; Fri, 21 Oct 2005 11:28:59 -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 LAA08411 for ; Fri, 21 Oct 2005 11:28:47 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESz1K-0000X6-MZ for dcpel@ietf.org; Fri, 21 Oct 2005 11:41:27 -0400 Received: from ftrdmel10.rd.francetelecom.fr ([10.193.117.156]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Fri, 21 Oct 2005 17:28:49 +0200 Received: from [10.193.11.122] ([10.193.11.122]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Fri, 21 Oct 2005 17:28:49 +0200 Message-ID: <43590931.5080809@francetelecom.com> Date: Fri, 21 Oct 2005 17:28:49 +0200 From: Olivier Dugeon Organization: France Telecom User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: fr, en MIME-Version: 1.0 To: dcpel@ietf.org X-OriginalArrivalTime: 21 Oct 2005 15:28:49.0463 (UTC) FILETIME=[22847470:01C5D654] X-Spam-Score: 0.6 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Subject: [Dcpel] Dcpel BoF support X-BeenThere: dcpel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for possible diffserv control plane elements WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0055064883==" Sender: dcpel-bounces@ietf.org Errors-To: dcpel-bounces@ietf.org --===============0055064883== Content-Type: text/html; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Kahtleen and all,

I saw some days= ago your announce for the Dcpel BoF, and I'm very enthousiste about your initiative. Indeed, I'm working for 5 years now in the field of QoS control and especially the control plane of IP network. My past research concern an european IST project named CADENUS (http://www.cadenus.fo= kus.fraunhofer.de) which aimed to define = a QoS framework and also follow on=A0 the TEQUILA one (http://www.ist-tequila.org) . Now I'm involve in a n= ew european project named EuQoS (http://www= =2Eeuqos.org) which have for goal to study the end-to-end QoS over heterogeneous network. Inside France Telecom, I also conducting projects in this field area, and, inside this scope, have established a great collaboration with Operax people.

In june, we organized a joint QoS workshop with EuQoS and Mescal project. Proceeding of this workshop could be found at http://www.euqos.o= rg/shownews.php?idnews=3D9 or at http://www.mesca= l.org/EEQoS/index.html which could give you a good overview of the start of the art of the european research in this area. The conclusion of this workshop was about the creation of a Resource Management BoF for the control plane of IP network. A dedicated mailing list have been created for this purpose to carrefully prepare the BoF since many attemps was unsuccessfull during the past (for example SLS BoF, NSIS off-path and so on). But, this attempt didn't encounter success. So, it was a pleasure to discover your initiative and to joint it.

=46rom the EuQoS board, many peoples have express their interrest for this BoF. Inside France Telecom, I already got interests from my colleagues for such study, and of course, to support this BoF.

Concerning the charter, in our initiative, we intend to not only focus on DiffServ to enforce QoS in the network. Our goal was more to define a Resource Manager framework with the corresponding interface/protocols around it:

- Topology acquisition
- Inter Resouce Manager protocol both for intra and inter domain SLS exchange
- Service request interface
- Devices configuration which in fact have link to COPS and netconf WG - Link to PCE

We have volunteer exclude business aspect as well as the Call Admission Control algorithm which, in our opinion are not in the scope of the IETF. In parallel, and for the framework, we think that we must seperate what is devoted for the provisionning of resources and the usage of the resources itself (i.e. the per flow control). In fact, it could be related to the NSIS off-path BoF attempt which occur some time ago.

So, do you think the charter must be only focus on DiffServ or could it be open to other QoS enforcement mechanism ? Or, for the strategy, is it preferable to focus on DiffServ, and after the WG created, open the scope to other technology ?

I'm also very confident in this attempt since this kind of functions are now studied in various place:

- The Multi Switching Forum (MSF) have already identified a such function (Bandwidth Manager) for VoIP. The document was written by Operax people.
- The ETSI-TISPAN have almost achieve the specification of the RACS (Resource Allocation Control Subsystem) which embedded the RACF (Resource Allocation Control Function) for the fixed/mobile IMS convergence.
- 3Gpp has already specify such function in Release R6 for the IMS (IP Multemedia Subsystem)
- The ITU-T NGN Focus Group doing a parallel work as the ETSI, but including the intra domain and in a more general way as the IMS
- And recently the DSL Forum has lunch a new Work Item about the Policy Control Framework.

Finally, the IETF is the only place where such study is not yet conduct.<= br>
I not planned to attend the Vancouver meeting, but people from the EuQoS board as well as the France Telecom delegation could attend the BoF.

Best regards,

Olivier Dugeon
--=20
Project Manager for Network architecture and switching Division=20
 & FT/DR&D/CORE/M2I           | mailto:Olivier.Dugeon@=
francetelecom.com
 2, Avenue Pierre Marzin      | Phone/Fax:  +(33) 296 05 2880/1470
 F-22307 LANNION              | Mobile:     +(33) 6 82 90 37 85
--===============0055064883== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel --===============0055064883==-- From dcpel-bounces@ietf.org Mon Oct 24 18:41:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUB0L-0001nI-F1; Mon, 24 Oct 2005 18:41:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUB0J-0001l9-6v for dcpel@megatron.ietf.org; Mon, 24 Oct 2005 18:41:19 -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 SAA26210 for ; Mon, 24 Oct 2005 18:41:05 -0400 (EDT) Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUBD9-0002fC-BK for dcpel@ietf.org; Mon, 24 Oct 2005 18:54:35 -0400 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 1EUB0A-000DDk-Rb for dcpel@ietf.org; Mon, 24 Oct 2005 18:41:11 -0400 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: <435D630E.9010701@pollere.com> Date: Mon, 24 Oct 2005 15:41:18 -0700 From: Kathleen Nichols User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dcpel@ietf.org References: <28F05C819859B042BBF585C4997D5A476ED7B2@deex.docomolab-euro.com> <4358D229.8050808@docomolab-euro.com> In-Reply-To: <4358D229.8050808@docomolab-euro.com> X-Enigmail-Version: 0.90.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Subject: [Dcpel] response (changed long subject line) X-BeenThere: dcpel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for possible diffserv control plane elements WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dcpel-bounces@ietf.org Errors-To: dcpel-bounces@ietf.org Paulo Mendes wrote: > 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. That has been our thinking also. And I think it makes sense to seek a charter that is limited to intra-domain at first. Many WGs (including Diffserv) recharter when it is time for new work items and that's a nice way to keep focus. > > 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. I would welcome your input on any of these items. We put out a strawman to give something common to talk about (even if it is just to disagree with it. If you would like to write a brief draft of a proposed problem statement, we could discuss that on the list and at Vancouver. So, we have the possibility of using the COPS RFCs as a basis for a diffserv control plane, we have the option of looking at some solution approaches to see if there is a stable idea of the control plane, and we have the option of writing a problem statement. > > 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. > Certainly shaping a proposal for a WG charter is still needed. This can be done through email. regards, Kathie Nichols _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel From dcpel-bounces@ietf.org Mon Oct 24 18:48:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUB7j-0004Js-Rq; Mon, 24 Oct 2005 18:48:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUB7i-0004Jh-AX for dcpel@megatron.ietf.org; Mon, 24 Oct 2005 18:48:58 -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 SAA26482 for ; Mon, 24 Oct 2005 18:48:45 -0400 (EDT) Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUBKY-0002oV-KM for dcpel@ietf.org; Mon, 24 Oct 2005 19:02:14 -0400 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 1EUB7h-000EYV-5R; Mon, 24 Oct 2005 18:48:57 -0400 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: <435D64E1.4000605@pollere.com> Date: Mon, 24 Oct 2005 15:49:05 -0700 From: Kathleen Nichols User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Olivier Dugeon Subject: Re: [Dcpel] Dcpel BoF support References: <43590931.5080809@francetelecom.com> In-Reply-To: <43590931.5080809@francetelecom.com> X-Enigmail-Version: 0.90.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dcpel-bounces@ietf.org Errors-To: dcpel-bounces@ietf.org Olivier Dugeon wrote: > Hi Kahtleen and all, > > I saw some days ago your announce for the Dcpel BoF, and I'm very > enthousiste about your initiative. Indeed, I'm working for 5 years now > in the field of QoS control and especially the control plane of IP > network. ... Thanks for an impressive list of reference links! > From the EuQoS board, many peoples have express their interrest for this > BoF. Inside France Telecom, I already got interests from my colleagues > for such study, and of course, to support this BoF. > > Concerning the charter, in our initiative, we intend to not only focus > on DiffServ to enforce QoS in the network. Our goal was more to define a > Resource Manager framework with the corresponding interface/protocols > around it: > > - Topology acquisition > - Inter Resouce Manager protocol both for intra and inter domain SLS > exchange > - Service request interface > - Devices configuration which in fact have link to COPS and netconf WG > - Link to PCE > > We have volunteer exclude business aspect as well as the Call Admission > Control algorithm which, in our opinion are not in the scope of the > IETF. In parallel, and for the framework, we think that we must seperate > what is devoted for the provisionning of resources and the usage of the > resources itself (i.e. the per flow control). In fact, it could be > related to the NSIS off-path BoF attempt which occur some time ago. > So, this is all quite interesting. Sounds like there are commonalities to our proposal. > So, do you think the charter must be only focus on DiffServ or could it > be open to other QoS enforcement mechanism ? Or, for the strategy, is it > preferable to focus on DiffServ, and after the WG created, open the > scope to other technology ? I'm in favor of keeping the focus limited at any one time, but rechartering is fine when some things get done. But what other QoS enforcement mechanisms did you have in mind besides diffserv? > > I'm also very confident in this attempt since this kind of functions are > now studied in various place: > > - The Multi Switching Forum (MSF) have already identified a such > function (Bandwidth Manager) for VoIP. The document was written by > Operax people. > - The ETSI-TISPAN have almost achieve the specification of the RACS > (Resource Allocation Control Subsystem) which embedded the RACF > (Resource Allocation Control Function) for the fixed/mobile IMS convergence. > - 3Gpp has already specify such function in Release R6 for the IMS (IP > Multemedia Subsystem) > - The ITU-T NGN Focus Group doing a parallel work as the ETSI, but > including the intra domain and in a more general way as the IMS > - And recently the DSL Forum has lunch a new Work Item about the Policy > Control Framework. > > Finally, the IETF is the only place where such study is not yet conduct. > > I not planned to attend the Vancouver meeting, but people from the EuQoS > board as well as the France Telecom delegation could attend the BoF. > It would be nice if someone could attend. We don't have a very long time slot, so perhaps we could find some time to get together in addition to the BoF. regards, Kathie _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel From dcpel-bounces@ietf.org Wed Oct 26 06:32:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUiaK-0005p4-76; Wed, 26 Oct 2005 06:32:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUiaG-0005oV-Jd for dcpel@megatron.ietf.org; Wed, 26 Oct 2005 06:32:42 -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 GAA10253 for ; Wed, 26 Oct 2005 06:32:24 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUinO-0004ef-EV for dcpel@ietf.org; Wed, 26 Oct 2005 06:46:15 -0400 Received: from ftrdmel10.rd.francetelecom.fr ([10.193.117.156]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Wed, 26 Oct 2005 12:32:29 +0200 Received: from [10.193.11.122] ([10.193.11.122]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Wed, 26 Oct 2005 12:32:29 +0200 Message-ID: <435F5B3D.40706@francetelecom.com> Date: Wed, 26 Oct 2005 12:32:29 +0200 From: Olivier Dugeon Organization: France Telecom User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: fr, en MIME-Version: 1.0 To: Kathleen Nichols Subject: Re: [Dcpel] Dcpel BoF support References: <43590931.5080809@francetelecom.com> <435D64E1.4000605@pollere.com> In-Reply-To: <435D64E1.4000605@pollere.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 26 Oct 2005 10:32:29.0726 (UTC) FILETIME=[9108A3E0:01C5DA18] X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: quoted-printable 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dcpel-bounces@ietf.org Errors-To: dcpel-bounces@ietf.org Hi Kathleen, Kathleen Nichols a =E9crit : >Olivier Dugeon wrote: > =20 > [ ... skip ... ] >>So, do you think the charter must be only focus on DiffServ or could it= >>be open to other QoS enforcement mechanism ? Or, for the strategy, is i= t >>preferable to focus on DiffServ, and after the WG created, open the >>scope to other technology ? >> =20 >> > >I'm in favor of keeping the focus limited at any one time, but >rechartering is fine when some things get done. But what other QoS >enforcement mechanisms did you have in mind besides diffserv? > =20 > In fact, inside the EuQoS project, we intend to manage several=20 technology (in particular the access part) across a common view of the=20 QoS. This why, in our architecture there is 2 view of the Control Plane. = One which technology independent and manage the inter-domain and the=20 other which is technology dependent and manage the intra domain part.=20 So, from the DiffServ point of view, this could result to setup=20 approriate L2 mechanism in order to provide a DiffServ aware QoS=20 mechanism. For example, in xDSL ATM or GE network, the EF class could be = map to a CBR ATM ATC or a particular VLAN. This could be also apply if=20 you intend to used MPLS-DiffServ mechanism. > =20 > >>I'm also very confident in this attempt since this kind of functions ar= e >>now studied in various place: >> >>- The Multi Switching Forum (MSF) have already identified a such >>function (Bandwidth Manager) for VoIP. The document was written by >>Operax people. >>- The ETSI-TISPAN have almost achieve the specification of the RACS >>(Resource Allocation Control Subsystem) which embedded the RACF >>(Resource Allocation Control Function) for the fixed/mobile IMS converg= ence. >>- 3Gpp has already specify such function in Release R6 for the IMS (IP >>Multemedia Subsystem) >>- The ITU-T NGN Focus Group doing a parallel work as the ETSI, but >>including the intra domain and in a more general way as the IMS >>- And recently the DSL Forum has lunch a new Work Item about the Policy= >>Control Framework. >> >>Finally, the IETF is the only place where such study is not yet conduct= =2E >> >>I not planned to attend the Vancouver meeting, but people from the EuQo= S >>board as well as the France Telecom delegation could attend the BoF. >> >> =20 >> > >It would be nice if someone could attend. We don't have a very long time= >slot, so perhaps we could find some time to get together in addition >to the BoF. > =20 > I get answer from FT people. So, normaly someones from FTR&D will attend = the BoF attempt. From EuQoS, I'm not sure someone could be present. Regards, Olivier > regards, > Kathie > > =20 > --=20 Project Manager for Network architecture and switching Division & FT/DR&D/CORE/M2I | mailto:Olivier.Dugeon@francetelecom.com 2, Avenue Pierre Marzin | Phone/Fax: +(33) 296 05 2880/1470 F-22307 LANNION | Mobile: +(33) 6 82 90 37 85 _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel From dcpel-bounces@ietf.org Wed Oct 26 06:39:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUiga-0007Gk-AQ; Wed, 26 Oct 2005 06:39:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUigZ-0007Gf-Pa for dcpel@megatron.ietf.org; Wed, 26 Oct 2005 06:39:11 -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 GAA10562 for ; Wed, 26 Oct 2005 06:38:55 -0400 (EDT) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUiti-0004q0-P3 for dcpel@ietf.org; Wed, 26 Oct 2005 06:52:47 -0400 Received: from ftrdmel10.rd.francetelecom.fr ([10.193.117.156]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Wed, 26 Oct 2005 12:39:08 +0200 Received: from [10.193.11.122] ([10.193.11.122]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Wed, 26 Oct 2005 12:39:08 +0200 Message-ID: <435F5CCC.2090205@francetelecom.com> Date: Wed, 26 Oct 2005 12:39:08 +0200 From: Olivier Dugeon Organization: France Telecom User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: fr, en MIME-Version: 1.0 To: Kathleen Nichols Subject: Re: [Dcpel] response (changed long subject line) References: <28F05C819859B042BBF585C4997D5A476ED7B2@deex.docomolab-euro.com> <4358D229.8050808@docomolab-euro.com> <435D630E.9010701@pollere.com> In-Reply-To: <435D630E.9010701@pollere.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 26 Oct 2005 10:39:08.0619 (UTC) FILETIME=[7ECAE1B0:01C5DA19] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Content-Transfer-Encoding: quoted-printable 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dcpel-bounces@ietf.org Errors-To: dcpel-bounces@ietf.org Hi Kathleen, Kathleen Nichols a =E9crit : >Paulo Mendes wrote: > =20 > >>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 topi= cs: >>- 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. >> =20 >> > >That has been our thinking also. And I think it makes sense to seek >a charter that is limited to intra-domain at first. Many WGs >(including Diffserv) recharter when it is time for new work items >and that's a nice way to keep focus. > =20 > I understand your reason to focus on intra-domain but, IMHO I think it=20 is very important to also keep in mind the inter-domain aspect. I would=20 propose to keep in the charter a sentence which clearly say that the WG=20 will take into account the inter-domain and build a=20 framework/architecture in this perspective. So, the result from the WG=20 could be easely extend to inter-domain in a second step. > =20 > >>It seems that for now there is only Nichols's et al. ID about a strawma= n >>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. >> =20 >> > >I would welcome your input on any of these items. We put out a >strawman to give something common to talk about (even if it is >just to disagree with it. If you would like to write a brief >draft of a proposed problem statement, we could discuss that >on the list and at Vancouver. So, we have the possibility of >using the COPS RFCs as a basis for a diffserv control plane, >we have the option of looking at some solution approaches to >see if there is a stable idea of the control plane, and >we have the option of writing a problem statement. > =20 > I take the opportunity to give my understanding about COPS. I think that = COPS is more devoted to apply policy to a given set of device rather=20 than building a control Plane. In fact, the Dcpel could used COPS to=20 enforce QoS in the network and IMHO is placed on top of PDP since it=20 facilitate the PDP configuration. i.e. that it is not solved in COPS is=20 how/when/with which information an operator could easely fullfill the=20 PIB in a PDP. >>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. >> >> =20 >> > >Certainly shaping a proposal for a WG charter is still needed. This >can be done through email. > > regards, > Kathie Nichols > > >_______________________________________________ >Dcpel mailing list >Dcpel@ietf.org >https://www1.ietf.org/mailman/listinfo/dcpel > > =20 > Regards, Olivier --=20 Project Manager for Network architecture and switching Division & FT/DR&D/CORE/M2I | mailto:Olivier.Dugeon@francetelecom.com 2, Avenue Pierre Marzin | Phone/Fax: +(33) 296 05 2880/1470 F-22307 LANNION | Mobile: +(33) 6 82 90 37 85 _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel From dcpel-bounces@ietf.org Wed Oct 26 12:34:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUoEh-0006HZ-Mp; Wed, 26 Oct 2005 12:34:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUoEf-0006Fe-T6 for dcpel@megatron.ietf.org; Wed, 26 Oct 2005 12:34:45 -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 MAA06085 for ; Wed, 26 Oct 2005 12:34:29 -0400 (EDT) Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUoRq-00013p-UU for dcpel@ietf.org; Wed, 26 Oct 2005 12:48:24 -0400 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 1EUoEZ-000FDy-3G for dcpel@ietf.org; Wed, 26 Oct 2005 12:34:39 -0400 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: <435FB01A.1080306@pollere.com> Date: Wed, 26 Oct 2005 09:34:34 -0700 From: Kathleen Nichols 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: <43590931.5080809@francetelecom.com> <435D64E1.4000605@pollere.com> <435F5B3D.40706@francetelecom.com> In-Reply-To: <435F5B3D.40706@francetelecom.com> 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: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id MAA06085 X-BeenThere: dcpel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for possible diffserv control plane elements WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dcpel-bounces@ietf.org Errors-To: dcpel-bounces@ietf.org Olivier Dugeon wrote: > Kathleen Nichols a =E9crit : >=20 >> Olivier Dugeon wrote: ... >=20 >>> So, do you think the charter must be only focus on DiffServ or could = it >>> be open to other QoS enforcement mechanism ? Or, for the strategy, is= it >>> preferable to focus on DiffServ, and after the WG created, open the >>> scope to other technology ? >>> =20 >> I'm in favor of keeping the focus limited at any one time, but >> rechartering is fine when some things get done. But what other QoS >> enforcement mechanisms did you have in mind besides diffserv? >> =20 > In fact, inside the EuQoS project, we intend to manage several > technology (in particular the access part) across a common view of the > QoS. This why, in our architecture there is 2 view of the Control Plane. > One which technology independent and manage the inter-domain and the > other which is technology dependent and manage the intra domain part. > So, from the DiffServ point of view, this could result to setup > approriate L2 mechanism in order to provide a DiffServ aware QoS > mechanism. For example, in xDSL ATM or GE network, the EF class could b= e > map to a CBR ATM ATC or a particular VLAN. This could be also apply if > you intend to used MPLS-DiffServ mechanism. > Okay, this is of course useful stuff and something we all end up doing in adapting to a particular network. It seems like it would be useful if it is possible to have some kind of commonality in how L2 interacts with L3 diffserv mechansims so that the control plane can be technology independent. Though this needs to be considered when designing a network QoS solution, I'm not sure we should put it on dcpel's work list. At least not immediately. It seems to me that at some point this might need some kind of sub-category of "Advice to Link Layer Designers". >> >>> I'm also very confident in this attempt since this kind of functions = are >>> now studied in various place: >>> So, in your opinion, what are the major things Dcpel could *add* to this work? Kathie _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel From dcpel-bounces@ietf.org Thu Oct 27 07:35:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV62B-00081v-Lk; Thu, 27 Oct 2005 07:35:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV629-00081F-NK for dcpel@megatron.ietf.org; Thu, 27 Oct 2005 07:35:01 -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 HAA22537 for ; Thu, 27 Oct 2005 07:34:44 -0400 (EDT) Received: from deprox.docomolab-euro.com ([212.119.9.186]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EV6FV-00074b-LH for dcpel@ietf.org; Thu, 27 Oct 2005 07:48:50 -0400 Received: from 172.27.10.3 by deprox.docomolab-euro.com (InterScan E-Mail VirusWall NT); Thu, 27 Oct 2005 13:34:32 +0200 Received: from [172.27.100.57] ([172.27.100.57]) by deex.docomolab-euro.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 27 Oct 2005 13:34:32 +0200 Message-ID: <4360BBE9.3070207@docomolab-euro.com> Date: Thu, 27 Oct 2005 13:37:13 +0200 From: Paulo Mendes User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Olivier Dugeon Subject: Re: [Dcpel] Dcpel BoF support References: <43590931.5080809@francetelecom.com> In-Reply-To: <43590931.5080809@francetelecom.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Oct 2005 11:34:32.0591 (UTC) FILETIME=[667281F0:01C5DAEA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Content-Transfer-Encoding: 7bit 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dcpel-bounces@ietf.org Errors-To: dcpel-bounces@ietf.org Hi Olivier, Kathleen and all, It is good to know that the partners in IST EuQoS are planning to support this BoF. I was acquainted in joint QoS workshop of EuQoS and Mescal with the idea to create one BoF on Resource Management. I think that the QoS community will gain in having all the interested parties in the same BoF. So, it will be a good exercise to merge, as possible, the ideas behind both proposals. 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. 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. 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. 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. Cheers, Paulo Olivier Dugeon wrote: > Hi Kahtleen and all, > > I saw some days ago your announce for the Dcpel BoF, and I'm very > enthousiste about your initiative. Indeed, I'm working for 5 years now > in the field of QoS control and especially the control plane of IP > network. My past research concern an european IST project named > CADENUS (http://www.cadenus.fokus.fraunhofer.de) which aimed to define > a QoS framework and also follow on the TEQUILA one > (http://www.ist-tequila.org) . Now I'm involve in a new european > project named EuQoS (http://www.euqos.org) which have for goal to > study the end-to-end QoS over heterogeneous network. Inside France > Telecom, I also conducting projects in this field area, and, inside > this scope, have established a great collaboration with Operax people. > > In june, we organized a joint QoS workshop with EuQoS and Mescal > project. Proceeding of this workshop could be found at > http://www.euqos.org/shownews.php?idnews=9 or at > http://www.mescal.org/EEQoS/index.html which could give you a good > overview of the start of the art of the european research in this > area. The conclusion of this workshop was about the creation of a > Resource Management BoF for the control plane of IP network. A > dedicated mailing list have been created for this purpose to > carrefully prepare the BoF since many attemps was unsuccessfull during > the past (for example SLS BoF, NSIS off-path and so on). But, this > attempt didn't encounter success. So, it was a pleasure to discover > your initiative and to joint it. > >>From the EuQoS board, many peoples have express their interrest for > this BoF. Inside France Telecom, I already got interests from my > colleagues for such study, and of course, to support this BoF. > > Concerning the charter, in our initiative, we intend to not only focus > on DiffServ to enforce QoS in the network. Our goal was more to define > a Resource Manager framework with the corresponding > interface/protocols around it: > > - Topology acquisition > - Inter Resouce Manager protocol both for intra and inter domain SLS > exchange > - Service request interface > - Devices configuration which in fact have link to COPS and netconf WG > - Link to PCE > > We have volunteer exclude business aspect as well as the Call > Admission Control algorithm which, in our opinion are not in the scope > of the IETF. In parallel, and for the framework, we think that we must > seperate what is devoted for the provisionning of resources and the > usage of the resources itself (i.e. the per flow control). In fact, it > could be related to the NSIS off-path BoF attempt which occur some > time ago. > > So, do you think the charter must be only focus on DiffServ or could > it be open to other QoS enforcement mechanism ? Or, for the strategy, > is it preferable to focus on DiffServ, and after the WG created, open > the scope to other technology ? > > I'm also very confident in this attempt since this kind of functions > are now studied in various place: > > - The Multi Switching Forum (MSF) have already identified a such > function (Bandwidth Manager) for VoIP. The document was written by > Operax people. > - The ETSI-TISPAN have almost achieve the specification of the RACS > (Resource Allocation Control Subsystem) which embedded the RACF > (Resource Allocation Control Function) for the fixed/mobile IMS > convergence. > - 3Gpp has already specify such function in Release R6 for the IMS (IP > Multemedia Subsystem) > - The ITU-T NGN Focus Group doing a parallel work as the ETSI, but > including the intra domain and in a more general way as the IMS > - And recently the DSL Forum has lunch a new Work Item about the > Policy Control Framework. > > Finally, the IETF is the only place where such study is not yet conduct. > > I not planned to attend the Vancouver meeting, but people from the > EuQoS board as well as the France Telecom delegation could attend the BoF. > > Best regards, > > Olivier Dugeon > >-- >Project Manager for Network architecture and switching Division > & FT/DR&D/CORE/M2I | mailto:Olivier.Dugeon@francetelecom.com > 2, Avenue Pierre Marzin | Phone/Fax: +(33) 296 05 2880/1470 > F-22307 LANNION | Mobile: +(33) 6 82 90 37 85 > > >------------------------------------------------------------------------ > >_______________________________________________ >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 From dcpel-bounces@ietf.org Thu Oct 27 07:35:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV62H-00083A-VW; Thu, 27 Oct 2005 07:35:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV62E-00082y-UR for dcpel@megatron.ietf.org; Thu, 27 Oct 2005 07:35:08 -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 HAA22542 for ; Thu, 27 Oct 2005 07:34:50 -0400 (EDT) Received: from deprox.docomolab-euro.com ([212.119.9.186]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EV6Fa-00075E-L4 for dcpel@ietf.org; Thu, 27 Oct 2005 07:48:55 -0400 Received: from 172.27.10.3 by deprox.docomolab-euro.com (InterScan E-Mail VirusWall NT); Thu, 27 Oct 2005 13:34:49 +0200 Received: from [172.27.100.57] ([172.27.100.57]) by deex.docomolab-euro.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 27 Oct 2005 13:34:49 +0200 Message-ID: <4360BBFB.80907@docomolab-euro.com> Date: Thu, 27 Oct 2005 13:37:31 +0200 From: Paulo Mendes User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kathleen Nichols Subject: Re: [Dcpel] response (changed long subject line) References: <28F05C819859B042BBF585C4997D5A476ED7B2@deex.docomolab-euro.com> <4358D229.8050808@docomolab-euro.com> <435D630E.9010701@pollere.com> In-Reply-To: <435D630E.9010701@pollere.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Oct 2005 11:34:49.0232 (UTC) FILETIME=[705DB900:01C5DAEA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: 7bit 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dcpel-bounces@ietf.org Errors-To: dcpel-bounces@ietf.org Hi Kathleen, Kathleen Nichols wrote: >Paulo Mendes wrote: > > >>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. >> >> > >That has been our thinking also. And I think it makes sense to seek >a charter that is limited to intra-domain at first. Many WGs >(including Diffserv) recharter when it is time for new work items >and that's a nice way to keep focus. > > [Paulo] I agree. We can do this is two ways: a) create a charter only for intra-domain issues, keeping in mind that the charter may be changed latter to include inter-domain issues; b) he create a charter encompassing intra- and inter- domain issues, but we define a clear work plan, which should give higher priority to intra-domain issues. I would prefer the option b), because this will make the WG stronger, since we aim to provide the needed E2E solution. And in the end is this that matters. If you follow option a), we are leaving behind the major reason not to have QoS deployed in the Internet, which is the lack of inter-domain control. I'm a little afraid that if we don't include the inter-domain control in our list of priorities, it may happen that we end up again with a half-solution: control of Diffserv networks but still no end-to-end QoS. >>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. >> >> > >I would welcome your input on any of these items. We put out a >strawman to give something common to talk about (even if it is >just to disagree with it. If you would like to write a brief >draft of a proposed problem statement, we could discuss that >on the list and at Vancouver. So, we have the possibility of >using the COPS RFCs as a basis for a diffserv control plane, >we have the option of looking at some solution approaches to >see if there is a stable idea of the control plane, and >we have the option of writing a problem statement. > > I would very much like to contribute to this problem statement draft, since it will clarify our goals. If we do this, can you present the draft in Vancouver? (like I said in my last email, unfortunately I cannot attend the IETF meeting in Vancouver). >>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. >> >> >> > >Certainly shaping a proposal for a WG charter is still needed. This >can be done through email. > > regards, > Kathie Nichols > > Cheers Paulo _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel From dcpel-bounces@ietf.org Thu Oct 27 07:35:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV62W-0008Fg-Mt; Thu, 27 Oct 2005 07:35:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV62V-0008EI-9j for dcpel@megatron.ietf.org; Thu, 27 Oct 2005 07:35:23 -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 HAA22557 for ; Thu, 27 Oct 2005 07:35:06 -0400 (EDT) Received: from deprox.docomolab-euro.com ([212.119.9.186]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EV6Fr-00075o-8Z for dcpel@ietf.org; Thu, 27 Oct 2005 07:49:11 -0400 Received: from 172.27.10.3 by deprox.docomolab-euro.com (InterScan E-Mail VirusWall NT); Thu, 27 Oct 2005 13:35:04 +0200 Received: from [172.27.100.57] ([172.27.100.57]) by deex.docomolab-euro.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 27 Oct 2005 13:35:04 +0200 Message-ID: <4360BC0A.40302@docomolab-euro.com> Date: Thu, 27 Oct 2005 13:37:46 +0200 From: Paulo Mendes User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Olivier Dugeon Subject: Re: [Dcpel] response (changed long subject line) References: <28F05C819859B042BBF585C4997D5A476ED7B2@deex.docomolab-euro.com> <4358D229.8050808@docomolab-euro.com> <435D630E.9010701@pollere.com> <435F5CCC.2090205@francetelecom.com> In-Reply-To: <435F5CCC.2090205@francetelecom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-OriginalArrivalTime: 27 Oct 2005 11:35:04.0435 (UTC) FILETIME=[796D8430:01C5DAEA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id HAA22557 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dcpel-bounces@ietf.org Errors-To: dcpel-bounces@ietf.org Hi there, some comments inline... Olivier Dugeon wrote: > Hi Kathleen, > > Kathleen Nichols a =E9crit : > >> Paulo Mendes wrote: >> =20 >> >>> Hello, >>> >>> I'm quite interested in this BOF. Actually, for a long time that I wa= s >>> 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=20 >>> topics: >>> - Dynamic control of inter-domain QoS with local configuration of PDB= s: >>> - 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-doma= in >>> 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. >>> =20 >> >> >> That has been our thinking also. And I think it makes sense to seek >> a charter that is limited to intra-domain at first. Many WGs >> (including Diffserv) recharter when it is time for new work items >> and that's a nice way to keep focus. >> =20 >> > I understand your reason to focus on intra-domain but, IMHO I think it=20 > is very important to also keep in mind the inter-domain aspect. I=20 > would propose to keep in the charter a sentence which clearly say that=20 > the WG will take into account the inter-domain and build a=20 > framework/architecture in this perspective. So, the result from the WG=20 > could be easely extend to inter-domain in a second step. > >> =20 >> >>> It seems that for now there is only Nichols's et al. ID about a=20 >>> 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 nex= t >>> step may be the classification of existing solutions and identificati= on >>> of missing functionalities. Otherwise, it is better to clearly identi= fy >>> the problem statement, and a set or requirements and assumptions. >>> =20 >> >> >> I would welcome your input on any of these items. We put out a >> strawman to give something common to talk about (even if it is >> just to disagree with it. If you would like to write a brief >> draft of a proposed problem statement, we could discuss that >> on the list and at Vancouver. So, we have the possibility of >> using the COPS RFCs as a basis for a diffserv control plane, >> we have the option of looking at some solution approaches to >> see if there is a stable idea of the control plane, and >> we have the option of writing a problem statement. >> =20 >> > I take the opportunity to give my understanding about COPS. I think=20 > that COPS is more devoted to apply policy to a given set of device=20 > rather than building a control Plane. In fact, the Dcpel could used=20 > COPS to enforce QoS in the network and IMHO is placed on top of PDP=20 > since it facilitate the PDP configuration. i.e. that it is not solved=20 > in COPS is how/when/with which information an operator could easely=20 > fullfill the PIB in a PDP. [Paulo] Keeping in mind a modular distinction between inter- and=20 intra-domain, I would say that based on a set of available inter-domain=20 QoS agreements, the PDP, which control the QoS agreements, may use COPS=20 to enforce QoS in the network, as you say. But we must see what do you=20 mean by "enforcing the QoS in the network". IMHO there are two options:=20 a) a centralized one, in which the PDP uses COPS to configure all the=20 needed routers; b) a decentralized one, in which the PDP used COPS to=20 configure the ingress PEP, and to inform the PEP about the PDB that=20 needs to be setup. Based on this information the PEP uses an=20 intra-domain signaling protocol to perform class configuration until the=20 required egress point. This signaling may be based on a NSIS protocol. > >>> 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. >>> >>> =20 >> >> >> Certainly shaping a proposal for a WG charter is still needed. This >> can be done through email. >> >> regards, >> Kathie Nichols >> >> >> _______________________________________________ >> Dcpel mailing list >> Dcpel@ietf.org >> https://www1.ietf.org/mailman/listinfo/dcpel >> >> =20 >> > Regards, > > Olivier > _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel From dcpel-bounces@ietf.org Thu Oct 27 13:18:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVBOp-0001eH-K0; Thu, 27 Oct 2005 13:18:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVBOn-0001an-SX for dcpel@megatron.ietf.org; Thu, 27 Oct 2005 13:18:45 -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 NAA16740 for ; Thu, 27 Oct 2005 13:18:29 -0400 (EDT) Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVBcD-0004P6-3j for dcpel@ietf.org; Thu, 27 Oct 2005 13:32:37 -0400 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 1EVBOf-0008pG-Of for dcpel@ietf.org; Thu, 27 Oct 2005 13:18:37 -0400 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: <43610BEA.6010409@pollere.com> Date: Thu, 27 Oct 2005 10:18:34 -0700 From: Kathleen Nichols 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: <43590931.5080809@francetelecom.com> <4360BBE9.3070207@docomolab-euro.com> In-Reply-To: <4360BBE9.3070207@docomolab-euro.com> X-Enigmail-Version: 0.90.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit X-BeenThere: dcpel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for possible diffserv control plane elements WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dcpel-bounces@ietf.org Errors-To: dcpel-bounces@ietf.org 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. > > 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. > > 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 From dcpel-bounces@ietf.org Thu Oct 27 13:21:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVBRH-0003gJ-AL; Thu, 27 Oct 2005 13:21:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVBRE-0003cs-QL for dcpel@megatron.ietf.org; Thu, 27 Oct 2005 13:21:18 -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 NAA16881 for ; Thu, 27 Oct 2005 13:21:00 -0400 (EDT) Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVBed-0004VV-6J for dcpel@ietf.org; Thu, 27 Oct 2005 13:35:08 -0400 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 1EVBRC-0009Xi-JL for dcpel@ietf.org; Thu, 27 Oct 2005 13:21:14 -0400 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: <43610C88.7030801@pollere.com> Date: Thu, 27 Oct 2005 10:21:12 -0700 From: Kathleen Nichols 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] response (changed long subject line) References: <28F05C819859B042BBF585C4997D5A476ED7B2@deex.docomolab-euro.com> <4358D229.8050808@docomolab-euro.com> <435D630E.9010701@pollere.com> <4360BBFB.80907@docomolab-euro.com> In-Reply-To: <4360BBFB.80907@docomolab-euro.com> X-Enigmail-Version: 0.90.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit X-BeenThere: dcpel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for possible diffserv control plane elements WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dcpel-bounces@ietf.org Errors-To: dcpel-bounces@ietf.org Paulo Mendes wrote: ... > I would very much like to contribute to this problem statement draft, > since it will clarify our goals. If we do this, can you present the > draft in Vancouver? (like I said in my last email, unfortunately I > cannot attend the IETF meeting in Vancouver). > If you produce something we can put out on the list (it can go into the I-D repository later) and we are given sufficient time, I would be happy to put it on the agenda for discussion. Perhaps some of us can meet separately if there is insufficient time. And we can always have list discussion. Kathie _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel From dcpel-bounces@ietf.org Fri Oct 28 05:28:37 2005 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 ; 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: X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Thread-Topic: [Dcpel] Dcpel BoF support Thread-Index: AcXbGrRcBK6TvTBlQ9ipfckzMv7CLQAgdPvQ From: =?iso-8859-15?Q?Attila_B=E1der_=28IJ/ETH=29?= To: "Kathleen Nichols" , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dcpel-bounces@ietf.org Errors-To: dcpel-bounces@ietf.org Dear All, =20 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.=20 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 >=20 >=20 > Paulo Mendes wrote: > ... > >=20 > > 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. >=20 > [Kathie]I believe division is the way to go, but I think we=20 > 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. >=20 > > >=20 > > You say that your focus in not on DiffServ to enforce QoS in the > > network, but on the definition of a Resource Manager=20 > framework. Good, > > but this Resource Management framework can still be defined with two > > modules for inter- and intra-domain, connected by a network=20 > interface. > > But, in what concerns the intra-domain resource control, I=20 > don't know > > why shouldn't we focus on DiffServ. First, the DiffServ=20 > model is clearly > > lacking a control plane; second, other QoS enforcement=20 > 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. >=20 > [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. > > >=20 > > 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",=20 > which will then > > need to collect topology information? Since a PDB is=20 > 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=20 > robustness and > > perhaps performance. >=20 > Hmm, I don't think topology acquisition necessarily means=20 > "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=20 > 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. > >=20 > > In what concerns the other standardization efforts, I would=20 > say that it > > would help a lot this BoF, if we had a brief document=20 > characterizing the > > differences between all these approaches to see where this=20 > BoF would fit. >=20 > 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. >=20 > Kathie >=20 >=20 > _______________________________________________ > Dcpel mailing list > Dcpel@ietf.org > https://www1.ietf.org/mailman/listinfo/dcpel >=20 _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel From dcpel-bounces@ietf.org Fri Oct 28 11:58:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVWcH-0005fi-UZ; Fri, 28 Oct 2005 11:58:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVWcG-0005fd-61 for dcpel@megatron.ietf.org; Fri, 28 Oct 2005 11:58:04 -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 LAA25991 for ; Fri, 28 Oct 2005 11:57:47 -0400 (EDT) Received: from deprox.docomolab-euro.com ([212.119.9.186]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EVWpq-0001nU-9e for dcpel@ietf.org; Fri, 28 Oct 2005 12:12:07 -0400 Received: from 172.27.10.3 by deprox.docomolab-euro.com (InterScan E-Mail VirusWall NT); Fri, 28 Oct 2005 17:57:30 +0200 Received: from [172.27.100.57] ([172.27.100.57]) by deex.docomolab-euro.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 28 Oct 2005 17:57:30 +0200 Message-ID: <43624B0C.2090209@docomolab-euro.com> Date: Fri, 28 Oct 2005 18:00:12 +0200 From: Paulo Mendes User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kathleen Nichols Subject: Re: [Dcpel] response (changed long subject line) References: <28F05C819859B042BBF585C4997D5A476ED7B2@deex.docomolab-euro.com> <4358D229.8050808@docomolab-euro.com> <435D630E.9010701@pollere.com> <4360BBFB.80907@docomolab-euro.com> <43610C88.7030801@pollere.com> In-Reply-To: <43610C88.7030801@pollere.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Oct 2005 15:57:30.0302 (UTC) FILETIME=[4D1BE5E0:01C5DBD8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dcpel-bounces@ietf.org Errors-To: dcpel-bounces@ietf.org Hi Kathleen and all, I would like to give it a try, and write a I-D focusing on the problem statement. However, due to traveling, I can only write this I-D on the 3rd-4th of November. I can send it then to the mailing list. I hope this is not too late to allow us to discuss it in the mailing list, before Vancouver. Paulo Kathleen Nichols wrote: >Paulo Mendes wrote: >... > > >>I would very much like to contribute to this problem statement draft, >>since it will clarify our goals. If we do this, can you present the >>draft in Vancouver? (like I said in my last email, unfortunately I >>cannot attend the IETF meeting in Vancouver). >> >> >> > >If you produce something we can put out on the list (it can go into >the I-D repository later) and we are given sufficient time, I would >be happy to put it on the agenda for discussion. Perhaps some of us >can meet separately if there is insufficient time. And we can always >have list discussion. > > 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