Re: [Dcpel] response (changed long subject line)

[Paulo Mendes <[e-mail]>]

Hi there,

some comments inline...

Olivier Dugeon wrote:

> Hi Kathleen,
>
> Kathleen Nichols a écrit :
>
>> Paulo Mendes wrote:
>>  
>>
>>> Hello,
>>>
>>> I'm quite interested in this BOF. Actually, for a long time that I was
>>> expecting a BOF like this to show up. This because it is perfectly
>>> synchronized with the work that I'm currently doing at the NTT DoCoMo
>>> laboratories in Europe. Currently, we are working on the following 
>>> topics:
>>> - Dynamic control of inter-domain QoS with local configuration of PDBs:
>>>  - Standard Information model
>>>  - Standard interface
>>>  - Standard protocol for local configuration of classes
>>> - Distributed control of intra-domain QoS with admission control and
>>> dynamic allocation of BW to different classes.
>>>
>>> I enumerated these two topic in a clear separation between inter-domain
>>> and intra-domain. This because the requirements are clearly different.
>>> For instance, in what concerns signaling, while inter-domain must be
>>> done at the network level, and a protocol much simpler than NSIS may be
>>> used, intra-domain control of classes resources should be done in the
>>> data path from ingress to egress.
>>>   
>>
>>
>> That has been our thinking also. And I think it makes sense to seek
>> a charter that is limited to intra-domain at first. Many WGs
>> (including Diffserv) recharter when it is time for new work items
>> and that's a nice way to keep focus.
>>  
>>
> I understand your reason to focus on intra-domain but, IMHO I think it 
> is very important to also keep in mind the inter-domain aspect. I 
> would propose to keep in the charter a sentence which clearly say that 
> the WG will take into account the inter-domain and build a 
> framework/architecture in this perspective. So, the result from the WG 
> could be easely extend to inter-domain in a second step.
>
>>  
>>
>>> It seems that for now there is only Nichols's et al. ID about a 
>>> strawman
>>> description of components. If there is already a stable idea of what
>>> this control plane must, should and may provide, I agree that the next
>>> step may be the classification of existing solutions and identification
>>> of missing functionalities. Otherwise, it is better to clearly identify
>>> the problem statement, and a set or requirements and assumptions.
>>>   
>>
>>
>> I would welcome your input on any of these items. We put out a
>> strawman to give something common to talk about (even if it is
>> just to disagree with it. If you would like to write a brief
>> draft of a proposed problem statement, we could discuss that
>> on the list and at Vancouver. So, we have the possibility of
>> using the COPS RFCs as a basis for a diffserv control plane,
>> we have the option of looking at some solution approaches to
>> see if there is a stable idea of the control plane, and
>> we have the option of writing a problem statement.
>>  
>>
> I take the opportunity to give my understanding about COPS. I think 
> that COPS is more devoted to apply policy to a given set of device 
> rather than building a control Plane. In fact, the Dcpel could used 
> COPS to enforce QoS in the network and IMHO is placed on top of PDP 
> since it facilitate the PDP configuration. i.e. that it is not solved 
> in COPS is how/when/with which information an operator could easely 
> fullfill the PIB in a PDP.

[Paulo] Keeping in mind a modular distinction between inter- and 
intra-domain, I would say that based on a set of available inter-domain 
QoS agreements, the PDP, which control the QoS agreements, may use COPS 
to enforce QoS in the network, as you say. But we must see what do you 
mean by "enforcing the QoS in the network". IMHO there are two options: 
a) a centralized one, in which the PDP uses COPS to configure all the 
needed routers; b) a decentralized one, in which the PDP used COPS to 
configure the ingress PEP, and to inform the PEP about the PDB that 
needs to be setup. Based on this information the PEP uses an 
intra-domain signaling protocol to perform class configuration until the 
required egress point. This signaling may be based on a NSIS protocol.

>
>>> So, I'm available to contribute to the following actions:
>>> - Classification of requirements and assumptions for the control of
>>> DiffServ networks
>>> - Specification of control elements/protocols (which should all have a
>>> good security assurance :) )
>>>
>>> I could also help in the shape the BoF proposal, if still needed, but
>>> unfortunately, due to other travel appointments, I cannot attend the
>>> Vancouver meeting.
>>>
>>>   
>>
>>
>> Certainly shaping a proposal for a WG charter is still needed. This
>> can be done through email.
>>
>>     regards,
>>         Kathie Nichols
>>
>>
>> _______________________________________________
>> Dcpel mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/dcpel
>>
>>  
>>
> Regards,
>
> Olivier
>



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