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

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>om>, Yakov Rekhter writes:
> 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 application
> s
>    is a good idea or not

If the application specifies QoS and traffic characteristics and
indirectly controls SVC management, then we are in agreement.  Then it
doesn't matter if the box it is running on sets up a VC or if it sits
on an ethernet and the next hop sets up a VC.  Are we in agreement on
this?

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

Not allowing for the possibility of that information being passed to
an adjacent box (specifically for when SVCs are not availaible on the
box running the application) would be counter to the rsvp and int-serv
directions.  Are we in agreement on that?

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

OK.

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

But I'm not arguing that the local/remote not be QoS based.  If you
look at the quote that you responded to it says "the application
passes QoS requirement or traffic characterisitics through RSVP
(possible passed it within the same box) and indirectly controls SVC
management, not directly".

> Yakov.

We may be closer to agreement than you think.  It may just be a matter
of wording at this point, particularly how we treat the case (in the
document) where RSVP does not offer an appropriate parameter space for
a class of QoS requirement or class of traffic.

Curtis