Subject: [Dcpel] Comments on draft-mendes-dcpel-requirements-00.txt

From: Olivier Dugeon <[email-masked]>
Date: Mon, 16 Jan 2006 18:27:14 +0100

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:[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: Paulo Mendes <[email-masked]>
Date: Sun, 22 Jan 2006 19:04:12 +0100

Hi Olivier,

please find my comments inline.

> 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?

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

> 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:

[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?

> 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