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

Fred Baker <fred@cisco.com> Thu, 26 October 1995 22:12 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25760; 26 Oct 95 18:12 EDT
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa25756; 26 Oct 95 18:12 EDT
Received: from maelstrom.nexen.com ([204.249.99.5]) by guelah.nexen.com (8.6.12/8.6.12) with ESMTP id RAA29231; Thu, 26 Oct 1995 17:48:09 -0400
Received: (from root@localhost) by maelstrom.nexen.com (8.6.12/8.6.12) id RAA15565 for rolc-out; Thu, 26 Oct 1995 17:59:29 -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 RAA15556 for <rolc@nexen.com>; Thu, 26 Oct 1995 17:59:26 -0400
Received: from stilton.cisco.com (stilton.cisco.com [171.69.1.161]) by guelah.nexen.com (8.6.12/8.6.12) with ESMTP id RAA29227 for <rolc@nexen.com>; Thu, 26 Oct 1995 17:47:56 -0400
Received: from [171.69.126.203] (sl-chanty-02.cisco.com [171.69.126.156]) by stilton.cisco.com (8.6.8+c/8.6.5) with SMTP id OAA27673; Thu, 26 Oct 1995 14:51:56 -0700
X-Sender: fred@stilton.cisco.com
Message-Id: <v0213050eacb5ae123b0b@[171.69.126.203]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 26 Oct 1995 14:52:05 -0700
To: Juha Heinanen <jh@lohi.dat.tele.fi>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Fred Baker <fred@cisco.com>
Subject: Re: Last Call for draft-ietf-rolc-apr-00.txt
Cc: curtis@ans.net, yakov@cisco.com, rolc@nexen.com
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/

At 10:21 AM 10/26/95, Juha Heinanen wrote:
>this is what i have never understod about rsvp.  how can a host sitting
>on a shared media, like ethernet, make any reservation whatsoever.  so
>isn't it a requirement for rsvp to work that the hosts are directly
>connected to such a link layer network, eg. atm, that supports
>reservation requests?  what does it help if all the routers in the whole
>internet are rsvp capable if the last hop isn't?

well, we're discussing a "mother may I" protocol extension to RSVP that
would limit not only what the device on the shared medium does but what
reservations are made in toto on the medium. That's not a current goal -
the RSVP system right now guarantees what *it* will do, not what a queuing
system out of its control will do.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
...Every morning is the dawn of a new error...