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

[Lixia Zhang <[e-mail]>]

> We don't need to ignore the work on RSVP and int-serv, but we also need
> to remember that if a pair of hosts on a common NBMA would like to
> establish a direct SVC (because of QoS and/or traffic characteristics),
> then RSVP has to do with this. After all, RSVP is a protocol to reserve
> resources on routers. In the scenario I described there are no routers
> involved (as there is a direct SVC). The decision to establish such SVC
> is controlled by the application (through an API). RSVP is *NOT* a
> QoS-capable host API.
>  
> Yakov.

I was not on rolc list but a friend forwarded the above msg to me.

I disagree (of course with the caveat that I do not know the full
context of this discussion).

The above quote suggests that the host has to have at least two API
interfaces for QoS management, one copes with the case of the other
end being on a directly connected ATM network, and a second one handle
more general case of QoS over the Internet (even there some fragments
along the path may be ATM subnets).

Fine.  But does this also suggest that, when some BTM technology shows
up next year, we'd add a third QoS API to handle that???

What about a multicast application, and a new member want to join but
is not on the same ATM net?

Yes RSVP is a protocol that makes reservations on IP boxes; hosts
are IP-speaking boxes too.  Therefore I do consider RSVP API as a
general QoS-capable host API.

As I said already, some parts of the greater Internet may be made of
ATM subnets, therefore RSVP necessarily has to handle all the issues
of interfacing with ATM.  And when BTM shows up, RSVP, as a resource
reservation protocol for the Internet, is obligated to handle that
too.

Why should we have a separate API for a new subnet type?  I do not
recall we ever had an Ethernet API.

Think in terms of a global picture.
Dont be too near-sighted; get a new pair of glasses.

Lixia