Re: [Dcpel] DCPEL BoF support

[Paulo Mendes <[e-mail]>]

Hi Olivier,

some comments inline.

Olivier Dugeon wrote:

> Hi Paulo and Kathie,
>
> Paulo Mendes a écrit :
>
>> Hi Olivier,
>>
>> see my comments inline.
>>
>> Olivier Dugeon wrote:
>>
>>> Hello Kathleen and all,
>>>
>>> We are in favor of a such BoF. Again, I'll ask my colleagues whom 
>>> attend the next IETF meeting to be present during the DCPEL BoF 
>>> session regarding their respective constraint to follow their 
>>> respective WG.
>>>
>>> Concerning the charter, I just want to know if the points described 
>>> below could be present:
>>>
>>> - Study and define a global framework and architecture which take 
>>> into account the inter-domain control plane and not only the 
>>> intra-domain
>>
>>
>> [Paulo] The definition of a overall architecture is already scheduled 
>> in the current proposed charter. And the current version of the DCPEL 
>> requirements I-D, already mention the the Diffserv control plane, 
>> should consider the inter-domain relationship besides the 
>> intra-domain control. The creation of an I-D on interworking between 
>> DiffServ domains is also planned in the charter proposal.
>
> [OD] Ok.
>
>>
>>> - Produce RFC about the end to end CoS definition i.e. by extending 
>>> the notion of Per Domain Behavior to the inter domain. The draft 
>>> about Meta-CoS class from Pierre Levis could be a starting point
>>
>>
>> [Paulo] The e2e definition of CoS should be discussed. IMO, it is 
>> most helpful if we keep the intra-domain mechanisms and PDBs 
>> transparent to the inter-domain operations, and so e2e. So, I would 
>> say that the definition of e2e CoS is related to the use of the 
>> inter-domain service information model, and not the to PDBs to be 
>> used within a network. The relationship between PDBs and services 
>> (SLSs) is something to be worked out within DCPEL.
>
> [OD] Ok. In fact I just want to make an analogy to the PDB. IMHO, I 
> think we need to study, effectively in the scope of e2e, an equivalent 
> of the PDB for the inter-domain aka Inter-Domain Behavior (IDB). Is 
> why I'm referring to the work done by Pierre Levis about the Meta-CoS 
> Class. Without a such IDB, we can't define the behavior of the DCP for 
> the inter-domain.
>
>>
>>> - Produce RFC which define both data and interface to request CoS to 
>>> the DCPEL framework from and application i.e. SLS definition in term 
>>> of parameters, function and transport prootocol
>>
>>
>> [Paulo] The first issue of an I-D on DCP  service information model 
>> is schedule for November 2006, while the interworking of a DCP 
>> network with external mechanisms will be analyzed in the framework I-D.
>
> [OD]. Ok, it make sense to start with the framework and the 
> architecture and then goes into the detail like the service 
> information model.
>
>>
>>> - Produce RFC on topology acquisition to let the Control Plane in 
>>> touch (synchronize) with the Transfert Plane
>>
>>
>> [Paulo] This is a topic related to a centralized control plane. Since 
>> the DCPEL requirements I-D mention the possible centralized and 
>> distributed control of PDBs, and assuming that this proposal will be 
>> accepted, I'm expecting some I-D proposals for DCP centralized 
>> mechanisms and distributed mechanisms (December 2006 in the current 
>> charter proposal). It is up to the authors of the centralized 
>> proposals to refer to describe mechanisms for the acquisition of 
>> topology information.
>
> [OD]. I'm not explicitly refer to a full centralized mode. In fact, I 
> think we need to clarify what we intend by centralized vs. 
> distributed. For the distributed point of view, I'm not sure that it 
> is pertinent to refer to a full distributed mode where all DCP agent 
> are place in each router/device and are aware of the topology since 
> there are on the data path. This mode is too close to a signaling 
> approach and certainly be in conflict with NSIS. IMHO, is certainly 
> why NSIS peoples will see some overlapping with this BoF. At the 
> opposite, a fully centralized mode is certainly not scalable for big 
> network.
>
> IMHO, the DCPEL WG could focus on a semi distributed mode. In this 
> case, a DCP agent will control a given set of routers/devices and are 
> out of the data-path. So, in this case a simple but efficient topology 
> acquisition tools is mandatory to automatically discover and maintain 
> the part of the network the DCP agent control. Typically, this is 
> correspond to an area or sub area of a routing protocol. The 
> communication between DCP agent is more or less the same even if the 2 
> DCP agents are not part of the same AS i.e intra and inter domain 
> communication is more or less the same.

[Paulo] I agree with you.  What we need to analyze is what is the best 
compromise, since this semi-distributed  approach , as you called it, 
may have different operation modes, depending on the size of the 'area'. 
For instance, it may be different if we have an DCP agent in each edge 
device of one DCP agent controlling two of three edge devices. BTW: I 
don't think we need to have a DCP agent in any router/device in a 
network. At this point in time, I would say that that maximum 
distribution level that we should look at is having DCP agent in each 
edge devices (which may be present in a reduced number).

>>
>>> - Produce RFC on which protocol will fit requirement to exchange 
>>> inter-DCPEL SLS i.e. looking how NSIS could fit or be extended to 
>>> this purpose.
>>
>>
>> [Paulo] This is contemplated in the I-D on interworking between 
>> DiffServ domain (scheduled March 2007 in the current charter). It is 
>> expectable that we'll be able to discuss different approaches to 
>> allow the interworking of DiffServ domains, based for instance on 
>> NSIS, SIP, or other protocol model.
>
> [OD] Ok. But I'm not in favor of using SIP. Using SIP will lead the 
> e2e CoS decision at the service plane level which, IMHO, is not a good 
> solution. I understand the argument in favor of this. All operator 
> through the IMS concept thinks that the e2e will be assured by IMS 
> interconnection. The main problem come from the fact that 2 IMS could 
> not necessary be directly interconnect. The connection could traverse 
> one or more AS and completely escape to the IMS signaling. In this 
> case, DCP take all its sense since it see all the AS between 2 IMS. 
> Another reason is that the NGN stratum separation is not respected. In 
> order to efficiently select the best AS path, the IMS, at service 
> level, need information which come from the control and transfer levels.

[Paulo] I never defended a SIP solution by e2e inter-domain control. I 
mentioned that SIP may also play a role in inter-domain DiffServ 
control. For instance to allow end-host and network communication, since 
it is expectable all terminals to be SIP-enabled.

>>
>>> - Produce RFC on which protocol will fit requirement to enforce QoS 
>>> in the underlying network i.e lookink to COPS and NetConf to see how 
>>> it could be used
>>
>>
>> [Paulo] This is also mostly specific to centralized control approaches.
>
> [OD]. See point above. A semi-distributed approach need them also.
>
> Regards,
>
> Olivier
>
>>
>> Cheers
>> Paulo
>>
>>>
>>> Please, don't hesitate to comment.
>>>
>>> Regards,
>>>
>>> Olivier
>>>
>>> PS. I will be out of my office next week and have sporadic access to 
>>> my e-mail
>>>
>>>
>>
>>
>>
>



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