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

[Yakov Rekhter <[e-mail]>]

Curtis,

> > This leads, to my thinking, to a document (the APR document under
> > discussion) whcih discusses when one wants direct VCs.  The important
> > observations (I think) are:
> > 1) That the desire for direct VCs is not coupled to whether the source
> >     and destination are in the same "address aggregate".  In particular, 
> >     it is independent of whether they are in the same lowest level
> >     "address aggregate" (traditionally known as "subnet").
> > 2) That the communicating host, informated by the policy of the system
> >     and the QoS requested by the user/application is in the best position
> >     to decide when to establish direct VCs.
> 
> Your conclusion 2) is predicated on their being an ommission in the
> int-serv work.  If so, fix the ommission for the general case, rather
> than stating that the only way to do this is to essentially ignore the
> work of RSVP and int-serv and limit yourself to directly connecting
> the end system to the NBMA.

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.