From dcpel-bounces@ietf.org Fri Jan 13 14:11:17 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExUKS-0005U1-W8; Fri, 13 Jan 2006 14:11:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExUKR-0005TE-MC for dcpel@megatron.ietf.org; Fri, 13 Jan 2006 14:11:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29416 for ; Fri, 13 Jan 2006 14:09:54 -0500 (EST) Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExURn-0007cO-OI for dcpel@ietf.org; Fri, 13 Jan 2006 14:18: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 1ExUKO-000MIX-Vi for dcpel@ietf.org; Fri, 13 Jan 2006 14:11: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: <43C7FB50.301@pollere.com> Date: Fri, 13 Jan 2006 11:11:12 -0800 From: Kathleen Nichols User-Agent: Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: dcpel@ietf.org 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.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Subject: [Dcpel] new drafts X-BeenThere: dcpel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for possible diffserv control plane elements WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dcpel-bounces@ietf.org Errors-To: dcpel-bounces@ietf.org A "problem statement" draft and a "requirements" draft have been sent to the internet draft editor. The versions sent are at: http://www.pollere.net/Txtdocs/draft-vandenberghe-dcpel-basics-00.txt and http://www.pollere.net/Txtdocs/draft-mendes-dcpel-requirements-00.txt if you'd like to look now. (Warning these may have nits that won't pass the I-D editor, but content will not change). The "basics" draft is meant to be a basis of discussion about what (if anything) is needed in the way of a diffserv control plane working group. The requirements draft is a rough early take on the requirements for a Diffserv Control Plane. Discussion is welcome and encouraged on this list. Kathie _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel From dcpel-bounces@ietf.org Mon Jan 16 11:33:12 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyXI8-00077Y-V8; Mon, 16 Jan 2006 11:33:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyXI7-00077Q-BO for dcpel@megatron.ietf.org; Mon, 16 Jan 2006 11:33:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25434 for ; Mon, 16 Jan 2006 11:31:47 -0500 (EST) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyXQ2-0000X5-Gu for dcpel@ietf.org; Mon, 16 Jan 2006 11:41:25 -0500 Received: from ftrdmel10.rd.francetelecom.fr ([10.193.117.156]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Mon, 16 Jan 2006 17:33:06 +0100 Received: from [10.193.11.122] ([10.193.11.122]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Mon, 16 Jan 2006 17:33:06 +0100 Message-ID: <43CBCAC2.6080406@francetelecom.com> Date: Mon, 16 Jan 2006 17:33:06 +0100 From: Olivier Dugeon Organization: France Telecom R&D User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: dcpel@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2006 16:33:06.0431 (UTC) FILETIME=[876350F0:01C61ABA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Subject: [Dcpel] 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: , Sender: dcpel-bounces@ietf.org Errors-To: dcpel-bounces@ietf.org Hello Steven and all, Following the last draft sent by Kathleen, here it is some comments about your draft: Concerning the scope of DCP: is DCP will provision and enforce basic DiffServ router configuration or not ? In fact, I just want to know if an operator needs to continue to setup manually some configuration (like queuing, bandwidth, priority ...) of the DCPEL (a), or if the DCP could help an operator to provision its DiffServ Domain (b). For example, I want to support this PDBs from this ingress to this egress. The DCP verify it its possible and enforce the PDBs inside the domain including both ingress, egress and core node. In case of (a), how a DCP could retrieve all DS setup (it is also related to another question - see below). In case of (b), I think that the draft should explicitly state this and make distinction between provisioning and invocation (or perhaps is what you state with pre-provisioning and provisioning). As usual, definition is very important. In figure I (section 4.1) you describe and comment the monitoring function of the DCP. Instead of "defining what types of network status are needed" I would prefer speaking about information which are needed. Indeed, I think that a DCP need more than simple network status. For example, if PDBs are manually setup, the DCP must retrieve all this kind of information. In order to perform a correct and efficient admission control, the DCP must be aware of the topology of the network (path awareness). It is not clear for me which entity could request some SLSs in a DCP control DS domain. Is it only another DS domain or a customer could do this. Do you assume that its the same from the DCP point of view ? and, so, make no distinction between a network and a end-host ? In this case, why make distinction between intra and inter domain for the request and the interface. Do you think that the figure 1 could be enhance by designing a common interface used by customer, provider, other DCP in order to request some SLSs ? Despite this, I'm agree with your draft and think that is in good shape to define the DCPEL WG. Best regards, Olivier -- 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 Mon Jan 16 12:27:21 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyY8X-0006zO-1w; Mon, 16 Jan 2006 12:27:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyY8T-0006xv-Tw for dcpel@megatron.ietf.org; Mon, 16 Jan 2006 12:27:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29874 for ; Mon, 16 Jan 2006 12:25:53 -0500 (EST) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyYGQ-0002YC-On for dcpel@ietf.org; Mon, 16 Jan 2006 12:35:32 -0500 Received: from ftrdmel10.rd.francetelecom.fr ([10.193.117.156]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Mon, 16 Jan 2006 18:27:14 +0100 Received: from [10.193.11.122] ([10.193.11.122]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Mon, 16 Jan 2006 18:27:14 +0100 Message-ID: <43CBD772.7070004@francetelecom.com> Date: Mon, 16 Jan 2006 18:27:14 +0100 From: Olivier Dugeon Organization: France Telecom R&D User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: dcpel@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2006 17:27:14.0325 (UTC) FILETIME=[17489C50:01C61AC2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Subject: [Dcpel] 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: , Sender: dcpel-bounces@ietf.org Errors-To: dcpel-bounces@ietf.org Hi Paulo and all, Following the last draft sent by Kathleen, here it is some comments about your draft: On page 2, do you think it is suitable to mention application (or customer) request as an example of service which need DS Control Plane ? On page 6, you mention that DCP must support heterogeneous network including mobile. Do you think that DCP must support mobility or just nomadic. In case of mobility, how do you think that handover could be support ? I think it's a very huge problem. On page 7, like on draft-vandenberghe-dcepl-basis-00.txt, I think that the monitoring should include network topology acquisition in order to the DCP to be path aware. In fact, globaly speaking regarding NSIS, which are path coupled, the DCP should be path-decoupled, but, in the same time be path awareness. I understand that, stating like this, it is a little bit disappointed, but, in order to correctly handle a DS domain and perform admission control, the DCP must know a minimu about the network it control. This include at least the topology. On page 8, you describe the SLS, but not mention the function necessary to manipulate the SLSs. I think it could be include: Request, Delete, Modify, Announce, Query as basis functions and certainly need some maintenance functions like GetAll, DeleteAll ... On page 9, about the inter-domain (bullet point 2). You mention packet re-marking at the inter-domain boundary. Do you think that this statement must be extend to policy (in fact, all DS actions: classify, policy, marking/dropping and scheduling) ? Operator wants to control what is entering their network despite that there is a contract with the sender. In any case the traffic is control, mark and shaped or spaced if necessary. Packet dropping could occur if the contract is not respected. I also note some mis-spelling (like double section) and generally wants to propose some sentence adjustment. Did you directly write the draft in plain text or do you use another format ? If yes, is it possible to get the original file in order to propose my corrections ? Finally, as the other proposed draft, I'm in favor of this draft and think it is in good shape to provide material for a DCPEL BoF. Best regards, Olivier -- 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 Tue Jan 17 09:12:08 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyrZA-0005ju-NF; Tue, 17 Jan 2006 09:12:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyrZ7-0005hh-V8 for dcpel@megatron.ietf.org; Tue, 17 Jan 2006 09:12:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18707 for ; Tue, 17 Jan 2006 09:10:40 -0500 (EST) Received: from pecan.ugent.be ([157.193.49.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyrhF-0001xY-Gi for dcpel@ietf.org; Tue, 17 Jan 2006 09:20:31 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by pecan.UGent.be (Postfix) with ESMTP id B149035268B; Tue, 17 Jan 2006 15:11:46 +0100 (CET) Received: from pecan.UGent.be ([127.0.0.1]) by localhost (gorilla.UGent.be [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03205-10; Tue, 17 Jan 2006 15:11:42 +0100 (CET) Received: from plinius.intec.ugent.be (plinius.intec2.rug.ac.be [157.193.214.4]) by pecan.UGent.be (Postfix) with ESMTP id 6C51035268F; Tue, 17 Jan 2006 15:11:42 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by plinius.intec.ugent.be (Postfix) with ESMTP id 848CABD54; Tue, 17 Jan 2006 15:11:43 +0100 (CET) Received: from [192.168.1.14] (svdberg.vpn [192.168.1.14]) by plinius.intec.ugent.be (Postfix) with ESMTP id 1B372BD22; Tue, 17 Jan 2006 15:11:43 +0100 (CET) From: Steven Van den Berghe Organization: Ghent University To: dcpel@ietf.org Subject: Re: [Dcpel] Comments on draft-vandenberghe-dcpel-basics-00.txt Date: Tue, 17 Jan 2006 11:25:13 +0100 User-Agent: KMail/1.7.1 References: <43CBCAC2.6080406@francetelecom.com> In-Reply-To: <43CBCAC2.6080406@francetelecom.com> MIME-Version: 1.0 Message-Id: <200601171125.15733.steven.vandenberghe@intec.ugent.be> X-Virus-Scanned: by AMaViS snapshot-20020222 X-Virus-Scanned: by UGent DICT X-Spam-Score: 0.7 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: 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: , Content-Type: multipart/mixed; boundary="===============1411801093==" Sender: dcpel-bounces@ietf.org Errors-To: dcpel-bounces@ietf.org --===============1411801093== Content-Type: multipart/signed; boundary="nextPart9897469.5YexZjJz4q"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart9897469.5YexZjJz4q Content-Type: text/plain; charset="iso-8859-15" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Olivier, Thanks for your valuable comments, i've put some replies inline=20 (note that this document was intended to gather the scope/boundaries the=20 community sees for the DCPEL work, so any disagreements and comments on the= =20 opinions expressed below are welcome). On Monday 16 January 2006 17:33, Olivier Dugeon wrote: > Hello Steven and all, > > Following the last draft sent by Kathleen, here it is some comments > about your draft: > > Concerning the scope of DCP: is DCP will provision and enforce basic > DiffServ router configuration or not ? > In fact, I just want to know if an operator needs to continue to setup > manually some configuration (like queuing, bandwidth, priority ...) of > the DCPEL (a), or if the DCP could help an operator to provision its > DiffServ Domain (b). For example, I want to support this PDBs from this > ingress to this egress. The DCP verify it its possible and enforce the > PDBs inside the domain including both ingress, egress and core node. In > case of (a), how a DCP could retrieve all DS setup (it is also related > to another question - see below). In case of (b), I think that the draft > should explicitly state this and make distinction between provisioning > and invocation (or perhaps is what you state with pre-provisioning and > provisioning). As usual, definition is very important. Intuitively, my personal short answer would be (b). The long answer would b= e=20 part of the DCPEL process. DCPEL will define requirements, architecture and individual elements in tha= t=20 architecture to build up a DCP domain. The main goal of that part would be = to=20 define externally observable "Service Behaviours" and ways to semantically= =20 work with these DCP services, similar to PDBs which define externally=20 observable "Packet Treatment Behaviours" in a domain scope, and PHBs do the= =20 same for a hop.=20 Additionally some sample DCP services will be defined in that framework.=20 Examples might include services that are "invocation-only", and others that= =20 take the two-step approach. In terms of the actual internal enforcement procedure (i.e. configuration o= f=20 PDBs and/or PHBs), i don't think we can enforce a single approach, as state= d=20 in section 4.1. Nevertheless, documents describing implementation practises= =20 for implementing DCP services with other standardization efforts (e.g. SNMP= ,=20 COPS, NSIS, RSVP-TE, ...) will imho be valuable. These are envisaged in the= =20 "Define a set of DCP enforcement architectures and mechanisms (i.e.=20 single-domain DCP implementations) that satisfy the framework." milestone. (btw, the hybrid approach mentioned as an enforcement example in section 4.= 1=20 is indeed somewhat similar to the subscription/invocation combination from = a=20 intradomain point of view, but this is not necessarily a requirement for th= e=20 service that is "externally observed" from that domain). > In figure I (section 4.1) you describe and comment the monitoring > function of the DCP. Instead of "defining what types of network status > are needed" I would prefer speaking about information which are needed. > Indeed, I think that a DCP need more than simple network status. For > example, if PDBs are manually setup, the DCP must retrieve all this kind > of information. In order to perform a correct and efficient admission > control, the DCP must be aware of the topology of the network (path > awareness). DCPEL will provide the requirements for the bi-directional interface betwee= n=20 DCP and Enforcement/Monitoring. Depending on the approach chosen for the=20 enforcement, the required information to "monitor" or retrieve from the=20 underlying network will indeed vary. The architecture and elements should=20 define the information required for operating DCP, not the whether this=20 information is obtained through monitoring or is known through the=20 enforcement mechanism. So indeed, the "status" could also include retrieval= =20 of configuration information. Maybe the following definition would be more= =20 accurate ? o Monitoring: in order to adjust configurations, evaluate ability to respond to requests, record delivered commitments, etc., the DCP needs access to a wide range of information about the operational conditions of its network. DCPEL will not work on developing monitoring tools, but rather on defining what types of network information (configuration, status, performance parameters, ...)=20 are needed and on how this can be communicated to the DCP. This may stimulate work in other IETF WGs or by vendors. > It is not clear for me which entity could request some SLSs in a DCP > control DS domain. Is it only another DS domain or a customer could do > this. Do you assume that its the same from the DCP point of view ? and, > so, make no distinction between a network and a end-host ? In this case, > why make distinction between intra and inter domain for the request and > the interface. Do you think that the figure 1 could be enhance by > designing a common interface used by customer, provider, other DCP in > order to request some SLSs ? The short answer would be that the DCP doesn't care whether it is talking t= o a=20 customer, or other DCPs. However, the interaction with the DCP, and the DCP= =20 services will most probably differ between the cases. This will be describe= d=20 in documents belonging to respectively the "Define DCP service information= =20 models and service framework" and "Define interworking of a DS domain (and= =20 its DCP)" milestones. Best regards, Steven =2D-=20 Steven Van den Berghe Department of Information Technology Ghent University - IBBT - IMEC http://www.ibcn.intec.ugent.be Tel: +32 (0) 9 331 49 73 =46ax: +32 (0) 9 331 48 99 --nextPart9897469.5YexZjJz4q Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBDzMYLOe05O+wjKOwRAmd3AJ0Wz+LnMa0JSq5/OZYSt52bvA0JuwCghdpW ISoHgFu2MUC7FkSu7I99ltM= =qqsD -----END PGP SIGNATURE----- --nextPart9897469.5YexZjJz4q-- --===============1411801093== 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 --===============1411801093==-- From dcpel-bounces@ietf.org Sun Jan 22 13:00:34 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0jVy-0007Fk-7X; Sun, 22 Jan 2006 13:00:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0jVw-0007Df-62 for dcpel@megatron.ietf.org; Sun, 22 Jan 2006 13:00:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05539 for ; Sun, 22 Jan 2006 12:59:02 -0500 (EST) Received: from deprox.docomolab-euro.com ([212.119.9.186]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F0jf7-0006xR-NX for dcpel@ietf.org; Sun, 22 Jan 2006 13:10:02 -0500 Received: from 172.27.10.3 by deprox.docomolab-euro.com (InterScan E-Mail VirusWall NT); Sun, 22 Jan 2006 18:59:56 +0100 Received: from [192.168.70.20] ([192.168.70.20]) by deex.docomolab-euro.com with Microsoft SMTPSVC(5.0.2195.4905); Sun, 22 Jan 2006 18:59:56 +0100 Message-ID: <43D3C91C.9030601@docomolab-euro.com> Date: Sun, 22 Jan 2006 19:04:12 +0100 From: Paulo Mendes User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Olivier Dugeon Subject: Re: [Dcpel] Comments on draft-mendes-dcpel-requirements-00.txt References: <43CBD772.7070004@francetelecom.com> In-Reply-To: <43CBD772.7070004@francetelecom.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jan 2006 17:59:56.0259 (UTC) FILETIME=[A72A7B30:01C61F7D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: 7bit Cc: dcpel@ietf.org X-BeenThere: dcpel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for possible diffserv control plane elements WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dcpel-bounces@ietf.org Errors-To: dcpel-bounces@ietf.org Hi Olivier, please find my comments inline. Olivier Dugeon wrote: > Hi Paulo and all, > > Following the last draft sent by Kathleen, here it is some comments > about your draft: > > On page 2, do you think it is suitable to mention application (or > customer) request as an example of service which need DS Control Plane ? [Paulo] I cannot locate any reference to applications or customers in page 2. Can you provide references to the sections and not to the pages? > > On page 6, you mention that DCP must support heterogeneous network > including mobile. Do you think that DCP must support mobility or just > nomadic. In case of mobility, how do you think that handover could be > support ? I think it's a very huge problem. [Paulo] It is my understanding that nomadic systems are already a reality in IP networks, and that end-host mobility is a reality that is being brought very fast to the IP world (see the all IP work in 3GPP). Moreover we can already see mobile communications being provided in moving networks, such as trains. So, considering the time needed to standardize anything, considering only a sub-set of these scenarios will lead us to a short-lived solution. This doesn't mean that all these requirements should be considered at once. On the one hand, we should start from the simplest solution (nomadic) an enhance it for other scenarios (host and network mobility). On the other hand, IMHO, a solution limited to the nomadic case, will not fulfill all the needs in a near future. > > On page 7, like on draft-vandenberghe-dcepl-basis-00.txt, I think that > the monitoring should include network topology acquisition in order to > the DCP to be path aware. In fact, globaly speaking regarding NSIS, > which are path coupled, the DCP should be path-decoupled, but, in the > same time be path awareness. I understand that, stating like this, it > is a little bit disappointed, but, in order to correctly handle a DS > domain and perform admission control, the DCP must know a minimu about > the network it control. This include at least the topology. [Paulo] As is said in section 4 "A specific intra-domain control plane solution will have dependencies on the particular forwarding path..." and "...inter-network control is decoupled from the forwarding path." So, what is assumed is that an inter-domain control will be path-decoupled, and intra-domain control will be dependent from the forwarding path. This dependency can be provided by a path-decoupled signalling enhanced by an extra mechanism to collect updated information on network topology and capability, or by a path-coupled signalling that has its own topology and capability probing mechanism. If I understood you right, you are suggesting the first option (intra-domain path decoupled + monitoring mechanism). However, it seems that the second option (intra-domain path coupled) may be based on existing standards (or changed ones), such as NSIS signalling. The req document also mention that "...more than one solution can fit the set of identified requirements." for the case of intra-domain, which means that based on a common set of DCP elements, solutions for both hypotheses may be possible (how many is something to be discussed during the DCPEL work). > > On page 8, you describe the SLS, but not mention the function > necessary to manipulate the SLSs. I think it could be include: > Request, Delete, Modify, Announce, Query as basis functions and > certainly need some maintenance functions like GetAll, DeleteAll ... [Paulo] The operations required to manipulate SLS are only briefly mentioned in section 5.3 "The inter-domain interface must allow network domains to offer, request/negotiate, and monitor agreements/SLSs." I think that this covers the Request, Announce, and Query functions that you mentioned. Do you really see as necessary the reference to operations such as Delete, Modify, GetAll and DeleteAll? Can't we see these operations as examples of a Request operation? > > On page 9, about the inter-domain (bullet point 2). You mention packet > re-marking at the inter-domain boundary. Do you think that this > statement must be extend to policy (in fact, all DS actions: classify, > policy, marking/dropping and scheduling) ? Operator wants to control > what is entering their network despite that there is a contract with > the sender. In any case the traffic is control, mark and shaped or > spaced if necessary. Packet dropping could occur if the contract is > not respected. [Paulo] Actually what is said in that bullet requires at least classification and marking capabilities, since what is being stressed is that PDBs have an intra-domain meaning, and that when flowing from one domain to another it is required to re-mark the traffic from the PDB of the upstream domain to the PDB of the downstream domain, being the SLS between both domains used to allow such 'translation'. As I see it, the policy mechanism that may happen after marking the packets is already an internal operation (being section 5.3 dedicated to inter-domain operations). Do you agree with this? > > I also note some mis-spelling (like double section) and generally > wants to propose some sentence adjustment. Did you directly write the > draft in plain text or do you use another format ? If yes, is it > possible to get the original file in order to propose my corrections ? [Paulo] The document was written in xml and converted to txt format. For sure the document needs more work. Can you point out to the misspelling cases? Cheers Paulo > Finally, as the other proposed draft, I'm in favor of this draft and > think it is in good shape to provide material for a DCPEL BoF. > > Best regards, > > Olivier > _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel