From dcpel-bounces@ietf.org Tue Feb 21 05:29:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBUle-0005Yp-Vw; Tue, 21 Feb 2006 05:29:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBUld-0005Yk-6m for dcpel@ietf.org; Tue, 21 Feb 2006 05:29:13 -0500 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBUlb-0004XG-PO for dcpel@ietf.org; Tue, 21 Feb 2006 05:29:13 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.1/8.13.1) with SMTP id k1LAT789015017 for ; Tue, 21 Feb 2006 11:29:08 +0100 (MET) Message-ID: <012601c636d1$a6181a20$4c0d5982@dynamic.ewi.utwente.nl> From: "Georgios Karagiannis" To: Date: Tue, 21 Feb 2006 11:29:03 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: -5.664 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Tue, 21 Feb 2006 11:29:09 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [Dcpel] questions related to DCPEL scope 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 Dear all I have read the following draft, but I am not sure if I really understood what is the scope of staring the DCPEL BOF/WG. http://www.pollere.net/Txtdocs/draft-vandenberghe-dcpel-basics-00.txt Bellow are some questions for you: Is the scope of starting this BOF/WG the specification of new Per Domain Behaviours (PDBs) and the specification of new interfaces that can be used by existing signaling protocols (such as NSIS) to influence/ manage these PDB's? >From what I have read, another scope of this BOF/WG will be the specification of a new Difsserv control plane architecture and framework. This architecture can be centralized or distributed. 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? >From what I know other stardardisation bodies are working for a long time already on a centralized (bandwidth broker like) architecture/framework. Such standardisation bodies are: the ITU-t, ETSI-tispan, DSL, packetcable, 3gpp, 3gpp2, ipshere, wimax. My question is how is the DCPEL effort related to this work? Best Regards, Georgios _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel From dcpel-bounces@ietf.org Wed Feb 22 14:34:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBzlA-0004Zl-GD; Wed, 22 Feb 2006 14:34:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBzl9-0004Ze-Dj for dcpel@ietf.org; Wed, 22 Feb 2006 14:34:47 -0500 Received: from outbound.mailhop.org ([63.208.196.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBzl9-0002Z8-6F for dcpel@ietf.org; Wed, 22 Feb 2006 14:34:47 -0500 Received: from c-24-6-155-12.hsd1.ca.comcast.net ([24.6.155.12] helo=[10.1.1.50]) by outbound.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.51) id 1FBzl8-000MRw-IP; Wed, 22 Feb 2006 14:34:46 -0500 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.6.155.12 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: kmnichols Message-ID: <43FCBCD3.7000504@pollere.com> Date: Wed, 22 Feb 2006 11:34:43 -0800 From: Kathleen Nichols User-Agent: Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: Georgios Karagiannis Subject: Re: [Dcpel] questions related to DCPEL scope References: <012601c636d1$a6181a20$4c0d5982@dynamic.ewi.utwente.nl> In-Reply-To: <012601c636d1$a6181a20$4c0d5982@dynamic.ewi.utwente.nl> X-Enigmail-Version: 0.93.1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 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 Georgios, > > Is the scope of starting this BOF/WG the specification of new Per > Domain Behaviours (PDBs) and the specification of new interfaces that > can be used by existing signaling protocols (such as NSIS) to > influence/ manage these PDB's? Those items are in the scope of our current proposal. In addition, we want to have the discussion that will result in specification of service models and metrics that can be used externally by network operators to describe their offerings (without exposing the internal implementations). We've proposed a starting point of looking at the NSIS Qspec which in turn builds on the ITU Y1554. However, we don't feel the dcpel effort should be bound to those metrics if they are not sufficient. > 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? 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. Following the model of RFC3290, we expect to spend time on the QoS agent and the configuration and management interface. In draft-nichols-dcpel-strawman-arch-00, this is where we located the DiffServ Control Plane Agent or DCPA. I believe a longer answer is the work of the proposed working group. Please note that we have put out some proposals based on our own work and based on meeting with several folks last November. The final form of a solution would be an outcome of the consensus process. > From what I know other stardardisation bodies are working for a long time > already > on a centralized (bandwidth broker like) architecture/framework. > Such standardisation bodies are: > the ITU-t, ETSI-tispan, DSL, packetcable, 3gpp, 3gpp2, ipshere, wimax. > My question is how is the DCPEL effort related to this work? Well, we have contributors and reviewers of our work who are involved with some of these efforts who still feel IETF work is needed. Since IETF sets standards and practices for the more general internet, this seems appropriate to me. However, the IETF framework for a DCP ought to look at some of these approaches as specific instances of solutions and it would be good if they fit into the framework. Unless we come to the consensus opinion that someone is just doing it wrong! So I would hope we would have some cross- participation. (I coauthored my first document in this area in November of 1997, now rfc2638, and one of my coauthors had been working on the architecture a few years before that, so I think there is a history in the IETF and the IRTF too). The feedback we've gotten is that "something" is needed and we were told from a provider perspective that the acknowleged "big problem" is having common notions of the differentiated services that are openly provided along with a few examples of how to achieve these. Getting to that point is clearly best done through the open, consensus-driven, experience-driven process. regards, Kathie _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel From dcpel-bounces@ietf.org Thu Feb 23 01:28:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC9xu-0002qk-0B; Thu, 23 Feb 2006 01:28:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC9xt-0002qf-KK for dcpel@ietf.org; Thu, 23 Feb 2006 01:28:37 -0500 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FC9xt-0001cA-2G for dcpel@ietf.org; Thu, 23 Feb 2006 01:28:37 -0500 Received: from zeus.cs.utwente.nl (zeus.ewi.utwente.nl [130.89.10.12]) by denhaag.ewi.utwente.nl (8.13.1/8.13.1) with ESMTP id k1N6SX3a003108; Thu, 23 Feb 2006 07:28:33 +0100 (MET) Received: from janus.cs.utwente.nl (janus [130.89.10.26]) by zeus.cs.utwente.nl (8.12.10/8.12.10) with ESMTP id k1N6SXD8012831; Thu, 23 Feb 2006 07:28:33 +0100 (MET) Received: (from nobody@localhost) by janus.cs.utwente.nl (8.11.7p1+Sun/8.10.2) id k1N6SXb27877; Thu, 23 Feb 2006 07:28:33 +0100 (MET) Date: Thu, 23 Feb 2006 07:28:33 +0100 (MET) X-Authentication-Warning: janus.cs.utwente.nl: nobody set sender to karagian@cs.utwente.nl using -f To: nichols@pollere.com Subject: Re: [Dcpel] questions related to DCPEL scope Received: from 84.82.109.231 (auth. user karagian@imap2.cs.utwente.nl) by webmail.cs.utwente.nl with HTTP; Thu, 23 Feb 2006 06:28:33 +0000 X-IlohaMail-Blah: karagian@ewi.utwente.nl X-IlohaMail-Method: mail() [mem] X-IlohaMail-Dummy: moo X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <43FCBCD3.7000504@pollere.com> From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -5.667 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Thu, 23 Feb 2006 07:28:35 +0100 (MET) X-Spam-Score: 0.1 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 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 Kathie Thank you very much for your quick reply! Please see in line! On 2/22/2006, "Kathleen Nichols" wrote: >Georgios, >> >> Is the scope of starting this BOF/WG the specification of new Per >> Domain Behaviours (PDBs) and the specification of new interfaces that >> can be used by existing signaling protocols (such as NSIS) to >> influence/ manage these PDB's? > >Those items are in the scope of our current proposal. In addition, >we want to have the discussion that will result in specification >of service models and metrics that can be used externally by network >operators to describe their offerings (without exposing the >internal implementations). We've proposed a starting point of >looking at the NSIS Qspec which in turn builds on the ITU Y1554. >However, we don't feel the dcpel effort should be bound to those >metrics if they are not sufficient. > >> 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? > >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.=20 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? >Following the model of RFC3290, we >expect to spend time on the QoS agent and the configuration and >management interface. In draft-nichols-dcpel-strawman-arch-00, this is >where we located the DiffServ Control Plane Agent or DCPA. I >believe a longer answer is the work of the proposed working group. >Please note that we have put out some proposals based on our >own work and based on meeting with several folks last November. >The final form of a solution would be an outcome of the consensus >process. > >> From what I know other stardardisation bodies are working for a long time >> already >> on a centralized (bandwidth broker like) architecture/framework. >> Such standardisation bodies are: >> the ITU-t, ETSI-tispan, DSL, packetcable, 3gpp, 3gpp2, ipshere, wimax. >> My question is how is the DCPEL effort related to this work? > >Well, we have contributors and reviewers of our work who are >involved with some of these efforts who still feel IETF work is >needed. Since IETF sets standards and practices for the more general >internet, this seems appropriate to me. However, the IETF framework >for a DCP ought to look at some of these approaches as specific >instances of solutions and it would be good if they fit into the >framework. Unless we come to the consensus opinion that someone >is just doing it wrong! So I would hope we would have some cross- >participation. (I coauthored my first document in this area in >November of 1997, now rfc2638, and one of my coauthors had been >working on the architecture a few years before that, so I think there >is a history in the IETF and the IRTF too). > >The feedback we've gotten is that "something" >is needed and we were told from a provider perspective that >the acknowleged "big problem" is having common notions of the >differentiated services that are openly provided along with >a few examples of how to achieve these. Getting to that point >is clearly best done through the open, consensus-driven, >experience-driven process. 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,=20 ipshere, wimax. The outcome of this state of the art study could then help to define the final charter of the DCPEL BOF/WG. Best Regards, Georgios _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel From dcpel-bounces@ietf.org Thu Feb 23 16:47:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCOIu-0001ax-EJ; Thu, 23 Feb 2006 16:47:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCOIt-0001aX-4v for dcpel@ietf.org; Thu, 23 Feb 2006 16:47:15 -0500 Received: from outbound.mailhop.org ([63.208.196.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCOIr-0006fA-UR for dcpel@ietf.org; Thu, 23 Feb 2006 16:47:15 -0500 Received: from c-24-6-155-12.hsd1.ca.comcast.net ([24.6.155.12] helo=[10.1.1.50]) by outbound.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.51) id 1FCOIr-000Ai8-CK; Thu, 23 Feb 2006 16:47:13 -0500 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.6.155.12 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: kmnichols Message-ID: <43FE2D61.8050307@pollere.com> Date: Thu, 23 Feb 2006 13:47:13 -0800 From: Kathleen Nichols User-Agent: Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: Georgios Karagiannis Subject: Re: [Dcpel] questions related to DCPEL scope References: In-Reply-To: X-Enigmail-Version: 0.93.1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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 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 From dcpel-bounces@ietf.org Fri Feb 24 07:49:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCcNe-0001O1-Eq; Fri, 24 Feb 2006 07:49:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCcNd-0001Nw-OJ for dcpel@ietf.org; Fri, 24 Feb 2006 07:49:05 -0500 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCcNb-0001Ex-B7 for dcpel@ietf.org; Fri, 24 Feb 2006 07:49:05 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.1/8.13.1) with SMTP id k1OCmvJM014912; Fri, 24 Feb 2006 13:48:59 +0100 (MET) Message-ID: <007d01c63940$ae5df080$4c0d5982@dynamic.ewi.utwente.nl> From: "Georgios Karagiannis" To: "Kathleen Nichols" References: <43FE2D61.8050307@pollere.com> Subject: Re: [Dcpel] questions related to DCPEL scope Date: Fri, 24 Feb 2006 13:48:53 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: -5.665 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Fri, 24 Feb 2006 13:49:00 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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 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 From dcpel-bounces@ietf.org Fri Feb 24 08:43:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCdEg-0002ir-Gf; Fri, 24 Feb 2006 08:43:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCdEf-0002i4-QY for dcpel@ietf.org; Fri, 24 Feb 2006 08:43:53 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCdEe-00034z-ED for dcpel@ietf.org; Fri, 24 Feb 2006 08:43:53 -0500 Received: from ftrdmel10.rd.francetelecom.fr ([10.193.117.156]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Feb 2006 14:43:45 +0100 Received: from [10.193.106.99] ([10.193.106.99]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Fri, 24 Feb 2006 14:43:44 +0100 Message-ID: <43FF0D8F.1020800@rd.francetelecom.com> Date: Fri, 24 Feb 2006 14:43:43 +0100 From: Olivier Dugeon User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Kathleen Nichols , dcpel@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Feb 2006 13:43:44.0161 (UTC) FILETIME=[54503910:01C63948] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Subject: [Dcpel] DCPEL BoF support X-BeenThere: dcpel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for possible diffserv control plane elements WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dcpel-bounces@ietf.org 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 - 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 - 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 - Produce RFC on topology acquisition to let the Control Plane in touch (synchronize) with the Transfert Plane - 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. - 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 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 & FTR&D/CORE/M2I | mailto:Olivier.Dugeon@francetelecom.com 2, Avenue Pierre Marzin | Phone/Fax: +(33) 296 05 2880/1852 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 Fri Feb 24 11:05:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCfRW-00044J-4r; Fri, 24 Feb 2006 11:05:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCfRU-00042q-J6 for dcpel@ietf.org; Fri, 24 Feb 2006 11:05:16 -0500 Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCfRS-00089G-2p for dcpel@ietf.org; Fri, 24 Feb 2006 11:05:16 -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 k1OG54oW011810 for ; Fri, 24 Feb 2006 16:05:04 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: Fri, 24 Feb 2006 16:05:04 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: some comments on draft-vandenberghe-dcpel-basics-00.txt Thread-Index: AcYYdS3TIGK+4Po8RAWdixxlqesEFAg0NmTA 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: 7fa173a723009a6ca8ce575a65a5d813 Subject: [Dcpel] some comments on draft-vandenberghe-dcpel-basics-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 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 main questions are about trying to understand the scope in a bit more concrete terms. this email got rather long; sorry for that. r. 1. What is a "traffic aggregate"? 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 These would seem to me to be rather different concepts, especially once routing interactions are taken into account. The first is can be defined quite precisely by giving a specific (ingress, egress); for 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 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 you supposed to renegotiate for a new aggregate? [The reason I ask is that there seems to be a big spectrum of complexity here in the range of possible sophistication of aggregate definition. And I'm not sure where the scope boundary is supposed to be.] 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 signalling mechanisms or to the definition of traffic aggregates themselves? 2. Interior vs. edge vs. exterior The document seems to distinguish three different aspects of 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 independant of these 'internals') 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? 3. Role of PDBs and service descriptions [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 (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. 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. 4. SIP interactions I was confused by two aspects of the interaction with SIP. - SIP is mentioned as a possible instantiation of the inter-domain control mechanism, but I don't see how it would be relevant. 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. - So far as I can tell, assuming that application interactions are handled by 3312 (SDP preconditions) is quite valid, but also 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.) 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. _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel From dcpel-bounces@ietf.org Fri Feb 24 17:48:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FClk6-0002NJ-Td; Fri, 24 Feb 2006 17:48:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FClk5-0002M0-9w for dcpel@ietf.org; Fri, 24 Feb 2006 17:48:53 -0500 Received: from outbound.mailhop.org ([63.208.196.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FClk5-0004qf-18 for dcpel@ietf.org; Fri, 24 Feb 2006 17:48:53 -0500 Received: from c-24-6-155-12.hsd1.ca.comcast.net ([24.6.155.12] helo=[10.1.1.50]) by outbound.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.51) id 1FClk4-000J5P-Cd; Fri, 24 Feb 2006 17:48:52 -0500 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.6.155.12 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: kmnichols Message-ID: <43FF8D51.8050501@pollere.com> Date: Fri, 24 Feb 2006 14:48:49 -0800 From: Kathleen Nichols User-Agent: Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: dcpel@ietf.org Subject: Re: [Dcpel] some comments on draft-vandenberghe-dcpel-basics-00.txt References: In-Reply-To: X-Enigmail-Version: 0.93.1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 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 Robert, 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. This is a fairly short reply. I can send more later or let others reply in detail. > 1. What is a "traffic aggregate"? > I thought that we said we were using the 3086 definition of taffic aggregate. Anyway, that is: 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. > 2. Interior vs. edge vs. exterior 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. > 3. Role of PDBs and service descriptions > ...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. So, I think you have it correct. RFC3086 says in the abstract: 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. 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. > 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. > 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. Kathie _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel