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

Yakov Rekhter <yakov@cisco.com> Thu, 26 October 1995 03:59 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05312; 25 Oct 95 23:59 EDT
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa05308; 25 Oct 95 23:59 EDT
Received: from maelstrom.nexen.com ([204.249.99.5]) by guelah.nexen.com (8.6.12/8.6.12) with ESMTP id XAA21489; Wed, 25 Oct 1995 23:24:33 -0400
Received: (from root@localhost) by maelstrom.nexen.com (8.6.12/8.6.12) id XAA03466 for rolc-out; Wed, 25 Oct 1995 23:34:48 -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 XAA03457 for <rolc@nexen.com>; Wed, 25 Oct 1995 23:34:45 -0400
Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by guelah.nexen.com (8.6.12/8.6.12) with ESMTP id XAA21485 for <rolc@nexen.com>; Wed, 25 Oct 1995 23:23:24 -0400
Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with SMTP id UAA11401; Wed, 25 Oct 1995 20:30:08 -0700
Message-Id: <199510260330.UAA11401@hubbub.cisco.com>
To: Tim Salo <salo@msc.edu>
cc: rolc@nexen.com
Subject: Re: Last Call for draft-ietf-rolc-apr-00.txt
In-reply-to: Your message of "Wed, 25 Oct 95 22:24:03 CDT." <199510260324.WAA04904@uh.msc.edu>
Date: Wed, 25 Oct 95 20:30:07 PDT
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Yakov Rekhter <yakov@cisco.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/

Tim,

> > To: curtis@ans.net
> > Cc: rolc@nexen.com
> > Subject: Re: Last Call for draft-ietf-rolc-apr-00.txt 
> > Date: Wed, 25 Oct 95 19:31:00 PDT
> > From: Yakov Rekhter <yakov@cisco.com>
> > 	[...]
> > And I'd like to finess the issue of whether this control is done directly
> > or indirectly. I think it should be sufficient if we'll just say that
> > "SVC management should be driven by the QoS and/or traffic requriements
> > of the application".
> 
> In an environment where some SVCs cost money and others don't, _products_
> will need to ensure that SVC management takes costs into account.

You are certainly correct on this, and I'll add this to the document.
So, the local/remote outcome could be controlled not only by the QoS
and/or traffic requirements, but by cost of SVC as well.

Yakov.