Re: [Dcpel] Comments on draft-vandenberghe-dcpel-basics-00.txt

[Steven Van den Berghe <[e-mail]>]

Hi Olivier,

Thanks for your valuable comments, i've put some replies inline 

(note that this document was intended to gather the scope/boundaries the 
community sees for the DCPEL work, so any disagreements and comments on the 
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 be 
part of the DCPEL process.

DCPEL will define requirements, architecture and individual elements in that 
architecture to build up a DCP domain. The main goal of that part would be to 
define externally observable "Service Behaviours" and ways to semantically 
work with these DCP services, similar to PDBs which define externally 
observable "Packet Treatment Behaviours" in a domain scope, and PHBs do the 
same for a hop. 

Additionally some sample DCP services will be defined in that framework. 
Examples might include services that are "invocation-only", and others that 
take the two-step approach.

In terms of the actual internal enforcement procedure (i.e. configuration of 
PDBs and/or PHBs), i don't think we can enforce a single approach, as stated 
in section 4.1. Nevertheless, documents describing implementation practises 
for implementing DCP services with other standardization efforts (e.g. SNMP, 
COPS, NSIS, RSVP-TE, ...) will imho be valuable. These are envisaged in the 
"Define a set of DCP enforcement architectures and mechanisms (i.e. 
single-domain DCP implementations) that satisfy the framework." milestone.

(btw, the hybrid approach mentioned as an enforcement example in section 4.1 
is indeed somewhat similar to the subscription/invocation combination from a 
intradomain point of view, but this is not necessarily a requirement for the 
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 between 
DCP and Enforcement/Monitoring. Depending on the approach chosen for the 
enforcement, the required information to "monitor" or retrieve from the 
underlying network will indeed vary. The architecture and elements should 
define the information required for operating DCP, not the whether this 
information is obtained through monitoring or is known through the 
enforcement mechanism. So indeed, the "status" could also include retrieval 
of configuration information. Maybe the following definition would be more 
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, ...) 
     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 to a 
customer, or other DCPs. However, the interaction with the DCP, and the DCP 
services will most probably differ between the cases. This will be described 
in documents belonging to respectively the "Define DCP service information 
models and service framework" and "Define interworking of a DS domain (and 
its DCP)" milestones.

Best regards,
Steven
-- 
Steven Van den Berghe
Department of Information Technology
Ghent University - IBBT - IMEC
http://www.ibcn.intec.ugent.be
Tel: [phone]
Fax: [phone]

_______________________________________________
Dcpel mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dcpel