From dcpel-bounces@ietf.org Fri Mar 03 08:49:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFAen-00070U-Ms; Fri, 03 Mar 2006 08:49:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFAem-0006sc-Ic for dcpel@ietf.org; Fri, 03 Mar 2006 08:49:20 -0500 Received: from deprox.docomolab-euro.com ([212.119.9.186]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FFAem-0005y8-4M for dcpel@ietf.org; Fri, 03 Mar 2006 08:49:20 -0500 Received: from 172.27.10.3 by deprox.docomolab-euro.com (InterScan E-Mail VirusWall NT); Fri, 03 Mar 2006 14:49:09 +0100 Received: from [172.27.100.57] ([172.27.100.57]) by deex.docomolab-euro.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 3 Mar 2006 14:49:09 +0100 Message-ID: <4408495A.10003@docomolab-euro.com> Date: Fri, 03 Mar 2006 14:49:14 +0100 From: Paulo Mendes User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Olivier Dugeon Subject: Re: [Dcpel] DCPEL BoF support References: <43FF0D8F.1020800@rd.francetelecom.com> In-Reply-To: <43FF0D8F.1020800@rd.francetelecom.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Mar 2006 13:49:09.0437 (UTC) FILETIME=[3F15A6D0:01C63EC9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 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: , Errors-To: dcpel-bounces@ietf.org Hi Olivier, see my comments inline. Olivier Dugeon wrote: > Hello Kathleen and all, > > We are in favor of a such BoF. Again, I'll ask my colleagues whom > attend the next IETF meeting to be present during the DCPEL BoF > session regarding their respective constraint to follow their > respective WG. > > Concerning the charter, I just want to know if the points described > below could be present: > > - Study and define a global framework and architecture which take into > account the inter-domain control plane and not only the intra-domain [Paulo] The definition of a overall architecture is already scheduled in the current proposed charter. And the current version of the DCPEL requirements I-D, already mention the the Diffserv control plane, should consider the inter-domain relationship besides the intra-domain control. The creation of an I-D on interworking between DiffServ domains is also planned in the charter proposal. > - Produce RFC about the end to end CoS definition i.e. by extending > the notion of Per Domain Behavior to the inter domain. The draft about > Meta-CoS class from Pierre Levis could be a starting point [Paulo] The e2e definition of CoS should be discussed. IMO, it is most helpful if we keep the intra-domain mechanisms and PDBs transparent to the inter-domain operations, and so e2e. So, I would say that the definition of e2e CoS is related to the use of the inter-domain service information model, and not the to PDBs to be used within a network. The relationship between PDBs and services (SLSs) is something to be worked out within DCPEL. > - Produce RFC which define both data and interface to request CoS to > the DCPEL framework from and application i.e. SLS definition in term > of parameters, function and transport prootocol [Paulo] The first issue of an I-D on DCP service information model is schedule for November 2006, while the interworking of a DCP network with external mechanisms will be analyzed in the framework I-D. > - Produce RFC on topology acquisition to let the Control Plane in > touch (synchronize) with the Transfert Plane [Paulo] This is a topic related to a centralized control plane. Since the DCPEL requirements I-D mention the possible centralized and distributed control of PDBs, and assuming that this proposal will be accepted, I'm expecting some I-D proposals for DCP centralized mechanisms and distributed mechanisms (December 2006 in the current charter proposal). It is up to the authors of the centralized proposals to refer to describe mechanisms for the acquisition of topology information. > - Produce RFC on which protocol will fit requirement to exchange > inter-DCPEL SLS i.e. looking how NSIS could fit or be extended to this > purpose. [Paulo] This is contemplated in the I-D on interworking between DiffServ domain (scheduled March 2007 in the current charter). It is expectable that we'll be able to discuss different approaches to allow the interworking of DiffServ domains, based for instance on NSIS, SIP, or other protocol model. > - Produce RFC on which protocol will fit requirement to enforce QoS in > the underlying network i.e lookink to COPS and NetConf to see how it > could be used [Paulo] This is also mostly specific to centralized control approaches. Cheers Paulo > > Please, don't hesitate to comment. > > Regards, > > Olivier > > PS. I will be out of my office next week and have sporadic access to > my e-mail > > _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel From dcpel-bounces@ietf.org Fri Mar 03 08:49:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFAet-0007Fz-V0; Fri, 03 Mar 2006 08:49:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFAes-0007Fu-PD for dcpel@ietf.org; Fri, 03 Mar 2006 08:49:27 -0500 Received: from deprox.docomolab-euro.com ([212.119.9.186]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FFAes-0005yN-AJ for dcpel@ietf.org; Fri, 03 Mar 2006 08:49:26 -0500 Received: from 172.27.10.3 by deprox.docomolab-euro.com (InterScan E-Mail VirusWall NT); Fri, 03 Mar 2006 14:49:03 +0100 Received: from [172.27.100.57] ([172.27.100.57]) by deex.docomolab-euro.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 3 Mar 2006 14:49:03 +0100 Message-ID: <44084954.8090201@docomolab-euro.com> Date: Fri, 03 Mar 2006 14:49:08 +0100 From: Paulo Mendes User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Georgios Karagiannis Subject: Re: [Dcpel] questions related to DCPEL scope References: <43FE2D61.8050307@pollere.com> <007d01c63940$ae5df080$4c0d5982@dynamic.ewi.utwente.nl> In-Reply-To: <007d01c63940$ae5df080$4c0d5982@dynamic.ewi.utwente.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Mar 2006 13:49:03.0187 (UTC) FILETIME=[3B5BFA30:01C63EC9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e 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: , Errors-To: dcpel-bounces@ietf.org Hi Georgios, IMO, a state of the art study about centralized approaches should not have an impact on the DCPEL BOF/WG charter. The major reason is that the internetworking approach followed by IETF and other organizations, such as 3GPP, is different: IETF vision of internetworking was always more close to a distributed approach, while other organizations have been following a more centralized approach. Nevertheless, I agree that existing centralized resource management approaches should be analyzed. But, IMO, this should be done against the DCPEL requirements I-D. This is, if some of those approaches fulfill the requirements agreed within DCPEL, they (intact, changed or simplified) may be candidates to integrate a DiffServ control plane. But, I also want to stress that the DCPEL requirements I-D mention also distributed control approaches as suitable for the DiffServ control plane, following a more IETF way of doing internetworking. Cheers Paulo Georgios Karagiannis wrote: > Hi Kathie > > Please do not understand me wrong! > I am in favour of starting the DCPEL WG. > My concerns are related to the match between the DCPEL charter activities > and the work that has been by theITU-t, ETSI-tispan, DSL, packetcable, > 3gpp, 3gpp2, > ipshere, wimax goups on the area of centralized control plane > architectures. > I think that it is useful to start the work in DCPEL WG considering as > starting point > the work that has been done already in the other groups. > > Best Regards, > Georgios > > > > ----- Original Message ----- From: "Kathleen Nichols" > > To: "Georgios Karagiannis" > Cc: > Sent: Thursday, February 23, 2006 10:47 PM > Subject: Re: [Dcpel] questions related to DCPEL scope > > >> >> Trimmed to reply (in-line) to your comments: >> >> Georgios Karagiannis wrote: >> ... >> >>>> >> [G]>>> Could you specify what do you mean by a distributed Difsserv >> control >> >>>>> plane approach? Will this distributed approach impact an individual >>>>> Diffserv router, e.g., a Diffserv core router? >>>> >> [K]>> I'm just giving a short answer here. A distributed DiffServ >> control >> >>>> plane is one where the control plane actions do not reside in >>>> one physical location and probably not in one logical location. >>>> We would expect an impact on DiffServ edge routers, but probably >>>> not DiffServ core routers. >>> >>> >>> Georgios: But I suppose that this will of depend on the specified PDBs. >>> What if a PDB requires a control plane support for a core Diffserv >>> router? >>> >> >> If by core Diffserv router you mean a diffserv router interior to a >> domain, one would not normally expect the need for control of >> classifiers and policers, but just configuration of the PHBs as >> realized by queues and their scheduler, as described in RFC 2475 >> and other diffserv documents. However, this doesn't preclude an >> operator from using the diffserv "edge" functions interior to a >> network if desired. >> >> ... >> >>> Georgios: Maybe it is very useful to perform an extensive state of the >>> art study on the area of centralized control plane architectures that >>> are developed in ITU-t, ETSI-tispan, DSL, packetcable, 3gpp, 3gpp2, >>> ipshere, wimax. The outcome of this state of the art study could then >>> help to define >>> the final charter of the DCPEL BOF/WG. >>> >> >> Do you believe that the work of these groups obviates an IETF DCPEL WG? >> >> regards, >> 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 From dcpel-bounces@ietf.org Fri Mar 03 08:49:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFAfG-0008Dn-3y; Fri, 03 Mar 2006 08:49:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFAfF-0008Cl-77 for dcpel@ietf.org; Fri, 03 Mar 2006 08:49:49 -0500 Received: from deprox.docomolab-euro.com ([212.119.9.186]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FFAfE-0005ye-QQ for dcpel@ietf.org; Fri, 03 Mar 2006 08:49:49 -0500 Received: from 172.27.10.3 by deprox.docomolab-euro.com (InterScan E-Mail VirusWall NT); Fri, 03 Mar 2006 14:49:37 +0100 Received: from [172.27.100.57] ([172.27.100.57]) by deex.docomolab-euro.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 3 Mar 2006 14:49:37 +0100 Message-ID: <44084977.2050101@docomolab-euro.com> Date: Fri, 03 Mar 2006 14:49:43 +0100 From: Paulo Mendes User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hancock, Robert" Subject: Re: [Dcpel] some comments on draft-vandenberghe-dcpel-basics-00.txt References: <43FF8D51.8050501@pollere.com> In-Reply-To: <43FF8D51.8050501@pollere.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Mar 2006 13:49:37.0703 (UTC) FILETIME=[4FEEB370:01C63EC9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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: , Errors-To: dcpel-bounces@ietf.org Hi Robert, to add something to Kathie's e-mail, here is an extract of your e-mail: Kathleen Nichols wrote: > ....... > >> 4. SIP interactions > > > The quick response is that we didn't plan to change SIP or 3312 but > to use that as a guideline for our framework, that is, our framework > should have a way to interoperate in the 3312 sense. It was suggested > as a starting point (and maybe sufficient) for application > interaction. [Paulo] It is also my opinion that 3312 can provide some guideline on the interaction between applications and network, in both ends of a communication session. However, IMO it is not clear the interaction of the SIP signaling and the DiffServ inter-domain interactions. In 3312, it is proposed to configure network resources e2e by means of a protocol like RSVP, being the RSVP signaling triggered by end-hosts at both ends of the communication session. In this context, 3312 approach may be an option to trigger the configuration of the necessary PDBs in all DiffServ domains between the involved end-hosts. However, the most suitable mechanism to configure PDBs in a set of DiffServ domains should be analyzed within DCPEL. > >> 5. Is development of signalling protocols in scope or not? >> >> 4.1.2 says that "...definition of an interdomain QoS signaling protocol >> is considered as future work for the proposed DCPEL WG", but 4.2 only >> lists interworking with existing protocols. This seems contradictory. > > > So I think this is a language failure. I think we meant something more > like "selection" instead of "definition" subject to the state of the > art at the time interdomain is being considered. But perhaps others > have a different opinion. [Paulo] My opinion is somehow similar. It is not the main focus of DCPEL the definition of new signaling protocols. Like I said in my previous comment, our attention is to analyze what is the best approach to control the interworking between DiffServ domains. This analysis may lead to the selection of an existing protocol. For instance, we may conclude that QoS-NSLP may be used to provide some kind of interworking. But we may also conclude that other signaling protocols (presented as I-D) may also bring benefits to DiffServ interworking. In the later case, we must decide what to do. An hypothesis may be, for instance, to propose the specification of a new NSLP to the NSIS WG. Cheers Paulo _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel From dcpel-bounces@ietf.org Fri Mar 03 09:46:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFBXv-0007h1-47; Fri, 03 Mar 2006 09:46:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFBXt-0007fC-Hk for dcpel@ietf.org; Fri, 03 Mar 2006 09:46:17 -0500 Received: from tla.crepundia.net ([194.71.127.149] helo=report.tla-group.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFBXs-0007yu-3j for dcpel@ietf.org; Fri, 03 Mar 2006 09:46:17 -0500 Received: from [127.0.0.1] (report.tla-group.com [194.71.127.149]) by report.tla-group.com (8.12.4/8.12.4) with ESMTP id k23E5vHC010998; Fri, 3 Mar 2006 15:05:57 +0100 In-Reply-To: <43FF0D8F.1020800@rd.francetelecom.com> References: <43FF0D8F.1020800@rd.francetelecom.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Avri Doria Subject: Re: [Dcpel] DCPEL BoF support Date: Fri, 3 Mar 2006 15:46:11 +0100 To: Kathleen Nichols X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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: , Errors-To: dcpel-bounces@ietf.org On 24 feb 2006, at 14.43, Olivier Dugeon wrote: > We are in favor of a such BoF. is there going to be a BoF? I don't see one on the current draft schedule. I know it is too late, but i think having a BoF would be a good thing, even if it ends up an informal affair at this point. a. _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel From dcpel-bounces@ietf.org Mon Mar 06 04:24:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGBxS-0001JU-R7; Mon, 06 Mar 2006 04:24:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGBxR-0001JP-Up for dcpel@ietf.org; Mon, 06 Mar 2006 04:24:49 -0500 Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGBxQ-000862-F5 for dcpel@ietf.org; Mon, 06 Mar 2006 04:24:49 -0500 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id k269OeoW021261; Mon, 6 Mar 2006 09:24:41 GMT MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In-Reply-To: <44084977.2050101@docomolab-euro.com> X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-OlkEid: E3848C283B9805ED3D7D8143AE3E0C6BFA536B88 Content-class: urn:content-classes:message Subject: RE: [Dcpel] some comments on draft-vandenberghe-dcpel-basics-00.txt Date: Mon, 6 Mar 2006 09:24:40 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dcpel] some comments on draft-vandenberghe-dcpel-basics-00.txt Thread-Index: AcZAroLX4nHk2FzlQrq2HQfKTVt25w== From: "Hancock, Robert" To: "Paulo Mendes" X-MailScanner-rsys001x: Found to be clean X-MailScanner-rsys001x-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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: , Errors-To: dcpel-bounces@ietf.org hi, > Hi Robert, >=20 > to add something to Kathie's e-mail, here is an extract of=20 > your e-mail: >=20 >=20 > Kathleen Nichols wrote: >=20 > > ....... > > > >> 4. SIP interactions > > > > > > The quick response is that we didn't plan to change SIP or 3312 but > > to use that as a guideline for our framework, that is, our framework > > should have a way to interoperate in the 3312 sense. It was=20 > suggested > > as a starting point (and maybe sufficient) for application > > interaction. >=20 > [Paulo] It is also my opinion that 3312 can provide some guideline on=20 > the interaction between applications and network, in both ends of a=20 > communication session. However, IMO it is not clear the=20 > interaction of=20 > the SIP signaling and the DiffServ inter-domain interactions.=20 > In 3312,=20 > it is proposed to configure network resources e2e by means of=20 > a protocol=20 > like RSVP, being the RSVP signaling triggered by end-hosts at=20 > both ends=20 > of the communication session. In this context, 3312 approach=20 > may be an=20 > option to trigger the configuration of the necessary PDBs in all=20 > DiffServ domains between the involved end-hosts. However, the most=20 > suitable mechanism to configure PDBs in a set of DiffServ=20 > domains should=20 > be analyzed within DCPEL. All of this is true. However, it doesn't explain why 3312 would be relevant to DCPEL, unless I've fundamentally misunderstood the=20 scope of DCPEL. To put is more concretely, 3312 (as far as I understand) assumes the existence of a resource request mechanism initiated by the end point, and explains how end systems should manage the resource=20 transaction and session signalling transaction. But the resource management mechanism (RSVP, NSIS or whatever) doesn't care that=20 3312 is being used - is DCPEL any different? To put it another way, 3312 is about extending SDP with additional information. Is it in the scope of DCPEL to take part in the SDP negotiation? r. _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel From dcpel-bounces@ietf.org Tue Mar 07 06:22:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGaHI-0000Fd-9A; Tue, 07 Mar 2006 06:22:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGaHG-0000FY-KX for dcpel@ietf.org; Tue, 07 Mar 2006 06:22:54 -0500 Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGaHG-00073Z-5C for dcpel@ietf.org; Tue, 07 Mar 2006 06:22:54 -0500 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id k27BMhoW026462; Tue, 7 Mar 2006 11:22:43 GMT 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 Subject: RE: [Dcpel] some comments on draft-vandenberghe-dcpel-basics-00.txt Date: Tue, 7 Mar 2006 11:22:43 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dcpel] some comments on draft-vandenberghe-dcpel-basics-00.txt Thread-Index: AcY5lIWLIaFO2l7PTquyTagNGvxExgIPgc/Q From: "Hancock, Robert" To: "Kathleen Nichols" , X-MailScanner-rsys001x: Found to be clean X-MailScanner-rsys001x-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 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: , Errors-To: dcpel-bounces@ietf.org hi kathie, > Robert, >=20 > First, I apololgize for the "minor comprehensibility nits" but > 1) we wanted to get something out for comment and 2) we figured > that things might change a lot after discussion, so a lengthy > editing pass seemed okay to skip. fair enough. >=20 > This is a fairly short reply. I can send more later or let others > reply in detail. >=20 > > 1. What is a "traffic aggregate"? > >=20 >=20 > I thought that we said we were using the 3086 definition of taffic > aggregate. Anyway, that is: >=20 >=20 > Traffic Aggregate: a collection of packets with a codepoint that > maps to the same PHB, usually in a DS domain or some subset of a DS > domain. A traffic aggregate marked for the foo PHB is referred to > as the "foo traffic aggregate" or "foo aggregate" interchangeably. > This generalizes the concept of Behavior Aggregate from a link to a > network. True, and that definition is included in the 'basics' draft directly. My question was not so much 'what does the definition mean?' but 'is the definition too broad to be a good basis for scoping the=20 problem space?'. Defining a specific aggregate for a link is very simple; defining a specific aggregate for a network could be nearly arbitrarily=20 complex. Is all of that complexity envisaged to be in scope, or is that something still to be worked out? >=20 > > 2. Interior vs. edge vs. exterior >=20 > So, again, we are following the diffserv architecture. See, for > example section 2.1.1 of RFC2475. "edge", "boundary" and "border" > are somewhat interchangeable, but normally "border" is used for > the edge of an AS where boundary or edge might be at the edge of > a DS domain that is not administratively separate from the adjoining > one. We should probably avoid "exterior". The same > distinction between interior and edge/boundary/border shows up in > RFC3086. That seems reasonable; but again, why does the basics draft need to assert that the DCP should do some things only at the edge/whatever only and some things domain wide? Isn't that part of the solution space? >=20 > > 3. Role of PDBs and service descriptions > >=20 > ...PDBs apparently define the treatment that a set of packets > > will receive from a DS domain; that sounds like a service to (certainly > > in the way that IntServ talks about service elements). Elsewhere the > > document indicates that multiple services might use (implement? > > provide?) the same PDB, but with different policy constraints, which > > implies that 'service' means something more like an SLS (e.g. in the > > Tequila sense). It might be nice to have a definition of 'service' and > > some examples. >=20 > So, I think you have it correct. RFC3086 says in the abstract: >=20 > The next step is to formulate examples of how forwarding path > components (PHBs, classifiers, and traffic conditioners) can be used > to compose traffic aggregates whose packets experience specific > forwarding characteristics as they transit a differentiated services > domain. The WG has decided to use the term per-domain behavior, or > PDB, to describe the behavior experienced by a particular set of > packets as they cross a DS domain. A PDB is characterized by > specific metrics that quantify the treatment a set of packets with a > particular DSCP (or set of DSCPs) will receive as it crosses a DS > domain. A PDB specifies a forwarding path treatment for a traffic > aggregate and, due to the role that particular choices of edge and > PHB configuration play in its resulting attributes, it is where the > forwarding path and the control plane interact. The measurable > parameters of a PDB should be suitable for use in Service Level > Specifications at the network edge. >=20 > And says later that a PDB might be specified in an SLA (e.g. if it is a > "well-known PDB") or perhaps just the measurable parmeters of the PDB. I > believe part of the work of dcpel can be to work out what are the right > ways to exchange this information. But the point is well-taken that all > of this will need to be made clearer. OK, my fog may be starting to lift slightly. My underlying question is whether there is an expectation to use PDBs to describe resources in=20 the interdomain communication. AFAIK neither Y.1541 (caveat: I have only looked at the 2002 version) nor the NSIS Q-spec use PDBs themselves, but they might very well use the measurable parameters of PDBs. There could be a concern about extending the vocabulary for describing interdomain QoS any further; some people think that it is already too sophisticated ;-) But I guess this could come out of subsequent work. cheers, robert h. _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel From dcpel-bounces@ietf.org Tue Mar 07 10:20:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGdyp-0006YF-9I; Tue, 07 Mar 2006 10:20:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGdyn-0006Xt-TM for dcpel@ietf.org; Tue, 07 Mar 2006 10:20:05 -0500 Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGdyn-0006HV-24 for dcpel@ietf.org; Tue, 07 Mar 2006 10:20:05 -0500 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id k27FJcoW029291 for ; Tue, 7 Mar 2006 15:19:38 GMT 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: Tue, 7 Mar 2006 15:19:38 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: some comments on draft-mendes-dcpel-requirements-00.txt Thread-Index: AcYYdS3TIGK+4Po8RAWdixxlqesEFAg0NmTAAiyauuA= From: "Hancock, Robert" To: X-MailScanner-rsys001x: Found to be clean X-MailScanner-rsys001x-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Subject: [Dcpel] some comments on draft-mendes-dcpel-requirements-00.txt 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: , Errors-To: dcpel-bounces@ietf.org hi, i've also been reading draft-mendes-dcpel-requirements-00, and have some questions on that draft. (interestingly, not as many as on the basics draft. maybe that's because everything i don't understand is already covered in the basics draft.) *) are the inter-domain aspects of the solution required to be diffserv-independent? some parts of the requirements suggest yes (last-but-one on page 5) whereas others seem more diffserv specific (3rd one on page 7). *) (1st & 3rd in section 5.3): the claims for the benefits of=20 XML seem slightly out of place in a requirements proposal. *) there seem to be several different levels of 'state' information governing an inter-domain relationship. we have policies,=20 agreements (is this a synonym for SLA?), SLSs (some people use this as a term for a part of an SLA, is that the implication here?), and at the end of 5.3 there is the concept of activating an agreement (so as well as just existing or not, an agreement can have some kind of dynamic status). is this hierarchy fixed or can there be arbitrary levels of it? is all of it in scope for the DCPEL inter-domain definition, or are (for example) the policies considered a purely out-of-band/upper-layer issue? *) (1st & 2nd in section 5.4): the assumption of a fixed/well-known address (even if it's for a virtual entity) seems over restrictive in a requirements document. It's a possible solution, but not the only one. (If it's a must, then it's reasonable to ask by what=20 mechanism the address becomes well known in the first place.) cheers, robert h. > hi, >=20 > i've been reading draft-vandenberghe-dcpel-basics-00.txt and > draft-mendes-dcpel-requirements-00. i have some comments/questions on > the first. leaving aside minor comprehensibility nits, my=20 > main questions > are about trying to understand the scope in a bit more concrete terms. >=20 > this email got rather long; sorry for that. >=20 > r. >=20 > 1. What is a "traffic aggregate"? >=20 > This term is given in section 2, as the generalisation of a behaviour > aggregate (which applies to a link) to a network. What I don't > understand is the nature of the generalisation - does a traffic > aggregate apply to a sequence of links along a path, or to all traffic > within a network? (Both possibilities are listed in the previous > section.)=20 >=20 > These would seem to me to be rather different concepts,=20 > especially once > routing interactions are taken into account. The first is can=20 > be defined > quite precisely by giving a specific (ingress, egress); for=20 > the second, > is one expecting ({set of ingresses}, {set of egresses}), or {set of > edge nodes}, or just to say 'all traffic passing a given AS'? Does a > traffic aggregate have a direction? Would a service description > assume/define particular traffic patterns within the=20 > aggregate, or would > arbitrary distributions be expected? If there is a change in external > connectivity (e.g. a BGP route switches from one egress to another) is > the definition of the aggregate supposed to change, or are=20 > you supposed > to renegotiate for a new aggregate? >=20 > [The reason I ask is that there seems to be a big spectrum of=20 > complexity > here in the range of possible sophistication of aggregate definition. > And I'm not sure where the scope boundary is supposed to be.] >=20 > Section 4.1 includes the phrase "There must be a non-path-specific > option." but I can't tell what this means - does it refer to=20 > signalling > mechanisms or to the definition of traffic aggregates themselves? >=20 > 2. Interior vs. edge vs. exterior >=20 > The document seems to distinguish three different aspects of=20 > a DiffServ > network, but I'm not sure how they relate and/or overlap. > - There is a fairly consistent message that the 'internals' of the > network should not be exposed externally > - There is a discussion of developing or being consistent with a > universal inter-domain interface (which would presumably be=20 > independant > of these 'internals') >=20 > On the other hand, there are several places where it's asserted that > certain sorts of operations should affect only edge and not interior > nodes. This seems to be something that does more than just scope the > problem but describes some fundamental aspect of the solution; does it > mean that the edge nodes and interior nodes are going to be > distinguished in some architectural sense? For example, does this > distinction between edge and interior count as an aspect of the > 'internals' which should not be exposed? >=20 > 3. Role of PDBs and service descriptions >=20 > [This may all be clear to people with a longer DS background than me.] > I got continually confused by the relationship between PDBs and > services. PDBs apparently define the treatment that a set of packets > will receive from a DS domain; that sounds like a service to=20 > (certainly > in the way that IntServ talks about service elements). Elsewhere the > document indicates that multiple services might use (implement? > provide?) the same PDB, but with different policy constraints, which > implies that 'service' means something more like an SLS (e.g. in the > Tequila sense). It might be nice to have a definition of 'service' and > some examples. >=20 > A particular way of posing the question: would PDBs be visible in the > inter-domain interface of a DS domain (e.g. as part of a service > description)? If so, how would the use of PDBs to describe packet > treatment relate to other syntax for describing packet treatment (e.g. > ITU based)? Or are PDBs purely 'internal' language for a DCP to use in > intra-domain communication between the various DCP elements? For > example, the requirements draft indicates that the same inter-domain > control interface should be applicable to non-DiffServ domains, which > presumably wouldn't use PDBs at all. >=20 > 4. SIP interactions >=20 > I was confused by two aspects of the interaction with SIP. >=20 > - SIP is mentioned as a possible instantiation of the inter-domain > control mechanism, but I don't see how it would be relevant.=20 > If the idea > is to piggyback the DifS signalling for a given flow on the SIP > exchanges for a flow, this would imply that there is a constraint that > the SIP signalling path and traffic path are the same (at the domain > level), which does not need to be true. If the idea is to have totally > different SIP interactions, I'm not clear how much of the SIP protocol > machinery is relevant to the DCP problem space. >=20 > - So far as I can tell, assuming that application interactions are > handled by 3312 (SDP preconditions) is quite valid, but also=20 > means that > there is no further relevance to the DCP work. As far as I understand, > 3312 allows application endpoints to agree with each other which > endpoint is taking responsibility for resource configuration, but the > logic of the detailed interactions between the resource configuration > and SIP/SDP signalling is internal to those endpoints. In other words, > the fact that 3312 is being used should be entirely transparent to the > resource configuration mechansisms between the endpoints. (But 4.2 > implies there is some specific work to be done here.) >=20 > 5. Is development of signalling protocols in scope or not? >=20 > 4.1.2 says that "...definition of an interdomain QoS=20 > signaling protocol > is considered as future work for the proposed DCPEL WG", but 4.2 only > lists interworking with existing protocols. This seems contradictory. >=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 Thu Mar 09 00:49:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHE1b-0006wu-2m; Thu, 09 Mar 2006 00:49:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHE1Z-0006wp-I8 for dcpel@ietf.org; Thu, 09 Mar 2006 00:49:21 -0500 Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHE1Z-00046g-3a for dcpel@ietf.org; Thu, 09 Mar 2006 00:49:21 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k295nJb3023987 for ; Thu, 9 Mar 2006 07:49:20 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Mar 2006 07:49:16 +0200 Received: from dadhcp-172019068136.americas.nokia.com ([172.18.141.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 9 Mar 2006 07:49:16 +0200 Received: from dadhcp-172019068136.americas.nokia.com (localhost.localdomain [127.0.0.1]) by dadhcp-172019068136.americas.nokia.com (8.12.8/8.12.8) with ESMTP id k295nEfe029580 for ; Wed, 8 Mar 2006 21:49:14 -0800 Received: (from kessens@localhost) by dadhcp-172019068136.americas.nokia.com (8.12.8/8.12.8/Submit) id k295nEcN029578 for dcpel@ietf.org; Wed, 8 Mar 2006 21:49:14 -0800 Date: Wed, 8 Mar 2006 21:49:14 -0800 From: David Kessens To: dcpel@ietf.org Message-ID: <20060309054914.GA29529@nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-OriginalArrivalTime: 09 Mar 2006 05:49:16.0777 (UTC) FILETIME=[33CCE590:01C6433D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Subject: [Dcpel] FWD: [Re: proposed charter] 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: , Errors-To: dcpel-bounces@ietf.org Kathie asked me whether I would be willing to share the following mail with the group on my current thinking regarding a bof for dcepl. I obviously have no problem with that so please see below for my mail to Kathie regarding this topic. I, and the other ADs CC'ed on this mail, are interested in your comments. I hope this helps, David Kessens --- ----- Forwarded message from David Kessens ----- Date: Mon, 6 Mar 2006 20:58:32 -0800 From: David Kessens To: Kathleen Nichols Subject: Re: proposed charter Kathie, On Wed, Feb 22, 2006 at 10:51:34AM -0800, Kathleen Nichols wrote: > > Attached is a draft charter. Scott and Paulo haven't had a > chance to weigh in on it, so I might get some good input > there. I would hope to have better milestones after an > organizational meeting or BoF. I am sorry for the delay in my response. We normally spend some time to do an internal review with the IAB and IESG and I was waiting for Allison who promised comments. I am sympathic to the goals of this proposed work and I have received various comments from the IAB stating so. However, I also received comments that this work could be conflicting with existing IETF work in the NSIS and TSV working group. While the proposed charter doesn't necessarily would require protocol work, the drafts that I read would more or less require this. As you know, the Ops part of the Ops&Mgmt area usually doesn't do protocol work and limits itself to issues that are relevant to the operations of the Internet. In addition, to make sure that things are relevant for operators, we normally want to have feedback, support and involvement from operators to avoid situations where vendors build all kind of complex solutions for problems that operators don't have. So far, I have seen some support from academia, research efforts within larger corporations and some vendors, but I have seen little evidence that this group is going to solve a problem that operators want to be solved. As I already mentioned in an earlier mail, I am really somewhat surprised that I haven't seen any operator on the list commenting that we need to start this work as I did expect that myself. Considering these issues, I think that it probably is not in your best interest to pursue a bof for this IETF. We will first need a much clearer answer on what problem is going to be solved *for operators*, get real support from operators behind this effort and after that we need to figure out whether that solution will involve protocol work or not. You can probably convince me to hold a bof anyways but considering the above stumbling blocks, I would advise you not to do so. David Kessens --- _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel From dcpel-bounces@ietf.org Thu Mar 09 00:56:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHE8p-0006E2-UH; Thu, 09 Mar 2006 00:56:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHE8o-00069X-NR for dcpel@ietf.org; Thu, 09 Mar 2006 00:56:50 -0500 Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHE8o-0004SN-8v for dcpel@ietf.org; Thu, 09 Mar 2006 00:56:50 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k295ufHK011603; Thu, 9 Mar 2006 07:56:44 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Mar 2006 07:56:43 +0200 Received: from dadhcp-172019068136.americas.nokia.com ([172.18.141.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 9 Mar 2006 07:56:42 +0200 Received: from dadhcp-172019068136.americas.nokia.com (localhost.localdomain [127.0.0.1]) by dadhcp-172019068136.americas.nokia.com (8.12.8/8.12.8) with ESMTP id k295uffe029663; Wed, 8 Mar 2006 21:56:41 -0800 Received: (from kessens@localhost) by dadhcp-172019068136.americas.nokia.com (8.12.8/8.12.8/Submit) id k295ubPK029661; Wed, 8 Mar 2006 21:56:37 -0800 Date: Wed, 8 Mar 2006 21:56:37 -0800 From: David Kessens To: dcpel@ietf.org Message-ID: <20060309055637.GF29193@nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-OriginalArrivalTime: 09 Mar 2006 05:56:43.0349 (UTC) FILETIME=[3DFA6050:01C6433E] X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: Bert Wijnen , Magnus Westerlund Subject: [Dcpel] FWD: [Re: proposed charter] 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: , Errors-To: dcpel-bounces@ietf.org [ I did not CC all (in the future) involved ADs in my previous mail ] Kathie asked me whether I would be willing to share the following mail with the group on my current thinking regarding a bof for dcepl. I obviously have no problem with that so please see below for my mail to Kathie regarding this topic. I, and the other ADs CC'ed on this mail, are interested in your comments. I hope this helps, David Kessens --- ----- Forwarded message from David Kessens ----- Date: Mon, 6 Mar 2006 20:58:32 -0800 From: David Kessens To: Kathleen Nichols Subject: Re: proposed charter Kathie, On Wed, Feb 22, 2006 at 10:51:34AM -0800, Kathleen Nichols wrote: > > Attached is a draft charter. Scott and Paulo haven't had a > chance to weigh in on it, so I might get some good input > there. I would hope to have better milestones after an > organizational meeting or BoF. I am sorry for the delay in my response. We normally spend some time to do an internal review with the IAB and IESG and I was waiting for Allison who promised comments. I am sympathic to the goals of this proposed work and I have received various comments from the IAB stating so. However, I also received comments that this work could be conflicting with existing IETF work in the NSIS and TSV working group. While the proposed charter doesn't necessarily would require protocol work, the drafts that I read would more or less require this. As you know, the Ops part of the Ops&Mgmt area usually doesn't do protocol work and limits itself to issues that are relevant to the operations of the Internet. In addition, to make sure that things are relevant for operators, we normally want to have feedback, support and involvement from operators to avoid situations where vendors build all kind of complex solutions for problems that operators don't have. So far, I have seen some support from academia, research efforts within larger corporations and some vendors, but I have seen little evidence that this group is going to solve a problem that operators want to be solved. As I already mentioned in an earlier mail, I am really somewhat surprised that I haven't seen any operator on the list commenting that we need to start this work as I did expect that myself. Considering these issues, I think that it probably is not in your best interest to pursue a bof for this IETF. We will first need a much clearer answer on what problem is going to be solved *for operators*, get real support from operators behind this effort and after that we need to figure out whether that solution will involve protocol work or not. You can probably convince me to hold a bof anyways but considering the above stumbling blocks, I would advise you not to do so. David Kessens --- _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel From dcpel-bounces@ietf.org Thu Mar 09 03:32:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHGZf-00025k-9C; Thu, 09 Mar 2006 03:32:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHGZe-00025O-RX for dcpel@ietf.org; Thu, 09 Mar 2006 03:32:42 -0500 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHGZb-0000u1-Bh for dcpel@ietf.org; Thu, 09 Mar 2006 03:32:42 -0500 Received: from ftrdmel10.rd.francetelecom.fr ([10.193.117.156]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Mar 2006 09:32:36 +0100 Received: from [10.193.75.118] ([10.193.75.118]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Mar 2006 09:32:35 +0100 Message-ID: <440FE824.407@rd.francetelecom.com> Date: Thu, 09 Mar 2006 09:32:36 +0100 From: Olivier Dugeon Organization: France Telecom R&D User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: David Kessens Subject: Re: [Dcpel] FWD: [Re: proposed charter] References: <20060309054914.GA29529@nokia.com> In-Reply-To: <20060309054914.GA29529@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 09 Mar 2006 08:32:35.0993 (UTC) FILETIME=[04969890:01C64354] X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 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: , Errors-To: dcpel-bounces@ietf.org Hello David, Here it is some comments from an operator (ok R&D part only) !!! David Kessens a =E9crit : > Kathie asked me whether I would be willing to share the following mail > with the group on my current thinking regarding a bof for dcepl. > > I obviously have no problem with that so please see below for my mail > to Kathie regarding this topic. I, and the other ADs CC'ed on this > mail, are interested in your comments. > > I hope this helps, > > David Kessens > --- > > ----- Forwarded message from David Kessens --= --- > > Date: Mon, 6 Mar 2006 20:58:32 -0800 > From: David Kessens > To: Kathleen Nichols > Subject: Re: proposed charter > > > Kathie, > > On Wed, Feb 22, 2006 at 10:51:34AM -0800, Kathleen Nichols wrote: > =20 >> Attached is a draft charter. Scott and Paulo haven't had a >> chance to weigh in on it, so I might get some good input >> there. I would hope to have better milestones after an >> organizational meeting or BoF. >> =20 > > I am sorry for the delay in my response. We normally spend some time > to do an internal review with the IAB and IESG and I was waiting for > Allison who promised comments. > > I am sympathic to the goals of this proposed work and I have received > various comments from the IAB stating so. > > However, I also received comments that this work could be conflicting > with existing IETF work in the NSIS and TSV working group. > > While the proposed charter doesn't necessarily would require protocol > work, the drafts that I read would more or less require this. As you > know, the Ops part of the Ops&Mgmt area usually doesn't do protocol > work and limits itself to issues that are relevant to the operations > =20 I'm agree with your remarks. But, IMHO, the DCPEL WG have to deal with=20 protocol: Not produce new protocol, but adapt or suggest modifications=20 to relevant WG. For exemple, DCPA inter-domain communication could use=20 NSIS. But, since NSIS have not yet design for this, it certainly need=20 some modifications or, at least, to setup a new NSLP stack liek QoS-NSLP = (thanks to the 2 layers signalling of NSIS which could facilitate the=20 work). Another example concern the SLS interface aka the interface=20 between service and DCPEL. Again, some stuff are usable like SIP, XML,=20 =2E.. but need some adaptation to carry properly the SLS from the service= =20 to the DCPEL. > of the Internet. In addition, to make sure that things are relevant > for operators, we normally want to have feedback, support and > involvement from operators to avoid situations where vendors build all > kind of complex solutions for problems that operators don't have. > > So far, I have seen some support from academia, research efforts > within larger corporations and some vendors, but I have seen little > evidence that this group is going to solve a problem that operators > want to be solved. As I already mentioned in an earlier mail, I am > really somewhat surprised that I haven't seen any operator on the list > commenting that we need to start this work as I did expect that myself.= > =20 Sorry to contradict you, but, if you look carefully at the mailing list, = you could see that I support DCPEL initiative from the beginning=20 (10/14/2005). During the last IETF meeting, FTR&D support this work=20 during the OPS AREA meeting. In the same time, through the European IST=20 projet EuQoS, I request support from other operator like TID (Telefonica = I+D). Generally speaking, in Europe, most of the operator are search for = such functionalities. Look to the work done in other fora such as=20 ETSI/TISPAN, ITU-NGN-FG and now Q4/13 or more recently to the DSL Forum. = In fact, IETF is the only place where QoS control, and in particular=20 resource control, are not study in the scope proposed by the DCEPL=20 initiative. > Considering these issues, I think that it probably is not in your best > interest to pursue a bof for this IETF. > > We will first need a much clearer answer on what problem is going to > be solved *for operators*, get real support from operators behind this > effort and after that we need to figure out whether that solution will > involve protocol work or not. > =20 I could discuss this directly by phone as I'm not agree with you. But,=20 operator need and want a global solution to setup and exchange QoS. If=20 you just look at the VoIP service, inter-domain correspond to the=20 "international" part of the traditional PSTN. For the moment, only study = are conduct to the access network. But, it is not sufficient. For the=20 moment, people think that over-provisioning will solve this issue. This=20 is true for the bandwidth, but not for the other QoS parameters such as=20 jitter, delay, loss ... However, VoIP services are vey sensible to the=20 jitter and the delay. Without inter-domain and global QoS solution, it=20 could not be possible to deploy a global VoIP QoS solution. In the same=20 way, all multi-media service (IP TV, VoD, ...) need also QoS control.=20 Adopting a signaling like NSIS is certainly a great solution, but which=20 will be deploy not before 5 or 10 years due to the time scale operator=20 renew their transfer plane equipments. At the opposite, a control plane=20 such as DCPEL propose, could be deploy very quickly without changing=20 their transfer plane. Today, operator are in a such situation that there is some industrial=20 solution on the market, but no standard to compare them or inter-oper=20 without development or major adaptation. Finally, ITU and ETSI will finalize first standard of the RACF function, = but too much dedicated to conversational service. IMHO, it is really a=20 mess that IETF will not conduct study on diffserv control plane. > You can probably convince me to hold a bof anyways but considering > the above stumbling blocks, I would advise you not to do so. > =20 I'm agree that the charter need more clarification and scope need more=20 focus. But, this is a very complex subject. All peoples with whom I=20 discussed about this, have a different opinion on the technical=20 solution, but all are agree to said that we need a solution. Best regards, Olivier Dugeon > David Kessens > --- > > _______________________________________________ > Dcpel mailing list > Dcpel@ietf.org > https://www1.ietf.org/mailman/listinfo/dcpel > > =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 Thu Mar 09 07:43:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHKUG-0001xr-Ss; Thu, 09 Mar 2006 07:43:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHKUF-0001xm-53 for dcpel@ietf.org; Thu, 09 Mar 2006 07:43:23 -0500 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHKUE-0000Lp-C9 for dcpel@ietf.org; Thu, 09 Mar 2006 07:43:23 -0500 Received: from mail2.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k29ChKca030766; Thu, 9 Mar 2006 13:43:20 +0100 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k29ChKvm001272; Thu, 9 Mar 2006 13:43:20 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Mar 2006 13:42:44 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [Dcpel] FWD: [Re: proposed charter] Date: Thu, 9 Mar 2006 13:42:30 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dcpel] FWD: [Re: proposed charter] thread-index: AcZDVB26FK6K54SjRyqensRHluIyqQAH0UTQ From: "Tschofenig, Hannes" To: "Olivier Dugeon" , "David Kessens" X-OriginalArrivalTime: 09 Mar 2006 12:42:44.0854 (UTC) FILETIME=[F6910960:01C64376] X-Spam-Score: 0.0 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 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: , Errors-To: dcpel-bounces@ietf.org Hi Olivier,=20 Hi David,=20 I agree with David that there is essentially a lot of protocol work = (hopefully "only" extensions) that seems to be envisioned by DCPEL. A = few weeks ago Georgios has sent a mail asking for the relationship = between the IETF work and other QoS work that is currently being done = outside the IETF. There are many proposals being made today that need to = be considered. These organizations are, for various reasons, really = crazy about QoS and QoS signaling. As I noted at the last IETF meeting I = think that the best place for these discussions is the Transport Area = where this type of protocol discussions already happened in the past.=20 The IETF NSIS work has discussed various aspects of path-decoupled = signaling approaches in the past and there are still proposals floating = around. You might be interesting to see that there will be a discussion = about this subject at the next IETF meeting. See = http://www1.ietf.org/mail-archive/web/nsis/current/msg06007.html It = might be interesting for you to attend the NSIS WG session to share your = thoughts with other QoS minded people. Furthermore, a number of us have = been in contact with the ITU-T (and the ITU-T liaison person from the = ITU-T side, Hui-Lan Lu, in particular), including John Loughney and = myself, to discuss how their requirements can be brought to the = IETF/NSIS working group to have a fruitful discussion.=20 Ciao Hannes > Hello David, >=20 > Here it is some comments from an operator (ok R&D part only) !!! >=20 > David Kessens a =E9crit : > > Kathie asked me whether I would be willing to share the=20 > following mail > > with the group on my current thinking regarding a bof for dcepl. > > > > I obviously have no problem with that so please see below=20 > for my mail > > to Kathie regarding this topic. I, and the other ADs CC'ed on this > > mail, are interested in your comments. > > > > I hope this helps, > > > > David Kessens > > --- > > > > ----- Forwarded message from David Kessens=20 > ----- > > > > Date: Mon, 6 Mar 2006 20:58:32 -0800 > > From: David Kessens > > To: Kathleen Nichols > > Subject: Re: proposed charter > > > > > > Kathie, > > > > On Wed, Feb 22, 2006 at 10:51:34AM -0800, Kathleen Nichols wrote: > > =20 > >> Attached is a draft charter. Scott and Paulo haven't had a > >> chance to weigh in on it, so I might get some good input > >> there. I would hope to have better milestones after an > >> organizational meeting or BoF. > >> =20 > > > > I am sorry for the delay in my response. We normally spend some time > > to do an internal review with the IAB and IESG and I was waiting for > > Allison who promised comments. > > > > I am sympathic to the goals of this proposed work and I=20 > have received > > various comments from the IAB stating so. > > > > However, I also received comments that this work could be=20 > conflicting > > with existing IETF work in the NSIS and TSV working group. > > > > While the proposed charter doesn't necessarily would=20 > require protocol > > work, the drafts that I read would more or less require this. As you > > know, the Ops part of the Ops&Mgmt area usually doesn't do protocol > > work and limits itself to issues that are relevant to the operations > > =20 > I'm agree with your remarks. But, IMHO, the DCPEL WG have to=20 > deal with=20 > protocol: Not produce new protocol, but adapt or suggest=20 > modifications=20 > to relevant WG. For exemple, DCPA inter-domain communication=20 > could use=20 > NSIS. But, since NSIS have not yet design for this, it certainly need=20 > some modifications or, at least, to setup a new NSLP stack=20 > liek QoS-NSLP=20 > (thanks to the 2 layers signalling of NSIS which could facilitate the=20 > work). Another example concern the SLS interface aka the interface=20 > between service and DCPEL. Again, some stuff are usable like=20 > SIP, XML,=20 > ... but need some adaptation to carry properly the SLS from=20 > the service=20 > to the DCPEL. > > of the Internet. In addition, to make sure that things are relevant > > for operators, we normally want to have feedback, support and > > involvement from operators to avoid situations where=20 > vendors build all > > kind of complex solutions for problems that operators don't have. > > > > So far, I have seen some support from academia, research efforts > > within larger corporations and some vendors, but I have seen little > > evidence that this group is going to solve a problem that operators > > want to be solved. As I already mentioned in an earlier mail, I am > > really somewhat surprised that I haven't seen any operator=20 > on the list > > commenting that we need to start this work as I did expect=20 > that myself. > > =20 > Sorry to contradict you, but, if you look carefully at the=20 > mailing list,=20 > you could see that I support DCPEL initiative from the beginning=20 > (10/14/2005). During the last IETF meeting, FTR&D support this work=20 > during the OPS AREA meeting. In the same time, through the=20 > European IST=20 > projet EuQoS, I request support from other operator like TID=20 > (Telefonica=20 > I+D). Generally speaking, in Europe, most of the operator are=20 > search for=20 > such functionalities. Look to the work done in other fora such as=20 > ETSI/TISPAN, ITU-NGN-FG and now Q4/13 or more recently to the=20 > DSL Forum.=20 > In fact, IETF is the only place where QoS control, and in particular=20 > resource control, are not study in the scope proposed by the DCEPL=20 > initiative. > > Considering these issues, I think that it probably is not=20 > in your best > > interest to pursue a bof for this IETF. > > > > We will first need a much clearer answer on what problem is going to > > be solved *for operators*, get real support from operators=20 > behind this > > effort and after that we need to figure out whether that=20 > solution will > > involve protocol work or not. > > =20 > I could discuss this directly by phone as I'm not agree with=20 > you. But,=20 > operator need and want a global solution to setup and=20 > exchange QoS. If=20 > you just look at the VoIP service, inter-domain correspond to the=20 > "international" part of the traditional PSTN. For the moment,=20 > only study=20 > are conduct to the access network. But, it is not sufficient. For the=20 > moment, people think that over-provisioning will solve this=20 > issue. This=20 > is true for the bandwidth, but not for the other QoS=20 > parameters such as=20 > jitter, delay, loss ... However, VoIP services are vey=20 > sensible to the=20 > jitter and the delay. Without inter-domain and global QoS=20 > solution, it=20 > could not be possible to deploy a global VoIP QoS solution.=20 > In the same=20 > way, all multi-media service (IP TV, VoD, ...) need also QoS control.=20 > Adopting a signaling like NSIS is certainly a great solution,=20 > but which=20 > will be deploy not before 5 or 10 years due to the time scale=20 > operator=20 > renew their transfer plane equipments. At the opposite, a=20 > control plane=20 > such as DCPEL propose, could be deploy very quickly without changing=20 > their transfer plane. >=20 > Today, operator are in a such situation that there is some industrial=20 > solution on the market, but no standard to compare them or inter-oper=20 > without development or major adaptation. >=20 > Finally, ITU and ETSI will finalize first standard of the=20 > RACF function,=20 > but too much dedicated to conversational service. IMHO, it is=20 > really a=20 > mess that IETF will not conduct study on diffserv control plane. > > You can probably convince me to hold a bof anyways but considering > > the above stumbling blocks, I would advise you not to do so. > > =20 > I'm agree that the charter need more clarification and scope=20 > need more=20 > focus. But, this is a very complex subject. All peoples with whom I=20 > discussed about this, have a different opinion on the technical=20 > solution, but all are agree to said that we need a solution. >=20 > Best regards, >=20 > Olivier Dugeon > > David Kessens > > --- > > > > _______________________________________________ > > Dcpel mailing list > > Dcpel@ietf.org > > https://www1.ietf.org/mailman/listinfo/dcpel > > > > =20 >=20 > --=20 > Project Manager for Network architecture and switching Division > & FT/DR&D/CORE/M2I |=20 > 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 >=20 >=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 Thu Mar 09 10:56:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHNVC-0003lT-Nw; Thu, 09 Mar 2006 10:56:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHNVB-0003lO-Mx for dcpel@ietf.org; Thu, 09 Mar 2006 10:56:33 -0500 Received: from outbound.mailhop.org ([63.208.196.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHNVA-0006MA-Gr for dcpel@ietf.org; Thu, 09 Mar 2006 10:56:33 -0500 Received: from 72-254-36-225.client.stsn.net ([72.254.36.225] helo=[192.168.1.102]) by outbound.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.51) id 1FHNVA-000GMd-0q; Thu, 09 Mar 2006 10:56:32 -0500 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 72.254.36.225 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: <4410502C.3070002@pollere.com> Date: Thu, 09 Mar 2006 07:56:28 -0800 From: Kathleen Nichols User-Agent: Thunderbird 1.4.1 (Macintosh/20051006) MIME-Version: 1.0 To: "Tschofenig, Hannes" , dcpel@ietf.org Subject: Re: AW: [Dcpel] FWD: [Re: proposed charter] References: In-Reply-To: X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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: , Errors-To: dcpel-bounces@ietf.org So, I really must reply, in brief, to Hannes's email. It seems to be all about signaling. In my opinion, this has been a big problem in the QoS area in general and particularly at the IETF. That is, spending time talking about what information is going to be sent around and in what sort of containers rather than how to manage and control IP differentiated services. If the right information is being sent, then a useful control and management structure should be able to use it. But it seems like we need to have an infrastructure that is capable of realizing services on an IP network before we worry overly much about what is being sent. Particularly since signaling is not required for all services. Kathie _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel From dcpel-bounces@ietf.org Thu Mar 09 12:07:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHOc9-00076w-BQ; Thu, 09 Mar 2006 12:07:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHOc8-00076m-KD for dcpel@ietf.org; Thu, 09 Mar 2006 12:07:48 -0500 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHOc6-0000H8-Vq for dcpel@ietf.org; Thu, 09 Mar 2006 12:07:48 -0500 Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k29H7kN3021520; Thu, 9 Mar 2006 18:07:46 +0100 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 k29H7jgf004169; Thu, 9 Mar 2006 18:07:46 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Mar 2006 18:07:29 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: AW: [Dcpel] FWD: [Re: proposed charter] Date: Thu, 9 Mar 2006 18:07:23 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [Dcpel] FWD: [Re: proposed charter] thread-index: AcZDkg+n0l5MyG3xQxKvaB1/VBKD0QAAo2BQ From: "Tschofenig, Hannes" To: "Kathleen Nichols" , X-OriginalArrivalTime: 09 Mar 2006 17:07:29.0540 (UTC) FILETIME=[F293C440:01C6439B] X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a 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: , Errors-To: dcpel-bounces@ietf.org Hi Kathie,=20 your mail points to an aspect that a number of us have never really = understood.=20 I think we have a terminology problem here.=20 Just as an example, let us take a look at Figure 1 of = : +-DCP-----------------------------+ | | | +---------------+ +-----+ | | |Domain Policies| | AAA | | | +--------||-----+ +-----+ | | || || | | +-----||----------|+ | QoS Announce(*) <=3D=3D=3D=3D=3D| = |=3D=3D=3D=3D=3D=3D=3D=3D=3D> QoS Announce (*) QoS Request =3D=3D=3D=3D=3D=3D=3D=3D>| = |=3D=3D=3D=3D=3D=3D=3D=3D=3D> QoS Request QoS Response <=3D=3D=3D=3D=3D=3D=3D=3D| DCP = |<=3D=3D=3D=3D=3D=3D=3D=3D=3D QoS Response QoS Query(*) =3D=3D=3D=3D=3D=3D=3D=3D>| = |=3D=3D=3D=3D=3D=3D=3D=3D=3D> QoS Query(*) QoS Status <=3D=3D=3D=3D=3D=3D=3D=3D| = |<=3D=3D=3D=3D=3D=3D=3D=3D=3D QoS Status | +----||------------+ | | || || | | +-------||------+ +-||--------+ | | | Enforcement | | Monitoring| | | +---------------+ +-----------+ | | | +---------------------------------+ A few protocol interactions that come to my mind when I see this figure = are:=20 a) How does the AAA infrastructure interact with the DCP node?=20 b) Isn't a protocol required in order to provide the interaction between = different DCP nodes? (e.g., for QoS Announce, Request, Response, Query, = Status)? c) How does the DCP node communicate with the enforcement (points)? d) How does the interaction between DCP and the monitoring entities = looks like?=20 e) Where do the Domain Policies come from?=20 For (a) you mention "access to the AAA information". This might be = RADIUS or Diameter since this stuff is used today.=20 For (b) you mention "external protocol/mechanism sends a QoS Query, .... = to the DCP"=20 For (c) you mention COPS, Netconf, SNMP=20 For (d) you mention "needs access to a wide range of information about = the operational conditions of its network." For (e) you mention "A DCP must either contain these or have access to = them, perhaps a combination."=20 The draft also talks about other protocols like SIP and NSIS. Having briefly looked at these aspects of your draft please explain what = you mean by: * "... infrastructure that is capable of realizing services on an IP = network before we worry overly much about what is being sent." * "Particularly since signaling is not required for all services." (Note that the term 'service' is not really well defined in the IETF nor = in any other organization.) * "It seems > to be all about signaling. In my opinion, this has been a big > problem in the QoS area in general and particularly at the IETF. > That is, spending time talking about what information is going to > be sent around and in what sort of containers rather than how to > manage and control IP differentiated services." If you do not have these protocols and if you don't worry about the = content that is sent around (with the associated semantic) then it might = be a 'little bit difficult' to dynamically manage and control QoS. What term do you use for this dynamic information exchange?=20 Ciao Hannes > -----Urspr=FCngliche Nachricht----- > Von: Kathleen Nichols [mailto:nichols@pollere.com]=20 > Gesendet: Donnerstag, 9. M=E4rz 2006 16:56 > An: Tschofenig, Hannes; dcpel@ietf.org > Betreff: Re: AW: [Dcpel] FWD: [Re: proposed charter] >=20 >=20 > So, I really must reply, in brief, to Hannes's email. It seems > to be all about signaling. In my opinion, this has been a big > problem in the QoS area in general and particularly at the IETF. > That is, spending time talking about what information is going to > be sent around and in what sort of containers rather than how to > manage and control IP differentiated services. If the right > information is being sent, then a useful control and management > structure should be able to use it. But it seems like we need to > have an infrastructure that is capable of realizing services on > an IP network before we worry overly much about what is being > sent. Particularly since signaling is not required for all > services. >=20 > Kathie >=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 Thu Mar 09 12:40:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHP8F-0000Yl-4n; Thu, 09 Mar 2006 12:40:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHP8E-0000Yd-DF for dcpel@ietf.org; Thu, 09 Mar 2006 12:40:58 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHP8E-0001N6-2f for dcpel@ietf.org; Thu, 09 Mar 2006 12:40:58 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 09 Mar 2006 09:40:57 -0800 X-IronPort-AV: i="4.02,179,1139212800"; d="scan'208"; a="260824174:sNHT32062590" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k29Hev1l011763; Thu, 9 Mar 2006 09:40:57 -0800 (PST) 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); Thu, 9 Mar 2006 09:40:57 -0800 Received: from jmpolk-wxp.cisco.com ([10.89.16.70]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Mar 2006 09:40:56 -0800 Message-Id: <4.3.2.7.2.20060309105756.02f4d4f0@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 09 Mar 2006 11:40:55 -0600 To: Kathleen Nichols , "Tschofenig, Hannes" , dcpel@ietf.org From: "James M. Polk" Subject: Re: AW: [Dcpel] FWD: [Re: proposed charter] In-Reply-To: <4410502C.3070002@pollere.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 09 Mar 2006 17:40:56.0587 (UTC) FILETIME=[9EDED5B0:01C643A0] X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c 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: , Errors-To: dcpel-bounces@ietf.org Kathie Long ago the IESG made the decision in the SIP community to break that WG up into two parts: SIP and SIPPING. SIPPING handles the requirements and the "how to use SIP" aspects, and SIP focuses on the core specification and extending the protocol. The reason I bring up that analogy is that what I read from you below is saying that you aren't particularly interested, not cavalierly, but for a reason, in how your "control" is sent around the Internet. You're working on what to do with whatever control there can be when it gets to the destination elements. Is this about right? If so, taking the SIP example, you're looking at more of a "how to use *Diffserv* to elicit a level of control of traffic behaviors traversing elements in a domain" - which to me, is a BCP of what exists already. If you do not have the necessary pieces or parts to write this BCP of how to do something regarding control and mgmt of QoS within a domain or interdomain, then the appropriate protocols need to be extended in order to get you (said in general terms) the tools to write an appropriate BCP. This seems like it can be accomplished in one of two ways: #1 - individual submissions into each protocol WG that will enable the functionality you seek or #2 - create a WG designed to extend, within that new WG, each protocol that will enable the functionality you seek. Then, after all this is done, this BCP (or two) can be written. Perhaps one for Intra-domain control and mgmt, and one for Inter-domain. I think the endgame of this list is these two documents, the first of which you agreed to tackle, and the latter is what a few others on the list want to tackle right away too. I believe there are more than a few out there that believe what you (speaking generally) need is a hub-and-spoke communication protocol to carry your control, which may or may not exist yet; but if it does, it certainly needs extending, which ought to occur first. At 07:56 AM 3/9/2006 -0800, Kathleen Nichols wrote: >So, I really must reply, in brief, to Hannes's email. It seems >to be all about signaling. In my opinion, this has been a big >problem in the QoS area in general and particularly at the IETF. >That is, spending time talking about what information is going to >be sent around and in what sort of containers rather than how to >manage and control IP differentiated services. If the right >information is being sent, then a useful control and management >structure should be able to use it. But it seems like we need to >have an infrastructure that is capable of realizing services on >an IP network before we worry overly much about what is being >sent. Particularly since signaling is not required for all >services. > > 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 From dcpel-bounces@ietf.org Thu Mar 09 13:21:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHPlQ-0006No-JS; Thu, 09 Mar 2006 13:21:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHPlP-0006KM-Ai for dcpel@ietf.org; Thu, 09 Mar 2006 13:21:27 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHPlO-0002gd-Rk for dcpel@ietf.org; Thu, 09 Mar 2006 13:21:27 -0500 Received: from ftrdmel10.rd.francetelecom.fr ([10.193.117.156]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Mar 2006 19:21:24 +0100 Received: from [10.193.11.148] ([10.193.11.148]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Mar 2006 19:21:23 +0100 Message-ID: <44107223.9090203@rd.francetelecom.com> Date: Thu, 09 Mar 2006 19:21:23 +0100 From: Olivier Dugeon Organization: France Telecom R&D User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: Paulo Mendes Subject: Re: [Dcpel] DCPEL BoF support References: <43FF0D8F.1020800@rd.francetelecom.com> <4408495A.10003@docomolab-euro.com> In-Reply-To: <4408495A.10003@docomolab-euro.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 09 Mar 2006 18:21:23.0589 (UTC) FILETIME=[4579F350:01C643A6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba 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: , Errors-To: dcpel-bounces@ietf.org Hi Paulo and Kathie, Paulo Mendes a =E9crit : > Hi Olivier, > > see my comments inline. > > Olivier Dugeon wrote: > >> Hello Kathleen and all, >> >> We are in favor of a such BoF. Again, I'll ask my colleagues whom=20 >> attend the next IETF meeting to be present during the DCPEL BoF=20 >> session regarding their respective constraint to follow their=20 >> respective WG. >> >> Concerning the charter, I just want to know if the points described=20 >> below could be present: >> >> - Study and define a global framework and architecture which take=20 >> into account the inter-domain control plane and not only the=20 >> intra-domain > > [Paulo] The definition of a overall architecture is already scheduled=20 > in the current proposed charter. And the current version of the DCPEL=20 > requirements I-D, already mention the the Diffserv control plane,=20 > should consider the inter-domain relationship besides the intra-domain = > control. The creation of an I-D on interworking between DiffServ=20 > domains is also planned in the charter proposal. [OD] Ok. > >> - Produce RFC about the end to end CoS definition i.e. by extending=20 >> the notion of Per Domain Behavior to the inter domain. The draft=20 >> about Meta-CoS class from Pierre Levis could be a starting point > > [Paulo] The e2e definition of CoS should be discussed. IMO, it is most = > helpful if we keep the intra-domain mechanisms and PDBs transparent to = > the inter-domain operations, and so e2e. So, I would say that the=20 > definition of e2e CoS is related to the use of the inter-domain=20 > service information model, and not the to PDBs to be used within a=20 > network. The relationship between PDBs and services (SLSs) is=20 > something to be worked out within DCPEL. [OD] Ok. In fact I just want to make an analogy to the PDB. IMHO, I=20 think we need to study, effectively in the scope of e2e, an equivalent=20 of the PDB for the inter-domain aka Inter-Domain Behavior (IDB). Is why=20 I'm referring to the work done by Pierre Levis about the Meta-CoS Class. = Without a such IDB, we can't define the behavior of the DCP for the=20 inter-domain. > >> - Produce RFC which define both data and interface to request CoS to=20 >> the DCPEL framework from and application i.e. SLS definition in term=20 >> of parameters, function and transport prootocol > > [Paulo] The first issue of an I-D on DCP service information model is = > schedule for November 2006, while the interworking of a DCP network=20 > with external mechanisms will be analyzed in the framework I-D. [OD]. Ok, it make sense to start with the framework and the architecture = and then goes into the detail like the service information model. > >> - Produce RFC on topology acquisition to let the Control Plane in=20 >> touch (synchronize) with the Transfert Plane > > [Paulo] This is a topic related to a centralized control plane. Since=20 > the DCPEL requirements I-D mention the possible centralized and=20 > distributed control of PDBs, and assuming that this proposal will be=20 > accepted, I'm expecting some I-D proposals for DCP centralized=20 > mechanisms and distributed mechanisms (December 2006 in the current=20 > charter proposal). It is up to the authors of the centralized=20 > proposals to refer to describe mechanisms for the acquisition of=20 > topology information. [OD]. I'm not explicitly refer to a full centralized mode. In fact, I=20 think we need to clarify what we intend by centralized vs. distributed.=20 For the distributed point of view, I'm not sure that it is pertinent to=20 refer to a full distributed mode where all DCP agent are place in each=20 router/device and are aware of the topology since there are on the data=20 path. This mode is too close to a signaling approach and certainly be in = conflict with NSIS. IMHO, is certainly why NSIS peoples will see some=20 overlapping with this BoF. At the opposite, a fully centralized mode is=20 certainly not scalable for big network. IMHO, the DCPEL WG could focus on a semi distributed mode. In this case, = a DCP agent will control a given set of routers/devices and are out of=20 the data-path. So, in this case a simple but efficient topology=20 acquisition tools is mandatory to automatically discover and maintain=20 the part of the network the DCP agent control. Typically, this is=20 correspond to an area or sub area of a routing protocol. The=20 communication between DCP agent is more or less the same even if the 2=20 DCP agents are not part of the same AS i.e intra and inter domain=20 communication is more or less the same. > >> - Produce RFC on which protocol will fit requirement to exchange=20 >> inter-DCPEL SLS i.e. looking how NSIS could fit or be extended to=20 >> this purpose. > > [Paulo] This is contemplated in the I-D on interworking between=20 > DiffServ domain (scheduled March 2007 in the current charter). It is=20 > expectable that we'll be able to discuss different approaches to allow = > the interworking of DiffServ domains, based for instance on NSIS, SIP, = > or other protocol model. [OD] Ok. But I'm not in favor of using SIP. Using SIP will lead the e2e=20 CoS decision at the service plane level which, IMHO, is not a good=20 solution. I understand the argument in favor of this. All operator=20 through the IMS concept thinks that the e2e will be assured by IMS=20 interconnection. The main problem come from the fact that 2 IMS could=20 not necessary be directly interconnect. The connection could traverse=20 one or more AS and completely escape to the IMS signaling. In this case, = DCP take all its sense since it see all the AS between 2 IMS. Another=20 reason is that the NGN stratum separation is not respected. In order to=20 efficiently select the best AS path, the IMS, at service level, need=20 information which come from the control and transfer levels. > >> - Produce RFC on which protocol will fit requirement to enforce QoS=20 >> in the underlying network i.e lookink to COPS and NetConf to see how=20 >> it could be used > > [Paulo] This is also mostly specific to centralized control approaches.= [OD]. See point above. A semi-distributed approach need them also. Regards, Olivier > > Cheers > Paulo > >> >> Please, don't hesitate to comment. >> >> Regards, >> >> Olivier >> >> PS. I will be out of my office next week and have sporadic access to=20 >> my e-mail >> >> > > > --=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 Thu Mar 09 13:31:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHPvW-0001GZ-46; Thu, 09 Mar 2006 13:31:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHPvU-0001GA-6c for dcpel@ietf.org; Thu, 09 Mar 2006 13:31:52 -0500 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHPvT-00034h-57 for dcpel@ietf.org; Thu, 09 Mar 2006 13:31:52 -0500 Received: from ftrdmel10.rd.francetelecom.fr ([10.193.117.156]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Mar 2006 19:31:42 +0100 Received: from [10.193.11.148] ([10.193.11.148]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Mar 2006 19:31:41 +0100 Message-ID: <4410748D.70502@rd.francetelecom.com> Date: Thu, 09 Mar 2006 19:31:41 +0100 From: Olivier Dugeon Organization: France Telecom R&D User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: "Tschofenig, Hannes" Subject: Re: AW: [Dcpel] FWD: [Re: proposed charter] References: In-Reply-To: X-OriginalArrivalTime: 09 Mar 2006 18:31:41.0819 (UTC) FILETIME=[B5F85CB0:01C643A7] X-Spam-Score: 0.5 (/) X-Scan-Signature: 3bef755d9f4ba0b7ac474570b36ffadb Cc: dcpel@ietf.org, Michel Diaz 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="===============1330781156==" Errors-To: dcpel-bounces@ietf.org This is a multi-part message in MIME format. --===============1330781156== Content-Type: multipart/alternative; boundary="------------070400060500070704080100" This is a multi-part message in MIME format. --------------070400060500070704080100 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hello Hannes, Thanks to your pointer. I remember at the beginning of NSIS WG the great debate about on-path=20 vs. off-path. The conclusion have been to choose to study only on-path=20 within NSIS. In parallel, a BoF was setup to attempt to create an=20 off-path WG. Unfortunately this was cancel too. So, I'm surprise and the same time happy to see that NSIS will again=20 start studying off-path or try to attempt a BoF. In my opinion, DCPEL and off-path NSIS have more or less the same=20 objective looking at 2 different approaches. Perhaps a good deal will to = merge the 2 initiatives to form a larger and greater consensus. In the same time, some ideas from EuQoS project=20 (http://www.ietf.org/internet-drafts/draft-cordeiro-nsis-hypath-00.txt)=20 have been submit to the NSIS WG about a such approach (in fact, we used=20 NSIS for our Resource Manager communication). Regards, Olivier Tschofenig, Hannes a =E9crit : > Hi Olivier,=20 > Hi David,=20 > > I agree with David that there is essentially a lot of protocol work (ho= pefully "only" extensions) that seems to be envisioned by DCPEL. A few we= eks ago Georgios has sent a mail asking for the relationship between the = IETF work and other QoS work that is currently being done outside the IET= F. There are many proposals being made today that need to be considered. = These organizations are, for various reasons, really crazy about QoS and = QoS signaling. As I noted at the last IETF meeting I think that the best = place for these discussions is the Transport Area where this type of prot= ocol discussions already happened in the past.=20 > > The IETF NSIS work has discussed various aspects of path-decoupled sign= aling approaches in the past and there are still proposals floating aroun= d. You might be interesting to see that there will be a discussion about = this subject at the next IETF meeting. See http://www1.ietf.org/mail-arch= ive/web/nsis/current/msg06007.html It might be interesting for you to att= end the NSIS WG session to share your thoughts with other QoS minded peop= le. Furthermore, a number of us have been in contact with the ITU-T (and = the ITU-T liaison person from the ITU-T side, Hui-Lan Lu, in particular),= including John Loughney and myself, to discuss how their requirements ca= n be brought to the IETF/NSIS working group to have a fruitful discussion= =2E=20 > > Ciao > Hannes > > =20 >> Hello David, >> >> Here it is some comments from an operator (ok R&D part only) !!! >> >> David Kessens a =E9crit : >> =20 >>> Kathie asked me whether I would be willing to share the=20 >>> =20 >> following mail >> =20 >>> with the group on my current thinking regarding a bof for dcepl. >>> >>> I obviously have no problem with that so please see below=20 >>> =20 >> for my mail >> =20 >>> to Kathie regarding this topic. I, and the other ADs CC'ed on this >>> mail, are interested in your comments. >>> >>> I hope this helps, >>> >>> David Kessens >>> --- >>> >>> ----- Forwarded message from David Kessens=20 >>> =20 >> ----- >> =20 >>> Date: Mon, 6 Mar 2006 20:58:32 -0800 >>> From: David Kessens >>> To: Kathleen Nichols >>> Subject: Re: proposed charter >>> >>> >>> Kathie, >>> >>> On Wed, Feb 22, 2006 at 10:51:34AM -0800, Kathleen Nichols wrote: >>> =20 >>> =20 >>>> Attached is a draft charter. Scott and Paulo haven't had a >>>> chance to weigh in on it, so I might get some good input >>>> there. I would hope to have better milestones after an >>>> organizational meeting or BoF. >>>> =20 >>>> =20 >>> I am sorry for the delay in my response. We normally spend some time >>> to do an internal review with the IAB and IESG and I was waiting for >>> Allison who promised comments. >>> >>> I am sympathic to the goals of this proposed work and I=20 >>> =20 >> have received >> =20 >>> various comments from the IAB stating so. >>> >>> However, I also received comments that this work could be=20 >>> =20 >> conflicting >> =20 >>> with existing IETF work in the NSIS and TSV working group. >>> >>> While the proposed charter doesn't necessarily would=20 >>> =20 >> require protocol >> =20 >>> work, the drafts that I read would more or less require this. As you >>> know, the Ops part of the Ops&Mgmt area usually doesn't do protocol >>> work and limits itself to issues that are relevant to the operations >>> =20 >>> =20 >> I'm agree with your remarks. But, IMHO, the DCPEL WG have to=20 >> deal with=20 >> protocol: Not produce new protocol, but adapt or suggest=20 >> modifications=20 >> to relevant WG. For exemple, DCPA inter-domain communication=20 >> could use=20 >> NSIS. But, since NSIS have not yet design for this, it certainly need = >> some modifications or, at least, to setup a new NSLP stack=20 >> liek QoS-NSLP=20 >> (thanks to the 2 layers signalling of NSIS which could facilitate the = >> work). Another example concern the SLS interface aka the interface=20 >> between service and DCPEL. Again, some stuff are usable like=20 >> SIP, XML,=20 >> ... but need some adaptation to carry properly the SLS from=20 >> the service=20 >> to the DCPEL. >> =20 >>> of the Internet. In addition, to make sure that things are relevant >>> for operators, we normally want to have feedback, support and >>> involvement from operators to avoid situations where=20 >>> =20 >> vendors build all >> =20 >>> kind of complex solutions for problems that operators don't have. >>> >>> So far, I have seen some support from academia, research efforts >>> within larger corporations and some vendors, but I have seen little >>> evidence that this group is going to solve a problem that operators >>> want to be solved. As I already mentioned in an earlier mail, I am >>> really somewhat surprised that I haven't seen any operator=20 >>> =20 >> on the list >> =20 >>> commenting that we need to start this work as I did expect=20 >>> =20 >> that myself. >> =20 >>> =20 >>> =20 >> Sorry to contradict you, but, if you look carefully at the=20 >> mailing list,=20 >> you could see that I support DCPEL initiative from the beginning=20 >> (10/14/2005). During the last IETF meeting, FTR&D support this work=20 >> during the OPS AREA meeting. In the same time, through the=20 >> European IST=20 >> projet EuQoS, I request support from other operator like TID=20 >> (Telefonica=20 >> I+D). Generally speaking, in Europe, most of the operator are=20 >> search for=20 >> such functionalities. Look to the work done in other fora such as=20 >> ETSI/TISPAN, ITU-NGN-FG and now Q4/13 or more recently to the=20 >> DSL Forum.=20 >> In fact, IETF is the only place where QoS control, and in particular=20 >> resource control, are not study in the scope proposed by the DCEPL=20 >> initiative. >> =20 >>> Considering these issues, I think that it probably is not=20 >>> =20 >> in your best >> =20 >>> interest to pursue a bof for this IETF. >>> >>> We will first need a much clearer answer on what problem is going to >>> be solved *for operators*, get real support from operators=20 >>> =20 >> behind this >> =20 >>> effort and after that we need to figure out whether that=20 >>> =20 >> solution will >> =20 >>> involve protocol work or not. >>> =20 >>> =20 >> I could discuss this directly by phone as I'm not agree with=20 >> you. But,=20 >> operator need and want a global solution to setup and=20 >> exchange QoS. If=20 >> you just look at the VoIP service, inter-domain correspond to the=20 >> "international" part of the traditional PSTN. For the moment,=20 >> only study=20 >> are conduct to the access network. But, it is not sufficient. For the = >> moment, people think that over-provisioning will solve this=20 >> issue. This=20 >> is true for the bandwidth, but not for the other QoS=20 >> parameters such as=20 >> jitter, delay, loss ... However, VoIP services are vey=20 >> sensible to the=20 >> jitter and the delay. Without inter-domain and global QoS=20 >> solution, it=20 >> could not be possible to deploy a global VoIP QoS solution.=20 >> In the same=20 >> way, all multi-media service (IP TV, VoD, ...) need also QoS control. = >> Adopting a signaling like NSIS is certainly a great solution,=20 >> but which=20 >> will be deploy not before 5 or 10 years due to the time scale=20 >> operator=20 >> renew their transfer plane equipments. At the opposite, a=20 >> control plane=20 >> such as DCPEL propose, could be deploy very quickly without changing=20 >> their transfer plane. >> >> Today, operator are in a such situation that there is some industrial = >> solution on the market, but no standard to compare them or inter-oper = >> without development or major adaptation. >> >> Finally, ITU and ETSI will finalize first standard of the=20 >> RACF function,=20 >> but too much dedicated to conversational service. IMHO, it is=20 >> really a=20 >> mess that IETF will not conduct study on diffserv control plane. >> =20 >>> You can probably convince me to hold a bof anyways but considering >>> the above stumbling blocks, I would advise you not to do so. >>> =20 >>> =20 >> I'm agree that the charter need more clarification and scope=20 >> need more=20 >> focus. But, this is a very complex subject. All peoples with whom I=20 >> discussed about this, have a different opinion on the technical=20 >> solution, but all are agree to said that we need a solution. >> >> Best regards, >> >> Olivier Dugeon >> =20 >>> David Kessens >>> --- >>> >>> _______________________________________________ >>> Dcpel mailing list >>> Dcpel@ietf.org >>> https://www1.ietf.org/mailman/listinfo/dcpel >>> >>> =20 >>> =20 >> --=20 >> Project Manager for Network architecture and switching Division >> & FT/DR&D/CORE/M2I |=20 >> 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 >> >> =20 > > =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 --------------070400060500070704080100 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello Hannes,

Thanks to your pointer.

I remember at the beginning of NSIS WG the great debate about on-path vs. off-path. The conclusion have been to choose to study only on-path within NSIS. In parallel, a BoF was setup to attempt to create an off-path WG. Unfortunately this was cancel too.

So, I'm surprise and the same time happy to see that NSIS will again start studying off-path or try to attempt a BoF.

In my opinion, DCPEL and off-path NSIS have more or less the same objective looking at 2 different approaches. Perhaps a good deal will to merge the 2 initiatives to form a larger and greater consensus.

In the same time, some ideas from EuQoS project (http://www.ietf.org/internet-drafts/draft-cordeiro-nsis-hypath-00.txt) have been submit to the NSIS WG about a such approach (in fact, we used NSIS for our Resource Manager communication).

Regards,

Olivier

Tschofenig, Hannes a écrit : 
Hi Olivier, 
Hi David, 

I agree with David that there is essentially a lot of protocol work (hopefully "only" extensions) that seems to be envisioned by DCPEL. A few weeks ago Georgios has sent a mail asking for the relationship between the IETF work and other QoS work that is currently being done outside the IETF. There are many proposals being made today that need to be considered. These organizations are, for various reasons, really crazy about QoS and QoS signaling. As I noted at the last IETF meeting I think that the best place for these discussions is the Transport Area where this type of protocol discussions already happened in the past. 

The IETF NSIS work has discussed various aspects of path-decoupled signaling approaches in the past and there are still proposals floating around. You might be interesting to see that there will be a discussion about this subject at the next IETF meeting. See http://www1.ietf.org/mail-archive/web/nsis/current/msg06007.html It might be interesting for you to attend the NSIS WG session to share your thoughts with other QoS minded people. Furthermore, a number of us have been in contact with the ITU-T (and the ITU-T liaison person from the ITU-T side, Hui-Lan Lu, in particular), including John Loughney and myself, to discuss how their requirements can be brought to the IETF/NSIS working group to have a fruitful discussion. 

Ciao
Hannes

  
Hello David,

Here it is some comments from an operator (ok R&D part only)  !!!

David Kessens a écrit :
    
Kathie asked me whether I would be willing to share the 
      
following mail
    
with the group on my current thinking regarding a bof for dcepl.

I obviously have no problem with that so please see below 
      
for my mail
    
to Kathie regarding this topic. I, and the other ADs CC'ed on this
mail, are interested in your comments.

I hope this helps,

David Kessens
---

----- Forwarded message from David Kessens 
      
<david.kessens@nokia.com> -----
    
Date: Mon, 6 Mar 2006 20:58:32 -0800
From: David Kessens <david.kessens@nokia.com>
To: Kathleen Nichols <nichols@pollere.com>
Subject: Re: proposed charter


Kathie,

On Wed, Feb 22, 2006 at 10:51:34AM -0800, Kathleen Nichols wrote:
  
      
Attached is a draft charter. Scott and Paulo haven't had a
chance to weigh in on it, so I might get some good input
there. I would hope to have better milestones after an
organizational meeting or BoF.
    
        
I am sorry for the delay in my response. We normally spend some time
to do an internal review with the IAB and IESG and I was waiting for
Allison who promised comments.

I am sympathic to the goals of this proposed work and I 
      
have received
    
various comments from the IAB stating so.

However, I also received comments that this work could be 
      
conflicting
    
with existing IETF work in the NSIS and TSV working group.

While the proposed charter doesn't necessarily would 
      
require protocol
    
work, the drafts that I read would more or less require this. As you
know, the Ops part of the Ops&Mgmt area usually doesn't do protocol
work and limits itself to issues that are relevant to the operations
  
      
I'm agree with your remarks. But, IMHO, the DCPEL WG have to 
deal with 
protocol: Not produce new protocol, but adapt or suggest 
modifications 
to relevant WG. For exemple, DCPA inter-domain communication 
could use 
NSIS. But, since NSIS have not yet design for this, it certainly need 
some modifications or, at least, to setup a new NSLP stack 
liek QoS-NSLP 
(thanks to the 2 layers signalling of NSIS which could facilitate the 
work). Another example concern the SLS interface aka the interface 
between service and DCPEL. Again, some stuff are usable like 
SIP, XML, 
... but need some adaptation to carry properly the SLS from 
the service 
to the DCPEL.
    
of the Internet. In addition, to make sure that things are relevant
for operators, we normally want to have feedback, support and
involvement from operators to avoid situations where 
      
vendors build all
    
kind of complex solutions for problems that operators don't have.

So far, I have seen some support from academia, research efforts
within larger corporations and some vendors, but I have seen little
evidence that this group is going to solve a problem that operators
want to be solved. As I already mentioned in an earlier mail, I am
really somewhat surprised that I haven't seen any operator 
      
on the list
    
commenting that we need to start this work as I did expect 
      
that myself.
    
  
      
Sorry to contradict you, but, if you look carefully at the 
mailing list, 
you could see that I support DCPEL initiative from the beginning 
(10/14/2005). During the last IETF meeting, FTR&D support this work 
during the OPS AREA meeting. In the same time, through the 
European IST 
projet EuQoS, I request support from other operator like TID 
(Telefonica 
I+D). Generally speaking, in Europe, most of the operator are 
search for 
such functionalities. Look to the work done in other fora such as 
ETSI/TISPAN, ITU-NGN-FG and now Q4/13 or more recently to the 
DSL Forum. 
In fact, IETF is the only place where QoS control, and in particular 
resource control, are not study in the scope proposed by the DCEPL 
initiative.
    
Considering these issues, I think that it probably is not 
      
in your best
    
interest to pursue a bof for this IETF.

We will first need a much clearer answer on what problem is going to
be solved *for operators*, get real support from operators 
      
behind this
    
effort and after that we need to figure out whether that 
      
solution will
    
involve protocol work or not.
  
      
I could discuss this directly by phone as I'm not agree with 
you. But, 
operator need and want a global solution to setup and 
exchange QoS. If 
you just look at the VoIP service, inter-domain correspond to the 
"international" part of the traditional PSTN. For the moment, 
only study 
are conduct to the access network. But, it is not sufficient. For the 
moment, people think that over-provisioning will solve this 
issue. This 
is true for the bandwidth, but not for the other QoS 
parameters such as 
jitter, delay, loss ... However, VoIP services are vey 
sensible to the 
jitter and the delay. Without inter-domain and global QoS 
solution, it 
could not be possible to deploy a global VoIP QoS solution. 
In the same 
way, all multi-media service (IP TV, VoD, ...) need also QoS control. 
Adopting a signaling like NSIS is certainly a great solution, 
but which 
will be deploy not before 5 or 10 years due to the time scale 
operator 
renew their transfer plane equipments. At the opposite, a 
control plane 
such as DCPEL propose, could be deploy very quickly without changing 
their transfer plane.

Today, operator are in a such situation that there is some industrial 
solution on the market, but no standard to compare them or inter-oper 
without development or major adaptation.

Finally, ITU and ETSI will finalize first standard of the 
RACF function, 
but too much dedicated to conversational service. IMHO, it is 
really a 
mess that IETF will not conduct study on diffserv control plane.
    
You can probably convince me to hold a bof anyways but considering
the above stumbling blocks, I would advise you not to do so.
  
      
I'm agree that the charter need more clarification and scope 
need more 
focus. But, this is a very complex subject. All peoples with whom I 
discussed about this, have a different opinion on the technical 
solution, but all are agree to said that we need a solution.

Best regards,

Olivier Dugeon
    
David Kessens
---

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

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

    

  

-- 
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
--------------070400060500070704080100-- --===============1330781156== 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 --===============1330781156==-- From dcpel-bounces@ietf.org Fri Mar 10 05:56:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHfIY-0003HY-6N; Fri, 10 Mar 2006 05:56:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHfIW-0003Dh-O0 for dcpel@ietf.org; Fri, 10 Mar 2006 05:56:40 -0500 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHfIV-0002OD-6K for dcpel@ietf.org; Fri, 10 Mar 2006 05:56:40 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Mar 2006 11:56:37 +0100 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dcpel] DCPEL BoF support Date: Fri, 10 Mar 2006 11:56:35 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dcpel] DCPEL BoF support Thread-Index: AcZDpklWn6ni3UFtSWG10746y3pHSAAiXLpg From: "LEVIS Pierre RD-CORE-CAE" To: X-OriginalArrivalTime: 10 Mar 2006 10:56:37.0001 (UTC) FILETIME=[4D718790:01C64431] X-Spam-Score: 0.0 (/) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e 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: , Errors-To: dcpel-bounces@ietf.org Hi all, As the author of draft-meta-qos-class-00.txt stated by Olivier, I would = like to provide somm complement to back Olivier's proposal. IMHO QoS SLS between Autonomous Systems (if we take AS as the basic = interdomain element) doesn't really care about PDB. A PDP is a way, I would say the Diffserv way, to enforce a QoS level = target inside a single domain. It is closely related to a PHB or set of = PHBs. Suppose now, I'm an ISP, with a tremendously over-provisioned = best-effort network. Despite best-effort only, I can gaurantee strong QoS. My neighbouring domains won't decline my offer just because my only PDB = is best-effort, they are interested in the level of QoS I can provide, = and not in the way I have engineered my network. Furthermore I, as an ISP, would not disclose my internal network = setting. So, for interdomain QoS negotiations we need a notion, an = external view, decorrelated from any type of physical realisation, = simply to capture the available level of QoS. It is where Meta-QoS-Class applies. Note that I've sent directly my = draft to the RFC Editor because there was no WG, at that time, to host = this work, so the draft is in the RFC Editor queue, the intended status = is Informational RFC.=20 This work is the outcome of the MESCAL European project, follow-up of = the TEQUILA project well known for its proposal on SLS format.=20 Regards, Pierre -----Message d'origine----- De : DUGEON Olivier RD-CORE [mailto:olivier.dugeon@francetelecom.com]=20 Envoy=E9 : jeudi 9 mars 2006 19:21 =C0 : Paulo Mendes Cc : dcpel@ietf.org Objet : Re: [Dcpel] DCPEL BoF support Hi Paulo and Kathie, Paulo Mendes a =E9crit : > Hi Olivier, > > see my comments inline. > > Olivier Dugeon wrote: > >> Hello Kathleen and all, >> >> We are in favor of a such BoF. Again, I'll ask my colleagues whom=20 >> attend the next IETF meeting to be present during the DCPEL BoF=20 >> session regarding their respective constraint to follow their=20 >> respective WG. >> >> Concerning the charter, I just want to know if the points described=20 >> below could be present: >> >> - Study and define a global framework and architecture which take=20 >> into account the inter-domain control plane and not only the=20 >> intra-domain > > [Paulo] The definition of a overall architecture is already scheduled=20 > in the current proposed charter. And the current version of the DCPEL=20 > requirements I-D, already mention the the Diffserv control plane,=20 > should consider the inter-domain relationship besides the intra-domain = > control. The creation of an I-D on interworking between DiffServ=20 > domains is also planned in the charter proposal. [OD] Ok. > >> - Produce RFC about the end to end CoS definition i.e. by extending=20 >> the notion of Per Domain Behavior to the inter domain. The draft=20 >> about Meta-CoS class from Pierre Levis could be a starting point > > [Paulo] The e2e definition of CoS should be discussed. IMO, it is most = > helpful if we keep the intra-domain mechanisms and PDBs transparent to = > the inter-domain operations, and so e2e. So, I would say that the=20 > definition of e2e CoS is related to the use of the inter-domain=20 > service information model, and not the to PDBs to be used within a=20 > network. The relationship between PDBs and services (SLSs) is=20 > something to be worked out within DCPEL. [OD] Ok. In fact I just want to make an analogy to the PDB. IMHO, I = think we need to study, effectively in the scope of e2e, an equivalent = of the PDB for the inter-domain aka Inter-Domain Behavior (IDB). Is why = I'm referring to the work done by Pierre Levis about the Meta-CoS Class. = Without a such IDB, we can't define the behavior of the DCP for the = inter-domain. > >> - Produce RFC which define both data and interface to request CoS to=20 >> the DCPEL framework from and application i.e. SLS definition in term=20 >> of parameters, function and transport prootocol > > [Paulo] The first issue of an I-D on DCP service information model is = > schedule for November 2006, while the interworking of a DCP network=20 > with external mechanisms will be analyzed in the framework I-D. [OD]. Ok, it make sense to start with the framework and the architecture = and then goes into the detail like the service information model. > >> - Produce RFC on topology acquisition to let the Control Plane in=20 >> touch (synchronize) with the Transfert Plane > > [Paulo] This is a topic related to a centralized control plane. Since=20 > the DCPEL requirements I-D mention the possible centralized and=20 > distributed control of PDBs, and assuming that this proposal will be=20 > accepted, I'm expecting some I-D proposals for DCP centralized=20 > mechanisms and distributed mechanisms (December 2006 in the current=20 > charter proposal). It is up to the authors of the centralized=20 > proposals to refer to describe mechanisms for the acquisition of=20 > topology information. [OD]. I'm not explicitly refer to a full centralized mode. In fact, I = think we need to clarify what we intend by centralized vs. distributed.=20 For the distributed point of view, I'm not sure that it is pertinent to = refer to a full distributed mode where all DCP agent are place in each = router/device and are aware of the topology since there are on the data = path. This mode is too close to a signaling approach and certainly be in = conflict with NSIS. IMHO, is certainly why NSIS peoples will see some = overlapping with this BoF. At the opposite, a fully centralized mode is = certainly not scalable for big network. IMHO, the DCPEL WG could focus on a semi distributed mode. In this case, = a DCP agent will control a given set of routers/devices and are out of = the data-path. So, in this case a simple but efficient topology = acquisition tools is mandatory to automatically discover and maintain = the part of the network the DCP agent control. Typically, this is = correspond to an area or sub area of a routing protocol. The = communication between DCP agent is more or less the same even if the 2 = DCP agents are not part of the same AS i.e intra and inter domain = communication is more or less the same. > >> - Produce RFC on which protocol will fit requirement to exchange=20 >> inter-DCPEL SLS i.e. looking how NSIS could fit or be extended to=20 >> this purpose. > > [Paulo] This is contemplated in the I-D on interworking between=20 > DiffServ domain (scheduled March 2007 in the current charter). It is=20 > expectable that we'll be able to discuss different approaches to allow = > the interworking of DiffServ domains, based for instance on NSIS, SIP, = > or other protocol model. [OD] Ok. But I'm not in favor of using SIP. Using SIP will lead the e2e = CoS decision at the service plane level which, IMHO, is not a good = solution. I understand the argument in favor of this. All operator = through the IMS concept thinks that the e2e will be assured by IMS = interconnection. The main problem come from the fact that 2 IMS could = not necessary be directly interconnect. The connection could traverse = one or more AS and completely escape to the IMS signaling. In this case, = DCP take all its sense since it see all the AS between 2 IMS. Another = reason is that the NGN stratum separation is not respected. In order to = efficiently select the best AS path, the IMS, at service level, need = information which come from the control and transfer levels. > >> - Produce RFC on which protocol will fit requirement to enforce QoS=20 >> in the underlying network i.e lookink to COPS and NetConf to see how=20 >> it could be used > > [Paulo] This is also mostly specific to centralized control = approaches. [OD]. See point above. A semi-distributed approach need them also. Regards, Olivier > > Cheers > Paulo > >> >> Please, don't hesitate to comment. >> >> Regards, >> >> Olivier >> >> PS. I will be out of my office next week and have sporadic access to=20 >> my e-mail >> >> > > > -- 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 Mon Mar 13 04:59:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIjpZ-0006YG-C5; Mon, 13 Mar 2006 04:59:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIjpY-0006XU-A6 for dcpel@ietf.org; Mon, 13 Mar 2006 04:59:12 -0500 Received: from deprox.docomolab-euro.com ([212.119.9.186]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FIjpX-0008GE-D8 for dcpel@ietf.org; Mon, 13 Mar 2006 04:59:12 -0500 Received: from 172.27.10.3 by deprox.docomolab-euro.com (InterScan E-Mail VirusWall NT); Mon, 13 Mar 2006 10:57:31 +0100 Received: from [172.27.100.57] ([172.27.100.57]) by deex.docomolab-euro.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 13 Mar 2006 10:57:31 +0100 Message-ID: <44154219.3020800@docomolab-euro.com> Date: Mon, 13 Mar 2006 10:57:45 +0100 From: Paulo Mendes User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Tschofenig, Hannes" , David Kessens Subject: Re: AW: [Dcpel] FWD: [Re: proposed charter] References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 13 Mar 2006 09:57:31.0381 (UTC) FILETIME=[8B541A50:01C64684] X-Spam-Score: 0.0 (/) X-Scan-Signature: e3901bdd61b234d82da85cc76f05a7e8 Cc: dcpel@ietf.org, Olivier Dugeon 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: , Errors-To: dcpel-bounces@ietf.org Hi David, Hannes, and all Here is my view about the need of DCPEL for operators and about DCPEL relationship with NSIS, as I see it. I would like to stress we have been receiving support from operators since the beginning. Not only from NTT DoCoMo: I'm been helping to develop DCPEL since the beginning, and although NTT DoCoMo Euro-Labs is a research institution I gain the support of the Japanese development department since January. To NTT DoCoMo we can add France Telecom and Telefonia, as mentioned by Olivier. I would like to mention that the involvement of these operators in DCPEL follows their work on similar topics in other fora and research projects as mentioned by Olivier. Being even more pragmatic about the operators' need for a good solution to control and manage a DiffServ network, I would like to say that the need for such solution in increasing from DoCoMo side. We are looking at several possible solutions to control QoS in an all IP network. So, we are looking at work being done at 3GPP for instance. But we think that DiffServ may be a better solution for the future. The only problem (big one) is that there is no standard way to control and manage a DiffServ network. This is what DoCoMo wants: a standards set of procedures, PDBs for well-know traffic (voip, IPTV, video-streaming, ...), and set of protocols that together will allow us to control a future DiffServ network. So DCPEL aims to focus on how to operate a DiffServ network: - draft-chan-tsvwg-diffserv-class-aggr-03 (discussion of which fits DCPEL, IMO) provides guidelines of how multiple service classes may be aggregated into a forwarding treatment aggregate. - Independently from the fact that we need or not all the types of traffic aggregates enumerated in draft-chan-tsvwg-diffserv-class-aggr-03, we need to know how to make them real. - DCPEL is focusing on this goal. There is no work in IETF for: i) Define the PDBs to manage the traffic types discussed in draft-chan-tsvwg-diffserv-class-aggr-03 (the authors discuss a possible control based on MPLS). ii) Analyze what type of signaling is most suitable, and how different protocols may be combined. iii) Make ii) work for intra-domain management and combine it with inter-domain control. The interaction with NSIS fits in the analysis of current signaling protocols and how suitable they are to help in the control of a DiffServ network. This is, to be able to control QoS in real networks, we need a little more than defining signaling protocols. Currently, we have a very good number of protocols available in IETF, but we need to know how to use them and how to inter-operate them. For instance, it may be clear, based on the specification of DiffServ control elements that QoS-NSLP is the best option for intra-domain control. Or we may conclude that QoS-NSLP may need to be adapted. In the later case, the adaptation is analyzed in DCPEL (focusing on DiffServ control) and is specified in NSIS (focused on protocol specification). At least in some projects, I had some discussions about the current difficulty of standardizing a control mechanism in NSIS, since NSIS is only interested in the signaling part, while the mentioned mechanism may involve more that that (admission control, network monitoring, control of SLS, etc, etc). As an example, I can indicate some work being presented in NSIS that, IMO, is more suitable to be discussed in DCPEL: RMD - draft-ietf-nsis-rmd-06. RMD is not specifying any new NSLP, although it may have consequences in NSIS, if RMD needs some extensions or options for QoS-NSLP. RMD is more focus on the admission control and controlof congestion in Diffserv networks, being the signaling done with QoS-NSLP. IMO, it may be a hard job for NSIS to try to specify every possible NSLP on top of GIST. It would be better if NSIS provides the service level protocols that are required by other WG (namely the ones analysing the operation of IP networks), and not to specify any protocol that fits nicely on top of GIST. To terminate, an example (just an raw example, without any discussion until now :) ) of a possible interaction of DCPEL and NSIS: i) The control of some PDBs requires the use of QoS-NSLP edge-to-edge, but combined with COPS (for signaling between edges and an inter-domain QoS controller, from a set of possible controllers) and SIP (for signaling between terminal and network). The specification of this management operation is in the scope of DCPEL. NSIS contributes with QoS-NSLP. ii) Same scenario as in i) but QoS-NSLP doesn't fit perfectly. In this case DCPEL will analyse the needed requirements to extend QoS-NSLP. NSIS should then analyse all the details to include these extra requirements in the current draft. iii) QoS-NSLP doesn't fit at all in some scenarios, such as inter-domain, where a path-decoupled solution is better. Some people is currently thinking in extending, again, QoS-NSLP for path-decoupled signaling. But, how can we know that that work will be the most suitable for inter-domain DiffServ control? Or, even if it may be used, different approaches to path-decoupled signaling, even if based on NSIS, may also bring other advantages. This is, it is not because NSIS is going to 'extend' QoS-NSLP to operate path-decoupled that all DiffServ inter-domain operation control is solved. Here, I fully agree with Kathie. Cheers Paulo Tschofenig, Hannes wrote: >Hi Olivier, >Hi David, > >I agree with David that there is essentially a lot of protocol work (hopefully "only" extensions) that seems to be envisioned by DCPEL. A few weeks ago Georgios has sent a mail asking for the relationship between the IETF work and other QoS work that is currently being done outside the IETF. There are many proposals being made today that need to be considered. These organizations are, for various reasons, really crazy about QoS and QoS signaling. As I noted at the last IETF meeting I think that the best place for these discussions is the Transport Area where this type of protocol discussions already happened in the past. > >The IETF NSIS work has discussed various aspects of path-decoupled signaling approaches in the past and there are still proposals floating around. You might be interesting to see that there will be a discussion about this subject at the next IETF meeting. See http://www1.ietf.org/mail-archive/web/nsis/current/msg06007.html It might be interesting for you to attend the NSIS WG session to share your thoughts with other QoS minded people. Furthermore, a number of us have been in contact with the ITU-T (and the ITU-T liaison person from the ITU-T side, Hui-Lan Lu, in particular), including John Loughney and myself, to discuss how their requirements can be brought to the IETF/NSIS working group to have a fruitful discussion. > >Ciao >Hannes > > > >>Hello David, >> >>Here it is some comments from an operator (ok R&D part only) !!! >> >>David Kessens a écrit : >> >> >>>Kathie asked me whether I would be willing to share the >>> >>> >>following mail >> >> >>>with the group on my current thinking regarding a bof for dcepl. >>> >>>I obviously have no problem with that so please see below >>> >>> >>for my mail >> >> >>>to Kathie regarding this topic. I, and the other ADs CC'ed on this >>>mail, are interested in your comments. >>> >>>I hope this helps, >>> >>>David Kessens >>>--- >>> >>>----- Forwarded message from David Kessens >>> >>> >> ----- >> >> >>>Date: Mon, 6 Mar 2006 20:58:32 -0800 >>>From: David Kessens >>>To: Kathleen Nichols >>>Subject: Re: proposed charter >>> >>> >>>Kathie, >>> >>>On Wed, Feb 22, 2006 at 10:51:34AM -0800, Kathleen Nichols wrote: >>> >>> >>> >>>>Attached is a draft charter. Scott and Paulo haven't had a >>>>chance to weigh in on it, so I might get some good input >>>>there. I would hope to have better milestones after an >>>>organizational meeting or BoF. >>>> >>>> >>>> >>>I am sorry for the delay in my response. We normally spend some time >>>to do an internal review with the IAB and IESG and I was waiting for >>>Allison who promised comments. >>> >>>I am sympathic to the goals of this proposed work and I >>> >>> >>have received >> >> >>>various comments from the IAB stating so. >>> >>>However, I also received comments that this work could be >>> >>> >>conflicting >> >> >>>with existing IETF work in the NSIS and TSV working group. >>> >>>While the proposed charter doesn't necessarily would >>> >>> >>require protocol >> >> >>>work, the drafts that I read would more or less require this. As you >>>know, the Ops part of the Ops&Mgmt area usually doesn't do protocol >>>work and limits itself to issues that are relevant to the operations >>> >>> >>> >>I'm agree with your remarks. But, IMHO, the DCPEL WG have to >>deal with >>protocol: Not produce new protocol, but adapt or suggest >>modifications >>to relevant WG. For exemple, DCPA inter-domain communication >>could use >>NSIS. But, since NSIS have not yet design for this, it certainly need >>some modifications or, at least, to setup a new NSLP stack >>liek QoS-NSLP >>(thanks to the 2 layers signalling of NSIS which could facilitate the >>work). Another example concern the SLS interface aka the interface >>between service and DCPEL. Again, some stuff are usable like >>SIP, XML, >>... but need some adaptation to carry properly the SLS from >>the service >>to the DCPEL. >> >> >>>of the Internet. In addition, to make sure that things are relevant >>>for operators, we normally want to have feedback, support and >>>involvement from operators to avoid situations where >>> >>> >>vendors build all >> >> >>>kind of complex solutions for problems that operators don't have. >>> >>>So far, I have seen some support from academia, research efforts >>>within larger corporations and some vendors, but I have seen little >>>evidence that this group is going to solve a problem that operators >>>want to be solved. As I already mentioned in an earlier mail, I am >>>really somewhat surprised that I haven't seen any operator >>> >>> >>on the list >> >> >>>commenting that we need to start this work as I did expect >>> >>> >>that myself. >> >> >>> >>> >>> >>Sorry to contradict you, but, if you look carefully at the >>mailing list, >>you could see that I support DCPEL initiative from the beginning >>(10/14/2005). During the last IETF meeting, FTR&D support this work >>during the OPS AREA meeting. In the same time, through the >>European IST >>projet EuQoS, I request support from other operator like TID >>(Telefonica >>I+D). Generally speaking, in Europe, most of the operator are >>search for >>such functionalities. Look to the work done in other fora such as >>ETSI/TISPAN, ITU-NGN-FG and now Q4/13 or more recently to the >>DSL Forum. >>In fact, IETF is the only place where QoS control, and in particular >>resource control, are not study in the scope proposed by the DCEPL >>initiative. >> >> >>>Considering these issues, I think that it probably is not >>> >>> >>in your best >> >> >>>interest to pursue a bof for this IETF. >>> >>>We will first need a much clearer answer on what problem is going to >>>be solved *for operators*, get real support from operators >>> >>> >>behind this >> >> >>>effort and after that we need to figure out whether that >>> >>> >>solution will >> >> >>>involve protocol work or not. >>> >>> >>> >>I could discuss this directly by phone as I'm not agree with >>you. But, >>operator need and want a global solution to setup and >>exchange QoS. If >>you just look at the VoIP service, inter-domain correspond to the >>"international" part of the traditional PSTN. For the moment, >>only study >>are conduct to the access network. But, it is not sufficient. For the >>moment, people think that over-provisioning will solve this >>issue. This >>is true for the bandwidth, but not for the other QoS >>parameters such as >>jitter, delay, loss ... However, VoIP services are vey >>sensible to the >>jitter and the delay. Without inter-domain and global QoS >>solution, it >>could not be possible to deploy a global VoIP QoS solution. >>In the same >>way, all multi-media service (IP TV, VoD, ...) need also QoS control. >>Adopting a signaling like NSIS is certainly a great solution, >>but which >>will be deploy not before 5 or 10 years due to the time scale >>operator >>renew their transfer plane equipments. At the opposite, a >>control plane >>such as DCPEL propose, could be deploy very quickly without changing >>their transfer plane. >> >>Today, operator are in a such situation that there is some industrial >>solution on the market, but no standard to compare them or inter-oper >>without development or major adaptation. >> >>Finally, ITU and ETSI will finalize first standard of the >>RACF function, >>but too much dedicated to conversational service. IMHO, it is >>really a >>mess that IETF will not conduct study on diffserv control plane. >> >> >>>You can probably convince me to hold a bof anyways but considering >>>the above stumbling blocks, I would advise you not to do so. >>> >>> >>> >>I'm agree that the charter need more clarification and scope >>need more >>focus. But, this is a very complex subject. All peoples with whom I >>discussed about this, have a different opinion on the technical >>solution, but all are agree to said that we need a solution. >> >>Best regards, >> >>Olivier Dugeon >> >> >>>David Kessens >>>--- >>> >>>_______________________________________________ >>>Dcpel mailing list >>>Dcpel@ietf.org >>>https://www1.ietf.org/mailman/listinfo/dcpel >>> >>> >>> >>> >>-- >>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 > > > _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel From dcpel-bounces@ietf.org Mon Mar 13 05:01:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIjrI-0007Of-6B; Mon, 13 Mar 2006 05:01:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIjrG-0007OF-LS for dcpel@ietf.org; Mon, 13 Mar 2006 05:00:58 -0500 Received: from deprox.docomolab-euro.com ([212.119.9.186]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FIjrG-0008I4-2w for dcpel@ietf.org; Mon, 13 Mar 2006 05:00:58 -0500 Received: from 172.27.10.3 by deprox.docomolab-euro.com (InterScan E-Mail VirusWall NT); Mon, 13 Mar 2006 11:00:48 +0100 Received: from [172.27.100.57] ([172.27.100.57]) by deex.docomolab-euro.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 13 Mar 2006 11:00:48 +0100 Message-ID: <441542DE.1010000@docomolab-euro.com> Date: Mon, 13 Mar 2006 11:01:02 +0100 From: Paulo Mendes User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Olivier Dugeon Subject: Re: [Dcpel] DCPEL BoF support References: <43FF0D8F.1020800@rd.francetelecom.com> <4408495A.10003@docomolab-euro.com> <44107223.9090203@rd.francetelecom.com> In-Reply-To: <44107223.9090203@rd.francetelecom.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 13 Mar 2006 10:00:48.0241 (UTC) FILETIME=[00AA8E10:01C64685] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e 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: , Errors-To: dcpel-bounces@ietf.org Hi Olivier, some comments inline. Olivier Dugeon wrote: > Hi Paulo and Kathie, > > Paulo Mendes a écrit : > >> Hi Olivier, >> >> see my comments inline. >> >> Olivier Dugeon wrote: >> >>> Hello Kathleen and all, >>> >>> We are in favor of a such BoF. Again, I'll ask my colleagues whom >>> attend the next IETF meeting to be present during the DCPEL BoF >>> session regarding their respective constraint to follow their >>> respective WG. >>> >>> Concerning the charter, I just want to know if the points described >>> below could be present: >>> >>> - Study and define a global framework and architecture which take >>> into account the inter-domain control plane and not only the >>> intra-domain >> >> >> [Paulo] The definition of a overall architecture is already scheduled >> in the current proposed charter. And the current version of the DCPEL >> requirements I-D, already mention the the Diffserv control plane, >> should consider the inter-domain relationship besides the >> intra-domain control. The creation of an I-D on interworking between >> DiffServ domains is also planned in the charter proposal. > > [OD] Ok. > >> >>> - Produce RFC about the end to end CoS definition i.e. by extending >>> the notion of Per Domain Behavior to the inter domain. The draft >>> about Meta-CoS class from Pierre Levis could be a starting point >> >> >> [Paulo] The e2e definition of CoS should be discussed. IMO, it is >> most helpful if we keep the intra-domain mechanisms and PDBs >> transparent to the inter-domain operations, and so e2e. So, I would >> say that the definition of e2e CoS is related to the use of the >> inter-domain service information model, and not the to PDBs to be >> used within a network. The relationship between PDBs and services >> (SLSs) is something to be worked out within DCPEL. > > [OD] Ok. In fact I just want to make an analogy to the PDB. IMHO, I > think we need to study, effectively in the scope of e2e, an equivalent > of the PDB for the inter-domain aka Inter-Domain Behavior (IDB). Is > why I'm referring to the work done by Pierre Levis about the Meta-CoS > Class. Without a such IDB, we can't define the behavior of the DCP for > the inter-domain. > >> >>> - Produce RFC which define both data and interface to request CoS to >>> the DCPEL framework from and application i.e. SLS definition in term >>> of parameters, function and transport prootocol >> >> >> [Paulo] The first issue of an I-D on DCP service information model >> is schedule for November 2006, while the interworking of a DCP >> network with external mechanisms will be analyzed in the framework I-D. > > [OD]. Ok, it make sense to start with the framework and the > architecture and then goes into the detail like the service > information model. > >> >>> - Produce RFC on topology acquisition to let the Control Plane in >>> touch (synchronize) with the Transfert Plane >> >> >> [Paulo] This is a topic related to a centralized control plane. Since >> the DCPEL requirements I-D mention the possible centralized and >> distributed control of PDBs, and assuming that this proposal will be >> accepted, I'm expecting some I-D proposals for DCP centralized >> mechanisms and distributed mechanisms (December 2006 in the current >> charter proposal). It is up to the authors of the centralized >> proposals to refer to describe mechanisms for the acquisition of >> topology information. > > [OD]. I'm not explicitly refer to a full centralized mode. In fact, I > think we need to clarify what we intend by centralized vs. > distributed. For the distributed point of view, I'm not sure that it > is pertinent to refer to a full distributed mode where all DCP agent > are place in each router/device and are aware of the topology since > there are on the data path. This mode is too close to a signaling > approach and certainly be in conflict with NSIS. IMHO, is certainly > why NSIS peoples will see some overlapping with this BoF. At the > opposite, a fully centralized mode is certainly not scalable for big > network. > > IMHO, the DCPEL WG could focus on a semi distributed mode. In this > case, a DCP agent will control a given set of routers/devices and are > out of the data-path. So, in this case a simple but efficient topology > acquisition tools is mandatory to automatically discover and maintain > the part of the network the DCP agent control. Typically, this is > correspond to an area or sub area of a routing protocol. The > communication between DCP agent is more or less the same even if the 2 > DCP agents are not part of the same AS i.e intra and inter domain > communication is more or less the same. [Paulo] I agree with you. What we need to analyze is what is the best compromise, since this semi-distributed approach , as you called it, may have different operation modes, depending on the size of the 'area'. For instance, it may be different if we have an DCP agent in each edge device of one DCP agent controlling two of three edge devices. BTW: I don't think we need to have a DCP agent in any router/device in a network. At this point in time, I would say that that maximum distribution level that we should look at is having DCP agent in each edge devices (which may be present in a reduced number). >> >>> - Produce RFC on which protocol will fit requirement to exchange >>> inter-DCPEL SLS i.e. looking how NSIS could fit or be extended to >>> this purpose. >> >> >> [Paulo] This is contemplated in the I-D on interworking between >> DiffServ domain (scheduled March 2007 in the current charter). It is >> expectable that we'll be able to discuss different approaches to >> allow the interworking of DiffServ domains, based for instance on >> NSIS, SIP, or other protocol model. > > [OD] Ok. But I'm not in favor of using SIP. Using SIP will lead the > e2e CoS decision at the service plane level which, IMHO, is not a good > solution. I understand the argument in favor of this. All operator > through the IMS concept thinks that the e2e will be assured by IMS > interconnection. The main problem come from the fact that 2 IMS could > not necessary be directly interconnect. The connection could traverse > one or more AS and completely escape to the IMS signaling. In this > case, DCP take all its sense since it see all the AS between 2 IMS. > Another reason is that the NGN stratum separation is not respected. In > order to efficiently select the best AS path, the IMS, at service > level, need information which come from the control and transfer levels. [Paulo] I never defended a SIP solution by e2e inter-domain control. I mentioned that SIP may also play a role in inter-domain DiffServ control. For instance to allow end-host and network communication, since it is expectable all terminals to be SIP-enabled. >> >>> - Produce RFC on which protocol will fit requirement to enforce QoS >>> in the underlying network i.e lookink to COPS and NetConf to see how >>> it could be used >> >> >> [Paulo] This is also mostly specific to centralized control approaches. > > [OD]. See point above. A semi-distributed approach need them also. > > Regards, > > Olivier > >> >> Cheers >> Paulo >> >>> >>> Please, don't hesitate to comment. >>> >>> Regards, >>> >>> Olivier >>> >>> PS. I will be out of my office next week and have sporadic access to >>> my e-mail >>> >>> >> >> >> > _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel From dcpel-bounces@ietf.org Mon Mar 13 05:01:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIjrY-0007dv-B7; Mon, 13 Mar 2006 05:01:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIjrX-0007dq-1C for dcpel@ietf.org; Mon, 13 Mar 2006 05:01:15 -0500 Received: from deprox.docomolab-euro.com ([212.119.9.186]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FIjrW-0008IO-GM for dcpel@ietf.org; Mon, 13 Mar 2006 05:01:15 -0500 Received: from 172.27.10.3 by deprox.docomolab-euro.com (InterScan E-Mail VirusWall NT); Mon, 13 Mar 2006 11:00:25 +0100 Received: from [172.27.100.57] ([172.27.100.57]) by deex.docomolab-euro.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 13 Mar 2006 11:00:25 +0100 Message-ID: <441542C7.8020100@docomolab-euro.com> Date: Mon, 13 Mar 2006 11:00:39 +0100 From: Paulo Mendes User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Tschofenig, Hannes" Subject: Re: AW: AW: [Dcpel] FWD: [Re: proposed charter] References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 13 Mar 2006 10:00:25.0131 (UTC) FILETIME=[F2E43FB0:01C64684] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c 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: , Errors-To: dcpel-bounces@ietf.org Hi Hannes, All the questions that you mention are some of the reasons to have a WG looking at what do we need to operate a DiffServ network. Even if we focus on protocols, as you did in your e-mail, all your questions show that although we have a set of protocols available in IETF we still don't know our to inter-operate them for a common goal. The control of Diffserv networks, in this case. About what comes first, protocols or service control, IMO a protocol is only useful if we know why do we need it. Transporting data-control packets among network devices serves the goal of controlling some network functionality. In the case of DiffServ, it is not clear what protocols (and what content semantic) do we need and how will they interact to control DiffServ operations. I see this as a very good opportunity to stress the cooperation between different IETF WGs with a common goal in mind. So, DCPEL is all about cooperation and not about competition between WGs. Paulo Tschofenig, Hannes wrote: >Hi Kathie, > >your mail points to an aspect that a number of us have never really understood. >I think we have a terminology problem here. > >Just as an example, let us take a look at Figure 1 of : > > +-DCP-----------------------------+ > | | > | +---------------+ +-----+ | > | |Domain Policies| | AAA | | > | +--------||-----+ +-----+ | > | || || | > | +-----||----------|+ | > QoS Announce(*) <=====| |=========> QoS Announce (*) > QoS Request ========>| |=========> QoS Request > QoS Response <========| DCP |<========= QoS Response > QoS Query(*) ========>| |=========> QoS Query(*) > QoS Status <========| |<========= QoS Status > | +----||------------+ | > | || || | > | +-------||------+ +-||--------+ | > | | Enforcement | | Monitoring| | > | +---------------+ +-----------+ | > | | > +---------------------------------+ > >A few protocol interactions that come to my mind when I see this figure are: > >a) How does the AAA infrastructure interact with the DCP node? >b) Isn't a protocol required in order to provide the interaction between different DCP nodes? (e.g., for QoS Announce, Request, Response, Query, Status)? >c) How does the DCP node communicate with the enforcement (points)? >d) How does the interaction between DCP and the monitoring entities looks like? >e) Where do the Domain Policies come from? > >For (a) you mention "access to the AAA information". This might be RADIUS or Diameter since this stuff is used today. >For (b) you mention "external protocol/mechanism sends a QoS Query, .... to the DCP" >For (c) you mention COPS, Netconf, SNMP >For (d) you mention "needs access to a wide range of information about the operational conditions of its network." >For (e) you mention "A DCP must either contain these or have access to them, perhaps a combination." > >The draft also talks about other protocols like SIP and NSIS. > >Having briefly looked at these aspects of your draft please explain what you mean by: > >* "... infrastructure that is capable of realizing services on an IP network before we worry overly much about what is being sent." > >* "Particularly since signaling is not required for all services." > >(Note that the term 'service' is not really well defined in the IETF nor in any other organization.) > >* "It seems > > >>to be all about signaling. In my opinion, this has been a big >>problem in the QoS area in general and particularly at the IETF. >>That is, spending time talking about what information is going to >>be sent around and in what sort of containers rather than how to >>manage and control IP differentiated services." >> >> > >If you do not have these protocols and if you don't worry about the content that is sent around (with the associated semantic) then it might be a 'little bit difficult' to dynamically manage and control QoS. > >What term do you use for this dynamic information exchange? > >Ciao >Hannes > > > >>-----Ursprüngliche Nachricht----- >>Von: Kathleen Nichols [mailto:nichols@pollere.com] >>Gesendet: Donnerstag, 9. März 2006 16:56 >>An: Tschofenig, Hannes; dcpel@ietf.org >>Betreff: Re: AW: [Dcpel] FWD: [Re: proposed charter] >> >> >>So, I really must reply, in brief, to Hannes's email. It seems >>to be all about signaling. In my opinion, this has been a big >>problem in the QoS area in general and particularly at the IETF. >>That is, spending time talking about what information is going to >>be sent around and in what sort of containers rather than how to >>manage and control IP differentiated services. If the right >>information is being sent, then a useful control and management >>structure should be able to use it. But it seems like we need to >>have an infrastructure that is capable of realizing services on >>an IP network before we worry overly much about what is being >>sent. Particularly since signaling is not required for all >>services. >> >> Kathie >> >>_______________________________________________ >>Dcpel mailing list >>Dcpel@ietf.org >>https://www1.ietf.org/mailman/listinfo/dcpel >> >> >> > >_______________________________________________ >Dcpel mailing list >Dcpel@ietf.org >https://www1.ietf.org/mailman/listinfo/dcpel > > > _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel From dcpel-bounces@ietf.org Mon Mar 13 05:01:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIjrZ-0007fZ-JK; Mon, 13 Mar 2006 05:01:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIjrY-0007fL-GZ for dcpel@ietf.org; Mon, 13 Mar 2006 05:01:16 -0500 Received: from deprox.docomolab-euro.com ([212.119.9.186]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FIjrX-0008IR-SR for dcpel@ietf.org; Mon, 13 Mar 2006 05:01:16 -0500 Received: from 172.27.10.3 by deprox.docomolab-euro.com (InterScan E-Mail VirusWall NT); Mon, 13 Mar 2006 11:01:12 +0100 Received: from [172.27.100.57] ([172.27.100.57]) by deex.docomolab-euro.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 13 Mar 2006 11:01:11 +0100 Message-ID: <441542F6.9050909@docomolab-euro.com> Date: Mon, 13 Mar 2006 11:01:26 +0100 From: Paulo Mendes User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: LEVIS Pierre RD-CORE-CAE Subject: Re: [Dcpel] DCPEL BoF support References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 13 Mar 2006 10:01:11.0991 (UTC) FILETIME=[0ED28470:01C64685] X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 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: , Errors-To: dcpel-bounces@ietf.org Hi Pierre, I agree with you. Actually the current I-D on DCPEL requirements brings the same view on PDB - SLS relationship when it say: - "The inter-domain interface should be independent from the specifics of the intra-domain control plane." - "Packets should be re-marked from the internal PDB identifier to the inter-domain SLS identifier if needed." Paulo LEVIS Pierre RD-CORE-CAE wrote: >Hi all, > >As the author of draft-meta-qos-class-00.txt stated by Olivier, I would like to provide somm complement to back Olivier's proposal. >IMHO QoS SLS between Autonomous Systems (if we take AS as the basic interdomain element) doesn't really care about PDB. >A PDP is a way, I would say the Diffserv way, to enforce a QoS level target inside a single domain. It is closely related to a PHB or set of PHBs. >Suppose now, I'm an ISP, with a tremendously over-provisioned best-effort network. >Despite best-effort only, I can gaurantee strong QoS. >My neighbouring domains won't decline my offer just because my only PDB is best-effort, they are interested in the level of QoS I can provide, and not in the way I have engineered my network. >Furthermore I, as an ISP, would not disclose my internal network setting. So, for interdomain QoS negotiations we need a notion, an external view, decorrelated from any type of physical realisation, simply to capture the available level of QoS. >It is where Meta-QoS-Class applies. Note that I've sent directly my draft to the RFC Editor because there was no WG, at that time, to host this work, so the draft is in the RFC Editor queue, the intended status is Informational RFC. >This work is the outcome of the MESCAL European project, follow-up of the TEQUILA project well known for its proposal on SLS format. > >Regards, > >Pierre > >-----Message d'origine----- >De : DUGEON Olivier RD-CORE [mailto:olivier.dugeon@francetelecom.com] >Envoyé : jeudi 9 mars 2006 19:21 >À : Paulo Mendes >Cc : dcpel@ietf.org >Objet : Re: [Dcpel] DCPEL BoF support > >Hi Paulo and Kathie, > >Paulo Mendes a écrit : > > >>Hi Olivier, >> >>see my comments inline. >> >>Olivier Dugeon wrote: >> >> >> >>>Hello Kathleen and all, >>> >>>We are in favor of a such BoF. Again, I'll ask my colleagues whom >>>attend the next IETF meeting to be present during the DCPEL BoF >>>session regarding their respective constraint to follow their >>>respective WG. >>> >>>Concerning the charter, I just want to know if the points described >>>below could be present: >>> >>>- Study and define a global framework and architecture which take >>>into account the inter-domain control plane and not only the >>>intra-domain >>> >>> >>[Paulo] The definition of a overall architecture is already scheduled >>in the current proposed charter. And the current version of the DCPEL >>requirements I-D, already mention the the Diffserv control plane, >>should consider the inter-domain relationship besides the intra-domain >>control. The creation of an I-D on interworking between DiffServ >>domains is also planned in the charter proposal. >> >> >[OD] Ok. > > >>>- Produce RFC about the end to end CoS definition i.e. by extending >>>the notion of Per Domain Behavior to the inter domain. The draft >>>about Meta-CoS class from Pierre Levis could be a starting point >>> >>> >>[Paulo] The e2e definition of CoS should be discussed. IMO, it is most >>helpful if we keep the intra-domain mechanisms and PDBs transparent to >>the inter-domain operations, and so e2e. So, I would say that the >>definition of e2e CoS is related to the use of the inter-domain >>service information model, and not the to PDBs to be used within a >>network. The relationship between PDBs and services (SLSs) is >>something to be worked out within DCPEL. >> >> >[OD] Ok. In fact I just want to make an analogy to the PDB. IMHO, I think we need to study, effectively in the scope of e2e, an equivalent of the PDB for the inter-domain aka Inter-Domain Behavior (IDB). Is why I'm referring to the work done by Pierre Levis about the Meta-CoS Class. >Without a such IDB, we can't define the behavior of the DCP for the inter-domain. > > >>>- Produce RFC which define both data and interface to request CoS to >>>the DCPEL framework from and application i.e. SLS definition in term >>>of parameters, function and transport prootocol >>> >>> >>[Paulo] The first issue of an I-D on DCP service information model is >>schedule for November 2006, while the interworking of a DCP network >>with external mechanisms will be analyzed in the framework I-D. >> >> >[OD]. Ok, it make sense to start with the framework and the architecture and then goes into the detail like the service information model. > > >>>- Produce RFC on topology acquisition to let the Control Plane in >>>touch (synchronize) with the Transfert Plane >>> >>> >>[Paulo] This is a topic related to a centralized control plane. Since >>the DCPEL requirements I-D mention the possible centralized and >>distributed control of PDBs, and assuming that this proposal will be >>accepted, I'm expecting some I-D proposals for DCP centralized >>mechanisms and distributed mechanisms (December 2006 in the current >>charter proposal). It is up to the authors of the centralized >>proposals to refer to describe mechanisms for the acquisition of >>topology information. >> >> >[OD]. I'm not explicitly refer to a full centralized mode. In fact, I think we need to clarify what we intend by centralized vs. distributed. >For the distributed point of view, I'm not sure that it is pertinent to refer to a full distributed mode where all DCP agent are place in each router/device and are aware of the topology since there are on the data path. This mode is too close to a signaling approach and certainly be in conflict with NSIS. IMHO, is certainly why NSIS peoples will see some overlapping with this BoF. At the opposite, a fully centralized mode is certainly not scalable for big network. > >IMHO, the DCPEL WG could focus on a semi distributed mode. In this case, a DCP agent will control a given set of routers/devices and are out of the data-path. So, in this case a simple but efficient topology acquisition tools is mandatory to automatically discover and maintain the part of the network the DCP agent control. Typically, this is correspond to an area or sub area of a routing protocol. The communication between DCP agent is more or less the same even if the 2 DCP agents are not part of the same AS i.e intra and inter domain communication is more or less the same. > > >>>- Produce RFC on which protocol will fit requirement to exchange >>>inter-DCPEL SLS i.e. looking how NSIS could fit or be extended to >>>this purpose. >>> >>> >>[Paulo] This is contemplated in the I-D on interworking between >>DiffServ domain (scheduled March 2007 in the current charter). It is >>expectable that we'll be able to discuss different approaches to allow >>the interworking of DiffServ domains, based for instance on NSIS, SIP, >>or other protocol model. >> >> >[OD] Ok. But I'm not in favor of using SIP. Using SIP will lead the e2e CoS decision at the service plane level which, IMHO, is not a good solution. I understand the argument in favor of this. All operator through the IMS concept thinks that the e2e will be assured by IMS interconnection. The main problem come from the fact that 2 IMS could not necessary be directly interconnect. The connection could traverse one or more AS and completely escape to the IMS signaling. In this case, DCP take all its sense since it see all the AS between 2 IMS. Another reason is that the NGN stratum separation is not respected. In order to efficiently select the best AS path, the IMS, at service level, need information which come from the control and transfer levels. > > >>>- Produce RFC on which protocol will fit requirement to enforce QoS >>>in the underlying network i.e lookink to COPS and NetConf to see how >>>it could be used >>> >>> >>[Paulo] This is also mostly specific to centralized control approaches. >> >> >[OD]. See point above. A semi-distributed approach need them also. > >Regards, > >Olivier > > >>Cheers >>Paulo >> >> >> >>>Please, don't hesitate to comment. >>> >>>Regards, >>> >>>Olivier >>> >>>PS. I will be out of my office next week and have sporadic access to >>>my e-mail >>> >>> >>> >>> >> >> > >-- >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 Mon Mar 13 06:06:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIksH-0007oy-Di; Mon, 13 Mar 2006 06:06:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIksG-0007ot-C5 for dcpel@ietf.org; Mon, 13 Mar 2006 06:06:04 -0500 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIksE-0002B5-VV for dcpel@ietf.org; Mon, 13 Mar 2006 06:06:04 -0500 Received: from mail1.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k2DB61P8030271; Mon, 13 Mar 2006 12:06:01 +0100 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k2DB61AY007555; Mon, 13 Mar 2006 12:06:01 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Mar 2006 12:06:00 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: AW: AW: [Dcpel] FWD: [Re: proposed charter] Date: Mon, 13 Mar 2006 12:01:23 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [Dcpel] FWD: [Re: proposed charter] thread-index: AcZDp87b+JyV3icOQXe4DjZg8NWA2wC39rUg From: "Tschofenig, Hannes" To: "Olivier Dugeon" X-OriginalArrivalTime: 13 Mar 2006 11:06:00.0598 (UTC) FILETIME=[1C9CDB60:01C6468E] X-Spam-Score: 0.1 (/) X-Scan-Signature: 285c5d2442d4c903d8dda55de04f5334 Cc: dcpel@ietf.org, Michel Diaz 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="===============1357435533==" Errors-To: dcpel-bounces@ietf.org This is a multi-part message in MIME format. --===============1357435533== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6468E.1C2890C5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6468E.1C2890C5 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Olivier,=20 =20 Hello Hannes, Thanks to your pointer. I remember at the beginning of NSIS WG the great debate about on-path = vs. off-path. The conclusion have been to choose to study only on-path = within NSIS. In parallel, a BoF was setup to attempt to create an = off-path WG. Unfortunately this was cancel too. NSIS was always chartered with a focus on path-coupled signaling in = mind.=20 Still, there was a lot of interest on transition scenarios that require = some path-decoupled processing. In some sense, this is almost a = philosophical discussion.=20 =20 For example, is RFC 2749 (about COPS and RSVP interaction) = off-path/path-decoupled signaling? What about RFC 3084?=20 =20 Unfortunately, the term "off-path" is a little bit overloaded and means = different things to different people (like the term 'NGN' is heavily = overloaded as well). This caused a lot of confusion. If there is = confusion then it is, in general, quite good to think about it a little = bit longer.=20 That's what we did.=20 So, I'm surprise and the same time happy to see that NSIS will again = start studying off-path or try to attempt a BoF. =20 =20 Don't be surprised. These aspects have been topic for many, many = discussions in the past.=20 In my opinion, DCPEL and off-path NSIS have more or less the same = objective looking at 2 different approaches. Perhaps a good deal will to = merge the 2 initiatives to form a larger and greater consensus.=20 =20 Why do you think that they look at two different approaches? =20 In the same time, some ideas from EuQoS project = (http://www.ietf.org/internet-drafts/draft-cordeiro-nsis-hypath-00.txt = = ) have been submit to the NSIS WG about a such approach (in fact, we = used NSIS for our Resource Manager communication).=20 =20 We have been in contact with the authors based on the NSIS interim = meeting in May 2005 and the interop in Paris a few months later.=20 It is very interesting to see this type of input.=20 =20 =20 Ciao Hannes =20 Regards, Olivier Tschofenig, Hannes a =E9crit :=20 Hi Olivier,=20 Hi David,=20 =09 I agree with David that there is essentially a lot of protocol work = (hopefully "only" extensions) that seems to be envisioned by DCPEL. A = few weeks ago Georgios has sent a mail asking for the relationship = between the IETF work and other QoS work that is currently being done = outside the IETF. There are many proposals being made today that need to = be considered. These organizations are, for various reasons, really = crazy about QoS and QoS signaling. As I noted at the last IETF meeting I = think that the best place for these discussions is the Transport Area = where this type of protocol discussions already happened in the past.=20 =09 The IETF NSIS work has discussed various aspects of path-decoupled = signaling approaches in the past and there are still proposals floating = around. You might be interesting to see that there will be a discussion = about this subject at the next IETF meeting. See = http://www1.ietf.org/mail-archive/web/nsis/current/msg06007.html It = might be interesting for you to attend the NSIS WG session to share your = thoughts with other QoS minded people. Furthermore, a number of us have = been in contact with the ITU-T (and the ITU-T liaison person from the = ITU-T side, Hui-Lan Lu, in particular), including John Loughney and = myself, to discuss how their requirements can be brought to the = IETF/NSIS working group to have a fruitful discussion.=20 =09 Ciao Hannes =09 =20 Hello David, =09 Here it is some comments from an operator (ok R&D part only) !!! =09 David Kessens a =E9crit : =20 Kathie asked me whether I would be willing to share the=20 =20 following mail =20 with the group on my current thinking regarding a bof for dcepl. =09 I obviously have no problem with that so please see below=20 =20 for my mail =20 to Kathie regarding this topic. I, and the other ADs CC'ed on this mail, are interested in your comments. =09 I hope this helps, =09 David Kessens --- =09 ----- Forwarded message from David Kessens=20 =20 ----- =20 Date: Mon, 6 Mar 2006 20:58:32 -0800 From: David Kessens = =20 To: Kathleen Nichols = =20 Subject: Re: proposed charter =09 =09 Kathie, =09 On Wed, Feb 22, 2006 at 10:51:34AM -0800, Kathleen Nichols wrote: =20 =20 Attached is a draft charter. Scott and Paulo haven't had a chance to weigh in on it, so I might get some good input there. I would hope to have better milestones after an organizational meeting or BoF. =20 =20 I am sorry for the delay in my response. We normally spend some time to do an internal review with the IAB and IESG and I was waiting for Allison who promised comments. =09 I am sympathic to the goals of this proposed work and I=20 =20 have received =20 various comments from the IAB stating so. =09 However, I also received comments that this work could be=20 =20 conflicting =20 with existing IETF work in the NSIS and TSV working group. =09 While the proposed charter doesn't necessarily would=20 =20 require protocol =20 work, the drafts that I read would more or less require this. As you know, the Ops part of the Ops&Mgmt area usually doesn't do protocol work and limits itself to issues that are relevant to the operations =20 =20 I'm agree with your remarks. But, IMHO, the DCPEL WG have to=20 deal with=20 protocol: Not produce new protocol, but adapt or suggest=20 modifications=20 to relevant WG. For exemple, DCPA inter-domain communication=20 could use=20 NSIS. But, since NSIS have not yet design for this, it certainly need = some modifications or, at least, to setup a new NSLP stack=20 liek QoS-NSLP=20 (thanks to the 2 layers signalling of NSIS which could facilitate the = work). Another example concern the SLS interface aka the interface=20 between service and DCPEL. Again, some stuff are usable like=20 SIP, XML,=20 ... but need some adaptation to carry properly the SLS from=20 the service=20 to the DCPEL. =20 of the Internet. In addition, to make sure that things are relevant for operators, we normally want to have feedback, support and involvement from operators to avoid situations where=20 =20 vendors build all =20 kind of complex solutions for problems that operators don't have. =09 So far, I have seen some support from academia, research efforts within larger corporations and some vendors, but I have seen little evidence that this group is going to solve a problem that operators want to be solved. As I already mentioned in an earlier mail, I am really somewhat surprised that I haven't seen any operator=20 =20 on the list =20 commenting that we need to start this work as I did expect=20 =20 that myself. =20 =20 =20 Sorry to contradict you, but, if you look carefully at the=20 mailing list,=20 you could see that I support DCPEL initiative from the beginning=20 (10/14/2005). During the last IETF meeting, FTR&D support this work=20 during the OPS AREA meeting. In the same time, through the=20 European IST=20 projet EuQoS, I request support from other operator like TID=20 (Telefonica=20 I+D). Generally speaking, in Europe, most of the operator are=20 search for=20 such functionalities. Look to the work done in other fora such as=20 ETSI/TISPAN, ITU-NGN-FG and now Q4/13 or more recently to the=20 DSL Forum.=20 In fact, IETF is the only place where QoS control, and in particular=20 resource control, are not study in the scope proposed by the DCEPL=20 initiative. =20 Considering these issues, I think that it probably is not=20 =20 in your best =20 interest to pursue a bof for this IETF. =09 We will first need a much clearer answer on what problem is going to be solved *for operators*, get real support from operators=20 =20 behind this =20 effort and after that we need to figure out whether that=20 =20 solution will =20 involve protocol work or not. =20 =20 I could discuss this directly by phone as I'm not agree with=20 you. But,=20 operator need and want a global solution to setup and=20 exchange QoS. If=20 you just look at the VoIP service, inter-domain correspond to the=20 "international" part of the traditional PSTN. For the moment,=20 only study=20 are conduct to the access network. But, it is not sufficient. For the = moment, people think that over-provisioning will solve this=20 issue. This=20 is true for the bandwidth, but not for the other QoS=20 parameters such as=20 jitter, delay, loss ... However, VoIP services are vey=20 sensible to the=20 jitter and the delay. Without inter-domain and global QoS=20 solution, it=20 could not be possible to deploy a global VoIP QoS solution.=20 In the same=20 way, all multi-media service (IP TV, VoD, ...) need also QoS control. = Adopting a signaling like NSIS is certainly a great solution,=20 but which=20 will be deploy not before 5 or 10 years due to the time scale=20 operator=20 renew their transfer plane equipments. At the opposite, a=20 control plane=20 such as DCPEL propose, could be deploy very quickly without changing=20 their transfer plane. =09 Today, operator are in a such situation that there is some industrial = solution on the market, but no standard to compare them or inter-oper = without development or major adaptation. =09 Finally, ITU and ETSI will finalize first standard of the=20 RACF function,=20 but too much dedicated to conversational service. IMHO, it is=20 really a=20 mess that IETF will not conduct study on diffserv control plane. =20 You can probably convince me to hold a bof anyways but considering the above stumbling blocks, I would advise you not to do so. =20 =20 I'm agree that the charter need more clarification and scope=20 need more=20 focus. But, this is a very complex subject. All peoples with whom I=20 discussed about this, have a different opinion on the technical=20 solution, but all are agree to said that we need a solution. =09 Best regards, =09 Olivier Dugeon =20 David Kessens --- =09 _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel =09 =20 =20 --=20 Project Manager for Network architecture and switching Division & FT/DR&D/CORE/M2I |=20 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 =09 =09 =09 _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel =09 =20 =09 =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 ------_=_NextPart_001_01C6468E.1C2890C5 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Olivier,
 
Hello = Hannes,

Thanks to=20 your pointer.

I remember at the beginning of NSIS WG the great = debate=20 about on-path vs. off-path. The conclusion have been to choose to study = only=20 on-path within NSIS. In parallel, a BoF was setup to attempt to create = an=20 off-path WG. Unfortunately this was cancel too.
NSIS was always = chartered with=20 a focus on path-coupled signaling in=20 mind. 
Still, there was a lot = of interest=20 on transition scenarios that require some path-decoupled=20 processing. In some sense, this is almost a philosophical = discussion.=20
 
For example, is = RFC=20 2749 (about COPS and RSVP interaction) off-path/path-decoupled = signaling?=20 What about RFC 3084?
 
Unfortunately, the term = "off-path"=20 is a little bit overloaded and means different things to = different=20 people (like the term 'NGN' is heavily overloaded as well).=20 This caused a lot of confusion. If there is = confusion then=20 it is, in general, quite good to think about it a little bit longer.=20
That's what we did. =

So, I'm surprise and the = same time=20 happy to see that NSIS will again start studying off-path or try to = attempt a=20 BoF.  
 
Don't be = surprised. These=20 aspects have been topic for many, many discussions in the past.=20

In my opinion, DCPEL and off-path NSIS have more = or less=20 the same objective looking at 2 different approaches. Perhaps a good = deal will=20 to merge the 2 initiatives to form a larger and greater consensus. 
 
Why do you think that = they look at=20 two different approaches?
 

In the same time, some = ideas from=20 EuQoS project (http://www.ietf.org/internet-drafts/draft-cordeiro-nsis-hypath-0= 0.txt) have been submit to the NSIS WG about a such = approach (in=20 fact, we used NSIS for our Resource Manager communication). 
 
We have been in contact = with the=20 authors based on the NSIS interim meeting in May 2005 and the = interop=20 in Paris a few months later. 
It is very interesting = to see this=20 type of input. 
 
 
Ciao
Hannes
 
Regards,

Olivier

Tschofenig,=20 Hannes a =E9crit : 
Hi Olivier,=20
Hi David,=20

I agree with David that there is essentially a lot of protocol work =
(hopefully "only" extensions) that seems to be envisioned by DCPEL. A =
few weeks ago Georgios has sent a mail asking for the relationship =
between the IETF work and other QoS work that is currently being done =
outside the IETF. There are many proposals being made today that need to =
be considered. These organizations are, for various reasons, really =
crazy about QoS and QoS signaling. As I noted at the last IETF meeting I =
think that the best place for these discussions is the Transport Area =
where this type of protocol discussions already happened in the past.=20

The IETF NSIS work has discussed various aspects of path-decoupled =
signaling approaches in the past and there are still proposals floating =
around. You might be interesting to see that there will be a discussion =
about this subject at the next IETF meeting. See http://www1.ietf.org/mail-archive/web/nsis/current/msg06007.html It =
might be interesting for you to attend the NSIS WG session to share your =
thoughts with other QoS minded people. Furthermore, a number of us have =
been in contact with the ITU-T (and the ITU-T liaison person from the =
ITU-T side, Hui-Lan Lu, in particular), including John Loughney and =
myself, to discuss how their requirements can be brought to the =
IETF/NSIS working group to have a fruitful discussion.=20

Ciao
Hannes

  
Hello David,

Here it is some comments from an operator (ok R&D part only)  !!!

David Kessens a =E9crit :
    
Kathie asked me whether I =
would be willing to share the=20
      
following mail
    
with the group on my =
current thinking regarding a bof for dcepl.

I obviously have no problem with that so please see below=20
      
for my mail
    
to Kathie regarding this =
topic. I, and the other ADs CC'ed on this
mail, are interested in your comments.

I hope this helps,

David Kessens
---

----- Forwarded message from David Kessens=20
      
<david.kessens@nokia.com> -----
    
Date: Mon, 6 Mar 2006 =
20:58:32 -0800
From: David Kessens <david.kessens@nokia.com>
To: Kathleen Nichols <nichols@pollere.com>
Subject: Re: proposed charter


Kathie,

On Wed, Feb 22, 2006 at 10:51:34AM -0800, Kathleen Nichols wrote:
 =20
      
Attached is a draft =
charter. Scott and Paulo haven't had a
chance to weigh in on it, so I might get some good input
there. I would hope to have better milestones after an
organizational meeting or BoF.
   =20
        
I am sorry for the delay in my =
response. We normally spend some time
to do an internal review with the IAB and IESG and I was waiting for
Allison who promised comments.

I am sympathic to the goals of this proposed work and I=20
      
have received
    
various comments from the =
IAB stating so.

However, I also received comments that this work could be=20
      
conflicting
    
with existing IETF work =
in the NSIS and TSV working group.

While the proposed charter doesn't necessarily would=20
      
require protocol
    
work, the drafts that I =
read would more or less require this. As you
know, the Ops part of the Ops&Mgmt area usually doesn't do protocol
work and limits itself to issues that are relevant to the operations
 =20
      
I'm agree with your remarks. =
But, IMHO, the DCPEL WG have to=20
deal with=20
protocol: Not produce new protocol, but adapt or suggest=20
modifications=20
to relevant WG. For exemple, DCPA inter-domain communication=20
could use=20
NSIS. But, since NSIS have not yet design for this, it certainly need=20
some modifications or, at least, to setup a new NSLP stack=20
liek QoS-NSLP=20
(thanks to the 2 layers signalling of NSIS which could facilitate the=20
work). Another example concern the SLS interface aka the interface=20
between service and DCPEL. Again, some stuff are usable like=20
SIP, XML,=20
... but need some adaptation to carry properly the SLS from=20
the service=20
to the DCPEL.
    
of the Internet. In =
addition, to make sure that things are relevant
for operators, we normally want to have feedback, support and
involvement from operators to avoid situations where=20
      
vendors build all
    
kind of complex solutions =
for problems that operators don't have.

So far, I have seen some support from academia, research efforts
within larger corporations and some vendors, but I have seen little
evidence that this group is going to solve a problem that operators
want to be solved. As I already mentioned in an earlier mail, I am
really somewhat surprised that I haven't seen any operator=20
      
on the list
    
commenting that we need =
to start this work as I did expect=20
      
that myself.
    
 =20
      
Sorry to contradict you, but, if =
you look carefully at the=20
mailing list,=20
you could see that I support DCPEL initiative from the beginning=20
(10/14/2005). During the last IETF meeting, FTR&D support this work=20
during the OPS AREA meeting. In the same time, through the=20
European IST=20
projet EuQoS, I request support from other operator like TID=20
(Telefonica=20
I+D). Generally speaking, in Europe, most of the operator are=20
search for=20
such functionalities. Look to the work done in other fora such as=20
ETSI/TISPAN, ITU-NGN-FG and now Q4/13 or more recently to the=20
DSL Forum.=20
In fact, IETF is the only place where QoS control, and in particular=20
resource control, are not study in the scope proposed by the DCEPL=20
initiative.
    
Considering these issues, =
I think that it probably is not=20
      
in your best
    
interest to pursue a bof =
for this IETF.

We will first need a much clearer answer on what problem is going to
be solved *for operators*, get real support from operators=20
      
behind this
    
effort and after that we =
need to figure out whether that=20
      
solution will
    
involve protocol work or =
not.
 =20
      
I could discuss this directly by =
phone as I'm not agree with=20
you. But,=20
operator need and want a global solution to setup and=20
exchange QoS. If=20
you just look at the VoIP service, inter-domain correspond to the=20
"international" part of the traditional PSTN. For the moment,=20
only study=20
are conduct to the access network. But, it is not sufficient. For the=20
moment, people think that over-provisioning will solve this=20
issue. This=20
is true for the bandwidth, but not for the other QoS=20
parameters such as=20
jitter, delay, loss ... However, VoIP services are vey=20
sensible to the=20
jitter and the delay. Without inter-domain and global QoS=20
solution, it=20
could not be possible to deploy a global VoIP QoS solution.=20
In the same=20
way, all multi-media service (IP TV, VoD, ...) need also QoS control.=20
Adopting a signaling like NSIS is certainly a great solution,=20
but which=20
will be deploy not before 5 or 10 years due to the time scale=20
operator=20
renew their transfer plane equipments. At the opposite, a=20
control plane=20
such as DCPEL propose, could be deploy very quickly without changing=20
their transfer plane.

Today, operator are in a such situation that there is some industrial=20
solution on the market, but no standard to compare them or inter-oper=20
without development or major adaptation.

Finally, ITU and ETSI will finalize first standard of the=20
RACF function,=20
but too much dedicated to conversational service. IMHO, it is=20
really a=20
mess that IETF will not conduct study on diffserv control plane.
    
You can probably convince =
me to hold a bof anyways but considering
the above stumbling blocks, I would advise you not to do so.
 =20
      
I'm agree that the charter need =
more clarification and scope=20
need more=20
focus. But, this is a very complex subject. All peoples with whom I=20
discussed about this, have a different opinion on the technical=20
solution, but all are agree to said that we need a solution.

Best regards,

Olivier Dugeon
    
David Kessens
---

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

 =20
      
--=20
Project Manager for Network architecture and switching Division
 & FT/DR&D/CORE/M2I           |=20
mailto:Olivier.Dugeon@fr=
ancetelecom.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.o=
rg/mailman/listinfo/dcpel

    

  

--=20
Project Manager for Network architecture and switching Division
 & FT/DR&D/CORE/M2I           | mailto:Olivier.Dugeon@fr=
ancetelecom.com
 2, Avenue Pierre Marzin      | Phone/Fax:  +(33) 296 05 2880/1470
 F-22307 LANNION              | Mobile:     +(33) 6 82 90 37 85
------_=_NextPart_001_01C6468E.1C2890C5-- --===============1357435533== 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 --===============1357435533==-- From dcpel-bounces@ietf.org Mon Mar 13 08:49:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FInQ3-0004ib-Js; Mon, 13 Mar 2006 08:49:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FInOh-0003DE-U2 for dcpel@ietf.org; Mon, 13 Mar 2006 08:47:43 -0500 Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FInF4-0006hx-LL for dcpel@ietf.org; Mon, 13 Mar 2006 08:37:47 -0500 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id k2DDbXti020260; Mon, 13 Mar 2006 13:37:33 GMT 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: [Dcpel] FWD: [Re: proposed charter] Date: Mon, 13 Mar 2006 13:37:33 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [Dcpel] FWD: [Re: proposed charter] Thread-Index: AcZGhOzFdqiaXzGTR1647i5hlo+y6AAHFoBA From: "Hancock, Robert" To: "Paulo Mendes" , X-MailScanner-rsys001x: Found to be clean X-MailScanner-rsys001x-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 680445c3afe8c9e96925f2dfef141924 Cc: "Tschofenig, Hannes" 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: , Errors-To: dcpel-bounces@ietf.org Paulo, Kathie, specifically on the protocols question, it strikes me that there are two = issues here: 1) in defining the scope of a proposed WG, it seems that it would be = necessary to pin down more precisely the scope of any protocol work = before the WG can be formed. (Is this a correct interpretation of the AD = comments?) Is this going to be impossible? In the case of NSIS, the WG = was *initially* chartered *only* to answer the question of what needed = to be done compared to existing protocols and not do any new protocol = work; maybe the same approach would work here. 2) with respect to the specific question of the inter-domain protocol, I = think there would have to be really good arguments to justify anything = beyond extensions to existing protocols, and so far I've not seen = anything that would require any extensions at all for the case where the = flows/aggregates follow well defined network paths. (This may or may not = be the full scope of DCPEL. If the aggregate path is not well defined = then the signalling problem becomes harder and more work may be needed.) r. > -----Original Message----- > From: Paulo Mendes [mailto:mendes@docomolab-euro.com]=20 > Sent: 13 March 2006 09:58 > To: Tschofenig, Hannes; David Kessens > Cc: dcpel@ietf.org; Olivier Dugeon > Subject: Re: AW: [Dcpel] FWD: [Re: proposed charter] >=20 >=20 > Hi David, Hannes, and all >=20 > Here is my view about the need of DCPEL for operators and about DCPEL=20 > relationship with NSIS, as I see it. >=20 > I would like to stress we have been receiving support from operators=20 > since the beginning. Not only from NTT DoCoMo: I'm been helping to=20 > develop DCPEL since the beginning, and although NTT DoCoMo=20 > Euro-Labs is=20 > a research institution I gain the support of the Japanese development=20 > department since January. To NTT DoCoMo we can add France Telecom and=20 > Telefonia, as mentioned by Olivier. I would like to mention that the=20 > involvement of these operators in DCPEL follows their work on similar=20 > topics in other fora and research projects as mentioned by Olivier. >=20 > Being even more pragmatic about the operators' need for a=20 > good solution=20 > to control and manage a DiffServ network, I would like to say=20 > that the=20 > need for such solution in increasing from DoCoMo side. We are=20 > looking at=20 > several possible solutions to control QoS in an all IP=20 > network. So, we=20 > are looking at work being done at 3GPP for instance. But we=20 > think that=20 > DiffServ may be a better solution for the future. The only=20 > problem (big=20 > one) is that there is no standard way to control and manage a=20 > DiffServ=20 > network. This is what DoCoMo wants: a standards set of=20 > procedures, PDBs=20 > for well-know traffic (voip, IPTV, video-streaming, ...), and set of=20 > protocols that together will allow us to control a future=20 > DiffServ network. >=20 > So DCPEL aims to focus on how to operate a DiffServ network: > - draft-chan-tsvwg-diffserv-class-aggr-03 (discussion of which fits=20 > DCPEL, IMO) provides guidelines of how multiple service=20 > classes may be=20 > aggregated into a forwarding treatment aggregate. > - Independently from the fact that we need or not all the types of=20 > traffic aggregates enumerated in=20 > draft-chan-tsvwg-diffserv-class-aggr-03, we need to know how to make=20 > them real. > - DCPEL is focusing on this goal. There is no work in IETF for: > i) Define the PDBs to manage the traffic types discussed in=20 > draft-chan-tsvwg-diffserv-class-aggr-03 (the authors discuss=20 > a possible=20 > control based on MPLS). > ii) Analyze what type of signaling is most suitable, and how=20 > different protocols may be combined. > iii) Make ii) work for intra-domain management and combine it with=20 > inter-domain control. >=20 > The interaction with NSIS fits in the analysis of current signaling=20 > protocols and how suitable they are to help in the control of=20 > a DiffServ=20 > network. This is, to be able to control QoS in real networks,=20 > we need a=20 > little more than defining signaling protocols. Currently, we=20 > have a very=20 > good number of protocols available in IETF, but we need to=20 > know how to=20 > use them and how to inter-operate them. For instance, it may=20 > be clear,=20 > based on the specification of DiffServ control elements that=20 > QoS-NSLP is=20 > the best option for intra-domain control. Or we may conclude that=20 > QoS-NSLP may need to be adapted. In the later case, the adaptation is=20 > analyzed in DCPEL (focusing on DiffServ control) and is specified in=20 > NSIS (focused on protocol specification). At least in some=20 > projects, I=20 > had some discussions about the current difficulty of standardizing a=20 > control mechanism in NSIS, since NSIS is only interested in the=20 > signaling part, while the mentioned mechanism may involve=20 > more that that=20 > (admission control, network monitoring, control of SLS, etc, etc). >=20 > As an example, I can indicate some work being presented in NSIS that,=20 > IMO, is more suitable to be discussed in DCPEL: RMD -=20 > draft-ietf-nsis-rmd-06. RMD is not specifying any new NSLP,=20 > although it=20 > may have consequences in NSIS, if RMD needs some extensions=20 > or options=20 > for QoS-NSLP. RMD is more focus on the admission control and=20 > controlof=20 > congestion in Diffserv networks, being the signaling done=20 > with QoS-NSLP. >=20 > IMO, it may be a hard job for NSIS to try to specify every=20 > possible NSLP=20 > on top of GIST. It would be better if NSIS provides the service level=20 > protocols that are required by other WG (namely the ones=20 > analysing the=20 > operation of IP networks), and not to specify any protocol that fits=20 > nicely on top of GIST. >=20 > To terminate, an example (just an raw example, without any discussion=20 > until now :) ) of a possible interaction of DCPEL and NSIS: > i) The control of some PDBs requires the use of QoS-NSLP=20 > edge-to-edge,=20 > but combined with COPS (for signaling between edges and an=20 > inter-domain=20 > QoS controller, from a set of possible controllers) and SIP (for=20 > signaling between terminal and network). The specification of this=20 > management operation is in the scope of DCPEL. NSIS contributes with=20 > QoS-NSLP. > ii) Same scenario as in i) but QoS-NSLP doesn't fit=20 > perfectly. In this=20 > case DCPEL will analyse the needed requirements to extend=20 > QoS-NSLP. NSIS=20 > should then analyse all the details to include these extra=20 > requirements=20 > in the current draft. > iii) QoS-NSLP doesn't fit at all in some scenarios, such as=20 > inter-domain, where a path-decoupled solution is better. Some=20 > people is=20 > currently thinking in extending, again, QoS-NSLP for path-decoupled=20 > signaling. But, how can we know that that work will be the=20 > most suitable=20 > for inter-domain DiffServ control? Or, even if it may be=20 > used, different=20 > approaches to path-decoupled signaling, even if based on=20 > NSIS, may also=20 > bring other advantages. This is, it is not because NSIS is going to=20 > 'extend' QoS-NSLP to operate path-decoupled that all DiffServ=20 > inter-domain operation control is solved. Here, I fully agree=20 > with Kathie. >=20 > Cheers > Paulo >=20 > Tschofenig, Hannes wrote: >=20 > >Hi Olivier,=20 > >Hi David,=20 > > > >I agree with David that there is essentially a lot of=20 > protocol work (hopefully "only" extensions) that seems to be=20 > envisioned by DCPEL. A few weeks ago Georgios has sent a mail=20 > asking for the relationship between the IETF work and other=20 > QoS work that is currently being done outside the IETF. There=20 > are many proposals being made today that need to be=20 > considered. These organizations are, for various reasons,=20 > really crazy about QoS and QoS signaling. As I noted at the=20 > last IETF meeting I think that the best place for these=20 > discussions is the Transport Area where this type of protocol=20 > discussions already happened in the past.=20 > > > >The IETF NSIS work has discussed various aspects of=20 > path-decoupled signaling approaches in the past and there are=20 > still proposals floating around. You might be interesting to=20 > see that there will be a discussion about this subject at the=20 > next IETF meeting. See=20 > http://www1.ietf.org/mail-archive/web/nsis/current/msg06007.ht > ml It might be interesting for you to attend the NSIS WG=20 > session to share your thoughts with other QoS minded people.=20 > Furthermore, a number of us have been in contact with the=20 > ITU-T (and the ITU-T liaison person from the ITU-T side,=20 > Hui-Lan Lu, in particular), including John Loughney and=20 > myself, to discuss how their requirements can be brought to=20 > the IETF/NSIS working group to have a fruitful discussion.=20 > > > >Ciao > >Hannes > > > > =20 > > > >>Hello David, > >> > >>Here it is some comments from an operator (ok R&D part only) !!! > >> > >>David Kessens a =E9crit : > >> =20 > >> > >>>Kathie asked me whether I would be willing to share the=20 > >>> =20 > >>> > >>following mail > >> =20 > >> > >>>with the group on my current thinking regarding a bof for dcepl. > >>> > >>>I obviously have no problem with that so please see below=20 > >>> =20 > >>> > >>for my mail > >> =20 > >> > >>>to Kathie regarding this topic. I, and the other ADs CC'ed on this > >>>mail, are interested in your comments. > >>> > >>>I hope this helps, > >>> > >>>David Kessens > >>>--- > >>> > >>>----- Forwarded message from David Kessens=20 > >>> =20 > >>> > >> ----- > >> =20 > >> > >>>Date: Mon, 6 Mar 2006 20:58:32 -0800 > >>>From: David Kessens > >>>To: Kathleen Nichols > >>>Subject: Re: proposed charter > >>> > >>> > >>>Kathie, > >>> > >>>On Wed, Feb 22, 2006 at 10:51:34AM -0800, Kathleen Nichols wrote: > >>> =20 > >>> =20 > >>> > >>>>Attached is a draft charter. Scott and Paulo haven't had a > >>>>chance to weigh in on it, so I might get some good input > >>>>there. I would hope to have better milestones after an > >>>>organizational meeting or BoF. > >>>> =20 > >>>> =20 > >>>> > >>>I am sorry for the delay in my response. We normally spend=20 > some time > >>>to do an internal review with the IAB and IESG and I was=20 > waiting for > >>>Allison who promised comments. > >>> > >>>I am sympathic to the goals of this proposed work and I=20 > >>> =20 > >>> > >>have received > >> =20 > >> > >>>various comments from the IAB stating so. > >>> > >>>However, I also received comments that this work could be=20 > >>> =20 > >>> > >>conflicting > >> =20 > >> > >>>with existing IETF work in the NSIS and TSV working group. > >>> > >>>While the proposed charter doesn't necessarily would=20 > >>> =20 > >>> > >>require protocol > >> =20 > >> > >>>work, the drafts that I read would more or less require=20 > this. As you > >>>know, the Ops part of the Ops&Mgmt area usually doesn't do protocol > >>>work and limits itself to issues that are relevant to the=20 > operations > >>> =20 > >>> =20 > >>> > >>I'm agree with your remarks. But, IMHO, the DCPEL WG have to=20 > >>deal with=20 > >>protocol: Not produce new protocol, but adapt or suggest=20 > >>modifications=20 > >>to relevant WG. For exemple, DCPA inter-domain communication=20 > >>could use=20 > >>NSIS. But, since NSIS have not yet design for this, it=20 > certainly need=20 > >>some modifications or, at least, to setup a new NSLP stack=20 > >>liek QoS-NSLP=20 > >>(thanks to the 2 layers signalling of NSIS which could=20 > facilitate the=20 > >>work). Another example concern the SLS interface aka the interface=20 > >>between service and DCPEL. Again, some stuff are usable like=20 > >>SIP, XML,=20 > >>... but need some adaptation to carry properly the SLS from=20 > >>the service=20 > >>to the DCPEL. > >> =20 > >> > >>>of the Internet. In addition, to make sure that things are relevant > >>>for operators, we normally want to have feedback, support and > >>>involvement from operators to avoid situations where=20 > >>> =20 > >>> > >>vendors build all > >> =20 > >> > >>>kind of complex solutions for problems that operators don't have. > >>> > >>>So far, I have seen some support from academia, research efforts > >>>within larger corporations and some vendors, but I have seen little > >>>evidence that this group is going to solve a problem that operators > >>>want to be solved. As I already mentioned in an earlier mail, I am > >>>really somewhat surprised that I haven't seen any operator=20 > >>> =20 > >>> > >>on the list > >> =20 > >> > >>>commenting that we need to start this work as I did expect=20 > >>> =20 > >>> > >>that myself. > >> =20 > >> > >>> =20 > >>> =20 > >>> > >>Sorry to contradict you, but, if you look carefully at the=20 > >>mailing list,=20 > >>you could see that I support DCPEL initiative from the beginning=20 > >>(10/14/2005). During the last IETF meeting, FTR&D support this work=20 > >>during the OPS AREA meeting. In the same time, through the=20 > >>European IST=20 > >>projet EuQoS, I request support from other operator like TID=20 > >>(Telefonica=20 > >>I+D). Generally speaking, in Europe, most of the operator are=20 > >>search for=20 > >>such functionalities. Look to the work done in other fora such as=20 > >>ETSI/TISPAN, ITU-NGN-FG and now Q4/13 or more recently to the=20 > >>DSL Forum.=20 > >>In fact, IETF is the only place where QoS control, and in=20 > particular=20 > >>resource control, are not study in the scope proposed by the DCEPL=20 > >>initiative. > >> =20 > >> > >>>Considering these issues, I think that it probably is not=20 > >>> =20 > >>> > >>in your best > >> =20 > >> > >>>interest to pursue a bof for this IETF. > >>> > >>>We will first need a much clearer answer on what problem=20 > is going to > >>>be solved *for operators*, get real support from operators=20 > >>> =20 > >>> > >>behind this > >> =20 > >> > >>>effort and after that we need to figure out whether that=20 > >>> =20 > >>> > >>solution will > >> =20 > >> > >>>involve protocol work or not. > >>> =20 > >>> =20 > >>> > >>I could discuss this directly by phone as I'm not agree with=20 > >>you. But,=20 > >>operator need and want a global solution to setup and=20 > >>exchange QoS. If=20 > >>you just look at the VoIP service, inter-domain correspond to the=20 > >>"international" part of the traditional PSTN. For the moment,=20 > >>only study=20 > >>are conduct to the access network. But, it is not=20 > sufficient. For the=20 > >>moment, people think that over-provisioning will solve this=20 > >>issue. This=20 > >>is true for the bandwidth, but not for the other QoS=20 > >>parameters such as=20 > >>jitter, delay, loss ... However, VoIP services are vey=20 > >>sensible to the=20 > >>jitter and the delay. Without inter-domain and global QoS=20 > >>solution, it=20 > >>could not be possible to deploy a global VoIP QoS solution.=20 > >>In the same=20 > >>way, all multi-media service (IP TV, VoD, ...) need also=20 > QoS control.=20 > >>Adopting a signaling like NSIS is certainly a great solution,=20 > >>but which=20 > >>will be deploy not before 5 or 10 years due to the time scale=20 > >>operator=20 > >>renew their transfer plane equipments. At the opposite, a=20 > >>control plane=20 > >>such as DCPEL propose, could be deploy very quickly without=20 > changing=20 > >>their transfer plane. > >> > >>Today, operator are in a such situation that there is some=20 > industrial=20 > >>solution on the market, but no standard to compare them or=20 > inter-oper=20 > >>without development or major adaptation. > >> > >>Finally, ITU and ETSI will finalize first standard of the=20 > >>RACF function,=20 > >>but too much dedicated to conversational service. IMHO, it is=20 > >>really a=20 > >>mess that IETF will not conduct study on diffserv control plane. > >> =20 > >> > >>>You can probably convince me to hold a bof anyways but considering > >>>the above stumbling blocks, I would advise you not to do so. > >>> =20 > >>> =20 > >>> > >>I'm agree that the charter need more clarification and scope=20 > >>need more=20 > >>focus. But, this is a very complex subject. All peoples with whom I=20 > >>discussed about this, have a different opinion on the technical=20 > >>solution, but all are agree to said that we need a solution. > >> > >>Best regards, > >> > >>Olivier Dugeon > >> =20 > >> > >>>David Kessens > >>>--- > >>> > >>>_______________________________________________ > >>>Dcpel mailing list > >>>Dcpel@ietf.org > >>>https://www1.ietf.org/mailman/listinfo/dcpel > >>> > >>> =20 > >>> =20 > >>> > >>--=20 > >>Project Manager for Network architecture and switching Division > >> & FT/DR&D/CORE/M2I |=20 > >>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 > >> > >> =20 > >> > > > >_______________________________________________ > >Dcpel mailing list > >Dcpel@ietf.org > >https://www1.ietf.org/mailman/listinfo/dcpel > > > > =20 > > >=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 Mon Mar 13 12:54:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIrFF-0006Nn-1g; Mon, 13 Mar 2006 12:54:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIrFE-0006Ni-7U for dcpel@ietf.org; Mon, 13 Mar 2006 12:54:12 -0500 Received: from tidos.tid.es ([193.145.240.2] helo=correo.tid.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIrFC-0006sZ-R0 for dcpel@ietf.org; Mon, 13 Mar 2006 12:54:12 -0500 Received: from [10.95.10.249] (herreria2.hi.inet [10.95.10.249]) by tid.hi.inet (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IW200KBIV2968@tid.hi.inet> for dcpel@ietf.org; Mon, 13 Mar 2006 18:54:09 +0100 (MET) Date: Mon, 13 Mar 2006 18:55:46 +0100 From: =?ISO-8859-15?Q?Jorge_Andr=E9s_Col=E1s?= In-reply-to: <43FF0D8F.1020800@rd.francetelecom.com> Cc: dcpel@ietf.org Message-id: <4415B222.5020106@tid.es> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-15 Content-transfer-encoding: QUOTED-PRINTABLE X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) References: <43FF0D8F.1020800@rd.francetelecom.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Subject: [Dcpel] DCPEL BoF support from Telefonica I+D 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: , Errors-To: dcpel-bounces@ietf.org Hello Kathleen, Paulo, all, I would like to express our support from Telefonica I+D (advanced= =20 networks department) to the BoF session regarding DCPEL and to the= =20 creation of a WG to work around these concepts. From our perspective, the coordination among control planes belongin= g=20 to different operators is a key point in order to deploy end-to-end= =20 services with QoS differentiation, that is, across operator network= =20 domains. And there is a lack of suitable solutions in the current= =20 Internet architecture in this field. As some of you have commented, one main requirement from an operator= =20 perspective is to avoid to expose the network internals to external= =20 actors for security reasons. In this sense, it is hard for an operato= r=20 to allow a distributed configuration of its network infrastructure by= =20 means of signalling messages coming form other networks/operators.= =20 Therefore, a different approach, probably based on devices negotiatin= g=20 inter-domain agreements and then configuring their internals to apply= =20 the negotiated inter-domain agreements, would be more suitable. In addition, this kind of approach provides flexibility for domains t= o=20 use different mechanisms to provide differentiated QoS internally. Th= is=20 means not only non-DiffServ solutions, but also different ways to= =20 use/configure DiffServ mechanisms. As some of you also commented, there are different fora (e.g. ITU-T,= =20 3GPP, ETSI-TISPAN, IPSphere) that are defining architectures with a= =20 similar overall view in mind, but this must be seen as an opportunity= =20 for the IETF to align their views with common protocols and mechanism= s=20 that these fora are not going to specify. In fact, they look at the I= ETF=20 for protocols to be used/adapted to implement their architectures... Among the topics to cover, I see of special need/interest the=20 standardisation of a common service information model to have a commo= n=20 language for inter-domain negotiation, and also the analysis of curre= nt=20 signalling protocols to find a solution for the inter-domain signalli= ng=20 among different control plane managers. From my work on european=20 research projects, the Ambient Networks and EuQoS projects have made = an=20 interesting work on these topics, so they should be considered as= =20 existing work for the WG. Best regards, Jorge --=20 Jorge Andr=E9s Col=E1s Telef=F3nica I+D Emilio Vargas, 6 28043 - Madrid (Espa=F1a) =20 E-mail: jorgeac@tid.es Tel. +34 91 337 39 28 Fax. +34 91 510 33 08 _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel