RE: [Dcpel] DCPEL BoF support

["LEVIS Pierre RD-CORE-CAE" <[e-mail]>]

Hi all,

As the author of draft-meta-qos-class-00.txt stated by Olivier, I would like to provide somm complement to back Olivier's proposal.
IMHO QoS SLS between Autonomous Systems (if we take AS as the basic interdomain element) doesn't really care about PDB.
A PDP is a way, I would say the Diffserv way, to enforce a QoS level target inside a single domain. It is closely related to a PHB or set of PHBs.
Suppose now, I'm an ISP, with a tremendously over-provisioned best-effort network.
Despite best-effort only, I can gaurantee strong QoS.
My neighbouring domains won't decline my offer just because my only PDB is best-effort, they are interested in the level of QoS I can provide, and not in the way I have engineered my network.
Furthermore I, as an ISP, would not disclose my internal network setting. So, for interdomain QoS negotiations we need a notion, an external view, decorrelated from any type of physical realisation, simply to capture the available level of QoS.
It is where Meta-QoS-Class applies. Note that I've sent directly my draft to the RFC Editor because there was no WG, at that time, to host this work, so the draft is in the RFC Editor queue, the intended status is Informational RFC. 
This work is the outcome of the MESCAL European project, follow-up of the TEQUILA project well known for its proposal on SLS format. 

Regards,

Pierre

-----Message d'origine-----
De : DUGEON Olivier RD-CORE [mailto:[e-mail]] 
Envoyé : jeudi 9 mars 2006 19:21
À : Paulo Mendes
Cc : [e-mail]
Objet : Re: [Dcpel] DCPEL BoF support

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

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