Re: [Dcpel] some comments on draft-vandenberghe-dcpel-basics-00.txt

Paulo Mendes <mendes@docomolab-euro.com> Fri, 03 March 2006 13:49 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFAfG-0008Dn-3y; Fri, 03 Mar 2006 08:49:50 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFAfF-0008Cl-77 for dcpel@ietf.org; Fri, 03 Mar 2006 08:49:49 -0500
Received: from deprox.docomolab-euro.com ([212.119.9.186]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FFAfE-0005ye-QQ for dcpel@ietf.org; Fri, 03 Mar 2006 08:49:49 -0500
Received: from 172.27.10.3 by deprox.docomolab-euro.com (InterScan E-Mail VirusWall NT); Fri, 03 Mar 2006 14:49:37 +0100
Received: from [172.27.100.57] ([172.27.100.57]) by deex.docomolab-euro.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 3 Mar 2006 14:49:37 +0100
Message-ID: <44084977.2050101@docomolab-euro.com>
Date: Fri, 03 Mar 2006 14:49:43 +0100
From: Paulo Mendes <mendes@docomolab-euro.com>
User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Hancock, Robert" <robert.hancock@roke.co.uk>
Subject: Re: [Dcpel] some comments on draft-vandenberghe-dcpel-basics-00.txt
References: <A632AD91CF90F24A87C42F6B96ADE5C57EBE1F@rsys005a.comm.ad.roke.co.uk> <43FF8D51.8050501@pollere.com>
In-Reply-To: <43FF8D51.8050501@pollere.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 03 Mar 2006 13:49:37.0703 (UTC) FILETIME=[4FEEB370:01C63EC9]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Cc: dcpel@ietf.org
X-BeenThere: dcpel@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for possible diffserv control plane elements WG <dcpel.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dcpel>, <mailto:dcpel-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dcpel>
List-Post: <mailto:dcpel@ietf.org>
List-Help: <mailto:dcpel-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dcpel>, <mailto:dcpel-request@ietf.org?subject=subscribe>
Errors-To: dcpel-bounces@ietf.org

Hi Robert,

to add something to Kathie's e-mail, here is an extract of your e-mail:


Kathleen Nichols wrote:

> .......
>
>> 4. SIP interactions
>
>
> The quick response is that we didn't plan to change SIP or 3312 but
> to use that as a guideline for our framework, that is, our framework
> should have a way to interoperate in the 3312 sense. It was suggested
> as a starting point (and maybe sufficient) for application
> interaction.

[Paulo] It is also my opinion that 3312 can provide some guideline on 
the interaction between applications and network, in both ends of a 
communication session. However, IMO it is not clear the interaction of 
the SIP signaling and the DiffServ inter-domain interactions. In 3312, 
it is proposed to configure network resources e2e by means of a protocol 
like RSVP, being the RSVP signaling triggered by end-hosts at both ends 
of the communication session. In this context, 3312 approach may be an 
option to trigger the configuration of the necessary PDBs in all 
DiffServ domains between the involved end-hosts. However, the most 
suitable mechanism to configure PDBs in a set of DiffServ domains should 
be analyzed within DCPEL.

>
>> 5. Is development of signalling protocols in scope or not?
>>
>> 4.1.2 says that "...definition of an interdomain QoS signaling protocol
>> is considered as future work for the proposed DCPEL WG", but 4.2 only
>> lists interworking with existing protocols. This seems contradictory.
>
>
> So I think this is a language failure. I think we meant something more
> like "selection" instead of "definition" subject to the state of the
> art at the time interdomain is being considered. But perhaps others
> have a different opinion.

[Paulo] My opinion is somehow similar. It is not the main focus of DCPEL 
the definition of new signaling protocols. Like I said in my previous 
comment, our attention is to analyze what is the best approach to 
control the interworking between DiffServ domains. This analysis may 
lead to the selection of an existing protocol. For instance, we may 
conclude that QoS-NSLP may be used to provide some kind of interworking. 
But we may also conclude that other signaling protocols (presented as 
I-D) may also bring benefits to DiffServ interworking. In the later 
case, we must decide what to do. An hypothesis may be, for instance, to 
propose the specification of a new NSLP to the NSIS WG.

Cheers
Paulo


_______________________________________________
Dcpel mailing list
Dcpel@ietf.org
https://www1.ietf.org/mailman/listinfo/dcpel