Re: [Dcpel] Comments on draft-mendes-dcpel-requirements-00.txt
Paulo Mendes <mendes@docomolab-euro.com> Sun, 22 January 2006 18:00 UTC
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 <dcpel@ietf.org>; 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 <mendes@docomolab-euro.com>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Olivier Dugeon <Olivier.Dugeon@francetelecom.com>
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 <dcpel.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dcpel>, <mailto:dcpel-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dcpel>
List-Post: <mailto:dcpel@ietf.org>
List-Help: <mailto:dcpel-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dcpel>, <mailto:dcpel-request@ietf.org?subject=subscribe>
Sender: dcpel-bounces@ietf.org
Errors-To: dcpel-bounces@ietf.org
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
- [Dcpel] Comments on draft-mendes-dcpel-requiremen… Olivier Dugeon
- Re: [Dcpel] Comments on draft-mendes-dcpel-requir… Paulo Mendes