Re: [Dcpel] DCPEL BoF support

[Olivier Dugeon <[e-mail]>]

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

-- 
Project Manager for Network architecture and switching Division
 & FT/DR&D/CORE/M2I           | mailto:[e-mail]
 2, Avenue Pierre Marzin      | Phone/Fax:  +(33) 296 05 2880/1470
 F-22307 LANNION              | Mobile:     +(33) 6 82 90 37 85



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