IETF Logo Mail Archive

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

Curtis Villamizar <curtis@ans.net> Wed, 25 October 1995 17:55 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14555; 25 Oct 95 13:55 EDT
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa14549; 25 Oct 95 13:55 EDT
Received: from maelstrom.nexen.com ([204.249.99.5]) by guelah.nexen.com (8.6.12/8.6.12) with ESMTP id NAA16103; Wed, 25 Oct 1995 13:15:26 -0400
Received: (from root@localhost) by maelstrom.nexen.com (8.6.12/8.6.12) id NAA26290 for rolc-out; Wed, 25 Oct 1995 13:19:21 -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 NAA26277 for <rolc@nexen.com>; Wed, 25 Oct 1995 13:19:18 -0400
Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by guelah.nexen.com (8.6.12/8.6.12) with ESMTP id NAA16031 for <rolc@nexen.com>; Wed, 25 Oct 1995 13:08:02 -0400
Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.6.12/8.6.12) with ESMTP id NAA17563; Wed, 25 Oct 1995 13:17:56 -0400
Message-Id: <199510251717.NAA17563@brookfield.ans.net>
To: kandlur@watson.ibm.com
cc: curtis@ans.net, Yakov Rekhter <yakov@cisco.com>, rolc@nexen.com
Reply-To: curtis@ans.net
Subject: Re: Last Call for draft-ietf-rolc-apr-00.txt
In-reply-to: Your message of "Tue, 24 Oct 1995 16:46:00 CDT." <9510242046.AA19617@vindhya.watson.ibm.com>
Date: Wed, 25 Oct 1995 13:17:55 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Curtis Villamizar <curtis@ans.net>
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/

In message <9510242046.AA19617@vindhya.watson.ibm.com>om>, Dilip Kandlur writes:
> 
> Curtis,
> response to some of your comments.
> 
> 
>     To exploit capabilities provided by the SVC-based Data Link
>     subnetworks we propose to allow SVC management to be directly
>     controlled by applications,
> 
>  This is a bad idea and runs counter to rsvp and int-serv directions.

You cut this off.  It is counter to rsvp and int-serv directions
because the application passes QoS requirement or traffic
characterisitics through RSVP (possible passed it within the same box)
and indirectly controls SVC management, not directly.

Curtis

v2.8.7 | Report a Bug | By Email