The Routing Over Large Clouds Mailing List Archive by date

Cell Relay Retreat>List Archive>month:1995-Oct> msg00082



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

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

  • From: Yakov Rekhter <yakov@cisco.com>
  • Date: Wed, 25 Oct 95 15:13:54 PDT
  • cc: rolc@nexen.com
  • X-Orig-Sender: owner-rolc@nexen.com

Curtis,

> >     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.

First of all, there are two distinct questions:

1) Whether allowing SVC management to be directly controlled by applications,
   and specifically by the QoS and/or traffic requirements of the applications
   is a good idea or not

2) Whether allowing SVC management to be directly controlled by applications
   and specifically by the QoS and/or traffic requirements of the applications
   runs counter to rsvp and int-serv directions

So, I would suggest we'll debate these two questions separately.

Wrt to the first question, I've yet to see any compelling technical
argument that would show why placing SVC management ("local/remote",
"dedicated/shared") under the control of QoS is a bad idea.

Yakov.