[rsvp-dir] Our first work items for RSVP Directorate

Bruce Davie <bdavie@cisco.com> Fri, 04 June 2010 16:41 UTC

Return-Path: <bdavie@cisco.com>
X-Original-To: rsvp-dir@core3.amsl.com
Delivered-To: rsvp-dir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83B9E3A68A4 for <rsvp-dir@core3.amsl.com>; Fri, 4 Jun 2010 09:41:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Level:
X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ARKz6Hm9RTBe for <rsvp-dir@core3.amsl.com>; Fri, 4 Jun 2010 09:41:36 -0700 (PDT)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 5A8633A67A1 for <rsvp-dir@ietf.org>; Fri, 4 Jun 2010 09:41:36 -0700 (PDT)
Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AoAFAALJCEyrR7Hu/2dsb2JhbACSKYwccaU8mhKFFwQ
X-IronPort-AV: E=Sophos;i="4.53,362,1272844800"; d="scan'208";a="207284929"
Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 04 Jun 2010 16:41:22 +0000
Received: from [10.32.241.76] ([10.32.241.76]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o54GfMpO022076 for <rsvp-dir@ietf.org>; Fri, 4 Jun 2010 16:41:22 GMT
From: Bruce Davie <bdavie@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Fri, 4 Jun 2010 12:41:21 -0400
Message-Id: <BC6E4F60-899C-4C86-94C1-3F15D98303DD@cisco.com>
To: rsvp-dir@ietf.org
Mime-Version: 1.0 (Apple Message framework v1078)
X-Mailer: Apple Mail (2.1078)
Subject: [rsvp-dir] Our first work items for RSVP Directorate
X-BeenThere: rsvp-dir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: RSVP directorate <rsvp-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rsvp-dir>, <mailto:rsvp-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rsvp-dir>
List-Post: <mailto:rsvp-dir@ietf.org>
List-Help: <mailto:rsvp-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rsvp-dir>, <mailto:rsvp-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Jun 2010 16:41:38 -0000

Folks,
 There are a few drafts floating around that I think we should take a look at and make a recommendation to the ADs regarding their suitability for the TSVWG. These drafts are:

draft-narayanan-tsvwg-rsvp-resource-sharing-02 

draft-lefaucheur-tsvwg-rsvp-multiple-preemption-02.txt
draft-polk-tsvwg-intserv-multiple-tspec-03.txt

The first one seems pretty non-controversial. Here are comments from the author:
> 
> draft-narayanan-tsvwg-rsvp-resource-sharing-02 is now a companion draft to draft-berger-ccamp-assoc-info-01, and contains only the RSVP-CAC-specific part of the resource sharing thingy. Given that TSVWG is the place for RSVP CAC extensions, yes, I would think TSVWG is the place for it. It's a very small draft basically defining a new codepoint (Resource Sharing Remote-ID Association) with a small behavioural change (only treat this Association-ID as binding on the Resv, not on the Path), so I don't envision any significant backpressure of the form "this is not a small change to RSVP".

I would like to recommend that this be made a TSVWG work item. Any comments or concerns?

The lefaucheur and polk drafts should probably be treated as a pair. Both relate to the issue of reserving an appropriate level of resource (e.g. bandwidth) in a single round trip when it is not known in advance how much resource is available. This is quite helpful, for example, in a video conferencing application that has a choice of codecs. The polk draft in particular was (I think) a catalyst for the RSVP discussion in Anaheim because it seemed to be stretching the scope of what has normally been done in TSVWG for RSVP maintenance.

Given the scope of the directorate, I would like a couple of folks on the directorate to review those drafts and then we can discuss whether they should become TSVWG work items. Can I have some volunteers?

Thanks,
Bruce