Subject: Re: [Dcpel] DCPEL BoF support

From: Paulo Mendes <[email-masked]>
Date: Fri, 03 Mar 2006 14:49:14 +0100

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.

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

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

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

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

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

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/dcpel

---

From: Avri Doria <[email-masked]>
Date: Fri, 3 Mar 2006 15:46:11 +0100

On 24 feb 2006, at 14.43, Olivier Dugeon wrote:

> We are in favor of a such BoF.

is there going to be a BoF?  I don't see one on the current draft  
schedule.  I know it is too late, but i think having a BoF would be a  
good thing, even if it ends up an informal affair at this point.

a.

---

From: Olivier Dugeon <[email-masked]>
Date: Thu, 09 Mar 2006 19:21:23 +0100

Hi Paulo and Kathie,

Paulo Mendes a écrit :
>> - 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.
>> the notion of Per Domain Behavior to the inter domain. The draft 
>> about Meta-CoS class from Pierre Levis could be a starting point
>
> 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.
> 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.
> 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.
>> 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
>
[OD]. See point above. A semi-distributed approach need them also.

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

---

From: Paulo Mendes <[email-masked]>
Date: Mon, 13 Mar 2006 11:01:02 +0100

Hi Olivier,

some comments inline.

Olivier Dugeon wrote:

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

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

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

---

From: Jorge Andrés Colás <[email-masked]>
Date: Mon, 13 Mar 2006 18:55:46 +0100

Hello Kathleen, Paulo, all,

I would like to express our support from Telefonica I+D (advanced 
networks department) to the BoF session regarding DCPEL and to the 
creation of a WG to work around these concepts.

 From our perspective, the coordination among control planes belonging 
to different operators is a key point in order to deploy end-to-end 
services with QoS differentiation, that is, across operator network 
domains. And there is a lack of suitable solutions in the current 
Internet architecture in this field.

As some of you have commented, one main requirement from an operator 
perspective is to avoid to expose the network internals to external 
actors for security reasons. In this sense, it is hard for an operator 
to allow a distributed configuration of its network infrastructure by 
means of signalling messages coming form other networks/operators. 
Therefore, a different approach, probably based on devices negotiating 
inter-domain agreements and then configuring their internals to apply 
the negotiated inter-domain agreements, would be more suitable.

In addition, this kind of approach provides flexibility for domains to 
use different mechanisms to provide differentiated QoS internally. This 
means not only non-DiffServ solutions, but also different ways to 
use/configure DiffServ mechanisms.

As some of you also commented, there are different fora (e.g. ITU-T, 
3GPP, ETSI-TISPAN, IPSphere) that are defining architectures with a 
similar overall view in mind, but this must be seen as an opportunity 
for the IETF to align their views with common protocols and mechanisms 
that these fora are not going to specify. In fact, they look at the IETF 
for protocols to be used/adapted to implement their architectures...

Among the topics to cover, I see of special need/interest the 
standardisation of a common service information model to have a common 
language for inter-domain negotiation, and also the analysis of current 
signalling protocols to find a solution for the inter-domain signalling 
among different control plane managers. From my work on european 
research projects, the Ambient Networks and EuQoS projects have made an 
interesting work on these topics, so they should be considered as 
existing work for the WG.

Best regards,
Jorge

-- 
Jorge Andrés Colás
Telefónica I+D
Emilio Vargas, 6
28043 - Madrid (España)
 
E-mail: [email-masked]
Tel. +34 91 337 39 28
Fax. +34 91 510 33 08