Re: Last Call for draft-ietf-rolc-apr-00.txt

Juha Heinanen <jh@lohi.dat.tele.fi> Thu, 26 October 1995 09:00 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07692; 26 Oct 95 5:00 EDT
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa07688; 26 Oct 95 5:00 EDT
Received: from maelstrom.nexen.com ([204.249.99.5]) by guelah.nexen.com (8.6.12/8.6.12) with ESMTP id EAA22211; Thu, 26 Oct 1995 04:32:13 -0400
Received: (from root@localhost) by maelstrom.nexen.com (8.6.12/8.6.12) id EAA05959 for rolc-out; Thu, 26 Oct 1995 04:43:24 -0400
Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.6.12/8.6.12) with ESMTP id EAA05950 for <rolc@nexen.com>; Thu, 26 Oct 1995 04:43:21 -0400
Received: from lohi.dat.tele.fi (lohi.dat.tele.fi [193.167.64.161]) by guelah.nexen.com (8.6.12/8.6.12) with ESMTP id EAA22207 for <rolc@nexen.com>; Thu, 26 Oct 1995 04:31:57 -0400
Received: (from jh@localhost) by lohi.dat.tele.fi (8.6.12/8.6.12) id KAA02432; Thu, 26 Oct 1995 10:35:17 +0200
Date: Thu, 26 Oct 1995 10:35:17 +0200
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Juha Heinanen <jh@lohi.dat.tele.fi>
Message-Id: <199510260835.KAA02432@lohi.dat.tele.fi>
To: yakov@cisco.com
CC: curtis@ans.net, rolc@nexen.com
In-reply-to: <199510260305.UAA10392@hubbub.cisco.com> (yakov@cisco.com)
Subject: Re: Last Call for draft-ietf-rolc-apr-00.txt
X-Orig-Sender: owner-rolc@nexen.com
Precedence: bulk
X-Info: Submissions to rolc@nexen.com
X-Info: [Un]Subscribe requests to rolc-request@nexen.com
X-Info: Archives for rolc via ftp://ietf.cnri.reston.va.us/ietf-mail-archive/rolc/ After all, RSVP is a protocol to reserve resources on routers. In the scenario I described there are no routers involved (as there is a direct SVC). The decision to establish such SVC is controlled by the application (through an API). RSVP is *NOT* a QoS-capable host API.

i'm lost.  based on what curtis has written, i have got the very
impression that int-serv/rsvp also includes a qos aware host api.  what
sense would it make to start desiging a protocol to reserve resource on
routers, if we don't even know that kind of resources would need to be
reserved?  there must first be the api and based on that people can
start designing the necessary reservation protocols for routers and
direct mappings for routerless subnetworks, such as atm.

-- juha