The Routing Over Large Clouds Mailing List Archive by date[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
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.
|
|