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

[Paulo Mendes <[e-mail]>]

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
[e-mail]
https://www1.ietf.org/mailman/listinfo/dcpel