The Routing Over Large Clouds Mailing List Archive by date

[Curtis Villamizar <curtis@ans.net>]

In message <199510261716.KAA09024@hubbub.cisco.com>, Yakov Rekhter writes:
> Curtis,
> 
> > The remaining
> > difference may be that I wish to document the desirable case to be a
> > standardized parameterization which could be used to allow indirection
> > in cases where it was needed.  I'd like to document the case where no
> > appropriate parameterization is available in a standard protocol
> > making it necessary to restrict SVC management for an application
> > class as a practical reality that is less desirable and hopefully
> > temporary situation as the reservation parameterization can be
> > expected to evolve slowly but steadily.  Some vendors may decide they
> > don't want their proprietary local/remote "trick" standardized.  IMO
> > the architecture document can acknowlege this (if you insist) but
> > strongly discourage the practice.
> 
> While I would agree with what you said here, I am not sure whether this
> belongs to the APR document. So, I'd like to get a feedback from other
> folks on the list whether they think this should be included in the
> document, or whether this issue should be addressed in some other
> WG, like rsvp or int-serv.
> 
> Yakov.


Then this document should be reviewed by those WGs as well since it
relates to communicating QoS needs from the application in order to
obtain specific service.

It absolutely should NOT document the case where an application makes
a direct SVC management decision as the default.  If anything it
should not mention that case at all, and simply describe the
communication of application characteristics to another layer which
can act on it directly or pass the information on through a
reservation protocol.  Then leave the details of characterizing the
application and requirements to int-serv and the details of passing
the information on to RSVP.

It should not try to circumvent those efforts.

Curtis