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

From: Olivier Dugeon <[email-masked]>
Date: Mon, 16 Jan 2006 17:33:06 +0100

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:[email-masked]
 2, Avenue Pierre Marzin      | Phone/Fax:  +(33) 296 05 2880/1470
 F-22307 LANNION              | Mobile:     +(33) 6 82 90 37 85

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

---

From: Steven Van den Berghe <[email-masked]>
Date: Tue, 17 Jan 2006 11:25:13 +0100

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

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

> control, the DCP must be aware of the topology of the network (path

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.

> 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: +32 (0) 9 331 49 73
Fax: +32 (0) 9 331 48 99