Subject: Re: [rsvp-dir] Fwd: Update from RSVP directorate on RSVP Candidate items?

From: Bruce Davie <[email-masked]>
Date: Fri, 6 Aug 2010 17:48:40 -0400

On Jul 27, 2010, at 12:16 PM, Gorry Fairhurst wrote:

> Bruce,
> 
> It's good to know that you favour adoption. I think we are still working out the ways the directorate will work.

Sorry for the delay... swamped like everyone else - commenting below on the 2 more complex drafts.
> 
> I'd really appreciate a bit more detail, since there are quite a few things that Chairs need to determine before we can allow the WG to consider adopting the draft - The sort of things I'm interested as a Chair are:
> 
> * What specs would this draft update: Does this seem to update IntServ? Is it a minor update to RSVP?

In my view, the 2 drafts MULTI_TSPEC and MULTI_PREEMPTION are an update to how Intserv is invoked by RSVP, that is to say, RFC 2210. It is relatively minor (although this is totally subjective). Intserv defined some services. RSVP was defined as  a mechanism to invoke services. What this draft does is it says that you can invoke a service by saying what service parameters you would really like, and which lesser set of parameters you would accept. In the original RSVP design, you could only send one set of parameters and get a yes/no answer.

> 
> * Are there any areas that are less mature than others from a techical point of view: Can you see sections that would need more work? are there missing sections?

The draft looks pretty complete to me. But it will need careful line-by-line review by one or more RSVP experts.

> 
> * Do we need to do this? Why?

Well, it seems that in the current state of things, you can't use RSVP to reserve the "right" amount of resources when the endpoints could live with a range of possible levels. For example, if two endpoints support a high bit rate and low bit rate encoding, you can't settle on the right choice of codec in  a single RTT today. So, to the extent that you accept that this is a problem (which I do) yes, we need the draft.

> 
> * Do you know of indications that there may be a "customer" for the technology: e.g. another working group? to support an application? etc?

This is most useful to telephony/video conferencing apps in my reading. 

> 
> * Do you know of other things that may help the chairs understand whether the WG should devote energy to this draft?
> 
> * Would one or more members of the directorate volunteer to comment on progress of this and also commit to reviewing the document as we get to WGLC?

I'm willing to do this (but I see that Bob Briscoe has also done a review which he has not yet posted.) 

Bruce

> 
> * Anything else?
> 
> Best wishes,
> 
> Gorry
> 
> 
> On 27/07/2010 16:40, Bruce Davie wrote:
>> Directorate,
>> I don't feel I can speak for the directorate at this point, as I have
>> only heard back from Bob Briscoe to date, and only with questions. For
>> the record, I am in favor of the WG adopting the 3 drafts that I asked
>> you to look at, but I'd like to hear from some more directorate members.
>> 
>> Is anyone there?
>> 
>> Bruce
>> 
>> 
>> 
>> 
>> Begin forwarded message:
>> 
>>> *From: *Gorry Fairhurst <[email-masked]
>>> <mailto:[email-masked]>>
>>> *Date: *July 27, 2010 9:45:39 AM EDT
>>> *To: *Francois Le Faucheur <[email-masked]
>>> <mailto:[email-masked]>>
>>> *Cc: [email-masked] <mailto:[email-masked]>,
>>> "[email-masked] <mailto:[email-masked]>
>>> chair" <[email-masked]
>>> <mailto:[email-masked]>>, tsvwg WG <[email-masked]
>>> <mailto:[email-masked]>>
>>> *Subject: **Re: [rsvp-dir] Update from RSVP directorate on RSVP
>>> Candidate items?*
>>> *Reply-To: [email-masked] <mailto:[email-masked]>
>>> 
>>> It would indeed be good to get a summary of feedback from the rsvp
>>> directorate on these 2 drafts - please reply to tsv-ads and
>>> tsvwg-chairs, if it is appropriate, please also feel free to copy the
>>> tsvwg list.
>>> 
>>> My understanding is that this consultation is to provide feedback for
>>> the ADs and Chairs. These inputs can help to determine if there is
>>> sufficient interest and a need to adopt a draft. The RSVP directorate
>>> are not enabled to make a decision on what drafts are adopted.
>>> 
>>> If the directorate provide comments that support progression it may be
>>> helpful to also suggest some document reviewers who would commit to
>>> comment on the document both as it progresses through the WG *and* in
>>> the WGLC.
>>> 
>>> Gorry
>>> 
>>> On 27/07/2010 15:26, Francois Le Faucheur wrote:
>>>> Hello RSVP Directorate,
>>>> 
>>>> Any chance to get an update from RSVP Directorate regarding the
>>>> submitted RSVP candidate items before TSVWG (Thur am)?
>>>> 
>>>> I believe the submitted candidate items are:
>>>> * RSVP Multi-TSPEC/Multi-PREEMPTION
>>>> * RSVP Flexible Resource Sharing
>>>> 
>>>> Also, for memory:
>>>> * the meaty part of "draft-narayanan-tsvwg-rsvp-resource-sharing" has
>>>> been merged into "draft-berger-ccamp-assoc-info"
>>>> * so the latest version of "draft-narayanan-tsvwg-rsvp-resource-sharing"
>>>> only contains a smaller optional delta on top of
>>>> "draft-berger-ccamp-assoc-info"
>>>> * the CCAMP plan is that "draft-berger-ccamp-assoc-info" be progressed
>>>> in CCAMP
>>>> * I believe CCAMP is also proposing to progress
>>>> "draft-narayanan-tsvwg-rsvp-resource-sharing" as a companion document
>>>> (this proposal does make sense to me since, again, the real meat is in
>>>> "draft-berger-ccamp-assoc-info").
>>>> 
>>>> It would be good to get views on this plan.
>>>> 
>>>> Thanks
>>>> 
>>>> Francois
>>>> 
>>>>> 
>>>>> On 10 May 2010, at 15:01, Lars Eggert wrote:
>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> following the discussion during the IETF-77 TSVAREA meeting on how to
>>>>>> better review and progress extensions to (non-TE) RSVP and IntServ,
>>>>>> the transport area directors have formed a new RSVP directorate and
>>>>>> given it these tasks:
>>>>>> 
>>>>>> * Review of all new work related to RSVP and Integrated Services that
>>>>>> is proposed for IETF adoption. The purpose of this review is to
>>>>>> advise the ADs and the chairs of the Transport Area Working Group
>>>>>> (TSVWG) on whether a particular proposal should be taken on as a
>>>>>> work item. The directorate will continue to guide and review such
>>>>>> new work in TSVWG until it is ready for publication as an RFC.
>>>>>> 
>>>>>> * Review of selected documents during IETF last call or under IESG
>>>>>> review. The directorate monitors ongoing IETF work and should
>>>>>> independently decide when a document will benefit from their review,
>>>>>> assign a reviewer and enter into a follow-on discussion with the
>>>>>> authors. When deemed necessary, the area directors will on occasion
>>>>>> directly consult the directorate while forming their opinion on
>>>>>> selected documents being under review by the IESG.
>>>>>> 
>>>>>> * Cross-working group review. RSVP documents may have relevance to
>>>>>> several working groups, including TSVWG and MPLS-related groups
>>>>>> such as MPLS WG and CCAMP WG. The directorate will ensure that
>>>>>> drafts submitted to TSV WG are reviewed in the appropriate MPLS-related
>>>>>> WGs if necessary, and will bring drafts from the MPLS-related WGs
>>>>>> to the attention of the TSV WG as appropriate.
>>>>>> 
>>>>>> The directorate can be reached at [email-masked]
>>>>>> <mailto:[email-masked]>
>>>>>> <mailto:[email-masked]>. Additional information about the
>>>>>> directorate is at
>>>>>> http://trac.tools.ietf.org/area/tsv/trac/wiki/RSVP-Directorate.
>>>>>> 
>>>>>> Lars
>>>>> 
>>>> 
>>>> *
>>>> Francois Le Faucheur*
>>>> *Distinguished Engineer*
>>>> *Corporate Development*
>>>> [email-masked] <mailto:[email-masked]>
>>>> <mailto:[email-masked]>
>>>> Phone: *+33 49 723 2619*
>>>> Mobile: *+33 6 19 98 50 90*
>>>> 
>>>> 
>>>> 
>>>> 
>>>> *Cisco Systems France*
>>>> Greenside
>>>> 400 Ave de Roumanille
>>>> 06410 Sophia Antipolis
>>>> France
>>>> Cisco.com <http://Cisco.com> <http://www.cisco.com>
>>>> 
>>>> 
>>>> 
>>>> Think before you print.
>>>> 
>>>> This email may contain confidential and privileged material for the sole
>>>> use of the intended recipient. Any review, use, distribution or
>>>> disclosure by others is strictly prohibited. If you are not the intended
>>>> recipient (or authorized to receive for the recipient), please contact
>>>> the sender by reply email and delete all copies of this message.
>>>> 
>>>> Cisco Systems France, Société à responsabiité limitée, Rue Camille
>>>> Desmoulins – Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy les
>>>> Moulineaux, Au capital de 91.470 €, 349 166 561 RCS Nanterre, Directeur
>>>> de la publication: Jean-Luc Michel Givone.
>>>> 
>>>> For corporate legal information go to:
>>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>>>> 
>>>> 
>>> 
>>> _______________________________________________
>>> rsvp-dir mailing list
>>> [email-masked] <mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/rsvp-dir
>> 
>> 
>> 
>> _______________________________________________
>> rsvp-dir mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/rsvp-dir
>

---

From: Bruce Davie <[email-masked]>
Date: Fri, 6 Aug 2010 18:01:52 -0400

Replying now about draft-narayanan-tsvwg-rsvp-resource-sharing-02.txt

> * What specs would this draft update: Does this seem to update IntServ? Is it a minor update to RSVP?

This is a straight update to RFC 2205. It is minor (IMHO). Much of the content has been moved to a CCAMP companion draft draft-berger-ccamp-assoc-info-01
> * Are there any areas that are less mature than others from a techical point of view: Can you see sections that would need more work? are there missing sections?
It's in good shape
> * Do we need to do this? Why?

RSVP currently offers some support for resource sharing (historically designed with multicast applications in mind). However, this is restricted to sharing across reservations with the same destination transport address (ie with same Session). The proposed extensions retain the existing concept of resource sharing, but adds the flexibility to apply resource sharing across any arbitrary set of reservations. This has been known for some years to be a useful idea for call scenarios that are more complex that 1-1, e.g. 3-way calling, call-waiting, etc.

> * Do you know of indications that there may be a "customer" for the technology: e.g. another working group? to support an application? etc?

Supports telephony/video conferencing apps

> * Do you know of other things that may help the chairs understand whether the WG should devote energy to this draft?

The fact that most of the work is done in CCAMP should make this a small effort for TSVWG.
> * Would one or more members of the directorate volunteer to comment on progress of this and also commit to reviewing the document as we get to WGLC?

Yes, I can do this one (and I hope other directorate members might be able to).

Bruce