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

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

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

---

From: "Hancock, Robert" <[email-masked]>
Date: Mon, 6 Mar 2006 09:24:40 -0000

hi,

> be analyzed within DCPEL.

All of this is true. However, it doesn't explain why 3312 would be
relevant to DCPEL, unless I've fundamentally misunderstood the 
scope of DCPEL.
To put is more concretely, 3312 (as far as I understand) assumes
the existence of a resource request mechanism initiated by the end
point, and explains how end systems should manage the resource 
transaction and session signalling transaction. But the resource
management mechanism (RSVP, NSIS or whatever) doesn't care that 
3312 is being used - is DCPEL any different?
To put it another way, 3312 is about extending SDP with additional
information. Is it in the scope of DCPEL to take part in the SDP
negotiation?

r.