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

From: Olivier Dugeon <[email-masked]>
Date: Wed, 02 Nov 2005 18:46:04 +0100

Hi Paulo,

Paulo Mendes a écrit :

> Hi there,
>
> some comments inline...
>
> Olivier Dugeon wrote:
>
>> Hi Kathleen,
>>
>> Kathleen Nichols a écrit :
>>
>>> Paulo Mendes wrote:
>>>  
>>>
>>>
[ ... skip ... ]

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

[OD]. I'm agree with your analyze. I have in mind the b) solution where 
effectively only the ingress node need to be configured. The a) option 
mostly refer to OSS management and not to control plane. But, the main 
argument in favor of b) is performance issue. It is more scalable and 
faster to just enforce QoS on the ingress node. Now, what mechanism is 
needed to enforce QoS on ingress node vary depending on what the network 
support. It could be setup a path with NSIS or RSVP or RSVP-TE or simply 
configure a classifier/marker for a simple DiffServ node.

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: Olivier Dugeon <[email-masked]>
Date: Wed, 02 Nov 2005 18:47:23 +0100

Hi Paulo and Kathleen,

I stronger support the Paulo proposal and I'm also in favor of the b) 
option.

Regards,

Olivier

Paulo Mendes a écrit :

> Hi Kathleen,
>
> Kathleen Nichols wrote:
>
>> 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.
>>  
>>
> [Paulo] I agree. We can do this is two ways: a) create a charter only 
> for intra-domain issues, keeping in mind that the charter may be 
> changed latter to include inter-domain issues; b) he create a charter 
> encompassing intra- and inter- domain issues, but we define a clear 
> work plan, which should give higher priority to intra-domain issues. I 
> would prefer the option b), because this will make the WG stronger, 
> since we aim to provide the needed E2E solution. And in the end is 
> this that matters. If you follow option a), we are leaving behind the 
> major reason not to have QoS deployed in the Internet, which is the 
> lack of inter-domain control.
> I'm a little afraid that if we don't include the inter-domain control 
> in our list of priorities, it may happen that we end up again with a 
> half-solution: control of Diffserv networks but still no end-to-end QoS.
>
>>> 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 would very much like to contribute to this problem statement draft, 
> since it will clarify our goals. If we do this, can you present the 
> draft in Vancouver? (like I said in my last email, unfortunately I 
> cannot attend the IETF meeting in Vancouver).
>
>>> 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
>>  
>>
> Cheers
> Paulo
>